From rrichards@cdatazone.org Thu Jul 1 03:26:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FEE43A67E2 for ; Thu, 1 Jul 2010 03:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKMYtIBe6EuG for ; Thu, 1 Jul 2010 03:26:11 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by core3.amsl.com (Postfix) with ESMTP id BAA773A67BD for ; Thu, 1 Jul 2010 03:26:11 -0700 (PDT) Received: from [67.158.171.203] (helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1OUGyI-00073t-Pn; Thu, 01 Jul 2010 10:26:19 +0000 Message-ID: <4C2C6D4A.5010401@cdatazone.org> Date: Thu, 01 Jul 2010 06:26:18 -0400 From: Rob Richards User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" , eran@hueniverse.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP2Go-MailScanner-Information: Please contact support@smtp2go.com for more information X-SMTP2Go-MailScanner-ID: 1OUGyI-00073t-Pn X-SMTP2Go-MailScanner: Found to be clean X-SMTP2Go-MailScanner-From: rrichards@cdatazone.org Subject: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 10:26:12 -0000 Versioning is still something that needs to be addressed before being being able to consider the draft core complete. On this I'm still of the opinion that at the very minimum you will need to require an oauth_version parameter for the resource endpoints, if not also for the others as well. Rob From jricher@mitre.org Thu Jul 1 06:02: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 3C31F3A67EA for ; Thu, 1 Jul 2010 06:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.557 X-Spam-Level: X-Spam-Status: No, score=-4.557 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkF9fA4a8fIh for ; Thu, 1 Jul 2010 06:02:51 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 6E3BA3A67B2 for ; Thu, 1 Jul 2010 06:02:51 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o61D32fR023117 for ; Thu, 1 Jul 2010 09:03:02 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o61D32UD023111; Thu, 1 Jul 2010 09:03:02 -0400 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, 1 Jul 2010 09:03:02 -0400 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Thu, 1 Jul 2010 09:03:01 -0400 Message-ID: <1277989381.28743.160.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: OAuth WG Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 13:02:53 -0000 #2 is the best route forward. If a particular extension requires its parameters to be present and handled, then it has a few different options. One is breaking at the server side, either with an explicit error or throwing away some other required bit, which has been mentioned. Another is looking for a callback return parameter on the client side. If the server doesn't return it, then the server didn't support that extension and the client should break the flow at that point. I want to ask the list though: what exactly do we mean by ignoring parameters? Is it that a server library will ignore unknown parameters coming in when doing its processing? That I agree with completely. Same with parameters coming back to the client from the server. If you don't know about it, don't try to do anything with it. The one case that I don't think libraries can *ignore* extra parameters is when using a client library to build a request to a server. A particular server implementation may require extra parameters on the request in order to function (such as MediaWiki's title parameter), and a client needs to be able to pass such things through. These parameters can effectively be thought of as part of the address of the server URL, can be ignored by the OAuth part of the server process, but cannot be dropped by the client building the request. So "ignore" in this case means "quietly pass through" and not "drop". In most instances outside of the Big Web Companies, OAuth is going to be the new kid being grafted onto an existing framework or application. As such, it really needs to play nice. -- Justin On Mon, 2010-06-28 at 20:59 -0400, Eran Hammer-Lahav wrote: > There are 3 general ways to deal with this: > > > > 1. Break on unrecognized parameters – this tends to make the use of > extensions hard, and at a minimum requires an error to include the bad > parameter in a machine readable way (so a library can figure out an > extension is not supported). > > > > 2. Ignore unrecognized parameters – this is the usual way of dealing > with extensible protocols. It has security implications when extension > parameters must not be ignored. However, the workaround is simply to > break something else (i.e. replace the client_id with something else > that will cause the normal flow to break). > > > > 3. Same as #2 but include a directive which means ‘must not ignore any > parameter; return error if any parameter is unknown’. XRD used to > include such a ‘must-support’ attribute for properties but was dropped > due to lack of use cases. > > > > I think #2 offers a good enough balance here, but am happy to discuss > #3 if people have actual use cases where ignoring an extension will > cause security issues. Note that with the expectation of error codes, > my upcoming extensibility proposal does not allow adding any new > parameter values (only new parameters). > > > > EHL > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Yaron Goland > Sent: Monday, June 28, 2010 3:02 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] How do we deal with unrecognized elements in > requests and responses? > > > > > In a private thread with Eran an issue came up regarding how to handle > unrecognized arguments in OAuth requests and responses. > > > > For example, if a token endpoint receives an access token request that > contains both a client_id and a client_foo_bar argument, what should > it do? Should it reject the request since it doesn’t recognize > client_foo_bar? Should it ignore client_foo_bar and just process the > request based on client_id? > > > > Similarly imagine that a response to an access token request contains > a JSON member with some unrecognized name. What’s the right behavior? > Ignore the unrecognized value? Or treat the response as badly > formatted and fail out? > > > > We need to define in the spec how to deal with unrecognized > extensions. Typically the rule is ‘ignore what you don’t recognize’ > but there is a countervailing rule which applies here which is > “security is different”. Typically ignoring unrecognized elements in a > security context can lead to security holes. > > > > Just looking at the history of OAuth I suspect we need to go with the > ignore rule and then explore ad nauseam in the security considerations > section all the ways that the ignore rule can go wrong if extensions > aren’t handled carefully. > > > > Thoughts? > > > > Thanks, > > > > Yaron > > From pelleb@gmail.com Thu Jul 1 06: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 B863C3A67EA for ; Thu, 1 Jul 2010 06:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nunDiHlxlU1p for ; Thu, 1 Jul 2010 06:41:12 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 853693A67B2 for ; Thu, 1 Jul 2010 06:41:12 -0700 (PDT) Received: by pzk36 with SMTP id 36so426425pzk.31 for ; Thu, 01 Jul 2010 06:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=oWI5XEMgtlPyTeWzW+gVHCXNoFp3/fTp/Bq9dEzwr/M=; b=atClXsUsFkUjI7pBYZhQUrTva49NBDb235RrlwcmO25XLUFw0LvNRESarxc5NACYEf Sy613YwjTQgzlqWhKeNnb8ot/9NtJ00BbBnlTYefoAZ5rW6EzkHvs4HnLMm7lN8lghb5 CBNB9Y+4sOBBLTbTzrMS+jglrBtkus95txlYE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=GarXbmkoFs8JigdRL7lhbrUCd9SUrws+mLRQ1J0uGGHSZho5smSmByrblxr52PtN/2 oADmZISd7vRqpagZfaFtsBeSL1SWwu3xJVxGtT3g3Jbf3zzIehHwMl9vJyANx8Tgk8eG BQ4wLTlYQyXM0JN6mgPqJp2u88gKBckjYwai8= MIME-Version: 1.0 Received: by 10.115.84.40 with SMTP id m40mr11889541wal.223.1277991593182; Thu, 01 Jul 2010 06:39:53 -0700 (PDT) Sender: pelleb@gmail.com Received: by 10.114.58.5 with HTTP; Thu, 1 Jul 2010 06:39:52 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 1 Jul 2010 09:39:52 -0400 X-Google-Sender-Auth: BzeUaYoL2HgDi_mvqDaY57ZcJLE Message-ID: From: Pelle Braendgaard To: Lukas Rosenstock Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Underscore, dash, green, blue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 13:41:13 -0000 I already implemented 09 but it was a (very tiny) bit of a hassle to have to convert underscores. So I also agree with 3 except headers On Thu, Jul 1, 2010 at 2:41 AM, Lukas Rosenstock w= rote: > 3 except headers. > > 2010/7/1 Eran Hammer-Lahav : >> First, sorry about this. J >> >> >> >> I do my best not to ask the group this kind of questions and just pick >> something on my own, but I can=E2=80=99t decide so I=E2=80=99ll run a qu= ick vote (yes, a >> VOTE =E2=80=93 I can=E2=80=99t imagine seeking a consensus call on this)= . >> >> >> >> -09 uses underscores for parameter names (except for in the headers) and >> dashes for parameter values. This seems like an odd selection. Before, i= t >> used dashes for header parameter names, and underscore everywhere else. = Not >> great either. >> >> >> >> So=E2=80=A6 >> >> >> >> The changes my OCD can live with: >> >> >> >> 1. Use dashes throughout >> >> 2. Use underscores for all parameter names (headers included), dashes fo= r >> all values >> >> 3. Use underscores throughout >> >> >> >> I want to get this done with in a day because people are writing code fo= r >> -09 and I=E2=80=99d like to stop making changes beyond editorial. =C2=A0= I just think that >> having different styles between the endpoint parameters and header >> parameters is broken. >> >> >> >> EHL >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > > -- > http://lukasrosenstock.net/ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 http://agree2.com - Reach Agreement! http://stakeventures.com - My blog about startups and agile banking From pelleb@gmail.com Thu Jul 1 06:42: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 AA1683A68E3 for ; Thu, 1 Jul 2010 06:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9atAC3TvpGvr for ; Thu, 1 Jul 2010 06:42:44 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 2768C3A68A0 for ; Thu, 1 Jul 2010 06:42:43 -0700 (PDT) Received: by pvd12 with SMTP id 12so1091307pvd.31 for ; Thu, 01 Jul 2010 06:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=uUM/vSS2T3oRrUBOOx0QYIlL6JdHJClJeBfO9wqQgLo=; b=ehlj71KHQe9Aj+bJa77wy07OSYWNCzJP1kyt+dlUeboUiZcNfGnDnxNSHAcNYYTgxP 7P7WbEn4owaS46h9nid9TQryN0+FnBCGYGDO5NsTIkgjHrzzUCBmOUP2A+/0blTXpoBq NvEw09ytVHAPq1dtj2WS30b9R6Ba7QOEPUhnw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=IlyvJvu692EotBRiLm8CiiET8ySe9hUdI3vVlFFQM3mn6n+q5VLZnwwzGdPcK15DLZ 1VS0H9WTxugIXaYenhJmbgMP70na6yZx4H43skbmjsEmEI6jFDPGbkhaIVz27RbvFnhP aSegHRC9X9aMzgn0H74YSoGIWyp9Rq4YtvRl0= MIME-Version: 1.0 Received: by 10.114.188.30 with SMTP id l30mr11973332waf.134.1277991769803; Thu, 01 Jul 2010 06:42:49 -0700 (PDT) Sender: pelleb@gmail.com Received: by 10.114.58.5 with HTTP; Thu, 1 Jul 2010 06:42:49 -0700 (PDT) In-Reply-To: <1277989381.28743.160.camel@localhost.localdomain> References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1277989381.28743.160.camel@localhost.localdomain> Date: Thu, 1 Jul 2010 09:42:49 -0400 X-Google-Sender-Auth: bdLaIlgbmUZOo2E4Mni1rOCu6W0 Message-ID: From: Pelle Braendgaard To: Justin Richer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 13:42:46 -0000 #2 makes most sense to me On Thu, Jul 1, 2010 at 9:03 AM, Justin Richer wrote: > #2 is the best route forward. If a particular extension requires its > parameters to be present and handled, then it has a few different > options. One is breaking at the server side, either with an explicit > error or throwing away some other required bit, which has been > mentioned. Another is looking for a callback return parameter on the > client side. If the server doesn't return it, then the server didn't > support that extension and the client should break the flow at that > point. > > I want to ask the list though: what exactly do we mean by ignoring > parameters? Is it that a server library will ignore unknown parameters > coming in when doing its processing? That I agree with completely. Same > with parameters coming back to the client from the server. If you don't > know about it, don't try to do anything with it. The one case that I > don't think libraries can *ignore* extra parameters is when using a > client library to build a request to a server. A particular server > implementation may require extra parameters on the request in order to > function (such as MediaWiki's title parameter), and a client needs to be > able to pass such things through. These parameters can effectively be > thought of as part of the address of the server URL, can be ignored by > the OAuth part of the server process, but cannot be dropped by the > client building the request. So "ignore" in this case means "quietly > pass through" and not "drop". > > In most instances outside of the Big Web Companies, OAuth is going to be > the new kid being grafted onto an existing framework or application. As > such, it really needs to play nice. > > =C2=A0-- Justin > > > On Mon, 2010-06-28 at 20:59 -0400, Eran Hammer-Lahav wrote: >> There are 3 general ways to deal with this: >> >> >> >> 1. Break on unrecognized parameters =E2=80=93 this tends to make the use= of >> extensions hard, and at a minimum requires an error to include the bad >> parameter in a machine readable way (so a library can figure out an >> extension is not supported). >> >> >> >> 2. Ignore unrecognized parameters =E2=80=93 this is the usual way of dea= ling >> with extensible protocols. It has security implications when extension >> parameters must not be ignored. However, the workaround is simply to >> break something else (i.e. replace the client_id with something else >> that will cause the normal flow to break). >> >> >> >> 3. Same as #2 but include a directive which means =E2=80=98must not igno= re any >> parameter; return error if any parameter is unknown=E2=80=99. XRD used t= o >> include such a =E2=80=98must-support=E2=80=99 attribute for properties b= ut was dropped >> due to lack of use cases. >> >> >> >> I think #2 offers a good enough balance here, but am happy to discuss >> #3 if people have actual use cases where ignoring an extension will >> cause security issues. Note that with the expectation of error codes, >> my upcoming extensibility proposal does not allow adding any new >> parameter values (only new parameters). >> >> >> >> EHL >> >> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Yaron Goland >> Sent: Monday, June 28, 2010 3:02 PM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] How do we deal with unrecognized elements in >> requests and responses? >> >> >> >> >> In a private thread with Eran an issue came up regarding how to handle >> unrecognized arguments in OAuth requests and responses. >> >> >> >> For example, if a token endpoint receives an access token request that >> contains both a client_id and a client_foo_bar argument, what should >> it do? Should it reject the request since it doesn=E2=80=99t recognize >> client_foo_bar? Should it ignore client_foo_bar and just process the >> request based on client_id? >> >> >> >> Similarly imagine that a response to an access token request contains >> a JSON member with some unrecognized name. What=E2=80=99s the right beha= vior? >> Ignore the unrecognized value? Or treat the response as badly >> formatted and fail out? >> >> >> >> We need to define in the spec how to deal with unrecognized >> extensions. Typically the rule is =E2=80=98ignore what you don=E2=80=99t= recognize=E2=80=99 >> but there is a countervailing rule which applies here which is >> =E2=80=9Csecurity is different=E2=80=9D. Typically ignoring unrecognized= elements in a >> security context can lead to security holes. >> >> >> >> Just looking at the history of OAuth I suspect we need to go with the >> ignore rule and then explore ad nauseam in the security considerations >> section all the ways that the ignore rule can go wrong if extensions >> aren=E2=80=99t handled carefully. >> >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thoughts? >> >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks, >> >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Yaron >> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 http://agree2.com - Reach Agreement! http://stakeventures.com - My blog about startups and agile banking From jhart@photobucket.com Thu Jul 1 07:09:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997633A6452 for ; Thu, 1 Jul 2010 07:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.742 X-Spam-Level: X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMmFv0P2EATM for ; Thu, 1 Jul 2010 07:09:39 -0700 (PDT) Received: from EXHUB003-4.exch003intermedia.net (exhub003-4.exch003intermedia.net [207.5.74.111]) by core3.amsl.com (Postfix) with ESMTP id 689103A68B2 for ; Thu, 1 Jul 2010 07:09:39 -0700 (PDT) Received: from EXVMBX003-4.exch003intermedia.net ([207.5.74.44]) by EXHUB003-4.exch003intermedia.net ([207.5.74.111]) with mapi; Thu, 1 Jul 2010 07:09:51 -0700 From: Justin Hart To: Pelle Braendgaard Date: Thu, 1 Jul 2010 07:09:48 -0700 Thread-Topic: [OAUTH-WG] Underscore, dash, green, blue Thread-Index: AcsZJxGoS8lpmFf0RLWq5U1Xoknbjg== Message-ID: <0E0C7232-0C39-4D2A-9918-FCD68F27E789@photobucket.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7@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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Underscore, dash, green, blue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 14:09:40 -0000 +1 for underscores except header keys. ---- -- Justin Hart -- jhart@photobucket.com On Jul 1, 2010, at 7:39 AM, Pelle Braendgaard wrote: > I already implemented 09 but it was a (very tiny) bit of a hassle to > have to convert underscores. >=20 > So I also agree with 3 except headers >=20 > On Thu, Jul 1, 2010 at 2:41 AM, Lukas Rosenstock = wrote: >> 3 except headers. >>=20 >> 2010/7/1 Eran Hammer-Lahav : >>> First, sorry about this. J >>>=20 >>>=20 >>>=20 >>> I do my best not to ask the group this kind of questions and just pick >>> something on my own, but I can=92t decide so I=92ll run a quick vote (y= es, a >>> VOTE =96 I can=92t imagine seeking a consensus call on this). >>>=20 >>>=20 >>>=20 >>> -09 uses underscores for parameter names (except for in the headers) an= d >>> dashes for parameter values. This seems like an odd selection. Before, = it >>> used dashes for header parameter names, and underscore everywhere else.= Not >>> great either. >>>=20 >>>=20 >>>=20 >>> So=85 >>>=20 >>>=20 >>>=20 >>> The changes my OCD can live with: >>>=20 >>>=20 >>>=20 >>> 1. Use dashes throughout >>>=20 >>> 2. Use underscores for all parameter names (headers included), dashes f= or >>> all values >>>=20 >>> 3. Use underscores throughout >>>=20 >>>=20 >>>=20 >>> I want to get this done with in a day because people are writing code f= or >>> -09 and I=92d like to stop making changes beyond editorial. I just thi= nk that >>> having different styles between the endpoint parameters and header >>> parameters is broken. >>>=20 >>>=20 >>>=20 >>> EHL >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>=20 >>=20 >>=20 >> -- >> http://lukasrosenstock.net/ >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 >=20 > --=20 > http://agree2.com - Reach Agreement! > http://stakeventures.com - My blog about startups and agile banking > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Jul 1 09:23:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0803A684A for ; Thu, 1 Jul 2010 09:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxpGIq2YRoyK for ; Thu, 1 Jul 2010 09:23:11 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 63FF83A659A for ; Thu, 1 Jul 2010 09:23:11 -0700 (PDT) Received: (qmail 14709 invoked from network); 1 Jul 2010 16:23:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 16:23:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 1 Jul 2010 09:23:18 -0700 From: Eran Hammer-Lahav To: Justin Hart , Pelle Braendgaard Date: Thu, 1 Jul 2010 09:23:30 -0700 Thread-Topic: [OAUTH-WG] Underscore, dash, green, blue Thread-Index: AcsZJxGoS8lpmFf0RLWq5U1XoknbjgAEhwTQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0E0C7232-0C39-4D2A-9918-FCD68F27E789@photobucket.com> In-Reply-To: <0E0C7232-0C39-4D2A-9918-FCD68F27E789@photobucket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Underscore, dash, green, blue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 16:23:12 -0000 That's wasn't an option for a reason. Beside offending my esthetic sensibil= ity :-) having the same parameter use a different name between the header a= nd endpoint makes registration of extension parameters much harder. For exa= mple, if we used this scheme, the 'error-uri' parameter would require two r= egistration requests, one for 'error-uri' and another for 'error_uri'. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Justin Hart > Sent: Thursday, July 01, 2010 7:10 AM > To: Pelle Braendgaard > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Underscore, dash, green, blue >=20 > +1 for underscores except header keys. > ---- > -- Justin Hart > -- jhart@photobucket.com >=20 >=20 >=20 >=20 >=20 >=20 > On Jul 1, 2010, at 7:39 AM, Pelle Braendgaard wrote: >=20 > > I already implemented 09 but it was a (very tiny) bit of a hassle to > > have to convert underscores. > > > > So I also agree with 3 except headers > > > > On Thu, Jul 1, 2010 at 2:41 AM, Lukas Rosenstock > wrote: > >> 3 except headers. > >> > >> 2010/7/1 Eran Hammer-Lahav : > >>> First, sorry about this. J > >>> > >>> > >>> > >>> I do my best not to ask the group this kind of questions and just > >>> pick something on my own, but I can't decide so I'll run a quick > >>> vote (yes, a VOTE - I can't imagine seeking a consensus call on this)= . > >>> > >>> > >>> > >>> -09 uses underscores for parameter names (except for in the headers) > >>> and dashes for parameter values. This seems like an odd selection. > >>> Before, it used dashes for header parameter names, and underscore > >>> everywhere else. Not great either. > >>> > >>> > >>> > >>> So... > >>> > >>> > >>> > >>> The changes my OCD can live with: > >>> > >>> > >>> > >>> 1. Use dashes throughout > >>> > >>> 2. Use underscores for all parameter names (headers included), > >>> dashes for all values > >>> > >>> 3. Use underscores throughout > >>> > >>> > >>> > >>> I want to get this done with in a day because people are writing > >>> code for > >>> -09 and I'd like to stop making changes beyond editorial. I just > >>> think that having different styles between the endpoint parameters > >>> and header parameters is broken. > >>> > >>> > >>> > >>> EHL > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >> > >> > >> > >> -- > >> http://lukasrosenstock.net/ > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > > > > -- > > http://agree2.com - Reach Agreement! > > http://stakeventures.com - My blog about startups and agile banking > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Jul 1 09:35: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 C6C7E3A6895 for ; Thu, 1 Jul 2010 09:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, J_CHICKENPOX_55=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 UOsaC2QpNwLv for ; Thu, 1 Jul 2010 09:35:20 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 715FF3A68DF for ; Thu, 1 Jul 2010 09:35:18 -0700 (PDT) Received: (qmail 31090 invoked from network); 1 Jul 2010 16:35:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 16:35:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 1 Jul 2010 09:35:20 -0700 From: Eran Hammer-Lahav To: Rob Richards , "OAuth WG (oauth@ietf.org)" Date: Thu, 1 Jul 2010 09:35:32 -0700 Thread-Topic: Versioning Thread-Index: AcsZB9t1JjxcrbXrQsqobIZKUEzEKQAMg3aA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2C6D4A.5010401@cdatazone.org> In-Reply-To: <4C2C6D4A.5010401@cdatazone.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] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 16:35:23 -0000 Hi Rob, > -----Original Message----- > From: Rob Richards [mailto:rrichards@cdatazone.org] > Sent: Thursday, July 01, 2010 3:26 AM > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > Subject: Versioning >=20 > Versioning is still something that needs to be addressed before being bei= ng > able to consider the draft core complete. Versioning rarely works because when you define it, you have no idea what t= he requirements will be for the next version. A good example is the OAuth 1= .0 version parameter. When we worked to revised 1.0 into 1.0a, we had a lon= g debate on changing the protocol version number. We had a hard time agreei= ng on what the version meant and what was it a version *of*: the signature = method or the token flow. If this protocol will require significant changes in the future that go bey= ond its extensibility support, such a new version will need to use differen= t endpoints (token or end-user authorization) and/or different HTTP authent= ication scheme. If you want to discuss versioning, you must provide your requirements for s= uch a feature, and clearly show how they are not served by the current exte= nsibility proposal. > On this I'm still of the opinion that at the very minimum you will need t= o > require an oauth_version parameter for the resource endpoints, if not als= o > for the others as well. I think the difficulty of differentiating a 1.0 from a 2.0 protected resour= ce request is exaggerated. As said before, you can tell the difference base= d on the presence of other parameter (oauth_signature_method), or by examin= ing the provided token (assuming you issue different tokens for each versio= n). The argument that a 2.0 request can also be a malformed 1.0 request is = silly. I have yet to hear about that level of incompetence for a 1.0 develo= per (and I've heard about a lot) - omitting every other required parameter. At most, I'm open to renaming the oauth_token parameter to something else (= oauth_access_token, oauth.token, oauth-token, etc.) but I think even that i= s not needed. EHL From eran@hueniverse.com Thu Jul 1 09:37: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 297633A684A for ; Thu, 1 Jul 2010 09:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 D1IcMQigoGbI for ; Thu, 1 Jul 2010 09:37:30 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E2EDD3A659A for ; Thu, 1 Jul 2010 09:37:29 -0700 (PDT) Received: (qmail 6276 invoked from network); 1 Jul 2010 16:37:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 16:37:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 1 Jul 2010 09:37:37 -0700 From: Eran Hammer-Lahav To: Justin Richer Date: Thu, 1 Jul 2010 09:37:49 -0700 Thread-Topic: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? Thread-Index: AcsZHb51xCcmHhoHS/umV08hWVAYyAAHdm2A Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1277989381.28743.160.camel@localhost.localdomain> In-Reply-To: <1277989381.28743.160.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 16:37:31 -0000 SWdub3JlIGFzIGluLCBwcmV0ZW5kIGl0IHdhc24ndCBzZW50IChmcm9tIGVpdGhlciB0aGUgY2xp ZW50IG9yIHNlcnZlcikuDQoNCkVITA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IEp1c3RpbiBSaWNoZXIgW21haWx0bzpqcmljaGVyQG1pdHJlLm9yZ10NCj4gU2VudDog VGh1cnNkYXksIEp1bHkgMDEsIDIwMTAgNjowMyBBTQ0KPiBUbzogRXJhbiBIYW1tZXItTGFoYXYN Cj4gQ2M6IFlhcm9uIEdvbGFuZDsgT0F1dGggV0cNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10g SG93IGRvIHdlIGRlYWwgd2l0aCB1bnJlY29nbml6ZWQgZWxlbWVudHMgaW4NCj4gcmVxdWVzdHMg YW5kIHJlc3BvbnNlcz8NCj4gDQo+ICMyIGlzIHRoZSBiZXN0IHJvdXRlIGZvcndhcmQuIElmIGEg cGFydGljdWxhciBleHRlbnNpb24gcmVxdWlyZXMgaXRzIHBhcmFtZXRlcnMNCj4gdG8gYmUgcHJl c2VudCBhbmQgaGFuZGxlZCwgdGhlbiBpdCBoYXMgYSBmZXcgZGlmZmVyZW50IG9wdGlvbnMuIE9u ZSBpcw0KPiBicmVha2luZyBhdCB0aGUgc2VydmVyIHNpZGUsIGVpdGhlciB3aXRoIGFuIGV4cGxp Y2l0IGVycm9yIG9yIHRocm93aW5nIGF3YXkNCj4gc29tZSBvdGhlciByZXF1aXJlZCBiaXQsIHdo aWNoIGhhcyBiZWVuIG1lbnRpb25lZC4gQW5vdGhlciBpcyBsb29raW5nIGZvciBhDQo+IGNhbGxi YWNrIHJldHVybiBwYXJhbWV0ZXIgb24gdGhlIGNsaWVudCBzaWRlLiBJZiB0aGUgc2VydmVyIGRv ZXNuJ3QgcmV0dXJuIGl0LA0KPiB0aGVuIHRoZSBzZXJ2ZXIgZGlkbid0IHN1cHBvcnQgdGhhdCBl eHRlbnNpb24gYW5kIHRoZSBjbGllbnQgc2hvdWxkIGJyZWFrIHRoZQ0KPiBmbG93IGF0IHRoYXQg cG9pbnQuDQo+IA0KPiBJIHdhbnQgdG8gYXNrIHRoZSBsaXN0IHRob3VnaDogd2hhdCBleGFjdGx5 IGRvIHdlIG1lYW4gYnkgaWdub3JpbmcNCj4gcGFyYW1ldGVycz8gSXMgaXQgdGhhdCBhIHNlcnZl ciBsaWJyYXJ5IHdpbGwgaWdub3JlIHVua25vd24gcGFyYW1ldGVycyBjb21pbmcNCj4gaW4gd2hl biBkb2luZyBpdHMgcHJvY2Vzc2luZz8gVGhhdCBJIGFncmVlIHdpdGggY29tcGxldGVseS4gU2Ft ZSB3aXRoDQo+IHBhcmFtZXRlcnMgY29taW5nIGJhY2sgdG8gdGhlIGNsaWVudCBmcm9tIHRoZSBz ZXJ2ZXIuIElmIHlvdSBkb24ndCBrbm93DQo+IGFib3V0IGl0LCBkb24ndCB0cnkgdG8gZG8gYW55 dGhpbmcgd2l0aCBpdC4gVGhlIG9uZSBjYXNlIHRoYXQgSSBkb24ndCB0aGluaw0KPiBsaWJyYXJp ZXMgY2FuICppZ25vcmUqIGV4dHJhIHBhcmFtZXRlcnMgaXMgd2hlbiB1c2luZyBhIGNsaWVudCBs aWJyYXJ5IHRvIGJ1aWxkIGENCj4gcmVxdWVzdCB0byBhIHNlcnZlci4gQSBwYXJ0aWN1bGFyIHNl cnZlciBpbXBsZW1lbnRhdGlvbiBtYXkgcmVxdWlyZSBleHRyYQ0KPiBwYXJhbWV0ZXJzIG9uIHRo ZSByZXF1ZXN0IGluIG9yZGVyIHRvIGZ1bmN0aW9uIChzdWNoIGFzIE1lZGlhV2lraSdzIHRpdGxl DQo+IHBhcmFtZXRlciksIGFuZCBhIGNsaWVudCBuZWVkcyB0byBiZSBhYmxlIHRvIHBhc3Mgc3Vj aCB0aGluZ3MgdGhyb3VnaC4gVGhlc2UNCj4gcGFyYW1ldGVycyBjYW4gZWZmZWN0aXZlbHkgYmUg dGhvdWdodCBvZiBhcyBwYXJ0IG9mIHRoZSBhZGRyZXNzIG9mIHRoZSBzZXJ2ZXINCj4gVVJMLCBj YW4gYmUgaWdub3JlZCBieSB0aGUgT0F1dGggcGFydCBvZiB0aGUgc2VydmVyIHByb2Nlc3MsIGJ1 dCBjYW5ub3QgYmUNCj4gZHJvcHBlZCBieSB0aGUgY2xpZW50IGJ1aWxkaW5nIHRoZSByZXF1ZXN0 LiBTbyAiaWdub3JlIiBpbiB0aGlzIGNhc2UgbWVhbnMNCj4gInF1aWV0bHkgcGFzcyB0aHJvdWdo IiBhbmQgbm90ICJkcm9wIi4NCj4gDQo+IEluIG1vc3QgaW5zdGFuY2VzIG91dHNpZGUgb2YgdGhl IEJpZyBXZWIgQ29tcGFuaWVzLCBPQXV0aCBpcyBnb2luZyB0byBiZQ0KPiB0aGUgbmV3IGtpZCBi ZWluZyBncmFmdGVkIG9udG8gYW4gZXhpc3RpbmcgZnJhbWV3b3JrIG9yIGFwcGxpY2F0aW9uLiBB cyBzdWNoLA0KPiBpdCByZWFsbHkgbmVlZHMgdG8gcGxheSBuaWNlLg0KPiANCj4gIC0tIEp1c3Rp bg0KPiANCj4gDQo+IE9uIE1vbiwgMjAxMC0wNi0yOCBhdCAyMDo1OSAtMDQwMCwgRXJhbiBIYW1t ZXItTGFoYXYgd3JvdGU6DQo+ID4gVGhlcmUgYXJlIDMgZ2VuZXJhbCB3YXlzIHRvIGRlYWwgd2l0 aCB0aGlzOg0KPiA+DQo+ID4NCj4gPg0KPiA+IDEuIEJyZWFrIG9uIHVucmVjb2duaXplZCBwYXJh bWV0ZXJzIOKAkyB0aGlzIHRlbmRzIHRvIG1ha2UgdGhlIHVzZSBvZg0KPiA+IGV4dGVuc2lvbnMg aGFyZCwgYW5kIGF0IGEgbWluaW11bSByZXF1aXJlcyBhbiBlcnJvciB0byBpbmNsdWRlIHRoZSBi YWQNCj4gPiBwYXJhbWV0ZXIgaW4gYSBtYWNoaW5lIHJlYWRhYmxlIHdheSAoc28gYSBsaWJyYXJ5 IGNhbiBmaWd1cmUgb3V0IGFuDQo+ID4gZXh0ZW5zaW9uIGlzIG5vdCBzdXBwb3J0ZWQpLg0KPiA+ DQo+ID4NCj4gPg0KPiA+IDIuIElnbm9yZSB1bnJlY29nbml6ZWQgcGFyYW1ldGVycyDigJMgdGhp cyBpcyB0aGUgdXN1YWwgd2F5IG9mIGRlYWxpbmcNCj4gPiB3aXRoIGV4dGVuc2libGUgcHJvdG9j b2xzLiBJdCBoYXMgc2VjdXJpdHkgaW1wbGljYXRpb25zIHdoZW4gZXh0ZW5zaW9uDQo+ID4gcGFy YW1ldGVycyBtdXN0IG5vdCBiZSBpZ25vcmVkLiBIb3dldmVyLCB0aGUgd29ya2Fyb3VuZCBpcyBz aW1wbHkgdG8NCj4gPiBicmVhayBzb21ldGhpbmcgZWxzZSAoaS5lLiByZXBsYWNlIHRoZSBjbGll bnRfaWQgd2l0aCBzb21ldGhpbmcgZWxzZQ0KPiA+IHRoYXQgd2lsbCBjYXVzZSB0aGUgbm9ybWFs IGZsb3cgdG8gYnJlYWspLg0KPiA+DQo+ID4NCj4gPg0KPiA+IDMuIFNhbWUgYXMgIzIgYnV0IGlu Y2x1ZGUgYSBkaXJlY3RpdmUgd2hpY2ggbWVhbnMg4oCYbXVzdCBub3QgaWdub3JlIGFueQ0KPiA+ IHBhcmFtZXRlcjsgcmV0dXJuIGVycm9yIGlmIGFueSBwYXJhbWV0ZXIgaXMgdW5rbm93buKAmS4g WFJEIHVzZWQgdG8NCj4gPiBpbmNsdWRlIHN1Y2ggYSDigJhtdXN0LXN1cHBvcnTigJkgYXR0cmli dXRlIGZvciBwcm9wZXJ0aWVzIGJ1dCB3YXMgZHJvcHBlZA0KPiA+IGR1ZSB0byBsYWNrIG9mIHVz ZSBjYXNlcy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBJIHRoaW5rICMyIG9mZmVycyBhIGdvb2QgZW5v dWdoIGJhbGFuY2UgaGVyZSwgYnV0IGFtIGhhcHB5IHRvIGRpc2N1c3MNCj4gPiAjMyBpZiBwZW9w bGUgaGF2ZSBhY3R1YWwgdXNlIGNhc2VzIHdoZXJlIGlnbm9yaW5nIGFuIGV4dGVuc2lvbiB3aWxs DQo+ID4gY2F1c2Ugc2VjdXJpdHkgaXNzdWVzLiBOb3RlIHRoYXQgd2l0aCB0aGUgZXhwZWN0YXRp b24gb2YgZXJyb3IgY29kZXMsDQo+ID4gbXkgdXBjb21pbmcgZXh0ZW5zaWJpbGl0eSBwcm9wb3Nh bCBkb2VzIG5vdCBhbGxvdyBhZGRpbmcgYW55IG5ldw0KPiA+IHBhcmFtZXRlciB2YWx1ZXMgKG9u bHkgbmV3IHBhcmFtZXRlcnMpLg0KPiA+DQo+ID4NCj4gPg0KPiA+IEVITA0KPiA+DQo+ID4NCj4g Pg0KPiA+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiBPZiBZYXJvbiBHb2xhbmQNCj4gPiBTZW50OiBNb25k YXksIEp1bmUgMjgsIDIwMTAgMzowMiBQTQ0KPiA+IFRvOiBvYXV0aEBpZXRmLm9yZw0KPiA+IFN1 YmplY3Q6IFtPQVVUSC1XR10gSG93IGRvIHdlIGRlYWwgd2l0aCB1bnJlY29nbml6ZWQgZWxlbWVu dHMgaW4NCj4gPiByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzPw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ ID4gSW4gYSBwcml2YXRlIHRocmVhZCB3aXRoIEVyYW4gYW4gaXNzdWUgY2FtZSB1cCByZWdhcmRp bmcgaG93IHRvIGhhbmRsZQ0KPiA+IHVucmVjb2duaXplZCBhcmd1bWVudHMgaW4gT0F1dGggcmVx dWVzdHMgYW5kIHJlc3BvbnNlcy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBGb3IgZXhhbXBsZSwgaWYg YSB0b2tlbiBlbmRwb2ludCByZWNlaXZlcyBhbiBhY2Nlc3MgdG9rZW4gcmVxdWVzdCB0aGF0DQo+ ID4gY29udGFpbnMgYm90aCBhIGNsaWVudF9pZCBhbmQgYSBjbGllbnRfZm9vX2JhciBhcmd1bWVu dCwgd2hhdCBzaG91bGQNCj4gPiBpdCBkbz8gU2hvdWxkIGl0IHJlamVjdCB0aGUgcmVxdWVzdCBz aW5jZSBpdCBkb2VzbuKAmXQgcmVjb2duaXplDQo+ID4gY2xpZW50X2Zvb19iYXI/IFNob3VsZCBp dCBpZ25vcmUgY2xpZW50X2Zvb19iYXIgYW5kIGp1c3QgcHJvY2VzcyB0aGUNCj4gPiByZXF1ZXN0 IGJhc2VkIG9uIGNsaWVudF9pZD8NCj4gPg0KPiA+DQo+ID4NCj4gPiBTaW1pbGFybHkgaW1hZ2lu ZSB0aGF0IGEgcmVzcG9uc2UgdG8gYW4gYWNjZXNzIHRva2VuIHJlcXVlc3QgY29udGFpbnMNCj4g PiBhIEpTT04gbWVtYmVyIHdpdGggc29tZSB1bnJlY29nbml6ZWQgbmFtZS4gV2hhdOKAmXMgdGhl IHJpZ2h0IGJlaGF2aW9yPw0KPiA+IElnbm9yZSB0aGUgdW5yZWNvZ25pemVkIHZhbHVlPyBPciB0 cmVhdCB0aGUgcmVzcG9uc2UgYXMgYmFkbHkNCj4gPiBmb3JtYXR0ZWQgYW5kIGZhaWwgb3V0Pw0K PiA+DQo+ID4NCj4gPg0KPiA+IFdlIG5lZWQgdG8gZGVmaW5lIGluIHRoZSBzcGVjIGhvdyB0byBk ZWFsIHdpdGggdW5yZWNvZ25pemVkDQo+ID4gZXh0ZW5zaW9ucy4gVHlwaWNhbGx5IHRoZSBydWxl IGlzIOKAmGlnbm9yZSB3aGF0IHlvdSBkb27igJl0IHJlY29nbml6ZeKAmQ0KPiA+IGJ1dCB0aGVy ZSBpcyBhIGNvdW50ZXJ2YWlsaW5nIHJ1bGUgd2hpY2ggYXBwbGllcyBoZXJlIHdoaWNoIGlzDQo+ ID4g4oCcc2VjdXJpdHkgaXMgZGlmZmVyZW504oCdLiBUeXBpY2FsbHkgaWdub3JpbmcgdW5yZWNv Z25pemVkIGVsZW1lbnRzIGluIGENCj4gPiBzZWN1cml0eSBjb250ZXh0IGNhbiBsZWFkIHRvIHNl Y3VyaXR5IGhvbGVzLg0KPiA+DQo+ID4NCj4gPg0KPiA+IEp1c3QgbG9va2luZyBhdCB0aGUgaGlz dG9yeSBvZiBPQXV0aCBJIHN1c3BlY3Qgd2UgbmVlZCB0byBnbyB3aXRoIHRoZQ0KPiA+IGlnbm9y ZSBydWxlIGFuZCB0aGVuIGV4cGxvcmUgYWQgbmF1c2VhbSBpbiB0aGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMNCj4gPiBzZWN0aW9uIGFsbCB0aGUgd2F5cyB0aGF0IHRoZSBpZ25vcmUgcnVsZSBj YW4gZ28gd3JvbmcgaWYgZXh0ZW5zaW9ucw0KPiA+IGFyZW7igJl0IGhhbmRsZWQgY2FyZWZ1bGx5 Lg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICBUaG91Z2h0cz8NCj4gPg0KPiA+ DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcywNCj4gPg0K PiA+DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBZYXJvbg0KPiA+DQo+ID4NCj4gDQoNCg== From mscurtescu@google.com Thu Jul 1 10:37: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 65F183A6900 for ; Thu, 1 Jul 2010 10:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.423 X-Spam-Level: X-Spam-Status: No, score=-105.423 tagged_above=-999 required=5 tests=[AWL=0.554, 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 uLxvSu8k466C for ; Thu, 1 Jul 2010 10:37:17 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6D8683A685A for ; Thu, 1 Jul 2010 10:37:17 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o61HbSdR012654 for ; Thu, 1 Jul 2010 10:37:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278005848; bh=0IwGN68zRjvU2fLEFMlvn2aw4iM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=H7UcCpmU7Ox0sDWVJ7odVJUdpfeJ55yFCg+QuXD1PeppICrE9e9Nh+kY46HuUzUP4 pmzOzIl01oKZ19wzYpyqw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=ivYFBT/nB1We+JbFsjY/8/ijGMPbt4jRHDk3QMLd625MSgP0wi6P7H9DHtDOa7VW2 Yp9OpLMHUEIE1teV3fdog== Received: from gyg8 (gyg8.prod.google.com [10.243.50.136]) by wpaz24.hot.corp.google.com with ESMTP id o61HadUE016086 for ; Thu, 1 Jul 2010 10:37:27 -0700 Received: by gyg8 with SMTP id 8so1209377gyg.30 for ; Thu, 01 Jul 2010 10:37:27 -0700 (PDT) Received: by 10.100.163.13 with SMTP id l13mr13290855ane.267.1278005847202; Thu, 01 Jul 2010 10:37:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Thu, 1 Jul 2010 10:37:07 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 1 Jul 2010 10:37:07 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 17:37:18 -0000 On Thu, Jul 1, 2010 at 9:35 AM, Eran Hammer-Lahav wro= te: > Hi Rob, > >> -----Original Message----- >> From: Rob Richards [mailto:rrichards@cdatazone.org] >> Sent: Thursday, July 01, 2010 3:26 AM >> To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav >> Subject: Versioning >> >> Versioning is still something that needs to be addressed before being be= ing >> able to consider the draft core complete. > > Versioning rarely works because when you define it, you have no idea what= the requirements will be for the next version. A good example is the OAuth= 1.0 version parameter. When we worked to revised 1.0 into 1.0a, we had a l= ong debate on changing the protocol version number. We had a hard time agre= eing on what the version meant and what was it a version *of*: the signatur= e method or the token flow. > > If this protocol will require significant changes in the future that go b= eyond its extensibility support, such a new version will need to use differ= ent endpoints (token or end-user authorization) and/or different HTTP authe= ntication scheme. I don't think the authz server endpoints are an issue, but the protected resources. The auth scheme is very generic, "Token". So either the scheme should be more specific, like "OAuth2", or a version should be added as a parameter. Maybe a token type as Dick suggested. Marius From wmills@yahoo-inc.com Thu Jul 1 10:50: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 8181E3A67F9 for ; Thu, 1 Jul 2010 10:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.837 X-Spam-Level: X-Spam-Status: No, score=-16.837 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_55=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNYbhnffFb+1 for ; Thu, 1 Jul 2010 10:50:35 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 7A0513A6845 for ; Thu, 1 Jul 2010 10:50:30 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o61HnZxd065886; Thu, 1 Jul 2010 10:49:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:x-originalarrivaltime; b=FFtM+yJYB/0Stx0ByuJgZhr9nGgQufJTdLq2wBKQDrqu647x8f7I9ZMMwr3MZmcA Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 10:49:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jul 2010 10:49:18 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZB9t1JjxcrbXrQsqobIZKUEzEKQAMg3aAAAKO0XA= References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" To: "Eran Hammer-Lahav" , "Rob Richards" , X-OriginalArrivalTime: 01 Jul 2010 17:49:34.0924 (UTC) FILETIME=[C46F08C0:01CB1945] Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 17:50:37 -0000 My feeling on this is that versioning explicitly in the protocol adds clarity and some small level of compatibility. Different auth and token endpoints are easy, what's harder is supporting multiple protocols on the same protected resource. It's on the protected resource I'd like to see some clearer protocol version spec so I'm not having to figure out from the variable names which protocol it is. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Eran Hammer-Lahav > Sent: Thursday, July 01, 2010 9:36 AM > To: Rob Richards; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Versioning >=20 > Hi Rob, >=20 > > -----Original Message----- > > From: Rob Richards [mailto:rrichards@cdatazone.org] > > Sent: Thursday, July 01, 2010 3:26 AM > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > > Subject: Versioning > >=20 > > Versioning is still something that needs to be addressed=20 > before being=20 > > being able to consider the draft core complete. >=20 > Versioning rarely works because when you define it, you have=20 > no idea what the requirements will be for the next version. A=20 > good example is the OAuth 1.0 version parameter. When we=20 > worked to revised 1.0 into 1.0a, we had a long debate on=20 > changing the protocol version number. We had a hard time=20 > agreeing on what the version meant and what was it a version=20 > *of*: the signature method or the token flow. >=20 > If this protocol will require significant changes in the=20 > future that go beyond its extensibility support, such a new=20 > version will need to use different endpoints (token or=20 > end-user authorization) and/or different HTTP authentication scheme. >=20 > If you want to discuss versioning, you must provide your=20 > requirements for such a feature, and clearly show how they=20 > are not served by the current extensibility proposal. >=20 > > On this I'm still of the opinion that at the very minimum you will=20 > > need to require an oauth_version parameter for the resource=20 > endpoints,=20 > > if not also for the others as well. >=20 > I think the difficulty of differentiating a 1.0 from a 2.0=20 > protected resource request is exaggerated. As said before,=20 > you can tell the difference based on the presence of other=20 > parameter (oauth_signature_method), or by examining the=20 > provided token (assuming you issue different tokens for each=20 > version). The argument that a 2.0 request can also be a=20 > malformed 1.0 request is silly. I have yet to hear about that=20 > level of incompetence for a 1.0 developer (and I've heard=20 > about a lot) - omitting every other required parameter. >=20 > At most, I'm open to renaming the oauth_token parameter to=20 > something else (oauth_access_token, oauth.token, oauth-token,=20 > etc.) but I think even that is not needed. >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From wmills@yahoo-inc.com Thu Jul 1 10:52:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4171D3A681F for ; Thu, 1 Jul 2010 10:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.121 X-Spam-Level: X-Spam-Status: No, score=-17.121 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wqvxi2o3ifC8 for ; Thu, 1 Jul 2010 10:52:26 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 6FB013A6832 for ; Thu, 1 Jul 2010 10:52:26 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o61HpZ9H066753; Thu, 1 Jul 2010 10:51:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:x-originalarrivaltime; b=OGrqx+JLsBwQtXRwoxcDCyog9MSsxbEIlYmVIsumnyS5arwuencR4Qm402BGN2/q Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 10:51:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jul 2010 10:51:26 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B693C@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZRCGgtvy+ClLmSyOIQNtBOPo1CQAAdIJA References: <4C2C6D4A.5010401@cdatazone.org><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" To: "Marius Scurtescu" , "Eran Hammer-Lahav" X-OriginalArrivalTime: 01 Jul 2010 17:51:36.0112 (UTC) FILETIME=[0CAADB00:01CB1946] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 17:52:27 -0000 +1 > I don't think the authz server endpoints are an issue, but=20 > the protected resources. The auth scheme is very generic,=20 > "Token". So either the scheme should be more specific, like=20 > "OAuth2", or a version should be added as a parameter. Maybe=20 > a token type as Dick suggested. =20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Marius Scurtescu > Sent: Thursday, July 01, 2010 10:37 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Versioning >=20 > On Thu, Jul 1, 2010 at 9:35 AM, Eran Hammer-Lahav=20 > wrote: > > Hi Rob, > > > >> -----Original Message----- > >> From: Rob Richards [mailto:rrichards@cdatazone.org] > >> Sent: Thursday, July 01, 2010 3:26 AM > >> To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > >> Subject: Versioning > >> > >> Versioning is still something that needs to be addressed=20 > before being=20 > >> being able to consider the draft core complete. > > > > Versioning rarely works because when you define it, you=20 > have no idea what the requirements will be for the next=20 > version. A good example is the OAuth 1.0 version parameter.=20 > When we worked to revised 1.0 into 1.0a, we had a long debate=20 > on changing the protocol version number. We had a hard time=20 > agreeing on what the version meant and what was it a version=20 > *of*: the signature method or the token flow. > > > > If this protocol will require significant changes in the=20 > future that go beyond its extensibility support, such a new=20 > version will need to use different endpoints (token or=20 > end-user authorization) and/or different HTTP authentication scheme. >=20 > I don't think the authz server endpoints are an issue, but=20 > the protected resources. The auth scheme is very generic,=20 > "Token". So either the scheme should be more specific, like=20 > "OAuth2", or a version should be added as a parameter. Maybe=20 > a token type as Dick suggested. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Thu Jul 1 10:56:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CFC33A6845 for ; Thu, 1 Jul 2010 10:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357, 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 rjosUNgCLMCR for ; Thu, 1 Jul 2010 10:56:31 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 774983A67F9 for ; Thu, 1 Jul 2010 10:56:31 -0700 (PDT) Received: (qmail 2443 invoked from network); 1 Jul 2010 17:56:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 17:56:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 1 Jul 2010 10:56:40 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Thu, 1 Jul 2010 10:56:52 -0700 Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZRBXLAwYHvcG9RsG5JGgIVXMs4QAAQCRA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C450@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 17:56:32 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Thursday, July 01, 2010 10:37 AM > To: Eran Hammer-Lahav > Cc: Rob Richards; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Versioning >=20 > On Thu, Jul 1, 2010 at 9:35 AM, Eran Hammer-Lahav > wrote: > > Hi Rob, > > > >> -----Original Message----- > >> From: Rob Richards [mailto:rrichards@cdatazone.org] > >> Sent: Thursday, July 01, 2010 3:26 AM > >> To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > >> Subject: Versioning > >> > >> Versioning is still something that needs to be addressed before being > >> being able to consider the draft core complete. > > > > Versioning rarely works because when you define it, you have no idea > what the requirements will be for the next version. A good example is the > OAuth 1.0 version parameter. When we worked to revised 1.0 into 1.0a, we > had a long debate on changing the protocol version number. We had a hard > time agreeing on what the version meant and what was it a version *of*: t= he > signature method or the token flow. > > > > If this protocol will require significant changes in the future that go= beyond > its extensibility support, such a new version will need to use different > endpoints (token or end-user authorization) and/or different HTTP > authentication scheme. >=20 > I don't think the authz server endpoints are an issue, but the protected > resources. The auth scheme is very generic, "Token". So either the scheme > should be more specific, like "OAuth2", or a version should be added as a > parameter. Maybe a token type as Dick suggested. HTTP Basic has no version, and I believe Digest doesn't have a version eith= er (though it has been revised from 2069 to 2617). The Token scheme is gene= ric, but also wide open. The only required parameter is 'token' (which make= s sense for a Token scheme). I can't come up with a single requirement that= would require an explicit version parameter. Version discussions are almost always a waste of time because at the time t= hey are debated, no one knows what the requirement for such a feature will = be. Versioning usually makes sense in a follow-up revision where the protoc= ol needs a way to differentiate itself from the previous version. If anyone wants to propose a versioning of any parts of this protocol, they= must present specific objectives. The vague objective of "allow future ver= sions" isn't valid because it has failed for 1.0 (and many other protocols)= . Instead, I suggest people pay more attention to the extensibility and ens= ure that it offers enough support for future needs, without having the chan= ge the protocol. We tried adding version support in OAuth 1.0 and failed. The version parame= ter does not help in any real way, is incompletely, and poorly defined. The= quality of this new discussion is as low as that of the 1.0 attempt. Let's= learn from our mistakes. EHL From eran@hueniverse.com Thu Jul 1 10:59: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 EA7183A6845 for ; Thu, 1 Jul 2010 10:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, J_CHICKENPOX_55=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 Fvb3L3boKn2h for ; Thu, 1 Jul 2010 10:59:43 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id CCE043A67F9 for ; Thu, 1 Jul 2010 10:59:42 -0700 (PDT) Received: (qmail 19396 invoked from network); 1 Jul 2010 17:59:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 17:59:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 1 Jul 2010 10:59:45 -0700 From: Eran Hammer-Lahav To: William Mills , Rob Richards , "oauth@ietf.org" Date: Thu, 1 Jul 2010 10:59:58 -0700 Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZB9t1JjxcrbXrQsqobIZKUEzEKQAMg3aAAAKO0XAAAK/FEA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.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] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 17:59:44 -0000 Why is a version better than a new scheme name? Version is only helpful whe= n the protocol is practically the same with some minor changes, and if that= is the case, extensibility alone should be enough. EHL=20 > -----Original Message----- > From: William Mills [mailto:wmills@yahoo-inc.com] > Sent: Thursday, July 01, 2010 10:49 AM > To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > Subject: RE: [OAUTH-WG] Versioning >=20 > My feeling on this is that versioning explicitly in the protocol adds cla= rity and > some small level of compatibility. Different auth and token endpoints ar= e > easy, what's harder is supporting multiple protocols on the same protecte= d > resource. It's on the protected resource I'd like to see some clearer pr= otocol > version spec so I'm not having to figure out from the variable names whic= h > protocol it is. >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Thursday, July 01, 2010 9:36 AM > > To: Rob Richards; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Versioning > > > > Hi Rob, > > > > > -----Original Message----- > > > From: Rob Richards [mailto:rrichards@cdatazone.org] > > > Sent: Thursday, July 01, 2010 3:26 AM > > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > > > Subject: Versioning > > > > > > Versioning is still something that needs to be addressed > > before being > > > being able to consider the draft core complete. > > > > Versioning rarely works because when you define it, you have no idea > > what the requirements will be for the next version. A good example is > > the OAuth 1.0 version parameter. When we worked to revised 1.0 into > > 1.0a, we had a long debate on changing the protocol version number. We > > had a hard time agreeing on what the version meant and what was it a > > version > > *of*: the signature method or the token flow. > > > > If this protocol will require significant changes in the future that > > go beyond its extensibility support, such a new version will need to > > use different endpoints (token or end-user authorization) and/or > > different HTTP authentication scheme. > > > > If you want to discuss versioning, you must provide your requirements > > for such a feature, and clearly show how they are not served by the > > current extensibility proposal. > > > > > On this I'm still of the opinion that at the very minimum you will > > > need to require an oauth_version parameter for the resource > > endpoints, > > > if not also for the others as well. > > > > I think the difficulty of differentiating a 1.0 from a 2.0 protected > > resource request is exaggerated. As said before, you can tell the > > difference based on the presence of other parameter > > (oauth_signature_method), or by examining the provided token (assuming > > you issue different tokens for each version). The argument that a 2.0 > > request can also be a malformed 1.0 request is silly. I have yet to > > hear about that level of incompetence for a 1.0 developer (and I've > > heard about a lot) - omitting every other required parameter. > > > > At most, I'm open to renaming the oauth_token parameter to something > > else (oauth_access_token, oauth.token, oauth-token, > > etc.) but I think even that is not needed. > > > > EHL > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Thu Jul 1 11:01:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5EEA3A6845 for ; Thu, 1 Jul 2010 11:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 7NI4CpvTsvcy for ; Thu, 1 Jul 2010 11:01:24 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 2AC893A67F9 for ; Thu, 1 Jul 2010 11:01:24 -0700 (PDT) Received: (qmail 22177 invoked from network); 1 Jul 2010 18:01:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 18:01:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Jul 2010 11:01:24 -0700 From: Eran Hammer-Lahav To: Luke Shepard Date: Thu, 1 Jul 2010 11:01:35 -0700 Thread-Topic: [OAUTH-WG] Underscore, dash, green, blue Thread-Index: AcsZRuFVBhp/yeeQQx2kwhdt0kQMEAAAGPbA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C456@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0E0C7232-0C39-4D2A-9918-FCD68F27E789@photobucket.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0B379746-ED5A-4402-A8E6-1CF7D72ECE53@facebook.com> In-Reply-To: <0B379746-ED5A-4402-A8E6-1CF7D72ECE53@facebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Underscore, dash, green, blue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:01:27 -0000 > -----Original Message----- > From: Luke Shepard [mailto:lshepard@facebook.com] > Sent: Thursday, July 01, 2010 10:58 AM > To: Eran Hammer-Lahav > Cc: Justin Hart; Pelle Braendgaard; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Underscore, dash, green, blue >=20 > Don't really care, but to pick one - underscores throughout. >=20 > Why not headers? Historically, HTTP headers use dashes and not underscores, but there is not= hing to prevent us from using underscores throughout. EHL > On Jul 1, 2010, at 9:23 AM, Eran Hammer-Lahav wrote: >=20 > > That's wasn't an option for a reason. Beside offending my esthetic > sensibility :-) having the same parameter use a different name between th= e > header and endpoint makes registration of extension parameters much > harder. For example, if we used this scheme, the 'error-uri' parameter wo= uld > require two registration requests, one for 'error-uri' and another for > 'error_uri'. > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Justin Hart > >> Sent: Thursday, July 01, 2010 7:10 AM > >> To: Pelle Braendgaard > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue > >> > >> +1 for underscores except header keys. > >> ---- > >> -- Justin Hart > >> -- jhart@photobucket.com > >> > >> > >> > >> > >> > >> > >> On Jul 1, 2010, at 7:39 AM, Pelle Braendgaard wrote: > >> > >>> I already implemented 09 but it was a (very tiny) bit of a hassle to > >>> have to convert underscores. > >>> > >>> So I also agree with 3 except headers > >>> > >>> On Thu, Jul 1, 2010 at 2:41 AM, Lukas Rosenstock > >>> > >> wrote: > >>>> 3 except headers. > >>>> > >>>> 2010/7/1 Eran Hammer-Lahav : > >>>>> First, sorry about this. J > >>>>> > >>>>> > >>>>> > >>>>> I do my best not to ask the group this kind of questions and just > >>>>> pick something on my own, but I can't decide so I'll run a quick > >>>>> vote (yes, a VOTE - I can't imagine seeking a consensus call on thi= s). > >>>>> > >>>>> > >>>>> > >>>>> -09 uses underscores for parameter names (except for in the > >>>>> headers) and dashes for parameter values. This seems like an odd > selection. > >>>>> Before, it used dashes for header parameter names, and underscore > >>>>> everywhere else. Not great either. > >>>>> > >>>>> > >>>>> > >>>>> So... > >>>>> > >>>>> > >>>>> > >>>>> The changes my OCD can live with: > >>>>> > >>>>> > >>>>> > >>>>> 1. Use dashes throughout > >>>>> > >>>>> 2. Use underscores for all parameter names (headers included), > >>>>> dashes for all values > >>>>> > >>>>> 3. Use underscores throughout > >>>>> > >>>>> > >>>>> > >>>>> I want to get this done with in a day because people are writing > >>>>> code for > >>>>> -09 and I'd like to stop making changes beyond editorial. I just > >>>>> think that having different styles between the endpoint parameters > >>>>> and header parameters is broken. > >>>>> > >>>>> > >>>>> > >>>>> EHL > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> http://lukasrosenstock.net/ > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>> > >>> > >>> > >>> -- > >>> http://agree2.com - Reach Agreement! > >>> http://stakeventures.com - My blog about startups and agile banking > >>> _______________________________________________ > >>> 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 Jul 1 11:07: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 A97193A6850 for ; Thu, 1 Jul 2010 11:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.451 X-Spam-Level: X-Spam-Status: No, score=-105.451 tagged_above=-999 required=5 tests=[AWL=0.526, 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 fzccMNE4jq0m for ; Thu, 1 Jul 2010 11:07:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A6E9A3A67B6 for ; Thu, 1 Jul 2010 11:07:14 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o61I7PaJ003375 for ; Thu, 1 Jul 2010 11:07:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278007646; bh=gBe+BDKrvoCwgUH5tyFA/mlwlvk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=MhrgkWgnkTG09tkm7o88AvmANuMgjqi/npjokdrmMQ2ix6vxryZGA9gLj1dgcRbJV 46y1hEDCBpYtCuzmNl6gA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=hpNFUI5veQ84raKDx2eIqDTv/FCKBeGaz0SYocuVRNbHMK+F9/g/oZAXKL1ZZMn+S Y7x44aXsd3cY7I9HKomrA== Received: from gxk2 (gxk2.prod.google.com [10.202.11.2]) by kpbe18.cbf.corp.google.com with ESMTP id o61I7O6L024538 for ; Thu, 1 Jul 2010 11:07:25 -0700 Received: by gxk2 with SMTP id 2so148092gxk.26 for ; Thu, 01 Jul 2010 11:07:24 -0700 (PDT) Received: by 10.101.3.19 with SMTP id f19mr13158545ani.10.1278007644207; Thu, 01 Jul 2010 11:07:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Thu, 1 Jul 2010 11:07:04 -0700 (PDT) In-Reply-To: <1277989381.28743.160.camel@localhost.localdomain> References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1277989381.28743.160.camel@localhost.localdomain> From: Marius Scurtescu Date: Thu, 1 Jul 2010 11:07:04 -0700 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] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:07:15 -0000 On Thu, Jul 1, 2010 at 6:03 AM, Justin Richer wrote: > #2 is the best route forward. If a particular extension requires its > parameters to be present and handled, then it has a few different > options. One is breaking at the server side, either with an explicit > error or throwing away some other required bit, which has been > mentioned. Another is looking for a callback return parameter on the > client side. If the server doesn't return it, then the server didn't > support that extension and the client should break the flow at that > point. > > I want to ask the list though: what exactly do we mean by ignoring > parameters? Is it that a server library will ignore unknown parameters > coming in when doing its processing? That I agree with completely. Same > with parameters coming back to the client from the server. If you don't > know about it, don't try to do anything with it. The one case that I > don't think libraries can *ignore* extra parameters is when using a > client library to build a request to a server. A particular server > implementation may require extra parameters on the request in order to > function (such as MediaWiki's title parameter), and a client needs to be > able to pass such things through. These parameters can effectively be > thought of as part of the address of the server URL, can be ignored by > the OAuth part of the server process, but cannot be dropped by the > client building the request. So "ignore" in this case means "quietly > pass through" and not "drop". > > In most instances outside of the Big Web Companies, OAuth is going to be > the new kid being grafted onto an existing framework or application. As > such, it really needs to play nice. Just a side note, with extensions also being simple names added to the protocol chances of a collision with an existing framework are much higher. Using MediaWiki as an example, if an extension proposes to use 'title' as a parameter name it will be approved if it does not collied with other OAuth 2 parameter names (core or extensions), but frameworks will not be checked (that is impossible). Marius From eran@hueniverse.com Thu Jul 1 11:07:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DB73A6917 for ; Thu, 1 Jul 2010 11:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 oFy2Wn+tGeLY for ; Thu, 1 Jul 2010 11:07:20 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 4C2363A67B6 for ; Thu, 1 Jul 2010 11:07:20 -0700 (PDT) Received: (qmail 30299 invoked from network); 1 Jul 2010 18:07:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 18:07:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Jul 2010 11:07:26 -0700 From: Eran Hammer-Lahav To: Eran Hammer-Lahav , Marius Scurtescu Date: Thu, 1 Jul 2010 11:07:38 -0700 Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZRBXLAwYHvcG9RsG5JGgIVXMs4QAAQCRAAAC07KA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C460@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C450@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C450@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 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:07:22 -0000 I was told that my last paragraph was greatly insulting. I want to apologiz= e if it came off that way or if anyone perceived it as directed at them. I = think the quality of the discussion about version for the past year has bee= n of low quality. People did not present requirements or shows an actual ne= ed for versions, as well as lacked detail as to what is being versioned. Th= e only argument made is that "it seems like a useful thing". Again, please don't take my comments to imply anything personal and I am so= rry for my tone. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Thursday, July 01, 2010 10:57 AM > To: Marius Scurtescu > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Versioning >=20 >=20 >=20 > > -----Original Message----- > > From: Marius Scurtescu [mailto:mscurtescu@google.com] > > Sent: Thursday, July 01, 2010 10:37 AM > > To: Eran Hammer-Lahav > > Cc: Rob Richards; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Versioning > > > > On Thu, Jul 1, 2010 at 9:35 AM, Eran Hammer-Lahav > > > > wrote: > > > Hi Rob, > > > > > >> -----Original Message----- > > >> From: Rob Richards [mailto:rrichards@cdatazone.org] > > >> Sent: Thursday, July 01, 2010 3:26 AM > > >> To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > > >> Subject: Versioning > > >> > > >> Versioning is still something that needs to be addressed before > > >> being being able to consider the draft core complete. > > > > > > Versioning rarely works because when you define it, you have no idea > > what the requirements will be for the next version. A good example is > > the OAuth 1.0 version parameter. When we worked to revised 1.0 into > > 1.0a, we had a long debate on changing the protocol version number. We > > had a hard time agreeing on what the version meant and what was it a > > version *of*: the signature method or the token flow. > > > > > > If this protocol will require significant changes in the future that > > > go beyond > > its extensibility support, such a new version will need to use > > different endpoints (token or end-user authorization) and/or different > > HTTP authentication scheme. > > > > I don't think the authz server endpoints are an issue, but the > > protected resources. The auth scheme is very generic, "Token". So > > either the scheme should be more specific, like "OAuth2", or a version > > should be added as a parameter. Maybe a token type as Dick suggested. >=20 > HTTP Basic has no version, and I believe Digest doesn't have a version ei= ther > (though it has been revised from 2069 to 2617). The Token scheme is gener= ic, > but also wide open. The only required parameter is 'token' (which makes > sense for a Token scheme). I can't come up with a single requirement that > would require an explicit version parameter. >=20 > Version discussions are almost always a waste of time because at the time > they are debated, no one knows what the requirement for such a feature > will be. Versioning usually makes sense in a follow-up revision where the > protocol needs a way to differentiate itself from the previous version. >=20 > If anyone wants to propose a versioning of any parts of this protocol, th= ey > must present specific objectives. The vague objective of "allow future > versions" isn't valid because it has failed for 1.0 (and many other proto= cols). > Instead, I suggest people pay more attention to the extensibility and ens= ure > that it offers enough support for future needs, without having the change > the protocol. >=20 > We tried adding version support in OAuth 1.0 and failed. The version > parameter does not help in any real way, is incompletely, and poorly defi= ned. > The quality of this new discussion is as low as that of the 1.0 attempt. = Let's > learn from our mistakes. >=20 > EHL >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From lshepard@facebook.com Thu Jul 1 11:07: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 923C63A68D8 for ; Thu, 1 Jul 2010 11:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[AWL=0.969, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qE-7AnKbtmF for ; Thu, 1 Jul 2010 11:07:34 -0700 (PDT) Received: from mx-out.facebook.com (outmail005.ash1.tfbnw.net [69.63.184.105]) by core3.amsl.com (Postfix) with ESMTP id 56DCA3A67B6 for ; Thu, 1 Jul 2010 11:07:34 -0700 (PDT) Received: from [10.18.255.121] ([10.18.255.121:33909] helo=mail.thefacebook.com) by mta010.ash1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 31/83-00970-217DC2C4; Thu, 01 Jul 2010 10:57:38 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.694.1; Thu, 1 Jul 2010 10:57:34 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Thu, 1 Jul 2010 10:57:33 -0700 From: Luke Shepard To: Eran Hammer-Lahav Date: Thu, 1 Jul 2010 10:57:36 -0700 Thread-Topic: [OAUTH-WG] Underscore, dash, green, blue Thread-Index: AcsZRuFVBhp/yeeQQx2kwhdt0kQMEA== Message-ID: <0B379746-ED5A-4402-A8E6-1CF7D72ECE53@facebook.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0E0C7232-0C39-4D2A-9918-FCD68F27E789@photobucket.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3D7@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 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Underscore, dash, green, blue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:07:35 -0000 Don't really care, but to pick one - underscores throughout. Why not headers? On Jul 1, 2010, at 9:23 AM, Eran Hammer-Lahav wrote: > That's wasn't an option for a reason. Beside offending my esthetic sensib= ility :-) having the same parameter use a different name between the header= and endpoint makes registration of extension parameters much harder. For e= xample, if we used this scheme, the 'error-uri' parameter would require two= registration requests, one for 'error-uri' and another for 'error_uri'. >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Justin Hart >> Sent: Thursday, July 01, 2010 7:10 AM >> To: Pelle Braendgaard >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue >>=20 >> +1 for underscores except header keys. >> ---- >> -- Justin Hart >> -- jhart@photobucket.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Jul 1, 2010, at 7:39 AM, Pelle Braendgaard wrote: >>=20 >>> I already implemented 09 but it was a (very tiny) bit of a hassle to >>> have to convert underscores. >>>=20 >>> So I also agree with 3 except headers >>>=20 >>> On Thu, Jul 1, 2010 at 2:41 AM, Lukas Rosenstock >> wrote: >>>> 3 except headers. >>>>=20 >>>> 2010/7/1 Eran Hammer-Lahav : >>>>> First, sorry about this. J >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I do my best not to ask the group this kind of questions and just >>>>> pick something on my own, but I can't decide so I'll run a quick >>>>> vote (yes, a VOTE - I can't imagine seeking a consensus call on this)= . >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -09 uses underscores for parameter names (except for in the headers) >>>>> and dashes for parameter values. This seems like an odd selection. >>>>> Before, it used dashes for header parameter names, and underscore >>>>> everywhere else. Not great either. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> So... >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The changes my OCD can live with: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> 1. Use dashes throughout >>>>>=20 >>>>> 2. Use underscores for all parameter names (headers included), >>>>> dashes for all values >>>>>=20 >>>>> 3. Use underscores throughout >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I want to get this done with in a day because people are writing >>>>> code for >>>>> -09 and I'd like to stop making changes beyond editorial. I just >>>>> think that having different styles between the endpoint parameters >>>>> and header parameters is broken. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> EHL >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> http://lukasrosenstock.net/ >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> http://agree2.com - Reach Agreement! >>> http://stakeventures.com - My blog about startups and agile banking >>> _______________________________________________ >>> 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Thu Jul 1 11:09: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 D02883A6A0D for ; Thu, 1 Jul 2010 11:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.833 X-Spam-Level: X-Spam-Status: No, score=-16.833 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_55=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LttF+zZBwPVY for ; Thu, 1 Jul 2010 11:09:27 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id AF4263A6A02 for ; Thu, 1 Jul 2010 11:09:27 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o61I8ebe071547; Thu, 1 Jul 2010 11:08:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:x-originalarrivaltime; b=JySd83aa78pSat1gUQzQLBEjTJGtHP7AYQKQKjFZ3MHugE1r5uTNhqDjqEyFVdyf Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 11:08:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jul 2010 11:08:20 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6946@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZB9t1JjxcrbXrQsqobIZKUEzEKQAMg3aAAAKO0XAAAK/FEAAAThdA References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" To: "Eran Hammer-Lahav" , "Rob Richards" , X-OriginalArrivalTime: 01 Jul 2010 18:08:40.0730 (UTC) FILETIME=[6F6327A0:01CB1948] Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:09:28 -0000 Why is using the string "Token" better than "OAuth2"? 1.0 used "Oauth". If it's purely a question of aesthetics, I prefer "Oauth_2" to "Token" because I feel it's clearer and more descriptive.=20 > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 > Sent: Thursday, July 01, 2010 11:00 AM > To: William Mills; Rob Richards; oauth@ietf.org > Subject: RE: [OAUTH-WG] Versioning >=20 > Why is a version better than a new scheme name? Version is=20 > only helpful when the protocol is practically the same with=20 > some minor changes, and if that is the case, extensibility=20 > alone should be enough. >=20 > EHL=20 >=20 > > -----Original Message----- > > From: William Mills [mailto:wmills@yahoo-inc.com] > > Sent: Thursday, July 01, 2010 10:49 AM > > To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > > Subject: RE: [OAUTH-WG] Versioning > >=20 > > My feeling on this is that versioning explicitly in the=20 > protocol adds=20 > > clarity and some small level of compatibility. Different auth and=20 > > token endpoints are easy, what's harder is supporting multiple=20 > > protocols on the same protected resource. It's on the protected=20 > > resource I'd like to see some clearer protocol version spec=20 > so I'm not=20 > > having to figure out from the variable names which protocol it is. > >=20 > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > > > Behalf Of Eran Hammer-Lahav > > > Sent: Thursday, July 01, 2010 9:36 AM > > > To: Rob Richards; OAuth WG (oauth@ietf.org) > > > Subject: Re: [OAUTH-WG] Versioning > > > > > > Hi Rob, > > > > > > > -----Original Message----- > > > > From: Rob Richards [mailto:rrichards@cdatazone.org] > > > > Sent: Thursday, July 01, 2010 3:26 AM > > > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > > > > Subject: Versioning > > > > > > > > Versioning is still something that needs to be addressed > > > before being > > > > being able to consider the draft core complete. > > > > > > Versioning rarely works because when you define it, you=20 > have no idea=20 > > > what the requirements will be for the next version. A=20 > good example=20 > > > is the OAuth 1.0 version parameter. When we worked to revised 1.0=20 > > > into 1.0a, we had a long debate on changing the protocol version=20 > > > number. We had a hard time agreeing on what the version meant and=20 > > > what was it a version > > > *of*: the signature method or the token flow. > > > > > > If this protocol will require significant changes in the=20 > future that=20 > > > go beyond its extensibility support, such a new version=20 > will need to=20 > > > use different endpoints (token or end-user authorization) and/or=20 > > > different HTTP authentication scheme. > > > > > > If you want to discuss versioning, you must provide your=20 > > > requirements for such a feature, and clearly show how=20 > they are not=20 > > > served by the current extensibility proposal. > > > > > > > On this I'm still of the opinion that at the very=20 > minimum you will=20 > > > > need to require an oauth_version parameter for the resource > > > endpoints, > > > > if not also for the others as well. > > > > > > I think the difficulty of differentiating a 1.0 from a=20 > 2.0 protected=20 > > > resource request is exaggerated. As said before, you can tell the=20 > > > difference based on the presence of other parameter=20 > > > (oauth_signature_method), or by examining the provided token=20 > > > (assuming you issue different tokens for each version).=20 > The argument=20 > > > that a 2.0 request can also be a malformed 1.0 request is=20 > silly. I=20 > > > have yet to hear about that level of incompetence for a 1.0=20 > > > developer (and I've heard about a lot) - omitting every=20 > other required parameter. > > > > > > At most, I'm open to renaming the oauth_token parameter=20 > to something=20 > > > else (oauth_access_token, oauth.token, oauth-token, > > > etc.) but I think even that is not needed. > > > > > > EHL > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > >=20 From mscurtescu@google.com Thu Jul 1 11:16:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051513A6880 for ; Thu, 1 Jul 2010 11:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.176 X-Spam-Level: X-Spam-Status: No, score=-105.176 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_55=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 CAKl5-YygbtN for ; Thu, 1 Jul 2010 11:16:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BE4B13A67B6 for ; Thu, 1 Jul 2010 11:16:25 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o61IGa0G018252 for ; Thu, 1 Jul 2010 11:16:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278008197; bh=9OkJkM8co0cICBLrrzWCFNgoRR8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ChwnkOC5IxUl+eJdIpVLTHu4pl6nKLwOq32yhv8friYVM0kQROHZk3S3h7CrGmJlv Zx3eY6lFOm6EVp8d1kF/Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=YL4PU9VyToLfNP1LFkJ1d+SOSoxy9r1f+1L8X6vJmhYdxDQleK7bhZudisySD3lpn r6NFbOJzUT5Cl1nFpUngQ== Received: from gxk23 (gxk23.prod.google.com [10.202.11.23]) by kpbe12.cbf.corp.google.com with ESMTP id o61IGZmB019543 for ; Thu, 1 Jul 2010 11:16:36 -0700 Received: by gxk23 with SMTP id 23so1225465gxk.19 for ; Thu, 01 Jul 2010 11:16:35 -0700 (PDT) Received: by 10.100.165.18 with SMTP id n18mr13159070ane.246.1278008195205; Thu, 01 Jul 2010 11:16:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Thu, 1 Jul 2010 11:16:15 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 1 Jul 2010 11:16:15 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:16:27 -0000 On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav wr= ote: > Why is a version better than a new scheme name? Sure, but then make the scheme more specific. What will the scheme name be for OAuth 3? When tokens are passed in the query string there is no scheme. Marius > > EHL > >> -----Original Message----- >> From: William Mills [mailto:wmills@yahoo-inc.com] >> Sent: Thursday, July 01, 2010 10:49 AM >> To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org >> Subject: RE: [OAUTH-WG] Versioning >> >> My feeling on this is that versioning explicitly in the protocol adds cl= arity and >> some small level of compatibility. =A0Different auth and token endpoints= are >> easy, what's harder is supporting multiple protocols on the same protect= ed >> resource. =A0It's on the protected resource I'd like to see some clearer= protocol >> version spec so I'm not having to figure out from the variable names whi= ch >> protocol it is. >> >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> > Of Eran Hammer-Lahav >> > Sent: Thursday, July 01, 2010 9:36 AM >> > To: Rob Richards; OAuth WG (oauth@ietf.org) >> > Subject: Re: [OAUTH-WG] Versioning >> > >> > Hi Rob, >> > >> > > -----Original Message----- >> > > From: Rob Richards [mailto:rrichards@cdatazone.org] >> > > Sent: Thursday, July 01, 2010 3:26 AM >> > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav >> > > Subject: Versioning >> > > >> > > Versioning is still something that needs to be addressed >> > before being >> > > being able to consider the draft core complete. >> > >> > Versioning rarely works because when you define it, you have no idea >> > what the requirements will be for the next version. A good example is >> > the OAuth 1.0 version parameter. When we worked to revised 1.0 into >> > 1.0a, we had a long debate on changing the protocol version number. We >> > had a hard time agreeing on what the version meant and what was it a >> > version >> > *of*: the signature method or the token flow. >> > >> > If this protocol will require significant changes in the future that >> > go beyond its extensibility support, such a new version will need to >> > use different endpoints (token or end-user authorization) and/or >> > different HTTP authentication scheme. >> > >> > If you want to discuss versioning, you must provide your requirements >> > for such a feature, and clearly show how they are not served by the >> > current extensibility proposal. >> > >> > > On this I'm still of the opinion that at the very minimum you will >> > > need to require an oauth_version parameter for the resource >> > endpoints, >> > > if not also for the others as well. >> > >> > I think the difficulty of differentiating a 1.0 from a 2.0 protected >> > resource request is exaggerated. As said before, you can tell the >> > difference based on the presence of other parameter >> > (oauth_signature_method), or by examining the provided token (assuming >> > you issue different tokens for each version). The argument that a 2.0 >> > request can also be a malformed 1.0 request is silly. I have yet to >> > hear about that level of incompetence for a 1.0 developer (and I've >> > heard about a lot) - omitting every other required parameter. >> > >> > At most, I'm open to renaming the oauth_token parameter to something >> > else (oauth_access_token, oauth.token, oauth-token, >> > etc.) but I think even that is not needed. >> > >> > 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 eran@hueniverse.com Thu Jul 1 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 E867B3A6880 for ; Thu, 1 Jul 2010 11:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, J_CHICKENPOX_55=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 h+QEDmOZS2TZ for ; Thu, 1 Jul 2010 11:19:28 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A54893A69B0 for ; Thu, 1 Jul 2010 11:19:27 -0700 (PDT) Received: (qmail 14199 invoked from network); 1 Jul 2010 18:19:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 18:19:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 1 Jul 2010 11:19:36 -0700 From: Eran Hammer-Lahav To: William Mills , Rob Richards , "oauth@ietf.org" Date: Thu, 1 Jul 2010 11:19:48 -0700 Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZB9t1JjxcrbXrQsqobIZKUEzEKQAMg3aAAAKO0XAAAK/FEAAAThdAAAA+WzA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C470@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B6946@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6946@SNV-EXVS08.ds.corp.yahoo.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] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:19:29 -0000 I think HTTP authentication schemes should be generally useful. In this cas= e, OAuth defines a few ways to obtain an token, and a few ways to use a tok= en with HTTP resources. What it doesn't do is say anything useful about the= token itself, or implies that the tokens are "OAuth tokens" (i.e. that the= nature of the token is bound to the OAuth protocol). I can envision use cases where someone wants to use existing tokens (obtain= ed via other means than those provided by OAuth) to access protected resour= ces. What about using a token as currently defined is OAuth-specific? In other words, the scheme name is generic because OAuth tokens are generic= and for the most part left undefined. Naming the scheme OAuth implies that= there is a link between the token properties and how they are obtained, an= d the current protocol does not specify any such link. The same applies to = using HTTP Basic for client credentials, not to log-in an end-user. EHL > -----Original Message----- > From: William Mills [mailto:wmills@yahoo-inc.com] > Sent: Thursday, July 01, 2010 11:08 AM > To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > Subject: RE: [OAUTH-WG] Versioning >=20 > Why is using the string "Token" better than "OAuth2"? 1.0 used "Oauth". >=20 >=20 > If it's purely a question of aesthetics, I prefer "Oauth_2" to "Token" > because I feel it's clearer and more descriptive. >=20 > > -----Original Message----- > > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > > Sent: Thursday, July 01, 2010 11:00 AM > > To: William Mills; Rob Richards; oauth@ietf.org > > Subject: RE: [OAUTH-WG] Versioning > > > > Why is a version better than a new scheme name? Version is only > > helpful when the protocol is practically the same with some minor > > changes, and if that is the case, extensibility alone should be > > enough. > > > > EHL > > > > > -----Original Message----- > > > From: William Mills [mailto:wmills@yahoo-inc.com] > > > Sent: Thursday, July 01, 2010 10:49 AM > > > To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > > > Subject: RE: [OAUTH-WG] Versioning > > > > > > My feeling on this is that versioning explicitly in the > > protocol adds > > > clarity and some small level of compatibility. Different auth and > > > token endpoints are easy, what's harder is supporting multiple > > > protocols on the same protected resource. It's on the protected > > > resource I'd like to see some clearer protocol version spec > > so I'm not > > > having to figure out from the variable names which protocol it is. > > > > > > > -----Original Message----- > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > > > Behalf Of Eran Hammer-Lahav > > > > Sent: Thursday, July 01, 2010 9:36 AM > > > > To: Rob Richards; OAuth WG (oauth@ietf.org) > > > > Subject: Re: [OAUTH-WG] Versioning > > > > > > > > Hi Rob, > > > > > > > > > -----Original Message----- > > > > > From: Rob Richards [mailto:rrichards@cdatazone.org] > > > > > Sent: Thursday, July 01, 2010 3:26 AM > > > > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > > > > > Subject: Versioning > > > > > > > > > > Versioning is still something that needs to be addressed > > > > before being > > > > > being able to consider the draft core complete. > > > > > > > > Versioning rarely works because when you define it, you > > have no idea > > > > what the requirements will be for the next version. A > > good example > > > > is the OAuth 1.0 version parameter. When we worked to revised 1.0 > > > > into 1.0a, we had a long debate on changing the protocol version > > > > number. We had a hard time agreeing on what the version meant and > > > > what was it a version > > > > *of*: the signature method or the token flow. > > > > > > > > If this protocol will require significant changes in the > > future that > > > > go beyond its extensibility support, such a new version > > will need to > > > > use different endpoints (token or end-user authorization) and/or > > > > different HTTP authentication scheme. > > > > > > > > If you want to discuss versioning, you must provide your > > > > requirements for such a feature, and clearly show how > > they are not > > > > served by the current extensibility proposal. > > > > > > > > > On this I'm still of the opinion that at the very > > minimum you will > > > > > need to require an oauth_version parameter for the resource > > > > endpoints, > > > > > if not also for the others as well. > > > > > > > > I think the difficulty of differentiating a 1.0 from a > > 2.0 protected > > > > resource request is exaggerated. As said before, you can tell the > > > > difference based on the presence of other parameter > > > > (oauth_signature_method), or by examining the provided token > > > > (assuming you issue different tokens for each version). > > The argument > > > > that a 2.0 request can also be a malformed 1.0 request is > > silly. I > > > > have yet to hear about that level of incompetence for a 1.0 > > > > developer (and I've heard about a lot) - omitting every > > other required parameter. > > > > > > > > At most, I'm open to renaming the oauth_token parameter > > to something > > > > else (oauth_access_token, oauth.token, oauth-token, > > > > etc.) but I think even that is not needed. > > > > > > > > EHL > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > From mscurtescu@google.com Thu Jul 1 11:19:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EE2D3A67B6 for ; Thu, 1 Jul 2010 11:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.536 X-Spam-Level: X-Spam-Status: No, score=-101.536 tagged_above=-999 required=5 tests=[AWL=0.441, 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 06hA-fUZFkLi for ; Thu, 1 Jul 2010 11:19:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 03E253A6880 for ; Thu, 1 Jul 2010 11:19:39 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o61IJouu031509 for ; Thu, 1 Jul 2010 11:19:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278008390; bh=TEONDI2xYpELF6IeigZC39XW/Ho=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=JLymxzDLHnvxkebZdLNVd91wgwIZAUxWdGWDDA5b+i0MNS+diBgNKmSJ1QynZiGnU eid5wBoUxppisNgMsPg6A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=vc09bsD56dmdZjSA3Hl1nWgokoqdymbEf0Yvr8BQkj35w+3adVkmfpCPT+5YlPi1m E0SkEyfc4XGQgKoXhJY8A== Received: from gwj20 (gwj20.prod.google.com [10.200.10.20]) by kpbe16.cbf.corp.google.com with ESMTP id o61IJmI9021883 for ; Thu, 1 Jul 2010 11:19:49 -0700 Received: by gwj20 with SMTP id 20so1327134gwj.4 for ; Thu, 01 Jul 2010 11:19:48 -0700 (PDT) Received: by 10.100.163.13 with SMTP id l13mr13356063ane.267.1278008388240; Thu, 01 Jul 2010 11:19:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Thu, 1 Jul 2010 11:19:28 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C456@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0E0C7232-0C39-4D2A-9918-FCD68F27E789@photobucket.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0B379746-ED5A-4402-A8E6-1CF7D72ECE53@facebook.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C456@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 1 Jul 2010 11:19:28 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Underscore, dash, green, blue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:19:41 -0000 3 - all underscores. If underscores are a big issue with headers then we should consider 1 - all dashes. The problem with all dashes is that it is counterintuitive for people that know OAuth 1. Marius On Thu, Jul 1, 2010 at 11:01 AM, Eran Hammer-Lahav wr= ote: > > >> -----Original Message----- >> From: Luke Shepard [mailto:lshepard@facebook.com] >> Sent: Thursday, July 01, 2010 10:58 AM >> To: Eran Hammer-Lahav >> Cc: Justin Hart; Pelle Braendgaard; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue >> >> Don't really care, but to pick one - underscores throughout. >> >> Why not headers? > > Historically, HTTP headers use dashes and not underscores, but there is n= othing to prevent us from using underscores throughout. > > EHL > >> On Jul 1, 2010, at 9:23 AM, Eran Hammer-Lahav wrote: >> >> > That's wasn't an option for a reason. Beside offending my esthetic >> sensibility :-) having the same parameter use a different name between t= he >> header and endpoint makes registration of extension parameters much >> harder. For example, if we used this scheme, the 'error-uri' parameter w= ould >> require two registration requests, one for 'error-uri' and another for >> 'error_uri'. >> > >> > EHL >> > >> >> -----Original Message----- >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> >> Behalf Of Justin Hart >> >> Sent: Thursday, July 01, 2010 7:10 AM >> >> To: Pelle Braendgaard >> >> Cc: OAuth WG (oauth@ietf.org) >> >> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue >> >> >> >> +1 for underscores except header keys. >> >> ---- >> >> -- Justin Hart >> >> -- jhart@photobucket.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Jul 1, 2010, at 7:39 AM, Pelle Braendgaard wrote: >> >> >> >>> I already implemented 09 but it was a (very tiny) bit of a hassle to >> >>> have to convert underscores. >> >>> >> >>> So I also agree with 3 except headers >> >>> >> >>> On Thu, Jul 1, 2010 at 2:41 AM, Lukas Rosenstock >> >>> >> >> wrote: >> >>>> 3 except headers. >> >>>> >> >>>> 2010/7/1 Eran Hammer-Lahav : >> >>>>> First, sorry about this. J >> >>>>> >> >>>>> >> >>>>> >> >>>>> I do my best not to ask the group this kind of questions and just >> >>>>> pick something on my own, but I can't decide so I'll run a quick >> >>>>> vote (yes, a VOTE - I can't imagine seeking a consensus call on th= is). >> >>>>> >> >>>>> >> >>>>> >> >>>>> -09 uses underscores for parameter names (except for in the >> >>>>> headers) and dashes for parameter values. This seems like an odd >> selection. >> >>>>> Before, it used dashes for header parameter names, and underscore >> >>>>> everywhere else. Not great either. >> >>>>> >> >>>>> >> >>>>> >> >>>>> So... >> >>>>> >> >>>>> >> >>>>> >> >>>>> The changes my OCD can live with: >> >>>>> >> >>>>> >> >>>>> >> >>>>> 1. Use dashes throughout >> >>>>> >> >>>>> 2. Use underscores for all parameter names (headers included), >> >>>>> dashes for all values >> >>>>> >> >>>>> 3. Use underscores throughout >> >>>>> >> >>>>> >> >>>>> >> >>>>> I want to get this done with in a day because people are writing >> >>>>> code for >> >>>>> -09 and I'd like to stop making changes beyond editorial. =A0I jus= t >> >>>>> think that having different styles between the endpoint parameters >> >>>>> and header parameters is broken. >> >>>>> >> >>>>> >> >>>>> >> >>>>> EHL >> >>>>> >> >>>>> _______________________________________________ >> >>>>> OAuth mailing list >> >>>>> OAuth@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/oauth >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> http://lukasrosenstock.net/ >> >>>> _______________________________________________ >> >>>> OAuth mailing list >> >>>> OAuth@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/oauth >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> http://agree2.com - Reach Agreement! >> >>> http://stakeventures.com - My blog about startups and agile banking >> >>> _______________________________________________ >> >>> OAuth mailing list >> >>> OAuth@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Thu Jul 1 11:23: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 A62F53A67A3 for ; Thu, 1 Jul 2010 11:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, J_CHICKENPOX_55=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 IL+rZLa84W4s for ; Thu, 1 Jul 2010 11:23:57 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A39E43A6868 for ; Thu, 1 Jul 2010 11:23:57 -0700 (PDT) Received: (qmail 20390 invoked from network); 1 Jul 2010 18:24:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 18:24:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 1 Jul 2010 11:24:06 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Thu, 1 Jul 2010 11:24:18 -0700 Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZSZC823+xxqGaQ7CFftW66IJASwAAH0JA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:23:58 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Thursday, July 01, 2010 11:16 AM > To: Eran Hammer-Lahav > Cc: William Mills; Rob Richards; oauth@ietf.org > Subject: Re: [OAUTH-WG] Versioning >=20 > On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav > wrote: > > Why is a version better than a new scheme name? >=20 > Sure, but then make the scheme more specific. What will the scheme name > be for OAuth 3? I don't think there should be a new scheme for OAuth 3. The only reason why= we need to define a new scheme for OAuth 2 is that we so poorly defined th= e header for 1.0 and made it unworkable for new requirements. Reusing the O= Auth scheme from 1.0 would result in something closer to a hack than a prop= erly designed protocol, and the current cost of a new scheme is largely neg= ligible. If you would like to discuss a version for the header, please provide examp= les and requirements for what changes in the future you would like to suppo= rt. EHL > When tokens are passed in the query string there is no scheme. >=20 > Marius >=20 > > > > EHL > > > >> -----Original Message----- > >> From: William Mills [mailto:wmills@yahoo-inc.com] > >> Sent: Thursday, July 01, 2010 10:49 AM > >> To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > >> Subject: RE: [OAUTH-WG] Versioning > >> > >> My feeling on this is that versioning explicitly in the protocol adds > >> clarity and some small level of compatibility. =A0Different auth and > >> token endpoints are easy, what's harder is supporting multiple > >> protocols on the same protected resource. =A0It's on the protected > >> resource I'd like to see some clearer protocol version spec so I'm > >> not having to figure out from the variable names which protocol it is. > >> > >> > -----Original Message----- > >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> > Behalf Of Eran Hammer-Lahav > >> > Sent: Thursday, July 01, 2010 9:36 AM > >> > To: Rob Richards; OAuth WG (oauth@ietf.org) > >> > Subject: Re: [OAUTH-WG] Versioning > >> > > >> > Hi Rob, > >> > > >> > > -----Original Message----- > >> > > From: Rob Richards [mailto:rrichards@cdatazone.org] > >> > > Sent: Thursday, July 01, 2010 3:26 AM > >> > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > >> > > Subject: Versioning > >> > > > >> > > Versioning is still something that needs to be addressed > >> > before being > >> > > being able to consider the draft core complete. > >> > > >> > Versioning rarely works because when you define it, you have no > >> > idea what the requirements will be for the next version. A good > >> > example is the OAuth 1.0 version parameter. When we worked to > >> > revised 1.0 into 1.0a, we had a long debate on changing the > >> > protocol version number. We had a hard time agreeing on what the > >> > version meant and what was it a version > >> > *of*: the signature method or the token flow. > >> > > >> > If this protocol will require significant changes in the future > >> > that go beyond its extensibility support, such a new version will > >> > need to use different endpoints (token or end-user authorization) > >> > and/or different HTTP authentication scheme. > >> > > >> > If you want to discuss versioning, you must provide your > >> > requirements for such a feature, and clearly show how they are not > >> > served by the current extensibility proposal. > >> > > >> > > On this I'm still of the opinion that at the very minimum you > >> > > will need to require an oauth_version parameter for the resource > >> > endpoints, > >> > > if not also for the others as well. > >> > > >> > I think the difficulty of differentiating a 1.0 from a 2.0 > >> > protected resource request is exaggerated. As said before, you can > >> > tell the difference based on the presence of other parameter > >> > (oauth_signature_method), or by examining the provided token > >> > (assuming you issue different tokens for each version). The > >> > argument that a 2.0 request can also be a malformed 1.0 request is > >> > silly. I have yet to hear about that level of incompetence for a > >> > 1.0 developer (and I've heard about a lot) - omitting every other > required parameter. > >> > > >> > At most, I'm open to renaming the oauth_token parameter to > >> > something else (oauth_access_token, oauth.token, oauth-token, > >> > etc.) but I think even that is not needed. > >> > > >> > 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 eran@hueniverse.com Thu Jul 1 11:25: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 C1F253A6868 for ; Thu, 1 Jul 2010 11:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcRp20SIY+z8 for ; Thu, 1 Jul 2010 11:25:03 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 423313A67A3 for ; Thu, 1 Jul 2010 11:25:03 -0700 (PDT) Received: (qmail 21621 invoked from network); 1 Jul 2010 18:25:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 18:25:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 1 Jul 2010 11:25:08 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Thu, 1 Jul 2010 11:25:20 -0700 Thread-Topic: [OAUTH-WG] Underscore, dash, green, blue Thread-Index: AcsZSgAymnNeYG9qRn6wJNnGTdeX4gAAKfjQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C476@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0E0C7232-0C39-4D2A-9918-FCD68F27E789@photobucket.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0B379746-ED5A-4402-A8E6-1CF7D72ECE53@facebook.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C456@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Underscore, dash, green, blue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:25:04 -0000 The 1.0 install base is small enough to ignore. Looking at the interest and= community around 2.0 makes such considerations marginal. There is no problem with underscores in headers, it is just unusual. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Thursday, July 01, 2010 11:19 AM > To: Eran Hammer-Lahav > Cc: Luke Shepard; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Underscore, dash, green, blue >=20 > 3 - all underscores. >=20 > If underscores are a big issue with headers then we should consider 1 > - all dashes. The problem with all dashes is that it is counterintuitive = for > people that know OAuth 1. >=20 > Marius >=20 >=20 >=20 > On Thu, Jul 1, 2010 at 11:01 AM, Eran Hammer-Lahav > wrote: > > > > > >> -----Original Message----- > >> From: Luke Shepard [mailto:lshepard@facebook.com] > >> Sent: Thursday, July 01, 2010 10:58 AM > >> To: Eran Hammer-Lahav > >> Cc: Justin Hart; Pelle Braendgaard; OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue > >> > >> Don't really care, but to pick one - underscores throughout. > >> > >> Why not headers? > > > > Historically, HTTP headers use dashes and not underscores, but there is > nothing to prevent us from using underscores throughout. > > > > EHL > > > >> On Jul 1, 2010, at 9:23 AM, Eran Hammer-Lahav wrote: > >> > >> > That's wasn't an option for a reason. Beside offending my esthetic > >> sensibility :-) having the same parameter use a different name > >> between the header and endpoint makes registration of extension > >> parameters much harder. For example, if we used this scheme, the > >> 'error-uri' parameter would require two registration requests, one > >> for 'error-uri' and another for 'error_uri'. > >> > > >> > EHL > >> > > >> >> -----Original Message----- > >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> >> Behalf Of Justin Hart > >> >> Sent: Thursday, July 01, 2010 7:10 AM > >> >> To: Pelle Braendgaard > >> >> Cc: OAuth WG (oauth@ietf.org) > >> >> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue > >> >> > >> >> +1 for underscores except header keys. > >> >> ---- > >> >> -- Justin Hart > >> >> -- jhart@photobucket.com > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> On Jul 1, 2010, at 7:39 AM, Pelle Braendgaard wrote: > >> >> > >> >>> I already implemented 09 but it was a (very tiny) bit of a hassle > >> >>> to have to convert underscores. > >> >>> > >> >>> So I also agree with 3 except headers > >> >>> > >> >>> On Thu, Jul 1, 2010 at 2:41 AM, Lukas Rosenstock > >> >>> > >> >> wrote: > >> >>>> 3 except headers. > >> >>>> > >> >>>> 2010/7/1 Eran Hammer-Lahav : > >> >>>>> First, sorry about this. J > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> I do my best not to ask the group this kind of questions and > >> >>>>> just pick something on my own, but I can't decide so I'll run a > >> >>>>> quick vote (yes, a VOTE - I can't imagine seeking a consensus ca= ll on > this). > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> -09 uses underscores for parameter names (except for in the > >> >>>>> headers) and dashes for parameter values. This seems like an > >> >>>>> odd > >> selection. > >> >>>>> Before, it used dashes for header parameter names, and > >> >>>>> underscore everywhere else. Not great either. > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> So... > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> The changes my OCD can live with: > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> 1. Use dashes throughout > >> >>>>> > >> >>>>> 2. Use underscores for all parameter names (headers included), > >> >>>>> dashes for all values > >> >>>>> > >> >>>>> 3. Use underscores throughout > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> I want to get this done with in a day because people are > >> >>>>> writing code for > >> >>>>> -09 and I'd like to stop making changes beyond editorial. =A0I > >> >>>>> just think that having different styles between the endpoint > >> >>>>> parameters and header parameters is broken. > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> EHL > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> OAuth mailing list > >> >>>>> OAuth@ietf.org > >> >>>>> https://www.ietf.org/mailman/listinfo/oauth > >> >>>>> > >> >>>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> -- > >> >>>> http://lukasrosenstock.net/ > >> >>>> _______________________________________________ > >> >>>> OAuth mailing list > >> >>>> OAuth@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/oauth > >> >>>> > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> http://agree2.com - Reach Agreement! > >> >>> http://stakeventures.com - My blog about startups and agile > >> >>> banking > _______________________________________________ > >> >>> OAuth mailing list > >> >>> OAuth@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/oauth > >> >> > >> >> _______________________________________________ > >> >> OAuth mailing list > >> >> OAuth@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > From wmills@yahoo-inc.com Thu Jul 1 11:26: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 A3E0D3A67A3 for ; Thu, 1 Jul 2010 11:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.82 X-Spam-Level: X-Spam-Status: No, score=-16.82 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_55=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwPJoq2L4Odc for ; Thu, 1 Jul 2010 11:26:07 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 1C22D3A6868 for ; Thu, 1 Jul 2010 11:26:07 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o61IPk6c002703; Thu, 1 Jul 2010 11:25:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=T3j3J+adPFhIiajrLMT9oxgpy0l6v2LxtmzQNGFsV76gfOU0eNrw6w6U68IjUv3K Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 11:25:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jul 2010 11:25:25 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B694C@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZSZuTM0E+TBWuRDOEhaA5IEFtCgAAPccQ References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" To: "Marius Scurtescu" , "Eran Hammer-Lahav" X-OriginalArrivalTime: 01 Jul 2010 18:25:46.0565 (UTC) FILETIME=[D2D52750:01CB194A] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:26:08 -0000 +1 on this. Makes life interesting on the PR. > When tokens are passed in the query string there is no scheme.=20 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 > Sent: Thursday, July 01, 2010 11:16 AM > To: Eran Hammer-Lahav > Cc: William Mills; Rob Richards; oauth@ietf.org > Subject: Re: [OAUTH-WG] Versioning >=20 > On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav=20 > wrote: > > Why is a version better than a new scheme name? >=20 > Sure, but then make the scheme more specific. What will the=20 > scheme name be for OAuth 3? >=20 > When tokens are passed in the query string there is no scheme. >=20 > Marius >=20 > > > > EHL > > > >> -----Original Message----- > >> From: William Mills [mailto:wmills@yahoo-inc.com] > >> Sent: Thursday, July 01, 2010 10:49 AM > >> To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > >> Subject: RE: [OAUTH-WG] Versioning > >> > >> My feeling on this is that versioning explicitly in the=20 > protocol adds=20 > >> clarity and some small level of compatibility. =A0Different auth = and=20 > >> token endpoints are easy, what's harder is supporting multiple=20 > >> protocols on the same protected resource. =A0It's on the protected=20 > >> resource I'd like to see some clearer protocol version spec so I'm=20 > >> not having to figure out from the variable names which=20 > protocol it is. > >> > >> > -----Original Message----- > >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > >> > Behalf Of Eran Hammer-Lahav > >> > Sent: Thursday, July 01, 2010 9:36 AM > >> > To: Rob Richards; OAuth WG (oauth@ietf.org) > >> > Subject: Re: [OAUTH-WG] Versioning > >> > > >> > Hi Rob, > >> > > >> > > -----Original Message----- > >> > > From: Rob Richards [mailto:rrichards@cdatazone.org] > >> > > Sent: Thursday, July 01, 2010 3:26 AM > >> > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > >> > > Subject: Versioning > >> > > > >> > > Versioning is still something that needs to be addressed > >> > before being > >> > > being able to consider the draft core complete. > >> > > >> > Versioning rarely works because when you define it, you have no=20 > >> > idea what the requirements will be for the next version. A good=20 > >> > example is the OAuth 1.0 version parameter. When we worked to=20 > >> > revised 1.0 into 1.0a, we had a long debate on changing the=20 > >> > protocol version number. We had a hard time agreeing on what the=20 > >> > version meant and what was it a version > >> > *of*: the signature method or the token flow. > >> > > >> > If this protocol will require significant changes in the future=20 > >> > that go beyond its extensibility support, such a new=20 > version will=20 > >> > need to use different endpoints (token or end-user=20 > authorization)=20 > >> > and/or different HTTP authentication scheme. > >> > > >> > If you want to discuss versioning, you must provide your=20 > >> > requirements for such a feature, and clearly show how=20 > they are not=20 > >> > served by the current extensibility proposal. > >> > > >> > > On this I'm still of the opinion that at the very minimum you=20 > >> > > will need to require an oauth_version parameter for=20 > the resource > >> > endpoints, > >> > > if not also for the others as well. > >> > > >> > I think the difficulty of differentiating a 1.0 from a 2.0=20 > >> > protected resource request is exaggerated. As said=20 > before, you can=20 > >> > tell the difference based on the presence of other parameter=20 > >> > (oauth_signature_method), or by examining the provided token=20 > >> > (assuming you issue different tokens for each version). The=20 > >> > argument that a 2.0 request can also be a malformed 1.0=20 > request is=20 > >> > silly. I have yet to hear about that level of incompetence for a=20 > >> > 1.0 developer (and I've heard about a lot) - omitting=20 > every other required parameter. > >> > > >> > At most, I'm open to renaming the oauth_token parameter to=20 > >> > something else (oauth_access_token, oauth.token, oauth-token, > >> > etc.) but I think even that is not needed. > >> > > >> > 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 > > >=20 From mscurtescu@google.com Thu Jul 1 11:28:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FEAA3A699C for ; Thu, 1 Jul 2010 11:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.249 X-Spam-Level: X-Spam-Status: No, score=-101.249 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_55=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NNLcGhZXX-j for ; Thu, 1 Jul 2010 11:28:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9183A3A67A3 for ; Thu, 1 Jul 2010 11:28:17 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o61ISS10030748 for ; Thu, 1 Jul 2010 11:28:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278008908; bh=CuT+tZOiTki8MaLW6u8aL24AmVw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Ve/0hNqIOoTz3A15Dl9AHI57xun2K//inEFhBOoaOrJoZyvYiqaBYn+SKLAoQncWr t7V0IAGTHuc0x4wepHywg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=OttAe6xi5rHTvgrHbhV9z1/1+oEeDi5iLGq+fO7mR8VuEYDpUICVTuSwlfl0x4QC6 YZULKhOklf78lMOS0YFYw== Received: from gxk19 (gxk19.prod.google.com [10.202.11.19]) by hpaq6.eem.corp.google.com with ESMTP id o61ISR61011634 for ; Thu, 1 Jul 2010 11:28:27 -0700 Received: by gxk19 with SMTP id 19so611380gxk.18 for ; Thu, 01 Jul 2010 11:28:26 -0700 (PDT) Received: by 10.101.146.3 with SMTP id y3mr13137982ann.199.1278008906102; Thu, 01 Jul 2010 11:28:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Thu, 1 Jul 2010 11:28:06 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C470@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B6946@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C470@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 1 Jul 2010 11:28:06 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:28:19 -0000 On Thu, Jul 1, 2010 at 11:19 AM, Eran Hammer-Lahav wr= ote: > I think HTTP authentication schemes should be generally useful. In this c= ase, OAuth defines a few ways to obtain an token, and a few ways to use a t= oken with HTTP resources. What it doesn't do is say anything useful about t= he token itself, or implies that the tokens are "OAuth tokens" (i.e. that t= he nature of the token is bound to the OAuth protocol). > > I can envision use cases where someone wants to use existing tokens (obta= ined via other means than those provided by OAuth) to access protected reso= urces. What about using a token as currently defined is OAuth-specific? > > In other words, the scheme name is generic because OAuth tokens are gener= ic and for the most part left undefined. Naming the scheme OAuth implies th= at there is a link between the token properties and how they are obtained, = and the current protocol does not specify any such link. The same applies t= o using HTTP Basic for client credentials, not to log-in an end-user. Sure, but then I think the "Token" scheme needs its own standalone spec and not be defined as part of the OAuth 2 spec. Marius > > EHL > >> -----Original Message----- >> From: William Mills [mailto:wmills@yahoo-inc.com] >> Sent: Thursday, July 01, 2010 11:08 AM >> To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org >> Subject: RE: [OAUTH-WG] Versioning >> >> Why is using the string "Token" better than "OAuth2"? =A01.0 used "Oauth= ". >> >> >> If it's purely a question of aesthetics, I prefer "Oauth_2" to "Token" >> because I feel it's clearer and more descriptive. >> >> > -----Original Message----- >> > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] >> > Sent: Thursday, July 01, 2010 11:00 AM >> > To: William Mills; Rob Richards; oauth@ietf.org >> > Subject: RE: [OAUTH-WG] Versioning >> > >> > Why is a version better than a new scheme name? Version is only >> > helpful when the protocol is practically the same with some minor >> > changes, and if that is the case, extensibility alone should be >> > enough. >> > >> > EHL >> > >> > > -----Original Message----- >> > > From: William Mills [mailto:wmills@yahoo-inc.com] >> > > Sent: Thursday, July 01, 2010 10:49 AM >> > > To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org >> > > Subject: RE: [OAUTH-WG] Versioning >> > > >> > > My feeling on this is that versioning explicitly in the >> > protocol adds >> > > clarity and some small level of compatibility. =A0Different auth and >> > > token endpoints are easy, what's harder is supporting multiple >> > > protocols on the same protected resource. =A0It's on the protected >> > > resource I'd like to see some clearer protocol version spec >> > so I'm not >> > > having to figure out from the variable names which protocol it is. >> > > >> > > > -----Original Message----- >> > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> > > > Behalf Of Eran Hammer-Lahav >> > > > Sent: Thursday, July 01, 2010 9:36 AM >> > > > To: Rob Richards; OAuth WG (oauth@ietf.org) >> > > > Subject: Re: [OAUTH-WG] Versioning >> > > > >> > > > Hi Rob, >> > > > >> > > > > -----Original Message----- >> > > > > From: Rob Richards [mailto:rrichards@cdatazone.org] >> > > > > Sent: Thursday, July 01, 2010 3:26 AM >> > > > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav >> > > > > Subject: Versioning >> > > > > >> > > > > Versioning is still something that needs to be addressed >> > > > before being >> > > > > being able to consider the draft core complete. >> > > > >> > > > Versioning rarely works because when you define it, you >> > have no idea >> > > > what the requirements will be for the next version. A >> > good example >> > > > is the OAuth 1.0 version parameter. When we worked to revised 1.0 >> > > > into 1.0a, we had a long debate on changing the protocol version >> > > > number. We had a hard time agreeing on what the version meant and >> > > > what was it a version >> > > > *of*: the signature method or the token flow. >> > > > >> > > > If this protocol will require significant changes in the >> > future that >> > > > go beyond its extensibility support, such a new version >> > will need to >> > > > use different endpoints (token or end-user authorization) and/or >> > > > different HTTP authentication scheme. >> > > > >> > > > If you want to discuss versioning, you must provide your >> > > > requirements for such a feature, and clearly show how >> > they are not >> > > > served by the current extensibility proposal. >> > > > >> > > > > On this I'm still of the opinion that at the very >> > minimum you will >> > > > > need to require an oauth_version parameter for the resource >> > > > endpoints, >> > > > > if not also for the others as well. >> > > > >> > > > I think the difficulty of differentiating a 1.0 from a >> > 2.0 protected >> > > > resource request is exaggerated. As said before, you can tell the >> > > > difference based on the presence of other parameter >> > > > (oauth_signature_method), or by examining the provided token >> > > > (assuming you issue different tokens for each version). >> > The argument >> > > > that a 2.0 request can also be a malformed 1.0 request is >> > silly. I >> > > > have yet to hear about that level of incompetence for a 1.0 >> > > > developer (and I've heard about a lot) - omitting every >> > other required parameter. >> > > > >> > > > At most, I'm open to renaming the oauth_token parameter >> > to something >> > > > else (oauth_access_token, oauth.token, oauth-token, >> > > > etc.) but I think even that is not needed. >> > > > >> > > > 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 jricher@mitre.org Thu Jul 1 11:29: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 D82833A69B4 for ; Thu, 1 Jul 2010 11:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.824 X-Spam-Level: X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[AWL=0.775, 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 lXV-rWgW0rjm for ; Thu, 1 Jul 2010 11:29:13 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id F258B3A69C8 for ; Thu, 1 Jul 2010 11:29:12 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o61ITNQI005890 for ; Thu, 1 Jul 2010 14:29:24 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o61ITNi2005887; Thu, 1 Jul 2010 14:29:23 -0400 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, 1 Jul 2010 14:29:23 -0400 From: Justin Richer To: Marius Scurtescu In-Reply-To: References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1277989381.28743.160.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Thu, 1 Jul 2010 14:29:23 -0400 Message-ID: <1278008963.28743.199.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:29:13 -0000 > > In most instances outside of the Big Web Companies, OAuth is going to be > > the new kid being grafted onto an existing framework or application. As > > such, it really needs to play nice. > > Just a side note, with extensions also being simple names added to the > protocol chances of a collision with an existing framework are much > higher. Using MediaWiki as an example, if an extension proposes to use > 'title' as a parameter name it will be approved if it does not collied > with other OAuth 2 parameter names (core or extensions), but > frameworks will not be checked (that is impossible). Right, and it's exactly for reasons like this that I had argued for namespacing all of the OAuth parameters. But was shot down by the WG. -- Justin From mscurtescu@google.com Thu Jul 1 11:35: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 71A7C3A67A3 for ; Thu, 1 Jul 2010 11:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.185 X-Spam-Level: X-Spam-Status: No, score=-105.185 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_55=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 XekcHndyGrMd for ; Thu, 1 Jul 2010 11:35:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id ADB2C3A6868 for ; Thu, 1 Jul 2010 11:35:48 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o61IZxjI032691 for ; Thu, 1 Jul 2010 11:35:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278009360; bh=jhspOnCn7zmJLqm9HEDH6LTikDM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=iMkB9b83kWO3LTfMO+AS6WSchXd2YWkYSIHqVM45hcIEBslLIVNthuCfEvUPn2wQ1 Uz5WzVQ/wbmQeOtZXzqLQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=M6SPcOQ+ltmGXwrdqB/jrgpZTFnfbxJIm2/bCmVZefVY1q9072Zs9FN/31TMfBr4n Cxe7FtVsJEE6RQNXPvpVQ== Received: from gwb10 (gwb10.prod.google.com [10.200.2.10]) by kpbe11.cbf.corp.google.com with ESMTP id o61IZwlQ023000 for ; Thu, 1 Jul 2010 11:35:58 -0700 Received: by gwb10 with SMTP id 10so1343088gwb.31 for ; Thu, 01 Jul 2010 11:35:58 -0700 (PDT) Received: by 10.100.163.13 with SMTP id l13mr13380176ane.267.1278009358177; Thu, 01 Jul 2010 11:35:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Thu, 1 Jul 2010 11:35:38 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 1 Jul 2010 11:35:38 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:35:51 -0000 On Thu, Jul 1, 2010 at 11:24 AM, Eran Hammer-Lahav wr= ote: > > If you would like to discuss a version for the header, please provide exa= mples and requirements for what changes in the future you would like to sup= port. Not sure about the future, but looking at OAuth 1 vs OAuth 2. A protected resource request filter may want to decide early what protocol it deals with so it can call the appropriate handler, or to enforce HTTPS for OAuth 2 for example. Sure, it can apply heuristics right now, but it would be nice to have a more deterministic way which can also be extended in the future. You can always embed the protocol version inside the token I guess, so I don't think this is a huge issue. I was not part of the 1.0 vs 1.0a discussions, so not sure what was the conclusion there. Marius > > EHL > >> When tokens are passed in the query string there is no scheme. >> >> Marius >> >> > >> > EHL >> > >> >> -----Original Message----- >> >> From: William Mills [mailto:wmills@yahoo-inc.com] >> >> Sent: Thursday, July 01, 2010 10:49 AM >> >> To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org >> >> Subject: RE: [OAUTH-WG] Versioning >> >> >> >> My feeling on this is that versioning explicitly in the protocol adds >> >> clarity and some small level of compatibility. =A0Different auth and >> >> token endpoints are easy, what's harder is supporting multiple >> >> protocols on the same protected resource. =A0It's on the protected >> >> resource I'd like to see some clearer protocol version spec so I'm >> >> not having to figure out from the variable names which protocol it is= . >> >> >> >> > -----Original Message----- >> >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> >> > Behalf Of Eran Hammer-Lahav >> >> > Sent: Thursday, July 01, 2010 9:36 AM >> >> > To: Rob Richards; OAuth WG (oauth@ietf.org) >> >> > Subject: Re: [OAUTH-WG] Versioning >> >> > >> >> > Hi Rob, >> >> > >> >> > > -----Original Message----- >> >> > > From: Rob Richards [mailto:rrichards@cdatazone.org] >> >> > > Sent: Thursday, July 01, 2010 3:26 AM >> >> > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav >> >> > > Subject: Versioning >> >> > > >> >> > > Versioning is still something that needs to be addressed >> >> > before being >> >> > > being able to consider the draft core complete. >> >> > >> >> > Versioning rarely works because when you define it, you have no >> >> > idea what the requirements will be for the next version. A good >> >> > example is the OAuth 1.0 version parameter. When we worked to >> >> > revised 1.0 into 1.0a, we had a long debate on changing the >> >> > protocol version number. We had a hard time agreeing on what the >> >> > version meant and what was it a version >> >> > *of*: the signature method or the token flow. >> >> > >> >> > If this protocol will require significant changes in the future >> >> > that go beyond its extensibility support, such a new version will >> >> > need to use different endpoints (token or end-user authorization) >> >> > and/or different HTTP authentication scheme. >> >> > >> >> > If you want to discuss versioning, you must provide your >> >> > requirements for such a feature, and clearly show how they are not >> >> > served by the current extensibility proposal. >> >> > >> >> > > On this I'm still of the opinion that at the very minimum you >> >> > > will need to require an oauth_version parameter for the resource >> >> > endpoints, >> >> > > if not also for the others as well. >> >> > >> >> > I think the difficulty of differentiating a 1.0 from a 2.0 >> >> > protected resource request is exaggerated. As said before, you can >> >> > tell the difference based on the presence of other parameter >> >> > (oauth_signature_method), or by examining the provided token >> >> > (assuming you issue different tokens for each version). The >> >> > argument that a 2.0 request can also be a malformed 1.0 request is >> >> > silly. I have yet to hear about that level of incompetence for a >> >> > 1.0 developer (and I've heard about a lot) - omitting every other >> required parameter. >> >> > >> >> > At most, I'm open to renaming the oauth_token parameter to >> >> > something else (oauth_access_token, oauth.token, oauth-token, >> >> > etc.) but I think even that is not needed. >> >> > >> >> > 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 eran@hueniverse.com Thu Jul 1 11:41:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E0343A6862 for ; Thu, 1 Jul 2010 11:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, J_CHICKENPOX_55=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 ERnHo+qhSGLw for ; Thu, 1 Jul 2010 11:41:49 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E83E13A6817 for ; Thu, 1 Jul 2010 11:41:48 -0700 (PDT) Received: (qmail 2179 invoked from network); 1 Jul 2010 18:41:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 18:41:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 1 Jul 2010 11:41:54 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Thu, 1 Jul 2010 11:42:05 -0700 Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZSzjT2XuJsjIFRJKTa1PyFud/4wAAcgWA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C481@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B6946@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C470@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:41:50 -0000 It was and this approach was rejected by this group as confusing. At this p= oint, it's specification is so short, it can live anywhere. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Thursday, July 01, 2010 11:28 AM > To: Eran Hammer-Lahav > Cc: William Mills; Rob Richards; oauth@ietf.org > Subject: Re: [OAUTH-WG] Versioning >=20 > On Thu, Jul 1, 2010 at 11:19 AM, Eran Hammer-Lahav > wrote: > > I think HTTP authentication schemes should be generally useful. In this > case, OAuth defines a few ways to obtain an token, and a few ways to use = a > token with HTTP resources. What it doesn't do is say anything useful abou= t > the token itself, or implies that the tokens are "OAuth tokens" (i.e. tha= t the > nature of the token is bound to the OAuth protocol). > > > > I can envision use cases where someone wants to use existing tokens > (obtained via other means than those provided by OAuth) to access > protected resources. What about using a token as currently defined is > OAuth-specific? > > > > In other words, the scheme name is generic because OAuth tokens are > generic and for the most part left undefined. Naming the scheme OAuth > implies that there is a link between the token properties and how they ar= e > obtained, and the current protocol does not specify any such link. The sa= me > applies to using HTTP Basic for client credentials, not to log-in an end-= user. >=20 > Sure, but then I think the "Token" scheme needs its own standalone spec > and not be defined as part of the OAuth 2 spec. >=20 > Marius >=20 > > > > EHL > > > >> -----Original Message----- > >> From: William Mills [mailto:wmills@yahoo-inc.com] > >> Sent: Thursday, July 01, 2010 11:08 AM > >> To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > >> Subject: RE: [OAUTH-WG] Versioning > >> > >> Why is using the string "Token" better than "OAuth2"? =A01.0 used "Oau= th". > >> > >> > >> If it's purely a question of aesthetics, I prefer "Oauth_2" to "Token" > >> because I feel it's clearer and more descriptive. > >> > >> > -----Original Message----- > >> > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > >> > Sent: Thursday, July 01, 2010 11:00 AM > >> > To: William Mills; Rob Richards; oauth@ietf.org > >> > Subject: RE: [OAUTH-WG] Versioning > >> > > >> > Why is a version better than a new scheme name? Version is only > >> > helpful when the protocol is practically the same with some minor > >> > changes, and if that is the case, extensibility alone should be > >> > enough. > >> > > >> > EHL > >> > > >> > > -----Original Message----- > >> > > From: William Mills [mailto:wmills@yahoo-inc.com] > >> > > Sent: Thursday, July 01, 2010 10:49 AM > >> > > To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > >> > > Subject: RE: [OAUTH-WG] Versioning > >> > > > >> > > My feeling on this is that versioning explicitly in the > >> > protocol adds > >> > > clarity and some small level of compatibility. =A0Different auth > >> > > and token endpoints are easy, what's harder is supporting > >> > > multiple protocols on the same protected resource. =A0It's on the > >> > > protected resource I'd like to see some clearer protocol version > >> > > spec > >> > so I'm not > >> > > having to figure out from the variable names which protocol it is. > >> > > > >> > > > -----Original Message----- > >> > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> > > > Behalf Of Eran Hammer-Lahav > >> > > > Sent: Thursday, July 01, 2010 9:36 AM > >> > > > To: Rob Richards; OAuth WG (oauth@ietf.org) > >> > > > Subject: Re: [OAUTH-WG] Versioning > >> > > > > >> > > > Hi Rob, > >> > > > > >> > > > > -----Original Message----- > >> > > > > From: Rob Richards [mailto:rrichards@cdatazone.org] > >> > > > > Sent: Thursday, July 01, 2010 3:26 AM > >> > > > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > >> > > > > Subject: Versioning > >> > > > > > >> > > > > Versioning is still something that needs to be addressed > >> > > > before being > >> > > > > being able to consider the draft core complete. > >> > > > > >> > > > Versioning rarely works because when you define it, you > >> > have no idea > >> > > > what the requirements will be for the next version. A > >> > good example > >> > > > is the OAuth 1.0 version parameter. When we worked to revised > >> > > > 1.0 into 1.0a, we had a long debate on changing the protocol > >> > > > version number. We had a hard time agreeing on what the version > >> > > > meant and what was it a version > >> > > > *of*: the signature method or the token flow. > >> > > > > >> > > > If this protocol will require significant changes in the > >> > future that > >> > > > go beyond its extensibility support, such a new version > >> > will need to > >> > > > use different endpoints (token or end-user authorization) > >> > > > and/or different HTTP authentication scheme. > >> > > > > >> > > > If you want to discuss versioning, you must provide your > >> > > > requirements for such a feature, and clearly show how > >> > they are not > >> > > > served by the current extensibility proposal. > >> > > > > >> > > > > On this I'm still of the opinion that at the very > >> > minimum you will > >> > > > > need to require an oauth_version parameter for the resource > >> > > > endpoints, > >> > > > > if not also for the others as well. > >> > > > > >> > > > I think the difficulty of differentiating a 1.0 from a > >> > 2.0 protected > >> > > > resource request is exaggerated. As said before, you can tell > >> > > > the difference based on the presence of other parameter > >> > > > (oauth_signature_method), or by examining the provided token > >> > > > (assuming you issue different tokens for each version). > >> > The argument > >> > > > that a 2.0 request can also be a malformed 1.0 request is > >> > silly. I > >> > > > have yet to hear about that level of incompetence for a 1.0 > >> > > > developer (and I've heard about a lot) - omitting every > >> > other required parameter. > >> > > > > >> > > > At most, I'm open to renaming the oauth_token parameter > >> > to something > >> > > > else (oauth_access_token, oauth.token, oauth-token, > >> > > > etc.) but I think even that is not needed. > >> > > > > >> > > > 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 rrichards@cdatazone.org Thu Jul 1 11:42: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 71E1D3A6862 for ; Thu, 1 Jul 2010 11:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6hJteH9tm+8 for ; Thu, 1 Jul 2010 11:42:52 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by core3.amsl.com (Postfix) with ESMTP id 482B23A67A3 for ; Thu, 1 Jul 2010 11:42:52 -0700 (PDT) Received: from [67.158.171.203] (helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1OUOix-0003zX-1i; Thu, 01 Jul 2010 18:42:59 +0000 Message-ID: <4C2CE1B2.8000605@cdatazone.org> Date: Thu, 01 Jul 2010 14:42:58 -0400 From: Rob Richards User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C450@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C450@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP2Go-MailScanner-Information: Please contact support@smtp2go.com for more information X-SMTP2Go-MailScanner-ID: 1OUOix-0003zX-1i X-SMTP2Go-MailScanner: Found to be clean X-SMTP2Go-MailScanner-From: rrichards@cdatazone.org Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:42:53 -0000 Eran Hammer-Lahav wrote: > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Thursday, July 01, 2010 10:37 AM >> To: Eran Hammer-Lahav >> Cc: Rob Richards; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Versioning >> >> On Thu, Jul 1, 2010 at 9:35 AM, Eran Hammer-Lahav >> wrote: >> >>> Hi Rob, >>> >>> >>>> -----Original Message----- >>>> From: Rob Richards [mailto:rrichards@cdatazone.org] >>>> Sent: Thursday, July 01, 2010 3:26 AM >>>> To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav >>>> Subject: Versioning >>>> >>>> Versioning is still something that needs to be addressed before being >>>> being able to consider the draft core complete. >>>> >>> Versioning rarely works because when you define it, you have no idea >>> >> what the requirements will be for the next version. A good example is the >> OAuth 1.0 version parameter. When we worked to revised 1.0 into 1.0a, we >> had a long debate on changing the protocol version number. We had a hard >> time agreeing on what the version meant and what was it a version *of*: the >> signature method or the token flow. >> >>> If this protocol will require significant changes in the future that go beyond >>> >> its extensibility support, such a new version will need to use different >> endpoints (token or end-user authorization) and/or different HTTP >> authentication scheme. >> >> I don't think the authz server endpoints are an issue, but the protected >> resources. The auth scheme is very generic, "Token". So either the scheme >> should be more specific, like "OAuth2", or a version should be added as a >> parameter. Maybe a token type as Dick suggested. >> > > HTTP Basic has no version, and I believe Digest doesn't have a version either (though it has been revised from 2069 to 2617). The Token scheme is generic, but also wide open. The only required parameter is 'token' (which makes sense for a Token scheme). I can't come up with a single requirement that would require an explicit version parameter. > > Version discussions are almost always a waste of time because at the time they are debated, no one knows what the requirement for such a feature will be. Versioning usually makes sense in a follow-up revision where the protocol needs a way to differentiate itself from the previous version. > > > Exactly. While it might be needed in the future, there is a need to differentiate OAuth 1.0 from 2.0 on resource endpoints right now. Outside of requiring an oauth_version parameter (or equivalent) all other suggestions leave versioning as a grey area, where things can be interpreted one way or another with no consistency. Grey areas in specs are a bad thing. You end up with different languages/libraries dealing with things in completely different and incompatible ways because something was not clearly spelled out. Rob From wmills@yahoo-inc.com Thu Jul 1 11:43: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 09BD93A68A0 for ; Thu, 1 Jul 2010 11:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.976 X-Spam-Level: X-Spam-Status: No, score=-16.976 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R6+z0UIDLks for ; Thu, 1 Jul 2010 11:43:04 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 13B6C3A690B for ; Thu, 1 Jul 2010 11:43:04 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o61IgoJp088758; Thu, 1 Jul 2010 11:42:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=rhclJVv1G0lKxUenLarBAs0ixfyZ8A3TLzPRBkPrWHVEIQcdzrzpzMVyr80jBaV9 Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 11:42:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jul 2010 11:42:02 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B694F@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZTFTIwax+TF8xRQ+QYrNTV/OyqgAAGoYg References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" To: "Marius Scurtescu" , "Eran Hammer-Lahav" X-OriginalArrivalTime: 01 Jul 2010 18:42:50.0636 (UTC) FILETIME=[3539FCC0:01CB194D] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:43:05 -0000 =20 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 > Sent: Thursday, July 01, 2010 11:36 AM > To: Eran Hammer-Lahav > Cc: William Mills; Rob Richards; oauth@ietf.org > Subject: Re: [OAUTH-WG] Versioning >=20 > On Thu, Jul 1, 2010 at 11:24 AM, Eran Hammer-Lahav=20 > wrote: > > > > If you would like to discuss a version for the header,=20 > please provide examples and requirements for what changes in=20 > the future you would like to support. >=20 > Not sure about the future, but looking at OAuth 1 vs OAuth 2.=20 > A protected resource request filter may want to decide early=20 > what protocol it deals with so it can call the appropriate=20 > handler, or to enforce HTTPS for OAuth 2 for example. Sure,=20 > it can apply heuristics right now, but it would be nice to=20 > have a more deterministic way which can also be extended in=20 > the future. You can always embed the protocol version inside=20 > the token I guess, so I don't think this is a huge issue. Yeah, unfortunately early selection of a handler might require peeking = into the post body. =20 >=20 > I was not part of the 1.0 vs 1.0a discussions, so not sure=20 > what was the conclusion there. >=20 > Marius >=20 > > > > EHL > > > >> When tokens are passed in the query string there is no scheme. > >> > >> Marius > >> > >> > > >> > EHL > >> > > >> >> -----Original Message----- > >> >> From: William Mills [mailto:wmills@yahoo-inc.com] > >> >> Sent: Thursday, July 01, 2010 10:49 AM > >> >> To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > >> >> Subject: RE: [OAUTH-WG] Versioning > >> >> > >> >> My feeling on this is that versioning explicitly in the=20 > protocol=20 > >> >> adds clarity and some small level of compatibility. =A0Different = > >> >> auth and token endpoints are easy, what's harder is supporting=20 > >> >> multiple protocols on the same protected resource. =A0It's on = the=20 > >> >> protected resource I'd like to see some clearer=20 > protocol version=20 > >> >> spec so I'm not having to figure out from the variable=20 > names which protocol it is. > >> >> > >> >> > -----Original Message----- > >> >> > From: oauth-bounces@ietf.org=20 > [mailto:oauth-bounces@ietf.org] On=20 > >> >> > Behalf Of Eran Hammer-Lahav > >> >> > Sent: Thursday, July 01, 2010 9:36 AM > >> >> > To: Rob Richards; OAuth WG (oauth@ietf.org) > >> >> > Subject: Re: [OAUTH-WG] Versioning > >> >> > > >> >> > Hi Rob, > >> >> > > >> >> > > -----Original Message----- > >> >> > > From: Rob Richards [mailto:rrichards@cdatazone.org] > >> >> > > Sent: Thursday, July 01, 2010 3:26 AM > >> >> > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > >> >> > > Subject: Versioning > >> >> > > > >> >> > > Versioning is still something that needs to be addressed > >> >> > before being > >> >> > > being able to consider the draft core complete. > >> >> > > >> >> > Versioning rarely works because when you define it,=20 > you have no=20 > >> >> > idea what the requirements will be for the next=20 > version. A good=20 > >> >> > example is the OAuth 1.0 version parameter. When we worked to=20 > >> >> > revised 1.0 into 1.0a, we had a long debate on changing the=20 > >> >> > protocol version number. We had a hard time agreeing=20 > on what the=20 > >> >> > version meant and what was it a version > >> >> > *of*: the signature method or the token flow. > >> >> > > >> >> > If this protocol will require significant changes in=20 > the future=20 > >> >> > that go beyond its extensibility support, such a new version=20 > >> >> > will need to use different endpoints (token or end-user=20 > >> >> > authorization) and/or different HTTP authentication scheme. > >> >> > > >> >> > If you want to discuss versioning, you must provide your=20 > >> >> > requirements for such a feature, and clearly show how=20 > they are=20 > >> >> > not served by the current extensibility proposal. > >> >> > > >> >> > > On this I'm still of the opinion that at the very=20 > minimum you=20 > >> >> > > will need to require an oauth_version parameter for the=20 > >> >> > > resource > >> >> > endpoints, > >> >> > > if not also for the others as well. > >> >> > > >> >> > I think the difficulty of differentiating a 1.0 from a 2.0=20 > >> >> > protected resource request is exaggerated. As said=20 > before, you=20 > >> >> > can tell the difference based on the presence of=20 > other parameter=20 > >> >> > (oauth_signature_method), or by examining the provided token=20 > >> >> > (assuming you issue different tokens for each version). The=20 > >> >> > argument that a 2.0 request can also be a malformed=20 > 1.0 request=20 > >> >> > is silly. I have yet to hear about that level of incompetence=20 > >> >> > for a 1.0 developer (and I've heard about a lot) - omitting=20 > >> >> > every other > >> required parameter. > >> >> > > >> >> > At most, I'm open to renaming the oauth_token parameter to=20 > >> >> > something else (oauth_access_token, oauth.token, oauth-token, > >> >> > etc.) but I think even that is not needed. > >> >> > > >> >> > 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 > >> > > > >=20 From mscurtescu@google.com Thu Jul 1 11:47: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 1EF653A6A15 for ; Thu, 1 Jul 2010 11:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.553 X-Spam-Level: X-Spam-Status: No, score=-101.553 tagged_above=-999 required=5 tests=[AWL=0.424, 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 Xjbo54ceKM94 for ; Thu, 1 Jul 2010 11:47:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 240753A6A2F for ; Thu, 1 Jul 2010 11:47:29 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id o61IlfT5001176 for ; Thu, 1 Jul 2010 11:47:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278010061; bh=vgtLduZ/+R13lR9/zxGshvByXc8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=MatK9lUbUF04HzQQTw/MVYJ8fZlXWQXNcVaZottLZ4K34wsMSSahULFEARGDCNFYT 2rTLXsYSqGlhqUH7BXq9Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=MtSM1yPPwsZjyJESR4k4gsghW2IsBR2NkcSwVuz6u+ULiq8VuqGknu9EfawfF5ZCv eKJz3PX/a0Vmo8bJd73Sg== Received: from gyf3 (gyf3.prod.google.com [10.243.50.67]) by hpaq11.eem.corp.google.com with ESMTP id o61IldtF011485 for ; Thu, 1 Jul 2010 11:47:40 -0700 Received: by gyf3 with SMTP id 3so1886876gyf.27 for ; Thu, 01 Jul 2010 11:47:39 -0700 (PDT) Received: by 10.101.170.33 with SMTP id x33mr13272149ano.265.1278010059405; Thu, 01 Jul 2010 11:47:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Thu, 1 Jul 2010 11:47:19 -0700 (PDT) In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B694F@SNV-EXVS08.ds.corp.yahoo.com> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B694F@SNV-EXVS08.ds.corp.yahoo.com> From: Marius Scurtescu Date: Thu, 1 Jul 2010 11:47:19 -0700 Message-ID: To: William Mills Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:47:31 -0000 On Thu, Jul 1, 2010 at 11:42 AM, William Mills wrote: > > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Thursday, July 01, 2010 11:36 AM >> To: Eran Hammer-Lahav >> Cc: William Mills; Rob Richards; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Versioning >> >> On Thu, Jul 1, 2010 at 11:24 AM, Eran Hammer-Lahav >> wrote: >> > >> > If you would like to discuss a version for the header, >> please provide examples and requirements for what changes in >> the future you would like to support. >> >> Not sure about the future, but looking at OAuth 1 vs OAuth 2. >> A protected resource request filter may want to decide early >> what protocol it deals with so it can call the appropriate >> handler, or to enforce HTTPS for OAuth 2 for example. Sure, >> it can apply heuristics right now, but it would be nice to >> have a more deterministic way which can also be extended in >> the future. You can always embed the protocol version inside >> the token I guess, so I don't think this is a huge issue. > > Yeah, unfortunately early selection of a handler might require peeking into the post body. Is anybody really using or needing this feature? Can we drop this option? Marius From wmills@yahoo-inc.com Thu Jul 1 11:48: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 EA03228C120 for ; Thu, 1 Jul 2010 11:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.81 X-Spam-Level: X-Spam-Status: No, score=-16.81 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_55=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbpS0FTWz8+v for ; Thu, 1 Jul 2010 11:47:59 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 60CE828C122 for ; Thu, 1 Jul 2010 11:47:59 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o61IkqY0082349; Thu, 1 Jul 2010 11:46:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:x-originalarrivaltime; b=hnetA0d+1Hnnx3XQe3c2/qKI95kCfwFw9M02zHVEe2KqlzBT7Y8j3gzNb8V0gB51 Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 11:46:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jul 2010 11:46:16 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6953@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C481@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZSzjT2XuJsjIFRJKTa1PyFud/4wAAcgWAAAAYZgA= References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B6946@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C470@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C481@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" To: "Eran Hammer-Lahav" , "Marius Scurtescu" X-OriginalArrivalTime: 01 Jul 2010 18:46:52.0580 (UTC) FILETIME=[C56FB640:01CB194D] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:48:01 -0000 Perhaps it's enough if in the spec we make clear that we are also = defining a scheme usable for other things. I don't think that's quite = spelled out. Then other specs just refer to the specific section like = we're pulling in the WWW-Authenticate part from another spec.=20 > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 > Sent: Thursday, July 01, 2010 11:42 AM > To: Marius Scurtescu > Cc: William Mills; Rob Richards; oauth@ietf.org > Subject: RE: [OAUTH-WG] Versioning >=20 > It was and this approach was rejected by this group as=20 > confusing. At this point, it's specification is so short, it=20 > can live anywhere. >=20 > EHL >=20 > > -----Original Message----- > > From: Marius Scurtescu [mailto:mscurtescu@google.com] > > Sent: Thursday, July 01, 2010 11:28 AM > > To: Eran Hammer-Lahav > > Cc: William Mills; Rob Richards; oauth@ietf.org > > Subject: Re: [OAUTH-WG] Versioning > >=20 > > On Thu, Jul 1, 2010 at 11:19 AM, Eran Hammer-Lahav=20 > > wrote: > > > I think HTTP authentication schemes should be generally=20 > useful. In=20 > > > this > > case, OAuth defines a few ways to obtain an token, and a=20 > few ways to=20 > > use a token with HTTP resources. What it doesn't do is say anything=20 > > useful about the token itself, or implies that the tokens=20 > are "OAuth=20 > > tokens" (i.e. that the nature of the token is bound to the=20 > OAuth protocol). > > > > > > I can envision use cases where someone wants to use=20 > existing tokens > > (obtained via other means than those provided by OAuth) to access=20 > > protected resources. What about using a token as currently=20 > defined is=20 > > OAuth-specific? > > > > > > In other words, the scheme name is generic because OAuth=20 > tokens are > > generic and for the most part left undefined. Naming the=20 > scheme OAuth=20 > > implies that there is a link between the token properties=20 > and how they=20 > > are obtained, and the current protocol does not specify any=20 > such link.=20 > > The same applies to using HTTP Basic for client=20 > credentials, not to log-in an end-user. > >=20 > > Sure, but then I think the "Token" scheme needs its own standalone=20 > > spec and not be defined as part of the OAuth 2 spec. > >=20 > > Marius > >=20 > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: William Mills [mailto:wmills@yahoo-inc.com] > > >> Sent: Thursday, July 01, 2010 11:08 AM > > >> To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > > >> Subject: RE: [OAUTH-WG] Versioning > > >> > > >> Why is using the string "Token" better than "OAuth2"? =A0 > 1.0 used "Oauth". > > >> > > >> > > >> If it's purely a question of aesthetics, I prefer=20 > "Oauth_2" to "Token" > > >> because I feel it's clearer and more descriptive. > > >> > > >> > -----Original Message----- > > >> > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > > >> > Sent: Thursday, July 01, 2010 11:00 AM > > >> > To: William Mills; Rob Richards; oauth@ietf.org > > >> > Subject: RE: [OAUTH-WG] Versioning > > >> > > > >> > Why is a version better than a new scheme name?=20 > Version is only=20 > > >> > helpful when the protocol is practically the same with=20 > some minor=20 > > >> > changes, and if that is the case, extensibility alone=20 > should be=20 > > >> > enough. > > >> > > > >> > EHL > > >> > > > >> > > -----Original Message----- > > >> > > From: William Mills [mailto:wmills@yahoo-inc.com] > > >> > > Sent: Thursday, July 01, 2010 10:49 AM > > >> > > To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > > >> > > Subject: RE: [OAUTH-WG] Versioning > > >> > > > > >> > > My feeling on this is that versioning explicitly in the > > >> > protocol adds > > >> > > clarity and some small level of compatibility. =A0 > Different auth=20 > > >> > > and token endpoints are easy, what's harder is supporting=20 > > >> > > multiple protocols on the same protected resource. =A0 > It's on the=20 > > >> > > protected resource I'd like to see some clearer protocol=20 > > >> > > version spec > > >> > so I'm not > > >> > > having to figure out from the variable names which=20 > protocol it is. > > >> > > > > >> > > > -----Original Message----- > > >> > > > From: oauth-bounces@ietf.org=20 > [mailto:oauth-bounces@ietf.org]=20 > > >> > > > On Behalf Of Eran Hammer-Lahav > > >> > > > Sent: Thursday, July 01, 2010 9:36 AM > > >> > > > To: Rob Richards; OAuth WG (oauth@ietf.org) > > >> > > > Subject: Re: [OAUTH-WG] Versioning > > >> > > > > > >> > > > Hi Rob, > > >> > > > > > >> > > > > -----Original Message----- > > >> > > > > From: Rob Richards [mailto:rrichards@cdatazone.org] > > >> > > > > Sent: Thursday, July 01, 2010 3:26 AM > > >> > > > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > > >> > > > > Subject: Versioning > > >> > > > > > > >> > > > > Versioning is still something that needs to be addressed > > >> > > > before being > > >> > > > > being able to consider the draft core complete. > > >> > > > > > >> > > > Versioning rarely works because when you define it, you > > >> > have no idea > > >> > > > what the requirements will be for the next version. A > > >> > good example > > >> > > > is the OAuth 1.0 version parameter. When we worked=20 > to revised=20 > > >> > > > 1.0 into 1.0a, we had a long debate on changing=20 > the protocol=20 > > >> > > > version number. We had a hard time agreeing on what the=20 > > >> > > > version meant and what was it a version > > >> > > > *of*: the signature method or the token flow. > > >> > > > > > >> > > > If this protocol will require significant changes in the > > >> > future that > > >> > > > go beyond its extensibility support, such a new version > > >> > will need to > > >> > > > use different endpoints (token or end-user authorization)=20 > > >> > > > and/or different HTTP authentication scheme. > > >> > > > > > >> > > > If you want to discuss versioning, you must provide your=20 > > >> > > > requirements for such a feature, and clearly show how > > >> > they are not > > >> > > > served by the current extensibility proposal. > > >> > > > > > >> > > > > On this I'm still of the opinion that at the very > > >> > minimum you will > > >> > > > > need to require an oauth_version parameter for=20 > the resource > > >> > > > endpoints, > > >> > > > > if not also for the others as well. > > >> > > > > > >> > > > I think the difficulty of differentiating a 1.0 from a > > >> > 2.0 protected > > >> > > > resource request is exaggerated. As said before,=20 > you can tell=20 > > >> > > > the difference based on the presence of other parameter=20 > > >> > > > (oauth_signature_method), or by examining the=20 > provided token=20 > > >> > > > (assuming you issue different tokens for each version). > > >> > The argument > > >> > > > that a 2.0 request can also be a malformed 1.0 request is > > >> > silly. I > > >> > > > have yet to hear about that level of incompetence=20 > for a 1.0=20 > > >> > > > developer (and I've heard about a lot) - omitting every > > >> > other required parameter. > > >> > > > > > >> > > > At most, I'm open to renaming the oauth_token parameter > > >> > to something > > >> > > > else (oauth_access_token, oauth.token, oauth-token, > > >> > > > etc.) but I think even that is not needed. > > >> > > > > > >> > > > 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 > > > >=20 From jricher@mitre.org Thu Jul 1 11:49:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24BB28C120 for ; Thu, 1 Jul 2010 11:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.567 X-Spam-Level: X-Spam-Status: No, score=-5.567 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, 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 p1qQcA3Qscw2 for ; Thu, 1 Jul 2010 11:49:26 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id A611028C123 for ; Thu, 1 Jul 2010 11:49:26 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o61InbV9026166 for ; Thu, 1 Jul 2010 14:49:38 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o61Inbbj026163; Thu, 1 Jul 2010 14:49:37 -0400 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, 1 Jul 2010 14:49:37 -0400 From: Justin Richer To: William Mills In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B694C@SNV-EXVS08.ds.corp.yahoo.com> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B694C@SNV-EXVS08.ds.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 1 Jul 2010 14:49:36 -0400 Message-ID: <1278010176.28743.216.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:49:28 -0000 An easy fix here is to use oauth2_token instead of oauth_token here, since that's the only place we seem to be using the oauth_ namespace now. Makes figuring out the two completely deterministic since it's a different parameter name when passed as a GET or POST variable, and a different header name when passed as a header (using the current Token scheme or an OAuth2 scheme or whatever). -- Justin On Thu, 2010-07-01 at 14:25 -0400, William Mills wrote: > +1 on this. Makes life interesting on the PR. > > > When tokens are passed in the query string there is no scheme. > > > -----Original Message----- > > From: Marius Scurtescu [mailto:mscurtescu@google.com] > > Sent: Thursday, July 01, 2010 11:16 AM > > To: Eran Hammer-Lahav > > Cc: William Mills; Rob Richards; oauth@ietf.org > > Subject: Re: [OAUTH-WG] Versioning > > > > On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav > > wrote: > > > Why is a version better than a new scheme name? > > > > Sure, but then make the scheme more specific. What will the > > scheme name be for OAuth 3? > > > > When tokens are passed in the query string there is no scheme. > > > > Marius > > > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: William Mills [mailto:wmills@yahoo-inc.com] > > >> Sent: Thursday, July 01, 2010 10:49 AM > > >> To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > > >> Subject: RE: [OAUTH-WG] Versioning > > >> > > >> My feeling on this is that versioning explicitly in the > > protocol adds > > >> clarity and some small level of compatibility. Different auth and > > >> token endpoints are easy, what's harder is supporting multiple > > >> protocols on the same protected resource. It's on the protected > > >> resource I'd like to see some clearer protocol version spec so I'm > > >> not having to figure out from the variable names which > > protocol it is. > > >> > > >> > -----Original Message----- > > >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > >> > Behalf Of Eran Hammer-Lahav > > >> > Sent: Thursday, July 01, 2010 9:36 AM > > >> > To: Rob Richards; OAuth WG (oauth@ietf.org) > > >> > Subject: Re: [OAUTH-WG] Versioning > > >> > > > >> > Hi Rob, > > >> > > > >> > > -----Original Message----- > > >> > > From: Rob Richards [mailto:rrichards@cdatazone.org] > > >> > > Sent: Thursday, July 01, 2010 3:26 AM > > >> > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > > >> > > Subject: Versioning > > >> > > > > >> > > Versioning is still something that needs to be addressed > > >> > before being > > >> > > being able to consider the draft core complete. > > >> > > > >> > Versioning rarely works because when you define it, you have no > > >> > idea what the requirements will be for the next version. A good > > >> > example is the OAuth 1.0 version parameter. When we worked to > > >> > revised 1.0 into 1.0a, we had a long debate on changing the > > >> > protocol version number. We had a hard time agreeing on what the > > >> > version meant and what was it a version > > >> > *of*: the signature method or the token flow. > > >> > > > >> > If this protocol will require significant changes in the future > > >> > that go beyond its extensibility support, such a new > > version will > > >> > need to use different endpoints (token or end-user > > authorization) > > >> > and/or different HTTP authentication scheme. > > >> > > > >> > If you want to discuss versioning, you must provide your > > >> > requirements for such a feature, and clearly show how > > they are not > > >> > served by the current extensibility proposal. > > >> > > > >> > > On this I'm still of the opinion that at the very minimum you > > >> > > will need to require an oauth_version parameter for > > the resource > > >> > endpoints, > > >> > > if not also for the others as well. > > >> > > > >> > I think the difficulty of differentiating a 1.0 from a 2.0 > > >> > protected resource request is exaggerated. As said > > before, you can > > >> > tell the difference based on the presence of other parameter > > >> > (oauth_signature_method), or by examining the provided token > > >> > (assuming you issue different tokens for each version). The > > >> > argument that a 2.0 request can also be a malformed 1.0 > > request is > > >> > silly. I have yet to hear about that level of incompetence for a > > >> > 1.0 developer (and I've heard about a lot) - omitting > > every other required parameter. > > >> > > > >> > At most, I'm open to renaming the oauth_token parameter to > > >> > something else (oauth_access_token, oauth.token, oauth-token, > > >> > etc.) but I think even that is not needed. > > >> > > > >> > 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 > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Thu Jul 1 12:07: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 EFF9B28C0ED for ; Thu, 1 Jul 2010 12:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.89 X-Spam-Level: X-Spam-Status: No, score=-5.89 tagged_above=-999 required=5 tests=[AWL=0.709, 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 FmsrXaGw3jMN for ; Thu, 1 Jul 2010 12:07:05 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id E593B3A6A1A for ; Thu, 1 Jul 2010 12:07:04 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o61J7GR9013401 for ; Thu, 1 Jul 2010 15:07:16 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o61J7GJu013395; Thu, 1 Jul 2010 15:07:16 -0400 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, 1 Jul 2010 15:07:16 -0400 From: Justin Richer To: Marius Scurtescu In-Reply-To: References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B694F@SNV-EXVS08.ds.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 1 Jul 2010 15:07:15 -0400 Message-ID: <1278011235.28743.223.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 19:07:06 -0000 OAuth tokens as a form-encoded element in a post body? Yes. Keep it. -- Justin On Thu, 2010-07-01 at 14:47 -0400, Marius Scurtescu wrote: > On Thu, Jul 1, 2010 at 11:42 AM, William Mills wrote: > > > > > >> -----Original Message----- > >> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >> Sent: Thursday, July 01, 2010 11:36 AM > >> To: Eran Hammer-Lahav > >> Cc: William Mills; Rob Richards; oauth@ietf.org > >> Subject: Re: [OAUTH-WG] Versioning > >> > >> On Thu, Jul 1, 2010 at 11:24 AM, Eran Hammer-Lahav > >> wrote: > >> > > >> > If you would like to discuss a version for the header, > >> please provide examples and requirements for what changes in > >> the future you would like to support. > >> > >> Not sure about the future, but looking at OAuth 1 vs OAuth 2. > >> A protected resource request filter may want to decide early > >> what protocol it deals with so it can call the appropriate > >> handler, or to enforce HTTPS for OAuth 2 for example. Sure, > >> it can apply heuristics right now, but it would be nice to > >> have a more deterministic way which can also be extended in > >> the future. You can always embed the protocol version inside > >> the token I guess, so I don't think this is a huge issue. > > > > Yeah, unfortunately early selection of a handler might require peeking into the post body. > > Is anybody really using or needing this feature? Can we drop this option? > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Thu Jul 1 12:26: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 795093A6A3B for ; Thu, 1 Jul 2010 12:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.566 X-Spam-Level: X-Spam-Status: No, score=-101.566 tagged_above=-999 required=5 tests=[AWL=0.411, 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 1jndNhxKasEx for ; Thu, 1 Jul 2010 12:26:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7C0383A6A25 for ; Thu, 1 Jul 2010 12:26:05 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o61JQFdH020899 for ; Thu, 1 Jul 2010 12:26:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278012376; bh=xSOB3aSa92qMpd/j5eY50yEfAds=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=oTpC+E63GYNNNBG1cGGgLuTGyYFSS/zRm5jh/8CDHbkQHSkzYWRVmMeH2n2Y7qf+0 ae9fz1WYUpbNDxcf+XvTw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=rOaPesQKJqw/pt3heiy6b7vBKmt8/h8Ao8UiY8+ywCGiY6V7Iam9er5b6YUn5Ik6V ng5iSAyBoSXvICSlxl4VQ== Received: from gyg4 (gyg4.prod.google.com [10.243.50.132]) by kpbe20.cbf.corp.google.com with ESMTP id o61JPuDb022858 for ; Thu, 1 Jul 2010 12:26:14 -0700 Received: by gyg4 with SMTP id 4so1631518gyg.12 for ; Thu, 01 Jul 2010 12:26:14 -0700 (PDT) Received: by 10.101.145.16 with SMTP id x16mr13257079ann.226.1278012374257; Thu, 01 Jul 2010 12:26:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Thu, 1 Jul 2010 12:25:54 -0700 (PDT) In-Reply-To: <1278011235.28743.223.camel@localhost.localdomain> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B694F@SNV-EXVS08.ds.corp.yahoo.com> <1278011235.28743.223.camel@localhost.localdomain> From: Marius Scurtescu Date: Thu, 1 Jul 2010 12:25:54 -0700 Message-ID: To: Justin Richer Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 19:26:10 -0000 On Thu, Jul 1, 2010 at 12:07 PM, Justin Richer wrote: > OAuth tokens as a form-encoded element in a post body? Yes. Keep it. Just curious. What use case would require that the access token is put in the post body as opposed to an http header when accessing a protected resource? Marius From rrichards@cdatazone.org Thu Jul 1 12:28: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 A80D03A6A3B for ; Thu, 1 Jul 2010 12:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, J_CHICKENPOX_55=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 KrR3JowVuxHr for ; Thu, 1 Jul 2010 12:28:46 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by core3.amsl.com (Postfix) with ESMTP id 8401A3A67F5 for ; Thu, 1 Jul 2010 12:28:46 -0700 (PDT) Received: from [67.158.171.203] (helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1OUPRN-0002l6-I4; Thu, 01 Jul 2010 19:28:53 +0000 Message-ID: <4C2CEC74.7040005@cdatazone.org> Date: Thu, 01 Jul 2010 15:28:52 -0400 From: Rob Richards User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Justin Richer References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B694C@SNV-EXVS08.ds.corp.yahoo.com> <1278010176.28743.216.camel@localhost.localdomain> In-Reply-To: <1278010176.28743.216.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP2Go-MailScanner-Information: Please contact support@smtp2go.com for more information X-SMTP2Go-MailScanner-ID: 1OUPRN-0002l6-I4 X-SMTP2Go-MailScanner: Found to be clean X-SMTP2Go-MailScanner-From: rrichards@cdatazone.org Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 19:28:47 -0000 With this the spec needs to including some wording to explicitly define how to handle the case when running an endpoint supporting both OAuth 1.0 and 2.0 and the oauth2_token is missing then the call is handled according to the OAuth 1.0/a spec. Whatever is decided, be it a version parameter, the use of oauth2_token or the check for the existence of the oauth_signature_method parameter, etc///, the spec needs to define and be explicit on how a resource endpoint determines between a 1.0 and 2.0 call when both are supported. Rob Justin Richer wrote: > An easy fix here is to use oauth2_token instead of oauth_token here, > since that's the only place we seem to be using the oauth_ namespace > now. Makes figuring out the two completely deterministic since it's a > different parameter name when passed as a GET or POST variable, and a > different header name when passed as a header (using the current Token > scheme or an OAuth2 scheme or whatever). > > -- Justin > > On Thu, 2010-07-01 at 14:25 -0400, William Mills wrote: > >> +1 on this. Makes life interesting on the PR. >> >> >>> When tokens are passed in the query string there is no scheme. >>> >>> -----Original Message----- >>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>> Sent: Thursday, July 01, 2010 11:16 AM >>> To: Eran Hammer-Lahav >>> Cc: William Mills; Rob Richards; oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Versioning >>> >>> On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav >>> wrote: >>> >>>> Why is a version better than a new scheme name? >>>> >>> Sure, but then make the scheme more specific. What will the >>> scheme name be for OAuth 3? >>> >>> When tokens are passed in the query string there is no scheme. >>> >>> Marius >>> >>> >>>> EHL >>>> >>>> >>>>> -----Original Message----- >>>>> From: William Mills [mailto:wmills@yahoo-inc.com] >>>>> Sent: Thursday, July 01, 2010 10:49 AM >>>>> To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org >>>>> Subject: RE: [OAUTH-WG] Versioning >>>>> >>>>> My feeling on this is that versioning explicitly in the >>>>> >>> protocol adds >>> >>>>> clarity and some small level of compatibility. Different auth and >>>>> token endpoints are easy, what's harder is supporting multiple >>>>> protocols on the same protected resource. It's on the protected >>>>> resource I'd like to see some clearer protocol version spec so I'm >>>>> not having to figure out from the variable names which >>>>> >>> protocol it is. >>> >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>> Behalf Of Eran Hammer-Lahav >>>>>> Sent: Thursday, July 01, 2010 9:36 AM >>>>>> To: Rob Richards; OAuth WG (oauth@ietf.org) >>>>>> Subject: Re: [OAUTH-WG] Versioning >>>>>> >>>>>> Hi Rob, >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rob Richards [mailto:rrichards@cdatazone.org] >>>>>>> Sent: Thursday, July 01, 2010 3:26 AM >>>>>>> To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav >>>>>>> Subject: Versioning >>>>>>> >>>>>>> Versioning is still something that needs to be addressed >>>>>>> >>>>>> before being >>>>>> >>>>>>> being able to consider the draft core complete. >>>>>>> >>>>>> Versioning rarely works because when you define it, you have no >>>>>> idea what the requirements will be for the next version. A good >>>>>> example is the OAuth 1.0 version parameter. When we worked to >>>>>> revised 1.0 into 1.0a, we had a long debate on changing the >>>>>> protocol version number. We had a hard time agreeing on what the >>>>>> version meant and what was it a version >>>>>> *of*: the signature method or the token flow. >>>>>> >>>>>> If this protocol will require significant changes in the future >>>>>> that go beyond its extensibility support, such a new >>>>>> >>> version will >>> >>>>>> need to use different endpoints (token or end-user >>>>>> >>> authorization) >>> >>>>>> and/or different HTTP authentication scheme. >>>>>> >>>>>> If you want to discuss versioning, you must provide your >>>>>> requirements for such a feature, and clearly show how >>>>>> >>> they are not >>> >>>>>> served by the current extensibility proposal. >>>>>> >>>>>> >>>>>>> On this I'm still of the opinion that at the very minimum you >>>>>>> will need to require an oauth_version parameter for >>>>>>> >>> the resource >>> >>>>>> endpoints, >>>>>> >>>>>>> if not also for the others as well. >>>>>>> >>>>>> I think the difficulty of differentiating a 1.0 from a 2.0 >>>>>> protected resource request is exaggerated. As said >>>>>> >>> before, you can >>> >>>>>> tell the difference based on the presence of other parameter >>>>>> (oauth_signature_method), or by examining the provided token >>>>>> (assuming you issue different tokens for each version). The >>>>>> argument that a 2.0 request can also be a malformed 1.0 >>>>>> >>> request is >>> >>>>>> silly. I have yet to hear about that level of incompetence for a >>>>>> 1.0 developer (and I've heard about a lot) - omitting >>>>>> >>> every other required parameter. >>> >>>>>> At most, I'm open to renaming the oauth_token parameter to >>>>>> something else (oauth_access_token, oauth.token, oauth-token, >>>>>> etc.) but I think even that is not needed. >>>>>> >>>>>> 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 >>>> >>>> >> _______________________________________________ >> 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 Thu Jul 1 12:38:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7123928C122 for ; Thu, 1 Jul 2010 12:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.925 X-Spam-Level: X-Spam-Status: No, score=-5.925 tagged_above=-999 required=5 tests=[AWL=0.674, 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 xIF4kfDvfq6V for ; Thu, 1 Jul 2010 12:38:40 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id DF55328C12C for ; Thu, 1 Jul 2010 12:38:39 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o61JcpVH011405 for ; Thu, 1 Jul 2010 15:38:51 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o61JcpG7011402; Thu, 1 Jul 2010 15:38:51 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Thu, 1 Jul 2010 15:38:50 -0400 From: Justin Richer To: Marius Scurtescu In-Reply-To: References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B694F@SNV-EXVS08.ds.corp.yahoo.com> <1278011235.28743.223.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Thu, 1 Jul 2010 15:38:50 -0400 Message-ID: <1278013130.28743.229.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 19:38:41 -0000 > > OAuth tokens as a form-encoded element in a post body? Yes. Keep it. > > Just curious. What use case would require that the access token is put > in the post body as opposed to an http header when accessing a > protected resource? If nothing else, it parallels the use case of a GET-style query parameter. It makes sense to have it be valid in both ways to allow developers to put the token in with whatever other parameters they're passing along. I've got plenty of use cases here for the query parameters: it's needed for cases where your client can't get any deeper into HTTP than "hey go fetch me this URL". What use case says we shouldn't do POST parameters like that? A server wanting to do early-dispatch of a request was brought up, but that was only in the case of handling OAuth 1 and 2 simultaneously as I understood it. If a server's going to be doing dispatch on auth headers and query parameters already, it seems that it's got the wherewithal to parse a form-encoded body, too. -- Justin From mscurtescu@google.com Thu Jul 1 12:47: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 108B13A6784 for ; Thu, 1 Jul 2010 12:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.578 X-Spam-Level: X-Spam-Status: No, score=-101.578 tagged_above=-999 required=5 tests=[AWL=0.399, 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 zKtjfnQoFvpS for ; Thu, 1 Jul 2010 12:47:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id B142A3A6A25 for ; Thu, 1 Jul 2010 12:47:55 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o61Jm6eo007658 for ; Thu, 1 Jul 2010 12:48:06 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278013686; bh=shSYjakyt8oeFI/TL+yPMlnUu+M=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=K6TxEzKScGwpUUh7kyVhLRPyzcAYIqAVmXk6CE/0hTlpggKGOPaYugPz9FyxjQulB t03bf7tVViecQTkA7Ea8g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=Wef1GkGoasLRyn5krMqB4Zx8Vnlat7OsCMlrekfZ0MQy8jMSnRuhdsprVcp7oHCQW nOA/9QsdoQx6BiE+9Lkdg== Received: from gyh3 (gyh3.prod.google.com [10.243.50.195]) by hpaq13.eem.corp.google.com with ESMTP id o61JlE9r017586 for ; Thu, 1 Jul 2010 12:48:05 -0700 Received: by gyh3 with SMTP id 3so1391644gyh.31 for ; Thu, 01 Jul 2010 12:48:05 -0700 (PDT) Received: by 10.100.122.10 with SMTP id u10mr307anc.21.1278013681578; Thu, 01 Jul 2010 12:48:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Thu, 1 Jul 2010 12:47:41 -0700 (PDT) In-Reply-To: <1278013130.28743.229.camel@localhost.localdomain> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B694F@SNV-EXVS08.ds.corp.yahoo.com> <1278011235.28743.223.camel@localhost.localdomain> <1278013130.28743.229.camel@localhost.localdomain> From: Marius Scurtescu Date: Thu, 1 Jul 2010 12:47:41 -0700 Message-ID: To: Justin Richer Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 19:47:57 -0000 On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer wrote: >> > OAuth tokens as a form-encoded element in a post body? Yes. Keep it. >> >> Just curious. What use case would require that the access token is put >> in the post body as opposed to an http header when accessing a >> protected resource? > > If nothing else, it parallels the use case of a GET-style query > parameter. It makes sense to have it be valid in both ways to allow > developers to put the token in with whatever other parameters they're > passing along. I've got plenty of use cases here for the query > parameters: it's needed for cases where your client can't get any deeper > into HTTP than "hey go fetch me this URL". You can still use query parameters with POST. > What use case says we shouldn't do POST parameters like that? A server > wanting to do early-dispatch of a request was brought up, but that was > only in the case of handling OAuth 1 and 2 simultaneously as I > understood it. If a server's going to be doing dispatch on auth headers > and query parameters already, it seems that it's got the wherewithal to > parse a form-encoded body, too. Parsing the body is not trivial. Some filters do not have access to it (apache mod_redirect for example), some frameworks will allow you to access it once and then commit to a format, a decision that cannot be made by a filter (in Java see ServletRequest: getInputStream vs getReader vs getParameter). Marius From mscurtescu@google.com Thu Jul 1 12:52:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045F03A6359 for ; Thu, 1 Jul 2010 12:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.494 X-Spam-Level: X-Spam-Status: No, score=-105.494 tagged_above=-999 required=5 tests=[AWL=0.483, 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 7+L8VktTm1D5 for ; Thu, 1 Jul 2010 12:51:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 56A143A67ED for ; Thu, 1 Jul 2010 12:51:53 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o61Jq4NH016915 for ; Thu, 1 Jul 2010 12:52:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278013924; bh=7jTs8me1IkiO6pSi1XVKTMMTIn4=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=GgSeMIw9lf115Zz9I/uWppH0FyS5KHST2leYwSPPHsVGKdhcuYN2yhOsr/5Fkworm Tv8OsjoVMa2ZXh/tdm5JQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:content-type:x-system-of-record; b=CcJTEMbZ+YlIe0Q4oR6V03uF+RmgBnpBHuq93rsEXeyOrQlpV+bZH8HD2Gfp5TTsd fh+dUdI7SfeP+0hTslmxA== Received: from gwb17 (gwb17.prod.google.com [10.200.2.17]) by kpbe20.cbf.corp.google.com with ESMTP id o61Jpwfs013921 for ; Thu, 1 Jul 2010 12:52:03 -0700 Received: by gwb17 with SMTP id 17so2200437gwb.11 for ; Thu, 01 Jul 2010 12:52:03 -0700 (PDT) Received: by 10.100.165.18 with SMTP id n18mr13312626ane.246.1278013923213; Thu, 01 Jul 2010 12:52:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Thu, 1 Jul 2010 12:51:43 -0700 (PDT) From: Marius Scurtescu Date: Thu, 1 Jul 2010 12:51:43 -0700 Message-ID: To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 19:52:01 -0000 For section 6.2, and possibly 6.3, I would suggest to register a prefix for all the parameters defined by an extension. Pros: 1. Simpler registration, only one element needs to be registered, the prefix, and not every single parameter name. Once an extension has a prefix registered it can evolve and change the parameters it is using much easier. 2. Greatly reduce the chances of a conflict with a query parameter used by an authz server endpoint or client redirect_uri. 3. Consistent with the generic vendor specific extension space ("x_"). 4. Allows strict validation of OAuth parameters. Unknown extensions will be ignored, but the known ones can be strictly validated. 5. Easy to determine what parameter is core and what is part of an extension. Cons: 1. Slightly longer parameter names. Underscore or dot could be used to separate the prefix from the name. Marius From naitiks@gmail.com Thu Jul 1 13:01: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 696493A6782 for ; Thu, 1 Jul 2010 13:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.310, 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 8JT9tfFOE4Xw for ; Thu, 1 Jul 2010 13:01:11 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4C3833A6A5A for ; Thu, 1 Jul 2010 13:00:41 -0700 (PDT) Received: by iwn10 with SMTP id 10so6368iwn.31 for ; Thu, 01 Jul 2010 13:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=1yTOHoN5iW27K6EpNcYWGxBMkFodH1i43ZgxxUxp4qI=; b=Pp3Bchm2uxfCBB8HqSnf2cqMk5kUruPvtP5pCI+GRL1Q1tT32N1BhIepucPoSXeJl5 Mbf8rbTjuQT7olWFTKahGcQ6shNSAD3NHyY5jKboMXBCvnT1Ys8Ijnd3juTjG0jEcft4 9nW+auWn4miwY0oV8/ioYioxqiEOBg0Bv+75U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=FjwCzGQz7MUM57s6/YsL5BoFOtisZ9iYP+qhaa7saEwNKqUOauT/4av7zFLsb/iz7V 2xdj0/Gwfyi3uZDmeMNK78LddwV/78JfTAu4vn0lqZ6nxrANx7bVRIYTCVFn1N9tke40 Tcs8ZBCmKM5ywfuuQ4Eqd2OXaCgCJOl0iiGA4= Received: by 10.231.35.10 with SMTP id n10mr8488390ibd.161.1278013970284; Thu, 01 Jul 2010 12:52:50 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.231.170.9 with HTTP; Thu, 1 Jul 2010 12:52:30 -0700 (PDT) In-Reply-To: <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> References: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> From: Naitik Shah Date: Thu, 1 Jul 2010 12:52:30 -0700 X-Google-Sender-Auth: G01IA7qZSxA4x3H75SsRNGoY6mk Message-ID: To: Dick Hardt Content-Type: multipart/alternative; boundary=0022150482dfb79902048a58d026 Cc: OAuth WG Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 20:01:13 -0000 --0022150482dfb79902048a58d026 Content-Type: text/plain; charset=UTF-8 Searching for base64url does make it better. Thanks for that pointer Dick. We don't think base64url will work, because the most common error we'll see is that developers forget the "url" part and just do plain base64, and that's not sufficient because the stock set includes +. So it will maybe work, maybe not. Maybe they'll do urlencoding after anyways, since if they are passing this as a query param, or post data, client libraries will take a dict and try to "do the right thing". And we end up with pluses, and we're not quite sure if they should be urldecoded or not. For example, this doesn't give me back what I put in: base64_decode(urldecode(base64_encode('-+>'))) Because the base64_encode returns something containing a +, and the usual urldecode logic will convert this into a space. In fact, looking at the PHP docs for base64 decode, there are a bunch of comments talking about pluses: http://php.net/manual/en/function.base64-decode.php. The approach I'm thinking is something like: function getSignedToken($params, $secret) { $json = json_encode($params); // Moving the signature to be before the payload makes the separator/split // logic be: "everything before the first dot is the sig". also, it's hex. return hash_hmac('sha256', $json, $secret) . '.' . $json; } function parseSignedToken($token, $secret) { list($sig, $json) = explode('.', $token, $limit=2); if (hash_hmac('sha256', $json, $secret) !== $sig) { throw new Exception('Bad Sig'); } return json_decode($json); } [UNTESTED!] Where url encoding and decoding happens outside of the signature process. I'm not convinced adding the request as a header is going to be used often. Headers are always sent uncompressed. I imagine signatures to be used for those that are perf sensitive and don't want the SSL overhead. So this minor detail will matter to them. This is especially true because unlike OAuth1, the header doesn't just contain a signature, but contains the entire signed payload. But there's nothing stopping us from using the same format above for sending the payload as a header. One of the arguments was wrt detecting double url encoding. Since the thing we're signing is a JSON object, we always know it will start with %7B and if it's double encoded, it will be %257B. -Naitik On Fri, Jun 25, 2010 at 5:21 PM, Dick Hardt wrote: > The RFC term is base64url which turns up much better results when > searching. "URL safe base64" is also a good search term. > > Note that the token may also be included in the HTTP header. base64url > encoding works well for HTTP headers. Note that the token is opaque to the > client, so being plain text is not as useful as it may seem. Unlike URL > encoding, it is pretty easy to see if a string is base64url or not. With URL > encoding, it may or may not be encoded which sometimes leads to double > encoding / mismatched encoding. > > -- Dick > > On 2010-06-25, at 4:42 PM, Naitik Shah wrote: > > So my litmus test was looking on the web for "web base 64" or "web base64". > Both yield nothing useful. Looking at the docs for PHP, it doesn't seem to > support it, Python does, Ruby doesn't seem to. Java doesn't seem to have a > native base64, and the C# one doesn't seem to have the web version (a bit > unsure about these two). The point I'm trying to make is to someone who > comes and reads the docs for an API where we're talking about signature, web > base64 will need to be explained in detail. > > I agree eliminating encoding problems is a good goal. But if we do have to > teach the developer a new, or slightly modified encoding scheme, why not > have it be URL encoding? It seems more valuable in the long term, since it's > a spec that shows up more frequently on the web. And OAuth 1 has already > taught this spec to at least some of the target audience. > > While encoding/decoding with any format will result in some learning, I > think if we sign a JSON blob sans urlencoding or web-base64, it might work > out to be easier. The fact that it's still mostly plain text is also a plus > imho. > > > -Naitik > > > On Fri, Jun 25, 2010 at 1:36 PM, John Panzer wrote: > >> There are 2 characters that are different between base64 and base64url. >> Many good libraries support both (as they're both useful, and both are in >> the base64 RFC spec); the ability to eliminate a class of encoding problems >> seems like a good trade-off for, in some languages without full base64 >> support, an additional substitution of 2 characters. >> >> -- >> John Panzer / Google >> jpanzer@google.com / abstractioneer.org / @jpanzer >> >> >> >> On Fri, Jun 25, 2010 at 12:15 PM, Naitik Shah wrote: >> >>> On Fri, Jun 25, 2010 at 11:39 AM, Breno wrote: >>> >>>> On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard >>>> wrote: >>>> > Brian, Dirk - just wondering if you had thoughts here? >>>> > >>>> > The only strong reason I can think of for base64 encoding is that it >>>> allows for a delimiter between the body and the signature. Is there any >>>> other reason? >>>> >>>> Without base64 encoding we have to define canonicalization procedures >>>> around spaces and we still have to URL encode separator characters >>>> such as {. There is also the risk that developers might be confused >>>> whether the URL encoding is to be performed before or after >>>> computation of the signature. If you say that the signature is >>>> computed on the base64 encoded blob, there's less scope for confusion >>>> and interoperability issues. >>>> >>>> >>> Yep, I get that the "web" version makes the url encoding a no op. But I >>> fear we're trading one spec (urlencoding) to another one (web base64). I'm >>> imagining the sample code (that does not rely on an SDK) we'ed give out to >>> developers in our docs, and the thing that stands out is the "web" part in >>> the web_base64. It means that our sample code will look like >>> >>> str_replace("+", "_", base64(json_encode(data)))) >>> >>> or for validating signatures: >>> >>> json_decode(decode64(str_replace("_", "+", data))) >>> >>> The str_replace() really stands out. From my quick read, it seemed like >>> there were one or two other characters that needed to get replaced too. >>> While some languages (like PHP) support arrays to specify multiple >>> replacement patterns, in other languages you'll end up with a few >>> str_replace calls. It would be nice if that wasn't necessary. >>> >>> I'm wondering if we can get away with "urlencode(json_encode(data) + '.' >>> + sig)" as the value. then, instead of str_replace for getting normal base64 >>> logic to work, we would instead need a rsplit or something, since the dot is >>> not a reserved character in the json blob. Was that approach considered? >>> >>> >>> -Naitik >>> >>> _______________________________________________ >>> 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 > > > --0022150482dfb79902048a58d026 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Searching for base64url does make it better. Thanks for that pointer Dick.<= div>
We don't think base64url will work, because the most= common error we'll see is that developers=C2=A0forget the "url&qu= ot; part and just do plain base64, and that's not sufficient because th= e stock set includes +.

So it will maybe work, maybe not. Maybe they'll do = urlencoding after anyways, since if they are passing this as a query param,= or post data, client libraries will take a dict and try to "do the ri= ght thing". And we end up with pluses, and we're not quite sure if= they should be urldecoded or not.

For example, this doesn't give me back what I put i= n:

=C2=A0=C2=A0base64_decode(urldecode(base64_enco= de('-+>')))

Because the base64_encode r= eturns something containing a +, and the usual urldecode logic will convert= this into a space.=C2=A0In fact, looking at the PHP docs for base64 decode= , there are a bunch of comments talking about pluses:=C2=A0http://ph= p.net/manual/en/function.base64-decode.php.

The approach I'm thinking is something like:
<= div>
=C2=A0=C2=A0function getSignedToken($params, $secre= t) {
=C2=A0=C2=A0 =C2=A0$json =3D json_encode($params);
=C2=A0=C2=A0 =C2=A0// Moving the signature to be before the payload m= akes the separator/split
=C2=A0=C2=A0 =C2=A0// logic be: "everything before the first dot = is the sig". also, it's hex.
=C2=A0=C2=A0 =C2=A0re= turn hash_hmac('sha256', $json, $secret) . '.' . $json;
=C2=A0=C2=A0}

=C2=A0=C2=A0function parseSigne= dToken($token, $secret) {
=C2=A0=C2=A0 =C2=A0list($sig, $json) = =3D explode('.', $token, $limit=3D2);
=C2=A0=C2=A0 =C2=A0= if (hash_hmac('sha256', $json, $secret) !=3D=3D $sig) {
=C2=A0=C2=A0 =C2=A0 =C2=A0throw new Exception('Bad Sig');
=C2=A0=C2=A0 =C2=A0}
=C2=A0=C2=A0 =C2=A0return json_decode(= $json);
=C2=A0=C2=A0}

[UNTESTED!] = Where url encoding and decoding happens outside of the signature process.

I'm not convinced adding the request as a header is= going to be used often. Headers are always sent uncompressed. I imagine si= gnatures to be used for those that are perf sensitive and don't want th= e SSL overhead. So this minor detail will matter to them. This is especiall= y true because unlike OAuth1, the header doesn't just contain a signatu= re, but contains the entire signed payload. But there's nothing stoppin= g us from using the same format above for sending the payload as a header.<= /div>

One of the arguments was wrt detecting double url encod= ing. Since the thing we're signing is a JSON object, we always know it = will start with %7B and if it's double encoded, it will be %257B.


-Naitik

On Fri, Jun 25, 2010 at 5:21 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:
The RFC = term is=C2=A0base64url which turns up much better results when searching. &= quot;URL safe base64" is also a good search term.

Note that the token may also be included in the HT= TP header. base64url encoding works well for HTTP headers. Note that the to= ken is opaque to the client, so being plain text is not as useful as it may= seem. Unlike URL encoding, it is pretty easy to see if a string is base64u= rl or not. With URL encoding, it may or may not be encoded which sometimes = leads to double encoding / mismatched encoding.

-- Dick

On 2010-06-25, at 4:42 = PM, Naitik Shah wrote:

So my litmus= test was looking on the web for "web base 64" or "web base6= 4". Both=C2=A0yield=C2=A0nothing useful. Looking at the docs for PHP, = it doesn't seem to support it, Python does, Ruby doesn't seem to. J= ava doesn't seem to have a native base64, and the C# one doesn't se= em to have the web version (a bit unsure about these two). The point I'= m trying to make is to someone who comes and reads the docs for an API wher= e we're talking about signature, web base64 will need to be explained i= n detail.

I agree eliminating encoding problems is a good goal. B= ut if we do have to teach the developer a new, or slightly modified encodin= g scheme, why not have it be URL encoding? It seems more valuable in the lo= ng term, since it's a spec that shows up more frequently on the web. An= d OAuth 1 has already taught this spec to at least some of the target audie= nce.

While encoding/decoding with any format will result in = some learning, I think if we sign a JSON blob sans urlencoding or web-base6= 4, it might work out to be easier. The fact that it's still mostly plai= n text is also a plus imho.


-Naitik


On Fri, Jun 25, 2010 at 1:36 PM, John Panzer <jpanzer@google.com&g= t; wrote:
There are 2 chara= cters that are different between base64 and base64url. =C2=A0Many good libr= aries support both (as they're both useful, and both are in the base64 = RFC spec); the ability to eliminate a class of encoding problems seems like= a good trade-off for, in some languages without full base64 support, an ad= ditional substitution of 2 characters.

--
John Panze= r / Google
jpanz= er@google.com / abstractioneer.org / @jpanzer



On Fri, Jun = 25, 2010 at 12:15 PM, Naitik Shah <n@daaku.org> wrote:
On Fri, Jun 25, 2010 at 11:39 AM, Breno <breno.demedeiros@g= mail.com> wrote:
On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <lshepard@facebook.com> wrote= :
> Brian, Dirk - just wondering if you had thoughts here?
>
> The only strong reason I can think of for base64 encoding is that it a= llows for a delimiter between the body and the signature. Is there any othe= r reason?

Without base64 encoding we have to define canonicalization procedures=
around spaces and we still have to URL encode separator characters
such as {. There is also the risk that developers might be confused
whether the URL encoding is to be performed before or after
computation of the signature. =C2=A0If you say that the signature is
computed on the base64 encoded blob, there's less scope for confusion and interoperability issues.


Yep, I get= that the "web" version makes the url encoding a no op. But I fea= r we're trading one spec (urlencoding) to another one (web base64). I&#= 39;m imagining the sample code (that does not rely on an SDK) we'ed giv= e out to developers in our docs, and the thing that stands out is the "= ;web" part in the web_base64. It means that our sample code will look = like

=C2=A0=C2=A0str_replace("+", "_", b= ase64(json_encode(data))))

or for validating signa= tures:

=C2=A0=C2=A0json_decode(decode64(str_replac= e("_", "+", data)))

The str_replace() really stands out. From my quick read= , it seemed like there were one or two other characters that needed to get = replaced too. While some languages (like PHP) support arrays to specify mul= tiple replacement patterns, in other languages you'll end up with a few= str_replace calls. It would be nice if that wasn't necessary.

I'm wondering if we can get away with &q= uot;urlencode(json_encode(data) + '.' + sig)" as the value. th= en, instead of str_replace for getting normal base64 logic to work, we woul= d instead need a rsplit or something, since the dot is not a reserved chara= cter in the json blob. Was that approach considered?


-Naitik

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



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


--0022150482dfb79902048a58d026-- From eran@hueniverse.com Thu Jul 1 13:17:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F32F3A6940 for ; Thu, 1 Jul 2010 13:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344, 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 TsJEj4X9eElJ for ; Thu, 1 Jul 2010 13:17:38 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 8A3623A67B1 for ; Thu, 1 Jul 2010 13:17:38 -0700 (PDT) Received: (qmail 8389 invoked from network); 1 Jul 2010 20:17:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 20:17:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Jul 2010 13:17:49 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , Justin Richer Date: Thu, 1 Jul 2010 13:18:01 -0700 Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZU0w71ARa4zURRJG+ZOmVTEZobgAByv/w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B694F@SNV-EXVS08.ds.corp.yahoo.com> <1278011235.28743.223.camel@localhost.localdomain> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 20:17:39 -0000 The rest of the parameters being in the body. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Thursday, July 01, 2010 12:26 PM > To: Justin Richer > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Versioning >=20 > On Thu, Jul 1, 2010 at 12:07 PM, Justin Richer wrote: > > OAuth tokens as a form-encoded element in a post body? Yes. Keep it. >=20 > Just curious. What use case would require that the access token is put in= the > post body as opposed to an http header when accessing a protected > resource? >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Jul 1 13:27: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 4E12F3A67ED for ; Thu, 1 Jul 2010 13:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 vxe4Xj5Adgh4 for ; Thu, 1 Jul 2010 13:27:50 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 63E993A6784 for ; Thu, 1 Jul 2010 13:27:50 -0700 (PDT) Received: (qmail 14781 invoked from network); 1 Jul 2010 20:28:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 20:28:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Jul 2010 13:27:56 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , Justin Richer Date: Thu, 1 Jul 2010 13:28:08 -0700 Thread-Topic: [OAUTH-WG] Support for query/body parameters (Was Re: Versioning) Thread-Index: AcsZWtF5TYSkysmJT2OwexOenqu5eQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4D9@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 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re: Versioning) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 20:27:51 -0000 I think all servers must support the header. I don't think we can demand al= l servers to support query or post parameters as that can conflict with the= ir existing namespace or architecture. I suggest we: 1. Make the "Token" scheme required in all resource servers 2. Allow resource servers to support the URI query or response body 3. Specify that when a request comes without the header to a server only su= pporting the header, the server should respond with error=3Dauthentication_= required to inform the client this form of authentication is not supported. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Thursday, July 01, 2010 12:48 PM > To: Justin Richer > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Versioning >=20 > On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer wrote: > >> > OAuth tokens as a form-encoded element in a post body? Yes. Keep it. > >> > >> Just curious. What use case would require that the access token is > >> put in the post body as opposed to an http header when accessing a > >> protected resource? > > > > If nothing else, it parallels the use case of a GET-style query > > parameter. It makes sense to have it be valid in both ways to allow > > developers to put the token in with whatever other parameters they're > > passing along. I've got plenty of use cases here for the query > > parameters: it's needed for cases where your client can't get any > > deeper into HTTP than "hey go fetch me this URL". >=20 > You can still use query parameters with POST. >=20 >=20 > > What use case says we shouldn't do POST parameters like that? A server > > wanting to do early-dispatch of a request was brought up, but that was > > only in the case of handling OAuth 1 and 2 simultaneously as I > > understood it. If a server's going to be doing dispatch on auth > > headers and query parameters already, it seems that it's got the > > wherewithal to parse a form-encoded body, too. >=20 > Parsing the body is not trivial. Some filters do not have access to it (a= pache > mod_redirect for example), some frameworks will allow you to access it on= ce > and then commit to a format, a decision that cannot be made by a filter (= in > Java see ServletRequest: getInputStream vs getReader vs getParameter). >=20 >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Jul 1 13:35: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 E3B1B3A686D for ; Thu, 1 Jul 2010 13:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.338, 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 uszgxaXkoZUp for ; Thu, 1 Jul 2010 13:35:32 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D1E343A6922 for ; Thu, 1 Jul 2010 13:35:32 -0700 (PDT) Received: (qmail 20031 invoked from network); 1 Jul 2010 20:35:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 20:35:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 1 Jul 2010 13:35:43 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , OAuth WG Date: Thu, 1 Jul 2010 13:35:56 -0700 Thread-Topic: [OAUTH-WG] register prefixes as opposed to full parameter names Thread-Index: AcsZVuv4BELBKhPoSuCYqsNWIakOgwABUs4Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4E2@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] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 20:35:37 -0000 I don't think this is necessary. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Thursday, July 01, 2010 12:52 PM > To: OAuth WG > Subject: [OAUTH-WG] register prefixes as opposed to full parameter names >=20 > For section 6.2, and possibly 6.3, I would suggest to register a prefix f= or all the > parameters defined by an extension. >=20 > Pros: >=20 > 1. Simpler registration, only one element needs to be registered, the pre= fix, > and not every single parameter name. Once an extension has a prefix > registered it can evolve and change the parameters it is using much easie= r. The registration is pretty simple and only requires reserving the name. All= other information is defined in a specification. There is no limit on the = number of records the registry can have, and mandating review for all regis= tered parameters is a good thing. Note that review is mostly used to make s= ure people are not doing something really really stupid. It is not a proces= s for obtaining rough consensus over any extension. This is why it uses Spe= cification required and not RFC required. =20 > 2. Greatly reduce the chances of a conflict with a query parameter used b= y an > authz server endpoint or client redirect_uri. There should not be any conflict. Either it has been registered or uses x_. > 3. Consistent with the generic vendor specific extension space ("x_"). >=20 > 4. Allows strict validation of OAuth parameters. Unknown extensions will = be > ignored, but the known ones can be strictly validated. I don't see how this is any different. If you know an extension "set" you s= till need to hardcode all the possible parameter part of that set. =20 > 5. Easy to determine what parameter is core and what is part of an > extension. How is that important? The point of extensibility is to extend the protocol= without looking like patches or hacks. I think allowing new parameters to = live as equal to core parameters is a good thing and is how protocols such = as HTTP work. >=20 > Cons: >=20 > 1. Slightly longer parameter names. Also, messy, ugly, opens the door to extensions without review. EHL >=20 > Underscore or dot could be used to separate the prefix from the name. >=20 >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Thu Jul 1 14:16: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 EAF073A695E for ; Thu, 1 Jul 2010 14:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.268 X-Spam-Level: X-Spam-Status: No, score=-17.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O53uROkImonV for ; Thu, 1 Jul 2010 14:16:16 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 38D5C3A67B4 for ; Thu, 1 Jul 2010 14:16:15 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o61LFUAA074255; Thu, 1 Jul 2010 14:15:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=rqlVjKwh7gvqC6H3ZSf7MzQ03LfpZc/lf6Q67ET3mG+78JKNMFiZeI6zgURMjymv Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 14:15:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jul 2010 14:15:02 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6969@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Support for query/body parameters (Was Re: Versioning) Thread-Index: AcsZWtF5TYSkysmJT2OwexOenqu5eQAB3oeg References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" To: "Eran Hammer-Lahav" , "Marius Scurtescu" , "Justin Richer" X-OriginalArrivalTime: 01 Jul 2010 21:15:29.0933 (UTC) FILETIME=[8897CBD0:01CB1962] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re: Versioning) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:16:25 -0000 So does this mean that supporting multiple protocols ends is in conflict with allowing use of POST parameters?=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Eran Hammer-Lahav > Sent: Thursday, July 01, 2010 1:28 PM > To: Marius Scurtescu; Justin Richer > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Support for query/body parameters=20 > (Was Re: Versioning) >=20 > I think all servers must support the header. I don't think we=20 > can demand all servers to support query or post parameters as=20 > that can conflict with their existing namespace or=20 > architecture. I suggest we: >=20 > 1. Make the "Token" scheme required in all resource servers=20 > 2. Allow resource servers to support the URI query or=20 > response body 3. Specify that when a request comes without=20 > the header to a server only supporting the header, the server=20 > should respond with error=3Dauthentication_required to inform=20 > the client this form of authentication is not supported. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org=20 > [mailto:oauth-bounces@ietf.org] On Behalf=20 > > Of Marius Scurtescu > > Sent: Thursday, July 01, 2010 12:48 PM > > To: Justin Richer > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] Versioning > >=20 > > On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer=20 > wrote: > > >> > OAuth tokens as a form-encoded element in a post body?=20 > Yes. Keep it. > > >> > > >> Just curious. What use case would require that the=20 > access token is=20 > > >> put in the post body as opposed to an http header when=20 > accessing a=20 > > >> protected resource? > > > > > > If nothing else, it parallels the use case of a GET-style query=20 > > > parameter. It makes sense to have it be valid in both=20 > ways to allow=20 > > > developers to put the token in with whatever other parameters=20 > > > they're passing along. I've got plenty of use cases here for the=20 > > > query > > > parameters: it's needed for cases where your client can't get any=20 > > > deeper into HTTP than "hey go fetch me this URL". > >=20 > > You can still use query parameters with POST. > >=20 > >=20 > > > What use case says we shouldn't do POST parameters like that? A=20 > > > server wanting to do early-dispatch of a request was=20 > brought up, but=20 > > > that was only in the case of handling OAuth 1 and 2=20 > simultaneously=20 > > > as I understood it. If a server's going to be doing=20 > dispatch on auth=20 > > > headers and query parameters already, it seems that it's got the=20 > > > wherewithal to parse a form-encoded body, too. > >=20 > > Parsing the body is not trivial. Some filters do not have=20 > access to it=20 > > (apache mod_redirect for example), some frameworks will=20 > allow you to=20 > > access it once and then commit to a format, a decision that=20 > cannot be=20 > > made by a filter (in Java see ServletRequest:=20 > getInputStream vs getReader vs getParameter). > >=20 > >=20 > > 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 >=20 From mscurtescu@google.com Thu Jul 1 14:21:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E783A6A21 for ; Thu, 1 Jul 2010 14:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.589 X-Spam-Level: X-Spam-Status: No, score=-101.589 tagged_above=-999 required=5 tests=[AWL=0.388, 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 gZmIoHfYoAC2 for ; Thu, 1 Jul 2010 14:21:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 76BA83A6A1B for ; Thu, 1 Jul 2010 14:21:19 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o61LLUTv029869 for ; Thu, 1 Jul 2010 14:21:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278019290; bh=0e58BbZzEnY4hvt0Otuyap+bF5o=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=W1AqY7IRhR8JK7utJNaHPVLlBr2Gu4HJ0QVpkkDfiP8KhDbJeINQLk5XGlViZ3Dfb EgJ3TtkRJt4L44O+9AdCQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=XhVp71G/te35kHg7ZyNpJtnIbPcUjtvduqBysj33/x4sRbI/n8aCBvB8anW3aTlpx pToqLlM8P4Vq8kcX8Qd5w== Received: from gxk26 (gxk26.prod.google.com [10.202.11.26]) by wpaz13.hot.corp.google.com with ESMTP id o61LLSSg024504 for ; Thu, 1 Jul 2010 14:21:29 -0700 Received: by gxk26 with SMTP id 26so1241568gxk.38 for ; Thu, 01 Jul 2010 14:21:28 -0700 (PDT) Received: by 10.100.7.3 with SMTP id 3mr78410ang.174.1278019288495; Thu, 01 Jul 2010 14:21:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Thu, 1 Jul 2010 14:21:08 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 1 Jul 2010 14:21:08 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:21:24 -0000 On Thu, Jul 1, 2010 at 1:35 PM, Eran Hammer-Lahav wro= te: > I don't think this is necessary. > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Marius Scurtescu >> Sent: Thursday, July 01, 2010 12:52 PM >> To: OAuth WG >> Subject: [OAUTH-WG] register prefixes as opposed to full parameter names >> >> For section 6.2, and possibly 6.3, I would suggest to register a prefix = for all the >> parameters defined by an extension. >> >> Pros: >> >> 1. Simpler registration, only one element needs to be registered, the pr= efix, >> and not every single parameter name. Once an extension has a prefix >> registered it can evolve and change the parameters it is using much easi= er. > > The registration is pretty simple and only requires reserving the name. A= ll other information is defined in a specification. There is no limit on th= e number of records the registry can have, and mandating review for all reg= istered parameters is a good thing. Note that review is mostly used to make= sure people are not doing something really really stupid. It is not a proc= ess for obtaining rough consensus over any extension. This is why it uses S= pecification required and not RFC required. > >> 2. Greatly reduce the chances of a conflict with a query parameter used = by an >> authz server endpoint or client redirect_uri. > > There should not be any conflict. Either it has been registered or uses x= _. There can be. Here is the example I gave earlier in another thread. MediaWiki uses the 'title' parameter. Some OAuth extension may register and use this same name and this will prevent MediWiki from being able to support that extension. >> 3. Consistent with the generic vendor specific extension space ("x_"). >> >> 4. Allows strict validation of OAuth parameters. Unknown extensions will= be >> ignored, but the known ones can be strictly validated. > > I don't see how this is any different. If you know an extension "set" you= still need to hardcode all the possible parameter part of that set. I guess you are right. This will work only if some special char is used to delimit the prefix. >> 5. Easy to determine what parameter is core and what is part of an >> extension. > > How is that important? The point of extensibility is to extend the protoc= ol without looking like patches or hacks. I think allowing new parameters t= o live as equal to core parameters is a good thing and is how protocols suc= h as HTTP work. > >> >> Cons: >> >> 1. Slightly longer parameter names. > > Also, messy, ugly, opens the door to extensions without review. I don't get the last part, skipping reviews. As for beauty, that's relative= ;-) Marius From mscurtescu@google.com Thu Jul 1 14:23:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E05F3A6968 for ; Thu, 1 Jul 2010 14:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.599 X-Spam-Level: X-Spam-Status: No, score=-101.599 tagged_above=-999 required=5 tests=[AWL=0.378, 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 IUEwv2L7Oa10 for ; Thu, 1 Jul 2010 14:23:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 3323F3A6951 for ; Thu, 1 Jul 2010 14:23:34 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o61LNit2000359 for ; Thu, 1 Jul 2010 14:23:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278019425; bh=srDotVdMORA+4nnnuNyoO70FK4g=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=AXTYr+nvqmg816jiDJN+S0+D08i2tjp3eHbEMhLQ44IQyZPsis8TFp/Pn8Gq8WmAo A1Amh88Cqgxs5JO67DMAg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=YlliWROTnhr2qyn/w08jwB+K6HFdp14v+H3z66Ju6HXYgcPDIyI/nqU+6OwVrehau YBZOOAccPCiWoWPghJi5A== Received: from gwj20 (gwj20.prod.google.com [10.200.10.20]) by kpbe16.cbf.corp.google.com with ESMTP id o61LNhZh007019 for ; Thu, 1 Jul 2010 14:23:43 -0700 Received: by gwj20 with SMTP id 20so1443670gwj.4 for ; Thu, 01 Jul 2010 14:23:43 -0700 (PDT) Received: by 10.101.130.2 with SMTP id h2mr145903ann.54.1278019423238; Thu, 01 Jul 2010 14:23:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Thu, 1 Jul 2010 14:23:23 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 1 Jul 2010 14:23:23 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re: Versioning) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:23:35 -0000 I think that works. POST body support can even be moved to a separate spec, if anyone really uses it. Marius On Thu, Jul 1, 2010 at 1:28 PM, Eran Hammer-Lahav wrote: > I think all servers must support the header. I don't think we can demand all servers to support query or post parameters as that can conflict with their existing namespace or architecture. I suggest we: > > 1. Make the "Token" scheme required in all resource servers > 2. Allow resource servers to support the URI query or response body > 3. Specify that when a request comes without the header to a server only supporting the header, the server should respond with error=authentication_required to inform the client this form of authentication is not supported. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Marius Scurtescu >> Sent: Thursday, July 01, 2010 12:48 PM >> To: Justin Richer >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Versioning >> >> On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer wrote: >> >> > OAuth tokens as a form-encoded element in a post body? Yes. Keep it. >> >> >> >> Just curious. What use case would require that the access token is >> >> put in the post body as opposed to an http header when accessing a >> >> protected resource? >> > >> > If nothing else, it parallels the use case of a GET-style query >> > parameter. It makes sense to have it be valid in both ways to allow >> > developers to put the token in with whatever other parameters they're >> > passing along. I've got plenty of use cases here for the query >> > parameters: it's needed for cases where your client can't get any >> > deeper into HTTP than "hey go fetch me this URL". >> >> You can still use query parameters with POST. >> >> >> > What use case says we shouldn't do POST parameters like that? A server >> > wanting to do early-dispatch of a request was brought up, but that was >> > only in the case of handling OAuth 1 and 2 simultaneously as I >> > understood it. If a server's going to be doing dispatch on auth >> > headers and query parameters already, it seems that it's got the >> > wherewithal to parse a form-encoded body, too. >> >> Parsing the body is not trivial. Some filters do not have access to it (apache >> mod_redirect for example), some frameworks will allow you to access it once >> and then commit to a format, a decision that cannot be made by a filter (in >> Java see ServletRequest: getInputStream vs getReader vs getParameter). >> >> >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Thu Jul 1 14:24: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 B68483A69B1 for ; Thu, 1 Jul 2010 14:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=0.336, 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 k9mRWS63kWjy for ; Thu, 1 Jul 2010 14:24:08 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8C0543A6951 for ; Thu, 1 Jul 2010 14:24:08 -0700 (PDT) Received: (qmail 13051 invoked from network); 1 Jul 2010 21:24:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 21:24:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Jul 2010 14:24:13 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Thu, 1 Jul 2010 14:24:25 -0700 Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZTElmAmpwoxk6TFekQiB+TeOGJwAEMKqw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:24:09 -0000 [Replying to everything at once...] > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Thursday, July 01, 2010 11:36 AM > Not sure about the future, but looking at OAuth 1 vs OAuth 2. A protected > resource request filter may want to decide early what protocol it deals w= ith > so it can call the appropriate handler, or to enforce HTTPS for OAuth 2 f= or > example. Sure, it can apply heuristics right now, but it would be nice to= have > a more deterministic way which can also be extended in the future. You ca= n > always embed the protocol version inside the token I guess, so I don't th= ink > this is a huge issue. First, this is limited to non-header methods. Look for 'oauth_signature_met= hod'. If it is not there, assume this is a 2.0 request. I don't buy the suggestio= n that in practice, developers are likely to omit *this* parameter in a mal= formed 1.0 requests. If an existing 1.0 provider can demonstrate how this i= s a problem from experience, I might reconsider. > I was not part of the 1.0 vs 1.0a discussions, so not sure what was the > conclusion there. The conclusion was that beyond "this sounds like a good idea" we didn't kno= w what the heck we were doing. Blaine at the time strongly opposed it and l= ost the argument to me. Since the 1.0a discussions, I have changed my view = and am no decidedly against version parameters because they are impossible = to design. > -----Original Message----- > From: Rob Richards [mailto:rrichards@cdatazone.org] > Sent: Thursday, July 01, 2010 11:43 AM > Exactly. While it might be needed in the future, there is a need to > differentiate OAuth 1.0 from 2.0 on resource endpoints right now. > Outside of requiring an oauth_version parameter (or equivalent) all other > suggestions leave versioning as a grey area, where things can be interpre= ted > one way or another with no consistency. Grey areas in specs are a bad thi= ng. > You end up with different languages/libraries dealing with things in > completely different and incompatible ways because something was not > clearly spelled out. This is an area that is clearly on the server side, not the client. Since t= he core specification leaves discovery out, client developers need to know = what version of OAuth is supported by the server and use the right one. Wit= hout discovery, the client must know ahead of time what to do. With discove= ry, the client can choose the right protocol. Either way, the client never = just sends a 1.0 or 2.0 requests and hopes for the best. On the server side, the challenge isn't that significant. When not using a = header, the server can use multiple methods to differentiate the version us= ed by the client: 1. Token syntax 2. Presence of 'oauth_signature_method' 3. Presence of 'oauth_signature' 4. Presence of no other 'oauth_' parameter than 'oauth_token' > With this the spec needs to including some wording to explicitly define h= ow > to handle the case when running an endpoint supporting both OAuth > 1.0 and 2.0 and the oauth2_token is missing then the call is handled acco= rding > to the OAuth 1.0/a spec. Whatever is decided, be it a version parameter, = the > use of oauth2_token or the check for the existence of the > oauth_signature_method parameter, etc///, the spec needs to define and > be explicit on how a resource endpoint determines between a 1.0 and 2.0 c= all > when both are supported. The damage done by interpreting a malformed 1.0 request (the odd attempt to= use 1.0 by only including 'oauth_token') is at most returning an 'invalid-= token' response. I hope every server developer understands that they should= not share tokens between 1.0 and 2.0 with completely different security pr= operties. I think there are more issue with regard to 1.0 to 2.0 migration that shoul= d be addressed, and I have asked those who care about this to propose a dra= ft. Given that such a draft will not be useful for a long time, given that = the vast majority of OAuth implementation 1-2 years from now will be 2.0, I= do not want to include it in the core specification. In order for your argument to stand, you need to show how the current setup= leads to interoperability problems. Given the 4 options above, and the fac= t that a malformed 1.0 request will still fail, I do not agree that interop= is affected. > -----Original Message----- > From: Justin Richer [mailto:jricher@mitre.org] > Sent: Thursday, July 01, 2010 11:50 AM > An easy fix here is to use oauth2_token instead of oauth_token here, sinc= e > that's the only place we seem to be using the oauth_ namespace now. > Makes figuring out the two completely deterministic since it's a differen= t > parameter name when passed as a GET or POST variable, and a different > header name when passed as a header (using the current Token scheme or > an OAuth2 scheme or whatever). Yes, we can rename the 'oauth_token' parameter to something else. I might b= e included to support such an idea but not to 'oauth2_token', but to someth= ing that would use the same parameter name across the header and query/body= . At the same time, I consider using the query/body parameters as hacks so = I'm generally not sympathetic to changes there. EHL From wmills@yahoo-inc.com Thu Jul 1 14:37:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D20B3A68A0 for ; Thu, 1 Jul 2010 14:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.288 X-Spam-Level: X-Spam-Status: No, score=-17.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6eIlS6Uzikp for ; Thu, 1 Jul 2010 14:36:56 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id 63FDE3A63CB for ; Thu, 1 Jul 2010 14:36:54 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o61LabQp029432; Thu, 1 Jul 2010 14:36:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:return-path:x-originalarrivaltime; b=GmH/XDQjXJK6awO3V2ajtlohmxqevEkpsPJ5TQIcYU+JVt3Das1Z+KoFepPqYcVj Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 14:36:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jul 2010 14:36:09 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B696F@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZTElmAmpwoxk6TFekQiB+TeOGJwAEMKqwAAH2BSA= References: <4C2C6D4A.5010401@cdatazone.org><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET><012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" To: "Eran Hammer-Lahav" , X-OriginalArrivalTime: 01 Jul 2010 21:36:37.0152 (UTC) FILETIME=[7BEA1200:01CB1965] Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:37:01 -0000 In re: 1. Token syntax 2. Presence of 'oauth_signature_method' 3. Presence of 'oauth_signature' 4. Presence of no other 'oauth_' parameter than 'oauth_token'=20 We can certainly do better than this. Yeah, the server should be smart enough, but this seems unneccesary when we could be a lot simpler. Can we require the presence of the Authorization header with "Token", and if nothing else is there you have to go to the query params or post body? > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Eran Hammer-Lahav > Sent: Thursday, July 01, 2010 2:24 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Versioning >=20 > [Replying to everything at once...] >=20 > > -----Original Message----- > > From: Marius Scurtescu [mailto:mscurtescu@google.com] > > Sent: Thursday, July 01, 2010 11:36 AM >=20 > > Not sure about the future, but looking at OAuth 1 vs OAuth 2. A=20 > > protected resource request filter may want to decide early what=20 > > protocol it deals with so it can call the appropriate=20 > handler, or to=20 > > enforce HTTPS for OAuth 2 for example. Sure, it can apply=20 > heuristics=20 > > right now, but it would be nice to have a more=20 > deterministic way which=20 > > can also be extended in the future. You can always embed=20 > the protocol=20 > > version inside the token I guess, so I don't think this is=20 > a huge issue. >=20 > First, this is limited to non-header methods. Look for=20 > 'oauth_signature_method'. >=20 > If it is not there, assume this is a 2.0 request. I don't buy=20 > the suggestion that in practice, developers are likely to=20 > omit *this* parameter in a malformed 1.0 requests. If an=20 > existing 1.0 provider can demonstrate how this is a problem=20 > from experience, I might reconsider. >=20 > > I was not part of the 1.0 vs 1.0a discussions, so not sure what was=20 > > the conclusion there. >=20 > The conclusion was that beyond "this sounds like a good idea"=20 > we didn't know what the heck we were doing. Blaine at the=20 > time strongly opposed it and lost the argument to me. Since=20 > the 1.0a discussions, I have changed my view and am no=20 > decidedly against version parameters because they are=20 > impossible to design. >=20 >=20 > > -----Original Message----- > > From: Rob Richards [mailto:rrichards@cdatazone.org] > > Sent: Thursday, July 01, 2010 11:43 AM >=20 > > Exactly. While it might be needed in the future, there is a need to=20 > > differentiate OAuth 1.0 from 2.0 on resource endpoints right now. > > Outside of requiring an oauth_version parameter (or equivalent) all=20 > > other suggestions leave versioning as a grey area, where=20 > things can be=20 > > interpreted one way or another with no consistency. Grey=20 > areas in specs are a bad thing. > > You end up with different languages/libraries dealing with=20 > things in=20 > > completely different and incompatible ways because=20 > something was not=20 > > clearly spelled out. >=20 > This is an area that is clearly on the server side, not the=20 > client. Since the core specification leaves discovery out,=20 > client developers need to know what version of OAuth is=20 > supported by the server and use the right one. Without=20 > discovery, the client must know ahead of time what to do.=20 > With discovery, the client can choose the right protocol.=20 > Either way, the client never just sends a 1.0 or 2.0 requests=20 > and hopes for the best. >=20 > On the server side, the challenge isn't that significant.=20 > When not using a header, the server can use multiple methods=20 > to differentiate the version used by the client: >=20 > 1. Token syntax > 2. Presence of 'oauth_signature_method' > 3. Presence of 'oauth_signature' > 4. Presence of no other 'oauth_' parameter than 'oauth_token' >=20 > > With this the spec needs to including some wording to explicitly=20 > > define how to handle the case when running an endpoint=20 > supporting both=20 > > OAuth 1.0 and 2.0 and the oauth2_token is missing then the call is=20 > > handled according to the OAuth 1.0/a spec. Whatever is=20 > decided, be it=20 > > a version parameter, the use of oauth2_token or the check for the=20 > > existence of the oauth_signature_method parameter, etc///, the spec=20 > > needs to define and be explicit on how a resource endpoint=20 > determines=20 > > between a 1.0 and 2.0 call when both are supported. >=20 > The damage done by interpreting a malformed 1.0 request (the=20 > odd attempt to use 1.0 by only including 'oauth_token') is at=20 > most returning an 'invalid-token' response. I hope every=20 > server developer understands that they should not share=20 > tokens between 1.0 and 2.0 with completely different security=20 > properties. >=20 > I think there are more issue with regard to 1.0 to 2.0=20 > migration that should be addressed, and I have asked those=20 > who care about this to propose a draft. Given that such a=20 > draft will not be useful for a long time, given that the vast=20 > majority of OAuth implementation 1-2 years from now will be=20 > 2.0, I do not want to include it in the core specification. >=20 > In order for your argument to stand, you need to show how the=20 > current setup leads to interoperability problems. Given the 4=20 > options above, and the fact that a malformed 1.0 request will=20 > still fail, I do not agree that interop is affected. >=20 >=20 > > -----Original Message----- > > From: Justin Richer [mailto:jricher@mitre.org] > > Sent: Thursday, July 01, 2010 11:50 AM >=20 > > An easy fix here is to use oauth2_token instead of=20 > oauth_token here,=20 > > since that's the only place we seem to be using the oauth_=20 > namespace now. > > Makes figuring out the two completely deterministic since it's a=20 > > different parameter name when passed as a GET or POST=20 > variable, and a=20 > > different header name when passed as a header (using the=20 > current Token=20 > > scheme or an OAuth2 scheme or whatever). >=20 > Yes, we can rename the 'oauth_token' parameter to something=20 > else. I might be included to support such an idea but not to=20 > 'oauth2_token', but to something that would use the same=20 > parameter name across the header and query/body. At the same=20 > time, I consider using the query/body parameters as hacks so=20 > I'm generally not sympathetic to changes there. >=20 > EHL >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From wmills@yahoo-inc.com Thu Jul 1 14:41: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 76F163A6A5D for ; Thu, 1 Jul 2010 14:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.305 X-Spam-Level: X-Spam-Status: No, score=-17.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vn-TUyIfpDO for ; Thu, 1 Jul 2010 14:41:29 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id B71153A694E for ; Thu, 1 Jul 2010 14:41:26 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o61LecBY081077; Thu, 1 Jul 2010 14:40:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:return-path:x-originalarrivaltime; b=W77MpiH4jzWigeSWkA53q7Z2ZqZeHqOZfvw3id1Bioz7tZakK2AMlU9TtsCXHnTc Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 14:40:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jul 2010 14:40:24 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6970@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B696F@SNV-EXVS08.ds.corp.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZTElmAmpwoxk6TFekQiB+TeOGJwAEMKqwAAH2BSAAAD3bkA== References: <4C2C6D4A.5010401@cdatazone.org><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET><012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B696F@SNV-EXVS08.ds.corp.yahoo.com> From: "William Mills" To: "William Mills" , "Eran Hammer-Lahav" , X-OriginalArrivalTime: 01 Jul 2010 21:40:37.0996 (UTC) FILETIME=[0B77F2C0:01CB1966] Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:41:35 -0000 I'm also fine with a note in the spec that says, something like "If you need to support 1.0a and 2 on the same protected resource it is RECOMMENDED that you always use the Authorization header variant."=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of William Mills > Sent: Thursday, July 01, 2010 2:36 PM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: Re: [OAUTH-WG] Versioning >=20 > In re: >=20 > 1. Token syntax > 2. Presence of 'oauth_signature_method' > 3. Presence of 'oauth_signature' > 4. Presence of no other 'oauth_' parameter than 'oauth_token'=20 >=20 > We can certainly do better than this. Yeah, the server=20 > should be smart enough, but this seems unneccesary when we=20 > could be a lot simpler. >=20 > Can we require the presence of the Authorization header with=20 > "Token", and if nothing else is there you have to go to the=20 > query params or post body? >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org=20 > [mailto:oauth-bounces@ietf.org] On Behalf=20 > > Of Eran Hammer-Lahav > > Sent: Thursday, July 01, 2010 2:24 PM > > To: oauth@ietf.org > > Subject: Re: [OAUTH-WG] Versioning > >=20 > > [Replying to everything at once...] > >=20 > > > -----Original Message----- > > > From: Marius Scurtescu [mailto:mscurtescu@google.com] > > > Sent: Thursday, July 01, 2010 11:36 AM > >=20 > > > Not sure about the future, but looking at OAuth 1 vs OAuth 2. A=20 > > > protected resource request filter may want to decide early what=20 > > > protocol it deals with so it can call the appropriate > > handler, or to > > > enforce HTTPS for OAuth 2 for example. Sure, it can apply > > heuristics > > > right now, but it would be nice to have a more > > deterministic way which > > > can also be extended in the future. You can always embed > > the protocol > > > version inside the token I guess, so I don't think this is > > a huge issue. > >=20 > > First, this is limited to non-header methods. Look for=20 > > 'oauth_signature_method'. > >=20 > > If it is not there, assume this is a 2.0 request. I don't buy the=20 > > suggestion that in practice, developers are likely to omit *this*=20 > > parameter in a malformed 1.0 requests. If an existing 1.0=20 > provider can=20 > > demonstrate how this is a problem from experience, I might=20 > reconsider. > >=20 > > > I was not part of the 1.0 vs 1.0a discussions, so not=20 > sure what was=20 > > > the conclusion there. > >=20 > > The conclusion was that beyond "this sounds like a good idea"=20 > > we didn't know what the heck we were doing. Blaine at the time=20 > > strongly opposed it and lost the argument to me. Since the 1.0a=20 > > discussions, I have changed my view and am no decidedly against=20 > > version parameters because they are impossible to design. > >=20 > >=20 > > > -----Original Message----- > > > From: Rob Richards [mailto:rrichards@cdatazone.org] > > > Sent: Thursday, July 01, 2010 11:43 AM > >=20 > > > Exactly. While it might be needed in the future, there is=20 > a need to=20 > > > differentiate OAuth 1.0 from 2.0 on resource endpoints right now. > > > Outside of requiring an oauth_version parameter (or=20 > equivalent) all=20 > > > other suggestions leave versioning as a grey area, where=20 > > things can be=20 > > > interpreted one way or another with no consistency. Grey=20 > > areas in specs are a bad thing. > > > You end up with different languages/libraries dealing with=20 > > things in=20 > > > completely different and incompatible ways because=20 > > something was not=20 > > > clearly spelled out. > >=20 > > This is an area that is clearly on the server side, not the=20 > > client. Since the core specification leaves discovery out,=20 > > client developers need to know what version of OAuth is=20 > > supported by the server and use the right one. Without=20 > > discovery, the client must know ahead of time what to do.=20 > > With discovery, the client can choose the right protocol.=20 > > Either way, the client never just sends a 1.0 or 2.0 requests=20 > > and hopes for the best. > >=20 > > On the server side, the challenge isn't that significant.=20 > > When not using a header, the server can use multiple methods=20 > > to differentiate the version used by the client: > >=20 > > 1. Token syntax > > 2. Presence of 'oauth_signature_method' > > 3. Presence of 'oauth_signature' > > 4. Presence of no other 'oauth_' parameter than 'oauth_token' > >=20 > > > With this the spec needs to including some wording to explicitly=20 > > > define how to handle the case when running an endpoint=20 > > supporting both=20 > > > OAuth 1.0 and 2.0 and the oauth2_token is missing then=20 > the call is=20 > > > handled according to the OAuth 1.0/a spec. Whatever is=20 > > decided, be it=20 > > > a version parameter, the use of oauth2_token or the check for the=20 > > > existence of the oauth_signature_method parameter,=20 > etc///, the spec=20 > > > needs to define and be explicit on how a resource endpoint=20 > > determines=20 > > > between a 1.0 and 2.0 call when both are supported. > >=20 > > The damage done by interpreting a malformed 1.0 request (the=20 > > odd attempt to use 1.0 by only including 'oauth_token') is at=20 > > most returning an 'invalid-token' response. I hope every=20 > > server developer understands that they should not share=20 > > tokens between 1.0 and 2.0 with completely different security=20 > > properties. > >=20 > > I think there are more issue with regard to 1.0 to 2.0=20 > > migration that should be addressed, and I have asked those=20 > > who care about this to propose a draft. Given that such a=20 > > draft will not be useful for a long time, given that the vast=20 > > majority of OAuth implementation 1-2 years from now will be=20 > > 2.0, I do not want to include it in the core specification. > >=20 > > In order for your argument to stand, you need to show how the=20 > > current setup leads to interoperability problems. Given the 4=20 > > options above, and the fact that a malformed 1.0 request will=20 > > still fail, I do not agree that interop is affected. > >=20 > >=20 > > > -----Original Message----- > > > From: Justin Richer [mailto:jricher@mitre.org] > > > Sent: Thursday, July 01, 2010 11:50 AM > >=20 > > > An easy fix here is to use oauth2_token instead of=20 > > oauth_token here,=20 > > > since that's the only place we seem to be using the oauth_=20 > > namespace now. > > > Makes figuring out the two completely deterministic since it's a=20 > > > different parameter name when passed as a GET or POST=20 > > variable, and a=20 > > > different header name when passed as a header (using the=20 > > current Token=20 > > > scheme or an OAuth2 scheme or whatever). > >=20 > > Yes, we can rename the 'oauth_token' parameter to something=20 > > else. I might be included to support such an idea but not to=20 > > 'oauth2_token', but to something that would use the same=20 > > parameter name across the header and query/body. At the same=20 > > time, I consider using the query/body parameters as hacks so=20 > > I'm generally not sympathetic to changes there. > >=20 > > EHL > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From torsten@lodderstedt.net Thu Jul 1 14:50: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 4A3843A6A4A for ; Thu, 1 Jul 2010 14:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.404 X-Spam-Level: X-Spam-Status: No, score=-1.404 tagged_above=-999 required=5 tests=[AWL=0.845, 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 Wbcl4NVrIV5b for ; Thu, 1 Jul 2010 14:50:42 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by core3.amsl.com (Postfix) with ESMTP id 0303A3A696B for ; Thu, 1 Jul 2010 14:50:41 -0700 (PDT) Received: from p4fff04a2.dip.t-dialin.net ([79.255.4.162] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OURel-0006Jf-Fw; Thu, 01 Jul 2010 23:50:51 +0200 Message-ID: <4C2D0DBA.70201@lodderstedt.net> Date: Thu, 01 Jul 2010 23:50:50 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re: Versioning) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:50:43 -0000 I essentially agreed, except in 3. the server should send back status code 401 with a WWW-Authenticate header. regards, Torsten. Am 01.07.2010 22:28, schrieb Eran Hammer-Lahav: > I think all servers must support the header. I don't think we can demand all servers to support query or post parameters as that can conflict with their existing namespace or architecture. I suggest we: > > 1. Make the "Token" scheme required in all resource servers > 2. Allow resource servers to support the URI query or response body > 3. Specify that when a request comes without the header to a server only supporting the header, the server should respond with error=authentication_required to inform the client this form of authentication is not supported. > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Marius Scurtescu >> Sent: Thursday, July 01, 2010 12:48 PM >> To: Justin Richer >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Versioning >> >> On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer wrote: >> >>>>> OAuth tokens as a form-encoded element in a post body? Yes. Keep it. >>>>> >>>> Just curious. What use case would require that the access token is >>>> put in the post body as opposed to an http header when accessing a >>>> protected resource? >>>> >>> If nothing else, it parallels the use case of a GET-style query >>> parameter. It makes sense to have it be valid in both ways to allow >>> developers to put the token in with whatever other parameters they're >>> passing along. I've got plenty of use cases here for the query >>> parameters: it's needed for cases where your client can't get any >>> deeper into HTTP than "hey go fetch me this URL". >>> >> You can still use query parameters with POST. >> >> >> >>> What use case says we shouldn't do POST parameters like that? A server >>> wanting to do early-dispatch of a request was brought up, but that was >>> only in the case of handling OAuth 1 and 2 simultaneously as I >>> understood it. If a server's going to be doing dispatch on auth >>> headers and query parameters already, it seems that it's got the >>> wherewithal to parse a form-encoded body, too. >>> >> Parsing the body is not trivial. Some filters do not have access to it (apache >> mod_redirect for example), some frameworks will allow you to access it once >> and then commit to a format, a decision that cannot be made by a filter (in >> Java see ServletRequest: getInputStream vs getReader vs getParameter). >> >> >> 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 eran@hueniverse.com Thu Jul 1 14:52: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 B368C3A694E for ; Thu, 1 Jul 2010 14:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 B9YPCuCy+Yx0 for ; Thu, 1 Jul 2010 14:52:22 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 27A4C3A696B for ; Thu, 1 Jul 2010 14:52:17 -0700 (PDT) Received: (qmail 16225 invoked from network); 1 Jul 2010 21:52:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 21:52:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Jul 2010 14:52:28 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Thu, 1 Jul 2010 14:52:40 -0700 Thread-Topic: [OAUTH-WG] register prefixes as opposed to full parameter names Thread-Index: AcsZZBy/c5Pe4L6bQJqWVPzUcp8EVwAARdIQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C528@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:52:24 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Thursday, July 01, 2010 2:21 PM > >> 2. Greatly reduce the chances of a conflict with a query parameter > >> used by an authz server endpoint or client redirect_uri. > > > > There should not be any conflict. Either it has been registered or uses= x_. >=20 > There can be. Here is the example I gave earlier in another thread. > MediaWiki uses the 'title' parameter. Some OAuth extension may register > and use this same name and this will prevent MediWiki from being able to > support that extension. I think this discussion (which we spent many days on already) boils down to= a philosophical approach to the level a new protocol should accommodate th= e broken environment in which it is expected to be deployed. =20 I think MediaWiki should change the way it treats the OAuth endpoints to is= olate them from the rest of the platform. When receiving an OAuth request (= with such an OAuth 'title' parameter), the platform can rename all the OAut= h parameters to oauth_ internally and proceed to add its own parameters wit= hout conflicts. While this approach might not be trivial, it is clearly possible. I think t= here is a larger question of how OAuth is used in a MediaWiki installation,= and how it can accommodate some of the other requirements such as SSL. I do not consider making MediaWiki's deployment of 2.0 easier an important = consideration. > >> Cons: > >> > >> 1. Slightly longer parameter names. > > > > Also, messy, ugly, opens the door to extensions without review. >=20 > I don't get the last part, skipping reviews. As for beauty, that's relati= ve ;-) If we approve a blanket "prefix_" extension, we lose the ability to review = individual parameters within that prefix. EHL From eran@hueniverse.com Thu Jul 1 14:54: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 213E73A694E for ; Thu, 1 Jul 2010 14:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.331, 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 e23pyv1H-T4y for ; Thu, 1 Jul 2010 14:54:29 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 15C6E3A696B for ; Thu, 1 Jul 2010 14:54:29 -0700 (PDT) Received: (qmail 19079 invoked from network); 1 Jul 2010 21:54:40 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 21:54:40 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 1 Jul 2010 14:54:40 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Thu, 1 Jul 2010 14:54:52 -0700 Thread-Topic: [OAUTH-WG] Support for query/body parameters (Was Re: Versioning) Thread-Index: AcsZZ3vYwYmfSVH7T3KdGfSClx7GwwAAHXwA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C52A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2D0DBA.70201@lodderstedt.net> In-Reply-To: <4C2D0DBA.70201@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re: Versioning) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:54:30 -0000 That's where the error parameter will be (the only supported place in -09 f= or a failed protected resource response). EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Thursday, July 01, 2010 2:51 PM > To: Eran Hammer-Lahav > Cc: Marius Scurtescu; Justin Richer; oauth@ietf.org > Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re: > Versioning) >=20 > I essentially agreed, except in 3. the server should send back status cod= e 401 > with a WWW-Authenticate header. >=20 > regards, > Torsten. >=20 > Am 01.07.2010 22:28, schrieb Eran Hammer-Lahav: > > I think all servers must support the header. I don't think we can deman= d all > servers to support query or post parameters as that can conflict with the= ir > existing namespace or architecture. I suggest we: > > > > 1. Make the "Token" scheme required in all resource servers 2. Allow > > resource servers to support the URI query or response body 3. Specify > > that when a request comes without the header to a server only supportin= g > the header, the server should respond with error=3Dauthentication_require= d > to inform the client this form of authentication is not supported. > > > > EHL > > > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Marius Scurtescu > >> Sent: Thursday, July 01, 2010 12:48 PM > >> To: Justin Richer > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] Versioning > >> > >> On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer wro= te: > >> > >>>>> OAuth tokens as a form-encoded element in a post body? Yes. Keep > it. > >>>>> > >>>> Just curious. What use case would require that the access token is > >>>> put in the post body as opposed to an http header when accessing a > >>>> protected resource? > >>>> > >>> If nothing else, it parallels the use case of a GET-style query > >>> parameter. It makes sense to have it be valid in both ways to allow > >>> developers to put the token in with whatever other parameters > >>> they're passing along. I've got plenty of use cases here for the > >>> query > >>> parameters: it's needed for cases where your client can't get any > >>> deeper into HTTP than "hey go fetch me this URL". > >>> > >> You can still use query parameters with POST. > >> > >> > >> > >>> What use case says we shouldn't do POST parameters like that? A > >>> server wanting to do early-dispatch of a request was brought up, but > >>> that was only in the case of handling OAuth 1 and 2 simultaneously > >>> as I understood it. If a server's going to be doing dispatch on auth > >>> headers and query parameters already, it seems that it's got the > >>> wherewithal to parse a form-encoded body, too. > >>> > >> Parsing the body is not trivial. Some filters do not have access to > >> it (apache mod_redirect for example), some frameworks will allow you > >> to access it once and then commit to a format, a decision that cannot > >> be made by a filter (in Java see ServletRequest: getInputStream vs > getReader vs getParameter). > >> > >> > >> 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 torsten@lodderstedt.net Thu Jul 1 14:59: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 4CB873A68BB for ; Thu, 1 Jul 2010 14:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svXzUC51QBFx for ; Thu, 1 Jul 2010 14:59:04 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by core3.amsl.com (Postfix) with ESMTP id 802503A694E for ; Thu, 1 Jul 2010 14:59:03 -0700 (PDT) Received: from p4fff04a2.dip.t-dialin.net ([79.255.4.162] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OURms-0008DM-GV; Thu, 01 Jul 2010 23:59:14 +0200 Message-ID: <4C2D0FB1.8060608@lodderstedt.net> Date: Thu, 01 Jul 2010 23:59:13 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2AD5F4.2010306@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C095@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C095@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------000509020207090102040900" X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:59:10 -0000 This is a multi-part message in MIME format. --------------000509020207090102040900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit since the rewrite of the draft the token endpoint has become a token issuing endpoint, so revocation does not really fit into the picture. We could add another endpoint for the purpose. This endpoint should support both token types. Authorization server should be given the option to decide for which type they support revocation. BTW: Will the upoming OAuth discovery support discovery of additional capabilities/endpoints? regards, Torsten. Am 30.06.2010 17:48, schrieb Eran Hammer-Lahav: > > I didn't see consensus around it. Specifically, what should be revoked > (refresh token, access token, both, etc.). If you build consensus, > I'll gladly include it. Also, it is not clear to me how to add it to > the current token endpoint (unless we use a DELETE method). > > EHL > > *From:* Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > *Sent:* Tuesday, June 29, 2010 10:28 PM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Draft -09 > > Hi Eran, > > what about token revocation? Will you include it? > > regards, > Torsten. > > Am 29.06.2010 08:56, schrieb Eran Hammer-Lahav: > > Draft -09 is now posted. Main changes include: > > o Fixed typos, editorial changes. Thanks to Dick for his useful feedback. > > o Added token expiration example. > > o Added scope parameter to end-user authorization endpoint response > and WWW-Authenticate header. > > o Added note about parameters with empty values (same as omitted). > > o Changed parameter values to use '-' instead of '_'. Parameter > names still use '_'. > > o Changed authorization endpoint client type to response type with > values: code, token, or both. > > o Complete cleanup of error codes. Added support for error > description and URI. > > o Add initial extensibility support. > > Draft -09 represents what I consider to be the first feature complete > proposal. While it still needs much work, it has notes for open issues > and missing parts. I plan to give people 2 weeks to review and provide > extensive feedback, and will post one more draft before the 7/12 > cutoff date for the meeting. > > My goal is to collect enough feedback to declare the next draft (-10) > stable for wider implementation. If you were waiting for a stable > draft to study and provide extensive feedback, this is the draft! When > giving feedback pretend this is your last chance to making a > significant contribution or changes to the core specification. > > Please submit feedback by 7/9. > > When submitting feedback please start a new thread for each item. > Editorial commentary can be collected in one post (and please send to > the list, even if it is minor, because I tend to get the same typo > correction many times). > > Thanks, > > EHL > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------000509020207090102040900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit since the rewrite of the draft the token endpoint has become a token issuing endpoint, so revocation does not really fit into the picture. We could add another endpoint for the purpose. This endpoint should support both token types. Authorization server should be given the option to decide for which type they support revocation.

BTW: Will the upoming OAuth discovery support discovery of additional capabilities/endpoints?

regards,
Torsten.

Am 30.06.2010 17:48, schrieb Eran Hammer-Lahav:

I didn’t see consensus around it. Specifically, what should be revoked (refresh token, access token, both, etc.). If you build consensus, I’ll gladly include it. Also, it is not clear to me how to add it to the current token endpoint (unless we use a DELETE method).

 

EHL

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Tuesday, June 29, 2010 10:28 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Draft -09

 

Hi Eran,

what about token revocation? Will you include it?

regards,
Torsten.

Am 29.06.2010 08:56, schrieb Eran Hammer-Lahav:

Draft -09 is now posted. Main changes include:

 

o  Fixed typos, editorial changes. Thanks to Dick for his useful feedback.

o  Added token expiration example.

o  Added scope parameter to end-user authorization endpoint response and WWW-Authenticate header.

o  Added note about parameters with empty values (same as omitted).

o  Changed parameter values to use '-' instead of '_'.  Parameter names still use '_'.

o  Changed authorization endpoint client type to response type with values: code, token, or both.

o  Complete cleanup of error codes.  Added support for error description and URI.

o  Add initial extensibility support.

 

Draft -09 represents what I consider to be the first feature complete proposal. While it still needs much work, it has notes for open issues and missing parts. I plan to give people 2 weeks to review and provide extensive feedback, and will post one more draft before the 7/12 cutoff date for the meeting.

 

My goal is to collect enough feedback to declare the next draft (-10) stable for wider implementation. If you were waiting for a stable draft to study and provide extensive feedback, this is the draft! When giving feedback pretend this is your last chance to making a significant contribution or changes to the core specification.

 

Please submit feedback by 7/9.

 

When submitting feedback please start a new thread for each item. Editorial commentary can be collected in one post (and please send to the list, even if it is minor, because I tend to get the same typo correction many times).

 

Thanks,

 

EHL

 

 

 
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
--------------000509020207090102040900-- From mscurtescu@google.com Thu Jul 1 14:59:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A4D13A6A53 for ; Thu, 1 Jul 2010 14:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.609 X-Spam-Level: X-Spam-Status: No, score=-101.609 tagged_above=-999 required=5 tests=[AWL=0.368, 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 8w5qUphKNSp3 for ; Thu, 1 Jul 2010 14:59:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C4FD63A68BB for ; Thu, 1 Jul 2010 14:59:10 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o61LxKZt003749 for ; Thu, 1 Jul 2010 14:59:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278021561; bh=5X7ri97GSE3AmANtR4mp40I2Xp0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=mwxevTtxh1t0ihY1IIkZFPWAWGO90FGS3Us8mziF7L7RVBAc07SrxUTQuhVTGhe3q I+eY7ZUeA9BsmyVYJB0lg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=TZ4EDJJqctcev1h+mC+Qdp7sOhox1Ji3LPo/S9uZzZZW8O9Hlf+thrrMQ52GESHvB wFjLrFnGKoI7w/9URul1A== Received: from gyg8 (gyg8.prod.google.com [10.243.50.136]) by wpaz29.hot.corp.google.com with ESMTP id o61LxJYL003519 for ; Thu, 1 Jul 2010 14:59:19 -0700 Received: by gyg8 with SMTP id 8so1753173gyg.16 for ; Thu, 01 Jul 2010 14:59:19 -0700 (PDT) Received: by 10.101.134.9 with SMTP id l9mr136697ann.184.1278021559220; Thu, 01 Jul 2010 14:59:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Thu, 1 Jul 2010 14:58:59 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C528@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C528@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 1 Jul 2010 14:58:59 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:59:12 -0000 On Thu, Jul 1, 2010 at 2:52 PM, Eran Hammer-Lahav wro= te: > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Thursday, July 01, 2010 2:21 PM > >> >> 2. Greatly reduce the chances of a conflict with a query parameter >> >> used by an authz server endpoint or client redirect_uri. >> > >> > There should not be any conflict. Either it has been registered or use= s x_. >> >> There can be. Here is the example I gave earlier in another thread. >> MediaWiki uses the 'title' parameter. Some OAuth extension may register >> and use this same name and this will prevent MediWiki from being able to >> support that extension. > > I think this discussion (which we spent many days on already) boils down = to a philosophical approach to the level a new protocol should accommodate = the broken environment in which it is expected to be deployed. > > I think MediaWiki should change the way it treats the OAuth endpoints to = isolate them from the rest of the platform. When receiving an OAuth request= (with such an OAuth 'title' parameter), the platform can rename all the OA= uth parameters to oauth_ internally and proceed to add its own parameters w= ithout conflicts. When receiving an OAuth request MediaWiki will have two title parameters, the damage is already done. > While this approach might not be trivial, it is clearly possible. I think= there is a larger question of how OAuth is used in a MediaWiki installatio= n, and how it can accommodate some of the other requirements such as SSL. > > I do not consider making MediaWiki's deployment of 2.0 easier an importan= t consideration. MediaWiki is just an example. Drupal is another. My guess is that most PHP frameworks have this issue. >> >> Cons: >> >> >> >> 1. Slightly longer parameter names. >> > >> > Also, messy, ugly, opens the door to extensions without review. >> >> I don't get the last part, skipping reviews. As for beauty, that's relat= ive ;-) > > If we approve a blanket "prefix_" extension, we lose the ability to revie= w individual parameters within that prefix. I think you mentioned that the review is meant to prevent name conflicts, nothing else. Marius From torsten@lodderstedt.net Thu Jul 1 15:04: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 922313A694E for ; Thu, 1 Jul 2010 15:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=0.782, 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 y+KnC6DRqQTN for ; Thu, 1 Jul 2010 15:04:34 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by core3.amsl.com (Postfix) with ESMTP id 597DD3A6A1B for ; Thu, 1 Jul 2010 15:04:34 -0700 (PDT) Received: from p4fff04a2.dip.t-dialin.net ([79.255.4.162] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OURsC-0003Fp-1z; Fri, 02 Jul 2010 00:04:44 +0200 Message-ID: <4C2D10FB.2090308@lodderstedt.net> Date: Fri, 02 Jul 2010 00:04:43 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2D0DBA.70201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C52A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C52A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re: Versioning) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 22:04:35 -0000 ok sounds good. But AFAIK "authentication required" is already the meaning of status code 401. So why another error parameter? regards, Torsten. Am 01.07.2010 23:54, schrieb Eran Hammer-Lahav: > That's where the error parameter will be (the only supported place in -09 for a failed protected resource response). > > EHL > > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Thursday, July 01, 2010 2:51 PM >> To: Eran Hammer-Lahav >> Cc: Marius Scurtescu; Justin Richer; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re: >> Versioning) >> >> I essentially agreed, except in 3. the server should send back status code 401 >> with a WWW-Authenticate header. >> >> regards, >> Torsten. >> >> Am 01.07.2010 22:28, schrieb Eran Hammer-Lahav: >> >>> I think all servers must support the header. I don't think we can demand all >>> >> servers to support query or post parameters as that can conflict with their >> existing namespace or architecture. I suggest we: >> >>> 1. Make the "Token" scheme required in all resource servers 2. Allow >>> resource servers to support the URI query or response body 3. Specify >>> that when a request comes without the header to a server only supporting >>> >> the header, the server should respond with error=authentication_required >> to inform the client this form of authentication is not supported. >> >>> EHL >>> >>> >>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> Behalf Of Marius Scurtescu >>>> Sent: Thursday, July 01, 2010 12:48 PM >>>> To: Justin Richer >>>> Cc: oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] Versioning >>>> >>>> On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer wrote: >>>> >>>> >>>>>>> OAuth tokens as a form-encoded element in a post body? Yes. Keep >>>>>>> >> it. >> >>>>>>> >>>>>> Just curious. What use case would require that the access token is >>>>>> put in the post body as opposed to an http header when accessing a >>>>>> protected resource? >>>>>> >>>>>> >>>>> If nothing else, it parallels the use case of a GET-style query >>>>> parameter. It makes sense to have it be valid in both ways to allow >>>>> developers to put the token in with whatever other parameters >>>>> they're passing along. I've got plenty of use cases here for the >>>>> query >>>>> parameters: it's needed for cases where your client can't get any >>>>> deeper into HTTP than "hey go fetch me this URL". >>>>> >>>>> >>>> You can still use query parameters with POST. >>>> >>>> >>>> >>>> >>>>> What use case says we shouldn't do POST parameters like that? A >>>>> server wanting to do early-dispatch of a request was brought up, but >>>>> that was only in the case of handling OAuth 1 and 2 simultaneously >>>>> as I understood it. If a server's going to be doing dispatch on auth >>>>> headers and query parameters already, it seems that it's got the >>>>> wherewithal to parse a form-encoded body, too. >>>>> >>>>> >>>> Parsing the body is not trivial. Some filters do not have access to >>>> it (apache mod_redirect for example), some frameworks will allow you >>>> to access it once and then commit to a format, a decision that cannot >>>> be made by a filter (in Java see ServletRequest: getInputStream vs >>>> >> getReader vs getParameter). >> >>>> >>>> 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 torsten@lodderstedt.net Thu Jul 1 15:06: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 3DF473A694E for ; Thu, 1 Jul 2010 15:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=0.754, 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 ujFac-I1joT0 for ; Thu, 1 Jul 2010 15:06:02 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by core3.amsl.com (Postfix) with ESMTP id CA2063A692C for ; Thu, 1 Jul 2010 15:06:01 -0700 (PDT) Received: from p4fff04a2.dip.t-dialin.net ([79.255.4.162] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OURtc-0004bT-OQ; Fri, 02 Jul 2010 00:06:12 +0200 Message-ID: <4C2D1153.90507@lodderstedt.net> Date: Fri, 02 Jul 2010 00:06:11 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Marius Scurtescu References: <4C259112.2040901@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 2 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 22:06:03 -0000 you are right. So the only trustworthy way to enter credentials is an external browser? regards, Torsten. Am 28.06.2010 20:11, schrieb Marius Scurtescu: > On Fri, Jun 25, 2010 at 10:33 PM, Torsten Lodderstedt > wrote: > >> comment/question regarding the Embedded Browser scenario: Is the URL bar and >> SSL verification symbols (lock + green bar) visible in that scenario? >> Otherwise, the user has no chance to verify the identity of the IDP/OAuth >> server. So there might be problems regarding password phishing . >> > AFAIK the URL bar is not visible. > > Who would phish the end user? If it is the native app, then all bets > are off regardless, the native app can show a fake address bar if it > really wants. > > Marius > > > >> regards, >> Torsten. >> >> Am 22.06.2010 02:54, schrieb Marius Scurtescu: >> >>> Here is the wiki page: http://wiki.oauth.net/OAuth-2-for-Native-Apps >>> >>> Feel free to edit or comment. >>> >>> Marius >>> >>> >>> >>> On Wed, Jun 9, 2010 at 10:59 AM, David Recordon >>> wrote: >>> >>> >>>> Want to put this on the wiki http://wiki.oauth.net/? >>>> >>>> >>>> On Mon, Jun 7, 2010 at 12:25 PM, Marius Scurtescu >>>> wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> I attached a document that summaries how native applications can use >>>>> OAuth 2. >>>>> >>>>> Feedback more than welcome, especially if you have experience with >>>>> native apps and OAuth. >>>>> >>>>> The current Web Server and Device flows need small changes and >>>>> clarifications in order to properly support native apps, I will start >>>>> a separate thread on that. >>>>> >>>>> 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 eran@hueniverse.com Thu Jul 1 16: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 1D67D3A6A96 for ; Thu, 1 Jul 2010 16:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.328, 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 dDI0dA7af-p6 for ; Thu, 1 Jul 2010 16:17:11 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5D1F53A694D for ; Thu, 1 Jul 2010 16:17:10 -0700 (PDT) Received: (qmail 21543 invoked from network); 1 Jul 2010 23:17:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 23:17:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 1 Jul 2010 16:17:22 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Thu, 1 Jul 2010 16:17:34 -0700 Thread-Topic: [OAUTH-WG] Draft -09 Thread-Index: AcsZaKgkAKakKM6KTDupiX6NNa2+twACstaA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C563@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2AD5F4.2010306@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C095@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2D0FB1.8060608@lodderstedt.net> In-Reply-To: <4C2D0FB1.8060608@lodderstedt.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_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C563P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 23:17:18 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C563P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sounds good. Please submit a draft and we can discuss incorporating it into= core later. As for discovery, I plan to support both super-light header discovery and a= richer host-meta/XRD based discovery. As we discuss it, we will decide if = we need the heavier one. EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Thursday, July 01, 2010 2:59 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Draft -09 since the rewrite of the draft the token endpoint has become a token issuin= g endpoint, so revocation does not really fit into the picture. We could ad= d another endpoint for the purpose. This endpoint should support both token= types. Authorization server should be given the option to decide for which= type they support revocation. BTW: Will the upoming OAuth discovery support discovery of additional capab= ilities/endpoints? regards, Torsten. Am 30.06.2010 17:48, schrieb Eran Hammer-Lahav: I didn't see consensus around it. Specifically, what should be revoked (ref= resh token, access token, both, etc.). If you build consensus, I'll gladly = include it. Also, it is not clear to me how to add it to the current token = endpoint (unless we use a DELETE method). EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Tuesday, June 29, 2010 10:28 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Draft -09 Hi Eran, what about token revocation? Will you include it? regards, Torsten. Am 29.06.2010 08:56, schrieb Eran Hammer-Lahav: Draft -09 is now posted. Main changes include: o Fixed typos, editorial changes. Thanks to Dick for his useful feedback. o Added token expiration example. o Added scope parameter to end-user authorization endpoint response and WW= W-Authenticate header. o Added note about parameters with empty values (same as omitted). o Changed parameter values to use '-' instead of '_'. Parameter names sti= ll use '_'. o Changed authorization endpoint client type to response type with values:= code, token, or both. o Complete cleanup of error codes. Added support for error description an= d URI. o Add initial extensibility support. Draft -09 represents what I consider to be the first feature complete propo= sal. While it still needs much work, it has notes for open issues and missi= ng parts. I plan to give people 2 weeks to review and provide extensive fee= dback, and will post one more draft before the 7/12 cutoff date for the mee= ting. My goal is to collect enough feedback to declare the next draft (-10) stabl= e for wider implementation. If you were waiting for a stable draft to study= and provide extensive feedback, this is the draft! When giving feedback pr= etend this is your last chance to making a significant contribution or chan= ges to the core specification. Please submit feedback by 7/9. When submitting feedback please start a new thread for each item. Editorial= commentary can be collected in one post (and please send to the list, even= if it is minor, because I tend to get the same typo correction many times)= . Thanks, EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C563P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Sounds good. Please submit a draft and we can= discuss incorporating it into core later.

 

As for discovery, I plan to sup= port both super-light header discovery and a richer host-meta/XRD based dis= covery. As we discuss it, we will decide if we need the heavier one.

&nbs= p;

EHL

 

From: Torsten Lodderstedt [mailto:torsten@loddersted= t.net]
Sent: Thursday, July 01, 2010 2:59 PM
To: Eran = Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re:= [OAUTH-WG] Draft -09

 

since the rewrite of the draft t= he token endpoint has become a token issuing endpoint, so revocation does n= ot really fit into the picture. We could add another endpoint for the purpo= se. This endpoint should support both token types. Authorization server sho= uld be given the option to decide for which type they support revocation.
BTW: Will the upoming OAuth discovery support discovery of additional= capabilities/endpoints?

regards,
Torsten.

Am 30.06.2010 1= 7:48, schrieb Eran Hammer-Lahav:

I didn’t see consensus around it. Specificall= y, what should be revoked (refresh token, access token, both, etc.). If you= build consensus, I’ll gladly include it. Also, it is not clear to me= how to add it to the current token endpoint (unless we use a DELETE method= ).

=  

EHL

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Tuesd= ay, June 29, 2010 10:28 PM
To: Eran Hammer-Lahav
Cc: OA= uth WG (oauth@ietf.org)
Subject= : Re: [OAUTH-WG] Draft -09

 

Hi Eran,

what ab= out token revocation? Will you include it?

regards,
Torsten.
<= br>Am 29.06.2010 08:56, schrieb Eran Hammer-Lahav:

Draft -09 is now posted. Main changes include:

<= p class=3DMsoNormal> 

o  Fixed typos, editorial ch= anges. Thanks to Dick for his useful feedback.

o  = Added token expiration example.

<= span style=3D'font-size:9.5pt;font-family:Consolas'>o  Added scope par= ameter to end-user authorization endpoint response and WWW-Authenticate hea= der.

o  Added note about parameters with empty val= ues (same as omitted).

o  Changed parameter values= to use '-' instead of '_'.  Parameter names still use '_'.

o  Changed authorization endpoint client type to response ty= pe with values: code, token, or both.

o  Complete = cleanup of error codes.  Added support for error description and URI.<= /span>

o  Add initial extensibility support.<= /o:p>

 

Draft -09 represents what I consider to = be the first feature complete proposal. While it still needs much work, it = has notes for open issues and missing parts. I plan to give people 2 weeks = to review and provide extensive feedback, and will post one more draft befo= re the 7/12 cutoff date for the meeting.

 <= o:p>

My goal is to collect enough feedback to declare the next draf= t (-10) stable for wider implementation. If you were waiting for a stable d= raft to study and provide extensive feedback, this is the draft! When givin= g feedback pretend this is your last chance to making a significant contrib= ution or changes to the core specification.

 

Please submit feedback by 7/9.

 =

When submitting feedback please start a new thread for= each item. Editorial commentary can be collected in one post (and please s= end to the list, even if it is minor, because I tend to get the same typo c= orrection many times).

 

Thank= s,

 

EHL

=

&= nbsp;

 

&=
nbsp;
 
____________________=
___________________________
OAuth mailing list
OAuth@ietf.org
https:=
//www.ietf.org/mailman/listinfo/oauth
  =
= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C563P3PW5EX1MB01E_-- From eran@hueniverse.com Thu Jul 1 16:21: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 768763A6A96 for ; Thu, 1 Jul 2010 16:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.326, 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 Bzbg-7e143wg for ; Thu, 1 Jul 2010 16:21:20 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 797023A67EC for ; Thu, 1 Jul 2010 16:21:20 -0700 (PDT) Received: (qmail 26231 invoked from network); 1 Jul 2010 23:21:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 23:21:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Jul 2010 16:21:31 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Thu, 1 Jul 2010 16:21:43 -0700 Thread-Topic: [OAUTH-WG] register prefixes as opposed to full parameter names Thread-Index: AcsZaKrO3m33ssjHQQSzqsZ6lEdPnQACwjuw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C567@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C528@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 23:21:21 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Thursday, July 01, 2010 2:59 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter > names >=20 > On Thu, Jul 1, 2010 at 2:52 PM, Eran Hammer-Lahav > wrote: > > > >> -----Original Message----- > >> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >> Sent: Thursday, July 01, 2010 2:21 PM > > > >> >> 2. Greatly reduce the chances of a conflict with a query parameter > >> >> used by an authz server endpoint or client redirect_uri. > >> > > >> > There should not be any conflict. Either it has been registered or u= ses > x_. > >> > >> There can be. Here is the example I gave earlier in another thread. > >> MediaWiki uses the 'title' parameter. Some OAuth extension may > >> register and use this same name and this will prevent MediWiki from > >> being able to support that extension. > > > > I think this discussion (which we spent many days on already) boils dow= n to > a philosophical approach to the level a new protocol should accommodate > the broken environment in which it is expected to be deployed. > > > > I think MediaWiki should change the way it treats the OAuth endpoints t= o > isolate them from the rest of the platform. When receiving an OAuth reque= st > (with such an OAuth 'title' parameter), the platform can rename all the > OAuth parameters to oauth_ internally and proceed to add its own > parameters without conflicts. >=20 > When receiving an OAuth request MediaWiki will have two title parameters, > the damage is already done. Yes, they might need to change their platform to support it. I'm ok with th= at. >=20 > > While this approach might not be trivial, it is clearly possible. I thi= nk there is > a larger question of how OAuth is used in a MediaWiki installation, and h= ow it > can accommodate some of the other requirements such as SSL. > > > > I do not consider making MediaWiki's deployment of 2.0 easier an > important consideration. >=20 > MediaWiki is just an example. Drupal is another. My guess is that most PH= P > frameworks have this issue. And they will need to find ways to accommodate OAuth 2.0 endpoints. Every w= eb server provides sufficient tools to rewrite requests. I don't have much = sympathy for the $5 hosting user. > >> >> Cons: > >> >> > >> >> 1. Slightly longer parameter names. > >> > > >> > Also, messy, ugly, opens the door to extensions without review. > >> > >> I don't get the last part, skipping reviews. As for beauty, that's > >> relative ;-) > > > > If we approve a blanket "prefix_" extension, we lose the ability to rev= iew > individual parameters within that prefix. >=20 > I think you mentioned that the review is meant to prevent name conflicts, > nothing else. The review is meant to prevent name collision and people doing really stupi= d things. Part of name collision is also to make sure that people use prope= r names... EHL From eran@hueniverse.com Thu Jul 1 16:22: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 3C74A3A6A96 for ; Thu, 1 Jul 2010 16:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 umzfvoxMuYa0 for ; Thu, 1 Jul 2010 16:21:58 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id AF65A3A6AA1 for ; Thu, 1 Jul 2010 16:21:58 -0700 (PDT) Received: (qmail 6309 invoked from network); 1 Jul 2010 23:22:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 23:22:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 1 Jul 2010 16:22:10 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Thu, 1 Jul 2010 16:22:22 -0700 Thread-Topic: [OAUTH-WG] Support for query/body parameters (Was Re: Versioning) Thread-Index: AcsZaWvOjql6jSKDSx+muX84b+HmZgACs7gg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C569@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2D0DBA.70201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C52A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2D10FB.2090308@lodderstedt.net> In-Reply-To: <4C2D10FB.2090308@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re: Versioning) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 23:22:02 -0000 Good point. No error required. EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Thursday, July 01, 2010 3:05 PM > To: Eran Hammer-Lahav > Cc: Marius Scurtescu; Justin Richer; oauth@ietf.org > Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re: > Versioning) >=20 > ok sounds good. But AFAIK "authentication required" is already the meanin= g > of status code 401. So why another error parameter? >=20 > regards, > Torsten. >=20 > Am 01.07.2010 23:54, schrieb Eran Hammer-Lahav: > > That's where the error parameter will be (the only supported place in -= 09 > for a failed protected resource response). > > > > EHL > > > > > >> -----Original Message----- > >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > >> Sent: Thursday, July 01, 2010 2:51 PM > >> To: Eran Hammer-Lahav > >> Cc: Marius Scurtescu; Justin Richer; oauth@ietf.org > >> Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re: > >> Versioning) > >> > >> I essentially agreed, except in 3. the server should send back status > >> code 401 with a WWW-Authenticate header. > >> > >> regards, > >> Torsten. > >> > >> Am 01.07.2010 22:28, schrieb Eran Hammer-Lahav: > >> > >>> I think all servers must support the header. I don't think we can > >>> demand all > >>> > >> servers to support query or post parameters as that can conflict with > >> their existing namespace or architecture. I suggest we: > >> > >>> 1. Make the "Token" scheme required in all resource servers 2. Allow > >>> resource servers to support the URI query or response body 3. > >>> Specify that when a request comes without the header to a server > >>> only supporting > >>> > >> the header, the server should respond with > >> error=3Dauthentication_required to inform the client this form of > authentication is not supported. > >> > >>> EHL > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>> Behalf Of Marius Scurtescu > >>>> Sent: Thursday, July 01, 2010 12:48 PM > >>>> To: Justin Richer > >>>> Cc: oauth@ietf.org > >>>> Subject: Re: [OAUTH-WG] Versioning > >>>> > >>>> On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer > wrote: > >>>> > >>>> > >>>>>>> OAuth tokens as a form-encoded element in a post body? Yes. > Keep > >>>>>>> > >> it. > >> > >>>>>>> > >>>>>> Just curious. What use case would require that the access token > >>>>>> is put in the post body as opposed to an http header when > >>>>>> accessing a protected resource? > >>>>>> > >>>>>> > >>>>> If nothing else, it parallels the use case of a GET-style query > >>>>> parameter. It makes sense to have it be valid in both ways to > >>>>> allow developers to put the token in with whatever other > >>>>> parameters they're passing along. I've got plenty of use cases > >>>>> here for the query > >>>>> parameters: it's needed for cases where your client can't get any > >>>>> deeper into HTTP than "hey go fetch me this URL". > >>>>> > >>>>> > >>>> You can still use query parameters with POST. > >>>> > >>>> > >>>> > >>>> > >>>>> What use case says we shouldn't do POST parameters like that? A > >>>>> server wanting to do early-dispatch of a request was brought up, > >>>>> but that was only in the case of handling OAuth 1 and 2 > >>>>> simultaneously as I understood it. If a server's going to be doing > >>>>> dispatch on auth headers and query parameters already, it seems > >>>>> that it's got the wherewithal to parse a form-encoded body, too. > >>>>> > >>>>> > >>>> Parsing the body is not trivial. Some filters do not have access to > >>>> it (apache mod_redirect for example), some frameworks will allow > >>>> you to access it once and then commit to a format, a decision that > >>>> cannot be made by a filter (in Java see ServletRequest: > >>>> getInputStream vs > >>>> > >> getReader vs getParameter). > >> > >>>> > >>>> 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 mscurtescu@google.com Thu Jul 1 16:32: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 BC5C93A69CC for ; Thu, 1 Jul 2010 16:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.514 X-Spam-Level: X-Spam-Status: No, score=-105.514 tagged_above=-999 required=5 tests=[AWL=0.463, 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 Ll0cs-+FAclW for ; Thu, 1 Jul 2010 16:32:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BCE5F3A6407 for ; Thu, 1 Jul 2010 16:32:07 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o61NWIVR007527 for ; Thu, 1 Jul 2010 16:32:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278027139; bh=A9vYCD66S0RqPzQSpSKT35AIPOY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=h4Trs4GFvJK+AU75oZAEO9FlAQiWOIaFOlnCI10fWEtgl/Jd0ExYVHLOeTKx2QZXf crj1RpBu0i3jkKaeft9Qg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=fJqx4l090EFNNEc5zQrMQWEgbIN9ue2X5sSUoxnT31wLe9xvklCeDr72oKtEcXdYB 2KNPymIT7qNgZ5jgZrX5A== Received: from gwb1 (gwb1.prod.google.com [10.200.2.1]) by hpaq1.eem.corp.google.com with ESMTP id o61NVm6N007446 for ; Thu, 1 Jul 2010 16:32:17 -0700 Received: by gwb1 with SMTP id 1so968198gwb.27 for ; Thu, 01 Jul 2010 16:32:15 -0700 (PDT) Received: by 10.100.235.10 with SMTP id i10mr142446anh.1.1278027135221; Thu, 01 Jul 2010 16:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Thu, 1 Jul 2010 16:31:54 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C567@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C528@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C567@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 1 Jul 2010 16:31:54 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 23:32:10 -0000 On Thu, Jul 1, 2010 at 4:21 PM, Eran Hammer-Lahav wrote: > > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Thursday, July 01, 2010 2:59 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter >> names >> >> On Thu, Jul 1, 2010 at 2:52 PM, Eran Hammer-Lahav >> wrote: >> > >> >> -----Original Message----- >> >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> >> Sent: Thursday, July 01, 2010 2:21 PM >> > >> >> >> 2. Greatly reduce the chances of a conflict with a query parameter >> >> >> used by an authz server endpoint or client redirect_uri. >> >> > >> >> > There should not be any conflict. Either it has been registered or uses >> x_. >> >> >> >> There can be. Here is the example I gave earlier in another thread. >> >> MediaWiki uses the 'title' parameter. Some OAuth extension may >> >> register and use this same name and this will prevent MediWiki from >> >> being able to support that extension. >> > >> > I think this discussion (which we spent many days on already) boils down to >> a philosophical approach to the level a new protocol should accommodate >> the broken environment in which it is expected to be deployed. >> > >> > I think MediaWiki should change the way it treats the OAuth endpoints to >> isolate them from the rest of the platform. When receiving an OAuth request >> (with such an OAuth 'title' parameter), the platform can rename all the >> OAuth parameters to oauth_ internally and proceed to add its own >> parameters without conflicts. >> >> When receiving an OAuth request MediaWiki will have two title parameters, >> the damage is already done. > > Yes, they might need to change their platform to support it. I'm ok with that. That is not realistic. >> > While this approach might not be trivial, it is clearly possible. I think there is >> a larger question of how OAuth is used in a MediaWiki installation, and how it >> can accommodate some of the other requirements such as SSL. >> > >> > I do not consider making MediaWiki's deployment of 2.0 easier an >> important consideration. >> >> MediaWiki is just an example. Drupal is another. My guess is that most PHP >> frameworks have this issue. > > And they will need to find ways to accommodate OAuth 2.0 endpoints. Every web server provides sufficient tools to rewrite requests. I don't have much sympathy for the $5 hosting user. This has nothing to do with the price of hosting. On dedicated servers PHP frameworks have the same issue. Chances for a collision are still small, so I am not saying that no prefixes will break all PHP frameworks, just that the chances that some of them will have collisions is getting higher. Also, not only existing frameworks can potentially have problems. A brand new OAuth 2 server implementation may decide to use query parameters on the published endpoints, for whatever reason. They can chose names so there are no collisions with core and existing extensions but there is no guarantee that newer extension will no introduce one. We are going in circles. The only reason I brought this up again is because of the extensions, feel free to ignore this thread. Marius From jobrien@ob3solutions.com Thu Jul 1 16:30: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 263B13A6407 for ; Thu, 1 Jul 2010 16:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.921 X-Spam-Level: ** X-Spam-Status: No, score=2.921 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, 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 8ufUlhI6Poaq for ; Thu, 1 Jul 2010 16:30:37 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 32B513A6837 for ; Thu, 1 Jul 2010 16:30:32 -0700 (PDT) Received: by ewy22 with SMTP id 22so993672ewy.31 for ; Thu, 01 Jul 2010 16:30:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.34.205 with SMTP id m13mr219879ebd.23.1278027040148; Thu, 01 Jul 2010 16:30:40 -0700 (PDT) Sender: jobrien@ob3solutions.com Received: by 10.213.105.209 with HTTP; Thu, 1 Jul 2010 16:30:40 -0700 (PDT) Date: Thu, 1 Jul 2010 19:30:40 -0400 X-Google-Sender-Auth: RFvcA-DfcYFYPAsuPDYCUFIRf1I Message-ID: From: "John O'Brien" To: OAuth@ietf.org Content-Type: multipart/alternative; boundary=0015174bf010bdcc55048a5bdbd8 Subject: [OAUTH-WG] OAuth in the Government? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 23:33:07 -0000 --0015174bf010bdcc55048a5bdbd8 Content-Type: text/plain; charset=ISO-8859-1 I was wondering if there are any other government employees on this list who may be looking to leverage the OAuth Protocol in their applications. We are leveraging OAuth 2.0 (rev05) server / client it in an internal prototype we are working on and wanted to reach out to other government employees who may be active in this space to see what kind of roadblocks you may (or may not) be encountering on the information assurance / security front - simply so we could compare notes. v/r, John jobrieniii@yahoo.com http://twitter.com/jobrieniii http://www.linkedin.com/in/jobrieniii --0015174bf010bdcc55048a5bdbd8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I was wondering if there are any other government employees on this list wh= o may be looking to leverage the OAuth Protocol in their applications.
=
We are leveraging OAuth 2.0 (rev05) server / client =A0it in= an internal prototype we are working on and wanted to reach out to other g= overnment employees who may be active in this space to see what kind of roa= dblocks you may (or may not) be encountering on the information assurance /= security front - simply so we could compare notes.

v/r,
John

--0015174bf010bdcc55048a5bdbd8-- From dick.hardt@gmail.com Thu Jul 1 16:43: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 0DD253A6A96 for ; Thu, 1 Jul 2010 16:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.137, 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 9yc5bVl+MRfI for ; Thu, 1 Jul 2010 16:43:04 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id A422C3A6837 for ; Thu, 1 Jul 2010 16:43:04 -0700 (PDT) Received: by pvd12 with SMTP id 12so1378359pvd.31 for ; Thu, 01 Jul 2010 16:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=j85kxQzPf1PRYoOi6bbCEN8OFs7kf/iAmeZbQpdrH68=; b=LPUhgJQPczl9eh2+wT8W05g5ijkPJvK9qXz+zXJ7gCjqBkib9+p/A8VWj4ER2+A3jx rCUhRI31hq/dGNDb3vEwDK5XARPJJUq8g95CEcJiQY934yPSOBwFYKB+lDGWeIsqF3YV 0dF52M2WKkZmANm9YQU+pog791Oax7gibk75k= 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=nO9EB1esxOuGp6TjJH87rfBQQ+nxXiB0XOs4Ot+lN+lgDPKPu2HvXRWzIlVu/WZC4e KXJyf8jv9jxJla1FOh/EUC6C3VHcbEFOhNwhS+pqlc9aWEFEFTPbX9u9whfKDnnAc2k3 EhR8pk6/MImY/gQH1mM5/fylfSBym1cJgaMXg= Received: by 10.142.139.13 with SMTP id m13mr203987wfd.348.1278027793401; Thu, 01 Jul 2010 16:43:13 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id w8sm33037wfd.19.2010.07.01.16.43.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Jul 2010 16:43:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-126--927119470 From: Dick Hardt In-Reply-To: Date: Thu, 1 Jul 2010 16:43:11 -0700 Message-Id: References: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> To: Naitik Shah X-Mailer: Apple Mail (2.1078) Cc: OAuth WG Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 23:43:06 -0000 --Apple-Mail-126--927119470 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-07-01, at 12:52 PM, Naitik Shah wrote: > Searching for base64url does make it better. Thanks for that pointer = Dick. >=20 > We don't think base64url will work, because the most common error = we'll see is that developers forget the "url" part and just do plain = base64, and that's not sufficient because the stock set includes +. I think forgetting to url-decode is more likely than doing the wrong = base64 encoding. At least with the wrong base64 encoding, what was done = wrong is more obvious right away. The + will not be in the string. >=20 > So it will maybe work, maybe not. Maybe they'll do urlencoding after = anyways, since if they are passing this as a query param, or post data, = client libraries will take a dict and try to "do the right thing". And = we end up with pluses, and we're not quite sure if they should be = urldecoded or not. we won't have pluses >=20 > For example, this doesn't give me back what I put in: >=20 > base64_decode(urldecode(base64_encode('-+>'))) >=20 > Because the base64_encode returns something containing a +, and the = usual urldecode logic will convert this into a space. In fact, looking = at the PHP docs for base64 decode, there are a bunch of comments talking = about pluses: http://php.net/manual/en/function.base64-decode.php. >=20 > The approach I'm thinking is something like: >=20 > function getSignedToken($params, $secret) { > $json =3D json_encode($params); > // Moving the signature to be before the payload makes the = separator/split > // logic be: "everything before the first dot is the sig". also, = it's hex. why hex? ... why not base64url? > return hash_hmac('sha256', $json, $secret) . '.' . $json; > } >=20 > function parseSignedToken($token, $secret) { > list($sig, $json) =3D explode('.', $token, $limit=3D2); > if (hash_hmac('sha256', $json, $secret) !=3D=3D $sig) { > throw new Exception('Bad Sig'); > } > return json_decode($json); > } >=20 > [UNTESTED!] Where url encoding and decoding happens outside of the = signature process. >=20 > I'm not convinced adding the request as a header is going to be used = often. Headers are always sent uncompressed. I imagine signatures to be = used for those that are perf sensitive and don't want the SSL overhead. = So this minor detail will matter to them. This is especially true = because unlike OAuth1, the header doesn't just contain a signature, but = contains the entire signed payload. But there's nothing stopping us from = using the same format above for sending the payload as a header. I am unclear on what your point is.=20 The token would be included as one of the headers. This is often = preferable as it separates the authorization layer (in header) from = application layer parameters (query string or message body) >=20 > One of the arguments was wrt detecting double url encoding. Since the = thing we're signing is a JSON object, we always know it will start with = %7B and if it's double encoded, it will be %257B. So you really think a developer will remember the spot that it is not = %7B and is %257B but will NOT to use base64url? --Apple-Mail-126--927119470 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 2010-07-01, at 12:52 PM, Naitik Shah wrote:

Searching for base64url does make it better. Thanks for that pointer Dick.

We don't think base64url will work, because the most common error we'll see is that developers forget the "url" part and just do plain base64, and that's not sufficient because the stock set includes +.

I think forgetting to url-decode is more likely than doing the wrong base64 encoding. At least with the wrong base64 encoding, what was done wrong is more obvious right away. The + will not be in the string.


So it will maybe work, maybe not. Maybe they'll do urlencoding after anyways, since if they are passing this as a query param, or post data, client libraries will take a dict and try to "do the right thing". And we end up with pluses, and we're not quite sure if they should be urldecoded or not.

we won't have pluses


For example, this doesn't give me back what I put in:

  base64_decode(urldecode(base64_encode('-+>')))

The approach I'm thinking is something like:

  function getSignedToken($params, $secret) {
    $json = json_encode($params);
    // Moving the signature to be before the payload makes the separator/split
    // logic be: "everything before the first dot is the sig". also, it's hex.

why hex? ... why not base64url?

    return hash_hmac('sha256', $json, $secret) . '.' . $json;
  }

  function parseSignedToken($token, $secret) {
    list($sig, $json) = explode('.', $token, $limit=2);
    if (hash_hmac('sha256', $json, $secret) !== $sig) {
      throw new Exception('Bad Sig');
    }
    return json_decode($json);
  }

[UNTESTED!] Where url encoding and decoding happens outside of the signature process.

I'm not convinced adding the request as a header is going to be used often. Headers are always sent uncompressed. I imagine signatures to be used for those that are perf sensitive and don't want the SSL overhead. So this minor detail will matter to them. This is especially true because unlike OAuth1, the header doesn't just contain a signature, but contains the entire signed payload. But there's nothing stopping us from using the same format above for sending the payload as a header.

I am unclear on what your point is. 

The token would be included as one of the headers. This is often preferable as it separates the authorization layer (in header) from application layer parameters (query string or message body)



One of the arguments was wrt detecting double url encoding. Since the thing we're signing is a JSON object, we always know it will start with %7B and if it's double encoded, it will be %257B.

So you really think a developer will remember the spot that it is  not %7B and is %257B  but will NOT to use base64url?

--Apple-Mail-126--927119470-- From James.H.Manger@team.telstra.com Thu Jul 1 19:21: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 63E7F3A684F for ; Thu, 1 Jul 2010 19:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.915 X-Spam-Level: X-Spam-Status: No, score=0.915 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1lFVTXprG5a for ; Thu, 1 Jul 2010 19:21:10 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id 32EEF3A680C for ; Thu, 1 Jul 2010 19:21:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,524,1272808800"; d="scan'208";a="5292205" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 02 Jul 2010 12:21:13 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6030"; a="4059188" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbni.tcif.telstra.com.au with ESMTP; 02 Jul 2010 12:21:15 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Fri, 2 Jul 2010 12:21:14 +1000 From: "Manger, James H" To: "oauth@ietf.org" Date: Fri, 2 Jul 2010 12:21:13 +1000 Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZSzilmUCgY70PSRSWeKQpLs0EBgAOi+Fg Message-ID: <255B9BB34FB7D647A506DC292726F6E11265D94789@WSMSG3153V.srv.dir.telstra.com> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B6946@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C470@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] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 02:21:13 -0000 Eran said: > Why is a version better than a new scheme name? YAY! Using a new scheme name if/when we aren't using a bearer token is a great i= dea. Today OAuth2 only defines how to access a protected resource with a bearer = token [the "Token" scheme in section 5]. Assume this is standardized soon, = then in 3 years time a MAC-based mechanism is defined. There is no way it w= ould reuse the existing "Token" scheme by giving it totally different seman= tics -- in much the same way no one considered reusing the "BASIC" scheme t= o hold a nonce/timestamp/alg/signature. A new mechanism would simply pick i= ts own scheme name, eg "MAC". OAuth2 can easily prepare for this today by explicitly indicating which sch= eme a token is designed to be used with when it is issued. That is, include= a "scheme" parameter in an access token response. { "access_token":"SlAV32hkKG", "scheme":"Token", "expires_in":3600, "refresh_token":"8xLOxBtZp8" } The spec would say: "A client app MUST support the "Token" scheme"; "A clie= nt app MUST NOT use a token response if it does not support the listed sche= me". [We could make "scheme":"Token" the default if absent, but I think it is be= tter to be explicit.] Changing the scheme name from "Token" to, say, "Bearer" would help. I also support changing the query parameter name from "oauth_token". How ab= out "_authz"? We want authentication/authorization to be orthogonal to the rest of the AP= I. When we can't use the separate "Authorization" header for this purpose w= e need a parameter name that is somehow "orthogonal" to any params that are= part of the API being protected. Starting the param name with "_" is a dec= ent way to suggest this orthogonality to other "normal" API params. Suggest= ions: "_authz" or "_authz_bearer" (or "_authz_token" if the "Token" scheme = is not renamed). Eran argued that the "Token" scheme name deliberately does not include the = "OAuth" label to be generic: it can hold a token obtained in any way, not n= ecessarily using an OAuth flow. With this logic, the URI query parameter na= me holding a bearer token should also avoid the "OAuth" label. It is simply= a URI-query variant of the HTTP "Token" scheme. --=20 James Manger From rrichards@cdatazone.org Fri Jul 2 04:04: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 9E7393A67BD for ; Fri, 2 Jul 2010 04:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 RMLa3w2zH+ow for ; Fri, 2 Jul 2010 04:04:27 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by core3.amsl.com (Postfix) with ESMTP id 7FA9E3A65A6 for ; Fri, 2 Jul 2010 04:04:27 -0700 (PDT) Received: from [67.158.171.203] (helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1OUe2v-000335-AZ; Fri, 02 Jul 2010 11:04:37 +0000 Message-ID: <4C2DC7C5.2090009@cdatazone.org> Date: Fri, 02 Jul 2010 07:04:37 -0400 From: Rob Richards User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP2Go-MailScanner-Information: Please contact support@smtp2go.com for more information X-SMTP2Go-MailScanner-ID: 1OUe2v-000335-AZ X-SMTP2Go-MailScanner: Found to be clean X-SMTP2Go-MailScanner-From: rrichards@cdatazone.org Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 11:04:28 -0000 Eran Hammer-Lahav wrote: > [Replying to everything at once...] > >> -----Original Message----- >> From: Rob Richards [mailto:rrichards@cdatazone.org] >> Sent: Thursday, July 01, 2010 11:43 AM >> > > >> Exactly. While it might be needed in the future, there is a need to >> differentiate OAuth 1.0 from 2.0 on resource endpoints right now. >> Outside of requiring an oauth_version parameter (or equivalent) all other >> suggestions leave versioning as a grey area, where things can be interpreted >> one way or another with no consistency. Grey areas in specs are a bad thing. >> You end up with different languages/libraries dealing with things in >> completely different and incompatible ways because something was not >> clearly spelled out. >> > > This is an area that is clearly on the server side, not the client. Since the core specification leaves discovery out, client developers need to know what version of OAuth is supported by the server and use the right one. Without discovery, the client must know ahead of time what to do. With discovery, the client can choose the right protocol. Either way, the client never just sends a 1.0 or 2.0 requests and hopes for the best. > > On the server side, the challenge isn't that significant. When not using a header, the server can use multiple methods to differentiate the version used by the client: > > 1. Token syntax > 2. Presence of 'oauth_signature_method' > 3. Presence of 'oauth_signature' > 4. Presence of no other 'oauth_' parameter than 'oauth_token' > Never said this was hard just that it needs to be documented. > >> With this the spec needs to including some wording to explicitly define how >> to handle the case when running an endpoint supporting both OAuth >> 1.0 and 2.0 and the oauth2_token is missing then the call is handled according >> to the OAuth 1.0/a spec. Whatever is decided, be it a version parameter, the >> use of oauth2_token or the check for the existence of the >> oauth_signature_method parameter, etc///, the spec needs to define and >> be explicit on how a resource endpoint determines between a 1.0 and 2.0 call >> when both are supported. >> > > The damage done by interpreting a malformed 1.0 request (the odd attempt to use 1.0 by only including 'oauth_token') is at most returning an 'invalid-token' response. I hope every server developer understands that they should not share tokens between 1.0 and 2.0 with completely different security properties. > Still the issue that different error codes returned which a client may handle differently. > I think there are more issue with regard to 1.0 to 2.0 migration that should be addressed, and I have asked those who care about this to propose a draft. Given that such a draft will not be useful for a long time, given that the vast majority of OAuth implementation 1-2 years from now will be 2.0, I do not want to include it in the core specification. > > In order for your argument to stand, you need to show how the current setup leads to interoperability problems. Given the 4 options above, and the fact that a malformed 1.0 request will still fail, I do not agree that interop is affected. > > > OAuth is a service that my company provides to other companies and we will need to run both versions in parallel for many of the customers. There are other companies out there who provide similar service, so this isn't just an isolated problem. We may be transitioning customers to/from our service and the behaviors of the systems need to be the same pre and post migration. There is also the WTF factor for developers. If I make calls to 2 providers (1.0 client), each of which is missing the oauth_signature, I would expect the same response back. An error that its missing a required signature. If one of the providers interprets a missing signature as meaning the call is a 2.0 based call then it will return back a different error code. I would expect that if I implemented 2 independent systems based on a spec they would operate and behave the exact same way, otherwise you can just throw the spec in the pile with the rest of them that have ambiguous sections left to interpretation and cause for argument over who implemented what correctly in their system. Rob From eran@hueniverse.com Fri Jul 2 07:38: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 E05BF3A68D5 for ; Fri, 2 Jul 2010 07:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.321, 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 MCa9B0WKYeTK for ; Fri, 2 Jul 2010 07:38:38 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B78F83A6876 for ; Fri, 2 Jul 2010 07:38:37 -0700 (PDT) Received: (qmail 28576 invoked from network); 2 Jul 2010 14:38:48 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Jul 2010 14:38:48 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 2 Jul 2010 07:38:42 -0700 From: Eran Hammer-Lahav To: Rob Richards Date: Fri, 2 Jul 2010 07:38:55 -0700 Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsZ1l8SKd5ijVW2S3yAy412OXvPNAAHZZ6g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2DC7C5.2090009@cdatazone.org> In-Reply-To: <4C2DC7C5.2090009@cdatazone.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@ietf.org" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 14:38:50 -0000 Hi Rob, I agree with you that a migration spec is important - please write one. As for every provider returning the same error code, I don't think that thi= s will always be the case as some providers will return invalid-request on = other security related errors to reduce the amount of information they retu= rn, or because they support different extensions, etc. The fact that both r= equest fail is really the only significant consistency needed. I don't agree that the 2.0 core specification needs to cover 1.0 issues. Th= at includes migrating from 1.0 to 2.0, supporting both, etc. EHL > -----Original Message----- > From: Rob Richards [mailto:rrichards@cdatazone.org] > Sent: Friday, July 02, 2010 4:05 AM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Versioning >=20 > Eran Hammer-Lahav wrote: > > [Replying to everything at once...] > > > >> -----Original Message----- > >> From: Rob Richards [mailto:rrichards@cdatazone.org] > >> Sent: Thursday, July 01, 2010 11:43 AM > >> > > > > > >> Exactly. While it might be needed in the future, there is a need to > >> differentiate OAuth 1.0 from 2.0 on resource endpoints right now. > >> Outside of requiring an oauth_version parameter (or equivalent) all > >> other suggestions leave versioning as a grey area, where things can > >> be interpreted one way or another with no consistency. Grey areas in > specs are a bad thing. > >> You end up with different languages/libraries dealing with things in > >> completely different and incompatible ways because something was not > >> clearly spelled out. > >> > > > > This is an area that is clearly on the server side, not the client. Sin= ce the > core specification leaves discovery out, client developers need to know w= hat > version of OAuth is supported by the server and use the right one. Withou= t > discovery, the client must know ahead of time what to do. With discovery, > the client can choose the right protocol. Either way, the client never ju= st > sends a 1.0 or 2.0 requests and hopes for the best. > > > > On the server side, the challenge isn't that significant. When not usin= g a > header, the server can use multiple methods to differentiate the version > used by the client: > > > > 1. Token syntax > > 2. Presence of 'oauth_signature_method' > > 3. Presence of 'oauth_signature' > > 4. Presence of no other 'oauth_' parameter than 'oauth_token' > > >=20 > Never said this was hard just that it needs to be documented. > > > >> With this the spec needs to including some wording to explicitly > >> define how to handle the case when running an endpoint supporting > >> both OAuth > >> 1.0 and 2.0 and the oauth2_token is missing then the call is handled > >> according to the OAuth 1.0/a spec. Whatever is decided, be it a > >> version parameter, the use of oauth2_token or the check for the > >> existence of the oauth_signature_method parameter, etc///, the spec > >> needs to define and be explicit on how a resource endpoint determines > >> between a 1.0 and 2.0 call when both are supported. > >> > > > > The damage done by interpreting a malformed 1.0 request (the odd > attempt to use 1.0 by only including 'oauth_token') is at most returning = an > 'invalid-token' response. I hope every server developer understands that > they should not share tokens between 1.0 and 2.0 with completely differen= t > security properties. > > > Still the issue that different error codes returned which a client may ha= ndle > differently. > > I think there are more issue with regard to 1.0 to 2.0 migration that s= hould > be addressed, and I have asked those who care about this to propose a dra= ft. > Given that such a draft will not be useful for a long time, given that th= e vast > majority of OAuth implementation 1-2 years from now will be 2.0, I do not > want to include it in the core specification. > > > > In order for your argument to stand, you need to show how the current > setup leads to interoperability problems. Given the 4 options above, and = the > fact that a malformed 1.0 request will still fail, I do not agree that in= terop is > affected. > > > > > > > OAuth is a service that my company provides to other companies and we wil= l > need to run both versions in parallel for many of the customers. > There are other companies out there who provide similar service, so this = isn't > just an isolated problem. We may be transitioning customers to/from our > service and the behaviors of the systems need to be the same pre and post > migration. > There is also the WTF factor for developers. If I make calls to 2 provide= rs (1.0 > client), each of which is missing the oauth_signature, I would expect the > same response back. An error that its missing a required signature. If on= e of > the providers interprets a missing signature as meaning the call is a 2.0= based > call then it will return back a different error code. >=20 > I would expect that if I implemented 2 independent systems based on a spe= c > they would operate and behave the exact same way, otherwise you can just > throw the spec in the pile with the rest of them that have ambiguous > sections left to interpretation and cause for argument over who > implemented what correctly in their system. >=20 > Rob From Dorothy.Gellert@InterDigital.com Fri Jul 2 08:44: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 487243A67B2 for ; Fri, 2 Jul 2010 08:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, 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 ewjwvook0bKe for ; Fri, 2 Jul 2010 08:44:52 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 488373A6452 for ; Fri, 2 Jul 2010 08:44:52 -0700 (PDT) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jul 2010 11:45:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB19FD.896EC51A" Date: Fri, 2 Jul 2010 11:45:02 -0400 Message-ID: <61CAF342FE1EE34EAC8FB19B765914000F280E73@SABRE.InterDigital.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Charter? Thread-Index: AcsZ/Yi6uU3Hxiv2SYeCm2z7Ftjp4w== From: "Gellert, Dorothy" To: , , X-OriginalArrivalTime: 02 Jul 2010 15:45:03.0279 (UTC) FILETIME=[89663BF0:01CB19FD] Subject: [OAUTH-WG] Updated Charter? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 15:44:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB19FD.896EC51A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hannes and Blaine, =20 Is it possible to get an updated charter before the next IETF? I noticed the milestones are from 2009. It would help understand the progress and goals of the WG! =20 Thanks, Dorothy =20 ------_=_NextPart_001_01CB19FD.896EC51A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hannes and Blaine,

 

Is it possible to get an updated charter before the = next IETF?   I noticed the milestones are from 2009.

It would help understand the progress and goals of = the WG!

 

Thanks,

Dorothy

 

------_=_NextPart_001_01CB19FD.896EC51A-- From diogo.borges.almeida@gmail.com Fri Jul 2 08:51:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65723A681C for ; Fri, 2 Jul 2010 08:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f893l6oR9os8 for ; Fri, 2 Jul 2010 08:51:26 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 756833A6802 for ; Fri, 2 Jul 2010 08:51:26 -0700 (PDT) Received: by wwb24 with SMTP id 24so443864wwb.13 for ; Fri, 02 Jul 2010 08:51:33 -0700 (PDT) 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:date:cc:content-transfer-encoding:message-id :references:to:x-mailer; bh=P9KABxPcZaxOGgHpTDywvgjWJ9Si8bRLG3QdiD+uVHI=; b=xo33UxYFX4bNT8bnM0NlIS47ZYGzdqFhgOAKErsW/tQ0iNxuuUQiIc3Po5sg/LoOQo jvd8cbVsOY3qV0PZog5ntLvpC7vJaVunAC09lZhgF+HYoSQPdcJSKBZV04qxsah5IbXx J9FsF2fu97ZNAY97ceaSo04tSq8hoSzmZyQwo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=gBNo/1NHmleDe9RxEWUWN6EEP9E2oC5NjZTZr37zEPvg6uuCJLYJCezj4qOmQKphLx fmyUN4vojLM0cF12OZ22T/ITDm6LV5N+e7M0GhuWcLOoogpBxtOnZYSAGoxbCs8Bx+5F qq/FEy0NXwe7cHWFp6ksrKhuhnWgnBIlcoat8= Received: by 10.213.4.138 with SMTP id 10mr4204983ebr.48.1278085892614; Fri, 02 Jul 2010 08:51:32 -0700 (PDT) Received: from [172.20.10.57] ([62.28.14.10]) by mx.google.com with ESMTPS id a48sm6632973eei.1.2010.07.02.08.51.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Jul 2010 08:51:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Diogo Almeida Date: Fri, 2 Jul 2010 16:51:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4D3A5EF5-CC38-405A-85F7-7E24B957BA44@gmail.com> References: <402D29DB-A3F5-48C5-9654-543B7F6D6356@gmail.com> To: oauth@ietf.org X-Mailer: Apple Mail (2.1081) Cc: flatter@gmail.com Subject: [OAUTH-WG] Authorization Response "scope" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 15:51:28 -0000 Good afternoon, We're in the process of implementing an open-source Ruby OAuth 2 (draft = 09) server, which will be made available at = http://github.com/aflatter/oauth2-ruby. During our draft 09 analysis we've noticed that the OPTIONAL scope sent = by the client in the Authorization Request is disconnected from the = Authorization Response scope in a way that, in our opinion, makes it = hard for the client to know if his requested scope was met or not. For example, consider a scenario where a client issues an authorization = code request to the authorization server, including in that request the = scope "friends photos videos". However, the resource owner only = authorizes the access to the friends list, thus, in our opinion, the = authorization server MUST send an authorization response containing the = code and the following scope "friends". Also, should the authorization server wish to append other scopes, it = should be free to do so, per current draft specification. In that = regard, it would be possible for the response to have the following = scope: "friends extended_user_info". In light of this opinion, we enclose the following text change request = regarding draft 9 section 3.1 scope parameter: scope REQUIRED if it has been passed in the authorization request, = otherwise OPTIONAL. This parameter delimits the scope of the access token as an = unordered list of space-delimited strings, each adding an additional access range = to the requested scope. The value of the "scope" parameter is defined by the = authorization server and MUST take into account the "scope" requested in the = authorization request by setting the authorization response "scope" parameter to the values to which = the token grants access. Furthermore, the authorization server can add any other values = deemed necessary to determine response scope. Best regards, Diogo Almeida From mscurtescu@google.com Fri Jul 2 09:02: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 E71C53A68D6 for ; Fri, 2 Jul 2010 09:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.532 X-Spam-Level: X-Spam-Status: No, score=-105.532 tagged_above=-999 required=5 tests=[AWL=0.445, 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 WSPz8CmjxIMF for ; Fri, 2 Jul 2010 09:02:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 817B23A68B9 for ; Fri, 2 Jul 2010 09:02:57 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o62G38cS015981 for ; Fri, 2 Jul 2010 09:03:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278086589; bh=DleqsKyKQcUKhuj1Wz3tjOWV0DE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=IWFqYe+G1tpSoCKaTaOiWaMqnUKpHGTpq7a5odMT/ceMvgW06fr1njLraAXDonTlS /uWVUCfJw6wd31xKLeN/Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=Staj+x7vzXpMsPf+/C3TRTEwbK4Fohn3iI+vVsaidJrQr6nPdVeh/OAQ7jg4VPcpP hr1PE/7EKyStxnp1fS1Kw== Received: from yxt3 (yxt3.prod.google.com [10.190.5.195]) by kpbe12.cbf.corp.google.com with ESMTP id o62G37rZ030623 for ; Fri, 2 Jul 2010 09:03:07 -0700 Received: by yxt3 with SMTP id 3so470197yxt.6 for ; Fri, 02 Jul 2010 09:03:07 -0700 (PDT) Received: by 10.100.30.13 with SMTP id d13mr1092291and.251.1278086587238; Fri, 02 Jul 2010 09:03:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Fri, 2 Jul 2010 09:02:47 -0700 (PDT) In-Reply-To: <4D3A5EF5-CC38-405A-85F7-7E24B957BA44@gmail.com> References: <402D29DB-A3F5-48C5-9654-543B7F6D6356@gmail.com> <4D3A5EF5-CC38-405A-85F7-7E24B957BA44@gmail.com> From: Marius Scurtescu Date: Fri, 2 Jul 2010 09:02:47 -0700 Message-ID: To: Diogo Almeida Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: flatter@gmail.com, oauth@ietf.org Subject: Re: [OAUTH-WG] Authorization Response "scope" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 16:02:59 -0000 If the scopes granted by the authz server are exactly the ones requested by the client then I don't see the need for the authz server to send a scope parameter. I think the authz server should send the scope parameter if the granted scopes are different from the requested ones, or if there was no scope parameter on the request. Marius On Fri, Jul 2, 2010 at 8:51 AM, Diogo Almeida wrote: > Good afternoon, > > We're in the process of implementing an open-source Ruby OAuth 2 (draft 0= 9) server, which will be made available at http://github.com/aflatter/oauth= 2-ruby. > > During our draft 09 analysis we've noticed that the OPTIONAL scope sent b= y the client in the Authorization Request is disconnected from the Authoriz= ation Response scope in a way that, in our opinion, makes it hard for the c= lient to know if his requested scope was met or not. > > For example, consider a scenario where a client issues an authorization c= ode request to the authorization server, including in that request the scop= e "friends photos videos". However, the resource owner only authorizes the = access to the friends list, thus, in our opinion, the authorization server = MUST send an authorization response containing the code and the following s= cope "friends". > > Also, should the authorization server wish to append other scopes, it sho= uld be free to do so, per current draft specification. In that regard, it w= ould be possible for the response to have the following scope: "friends ext= ended_user_info". > > In light of this opinion, we enclose the following text change request re= garding draft 9 section 3.1 scope parameter: > > =A0 scope > =A0 =A0 =A0 =A0 REQUIRED if it has been passed in the authorization reque= st, otherwise OPTIONAL. > =A0 =A0 =A0 =A0 This parameter delimits the scope of the access token as = an unordered list of > =A0 =A0 =A0 =A0 space-delimited strings, each adding an additional access= range to the requested > =A0 =A0 =A0 =A0 scope. > =A0 =A0 =A0 =A0 The value of the "scope" parameter is defined by the auth= orization server and > =A0 =A0 =A0 =A0 MUST take into account the "scope" requested in the autho= rization request by setting the > =A0 =A0 =A0 =A0 authorization response "scope" parameter to the values to= which the token grants access. > =A0 =A0 =A0 =A0 Furthermore, the authorization server can add any other v= alues deemed necessary > =A0 =A0 =A0 =A0 to determine response scope. > > Best regards, > Diogo Almeida > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From diogo.borges.almeida@gmail.com Fri Jul 2 09:22: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 082583A68D6 for ; Fri, 2 Jul 2010 09:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptQyAMcWjUQ9 for ; Fri, 2 Jul 2010 09:22:44 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 130143A67D4 for ; Fri, 2 Jul 2010 09:22:43 -0700 (PDT) Received: by wwb24 with SMTP id 24so456532wwb.13 for ; Fri, 02 Jul 2010 09:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=wvdyeKLESUNyTm/WOL3NFjte+iW4tsZH+ybC+fWlQL8=; b=mcH1x3Cl8Yi0YnTnS2xrmZ7tuNUmk7xHAg907sX4yGPDPxxSwDEx68QfqwZjkU6l8a LFlnoU7kZjFO2GDZOkWEUuC5J83oi6BUF2mH58RwOJAi7nksx4Is6IUOQYS4Q6ikkW0h n4w7nWR477eqWFDPt4IC32W5LEMsb6RVKxcWo= 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=P/LfZOkQA8H7t+ZUoO93XSTjhy7A/KmkTOOivderM7anZNMPfB0/pQ/qWWnBUczf7i Lpnqyh6JLTX0UxoSL8S/ws7YIByCaKyJKDT4ufAl9nxLEt3W/bCTvp2W66QpCicwEXgF +nM8WVZMb4b1lK2PmZAwwxJFIg1Nq8jl0CGDY= Received: by 10.227.127.208 with SMTP id h16mr578824wbs.12.1278087772510; Fri, 02 Jul 2010 09:22:52 -0700 (PDT) Received: from [172.20.10.57] ([62.28.14.10]) by mx.google.com with ESMTPS id i25sm5764993wbi.16.2010.07.02.09.22.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Jul 2010 09:22:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Diogo Almeida In-Reply-To: Date: Fri, 2 Jul 2010 17:22:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <21AF3452-B1AF-40CE-A72C-5923FEB0543C@gmail.com> References: <402D29DB-A3F5-48C5-9654-543B7F6D6356@gmail.com> <4D3A5EF5-CC38-405A-85F7-7E24B957BA44@gmail.com> To: Marius Scurtescu X-Mailer: Apple Mail (2.1081) Cc: flatter@gmail.com, oauth@ietf.org Subject: Re: [OAUTH-WG] Authorization Response "scope" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 16:22:46 -0000 Hello Marius, Thanks for your feedback regarding this issue. You make a valid point, stating that the authorization server should = only send the scope if it differs from the requested one. However, I = would like to enclose two notes regarding that approach: * If I understand the 09 draft correctly, the omission of the = authorization response scope has no implicit meaning, thus a change to = the spec would still have to made * =46rom an authorization server implementer point of view, I find that = enforcing the server to explicitly take into account the requester's = scope removes ambiguity from the messages / flow without any significant = overhead Best regards, Diogo Almeida On Jul 2, 2010, at 5:02 PM, Marius Scurtescu wrote: > If the scopes granted by the authz server are exactly the ones > requested by the client then I don't see the need for the authz server > to send a scope parameter. >=20 > I think the authz server should send the scope parameter if the > granted scopes are different from the requested ones, or if there was > no scope parameter on the request. >=20 > Marius >=20 >=20 >=20 > On Fri, Jul 2, 2010 at 8:51 AM, Diogo Almeida > wrote: >> Good afternoon, >>=20 >> We're in the process of implementing an open-source Ruby OAuth 2 = (draft 09) server, which will be made available at = http://github.com/aflatter/oauth2-ruby. >>=20 >> During our draft 09 analysis we've noticed that the OPTIONAL scope = sent by the client in the Authorization Request is disconnected from the = Authorization Response scope in a way that, in our opinion, makes it = hard for the client to know if his requested scope was met or not. >>=20 >> For example, consider a scenario where a client issues an = authorization code request to the authorization server, including in = that request the scope "friends photos videos". However, the resource = owner only authorizes the access to the friends list, thus, in our = opinion, the authorization server MUST send an authorization response = containing the code and the following scope "friends". >>=20 >> Also, should the authorization server wish to append other scopes, it = should be free to do so, per current draft specification. In that = regard, it would be possible for the response to have the following = scope: "friends extended_user_info". >>=20 >> In light of this opinion, we enclose the following text change = request regarding draft 9 section 3.1 scope parameter: >>=20 >> scope >> REQUIRED if it has been passed in the authorization request, = otherwise OPTIONAL. >> This parameter delimits the scope of the access token as an = unordered list of >> space-delimited strings, each adding an additional access = range to the requested >> scope. >> The value of the "scope" parameter is defined by the = authorization server and >> MUST take into account the "scope" requested in the = authorization request by setting the >> authorization response "scope" parameter to the values to = which the token grants access. >> Furthermore, the authorization server can add any other = values deemed necessary >> to determine response scope. >>=20 >> Best regards, >> Diogo Almeida >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 From andrewarnott@gmail.com Fri Jul 2 09:25: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 33DC73A6911 for ; Fri, 2 Jul 2010 09:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=2.601] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vb9or1djc+DL for ; Fri, 2 Jul 2010 09:25:55 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 4FFF13A6902 for ; Fri, 2 Jul 2010 09:25:55 -0700 (PDT) Received: by yxm8 with SMTP id 8so530670yxm.31 for ; Fri, 02 Jul 2010 09:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=TXWpHhV+ZvMej0eH3ZBkocgzEYc82KVS5wfO1yPnT6c=; b=pDFuFBvgW2kwpC1leBYO/CJThUulLUoN2mzpmu/wj9W20aC0PIBsLgSPE59I6BFPmU +vl29zqnTy6XkcLocLWMhUK8liR/0+xBjqhTGlasEZu8Q8QJK3NqZ5+R65q/2GY9/43F 2kQWGwAph5yqObnazMv1fm8r1ZrUHCKbne6vQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KH0Au0vZe0ALWuNWra+YaIBBP3zktzsURAjwwf8aZ0HbZsk95bg6VbslCsEWJ1bhPr hSsSEIPQqwhcJrpVtL8zZFpX5kR0papSYFMhdwAufErzLnfWmTcHPTTkUmf2tOUWt3Tp hJ6WehoEFcaAfvsnIA3JPFnvO5MKa4UQNe1Ak= MIME-Version: 1.0 Received: by 10.100.95.8 with SMTP id s8mr1028840anb.248.1278087962383; Fri, 02 Jul 2010 09:26:02 -0700 (PDT) Received: by 10.150.92.8 with HTTP; Fri, 2 Jul 2010 09:26:02 -0700 (PDT) Date: Fri, 2 Jul 2010 09:26:02 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=0016e64601b2fd5701048a6a0af1 Subject: [OAUTH-WG] End user auth response code-and-token's scope parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 16:25:56 -0000 --0016e64601b2fd5701048a6a0af1 Content-Type: text/plain; charset=ISO-8859-1 > If the response type is code-and-token, the authorization server adds the > codeand state parameters to the redirection URI query component and the > access_token, scope, and expires_in to the redirection URI fragment using > theapplication/x-www-form-urlencoded format as defined by... Since the scope applies equally to both the code and access_token parameters, it seems that scope should be included in the URI query part so it is available to the web server as well as the user-agent. While the scope remains in the fragment, the client's web server won't know whether the full scope it requested was actually granted. Was there an advantage to including the scope only in the #fragment, or was this just an oversight? Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --0016e64601b2fd5701048a6a0af1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

If the response type is=A0<= tt style=3D"color: rgb(0, 51, 102); font-family: 'Courier New', Cou= rier, monospace; font-size: small; ">code-and-token, the authorization= server adds the=A0codeand=A0state=A0parameters to the redirecti= on URI query component and theaccess_= token,=A0scope, and=A0expires_in=A0to the redirection URI f= ragment using theapplication/x-www-fo= rm-urlencoded=A0format as defined by...

Since the scope applies equally to both the code and access_= token parameters, it seems that scope should be included in the URI query p= art so it is available to the web server as well as the user-agent. =A0Whil= e the scope remains in the fragment, the client's web server won't = know whether the full scope it requested was actually granted.

Was there an advantage to including the scope only in the #f= ragment, or was this just an oversight?

Thanks.

--
Andrew Arnott
"I [may] not agree wi= th what you have to say, but I'll defend to the death your right to say= it." - S. G. Tallentyre
--0016e64601b2fd5701048a6a0af1-- From eran@hueniverse.com Fri Jul 2 09:27:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB4B3A6914 for ; Fri, 2 Jul 2010 09:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, 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 v5ycUqCX2Bvq for ; Fri, 2 Jul 2010 09:27:00 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 908763A6910 for ; Fri, 2 Jul 2010 09:27:00 -0700 (PDT) Received: (qmail 25510 invoked from network); 2 Jul 2010 16:27:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Jul 2010 16:27:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 2 Jul 2010 09:27:10 -0700 From: Eran Hammer-Lahav To: Diogo Almeida , Marius Scurtescu Date: Fri, 2 Jul 2010 09:27:24 -0700 Thread-Topic: [OAUTH-WG] Authorization Response "scope" parameter Thread-Index: AcsaAtdfCQGqmN/sS+uPJ7FaCpZgygAAF/Eg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6C1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <402D29DB-A3F5-48C5-9654-543B7F6D6356@gmail.com> <4D3A5EF5-CC38-405A-85F7-7E24B957BA44@gmail.com> <21AF3452-B1AF-40CE-A72C-5923FEB0543C@gmail.com> In-Reply-To: <21AF3452-B1AF-40CE-A72C-5923FEB0543C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "flatter@gmail.com" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Authorization Response "scope" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 16:27:02 -0000 Scope is an optional feature of a protocol. The server is free to express t= he granted scope in any way it deems appropriate (that is, omit it, include= it as requested by the client, specify another granted scope). No changes = are necessary. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Diogo Almeida > Sent: Friday, July 02, 2010 9:23 AM > To: Marius Scurtescu > Cc: flatter@gmail.com; oauth@ietf.org > Subject: Re: [OAUTH-WG] Authorization Response "scope" parameter >=20 > Hello Marius, >=20 > Thanks for your feedback regarding this issue. >=20 > You make a valid point, stating that the authorization server should only= send > the scope if it differs from the requested one. However, I would like to > enclose two notes regarding that approach: >=20 > * If I understand the 09 draft correctly, the omission of the authorizati= on > response scope has no implicit meaning, thus a change to the spec would s= till > have to made >=20 > * From an authorization server implementer point of view, I find that > enforcing the server to explicitly take into account the requester's scop= e > removes ambiguity from the messages / flow without any significant > overhead >=20 > Best regards, > Diogo Almeida >=20 >=20 > On Jul 2, 2010, at 5:02 PM, Marius Scurtescu wrote: >=20 > > If the scopes granted by the authz server are exactly the ones > > requested by the client then I don't see the need for the authz server > > to send a scope parameter. > > > > I think the authz server should send the scope parameter if the > > granted scopes are different from the requested ones, or if there was > > no scope parameter on the request. > > > > Marius > > > > > > > > On Fri, Jul 2, 2010 at 8:51 AM, Diogo Almeida > > wrote: > >> Good afternoon, > >> > >> We're in the process of implementing an open-source Ruby OAuth 2 > (draft 09) server, which will be made available at > http://github.com/aflatter/oauth2-ruby. > >> > >> During our draft 09 analysis we've noticed that the OPTIONAL scope sen= t > by the client in the Authorization Request is disconnected from the > Authorization Response scope in a way that, in our opinion, makes it hard= for > the client to know if his requested scope was met or not. > >> > >> For example, consider a scenario where a client issues an authorizatio= n > code request to the authorization server, including in that request the s= cope > "friends photos videos". However, the resource owner only authorizes the > access to the friends list, thus, in our opinion, the authorization serve= r MUST > send an authorization response containing the code and the following scop= e > "friends". > >> > >> Also, should the authorization server wish to append other scopes, it > should be free to do so, per current draft specification. In that regard,= it > would be possible for the response to have the following scope: "friends > extended_user_info". > >> > >> In light of this opinion, we enclose the following text change request > regarding draft 9 section 3.1 scope parameter: > >> > >> scope > >> REQUIRED if it has been passed in the authorization request, > otherwise OPTIONAL. > >> This parameter delimits the scope of the access token as an > unordered list of > >> space-delimited strings, each adding an additional access rang= e to the > requested > >> scope. > >> The value of the "scope" parameter is defined by the authoriza= tion > server and > >> MUST take into account the "scope" requested in the authorizat= ion > request by setting the > >> authorization response "scope" parameter to the values to whic= h the > token grants access. > >> Furthermore, the authorization server can add any other values > deemed necessary > >> to determine response scope. > >> > >> Best regards, > >> Diogo Almeida > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Jul 2 09:31: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 9C1743A6912 for ; Fri, 2 Jul 2010 09:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.316, 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 q+G+cBMLwbOy for ; Fri, 2 Jul 2010 09:31:05 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 0EC673A6910 for ; Fri, 2 Jul 2010 09:30:54 -0700 (PDT) Received: (qmail 26074 invoked from network); 2 Jul 2010 16:31:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Jul 2010 16:31:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 2 Jul 2010 09:30:55 -0700 From: Eran Hammer-Lahav To: Andrew Arnott , "OAuth WG (oauth@ietf.org)" Date: Fri, 2 Jul 2010 09:31:10 -0700 Thread-Topic: [OAUTH-WG] End user auth response code-and-token's scope parameter Thread-Index: AcsaA0/lfvJWCNNMTuS0DYUJlP7eywAADsnA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6C6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6C6P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] End user auth response code-and-token's scope parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 16:31:29 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6C6P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scope is specific to the access token, not the code. In fact, I expect some= providers to issue an access token with a lesser scope than that provided = when exchanging the authorization code later (which will include another sc= ope). This is because the authorization server can authenticate the client = when using the authorization code and provide greater access. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrew Arnott Sent: Friday, July 02, 2010 9:26 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] End user auth response code-and-token's scope parameter If the response type is code-and-token, the authorization server adds the c= odeand state parameters to the redirection URI query component and theacces= s_token, scope, and expires_in to the redirection URI fragment using theapp= lication/x-www-form-urlencoded format as defined by... Since the scope applies equally to both the code and access_token parameter= s, it seems that scope should be included in the URI query part so it is av= ailable to the web server as well as the user-agent. While the scope remai= ns in the fragment, the client's web server won't know whether the full sco= pe it requested was actually granted. Was there an advantage to including the scope only in the #fragment, or was= this just an oversight? Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6C6P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scope is = specific to the access token, not the code. In fact, I expect some provider= s to issue an access token with a lesser scope than that provided when exch= anging the authorization code later (which will include another scope). Thi= s is because the authorization server can authenticate the client when usin= g the authorization code and provide greater access.

<= p class=3DMsoNormal> 

EHL

 

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew ArnottSent: Friday, July 02, 2010 9:26 AM
To: OAuth WG (oauth@= ietf.org)
Subject: [OAUTH-WG] End user auth response code-and-tok= en's scope parameter

=  

 

<= blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in= 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'>

If the response type is code-and-token, = the authorization server adds the codeand = state=  parameters to the redirection URI query component and theaccess_token, scope, and expires_in to the re= direction URI fragment using theapplication/x-www-form-urlencoded&= nbsp;format as defined by...

=

 

Since = the scope applies equally to both the code and access_token parameters, it = seems that scope should be included in the URI query part so it is availabl= e to the web server as well as the user-agent.  While the scope remain= s in the fragment, the client's web server won't know whether the full scop= e it requested was actually granted.

 

Was there an advanta= ge to including the scope only in the #fragment, or was this just an oversi= ght?

 

Thanks.


--
Andrew Arnott
"I [may] not agree with= what you have to say, but I'll defend to the death your right to say it.&q= uot; - S. G. Tallentyre

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6C6P3PW5EX1MB01E_-- From stpeter@stpeter.im Fri Jul 2 09:42: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 200E13A68D6 for ; Fri, 2 Jul 2010 09:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUGtAZ+X2I0m for ; Fri, 2 Jul 2010 09:42:50 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 39D073A68F2 for ; Fri, 2 Jul 2010 09:42:50 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 162BA40E26; Fri, 2 Jul 2010 10:43:01 -0600 (MDT) Message-ID: <4C2E1713.9070904@stpeter.im> Date: Fri, 02 Jul 2010 10:42:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Gellert, Dorothy" References: <61CAF342FE1EE34EAC8FB19B765914000F280E73@SABRE.InterDigital.com> In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000F280E73@SABRE.InterDigital.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010003020408090607020005" Cc: Hannes.Tschofenig@gmx.net, OAuth WG Subject: Re: [OAUTH-WG] Updated Charter? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 16:42:52 -0000 This is a cryptographically signed message in MIME format. --------------ms010003020408090607020005 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/2/10 9:45 AM, Gellert, Dorothy wrote: > Hi Hannes and Blaine, >=20 > Is it possible to get an updated charter before the next IETF? I > noticed the milestones are from 2009. >=20 > It would help understand the progress and goals of the WG! Hi Dorothy, You're right that a re-charter needs to be done. I'll work with Hannes and Blaine on that. We'd probably have proposed charter text for discussion at the next IETF meeting but would not have time to complete the recharter by then, because there's simply not enough time to get that done in the next ~3 weeks. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms010003020408090607020005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDcwMjE2NDI1OVowIwYJKoZIhvcNAQkEMRYEFKDHVo2Lc8aiUFkeoOvL fGcOiPoGMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEASbaiqfzmilQz/RdzIMOrZIxSx0uOXLJkXSlR4zNv U7qVeL9DaxypUeSbRa4ijtY9WF5ZX4nCxdoqSluMtPV8ofKc7gL4mcyMpBMKerJxmCv5IpKI 1XPUFDY00jf2SGKdAeWcDrMpi2jQzjV07jAa6IZVLJwFShPWbVkmdL8WQdtfxqH+3iEhBGHo rlf2n97fO6nKET6gmGtl4sdMVGfSkaqRO/PP7StBG4pW2sMmueBkabaIx/4hwFkFJEDlXPAm n+OO+WnBc4RvO2vTymhgBAZaO2yGQc00Zykgas75UAX6oRSGas/032rJWCT7+ekRHDlDxfmG NFaQ0FPD9lf0ZwAAAAAAAA== --------------ms010003020408090607020005-- From andrewarnott@gmail.com Fri Jul 2 09:51:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5903A67D4 for ; Fri, 2 Jul 2010 09:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=0.914, 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 DgzSszS9iJen for ; Fri, 2 Jul 2010 09:51:19 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 053903A68E3 for ; Fri, 2 Jul 2010 09:51:18 -0700 (PDT) Received: by qyk1 with SMTP id 1so409430qyk.10 for ; Fri, 02 Jul 2010 09:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zFT230LLMhie8Bj4R7gtDGPkEAo81cs+kvSmKeef7dM=; b=ljWQRjem51eqpcD8KaBdUdhm7PRHCJxUzn4qnCNIzZAguq4YRfy5790cJ0QkRuR9QG 12jk6Hx1GP/OQWotsVjIrJmchk0aSNWSVEYcbLtlKHDSS4TeR7KEU6IrWMWKWQxgeGef duIDSRASzAINotlO2UaVUJ1gOjq+G5qh8uYCs= 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=w9ocwkJvp1umvEtD0DroAUcz9H3OXHFVaLpakki362Mb1wTl/FXrSzEj7yRanZ8MVU E8zTrFHyZA/WIeNYNisodLN40JniESjATuumOwUUa9V0IXvgzr/DrEI/VbL8fftYzIdu J0xdhEmGLOobs907LtH/U37GVtNk/ednH8zoI= MIME-Version: 1.0 Received: by 10.224.45.70 with SMTP id d6mr593876qaf.72.1278089482971; Fri, 02 Jul 2010 09:51:22 -0700 (PDT) Received: by 10.150.92.8 with HTTP; Fri, 2 Jul 2010 09:51:22 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6C6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6C6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 2 Jul 2010 09:51:22 -0700 Message-ID: From: Andrew Arnott To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0015175cba4e9fab82048a6a65c5 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] End user auth response code-and-token's scope parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 16:51:20 -0000 --0015175cba4e9fab82048a6a65c5 Content-Type: text/plain; charset=ISO-8859-1 Ah! Yes I'd missed the second scope parameter that web servers have the opportunity to see. And your point makes sense. Is this reduced scope on the access token, and the encouragement for a registered redirect_uri, the only mitigations we have for this possible attack? Popular client app *A *is broadly authorized by users on the web. Evil client app *B* is added as javascript on a web site. Victim visits that web site, and the evil client quietly requests an access token from auth server using a request claiming to be from client app *A*. Since client app *A* wasn't required to register a redirect_uri and did not do so, client app *B* is successful in supplying its own redirect_uri and gains an access token without user intervention or knowledge, since the user had already authorized client A and the auth server just freely granted a new access token. Client app B then uses AJAX to send access token to the attacker, who can now exploit the access token from a separate machine. I brought this attack up once before. I really feel the spec should forbid issuing access tokens directly to user-agent clients when they haven't registered a redirect_uri. Another mitigation is that implicit re-issuing of an access token to a previously authorized client should be banned without a registered redirect_uri (although this only reduces the risk, as the user is still presented with the wrong client name). Thoughts? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav wrote: > Scope is specific to the access token, not the code. In fact, I expect some > providers to issue an access token with a lesser scope than that provided > when exchanging the authorization code later (which will include another > scope). This is because the authorization server can authenticate the client > when using the authorization code and provide greater access. > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Andrew Arnott > *Sent:* Friday, July 02, 2010 9:26 AM > *To:* OAuth WG (oauth@ietf.org) > *Subject:* [OAUTH-WG] End user auth response code-and-token's scope > parameter > > > > > > If the response type is code-and-token, the authorization server adds the > codeand state parameters to the redirection URI query component and the > access_token, scope, and expires_in to the redirection URI fragment using > theapplication/x-www-form-urlencoded format as defined by... > > > > Since the scope applies equally to both the code and access_token > parameters, it seems that scope should be included in the URI query part so > it is available to the web server as well as the user-agent. While the > scope remains in the fragment, the client's web server won't know whether > the full scope it requested was actually granted. > > > > Was there an advantage to including the scope only in the #fragment, or was > this just an oversight? > > > > Thanks. > > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > --0015175cba4e9fab82048a6a65c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ah! =A0Yes I'd missed the second scope parameter that web servers have = the opportunity to see. =A0And your point makes sense. =A0

Is this reduced scope on the access token, and the encouragement for a r= egistered redirect_uri, the only mitigations we have for this possible atta= ck?

Popular client app=A0A= =A0is broadly authorized by users on the web. =A0Evil client app B=A0is added as javascript on a web site. =A0Victim visits that web site, = and the evil client quietly requests an access token from auth server using= a request claiming to be from client app A. =A0Since client app = A=A0wasn't required to register a redirect_uri and did not do so, c= lient app B=A0is successful in supplying its own redirect_uri and ga= ins an access token without user intervention or knowledge, since the user = had already authorized client A and the auth server just freely granted a n= ew access token. =A0Client app B then uses AJAX to send access token to the= attacker, who can now exploit the access token from a separate machine.

I brought this attack up once before. =A0I real= ly feel the spec should forbid issuing access tokens directly to user-agent= clients when they haven't registered a redirect_uri. =A0Another mitiga= tion is that implicit re-issuing of an access token to a previously authori= zed client should be banned without a registered redirect_uri (although thi= s only reduces the risk, as the user is still presented with the wrong clie= nt name).

Thoughts?
--
Andrew Arnott
"I [= may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre


On Fri, Jul 2, 2010 at 9:31 AM, Eran Ham= mer-Lahav <eran= @hueniverse.com> wrote:

Scope is specific to the= access token, not the code. In fact, I expect some providers to issue an a= ccess token with a lesser scope than that provided when exchanging the auth= orization code later (which will include another scope). This is because th= e authorization server can authenticate the client when using the authoriza= tion code and provide greater access.

=A0

EHL

=A0

From: oauth-bounces@ietf.org [mailto:= oauth-bounces@i= etf.org] On Behalf Of Andrew Arnott
Sent: Friday, July 02, 2010 9:26 AM
To: OAuth WG (oauth@ietf.org)
Subj= ect: [OAUTH-WG] End user auth response code-and-token's scope param= eter

=A0

=A0

If the respon= se type is=A0code-and-token= , the authorization serv= er adds the=A0codeand=A0state=A0parameters to the redirection URI query component and theaccess_token,=A0= scope, and=A0expires_in=A0to the redirection URI fragment using the<= /span>application/x-www-form-urlencoded=A0format as defined by...=

=A0

Since the scope applies equally to both the code and access_token paramet= ers, it seems that scope should be included in the URI query part so it is = available to the web server as well as the user-agent. =A0While the scope r= emains in the fragment, the client's web server won't know whether = the full scope it requested was actually granted.

=A0

Was th= ere an advantage to including the scope only in the #fragment, or was this = just an oversight?

=A0

<= p class=3D"MsoNormal"> Thanks.


--
Andrew= Arnott
"I [may] not agree with what you have to say, but I'll = defend to the death your right to say it." - S. G. Tallentyre


--0015175cba4e9fab82048a6a65c5-- From Hannes.Tschofenig@gmx.net Fri Jul 2 09:52: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 6FA713A68D6 for ; Fri, 2 Jul 2010 09:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVQpNwuwR8Bv for ; Fri, 2 Jul 2010 09:52:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DE1EF3A67EA for ; Fri, 2 Jul 2010 09:52:33 -0700 (PDT) Received: (qmail 6345 invoked by uid 0); 2 Jul 2010 16:52:44 -0000 Received: from 213.162.68.123 by www042.gmx.net with HTTP; Fri, 02 Jul 2010 18:52:43 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Fri, 02 Jul 2010 18:52:43 +0200 From: "Hannes Tschofenig" In-Reply-To: <4C2E1713.9070904@stpeter.im> Message-ID: <20100702165243.312910@gmx.net> MIME-Version: 1.0 References: <61CAF342FE1EE34EAC8FB19B765914000F280E73@SABRE.InterDigital.com> <4C2E1713.9070904@stpeter.im> To: Peter Saint-Andre , Dorothy.Gellert@InterDigital.com X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+pb84rNumpP27Z47I8FWX9TV85NYkfBWDkfnYbgK KaCs8/SOhPCckGYVCYS+Ey6HC1NJbnuDOCYg== Content-Transfer-Encoding: 8bit X-GMX-UID: aWMbJFAQZDIrBJ1QuGc2aKV5emhmYwHz X-FuHaFi: 0.56999999999999995 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Updated Charter? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 16:52:35 -0000 Hi Dorothy, interesting that you mention this. I had spoken with Blaine last week about the IETF meeting planning and we also had a chat about the need to have a new charter. We will need to get feedback from the working group members about the scope because the initially envisioned steps do not seem to be up-to-date anymore. Ciao Hannes -------- Original-Nachricht -------- > Datum: Fri, 02 Jul 2010 10:42:59 -0600 > Von: Peter Saint-Andre > An: "Gellert, Dorothy" > CC: Hannes.Tschofenig@gmx.net, romeda@gmail.com, OAuth WG > Betreff: Re: Updated Charter? > On 7/2/10 9:45 AM, Gellert, Dorothy wrote: > > Hi Hannes and Blaine, > > > > Is it possible to get an updated charter before the next IETF? I > > noticed the milestones are from 2009. > > > > It would help understand the progress and goals of the WG! > > Hi Dorothy, > > You're right that a re-charter needs to be done. I'll work with Hannes > and Blaine on that. We'd probably have proposed charter text for > discussion at the next IETF meeting but would not have time to complete > the recharter by then, because there's simply not enough time to get > that done in the next ~3 weeks. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > From Dorothy.Gellert@InterDigital.com Fri Jul 2 09:55:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FD03A6910 for ; Fri, 2 Jul 2010 09:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 VIBQWc7sSKca for ; Fri, 2 Jul 2010 09:55:39 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id A5D073A6905 for ; Fri, 2 Jul 2010 09:55:39 -0700 (PDT) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jul 2010 12:55:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 2 Jul 2010 12:55:50 -0400 Message-ID: <61CAF342FE1EE34EAC8FB19B765914000F280ED9@SABRE.InterDigital.com> In-Reply-To: <4C2E1713.9070904@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Charter? Thread-Index: AcsaBaPZF5o1l8ykRXCn/a7HjcjFswAAWzTA References: <61CAF342FE1EE34EAC8FB19B765914000F280E73@SABRE.InterDigital.com> <4C2E1713.9070904@stpeter.im> From: "Gellert, Dorothy" To: "Peter Saint-Andre" X-OriginalArrivalTime: 02 Jul 2010 16:55:51.0569 (UTC) FILETIME=[6D93D810:01CB1A07] Cc: Hannes.Tschofenig@gmx.net, OAuth WG Subject: Re: [OAUTH-WG] Updated Charter? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 16:55:40 -0000 SGkgUGV0ZXIsDQoNCk5vIHByb2JsZW0sIHRoYXQgc291bmRzIGdvb2QuICBJIHJlbWVtYmVyIHdl IGhhZCBzb21lIGdvb2QgZGlzY3Vzc2lvbnMgcmVnYXJkaW5nIHRoZSBjaGFydGVyIGFuZCBJIGNv dWxkbid0IHJlbWVtYmVyIGlmIHRoZSBXRyBhZ3JlZWQgYXQgc29tZSBwb2ludCBvciBub3QsIGFu ZCB0aGUgcGFnZSBtYXkgbm90IGhhdmUgYmVlbiB1cGRhdGVkLg0KDQpJIGxvb2sgZm9yd2FyZCB0 byBtb3JlIGRpc2N1c3Npb24hDQoNCkJlc3QgUmVnYXJkcywNCkRvcm90aHkNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBldGVyIFNhaW50LUFuZHJlIFttYWlsdG86c3RwZXRl ckBzdHBldGVyLmltXSANClNlbnQ6IEZyaWRheSwgSnVseSAwMiwgMjAxMCA5OjQzIEFNDQpUbzog R2VsbGVydCwgRG9yb3RoeQ0KQ2M6IEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ7IHJvbWVkYUBn bWFpbC5jb207IE9BdXRoIFdHDQpTdWJqZWN0OiBSZTogVXBkYXRlZCBDaGFydGVyPw0KDQpPbiA3 LzIvMTAgOTo0NSBBTSwgR2VsbGVydCwgRG9yb3RoeSB3cm90ZToNCj4gSGkgSGFubmVzIGFuZCBC bGFpbmUsDQo+IA0KPiBJcyBpdCBwb3NzaWJsZSB0byBnZXQgYW4gdXBkYXRlZCBjaGFydGVyIGJl Zm9yZSB0aGUgbmV4dCBJRVRGPyAgIEkNCj4gbm90aWNlZCB0aGUgbWlsZXN0b25lcyBhcmUgZnJv bSAyMDA5Lg0KPiANCj4gSXQgd291bGQgaGVscCB1bmRlcnN0YW5kIHRoZSBwcm9ncmVzcyBhbmQg Z29hbHMgb2YgdGhlIFdHIQ0KDQpIaSBEb3JvdGh5LA0KDQpZb3UncmUgcmlnaHQgdGhhdCBhIHJl LWNoYXJ0ZXIgbmVlZHMgdG8gYmUgZG9uZS4gSSdsbCB3b3JrIHdpdGggSGFubmVzDQphbmQgQmxh aW5lIG9uIHRoYXQuIFdlJ2QgcHJvYmFibHkgaGF2ZSBwcm9wb3NlZCBjaGFydGVyIHRleHQgZm9y DQpkaXNjdXNzaW9uIGF0IHRoZSBuZXh0IElFVEYgbWVldGluZyBidXQgd291bGQgbm90IGhhdmUg dGltZSB0byBjb21wbGV0ZQ0KdGhlIHJlY2hhcnRlciBieSB0aGVuLCBiZWNhdXNlIHRoZXJlJ3Mg c2ltcGx5IG5vdCBlbm91Z2ggdGltZSB0byBnZXQNCnRoYXQgZG9uZSBpbiB0aGUgbmV4dCB+MyB3 ZWVrcy4NCg0KUGV0ZXINCg0KLS0NClBldGVyIFNhaW50LUFuZHJlDQpodHRwczovL3N0cGV0ZXIu aW0vDQoNCg== From Dorothy.Gellert@InterDigital.com Fri Jul 2 10:01: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 A1B693A6905 for ; Fri, 2 Jul 2010 10:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 s5Mmuso1jjj5 for ; Fri, 2 Jul 2010 10:01:28 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 3900A3A67D4 for ; Fri, 2 Jul 2010 10:01:28 -0700 (PDT) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jul 2010 13:00:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 2 Jul 2010 13:00:39 -0400 Message-ID: <61CAF342FE1EE34EAC8FB19B765914000F280EDE@SABRE.InterDigital.com> In-Reply-To: <20100702165243.312910@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Charter? Thread-Index: AcsaBv+g20sQyHtiQ3SxYwIoLvumVgAAJy0g References: <61CAF342FE1EE34EAC8FB19B765914000F280E73@SABRE.InterDigital.com> <4C2E1713.9070904@stpeter.im> <20100702165243.312910@gmx.net> From: "Gellert, Dorothy" To: "Hannes Tschofenig" , "Peter Saint-Andre" X-OriginalArrivalTime: 02 Jul 2010 17:00:40.0424 (UTC) FILETIME=[19BF9E80:01CB1A08] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Updated Charter? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 17:01:29 -0000 SGkgSGFubmVzIQ0KDQpHcmVhdCwgbm8gaHVycnkuICBJJ3ZlIGJlZW4gdHJ5aW5nIHRvIGdldCBh IGdyaXAgb24gd2hlcmUgd2UgYXJlIHdpdGggZGlzY292ZXJ5LCBhbmQgdGltaW5nIGZvciBMQyBv biBPYXV0aCAyLjAuDQoNCkxvb2tpbmcgZm9yd2FyZCB0byBzZWVpbmcgeW91IGluIE1hYXN0cmlj aHQhDQotRG9yb3RoeQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIYW5u ZXMgVHNjaG9mZW5pZyBbbWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXRdIA0KU2VudDog RnJpZGF5LCBKdWx5IDAyLCAyMDEwIDk6NTMgQU0NClRvOiBQZXRlciBTYWludC1BbmRyZTsgR2Vs bGVydCwgRG9yb3RoeQ0KQ2M6IG9hdXRoQGlldGYub3JnOyByb21lZGFAZ21haWwuY29tDQpTdWJq ZWN0OiBSZTogVXBkYXRlZCBDaGFydGVyPw0KDQpIaSBEb3JvdGh5LCANCg0KaW50ZXJlc3Rpbmcg dGhhdCB5b3UgbWVudGlvbiB0aGlzLiBJIGhhZCBzcG9rZW4gd2l0aCBCbGFpbmUgbGFzdCB3ZWVr IGFib3V0IHRoZSBJRVRGIG1lZXRpbmcgcGxhbm5pbmcgYW5kIHdlIGFsc28gaGFkIGEgY2hhdCBh Ym91dCB0aGUgbmVlZCB0byBoYXZlIGEgbmV3IGNoYXJ0ZXIuIA0KDQpXZSB3aWxsIG5lZWQgdG8g Z2V0IGZlZWRiYWNrIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgbWVtYmVycyBhYm91dCB0aGUgc2Nv cGUgYmVjYXVzZSB0aGUgaW5pdGlhbGx5IGVudmlzaW9uZWQgc3RlcHMgZG8gbm90IHNlZW0gdG8g YmUgdXAtdG8tZGF0ZSBhbnltb3JlLiANCg0KQ2lhbw0KSGFubmVzDQoNCi0tLS0tLS0tIE9yaWdp bmFsLU5hY2hyaWNodCAtLS0tLS0tLQ0KPiBEYXR1bTogRnJpLCAwMiBKdWwgMjAxMCAxMDo0Mjo1 OSAtMDYwMA0KPiBWb246IFBldGVyIFNhaW50LUFuZHJlIDxzdHBldGVyQHN0cGV0ZXIuaW0+DQo+ IEFuOiAiR2VsbGVydCwgRG9yb3RoeSIgPERvcm90aHkuR2VsbGVydEBJbnRlckRpZ2l0YWwuY29t Pg0KPiBDQzogSGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldCwgcm9tZWRhQGdtYWlsLmNvbSwgT0F1 dGggV0cgPG9hdXRoQGlldGYub3JnPg0KPiBCZXRyZWZmOiBSZTogVXBkYXRlZCBDaGFydGVyPw0K DQo+IE9uIDcvMi8xMCA5OjQ1IEFNLCBHZWxsZXJ0LCBEb3JvdGh5IHdyb3RlOg0KPiA+IEhpIEhh bm5lcyBhbmQgQmxhaW5lLA0KPiA+IA0KPiA+IElzIGl0IHBvc3NpYmxlIHRvIGdldCBhbiB1cGRh dGVkIGNoYXJ0ZXIgYmVmb3JlIHRoZSBuZXh0IElFVEY/ICAgSQ0KPiA+IG5vdGljZWQgdGhlIG1p bGVzdG9uZXMgYXJlIGZyb20gMjAwOS4NCj4gPiANCj4gPiBJdCB3b3VsZCBoZWxwIHVuZGVyc3Rh bmQgdGhlIHByb2dyZXNzIGFuZCBnb2FscyBvZiB0aGUgV0chDQo+IA0KPiBIaSBEb3JvdGh5LA0K PiANCj4gWW91J3JlIHJpZ2h0IHRoYXQgYSByZS1jaGFydGVyIG5lZWRzIHRvIGJlIGRvbmUuIEkn bGwgd29yayB3aXRoIEhhbm5lcw0KPiBhbmQgQmxhaW5lIG9uIHRoYXQuIFdlJ2QgcHJvYmFibHkg aGF2ZSBwcm9wb3NlZCBjaGFydGVyIHRleHQgZm9yDQo+IGRpc2N1c3Npb24gYXQgdGhlIG5leHQg SUVURiBtZWV0aW5nIGJ1dCB3b3VsZCBub3QgaGF2ZSB0aW1lIHRvIGNvbXBsZXRlDQo+IHRoZSBy ZWNoYXJ0ZXIgYnkgdGhlbiwgYmVjYXVzZSB0aGVyZSdzIHNpbXBseSBub3QgZW5vdWdoIHRpbWUg dG8gZ2V0DQo+IHRoYXQgZG9uZSBpbiB0aGUgbmV4dCB+MyB3ZWVrcy4NCj4gDQo+IFBldGVyDQo+ IA0KPiAtLQ0KPiBQZXRlciBTYWludC1BbmRyZQ0KPiBodHRwczovL3N0cGV0ZXIuaW0vDQo+IA0K From eran@hueniverse.com Fri Jul 2 10:02: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 E29E53A6928 for ; Fri, 2 Jul 2010 10:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=0.314, 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 ncEzN2tKmP1l for ; Fri, 2 Jul 2010 10:02:01 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E23523A691C for ; Fri, 2 Jul 2010 10:02:00 -0700 (PDT) Received: (qmail 1263 invoked from network); 2 Jul 2010 17:02:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Jul 2010 17:02:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 2 Jul 2010 10:02:11 -0700 From: Eran Hammer-Lahav To: Andrew Arnott Date: Fri, 2 Jul 2010 10:02:26 -0700 Thread-Topic: [OAUTH-WG] End user auth response code-and-token's scope parameter Thread-Index: AcsaBtHmGmzcZZRTTOW0ZbETp37u8QAAV8yg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6C6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6E2P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] End user auth response code-and-token's scope parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 17:02:06 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6E2P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the end of the day, there isn't much you can do about user-agent clients= . Even a registered redirection URI doesn't really help because that endpoi= nt too cannot authenticate the client. EHL From: Andrew Arnott [mailto:andrewarnott@gmail.com] Sent: Friday, July 02, 2010 9:51 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] End user auth response code-and-token's scope param= eter Ah! Yes I'd missed the second scope parameter that web servers have the op= portunity to see. And your point makes sense. Is this reduced scope on the access token, and the encouragement for a regi= stered redirect_uri, the only mitigations we have for this possible attack? Popular client app A is broadly authorized by users on the web. Evil clien= t app B is added as javascript on a web site. Victim visits that web site,= and the evil client quietly requests an access token from auth server usin= g a request claiming to be from client app A. Since client app A wasn't re= quired to register a redirect_uri and did not do so, client app B is succes= sful in supplying its own redirect_uri and gains an access token without us= er intervention or knowledge, since the user had already authorized client = A and the auth server just freely granted a new access token. Client app B= then uses AJAX to send access token to the attacker, who can now exploit t= he access token from a separate machine. I brought this attack up once before. I really feel the spec should forbid= issuing access tokens directly to user-agent clients when they haven't reg= istered a redirect_uri. Another mitigation is that implicit re-issuing of = an access token to a previously authorized client should be banned without = a registered redirect_uri (although this only reduces the risk, as the user= is still presented with the wrong client name). Thoughts? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav > wrote: Scope is specific to the access token, not the code. In fact, I expect some= providers to issue an access token with a lesser scope than that provided = when exchanging the authorization code later (which will include another sc= ope). This is because the authorization server can authenticate the client = when using the authorization code and provide greater access. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Andrew Arnott Sent: Friday, July 02, 2010 9:26 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] End user auth response code-and-token's scope parameter If the response type is code-and-token, the authorization server adds the c= odeand state parameters to the redirection URI query component and theacces= s_token, scope, and expires_in to the redirection URI fragment using theapp= lication/x-www-form-urlencoded format as defined by... Since the scope applies equally to both the code and access_token parameter= s, it seems that scope should be included in the URI query part so it is av= ailable to the web server as well as the user-agent. While the scope remai= ns in the fragment, the client's web server won't know whether the full sco= pe it requested was actually granted. Was there an advantage to including the scope only in the #fragment, or was= this just an oversight? Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6E2P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the en= d of the day, there isn’t much you can do about user-agent clients. E= ven a registered redirection URI doesn’t really help because that end= point too cannot authenticate the client.

 

EHL=

 <= /p>

From: Andrew Arnott [mailto:andr= ewarnott@gmail.com]
Sent: Friday, July 02, 2010 9:51 AM
To= : Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subje= ct: Re: [OAUTH-WG] End user auth response code-and-token's scope parame= ter

 =

Ah!  Yes I'd missed the second scope paramete= r that web servers have the opportunity to see.  And your point makes = sense.  

 

=

Is this reduced scope on the access token, = and the encouragement for a registered redirect_uri, the only mitigations w= e have for this possible attack?

 

Popular client app A <= /i>is broadly authorized by users on the web.  Evil client app B is added as javascript on a web site.  Victim visits that web s= ite, and the evil client quietly requests an access token from auth server = using a request claiming to be from client app A.  Since client= app A wasn't required to register a redirect_uri and did not d= o so, client app B is successful in supplying its own redirect_= uri and gains an access token without user intervention or knowledge, since= the user had already authorized client A and the auth server just freely g= ranted a new access token.  Client app B then uses AJAX to send access= token to the attacker, who can now exploit the access token from a separat= e machine.

=  

I brought this attack up once be= fore.  I really feel the spec should forbid issuing access tokens dire= ctly to user-agent clients when they haven't registered a redirect_uri. &nb= sp;Another mitigation is that implicit re-issuing of an access token to a p= reviously authorized client should be banned without a registered redirect_= uri (although this only reduces the risk, as the user is still presented wi= th the wrong client name).

&nb= sp;

Thoughts?

<= div>

--
Andrew A= rnott
"I [may] not agree with what you have to say, but I'll defend= to the death your right to say it." - S. G. Tallentyre

On Fri, Jul 2, 2010 at 9:31 AM, Eran Hamm= er-Lahav <eran@hueniverse.com= > wrote:

Scope is specific to the access token, not the code. In fact= , I expect some providers to issue an access token with a lesser scope than= that provided when exchanging the authorization code later (which will inc= lude another scope). This is because the authorization server can authentic= ate the client when using the authorization code and provide greater access= .

 

EHL

 

From: oauth-boun= ces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew ArnottSent: Friday, July 02, 2010 9:26 AM
To: OAuth WG (oauth@ietf.org)
Sub= ject: [OAUTH-WG] End user auth response code-and-token's scope paramete= r

 

 

If the response type is code-and-token, the authorization server adds the codeand state parameters to the= redirection URI query component and theaccess_token, scope= , and expires_in to the redirection URI fragment using theapplication/x-www-form-url= encoded format as defined= by...

 

<= /div>

Since the scope applies equally to both the code and access_tok= en parameters, it seems that scope should be included in the URI query part= so it is available to the web server as well as the user-agent.  Whil= e the scope remains in the fragment, the client's web server won't know whe= ther the full scope it requested was actually granted.

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

Was there an advantage to incl= uding the scope only in the #fragment, or was this just an oversight?<= /o:p>

 

Thanks.


--
Andrew Arnott
"= ;I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6E2P3PW5EX1MB01E_-- From eran@hueniverse.com Fri Jul 2 10:06:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563633A6923 for ; Fri, 2 Jul 2010 10:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.311, 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 b26xxARJjap2 for ; Fri, 2 Jul 2010 10:06:38 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 4B6D03A691C for ; Fri, 2 Jul 2010 10:06:38 -0700 (PDT) Received: (qmail 16990 invoked from network); 2 Jul 2010 17:06:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Jul 2010 17:06:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 2 Jul 2010 10:06:43 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Fri, 2 Jul 2010 10:06:58 -0700 Thread-Topic: OAuth Meeting Thread-Index: AcsaCHbc5nnGiL2ZTJ2l+Z22BMXmEQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6E7@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_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6E7P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 17:06:41 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6E7P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While I will not be able to join the upcoming OAuth meeting in Maastricht, = I would like to see the following output from the meeting: - Complete review of the -10 draft (to be published next week ahead of the = meeting), similar to that of -05 from the interim meeting. - Discussion of internationalization and accessibility in the 2.0 specifica= tion (meetings are usually a good place to get experts involved). - Collect requirements for signatures, discovery, identity - this doesn't h= ave to be complete or consistent, just brainstorming. Thanks, EHL --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6E7P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While I will not= be able to join the upcoming OAuth meeting in Maastricht, I would like to = see the following output from the meeting:

 

- Complete review of the -10 d= raft (to be published next week ahead of the meeting), similar to that of -= 05 from the interim meeting.

- Discussio= n of internationalization and accessibility in the 2.0 specification (meeti= ngs are usually a good place to get experts involved).

- Collect requirements for signatures, discovery, identity &= #8211; this doesn’t have to be complete or consistent, just brainstor= ming.

 

Thanks,

 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6E7P3PW5EX1MB01E_-- From andrewarnott@gmail.com Fri Jul 2 11:02: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 05E163A681F for ; Fri, 2 Jul 2010 11:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=0.849, 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 0ovAa79Qu+P9 for ; Fri, 2 Jul 2010 11:02:57 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 966523A67C1 for ; Fri, 2 Jul 2010 11:02:57 -0700 (PDT) Received: by pzk36 with SMTP id 36so771325pzk.31 for ; Fri, 02 Jul 2010 11:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:cc:content-type; bh=Z12sBMDyK+J3IfT1FFbFsHhT+2sW7TJny8/5O7aHvmE=; b=aZR3iLxhcFNKnNqBQs/tt7wDmpz9Gym31tHXRvKxb7M48IXEX3saiQosKrVnHpM7kd EJx9AlMAAAU47MVPt8XsMMjNnGoGtoP8kW33OiVXZ7UZXi37s+Tj98pJeC4IFRdkG1hA 6pBXtNQ9dVRYI2tZ9JI/TDvOio3lMgzp/rsVo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; b=Kol9avA3lK5OKgnwm5iyrRBABw0oaCszYUCtvrzTSMocG194kzqHGfSKzK+JAPD3GW QewoJo8CD3BoWYGuuh0KB0KLKF1hkSOhYFkAfnu0oTwKhXm00D4EdTonm7ED0GSQRf+p BXDK7KTNBvjCBxihSRPLHgHLa14At4/wehwHE= Received: by 10.114.57.13 with SMTP id f13mr1488058waa.116.1278093785796; Fri, 02 Jul 2010 11:03:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.67.10 with HTTP; Fri, 2 Jul 2010 11:02:42 -0700 (PDT) From: Andrew Arnott Date: Fri, 2 Jul 2010 11:02:42 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016364587221792fb048a6b665f Cc: "OAuth WG \(oauth@ietf.org\)" Subject: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 18:02:59 -0000 --0016364587221792fb048a6b665f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I guess as a minimum then, user-agent clients should never be issued access tokens without explicit user interaction? Otherwise every web site around will automatically know who I am on facebook and who my friends are as soon as I authorize the one client that is popular. Or am I missing something? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Fri, Jul 2, 2010 at 10:02 AM, Eran Hammer-Lahav wro= te: > At the end of the day, there isn=92t much you can do about user-agent > clients. Even a registered redirection URI doesn=92t really help because = that > endpoint too cannot authenticate the client. > > > > EHL > > > > *From:* Andrew Arnott [mailto:andrewarnott@gmail.com] > *Sent:* Friday, July 02, 2010 9:51 AM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] End user auth response code-and-token's scope > parameter > > > > Ah! Yes I'd missed the second scope parameter that web servers have the > opportunity to see. And your point makes sense. > > > > Is this reduced scope on the access token, and the encouragement for a > registered redirect_uri, the only mitigations we have for this possible > attack? > > > > Popular client app *A *is broadly authorized by users on the web. Evil > client app *B* is added as javascript on a web site. Victim visits that > web site, and the evil client quietly requests an access token from auth > server using a request claiming to be from client app *A*. Since client > app *A* wasn't required to register a redirect_uri and did not do so, > client app *B* is successful in supplying its own redirect_uri and gains > an access token without user intervention or knowledge, since the user ha= d > already authorized client A and the auth server just freely granted a new > access token. Client app B then uses AJAX to send access token to the > attacker, who can now exploit the access token from a separate machine. > > > > I brought this attack up once before. I really feel the spec should forb= id > issuing access tokens directly to user-agent clients when they haven't > registered a redirect_uri. Another mitigation is that implicit re-issuin= g > of an access token to a previously authorized client should be banned > without a registered redirect_uri (although this only reduces the risk, a= s > the user is still presented with the wrong client name). > > > > Thoughts? > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the deat= h > your right to say it." - S. G. Tallentyre > > On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav > wrote: > > Scope is specific to the access token, not the code. In fact, I expect so= me > providers to issue an access token with a lesser scope than that provided > when exchanging the authorization code later (which will include another > scope). This is because the authorization server can authenticate the cli= ent > when using the authorization code and provide greater access. > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Andrew Arnott > *Sent:* Friday, July 02, 2010 9:26 AM > *To:* OAuth WG (oauth@ietf.org) > *Subject:* [OAUTH-WG] End user auth response code-and-token's scope > parameter > > > > > > If the response type is code-and-token, the authorization server adds the > codeand state parameters to the redirection URI query component and the > access_token, scope, and expires_in to the redirection URI fragment using > theapplication/x-www-form-urlencoded format as defined by... > > > > Since the scope applies equally to both the code and access_token > parameters, it seems that scope should be included in the URI query part = so > it is available to the web server as well as the user-agent. While the > scope remains in the fragment, the client's web server won't know whether > the full scope it requested was actually granted. > > > > Was there an advantage to including the scope only in the #fragment, or w= as > this just an oversight? > > > > Thanks. > > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the deat= h > your right to say it." - S. G. Tallentyre > > > --0016364587221792fb048a6b665f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I guess as a minimum then, user-agent clients should never be issued access= tokens without explicit user interaction? =A0Otherwise every web site arou= nd will automatically know who I am on facebook and who my friends are as s= oon as I authorize the one client that is popular.

 --0016364587221792fb048a6b665f-- From mscurtescu@google.com Fri Jul 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 0C1893A67A3 for ; Fri, 2 Jul 2010 12:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.549 X-Spam-Level: X-Spam-Status: No, score=-105.549 tagged_above=-999 required=5 tests=[AWL=0.428, 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 0hYzv34yWe2c for ; Fri, 2 Jul 2010 12:18:08 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 97E2628C143 for ; Fri, 2 Jul 2010 12:18:08 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o62JIJXl011415 for ; Fri, 2 Jul 2010 12:18:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278098300; bh=Wzoln5qklZWTCcekEZRTI6wM7sQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=PDFT72R7fKjhDyvPmLTpe9tfkyt5wS6PEmgTrTd8rqGoN6s026hpY0NOXAicj3HZB 5tMJ24verC5WASOYbCRfA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=dTD0nIaqu0RDpdGZQ9berrZ5IpR6DDTg6clU4BBMGi47sDfpgKyV52JE6IuT2uMhb 4QtW2FKzYGa4BleH8W8Tw== Received: from gyg13 (gyg13.prod.google.com [10.243.50.141]) by hpaq2.eem.corp.google.com with ESMTP id o62JIH35003502 for ; Fri, 2 Jul 2010 12:18:18 -0700 Received: by gyg13 with SMTP id 13so2307356gyg.39 for ; Fri, 02 Jul 2010 12:18:17 -0700 (PDT) Received: by 10.101.134.13 with SMTP id l13mr1373728ann.118.1278098296124; Fri, 02 Jul 2010 12:18:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Fri, 2 Jul 2010 12:17:56 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Fri, 2 Jul 2010 12:17:56 -0700 Message-ID: To: Andrew Arnott Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 19:18:10 -0000 On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott wro= te: > I guess as a minimum then, user-agent clients should never be issued acce= ss > tokens without explicit user interaction? =A0Otherwise every web site aro= und > will automatically know who I am on facebook and who my friends are as so= on > as I authorize the one client that is popular. > Or am I missing something? Most likely user interaction will be required for the first time, but after that an immediate mode (no user interaction) is almost a must. JavaScript clients will probably not be issued refresh tokens and access tokens are short lived. It would not be practical to ask the user every hour or so. In immediate mode there is no explicit user interaction, but the user must be at the browser and have an active session with the authz server. How would other web sites know about your facebook account? Are you worried if the same JavaScript widget is embedded in multiple site and that these instances share state? Or that the widget shares state with the embedding site/page? Not sure about that. Marius > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the deat= h > your right to say it." - S. G. Tallentyre > > > On Fri, Jul 2, 2010 at 10:02 AM, Eran Hammer-Lahav > wrote: >> >> At the end of the day, there isn=92t much you can do about user-agent >> clients. Even a registered redirection URI doesn=92t really help because= that >> endpoint too cannot authenticate the client. >> >> >> >> EHL >> >> >> >> From: Andrew Arnott [mailto:andrewarnott@gmail.com] >> Sent: Friday, July 02, 2010 9:51 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] End user auth response code-and-token's scope >> parameter >> >> >> >> Ah! =A0Yes I'd missed the second scope parameter that web servers have t= he >> opportunity to see. =A0And your point makes sense. >> >> >> >> Is this reduced scope on the access token, and the encouragement for a >> registered redirect_uri, the only mitigations we have for this possible >> attack? >> >> >> >> Popular client app=A0A=A0is broadly authorized by users on the web. =A0E= vil >> client app B=A0is added as javascript on a web site. =A0Victim visits th= at web >> site, and the evil client quietly requests an access token from auth ser= ver >> using a request claiming to be from client app A. =A0Since client app A= =A0wasn't >> required to register a redirect_uri and did not do so, client app B=A0is >> successful in supplying its own redirect_uri and gains an access token >> without user intervention or knowledge, since the user had already >> authorized client A and the auth server just freely granted a new access >> token. =A0Client app B then uses AJAX to send access token to the attack= er, >> who can now exploit the access token from a separate machine. >> >> >> >> I brought this attack up once before. =A0I really feel the spec should >> forbid issuing access tokens directly to user-agent clients when they >> haven't registered a redirect_uri. =A0Another mitigation is that implici= t >> re-issuing of an access token to a previously authorized client should b= e >> banned without a registered redirect_uri (although this only reduces the >> risk, as the user is still presented with the wrong client name). >> >> >> >> Thoughts? >> >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the dea= th >> your right to say it." - S. G. Tallentyre >> >> On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav >> wrote: >> >> Scope is specific to the access token, not the code. In fact, I expect >> some providers to issue an access token with a lesser scope than that >> provided when exchanging the authorization code later (which will includ= e >> another scope). This is because the authorization server can authenticat= e >> the client when using the authorization code and provide greater access. >> >> >> >> EHL >> >> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f >> Andrew Arnott >> Sent: Friday, July 02, 2010 9:26 AM >> To: OAuth WG (oauth@ietf.org) >> Subject: [OAUTH-WG] End user auth response code-and-token's scope >> parameter >> >> >> >> >> >> If the response type is=A0code-and-token, the authorization server adds >> the=A0codeand=A0state=A0parameters to the redirection URI query componen= t and >> theaccess_token,=A0scope, and=A0expires_in=A0to the redirection URI frag= ment using >> theapplication/x-www-form-urlencoded=A0format as defined by... >> >> >> >> Since the scope applies equally to both the code and access_token >> parameters, it seems that scope should be included in the URI query part= so >> it is available to the web server as well as the user-agent. =A0While th= e >> scope remains in the fragment, the client's web server won't know whethe= r >> the full scope it requested was actually granted. >> >> >> >> Was there an advantage to including the scope only in the #fragment, or >> was this just an oversight? >> >> >> >> Thanks. >> >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the dea= th >> your right to say it." - S. G. Tallentyre >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From ian@mckellar.org Fri Jul 2 14:09: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 0D9A53A6784 for ; Fri, 2 Jul 2010 14:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeJB+Z1k87Ug for ; Fri, 2 Jul 2010 14:09:47 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 8C70B3A67F5 for ; Fri, 2 Jul 2010 14:09:47 -0700 (PDT) Received: by vws14 with SMTP id 14so2596054vws.31 for ; Fri, 02 Jul 2010 14:09:55 -0700 (PDT) Received: by 10.220.62.5 with SMTP id v5mr693849vch.221.1278104994481; Fri, 02 Jul 2010 14:09:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.201.77 with HTTP; Fri, 2 Jul 2010 14:09:34 -0700 (PDT) In-Reply-To: References: From: Ian McKellar Date: Sat, 3 Jul 2010 09:09:34 +1200 Message-ID: To: Marius Scurtescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 21:09:49 -0000 No, that's a really simple recipe for disaster. Flickr kept opening up this security hole. They would allow applications to get new tokens simply using their api key & secret and a user's session cookies. If we assume that for a desktop user-agent will expose its secrets then this is a really easy way to gain access to peoples' accounts. See: http://ianloic.com/2006/12/23/flickr_authentication_security/ and: http://ianloic.com/2009/01/05/no-more-secrets/ Ian On Sat, Jul 3, 2010 at 7:17 AM, Marius Scurtescu wr= ote: > On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott w= rote: >> I guess as a minimum then, user-agent clients should never be issued acc= ess >> tokens without explicit user interaction? =C2=A0Otherwise every web site= around >> will automatically know who I am on facebook and who my friends are as s= oon >> as I authorize the one client that is popular. >> Or am I missing something? > > Most likely user interaction will be required for the first time, but > after that an immediate mode (no user interaction) is almost a must. > JavaScript clients will probably not be issued refresh tokens and > access tokens are short lived. It would not be practical to ask the > user every hour or so. In immediate mode there is no explicit user > interaction, but the user must be at the browser and have an active > session with the authz server. > > How would other web sites know about your facebook account? Are you > worried if the same JavaScript widget is embedded in multiple site and > that these instances share state? Or that the widget shares state with > the embedding site/page? Not sure about that. > > Marius > > >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the dea= th >> your right to say it." - S. G. Tallentyre >> >> >> On Fri, Jul 2, 2010 at 10:02 AM, Eran Hammer-Lahav >> wrote: >>> >>> At the end of the day, there isn=E2=80=99t much you can do about user-a= gent >>> clients. Even a registered redirection URI doesn=E2=80=99t really help = because that >>> endpoint too cannot authenticate the client. >>> >>> >>> >>> EHL >>> >>> >>> >>> From: Andrew Arnott [mailto:andrewarnott@gmail.com] >>> Sent: Friday, July 02, 2010 9:51 AM >>> To: Eran Hammer-Lahav >>> Cc: OAuth WG (oauth@ietf.org) >>> Subject: Re: [OAUTH-WG] End user auth response code-and-token's scope >>> parameter >>> >>> >>> >>> Ah! =C2=A0Yes I'd missed the second scope parameter that web servers ha= ve the >>> opportunity to see. =C2=A0And your point makes sense. >>> >>> >>> >>> Is this reduced scope on the access token, and the encouragement for a >>> registered redirect_uri, the only mitigations we have for this possible >>> attack? >>> >>> >>> >>> Popular client app=C2=A0A=C2=A0is broadly authorized by users on the we= b. =C2=A0Evil >>> client app B=C2=A0is added as javascript on a web site. =C2=A0Victim vi= sits that web >>> site, and the evil client quietly requests an access token from auth se= rver >>> using a request claiming to be from client app A. =C2=A0Since client ap= p A=C2=A0wasn't >>> required to register a redirect_uri and did not do so, client app B=C2= =A0is >>> successful in supplying its own redirect_uri and gains an access token >>> without user intervention or knowledge, since the user had already >>> authorized client A and the auth server just freely granted a new acces= s >>> token. =C2=A0Client app B then uses AJAX to send access token to the at= tacker, >>> who can now exploit the access token from a separate machine. >>> >>> >>> >>> I brought this attack up once before. =C2=A0I really feel the spec shou= ld >>> forbid issuing access tokens directly to user-agent clients when they >>> haven't registered a redirect_uri. =C2=A0Another mitigation is that imp= licit >>> re-issuing of an access token to a previously authorized client should = be >>> banned without a registered redirect_uri (although this only reduces th= e >>> risk, as the user is still presented with the wrong client name). >>> >>> >>> >>> Thoughts? >>> >>> -- >>> Andrew Arnott >>> "I [may] not agree with what you have to say, but I'll defend to the de= ath >>> your right to say it." - S. G. Tallentyre >>> >>> On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav >>> wrote: >>> >>> Scope is specific to the access token, not the code. In fact, I expect >>> some providers to issue an access token with a lesser scope than that >>> provided when exchanging the authorization code later (which will inclu= de >>> another scope). This is because the authorization server can authentica= te >>> the client when using the authorization code and provide greater access= . >>> >>> >>> >>> EHL >>> >>> >>> >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of >>> Andrew Arnott >>> Sent: Friday, July 02, 2010 9:26 AM >>> To: OAuth WG (oauth@ietf.org) >>> Subject: [OAUTH-WG] End user auth response code-and-token's scope >>> parameter >>> >>> >>> >>> >>> >>> If the response type is=C2=A0code-and-token, the authorization server a= dds >>> the=C2=A0codeand=C2=A0state=C2=A0parameters to the redirection URI quer= y component and >>> theaccess_token,=C2=A0scope, and=C2=A0expires_in=C2=A0to the redirectio= n URI fragment using >>> theapplication/x-www-form-urlencoded=C2=A0format as defined by... >>> >>> >>> >>> Since the scope applies equally to both the code and access_token >>> parameters, it seems that scope should be included in the URI query par= t so >>> it is available to the web server as well as the user-agent. =C2=A0Whil= e the >>> scope remains in the fragment, the client's web server won't know wheth= er >>> the full scope it requested was actually granted. >>> >>> >>> >>> Was there an advantage to including the scope only in the #fragment, or >>> was this just an oversight? >>> >>> >>> >>> Thanks. >>> >>> -- >>> Andrew Arnott >>> "I [may] not agree with what you have to say, but I'll defend to the de= ath >>> your right to say it." - S. G. Tallentyre >>> >>> >> >> _______________________________________________ >> 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 Ian McKellar ian@mckellar.org: email | jabber | msn ianloic: flickr | aim | yahoo | skype | linkedin | etc. From eran@hueniverse.com Fri Jul 2 14:13: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 030A13A6825 for ; Fri, 2 Jul 2010 14:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 Hq-J6iIma+LA for ; Fri, 2 Jul 2010 14:13:19 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 225F93A680C for ; Fri, 2 Jul 2010 14:13:18 -0700 (PDT) Received: (qmail 31106 invoked from network); 2 Jul 2010 21:13:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Jul 2010 21:13:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 2 Jul 2010 14:13:24 -0700 From: Eran Hammer-Lahav To: Ian McKellar , Marius Scurtescu Date: Fri, 2 Jul 2010 14:13:39 -0700 Thread-Topic: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) Thread-Index: AcsaKvIIa7XEoHzdQVCnVyfNRyEG9QAACm5g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 21:13:23 -0000 VGhlcmUgaXMgbm90aGluZyB5b3UgY2FuIGRvIHRvIHByb3RlY3QgYW55IG5vbi1zZXJ2ZXItYmFz ZWQgY2xpZW50IGZyb20gaW1pdGF0aW5nIGFub3RoZXIgY2xpZW50LiBBbGwgeW91IGNhbiBkbyBp cyByZXF1aXJlIHRoZSBlbmQtdXNlIHRvIGJlIHByZXNlbnQgd2hlbiB5b3UgY2Fubm90IHRydXN0 IHdobyB0aGUgY2xpZW50IGlzIChhc3N1bWluZyB5b3UgdHJ1c3QgdGhlIHVzZXIgdG8ga25vdyB3 aGF0IHRoZXkgYXJlIGRvaW5nKS4gV2hhdCBwcm92aWRlcnMgbmVlZCB0byBkbyBpcyB1bmRlcnN0 YW5kIHRoaXMgYW5kIGRlc2lnbiB0aGVpciBzZWN1cml0eSBhbmQgdG9rZW4gc2NvcGluZyBhdHRy aWJ1dGVzIGFjY29yZGluZyB0byB0aGVpciBvd24gYXR0YWNrIHZlY3RvcnMuIFRoZSBzcGVjIHNo b3VsZCBoaWdobGlnaHQgdGhlc2UgaXNzdWVzLCBidXQgY2Fubm90IHNvbHZlIHRoZW0uDQoNCkVI TA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG9hdXRoLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2Yg SWFuIE1jS2VsbGFyDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAwMiwgMjAxMCAyOjEwIFBNDQo+IFRv OiBNYXJpdXMgU2N1cnRlc2N1DQo+IENjOiBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQo+IFN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFNlY3VyaXR5IG9mIHVzZXIgYWdlbnQgY2xpZW50cyAoV0FT OiBFbmQgdXNlciBhdXRoDQo+IHJlc3BvbnNlIGNvZGUtYW5kLXRva2VuJ3Mgc2NvcGUgcGFyYW1l dGVyKQ0KPiANCj4gTm8sIHRoYXQncyBhIHJlYWxseSBzaW1wbGUgcmVjaXBlIGZvciBkaXNhc3Rl ci4NCj4gDQo+IEZsaWNrciBrZXB0IG9wZW5pbmcgdXAgdGhpcyBzZWN1cml0eSBob2xlLiBUaGV5 IHdvdWxkIGFsbG93IGFwcGxpY2F0aW9ucyB0byBnZXQNCj4gbmV3IHRva2VucyBzaW1wbHkgdXNp bmcgdGhlaXIgYXBpIGtleSAmIHNlY3JldCBhbmQgYSB1c2VyJ3Mgc2Vzc2lvbiBjb29raWVzLiBJ Zg0KPiB3ZSBhc3N1bWUgdGhhdCBmb3IgYSBkZXNrdG9wIHVzZXItYWdlbnQgd2lsbCBleHBvc2Ug aXRzIHNlY3JldHMgdGhlbiB0aGlzIGlzIGENCj4gcmVhbGx5IGVhc3kgd2F5IHRvIGdhaW4gYWNj ZXNzIHRvIHBlb3BsZXMnIGFjY291bnRzLg0KPiANCj4gU2VlOiBodHRwOi8vaWFubG9pYy5jb20v MjAwNi8xMi8yMy9mbGlja3JfYXV0aGVudGljYXRpb25fc2VjdXJpdHkvDQo+IGFuZDogaHR0cDov L2lhbmxvaWMuY29tLzIwMDkvMDEvMDUvbm8tbW9yZS1zZWNyZXRzLw0KPiANCj4gSWFuDQo+IA0K PiBPbiBTYXQsIEp1bCAzLCAyMDEwIGF0IDc6MTcgQU0sIE1hcml1cyBTY3VydGVzY3UgPG1zY3Vy dGVzY3VAZ29vZ2xlLmNvbT4NCj4gd3JvdGU6DQo+ID4gT24gRnJpLCBKdWwgMiwgMjAxMCBhdCAx MTowMiBBTSwgQW5kcmV3IEFybm90dCA8YW5kcmV3YXJub3R0QGdtYWlsLmNvbT4NCj4gd3JvdGU6 DQo+ID4+IEkgZ3Vlc3MgYXMgYSBtaW5pbXVtIHRoZW4sIHVzZXItYWdlbnQgY2xpZW50cyBzaG91 bGQgbmV2ZXIgYmUgaXNzdWVkDQo+ID4+IGFjY2VzcyB0b2tlbnMgd2l0aG91dCBleHBsaWNpdCB1 c2VyIGludGVyYWN0aW9uPyDCoE90aGVyd2lzZSBldmVyeSB3ZWINCj4gPj4gc2l0ZSBhcm91bmQg d2lsbCBhdXRvbWF0aWNhbGx5IGtub3cgd2hvIEkgYW0gb24gZmFjZWJvb2sgYW5kIHdobyBteQ0K PiA+PiBmcmllbmRzIGFyZSBhcyBzb29uIGFzIEkgYXV0aG9yaXplIHRoZSBvbmUgY2xpZW50IHRo YXQgaXMgcG9wdWxhci4NCj4gPj4gT3IgYW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCj4gPg0KPiA+ IE1vc3QgbGlrZWx5IHVzZXIgaW50ZXJhY3Rpb24gd2lsbCBiZSByZXF1aXJlZCBmb3IgdGhlIGZp cnN0IHRpbWUsIGJ1dA0KPiA+IGFmdGVyIHRoYXQgYW4gaW1tZWRpYXRlIG1vZGUgKG5vIHVzZXIg aW50ZXJhY3Rpb24pIGlzIGFsbW9zdCBhIG11c3QuDQo+ID4gSmF2YVNjcmlwdCBjbGllbnRzIHdp bGwgcHJvYmFibHkgbm90IGJlIGlzc3VlZCByZWZyZXNoIHRva2VucyBhbmQNCj4gPiBhY2Nlc3Mg dG9rZW5zIGFyZSBzaG9ydCBsaXZlZC4gSXQgd291bGQgbm90IGJlIHByYWN0aWNhbCB0byBhc2sg dGhlDQo+ID4gdXNlciBldmVyeSBob3VyIG9yIHNvLiBJbiBpbW1lZGlhdGUgbW9kZSB0aGVyZSBp cyBubyBleHBsaWNpdCB1c2VyDQo+ID4gaW50ZXJhY3Rpb24sIGJ1dCB0aGUgdXNlciBtdXN0IGJl IGF0IHRoZSBicm93c2VyIGFuZCBoYXZlIGFuIGFjdGl2ZQ0KPiA+IHNlc3Npb24gd2l0aCB0aGUg YXV0aHogc2VydmVyLg0KPiA+DQo+ID4gSG93IHdvdWxkIG90aGVyIHdlYiBzaXRlcyBrbm93IGFi b3V0IHlvdXIgZmFjZWJvb2sgYWNjb3VudD8gQXJlIHlvdQ0KPiA+IHdvcnJpZWQgaWYgdGhlIHNh bWUgSmF2YVNjcmlwdCB3aWRnZXQgaXMgZW1iZWRkZWQgaW4gbXVsdGlwbGUgc2l0ZSBhbmQNCj4g PiB0aGF0IHRoZXNlIGluc3RhbmNlcyBzaGFyZSBzdGF0ZT8gT3IgdGhhdCB0aGUgd2lkZ2V0IHNo YXJlcyBzdGF0ZSB3aXRoDQo+ID4gdGhlIGVtYmVkZGluZyBzaXRlL3BhZ2U/IE5vdCBzdXJlIGFi b3V0IHRoYXQuDQo+ID4NCj4gPiBNYXJpdXMNCj4gPg0KPiA+DQo+ID4+IC0tDQo+ID4+IEFuZHJl dyBBcm5vdHQNCj4gPj4gIkkgW21heV0gbm90IGFncmVlIHdpdGggd2hhdCB5b3UgaGF2ZSB0byBz YXksIGJ1dCBJJ2xsIGRlZmVuZCB0byB0aGUNCj4gPj4gZGVhdGggeW91ciByaWdodCB0byBzYXkg aXQuIiAtIFMuIEcuIFRhbGxlbnR5cmUNCj4gPj4NCj4gPj4NCj4gPj4gT24gRnJpLCBKdWwgMiwg MjAxMCBhdCAxMDowMiBBTSwgRXJhbiBIYW1tZXItTGFoYXYNCj4gPj4gPGVyYW5AaHVlbml2ZXJz ZS5jb20+DQo+ID4+IHdyb3RlOg0KPiA+Pj4NCj4gPj4+IEF0IHRoZSBlbmQgb2YgdGhlIGRheSwg dGhlcmUgaXNu4oCZdCBtdWNoIHlvdSBjYW4gZG8gYWJvdXQgdXNlci1hZ2VudA0KPiA+Pj4gY2xp ZW50cy4gRXZlbiBhIHJlZ2lzdGVyZWQgcmVkaXJlY3Rpb24gVVJJIGRvZXNu4oCZdCByZWFsbHkg aGVscA0KPiA+Pj4gYmVjYXVzZSB0aGF0IGVuZHBvaW50IHRvbyBjYW5ub3QgYXV0aGVudGljYXRl IHRoZSBjbGllbnQuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBFSEwNCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+IEZyb206IEFuZHJldyBBcm5vdHQgW21haWx0bzphbmRyZXdhcm5vdHRA Z21haWwuY29tXQ0KPiA+Pj4gU2VudDogRnJpZGF5LCBKdWx5IDAyLCAyMDEwIDk6NTEgQU0NCj4g Pj4+IFRvOiBFcmFuIEhhbW1lci1MYWhhdg0KPiA+Pj4gQ2M6IE9BdXRoIFdHIChvYXV0aEBpZXRm Lm9yZykNCj4gPj4+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEVuZCB1c2VyIGF1dGggcmVzcG9u c2UgY29kZS1hbmQtdG9rZW4ncw0KPiA+Pj4gc2NvcGUgcGFyYW1ldGVyDQo+ID4+Pg0KPiA+Pj4N Cj4gPj4+DQo+ID4+PiBBaCEgwqBZZXMgSSdkIG1pc3NlZCB0aGUgc2Vjb25kIHNjb3BlIHBhcmFt ZXRlciB0aGF0IHdlYiBzZXJ2ZXJzIGhhdmUNCj4gPj4+IHRoZSBvcHBvcnR1bml0eSB0byBzZWUu IMKgQW5kIHlvdXIgcG9pbnQgbWFrZXMgc2Vuc2UuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+ PiBJcyB0aGlzIHJlZHVjZWQgc2NvcGUgb24gdGhlIGFjY2VzcyB0b2tlbiwgYW5kIHRoZSBlbmNv dXJhZ2VtZW50IGZvcg0KPiA+Pj4gYSByZWdpc3RlcmVkIHJlZGlyZWN0X3VyaSwgdGhlIG9ubHkg bWl0aWdhdGlvbnMgd2UgaGF2ZSBmb3IgdGhpcw0KPiA+Pj4gcG9zc2libGUgYXR0YWNrPw0KPiA+ Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gUG9wdWxhciBjbGllbnQgYXBwwqBBwqBpcyBicm9hZGx5 IGF1dGhvcml6ZWQgYnkgdXNlcnMgb24gdGhlIHdlYi4NCj4gPj4+IEV2aWwgY2xpZW50IGFwcCBC wqBpcyBhZGRlZCBhcyBqYXZhc2NyaXB0IG9uIGEgd2ViIHNpdGUuIMKgVmljdGltDQo+ID4+PiB2 aXNpdHMgdGhhdCB3ZWIgc2l0ZSwgYW5kIHRoZSBldmlsIGNsaWVudCBxdWlldGx5IHJlcXVlc3Rz IGFuIGFjY2Vzcw0KPiA+Pj4gdG9rZW4gZnJvbSBhdXRoIHNlcnZlciB1c2luZyBhIHJlcXVlc3Qg Y2xhaW1pbmcgdG8gYmUgZnJvbSBjbGllbnQNCj4gPj4+IGFwcCBBLiDCoFNpbmNlIGNsaWVudCBh cHAgQcKgd2Fzbid0IHJlcXVpcmVkIHRvIHJlZ2lzdGVyIGENCj4gPj4+IHJlZGlyZWN0X3VyaSBh bmQgZGlkIG5vdCBkbyBzbywgY2xpZW50IGFwcCBCwqBpcyBzdWNjZXNzZnVsIGluDQo+ID4+PiBz dXBwbHlpbmcgaXRzIG93biByZWRpcmVjdF91cmkgYW5kIGdhaW5zIGFuIGFjY2VzcyB0b2tlbiB3 aXRob3V0DQo+ID4+PiB1c2VyIGludGVydmVudGlvbiBvciBrbm93bGVkZ2UsIHNpbmNlIHRoZSB1 c2VyIGhhZCBhbHJlYWR5DQo+ID4+PiBhdXRob3JpemVkIGNsaWVudCBBIGFuZCB0aGUgYXV0aCBz ZXJ2ZXIganVzdCBmcmVlbHkgZ3JhbnRlZCBhIG5ldw0KPiA+Pj4gYWNjZXNzIHRva2VuLiDCoENs aWVudCBhcHAgQiB0aGVuIHVzZXMgQUpBWCB0byBzZW5kIGFjY2VzcyB0b2tlbiB0byB0aGUNCj4g YXR0YWNrZXIsIHdobyBjYW4gbm93IGV4cGxvaXQgdGhlIGFjY2VzcyB0b2tlbiBmcm9tIGEgc2Vw YXJhdGUgbWFjaGluZS4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEkgYnJvdWdodCB0aGlz IGF0dGFjayB1cCBvbmNlIGJlZm9yZS4gwqBJIHJlYWxseSBmZWVsIHRoZSBzcGVjIHNob3VsZA0K PiA+Pj4gZm9yYmlkIGlzc3VpbmcgYWNjZXNzIHRva2VucyBkaXJlY3RseSB0byB1c2VyLWFnZW50 IGNsaWVudHMgd2hlbg0KPiA+Pj4gdGhleSBoYXZlbid0IHJlZ2lzdGVyZWQgYSByZWRpcmVjdF91 cmkuIMKgQW5vdGhlciBtaXRpZ2F0aW9uIGlzIHRoYXQNCj4gPj4+IGltcGxpY2l0IHJlLWlzc3Vp bmcgb2YgYW4gYWNjZXNzIHRva2VuIHRvIGEgcHJldmlvdXNseSBhdXRob3JpemVkDQo+ID4+PiBj bGllbnQgc2hvdWxkIGJlIGJhbm5lZCB3aXRob3V0IGEgcmVnaXN0ZXJlZCByZWRpcmVjdF91cmkg KGFsdGhvdWdoDQo+ID4+PiB0aGlzIG9ubHkgcmVkdWNlcyB0aGUgcmlzaywgYXMgdGhlIHVzZXIg aXMgc3RpbGwgcHJlc2VudGVkIHdpdGggdGhlIHdyb25nDQo+IGNsaWVudCBuYW1lKS4NCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFRob3VnaHRzPw0KPiA+Pj4NCj4gPj4+IC0tDQo+ID4+PiBB bmRyZXcgQXJub3R0DQo+ID4+PiAiSSBbbWF5XSBub3QgYWdyZWUgd2l0aCB3aGF0IHlvdSBoYXZl IHRvIHNheSwgYnV0IEknbGwgZGVmZW5kIHRvIHRoZQ0KPiA+Pj4gZGVhdGggeW91ciByaWdodCB0 byBzYXkgaXQuIiAtIFMuIEcuIFRhbGxlbnR5cmUNCj4gPj4+DQo+ID4+PiBPbiBGcmksIEp1bCAy LCAyMDEwIGF0IDk6MzEgQU0sIEVyYW4gSGFtbWVyLUxhaGF2DQo+ID4+PiA8ZXJhbkBodWVuaXZl cnNlLmNvbT4NCj4gPj4+IHdyb3RlOg0KPiA+Pj4NCj4gPj4+IFNjb3BlIGlzIHNwZWNpZmljIHRv IHRoZSBhY2Nlc3MgdG9rZW4sIG5vdCB0aGUgY29kZS4gSW4gZmFjdCwgSQ0KPiA+Pj4gZXhwZWN0 IHNvbWUgcHJvdmlkZXJzIHRvIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiB3aXRoIGEgbGVzc2VyIHNj b3BlDQo+ID4+PiB0aGFuIHRoYXQgcHJvdmlkZWQgd2hlbiBleGNoYW5naW5nIHRoZSBhdXRob3Jp emF0aW9uIGNvZGUgbGF0ZXINCj4gPj4+ICh3aGljaCB3aWxsIGluY2x1ZGUgYW5vdGhlciBzY29w ZSkuIFRoaXMgaXMgYmVjYXVzZSB0aGUNCj4gPj4+IGF1dGhvcml6YXRpb24gc2VydmVyIGNhbiBh dXRoZW50aWNhdGUgdGhlIGNsaWVudCB3aGVuIHVzaW5nIHRoZQ0KPiBhdXRob3JpemF0aW9uIGNv ZGUgYW5kIHByb3ZpZGUgZ3JlYXRlciBhY2Nlc3MuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+ PiBFSEwNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+Pj4gQmVoYWxmIE9m IEFuZHJldyBBcm5vdHQNCj4gPj4+IFNlbnQ6IEZyaWRheSwgSnVseSAwMiwgMjAxMCA5OjI2IEFN DQo+ID4+PiBUbzogT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KPiA+Pj4gU3ViamVjdDogW09B VVRILVdHXSBFbmQgdXNlciBhdXRoIHJlc3BvbnNlIGNvZGUtYW5kLXRva2VuJ3Mgc2NvcGUNCj4g Pj4+IHBhcmFtZXRlcg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBJ ZiB0aGUgcmVzcG9uc2UgdHlwZSBpc8KgY29kZS1hbmQtdG9rZW4sIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlcg0KPiA+Pj4gYWRkcyB0aGXCoGNvZGVhbmTCoHN0YXRlwqBwYXJhbWV0ZXJzIHRvIHRo ZSByZWRpcmVjdGlvbiBVUkkgcXVlcnkNCj4gPj4+IGNvbXBvbmVudCBhbmQgdGhlYWNjZXNzX3Rv a2VuLMKgc2NvcGUsIGFuZMKgZXhwaXJlc19pbsKgdG8gdGhlDQo+ID4+PiByZWRpcmVjdGlvbiBV UkkgZnJhZ21lbnQgdXNpbmcgdGhlYXBwbGljYXRpb24veC13d3ctZm9ybS0NCj4gdXJsZW5jb2Rl ZMKgZm9ybWF0IGFzIGRlZmluZWQgYnkuLi4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFNp bmNlIHRoZSBzY29wZSBhcHBsaWVzIGVxdWFsbHkgdG8gYm90aCB0aGUgY29kZSBhbmQgYWNjZXNz X3Rva2VuDQo+ID4+PiBwYXJhbWV0ZXJzLCBpdCBzZWVtcyB0aGF0IHNjb3BlIHNob3VsZCBiZSBp bmNsdWRlZCBpbiB0aGUgVVJJIHF1ZXJ5DQo+ID4+PiBwYXJ0IHNvIGl0IGlzIGF2YWlsYWJsZSB0 byB0aGUgd2ViIHNlcnZlciBhcyB3ZWxsIGFzIHRoZSB1c2VyLWFnZW50Lg0KPiA+Pj4gV2hpbGUg dGhlIHNjb3BlIHJlbWFpbnMgaW4gdGhlIGZyYWdtZW50LCB0aGUgY2xpZW50J3Mgd2ViIHNlcnZl cg0KPiA+Pj4gd29uJ3Qga25vdyB3aGV0aGVyIHRoZSBmdWxsIHNjb3BlIGl0IHJlcXVlc3RlZCB3 YXMgYWN0dWFsbHkgZ3JhbnRlZC4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFdhcyB0aGVy ZSBhbiBhZHZhbnRhZ2UgdG8gaW5jbHVkaW5nIHRoZSBzY29wZSBvbmx5IGluIHRoZSAjZnJhZ21l bnQsDQo+ID4+PiBvciB3YXMgdGhpcyBqdXN0IGFuIG92ZXJzaWdodD8NCj4gPj4+DQo+ID4+Pg0K PiA+Pj4NCj4gPj4+IFRoYW5rcy4NCj4gPj4+DQo+ID4+PiAtLQ0KPiA+Pj4gQW5kcmV3IEFybm90 dA0KPiA+Pj4gIkkgW21heV0gbm90IGFncmVlIHdpdGggd2hhdCB5b3UgaGF2ZSB0byBzYXksIGJ1 dCBJJ2xsIGRlZmVuZCB0byB0aGUNCj4gPj4+IGRlYXRoIHlvdXIgcmlnaHQgdG8gc2F5IGl0LiIg LSBTLiBHLiBUYWxsZW50eXJlDQo+ID4+Pg0KPiA+Pj4NCj4gPj4NCj4gPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gT0F1dGggbWFpbGluZyBs aXN0DQo+ID4+IE9BdXRoQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCj4gPj4NCj4gPj4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+IE9B dXRoQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aA0KPiA+DQo+IA0KPiANCj4gDQo+IC0tDQo+IElhbiBNY0tlbGxhciAgPGh0dHA6Ly9pYW4u bWNrZWxsYXIub3JnLz4NCj4gaWFuQG1ja2VsbGFyLm9yZzogZW1haWwgfCBqYWJiZXIgfCBtc24N Cj4gaWFubG9pYzogZmxpY2tyIHwgYWltIHwgeWFob28gfCBza3lwZSB8IGxpbmtlZGluIHwgZXRj Lg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBP QXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K From jsmarr@gmail.com Fri Jul 2 15:15: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 909693A68F0 for ; Fri, 2 Jul 2010 15:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6sBLBJPtNsC for ; Fri, 2 Jul 2010 15:15:47 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 91C603A6925 for ; Fri, 2 Jul 2010 15:15:46 -0700 (PDT) Received: by vws14 with SMTP id 14so2662216vws.31 for ; Fri, 02 Jul 2010 15:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:reply-to :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; bh=OyYswslVCmGro7PrQdvS4ocA22n+qXvcYdPphI173gw=; b=dUmY2RM6gHoi9Pn/gFPJyAfUc+42pT1iydNv3MWmL6mCesqEhjMecGL5yvrCIQJ1tQ 5rYcjZpHgp/Z0r8wV7P11WYoS00eP6PCH1MX+xTbDTk/4bsl7iMcbpdJKMaX2AjwhBvj 53A4hrwGoDEFWyPhpas3Z52tNXiSFsK5FHT/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=xwjZE93hL7LgIlMdt1FwRDt1Kjeq/uQRGv6GkQkaiQZX+ao0XTRkC7rNnBpjwgLuFW mVdVo3MBHJbkYZ7LlLdv3OyCc4dyk4XvxHUUf8UNc6TX3nmgV39DFD28VYmeQQ9fDHuv niQf/iFG+4+/unCWY8wcn2U4RcVs2mU6c9GXY= Received: by 10.220.124.129 with SMTP id u1mr731747vcr.187.1278108953201; Fri, 02 Jul 2010 15:15:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.178.3 with HTTP; Fri, 2 Jul 2010 15:15:33 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C476@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0E0C7232-0C39-4D2A-9918-FCD68F27E789@photobucket.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0B379746-ED5A-4402-A8E6-1CF7D72ECE53@facebook.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C456@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C476@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Joseph Smarr Date: Fri, 2 Jul 2010 15:15:33 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00163691fbc523cb77048a6eee8c Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Underscore, dash, green, blue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jsmarr@stanfordalumni.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 22:15:52 -0000 --00163691fbc523cb77048a6eee8c Content-Type: text/plain; charset=ISO-8859-1 Just remember that dashes are problematic for JavaScript, since oauth_token is a valid variable name, but oauth-token is not. So unless you're sure this will never be a problem, +1 to underscores everywhere. I know HTTP headers normally use dash, but if you want to use dashes for headers and underscores everywhere, you have the burden of proof that this won't cause too much confusion... Thanks, js On Thu, Jul 1, 2010 at 11:25 AM, Eran Hammer-Lahav wrote: > The 1.0 install base is small enough to ignore. Looking at the interest and > community around 2.0 makes such considerations marginal. > > There is no problem with underscores in headers, it is just unusual. > > EHL > > > -----Original Message----- > > From: Marius Scurtescu [mailto:mscurtescu@google.com] > > Sent: Thursday, July 01, 2010 11:19 AM > > To: Eran Hammer-Lahav > > Cc: Luke Shepard; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Underscore, dash, green, blue > > > > 3 - all underscores. > > > > If underscores are a big issue with headers then we should consider 1 > > - all dashes. The problem with all dashes is that it is counterintuitive > for > > people that know OAuth 1. > > > > Marius > > > > > > > > On Thu, Jul 1, 2010 at 11:01 AM, Eran Hammer-Lahav > > wrote: > > > > > > > > >> -----Original Message----- > > >> From: Luke Shepard [mailto:lshepard@facebook.com] > > >> Sent: Thursday, July 01, 2010 10:58 AM > > >> To: Eran Hammer-Lahav > > >> Cc: Justin Hart; Pelle Braendgaard; OAuth WG (oauth@ietf.org) > > >> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue > > >> > > >> Don't really care, but to pick one - underscores throughout. > > >> > > >> Why not headers? > > > > > > Historically, HTTP headers use dashes and not underscores, but there is > > nothing to prevent us from using underscores throughout. > > > > > > EHL > > > > > >> On Jul 1, 2010, at 9:23 AM, Eran Hammer-Lahav wrote: > > >> > > >> > That's wasn't an option for a reason. Beside offending my esthetic > > >> sensibility :-) having the same parameter use a different name > > >> between the header and endpoint makes registration of extension > > >> parameters much harder. For example, if we used this scheme, the > > >> 'error-uri' parameter would require two registration requests, one > > >> for 'error-uri' and another for 'error_uri'. > > >> > > > >> > EHL > > >> > > > >> >> -----Original Message----- > > >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > >> >> Behalf Of Justin Hart > > >> >> Sent: Thursday, July 01, 2010 7:10 AM > > >> >> To: Pelle Braendgaard > > >> >> Cc: OAuth WG (oauth@ietf.org) > > >> >> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue > > >> >> > > >> >> +1 for underscores except header keys. > > >> >> ---- > > >> >> -- Justin Hart > > >> >> -- jhart@photobucket.com > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> On Jul 1, 2010, at 7:39 AM, Pelle Braendgaard wrote: > > >> >> > > >> >>> I already implemented 09 but it was a (very tiny) bit of a hassle > > >> >>> to have to convert underscores. > > >> >>> > > >> >>> So I also agree with 3 except headers > > >> >>> > > >> >>> On Thu, Jul 1, 2010 at 2:41 AM, Lukas Rosenstock > > >> >>> > > >> >> wrote: > > >> >>>> 3 except headers. > > >> >>>> > > >> >>>> 2010/7/1 Eran Hammer-Lahav : > > >> >>>>> First, sorry about this. J > > >> >>>>> > > >> >>>>> > > >> >>>>> > > >> >>>>> I do my best not to ask the group this kind of questions and > > >> >>>>> just pick something on my own, but I can't decide so I'll run a > > >> >>>>> quick vote (yes, a VOTE - I can't imagine seeking a consensus > call on > > this). > > >> >>>>> > > >> >>>>> > > >> >>>>> > > >> >>>>> -09 uses underscores for parameter names (except for in the > > >> >>>>> headers) and dashes for parameter values. This seems like an > > >> >>>>> odd > > >> selection. > > >> >>>>> Before, it used dashes for header parameter names, and > > >> >>>>> underscore everywhere else. Not great either. > > >> >>>>> > > >> >>>>> > > >> >>>>> > > >> >>>>> So... > > >> >>>>> > > >> >>>>> > > >> >>>>> > > >> >>>>> The changes my OCD can live with: > > >> >>>>> > > >> >>>>> > > >> >>>>> > > >> >>>>> 1. Use dashes throughout > > >> >>>>> > > >> >>>>> 2. Use underscores for all parameter names (headers included), > > >> >>>>> dashes for all values > > >> >>>>> > > >> >>>>> 3. Use underscores throughout > > >> >>>>> > > >> >>>>> > > >> >>>>> > > >> >>>>> I want to get this done with in a day because people are > > >> >>>>> writing code for > > >> >>>>> -09 and I'd like to stop making changes beyond editorial. I > > >> >>>>> just think that having different styles between the endpoint > > >> >>>>> parameters and header parameters is broken. > > >> >>>>> > > >> >>>>> > > >> >>>>> > > >> >>>>> EHL > > >> >>>>> > > >> >>>>> _______________________________________________ > > >> >>>>> OAuth mailing list > > >> >>>>> OAuth@ietf.org > > >> >>>>> https://www.ietf.org/mailman/listinfo/oauth > > >> >>>>> > > >> >>>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> -- > > >> >>>> http://lukasrosenstock.net/ > > >> >>>> _______________________________________________ > > >> >>>> OAuth mailing list > > >> >>>> OAuth@ietf.org > > >> >>>> https://www.ietf.org/mailman/listinfo/oauth > > >> >>>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> -- > > >> >>> http://agree2.com - Reach Agreement! > > >> >>> http://stakeventures.com - My blog about startups and agile > > >> >>> banking > > _______________________________________________ > > >> >>> OAuth mailing list > > >> >>> OAuth@ietf.org > > >> >>> https://www.ietf.org/mailman/listinfo/oauth > > >> >> > > >> >> _______________________________________________ > > >> >> OAuth mailing list > > >> >> OAuth@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/oauth > > >> > _______________________________________________ > > >> > OAuth mailing list > > >> > OAuth@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00163691fbc523cb77048a6eee8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just remember that dashes are problematic for JavaScript, since oauth_token= is a valid variable name, but oauth-token is not. So unless you're sur= e this will never be a problem, +1 to underscores everywhere. I know HTTP h= eaders normally use dash, but if you want to use dashes for headers and und= erscores everywhere, you have the burden of proof that this won't cause= too much confusion...

Thanks, js

On Thu, Jul 1, = 2010 at 11:25 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
The 1.0 install base is small enough to ignore. Looking at the interest and= community around 2.0 makes such considerations marginal.

There is no problem with underscores in headers, it is just unusual.

EHL

> -----Original Message-----
> From: Marius Scurtescu [mailto:mscurtescu@google.com]
> Sent: Thursday, July 01, 2010 11:19 AM
> To: Eran Hammer-Lahav
> Cc: Luke Shepard; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue
>
> 3 - all underscores.
>
> If underscores are a big issue with headers then we should consider 1<= br> > - all dashes. The problem with all dashes is that it is counterintuiti= ve for
> people that know OAuth 1.
>
> Marius
>
>
>
> On Thu, Jul 1, 2010 at 11:01 AM, Eran Hammer-Lahav
> <eran@hueniverse.com>= wrote:
> >
> >
> >> -----Original Message-----
> >> From: Luke Shepard [mailto:lshepard@facebook.com]
> >> Sent: Thursday, July 01, 2010 10:58 AM
> >> To: Eran Hammer-Lahav
> >> Cc: Justin Hart; Pelle Braendgaard; OAuth WG (oauth@ietf.org)
> >> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue
> >>
> >> Don't really care, but to pick one - underscores througho= ut.
> >>
> >> Why not headers?
> >
> > Historically, HTTP headers use dashes and not underscores, but th= ere is
> nothing to prevent us from using underscores throughout.
> >
> > EHL
> >
> >> On Jul 1, 2010, at 9:23 AM, Eran Hammer-Lahav wrote:
> >>
> >> > That's wasn't an option for a reason. Beside off= ending my esthetic
> >> sensibility :-) having the same parameter use a different nam= e
> >> between the header and endpoint makes registration of extensi= on
> >> parameters much harder. For example, if we used this scheme, = the
> >> 'error-uri' parameter would require two registration = requests, one
> >> for 'error-uri' and another for 'error_uri'.<= br> > >> >
> >> > EHL
> >> >
> >> >> -----Original Message-----
> >> >> From: oaut= h-bounces@ietf.org [mailto:oa= uth-bounces@ietf.org] On
> >> >> Behalf Of Justin Hart
> >> >> Sent: Thursday, July 01, 2010 7:10 AM
> >> >> To: Pelle Braendgaard
> >> >> Cc: OAuth WG (oaut= h@ietf.org)
> >> >> Subject: Re: [OAUTH-WG] Underscore, dash, green, blu= e
> >> >>
> >> >> +1 for underscores except header keys.
> >> >> ----
> >> >> -- Justin Hart
> >> >> -- jhart@ph= otobucket.com
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Jul 1, 2010, at 7:39 AM, Pelle Braendgaard wrote:=
> >> >>
> >> >>> I already implemented 09 but it was a (very tiny= ) bit of a hassle
> >> >>> to have to convert underscores.
> >> >>>
> >> >>> So I also agree with 3 except headers
> >> >>>
> >> >>> On Thu, Jul 1, 2010 at 2:41 AM, Lukas Rosenstock=
> >> >>> <lr= @lukasrosenstock.net>
> >> >> wrote:
> >> >>>> 3 except headers.
> >> >>>>
> >> >>>> 2010/7/1 Eran Hammer-Lahav <eran@hueniverse.com>:
> >> >>>>> First, sorry about this. J
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> I do my best not to ask the group this k= ind of questions and
> >> >>>>> just pick something on my own, but I can= 't decide so I'll run a
> >> >>>>> quick vote (yes, a VOTE - I can't im= agine seeking a consensus call on
> this).
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> -09 uses underscores for parameter names= (except for in the
> >> >>>>> headers) and dashes for parameter values= . This seems like an
> >> >>>>> odd
> >> selection.
> >> >>>>> Before, it used dashes for header parame= ter names, and
> >> >>>>> underscore everywhere else. Not great ei= ther.
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> So...
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> The changes my OCD can live with:
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> 1. Use dashes throughout
> >> >>>>>
> >> >>>>> 2. Use underscores for all parameter nam= es (headers included),
> >> >>>>> dashes for all values
> >> >>>>>
> >> >>>>> 3. Use underscores throughout
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> I want to get this done with in a day be= cause people are
> >> >>>>> writing code for
> >> >>>>> -09 and I'd like to stop making chan= ges beyond editorial. =A0I
> >> >>>>> just think that having different styles = between the endpoint
> >> >>>>> parameters and header parameters is brok= en.
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> EHL
> >> >>>>>
> >> >>>>> ________________________________________= _______
> >> >>>>> OAuth mailing list
> >> >>>>> OAuth@= ietf.org
> >> >>>>> https://www.ietf.org/mailman/listinfo/oau= th
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>> http://lukasrosenstock.net/
> >> >>>> ____________________________________________= ___
> >> >>>> OAuth mailing list
> >> >>>> OAuth@ietf= .org
> >> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> = http://agree2.com - Reach Agreement!
> >> >>> http://stakeventures.com - My blog about startups and agile
> >> >>> banking
> _______________________________________________
> >> >>> OAuth mailing list
> >> >>> OAuth@ietf.org=
> >> >>> https://www.ietf.org/mailman/listinfo/oauth > >> >>
> >> >> _______________________________________________
> >> >> OAuth mailing list
> >> >> OAuth@ietf.org=
> >> >> https://www.ietf.org/mailman/listinfo/oauth
> >> > _______________________________________________
> >> > OAuth mailing list
> >> > OAuth@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--00163691fbc523cb77048a6eee8c-- From paul.tarjan@facebook.com Fri Jul 2 17:03: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 9C3D63A68CF for ; Fri, 2 Jul 2010 17:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuTfhu7tDYGp for ; Fri, 2 Jul 2010 17:03:28 -0700 (PDT) Received: from mx-out.facebook.com (outmail007.snc1.tfbnw.net [69.63.178.166]) by core3.amsl.com (Postfix) with ESMTP id B6C383A6407 for ; Fri, 2 Jul 2010 17:03:28 -0700 (PDT) Received: from [10.18.255.123] ([10.18.255.123:55182] helo=mail.thefacebook.com) by mta004.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 2A/0E-15591-A5E7E2C4; Fri, 02 Jul 2010 17:03:38 -0700 Received: from SC-MBX04.TheFacebook.com ([169.254.3.146]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Fri, 2 Jul 2010 17:03:37 -0700 From: Paul Tarjan To: Dick Hardt Thread-Topic: [OAUTH-WG] Understanding the reasoning for Base64 Thread-Index: AQHLGVg7NcljKnju2kGxsi3dQJmpwJKdMPyAgAGYXQA= Date: Sat, 3 Jul 2010 00:04:46 +0000 Message-ID: References: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <609f9a2a-2e81-4959-a567-1663b960bb6c> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 00:03:29 -0000 >> We don't think base64url will work, because the most common error we'll = see is that developers forget the "url" part and just do plain base64, and = that's not sufficient because the stock set includes +. >=20 > I think forgetting to url-decode is more likely than doing the wrong base= 64 encoding. At least with the wrong base64 encoding, what was done wrong i= s more obvious right away. The + will not be in the string. Most web frameworks that I know of urldecode the inputs before they even hi= t application code.=20 >>=20 >> So it will maybe work, maybe not. Maybe they'll do urlencoding after any= ways, since if they are passing this as a query param, or post data, client= libraries will take a dict and try to "do the right thing". And we end up = with pluses, and we're not quite sure if they should be urldecoded or not. >=20 > we won't have pluses I think Naitik is saying that accidentally doing base64 and not base64url w= ill send some '+'s along. > why hex? ... why not base64url? It seems to be the encoding format in languages: python: >>> hmac.new('secret', 'payload', hashlib.sha256).hexdigest() 'b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4' php: print hash_hmac('sha256', 'payload', 'secret'); b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba ruby: >> HMAC::SHA256.hexdigest('secret', 'payload') =3D> "b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4" > I am unclear on what your point is.=20 >=20 > The token would be included as one of the headers. This is often preferab= le as it separates the authorization layer (in header) from application lay= er parameters (query string or message body) With our proposal, we were focussed on url parameters (hence the choice of = urlencode after it was all put together). I think it makes total sense to n= ot do the encoding as part of the sig spec, and let the transport choice di= ctate which encoding to use. Therefore, I think we should make the signature: hash + '.' + json string And then if you are putting it in a url parameter, you should urlencode the= whole thing. If you are putting it in an HTTP header you should remove all= the "\r" and "\n" in the json output (which are only whitespace as they ar= en't allowed inside strings, and most language encoders won't even output t= hem by default).=20 This way, this is a general signature spec, regardless of how it is being s= ent. You could send it as a DNS record and do the proper encoding for that = scenario, or carrier pigeon encoded in Navajo, etc.=20 So to sum up: * We'd like the signature first (so you can left split instead of right spl= it) * We'd like the signature to be hex encoded instead of base64url because th= at's how the common usage is nowadays * We'd like to not encode the payload (other than JSON) and let the choice = of transport layer dictate how to handle encoding the whole thing. Sound good? Paul= From wmills@yahoo-inc.com Fri Jul 2 17:48: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 08FEE3A68C7 for ; Fri, 2 Jul 2010 17:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.32 X-Spam-Level: X-Spam-Status: No, score=-17.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIILMeQQeJVg for ; Fri, 2 Jul 2010 17:48:44 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id 6848E3A68AF for ; Fri, 2 Jul 2010 17:48:44 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o630kl36093726; Fri, 2 Jul 2010 17:46:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=jJ5xkd/JANxhPJ6EEVZZLkdrhl/OoBS5h1N27V85Pedep9VEnEjIvlbE35CZdmpZ Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 17:46:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1A49.36F11C36" Date: Fri, 2 Jul 2010 17:46:46 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B69FB@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Underscore, dash, green, blue Thread-Index: AcsaNGx5G+AwSVAcRjKYLXgtx+M57wAFK4TQ References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0E0C7232-0C39-4D2A-9918-FCD68F27E789@photobucket.com><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3D7@P3PW5EX1MB01.EX1.SECURESERVER.NET><0B379746-ED5A-4402-A8E6-1CF7D72ECE53@facebook.com><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C456@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C476@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" To: , "Eran Hammer-Lahav" X-OriginalArrivalTime: 03 Jul 2010 00:46:47.0515 (UTC) FILETIME=[376F0AB0:01CB1A49] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Underscore, dash, green, blue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 00:48:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1A49.36F11C36 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable +1 for _ =20 I don't find HTTP header names having dashes confusing, because they all do. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Joseph Smarr Sent: Friday, July 02, 2010 3:16 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Underscore, dash, green, blue =09 =09 Just remember that dashes are problematic for JavaScript, since oauth_token is a valid variable name, but oauth-token is not. So unless you're sure this will never be a problem, +1 to underscores everywhere. I know HTTP headers normally use dash, but if you want to use dashes for headers and underscores everywhere, you have the burden of proof that this won't cause too much confusion...=20 Thanks, js =09 =09 On Thu, Jul 1, 2010 at 11:25 AM, Eran Hammer-Lahav wrote: =09 The 1.0 install base is small enough to ignore. Looking at the interest and community around 2.0 makes such considerations marginal. =09 There is no problem with underscores in headers, it is just unusual. =09 EHL =09 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Thursday, July 01, 2010 11:19 AM > To: Eran Hammer-Lahav =09 > Cc: Luke Shepard; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Underscore, dash, green, blue > > 3 - all underscores. > > If underscores are a big issue with headers then we should consider 1 > - all dashes. The problem with all dashes is that it is counterintuitive for > people that know OAuth 1. > > Marius > > > > On Thu, Jul 1, 2010 at 11:01 AM, Eran Hammer-Lahav > wrote: > > > > > >> -----Original Message----- > >> From: Luke Shepard [mailto:lshepard@facebook.com] > >> Sent: Thursday, July 01, 2010 10:58 AM > >> To: Eran Hammer-Lahav > >> Cc: Justin Hart; Pelle Braendgaard; OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue > >> > >> Don't really care, but to pick one - underscores throughout. > >> > >> Why not headers? > > > > Historically, HTTP headers use dashes and not underscores, but there is > nothing to prevent us from using underscores throughout. > > > > EHL > > > >> On Jul 1, 2010, at 9:23 AM, Eran Hammer-Lahav wrote: > >> > >> > That's wasn't an option for a reason. Beside offending my esthetic > >> sensibility :-) having the same parameter use a different name > >> between the header and endpoint makes registration of extension > >> parameters much harder. For example, if we used this scheme, the > >> 'error-uri' parameter would require two registration requests, one > >> for 'error-uri' and another for 'error_uri'. > >> > > >> > EHL > >> > > >> >> -----Original Message----- > >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> >> Behalf Of Justin Hart > >> >> Sent: Thursday, July 01, 2010 7:10 AM > >> >> To: Pelle Braendgaard > >> >> Cc: OAuth WG (oauth@ietf.org) > >> >> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue > >> >> > >> >> +1 for underscores except header keys. > >> >> ---- > >> >> -- Justin Hart > >> >> -- jhart@photobucket.com > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> On Jul 1, 2010, at 7:39 AM, Pelle Braendgaard wrote: > >> >> > >> >>> I already implemented 09 but it was a (very tiny) bit of a hassle > >> >>> to have to convert underscores. > >> >>> > >> >>> So I also agree with 3 except headers > >> >>> > >> >>> On Thu, Jul 1, 2010 at 2:41 AM, Lukas Rosenstock > >> >>> > >> >> wrote: > >> >>>> 3 except headers. > >> >>>> > >> >>>> 2010/7/1 Eran Hammer-Lahav : > >> >>>>> First, sorry about this. J > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> I do my best not to ask the group this kind of questions and > >> >>>>> just pick something on my own, but I can't decide so I'll run a > >> >>>>> quick vote (yes, a VOTE - I can't imagine seeking a consensus call on > this). > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> -09 uses underscores for parameter names (except for in the > >> >>>>> headers) and dashes for parameter values. This seems like an > >> >>>>> odd > >> selection. > >> >>>>> Before, it used dashes for header parameter names, and > >> >>>>> underscore everywhere else. Not great either. > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> So... > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> The changes my OCD can live with: > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> 1. Use dashes throughout > >> >>>>> > >> >>>>> 2. Use underscores for all parameter names (headers included), > >> >>>>> dashes for all values > >> >>>>> > >> >>>>> 3. Use underscores throughout > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> I want to get this done with in a day because people are > >> >>>>> writing code for > >> >>>>> -09 and I'd like to stop making changes beyond editorial. I > >> >>>>> just think that having different styles between the endpoint > >> >>>>> parameters and header parameters is broken. > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> EHL > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> OAuth mailing list > >> >>>>> OAuth@ietf.org > >> >>>>> https://www.ietf.org/mailman/listinfo/oauth > >> >>>>> > >> >>>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> -- > >> >>>> http://lukasrosenstock.net/ > >> >>>> _______________________________________________ > >> >>>> OAuth mailing list > >> >>>> OAuth@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/oauth > >> >>>> > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> http://agree2.com - Reach Agreement! > >> >>> http://stakeventures.com - My blog about startups and agile > >> >>> banking > _______________________________________________ > >> >>> OAuth mailing list > >> >>> OAuth@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/oauth > >> >> > >> >> _______________________________________________ > >> >> OAuth mailing list > >> >> OAuth@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =09 ------_=_NextPart_001_01CB1A49.36F11C36 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
+1 for _
 
I don't find HTTP header names having dashes = confusing,=20 because they all do.

From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] On Behalf Of Joseph=20 Smarr
Sent: Friday, July 02, 2010 3:16 PM
To: Eran = Hammer-Lahav
Cc: OAuth WG = (oauth@ietf.org)
Subject: Re:=20 [OAUTH-WG] Underscore, dash, green, blue

Just remember that dashes are problematic for JavaScript, = since=20 oauth_token is a valid variable name, but oauth-token is not. So = unless you're=20 sure this will never be a problem, +1 to underscores everywhere. I = know HTTP=20 headers normally use dash, but if you want to use dashes for headers = and=20 underscores everywhere, you have the burden of proof that this won't = cause too=20 much confusion...

Thanks, js

On Thu, Jul 1, 2010 at 11:25 AM, Eran = Hammer-Lahav=20 <eran@hueniverse.com> = wrote:
The 1.0 install base is small enough to ignore. = Looking at=20 the interest and community around 2.0 makes such considerations=20 marginal.

There is no problem with underscores in headers, it = is just=20 unusual.

EHL

> -----Original Message-----
> From: = Marius=20 Scurtescu [mailto:mscurtescu@google.com]
> = Sent:=20 Thursday, July 01, 2010 11:19 AM
> To: Eran = Hammer-Lahav
> Cc: Luke Shepard; OAuth WG (oauth@ietf.org)
> Subject: = Re:=20 [OAUTH-WG] Underscore, dash, green, blue
>
> 3 - all=20 underscores.
>
> If underscores are a big issue with = headers=20 then we should consider 1
> - all dashes. The problem with all = dashes=20 is that it is counterintuitive for
> people that know OAuth=20 1.
>
> Marius
>
>
>
> On Thu, = Jul 1,=20 2010 at 11:01 AM, Eran Hammer-Lahav
> <eran@hueniverse.com> = wrote:
>=20 >
> >
> >> -----Original = Message-----
>=20 >> From: Luke Shepard [mailto:lshepard@facebook.com]
> = >> Sent: Thursday, July 01, 2010 10:58 AM
> >> To: = Eran=20 Hammer-Lahav
> >> Cc: Justin Hart; Pelle Braendgaard; = OAuth WG=20 (oauth@ietf.org)
> = >>=20 Subject: Re: [OAUTH-WG] Underscore, dash, green, blue
>=20 >>
> >> Don't really care, but to pick one - = underscores=20 throughout.
> >>
> >> Why not = headers?
>=20 >
> > Historically, HTTP headers use dashes and not = underscores,=20 but there is
> nothing to prevent us from using underscores=20 throughout.
> >
> > EHL
> >
> = >> On=20 Jul 1, 2010, at 9:23 AM, Eran Hammer-Lahav wrote:
> = >>
>=20 >> > That's wasn't an option for a reason. Beside offending = my=20 esthetic
> >> sensibility :-) having the same parameter = use a=20 different name
> >> between the header and endpoint = makes=20 registration of extension
> >> parameters much harder. = For=20 example, if we used this scheme, the
> >> 'error-uri' = parameter=20 would require two registration requests, one
> >> for=20 'error-uri' and another for 'error_uri'.
> >> = >
>=20 >> > EHL
> >> >
> >> >>=20 -----Original Message-----
> >> >> From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] = On
>=20 >> >> Behalf Of Justin Hart
> >> >> = Sent:=20 Thursday, July 01, 2010 7:10 AM
> >> >> To: Pelle=20 Braendgaard
> >> >> Cc: OAuth WG (oauth@ietf.org)
> >> = >>=20 Subject: Re: [OAUTH-WG] Underscore, dash, green, blue
> = >>=20 >>
> >> >> +1 for underscores except header=20 keys.
> >> >> ----
> >> >> -- = Justin=20 Hart
> >> >> -- jhart@photobucket.com
>=20 >> >>
> >> >>
> >>=20 >>
> >> >>
> >> >>
> = >> >>
> >> >> On Jul 1, 2010, at 7:39 = AM,=20 Pelle Braendgaard wrote:
> >> >>
> >>=20 >>> I already implemented 09 but it was a (very tiny) bit = of a=20 hassle
> >> >>> to have to convert = underscores.
>=20 >> >>>
> >> >>> So I also agree = with 3=20 except headers
> >> >>>
> >> = >>>=20 On Thu, Jul 1, 2010 at 2:41 AM, Lukas Rosenstock
> >>=20 >>> <lr@lukasrosenstock.net>
= >=20 >> >> wrote:
> >> >>>> 3 except=20 headers.
> >> >>>>
> >> = >>>>=20 2010/7/1 Eran Hammer-Lahav <eran@hueniverse.com>:
> = >> >>>>> First, sorry about this. J
> = >>=20 >>>>>
> >> >>>>>
> = >>=20 >>>>>
> >> >>>>> I do my = best not=20 to ask the group this kind of questions and
> >>=20 >>>>> just pick something on my own, but I can't = decide so=20 I'll run a
> >> >>>>> quick vote (yes, a = VOTE - I=20 can't imagine seeking a consensus call on
> this).
> = >>=20 >>>>>
> >> >>>>>
> = >>=20 >>>>>
> >> >>>>> -09 uses=20 underscores for parameter names (except for in the
> >>=20 >>>>> headers) and dashes for parameter values. This = seems=20 like an
> >> >>>>> odd
> >>=20 selection.
> >> >>>>> Before, it used = dashes for=20 header parameter names, and
> >> >>>>> = underscore=20 everywhere else. Not great either.
> >>=20 >>>>>
> >> >>>>>
> = >>=20 >>>>>
> >> >>>>> = So...
>=20 >> >>>>>
> >> = >>>>>
>=20 >> >>>>>
> >> >>>>> = The=20 changes my OCD can live with:
> >> = >>>>>
>=20 >> >>>>>
> >> = >>>>>
>=20 >> >>>>> 1. Use dashes throughout
> = >>=20 >>>>>
> >> >>>>> 2. Use=20 underscores for all parameter names (headers included),
> = >>=20 >>>>> dashes for all values
> >>=20 >>>>>
> >> >>>>> 3. Use=20 underscores throughout
> >> >>>>>
> = >> >>>>>
> >> = >>>>>
>=20 >> >>>>> I want to get this done with in a day = because=20 people are
> >> >>>>> writing code = for
>=20 >> >>>>> -09 and I'd like to stop making = changes beyond=20 editorial.  I
> >> >>>>> just think = that=20 having different styles between the endpoint
> >>=20 >>>>> parameters and header parameters is = broken.
>=20 >> >>>>>
> >> = >>>>>
>=20 >> >>>>>
> >> >>>>>=20 EHL
> >> >>>>>
> >>=20 >>>>> = _______________________________________________
>=20 >> >>>>> OAuth mailing list
> >>=20 >>>>> OAuth@ietf.org
> >>=20 >>>>> https://www.ietf.org/mailman/listinfo/oauth
>=20 >> >>>>>
> >> = >>>>>
>=20 >> >>>>
> >> >>>>
> = >>=20 >>>>
> >> >>>> --
> = >>=20 >>>> http://lukasrosenstock.net/
> >>=20 >>>> = _______________________________________________
>=20 >> >>>> OAuth mailing list
> >>=20 >>>> OAuth@ietf.org
>=20 >> >>>> https://www.ietf.org/mailman/listinfo/oauth
>=20 >> >>>>
> >> >>>
> = >>=20 >>>
> >> >>>
> >> = >>>=20 --
> >> >>> http://agree2.com - Reach Agreement!
> = >>=20 >>> http://stakeventures.com - My blog about = startups and=20 agile
> >> >>> banking
>=20 _______________________________________________
> >>=20 >>> OAuth mailing list
> >> >>> OAuth@ietf.org
> >>=20 >>> https://www.ietf.org/mailman/listinfo/oauth
>=20 >> >>
> >> >>=20 _______________________________________________
> >> = >>=20 OAuth mailing list
> >> >> OAuth@ietf.org
> >> = >> https://www.ietf.org/mailman/listinfo/oauth
>=20 >> > = _______________________________________________
>=20 >> > 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=20 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=

------_=_NextPart_001_01CB1A49.36F11C36-- From andrewarnott@gmail.com Fri Jul 2 19:24:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741753A6837 for ; Fri, 2 Jul 2010 19:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.793, 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 P4WCavnBT4nO for ; Fri, 2 Jul 2010 19:23:58 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id AF00F3A659B for ; Fri, 2 Jul 2010 19:23:57 -0700 (PDT) Received: by gyh3 with SMTP id 3so2089756gyh.31 for ; Fri, 02 Jul 2010 19:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=vBgsbUAYET+CbU35Ei1jXbR9XS27HfJYvsEvnU1lSYU=; b=YrrCrVN3UGfnxiIfyIjBuqjLNTXO1uyiXUVf6dkzftXzIgBkWhivIrTPe+CfDyUisC AaGNzkEtILZdfXfqDBKOSPFw77UHH9vWl4vD6uU0En38L+9Z/lVWXki+bjcVWXEoRz/J 12oYFNslFnytbclh5rC1JYGL9Vw3t3xDCzHNU= 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=oNyoI6RcoMJSQ4ZXLPrZ9czbs2lcc+ReTj1MUiTZ5uOVoL74lWNxIEPnUxRzySdYbs mulJNG8tFQQ3PFOP6NpS5ShH6KK8dyoyQKs0NPWTBX0CCVUsXVnTZIrLofQ+PZpmLOeb wJUFf8VkUZjQ/IDZryoSv5GYpkoiM09g83aQk= MIME-Version: 1.0 Received: by 10.90.105.1 with SMTP id d1mr37468agc.93.1278123846047; Fri, 02 Jul 2010 19:24:06 -0700 (PDT) Received: by 10.150.92.8 with HTTP; Fri, 2 Jul 2010 19:24:05 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 2 Jul 2010 19:24:05 -0700 Message-ID: From: Andrew Arnott To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64f5178d29ac2048a7265be Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 02:24:00 -0000 --0016e64f5178d29ac2048a7265be Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with the installed client issue it cannot be solved. But for a browser-based user-agent script, it's particularly dangerous to not solve it, and I believe it can be solved. By forbidding unregistered redirect_ur= i values to be included in the request for a direct access token, user agent scripts can't (as far as I can imagine) productively spoof other clients. That is, they could pretend to be the popular client that is already authorized to get another access token, but the token would be sent to the real client via redirect and not be accessible to the evil client. And it's the web-based client that I am most concerned about. An installed client already has some degree of trust with the user since it is software running on the OS. But any and every web site the user visits could crack your Facebook account (or any other OAuth-enabled resource server) simply b= y formulating the request with a client_id that has likely already been authorized in a hidden iframe. I see this as a *real *problem, and I'm proposing what I believe is a working solution. Again, I'm *not trying* to solve the installed client problem and I think that's much less severe anyway. But the web-based one must be solved, and this is a way to solve it IMO. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Fri, Jul 2, 2010 at 2:13 PM, Eran Hammer-Lahav wrot= e: > There is nothing you can do to protect any non-server-based client from > imitating another client. All you can do is require the end-use to be > present when you cannot trust who the client is (assuming you trust the u= ser > to know what they are doing). What providers need to do is understand thi= s > and design their security and token scoping attributes according to their > own attack vectors. The spec should highlight these issues, but cannot so= lve > them. > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Ian McKellar > > Sent: Friday, July 02, 2010 2:10 PM > > To: Marius Scurtescu > > Cc: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user > auth > > response code-and-token's scope parameter) > > > > No, that's a really simple recipe for disaster. > > > > Flickr kept opening up this security hole. They would allow application= s > to get > > new tokens simply using their api key & secret and a user's session > cookies. If > > we assume that for a desktop user-agent will expose its secrets then th= is > is a > > really easy way to gain access to peoples' accounts. > > > > See: http://ianloic.com/2006/12/23/flickr_authentication_security/ > > and: http://ianloic.com/2009/01/05/no-more-secrets/ > > > > Ian > > > > On Sat, Jul 3, 2010 at 7:17 AM, Marius Scurtescu > > wrote: > > > On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott > > > wrote: > > >> I guess as a minimum then, user-agent clients should never be issued > > >> access tokens without explicit user interaction? Otherwise every we= b > > >> site around will automatically know who I am on facebook and who my > > >> friends are as soon as I authorize the one client that is popular. > > >> Or am I missing something? > > > > > > Most likely user interaction will be required for the first time, but > > > after that an immediate mode (no user interaction) is almost a must. > > > JavaScript clients will probably not be issued refresh tokens and > > > access tokens are short lived. It would not be practical to ask the > > > user every hour or so. In immediate mode there is no explicit user > > > interaction, but the user must be at the browser and have an active > > > session with the authz server. > > > > > > How would other web sites know about your facebook account? Are you > > > worried if the same JavaScript widget is embedded in multiple site an= d > > > that these instances share state? Or that the widget shares state wit= h > > > the embedding site/page? Not sure about that. > > > > > > Marius > > > > > > > > >> -- > > >> Andrew Arnott > > >> "I [may] not agree with what you have to say, but I'll defend to the > > >> death your right to say it." - S. G. Tallentyre > > >> > > >> > > >> On Fri, Jul 2, 2010 at 10:02 AM, Eran Hammer-Lahav > > >> > > >> wrote: > > >>> > > >>> At the end of the day, there isn=92t much you can do about user-age= nt > > >>> clients. Even a registered redirection URI doesn=92t really help > > >>> because that endpoint too cannot authenticate the client. > > >>> > > >>> > > >>> > > >>> EHL > > >>> > > >>> > > >>> > > >>> From: Andrew Arnott [mailto:andrewarnott@gmail.com] > > >>> Sent: Friday, July 02, 2010 9:51 AM > > >>> To: Eran Hammer-Lahav > > >>> Cc: OAuth WG (oauth@ietf.org) > > >>> Subject: Re: [OAUTH-WG] End user auth response code-and-token's > > >>> scope parameter > > >>> > > >>> > > >>> > > >>> Ah! Yes I'd missed the second scope parameter that web servers hav= e > > >>> the opportunity to see. And your point makes sense. > > >>> > > >>> > > >>> > > >>> Is this reduced scope on the access token, and the encouragement fo= r > > >>> a registered redirect_uri, the only mitigations we have for this > > >>> possible attack? > > >>> > > >>> > > >>> > > >>> Popular client app A is broadly authorized by users on the web. > > >>> Evil client app B is added as javascript on a web site. Victim > > >>> visits that web site, and the evil client quietly requests an acces= s > > >>> token from auth server using a request claiming to be from client > > >>> app A. Since client app A wasn't required to register a > > >>> redirect_uri and did not do so, client app B is successful in > > >>> supplying its own redirect_uri and gains an access token without > > >>> user intervention or knowledge, since the user had already > > >>> authorized client A and the auth server just freely granted a new > > >>> access token. Client app B then uses AJAX to send access token to > the > > attacker, who can now exploit the access token from a separate machine. > > >>> > > >>> > > >>> > > >>> I brought this attack up once before. I really feel the spec shoul= d > > >>> forbid issuing access tokens directly to user-agent clients when > > >>> they haven't registered a redirect_uri. Another mitigation is that > > >>> implicit re-issuing of an access token to a previously authorized > > >>> client should be banned without a registered redirect_uri (although > > >>> this only reduces the risk, as the user is still presented with the > wrong > > client name). > > >>> > > >>> > > >>> > > >>> Thoughts? > > >>> > > >>> -- > > >>> Andrew Arnott > > >>> "I [may] not agree with what you have to say, but I'll defend to th= e > > >>> death your right to say it." - S. G. Tallentyre > > >>> > > >>> On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav > > >>> > > >>> wrote: > > >>> > > >>> Scope is specific to the access token, not the code. In fact, I > > >>> expect some providers to issue an access token with a lesser scope > > >>> than that provided when exchanging the authorization code later > > >>> (which will include another scope). This is because the > > >>> authorization server can authenticate the client when using the > > authorization code and provide greater access. > > >>> > > >>> > > >>> > > >>> EHL > > >>> > > >>> > > >>> > > >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > >>> Behalf Of Andrew Arnott > > >>> Sent: Friday, July 02, 2010 9:26 AM > > >>> To: OAuth WG (oauth@ietf.org) > > >>> Subject: [OAUTH-WG] End user auth response code-and-token's scope > > >>> parameter > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> If the response type is code-and-token, the authorization server > > >>> adds the codeand state parameters to the redirection URI query > > >>> component and theaccess_token, scope, and expires_in to the > > >>> redirection URI fragment using theapplication/x-www-form- > > urlencoded format as defined by... > > >>> > > >>> > > >>> > > >>> Since the scope applies equally to both the code and access_token > > >>> parameters, it seems that scope should be included in the URI query > > >>> part so it is available to the web server as well as the user-agent= . > > >>> While the scope remains in the fragment, the client's web server > > >>> won't know whether the full scope it requested was actually granted= . > > >>> > > >>> > > >>> > > >>> Was there an advantage to including the scope only in the #fragment= , > > >>> or was this just an oversight? > > >>> > > >>> > > >>> > > >>> Thanks. > > >>> > > >>> -- > > >>> Andrew Arnott > > >>> "I [may] not agree with what you have to say, but I'll defend to th= e > > >>> death your right to say it." - S. G. Tallentyre > > >>> > > >>> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > > > > -- > > Ian McKellar > > ian@mckellar.org: email | jabber | msn > > ianloic: flickr | aim | yahoo | skype | linkedin | etc. > > _______________________________________________ > > 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 > --0016e64f5178d29ac2048a7265be Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with the installed client issue it cannot be solved. =A0But for a b= rowser-based user-agent script, it's particularly dangerous to not solv= e it, and I believe it can be solved. =A0By forbidding unregistered redirec= t_uri values to be included in the request for a direct access token, user = agent scripts can't (as far as I can imagine) productively spoof other = clients. =A0That is, they could pretend to be the popular client that is al= ready authorized to get another access token, but the token would be sent t= o the real client via redirect and not be accessible to the evil client.
Or am I missing something?
--
Andrew Arn= ott
"I [may] not agree with what you have to say, but I'll defe= nd to the death your right to say it." - S. G. Tallentyre


On Fri, Jul 2, 2010 at 10:02 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

At the end of the day, t= here isn=92t much you can do about user-agent clients. Even a registered re= direction URI doesn=92t really help because that endpoint too cannot authen= ticate the client.

=A0

EHL

=A0

From: Andrew Arnott [mailt= o:andrewarnott@= gmail.com]
Sent: Friday, July 02, 2010 9:51 AM
To: Eran Hammer-Lahav<= br>Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] End user auth respon= se code-and-token's scope parameter

=A0

Ah! =A0Yes I'd missed the second scope paramete= r that web servers have the opportunity to see. =A0And your point makes sen= se. =A0

=A0

Is thi= s reduced scope on the access token, and the encouragement for a registered= redirect_uri, the only mitigations we have for this possible attack?

=A0

Popular client app=A0A=A0is broadly authorized by users on the web. =A0Evil client app B= =A0is added as javascript on a web site. =A0Victim visits that web site= , and the evil client quietly requests an access token from auth server usi= ng a request claiming to be from client app A. =A0Since client app <= i>A=A0wasn't required to register a redirect_uri and did not do so,= client app B=A0is successful in supplying its own redirect_uri and = gains an access token without user intervention or knowledge, since the use= r had already authorized client A and the auth server just freely granted a= new access token. =A0Client app B then uses AJAX to send access token to t= he attacker, who can now exploit the access token from a separate machine.<= /p>

=A0

I brought this attack up once before. =A0I really feel the spec sho= uld forbid issuing access tokens directly to user-agent clients when they h= aven't registered a redirect_uri. =A0Another mitigation is that implici= t re-issuing of an access token to a previously authorized client should be= banned without a registered redirect_uri (although this only reduces the r= isk, as the user is still presented with the wrong client name).

=A0

Though= ts?

--
Andrew Arnott
"I [may] not agree with what you have to say, = but I'll defend to the death your right to say it." - S. G. Tallen= tyre

On Fri, Jul 2, 2010 at 9:31 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

Scope is specific to the access tok= en, not the code. In fact, I expect some providers to issue an access token= with a lesser scope than that provided when exchanging the authorization c= ode later (which will include another scope). This is because the authoriza= tion server can authenticate the client when using the authorization code a= nd provide greater access.

=A0

EHL

=A0

From: oauth-bounces@ietf.org [mailto:= oauth-bounces@i= etf.org] On Behalf Of Andrew Arnott
Sent: Friday, July 02, 2010 9:26 AM
To: OAuth WG (oauth@ietf.org)
Subj= ect: [OAUTH-WG] End user auth response code-and-token's scope param= eter

=A0

=A0

If the response typ= e is=A0code-and-t= oken, the authorization server= adds the=A0code<= /span>and=A0state=A0parameters to the redirection URI query component and the= access_token= ,=A0scope, and= =A0expires_in=A0to the redirection URI fragment= using theapplica= tion/x-www-form-urlencoded=A0f= ormat as defined by...

=A0

Since the scope applies equally to both the code and access_token paramet= ers, it seems that scope should be included in the URI query part so it is = available to the web server as well as the user-agent. =A0While the scope r= emains in the fragment, the client's web server won't know whether = the full scope it requested was actually granted.

=A0

Was th= ere an advantage to including the scope only in the #fragment, or was this = just an oversight?

=A0

<= p class=3D"MsoNormal"> Thanks.


--
Andrew= Arnott
"I [may] not agree with what you have to say, but I'll = defend to the death your right to say it." - S. G. Tallentyre

=A0


And it's the web-based client that I am most concerned a= bout. An installed client already has some degree of trust with the user si= nce it is software running on the OS. =A0But any and every web site the use= r visits could crack your Facebook account (or any other OAuth-enabled reso= urce server) simply by formulating the request with a client_id that has li= kely already been authorized in a hidden iframe. =A0

I see this as a real problem, and I'm propos= ing what I believe is a working solution. =A0Again, I'm not trying=A0to solve the installed client problem and I think that's much less= severe anyway. =A0But the web-based one must be solved, and this is a way = to solve it IMO.

--
Andrew Arnott
"I [may] not agree with = what you have to say, but I'll defend to the death your right to say it= ." - S. G. Tallentyre


On Fri, Jul 2, 2010 at 2:13 PM, Eran Ham= mer-Lahav <eran= @hueniverse.com> wrote:
There is nothing you can do to protect any non-server-based client from imi= tating another client. All you can do is require the end-use to be present = when you cannot trust who the client is (assuming you trust the user to kno= w what they are doing). What providers need to do is understand this and de= sign their security and token scoping attributes according to their own att= ack vectors. The spec should highlight these issues, but cannot solve them.=

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf
> Of Ian McKellar
> Sent: Friday, July 02, 2010 2:10 PM
> To: Marius Scurtescu
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Securi= ty of user agent clients (WAS: End user auth
> response code-and-token's scope parameter)
>
> No, that's a really simple recipe for disaster.
>
> Flickr kept opening up this security hole. They would allow applicatio= ns to get
> new tokens simply using their api key & secret and a user's se= ssion cookies. If
> we assume that for a desktop user-agent will expose its secrets then t= his is a
> really easy way to gain access to peoples' accounts.
>
> See: http://ianloic.com/2006/12/23/flickr_authenticat= ion_security/
> and: http://ianloic.com/2009/01/05/no-more-secrets/
>
> Ian
>
> On Sat, Jul 3, 2010 at 7:17 AM, Marius Scurtescu <mscurtescu@google.com>
> wrote:
> > On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott <andrewarnott@gmail.com>
> wrote:
> >> I guess as a minimum then, user-agent clients should never be= issued
> >> access tokens without explicit user interaction? =A0Otherwise= every web
> >> site around will automatically know who I am on facebook and = who my
> >> friends are as soon as I authorize the one client that is pop= ular.
> >> Or am I missing something?
> >
> > Most likely user interaction will be required for the first time,= but
> > after that an immediate mode (no user interaction) is almost a mu= st.
> > JavaScript clients will probably not be issued refresh tokens and=
> > access tokens are short lived. It would not be practical to ask t= he
> > user every hour or so. In immediate mode there is no explicit use= r
> > interaction, but the user must be at the browser and have an acti= ve
> > session with the authz server.
> >
> > How would other web sites know about your facebook account? Are y= ou
> > worried if the same JavaScript widget is embedded in multiple sit= e and
> > that these instances share state? Or that the widget shares state= with
> > the embedding site/page? Not sure about that.
> >
> > Marius
> >
> >
> >> --
> >> Andrew Arnott
> >> "I [may] not agree with what you have to say, but I'= ll defend to the
> >> death your right to say it." - S. G. Tallentyre
> >>
> >>
> >> On Fri, Jul 2, 2010 at 10:02 AM, Eran Hammer-Lahav
> >> <eran@hueniverse.co= m>
> >> wrote:
> >>>
> >>> At the end of the day, there isn=92t much you can do abou= t user-agent
> >>> clients. Even a registered redirection URI doesn=92t real= ly help
> >>> because that endpoint too cannot authenticate the client.=
> >>>
> >>>
> >>>
> >>> EHL
> >>>
> >>>
> >>>
> >>> From: Andrew Arnott [mailto:andrewarnott@gmail.com]
> >>> Sent: Friday, July 02, 2010 9:51 AM
> >>> To: Eran Hammer-Lahav
> >>> Cc: OAuth WG (oauth@iet= f.org)
> >>> Subject: Re: [OAUTH-WG] End user auth response code-and-t= oken's
> >>> scope parameter
> >>>
> >>>
> >>>
> >>> Ah! =A0Yes I'd missed the second scope parameter that= web servers have
> >>> the opportunity to see. =A0And your point makes sense. > >>>
> >>>
> >>>
> >>> Is this reduced scope on the access token, and the encour= agement for
> >>> a registered redirect_uri, the only mitigations we have f= or this
> >>> possible attack?
> >>>
> >>>
> >>>
> >>> Popular client app=A0A=A0is broadly authorized by users o= n the web.
> >>> Evil client app B=A0is added as javascript on a web site.= =A0Victim
> >>> visits that web site, and the evil client quietly request= s an access
> >>> token from auth server using a request claiming to be fro= m client
> >>> app A. =A0Since client app A=A0wasn't required to reg= ister a
> >>> redirect_uri and did not do so, client app B=A0is success= ful in
> >>> supplying its own redirect_uri and gains an access token = without
> >>> user intervention or knowledge, since the user had alread= y
> >>> authorized client A and the auth server just freely grant= ed a new
> >>> access token. =A0Client app B then uses AJAX to send acce= ss token to the
> attacker, who can now exploit the access token from a separate machine= .
> >>>
> >>>
> >>>
> >>> I brought this attack up once before. =A0I really feel th= e spec should
> >>> forbid issuing access tokens directly to user-agent clien= ts when
> >>> they haven't registered a redirect_uri. =A0Another mi= tigation is that
> >>> implicit re-issuing of an access token to a previously au= thorized
> >>> client should be banned without a registered redirect_uri= (although
> >>> this only reduces the risk, as the user is still presente= d with the wrong
> client name).
> >>>
> >>>
> >>>
> >>> Thoughts?
> >>>
> >>> --
> >>> Andrew Arnott
> >>> "I [may] not agree with what you have to say, but I&= #39;ll defend to the
> >>> death your right to say it." - S. G. Tallentyre
> >>>
> >>> On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav
> >>> <eran@huenivers= e.com>
> >>> wrote:
> >>>
> >>> Scope is specific to the access token, not the code. In f= act, I
> >>> expect some providers to issue an access token with a les= ser scope
> >>> than that provided when exchanging the authorization code= later
> >>> (which will include another scope). This is because the > >>> authorization server can authenticate the client when usi= ng the
> authorization code and provide greater access.
> >>>
> >>>
> >>>
> >>> EHL
> >>>
> >>>
> >>>
> >>> From: oauth-bou= nces@ietf.org [mailto:oauth-b= ounces@ietf.org] On
> >>> Behalf Of Andrew Arnott
> >>> Sent: Friday, July 02, 2010 9:26 AM
> >>> To: OAuth WG (oauth@iet= f.org)
> >>> Subject: [OAUTH-WG] End user auth response code-and-token= 's scope
> >>> parameter
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> If the response type is=A0code-and-token, the authorizati= on server
> >>> adds the=A0codeand=A0state=A0parameters to the redirectio= n URI query
> >>> component and theaccess_token,=A0scope, and=A0expires_in= =A0to the
> >>> redirection URI fragment using theapplication/x-www-form-=
> urlencoded=A0format as defined by...
> >>>
> >>>
> >>>
> >>> Since the scope applies equally to both the code and acce= ss_token
> >>> parameters, it seems that scope should be included in the= URI query
> >>> part so it is available to the web server as well as the = user-agent.
> >>> While the scope remains in the fragment, the client's= web server
> >>> won't know whether the full scope it requested was ac= tually granted.
> >>>
> >>>
> >>>
> >>> Was there an advantage to including the scope only in the= #fragment,
> >>> or was this just an oversight?
> >>>
> >>>
> >>>
> >>> Thanks.
> >>>
> >>> --
> >>> Andrew Arnott
> >>> "I [may] not agree with what you have to say, but I&= #39;ll defend to the
> >>> death your right to say it." - S. G. Tallentyre
> >>>
> >>>
> >>
> >> _______________________________________________
> >> 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
> >
>
>
>
> --
> Ian McKellar =A0<http://ian.mckellar.org/>
> ian@mckellar.org: email | jabb= er | msn
> ianloic: flickr | aim | yahoo | skype | linkedin | etc.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016e64f5178d29ac2048a7265be-- From eran@hueniverse.com Fri Jul 2 21:12:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A403A690D for ; Fri, 2 Jul 2010 21:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.307, 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 IsDXhqvOHqIa for ; Fri, 2 Jul 2010 21:12:07 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id C4FFF3A6907 for ; Fri, 2 Jul 2010 21:12:06 -0700 (PDT) Received: (qmail 22036 invoked from network); 3 Jul 2010 04:12:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Jul 2010 04:12:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 2 Jul 2010 21:12:16 -0700 From: Eran Hammer-Lahav To: Andrew Arnott Date: Fri, 2 Jul 2010 21:12:32 -0700 Thread-Topic: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) Thread-Index: AcsaVtDsifacugn/TymrdmouT4BUegADqkLw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 04:12:18 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You are putting too much weight on the value of redirection URI registratio= n. Since the same problem exists between the user-agent script and the serv= er-side component used in the user-agent profile, anyone can imitate that f= low. In most cases, the redirection URI will simply include a script that w= ill pass the parameter to the *parent* window which can be anything. If the= server-based page is an active page, it still needs to communicate with th= e user-agent, which again, can pretend to be that. As long as the access token is passed back to the user-agent application, y= ou can imitate it and pretend to be another client. EHL From: Andrew Arnott [mailto:andrewarnott@gmail.com] Sent: Friday, July 02, 2010 7:24 PM To: Eran Hammer-Lahav Cc: Ian McKellar; Marius Scurtescu; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth = response code-and-token's scope parameter) I agree with the installed client issue it cannot be solved. But for a bro= wser-based user-agent script, it's particularly dangerous to not solve it, = and I believe it can be solved. By forbidding unregistered redirect_uri va= lues to be included in the request for a direct access token, user agent sc= ripts can't (as far as I can imagine) productively spoof other clients. Th= at is, they could pretend to be the popular client that is already authoriz= ed to get another access token, but the token would be sent to the real cli= ent via redirect and not be accessible to the evil client. And it's the web-based client that I am most concerned about. An installed = client already has some degree of trust with the user since it is software = running on the OS. But any and every web site the user visits could crack = your Facebook account (or any other OAuth-enabled resource server) simply b= y formulating the request with a client_id that has likely already been aut= horized in a hidden iframe. I see this as a real problem, and I'm proposing what I believe is a working= solution. Again, I'm not trying to solve the installed client problem and= I think that's much less severe anyway. But the web-based one must be sol= ved, and this is a way to solve it IMO. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre On Fri, Jul 2, 2010 at 2:13 PM, Eran Hammer-Lahav > wrote: There is nothing you can do to protect any non-server-based client from imi= tating another client. All you can do is require the end-use to be present = when you cannot trust who the client is (assuming you trust the user to kno= w what they are doing). What providers need to do is understand this and de= sign their security and token scoping attributes according to their own att= ack vectors. The spec should highlight these issues, but cannot solve them. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Ian McKellar > Sent: Friday, July 02, 2010 2:10 PM > To: Marius Scurtescu > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user aut= h > response code-and-token's scope parameter) > > No, that's a really simple recipe for disaster. > > Flickr kept opening up this security hole. They would allow applications = to get > new tokens simply using their api key & secret and a user's session cooki= es. If > we assume that for a desktop user-agent will expose its secrets then this= is a > really easy way to gain access to peoples' accounts. > > See: http://ianloic.com/2006/12/23/flickr_authentication_security/ > and: http://ianloic.com/2009/01/05/no-more-secrets/ > > Ian > > On Sat, Jul 3, 2010 at 7:17 AM, Marius Scurtescu > > wrote: > > On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott > > wrote: > >> I guess as a minimum then, user-agent clients should never be issued > >> access tokens without explicit user interaction? Otherwise every web > >> site around will automatically know who I am on facebook and who my > >> friends are as soon as I authorize the one client that is popular. > >> Or am I missing something? > > > > Most likely user interaction will be required for the first time, but > > after that an immediate mode (no user interaction) is almost a must. > > JavaScript clients will probably not be issued refresh tokens and > > access tokens are short lived. It would not be practical to ask the > > user every hour or so. In immediate mode there is no explicit user > > interaction, but the user must be at the browser and have an active > > session with the authz server. > > > > How would other web sites know about your facebook account? Are you > > worried if the same JavaScript widget is embedded in multiple site and > > that these instances share state? Or that the widget shares state with > > the embedding site/page? Not sure about that. > > > > Marius > > > > > >> -- > >> Andrew Arnott > >> "I [may] not agree with what you have to say, but I'll defend to the > >> death your right to say it." - S. G. Tallentyre > >> > >> > >> On Fri, Jul 2, 2010 at 10:02 AM, Eran Hammer-Lahav > >> > > >> wrote: > >>> > >>> At the end of the day, there isn't much you can do about user-agent > >>> clients. Even a registered redirection URI doesn't really help > >>> because that endpoint too cannot authenticate the client. > >>> > >>> > >>> > >>> EHL > >>> > >>> > >>> > >>> From: Andrew Arnott [mailto:andrewarnott@gmail.com] > >>> Sent: Friday, July 02, 2010 9:51 AM > >>> To: Eran Hammer-Lahav > >>> Cc: OAuth WG (oauth@ietf.org) > >>> Subject: Re: [OAUTH-WG] End user auth response code-and-token's > >>> scope parameter > >>> > >>> > >>> > >>> Ah! Yes I'd missed the second scope parameter that web servers have > >>> the opportunity to see. And your point makes sense. > >>> > >>> > >>> > >>> Is this reduced scope on the access token, and the encouragement for > >>> a registered redirect_uri, the only mitigations we have for this > >>> possible attack? > >>> > >>> > >>> > >>> Popular client app A is broadly authorized by users on the web. > >>> Evil client app B is added as javascript on a web site. Victim > >>> visits that web site, and the evil client quietly requests an access > >>> token from auth server using a request claiming to be from client > >>> app A. Since client app A wasn't required to register a > >>> redirect_uri and did not do so, client app B is successful in > >>> supplying its own redirect_uri and gains an access token without > >>> user intervention or knowledge, since the user had already > >>> authorized client A and the auth server just freely granted a new > >>> access token. Client app B then uses AJAX to send access token to th= e > attacker, who can now exploit the access token from a separate machine. > >>> > >>> > >>> > >>> I brought this attack up once before. I really feel the spec should > >>> forbid issuing access tokens directly to user-agent clients when > >>> they haven't registered a redirect_uri. Another mitigation is that > >>> implicit re-issuing of an access token to a previously authorized > >>> client should be banned without a registered redirect_uri (although > >>> this only reduces the risk, as the user is still presented with the w= rong > client name). > >>> > >>> > >>> > >>> Thoughts? > >>> > >>> -- > >>> Andrew Arnott > >>> "I [may] not agree with what you have to say, but I'll defend to the > >>> death your right to say it." - S. G. Tallentyre > >>> > >>> On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav > >>> > > >>> wrote: > >>> > >>> Scope is specific to the access token, not the code. In fact, I > >>> expect some providers to issue an access token with a lesser scope > >>> than that provided when exchanging the authorization code later > >>> (which will include another scope). This is because the > >>> authorization server can authenticate the client when using the > authorization code and provide greater access. > >>> > >>> > >>> > >>> EHL > >>> > >>> > >>> > >>> From: oauth-bounces@ietf.org [mailto:o= auth-bounces@ietf.org] On > >>> Behalf Of Andrew Arnott > >>> Sent: Friday, July 02, 2010 9:26 AM > >>> To: OAuth WG (oauth@ietf.org) > >>> Subject: [OAUTH-WG] End user auth response code-and-token's scope > >>> parameter > >>> > >>> > >>> > >>> > >>> > >>> If the response type is code-and-token, the authorization server > >>> adds the codeand state parameters to the redirection URI query > >>> component and theaccess_token, scope, and expires_in to the > >>> redirection URI fragment using theapplication/x-www-form- > urlencoded format as defined by... > >>> > >>> > >>> > >>> Since the scope applies equally to both the code and access_token > >>> parameters, it seems that scope should be included in the URI query > >>> part so it is available to the web server as well as the user-agent. > >>> While the scope remains in the fragment, the client's web server > >>> won't know whether the full scope it requested was actually granted. > >>> > >>> > >>> > >>> Was there an advantage to including the scope only in the #fragment, > >>> or was this just an oversight? > >>> > >>> > >>> > >>> Thanks. > >>> > >>> -- > >>> Andrew Arnott > >>> "I [may] not agree with what you have to say, but I'll defend to the > >>> death your right to say it." - S. G. Tallentyre > >>> > >>> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Ian McKellar > ian@mckellar.org: email | jabber | msn > ianloic: flickr | aim | yahoo | skype | linkedin | etc. > _______________________________________________ > 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_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You are p= utting too much weight on the value of redirection URI registration. Since = the same problem exists between the user-agent script and the server-side c= omponent used in the user-agent profile, anyone can imitate that flow. In m= ost cases, the redirection URI will simply include a script that will pass = the parameter to the *parent* window which can be anything. If the s= erver-based page is an active page, it still needs to communicate with the = user-agent, which again, can pretend to be that.

 

As long as the access token is passed back to the user-agent applicatio= n, you can imitate it and pretend to be another client.

 

EHL

 =

From: Andrew Arn= ott [mailto:andrewarnott@gmail.com]
Sent: Friday, July 02, 2010 = 7:24 PM
To: Eran Hammer-Lahav
Cc: Ian McKellar; Marius = Scurtescu; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Secu= rity of user agent clients (WAS: End user auth response code-and-token's sc= ope parameter)

&= nbsp;

I agree with the installed client issue= it cannot be solved.  But for a browser-based user-agent script, it's= particularly dangerous to not solve it, and I believe it can be solved. &n= bsp;By forbidding unregistered redirect_uri values to be included in the re= quest for a direct access token, user agent scripts can't (as far as I can = imagine) productively spoof other clients.  That is, they could preten= d to be the popular client that is already authorized to get another access= token, but the token would be sent to the real client via redirect and not= be accessible to the evil client.

=  

And it's the web-based= client that I am most concerned about. An installed client already has som= e degree of trust with the user since it is software running on the OS. &nb= sp;But any and every web site the user visits could crack your Facebook acc= ount (or any other OAuth-enabled resource server) simply by formulating the= request with a client_id that has likely already been authorized in a hidd= en iframe.  

 =

I see this as a real probl= em, and I'm proposing what I believe is a working solution.  Again, I'= m not trying to solve the installed client problem and I think = that's much less severe anyway.  But the web-based one must be solved,= and this is a way to solve it IMO.


--
Andrew Arnott"I [may] not agree with what you have to say, but I'll defend to the= death your right to say it." - S. G. Tallentyre

On Fri, Jul 2, 2010 at 2:13 PM, Eran Hammer-Laha= v <eran@hueniverse.com> wr= ote:

There is nothing you can do to prot= ect any non-server-based client from imitating another client. All you can = do is require the end-use to be present when you cannot trust who the clien= t is (assuming you trust the user to know what they are doing). What provid= ers need to do is understand this and design their security and token scopi= ng attributes according to their own attack vectors. The spec should highli= ght these issues, but cannot solve them.
<= br>EHL


> -----Origina= l Message-----
> From: oaut= h-bounces@ietf.org [mailto:oa= uth-bounces@ietf.org] On Behalf

> Of Ian McKellar
> Sent: Friday, July 02, 2010 2:10 PM
= > To: Marius Scurtescu
> Cc: OAuth WG (oauth@ietf.org)

> Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End us= er auth
> response code-and-token's scope parameter)
>
> = No, that's a really simple recipe for disaster.
>
> Flickr kept= opening up this security hole. They would allow applications to get
>= ; new tokens simply using their api key & secret and a user's session c= ookies. If
> we assume that for a desktop user-agent will expose its = secrets then this is a
> really easy way to gain access to peoples' a= ccounts.
>
> See: http://ianloic.com/2006/12/2= 3/flickr_authentication_security/
> and: http://ianloic.com/200= 9/01/05/no-more-secrets/
>
> Ian
>
> On Sat, Ju= l 3, 2010 at 7:17 AM, Marius Scurtescu <mscurtescu@google.com>
> wrote:
> > On Fri, = Jul 2, 2010 at 11:02 AM, Andrew Arnott <andrewarnott@gmail.com>
> wrote:
> >> I = guess as a minimum then, user-agent clients should never be issued
> = >> access tokens without explicit user interaction?  Otherwise e= very web
> >> site around will automatically know who I am on f= acebook and who my
> >> friends are as soon as I authorize the = one client that is popular.
> >> Or am I missing something?
= > >
> > Most likely user interaction will be required for th= e first time, but
> > after that an immediate mode (no user intera= ction) is almost a must.
> > JavaScript clients will probably not = be issued refresh tokens and
> > access tokens are short lived. It= would not be practical to ask the
> > user every hour or so. In i= mmediate mode there is no explicit user
> > interaction, but the u= ser must be at the browser and have an active
> > session with the= authz server.
> >
> > How would other web sites know abo= ut your facebook account? Are you
> > worried if the same JavaScri= pt widget is embedded in multiple site and
> > that these instance= s share state? Or that the widget shares state with
> > the embedd= ing site/page? Not sure about that.
> >
> > Marius
>= ; >
> >
> >> --
> >> Andrew Arnott
&= gt; >> "I [may] not agree with what you have to say, but I'll de= fend to the
> >> death your right to say it." - S. G. Tall= entyre
> >>
> >>
> >> On Fri, Jul 2, 20= 10 at 10:02 AM, Eran Hammer-Lahav
> >> <eran@hueniverse.com>
> >> wrote:
&= gt; >>>
> >>> At the end of the day, there isn̵= 7;t much you can do about user-agent
> >>> clients. Even a r= egistered redirection URI doesn’t really help
> >>> be= cause that endpoint too cannot authenticate the client.
> >>>= ;
> >>>
> >>>
> >>> EHL
>= ; >>>
> >>>
> >>>
> >>&g= t; From: Andrew Arnott [mailto:an= drewarnott@gmail.com]
> >>> Sent: Friday, July 02, 2010 = 9:51 AM
> >>> To: Eran Hammer-Lahav
> >>> Cc:= OAuth WG (oauth@ietf.org)
> &g= t;>> Subject: Re: [OAUTH-WG] End user auth response code-and-token's<= br>> >>> scope parameter
> >>>
> >>&= gt;
> >>>
> >>> Ah!  Yes I'd missed the = second scope parameter that web servers have
> >>> the oppor= tunity to see.  And your point makes sense.
> >>>
&g= t; >>>
> >>>
> >>> Is this reduced s= cope on the access token, and the encouragement for
> >>> a = registered redirect_uri, the only mitigations we have for this
> >= >> possible attack?
> >>>
> >>>
>= >>>
> >>> Popular client app A is broadl= y authorized by users on the web.
> >>> Evil client app B&nb= sp;is added as javascript on a web site.  Victim
> >>> = visits that web site, and the evil client quietly requests an access
>= ; >>> token from auth server using a request claiming to be from c= lient
> >>> app A.  Since client app A wasn't requ= ired to register a
> >>> redirect_uri and did not do so, cli= ent app B is successful in
> >>> supplying its own redi= rect_uri and gains an access token without
> >>> user interv= ention or knowledge, since the user had already
> >>> author= ized client A and the auth server just freely granted a new
> >>= ;> access token.  Client app B then uses AJAX to send access token = to the
> attacker, who can now exploit the access token from a separa= te machine.
> >>>
> >>>
> >>><= br>> >>> I brought this attack up once before.  I really f= eel the spec should
> >>> forbid issuing access tokens direc= tly to user-agent clients when
> >>> they haven't registered= a redirect_uri.  Another mitigation is that
> >>> impl= icit re-issuing of an access token to a previously authorized
> >&= gt;> client should be banned without a registered redirect_uri (although=
> >>> this only reduces the risk, as the user is still pres= ented with the wrong
> client name).
> >>>
> >= ;>>
> >>>
> >>> Thoughts?
> >&= gt;>
> >>> --
> >>> Andrew Arnott
> = >>> "I [may] not agree with what you have to say, but I'll de= fend to the
> >>> death your right to say it." - S. G. = Tallentyre
> >>>
> >>> On Fri, Jul 2, 2010 at= 9:31 AM, Eran Hammer-Lahav
> >>> <eran@hueniverse.com>
> >>> wrote:> >>>
> >>> Scope is specific to the access tok= en, not the code. In fact, I
> >>> expect some providers to = issue an access token with a lesser scope
> >>> than that pr= ovided when exchanging the authorization code later
> >>> (w= hich will include another scope). This is because the
> >>> = authorization server can authenticate the client when using the
> aut= horization code and provide greater access.
> >>>
> &g= t;>>
> >>>
> >>> EHL
> >>&g= t;
> >>>
> >>>
> >>> From: oauth-bounces@ietf.org [mailto:<= a href=3D"mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.org] On
= > >>> Behalf Of Andrew Arnott
> >>> Sent: Friday= , July 02, 2010 9:26 AM
> >>> To: OAuth WG (oauth@ietf.org)
> >>> Subject: [OAUTH-= WG] End user auth response code-and-token's scope
> >>> para= meter
> >>>
> >>>
> >>>
>= ; >>>
> >>>
> >>> If the response ty= pe is code-and-token, the authorization server
> >>> ad= ds the codeand state parameters to the redirection URI query=
> >>> component and theaccess_token, scope, and e= xpires_in to the
> >>> redirection URI fragment using t= heapplication/x-www-form-
> urlencoded format as defined by...> >>>
> >>>
> >>>
> >&= gt;> Since the scope applies equally to both the code and access_token> >>> parameters, it seems that scope should be included in t= he URI query
> >>> part so it is available to the web server= as well as the user-agent.
> >>> While the scope remains in= the fragment, the client's web server
> >>> won't know whet= her the full scope it requested was actually granted.
> >>><= br>> >>>
> >>>
> >>> Was there an= advantage to including the scope only in the #fragment,
> >>&g= t; or was this just an oversight?
> >>>
> >>>=
> >>>
> >>> Thanks.
> >>>
= > >>> --
> >>> Andrew Arnott
> >>>= ; "I [may] not agree with what you have to say, but I'll defend to the=
> >>> death your right to say it." - S. G. Tallentyre<= br>> >>>
> >>>
> >>
> >>= _______________________________________________
> >> OAuth mai= ling list
> >> OAuth@ietf.org=
> >> https://www.ietf.org/mailman/listinfo/oauth
>= ; >>
> >>
> > __________________________________= _____________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailm= an/listinfo/oauth
> >
>
>
>
> --
&g= t; Ian McKellar  <http://ian.mckellar.org/>
> ian@mckellar.org: email | jabber | msn
> ianloic: flickr = | aim | yahoo | skype | linkedin | etc.
> ___________________________= ____________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listi= nfo/oauth
_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https= ://www.ietf.org/mailman/listinfo/oauth

=

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818P3PW5EX1MB01E_-- From torsten@lodderstedt.net Sat Jul 3 03:19: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 D29073A6991 for ; Sat, 3 Jul 2010 03:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQ6R8jyHGOOn for ; Sat, 3 Jul 2010 03:19:33 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by core3.amsl.com (Postfix) with ESMTP id 286513A6828 for ; Sat, 3 Jul 2010 03:19:32 -0700 (PDT) Received: from p4fff3c7e.dip.t-dialin.net ([79.255.60.126] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OUzp0-00054T-N8; Sat, 03 Jul 2010 12:19:42 +0200 Message-ID: <4C2F0EB4.2000602@lodderstedt.net> Date: Sat, 03 Jul 2010 12:19:32 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------010003020200080407070703" X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 10:19:44 -0000 This is a multi-part message in MIME format. --------------010003020200080407070703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Is something as the user agent flow used in the wild today? What security means are used their? I wonder why we do not drop the user agent flow from the spec because of security reasons. From my point of view, the web flow could be used to achieve a similar behavior except the JavaScript client could not directly obtain its access tokens. Instead a(n) (application internal) protocol must be used between web site and user agent client to exchange (and refresh) access tokens. Thoughts? regards, Torsten. Am 03.07.2010 06:12, schrieb Eran Hammer-Lahav: > > You are putting too much weight on the value of redirection URI > registration. Since the same problem exists between the user-agent > script and the server-side component used in the user-agent profile, > anyone can imitate that flow. In most cases, the redirection URI will > simply include a script that will pass the parameter to the **parent** > window which can be anything. If the server-based page is an active > page, it still needs to communicate with the user-agent, which again, > can pretend to be that. > > As long as the access token is passed back to the user-agent > application, you can imitate it and pretend to be another client. > > EHL > > *From:* Andrew Arnott [mailto:andrewarnott@gmail.com] > *Sent:* Friday, July 02, 2010 7:24 PM > *To:* Eran Hammer-Lahav > *Cc:* Ian McKellar; Marius Scurtescu; OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Security of user agent clients (WAS: End > user auth response code-and-token's scope parameter) > > I agree with the installed client issue it cannot be solved. But for > a browser-based user-agent script, it's particularly dangerous to not > solve it, and I believe it can be solved. By forbidding unregistered > redirect_uri values to be included in the request for a direct access > token, user agent scripts can't (as far as I can imagine) productively > spoof other clients. That is, they could pretend to be the popular > client that is already authorized to get another access token, but the > token would be sent to the real client via redirect and not be > accessible to the evil client. > > And it's the web-based client that I am most concerned about. An > installed client already has some degree of trust with the user since > it is software running on the OS. But any and every web site the user > visits could crack your Facebook account (or any other OAuth-enabled > resource server) simply by formulating the request with a client_id > that has likely already been authorized in a hidden iframe. > > I see this as a /real /problem, and I'm proposing what I believe is a > working solution. Again, I'm /not trying/ to solve the installed > client problem and I think that's much less severe anyway. But the > web-based one must be solved, and this is a way to solve it IMO. > > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the > death your right to say it." - S. G. Tallentyre > > On Fri, Jul 2, 2010 at 2:13 PM, Eran Hammer-Lahav > wrote: > > There is nothing you can do to protect any non-server-based client > from imitating another client. All you can do is require the end-use > to be present when you cannot trust who the client is (assuming you > trust the user to know what they are doing). What providers need to do > is understand this and design their security and token scoping > attributes according to their own attack vectors. The spec should > highlight these issues, but cannot solve them. > > EHL > > > > -----Original Message----- > > From: oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] On Behalf > > > Of Ian McKellar > > Sent: Friday, July 02, 2010 2:10 PM > > To: Marius Scurtescu > > Cc: OAuth WG (oauth@ietf.org ) > > > Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End > user auth > > response code-and-token's scope parameter) > > > > No, that's a really simple recipe for disaster. > > > > Flickr kept opening up this security hole. They would allow > applications to get > > new tokens simply using their api key & secret and a user's session > cookies. If > > we assume that for a desktop user-agent will expose its secrets then > this is a > > really easy way to gain access to peoples' accounts. > > > > See: http://ianloic.com/2006/12/23/flickr_authentication_security/ > > and: http://ianloic.com/2009/01/05/no-more-secrets/ > > > > Ian > > > > On Sat, Jul 3, 2010 at 7:17 AM, Marius Scurtescu > > > > wrote: > > > On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott > > > > wrote: > > >> I guess as a minimum then, user-agent clients should never be issued > > >> access tokens without explicit user interaction? Otherwise every web > > >> site around will automatically know who I am on facebook and who my > > >> friends are as soon as I authorize the one client that is popular. > > >> Or am I missing something? > > > > > > Most likely user interaction will be required for the first time, but > > > after that an immediate mode (no user interaction) is almost a must. > > > JavaScript clients will probably not be issued refresh tokens and > > > access tokens are short lived. It would not be practical to ask the > > > user every hour or so. In immediate mode there is no explicit user > > > interaction, but the user must be at the browser and have an active > > > session with the authz server. > > > > > > How would other web sites know about your facebook account? Are you > > > worried if the same JavaScript widget is embedded in multiple site and > > > that these instances share state? Or that the widget shares state with > > > the embedding site/page? Not sure about that. > > > > > > Marius > > > > > > > > >> -- > > >> Andrew Arnott > > >> "I [may] not agree with what you have to say, but I'll defend to the > > >> death your right to say it." - S. G. Tallentyre > > >> > > >> > > >> On Fri, Jul 2, 2010 at 10:02 AM, Eran Hammer-Lahav > > >> > > > >> wrote: > > >>> > > >>> At the end of the day, there isn't much you can do about user-agent > > >>> clients. Even a registered redirection URI doesn't really help > > >>> because that endpoint too cannot authenticate the client. > > >>> > > >>> > > >>> > > >>> EHL > > >>> > > >>> > > >>> > > >>> From: Andrew Arnott [mailto:andrewarnott@gmail.com > ] > > >>> Sent: Friday, July 02, 2010 9:51 AM > > >>> To: Eran Hammer-Lahav > > >>> Cc: OAuth WG (oauth@ietf.org ) > > >>> Subject: Re: [OAUTH-WG] End user auth response code-and-token's > > >>> scope parameter > > >>> > > >>> > > >>> > > >>> Ah! Yes I'd missed the second scope parameter that web servers have > > >>> the opportunity to see. And your point makes sense. > > >>> > > >>> > > >>> > > >>> Is this reduced scope on the access token, and the encouragement for > > >>> a registered redirect_uri, the only mitigations we have for this > > >>> possible attack? > > >>> > > >>> > > >>> > > >>> Popular client app A is broadly authorized by users on the web. > > >>> Evil client app B is added as javascript on a web site. Victim > > >>> visits that web site, and the evil client quietly requests an access > > >>> token from auth server using a request claiming to be from client > > >>> app A. Since client app A wasn't required to register a > > >>> redirect_uri and did not do so, client app B is successful in > > >>> supplying its own redirect_uri and gains an access token without > > >>> user intervention or knowledge, since the user had already > > >>> authorized client A and the auth server just freely granted a new > > >>> access token. Client app B then uses AJAX to send access token > to the > > attacker, who can now exploit the access token from a separate machine. > > >>> > > >>> > > >>> > > >>> I brought this attack up once before. I really feel the spec should > > >>> forbid issuing access tokens directly to user-agent clients when > > >>> they haven't registered a redirect_uri. Another mitigation is that > > >>> implicit re-issuing of an access token to a previously authorized > > >>> client should be banned without a registered redirect_uri (although > > >>> this only reduces the risk, as the user is still presented with > the wrong > > client name). > > >>> > > >>> > > >>> > > >>> Thoughts? > > >>> > > >>> -- > > >>> Andrew Arnott > > >>> "I [may] not agree with what you have to say, but I'll defend to the > > >>> death your right to say it." - S. G. Tallentyre > > >>> > > >>> On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav > > >>> > > > >>> wrote: > > >>> > > >>> Scope is specific to the access token, not the code. In fact, I > > >>> expect some providers to issue an access token with a lesser scope > > >>> than that provided when exchanging the authorization code later > > >>> (which will include another scope). This is because the > > >>> authorization server can authenticate the client when using the > > authorization code and provide greater access. > > >>> > > >>> > > >>> > > >>> EHL > > >>> > > >>> > > >>> > > >>> From: oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] On > > >>> Behalf Of Andrew Arnott > > >>> Sent: Friday, July 02, 2010 9:26 AM > > >>> To: OAuth WG (oauth@ietf.org ) > > >>> Subject: [OAUTH-WG] End user auth response code-and-token's scope > > >>> parameter > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> If the response type is code-and-token, the authorization server > > >>> adds the codeand state parameters to the redirection URI query > > >>> component and theaccess_token, scope, and expires_in to the > > >>> redirection URI fragment using theapplication/x-www-form- > > urlencoded format as defined by... > > >>> > > >>> > > >>> > > >>> Since the scope applies equally to both the code and access_token > > >>> parameters, it seems that scope should be included in the URI query > > >>> part so it is available to the web server as well as the user-agent. > > >>> While the scope remains in the fragment, the client's web server > > >>> won't know whether the full scope it requested was actually granted. > > >>> > > >>> > > >>> > > >>> Was there an advantage to including the scope only in the #fragment, > > >>> or was this just an oversight? > > >>> > > >>> > > >>> > > >>> Thanks. > > >>> > > >>> -- > > >>> Andrew Arnott > > >>> "I [may] not agree with what you have to say, but I'll defend to the > > >>> death your right to say it." - S. G. Tallentyre > > >>> > > >>> > > >> > > >> _______________________________________________ > > >> OAuth mailing list > > >> OAuth@ietf.org > > >> https://www.ietf.org/mailman/listinfo/oauth > > >> > > >> > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > -- > > Ian McKellar > > ian@mckellar.org : email | jabber | msn > > ianloic: flickr | aim | yahoo | skype | linkedin | etc. > > _______________________________________________ > > 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 > --------------010003020200080407070703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Is something as the user agent flow used in the wild today? What security means are used their?

I wonder why we do not drop the user agent flow from the spec because of security reasons. From my point of view, the web flow could be used to achieve a similar behavior except the JavaScript client could not directly obtain its access tokens. Instead a(n) (application internal) protocol must be used between web site and user agent client to exchange (and refresh) access tokens.

Thoughts?
regards,
Torsten.

Am 03.07.2010 06:12, schrieb Eran Hammer-Lahav:

You are putting too much weight on the value of redirection URI registration. Since the same problem exists between the user-agent script and the server-side component used in the user-agent profile, anyone can imitate that flow. In most cases, the redirection URI will simply include a script that will pass the parameter to the *parent* window which can be anything. If the server-based page is an active page, it still needs to communicate with the user-agent, which again, can pretend to be that.

 

As long as the access token is passed back to the user-agent application, you can imitate it and pretend to be another client.

 

EHL

 

From: Andrew Arnott [mailto:andrewarnott@gmail.com]
Sent: Friday, July 02, 2010 7:24 PM
To: Eran Hammer-Lahav
Cc: Ian McKellar; Marius Scurtescu; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter)

 

I agree with the installed client issue it cannot be solved.  But for a browser-based user-agent script, it's particularly dangerous to not solve it, and I believe it can be solved.  By forbidding unregistered redirect_uri values to be included in the request for a direct access token, user agent scripts can't (as far as I can imagine) productively spoof other clients.  That is, they could pretend to be the popular client that is already authorized to get another access token, but the token would be sent to the real client via redirect and not be accessible to the evil client.

 

And it's the web-based client that I am most concerned about. An installed client already has some degree of trust with the user since it is software running on the OS.  But any and every web site the user visits could crack your Facebook account (or any other OAuth-enabled resource server) simply by formulating the request with a client_id that has likely already been authorized in a hidden iframe.  

 

I see this as a real problem, and I'm proposing what I believe is a working solution.  Again, I'm not trying to solve the installed client problem and I think that's much less severe anyway.  But the web-based one must be solved, and this is a way to solve it IMO.


--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

On Fri, Jul 2, 2010 at 2:13 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

There is nothing you can do to protect any non-server-based client from imitating another client. All you can do is require the end-use to be present when you cannot trust who the client is (assuming you trust the user to know what they are doing). What providers need to do is understand this and design their security and token scoping attributes according to their own attack vectors. The spec should highlight these issues, but cannot solve them.

EHL


> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf

> Of Ian McKellar
> Sent: Friday, July 02, 2010 2:10 PM
> To: Marius Scurtescu
> Cc: OAuth WG (oauth@ietf.org)

> Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth
> response code-and-token's scope parameter)
>
> No, that's a really simple recipe for disaster.
>
> Flickr kept opening up this security hole. They would allow applications to get
> new tokens simply using their api key & secret and a user's session cookies. If
> we assume that for a desktop user-agent will expose its secrets then this is a
> really easy way to gain access to peoples' accounts.
>
> See: http://ianloic.com/2006/12/23/flickr_authentication_security/
> and: http://ianloic.com/2009/01/05/no-more-secrets/
>
> Ian
>
> On Sat, Jul 3, 2010 at 7:17 AM, Marius Scurtescu <mscurtescu@google.com>
> wrote:
> > On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott <andrewarnott@gmail.com>
> wrote:
> >> I guess as a minimum then, user-agent clients should never be issued
> >> access tokens without explicit user interaction?  Otherwise every web
> >> site around will automatically know who I am on facebook and who my
> >> friends are as soon as I authorize the one client that is popular.
> >> Or am I missing something?
> >
> > Most likely user interaction will be required for the first time, but
> > after that an immediate mode (no user interaction) is almost a must.
> > JavaScript clients will probably not be issued refresh tokens and
> > access tokens are short lived. It would not be practical to ask the
> > user every hour or so. In immediate mode there is no explicit user
> > interaction, but the user must be at the browser and have an active
> > session with the authz server.
> >
> > How would other web sites know about your facebook account? Are you
> > worried if the same JavaScript widget is embedded in multiple site and
> > that these instances share state? Or that the widget shares state with
> > the embedding site/page? Not sure about that.
> >
> > Marius
> >
> >
> >> --
> >> Andrew Arnott
> >> "I [may] not agree with what you have to say, but I'll defend to the
> >> death your right to say it." - S. G. Tallentyre
> >>
> >>
> >> On Fri, Jul 2, 2010 at 10:02 AM, Eran Hammer-Lahav
> >> <eran@hueniverse.com>
> >> wrote:
> >>>
> >>> At the end of the day, there isn’t much you can do about user-agent
> >>> clients. Even a registered redirection URI doesn’t really help
> >>> because that endpoint too cannot authenticate the client.
> >>>
> >>>
> >>>
> >>> EHL
> >>>
> >>>
> >>>
> >>> From: Andrew Arnott [mailto:andrewarnott@gmail.com]
> >>> Sent: Friday, July 02, 2010 9:51 AM
> >>> To: Eran Hammer-Lahav
> >>> Cc: OAuth WG (oauth@ietf.org)
> >>> Subject: Re: [OAUTH-WG] End user auth response code-and-token's
> >>> scope parameter
> >>>
> >>>
> >>>
> >>> Ah!  Yes I'd missed the second scope parameter that web servers have
> >>> the opportunity to see.  And your point makes sense.
> >>>
> >>>
> >>>
> >>> Is this reduced scope on the access token, and the encouragement for
> >>> a registered redirect_uri, the only mitigations we have for this
> >>> possible attack?
> >>>
> >>>
> >>>
> >>> Popular client app A is broadly authorized by users on the web.
> >>> Evil client app B is added as javascript on a web site.  Victim
> >>> visits that web site, and the evil client quietly requests an access
> >>> token from auth server using a request claiming to be from client
> >>> app A.  Since client app A wasn't required to register a
> >>> redirect_uri and did not do so, client app B is successful in
> >>> supplying its own redirect_uri and gains an access token without
> >>> user intervention or knowledge, since the user had already
> >>> authorized client A and the auth server just freely granted a new
> >>> access token.  Client app B then uses AJAX to send access token to the
> attacker, who can now exploit the access token from a separate machine.
> >>>
> >>>
> >>>
> >>> I brought this attack up once before.  I really feel the spec should
> >>> forbid issuing access tokens directly to user-agent clients when
> >>> they haven't registered a redirect_uri.  Another mitigation is that
> >>> implicit re-issuing of an access token to a previously authorized
> >>> client should be banned without a registered redirect_uri (although
> >>> this only reduces the risk, as the user is still presented with the wrong
> client name).
> >>>
> >>>
> >>>
> >>> Thoughts?
> >>>
> >>> --
> >>> Andrew Arnott
> >>> "I [may] not agree with what you have to say, but I'll defend to the
> >>> death your right to say it." - S. G. Tallentyre
> >>>
> >>> On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav
> >>> <eran@hueniverse.com>
> >>> wrote:
> >>>
> >>> Scope is specific to the access token, not the code. In fact, I
> >>> expect some providers to issue an access token with a lesser scope
> >>> than that provided when exchanging the authorization code later
> >>> (which will include another scope). This is because the
> >>> authorization server can authenticate the client when using the
> authorization code and provide greater access.
> >>>
> >>>
> >>>
> >>> EHL
> >>>
> >>>
> >>>
> >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >>> Behalf Of Andrew Arnott
> >>> Sent: Friday, July 02, 2010 9:26 AM
> >>> To: OAuth WG (oauth@ietf.org)
> >>> Subject: [OAUTH-WG] End user auth response code-and-token's scope
> >>> parameter
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> If the response type is code-and-token, the authorization server
> >>> adds the codeand state parameters to the redirection URI query
> >>> component and theaccess_token, scope, and expires_in to the
> >>> redirection URI fragment using theapplication/x-www-form-
> urlencoded format as defined by...
> >>>
> >>>
> >>>
> >>> Since the scope applies equally to both the code and access_token
> >>> parameters, it seems that scope should be included in the URI query
> >>> part so it is available to the web server as well as the user-agent.
> >>> While the scope remains in the fragment, the client's web server
> >>> won't know whether the full scope it requested was actually granted.
> >>>
> >>>
> >>>
> >>> Was there an advantage to including the scope only in the #fragment,
> >>> or was this just an oversight?
> >>>
> >>>
> >>>
> >>> Thanks.
> >>>
> >>> --
> >>> Andrew Arnott
> >>> "I [may] not agree with what you have to say, but I'll defend to the
> >>> death your right to say it." - S. G. Tallentyre
> >>>
> >>>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
>
> --
> Ian McKellar  <http://ian.mckellar.org/>
> ian@mckellar.org: email | jabber | msn
> ianloic: flickr | aim | yahoo | skype | linkedin | etc.
> _______________________________________________
> 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
--------------010003020200080407070703-- From rrichards@cdatazone.org Sat Jul 3 03:27: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 8E93C3A68D8 for ; Sat, 3 Jul 2010 03:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+DhdC0LVSN7 for ; Sat, 3 Jul 2010 03:27:14 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by core3.amsl.com (Postfix) with ESMTP id 4C2933A6828 for ; Sat, 3 Jul 2010 03:27:14 -0700 (PDT) Received: from [67.158.171.203] (helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1OUzwQ-0002Vm-TB; Sat, 03 Jul 2010 10:27:23 +0000 Message-ID: <4C2F108B.70504@cdatazone.org> Date: Sat, 03 Jul 2010 06:27:23 -0400 From: Rob Richards User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2DC7C5.2090009@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP2Go-MailScanner-Information: Please contact support@smtp2go.com for more information X-SMTP2Go-MailScanner-ID: 1OUzwQ-0002Vm-TB X-SMTP2Go-MailScanner: Found to be clean X-SMTP2Go-MailScanner-From: rrichards@cdatazone.org Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 10:27:15 -0000 Eran Hammer-Lahav wrote: > Hi Rob, > > I agree with you that a migration spec is important - please write one. > Like I didn't see that coming :) > As for every provider returning the same error code, I don't think that this will always be the case as some providers will return invalid-request on other security related errors to reduce the amount of information they return, or because they support different extensions, etc. The fact that both request fail is really the only significant consistency needed. > I agree with you on the fact about being able to handle them differently based on requirements, but believe there still needs to be a known set baseline. Think of a web server. By default all web servers will return a 404 for resourses that are not found, but the administrator/developer is free to override them. Clients then know to expect a 404 error when things are not found. Change in this behavior is typically then done to fir a sever applications needs or just for other reasons in which case would probably be documented by the provider. > I don't agree that the 2.0 core specification needs to cover 1.0 issues. That includes migrating from 1.0 to 2.0, supporting both, etc. > > EHL > Although I still disagree here since there is nothing between the 1.0 and 2.0 specs that concretely identify which version a resource call comes from, which really should be addressed in the spec iteself imo, I am willing to concede this point for now and just focus on the getting a migration spec written so that there is at least something official on this topic. On that note are there any guidelines, howtos, etc.. on writing a spec? Rob > >> -----Original Message----- >> From: Rob Richards [mailto:rrichards@cdatazone.org] >> Sent: Friday, July 02, 2010 4:05 AM >> To: Eran Hammer-Lahav >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Versioning >> >> Eran Hammer-Lahav wrote: >> >>> [Replying to everything at once...] >>> >>> >>>> -----Original Message----- >>>> From: Rob Richards [mailto:rrichards@cdatazone.org] >>>> Sent: Thursday, July 01, 2010 11:43 AM >>>> >>>> >>> >>>> Exactly. While it might be needed in the future, there is a need to >>>> differentiate OAuth 1.0 from 2.0 on resource endpoints right now. >>>> Outside of requiring an oauth_version parameter (or equivalent) all >>>> other suggestions leave versioning as a grey area, where things can >>>> be interpreted one way or another with no consistency. Grey areas in >>>> >> specs are a bad thing. >> >>>> You end up with different languages/libraries dealing with things in >>>> completely different and incompatible ways because something was not >>>> clearly spelled out. >>>> >>>> >>> This is an area that is clearly on the server side, not the client. Since the >>> >> core specification leaves discovery out, client developers need to know what >> version of OAuth is supported by the server and use the right one. Without >> discovery, the client must know ahead of time what to do. With discovery, >> the client can choose the right protocol. Either way, the client never just >> sends a 1.0 or 2.0 requests and hopes for the best. >> >>> On the server side, the challenge isn't that significant. When not using a >>> >> header, the server can use multiple methods to differentiate the version >> used by the client: >> >>> 1. Token syntax >>> 2. Presence of 'oauth_signature_method' >>> 3. Presence of 'oauth_signature' >>> 4. Presence of no other 'oauth_' parameter than 'oauth_token' >>> >>> >> Never said this was hard just that it needs to be documented. >> >>>> With this the spec needs to including some wording to explicitly >>>> define how to handle the case when running an endpoint supporting >>>> both OAuth >>>> 1.0 and 2.0 and the oauth2_token is missing then the call is handled >>>> according to the OAuth 1.0/a spec. Whatever is decided, be it a >>>> version parameter, the use of oauth2_token or the check for the >>>> existence of the oauth_signature_method parameter, etc///, the spec >>>> needs to define and be explicit on how a resource endpoint determines >>>> between a 1.0 and 2.0 call when both are supported. >>>> >>>> >>> The damage done by interpreting a malformed 1.0 request (the odd >>> >> attempt to use 1.0 by only including 'oauth_token') is at most returning an >> 'invalid-token' response. I hope every server developer understands that >> they should not share tokens between 1.0 and 2.0 with completely different >> security properties. >> >> Still the issue that different error codes returned which a client may handle >> differently. >> >>> I think there are more issue with regard to 1.0 to 2.0 migration that should >>> >> be addressed, and I have asked those who care about this to propose a draft. >> Given that such a draft will not be useful for a long time, given that the vast >> majority of OAuth implementation 1-2 years from now will be 2.0, I do not >> want to include it in the core specification. >> >>> In order for your argument to stand, you need to show how the current >>> >> setup leads to interoperability problems. Given the 4 options above, and the >> fact that a malformed 1.0 request will still fail, I do not agree that interop is >> affected. >> >>> >>> >> OAuth is a service that my company provides to other companies and we will >> need to run both versions in parallel for many of the customers. >> There are other companies out there who provide similar service, so this isn't >> just an isolated problem. We may be transitioning customers to/from our >> service and the behaviors of the systems need to be the same pre and post >> migration. >> There is also the WTF factor for developers. If I make calls to 2 providers (1.0 >> client), each of which is missing the oauth_signature, I would expect the >> same response back. An error that its missing a required signature. If one of >> the providers interprets a missing signature as meaning the call is a 2.0 based >> call then it will return back a different error code. >> >> I would expect that if I implemented 2 independent systems based on a spec >> they would operate and behave the exact same way, otherwise you can just >> throw the spec in the pile with the rest of them that have ambiguous >> sections left to interpretation and cause for argument over who >> implemented what correctly in their system. >> >> Rob >> > > From diogo.borges.almeida@gmail.com Sat Jul 3 04:50: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 5922A3A67BD for ; Sat, 3 Jul 2010 04:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xM6ylAb4i8H for ; Sat, 3 Jul 2010 04:50:09 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 87A343A6814 for ; Sat, 3 Jul 2010 04:50:09 -0700 (PDT) Received: by wwb24 with SMTP id 24so759363wwb.13 for ; Sat, 03 Jul 2010 04:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=GzAwvgU7C46hw+B8YoN9Im+kTJFGbdspTDCDU/7GED0=; b=wqppVeZ+quxxbLapKv8wlHNHXxmrBOf2V3d2Hb2ikhZzu4Qe2yhoStUYZf7cwYljpx cGREmsKOUaQN4eU8LOkO4H7nfHgt8ravXAyHdoz9zk5cwk9kHLS4gDJeAhiDXhoqMfzb u9ir5Z+M/hAUHtwMCloCEzmAud0di3jgUv92k= 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=PREiCQiUgKx42HQLGzJoEGe189m/8VAUkLdDaiyKoaoLjBhQcj0jZ970FysHBiqMSZ IcCZdvmJXSHsJyWVZRW428aB3agYJnp3Req/C7e1llb56larvJfT08z/rrO3AkbA6oSI 6XlmYSqSxkDuSyso+H8CPNZaQrlhkOjC7FBbI= Received: by 10.227.138.70 with SMTP id z6mr264996wbt.22.1278157816918; Sat, 03 Jul 2010 04:50:16 -0700 (PDT) Received: from [192.168.1.80] ([81.84.246.35]) by mx.google.com with ESMTPS id p29sm13265983wbc.1.2010.07.03.04.50.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 04:50:16 -0700 (PDT) From: Diogo Almeida Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Jul 2010 12:50:14 +0100 Message-Id: <60CEA1CE-0FF3-46F7-BC3E-A3BF75BE036B@gmail.com> To: oauth@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [OAUTH-WG] Questions regarding -09 section 3.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 11:50:11 -0000 Good afternoon, I would like to ask the WG two questions regarding -09 1) On section 3.1, regarding the scope parameter, it reads: code REQUIRED if the response type is "token" or "code-and-token", otherwise = MUST NOT be included. The authorization code generated by the = authorization server. The authorization code SHOULD expire shortly after = it is issued. The authorization server MUST invalidate the authorization = code after a single usage. The authorization code is bound to the client = identifier and redirection URI. Question: Is it a typo that the "code" parameter is REQUIRED if the = response type is "token" or "code-and-token", rather than "code" or = "code-and-token"? 2) Also in section 3.1 or -09, it's stated that the Authorization Response = contains the parameters: "code", "access_token", "expires_in", "scope" = and "state". Question: Would it make sense to also include an OPTIONAL = "refresh_token" to make this response more in line with section 4.2. = Access Token Response. Or the intention behind the decision of not = returning a "refresh_token" here was to make it so that the = "access_token" cannot be refreshed this way? Best regards, Diogo Almeida= From ian@mckellar.org Sat Jul 3 05:53:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3CEB3A69AA for ; Sat, 3 Jul 2010 05:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJvqqxaQkkY7 for ; Sat, 3 Jul 2010 05:53:43 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 23C133A67E2 for ; Sat, 3 Jul 2010 05:53:43 -0700 (PDT) Received: by vws14 with SMTP id 14so3099144vws.31 for ; Sat, 03 Jul 2010 05:53:52 -0700 (PDT) Received: by 10.220.62.5 with SMTP id v5mr88330vch.241.1278161631193; Sat, 03 Jul 2010 05:53:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.201.77 with HTTP; Sat, 3 Jul 2010 05:53:31 -0700 (PDT) In-Reply-To: <4C2F0EB4.2000602@lodderstedt.net> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F0EB4.2000602@lodderstedt.net> From: Ian McKellar Date: Sun, 4 Jul 2010 00:53:31 +1200 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 12:53:45 -0000 The user agent flow is really useful if you just require user interaction to issue new access tokens. There are big benefits (including security benefits[*]) to not involving the server. Ian [*] the security benefit being that I never have had to authorize your server to do action on my behalf, only software that's actually running on my computer that I can examine (view source) and audit. On Sat, Jul 3, 2010 at 10:19 PM, Torsten Lodderstedt wrote: > Is something as the user agent flow used in the wild today? What security > means are used their? > > I wonder why we do not drop the user agent flow from the spec because of > security reasons. From my point of view, the web flow could be used to > achieve a similar behavior except the JavaScript client could not directl= y > obtain its access tokens. Instead a(n) (application internal) protocol mu= st > be used between web site and user agent client to exchange (and refresh) > access tokens. > > Thoughts? > regards, > Torsten. > > Am 03.07.2010 06:12, schrieb Eran Hammer-Lahav: > > You are putting too much weight on the value of redirection URI > registration. Since the same problem exists between the user-agent script > and the server-side component used in the user-agent profile, anyone can > imitate that flow. In most cases, the redirection URI will simply include= a > script that will pass the parameter to the *parent* window which can be > anything. If the server-based page is an active page, it still needs to > communicate with the user-agent, which again, can pretend to be that. > > > > As long as the access token is passed back to the user-agent application, > you can imitate it and pretend to be another client. > > > > EHL > > > > From: Andrew Arnott [mailto:andrewarnott@gmail.com] > Sent: Friday, July 02, 2010 7:24 PM > To: Eran Hammer-Lahav > Cc: Ian McKellar; Marius Scurtescu; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user aut= h > response code-and-token's scope parameter) > > > > I agree with the installed client issue it cannot be solved. =C2=A0But fo= r a > browser-based user-agent script, it's particularly dangerous to not solve > it, and I believe it can be solved. =C2=A0By forbidding unregistered redi= rect_uri > values to be included in the request for a direct access token, user agen= t > scripts can't (as far as I can imagine) productively spoof other clients. > =C2=A0That is, they could pretend to be the popular client that is alread= y > authorized to get another access token, but the token would be sent to th= e > real client via redirect and not be accessible to the evil client. > > > > And it's the web-based client that I am most concerned about. An installe= d > client already has some degree of trust with the user since it is softwar= e > running on the OS. =C2=A0But any and every web site the user visits could= crack > your Facebook account (or any other OAuth-enabled resource server) simply= by > formulating the request with a client_id that has likely already been > authorized in a hidden iframe. > > > > I see this as a real problem, and I'm proposing what I believe is a worki= ng > solution. =C2=A0Again, I'm not trying=C2=A0to solve the installed client = problem and I > think that's much less severe anyway. =C2=A0But the web-based one must be= solved, > and this is a way to solve it IMO. > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the deat= h > your right to say it." - S. G. Tallentyre > > On Fri, Jul 2, 2010 at 2:13 PM, Eran Hammer-Lahav > wrote: > > There is nothing you can do to protect any non-server-based client from > imitating another client. All you can do is require the end-use to be > present when you cannot trust who the client is (assuming you trust the u= ser > to know what they are doing). What providers need to do is understand thi= s > and design their security and token scoping attributes according to their > own attack vectors. The spec should highlight these issues, but cannot so= lve > them. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > >> Of Ian McKellar >> Sent: Friday, July 02, 2010 2:10 PM >> To: Marius Scurtescu >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user au= th >> response code-and-token's scope parameter) >> >> No, that's a really simple recipe for disaster. >> >> Flickr kept opening up this security hole. They would allow applications >> to get >> new tokens simply using their api key & secret and a user's session >> cookies. If >> we assume that for a desktop user-agent will expose its secrets then thi= s >> is a >> really easy way to gain access to peoples' accounts. >> >> See: http://ianloic.com/2006/12/23/flickr_authentication_security/ >> and: http://ianloic.com/2009/01/05/no-more-secrets/ >> >> Ian >> >> On Sat, Jul 3, 2010 at 7:17 AM, Marius Scurtescu >> wrote: >> > On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott >> wrote: >> >> I guess as a minimum then, user-agent clients should never be issued >> >> access tokens without explicit user interaction? =C2=A0Otherwise ever= y web >> >> site around will automatically know who I am on facebook and who my >> >> friends are as soon as I authorize the one client that is popular. >> >> Or am I missing something? >> > >> > Most likely user interaction will be required for the first time, but >> > after that an immediate mode (no user interaction) is almost a must. >> > JavaScript clients will probably not be issued refresh tokens and >> > access tokens are short lived. It would not be practical to ask the >> > user every hour or so. In immediate mode there is no explicit user >> > interaction, but the user must be at the browser and have an active >> > session with the authz server. >> > >> > How would other web sites know about your facebook account? Are you >> > worried if the same JavaScript widget is embedded in multiple site and >> > that these instances share state? Or that the widget shares state with >> > the embedding site/page? Not sure about that. >> > >> > Marius >> > >> > >> >> -- >> >> Andrew Arnott >> >> "I [may] not agree with what you have to say, but I'll defend to the >> >> death your right to say it." - S. G. Tallentyre >> >> >> >> >> >> On Fri, Jul 2, 2010 at 10:02 AM, Eran Hammer-Lahav >> >> >> >> wrote: >> >>> >> >>> At the end of the day, there isn=E2=80=99t much you can do about use= r-agent >> >>> clients. Even a registered redirection URI doesn=E2=80=99t really he= lp >> >>> because that endpoint too cannot authenticate the client. >> >>> >> >>> >> >>> >> >>> EHL >> >>> >> >>> >> >>> >> >>> From: Andrew Arnott [mailto:andrewarnott@gmail.com] >> >>> Sent: Friday, July 02, 2010 9:51 AM >> >>> To: Eran Hammer-Lahav >> >>> Cc: OAuth WG (oauth@ietf.org) >> >>> Subject: Re: [OAUTH-WG] End user auth response code-and-token's >> >>> scope parameter >> >>> >> >>> >> >>> >> >>> Ah! =C2=A0Yes I'd missed the second scope parameter that web servers= have >> >>> the opportunity to see. =C2=A0And your point makes sense. >> >>> >> >>> >> >>> >> >>> Is this reduced scope on the access token, and the encouragement for >> >>> a registered redirect_uri, the only mitigations we have for this >> >>> possible attack? >> >>> >> >>> >> >>> >> >>> Popular client app=C2=A0A=C2=A0is broadly authorized by users on the= web. >> >>> Evil client app B=C2=A0is added as javascript on a web site. =C2=A0V= ictim >> >>> visits that web site, and the evil client quietly requests an access >> >>> token from auth server using a request claiming to be from client >> >>> app A. =C2=A0Since client app A=C2=A0wasn't required to register a >> >>> redirect_uri and did not do so, client app B=C2=A0is successful in >> >>> supplying its own redirect_uri and gains an access token without >> >>> user intervention or knowledge, since the user had already >> >>> authorized client A and the auth server just freely granted a new >> >>> access token. =C2=A0Client app B then uses AJAX to send access token= to the >> attacker, who can now exploit the access token from a separate machine. >> >>> >> >>> >> >>> >> >>> I brought this attack up once before. =C2=A0I really feel the spec s= hould >> >>> forbid issuing access tokens directly to user-agent clients when >> >>> they haven't registered a redirect_uri. =C2=A0Another mitigation is = that >> >>> implicit re-issuing of an access token to a previously authorized >> >>> client should be banned without a registered redirect_uri (although >> >>> this only reduces the risk, as the user is still presented with the >> >>> wrong >> client name). >> >>> >> >>> >> >>> >> >>> Thoughts? >> >>> >> >>> -- >> >>> Andrew Arnott >> >>> "I [may] not agree with what you have to say, but I'll defend to the >> >>> death your right to say it." - S. G. Tallentyre >> >>> >> >>> On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav >> >>> >> >>> wrote: >> >>> >> >>> Scope is specific to the access token, not the code. In fact, I >> >>> expect some providers to issue an access token with a lesser scope >> >>> than that provided when exchanging the authorization code later >> >>> (which will include another scope). This is because the >> >>> authorization server can authenticate the client when using the >> authorization code and provide greater access. >> >>> >> >>> >> >>> >> >>> EHL >> >>> >> >>> >> >>> >> >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> >>> Behalf Of Andrew Arnott >> >>> Sent: Friday, July 02, 2010 9:26 AM >> >>> To: OAuth WG (oauth@ietf.org) >> >>> Subject: [OAUTH-WG] End user auth response code-and-token's scope >> >>> parameter >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> If the response type is=C2=A0code-and-token, the authorization serve= r >> >>> adds the=C2=A0codeand=C2=A0state=C2=A0parameters to the redirection = URI query >> >>> component and theaccess_token,=C2=A0scope, and=C2=A0expires_in=C2=A0= to the >> >>> redirection URI fragment using theapplication/x-www-form- >> urlencoded=C2=A0format as defined by... >> >>> >> >>> >> >>> >> >>> Since the scope applies equally to both the code and access_token >> >>> parameters, it seems that scope should be included in the URI query >> >>> part so it is available to the web server as well as the user-agent. >> >>> While the scope remains in the fragment, the client's web server >> >>> won't know whether the full scope it requested was actually granted. >> >>> >> >>> >> >>> >> >>> Was there an advantage to including the scope only in the #fragment, >> >>> or was this just an oversight? >> >>> >> >>> >> >>> >> >>> Thanks. >> >>> >> >>> -- >> >>> Andrew Arnott >> >>> "I [may] not agree with what you have to say, but I'll defend to the >> >>> death your right to say it." - S. G. Tallentyre >> >>> >> >>> >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> >> >> >> -- >> Ian McKellar =C2=A0 >> ian@mckellar.org: email | jabber | msn >> ianloic: flickr | aim | yahoo | skype | linkedin | etc. >> _______________________________________________ >> 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 Ian McKellar ian@mckellar.org: email | jabber | msn ianloic: flickr | aim | yahoo | skype | linkedin | etc. From lshepard@facebook.com Sat Jul 3 07:25:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FC8E3A688E for ; Sat, 3 Jul 2010 07:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZUrFft9Y4pg for ; Sat, 3 Jul 2010 07:25:16 -0700 (PDT) Received: from mx-out.facebook.com (outmail015.snc4.facebook.com [66.220.144.147]) by core3.amsl.com (Postfix) with ESMTP id 189F33A686E for ; Sat, 3 Jul 2010 07:25:15 -0700 (PDT) Received: from [10.129.72.189] ([10.129.72.189:37500] helo=mx-out.facebook.com) by mta010.snc4.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id B9/E1-17559-3F54F2C4; Sat, 03 Jul 2010 07:15:16 -0700 Received: from [10.18.255.139] ([10.18.255.139:29097] helo=mail.thefacebook.com) by mta009.ash1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 32/E1-27949-3F54F2C4; Sat, 03 Jul 2010 07:15:15 -0700 Received: from sc-hub06.TheFacebook.com (192.168.18.83) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.694.1; Sat, 3 Jul 2010 07:15:14 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Sat, 3 Jul 2010 07:15:14 -0700 From: Luke Shepard To: Torsten Lodderstedt Date: Sat, 3 Jul 2010 07:15:21 -0700 Thread-Topic: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) Thread-Index: AcsauieXQHtIKRRIQhG2he6h4qbfsw== Message-ID: <9FC614F1-2FEE-4A27-BA01-919A3EC5A424@facebook.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F0EB4.2000602@lodderstedt.net> In-Reply-To: <4C2F0EB4.2000602@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 14:25:17 -0000 On Jul 3, 2010, at 3:19 AM, Torsten Lodderstedt wrote: > Is something as the user agent flow used in the wild today? What security= means are used their? Yes. Facebook has shipped it: http://developers.facebook.com/docs/authentic= ation/desktop We require either pre-registration of the callback URL, or that the app use= s a standard redirect URL on Facebook.com (which could only be used by a de= sktop app). > I wonder why we do not drop the user agent flow from the spec because of = security reasons. From my point of view, the web flow could be used to achi= eve a similar behavior except the JavaScript client could not directly obta= in its access tokens. Correct. The main purpose of the user-agent flow is to allow a Javascript c= lient to obtain an access token without requiring the presence of a secret,= or a server. There are cases when you have an app without a server component, and you do= n't want to require a secret key (which can be revealed) From dick.hardt@gmail.com Sat Jul 3 09:02:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C568E28C0D7 for ; Sat, 3 Jul 2010 09:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[AWL=-1.168, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuKV2Xn48UIQ for ; Sat, 3 Jul 2010 09:02:44 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id A2A6128B56A for ; Sat, 3 Jul 2010 09:02:44 -0700 (PDT) Received: by pwj2 with SMTP id 2so2118802pwj.31 for ; Sat, 03 Jul 2010 09:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=OQCMKKVzCWEGuu8pHj8gkel6of4lp5cD2EI8oJMvvMU=; b=by+R7aE2ZnrMrg3McIPoi3DU+sGWQfxDruijL72xlgA8F0jJsyoP8IVIN/7LoEWj5J GzswpxckQ8pEFhhISuATchALhFR5X+GKSD8gFEQi2gFwNLN00+myU2eMhvg4GUXVcSy3 v9oDmhi3Gomc8navmmBtDDhKdp9WVLzoJkUOM= 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=Vpao3HJD3DQNLQSr+UtVLhiRuuuK+8tHdnEdrYdnZc1VtdCTWiTvYkoVmZd7w0WEwg 7ulOzYY9dhAa43/PNno3z1pNpIgFNOouycW14PpCgOKAmcrAYjgcJMpn6V7z/nEs59xR 7tNg+Q9iERVo28y8YiIkV+0Vt7RzIlWLiGtGk= Received: by 10.142.48.18 with SMTP id v18mr660718wfv.101.1278172973962; Sat, 03 Jul 2010 09:02:53 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id l40sm2227614rvb.18.2010.07.03.09.02.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 09:02:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Sat, 3 Jul 2010 09:02:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> To: Paul Tarjan X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 16:02:45 -0000 On 2010-07-02, at 5:04 PM, Paul Tarjan wrote: >>> We don't think base64url will work, because the most common error = we'll see is that developers forget the "url" part and just do plain = base64, and that's not sufficient because the stock set includes +. >>=20 >> I think forgetting to url-decode is more likely than doing the wrong = base64 encoding. At least with the wrong base64 encoding, what was done = wrong is more obvious right away. The + will not be in the string. >=20 > Most web frameworks that I know of urldecode the inputs before they = even hit application code.=20 >=20 >=20 >=20 >>>=20 >>> So it will maybe work, maybe not. Maybe they'll do urlencoding after = anyways, since if they are passing this as a query param, or post data, = client libraries will take a dict and try to "do the right thing". And = we end up with pluses, and we're not quite sure if they should be = urldecoded or not. >>=20 >> we won't have pluses >=20 > I think Naitik is saying that accidentally doing base64 and not = base64url will send some '+'s along. if there are '+'s in the token, then it is easy for someone helping to = spot the problem. also easy for servers to send back an error message = saying, "hey, looks like you are using base64 instead of base64url = encoding" ie, it is easy to detect the error -- urlencoding / decoding is hard to = detect as an error >=20 >=20 >=20 >=20 >> why hex? ... why not base64url? >=20 > It seems to be the encoding format in languages: >=20 > python: >>>> hmac.new('secret', 'payload', hashlib.sha256).hexdigest() > 'b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4' >=20 > php: > print hash_hmac('sha256', 'payload', 'secret'); > b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba >=20 > ruby: >>> HMAC::SHA256.hexdigest('secret', 'payload') > =3D> = "b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4" When I wrote a sample in Perl, it was pretty easy to make it base64url = which then provides a consistent encoding. >=20 >> I am unclear on what your point is.=20 >>=20 >> The token would be included as one of the headers. This is often = preferable as it separates the authorization layer (in header) from = application layer parameters (query string or message body) >=20 > With our proposal, we were focussed on url parameters (hence the = choice of urlencode after it was all put together). I think it makes = total sense to not do the encoding as part of the sig spec, and let the = transport choice dictate which encoding to use. I understand what you are saying. having multiple encodings makes = libraries harder, and leads to the issues that motivated base64url over = url-encoding >=20 > Therefore, I think we should make the signature: >=20 > hash + '.' + json string >=20 > And then if you are putting it in a url parameter, you should = urlencode the whole thing. If you are putting it in an HTTP header you = should remove all the "\r" and "\n" in the json output (which are only = whitespace as they aren't allowed inside strings, and most language = encoders won't even output them by default).=20 >=20 > This way, this is a general signature spec, regardless of how it is = being sent. You could send it as a DNS record and do the proper encoding = for that scenario, or carrier pigeon encoded in Navajo, etc.=20 >=20 >=20 >=20 > So to sum up: >=20 > * We'd like the signature first (so you can left split instead of = right split) What are the advantages of left split vs right split? > * We'd like the signature to be hex encoded instead of base64url = because that's how the common usage is nowadays one encoding for everything seems simpler to do > * We'd like to not encode the payload (other than JSON) and let the = choice of transport layer dictate how to handle encoding the whole = thing. I don't understand why you think this is a good idea. >=20 > Sound good? nope From naitiks@gmail.com Sat Jul 3 09:13:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187363A6811 for ; Sat, 3 Jul 2010 09:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=0.232, 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 pjG9iEoNyxr4 for ; Sat, 3 Jul 2010 09:13:48 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id AF7A33A67D0 for ; Sat, 3 Jul 2010 09:13:47 -0700 (PDT) Received: by iwn10 with SMTP id 10so1971870iwn.31 for ; Sat, 03 Jul 2010 09:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=s5R0W3Gd2dFL8v8s6+xXepQPQlAWbx+iKR/6axysYGc=; b=c62knHDgl7UdwLdIo8o2QLlpcOpR2a2A3OsJ0TauauE6WoJ+/u2EAgO8zGuAl+UgdG HTlEzan8MECa+PS22mIsWhoazPoP3GKusxkJ+0P/ZQN7lNGv3z+uKpejDAV6wGWIE5QI PRb0vDIRbVr5BP/OHnK4Vjjw/Jmq9xKKJoRT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=gbccj549C4HEt6Fkh7t5gAbKJST/lXAaqbfcuSbOJLLoLDeF7JLim1zZmGXfnifg36 HGhtYMmPa8dNaklklBp/bJ9AAyYEchn/VzZUFxjL1Rbws37wdH6u3EFmNsdEk3G/hJKA VJAkf9ZGHXhyibyVmlO4CG2NsHApid7xNDKdA= Received: by 10.231.35.195 with SMTP id q3mr593605ibd.22.1278173639297; Sat, 03 Jul 2010 09:13:59 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.231.170.9 with HTTP; Sat, 3 Jul 2010 09:13:39 -0700 (PDT) In-Reply-To: References: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> From: Naitik Shah Date: Sat, 3 Jul 2010 09:13:39 -0700 X-Google-Sender-Auth: wUCo7wOiZt3mLy4oXex075eMyCk Message-ID: To: Dick Hardt Content-Type: multipart/alternative; boundary=0022152d6cb5bb5480048a7dfd86 Cc: OAuth WG Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 16:13:50 -0000 --0022152d6cb5bb5480048a7dfd86 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 3, 2010 at 9:02 AM, Dick Hardt wrote: > > On 2010-07-02, at 5:04 PM, Paul Tarjan wrote: > > >>> We don't think base64url will work, because the most common error we'll > see is that developers forget the "url" part and just do plain base64, and > that's not sufficient because the stock set includes +. > >> > >> I think forgetting to url-decode is more likely than doing the wrong > base64 encoding. At least with the wrong base64 encoding, what was done > wrong is more obvious right away. The + will not be in the string. > > > > Most web frameworks that I know of urldecode the inputs before they even > hit application code. > > > > > > > >>> > >>> So it will maybe work, maybe not. Maybe they'll do urlencoding after > anyways, since if they are passing this as a query param, or post data, > client libraries will take a dict and try to "do the right thing". And we > end up with pluses, and we're not quite sure if they should be urldecoded or > not. > >> > >> we won't have pluses > > > > I think Naitik is saying that accidentally doing base64 and not base64url > will send some '+'s along. > > if there are '+'s in the token, then it is easy for someone helping to spot > the problem. also easy for servers to send back an error message saying, > "hey, looks like you are using base64 instead of base64url encoding" > > ie, it is easy to detect the error -- urlencoding / decoding is hard to > detect as an error > The pluses are not guaranteed. They may or may not be there depending on the data stream you're encoding. If you don't urlencode the JSON, you'll get a "{", if you do it once, you'll get a "%7B", if you do it twice, you'll get a "%257B" -- seems easier to detect. > > > > > > > > > >> why hex? ... why not base64url? > > > > It seems to be the encoding format in languages: > > > > python: > >>>> hmac.new('secret', 'payload', hashlib.sha256).hexdigest() > > 'b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4' > > > > php: > > print hash_hmac('sha256', 'payload', 'secret'); > > b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba > > > > ruby: > >>> HMAC::SHA256.hexdigest('secret', 'payload') > > => "b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4" > > When I wrote a sample in Perl, it was pretty easy to make it base64url > which then provides a consistent encoding. > Did it involve a string replace call? Or a third party library? > > > >> I am unclear on what your point is. > >> > >> The token would be included as one of the headers. This is often > preferable as it separates the authorization layer (in header) from > application layer parameters (query string or message body) > > > > With our proposal, we were focussed on url parameters (hence the choice > of urlencode after it was all put together). I think it makes total sense to > not do the encoding as part of the sig spec, and let the transport choice > dictate which encoding to use. > > I understand what you are saying. having multiple encodings makes libraries > harder, and leads to the issues that motivated base64url over url-encoding > > > > Therefore, I think we should make the signature: > > > > hash + '.' + json string > > > > And then if you are putting it in a url parameter, you should urlencode > the whole thing. If you are putting it in an HTTP header you should remove > all the "\r" and "\n" in the json output (which are only whitespace as they > aren't allowed inside strings, and most language encoders won't even output > them by default). > > > > This way, this is a general signature spec, regardless of how it is being > sent. You could send it as a DNS record and do the proper encoding for that > scenario, or carrier pigeon encoded in Navajo, etc. > > > > > > > > So to sum up: > > > > * We'd like the signature first (so you can left split instead of right > split) > > What are the advantages of left split vs right split? > Built in split function with a limit is more common, which makes the left split easier. -Naitik --0022152d6cb5bb5480048a7dfd86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Jul 3, 2010 at 9:02 AM, Dick Har= dt <dick.hardt= @gmail.com> wrote:

On 2010-07-02, at 5:04 PM, Paul Tarjan wrote:

>>> We don't think base64url will work, because the most commo= n error we'll see is that developers forget the "url" part an= d just do plain base64, and that's not sufficient because the stock set= includes +.
>>
>> I think forgetting to url-decode is more likely than doing the wro= ng base64 encoding. At least with the wrong base64 encoding, what was done = wrong is more obvious right away. The + will not be in the string.
>
> Most web frameworks that I know of urldecode the inputs before they ev= en hit application code.
>
>
>
>>>
>>> So it will maybe work, maybe not. Maybe they'll do urlenco= ding after anyways, since if they are passing this as a query param, or pos= t data, client libraries will take a dict and try to "do the right thi= ng". And we end up with pluses, and we're not quite sure if they s= hould be urldecoded or not.
>>
>> we won't have pluses
>
> I think Naitik is saying that accidentally doing base64 and not base64= url will send some '+'s along.

if there are '+'s in the token, then it is easy for someone h= elping to spot the problem. also easy for servers to send back an error mes= sage saying, "hey, looks like you are using base64 instead of base64ur= l encoding"

ie, it is easy to detect the error -- urlencoding / decoding is hard to det= ect as an error

The pluses are not=C2= =A0guaranteed. They may or may not be there depending on the data stream yo= u're encoding. If you don't urlencode the JSON, you'll get a &q= uot;{", if you do it once, you'll get a "%7B", if you do= it twice, you'll get a "%257B" -- seems easier to detect.
=C2=A0



>
>
>
>
>> why hex? ... why not base64url?
>
> It seems to be the encoding format in languages:
>
> python:
>>>> hmac.new('secret', 'payload', hashlib.sha2= 56).hexdigest()
> 'b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4&= #39;
>
> php:
> print hash_hmac('sha256', 'payload', 'secret')= ;
> b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba
>
> ruby:
>>> HMAC::SHA256.hexdigest('secret', 'payload') > =3D> "b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e83= 75a42ba4"

When I wrote a sample in Perl, it was pretty easy to make it base64ur= l which then provides a consistent encoding.

Did it involve a string replace call? Or a third party library?
=C2=A0



>
>> I am unclear on what your point is.
>>
>> The token would be included as one of the headers. This is often p= referable as it separates the authorization layer (in header) from applicat= ion layer parameters (query string or message body)
>
> With our proposal, we were focussed on url parameters (hence the choic= e of urlencode after it was all put together). I think it makes total sense= to not do the encoding as part of the sig spec, and let the transport choi= ce dictate which encoding to use.

I understand what you are saying. having multiple encodings makes lib= raries harder, and leads to the issues that motivated base64url over url-en= coding=C2=A0
=C2=A0

>
> Therefore, I think we should make the signature:
>
> =C2=A0 =C2=A0hash + '.' + json string
>
> And then if you are putting it in a url parameter, you should urlencod= e the whole thing. If you are putting it in an HTTP header you should remov= e all the "\r" and "\n" in the json output (which are o= nly whitespace as they aren't allowed inside strings, and most language= encoders won't even output them by default).
>
> This way, this is a general signature spec, regardless of how it is be= ing sent. You could send it as a DNS record and do the proper encoding for = that scenario, or carrier pigeon encoded in Navajo, etc.
>
>
>
> So to sum up:
>
> * We'd like the signature first (so you can left split instead of = right split)

What are the advantages of left split vs right split?

Built in split function with a limit is more common, w= hich makes the left split easier.



-Naitik

--0022152d6cb5bb5480048a7dfd86-- From benl@google.com Sat Jul 3 09:27: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 288A23A67F4 for ; Sat, 3 Jul 2010 09:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.67 X-Spam-Level: X-Spam-Status: No, score=-100.67 tagged_above=-999 required=5 tests=[AWL=-1.107, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT6ukwEP3YGP for ; Sat, 3 Jul 2010 09:27:05 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 931893A67F0 for ; Sat, 3 Jul 2010 09:27:04 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o63GRFOk008799 for ; Sat, 3 Jul 2010 09:27:15 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278174436; bh=RIZ99XAvH+QAdCBnrUUDoVToDBY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=iz/2oA3rCZKmElWbxOy+Q3g1Mh+4OLLXar8z1XI7cc/tzvWTj/C4e5VYdgi/jGsUj 5wYly/ibKNg+Xie6ZvzQg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=bzi3g2JHYNupm9jxgilQPmbb8WVBvBk9/l6oh8DDND512XgJTEBI3ZpJ4LP85TtLY /dKLzor3ptaB6ICmaMNdw== Received: from pzk28 (pzk28.prod.google.com [10.243.19.156]) by kpbe11.cbf.corp.google.com with ESMTP id o63GREAF021171 for ; Sat, 3 Jul 2010 09:27:14 -0700 Received: by pzk28 with SMTP id 28so871549pzk.23 for ; Sat, 03 Jul 2010 09:27:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.134.7 with SMTP id h7mr698329wfd.25.1278174433700; Sat, 03 Jul 2010 09:27:13 -0700 (PDT) Received: by 10.143.178.6 with HTTP; Sat, 3 Jul 2010 09:27:10 -0700 (PDT) In-Reply-To: References: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> Date: Sat, 3 Jul 2010 17:27:10 +0100 Message-ID: From: Ben Laurie To: Naitik Shah 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] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 16:27:06 -0000 Let's not lose sight of the underlying reason to choose base64: avoiding the issue of canonicalisation. If you use an encoding that various software layers can choose to decode and operate on, then you open the canonicalisation can of worms. The point of using base64 is so the blob you hand around is just that: a blob, which no-one can process except the guy who actually wants to process it. And a more general plea: can we please stop trimming everything down to the bare minimum we can get away with? This is equivalent to maximising fragility, which is a bad idea and has led to several notable failures of late. On 3 July 2010 17:13, Naitik Shah wrote: > > > On Sat, Jul 3, 2010 at 9:02 AM, Dick Hardt wrote: >> >> On 2010-07-02, at 5:04 PM, Paul Tarjan wrote: >> >> >>> We don't think base64url will work, because the most common error >> >>> we'll see is that developers forget the "url" part and just do plain= base64, >> >>> and that's not sufficient because the stock set includes +. >> >> >> >> I think forgetting to url-decode is more likely than doing the wrong >> >> base64 encoding. At least with the wrong base64 encoding, what was do= ne >> >> wrong is more obvious right away. The + will not be in the string. >> > >> > Most web frameworks that I know of urldecode the inputs before they ev= en >> > hit application code. >> > >> > >> > >> >>> >> >>> So it will maybe work, maybe not. Maybe they'll do urlencoding after >> >>> anyways, since if they are passing this as a query param, or post da= ta, >> >>> client libraries will take a dict and try to "do the right thing". A= nd we >> >>> end up with pluses, and we're not quite sure if they should be urlde= coded or >> >>> not. >> >> >> >> we won't have pluses >> > >> > I think Naitik is saying that accidentally doing base64 and not >> > base64url will send some '+'s along. >> >> if there are '+'s in the token, then it is easy for someone helping to >> spot the problem. also easy for servers to send back an error message >> saying, "hey, looks like you are using base64 instead of base64url encod= ing" >> >> ie, it is easy to detect the error -- urlencoding / decoding is hard to >> detect as an error > > The pluses are not=A0guaranteed. They may or may not be there depending o= n the > data stream you're encoding. If you don't urlencode the JSON, you'll get = a > "{", if you do it once, you'll get a "%7B", if you do it twice, you'll ge= t a > "%257B" -- seems easier to detect. > > >> >> > >> > >> > >> > >> >> why hex? ... why not base64url? >> > >> > It seems to be the encoding format in languages: >> > >> > python: >> >>>> hmac.new('secret', 'payload', hashlib.sha256).hexdigest() >> > 'b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4' >> > >> > php: >> > print hash_hmac('sha256', 'payload', 'secret'); >> > b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba >> > >> > ruby: >> >>> HMAC::SHA256.hexdigest('secret', 'payload') >> > =3D> "b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4= " >> >> When I wrote a sample in Perl, it was pretty easy to make it base64url >> which then provides a consistent encoding. > > Did it involve a string replace call? Or a third party library? > > >> >> > >> >> I am unclear on what your point is. >> >> >> >> The token would be included as one of the headers. This is often >> >> preferable as it separates the authorization layer (in header) from >> >> application layer parameters (query string or message body) >> > >> > With our proposal, we were focussed on url parameters (hence the choic= e >> > of urlencode after it was all put together). I think it makes total se= nse to >> > not do the encoding as part of the sig spec, and let the transport cho= ice >> > dictate which encoding to use. >> >> I understand what you are saying. having multiple encodings makes >> libraries harder, and leads to the issues that motivated base64url over >> url-encoding >> >> >> >> > >> > Therefore, I think we should make the signature: >> > >> > =A0 =A0hash + '.' + json string >> > >> > And then if you are putting it in a url parameter, you should urlencod= e >> > the whole thing. If you are putting it in an HTTP header you should re= move >> > all the "\r" and "\n" in the json output (which are only whitespace as= they >> > aren't allowed inside strings, and most language encoders won't even o= utput >> > them by default). >> > >> > This way, this is a general signature spec, regardless of how it is >> > being sent. You could send it as a DNS record and do the proper encodi= ng for >> > that scenario, or carrier pigeon encoded in Navajo, etc. >> > >> > >> > >> > So to sum up: >> > >> > * We'd like the signature first (so you can left split instead of righ= t >> > split) >> >> What are the advantages of left split vs right split? > > Built in split function with a limit is more common, which makes the left > split easier. > > > -Naitik > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From dick.hardt@gmail.com Sat Jul 3 09:42: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 AAA143A67F4 for ; Sat, 3 Jul 2010 09:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.682 X-Spam-Level: X-Spam-Status: No, score=-1.682 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfxLumYe47nr for ; Sat, 3 Jul 2010 09:42:25 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 8E57A3A67D0 for ; Sat, 3 Jul 2010 09:42:25 -0700 (PDT) Received: by pxi20 with SMTP id 20so2153014pxi.31 for ; Sat, 03 Jul 2010 09:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=v8bE6SQDUAGRWJ+YqT8fF1nZ81HuYUo6oSvcu9cJzFA=; b=deTvnQmHJDefU0IICt/By3jTsdbloXYK3RiU5hII4U5n3o1Rc6i+hVtBuO5x3Vmxgl /nupGdh5SVLnkCiW1zX0jlxbGKCYSpUhtylPOkOPxTWyFRw1pFYBOG37/ZA1fQrz1c5E rfhafbC8ZGa/l6vPsBmMJkDvbjpVI/bxgXEjQ= 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=CCt7u9tzALkvvSXp0YDnvmj/3/OqUHt0NoawwH9OdZ15nIUSyBbgEnDQHq+1OMOKQc uRsYiNJitWjqDE6HiBKUo5I45Tly1T7PWS7YwAY86VkUEEyb5d0dE01B+l9Je3ULaC2P cSuaQ4OJ3Qsa6vCBF7SAooIB222aAN+mtvHXM= Received: by 10.114.57.14 with SMTP id f14mr570676waa.180.1278175355620; Sat, 03 Jul 2010 09:42:35 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id k23sm30849126waf.17.2010.07.03.09.42.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 09:42:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-1--779557441 From: Dick Hardt In-Reply-To: Date: Sat, 3 Jul 2010 09:42:33 -0700 Message-Id: <6B008ED4-4536-4A95-89B6-917696E6AF79@gmail.com> References: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> To: Naitik Shah X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 16:42:26 -0000 --Apple-Mail-1--779557441 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-07-03, at 9:13 AM, Naitik Shah wrote: > > I think Naitik is saying that accidentally doing base64 and not = base64url will send some '+'s along. >=20 > if there are '+'s in the token, then it is easy for someone helping to = spot the problem. also easy for servers to send back an error message = saying, "hey, looks like you are using base64 instead of base64url = encoding" >=20 > ie, it is easy to detect the error -- urlencoding / decoding is hard = to detect as an error >=20 > The pluses are not guaranteed. They may or may not be there depending = on the data stream you're encoding. If you don't urlencode the JSON, = you'll get a "{", if you do it once, you'll get a "%7B", if you do it = twice, you'll get a "%257B" -- seems easier to detect. Your earlier point was that developers may incorrectly use base64 = instead of base64url. If they used base64, and if there is a + / =3D or = % in the string, the server can send a useful note saying what is wrong. = There may not be one of those characters depending on the input string, = but if there is, then the server can suggest what the error might be = using base64 instead of base64url. If the token contains ANY character = that is not in base64url, then the server can say that it is not = base64url encoded. That seems pretty fool proof to detect. Note that you should never get = any %7B or other encoding in the token as it is url safe. >=20 > When I wrote a sample in Perl, it was pretty easy to make it base64url = which then provides a consistent encoding. >=20 > Did it involve a string replace call? Or a third party library? I used a standard CPAN library. > =20 >=20 >=20 >=20 > > > >> I am unclear on what your point is. > >> > >> The token would be included as one of the headers. This is often = preferable as it separates the authorization layer (in header) from = application layer parameters (query string or message body) > > > > With our proposal, we were focussed on url parameters (hence the = choice of urlencode after it was all put together). I think it makes = total sense to not do the encoding as part of the sig spec, and let the = transport choice dictate which encoding to use. >=20 > I understand what you are saying. having multiple encodings makes = libraries harder, and leads to the issues that motivated base64url over = url-encoding=20 Glad we agree on that. > > > > * We'd like the signature first (so you can left split instead of = right split) >=20 > What are the advantages of left split vs right split? >=20 > Built in split function with a limit is more common, which makes the = left split easier. Size limit I am assuming? Since the size of the signature is known, this = makes it safer to have it first? Makes sense to me. --Apple-Mail-1--779557441 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
> I think Naitik is saying = that accidentally doing base64 and not base64url will send some '+'s = along.

if there are '+'s in the token, then it is easy for someone = helping to spot the problem. also easy for servers to send back an error = message saying, "hey, looks like you are using base64 instead of = base64url encoding"

ie, it is easy to detect the error -- urlencoding / decoding is hard to = detect as an error

The pluses are = not guaranteed. They may or may not be there depending on the data = stream you're encoding. If you don't urlencode the JSON, you'll get a = "{", if you do it once, you'll get a "%7B", if you do it twice, you'll = get a "%257B" -- seems easier to = detect.

Your earlier point = was that developers may incorrectly use base64 instead of base64url. If = they used base64, and if there is a + / =3D or % in the string, the = server can send a useful note saying what is wrong. There may not be one = of those characters depending on the input string, but if there is, then = the server can suggest what the error might be using base64 instead of = base64url. If the token contains ANY character that is not in base64url, = then the server can say that it is not base64url = encoded.

That seems pretty fool proof to = detect. Note that you should never get any %7B or other encoding in the = token as it is url safe.
When I wrote a sample in Perl, it was pretty easy to make it = base64url which then provides a consistent = encoding.

Did it involve a string = replace call? Or a third party = library?

I used a standard = CPAN library.

 



>
>> I am unclear on what your point is.
>>
>> The token would be included as one of the headers. This is = often preferable as it separates the authorization layer (in header) = from application layer parameters (query string or message body)
>
> With our proposal, we were focussed on url parameters (hence the = choice of urlencode after it was all put together). I think it makes = total sense to not do the encoding as part of the sig spec, and let the = transport choice dictate which encoding to use.

I understand what you are saying. having multiple encodings makes = libraries harder, and leads to the issues that motivated base64url over = url-encoding 

Glad we = agree on that.

>
> * We'd like the signature first (so you can left split instead of = right split)

What are the advantages of left split vs right = split?

Built in split function with = a limit is more common, which makes the left split = easier.

Size limit I am = assuming? Since the size of the signature is known, this makes it safer = to have it first? Makes sense to = me.

= --Apple-Mail-1--779557441-- From dick.hardt@gmail.com Sat Jul 3 11:35: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 8FAAB3A6781 for ; Sat, 3 Jul 2010 11:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.191, 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 ZJ8cShoM2Utq for ; Sat, 3 Jul 2010 11:35:57 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 71B173A682A for ; Sat, 3 Jul 2010 11:35:56 -0700 (PDT) Received: by pxi20 with SMTP id 20so2178463pxi.31 for ; Sat, 03 Jul 2010 11:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=74QhIpzHCzrJvRB8pqDFsQxfxdhh7J1RQOJGYm9Sxi0=; b=wp8pNUtYfNtpbzHbx4hXJrvMc4She3vl537S9jgwxusgb4luvIEk9ltEntE+ifgZwh Oxt2MSx5tKKyzIaLeBK5xo16nWhtENeso/isdPtVtOcFZCAmzl+Dg8SRrG1zD1lXu1gK kGYLOOLbiMULJVMXUJHT/WaRPifWiIKFS6Qz0= 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=xuU2aG9HCcDR9ewOeVIGK1XwdGkkHLsYUv9z6iRs5FB/AXqi56xq8a8d+YKZvmsBqg 2LemHN/IhfMN5qnF3Aaj7Px6mvnuJs3Rqjk0jL8cqK42XP0ww71PiqOCdtgnTyP2Er4H IfIS4yttk2jEi2AEQ1jinx/2U+L7hqe8Eswrk= Received: by 10.142.134.7 with SMTP id h7mr785388wfd.267.1278182166560; Sat, 03 Jul 2010 11:36:06 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id g37sm2358357rvb.5.2010.07.03.11.36.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 11:36:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-5--772746886 From: Dick Hardt In-Reply-To: <20ACF96E-5753-4004-BE44-96BAD43FE7C9@facebook.com> Date: Sat, 3 Jul 2010 11:36:03 -0700 Message-Id: References: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> <6B008ED4-4536-4A95-89B6-917696E6AF79@gmail.com> <20ACF96E-5753-4004-BE44-96BAD43FE7C9@facebook.com> To: Luke Shepard X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 18:35:59 -0000 --Apple-Mail-5--772746886 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-07-03, at 11:28 AM, Luke Shepard wrote: >>=20 >>> > >>> > * We'd like the signature first (so you can left split instead of = right split) >>>=20 >>> What are the advantages of left split vs right split? >>>=20 >>> Built in split function with a limit is more common, which makes the = left split easier. >>=20 >> Size limit I am assuming? Since the size of the signature is known, = this makes it safer to have it first? Makes sense to me. >=20 > Sounds like we agree on this point at least. sortof, I don't disagree :) >=20 > The main reason is that it's easier to restrict the delimiter from = appearing in the signature than in the payload. This way the delimiter = (period) can show up in the payload and a left split can still work. if each string is base64url, then the period is always the separator I am still and advocate for a separate string which is the payload. I = consider this mechanism to be more generic than OAuth request = signatures. I think it can be used for OAuth tokens as well. --Apple-Mail-5--772746886 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
>
> * We'd like the signature first (so you can left split instead of = right split)

What are the advantages of left split vs right = split?

Built in split function with = a limit is more common, which makes the left split = easier.

Size limit I am = assuming? Since the size of the signature is known, this makes it safer = to have it first? Makes sense to = me.

Sounds like we agree on = this point at least.

sortof, I = don't disagree :)


The = main reason is that it's easier to restrict the delimiter from appearing = in the signature than in the payload. This way the delimiter (period) = can show up in the payload and a left split can still = work.

if each string is = base64url, then the period is always the = separator

I am still and advocate for a = separate string which is the payload. I consider this mechanism to be = more generic than OAuth request signatures. I think it can be used for = OAuth tokens as well.

= --Apple-Mail-5--772746886-- From lshepard@facebook.com Sat Jul 3 11:38: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 E36503A684A for ; Sat, 3 Jul 2010 11:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YbErFTidgtT for ; Sat, 3 Jul 2010 11:38:10 -0700 (PDT) Received: from mx-out.facebook.com (outcampmail001.snc4.facebook.com [66.220.144.159]) by core3.amsl.com (Postfix) with ESMTP id B5BAD3A6781 for ; Sat, 3 Jul 2010 11:38:09 -0700 (PDT) Received: from [10.18.74.191] ([10.18.74.191:44390] helo=mx-out.facebook.com) by mta007.snc4.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id 0B/2D-14209-B318F2C4; Sat, 03 Jul 2010 11:28:11 -0700 Received: from [10.18.255.121] ([10.18.255.121:3873] helo=mail.thefacebook.com) by mta025.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 81/FB-05162-B318F2C4; Sat, 03 Jul 2010 11:28:11 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.694.1; Sat, 3 Jul 2010 11:28:11 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Sat, 3 Jul 2010 11:28:11 -0700 From: Luke Shepard To: Dick Hardt Date: Sat, 3 Jul 2010 11:28:18 -0700 Thread-Topic: [OAUTH-WG] Understanding the reasoning for Base64 Thread-Index: Acsa3X3bGj3Q7BjWR3G0imnvzYpqCg== Message-ID: <20ACF96E-5753-4004-BE44-96BAD43FE7C9@facebook.com> References: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> <6B008ED4-4536-4A95-89B6-917696E6AF79@gmail.com> In-Reply-To: <6B008ED4-4536-4A95-89B6-917696E6AF79@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_20ACF96E57534004BE4496BAD43FE7C9facebookcom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 18:38:16 -0000 --_000_20ACF96E57534004BE4496BAD43FE7C9facebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > > * We'd like the signature first (so you can left split instead of right s= plit) What are the advantages of left split vs right split? Built in split function with a limit is more common, which makes the left s= plit easier. Size limit I am assuming? Since the size of the signature is known, this ma= kes it safer to have it first? Makes sense to me. Sounds like we agree on this point at least. The main reason is that it's easier to restrict the delimiter from appearin= g in the signature than in the payload. This way the delimiter (period) can= show up in the payload and a left split can still work. --_000_20ACF96E57534004BE4496BAD43FE7C9facebookcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>
> * We'd like the signature first (so you can left split instead of righ= t split)

What are the advantages of left split vs right split?

Built in split function with a limit is more common, w= hich makes the left split easier.

Size limit I am assuming? Since the size of the signature is known, this= makes it safer to have it first? Makes sense to me.

Sounds like we agree on this point at least.

The main reason is that it's easier to restrict the = delimiter from appearing in the signature than in the payload. This way the= delimiter (period) can show up in the payload and a left split can still w= ork.

= --_000_20ACF96E57534004BE4496BAD43FE7C9facebookcom_-- From andrewarnott@gmail.com Sat Jul 3 12:12: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 92D0C3A6813 for ; Sat, 3 Jul 2010 12:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs+mJ0kQubIl for ; Sat, 3 Jul 2010 12:12:22 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 89B963A685A for ; Sat, 3 Jul 2010 12:12:21 -0700 (PDT) Received: by gxk3 with SMTP id 3so319419gxk.31 for ; Sat, 03 Jul 2010 12:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=BeqpT8wg8LCgvREyjGijTpa2+pzB/J48Lt68ogdqll8=; b=RRyRSw5T+15DncWbrY2HQ8qu78hufsFCzKI41N5wqaDHMGzhUNissDNnb6MJJJzzc3 Xaiab52uQoIzteMZiHT19v1oLzghxADBso701e0vNGEmtMmS3OHCH3OFOxpjz4x3kGbT E/PozdzGpkazr+otgLMrwOxpMs81Fm1WIljig= 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=baxLQ//WtlAVFrgFAY7Kyv8XqOk4jtoD9/oMZeTePt6+0VrRQChy9FSI/JQ1z2WFrH NX/L7xP+Kktzdwv1ICj6eI9vqIMIZrtD2g2rKywHFO6cDdQEvI7Tb636eO+rTRvjxqtK 2LpZfbfXxZcDKG+9uwkNkpX0mtbyQ7nW2qNyo= MIME-Version: 1.0 Received: by 10.101.175.10 with SMTP id c10mr804648anp.192.1278184349567; Sat, 03 Jul 2010 12:12:29 -0700 (PDT) Received: by 10.150.92.8 with HTTP; Sat, 3 Jul 2010 12:12:29 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 3 Jul 2010 12:12:29 -0700 Message-ID: From: Andrew Arnott To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001636c5bbf11d0cf5048a807cca Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 19:12:23 -0000 --001636c5bbf11d0cf5048a807cca Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav wrote: > You are putting too much weight on the value of redirection URI > registration. Since the same problem exists between the user-agent script > and the server-side component used in the user-agent profile, anyone can > imitate that flow. In most cases, the redirection URI will simply include a > script that will pass the parameter to the **parent** window which can be > anything. If the server-based page is an active page, it still needs to > communicate with the user-agent, which again, can pretend to be that. > Good point. I wasn't imagining that far through it. Not to deny that most redirection URLs may just return a straight script that passes it to the parent window, but that seems pretty irresponsible to the host that's doing it -- because of the enormous security hole it opens up. Some client is trusted enough to authorize (by the user and auth server), receives an access token it wasn't expecting, and then blindly forwards it onto whoever wants it. Yikes. I sure hope these access tokens have *very* limited scope (like, I'd prefer none myself). I was about to describe how an active server could alleviate that by signing the original request using the state parameter, but I realized I'm solving a problem that the web server flow (or nowadays that the authorization code mode as I guess it's called) already solves. So I guess I just need to bite the bullet and accept that the user agent flow is *totally *insecure for web clients, and thus very special care must be taken to enable native clients without opening up the web client hole. Sorry to sound so negative about it. Enabling this scenario seems really important to me as well -- I just am against doing it when it can't be secured in some way. Seriously... as is, once you authorize any client, you've authorized them all, including clients not even running on your computer. I guess this answers how I was visiting a site a few days ago and was amazed that it knew who I was (via Facebook) and was displaying my name and photo when I never logged into the site. I was shocked it knew who I was. Enter living in Incognito mode from now on. --001636c5bbf11d0cf5048a807cca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer= -Lahav <eran@hu= eniverse.com> wrote:

You are putting too much= weight on the value of redirection URI registration. Since the same proble= m exists between the user-agent script and the server-side component used i= n the user-agent profile, anyone can imitate that flow. In most cases, the = redirection URI will simply include a script that will pass the parameter t= o the *parent* window which can be anything. If the server-based pag= e is an active page, it still needs to communicate with the user-agent, whi= ch again, can pretend to be that.

Good point. =A0I wasn't imagining that fa= r through it. =A0Not to deny that most redirection URLs may just return a s= traight script that passes it to the parent window, but that seems pretty i= rresponsible to the host that's doing it -- because of the enormous sec= urity hole it opens up. =A0Some client is trusted enough to authorize (by t= he user and auth server), receives an access token it wasn't expecting,= and then blindly forwards it onto whoever wants it. =A0Yikes. =A0I sure ho= pe these access tokens have very=A0limited scope (like, I'd pref= er none myself).

I was about to describe how an active server could alle= viate that by signing the original request using the state parameter, but I= realized I'm solving a problem that the web server flow (or nowadays t= hat the authorization code mode as I guess it's called) already solves.= =A0So I guess I just need to bite the bullet and accept that the user agen= t flow is totally insecure for web clients, and thus very special ca= re must be taken to enable native clients without opening up the web client= hole. =A0

Sorry to sound so negative about it. =A0Enabling this s= cenario seems really important to me as well -- I just am against doing it = when it can't be secured in some way. =A0Seriously... as is, once you a= uthorize any client, you've authorized them all, including clients not = even running on your computer. =A0I guess this answers how I was visiting a= site a few days ago and was amazed that it knew who I was (via Facebook) a= nd was displaying my name and photo when I never logged into the site. =A0I= was shocked it knew who I was. =A0Enter living in Incognito mode from now = on.
--001636c5bbf11d0cf5048a807cca-- From naitiks@gmail.com Sat Jul 3 12: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 90DBD3A684A for ; Sat, 3 Jul 2010 12:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.861 X-Spam-Level: X-Spam-Status: No, score=-0.861 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_20=-0.74, 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 UaorgnoqkB33 for ; Sat, 3 Jul 2010 12:14:46 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 36A2B3A6834 for ; Sat, 3 Jul 2010 12:14:46 -0700 (PDT) Received: by iwn10 with SMTP id 10so2062155iwn.31 for ; Sat, 03 Jul 2010 12:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=+P+9UjxpD5Zw7CKIko5jQp/1+8rbF1SLabXFkkfZpF0=; b=mTNJOVc9qrlpZebheYmGF7WnHZRY5vi8uGjo3twtJTMLoaPf8LbAgIkc4MtMKVPhCh LEsdmk4feerTdvU98+KHojjTdeTWGBkZwh/ThLc2zxvBWp2mSvri8FBcI7uExI7NCxr6 u2SgRK3Lwq+QH0jnZbFgxqxvl4lZKxeQFABEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=vRi8qhJiKPf0QvHsTYM5NCMya075PCNGJ5wNr6iMHuYOif4+L75FZkpobEMgpOsTrT aP8skZ1pZmekRexijXQrYh1jFIQeK3D0o7Dl1mQZbPYqJklHYSezIm/OwlMmCoNApv8D aewy6fRCGuirDHJsU3zXJFo9N1T47ObEjW+Dg= Received: by 10.231.37.7 with SMTP id v7mr818726ibd.147.1278184498423; Sat, 03 Jul 2010 12:14:58 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.231.170.9 with HTTP; Sat, 3 Jul 2010 12:14:38 -0700 (PDT) In-Reply-To: <6B008ED4-4536-4A95-89B6-917696E6AF79@gmail.com> References: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> <6B008ED4-4536-4A95-89B6-917696E6AF79@gmail.com> From: Naitik Shah Date: Sat, 3 Jul 2010 12:14:38 -0700 X-Google-Sender-Auth: vb0t0-po7KEx7E0XO1sg2gPAT-A Message-ID: To: Dick Hardt Content-Type: multipart/alternative; boundary=0003255759fefc6751048a808492 Cc: OAuth WG Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 19:14:48 -0000 --0003255759fefc6751048a808492 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt wrote: > > On 2010-07-03, at 9:13 AM, Naitik Shah wrote: > > > I think Naitik is saying that accidentally doing base64 and not base64url >> will send some '+'s along. >> >> if there are '+'s in the token, then it is easy for someone helping to >> spot the problem. also easy for servers to send back an error message >> saying, "hey, looks like you are using base64 instead of base64url encoding" >> >> ie, it is easy to detect the error -- urlencoding / decoding is hard to >> detect as an error >> > > The pluses are not guaranteed. They may or may not be there depending on > the data stream you're encoding. If you don't urlencode the JSON, you'll get > a "{", if you do it once, you'll get a "%7B", if you do it twice, you'll get > a "%257B" -- seems easier to detect. > > > Your earlier point was that developers may incorrectly use base64 instead > of base64url. If they used base64, and if there is a + / = or % in the > string, the server can send a useful note saying what is wrong. There may > not be one of those characters depending on the input string, but if there > is, then the server can suggest what the error might be using base64 instead > of base64url. If the token contains ANY character that is not in base64url, > then the server can say that it is not base64url encoded. > > That seems pretty fool proof to detect. Note that you should never get any > %7B or other encoding in the token as it is url safe. > The thing I was trying to say was that it's less predictable. That it might work just fine when you're experimenting with the API because at that point your token did not contain any pluses, but then suddenly started failing after you sent a link to your app to someone because their encoded token contains a plus. This hit-or-miss to me is worse than being able to tell by looking at the first few characters of the urlencoded JSON blob which will give a definitive answer as to how many times the token has been urlencoded. > >> When I wrote a sample in Perl, it was pretty easy to make it base64url >> which then provides a consistent encoding. >> > > Did it involve a string replace call? Or a third party library? > > > I used a standard CPAN library. > > Exactly :) I'm imagining our documentation where we want to be library agnostic, and have almost psuedo code like code snippets. I said this earlier -- while base64 may be common in standard libraries built into languages, the base64url version isn't. In order to not have a "cpan install base64url" (and gem install, easy_install, mvn install..) -- we'ed most likely document a str_replace() call in addition to a base64 call. And I'm worried that developers will miss this detail. > > > > >> > >> >> I am unclear on what your point is. >> >> >> >> The token would be included as one of the headers. This is often >> preferable as it separates the authorization layer (in header) from >> application layer parameters (query string or message body) >> > >> > With our proposal, we were focussed on url parameters (hence the choice >> of urlencode after it was all put together). I think it makes total sense to >> not do the encoding as part of the sig spec, and let the transport choice >> dictate which encoding to use. >> >> I understand what you are saying. having multiple encodings makes >> libraries harder, and leads to the issues that motivated base64url over >> url-encoding > > > Glad we agree on that. > I agree multiple encodings makes libraries harder :) But I think the stark difference between OAuth1 vs 2 wrt to signing actually makes the Authorization header less valuable (again, for signing only). I'm pretty happy with this because I thought this header was more complex for developers anyways (while big corporations with authentication infrastructure love it) :) But the reason I think so is that now the header is not just the signature, but also the signed payload. This means an application isn't just making a http request as before with a bunch of query or post parameters. It's instead making a "JSON request" that may or may not have query/post params. It's just not as separate as before. > > > >> > * We'd like the signature first (so you can left split instead of right >> split) >> >> What are the advantages of left split vs right split? >> > > Built in split function with a limit is more common, which makes the left > split easier. > > > Size limit I am assuming? Since the size of the signature is known, this > makes it safer to have it first? Makes sense to me. > > Yep, this and all the reasons you and Luke mentioned in the parallel thread. -Naitik --0003255759fefc6751048a808492 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

On 2010= -07-03, at 9:13 AM, Naitik Shah wrote:
> I think Naitik is saying that accidentally doing base64 and not b= ase64url will send some '+'s along.

if there are '+'s in the token, then it is easy for someone h= elping to spot the problem. also easy for servers to send back an error mes= sage saying, "hey, looks like you are using base64 instead of base64ur= l encoding"

ie, it is easy to detect the error -- urlencoding / decoding is hard to det= ect as an error

The pluses are not=C2= =A0guaranteed. They may or may not be there depending on the data stream yo= u're encoding. If you don't urlencode the JSON, you'll get a &q= uot;{", if you do it once, you'll get a "%7B", if you do= it twice, you'll get a "%257B" -- seems easier to detect.

Your earlier point was that de= velopers may incorrectly use base64 instead of base64url. If they used base= 64, and if there is a + / =3D or % in the string, the server can send a use= ful note saying what is wrong. There may not be one of those characters dep= ending on the input string, but if there is, then the server can suggest wh= at the error might be using base64 instead of base64url. If the token conta= ins ANY character that is not in base64url, then the server can say that it= is not base64url encoded.

That seems pretty fool proof to detect. Note that you s= hould never get any %7B or other encoding in the token as it is url safe.

The thing I was trying to = say was that it's less predictable. That it might work just fine when y= ou're experimenting with the API because at that point your token did n= ot contain any pluses, but then suddenly started failing after you sent a l= ink to your app to someone because their encoded token contains a plus. Thi= s hit-or-miss to me is worse than being able to tell by looking at the firs= t few characters of the urlencoded JSON blob which will give a definitive a= nswer as to how many times the token has been urlencoded.

=C2=A0
=

When I wrote a sample in Perl, it was pretty easy to make it base64ur= l which then provides a consistent encoding.

Did it involve a string replace call? Or a third party library?

I used a standard CPAN library= .


=
Exactly :) I'm imagining our documentation where we want to be lib= rary agnostic, and have almost psuedo code like code snippets. I said this = earlier -- while base64 may be common in standard libraries built into lang= uages, the base64url version isn't. In order to not have a "cpan i= nstall base64url" (and gem install, easy_install, mvn install..) -- we= 'ed most likely document a str_replace() call in addition to a base64 c= all. And I'm worried that developers will miss this detail.

=C2=A0
=
=C2=A0



>
>> I am unclear on what your point is.
>>
>> The token would be included as one of the headers. This is often p= referable as it separates the authorization layer (in header) from applicat= ion layer parameters (query string or message body)
>
> With our proposal, we were focussed on url parameters (hence the choic= e of urlencode after it was all put together). I think it makes total sense= to not do the encoding as part of the sig spec, and let the transport choi= ce dictate which encoding to use.

I understand what you are saying. having multiple encodings makes lib= raries harder, and leads to the issues that motivated base64url over url-en= coding=C2=A0

Glad we ag= ree on that.

I agree multiple encodings makes lib= raries harder :)

But I think the stark difference = between OAuth1 vs 2 wrt to signing actually makes the Authorization header = less valuable (again, for signing only). I'm pretty happy with this bec= ause I thought this header was more complex for developers anyways (while b= ig corporations with authentication infrastructure love it) :) But the reas= on I think so is that now the header is not just the signature, but also th= e signed payload. This means an application isn't just making a http re= quest as before with a bunch of query or post parameters. It's instead = making a "JSON request" that may or may not have query/post param= s. It's just not as separate as before.


=C2=A0

>
> * We'd like the signature first (so you can left split instead of = right split)

What are the advantages of left split vs right split?

Built in split function with a limit is more common, w= hich makes the left split easier.

Size limit I am assuming? Since the size of the signature is kno= wn, this makes it safer to have it first? Makes sense to me.

=

Yep, this and all the reasons= you and Luke mentioned in the parallel thread.



-Naitik
--0003255759fefc6751048a808492-- From andrewarnott@gmail.com Sat Jul 3 12:15: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 BFD613A684A for ; Sat, 3 Jul 2010 12:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.770, 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 1MihQ3b+-aZl for ; Sat, 3 Jul 2010 12:15:24 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id C9CB33A6834 for ; Sat, 3 Jul 2010 12:15:23 -0700 (PDT) Received: by gxk3 with SMTP id 3so319965gxk.31 for ; Sat, 03 Jul 2010 12:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Nc2/2iYj0wGRlhOFtTuKVKnNeH6ikFaWAk78ICISdH8=; b=dVNJtr15/3xBZkakkm0w7NFXepXKFxPk4J1LJ0bm61K/Pz17Uy4JGWCJ4sLTkIs8z1 G7ZWLWYAMWMxLgNO6zv78I4lryY9LA0zmXoTWDSz8ivi/dptRz9L5C7keq41lm8XqCJL 12ZCL76RKWGJOmwK4IIR/PkEmyBoDZ/BVD4NQ= 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=IV0bdimXeG/+PlHy0EjvmPTXBIF1USDBiZIxGa1Iun94mK0ARntRsPs4LNvMSHiCQU v101wEGsaqOZQ652l9pbHm3xMcfu343lDfRfuRau4DNUgJSWmGAxI3a+mF0eC0dpmRbA iMb7YerSxNQ1DaSlRl2fX5T3QcdvW1nONBw5U= MIME-Version: 1.0 Received: by 10.100.136.19 with SMTP id j19mr770470and.44.1278184533736; Sat, 03 Jul 2010 12:15:33 -0700 (PDT) Received: by 10.150.92.8 with HTTP; Sat, 3 Jul 2010 12:15:33 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 3 Jul 2010 12:15:33 -0700 Message-ID: From: Andrew Arnott To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e6509bc4174085048a808725 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 19:15:28 -0000 --0016e6509bc4174085048a808725 Content-Type: text/plain; charset=ISO-8859-1 (this sounds sarcastic, but I'm no being sarcastic... it's a serious question/challenge)... Why not just remove the client_id parameter from the user-agent flow? It's absolutely meaningless to security. It's only perceivable benefit is that the auth server can possible display to the user the client being authorized or the list of previously authorized clients. But again, that's totally meaningless if not verified. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott wrote: > On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav wrote: > >> You are putting too much weight on the value of redirection URI >> registration. Since the same problem exists between the user-agent script >> and the server-side component used in the user-agent profile, anyone can >> imitate that flow. In most cases, the redirection URI will simply include a >> script that will pass the parameter to the **parent** window which can be >> anything. If the server-based page is an active page, it still needs to >> communicate with the user-agent, which again, can pretend to be that. >> > Good point. I wasn't imagining that far through it. Not to deny that most > redirection URLs may just return a straight script that passes it to the > parent window, but that seems pretty irresponsible to the host that's doing > it -- because of the enormous security hole it opens up. Some client is > trusted enough to authorize (by the user and auth server), receives an > access token it wasn't expecting, and then blindly forwards it onto whoever > wants it. Yikes. I sure hope these access tokens have *very* limited > scope (like, I'd prefer none myself). > > I was about to describe how an active server could alleviate that by > signing the original request using the state parameter, but I realized I'm > solving a problem that the web server flow (or nowadays that the > authorization code mode as I guess it's called) already solves. So I guess > I just need to bite the bullet and accept that the user agent flow is *totally > *insecure for web clients, and thus very special care must be taken to > enable native clients without opening up the web client hole. > > Sorry to sound so negative about it. Enabling this scenario seems really > important to me as well -- I just am against doing it when it can't be > secured in some way. Seriously... as is, once you authorize any client, > you've authorized them all, including clients not even running on your > computer. I guess this answers how I was visiting a site a few days ago and > was amazed that it knew who I was (via Facebook) and was displaying my name > and photo when I never logged into the site. I was shocked it knew who I > was. Enter living in Incognito mode from now on. > --0016e6509bc4174085048a808725 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (this sounds sarcastic, but I'm no being sarcastic... it's a seriou= s question/challenge)...

Why not just remove the client_= id parameter from the user-agent flow? =A0It's absolutely meaningless t= o security. =A0It's only perceivable benefit is that the auth server ca= n possible display to the user the client being authorized or the list of p= reviously authorized clients. =A0But again, that's totally meaningless = if not verified.

--
Andrew Arnott
"I [may] not agree with = what you have to say, but I'll defend to the death your right to say it= ." - S. G. Tallentyre


On Sat, Jul 3, 2010 at 12:12 PM, Andrew = Arnott <andr= ewarnott@gmail.com> wrote:
On Fri, Jul 2, 2010 at 9:= 12 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

You are putting too much= weight on the value of redirection URI registration. Since the same proble= m exists between the user-agent script and the server-side component used i= n the user-agent profile, anyone can imitate that flow. In most cases, the = redirection URI will simply include a script that will pass the parameter t= o the *parent* window which can be anything. If the server-based pag= e is an active page, it still needs to communicate with the user-agent, whi= ch again, can pretend to be that.

Good point. =A0I wasn't imagining t= hat far through it. =A0Not to deny that most redirection URLs may just retu= rn a straight script that passes it to the parent window, but that seems pr= etty irresponsible to the host that's doing it -- because of the enormo= us security hole it opens up. =A0Some client is trusted enough to authorize= (by the user and auth server), receives an access token it wasn't expe= cting, and then blindly forwards it onto whoever wants it. =A0Yikes. =A0I s= ure hope these access tokens have very=A0limited scope (like, I'= d prefer none myself).

I was about to describe how an active server could alle= viate that by signing the original request using the state parameter, but I= realized I'm solving a problem that the web server flow (or nowadays t= hat the authorization code mode as I guess it's called) already solves.= =A0So I guess I just need to bite the bullet and accept that the user agen= t flow is totally insecure for web clients, and thus very special ca= re must be taken to enable native clients without opening up the web client= hole. =A0

Sorry to sound so negative about it. =A0Enabling this s= cenario seems really important to me as well -- I just am against doing it = when it can't be secured in some way. =A0Seriously... as is, once you a= uthorize any client, you've authorized them all, including clients not = even running on your computer. =A0I guess this answers how I was visiting a= site a few days ago and was amazed that it knew who I was (via Facebook) a= nd was displaying my name and photo when I never logged into the site. =A0I= was shocked it knew who I was. =A0Enter living in Incognito mode from now = on.

--0016e6509bc4174085048a808725-- From dick.hardt@gmail.com Sat Jul 3 12:45: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 2D2FA3A68F5 for ; Sat, 3 Jul 2010 12:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJ9MGLPVoDMm for ; Sat, 3 Jul 2010 12:45:24 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 986513A6911 for ; Sat, 3 Jul 2010 12:45:24 -0700 (PDT) Received: by pwj1 with SMTP id 1so44826pwj.31 for ; Sat, 03 Jul 2010 12:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=OXbP3y8f3jMwKFNdYIZsG7VnbY/wotciOCRRatfMAgM=; b=SXxrVvjrSEPrOM3AHwEKq3ppue3pxDeDZXuEWrTUDeNDLdmGyBhXymQtODRW7r6O1E VC2j3qUVgP+0CI164Pm5LctJIgfIABxaGxBhm2pHgFLk99np3R/yivdd56Cnw3Gtcu4k dH+eeZ4Hg77pECLEpX9DFzV5hBBVTJPYdOjh4= 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=IA+qhlR0PxirGsg2y7hYTR+5BPZ8RfxWMUAojKQHnZJtz0ifYL+ewVFwdWn2WEoaNS k+zLWNC5ORXMZOegTB7oNyHGrcb0W4VjA+m2yt+y6332wBN0gbpW8cSi9GStA9ZpZyzi wr0EsIenlaoo20KouNmm+ayJnIvwHbL5deHHU= Received: by 10.114.112.17 with SMTP id k17mr742017wac.188.1278186334256; Sat, 03 Jul 2010 12:45:34 -0700 (PDT) Received: from [192.168.1.5] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id 33sm33176789wad.6.2010.07.03.12.45.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 12:45:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-7--768581437 From: Dick Hardt In-Reply-To: Date: Sat, 3 Jul 2010 12:45:29 -0700 Message-Id: <095B9543-1F20-4DA5-A8EB-48F86CDED9A6@gmail.com> References: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> <6B008ED4-4536-4A95-89B6-917696E6AF79@gmail.com> To: Naitik Shah X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 19:45:26 -0000 --Apple-Mail-7--768581437 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-07-03, at 12:14 PM, Naitik Shah wrote: > On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt = wrote: >=20 > On 2010-07-03, at 9:13 AM, Naitik Shah wrote: >> > I think Naitik is saying that accidentally doing base64 and not = base64url will send some '+'s along. >>=20 >> if there are '+'s in the token, then it is easy for someone helping = to spot the problem. also easy for servers to send back an error message = saying, "hey, looks like you are using base64 instead of base64url = encoding" >>=20 >> ie, it is easy to detect the error -- urlencoding / decoding is hard = to detect as an error >>=20 >> The pluses are not guaranteed. They may or may not be there depending = on the data stream you're encoding. If you don't urlencode the JSON, = you'll get a "{", if you do it once, you'll get a "%7B", if you do it = twice, you'll get a "%257B" -- seems easier to detect. >=20 > Your earlier point was that developers may incorrectly use base64 = instead of base64url. If they used base64, and if there is a + / =3D or = % in the string, the server can send a useful note saying what is wrong. = There may not be one of those characters depending on the input string, = but if there is, then the server can suggest what the error might be = using base64 instead of base64url. If the token contains ANY character = that is not in base64url, then the server can say that it is not = base64url encoded. >=20 > That seems pretty fool proof to detect. Note that you should never get = any %7B or other encoding in the token as it is url safe. >=20 > The thing I was trying to say was that it's less predictable. That it = might work just fine when you're experimenting with the API because at = that point your token did not contain any pluses, but then suddenly = started failing after you sent a link to your app to someone because = their encoded token contains a plus. This hit-or-miss to me is worse = than being able to tell by looking at the first few characters of the = urlencoded JSON blob which will give a definitive answer as to how many = times the token has been urlencoded. I understand your point. I still think base64url encoding makes it = really clear that it is encoded (nothing is legible anymore), allows = there to be one encoding format for all data, makes it easy to support = encryption. >=20 > =20 >>=20 >> When I wrote a sample in Perl, it was pretty easy to make it = base64url which then provides a consistent encoding. >>=20 >> Did it involve a string replace call? Or a third party library? >=20 > I used a standard CPAN library. >=20 >=20 > Exactly :) I'm imagining our documentation where we want to be library = agnostic, and have almost psuedo code like code snippets. I said this = earlier -- while base64 may be common in standard libraries built into = languages, the base64url version isn't. In order to not have a "cpan = install base64url" (and gem install, easy_install, mvn install..) -- = we'ed most likely document a str_replace() call in addition to a base64 = call. And I'm worried that developers will miss this detail. Likely they will install an OAuth library that will deal with it if they = are going to have to sign rather than using a bearer token (I believe = most people will use a bearer token if they can -- soooo much easier!) Besides base64url, there is HMAC256 and JSON -- not all of which are = built in -- but are becoming more built in as time goes on, and if OAuth = signing uses base64url, I would expect these will all be part of = standard distributions in the future ...=20 (... in case you are unfamiliar with my backgroud, I have delivered = Perl, Python and Tcl distributions in the past -- what goes into a = packages is what is heavily used or what we thought was a good thing to = promote -- and assuming that making base64url more available is a good = thing, than using it in OAuth is a good thing to do. :) >=20 > =20 >> =20 >>=20 >>=20 >>=20 >> > >> >> I am unclear on what your point is. >> >> >> >> The token would be included as one of the headers. This is often = preferable as it separates the authorization layer (in header) from = application layer parameters (query string or message body) >> > >> > With our proposal, we were focussed on url parameters (hence the = choice of urlencode after it was all put together). I think it makes = total sense to not do the encoding as part of the sig spec, and let the = transport choice dictate which encoding to use. >>=20 >> I understand what you are saying. having multiple encodings makes = libraries harder, and leads to the issues that motivated base64url over = url-encoding=20 >=20 > Glad we agree on that. >=20 > I agree multiple encodings makes libraries harder :) glad we agree there >=20 > But I think the stark difference between OAuth1 vs 2 wrt to signing = actually makes the Authorization header less valuable (again, for = signing only). I'm pretty happy with this because I thought this header = was more complex for developers anyways (while big corporations with = authentication infrastructure love it) :) But the reason I think so is = that now the header is not just the signature, but also the signed = payload. This means an application isn't just making a http request as = before with a bunch of query or post parameters. It's instead making a = "JSON request" that may or may not have query/post params. It's just not = as separate as before. I am confused on what point you are trying to make here.=20 --Apple-Mail-7--768581437 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Sat, = Jul 3, 2010 at 9:42 AM, Dick Hardt <dick.hardt@gmail.com> = wrote:

On = 2010-07-03, at 9:13 AM, Naitik Shah wrote:
> I think Naitik is saying that accidentally doing base64 and = not base64url will send some '+'s along.

if there are '+'s in the token, then it is easy for someone = helping to spot the problem. also easy for servers to send back an error = message saying, "hey, looks like you are using base64 instead of = base64url encoding"

ie, it is easy to detect the error -- urlencoding / decoding is hard to = detect as an error

The pluses are = not guaranteed. They may or may not be there depending on the data = stream you're encoding. If you don't urlencode the JSON, you'll get a = "{", if you do it once, you'll get a "%7B", if you do it twice, you'll = get a "%257B" -- seems easier to detect.

Your earlier point was that = developers may incorrectly use base64 instead of base64url. If they used = base64, and if there is a + / =3D or % in the string, the server can = send a useful note saying what is wrong. There may not be one of those = characters depending on the input string, but if there is, then the = server can suggest what the error might be using base64 instead of = base64url. If the token contains ANY character that is not in base64url, = then the server can say that it is not base64url encoded.

That seems pretty fool proof to detect. Note that = you should never get any %7B or other encoding in the token as it is url = safe.

The thing I was = trying to say was that it's less predictable. That it might work just = fine when you're experimenting with the API because at that point your = token did not contain any pluses, but then suddenly started failing = after you sent a link to your app to someone because their encoded token = contains a plus. This hit-or-miss to me is worse than being able to tell = by looking at the first few characters of the urlencoded JSON blob which = will give a definitive answer as to how many times the token has been = urlencoded.

I understand = your point. I still think base64url encoding makes it really clear that = it is encoded (nothing is legible anymore), allows there to be one = encoding format for all data, makes it easy to support = encryption.



 
When I wrote a sample in Perl, it was pretty easy to make it = base64url which then provides a consistent = encoding.

Did it involve a string = replace call? Or a third party library?

I used a standard CPAN = library.


Exactl= y :) I'm imagining our documentation where we want to be library = agnostic, and have almost psuedo code like code snippets. I said this = earlier -- while base64 may be common in standard libraries built into = languages, the base64url version isn't. In order to not have a "cpan = install base64url" (and gem install, easy_install, mvn install..) -- = we'ed most likely document a str_replace() call in addition to a base64 = call. And I'm worried that developers will miss this = detail.

Likely they will = install an OAuth library that will deal with it if they are going to = have to sign rather than using a bearer token (I believe most people = will use a bearer token if they can -- soooo much = easier!)

Besides base64url, there is HMAC256 = and JSON -- not all of which are built in -- but are becoming more built = in as time goes on, and if OAuth signing uses base64url, I would expect = these will all be part of standard distributions in the future = ... 

(... in case you are unfamiliar with = my backgroud, I have delivered Perl, Python and Tcl distributions in the = past -- what goes into a packages is what is heavily used or what we = thought was a good thing to promote -- and assuming that  making = base64url more available is a good thing, than using it in OAuth is a = good thing to do. :)


 
 



>
>> I am unclear on what your point is.
>>
>> The token would be included as one of the headers. This is = often preferable as it separates the authorization layer (in header) = from application layer parameters (query string or message body)
>
> With our proposal, we were focussed on url parameters (hence the = choice of urlencode after it was all put together). I think it makes = total sense to not do the encoding as part of the sig spec, and let the = transport choice dictate which encoding to use.

I understand what you are saying. having multiple encodings makes = libraries harder, and leads to the issues that motivated base64url over = url-encoding 

Gla= d we agree on that.

I agree multiple encodings makes = libraries harder :)

glad we = agree there



But I think = the stark difference between OAuth1 vs 2 wrt to signing actually makes = the Authorization header less valuable (again, for signing only). I'm = pretty happy with this because I thought this header was more complex = for developers anyways (while big corporations with authentication = infrastructure love it) :) But the reason I think so is that now the = header is not just the signature, but also the signed payload. This = means an application isn't just making a http request as before with a = bunch of query or post parameters. It's instead making a "JSON request" = that may or may not have query/post params. It's just not as separate as = before.

I am confused on = what point you are trying to make = here. 

= --Apple-Mail-7--768581437-- From andrewarnott@gmail.com Sat Jul 3 14:28: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 B84A33A67ED for ; Sat, 3 Jul 2010 14:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZkFMD3nYVU9 for ; Sat, 3 Jul 2010 14:28:37 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id B58733A67B1 for ; Sat, 3 Jul 2010 14:28:37 -0700 (PDT) Received: by gyh3 with SMTP id 3so2302753gyh.31 for ; Sat, 03 Jul 2010 14:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=c9sYcems+pQAmowgOnvCf9l8QZlKT/f70Qd4GioJU4w=; b=lyLVllFuyqlvi6G1xGGpJnX0HuJn9s0y0yOYQYvM+3gh8dK28VnbjOOFxVesPa4MjC DJrYHmBkvSAXrQHrWeDmDQC3vaLY7QAJanm6ICboBW9LxfQUPdNSfiIJZPbNjxYgIxY4 8ixxW3F0Q6S8MnS5PV/BToT2ogRqbuOwN6CQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dEU1zuv6Ixj2dh7UuOVcBpN3HWTx0W0+gDbFgbGFD9s29GA1ntPwRG85dFgYNlyxcb K67mzci5Ec2vHku1mkYJesp2zewYnfOaft0LLfu/i3tJorCzDa7OdnKcyysXDt31G6JE BST998MW2Q6C3f+LOTTP0XcaSoz9RxZrPBf8M= MIME-Version: 1.0 Received: by 10.100.112.12 with SMTP id k12mr122098anc.234.1278192514103; Sat, 03 Jul 2010 14:28:34 -0700 (PDT) Received: by 10.150.92.8 with HTTP; Sat, 3 Jul 2010 14:28:34 -0700 (PDT) Date: Sat, 3 Jul 2010 14:28:34 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=001485f91236c1f7e8048a8262cb Subject: [OAUTH-WG] Draft 9, Section 4.1.1 missing several 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, 03 Jul 2010 21:28:43 -0000 --001485f91236c1f7e8048a8262cb Content-Type: text/plain; charset=ISO-8859-1 Section 4.1.1, which deals with requesting an access token using an authorization code, doesn't list the client_id and client_secret parameters at all, yet mentions verifying them in paragraph form, and they are included in the example. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --001485f91236c1f7e8048a8262cb Content-Type: text/html; charset=ISO-8859-1
Section 4.1.1, which deals with requesting an access token using an authorization code, doesn't list the client_id and client_secret parameters at all, yet mentions verifying them in paragraph form, and they are included in the example.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
--001485f91236c1f7e8048a8262cb-- From diogo.borges.almeida@gmail.com Sat Jul 3 15:58: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 007843A689D for ; Sat, 3 Jul 2010 15:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pE35eGfV-8s for ; Sat, 3 Jul 2010 15:58:02 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 7FD633A68AA for ; Sat, 3 Jul 2010 15:58:01 -0700 (PDT) Received: by wwb24 with SMTP id 24so932058wwb.13 for ; Sat, 03 Jul 2010 15:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type:subject :date:message-id:to:mime-version:x-mailer; bh=zFT6ABu14ujPvYnHXJj4KZ/3IUGZ4TlwDbPow12uezU=; b=K+RM9WK0LX/msPhBBoxfNAiBemRdzEULvpgyqCpHvfK4QE6s71bHrNihqn6g7eVBLC gmvQghNa6FTBqCFgx4ex2xhRfXzanMYGrtxm0SxgJvUWm8kfUrpPas53iBbaGlutIkVH i3V/t/vUZIPj+XZS5Ukk311I2ZLR43iuzt+r8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; b=NJ4CAtIEUQLwFrmKEkngxxNIGo/JnM9MYK7KSvq7llWFgcyXwDDAtGx+bB/yAa4ora De09a7Zql4KD3SuxwbyWaXnKlBLWUqHmtZ90PtbtUBSvHcshqwPnPfgBo+Rgo7gliUIf +F/9T/bG0Yx7EWF/JH4zznFwloYbbVDPHBJeI= Received: by 10.227.137.149 with SMTP id w21mr920119wbt.169.1278197876591; Sat, 03 Jul 2010 15:57:56 -0700 (PDT) Received: from [192.168.1.80] (a81-84-95-147.cpe.netcabo.pt [81.84.95.147]) by mx.google.com with ESMTPS id p29sm17609526wbc.19.2010.07.03.15.57.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 15:57:56 -0700 (PDT) From: Diogo Almeida Content-Type: multipart/alternative; boundary=Apple-Mail-1--757036328 Date: Sat, 3 Jul 2010 23:57:54 +0100 Message-Id: <4674453B-45C7-4B49-95E7-DC1BC0CAC719@gmail.com> To: oauth@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [OAUTH-WG] Possible "typos" in -09, section 2.1 examples X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 22:58:08 -0000 --Apple-Mail-1--757036328 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, Both examples in section 2.1 mention a "type" parameter, which, if I'm = interpreting the changes correctly, has been removed in -07. Assuming it's indeed a typo. Where it reads: For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded type=3Dweb-server&code=3Di1WsRn1uB1& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb it should read: For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded code=3Di1WsRn1uB1& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb And where it reads: For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded type=3Dweb-server&client_id=3Ds6BhdRkqt3& client_secret=3DgX1fBat3bV&code=3Di1WsRn1uB1& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb It should read: For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded client_id=3Ds6BhdRkqt3& client_secret=3DgX1fBat3bV&code=3Di1WsRn1uB1& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb Best regards, Diogo Almeida= --Apple-Mail-1--757036328 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hello,

Both examples in section 2.1 mention a "type" parameter, which, if I'm interpreting the changes correctly, has been removed in -07.

Assuming it's indeed a typo. Where it reads:

   For example (line breaks are for display purposes only):

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     type=web-server&code=i1WsRn1uB1&
     redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

it should read:

   For example (line breaks are for display purposes only):

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     code=i1WsRn1uB1&
     redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb


And where it reads:

For example (line breaks are for display purposes only):

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     type=web-server&client_id=s6BhdRkqt3&
     client_secret=gX1fBat3bV&code=i1WsRn1uB1&
     redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

It should read:

For example (line breaks are for display purposes only):

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     client_id=s6BhdRkqt3&
     client_secret=gX1fBat3bV&code=i1WsRn1uB1&
     redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb


Best regards,
Diogo Almeida
--Apple-Mail-1--757036328-- From andrewarnott@gmail.com Sat Jul 3 17:28:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A7E3A6946 for ; Sat, 3 Jul 2010 17:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhQGTAGomqUM for ; Sat, 3 Jul 2010 17:28:27 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 1FB3F3A6407 for ; Sat, 3 Jul 2010 17:28:27 -0700 (PDT) Received: by gxk3 with SMTP id 3so378220gxk.31 for ; Sat, 03 Jul 2010 17:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=zpKgUEr7l4z6t79ufWWZrfxtFbf1jpXuQu0U/10ZYU4=; b=YdjDLBkSg8xJgaAJvQZm5NLRqfcKo1/UvSECWiXSd/HfPP/PJC0wu4oUIC7Q6xJjLW 79MK7N8QmM8//R7VzE+qyBsuyEi/zzLneDD34z6I9XQzc6lCCVGH0DKQXNvoEx/WIW69 439n8cardXcaJujFkn2rjzASn4AaL/k1+VDss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Im2KvfCOz58SI4KK6w99lPgMWVun7Te3N8Ik+N90+c1D9WG96k0B0fdvlOBwtPx32w lFNC+wTE6H2j2z8TAMuwzn+XbuJVL2NJfTUYQdzQf9sT7j4hRNtuq+nal8Or/0Zd5psS E4eO4cmeRj0p5u7SWKC2f7Hh22vSzKskRYLyQ= MIME-Version: 1.0 Received: by 10.101.156.36 with SMTP id i36mr1091470ano.30.1278203304088; Sat, 03 Jul 2010 17:28:24 -0700 (PDT) Received: by 10.150.92.8 with HTTP; Sat, 3 Jul 2010 17:28:24 -0700 (PDT) Date: Sat, 3 Jul 2010 17:28:24 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=0016e68dea3de4131c048a84e597 Subject: [OAUTH-WG] draft 9, section 4.3.1 missing error code for invalid user 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: Sun, 04 Jul 2010 00:28:33 -0000 --0016e68dea3de4131c048a84e597 Content-Type: text/plain; charset=ISO-8859-1 I see an invalid-client-credentials error code, but for the basic-credentials grant type, it seems there should be a specific error code to indicate the resource owner's basic creds are invalid, as opposed to the client's credentials being invalid. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --0016e68dea3de4131c048a84e597 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see an invalid-client-credentials error code, but for the=A0basic-credentials=A0grant type= , it seems there should be a specific error code to indicate the resource o= wner's basic creds are invalid, as opposed to the client's credenti= als being invalid.

--
Andrew Arnott
"I [may] not agree with what = you have to say, but I'll defend to the death your right to say it.&quo= t; - S. G. Tallentyre
--0016e68dea3de4131c048a84e597-- From andrewarnott@gmail.com Sat Jul 3 17:42: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 CD1843A694E for ; Sat, 3 Jul 2010 17:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfDJgS69g-sS for ; Sat, 3 Jul 2010 17:42:31 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 9BCA13A681D for ; Sat, 3 Jul 2010 17:42:31 -0700 (PDT) Received: by gyh3 with SMTP id 3so2337192gyh.31 for ; Sat, 03 Jul 2010 17:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=eVNYQMXKn+0e/+gpUaRw4O9PpzFvTlK7cL7dFnny7Sg=; b=WXpx54BapLIiCpUBAKhSQzpx5v3o8lPZv+3dVF1w7VVXvOYieDkDs7jF3OH+Y1Qgmn FrYSj78ygyF6mxl2IOfUoAFLdEj6wlzykRAADzb4Mu8rh+K5HWo4zjsSY8WkWMYg1gF5 ZCesWDM/uRi82uIC1q+4+MpbALJ7pwE1bqL+I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NBnhe4z8XELQR55l0E/iMzMI1WVvdC/iF3uR1QIks8yf2Y5Ju+xw9RXkT6ETZF/HGq /5Dwym32xGhyJ6DXSZk4QGjRvXUJcSWzkXxsqnhxwiEW/uaMK0HoB9B2RoJ3IJkjA6YI zVmWKGbwuXFS8GEcsXH/5vCpxaSXprLR8a3eE= MIME-Version: 1.0 Received: by 10.90.96.20 with SMTP id t20mr1267967agb.37.1278204148565; Sat, 03 Jul 2010 17:42:28 -0700 (PDT) Received: by 10.150.92.8 with HTTP; Sat, 3 Jul 2010 17:42:28 -0700 (PDT) Date: Sat, 3 Jul 2010 17:42:28 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=0016363b92c039ca5b048a851803 Subject: [OAUTH-WG] Draft 9, Section 2 vs. Section 4.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 00:42:39 -0000 --0016363b92c039ca5b048a851803 Content-Type: text/plain; charset=ISO-8859-1 It may be my misreading the spec, or making assumptions based on my cluttered mind from reading the various drafts, so apologies if I'm just confused, but... Section 2 seems to be just sitting there. No discussion on how it fits into the spec from what I can see. It doesn't discuss how to obtain a grant, or access token, or anything. It also mentions type=web-server, which is an obsolete parameter. Section 4.1 has a grant_type=none option, which seems to cover the same scenario as Section 2 (did). I take it that section 4.1 is sort of the "2 legged OAuth" scenario. Am I correct in this? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --0016363b92c039ca5b048a851803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It may be my misreading the spec, or making assumptions based on my cl= uttered mind from reading the various drafts, so apologies if I'm just = confused, but...

Section 2 seems to be just sittin= g there. =A0No discussion on how it fits into the spec from what I can see.= =A0It doesn't discuss how to obtain a grant, or access token, or anyth= ing. =A0It also mentions type=3Dweb-server, which is an obsolete parameter.=

Section 4.1 has a grant_type=3Dnone option, which seems= to cover the same scenario as Section 2 (did). =A0I take it that section 4= .1 is sort of the "2 legged OAuth" scenario. =A0Am I correct in t= his?

--
Andrew Arnott
"I [may] not agree with what = you have to say, but I'll defend to the death your right to say it.&quo= t; - S. G. Tallentyre
--0016363b92c039ca5b048a851803-- From eran@hueniverse.com Sat Jul 3 21:42:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B601E3A683F for ; Sat, 3 Jul 2010 21:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.001 X-Spam-Level: ** X-Spam-Status: No, score=2.001 tagged_above=-999 required=5 tests=[BAYES_80=2, 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 KgcCaU8n1CdB for ; Sat, 3 Jul 2010 21:42:39 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 513423A659C for ; Sat, 3 Jul 2010 21:42:39 -0700 (PDT) Received: (qmail 29255 invoked from network); 4 Jul 2010 04:42:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Jul 2010 04:42:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 3 Jul 2010 21:42:39 -0700 From: Eran Hammer-Lahav To: Andrew Arnott Date: Sat, 3 Jul 2010 21:42:33 -0700 Thread-Topic: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) Thread-Index: Acsa47AeIfv18PgaRfqj+9BYqAv1swAT6EZX Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8555F4936AD2eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 04:42:41 -0000 --_000_C8555F4936AD2eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The user-agent security is based on the presence of the end-user. This is i= mportant. It is not like a client with the same ID can just go and ask for = an access token (if one was previously approved). The end-user must be pres= ent. How the end-user presence is verified is something each server has to = figure out. EHL On 7/3/10 12:12 PM, "Andrew Arnott" wrote: On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav wro= te: You are putting too much weight on the value of redirection URI registratio= n. Since the same problem exists between the user-agent script and the serv= er-side component used in the user-agent profile, anyone can imitate that f= low. In most cases, the redirection URI will simply include a script that w= ill pass the parameter to the *parent* window which can be anything. If the= server-based page is an active page, it still needs to communicate with th= e user-agent, which again, can pretend to be that. Good point. I wasn't imagining that far through it. Not to deny that most= redirection URLs may just return a straight script that passes it to the p= arent window, but that seems pretty irresponsible to the host that's doing = it -- because of the enormous security hole it opens up. Some client is tr= usted enough to authorize (by the user and auth server), receives an access= token it wasn't expecting, and then blindly forwards it onto whoever wants= it. Yikes. I sure hope these access tokens have very limited scope (like= , I'd prefer none myself). I was about to describe how an active server could alleviate that by signin= g the original request using the state parameter, but I realized I'm solvin= g a problem that the web server flow (or nowadays that the authorization co= de mode as I guess it's called) already solves. So I guess I just need to = bite the bullet and accept that the user agent flow is totally insecure for= web clients, and thus very special care must be taken to enable native cli= ents without opening up the web client hole. Sorry to sound so negative about it. Enabling this scenario seems really i= mportant to me as well -- I just am against doing it when it can't be secur= ed in some way. Seriously... as is, once you authorize any client, you've = authorized them all, including clients not even running on your computer. = I guess this answers how I was visiting a site a few days ago and was amaze= d that it knew who I was (via Facebook) and was displaying my name and phot= o when I never logged into the site. I was shocked it knew who I was. Ent= er living in Incognito mode from now on. --_000_C8555F4936AD2eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth &n= bsp;response code-and-token's scope parameter) The user-agent security is based on the presence of the end-user. Thi= s is important. It is not like a client with the same ID can just go and as= k for an access token (if one was previously approved). The end-user must b= e present. How the end-user presence is verified is something each server h= as to figure out.

EHL


On 7/3/10 12:12 PM, "Andrew Arnott" <andrewarnott@gmail.com> wrote:

On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer= -Lahav <eran@hueniverse.com> wrot= e:
You are putting too= much weight on the value of redirection URI registration. Since the same p= roblem exists between the user-agent script and the server-side component u= sed in the user-agent profile, anyone can imitate that flow. In most cases,= the redirection URI will simply include a script that will pass the parame= ter to the *parent* window which can be anything. If the server-base= d page is an active page, it still needs to communicate with the user-agent= , which again, can pretend to be that.
Good point. =A0I wasn't imagining t= hat far through it. =A0Not to deny that most redirection URLs may just retu= rn a straight script that passes it to the parent window, but that seems pr= etty irresponsible to the host that's doing it -- because of the enormous s= ecurity hole it opens up. =A0Some client is trusted enough to authorize (by= the user and auth server), receives an access token it wasn't expecting, a= nd then blindly forwards it onto whoever wants it. =A0Yikes. =A0I sure hope= these access tokens have very=A0limited scope (like, I'd prefer non= e myself).

I was about to describe how an active server could alleviate that by signin= g the original request using the state parameter, but I realized I'm solvin= g a problem that the web server flow (or nowadays that the authorization co= de mode as I guess it's called) already solves. =A0So I guess I just need t= o bite the bullet and accept that the user agent flow is totally ins= ecure for web clients, and thus very special care must be taken to enable n= ative clients without opening up the web client hole. =A0

Sorry to sound so negative about it. =A0Enabling this scenario seems really= important to me as well -- I just am against doing it when it can't be sec= ured in some way. =A0Seriously... as is, once you authorize any client, you= 've authorized them all, including clients not even running on your compute= r. =A0I guess this answers how I was visiting a site a few days ago and was= amazed that it knew who I was (via Facebook) and was displaying my name an= d photo when I never logged into the site. =A0I was shocked it knew who I w= as. =A0Enter living in Incognito mode from now on.

--_000_C8555F4936AD2eranhueniversecom_-- From eran@hueniverse.com Sat Jul 3 21:43: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 026F83A683F for ; Sat, 3 Jul 2010 21:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2P6eFLNsTdX for ; Sat, 3 Jul 2010 21:43:44 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id CB9373A659C for ; Sat, 3 Jul 2010 21:43:44 -0700 (PDT) Received: (qmail 29351 invoked from network); 4 Jul 2010 04:43:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Jul 2010 04:43:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 3 Jul 2010 21:43:45 -0700 From: Eran Hammer-Lahav To: Andrew Arnott Date: Sat, 3 Jul 2010 21:43:37 -0700 Thread-Topic: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) Thread-Index: Acsa5B0mMBrtSwd0RE+xrx5dN5mEfwAT1o1j Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8555F8936AD4eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 04:43:46 -0000 --_000_C8555F8936AD4eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It is used as a hint, but one the end-user can help verify. The security co= nsideration section needs to make this clear. EHL On 7/3/10 12:15 PM, "Andrew Arnott" wrote: (this sounds sarcastic, but I'm no being sarcastic... it's a serious questi= on/challenge)... Why not just remove the client_id parameter from the user-agent flow? It's= absolutely meaningless to security. It's only perceivable benefit is that= the auth server can possible display to the user the client being authoriz= ed or the list of previously authorized clients. But again, that's totally= meaningless if not verified. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott wro= te: On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav wro= te: You are putting too much weight on the value of redirection URI registratio= n. Since the same problem exists between the user-agent script and the serv= er-side component used in the user-agent profile, anyone can imitate that f= low. In most cases, the redirection URI will simply include a script that w= ill pass the parameter to the *parent* window which can be anything. If the= server-based page is an active page, it still needs to communicate with th= e user-agent, which again, can pretend to be that. Good point. I wasn't imagining that far through it. Not to deny that most= redirection URLs may just return a straight script that passes it to the p= arent window, but that seems pretty irresponsible to the host that's doing = it -- because of the enormous security hole it opens up. Some client is tr= usted enough to authorize (by the user and auth server), receives an access= token it wasn't expecting, and then blindly forwards it onto whoever wants= it. Yikes. I sure hope these access tokens have very limited scope (like= , I'd prefer none myself). I was about to describe how an active server could alleviate that by signin= g the original request using the state parameter, but I realized I'm solvin= g a problem that the web server flow (or nowadays that the authorization co= de mode as I guess it's called) already solves. So I guess I just need to = bite the bullet and accept that the user agent flow is totally insecure for= web clients, and thus very special care must be taken to enable native cli= ents without opening up the web client hole. Sorry to sound so negative about it. Enabling this scenario seems really i= mportant to me as well -- I just am against doing it when it can't be secur= ed in some way. Seriously... as is, once you authorize any client, you've = authorized them all, including clients not even running on your computer. = I guess this answers how I was visiting a site a few days ago and was amaze= d that it knew who I was (via Facebook) and was displaying my name and phot= o when I never logged into the site. I was shocked it knew who I was. Ent= er living in Incognito mode from now on. --_000_C8555F8936AD4eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth &n= bsp;response code-and-token's scope parameter) It is used as a hint, but one the end-user can help verify. The secur= ity consideration section needs to make this clear.

EHL


On 7/3/10 12:15 PM, "Andrew Arnott" <andrewarnott@gmail.com> wrote:

(this sounds sarcastic, but I'm no being sa= rcastic... it's a serious question/challenge)...

Why not just remove the client_id parameter from the user-agent flow? =A0It= 's absolutely meaningless to security. =A0It's only perceivable benefit is = that the auth server can possible display to the user the client being auth= orized or the list of previously authorized clients. =A0But again, that's t= otally meaningless if not verified.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the d= eath your right to say it." - S. G. Tallentyre


On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer= -Lahav <eran@hueniverse.com> wrot= e:
You are putting too= much weight on the value of redirection URI registration. Since the same p= roblem exists between the user-agent script and the server-side component u= sed in the user-agent profile, anyone can imitate that flow. In most cases,= the redirection URI will simply include a script that will pass the parame= ter to the *parent* window which can be anything. If the server-base= d page is an active page, it still needs to communicate with the user-agent= , which again, can pretend to be that.
Good point. =A0I wasn't imagining t= hat far through it. =A0Not to deny that most redirection URLs may just retu= rn a straight script that passes it to the parent window, but that seems pr= etty irresponsible to the host that's doing it -- because of the enormous s= ecurity hole it opens up. =A0Some client is trusted enough to authorize (by= the user and auth server), receives an access token it wasn't expecting, a= nd then blindly forwards it onto whoever wants it. =A0Yikes. =A0I sure hope= these access tokens have very=A0limited scope (like, I'd prefer non= e myself).

I was about to describe how an active server could alleviate that by signin= g the original request using the state parameter, but I realized I'm solvin= g a problem that the web server flow (or nowadays that the authorization co= de mode as I guess it's called) already solves. =A0So I guess I just need t= o bite the bullet and accept that the user agent flow is totally ins= ecure for web clients, and thus very special care must be taken to enable n= ative clients without opening up the web client hole. =A0

Sorry to sound so negative about it. =A0Enabling this scenario seems really= important to me as well -- I just am against doing it when it can't be sec= ured in some way. =A0Seriously... as is, once you authorize any client, you= 've authorized them all, including clients not even running on your compute= r. =A0I guess this answers how I was visiting a site a few days ago and was= amazed that it knew who I was (via Facebook) and was displaying my name an= d photo when I never logged into the site. =A0I was shocked it knew who I w= as. =A0Enter living in Incognito mode from now on.
In-Reply-To: <4674453B-45C7-4B49-95E7-DC1BC0CAC719@gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85560BD36AD7eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Possible "typos" in -09, section 2.1 examples X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 04:48:55 -0000 --_000_C85560BD36AD7eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks. This was previously reported and already fixed for -10. Should incl= ude the grant_type parameter. EHL On 7/3/10 3:57 PM, "Diogo Almeida" wrote: Hello, Both examples in section 2.1 mention a "type" parameter, which, if I'm inte= rpreting the changes correctly, has been removed in -07. Assuming it's indeed a typo. Where it reads: For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded type=3Dweb-server&code=3Di1WsRn1uB1& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb it should read: For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded code=3Di1WsRn1uB1& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb And where it reads: For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded type=3Dweb-server&client_id=3Ds6BhdRkqt3& client_secret=3DgX1fBat3bV&code=3Di1WsRn1uB1& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb It should read: For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded client_id=3Ds6BhdRkqt3& client_secret=3DgX1fBat3bV&code=3Di1WsRn1uB1& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb Best regards, Diogo Almeida --_000_C85560BD36AD7eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Possible "typos" in -09, section 2.1 exampl= es Thanks. This was previously reported and already fixed for –10.= Should include the grant_type parameter.

EHL


On 7/3/10 3:57 PM, "Diogo Almeida" <diogo.borges.almeida@gmail.com> wrote:

Hello,

Both examples in section 2.1 mention a "type" parameter, which, i= f I'm interpreting the changes correctly, has been removed in -07.

Assuming it's indeed a typo. Where it reads:

   For example (line breaks are for display purposes only= ):

     POST /token HTTP/1.1
     Host: server.example.com <http://server.example.com>
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0= M2JW
     Content-Type: application/x-www-form-urlencod= ed

     type=3Dweb-server&code=3Di1WsRn1uB1&<= BR>      redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample= %2Ecom%2Fcb

it should read:

   For example (line breaks are for display purposes only):<= BR>
     POST /token HTTP/1.1
     Host: server.example.com <http://server.example.com>
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0= M2JW
     Content-Type: application/x-www-form-urlencod= ed

     code=3Di1WsRn1uB1&
     redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample= %2Ecom%2Fcb


And where it reads:

For example (line breaks are for display purposes only):

     POST /token HTTP/1.1
     Host: server.example.com <http://server.example.com>
     Content-Type: application/x-www-form-urlencod= ed

     type=3Dweb-server&client_id=3Ds6BhdRkqt3&= amp;
     client_secret=3DgX1fBat3bV&code=3Di1WsRn1= uB1&
     redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample= %2Ecom%2Fcb

It should read:

For example (line breaks are for display purposes only):

     POST /token HTTP/1.1
     Host: server.example.com <http://server.example.com>
     Content-Type: application/x-www-form-urlencod= ed

     client_id=3Ds6BhdRkqt3&
     client_secret=3DgX1fBat3bV&code=3Di1WsRn1= uB1&
     redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample= %2Ecom%2Fcb


Best regards,
Diogo Almeida

--_000_C85560BD36AD7eranhueniversecom_-- From eran@hueniverse.com Sat Jul 3 21:50: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 9E3083A696D for ; Sat, 3 Jul 2010 21:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=1.200, 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 AJbz9H5JYbNM for ; Sat, 3 Jul 2010 21:50:22 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D8CE13A6840 for ; Sat, 3 Jul 2010 21:50:22 -0700 (PDT) Received: (qmail 30069 invoked from network); 4 Jul 2010 04:50:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Jul 2010 04:50:23 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 3 Jul 2010 21:50:22 -0700 From: Eran Hammer-Lahav To: Andrew Arnott , OAuth WG Date: Sat, 3 Jul 2010 21:50:17 -0700 Thread-Topic: [OAUTH-WG] draft 9, section 4.3.1 missing error code for invalid user credentials Thread-Index: AcsbD9gukU3HTxzVSeafLgVPTuS2DgAJI2b8 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C855611936AD9eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft 9, section 4.3.1 missing error code for invalid user 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: Sun, 04 Jul 2010 04:50:23 -0000 --_000_C855611936AD9eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There is no difference. The client credentials are either valid or not. EHL On 7/3/10 5:28 PM, "Andrew Arnott" wrote: I see an invalid-client-credentials error code, but for the basic-credentia= ls grant type, it seems there should be a specific error code to indicate t= he resource owner's basic creds are invalid, as opposed to the client's cre= dentials being invalid. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre --_000_C855611936AD9eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] draft 9, section 4.3.1 missing error code for invalid= user  credentials There is no difference. The client credentials are either valid or no= t.

EHL


On 7/3/10 5:28 PM, "Andrew Arnott" <andrewarnott@gmail.com> wrote:

I see an invalid-client-credentials error c= ode, but for the=A0basic-credentials=A0grant type, it seems there should be= a specific error code to indicate the resource owner's basic creds are inv= alid, as opposed to the client's credentials being invalid.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the d= eath your right to say it." - S. G. Tallentyre

--_000_C855611936AD9eranhueniversecom_-- From eran@hueniverse.com Sat Jul 3 21:51:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25BC3A696D for ; Sat, 3 Jul 2010 21:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=0.900, 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 mAYYHjkYeTw0 for ; Sat, 3 Jul 2010 21:51:23 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 0A7663A6840 for ; Sat, 3 Jul 2010 21:51:23 -0700 (PDT) Received: (qmail 17523 invoked from network); 4 Jul 2010 04:51:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Jul 2010 04:51:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 3 Jul 2010 21:51:22 -0700 From: Eran Hammer-Lahav To: Andrew Arnott , OAuth WG Date: Sat, 3 Jul 2010 21:51:17 -0700 Thread-Topic: [OAUTH-WG] Draft 9, Section 2 vs. Section 4.1 Thread-Index: AcsbEdHI1ZCOMNKrTG22UB+KFCMergAIrfAc Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C855615536ADBeranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft 9, Section 2 vs. Section 4.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 04:51:24 -0000 --_000_C855615536ADBeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Section 2 talked about how the client authenticates itself. This is used in= the token endpoint but can be used elsewhere (i.e. A device profile). EHL On 7/3/10 5:42 PM, "Andrew Arnott" wrote: It may be my misreading the spec, or making assumptions based on my clutter= ed mind from reading the various drafts, so apologies if I'm just confused,= but... Section 2 seems to be just sitting there. No discussion on how it fits int= o the spec from what I can see. It doesn't discuss how to obtain a grant, = or access token, or anything. It also mentions type=3Dweb-server, which is= an obsolete parameter. Section 4.1 has a grant_type=3Dnone option, which seems to cover the same s= cenario as Section 2 (did). I take it that section 4.1 is sort of the "2 l= egged OAuth" scenario. Am I correct in this? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre --_000_C855615536ADBeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Draft 9, Section 2 vs. Section 4.1 Section 2 talked about how the client authenticates itself. This is u= sed in the token endpoint but can be used elsewhere (i.e. A device profile)= .

EHL


On 7/3/10 5:42 PM, "Andrew Arnott" <andrewarnott@gmail.com> wrote:

It may be my misreading the spec, or making= assumptions based on my cluttered mind from reading the various drafts, so= apologies if I'm just confused, but...

Section 2 seems to be just sitting there. =A0No discussion on how it fits i= nto the spec from what I can see. =A0It doesn't discuss how to obtain a gra= nt, or access token, or anything. =A0It also mentions type=3Dweb-server, wh= ich is an obsolete parameter.

Section 4.1 has a grant_type=3Dnone option, which seems to cover the same s= cenario as Section 2 (did). =A0I take it that section 4.1 is sort of the &q= uot;2 legged OAuth" scenario. =A0Am I correct in this?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the d= eath your right to say it." - S. G. Tallentyre

--_000_C855615536ADBeranhueniversecom_-- From andrewarnott@gmail.com Sat Jul 3 21:52: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 CE1413A696D for ; Sat, 3 Jul 2010 21:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBqUsnV-BmFq for ; Sat, 3 Jul 2010 21:52:58 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 1226C3A6840 for ; Sat, 3 Jul 2010 21:52:57 -0700 (PDT) Received: by gxk3 with SMTP id 3so420697gxk.31 for ; Sat, 03 Jul 2010 21:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=TJ2n0XiIjyYUotIusLt360iPvWSEZHyw/opp7W0znFs=; b=U3n+VfXIZNJdhW9d1UBCUBR+axlSETxVmIC2mM866jMU/1DVmCl7BtHjK7nGoyjZCD lytvNY/99gNXdVT31qx4njgXFcwzrcE7IxjTP7uRkOfetWg5VWre9RNbWEm1h5vd5cAH uFrJ0H43HHRYBahfu3Y+iArzO00H69jnTz8LI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=gOQ36Vnt6C3HRVm9wqeydMCSukLaw55TJlzSJcHkeAeEehgfsybLMz55XrS8P2EsT9 UL4glc5rHxBK5SYGmjAsKEJkSlFSnoDoioNO5gZQmu5+JgTtQEYa3EVmD79bMqgQnSP+ 9YAkW25I6lVPpfyijdTweYzF1OdG+DlUFhhcs= Received: by 10.101.147.19 with SMTP id z19mr1341113ann.66.1278219175143; Sat, 03 Jul 2010 21:52:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.92.8 with HTTP; Sat, 3 Jul 2010 21:52:35 -0700 (PDT) In-Reply-To: References: From: Andrew Arnott Date: Sat, 3 Jul 2010 21:52:35 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e68debdee12b16048a8897f8 Cc: OAuth WG Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 04:52:59 -0000 --0016e68debdee12b16048a8897f8 Content-Type: text/plain; charset=ISO-8859-1 Yes, I agree the end user has to be present (or at least logged in with a cookie, typically) for the client to obtain an access token. But the user doesn't have to interact with the auth server at all or even be aware the a client web script is requesting an access token if that client script claims to have a client_id of another client the user has already authorized, and the auth server then issues the access token without confirmation with the user. And once the access token is obtained, that access token can be sent off to the evil script's master to use on another computer even. The only mitigation from this particular aspect of the portability of the access token that I can think of would be if the auth server and resource server are on the same domain, and the auth server sent an HTTP-only cookie to the client that would have to be present, paired with the access token, in the HTTP request at the resource server in order to be considered valid. That should defeat sending the access token away. But other evil things can be done with a illegitimately obtained access token that this wouldn't prevent. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Sat, Jul 3, 2010 at 9:43 PM, Eran Hammer-Lahav wrote: > It is used as a hint, but one the end-user can help verify. The security > consideration section needs to make this clear. > > EHL > > > > On 7/3/10 12:15 PM, "Andrew Arnott" wrote: > > (this sounds sarcastic, but I'm no being sarcastic... it's a serious > question/challenge)... > > Why not just remove the client_id parameter from the user-agent flow? It's > absolutely meaningless to security. It's only perceivable benefit is that > the auth server can possible display to the user the client being authorized > or the list of previously authorized clients. But again, that's totally > meaningless if not verified. > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > > On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott > wrote: > > On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav > wrote: > > You are putting too much weight on the value of redirection URI > registration. Since the same problem exists between the user-agent script > and the server-side component used in the user-agent profile, anyone can > imitate that flow. In most cases, the redirection URI will simply include a > script that will pass the parameter to the **parent** window which can be > anything. If the server-based page is an active page, it still needs to > communicate with the user-agent, which again, can pretend to be that. > > Good point. I wasn't imagining that far through it. Not to deny that most > redirection URLs may just return a straight script that passes it to the > parent window, but that seems pretty irresponsible to the host that's doing > it -- because of the enormous security hole it opens up. Some client is > trusted enough to authorize (by the user and auth server), receives an > access token it wasn't expecting, and then blindly forwards it onto whoever > wants it. Yikes. I sure hope these access tokens have *very* limited > scope (like, I'd prefer none myself). > > I was about to describe how an active server could alleviate that by > signing the original request using the state parameter, but I realized I'm > solving a problem that the web server flow (or nowadays that the > authorization code mode as I guess it's called) already solves. So I guess > I just need to bite the bullet and accept that the user agent flow is *totally > *insecure for web clients, and thus very special care must be taken to > enable native clients without opening up the web client hole. > > Sorry to sound so negative about it. Enabling this scenario seems really > important to me as well -- I just am against doing it when it can't be > secured in some way. Seriously... as is, once you authorize any client, > you've authorized them all, including clients not even running on your > computer. I guess this answers how I was visiting a site a few days ago and > was amazed that it knew who I was (via Facebook) and was displaying my name > and photo when I never logged into the site. I was shocked it knew who I > was. Enter living in Incognito mode from now on. > > > > --0016e68debdee12b16048a8897f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, I agree the end user has to be present (or at least logged in wit= h a cookie, typically) for the client to obtain an access token. =A0But the= user doesn't have to interact with the auth server at all or even be a= ware the a client web script is requesting an access token if that client s= cript claims to have a client_id of another client the user has already aut= horized, and the auth server then issues the access token without confirmat= ion with the user. =A0

And once the access token is obtained, that access toke= n can be sent off to the evil script's master to use on another compute= r even. The only mitigation from this particular aspect of the portability = of the access token that I can think of would be if the auth server and res= ource server are on the same domain, and the auth server sent an HTTP-only = cookie to the client that would have to be present, paired with the access = token, in the HTTP request at the resource server in order to be considered= valid. =A0That should defeat sending the access token away. =A0But other e= vil things can be done with a illegitimately obtained access token that thi= s wouldn't prevent.

--
Andrew Arnott
"I [may] not agree wi= th what you have to say, but I'll defend to the death your right to say= it." - S. G. Tallentyre


On Sat, Jul 3, 2010 at 9:43 PM, Eran Ham= mer-Lahav <eran= @hueniverse.com> wrote:
It is used as a hint, but one the end-user can help verify. The secur= ity consideration section needs to make this clear.

EHL



On 7/3/10 12:15 PM, "Andrew Arnott" <andrewarnott@gmail.com> wrote:
(this so= unds sarcastic, but I'm no being sarcastic... it's a serious questi= on/challenge)...

Why not just remove the client_id parameter from the user-agent flow? =A0It= 's absolutely meaningless to security. =A0It's only perceivable ben= efit is that the auth server can possible display to the user the client be= ing authorized or the list of previously authorized clients. =A0But again, = that's totally meaningless if not verified.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to t= he death your right to say it." - S. G. Tallentyre


On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer= -Lahav <eran@hu= eniverse.com> wrote:
You are putting too= much weight on the value of redirection URI registration. Since the same p= roblem exists between the user-agent script and the server-side component u= sed in the user-agent profile, anyone can imitate that flow. In most cases,= the redirection URI will simply include a script that will pass the parame= ter to the *parent* window which can be anything. If the server-base= d page is an active page, it still needs to communicate with the user-agent= , which again, can pretend to be that.
Good point. =A0I wasn't imagini= ng that far through it. =A0Not to deny that most redirection URLs may just = return a straight script that passes it to the parent window, but that seem= s pretty irresponsible to the host that's doing it -- because of the en= ormous security hole it opens up. =A0Some client is trusted enough to autho= rize (by the user and auth server), receives an access token it wasn't = expecting, and then blindly forwards it onto whoever wants it. =A0Yikes. = =A0I sure hope these access tokens have very=A0limited scope (like, = I'd prefer none myself).

I was about to describe how an active server could alleviate that by signin= g the original request using the state parameter, but I realized I'm so= lving a problem that the web server flow (or nowadays that the authorizatio= n code mode as I guess it's called) already solves. =A0So I guess I jus= t need to bite the bullet and accept that the user agent flow is totally= insecure for web clients, and thus very special care must be taken to = enable native clients without opening up the web client hole. =A0

Sorry to sound so negative about it. =A0Enabling this scenario seems really= important to me as well -- I just am against doing it when it can't be= secured in some way. =A0Seriously... as is, once you authorize any client,= you've authorized them all, including clients not even running on your= computer. =A0I guess this answers how I was visiting a site a few days ago= and was amazed that it knew who I was (via Facebook) and was displaying my= name and photo when I never logged into the site. =A0I was shocked it knew= who I was. =A0Enter living in Incognito mode from now on.



--0016e68debdee12b16048a8897f8-- From andrewarnott@gmail.com Sun Jul 4 19:33: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 D70DF3A67EF for ; Sun, 4 Jul 2010 19:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=0.045, 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 HYrSEhVj9-6r for ; Sun, 4 Jul 2010 19:33:21 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 49A7F3A6407 for ; Sun, 4 Jul 2010 19:33:21 -0700 (PDT) Received: by gyh3 with SMTP id 3so2600319gyh.31 for ; Sun, 04 Jul 2010 19:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=M6POG/lf1bbWVQB461rH2mPjv+KA8Qzcvy1jjU8n6XQ=; b=VLsHUGt3Hxq+B/jTg1b5k55ISjuOfeqr7TJamOhuuor+OVxopYM7zV+bTGrIYBm/mT QfA3QdI9avfsnXT8rNZqxO82eI6FN7+eEQyuzy8aaBR/5jPgRwjznUVJxehXtwwFsm/a fPnP8ZS6CZ/4NDYKi9xmr+Ig4VWyxFtn2hwwU= 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=SX/7C1Lj2H7U/WuLJtZ8b+lqA7Y4+adQAl7NRApk0NgQobIkw8QFazAH7G5d5OOSaw NvaS4+xfv2xtbqV8CkPDWFLlom8VPRazBb0kUKhQ+vQsKTvOlkrEpyX0J1N5P2dHrCxJ W6Oi15rGd47wvHHyMp5AVPe167Oq5WZ9RqeaM= MIME-Version: 1.0 Received: by 10.90.81.7 with SMTP id e7mr2484279agb.110.1278297199256; Sun, 04 Jul 2010 19:33:19 -0700 (PDT) Received: by 10.150.92.8 with HTTP; Sun, 4 Jul 2010 19:33:19 -0700 (PDT) In-Reply-To: References: Date: Sun, 4 Jul 2010 19:33:19 -0700 Message-ID: From: Andrew Arnott To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00163613a4047aa3c9048a9ac2e6 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft 9, section 4.3.1 missing error code for invalid user 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, 05 Jul 2010 02:33:23 -0000 --00163613a4047aa3c9048a9ac2e6 Content-Type: text/plain; charset=ISO-8859-1 Well, to the client app there's an important distinction I think. If the client id and secret are invalid, that signifies either an internal error or a total revocation of support for the client. But the username/password being bad means the client should ask the user to re-enter their credentials. Otherwise it leads to user frustration that the client keeps putting up a reprompt for creds when it will never end up working. So from a client perspective it seems like an important distinction. no? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Sat, Jul 3, 2010 at 9:50 PM, Eran Hammer-Lahav wrote: > There is no difference. The client credentials are either valid or not. > > > EHL > > > On 7/3/10 5:28 PM, "Andrew Arnott" wrote: > > I see an invalid-client-credentials error code, but for > the basic-credentials grant type, it seems there should be a specific error > code to indicate the resource owner's basic creds are invalid, as opposed to > the client's credentials being invalid. > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > --00163613a4047aa3c9048a9ac2e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, to the client app there's an important distinction I think. =A0If= the client id and secret are invalid, that signifies either an internal er= ror or a total revocation of support for the client. =A0But the username/pa= ssword being bad means the client should ask the user to re-enter their cre= dentials. =A0Otherwise it leads to user frustration that the client keeps p= utting up a reprompt for creds when it will never end up working.

So from a client perspective it seems like an important dist= inction. =A0no?
--
Andrew Arnott
"I [may] not a= gree with what you have to say, but I'll defend to the death your right= to say it." - S. G. Tallentyre


On Sat, Jul 3, 2010 at 9:50 PM, Eran Ham= mer-Lahav <eran= @hueniverse.com> wrote:
There is no difference. The client credentials are either valid or no= t.


EHL


On 7/3/10 5:28 PM, "Andrew Arnott" <andrewarnott@gmail.com> wrote:

I s= ee an invalid-client-credentials error code, but for the=A0basic-credential= s=A0grant type, it seems there should be a specific error code to indicate = the resource owner's basic creds are invalid, as opposed to the client&= #39;s credentials being invalid.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to t= he death your right to say it." - S. G. Tallentyre


--00163613a4047aa3c9048a9ac2e6-- From eran@hueniverse.com Sun Jul 4 19:48: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 BC8693A681D for ; Sun, 4 Jul 2010 19:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=0.335, 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 SwIykCNbnYNT for ; Sun, 4 Jul 2010 19:48:45 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 02CD83A6813 for ; Sun, 4 Jul 2010 19:48:44 -0700 (PDT) Received: (qmail 2490 invoked from network); 5 Jul 2010 02:48:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 5 Jul 2010 02:48:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 4 Jul 2010 19:48:44 -0700 From: Eran Hammer-Lahav To: Andrew Arnott Date: Sun, 4 Jul 2010 19:48:39 -0700 Thread-Topic: [OAUTH-WG] draft 9, section 4.3.1 missing error code for invalid user credentials Thread-Index: Acsb6m8RMl6wOYkUSqWdPmiig380vQAAiMs7 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C856961736AFFeranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft 9, section 4.3.1 missing error code for invalid user 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, 05 Jul 2010 02:48:49 -0000 --_000_C856961736AFFeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the client credentials are bad the server returns: invalid-client-creden= tials If the end-user's credentials are bad, the server returns: invalid-grant Not sure what's the issue. EHL On 7/4/10 7:33 PM, "Andrew Arnott" wrote: Well, to the client app there's an important distinction I think. If the c= lient id and secret are invalid, that signifies either an internal error or= a total revocation of support for the client. But the username/password b= eing bad means the client should ask the user to re-enter their credentials= . Otherwise it leads to user frustration that the client keeps putting up = a reprompt for creds when it will never end up working. So from a client perspective it seems like an important distinction. no? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre On Sat, Jul 3, 2010 at 9:50 PM, Eran Hammer-Lahav wro= te: There is no difference. The client credentials are either valid or not. EHL On 7/3/10 5:28 PM, "Andrew Arnott" > wrote: I see an invalid-client-credentials error code, but for the basic-credentia= ls grant type, it seems there should be a specific error code to indicate t= he resource owner's basic creds are invalid, as opposed to the client's cre= dentials being invalid. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre --_000_C856961736AFFeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] draft 9, section 4.3.1 missing error code for invalid=  user credentials If the client credentials are bad the server returns: invalid-client-= credentials
If the end-user’s credentials are bad, the server returns: invalid-gr= ant

Not sure what’s the issue.

EHL


On 7/4/10 7:33 PM, "Andrew Arnott" <andrewarnott@gmail.com> wrote:

Well, to the client app there's an importan= t distinction I think. =A0If the client id and secret are invalid, that sig= nifies either an internal error or a total revocation of support for the cl= ient. =A0But the username/password being bad means the client should ask th= e user to re-enter their credentials. =A0Otherwise it leads to user frustra= tion that the client keeps putting up a reprompt for creds when it will nev= er end up working.

So from a client perspective it seems like an important distinction. =A0no?=
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the d= eath your right to say it." - S. G. Tallentyre


On Sat, Jul 3, 2010 at 9:50 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
There is no difference. The client credenti= als are either valid or not.


EHL


On 7/3/10 5:28 PM, "Andrew Arnott" <andrewarnott@gmail.com <http://andrewarnott@gmail.com> > wrote:

I see an invalid-client-credentials error c= ode, but for the=A0basic-credentials=A0grant type, it seems there should be= a specific error code to indicate the resource owner's basic creds are inv= alid, as opposed to the client's credentials being invalid.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the d= eath your right to say it." - S. G. Tallentyre



--_000_C856961736AFFeranhueniversecom_-- From andrewarnott@gmail.com Mon Jul 5 07:00:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A383A696D for ; Mon, 5 Jul 2010 07:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=0.966, 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 TtQrfh4INjLh for ; Mon, 5 Jul 2010 07:00:42 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4746D3A67BD for ; Mon, 5 Jul 2010 07:00:42 -0700 (PDT) Received: by vws14 with SMTP id 14so4600426vws.31 for ; Mon, 05 Jul 2010 07:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=D0mY/4j4AWvSU24mjzc73Qt6BaqQ3vqa3PspMRW/ezw=; b=SUlZyO4PQMtAX7ByMbfwl342KPElNJ6HwKynl+vQn74L7cmej4M01GHGF6C9hcCO84 IQUR++hPkFQP8yipPyttp0VuHiGuaK+cdsPiKk+0uaclaVGIYjK3FhG5FwK3XSLj/PLB qOXyIBWg3IDaQE+BA2O54RroPxetH/c7nCTB4= 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=Qnya/VfaI6YfIuYcgf0Yv9TIb8/X9jX6bDJplSLWP5IIQIYyQeTMWprJR2OEGZr1J3 yQZXKjTxH/NtjyahCNU/EZJK30bhu2g6BoDLPA3jGhSqYbYAIq6DWYYxTEyaxP2EWtEl dQ0jUQRX5JjKs5EuamM/BHnJO37ezTljRe2pQ= MIME-Version: 1.0 Received: by 10.224.95.225 with SMTP id e33mr1440016qan.331.1278338437490; Mon, 05 Jul 2010 07:00:37 -0700 (PDT) Received: by 10.150.92.8 with HTTP; Mon, 5 Jul 2010 07:00:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Jul 2010 07:00:37 -0700 Message-ID: From: Andrew Arnott To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00c09f99de73782871048aa45c16 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft 9, section 4.3.1 missing error code for invalid user 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, 05 Jul 2010 14:00:44 -0000 --00c09f99de73782871048aa45c16 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable No issue. I didn't consider invalid-grant, but reading it more carefully I should have. Yes, the distinction I was looking for is there. Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Sun, Jul 4, 2010 at 7:48 PM, Eran Hammer-Lahav wrot= e: > If the client credentials are bad the server returns: > invalid-client-credentials > If the end-user=92s credentials are bad, the server returns: invalid-gran= t > > Not sure what=92s the issue. > > EHL > > > > On 7/4/10 7:33 PM, "Andrew Arnott" wrote: > > Well, to the client app there's an important distinction I think. If the > client id and secret are invalid, that signifies either an internal error= or > a total revocation of support for the client. But the username/password > being bad means the client should ask the user to re-enter their > credentials. Otherwise it leads to user frustration that the client keep= s > putting up a reprompt for creds when it will never end up working. > > So from a client perspective it seems like an important distinction. no? > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the deat= h > your right to say it." - S. G. Tallentyre > > > On Sat, Jul 3, 2010 at 9:50 PM, Eran Hammer-Lahav > wrote: > > There is no difference. The client credentials are either valid or not. > > > EHL > > > On 7/3/10 5:28 PM, "Andrew Arnott" http://andrewarnott@gmail.com> > wrote: > > I see an invalid-client-credentials error code, but for > the basic-credentials grant type, it seems there should be a specific err= or > code to indicate the resource owner's basic creds are invalid, as opposed= to > the client's credentials being invalid. > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the deat= h > your right to say it." - S. G. Tallentyre > > > > --00c09f99de73782871048aa45c16 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable No issue. I didn't consider invalid-grant, but reading it more carefull= y I should have. Yes, the distinction I was looking for is there.

<= /div>
Thanks.
--
Andrew Arnott
"I [may] not= agree with what you have to say, but I'll defend to the death your rig= ht to say it." - S. G. Tallentyre


On Sun, Jul 4, 2010 at 7:48 PM, Eran Ham= mer-Lahav <eran= @hueniverse.com> wrote:
If the client credentials are bad the server returns: invalid-client-= credentials
If the end-user=92s credentials are bad, the server returns: invalid-grant<= br>
Not sure what=92s the issue.

EHL



On 7/4/10 7:33 PM, "Andrew Arnott" <andrewarnott@gmail.com> wrote:

Well, to the client= app there's an important distinction I think. =A0If the client id and = secret are invalid, that signifies either an internal error or a total revo= cation of support for the client. =A0But the username/password being bad me= ans the client should ask the user to re-enter their credentials. =A0Otherw= ise it leads to user frustration that the client keeps putting up a repromp= t for creds when it will never end up working.

So from a client perspective it seems like an important distinction. =A0no?=
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to t= he death your right to say it." - S. G. Tallentyre


On Sat, Jul 3, 2010 at 9:50 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
There is no differe= nce. The client credentials are either valid or not.


EHL


On 7/3/10 5:28 PM, "Andrew Arnott" <andrewarnott@gmail.com <http://andrewarnott@gmail= .com> > wrote:

I see an invalid-cl= ient-credentials error code, but for the=A0basic-credentials=A0grant type, = it seems there should be a specific error code to indicate the resource own= er's basic creds are invalid, as opposed to the client's credential= s being invalid.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to t= he death your right to say it." - S. G. Tallentyre




--00c09f99de73782871048aa45c16-- From recordond@gmail.com Mon Jul 5 09:42: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 468653A67F7 for ; Mon, 5 Jul 2010 09:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCDTDwUjeYZ7 for ; Mon, 5 Jul 2010 09:42:00 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 5A8DE3A67F8 for ; Mon, 5 Jul 2010 09:42:00 -0700 (PDT) Received: by iwn5 with SMTP id 5so765314iwn.31 for ; Mon, 05 Jul 2010 09:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=OnG4n337YWZymMshTlVrj/7gXLCmfMxfGH1qjA04B90=; b=sByjZawhBb+6eKtH1o4nnhd6YUKGFwzsw3Sfl3OKMQSZE5wbWSiA8EFMYI1LJrXVM2 eu5ZLFj3lh3PyqYB4/stih0oUNgCwYqGOG3zJybnZ7olOvDndE2wKo06v5aJdtLJpOvC 8U6lXo/b05IwXmqy7ovzDbJV2WsKDu+t4yAD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=cx8Tg6HVQnA785D8RlZoSYMpfuoY4g1p2ki/2Un3QVXdbcCxVm/6S0p49bNOReFvPV dvHIMcDB/mYWYIZdhDKCMn1rcRqIB/yev4gzqArsweuTDn7+MXnMz5E8yg54hrkHxkaI hBAWidqvpmwQ7NKVS3FEL9TCzeWCMV5Y0MJGQ= MIME-Version: 1.0 Received: by 10.231.32.134 with SMTP id c6mr2985023ibd.152.1278348121338; Mon, 05 Jul 2010 09:42:01 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Mon, 5 Jul 2010 09:42:01 -0700 (PDT) In-Reply-To: <4C2F108B.70504@cdatazone.org> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2DC7C5.2090009@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F108B.70504@cdatazone.org> Date: Mon, 5 Jul 2010 09:42:01 -0700 Message-ID: From: David Recordon To: Rob Richards , Eran Hammer-Lahav , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=002215048e77abf2e9048aa69d0f Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 16:42:02 -0000 --002215048e77abf2e9048aa69d0f Content-Type: text/plain; charset=ISO-8859-1 I'm also of the opinion that a protected resource can use the request parameters to differentiate between 1.0 and 2.0. On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards wrote: > On that note are there any guidelines, howtos, etc.. on writing a spec? > I'd recommend focusing on just writing the text and then making it spec like later. Eran has been generally quite willing to take good text and edit it into an actual spec. If you're interested in learning about the spec side of it, you can take a look at http://github.com/daveman692/OAuth-2.0/blob/master/draft-recordon-oauth-v2-ux.xmlwhich is a pretty simple example. --David > -----Original Message----- >>> From: Rob Richards [mailto:rrichards@cdatazone.org] >>> Sent: Friday, July 02, 2010 4:05 AM >>> To: Eran Hammer-Lahav >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Versioning >>> >>> Eran Hammer-Lahav wrote: >>> >>> >>>> [Replying to everything at once...] >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Rob Richards [mailto:rrichards@cdatazone.org] >>>>> Sent: Thursday, July 01, 2010 11:43 AM >>>>> >>>>> >>>>> >>>> >>>> >>>>> Exactly. While it might be needed in the future, there is a need to >>>>> differentiate OAuth 1.0 from 2.0 on resource endpoints right now. >>>>> Outside of requiring an oauth_version parameter (or equivalent) all >>>>> other suggestions leave versioning as a grey area, where things can >>>>> be interpreted one way or another with no consistency. Grey areas in >>>>> >>>>> >>>> specs are a bad thing. >>> >>> >>>> You end up with different languages/libraries dealing with things in >>>>> completely different and incompatible ways because something was not >>>>> clearly spelled out. >>>>> >>>>> >>>>> >>>> This is an area that is clearly on the server side, not the client. >>>> Since the >>>> >>>> >>> core specification leaves discovery out, client developers need to know >>> what >>> version of OAuth is supported by the server and use the right one. >>> Without >>> discovery, the client must know ahead of time what to do. With discovery, >>> the client can choose the right protocol. Either way, the client never >>> just >>> sends a 1.0 or 2.0 requests and hopes for the best. >>> >>> >>>> On the server side, the challenge isn't that significant. When not using >>>> a >>>> >>>> >>> header, the server can use multiple methods to differentiate the version >>> used by the client: >>> >>> >>>> 1. Token syntax >>>> 2. Presence of 'oauth_signature_method' >>>> 3. Presence of 'oauth_signature' >>>> 4. Presence of no other 'oauth_' parameter than 'oauth_token' >>>> >>>> >>>> >>> Never said this was hard just that it needs to be documented. >>> >>> >>>> With this the spec needs to including some wording to explicitly >>>>> define how to handle the case when running an endpoint supporting >>>>> both OAuth >>>>> 1.0 and 2.0 and the oauth2_token is missing then the call is handled >>>>> according to the OAuth 1.0/a spec. Whatever is decided, be it a >>>>> version parameter, the use of oauth2_token or the check for the >>>>> existence of the oauth_signature_method parameter, etc///, the spec >>>>> needs to define and be explicit on how a resource endpoint determines >>>>> between a 1.0 and 2.0 call when both are supported. >>>>> >>>>> >>>>> >>>> The damage done by interpreting a malformed 1.0 request (the odd >>>> >>>> >>> attempt to use 1.0 by only including 'oauth_token') is at most returning >>> an >>> 'invalid-token' response. I hope every server developer understands that >>> they should not share tokens between 1.0 and 2.0 with completely >>> different >>> security properties. >>> Still the issue that different error codes returned which a client may >>> handle >>> differently. >>> >>> >>>> I think there are more issue with regard to 1.0 to 2.0 migration that >>>> should >>>> >>>> >>> be addressed, and I have asked those who care about this to propose a >>> draft. >>> Given that such a draft will not be useful for a long time, given that >>> the vast >>> majority of OAuth implementation 1-2 years from now will be 2.0, I do not >>> want to include it in the core specification. >>> >>> >>>> In order for your argument to stand, you need to show how the current >>>> >>>> >>> setup leads to interoperability problems. Given the 4 options above, and >>> the >>> fact that a malformed 1.0 request will still fail, I do not agree that >>> interop is >>> affected. >>> >>> >>>> >>>> >>>> >>> OAuth is a service that my company provides to other companies and we >>> will >>> need to run both versions in parallel for many of the customers. >>> There are other companies out there who provide similar service, so this >>> isn't >>> just an isolated problem. We may be transitioning customers to/from our >>> service and the behaviors of the systems need to be the same pre and post >>> migration. >>> There is also the WTF factor for developers. If I make calls to 2 >>> providers (1.0 >>> client), each of which is missing the oauth_signature, I would expect the >>> same response back. An error that its missing a required signature. If >>> one of >>> the providers interprets a missing signature as meaning the call is a 2.0 >>> based >>> call then it will return back a different error code. >>> >>> I would expect that if I implemented 2 independent systems based on a >>> spec >>> they would operate and behave the exact same way, otherwise you can just >>> throw the spec in the pile with the rest of them that have ambiguous >>> sections left to interpretation and cause for argument over who >>> implemented what correctly in their system. >>> >>> Rob >>> >>> >> >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --002215048e77abf2e9048aa69d0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm also of the opinion that a protected resource can use the requ= est parameters to differentiate between 1.0 and 2.0.

On= Sat, Jul 3, 2010 at 3:27 AM, Rob Richards <rrichards@cdatazone.org> wro= te:
On that note are there any guidelines, howtos, etc.. on writing a spec?

I'd=A0recommend=A0focusing on just wri= ting the text and then making it spec like later. Eran has been generally q= uite willing to take good text and edit it into an actual spec. If you'= re interested in learning about the spec side of it, you can take a look at= =A0http://github.com/daveman692/OAuth-2.0/blob/master/dr= aft-recordon-oauth-v2-ux.xml which is a pretty simple example.

--David

=A0=A0
-----Original Message-----
From: Rob Richards [mailto:rrichards@cdatazone.org]
Sent: Friday, July 02, 2010 4:05 AM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org<= br> Subject: Re: [OAUTH-WG] Versioning

Eran Hammer-Lahav wrote:
=A0 =A0
[Replying to everything at once...]

=A0 =A0 =A0
-----Original Message-----
From: Rob Richards [mailto:rrichards@cdatazone.org]
Sent: Thursday, July 01, 2010 11:43 AM

=A0 =A0 =A0 =A0
=A0 =A0 =A0
Exactly. While it might be needed in the future, there is a need to
differentiate OAuth 1.0 from 2.0 on resource endpoints right now.
Outside of requiring an oauth_version parameter (or equivalent) all
other suggestions leave versioning as a grey area, where things can
be interpreted one way or another with no consistency. Grey areas in
=A0 =A0 =A0 =A0
specs are a bad thing.
=A0 =A0
You end up with different languages/libraries dealing with things in
completely different and incompatible ways because something was not
clearly spelled out.

=A0 =A0 =A0 =A0
This is an area that is clearly on the server side, not the client. Since t= he
=A0 =A0 =A0
core specification leaves discovery out, client developers need to know wha= t
version of OAuth is supported by the server and use the right one. Without<= br> discovery, the client must know ahead of time what to do. With discovery, the client can choose the right protocol. Either way, the client never just=
sends a 1.0 or 2.0 requests and hopes for the best.
=A0 =A0
On the server side, the challenge isn't that significant. When not usin= g a
=A0 =A0 =A0
header, the server can use multiple methods to differentiate the version used by the client:
=A0 =A0
1. Token syntax
2. Presence of 'oauth_signature_method'
3. Presence of 'oauth_signature'
4. Presence of no other 'oauth_' parameter than 'oauth_token= 9;

=A0 =A0 =A0
Never said this was hard just that it needs to be documented.
=A0 =A0
With this the spec needs to including some wording to explicitly
define how to handle the case when running an endpoint supporting
both OAuth
1.0 and 2.0 and the oauth2_token is missing then the call is handled
according to the OAuth 1.0/a spec. Whatever is decided, be it a
version parameter, the use of oauth2_token or the check for the
existence of the oauth_signature_method parameter, etc///, the spec
needs to define and be explicit on how a resource endpoint determines
between a 1.0 and 2.0 call when both are supported.

=A0 =A0 =A0 =A0
The damage done by interpreting a malformed 1.0 request (the odd
=A0 =A0 =A0
attempt to use 1.0 by only including 'oauth_token') is at most retu= rning an
'invalid-token' response. I hope every server developer understands= that
they should not share tokens between 1.0 and 2.0 with completely different<= br> security properties.
=A0 =A0Still the issue that different error codes returned which a client = may handle
differently.
=A0 =A0
I think there are more issue with regard to 1.0 to 2.0 migration that shoul= d
=A0 =A0 =A0
be addressed, and I have asked those who care about this to propose a draft= .
Given that such a draft will not be useful for a long time, given that the = vast
majority of OAuth implementation 1-2 years from now will be 2.0, I do not want to include it in the core specification.
=A0 =A0
In order for your argument to stand, you need to show how the current
=A0 =A0 =A0
setup leads to interoperability problems. Given the 4 options above, and th= e
fact that a malformed 1.0 request will still fail, I do not agree that inte= rop is
affected.
=A0 =A0

=A0 =A0 =A0
OAuth is a service that my company provides to other companies and we will<= br> need to run both versions in parallel for many of the customers.
There are other companies out there who provide similar service, so this is= n't
just an isolated problem. We may be transitioning customers to/from our
service and the behaviors of the systems need to be the same pre and post migration.
There is also the WTF factor for developers. If I make calls to 2 providers= (1.0
client), each of which is missing the oauth_signature, I would expect the same response back. An error that its missing a required signature. If one = of
the providers interprets a missing signature as meaning the call is a 2.0 b= ased
call then it will return back a different error code.

I would expect that if I implemented 2 independent systems based on a spec<= br> they would operate and behave the exact same way, otherwise you can just throw the spec in the pile with the rest of them that have ambiguous
sections left to interpretation and cause for argument over who
implemented what correctly in their system.

Rob
=A0 =A0

=A0

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

--002215048e77abf2e9048aa69d0f-- From recordond@gmail.com Mon Jul 5 09:46: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 BC33D3A6919 for ; Mon, 5 Jul 2010 09:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmMr7Uoh7TIr for ; Mon, 5 Jul 2010 09:46:36 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 384193A69C7 for ; Mon, 5 Jul 2010 09:46:30 -0700 (PDT) Received: by iwn5 with SMTP id 5so769116iwn.31 for ; Mon, 05 Jul 2010 09:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=NvWjVnMw2SpXrPRW8aLhUovE+uBUz+cdnF6jtMBjpE0=; b=MRhKned3haBvd9rYfVXN1xMPWt0IQnCRgfh8A1OGixYI4mDWs0juzXP6kXvpGLZy7Z tJQqBHWls60iZIlmu6Pke6WolbqW3VIDc16mI6gmVTEiLglLTkD5h+kzuXXgAA8Rxfit gKX2thtm77FyHPupWEmuWCOjsMwurTRanx2L4= 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=lCJMmNS0bk36NCg/ihZFaNJjtM7wMHkhwbJhh6vN7Km3mn+IcrzRzqagTeuCa3rG0x Fcf3kPmhtWeyixENpmMh5BcQw+nGhE0Byroo0pjVhz4tcdtB8xzMRBXBBFLBBsl3WDUW 1NPcJ9u15fiXv96gqZPgkvwyPN6wmiziqTJ7I= MIME-Version: 1.0 Received: by 10.231.174.72 with SMTP id s8mr831214ibz.41.1278348391189; Mon, 05 Jul 2010 09:46:31 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Mon, 5 Jul 2010 09:46:31 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6C1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <402D29DB-A3F5-48C5-9654-543B7F6D6356@gmail.com> <4D3A5EF5-CC38-405A-85F7-7E24B957BA44@gmail.com> <21AF3452-B1AF-40CE-A72C-5923FEB0543C@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6C1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 5 Jul 2010 09:46:31 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016364ed35ec18ecc048aa6ad65 Cc: "flatter@gmail.com" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Authorization Response "scope" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 16:46:39 -0000 --0016364ed35ec18ecc048aa6ad65 Content-Type: text/plain; charset=ISO-8859-1 Seems like adding, "It's RECOMMENDED that this parameter be included if the access grant's scope differs from the requested scope." would be useful implementation advice in 3.1. On Fri, Jul 2, 2010 at 9:27 AM, Eran Hammer-Lahav wrote: > Scope is an optional feature of a protocol. The server is free to express > the granted scope in any way it deems appropriate (that is, omit it, include > it as requested by the client, specify another granted scope). No changes > are necessary. > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Diogo Almeida > > Sent: Friday, July 02, 2010 9:23 AM > > To: Marius Scurtescu > > Cc: flatter@gmail.com; oauth@ietf.org > > Subject: Re: [OAUTH-WG] Authorization Response "scope" parameter > > > > Hello Marius, > > > > Thanks for your feedback regarding this issue. > > > > You make a valid point, stating that the authorization server should only > send > > the scope if it differs from the requested one. However, I would like to > > enclose two notes regarding that approach: > > > > * If I understand the 09 draft correctly, the omission of the > authorization > > response scope has no implicit meaning, thus a change to the spec would > still > > have to made > > > > * From an authorization server implementer point of view, I find that > > enforcing the server to explicitly take into account the requester's > scope > > removes ambiguity from the messages / flow without any significant > > overhead > > > > Best regards, > > Diogo Almeida > > > > > > On Jul 2, 2010, at 5:02 PM, Marius Scurtescu wrote: > > > > > If the scopes granted by the authz server are exactly the ones > > > requested by the client then I don't see the need for the authz server > > > to send a scope parameter. > > > > > > I think the authz server should send the scope parameter if the > > > granted scopes are different from the requested ones, or if there was > > > no scope parameter on the request. > > > > > > Marius > > > > > > > > > > > > On Fri, Jul 2, 2010 at 8:51 AM, Diogo Almeida > > > wrote: > > >> Good afternoon, > > >> > > >> We're in the process of implementing an open-source Ruby OAuth 2 > > (draft 09) server, which will be made available at > > http://github.com/aflatter/oauth2-ruby. > > >> > > >> During our draft 09 analysis we've noticed that the OPTIONAL scope > sent > > by the client in the Authorization Request is disconnected from the > > Authorization Response scope in a way that, in our opinion, makes it hard > for > > the client to know if his requested scope was met or not. > > >> > > >> For example, consider a scenario where a client issues an > authorization > > code request to the authorization server, including in that request the > scope > > "friends photos videos". However, the resource owner only authorizes the > > access to the friends list, thus, in our opinion, the authorization > server MUST > > send an authorization response containing the code and the following > scope > > "friends". > > >> > > >> Also, should the authorization server wish to append other scopes, it > > should be free to do so, per current draft specification. In that regard, > it > > would be possible for the response to have the following scope: "friends > > extended_user_info". > > >> > > >> In light of this opinion, we enclose the following text change request > > regarding draft 9 section 3.1 scope parameter: > > >> > > >> scope > > >> REQUIRED if it has been passed in the authorization request, > > otherwise OPTIONAL. > > >> This parameter delimits the scope of the access token as an > > unordered list of > > >> space-delimited strings, each adding an additional access > range to the > > requested > > >> scope. > > >> The value of the "scope" parameter is defined by the > authorization > > server and > > >> MUST take into account the "scope" requested in the > authorization > > request by setting the > > >> authorization response "scope" parameter to the values to > which the > > token grants access. > > >> Furthermore, the authorization server can add any other values > > deemed necessary > > >> to determine response scope. > > >> > > >> Best regards, > > >> Diogo Almeida > > >> > > >> _______________________________________________ > > >> 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 > --0016364ed35ec18ecc048aa6ad65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Seems like adding, "It's RECOMMENDED that this parameter be includ= ed if the access grant's scope differs from the requested scope." = would be useful implementation advice in 3.1.


On Fri, Jul 2, 2010 at 9:27 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrot= e:
Scope is an optional feature of a protocol. The server is free to express t= he granted scope in any way it deems appropriate (that is, omit it, include= it as requested by the client, specify another granted scope). No changes = are necessary.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf
> Of Diogo Almeida
> Sent: Friday, July 02, 2010 9:23 AM
> To: Marius Scurtescu
> Cc: flatter@gmail.com; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Authorization Response "scope" param= eter
>
> Hello Marius,
>
> Thanks for your feedback regarding this issue.
>
> You make a valid point, stating that the authorization server should o= nly send
> the scope if it differs from the requested one. However, I would like = to
> enclose two notes regarding that approach:
>
> * If I understand the 09 draft correctly, the omission of the authoriz= ation
> response scope has no implicit meaning, thus a change to the spec woul= d still
> have to made
>
> * From an authorization server implementer point of view, I find that<= br> > enforcing the server to explicitly take into account the requester'= ;s scope
> removes ambiguity from the messages / flow without any significant
> overhead
>
> Best regards,
> Diogo Almeida
>
>
> On Jul 2, 2010, at 5:02 PM, Marius Scurtescu wrote:
>
> > If the scopes granted by the authz server are exactly the ones > > requested by the client then I don't see the need for the aut= hz server
> > to send a scope parameter.
> >
> > I think the authz server should send the scope parameter if the > > granted scopes are different from the requested ones, or if there= was
> > no scope parameter on the request.
> >
> > Marius
> >
> >
> >
> > On Fri, Jul 2, 2010 at 8:51 AM, Diogo Almeida
> > <diogo.borge= s.almeida@gmail.com> wrote:
> >> Good afternoon,
> >>
> >> We're in the process of implementing an open-source Ruby = OAuth 2
> (draft 09) server, which will be made available at
> h= ttp://github.com/aflatter/oauth2-ruby.
> >>
> >> During our draft 09 analysis we've noticed that the OPTIO= NAL scope sent
> by the client in the Authorization Request is disconnected from the > Authorization Response scope in a way that, in our opinion, makes it h= ard for
> the client to know if his requested scope was met or not.
> >>
> >> For example, consider a scenario where a client issues an aut= horization
> code request to the authorization server, including in that request th= e scope
> "friends photos videos". However, the resource owner only au= thorizes the
> access to the friends list, thus, in our opinion, the authorization se= rver MUST
> send an authorization response containing the code and the following s= cope
> "friends".
> >>
> >> Also, should the authorization server wish to append other sc= opes, it
> should be free to do so, per current draft specification. In that rega= rd, it
> would be possible for the response to have the following scope: "= friends
> extended_user_info".
> >>
> >> In light of this opinion, we enclose the following text chang= e request
> regarding draft 9 section 3.1 scope parameter:
> >>
> >> =A0 scope
> >> =A0 =A0 =A0 =A0 REQUIRED if it has been passed in the authori= zation request,
> otherwise OPTIONAL.
> >> =A0 =A0 =A0 =A0 This parameter delimits the scope of the acce= ss token as an
> unordered list of
> >> =A0 =A0 =A0 =A0 space-delimited strings, each adding an addit= ional access range to the
> requested
> >> =A0 =A0 =A0 =A0 scope.
> >> =A0 =A0 =A0 =A0 The value of the "scope" parameter = is defined by the authorization
> server and
> >> =A0 =A0 =A0 =A0 MUST take into account the "scope" = requested in the authorization
> request by setting the
> >> =A0 =A0 =A0 =A0 authorization response "scope" para= meter to the values to which the
> token grants access.
> >> =A0 =A0 =A0 =A0 Furthermore, the authorization server can add= any other values
> deemed necessary
> >> =A0 =A0 =A0 =A0 to determine response scope.
> >>
> >> Best regards,
> >> Diogo Almeida
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016364ed35ec18ecc048aa6ad65-- From wmills@yahoo-inc.com Mon Jul 5 22:28:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 733C83A68B0 for ; Mon, 5 Jul 2010 22:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.264 X-Spam-Level: X-Spam-Status: No, score=-17.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fEc7XyPI-hy for ; Mon, 5 Jul 2010 22:28:26 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id E5DC03A6856 for ; Mon, 5 Jul 2010 22:28:25 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o665RRnl080345; Mon, 5 Jul 2010 22:27:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=OCBSUi1F8Nl4ZW5gaEaFXzBDhyjBPkszhylH0MX8cByDHm6JALyRGaSqpt2jaaku Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 22:27:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1CCB.EBA8AA02" Date: Mon, 5 Jul 2010 22:27:26 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6A0A@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) Thread-Index: Acsa5C+8l0Fr7cg3RWKeKrsSZoLPjgBuPH8Q References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" To: "Andrew Arnott" , "Eran Hammer-Lahav" X-OriginalArrivalTime: 06 Jul 2010 05:27:27.0204 (UTC) FILETIME=[EBE8EA40:01CB1CCB] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 05:28:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1CCB.EBA8AA02 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable It's not verifiable, but it is as useful in this case as a "user agent" string. Not usefule formt he security perspective, but has some utility in application tracking. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew Arnott Sent: Saturday, July 03, 2010 12:16 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) =09 =09 (this sounds sarcastic, but I'm no being sarcastic... it's a serious question/challenge)...=20 Why not just remove the client_id parameter from the user-agent flow? It's absolutely meaningless to security. It's only perceivable benefit is that the auth server can possible display to the user the client being authorized or the list of previously authorized clients. But again, that's totally meaningless if not verified. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre =09 =09 =09 On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott wrote: =09 On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav wrote: =09 You are putting too much weight on the value of redirection URI registration. Since the same problem exists between the user-agent script and the server-side component used in the user-agent profile, anyone can imitate that flow. In most cases, the redirection URI will simply include a script that will pass the parameter to the *parent* window which can be anything. If the server-based page is an active page, it still needs to communicate with the user-agent, which again, can pretend to be that. Good point. I wasn't imagining that far through it. Not to deny that most redirection URLs may just return a straight script that passes it to the parent window, but that seems pretty irresponsible to the host that's doing it -- because of the enormous security hole it opens up. Some client is trusted enough to authorize (by the user and auth server), receives an access token it wasn't expecting, and then blindly forwards it onto whoever wants it. Yikes. I sure hope these access tokens have very limited scope (like, I'd prefer none myself). I was about to describe how an active server could alleviate that by signing the original request using the state parameter, but I realized I'm solving a problem that the web server flow (or nowadays that the authorization code mode as I guess it's called) already solves. So I guess I just need to bite the bullet and accept that the user agent flow is totally insecure for web clients, and thus very special care must be taken to enable native clients without opening up the web client hole. =20 Sorry to sound so negative about it. Enabling this scenario seems really important to me as well -- I just am against doing it when it can't be secured in some way. Seriously... as is, once you authorize any client, you've authorized them all, including clients not even running on your computer. I guess this answers how I was visiting a site a few days ago and was amazed that it knew who I was (via Facebook) and was displaying my name and photo when I never logged into the site. I was shocked it knew who I was. Enter living in Incognito mode from now on. ------_=_NextPart_001_01CB1CCB.EBA8AA02 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
It's not verifiable, but it is as useful in this = case as a=20 "user agent" string.  Not usefule formt he security perspective, = but has=20 some utility in application tracking.

From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew=20 Arnott
Sent: Saturday, July 03, 2010 12:16 PM
To: = Eran=20 Hammer-Lahav
Cc: OAuth WG = (oauth@ietf.org)
Subject: Re:=20 [OAUTH-WG] Security of user agent clients (WAS: End user authresponse=20 code-and-token's scope parameter)

(this sounds sarcastic, but I'm no being sarcastic... it's = a=20 serious question/challenge)...

Why not just remove the client_id parameter from the user-agent = flow?=20  It's absolutely meaningless to security.  It's only = perceivable=20 benefit is that the auth server can possible display to the user the = client=20 being authorized or the list of previously authorized clients. =  But=20 again, that's totally meaningless if not verified.

--
Andrew Arnott
"I [may] not agree with = what you=20 have to say, but I'll defend to the death your right to say it." - S. = G.=20 Tallentyre


On Sat, Jul 3, 2010 at 12:12 PM, Andrew = Arnott <andrewarnott@gmail.com>=20 wrote:
On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav = <eran@hueniverse.com> wrote:

You are=20 putting too much weight on the value of redirection URI = registration.=20 Since the same problem exists between the user-agent script and = the=20 server-side component used in the user-agent profile, anyone can = imitate=20 that flow. In most cases, the redirection URI will simply include = a script=20 that will pass the parameter to the *parent* window which = can be=20 anything. If the server-based page is an active page, it still = needs to=20 communicate with the user-agent, which again, can pretend to be=20 that.

Good point.  I wasn't imagining that far through it. =  Not to=20 deny that most redirection URLs may just return a straight script = that=20 passes it to the parent window, but that seems pretty irresponsible = to the=20 host that's doing it -- because of the enormous security hole it = opens up.=20  Some client is trusted enough to authorize (by the user and = auth=20 server), receives an access token it wasn't expecting, and then = blindly=20 forwards it onto whoever wants it.  Yikes.  I sure hope = these=20 access tokens have very limited scope (like, I'd prefer = none=20 myself).

I was about to describe how an active server could alleviate = that by=20 signing the original request using the state parameter, but I = realized I'm=20 solving a problem that the web server flow (or nowadays that the=20 authorization code mode as I guess it's called) already solves. =  So I=20 guess I just need to bite the bullet and accept that the user agent = flow is=20 totally insecure for web clients, and thus very special care = must be=20 taken to enable native clients without opening up the web client = hole.=20  

Sorry to sound so negative about it.  Enabling this = scenario seems=20 really important to me as well -- I just am against doing it when it = can't=20 be secured in some way.  Seriously... as is, once you authorize = any=20 client, you've authorized them all, including clients not even = running on=20 your computer.  I guess this answers how I was visiting a site = a few=20 days ago and was amazed that it knew who I was (via Facebook) and = was=20 displaying my name and photo when I never logged into the site. =  I was=20 shocked it knew who I was.  Enter living in Incognito mode from = now=20 = on.

------_=_NextPart_001_01CB1CCB.EBA8AA02-- From diogo.borges.almeida@gmail.com Tue Jul 6 01:53:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0063A67E2 for ; Tue, 6 Jul 2010 01:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iG5fdd5Gn5It for ; Tue, 6 Jul 2010 01:53:40 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B801A3A67A7 for ; Tue, 6 Jul 2010 01:53:39 -0700 (PDT) Received: by bwz7 with SMTP id 7so3909632bwz.31 for ; Tue, 06 Jul 2010 01:53:38 -0700 (PDT) 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=2WQ9q7XPotJrpMqh6Akr6nVx6BDGIvQi9U9BwK+NJRM=; b=J/jdDDkz2TNE5XZWbtKdDuLT6x+cTQR4ZNfhfiu82xrWujPwgFueVKPOw5RQbxjHli B1HrW8+CEDa6dZxAPstl4K46vQlqdOjTuJx6Pg94ayU1hBFuAJgVlrzQM8OzhVaUXJwo GnZ5iCJCNOzbLaTBS+KReW0ebpFMWSzoZbgrQ= 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=pJ/SVI/OMWkXFOTH4HMSOmYQ7Do/+gEKCVKZWc1luJMCF7+i4X2+hJLh4aLWIB5HZ9 NAtFLAHjjcvUZmks+8VCjxvgSodjqDGIs1XkVKqtEKz8BtgNjQcvYl9S16l3kwDAN3+E t82z2iS2Zn6Rn3wFzPx0hRmlD5XJ8TWuySqoc= Received: by 10.204.26.208 with SMTP id f16mr3409999bkc.71.1278406417571; Tue, 06 Jul 2010 01:53:37 -0700 (PDT) Received: from [172.20.10.57] ([62.28.14.10]) by mx.google.com with ESMTPS id y27sm22032276bkw.2.2010.07.06.01.53.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Jul 2010 01:53:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Diogo Almeida In-Reply-To: <60CEA1CE-0FF3-46F7-BC3E-A3BF75BE036B@gmail.com> Date: Tue, 6 Jul 2010 09:53:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <09B6A8A0-A72A-455A-881E-8B16FE753B15@gmail.com> References: <60CEA1CE-0FF3-46F7-BC3E-A3BF75BE036B@gmail.com> To: oauth@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [OAUTH-WG] Questions regarding -09 section 3.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 08:53:40 -0000 Sorry to repost this mail to the WG. However, we're still looking for = feedback on these two issues for our provider implementation. PS: There was a typo in my first question. Where it reads: "On section = 3.1, regarding the scope parameter" it should read: "On section 3.1, = regarding the code parameter". Best regards, Diogo Almeida On Jul 3, 2010, at 12:50 PM, Diogo Almeida wrote: > Good afternoon, >=20 > I would like to ask the WG two questions regarding -09 >=20 > 1) > On section 3.1, regarding the scope parameter, it reads: >=20 > code > REQUIRED if the response type is "token" or "code-and-token", = otherwise MUST NOT be included. The authorization code generated by the = authorization server. The authorization code SHOULD expire shortly after = it is issued. The authorization server MUST invalidate the authorization = code after a single usage. The authorization code is bound to the client = identifier and redirection URI. >=20 > Question: Is it a typo that the "code" parameter is REQUIRED if the = response type is "token" or "code-and-token", rather than "code" or = "code-and-token"? >=20 >=20 > 2) > Also in section 3.1 or -09, it's stated that the Authorization = Response contains the parameters: "code", "access_token", "expires_in", = "scope" and "state". >=20 > Question: Would it make sense to also include an OPTIONAL = "refresh_token" to make this response more in line with section 4.2. = Access Token Response. Or the intention behind the decision of not = returning a "refresh_token" here was to make it so that the = "access_token" cannot be refreshed this way? >=20 > Best regards, > Diogo Almeida From diogo.borges.almeida@gmail.com Tue Jul 6 01:59: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 2C4A63A67A7 for ; Tue, 6 Jul 2010 01:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ACHubRWhICh for ; Tue, 6 Jul 2010 01:59:33 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 241C63A6358 for ; Tue, 6 Jul 2010 01:59:32 -0700 (PDT) Received: by fxm1 with SMTP id 1so4789953fxm.31 for ; Tue, 06 Jul 2010 01:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=HuP681ELB4Hvk80NtRTTy8CDIGNFE2XpuZjVEtP8z+g=; b=omP0m6nFDRIJBvu9Fx5pV2T8fbOEzpMQzpQ3I1rQ3j0Kyt418Dfv5q+0UTgTd5dY90 8OvKjR3nV/fDghKJW1EIdirrUepWv/L3dxY2AnsdUYKbw8gh6KyYde7l9tPAKKjGiVV8 EEGL+2YsQiXHaBpntQXIB5HVq3YKpw7zJgoZI= 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=H7UVCNuJwqzOCWdL2unGv1x3IoQ1zU1y0UnIr2GF3KKpWnZif+nPEvz0Y/svmaA2vS /wbxlKF8+0UsC632RgXREIj2CGBNHW8HDyJh5fRG97AJj2VEmVq85WQB+RnbWbnh89Lt jERUxZuzRPUFqgmi5e0XWGk0z4f02a+Dkn46E= Received: by 10.86.70.16 with SMTP id s16mr3171319fga.52.1278406768667; Tue, 06 Jul 2010 01:59:28 -0700 (PDT) Received: from [172.20.10.57] ([62.28.14.10]) by mx.google.com with ESMTPS id 20sm11300477fax.8.2010.07.06.01.59.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Jul 2010 01:59:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-1--548144970 From: Diogo Almeida In-Reply-To: Date: Tue, 6 Jul 2010 09:59:25 +0100 Message-Id: <07265B40-2486-482B-970D-5CFDFB66B1DC@gmail.com> References: <402D29DB-A3F5-48C5-9654-543B7F6D6356@gmail.com> <4D3A5EF5-CC38-405A-85F7-7E24B957BA44@gmail.com> <21AF3452-B1AF-40CE-A72C-5923FEB0543C@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C6C1@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: David Recordon X-Mailer: Apple Mail (2.1081) Cc: "flatter@gmail.com" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Authorization Response "scope" parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 08:59:35 -0000 --Apple-Mail-1--548144970 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello David, Just a small note: if such change was made I believe it would also have = to be reflected on section 4.2 (draft 09), in order to have a coherent = scope parameter. Best regards, Diogo Almeida On Jul 5, 2010, at 5:46 PM, David Recordon wrote: > Seems like adding, "It's RECOMMENDED that this parameter be included = if the access grant's scope differs from the requested scope." would be = useful implementation advice in 3.1. >=20 >=20 > On Fri, Jul 2, 2010 at 9:27 AM, Eran Hammer-Lahav = wrote: > Scope is an optional feature of a protocol. The server is free to = express the granted scope in any way it deems appropriate (that is, omit = it, include it as requested by the client, specify another granted = scope). No changes are necessary. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf > > Of Diogo Almeida > > Sent: Friday, July 02, 2010 9:23 AM > > To: Marius Scurtescu > > Cc: flatter@gmail.com; oauth@ietf.org > > Subject: Re: [OAUTH-WG] Authorization Response "scope" parameter > > > > Hello Marius, > > > > Thanks for your feedback regarding this issue. > > > > You make a valid point, stating that the authorization server should = only send > > the scope if it differs from the requested one. However, I would = like to > > enclose two notes regarding that approach: > > > > * If I understand the 09 draft correctly, the omission of the = authorization > > response scope has no implicit meaning, thus a change to the spec = would still > > have to made > > > > * =46rom an authorization server implementer point of view, I find = that > > enforcing the server to explicitly take into account the requester's = scope > > removes ambiguity from the messages / flow without any significant > > overhead > > > > Best regards, > > Diogo Almeida > > > > > > On Jul 2, 2010, at 5:02 PM, Marius Scurtescu wrote: > > > > > If the scopes granted by the authz server are exactly the ones > > > requested by the client then I don't see the need for the authz = server > > > to send a scope parameter. > > > > > > I think the authz server should send the scope parameter if the > > > granted scopes are different from the requested ones, or if there = was > > > no scope parameter on the request. > > > > > > Marius > > > > > > > > > > > > On Fri, Jul 2, 2010 at 8:51 AM, Diogo Almeida > > > wrote: > > >> Good afternoon, > > >> > > >> We're in the process of implementing an open-source Ruby OAuth 2 > > (draft 09) server, which will be made available at > > http://github.com/aflatter/oauth2-ruby. > > >> > > >> During our draft 09 analysis we've noticed that the OPTIONAL = scope sent > > by the client in the Authorization Request is disconnected from the > > Authorization Response scope in a way that, in our opinion, makes it = hard for > > the client to know if his requested scope was met or not. > > >> > > >> For example, consider a scenario where a client issues an = authorization > > code request to the authorization server, including in that request = the scope > > "friends photos videos". However, the resource owner only authorizes = the > > access to the friends list, thus, in our opinion, the authorization = server MUST > > send an authorization response containing the code and the following = scope > > "friends". > > >> > > >> Also, should the authorization server wish to append other = scopes, it > > should be free to do so, per current draft specification. In that = regard, it > > would be possible for the response to have the following scope: = "friends > > extended_user_info". > > >> > > >> In light of this opinion, we enclose the following text change = request > > regarding draft 9 section 3.1 scope parameter: > > >> > > >> scope > > >> REQUIRED if it has been passed in the authorization = request, > > otherwise OPTIONAL. > > >> This parameter delimits the scope of the access token as = an > > unordered list of > > >> space-delimited strings, each adding an additional access = range to the > > requested > > >> scope. > > >> The value of the "scope" parameter is defined by the = authorization > > server and > > >> MUST take into account the "scope" requested in the = authorization > > request by setting the > > >> authorization response "scope" parameter to the values to = which the > > token grants access. > > >> Furthermore, the authorization server can add any other = values > > deemed necessary > > >> to determine response scope. > > >> > > >> Best regards, > > >> Diogo Almeida > > >> > > >> _______________________________________________ > > >> 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 --Apple-Mail-1--548144970 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Hello David,

Just a small note: if such change was made I believe it would also have to be reflected on section 4.2 (draft 09), in order to have a coherent scope parameter.

Best regards,
Diogo Almeida

On Jul 5, 2010, at 5:46 PM, David Recordon wrote:

Seems like adding, "It's RECOMMENDED that this parameter be included if the access grant's scope differs from the requested scope." would be useful implementation advice in 3.1.


On Fri, Jul 2, 2010 at 9:27 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Scope is an optional feature of a protocol. The server is free to express the granted scope in any way it deems appropriate (that is, omit it, include it as requested by the client, specify another granted scope). No changes are necessary.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Diogo Almeida
> Sent: Friday, July 02, 2010 9:23 AM
> To: Marius Scurtescu
> Cc: flatter@gmail.com; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Authorization Response "scope" parameter
>
> Hello Marius,
>
> Thanks for your feedback regarding this issue.
>
> You make a valid point, stating that the authorization server should only send
> the scope if it differs from the requested one. However, I would like to
> enclose two notes regarding that approach:
>
> * If I understand the 09 draft correctly, the omission of the authorization
> response scope has no implicit meaning, thus a change to the spec would still
> have to made
>
> * From an authorization server implementer point of view, I find that
> enforcing the server to explicitly take into account the requester's scope
> removes ambiguity from the messages / flow without any significant
> overhead
>
> Best regards,
> Diogo Almeida
>
>
> On Jul 2, 2010, at 5:02 PM, Marius Scurtescu wrote:
>
> > If the scopes granted by the authz server are exactly the ones
> > requested by the client then I don't see the need for the authz server
> > to send a scope parameter.
> >
> > I think the authz server should send the scope parameter if the
> > granted scopes are different from the requested ones, or if there was
> > no scope parameter on the request.
> >
> > Marius
> >
> >
> >
> > On Fri, Jul 2, 2010 at 8:51 AM, Diogo Almeida
> > <diogo.borges.almeida@gmail.com> wrote:
> >> Good afternoon,
> >>
> >> We're in the process of implementing an open-source Ruby OAuth 2
> (draft 09) server, which will be made available at
> http://github.com/aflatter/oauth2-ruby.
> >>
> >> During our draft 09 analysis we've noticed that the OPTIONAL scope sent
> by the client in the Authorization Request is disconnected from the
> Authorization Response scope in a way that, in our opinion, makes it hard for
> the client to know if his requested scope was met or not.
> >>
> >> For example, consider a scenario where a client issues an authorization
> code request to the authorization server, including in that request the scope
> "friends photos videos". However, the resource owner only authorizes the
> access to the friends list, thus, in our opinion, the authorization server MUST
> send an authorization response containing the code and the following scope
> "friends".
> >>
> >> Also, should the authorization server wish to append other scopes, it
> should be free to do so, per current draft specification. In that regard, it
> would be possible for the response to have the following scope: "friends
> extended_user_info".
> >>
> >> In light of this opinion, we enclose the following text change request
> regarding draft 9 section 3.1 scope parameter:
> >>
> >>   scope
> >>         REQUIRED if it has been passed in the authorization request,
> otherwise OPTIONAL.
> >>         This parameter delimits the scope of the access token as an
> unordered list of
> >>         space-delimited strings, each adding an additional access range to the
> requested
> >>         scope.
> >>         The value of the "scope" parameter is defined by the authorization
> server and
> >>         MUST take into account the "scope" requested in the authorization
> request by setting the
> >>         authorization response "scope" parameter to the values to which the
> token grants access.
> >>         Furthermore, the authorization server can add any other values
> deemed necessary
> >>         to determine response scope.
> >>
> >> Best regards,
> >> Diogo Almeida
> >>
> >> _______________________________________________
> >> 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-1--548144970-- From hank777@gmail.com Tue Jul 6 03:05:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0613A6823 for ; Tue, 6 Jul 2010 03:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI3dySepvAee for ; Tue, 6 Jul 2010 03:05:17 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id F38783A67E2 for ; Tue, 6 Jul 2010 03:05:16 -0700 (PDT) Received: by gyh3 with SMTP id 3so3172638gyh.31 for ; Tue, 06 Jul 2010 03:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=4AEIeqBYCCzKE9dx7n0LDQFfbA9QTAQb5zEpHF5vwzk=; b=Ox/bf+bz0PIXwM1HWqge6uqbFh33C5YvXN6KXuGvOKssybvaVAIAr1OurYPN3I+ta2 AH/b2dASyMTbsdTRj/KhEl59T2M2P8MsQznJfOv9TgeoJTaA1ZjZMiTNT/+QZeS18Sv4 2BhmgEhvl5V+ubhwyixgNGxyXoeU7qjjE4eQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=G5sB9pzdiMmGa5+zlxrcmvnaZyfsH38F3Z7wIjFgaDamDE8kEmFJWbZ6B78VbVFWpn TlZzn+rNd5+0rJsQAb01Tczsvu0I+MEhLHqBEjjKw4/xlip1u7eZV96Uef3sqhlGInvI P5xX+p5Mv+XPUWZXsu1jW2m0PFde9prTAepL8= MIME-Version: 1.0 Received: by 10.101.170.3 with SMTP id x3mr2808350ano.142.1278410716014; Tue, 06 Jul 2010 03:05:16 -0700 (PDT) Received: by 10.101.118.1 with HTTP; Tue, 6 Jul 2010 03:05:15 -0700 (PDT) Date: Tue, 6 Jul 2010 06:05:15 -0400 Message-ID: From: hank williams To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001636c92ac49aeb2c048ab530bf Subject: [OAUTH-WG] List security issue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 10:05:17 -0000 --001636c92ac49aeb2c048ab530bf Content-Type: text/plain; charset=ISO-8859-1 I just noticed that every month the list administration system sends out an email that includes the password to my account on this system. Obviously this is a huge security issue. I am a member of around fifteen lists and this is the only one that does this. I hope it can be resolved. Thanks. Hank -- blog: whydoeseverythingsuck.com --001636c92ac49aeb2c048ab530bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I just noticed that every month the list administration system sends out an= email that includes the password to my account on this system. Obviously t= his is a huge security issue. I am a member of around fifteen lists and thi= s is the only one that does this. I hope it can be resolved.

Thanks.
--001636c92ac49aeb2c048ab530bf-- From lvh@laurensvh.be Tue Jul 6 04:09:57 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617B43A68FC for ; Tue, 6 Jul 2010 04:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLuz+iKbghrw for ; Tue, 6 Jul 2010 04:09:56 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 4BA9E3A67B6 for ; Tue, 6 Jul 2010 04:09:55 -0700 (PDT) Received: by fxm1 with SMTP id 1so4934242fxm.31 for ; Tue, 06 Jul 2010 04:09:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.135.10 with SMTP id b10mr307390hbb.144.1278414594403; Tue, 06 Jul 2010 04:09:54 -0700 (PDT) Received: by 10.239.181.206 with HTTP; Tue, 6 Jul 2010 04:09:54 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Jul 2010 13:09:54 +0200 Message-ID: From: Laurens Van Houtven To: hank williams Content-Type: text/plain; charset=UTF-8 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] List security issue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 11:09:57 -0000 Um, this is reasonably common Mailman behavior (admittedly less common than the alternative), and the signup page warns you about it: You may enter a privacy password below. This provides only mild security, but should prevent others from messing with your subscription. Do not use a valuable password as it will occasionally be emailed back to you in cleartext. If this irks you, you can choose a random key so the password is useless for everything besides that list. There would be no escalation of privilege, since anyone accessing your email can already set *everything* related to the oauth@ietf.org mailing list. Cheers, Laurens From eran@hueniverse.com Tue Jul 6 07:04: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 EC24F3A686C for ; Tue, 6 Jul 2010 07:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 7sl--p-ZZw3h for ; Tue, 6 Jul 2010 07:04:18 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id C2BD63A67AE for ; Tue, 6 Jul 2010 07:04:17 -0700 (PDT) Received: (qmail 32427 invoked from network); 6 Jul 2010 14:04:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Jul 2010 14:04:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 6 Jul 2010 07:04:15 -0700 From: Eran Hammer-Lahav To: Diogo Almeida Date: Tue, 6 Jul 2010 07:03:22 -0700 Thread-Topic: [OAUTH-WG] Questions regarding -09 section 3.1 Thread-Index: AcsdFB4WvwCgJs0WRPCtoATXJx40SQ== Message-ID: <533787F7-0DD1-47A7-AB3A-9D64FF44EDFF@hueniverse.com> References: <60CEA1CE-0FF3-46F7-BC3E-A3BF75BE036B@gmail.com> In-Reply-To: <60CEA1CE-0FF3-46F7-BC3E-A3BF75BE036B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Questions regarding -09 section 3.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 14:04:19 -0000 On Jul 3, 2010, at 7:50, Diogo Almeida wro= te: > Good afternoon, >=20 > I would like to ask the WG two questions regarding -09 >=20 > 1) > On section 3.1, regarding the scope parameter, it reads: >=20 > code > REQUIRED if the response type is "token" or "code-and-token", otherwise M= UST NOT be included. The authorization code generated by the authorization = server. The authorization code SHOULD expire shortly after it is issued. Th= e authorization server MUST invalidate the authorization code after a singl= e usage. The authorization code is bound to the client identifier and redir= ection URI. >=20 > Question: Is it a typo that the "code" parameter is REQUIRED if the respo= nse type is "token" or "code-and-token", rather than "code" or "code-and-to= ken"? >=20 >=20 Yes. That's a typo.=20 > 2) > Also in section 3.1 or -09, it's stated that the Authorization Response c= ontains the parameters: "code", "access_token", "expires_in", "scope" and "= state". >=20 > Question: Would it make sense to also include an OPTIONAL "refresh_token"= to make this response more in line with section 4.2. Access Token Response= . Or the intention behind the decision of not returning a "refresh_token" h= ere was to make it so that the "access_token" cannot be refreshed this way? Refresh token is only returned when a client secret is present (or other au= thentication scheme).=20 EHL > Best regards, > Diogo Almeida > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From diogo.borges.almeida@gmail.com Tue Jul 6 07:06: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 4058D3A691B for ; Tue, 6 Jul 2010 07:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJdvnF2JI883 for ; Tue, 6 Jul 2010 07:06:26 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 827E43A686C for ; Tue, 6 Jul 2010 07:06:26 -0700 (PDT) Received: by fxm1 with SMTP id 1so5135349fxm.31 for ; Tue, 06 Jul 2010 07:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=1Cvagpa/5Bjs6sa2tHyAIdsCisCzRmAdl6v70hK/KFQ=; b=sZceTU/czqFRpri3ClVASpviXqw7oNCvH3c8YW2u1/37FbdxjzAeGNtUXlimKwP/eb FXTzGNvp81pUNwYEtM605OnDFwBz17ByY+LjUCzITM3b7CbQeTHTApOZqnhKAh6S4pDM 5TGh9gFBLJVdsDD56FqgLLGt3GzsguO9UqcLw= 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=Tb2cgFPjRDXR2pSLalMn4Q28SphiSmB2DMqj6i8ZndOObUbEAB0l0+PkRqkb/h1Yg/ qmVsII6wromQxWAmWm+BytE/8twAqLjg0GyzEQmB4eW+gQSt5UcRWKngZN0X3d8wfBvd cB4fVkb4Z9oKJJLXUbwLi6MOpAub1X+gPpneE= Received: by 10.223.104.77 with SMTP id n13mr4306353fao.24.1278425181822; Tue, 06 Jul 2010 07:06:21 -0700 (PDT) Received: from [172.20.10.57] ([62.28.14.10]) by mx.google.com with ESMTPS id b14sm11947100fab.43.2010.07.06.07.06.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Jul 2010 07:06:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Diogo Almeida In-Reply-To: <533787F7-0DD1-47A7-AB3A-9D64FF44EDFF@hueniverse.com> Date: Tue, 6 Jul 2010 15:06:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <764A1DD7-C7C2-4D9F-BF2F-5992F556C626@gmail.com> References: <60CEA1CE-0FF3-46F7-BC3E-A3BF75BE036B@gmail.com> <533787F7-0DD1-47A7-AB3A-9D64FF44EDFF@hueniverse.com> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1081) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Questions regarding -09 section 3.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 14:06:28 -0000 Thanks Eran, Best regards, Diogo Almeida On Jul 6, 2010, at 3:03 PM, Eran Hammer-Lahav wrote: >=20 >=20 >=20 >=20 > On Jul 3, 2010, at 7:50, Diogo Almeida = wrote: >=20 >> Good afternoon, >>=20 >> I would like to ask the WG two questions regarding -09 >>=20 >> 1) >> On section 3.1, regarding the scope parameter, it reads: >>=20 >> code >> REQUIRED if the response type is "token" or "code-and-token", = otherwise MUST NOT be included. The authorization code generated by the = authorization server. The authorization code SHOULD expire shortly after = it is issued. The authorization server MUST invalidate the authorization = code after a single usage. The authorization code is bound to the client = identifier and redirection URI. >>=20 >> Question: Is it a typo that the "code" parameter is REQUIRED if the = response type is "token" or "code-and-token", rather than "code" or = "code-and-token"? >>=20 >>=20 >=20 > Yes. That's a typo.=20 >=20 >> 2) >> Also in section 3.1 or -09, it's stated that the Authorization = Response contains the parameters: "code", "access_token", "expires_in", = "scope" and "state". >>=20 >> Question: Would it make sense to also include an OPTIONAL = "refresh_token" to make this response more in line with section 4.2. = Access Token Response. Or the intention behind the decision of not = returning a "refresh_token" here was to make it so that the = "access_token" cannot be refreshed this way? >=20 >=20 > Refresh token is only returned when a client secret is present (or = other authentication scheme).=20 >=20 > EHL >=20 >> Best regards, >> Diogo Almeida >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Tue Jul 6 11:10: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 6BCA93A683E for ; Tue, 6 Jul 2010 11:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmKMGHcW9clr for ; Tue, 6 Jul 2010 11:10:15 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 7967A3A67D4 for ; Tue, 6 Jul 2010 11:10:15 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o66IAGnQ029684 for ; Tue, 6 Jul 2010 14:10:16 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o66IAGNf029677; Tue, 6 Jul 2010 14:10:16 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Tue, 6 Jul 2010 14:10:16 -0400 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C567@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C528@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C567@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Tue, 6 Jul 2010 14:10:15 -0400 Message-ID: <1278439815.2445.8.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 18:10:16 -0000 > > When receiving an OAuth request MediaWiki will have two title parameters, > > the damage is already done. > > Yes, they might need to change their platform to support it. I'm ok with that. I think this is an unfortunate hubris of the spec-defining community here. For most people, if it comes down to "change my platform or don't support oauth", the answer is going to be "don't support oauth". -- Justin From eran@hueniverse.com Tue Jul 6 11:23:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD6D93A688A for ; Tue, 6 Jul 2010 11:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ic9W+r02MtOt for ; Tue, 6 Jul 2010 11:23:32 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 2D2D93A67A4 for ; Tue, 6 Jul 2010 11:23:32 -0700 (PDT) Received: (qmail 28954 invoked from network); 6 Jul 2010 18:23:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Jul 2010 18:23:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 6 Jul 2010 11:23:30 -0700 From: Eran Hammer-Lahav To: Justin Richer Date: Tue, 6 Jul 2010 11:23:29 -0700 Thread-Topic: [OAUTH-WG] register prefixes as opposed to full parameter names Thread-Index: AcsdNn4iCXzV8y1WR7C8HWb16/iAJwAAdbHA Message-ID: In-Reply-To: <1278439815.2445.8.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C858C2B136C16eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 18:23:33 -0000 --_000_C858C2B136C16eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Platforms change over time. These platforms are not designed with providing= APIs and web services in mind. They are also typically not capable of runn= ing over SSL (due to the self-hosted nature of most deployments). Using an = apache rewrite rules might be hard for some developers, but it is a good so= lution when there are issues with platform limitations. If there are actual requirements for using OAuth 2.0 with such systems, we = should discuss these, but it would be silly for us to architect our work ba= sed on the limitations of random platforms. EHL On 7/6/10 11:10 AM, "Justin Richer" wrote: > > When receiving an OAuth request MediaWiki will have two title parameter= s, > > the damage is already done. > > Yes, they might need to change their platform to support it. I'm ok with = that. I think this is an unfortunate hubris of the spec-defining community here. For most people, if it comes down to "change my platform or don't support oauth", the answer is going to be "don't support oauth". -- Justin --_000_C858C2B136C16eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] register prefixes as opposed to full parameter names<= /TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>Platforms change over time. These platforms are not designed with pro= viding APIs and web services in mind. They are also typically not capable o= f running over SSL (due to the self-hosted nature of most deployments). Usi= ng an apache rewrite rules might be hard for some developers, but it is a g= ood solution when there are issues with platform limitations.<BR> <BR> If there are actual requirements for using OAuth 2.0 with such systems, we = should discuss these, but it would be silly for us to architect our work ba= sed on the limitations of random platforms.<BR> <BR> EHL<BR> <BR> <BR> <BR> <BR> On 7/6/10 11:10 AM, "Justin Richer" <<a href=3D"jricher@mitre.= org">jricher@mitre.org</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>> > When receiving an OAuth request M= ediaWiki will have two title parameters,<BR> > > the damage is already done.<BR> ><BR> > Yes, they might need to change their platform to support it. I'm ok wi= th that.<BR> <BR> I think this is an unfortunate hubris of the spec-defining community<BR> here. For most people, if it comes down to "change my platform or don'= t<BR> support oauth", the answer is going to be "don't support oauth&qu= ot;.<BR> <BR>  -- Justin<BR> <BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C858C2B136C16eranhueniversecom_-- From andrewarnott@gmail.com Tue Jul 6 12:50:16 2010 Return-Path: <andrewarnott@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E07C3A693B for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 12:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvb3lZSdDqHh for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 12:50:11 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 131CF3A6816 for <oauth@ietf.org>; Tue, 6 Jul 2010 12:50:10 -0700 (PDT) Received: by qwe5 with SMTP id 5so2363920qwe.31 for <oauth@ietf.org>; Tue, 06 Jul 2010 12:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=H2KlW2/v7PSAQzlA+/qfoVu5TdJ8kTbZ4PFfJSJTnZo=; b=qI5oSj2hXhxBFaE0bEUkzjt3/KTmAekbjvPBpS9IVAJvOR8JWXT9dRSk9KxBqmYCOD 5yYQV5WELGmSrI847b15M/LvWijkMpr4ns11wiNmrj4h1+F4uvmxddSEsi8p0jCndVYU TvJSetLGVIpGxLxN2zkvRjNY45Hfw7inbstwI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=JQEwQBNEJsnA4A72P6+GnaF+/QtW85hlbWxNyLP0rX/BI6rC8ugytd156SXT/N3Jld aKWs+UNd21VHZslsdsgrCCTmXOdSbHjoYQo9bM+wfpHv4k4ycb5V2ha+CYBlslFpFuRf 8xfuj9IdsOhEYbCY68n+qV0gngx7XkA1HmPPE= Received: by 10.224.85.148 with SMTP id o20mr2805656qal.210.1278445808715; Tue, 06 Jul 2010 12:50:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.92.8 with HTTP; Tue, 6 Jul 2010 12:49:48 -0700 (PDT) In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6A0A@SNV-EXVS08.ds.corp.yahoo.com> References: <AANLkTik55pORyRWj9rBrV1e4cbPGHM7Zbb1_ySUwB-bH@mail.gmail.com> <AANLkTinhZ8cUlNzAtfJM2MVFkGod8zGb4GXQ8cLZ7qTS@mail.gmail.com> <AANLkTikWHWYKoXS_shws1mheYVtwSSPM4b2J6mMIE_H7@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTin5-GbdgXlvrws5UC60Plfh_tcpsODyHIoWw1mi@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTiky4opuiqF65cCZPyCdl46ReSt8wT9rDuufSPxB@mail.gmail.com> <AANLkTimlvQWeWzou4Q2flwjuK7i0InqFu099SrPFV60R@mail.gmail.com> <012AB2B223CB3F4BB846962876F47217059B6A0A@SNV-EXVS08.ds.corp.yahoo.com> From: Andrew Arnott <andrewarnott@gmail.com> Date: Tue, 6 Jul 2010 12:49:48 -0700 Message-ID: <AANLkTik5u25V8SFx-18LMO9WhFirm6Yra3HcDYBZ4gBF@mail.gmail.com> To: William Mills <wmills@yahoo-inc.com> Content-Type: multipart/alternative; boundary=00c09f8fe75f4b1826048abd5c62 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 06 Jul 2010 19:50:16 -0000 --00c09f8fe75f4b1826048abd5c62 Content-Type: text/plain; charset=ISO-8859-1 If we can agree that it is useless from a security perspective (and I think we agree on that by now), then an auth server must not ever issue an access token to a user agent client without interacting with the user (no "immediate" mode issuing of access tokens) so the user is aware that some anonymous client on the web page is trying to access their data, since there's no assurance whatsoever about which client that is, and whether the user trusts it. If anyone disagrees, please explain how you can justify it, in light of the fact that leaving it as-is means once one client is authorized, the whole world is authorized by just pretending to be that one client. It might as well be a "make my data public" switch at the resource server to authorize a client such that it gets an access token directly without a client secret. (Not the muddy the waters, but again, I know client secrets don't add value when the client is on an uncontrolled machine. Please don't let that technical hurdle stop you from justifying the status quo in draft 9 of the spec). -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Mon, Jul 5, 2010 at 10:27 PM, William Mills <wmills@yahoo-inc.com> wrote: > It's not verifiable, but it is as useful in this case as a "user agent" > string. Not usefule formt he security perspective, but has some utility in > application tracking. > > ------------------------------ > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Andrew Arnott > *Sent:* Saturday, July 03, 2010 12:16 PM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Security of user agent clients (WAS: End user > authresponse code-and-token's scope parameter) > > (this sounds sarcastic, but I'm no being sarcastic... it's a serious > question/challenge)... > > Why not just remove the client_id parameter from the user-agent flow? It's > absolutely meaningless to security. It's only perceivable benefit is that > the auth server can possible display to the user the client being authorized > or the list of previously authorized clients. But again, that's totally > meaningless if not verified. > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > > On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott <andrewarnott@gmail.com>wrote: > >> On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav <eran@hueniverse.com>wrote: >> >>> You are putting too much weight on the value of redirection URI >>> registration. Since the same problem exists between the user-agent script >>> and the server-side component used in the user-agent profile, anyone can >>> imitate that flow. In most cases, the redirection URI will simply include a >>> script that will pass the parameter to the **parent** window which can >>> be anything. If the server-based page is an active page, it still needs to >>> communicate with the user-agent, which again, can pretend to be that. >>> >> Good point. I wasn't imagining that far through it. Not to deny that >> most redirection URLs may just return a straight script that passes it to >> the parent window, but that seems pretty irresponsible to the host that's >> doing it -- because of the enormous security hole it opens up. Some client >> is trusted enough to authorize (by the user and auth server), receives an >> access token it wasn't expecting, and then blindly forwards it onto whoever >> wants it. Yikes. I sure hope these access tokens have *very* limited >> scope (like, I'd prefer none myself). >> >> I was about to describe how an active server could alleviate that by >> signing the original request using the state parameter, but I realized I'm >> solving a problem that the web server flow (or nowadays that the >> authorization code mode as I guess it's called) already solves. So I guess >> I just need to bite the bullet and accept that the user agent flow is *totally >> *insecure for web clients, and thus very special care must be taken to >> enable native clients without opening up the web client hole. >> >> Sorry to sound so negative about it. Enabling this scenario seems really >> important to me as well -- I just am against doing it when it can't be >> secured in some way. Seriously... as is, once you authorize any client, >> you've authorized them all, including clients not even running on your >> computer. I guess this answers how I was visiting a site a few days ago and >> was amazed that it knew who I was (via Facebook) and was displaying my name >> and photo when I never logged into the site. I was shocked it knew who I >> was. Enter living in Incognito mode from now on. >> > > --00c09f8fe75f4b1826048abd5c62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If we can agree that it is useless from a security perspective (and I think= we agree on that by now), then an auth server must not ever issue an acces= s token to a user agent client without interacting with the user (no "= immediate" mode issuing of access tokens) so the user is aware that so= me anonymous client on the web page is trying to access their data, since t= here's no assurance whatsoever about which client that is, and whether = the user trusts it.<div> <br></div><div>If anyone disagrees, please explain how you can justify it, = in light of the fact that leaving it as-is means once one client is authori= zed, the whole world is authorized by just pretending to be that one client= . =A0It might as well be a "make my data public" switch at the re= source server to authorize a client such that it gets an access token direc= tly without a client secret.</div> <div><br></div><div>(Not the muddy the waters, but again, I know client sec= rets don't add value when the client is on an uncontrolled machine. =A0= Please don't let that technical hurdle stop you from justifying the sta= tus quo in draft 9 of the spec).<br clear=3D"all"> --<br>Andrew Arnott<br>"I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre<br> <br><br><div class=3D"gmail_quote">On Mon, Jul 5, 2010 at 10:27 PM, William= Mills <span dir=3D"ltr"><<a href=3D"mailto:wmills@yahoo-inc.com">wmills= @yahoo-inc.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div> <div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" size=3D"2" fa= ce=3D"Arial">It's not verifiable, but it is as useful in this case as a= =20 "user agent" string.=A0 Not usefule formt he security perspective= , but has=20 some utility in application tracking.</font></span></div><br> <blockquote style=3D"border-left:#0000ff 2px solid;padding-left:5px;margin-= left:5px;margin-right:0px" dir=3D"ltr"> <div dir=3D"ltr" lang=3D"en-us" align=3D"left"> <hr> <font size=3D"2" face=3D"Tahoma"><div class=3D"im"><b>From:</b> <a href= =3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@ietf.org= </a>=20 [mailto:<a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth= -bounces@ietf.org</a>] <b>On Behalf Of </b>Andrew=20 Arnott<br></div><b>Sent:</b> Saturday, July 03, 2010 12:16 PM<br><b>To:</= b> Eran=20 Hammer-Lahav<br><b>Cc:</b> OAuth WG (<a href=3D"mailto:oauth@ietf.org" ta= rget=3D"_blank">oauth@ietf.org</a>)<br><b>Subject:</b> Re:=20 [OAUTH-WG] Security of user agent clients (WAS: End user authresponse=20 code-and-token's scope parameter)<br></font><br></div><div><div></div= ><div class=3D"h5"> <div></div>(this sounds sarcastic, but I'm no being sarcastic... it&#= 39;s a=20 serious question/challenge)... <div><br></div> <div>Why not just remove the client_id parameter from the user-agent flow= ?=20 =A0It's absolutely meaningless to security. =A0It's only perceiva= ble=20 benefit is that the auth server can possible display to the user the clie= nt=20 being authorized or the list of previously authorized clients. =A0But=20 again, that's totally meaningless if not verified.</div> <div><br clear=3D"all">--<br>Andrew Arnott<br>"I [may] not agree wit= h what you=20 have to say, but I'll defend to the death your right to say it."= - S. G.=20 Tallentyre<br><br><br> <div class=3D"gmail_quote">On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott= <span dir=3D"ltr"><<a href=3D"mailto:andrewarnott@gmail.com" target=3D"= _blank">andrewarnott@gmail.com</a>></span>=20 wrote:<br> <blockquote style=3D"border-left:#ccc 1px solid;margin:0px 0px 0px 0.8ex;= padding-left:1ex" class=3D"gmail_quote"> <div> <div class=3D"gmail_quote"> <div>On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav <span dir=3D"ltr= "><<a href=3D"mailto:eran@hueniverse.com" target=3D"_blank">eran@huenive= rse.com</a>></span> wrote:<br> <blockquote style=3D"border-left:#ccc 1px solid;margin:0px 0px 0px 0.8e= x;padding-left:1ex" class=3D"gmail_quote"> <div lang=3D"EN-US" vlink=3D"purple" link=3D"blue"> <div> <p class=3D"MsoNormal"><span style=3D"color:#1f497d;font-size:11pt">Y= ou are=20 putting too much weight on the value of redirection URI registration.= =20 Since the same problem exists between the user-agent script and the= =20 server-side component used in the user-agent profile, anyone can imit= ate=20 that flow. In most cases, the redirection URI will simply include a s= cript=20 that will pass the parameter to the *<b>parent</b>* window which can = be=20 anything. If the server-based page is an active page, it still needs = to=20 communicate with the user-agent, which again, can pretend to be=20 that.</span></p></div></div></blockquote></div> <div>Good point. =A0I wasn't imagining that far through it. =A0Not = to=20 deny that most redirection URLs may just return a straight script that= =20 passes it to the parent window, but that seems pretty irresponsible to = the=20 host that's doing it -- because of the enormous security hole it op= ens up.=20 =A0Some client is trusted enough to authorize (by the user and auth=20 server), receives an access token it wasn't expecting, and then bli= ndly=20 forwards it onto whoever wants it. =A0Yikes. =A0I sure hope these=20 access tokens have <i>very</i>=A0limited scope (like, I'd prefer no= ne=20 myself).</div> <div><br></div> <div>I was about to describe how an active server could alleviate that = by=20 signing the original request using the state parameter, but I realized = I'm=20 solving a problem that the web server flow (or nowadays that the=20 authorization code mode as I guess it's called) already solves. =A0= So I=20 guess I just need to bite the bullet and accept that the user agent flo= w is=20 <i>totally </i>insecure for web clients, and thus very special care mus= t be=20 taken to enable native clients without opening up the web client hole.= =20 =A0</div> <div><br></div> <div>Sorry to sound so negative about it. =A0Enabling this scenario see= ms=20 really important to me as well -- I just am against doing it when it ca= n't=20 be secured in some way. =A0Seriously... as is, once you authorize any= =20 client, you've authorized them all, including clients not even runn= ing on=20 your computer. =A0I guess this answers how I was visiting a site a few= =20 days ago and was amazed that it knew who I was (via Facebook) and was= =20 displaying my name and photo when I never logged into the site. =A0I wa= s=20 shocked it knew who I was. =A0Enter living in Incognito mode from now= =20 on.</div></div></div></blockquote></div><br></div></div></div></blockqu= ote></div> </blockquote></div><br></div> --00c09f8fe75f4b1826048abd5c62-- From wmills@yahoo-inc.com Tue Jul 6 13:00:43 2010 Return-Path: <wmills@yahoo-inc.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016E83A6899 for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 13:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.431 X-Spam-Level: X-Spam-Status: No, score=-17.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWkdxpopNe3I for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 13:00:41 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id EBAFC3A69DE for <oauth@ietf.org>; Tue, 6 Jul 2010 13:00:41 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o66JxVux020066; Tue, 6 Jul 2010 12:59:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=2qtdXXsmDf/NRY4hqMmA8MqS041ooyiQFFzIac6ovxHAhczHOnyNBzeW7iL1MxNB Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 12:59:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Jul 2010 12:59:30 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6A5F@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <1278439815.2445.8.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] register prefixes as opposed to full parameter names Thread-Index: AcsdNq1xsYDYUUHCQxacatk1i4M0UwADwIlA References: <AANLkTin7zWi7m_evTgI49JKXLPuVqYBFlCR8CtSYRKDM@mail.gmail.com><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4E2@P3PW5EX1MB01.EX1.SECURESERVER.NET><AANLkTik_f9MRWIK4kZ3c5pANtPloOsxyzYeL6bqMFhbs@mail.gmail.com><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C528@P3PW5EX1MB01.EX1.SECURESERVER.NET><AANLkTilrV6thlDrCx1yVVtpRqYWd7A4wAn6kCrwCO6T6@mail.gmail.com><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C567@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1278439815.2445.8.camel@localhost.localdomain> From: "William Mills" <wmills@yahoo-inc.com> To: "Justin Richer" <jricher@mitre.org>, "Eran Hammer-Lahav" <eran@hueniverse.com> X-OriginalArrivalTime: 06 Jul 2010 19:59:31.0596 (UTC) FILETIME=[BFAD84C0:01CB1D45] Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 06 Jul 2010 20:00:43 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Justin Richer > Sent: Tuesday, July 06, 2010 11:10 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] register prefixes as opposed to full=20 > parameter names >=20 > > > When receiving an OAuth request MediaWiki will have two title=20 > > > parameters, the damage is already done. > >=20 > > Yes, they might need to change their platform to support=20 > it. I'm ok with that. >=20 > I think this is an unfortunate hubris of the spec-defining=20 > community here. For most people, if it comes down to "change=20 +1 > my platform or don't support oauth", the answer is going to=20 > be "don't support oauth".=20 >=20 > -- Justin >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Tue Jul 6 13:03:11 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08943A695F for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 13:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.306, 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 hPvOmvOnCyPL for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 13:03:09 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 104E83A690E for <oauth@ietf.org>; Tue, 6 Jul 2010 13:03:08 -0700 (PDT) Received: (qmail 20027 invoked from network); 6 Jul 2010 20:03:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Jul 2010 20:03:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 6 Jul 2010 13:03:09 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Andrew Arnott <andrewarnott@gmail.com>, William Mills <wmills@yahoo-inc.com> Date: Tue, 6 Jul 2010 13:03:08 -0700 Thread-Topic: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) Thread-Index: AcsdRHKFvfshUZY/RCOQqJQGZcIYCgAAc4n7 Message-ID: <C858DA0C.36C35%eran@hueniverse.com> In-Reply-To: <AANLkTik5u25V8SFx-18LMO9WhFirm6Yra3HcDYBZ4gBF@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C858DA0C36C35eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 06 Jul 2010 20:03:11 -0000 --_000_C858DA0C36C35eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are known issues with using cookies and other passive authentication = measures, and we should document them. However, this all depends on the sec= urity needs of the service, and these patterns are already deployed in serv= ices such as FB. It would be useful to find out how they address these conc= erns. EHL On 7/6/10 12:49 PM, "Andrew Arnott" <andrewarnott@gmail.com> wrote: If we can agree that it is useless from a security perspective (and I think= we agree on that by now), then an auth server must not ever issue an acces= s token to a user agent client without interacting with the user (no "immed= iate" mode issuing of access tokens) so the user is aware that some anonymo= us client on the web page is trying to access their data, since there's no = assurance whatsoever about which client that is, and whether the user trust= s it. If anyone disagrees, please explain how you can justify it, in light of the= fact that leaving it as-is means once one client is authorized, the whole = world is authorized by just pretending to be that one client. It might as = well be a "make my data public" switch at the resource server to authorize = a client such that it gets an access token directly without a client secret= . (Not the muddy the waters, but again, I know client secrets don't add value= when the client is on an uncontrolled machine. Please don't let that tech= nical hurdle stop you from justifying the status quo in draft 9 of the spec= ). -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre On Mon, Jul 5, 2010 at 10:27 PM, William Mills <wmills@yahoo-inc.com> wrote= : It's not verifiable, but it is as useful in this case as a "user agent" str= ing. Not usefule formt he security perspective, but has some utility in ap= plication tracking. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Andrew Arnott Sent: Saturday, July 03, 2010 12:16 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth= response code-and-token's scope parameter) (this sounds sarcastic, but I'm no being sarcastic... it's a serious quest= ion/challenge)... Why not just remove the client_id parameter from the user-agent flow? It'= s absolutely meaningless to security. It's only perceivable benefit is th= at the auth server can possible display to the user the client being autho= rized or the list of previously authorized clients. But again, that's tot= ally meaningless if not verified. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death= your right to say it." - S. G. Tallentyre On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott <andrewarnott@gmail.com> wr= ote: On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav <eran@hueniverse.com> wro= te: You are putting too much weight on the value of redirection URI registrati= on. Since the same problem exists between the user-agent script and the s= erver-side component used in the user-agent profile, anyone can imitate th= at flow. In most cases, the redirection URI will simply include a script t= hat will pass the parameter to the *parent* window which can be anything. = If the server-based page is an active page, it still needs to communicate = with the user-agent, which again, can pretend to be that. Good point. I wasn't imagining that far through it. Not to deny that mos= t redirection URLs may just return a straight script that passes it to the= parent window, but that seems pretty irresponsible to the host that's doi= ng it -- because of the enormous security hole it opens up. Some client i= s trusted enough to authorize (by the user and auth server), receives an a= ccess token it wasn't expecting, and then blindly forwards it onto whoever= wants it. Yikes. I sure hope these access tokens have very limited scop= e (like, I'd prefer none myself). I was about to describe how an active server could alleviate that by signi= ng the original request using the state parameter, but I realized I'm solv= ing a problem that the web server flow (or nowadays that the authorization= code mode as I guess it's called) already solves. So I guess I just need= to bite the bullet and accept that the user agent flow is totally insecur= e for web clients, and thus very special care must be taken to enable nati= ve clients without opening up the web client hole. Sorry to sound so negative about it. Enabling this scenario seems really = important to me as well -- I just am against doing it when it can't be sec= ured in some way. Seriously... as is, once you authorize any client, you'= ve authorized them all, including clients not even running on your compute= r. I guess this answers how I was visiting a site a few days ago and was = amazed that it knew who I was (via Facebook) and was displaying my name an= d photo when I never logged into the site. I was shocked it knew who I wa= s. Enter living in Incognito mode from now on. --_000_C858DA0C36C35eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [OAUTH-WG] Security of user agent clients (WAS: End user  a= uthresponse code-and-token's scope parameter) There are known issues with using cookies and other passive authentic= ation measures, and we should document them. However, this all depends on t= he security needs of the service, and these patterns are already deployed i= n services such as FB. It would be useful to find out how they address thes= e concerns.

EHL


On 7/6/10 12:49 PM, "Andrew Arnott" <andrewarnott@gmail.com> wrote:

If we can agree that it is useless from a s= ecurity perspective (and I think we agree on that by now), then an auth ser= ver must not ever issue an access token to a user agent client without inte= racting with the user (no "immediate" mode issuing of access toke= ns) so the user is aware that some anonymous client on the web page is tryi= ng to access their data, since there's no assurance whatsoever about which = client that is, and whether the user trusts it.

If anyone disagrees, please explain how you can justify it, in light of the= fact that leaving it as-is means once one client is authorized, the whole = world is authorized by just pretending to be that one client. =A0It might a= s well be a "make my data public" switch at the resource server t= o authorize a client such that it gets an access token directly without a c= lient secret.

(Not the muddy the waters, but again, I know client secrets don't add value= when the client is on an uncontrolled machine. =A0Please don't let that te= chnical hurdle stop you from justifying the status quo in draft 9 of the sp= ec).
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the d= eath your right to say it." - S. G. Tallentyre


On Mon, Jul 5, 2010 at 10:27 PM, William Mills <wmills@yahoo-inc.com> wrote:
It's not verifiable, but it is as useful in this= case as a "user agent" string.=A0 Not usefule formt he security = perspective, but has some utility in application tracking.


 

From: oauth-bounces@ietf.org  [mailto:oauth-bounces@ietf.org] On Beha= lf Of Andrew  Arnott
Sent: Saturday, July 03, 2010 12:16 PM
To: Eran  Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re:  [OAUTH-WG] Security of user agent clients (WAS: E= nd user authresponse  code-and-token's scope parameter)

 
(this sounds sarcastic, but I'm no being sarcastic... it's a  serious = question/challenge)...

 
Why not just remove the client_id parameter from the user-agent flow?  = ;=A0It's absolutely meaningless to security. =A0It's only perceivable  = ;benefit is that the auth server can possible display to the user the clien= t  being authorized or the list of previously authorized clients. =A0B= ut  again, that's totally meaningless if not verified.
 

--
Andrew Arnott
"I [may] not agree with what you  have to say, but I'll defend to= the death your right to say it." - S. G.  Tallentyre


 
On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott <andrewarnott@gmail.com>  wrote:
 

 
 
On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
 

 
 

You are  putting too much weight on the value = of redirection URI registration.  Since the same problem exists betwee= n the user-agent script and the  server-side component used in the use= r-agent profile, anyone can imitate  that flow. In most cases, the red= irection URI will simply include a script  that will pass the paramete= r to the *parent* window which can be  anything. If the server-= based page is an active page, it still needs to  communicate with the = user-agent, which again, can pretend to be  that.

Good point. =A0I wasn't imagining that far through it. =A0Not to  deny= that most redirection URLs may just return a straight script that  pa= sses it to the parent window, but that seems pretty irresponsible to the &n= bsp;host that's doing it -- because of the enormous security hole it opens = up.  =A0Some client is trusted enough to authorize (by the user and au= th  server), receives an access token it wasn't expecting, and then bl= indly  forwards it onto whoever wants it. =A0Yikes. =A0I sure hope the= se  access tokens have very=A0limited scope (like, I'd prefer n= one  myself).
 

 
I was about to describe how an active server could alleviate that by  = signing the original request using the state parameter, but I realized I'm =  solving a problem that the web server flow (or nowadays that the &nbs= p;authorization code mode as I guess it's called) already solves. =A0So I &= nbsp;guess I just need to bite the bullet and accept that the user agent fl= ow is  totally insecure for web clients, and thus very special = care must be  taken to enable native clients without opening up the we= b client hole.  =A0
 

 
Sorry to sound so negative about it. =A0Enabling this scenario seems  = really important to me as well -- I just am against doing it when it can't =  be secured in some way. =A0Seriously... as is, once you authorize any=  client, you've authorized them all, including clients not even runni= ng on  your computer. =A0I guess this answers how I was visiting a sit= e a few  days ago and was amazed that it knew who I was (via Facebook)= and was  displaying my name and photo when I never logged into the si= te. =A0I was  shocked it knew who I was. =A0Enter living in Incognito = mode from now  on.



--_000_C858DA0C36C35eranhueniversecom_-- From beaton@google.com Tue Jul 6 14:23: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 3C6233A6987 for ; Tue, 6 Jul 2010 14:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.377 X-Spam-Level: X-Spam-Status: No, score=-103.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI0XXZbiud6f for ; Tue, 6 Jul 2010 14:23:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 476E53A6953 for ; Tue, 6 Jul 2010 14:23:28 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o66LNTXv004975 for ; Tue, 6 Jul 2010 14:23:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278451410; bh=725GfFkm0o2aQ/PQ/Z4ApYsQqA8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Yc74pTyGRu1SpHdtRyP2n/fYG0W/tG+NXtBKjoeFxGDlfbIZnPiaIDibnzGm6nKCH 8jxxGfC7Atnlz0aA0dT+A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=IkGRzXAlpuAzxyldiZuoivHrl80WNnXyd6aTY0i11H8A02LHyJcmRcZg1Atayy1E/ Vt6IjRtX377yCVCmuBzKw== Received: from pxi18 (pxi18.prod.google.com [10.243.27.18]) by hpaq14.eem.corp.google.com with ESMTP id o66LNRCH017274 for ; Tue, 6 Jul 2010 14:23:28 -0700 Received: by pxi18 with SMTP id 18so4837280pxi.18 for ; Tue, 06 Jul 2010 14:23:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.162.4 with SMTP id k4mr4526840wfe.192.1278451407207; Tue, 06 Jul 2010 14:23:27 -0700 (PDT) Received: by 10.142.187.19 with HTTP; Tue, 6 Jul 2010 14:23:27 -0700 (PDT) In-Reply-To: <39DE4E99-6DB3-4FBA-B78C-B2AB2B162221@facebook.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <39DE4E99-6DB3-4FBA-B78C-B2AB2B162221@facebook.com> Date: Tue, 6 Jul 2010 14:23:27 -0700 Message-ID: From: Brian Eaton To: Luke Shepard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 21:23:30 -0000 On Tue, Jun 22, 2010 at 11:00 PM, Luke Shepard wrot= e: > Two points: > > 1/ I agree that it can be onerous for clients to host web pages. It's not= a matter of expense but of complexity. > > BUT > > 2/ As we discussed previously in our in-person meeting, this should be ha= ndled by a different endpoint, and not be the responsibility for the provid= er. If Google wishes to support this for their desktop apps, then it should= provide an endpoint that handles the OAuth response and puts it in the . I can say that Facebook has no interest in supporting this hack on th= e server side, but clients that want it can use their own html file that do= es it for them. > > For example, for Javascript web apps it is a pain to host a cross-domain = receiver file. So we host one on behalf of developers (called xd_proxy.php)= . But it is not part of our server-side logic. > > If you want to write a spec for that, then great, but the hack do= es not belong in the main spec. Luke - A couple of questions for you. Question #1: In another thread, you mentioned "We require either pre-registration of the callback URL, or that the app uses a standard redirect URL on Facebook.com (which could only be used by a desktop app)." It sounds like both Google and Facebook have needed to provide a standard way for desktop applications to receive callback URLs, and that we've both opted to do so by hosting a page on our own site. What approach does your callback URL use for passing the authorization code down to the desktop app? And do you see value in standardizing that approach? (We settled on the <title> hack because it was very portable. But it's pretty ugly, and we'd love something better.) Question #2: most of the installed app developers we talk to ask how they can provide some sort of display name for their application, both on the approval page and on the revocation page. Do you see the same requirement, and if so how do you meet it? Cheers, Brian From lshepard@facebook.com Tue Jul 6 17:38:29 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E0B3A6781 for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 17:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhc+crDykltc for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 17:38:27 -0700 (PDT) Received: from mx-out.facebook.com (outmail014.snc1.tfbnw.net [69.63.178.173]) by core3.amsl.com (Postfix) with ESMTP id 584803A677C for <oauth@ietf.org>; Tue, 6 Jul 2010 17:38:27 -0700 (PDT) Received: from [10.18.255.124] ([10.18.255.124:8230] helo=mail.thefacebook.com) by mta014.snc1.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 44/FC-09289-38CC33C4; Tue, 06 Jul 2010 17:38:28 -0700 Received: from sc-hub06.TheFacebook.com (192.168.18.83) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.694.1; Tue, 6 Jul 2010 17:38:27 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Tue, 6 Jul 2010 17:38:27 -0700 From: Luke Shepard <lshepard@facebook.com> To: Brian Eaton <beaton@google.com> Date: Tue, 6 Jul 2010 17:38:40 -0700 Thread-Topic: [OAUTH-WG] native app support (was: Next draft) Thread-Index: AcsdbLZ+m4179b5GTqyzuo541Mlv+w== Message-ID: <BCA3B4DF-443D-4CBD-8746-ED52EDCF6A11@facebook.com> References: <AANLkTikkG3T_DYKhjMbyYayi7SzZel3RJXFSguxq7SSZ@mail.gmail.com> <AANLkTilycD2urJZqbP8HaRcqUQ6bM30WAzy4c4VOmLql@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTinj6wsniocBB45Ul0P5WNsAjktz-p0antXpkyUX@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTilM3NSD0BLQk5rz5UWxsudTHSBmMbDcwmcztcVb@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimykXBFhoAW4A3CY_GEc-v3I21SvKGKP08MjsX3@mail.gmail.com> <39DE4E99-6DB3-4FBA-B78C-B2AB2B162221@facebook.com> <AANLkTimhCxbD-bRWx9nq8zN08--rAGXwYwsdFHIGAHnr@mail.gmail.com> In-Reply-To: <AANLkTimhCxbD-bRWx9nq8zN08--rAGXwYwsdFHIGAHnr@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 00:38:30 -0000 Responses below. On Jul 6, 2010, at 2:23 PM, Brian Eaton wrote: > On Tue, Jun 22, 2010 at 11:00 PM, Luke Shepard <lshepard@facebook.com> wr= ote: >> Two points: >>=20 >> 1/ I agree that it can be onerous for clients to host web pages. It's no= t a matter of expense but of complexity. >>=20 >> BUT >>=20 >> 2/ As we discussed previously in our in-person meeting, this should be h= andled by a different endpoint, and not be the responsibility for the provi= der. If Google wishes to support this for their desktop apps, then it shoul= d provide an endpoint that handles the OAuth response and puts it in the <t= itle>. I can say that Facebook has no interest in supporting this hack on t= he server side, but clients that want it can use their own html file that d= oes it for them. >>=20 >> For example, for Javascript web apps it is a pain to host a cross-domain= receiver file. So we host one on behalf of developers (called xd_proxy.php= ). But it is not part of our server-side logic. >>=20 >> If you want to write a spec for that, then great, but the <title> hack d= oes not belong in the main spec. >=20 > Luke - >=20 > A couple of questions for you. >=20 > Question #1: In another thread, you mentioned "We require either > pre-registration of the callback URL, or that the app uses a standard > redirect URL on Facebook.com (which could only be used by a desktop > app)." >=20 > It sounds like both Google and Facebook have needed to provide a > standard way for desktop applications to receive callback URLs, and > that we've both opted to do so by hosting a page on our own site. >=20 > What approach does your callback URL use for passing the authorization > code down to the desktop app? We suggest developers use the user-agent flow, and retrieve the access toke= n after the fragment in the URL. We include links for .NET, Adobe Air, and = Objective C libraries. We haven't really run into issues with desktop apps = for which this is not possible (to my knowledge). http://developers.facebook.com/docs/authentication/desktop > And do you see value in standardizing that approach? You mentioned that there were desktop apps that aren't able to read the URL= values, but which can read the <title> value of apps - I know both Yahoo a= nd Google mentioned this. If you can show that this type of app is a common= scenario, then I can see some value in making it widespread. For now I hav= en't really seen a lot of examples of this in the wild such that it's worth= standardizing. One way to standardize this would be to host a file on a common domain - in= itially probably something like google.com, and then later perhaps a file o= n oauth.org or somewhere. It could use Javascript or server-side logic to i= ntercept the access token and display it in the <title>. Providers would ne= ed to accept redirect_uri values that contain that well known URL.=20 But it is much easier for a provider to just say "Oh, you're using oauth.or= g/desktoptitleauth.html? okay" than it is to implement the desktop title tr= ick themselves. > (We settled on the <title> hack because it was very portable. But > it's pretty ugly, and we'd love something better.) >=20 >=20 > Question #2: most of the installed app developers we talk to ask how > they can provide some sort of display name for their application, both > on the approval page and on the revocation page. Do you see the same > requirement, and if so how do you meet it? We don't allow unregistered applications. When an app registers their clien= t_id, they can specify a name and multiple sizes of icons. From yarong@microsoft.com Tue Jul 6 17:45:32 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F273A677C for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 17:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI1TcX+njuhU for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 17:45:31 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 195903A6359 for <oauth@ietf.org>; Tue, 6 Jul 2010 17:45:31 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 6 Jul 2010 17:45:35 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.44]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0160.007; Tue, 6 Jul 2010 17:45:33 -0700 From: Yaron Goland <yarong@microsoft.com> To: "Manger, James H" <James.H.Manger@team.telstra.com>, "oauth@ietf.org" <oauth@ietf.org> Thread-Topic: Proposal for text for section 2 Thread-Index: AcsUm7O3+LYTofkOQ6CsKuFeuynp2ACcJnPgAAxyEYAAH/FooAAMQp/wADFXrDAAAfH0QAEdXNSA Date: Wed, 7 Jul 2010 00:45:34 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C5F980EC4@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C579D0F31@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265A5FC9D@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C579D20CB@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265B7E872@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C579D76A1@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265CBC110@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11265CBC110@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for text for section 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 00:45:32 -0000 James, in theory I agree with you that we should use the authorization head= er. Unfortunately the reality of how implementations work prevent that as a= viable option. So for corporate scenarios where we need SAML we will have = to put the parameters into the request body. I do not see a viable way to s= tandardize that outside the context of a particular protocol since it requi= res using the request body which is owned by each protocol. So we will have= to extend OAuth directly to support this usage. It is of course the workin= g group's choice if they want to include the mechanism directly in the OAut= h spec or as an extension.=20 As for the distinction between client assertion/client assertion type and a= ssertion/assertion type it is identical to the difference between client id= /client secret and username/password. Thanks, Yaron > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Wednesday, June 30, 2010 9:18 PM > To: Yaron Goland; oauth@ietf.org > Subject: RE: Proposal for text for section 2 >=20 > Yaron, >=20 > > how can you ding client assertions credentials for doing exactly what c= lient > basic credentials do? >=20 > I don't like client basic credentials in request bodies either. We should= ditch > that as well. I am sure I have dinged it in the past. It offers too littl= e benefit > for the cost of confusing APIs (& code) by mixing the content and > authentication. And you lose a well-established discovery method: a > response with WWW-Authenticate: BASIC .... >=20 > At least with basic credentials they can fit in a URI. Consequently, they= don't > prevent GET, HEAD, or DELETE requests, or even non-form PUT and POST > requests in an API. Plus the Authorization header equivalent approach > always works as well. > [You can almost consider an "endpoint with client_id and client_secret" a= s a > single base URI for the API -- and almost pretend that it doesn't comprom= ise > the HTTP model.] >=20 >=20 > > How about we edit the client assertion proposal to include the ability = to put > assertions both in the HTTP authorization header as well as in the body? = Then > the assertion proposal will be 100% equivalent to the existing basic > credentials proposal. >=20 > It is hardly 100% equivalent when the header option will fail in some cas= es > (large assertions), and the other option fails for GETs, HEADs, DELETEs, = and > non-form requests. >=20 >=20 > I would like OAuth2 to say: "The token API will often require client auth= ; a > service MAY support any auth mechanisms; BASIC is a recommended > mechanism; BASIC MUST be supported if the service issues shared secrets t= o > clients". > Using a client assertion would fit right in if it could be defined as a s= tandalone > HTTP auth mechanism (even with a option to use form params for POSTs of > forms). This would be best as its own standalone spec. >=20 > If such a spec gets support (despite sometimes failing for non-POST or no= n- > form requests), we are done. If such a spec isn't supported it suggests w= e > should define a specific API that accepts client assertions, instead of a= n > "orthogonal" auth mechanism (still best in its own spec). >=20 >=20 > P.S. When are client_assertion/client_assertion_type used, as opposed to > assertion/assertion_type? It is not clear to me from the existing and > proposed spec text. I don't think the OAuth2 spec has enough context for > the assertion parts. It would be better outside the OAuth2 spec, where mo= re > details could be provided about how it hooks up with the rest of a claims= - > based system. >=20 > -- > James Manger From mscurtescu@google.com Tue Jul 6 19:43:06 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB203A6967 for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 19:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[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 iwsBlFhpd-NH for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 19:43:05 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1939E3A68F1 for <oauth@ietf.org>; Tue, 6 Jul 2010 19:43:04 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id o672h6r2014756 for <oauth@ietf.org>; Tue, 6 Jul 2010 19:43:06 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278470587; bh=RGLhgemj7OAlpKrJ+9TYp1EDZtI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=xpV9bVKh7gYF/tEMz3AHJfn70uEhMvEbjS0MBY8/Ymk5z+taugI/0RhtsYcndkEuS O4E/KMipa5Xb8hIpVo8Ow== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=F6YjWTrM6dn53MLNDEV+eXWSUph9/j6Mr5RIonsh6p5EF4XBrBFZJgOWz6iYGg+/2 xAP5jvcp7pkqD2Iot5hVA== Received: from gxk6 (gxk6.prod.google.com [10.202.11.6]) by kpbe15.cbf.corp.google.com with ESMTP id o672gb1B012629 for <oauth@ietf.org>; Tue, 6 Jul 2010 19:43:05 -0700 Received: by gxk6 with SMTP id 6so3028730gxk.16 for <oauth@ietf.org>; Tue, 06 Jul 2010 19:43:04 -0700 (PDT) Received: by 10.100.55.17 with SMTP id d17mr7102089ana.217.1278470584202; Tue, 06 Jul 2010 19:43:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Tue, 6 Jul 2010 19:42:44 -0700 (PDT) In-Reply-To: <AANLkTintGxCh-Pk1Wd5nubBm8qM96ZUb3TQ5Iuf0GQ07@mail.gmail.com> References: <AANLkTintGxCh-Pk1Wd5nubBm8qM96ZUb3TQ5Iuf0GQ07@mail.gmail.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 6 Jul 2010 19:42:44 -0700 Message-ID: <AANLkTimfbRxKhUSV-Ydz_YGv-aE1VaQGgIFsdJ7qgut2@mail.gmail.com> To: Andrew Arnott <andrewarnott@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Draft 9, Section 4.1.1 missing several parameters X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 02:43:06 -0000 How the client authenticates itself is covered in section 2, and client_id plus client_secret in 2.1. The first paragraph of section 4 mentions this in a general way, but I think an explicit pointer to section 2 would help. Regarding the last paragraph of 4.1.1, since it explains the example, it probably makes sense to mention client id and secret. Again, a direct reference to 2.1 may help. Marius On Sat, Jul 3, 2010 at 2:28 PM, Andrew Arnott <andrewarnott@gmail.com> wrote: > Section 4.1.1, which deals with requesting an access token using an > authorization code, doesn't list the client_id and client_secret parameters > at all, yet mentions verifying them in paragraph form, and they are included > in the example. > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From uidude@google.com Tue Jul 6 21:17:49 2010 Return-Path: <uidude@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 831E43A6970 for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 21:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.376 X-Spam-Level: X-Spam-Status: No, score=-103.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 g3olJ7RjsWAh for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 21:17:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 635F03A696F for <oauth@ietf.org>; Tue, 6 Jul 2010 21:17:44 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o674HkTJ021254 for <oauth@ietf.org>; Tue, 6 Jul 2010 21:17:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278476266; bh=w7mNdFtCw8OLPLiWOmeSf/HUUAs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=euYclGrUWPHxs5Z+DQEvZAvwsy0C2lHNJtJh/ac0EoHaHehlD45gZ0iz1izcolh03 sLJH9i70epndcAuNbF71w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=mibs/5C6h9K/KiTHT9dQuS9lJ+9Ne9AVfeV55E9OP0uV8wmmIZsEnmpEbfWf63Lzm tPCDeZpFpkcr8NNBWvtYw== Received: from qyk30 (qyk30.prod.google.com [10.241.83.158]) by kpbe14.cbf.corp.google.com with ESMTP id o674HiOv015380 for <oauth@ietf.org>; Tue, 6 Jul 2010 21:17:45 -0700 Received: by qyk30 with SMTP id 30so2647808qyk.6 for <oauth@ietf.org>; Tue, 06 Jul 2010 21:17:44 -0700 (PDT) Received: by 10.224.44.65 with SMTP id z1mr2809603qae.114.1278476264394; Tue, 06 Jul 2010 21:17:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.211 with HTTP; Tue, 6 Jul 2010 21:17:24 -0700 (PDT) In-Reply-To: <095B9543-1F20-4DA5-A8EB-48F86CDED9A6@gmail.com> References: <AANLkTimMruKyblUWROkPMDapFKtTztOXqL64PpQxCmKO@mail.gmail.com> <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <AANLkTinvLOV0f3I-aWpeAbfIpfGyxZSB2RHu52iw5mDC@mail.gmail.com> <AANLkTilWNneonIRX21U1RZcE80FuVSJWXU7CNm5pV275@mail.gmail.com> <AANLkTin-7PNLv-Hc229JJcOrIBh4fJqY5CMaLCMbmoIk@mail.gmail.com> <AANLkTikh_nQ8dXSp7QXJ79kCdbX1zeyPKAl_kgplb25x@mail.gmail.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> <AANLkTimpvWCbCBEWdI1Id5Ig_xCUW2hvKDro5LyhufMV@mail.gmail.com> <FE47FED0-3850-4393-9C79-DE06F0F7B6CA@gmail.com> <BA564125-9FBB-4B1A-93AC-7DD1A754A5E1@facebook.com> <C66A9854-02EB-4CCE-8338-382AEEC7EA61@gmail.com> <AANLkTikiXVruhZSH3Q6rMhdZAHRBPkhE_JVhSNOhCXmN@mail.gmail.com> <6B008ED4-4536-4A95-89B6-917696E6AF79@gmail.com> <AANLkTilTxGBYt2RFrEOqaYoLCV1TQOtonBh5dxL5PQCd@mail.gmail.com> <095B9543-1F20-4DA5-A8EB-48F86CDED9A6@gmail.com> From: Evan Gilbert <uidude@google.com> Date: Tue, 6 Jul 2010 21:17:24 -0700 Message-ID: <AANLkTimdWTqFd8UmcnYtYPZ3Dqzsffgn1HHwxPpnHcWY@mail.gmail.com> To: Dick Hardt <dick.hardt@gmail.com> Content-Type: multipart/alternative; boundary=00c09f97212f97d48d048ac473f9 X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 04:17:49 -0000 --00c09f97212f97d48d048ac473f9 Content-Type: text/plain; charset=ISO-8859-1 Hi all - having a little bit of a hard time following the full thread, but I'm strongly in favor of base64url encoding. A big advantage of this encoding is that, if token is base64url encoded, then urlencode(token) == token. This allows developers to avoid a large class of problems in dealing with URL encoding / decoding issues - it is very easy to accidentally double encode / decode values, and also easy to get tripped up on the different encoding rules in different parts of a URL. For example, different characters are OK before and after the hash, and not all browsers decode the hash the same way. Also being able to copy a value from a URL and use it directly in a tool or Authorization header is invaluable for debugging. Per notes above, the transformation is very straightforward. Evan On Sat, Jul 3, 2010 at 12:45 PM, Dick Hardt <dick.hardt@gmail.com> wrote: > > On 2010-07-03, at 12:14 PM, Naitik Shah wrote: > > On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt <dick.hardt@gmail.com> wrote: > >> >> On 2010-07-03, at 9:13 AM, Naitik Shah wrote: >> >> > I think Naitik is saying that accidentally doing base64 and not >>> base64url will send some '+'s along. >>> >>> if there are '+'s in the token, then it is easy for someone helping to >>> spot the problem. also easy for servers to send back an error message >>> saying, "hey, looks like you are using base64 instead of base64url encoding" >>> >>> ie, it is easy to detect the error -- urlencoding / decoding is hard to >>> detect as an error >>> >> >> The pluses are not guaranteed. They may or may not be there depending on >> the data stream you're encoding. If you don't urlencode the JSON, you'll get >> a "{", if you do it once, you'll get a "%7B", if you do it twice, you'll get >> a "%257B" -- seems easier to detect. >> >> >> Your earlier point was that developers may incorrectly use base64 instead >> of base64url. If they used base64, and if there is a + / = or % in the >> string, the server can send a useful note saying what is wrong. There may >> not be one of those characters depending on the input string, but if there >> is, then the server can suggest what the error might be using base64 instead >> of base64url. If the token contains ANY character that is not in base64url, >> then the server can say that it is not base64url encoded. >> >> That seems pretty fool proof to detect. Note that you should never get any >> %7B or other encoding in the token as it is url safe. >> > > The thing I was trying to say was that it's less predictable. That it might > work just fine when you're experimenting with the API because at that point > your token did not contain any pluses, but then suddenly started failing > after you sent a link to your app to someone because their encoded token > contains a plus. This hit-or-miss to me is worse than being able to tell by > looking at the first few characters of the urlencoded JSON blob which will > give a definitive answer as to how many times the token has been urlencoded. > > > I understand your point. I still think base64url encoding makes it really > clear that it is encoded (nothing is legible anymore), allows there to be > one encoding format for all data, makes it easy to support encryption. > > > > > >> >>> When I wrote a sample in Perl, it was pretty easy to make it base64url >>> which then provides a consistent encoding. >>> >> >> Did it involve a string replace call? Or a third party library? >> >> >> I used a standard CPAN library. >> >> > Exactly :) I'm imagining our documentation where we want to be library > agnostic, and have almost psuedo code like code snippets. I said this > earlier -- while base64 may be common in standard libraries built into > languages, the base64url version isn't. In order to not have a "cpan install > base64url" (and gem install, easy_install, mvn install..) -- we'ed most > likely document a str_replace() call in addition to a base64 call. And I'm > worried that developers will miss this detail. > > > Likely they will install an OAuth library that will deal with it if they > are going to have to sign rather than using a bearer token (I believe most > people will use a bearer token if they can -- soooo much easier!) > > Besides base64url, there is HMAC256 and JSON -- not all of which are built > in -- but are becoming more built in as time goes on, and if OAuth signing > uses base64url, I would expect these will all be part of standard > distributions in the future ... > > (... in case you are unfamiliar with my backgroud, I have delivered Perl, > Python and Tcl distributions in the past -- what goes into a packages is > what is heavily used or what we thought was a good thing to promote -- and > assuming that making base64url more available is a good thing, than using > it in OAuth is a good thing to do. :) > > > > >> >> >> >> >>> > >>> >> I am unclear on what your point is. >>> >> >>> >> The token would be included as one of the headers. This is often >>> preferable as it separates the authorization layer (in header) from >>> application layer parameters (query string or message body) >>> > >>> > With our proposal, we were focussed on url parameters (hence the choice >>> of urlencode after it was all put together). I think it makes total sense to >>> not do the encoding as part of the sig spec, and let the transport choice >>> dictate which encoding to use. >>> >>> I understand what you are saying. having multiple encodings makes >>> libraries harder, and leads to the issues that motivated base64url over >>> url-encoding >> >> >> Glad we agree on that. >> > > I agree multiple encodings makes libraries harder :) > > > glad we agree there > > > > But I think the stark difference between OAuth1 vs 2 wrt to signing > actually makes the Authorization header less valuable (again, for signing > only). I'm pretty happy with this because I thought this header was more > complex for developers anyways (while big corporations with authentication > infrastructure love it) :) But the reason I think so is that now the header > is not just the signature, but also the signed payload. This means an > application isn't just making a http request as before with a bunch of query > or post parameters. It's instead making a "JSON request" that may or may not > have query/post params. It's just not as separate as before. > > > I am confused on what point you are trying to make here. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00c09f97212f97d48d048ac473f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all - having a little bit of a hard time following the full thread, but = I'm strongly in favor of base64url encoding.<div><br></div><div>A big a= dvantage of this encoding is that, if token is base64url encoded, then urle= ncode(token) =3D=3D=A0token.=A0</div> <div><br></div><div>This allows developers to avoid a large class of proble= ms in dealing with URL encoding / decoding issues - it is very easy to acci= dentally double encode / decode values, and also easy to get tripped up on = the different encoding rules in different parts of a URL. For example, diff= erent characters are OK before and after the hash, and not all browsers dec= ode the hash the same way.</div> <div><br></div><div>Also being able to copy a value from a URL and use it d= irectly in a tool or Authorization header is invaluable for debugging.</div= ><div><br></div><div>Per notes above, the transformation is very straightfo= rward.</div> <div><br></div><div>Evan=A0</div><div><div><div><div><div><div><div><br><di= v class=3D"gmail_quote">On Sat, Jul 3, 2010 at 12:45 PM, Dick Hardt <span d= ir=3D"ltr"><<a href=3D"mailto:dick.hardt@gmail.com">dick.hardt@gmail.com= </a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:break-word"><br><di= v><div class=3D"im"><div>On 2010-07-03, at 12:14 PM, Naitik Shah wrote:</di= v><br> <blockquote type=3D"cite">On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt <span = dir=3D"ltr"><<a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">d= ick.hardt@gmail.com</a>></span> wrote:<br><div class=3D"gmail_quote"><bl= ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex"> <div style=3D"word-wrap:break-word"><br><div><div><div>On 2010-07-03, at 9:= 13 AM, Naitik Shah wrote:</div><blockquote type=3D"cite"><div class=3D"gmai= l_quote"><blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-r= ight:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-l= eft-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex"> <div>> I think Naitik is saying that accidentally doing base64 and not b= ase64url will send some '+'s along.<br> <br> </div>if there are '+'s in the token, then it is easy for someone h= elping to spot the problem. also easy for servers to send back an error mes= sage saying, "hey, looks like you are using base64 instead of base64ur= l encoding"<br> <br> ie, it is easy to detect the error -- urlencoding / decoding is hard to det= ect as an error<br></blockquote><div><br></div><div>The pluses are not=A0gu= aranteed. They may or may not be there depending on the data stream you'= ;re encoding. If you don't urlencode the JSON, you'll get a "{= ", if you do it once, you'll get a "%7B", if you do it t= wice, you'll get a "%257B" -- seems easier to detect.</div> </div></blockquote><div><br></div></div><div>Your earlier point was that de= velopers may incorrectly use base64 instead of base64url. If they used base= 64, and if there is a + / =3D or % in the string, the server can send a use= ful note saying what is wrong. There may not be one of those characters dep= ending on the input string, but if there is, then the server can suggest wh= at the error might be using base64 instead of base64url. If the token conta= ins ANY character that is not in base64url, then the server can say that it= is not base64url encoded.</div> <div><br></div><div>That seems pretty fool proof to detect. Note that you s= hould never get any %7B or other encoding in the token as it is url safe.</= div></div></div></blockquote><div><br></div><div>The thing I was trying to = say was that it's less predictable. That it might work just fine when y= ou're experimenting with the API because at that point your token did n= ot contain any pluses, but then suddenly started failing after you sent a l= ink to your app to someone because their encoded token contains a plus. Thi= s hit-or-miss to me is worse than being able to tell by looking at the firs= t few characters of the urlencoded JSON blob which will give a definitive a= nswer as to how many times the token has been urlencoded.</div> </div></blockquote><div><br></div></div><div>I understand your point. I sti= ll think base64url encoding makes it really clear that it is encoded (nothi= ng is legible anymore), allows there to be one encoding format for all data= , makes it easy to support encryption.</div> <div class=3D"im"><div><br></div><br><blockquote type=3D"cite"><div class= =3D"gmail_quote"> <div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"w= ord-wrap:break-word"><div><div><blockquote type=3D"cite"><div class=3D"gmai= l_quote"> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204, 204, 204);border-left-style:solid;padding-left:1ex"><div><font co= lor=3D"#000000"><br> </font> </div>When I wrote a sample in Perl, it was pretty easy to make it base64ur= l which then provides a consistent encoding.<br></blockquote><div><br></div= ><div>Did it involve a string replace call? Or a third party library?</div> </div></blockquote><div><br></div></div><div>I used a standard CPAN library= .</div><div><br></div></div></div></blockquote><div><br></div><div>Exactly = :) I'm imagining our documentation where we want to be library agnostic= , and have almost psuedo code like code snippets. I said this earlier -- wh= ile base64 may be common in standard libraries built into languages, the ba= se64url version isn't. In order to not have a "cpan install base64= url" (and gem install, easy_install, mvn install..) -- we'ed most = likely document a str_replace() call in addition to a base64 call. And I= 9;m worried that developers will miss this detail.</div> </div></blockquote><div><br></div></div><div>Likely they will install an OA= uth library that will deal with it if they are going to have to sign rather= than using a bearer token (I believe most people will use a bearer token i= f they can -- soooo much easier!)</div> <div><br></div><div>Besides base64url, there is HMAC256 and JSON -- not all= of which are built in -- but are becoming more built in as time goes on, a= nd if OAuth signing uses base64url, I would expect these will all be part o= f standard distributions in the future ...=A0</div> <div><br></div><div>(... in case you are unfamiliar with my backgroud, I ha= ve delivered Perl, Python and Tcl distributions in the past -- what goes in= to a packages is what is heavily used or what we thought was a good thing t= o promote -- and assuming that =A0making base64url more available is a good= thing, than using it in OAuth is a good thing to do. :)</div> <div class=3D"im"><br><blockquote type=3D"cite"><div class=3D"gmail_quote"> <div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar= gin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-lef= t-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;pa= dding-left:1ex"> <div style=3D"word-wrap:break-word"><div><div><blockquote type=3D"cite"><di= v class=3D"gmail_quote"> <div>=A0</div><div><br></div><div><br></div><blockquote class=3D"gmail_quot= e" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0= .8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left= -style:solid;padding-left:1ex"> <div><br> ><br> >> I am unclear on what your point is.<br> >><br> >> The token would be included as one of the headers. This is often p= referable as it separates the authorization layer (in header) from applicat= ion layer parameters (query string or message body)<br> ><br> > With our proposal, we were focussed on url parameters (hence the choic= e of urlencode after it was all put together). I think it makes total sense= to not do the encoding as part of the sig spec, and let the transport choi= ce dictate which encoding to use.<br> <br> </div>I understand what you are saying. having multiple encodings makes lib= raries harder, and leads to the issues that motivated base64url over url-en= coding=A0</blockquote></div></blockquote><div><br></div></div>Glad we agree= on that.</div> </div></blockquote><div><br></div><div>I agree multiple encodings makes lib= raries harder :)</div></div></blockquote><div><br></div></div><div>glad we = agree there</div><div><br></div></div><div><div class=3D"im"><br><blockquot= e type=3D"cite"> <div class=3D"gmail_quote"><div><br></div><div>But I think the stark differ= ence between OAuth1 vs 2 wrt to signing actually makes the Authorization he= ader less valuable (again, for signing only). I'm pretty happy with thi= s because I thought this header was more complex for developers anyways (wh= ile big corporations with authentication infrastructure love it) :) But the= reason I think so is that now the header is not just the signature, but al= so the signed payload. This means an application isn't just making a ht= tp request as before with a bunch of query or post parameters. It's ins= tead making a "JSON request" that may or may not have query/post = params. It's just not as separate as before.</div> </div></blockquote><div><br></div></div><div>I am confused on what point yo= u are trying to make here.=A0</div><div><br></div></div></div><br>_________= ______________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div></div></div></div></div></div></div> --00c09f97212f97d48d048ac473f9-- From uidude@google.com Tue Jul 6 21:32:51 2010 Return-Path: <uidude@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154293A67CC for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 21:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2xA1cO6ljM4 for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 21:32:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 5BA283A696F for <oauth@ietf.org>; Tue, 6 Jul 2010 21:31:48 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o674VZrr010445 for <oauth@ietf.org>; Tue, 6 Jul 2010 21:31:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278477096; bh=7SNGIo/kkK3eF2B87HTuBmGVg6Y=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=q9qdUza0orUv2NYJTZ4o3M7rWvGbQ6IML+JusQEtpEEFZdJAutYFpDer2Fh/aqcJh eL+FEBjLpIZDrIp0L7Abw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=DXwjURVmgRROlQjLFRrqvZeltbuDIRJQmBYsaZvy+LzOoI8dzj/T8TsEObE3hwnoY te2y99sb9O44Pv7LpLVOg== Received: from vws20 (vws20.prod.google.com [10.241.21.148]) by wpaz5.hot.corp.google.com with ESMTP id o674VO5b026339 for <oauth@ietf.org>; Tue, 6 Jul 2010 21:31:34 -0700 Received: by vws20 with SMTP id 20so8029484vws.15 for <oauth@ietf.org>; Tue, 06 Jul 2010 21:31:34 -0700 (PDT) Received: by 10.229.222.65 with SMTP id if1mr3395254qcb.53.1278477093258; Tue, 06 Jul 2010 21:31:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.211 with HTTP; Tue, 6 Jul 2010 21:31:13 -0700 (PDT) In-Reply-To: <AANLkTik5u25V8SFx-18LMO9WhFirm6Yra3HcDYBZ4gBF@mail.gmail.com> References: <AANLkTik55pORyRWj9rBrV1e4cbPGHM7Zbb1_ySUwB-bH@mail.gmail.com> <AANLkTinhZ8cUlNzAtfJM2MVFkGod8zGb4GXQ8cLZ7qTS@mail.gmail.com> <AANLkTikWHWYKoXS_shws1mheYVtwSSPM4b2J6mMIE_H7@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTin5-GbdgXlvrws5UC60Plfh_tcpsODyHIoWw1mi@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTiky4opuiqF65cCZPyCdl46ReSt8wT9rDuufSPxB@mail.gmail.com> <AANLkTimlvQWeWzou4Q2flwjuK7i0InqFu099SrPFV60R@mail.gmail.com> <012AB2B223CB3F4BB846962876F47217059B6A0A@SNV-EXVS08.ds.corp.yahoo.com> <AANLkTik5u25V8SFx-18LMO9WhFirm6Yra3HcDYBZ4gBF@mail.gmail.com> From: Evan Gilbert <uidude@google.com> Date: Tue, 6 Jul 2010 21:31:13 -0700 Message-ID: <AANLkTimzWCVVVhYvgtnkU2gPOKv173-vTUtQ0YzZu6DV@mail.gmail.com> To: Andrew Arnott <andrewarnott@gmail.com> Content-Type: multipart/alternative; boundary=0016363b8284ff45b4048ac4a498 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 04:32:52 -0000 --0016363b8284ff45b4048ac4a498 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 6, 2010 at 12:49 PM, Andrew Arnott <andrewarnott@gmail.com>wrote: > If we can agree that it is useless from a security perspective (and I think > we agree on that by now), then an auth server must not ever issue an access > token to a user agent client without interacting with the user (no > "immediate" mode issuing of access tokens) so the user is aware that some > anonymous client on the web page is trying to access their data, since > there's no assurance whatsoever about which client that is, and whether the > user trusts it. > If anyone disagrees, please explain how you can justify it, in light of the > fact that leaving it as-is means once one client is authorized, the whole > world is authorized by just pretending to be that one client. It might as > well be a "make my data public" switch at the resource server to authorize a > client such that it gets an access token directly without a client secret. > I'm not sure I understand the concerns. The User Agent flow of course can't send back a token to an arbitrary URL - regardless of whether there is user interaction or not. Callback URLs need to be validated - this can be via pre-registration to associate a URL with a client_id or by the user approving the specific callback URL. Any reasons why this isn't secure? > > (Not the muddy the waters, but again, I know client secrets don't add value > when the client is on an uncontrolled machine. Please don't let that > technical hurdle stop you from justifying the status quo in draft 9 of the > spec). > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > > On Mon, Jul 5, 2010 at 10:27 PM, William Mills <wmills@yahoo-inc.com>wrote: > >> It's not verifiable, but it is as useful in this case as a "user agent" >> string. Not usefule formt he security perspective, but has some utility in >> application tracking. >> >> ------------------------------ >> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf >> Of *Andrew Arnott >> *Sent:* Saturday, July 03, 2010 12:16 PM >> *To:* Eran Hammer-Lahav >> *Cc:* OAuth WG (oauth@ietf.org) >> *Subject:* Re: [OAUTH-WG] Security of user agent clients (WAS: End user >> authresponse code-and-token's scope parameter) >> >> (this sounds sarcastic, but I'm no being sarcastic... it's a serious >> question/challenge)... >> >> Why not just remove the client_id parameter from the user-agent flow? >> It's absolutely meaningless to security. It's only perceivable benefit is >> that the auth server can possible display to the user the client being >> authorized or the list of previously authorized clients. But again, that's >> totally meaningless if not verified. >> >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the death >> your right to say it." - S. G. Tallentyre >> >> >> On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott <andrewarnott@gmail.com>wrote: >> >>> On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav <eran@hueniverse.com>wrote: >>> >>>> You are putting too much weight on the value of redirection URI >>>> registration. Since the same problem exists between the user-agent script >>>> and the server-side component used in the user-agent profile, anyone can >>>> imitate that flow. In most cases, the redirection URI will simply include a >>>> script that will pass the parameter to the **parent** window which can >>>> be anything. If the server-based page is an active page, it still needs to >>>> communicate with the user-agent, which again, can pretend to be that. >>>> >>> Good point. I wasn't imagining that far through it. Not to deny that >>> most redirection URLs may just return a straight script that passes it to >>> the parent window, but that seems pretty irresponsible to the host that's >>> doing it -- because of the enormous security hole it opens up. Some client >>> is trusted enough to authorize (by the user and auth server), receives an >>> access token it wasn't expecting, and then blindly forwards it onto whoever >>> wants it. Yikes. I sure hope these access tokens have *very* limited >>> scope (like, I'd prefer none myself). >>> >>> I was about to describe how an active server could alleviate that by >>> signing the original request using the state parameter, but I realized I'm >>> solving a problem that the web server flow (or nowadays that the >>> authorization code mode as I guess it's called) already solves. So I guess >>> I just need to bite the bullet and accept that the user agent flow is *totally >>> *insecure for web clients, and thus very special care must be taken to >>> enable native clients without opening up the web client hole. >>> >>> Sorry to sound so negative about it. Enabling this scenario seems really >>> important to me as well -- I just am against doing it when it can't be >>> secured in some way. Seriously... as is, once you authorize any client, >>> you've authorized them all, including clients not even running on your >>> computer. I guess this answers how I was visiting a site a few days ago and >>> was amazed that it knew who I was (via Facebook) and was displaying my name >>> and photo when I never logged into the site. I was shocked it knew who I >>> was. Enter living in Incognito mode from now on. >>> >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0016363b8284ff45b4048ac4a498 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Tue, Jul 6, 2010 at 12:49 PM, Andrew = Arnott <span dir=3D"ltr"><<a href=3D"mailto:andrewarnott@gmail.com">andr= ewarnott@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"= > If we can agree that it is useless from a security perspective (and I think= we agree on that by now), then an auth server must not ever issue an acces= s token to a user agent client without interacting with the user (no "= immediate" mode issuing of access tokens) so the user is aware that so= me anonymous client on the web page is trying to access their data, since t= here's no assurance whatsoever about which client that is, and whether = the user trusts it.=A0</blockquote> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div> <br></div><div>If anyone disagrees, please explain how you can justify it, = in light of the fact that leaving it as-is means once one client is authori= zed, the whole world is authorized by just pretending to be that one client= . =A0It might as well be a "make my data public" switch at the re= source server to authorize a client such that it gets an access token direc= tly without a client secret.</div> </blockquote><div><br></div><div>I'm not sure I understand the concerns= .=A0The User Agent flow of course can't send back a token to an arbitra= ry URL - regardless of whether there is user interaction or not.</div><div> <br></div><div>Callback URLs need to be validated - this can be via pre-reg= istration to associate a URL with a client_id or by the user approving the = specific callback URL. Any reasons why this isn't secure?</div><div> =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex;"> <div><br></div><div>(Not the muddy the waters, but again, I know client sec= rets don't add value when the client is on an uncontrolled machine. =A0= Please don't let that technical hurdle stop you from justifying the sta= tus quo in draft 9 of the spec).<div class=3D"im"> <br clear=3D"all"> --<br>Andrew Arnott<br>"I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre<br> <br><br></div><div><div></div><div class=3D"h5"><div class=3D"gmail_quote">= On Mon, Jul 5, 2010 at 10:27 PM, William Mills <span dir=3D"ltr"><<a hre= f=3D"mailto:wmills@yahoo-inc.com" target=3D"_blank">wmills@yahoo-inc.com</a= >></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <div> <div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" size=3D"2" fa= ce=3D"Arial">It's not verifiable, but it is as useful in this case as a= =20 "user agent" string.=A0 Not usefule formt he security perspective= , but has=20 some utility in application tracking.</font></span></div><br> <blockquote style=3D"border-left:#0000ff 2px solid;padding-left:5px;margin-= left:5px;margin-right:0px" dir=3D"ltr"> <div dir=3D"ltr" lang=3D"en-us" align=3D"left"> <hr> <font size=3D"2" face=3D"Tahoma"><div><b>From:</b> <a href=3D"mailto:oaut= h-bounces@ietf.org" target=3D"_blank">oauth-bounces@ietf.org</a>=20 [mailto:<a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth= -bounces@ietf.org</a>] <b>On Behalf Of </b>Andrew=20 Arnott<br></div><b>Sent:</b> Saturday, July 03, 2010 12:16 PM<br><b>To:</= b> Eran=20 Hammer-Lahav<br><b>Cc:</b> OAuth WG (<a href=3D"mailto:oauth@ietf.org" ta= rget=3D"_blank">oauth@ietf.org</a>)<br><b>Subject:</b> Re:=20 [OAUTH-WG] Security of user agent clients (WAS: End user authresponse=20 code-and-token's scope parameter)<br></font><br></div><div><div></div= ><div> <div></div>(this sounds sarcastic, but I'm no being sarcastic... it&#= 39;s a=20 serious question/challenge)... <div><br></div> <div>Why not just remove the client_id parameter from the user-agent flow= ?=20 =A0It's absolutely meaningless to security. =A0It's only perceiva= ble=20 benefit is that the auth server can possible display to the user the clie= nt=20 being authorized or the list of previously authorized clients. =A0But=20 again, that's totally meaningless if not verified.</div> <div><br clear=3D"all">--<br>Andrew Arnott<br>"I [may] not agree wit= h what you=20 have to say, but I'll defend to the death your right to say it."= - S. G.=20 Tallentyre<br><br><br> <div class=3D"gmail_quote">On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott= <span dir=3D"ltr"><<a href=3D"mailto:andrewarnott@gmail.com" target=3D"= _blank">andrewarnott@gmail.com</a>></span>=20 wrote:<br> <blockquote style=3D"border-left:#ccc 1px solid;margin:0px 0px 0px 0.8ex;= padding-left:1ex" class=3D"gmail_quote"> <div> <div class=3D"gmail_quote"> <div>On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav <span dir=3D"ltr= "><<a href=3D"mailto:eran@hueniverse.com" target=3D"_blank">eran@huenive= rse.com</a>></span> wrote:<br> <blockquote style=3D"border-left:#ccc 1px solid;margin:0px 0px 0px 0.8e= x;padding-left:1ex" class=3D"gmail_quote"> <div lang=3D"EN-US" vlink=3D"purple" link=3D"blue"> <div> <p class=3D"MsoNormal"><span style=3D"color:#1f497d;font-size:11pt">Y= ou are=20 putting too much weight on the value of redirection URI registration.= =20 Since the same problem exists between the user-agent script and the= =20 server-side component used in the user-agent profile, anyone can imit= ate=20 that flow. In most cases, the redirection URI will simply include a s= cript=20 that will pass the parameter to the *<b>parent</b>* window which can = be=20 anything. If the server-based page is an active page, it still needs = to=20 communicate with the user-agent, which again, can pretend to be=20 that.</span></p></div></div></blockquote></div> <div>Good point. =A0I wasn't imagining that far through it. =A0Not = to=20 deny that most redirection URLs may just return a straight script that= =20 passes it to the parent window, but that seems pretty irresponsible to = the=20 host that's doing it -- because of the enormous security hole it op= ens up.=20 =A0Some client is trusted enough to authorize (by the user and auth=20 server), receives an access token it wasn't expecting, and then bli= ndly=20 forwards it onto whoever wants it. =A0Yikes. =A0I sure hope these=20 access tokens have <i>very</i>=A0limited scope (like, I'd prefer no= ne=20 myself).</div> <div><br></div> <div>I was about to describe how an active server could alleviate that = by=20 signing the original request using the state parameter, but I realized = I'm=20 solving a problem that the web server flow (or nowadays that the=20 authorization code mode as I guess it's called) already solves. =A0= So I=20 guess I just need to bite the bullet and accept that the user agent flo= w is=20 <i>totally </i>insecure for web clients, and thus very special care mus= t be=20 taken to enable native clients without opening up the web client hole.= =20 =A0</div> <div><br></div> <div>Sorry to sound so negative about it. =A0Enabling this scenario see= ms=20 really important to me as well -- I just am against doing it when it ca= n't=20 be secured in some way. =A0Seriously... as is, once you authorize any= =20 client, you've authorized them all, including clients not even runn= ing on=20 your computer. =A0I guess this answers how I was visiting a site a few= =20 days ago and was amazed that it knew who I was (via Facebook) and was= =20 displaying my name and photo when I never logged into the site. =A0I wa= s=20 shocked it knew who I was. =A0Enter living in Incognito mode from now= =20 on.</div></div></div></blockquote></div><br></div></div></div></blockqu= ote></div> </blockquote></div><br></div></div></div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br> --0016363b8284ff45b4048ac4a498-- From mscurtescu@google.com Tue Jul 6 21:54:38 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F9A3A6803 for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 21:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[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 npQZg-cEpy-F for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 21:54:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 4CFB93A6407 for <oauth@ietf.org>; Tue, 6 Jul 2010 21:54:36 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o674sc83005168 for <oauth@ietf.org>; Tue, 6 Jul 2010 21:54:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278478478; bh=PhWg573z2TB/fYp/9lhbqUVnpoE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=jqmn0O1Iyn7zls7wJg0/zg9vuQ0mIOT9xENrmCyuO9eEQrgFZyuAkUxd863fd191T DciBUMwfkLzERLlkBk7Qw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=uaR9Kl00I3Mvo3jAk6k49DrGTCNLOwFyvZT/W8BXyKnzDKKHS3waYLRs/vjARoaPk xUBxsOq34Iydnu2HLhsWQ== Received: from gwj21 (gwj21.prod.google.com [10.200.10.21]) by hpaq5.eem.corp.google.com with ESMTP id o674s55m011114 for <oauth@ietf.org>; Tue, 6 Jul 2010 21:54:37 -0700 Received: by gwj21 with SMTP id 21so1903630gwj.5 for <oauth@ietf.org>; Tue, 06 Jul 2010 21:54:36 -0700 (PDT) Received: by 10.101.72.4 with SMTP id z4mr7072780ank.77.1278478476553; Tue, 06 Jul 2010 21:54:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Tue, 6 Jul 2010 21:54:16 -0700 (PDT) In-Reply-To: <4C2F108B.70504@cdatazone.org> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTikjW5OqYJIzwxrooAmHoWR5tNX1522TTBLH5rBT@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTilTDOVNjJw9K0ZismTzbbNeuVcEBktE-8ojDfVR@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2DC7C5.2090009@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F108B.70504@cdatazone.org> From: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 6 Jul 2010 21:54:16 -0700 Message-ID: <AANLkTilr38Y0TrUhks2_djJiAzZIcagMMy_Her-5h3Xn@mail.gmail.com> To: Rob Richards <rrichards@cdatazone.org> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 04:54:38 -0000 On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards <rrichards@cdatazone.org> wrote: > Eran Hammer-Lahav wrote: >> >> Hi Rob, >> >> I agree with you that a migration spec is important - please write one. >> > > Like I didn't see that coming :) I would like to help with this migration spec. Is this a good starting point: http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html Or, you had something else in mind? Marius From mscurtescu@google.com Tue Jul 6 22:04:29 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F663A67EC for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 22:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezno4mAmiW-s for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 22:04:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 99BCC3A6407 for <oauth@ietf.org>; Tue, 6 Jul 2010 22:04:27 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o6754TAL025066 for <oauth@ietf.org>; Tue, 6 Jul 2010 22:04:29 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278479070; bh=/U0fJHB/3xHoOphHgcDxT5YhdQM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=KJMbJfdlZTPxZuiMaUGH9vReZrDEsCypVfg0bt1OwnIo96fo2CNn95xAGRdgOfjEl RZheC0UXsxmR5/zUjre1A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=HhnfjlcdOMWUACFt1aneO1A6XA5lfQmFtzVnaMx7ufO63mIBMcm4xdene59mdi0y3 Vm8Xg6vZ+QYoq3DdXEb+A== Received: from gxk25 (gxk25.prod.google.com [10.202.11.25]) by hpaq1.eem.corp.google.com with ESMTP id o6754Fpk003802 for <oauth@ietf.org>; Tue, 6 Jul 2010 22:04:16 -0700 Received: by gxk25 with SMTP id 25so2238208gxk.1 for <oauth@ietf.org>; Tue, 06 Jul 2010 22:04:15 -0700 (PDT) Received: by 10.101.124.4 with SMTP id b4mr7085351ann.214.1278479055221; Tue, 06 Jul 2010 22:04:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Tue, 6 Jul 2010 22:03:55 -0700 (PDT) In-Reply-To: <C858C2B1.36C16%eran@hueniverse.com> References: <1278439815.2445.8.camel@localhost.localdomain> <C858C2B1.36C16%eran@hueniverse.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 6 Jul 2010 22:03:55 -0700 Message-ID: <AANLkTimWZugW68Gkg_CCYZL8TUIbtaNEAlQS7cMTTSZV@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 05:04:29 -0000 On Tue, Jul 6, 2010 at 11:23 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > Platforms change over time. These platforms are not designed with providing > APIs and web services in mind. They are also typically not capable of > running over SSL (due to the self-hosted nature of most deployments). Using > an apache rewrite rules might be hard for some developers, but it is a good > solution when there are issues with platform limitations. Apache rewrite will not make a difference. Apache acts as a reverse proxy, the user agent requests a URL without query parameters and Apache is rewriting it by adding the query parameters. For the endpoint running behind Apache there is no change, in all cases it sees the query parameters. Many of these platforms can and do provide APIs. Even if in most cases these platforms act as clients only, the problem is still there because of redirect_uri. > If there are actual requirements for using OAuth 2.0 with such systems, we > should discuss these, but it would be silly for us to architect our work > based on the limitations of random platforms. I don't think these are random at all. MediaWiki, Drupal, WordPress, to name a few, are major platforms. Marius From michael.d.adams@gmail.com Tue Jul 6 22:19:04 2010 Return-Path: <michael.d.adams@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C7493A6873 for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 22:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpBA0v8J-SiI for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 22:18:58 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1BBF23A681E for <oauth@ietf.org>; Tue, 6 Jul 2010 22:18:58 -0700 (PDT) Received: by iwn38 with SMTP id 38so1868162iwn.31 for <oauth@ietf.org>; Tue, 06 Jul 2010 22:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=sUe3DF+btvVoxsPucq7YoL20eZYM2sXGuQxG71Zdnyk=; b=mgN9zLGlbQVWeDC6n9LhdegNtP1VODQ799Ug5VbhRfLnPZlIqnqEm6+0+mCa32/rZc uQPa+1YFPJPUOfBqWSg6HQK3oEDLZej5J1nnKJ2ZMt5azOpihdgcyETdwLNHNM2QSxIl tn9ik67Tvv9+3BP6SaoEeK1xQGv5O8THlvr/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=hRvxaJy3nBGml6dCvankhKfwEsjgtbHWkvY/rG9++/auTZi+wSMHterGXPGNeJ0rRW ONJEJ4foMUbw9ClQKUJMw4m9NgjWPiDyq/5xlsLFdEDS5lhpfreFLnZX3RX1J4WymBIu bePq8RdJIO8AGkRGdSukwvrhpy2Qaqi3imcxk= Received: by 10.231.30.129 with SMTP id u1mr6323884ibc.63.1278479940294; Tue, 06 Jul 2010 22:19:00 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.179.143 with HTTP; Tue, 6 Jul 2010 22:18:39 -0700 (PDT) In-Reply-To: <AANLkTimWZugW68Gkg_CCYZL8TUIbtaNEAlQS7cMTTSZV@mail.gmail.com> References: <1278439815.2445.8.camel@localhost.localdomain> <C858C2B1.36C16%eran@hueniverse.com> <AANLkTimWZugW68Gkg_CCYZL8TUIbtaNEAlQS7cMTTSZV@mail.gmail.com> From: Michael D Adams <mike@automattic.com> Date: Tue, 6 Jul 2010 22:18:39 -0700 X-Google-Sender-Auth: Hp4zE19gb4_2gGCQHwcr9KSGHqQ Message-ID: <AANLkTimsxRHsXggcEsQhgD04YgbdUlrm_rojSi_SLc-X@mail.gmail.com> To: Marius Scurtescu <mscurtescu@google.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 05:19:07 -0000 >> If there are actual requirements for using OAuth 2.0 with such systems, we >> should discuss these, but it would be silly for us to architect our work >> based on the limitations of random platforms. > > I don't think these are random at all. MediaWiki, Drupal, WordPress, > to name a few, are major platforms. For section 6.2 (query parameters on the end-user authorization and token endpoints), this should not be an issue for WordPress. For section 6.3 (header parameters), this should not be an issue for WordPress. The only place this could be problematic is adding query parameters on the protected resources themselves. Mike --mdawaffe From mscurtescu@google.com Tue Jul 6 22:24:09 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ED4B3A687B for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 22:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[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 QXGdhDAdZqxu for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 22:23:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id E04743A6873 for <oauth@ietf.org>; Tue, 6 Jul 2010 22:22:14 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o675MBki030805 for <oauth@ietf.org>; Tue, 6 Jul 2010 22:22:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278480132; bh=cTAmUVwn92Z0Mue4AcUkfounS08=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=GRQboQhFvYiYHDRQmPoVBQAtUVIqCaE/BcRDKaT1UPtnfNjLPYHc1RSU1AcI8erKv MFqwKL5eN+J4bKo74mZXA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=MbQmJ7YtCtAOWb0+FwXwg9Ld8PJ5Y5ww4ocVTC3MjENYqh8AVOwQVKEFirHfx3GQM 9hZ690ywPDiFyStZPQa0w== Received: from gxk23 (gxk23.prod.google.com [10.202.11.23]) by wpaz17.hot.corp.google.com with ESMTP id o675MA8m031731 for <oauth@ietf.org>; Tue, 6 Jul 2010 22:22:10 -0700 Received: by gxk23 with SMTP id 23so4454157gxk.5 for <oauth@ietf.org>; Tue, 06 Jul 2010 22:22:10 -0700 (PDT) Received: by 10.100.249.10 with SMTP id w10mr7283501anh.242.1278480129171; Tue, 06 Jul 2010 22:22:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Tue, 6 Jul 2010 22:21:49 -0700 (PDT) In-Reply-To: <AANLkTik5u25V8SFx-18LMO9WhFirm6Yra3HcDYBZ4gBF@mail.gmail.com> References: <AANLkTik55pORyRWj9rBrV1e4cbPGHM7Zbb1_ySUwB-bH@mail.gmail.com> <AANLkTinhZ8cUlNzAtfJM2MVFkGod8zGb4GXQ8cLZ7qTS@mail.gmail.com> <AANLkTikWHWYKoXS_shws1mheYVtwSSPM4b2J6mMIE_H7@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTin5-GbdgXlvrws5UC60Plfh_tcpsODyHIoWw1mi@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTiky4opuiqF65cCZPyCdl46ReSt8wT9rDuufSPxB@mail.gmail.com> <AANLkTimlvQWeWzou4Q2flwjuK7i0InqFu099SrPFV60R@mail.gmail.com> <012AB2B223CB3F4BB846962876F47217059B6A0A@SNV-EXVS08.ds.corp.yahoo.com> <AANLkTik5u25V8SFx-18LMO9WhFirm6Yra3HcDYBZ4gBF@mail.gmail.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 6 Jul 2010 22:21:49 -0700 Message-ID: <AANLkTilc3n9q7ZdY6WCGKEVettkcRyNXbJkuODZCGwrk@mail.gmail.com> To: Andrew Arnott <andrewarnott@gmail.com> 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] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 05:24:10 -0000 On Tue, Jul 6, 2010 at 12:49 PM, Andrew Arnott <andrewarnott@gmail.com> wro= te: > If we can agree that it is useless from a security perspective (and I thi= nk > we agree on that by now), I don't think this is useless. As Evan mentioned, a JavaScript client could register and provide a redirect_uri (or redirect_uri pattern) and also a display name. In this case the ID is needed. > then an auth server must not ever issue an access > token to a user agent client without interacting with the user (no > "immediate" mode issuing of access tokens) so the user is aware that some > anonymous client on the web page is trying to access their data, since > there's no assurance whatsoever about which client that is, and whether t= he > user trusts it. If the user has to be involved every time an access token is issued then the whole flow becomes unusable. Access tokens typically expire in an hour or so, you cannot keep prompting the user that often. Marius > If anyone disagrees, please explain how you can justify it, in light of t= he > fact that leaving it as-is means once one client is authorized, the whole > world is authorized by just pretending to be that one client. =A0It might= as > well be a "make my data public" switch at the resource server to authoriz= e a > client such that it gets an access token directly without a client secret= . > (Not the muddy the waters, but again, I know client secrets don't add val= ue > when the client is on an uncontrolled machine. =A0Please don't let that > technical hurdle stop you from justifying the status quo in draft 9 of th= e > spec). > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the deat= h > your right to say it." - S. G. Tallentyre > > > On Mon, Jul 5, 2010 at 10:27 PM, William Mills <wmills@yahoo-inc.com> wro= te: >> >> It's not verifiable, but it is as useful in this case as a "user agent" >> string.=A0 Not usefule formt he security perspective, but has some utili= ty in >> application tracking. >> >> ________________________________ >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f >> Andrew Arnott >> Sent: Saturday, July 03, 2010 12:16 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user >> authresponse code-and-token's scope parameter) >> >> (this sounds sarcastic, but I'm no being sarcastic... it's a serious >> question/challenge)... >> Why not just remove the client_id parameter from the user-agent flow? >> =A0It's absolutely meaningless to security. =A0It's only perceivable ben= efit is >> that the auth server can possible display to the user the client being >> authorized or the list of previously authorized clients. =A0But again, t= hat's >> totally meaningless if not verified. >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the dea= th >> your right to say it." - S. G. Tallentyre >> >> >> On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott <andrewarnott@gmail.com> >> wrote: >>> >>> On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav <eran@hueniverse.com> >>> wrote: >>>> >>>> You are putting too much weight on the value of redirection URI >>>> registration. Since the same problem exists between the user-agent scr= ipt >>>> and the server-side component used in the user-agent profile, anyone c= an >>>> imitate that flow. In most cases, the redirection URI will simply incl= ude a >>>> script that will pass the parameter to the *parent* window which can b= e >>>> anything. If the server-based page is an active page, it still needs t= o >>>> communicate with the user-agent, which again, can pretend to be that. >>> >>> Good point. =A0I wasn't imagining that far through it. =A0Not to deny t= hat >>> most redirection URLs may just return a straight script that passes it = to >>> the parent window, but that seems pretty irresponsible to the host that= 's >>> doing it -- because of the enormous security hole it opens up. =A0Some = client >>> is trusted enough to authorize (by the user and auth server), receives = an >>> access token it wasn't expecting, and then blindly forwards it onto who= ever >>> wants it. =A0Yikes. =A0I sure hope these access tokens have very=A0limi= ted scope >>> (like, I'd prefer none myself). >>> I was about to describe how an active server could alleviate that by >>> signing the original request using the state parameter, but I realized = I'm >>> solving a problem that the web server flow (or nowadays that the >>> authorization code mode as I guess it's called) already solves. =A0So I= guess >>> I just need to bite the bullet and accept that the user agent flow is >>> totally insecure for web clients, and thus very special care must be ta= ken >>> to enable native clients without opening up the web client hole. >>> Sorry to sound so negative about it. =A0Enabling this scenario seems re= ally >>> important to me as well -- I just am against doing it when it can't be >>> secured in some way. =A0Seriously... as is, once you authorize any clie= nt, >>> you've authorized them all, including clients not even running on your >>> computer. =A0I guess this answers how I was visiting a site a few days = ago and >>> was amazed that it knew who I was (via Facebook) and was displaying my = name >>> and photo when I never logged into the site. =A0I was shocked it knew w= ho I >>> was. =A0Enter living in Incognito mode from now on. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From mscurtescu@google.com Tue Jul 6 22:25:26 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8723A6873 for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 22:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[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 WBAuk4UtX6zd for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 22:25:21 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 601723A68F1 for <oauth@ietf.org>; Tue, 6 Jul 2010 22:25:20 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o675PBaM001431 for <oauth@ietf.org>; Tue, 6 Jul 2010 22:25:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278480311; bh=KpI/SR2CqOSRoBiI+2NYDOxyPaU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=njeSiDULSYz76df+IfmpzG9MqJamaU48n+eihWybEntnGUoxll5LmBWMru/xGAC8C L9Uh47FzYlisSIZON72wQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=reBdmnLj+QpD/acBQc/iYB6Rtd0NFLI7IF92BljPEMF5WntFTNPkWPUFf5uga6C5E gQ7PFo2VY8fyYWUC+3bQg== Received: from yxt3 (yxt3.prod.google.com [10.190.5.195]) by kpbe19.cbf.corp.google.com with ESMTP id o675PAlx003832 for <oauth@ietf.org>; Tue, 6 Jul 2010 22:25:10 -0700 Received: by yxt3 with SMTP id 3so500845yxt.2 for <oauth@ietf.org>; Tue, 06 Jul 2010 22:25:09 -0700 (PDT) Received: by 10.100.109.9 with SMTP id h9mr5850454anc.140.1278480309163; Tue, 06 Jul 2010 22:25:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Tue, 6 Jul 2010 22:24:49 -0700 (PDT) In-Reply-To: <AANLkTimsxRHsXggcEsQhgD04YgbdUlrm_rojSi_SLc-X@mail.gmail.com> References: <1278439815.2445.8.camel@localhost.localdomain> <C858C2B1.36C16%eran@hueniverse.com> <AANLkTimWZugW68Gkg_CCYZL8TUIbtaNEAlQS7cMTTSZV@mail.gmail.com> <AANLkTimsxRHsXggcEsQhgD04YgbdUlrm_rojSi_SLc-X@mail.gmail.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 6 Jul 2010 22:24:49 -0700 Message-ID: <AANLkTikDx54ypvWMlZXGlgXsBi3wErcs3-SxO2hYVQYW@mail.gmail.com> To: Michael D Adams <mike@automattic.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 05:25:26 -0000 On Tue, Jul 6, 2010 at 10:18 PM, Michael D Adams <mike@automattic.com> wrote: >>> If there are actual requirements for using OAuth 2.0 with such systems, we >>> should discuss these, but it would be silly for us to architect our work >>> based on the limitations of random platforms. >> >> I don't think these are random at all. MediaWiki, Drupal, WordPress, >> to name a few, are major platforms. > > For section 6.2 (query parameters on the end-user authorization and > token endpoints), this should not be an issue for WordPress. > > For section 6.3 (header parameters), this should not be an issue for WordPress. This is not an issue because whatever query parameter WordPress is using does not collide with the core OAuth 2 parameters? Or because WordPress is not using query parameters? Marius From naitiks@gmail.com Tue Jul 6 23:12:45 2010 Return-Path: <naitiks@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADFEB3A67EC for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 23:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6-0-Wkxt+yq for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 23:12:40 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B5A4A3A67CC for <oauth@ietf.org>; Tue, 6 Jul 2010 23:12:39 -0700 (PDT) Received: by iwn38 with SMTP id 38so1909378iwn.31 for <oauth@ietf.org>; Tue, 06 Jul 2010 23:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=9TGMujgfpdDPo0tpbKJX9KS2CsOSAJsIE04kkGqkoSo=; b=qlvvMi/507GsuXFWx0Vs+gKNAtsv0fmmHtY9rxlKStwlI/gcKSYQxrP7XU9kkpuDP6 C+/MrF4m3vvbDOYtbtpMYS07iZ1UkvVAHsYKobu9c3aN19UpGMnszCt5OsBR5txdUkk5 ai4h5WTIKERaiMMI0pLDEkdxZOyoD0JnsypAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=W0Jy3a1kAfMDUmVWkZ7hoDwS3542H/GK+Cx+ObsWu0JAwG2DxCLRrOYjr0Dmbvbli9 l6HjGnWwv15cEfZEIPyd91Z5G09gBMbqRWhW0Z2p0hGc9loF/PEPUmMcdYup4CcXId8k 2Ks5WPcY9g0u9E/vB6feZeZiJW1mGzwrLdFAA= Received: by 10.42.1.205 with SMTP id 13mr1853733ich.63.1278483162343; Tue, 06 Jul 2010 23:12:42 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.231.159.193 with HTTP; Tue, 6 Jul 2010 23:12:22 -0700 (PDT) In-Reply-To: <AANLkTimdWTqFd8UmcnYtYPZ3Dqzsffgn1HHwxPpnHcWY@mail.gmail.com> References: <AANLkTimMruKyblUWROkPMDapFKtTztOXqL64PpQxCmKO@mail.gmail.com> <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <AANLkTinvLOV0f3I-aWpeAbfIpfGyxZSB2RHu52iw5mDC@mail.gmail.com> <AANLkTilWNneonIRX21U1RZcE80FuVSJWXU7CNm5pV275@mail.gmail.com> <AANLkTin-7PNLv-Hc229JJcOrIBh4fJqY5CMaLCMbmoIk@mail.gmail.com> <AANLkTikh_nQ8dXSp7QXJ79kCdbX1zeyPKAl_kgplb25x@mail.gmail.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> <AANLkTimpvWCbCBEWdI1Id5Ig_xCUW2hvKDro5LyhufMV@mail.gmail.com> <FE47FED0-3850-4393-9C79-DE06F0F7B6CA@gmail.com> <BA564125-9FBB-4B1A-93AC-7DD1A754A5E1@facebook.com> <C66A9854-02EB-4CCE-8338-382AEEC7EA61@gmail.com> <AANLkTikiXVruhZSH3Q6rMhdZAHRBPkhE_JVhSNOhCXmN@mail.gmail.com> <6B008ED4-4536-4A95-89B6-917696E6AF79@gmail.com> <AANLkTilTxGBYt2RFrEOqaYoLCV1TQOtonBh5dxL5PQCd@mail.gmail.com> <095B9543-1F20-4DA5-A8EB-48F86CDED9A6@gmail.com> <AANLkTimdWTqFd8UmcnYtYPZ3Dqzsffgn1HHwxPpnHcWY@mail.gmail.com> From: Naitik Shah <n@daaku.org> Date: Tue, 6 Jul 2010 23:12:22 -0700 X-Google-Sender-Auth: CZ5jj5UpL9LFd5GzNaFsqrINWCQ Message-ID: <AANLkTimoD2DRu2s6QgQUbBPLiYrCqtN02Oa-sk_Ag8yv@mail.gmail.com> To: Evan Gilbert <uidude@google.com> Content-Type: multipart/alternative; boundary=005045015aecbe2a19048ac60e77 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 06:12:45 -0000 --005045015aecbe2a19048ac60e77 Content-Type: text/plain; charset=UTF-8 I was hoping to avoid needing str_replace -- but I've been convinced. I'm happy with base64url :) Thanks, -Naitik On Tue, Jul 6, 2010 at 9:17 PM, Evan Gilbert <uidude@google.com> wrote: > Hi all - having a little bit of a hard time following the full thread, but > I'm strongly in favor of base64url encoding. > > A big advantage of this encoding is that, if token is base64url encoded, > then urlencode(token) == token. > > This allows developers to avoid a large class of problems in dealing with > URL encoding / decoding issues - it is very easy to accidentally double > encode / decode values, and also easy to get tripped up on the different > encoding rules in different parts of a URL. For example, different > characters are OK before and after the hash, and not all browsers decode the > hash the same way. > > Also being able to copy a value from a URL and use it directly in a tool or > Authorization header is invaluable for debugging. > > Per notes above, the transformation is very straightforward. > > Evan > > On Sat, Jul 3, 2010 at 12:45 PM, Dick Hardt <dick.hardt@gmail.com> wrote: > >> >> On 2010-07-03, at 12:14 PM, Naitik Shah wrote: >> >> On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt <dick.hardt@gmail.com> wrote: >> >>> >>> On 2010-07-03, at 9:13 AM, Naitik Shah wrote: >>> >>> > I think Naitik is saying that accidentally doing base64 and not >>>> base64url will send some '+'s along. >>>> >>>> if there are '+'s in the token, then it is easy for someone helping to >>>> spot the problem. also easy for servers to send back an error message >>>> saying, "hey, looks like you are using base64 instead of base64url encoding" >>>> >>>> ie, it is easy to detect the error -- urlencoding / decoding is hard to >>>> detect as an error >>>> >>> >>> The pluses are not guaranteed. They may or may not be there depending on >>> the data stream you're encoding. If you don't urlencode the JSON, you'll get >>> a "{", if you do it once, you'll get a "%7B", if you do it twice, you'll get >>> a "%257B" -- seems easier to detect. >>> >>> >>> Your earlier point was that developers may incorrectly use base64 instead >>> of base64url. If they used base64, and if there is a + / = or % in the >>> string, the server can send a useful note saying what is wrong. There may >>> not be one of those characters depending on the input string, but if there >>> is, then the server can suggest what the error might be using base64 instead >>> of base64url. If the token contains ANY character that is not in base64url, >>> then the server can say that it is not base64url encoded. >>> >>> That seems pretty fool proof to detect. Note that you should never get >>> any %7B or other encoding in the token as it is url safe. >>> >> >> The thing I was trying to say was that it's less predictable. That it >> might work just fine when you're experimenting with the API because at that >> point your token did not contain any pluses, but then suddenly started >> failing after you sent a link to your app to someone because their encoded >> token contains a plus. This hit-or-miss to me is worse than being able to >> tell by looking at the first few characters of the urlencoded JSON blob >> which will give a definitive answer as to how many times the token has been >> urlencoded. >> >> >> I understand your point. I still think base64url encoding makes it really >> clear that it is encoded (nothing is legible anymore), allows there to be >> one encoding format for all data, makes it easy to support encryption. >> >> >> >> >> >>> >>>> When I wrote a sample in Perl, it was pretty easy to make it base64url >>>> which then provides a consistent encoding. >>>> >>> >>> Did it involve a string replace call? Or a third party library? >>> >>> >>> I used a standard CPAN library. >>> >>> >> Exactly :) I'm imagining our documentation where we want to be library >> agnostic, and have almost psuedo code like code snippets. I said this >> earlier -- while base64 may be common in standard libraries built into >> languages, the base64url version isn't. In order to not have a "cpan install >> base64url" (and gem install, easy_install, mvn install..) -- we'ed most >> likely document a str_replace() call in addition to a base64 call. And I'm >> worried that developers will miss this detail. >> >> >> Likely they will install an OAuth library that will deal with it if they >> are going to have to sign rather than using a bearer token (I believe most >> people will use a bearer token if they can -- soooo much easier!) >> >> Besides base64url, there is HMAC256 and JSON -- not all of which are built >> in -- but are becoming more built in as time goes on, and if OAuth signing >> uses base64url, I would expect these will all be part of standard >> distributions in the future ... >> >> (... in case you are unfamiliar with my backgroud, I have delivered Perl, >> Python and Tcl distributions in the past -- what goes into a packages is >> what is heavily used or what we thought was a good thing to promote -- and >> assuming that making base64url more available is a good thing, than using >> it in OAuth is a good thing to do. :) >> >> >> >> >>> >>> >>> >>> >>>> > >>>> >> I am unclear on what your point is. >>>> >> >>>> >> The token would be included as one of the headers. This is often >>>> preferable as it separates the authorization layer (in header) from >>>> application layer parameters (query string or message body) >>>> > >>>> > With our proposal, we were focussed on url parameters (hence the >>>> choice of urlencode after it was all put together). I think it makes total >>>> sense to not do the encoding as part of the sig spec, and let the transport >>>> choice dictate which encoding to use. >>>> >>>> I understand what you are saying. having multiple encodings makes >>>> libraries harder, and leads to the issues that motivated base64url over >>>> url-encoding >>> >>> >>> Glad we agree on that. >>> >> >> I agree multiple encodings makes libraries harder :) >> >> >> glad we agree there >> >> >> >> But I think the stark difference between OAuth1 vs 2 wrt to signing >> actually makes the Authorization header less valuable (again, for signing >> only). I'm pretty happy with this because I thought this header was more >> complex for developers anyways (while big corporations with authentication >> infrastructure love it) :) But the reason I think so is that now the header >> is not just the signature, but also the signed payload. This means an >> application isn't just making a http request as before with a bunch of query >> or post parameters. It's instead making a "JSON request" that may or may not >> have query/post params. It's just not as separate as before. >> >> >> I am confused on what point you are trying to make here. >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --005045015aecbe2a19048ac60e77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p class=3D"p1">I was hoping to avoid needing str_replace -- but I've b= een convinced. I'm happy with base64url :)</p> <div><br></div><div>Thanks,</div><div>-Naitik</div><br><div class=3D"gmail_= quote">On Tue, Jul 6, 2010 at 9:17 PM, Evan Gilbert <span dir=3D"ltr"><<= a href=3D"mailto:uidude@google.com">uidude@google.com</a>></span> wrote:= <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Hi all - having a little bit of a hard time= following the full thread, but I'm strongly in favor of base64url enco= ding.<div> <br></div><div>A big advantage of this encoding is that, if token is base64= url encoded, then urlencode(token) =3D=3D=C2=A0token.=C2=A0</div> <div><br></div><div>This allows developers to avoid a large class of proble= ms in dealing with URL encoding / decoding issues - it is very easy to acci= dentally double encode / decode values, and also easy to get tripped up on = the different encoding rules in different parts of a URL. For example, diff= erent characters are OK before and after the hash, and not all browsers dec= ode the hash the same way.</div> <div><br></div><div>Also being able to copy a value from a URL and use it d= irectly in a tool or Authorization header is invaluable for debugging.</div= ><div><br></div><div>Per notes above, the transformation is very straightfo= rward.</div> <div><br></div><div>Evan=C2=A0</div><div><div><div><div><div><div><div><br>= <div class=3D"gmail_quote"><div><div></div><div class=3D"h5">On Sat, Jul 3,= 2010 at 12:45 PM, Dick Hardt <span dir=3D"ltr"><<a href=3D"mailto:dick.= hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.com</a>></span> wrot= e:<br> </div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class=3D"h5= "><div style=3D"word-wrap:break-word"><br><div><div><div>On 2010-07-03, at = 12:14 PM, Naitik Shah wrote:</div> <br> <blockquote type=3D"cite">On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt <span = dir=3D"ltr"><<a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">d= ick.hardt@gmail.com</a>></span> wrote:<br><div class=3D"gmail_quote"><bl= ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex"> <div style=3D"word-wrap:break-word"><br><div><div><div>On 2010-07-03, at 9:= 13 AM, Naitik Shah wrote:</div><blockquote type=3D"cite"><div class=3D"gmai= l_quote"><blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-r= ight:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-l= eft-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex"> <div>> I think Naitik is saying that accidentally doing base64 and not b= ase64url will send some '+'s along.<br> <br> </div>if there are '+'s in the token, then it is easy for someone h= elping to spot the problem. also easy for servers to send back an error mes= sage saying, "hey, looks like you are using base64 instead of base64ur= l encoding"<br> <br> ie, it is easy to detect the error -- urlencoding / decoding is hard to det= ect as an error<br></blockquote><div><br></div><div>The pluses are not=C2= =A0guaranteed. They may or may not be there depending on the data stream yo= u're encoding. If you don't urlencode the JSON, you'll get a &q= uot;{", if you do it once, you'll get a "%7B", if you do= it twice, you'll get a "%257B" -- seems easier to detect.</d= iv> </div></blockquote><div><br></div></div><div>Your earlier point was that de= velopers may incorrectly use base64 instead of base64url. If they used base= 64, and if there is a + / =3D or % in the string, the server can send a use= ful note saying what is wrong. There may not be one of those characters dep= ending on the input string, but if there is, then the server can suggest wh= at the error might be using base64 instead of base64url. If the token conta= ins ANY character that is not in base64url, then the server can say that it= is not base64url encoded.</div> <div><br></div><div>That seems pretty fool proof to detect. Note that you s= hould never get any %7B or other encoding in the token as it is url safe.</= div></div></div></blockquote><div><br></div><div>The thing I was trying to = say was that it's less predictable. That it might work just fine when y= ou're experimenting with the API because at that point your token did n= ot contain any pluses, but then suddenly started failing after you sent a l= ink to your app to someone because their encoded token contains a plus. Thi= s hit-or-miss to me is worse than being able to tell by looking at the firs= t few characters of the urlencoded JSON blob which will give a definitive a= nswer as to how many times the token has been urlencoded.</div> </div></blockquote><div><br></div></div><div>I understand your point. I sti= ll think base64url encoding makes it really clear that it is encoded (nothi= ng is legible anymore), allows there to be one encoding format for all data= , makes it easy to support encryption.</div> <div><div><br></div><br><blockquote type=3D"cite"><div class=3D"gmail_quote= "> <div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style= =3D"word-wrap:break-word"><div><div><blockquote type=3D"cite"><div class=3D= "gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204, 204, 204);border-left-style:solid;padding-left:1ex"><div><font co= lor=3D"#000000"><br> </font> </div>When I wrote a sample in Perl, it was pretty easy to make it base64ur= l which then provides a consistent encoding.<br></blockquote><div><br></div= ><div>Did it involve a string replace call? Or a third party library?</div> </div></blockquote><div><br></div></div><div>I used a standard CPAN library= .</div><div><br></div></div></div></blockquote><div><br></div><div>Exactly = :) I'm imagining our documentation where we want to be library agnostic= , and have almost psuedo code like code snippets. I said this earlier -- wh= ile base64 may be common in standard libraries built into languages, the ba= se64url version isn't. In order to not have a "cpan install base64= url" (and gem install, easy_install, mvn install..) -- we'ed most = likely document a str_replace() call in addition to a base64 call. And I= 9;m worried that developers will miss this detail.</div> </div></blockquote><div><br></div></div><div>Likely they will install an OA= uth library that will deal with it if they are going to have to sign rather= than using a bearer token (I believe most people will use a bearer token i= f they can -- soooo much easier!)</div> <div><br></div><div>Besides base64url, there is HMAC256 and JSON -- not all= of which are built in -- but are becoming more built in as time goes on, a= nd if OAuth signing uses base64url, I would expect these will all be part o= f standard distributions in the future ...=C2=A0</div> <div><br></div><div>(... in case you are unfamiliar with my backgroud, I ha= ve delivered Perl, Python and Tcl distributions in the past -- what goes in= to a packages is what is heavily used or what we thought was a good thing t= o promote -- and assuming that =C2=A0making base64url more available is a g= ood thing, than using it in OAuth is a good thing to do. :)</div> <div><br><blockquote type=3D"cite"><div class=3D"gmail_quote"> <div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"= margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-= left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid= ;padding-left:1ex"> <div style=3D"word-wrap:break-word"><div><div><blockquote type=3D"cite"><di= v class=3D"gmail_quote"> <div>=C2=A0</div><div><br></div><div><br></div><blockquote class=3D"gmail_q= uote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-lef= t:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-l= eft-style:solid;padding-left:1ex"> <div><br> ><br> >> I am unclear on what your point is.<br> >><br> >> The token would be included as one of the headers. This is often p= referable as it separates the authorization layer (in header) from applicat= ion layer parameters (query string or message body)<br> ><br> > With our proposal, we were focussed on url parameters (hence the choic= e of urlencode after it was all put together). I think it makes total sense= to not do the encoding as part of the sig spec, and let the transport choi= ce dictate which encoding to use.<br> <br> </div>I understand what you are saying. having multiple encodings makes lib= raries harder, and leads to the issues that motivated base64url over url-en= coding=C2=A0</blockquote></div></blockquote><div><br></div></div>Glad we ag= ree on that.</div> </div></blockquote><div><br></div><div>I agree multiple encodings makes lib= raries harder :)</div></div></blockquote><div><br></div></div><div>glad we = agree there</div><div><br></div></div><div><div><br><blockquote type=3D"cit= e"> <div class=3D"gmail_quote"><div><br></div><div>But I think the stark differ= ence between OAuth1 vs 2 wrt to signing actually makes the Authorization he= ader less valuable (again, for signing only). I'm pretty happy with thi= s because I thought this header was more complex for developers anyways (wh= ile big corporations with authentication infrastructure love it) :) But the= reason I think so is that now the header is not just the signature, but al= so the signed payload. This means an application isn't just making a ht= tp request as before with a bunch of query or post parameters. It's ins= tead making a "JSON request" that may or may not have query/post = params. It's just not as separate as before.</div> </div></blockquote><div><br></div></div><div>I am confused on what point yo= u are trying to make here.=C2=A0</div><div><br></div></div></div><br></div>= </div><div class=3D"im">_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></div></blockquote></div><br></div></div></div></div></div></div></div> </blockquote></div><br> --005045015aecbe2a19048ac60e77-- From dick.hardt@gmail.com Tue Jul 6 23:45:54 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37E63A6862 for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 23:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZlnfd2sbCG6 for <oauth@core3.amsl.com>; Tue, 6 Jul 2010 23:45:52 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 155143A6828 for <oauth@ietf.org>; Tue, 6 Jul 2010 23:45:52 -0700 (PDT) Received: by pzk6 with SMTP id 6so750128pzk.31 for <oauth@ietf.org>; Tue, 06 Jul 2010 23:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=oYQkhgtBp/ezY0g78qNTqcQWHaDEXkuj7Meph3+gAGs=; b=N6XwzLhcxwhmV1DmOZmiPhVW7pK3geTqAljikbVpZo1Zuf0z9OQyiqFNTiR9EH8Oz3 tG1yjBdQN4FqdF6i3jIt4be+5bfQsqxS+aqVNSiINhZ3s2xqPfr2HVUKzqgIN69CwIgI 8a5QjWwwMnliUquDeNugDj6RO2oGWJa9YhMks= 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=ARs/bkmvGnCNdxMYcTkvfN0utK/BV5vbzrg6hl1Yy2RFIyNhdRo9+XQ6x3OEDIFn3g s8/PzMoAeap9DEGoo12qHWwWNB723TJ2Ne3ULNwLlDtGcTe4zVH1rIBQbzCyJVn09Q83 xyjQo9r0owoBqA7PO/DVS1zg9WjmaQO84omBg= Received: by 10.142.125.20 with SMTP id x20mr6810962wfc.134.1278485151380; Tue, 06 Jul 2010 23:45:51 -0700 (PDT) Received: from [192.168.1.5] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id t11sm6845080wfc.4.2010.07.06.23.45.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Jul 2010 23:45:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-43--469762011 From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <AANLkTimoD2DRu2s6QgQUbBPLiYrCqtN02Oa-sk_Ag8yv@mail.gmail.com> Date: Tue, 6 Jul 2010 23:45:48 -0700 Message-Id: <63E303F0-C3EF-4D56-AFC2-9D5BB06DCFF6@gmail.com> References: <AANLkTimMruKyblUWROkPMDapFKtTztOXqL64PpQxCmKO@mail.gmail.com> <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <AANLkTinvLOV0f3I-aWpeAbfIpfGyxZSB2RHu52iw5mDC@mail.gmail.com> <AANLkTilWNneonIRX21U1RZcE80FuVSJWXU7CNm5pV275@mail.gmail.com> <AANLkTin-7PNLv-Hc229JJcOrIBh4fJqY5CMaLCMbmoIk@mail.gmail.com> <AANLkTikh_nQ8dXSp7QXJ79kCdbX1zeyPKAl_kgplb25x@mail.gmail.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> <AANLkTimpvWCbCBEWdI1Id5Ig_xCUW2hvKDro5LyhufMV@mail.gmail.com> <FE47FED0-3850-4393-9C79-DE06F0F7B6CA@gmail.com> <BA564125-9FBB-4B1A-93AC-7DD1A754A5E1@facebook.com> <C66A9854-02EB-4CCE-8338-382AEEC7EA61@gmail.com> <AANLkTikiXVruhZSH3Q6rMhdZAHRBPkhE_JVhSNOhCXmN@mail.gmail.com> <6B008ED4-4536-4A95-89B6-917696E6AF79@gmail.com> <AANLkTilTxGBYt2RFrEOqaYoLCV1TQOtonBh5dxL5PQCd@mail.gmail.com> <095B9543-1F20-4DA5-A8EB-48F86CDED9A6@gmail.com> <AANLkTimdWTqFd8UmcnYtYPZ3Dqzsffgn1HHwxPpnHcWY@mail.gmail.com> <AANLkTimoD2DRu2s6QgQUbBPLiYrCqtN02Oa-sk_Ag8yv@mail.g mail.com> To: Naitik Shah <n@daaku.org> X-Mailer: Apple Mail (2.1081) Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 06:45:54 -0000 --Apple-Mail-43--469762011 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yeah! On 2010-07-06, at 11:12 PM, Naitik Shah wrote: > I was hoping to avoid needing str_replace -- but I've been convinced. = I'm happy with base64url :) >=20 >=20 > Thanks, > -Naitik >=20 > On Tue, Jul 6, 2010 at 9:17 PM, Evan Gilbert <uidude@google.com> = wrote: > Hi all - having a little bit of a hard time following the full thread, = but I'm strongly in favor of base64url encoding. >=20 > A big advantage of this encoding is that, if token is base64url = encoded, then urlencode(token) =3D=3D token.=20 >=20 > This allows developers to avoid a large class of problems in dealing = with URL encoding / decoding issues - it is very easy to accidentally = double encode / decode values, and also easy to get tripped up on the = different encoding rules in different parts of a URL. For example, = different characters are OK before and after the hash, and not all = browsers decode the hash the same way. >=20 > Also being able to copy a value from a URL and use it directly in a = tool or Authorization header is invaluable for debugging. >=20 > Per notes above, the transformation is very straightforward. >=20 > Evan=20 >=20 > On Sat, Jul 3, 2010 at 12:45 PM, Dick Hardt <dick.hardt@gmail.com> = wrote: >=20 > On 2010-07-03, at 12:14 PM, Naitik Shah wrote: >=20 >> On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt <dick.hardt@gmail.com> = wrote: >>=20 >> On 2010-07-03, at 9:13 AM, Naitik Shah wrote: >>> > I think Naitik is saying that accidentally doing base64 and not = base64url will send some '+'s along. >>>=20 >>> if there are '+'s in the token, then it is easy for someone helping = to spot the problem. also easy for servers to send back an error message = saying, "hey, looks like you are using base64 instead of base64url = encoding" >>>=20 >>> ie, it is easy to detect the error -- urlencoding / decoding is hard = to detect as an error >>>=20 >>> The pluses are not guaranteed. They may or may not be there = depending on the data stream you're encoding. If you don't urlencode the = JSON, you'll get a "{", if you do it once, you'll get a "%7B", if you do = it twice, you'll get a "%257B" -- seems easier to detect. >>=20 >> Your earlier point was that developers may incorrectly use base64 = instead of base64url. If they used base64, and if there is a + / =3D or = % in the string, the server can send a useful note saying what is wrong. = There may not be one of those characters depending on the input string, = but if there is, then the server can suggest what the error might be = using base64 instead of base64url. If the token contains ANY character = that is not in base64url, then the server can say that it is not = base64url encoded. >>=20 >> That seems pretty fool proof to detect. Note that you should never = get any %7B or other encoding in the token as it is url safe. >>=20 >> The thing I was trying to say was that it's less predictable. That it = might work just fine when you're experimenting with the API because at = that point your token did not contain any pluses, but then suddenly = started failing after you sent a link to your app to someone because = their encoded token contains a plus. This hit-or-miss to me is worse = than being able to tell by looking at the first few characters of the = urlencoded JSON blob which will give a definitive answer as to how many = times the token has been urlencoded. >=20 > I understand your point. I still think base64url encoding makes it = really clear that it is encoded (nothing is legible anymore), allows = there to be one encoding format for all data, makes it easy to support = encryption. >=20 >=20 >>=20 >> =20 >>>=20 >>> When I wrote a sample in Perl, it was pretty easy to make it = base64url which then provides a consistent encoding. >>>=20 >>> Did it involve a string replace call? Or a third party library? >>=20 >> I used a standard CPAN library. >>=20 >>=20 >> Exactly :) I'm imagining our documentation where we want to be = library agnostic, and have almost psuedo code like code snippets. I said = this earlier -- while base64 may be common in standard libraries built = into languages, the base64url version isn't. In order to not have a = "cpan install base64url" (and gem install, easy_install, mvn install..) = -- we'ed most likely document a str_replace() call in addition to a = base64 call. And I'm worried that developers will miss this detail. >=20 > Likely they will install an OAuth library that will deal with it if = they are going to have to sign rather than using a bearer token (I = believe most people will use a bearer token if they can -- soooo much = easier!) >=20 > Besides base64url, there is HMAC256 and JSON -- not all of which are = built in -- but are becoming more built in as time goes on, and if OAuth = signing uses base64url, I would expect these will all be part of = standard distributions in the future ...=20 >=20 > (... in case you are unfamiliar with my backgroud, I have delivered = Perl, Python and Tcl distributions in the past -- what goes into a = packages is what is heavily used or what we thought was a good thing to = promote -- and assuming that making base64url more available is a good = thing, than using it in OAuth is a good thing to do. :) >=20 >>=20 >> =20 >>> =20 >>>=20 >>>=20 >>>=20 >>> > >>> >> I am unclear on what your point is. >>> >> >>> >> The token would be included as one of the headers. This is often = preferable as it separates the authorization layer (in header) from = application layer parameters (query string or message body) >>> > >>> > With our proposal, we were focussed on url parameters (hence the = choice of urlencode after it was all put together). I think it makes = total sense to not do the encoding as part of the sig spec, and let the = transport choice dictate which encoding to use. >>>=20 >>> I understand what you are saying. having multiple encodings makes = libraries harder, and leads to the issues that motivated base64url over = url-encoding=20 >>=20 >> Glad we agree on that. >>=20 >> I agree multiple encodings makes libraries harder :) >=20 > glad we agree there >=20 >=20 >>=20 >> But I think the stark difference between OAuth1 vs 2 wrt to signing = actually makes the Authorization header less valuable (again, for = signing only). I'm pretty happy with this because I thought this header = was more complex for developers anyways (while big corporations with = authentication infrastructure love it) :) But the reason I think so is = that now the header is not just the signature, but also the signed = payload. This means an application isn't just making a http request as = before with a bunch of query or post parameters. It's instead making a = "JSON request" that may or may not have query/post params. It's just not = as separate as before. >=20 > I am confused on what point you are trying to make here.=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 --Apple-Mail-43--469762011 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii <html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Yeah!<div><br><div><div>On 2010-07-06, at 11:12 PM, Naitik Shah wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p class="p1">I was hoping to avoid needing str_replace -- but I've been convinced. I'm happy with base64url :)</p> <div><br></div><div>Thanks,</div><div>-Naitik</div><br><div class="gmail_quote">On Tue, Jul 6, 2010 at 9:17 PM, Evan Gilbert <span dir="ltr"><<a href="mailto:uidude@google.com">uidude@google.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi all - having a little bit of a hard time following the full thread, but I'm strongly in favor of base64url encoding.<div> <br></div><div>A big advantage of this encoding is that, if token is base64url encoded, then urlencode(token) == token. </div> <div><br></div><div>This allows developers to avoid a large class of problems in dealing with URL encoding / decoding issues - it is very easy to accidentally double encode / decode values, and also easy to get tripped up on the different encoding rules in different parts of a URL. For example, different characters are OK before and after the hash, and not all browsers decode the hash the same way.</div> <div><br></div><div>Also being able to copy a value from a URL and use it directly in a tool or Authorization header is invaluable for debugging.</div><div><br></div><div>Per notes above, the transformation is very straightforward.</div> <div><br></div><div>Evan </div><div><div><div><div><div><div><div><br><div class="gmail_quote"><div><div></div><div class="h5">On Sat, Jul 3, 2010 at 12:45 PM, Dick Hardt <span dir="ltr"><<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>></span> wrote:<br> </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5"><div style="word-wrap:break-word"><br><div><div><div>On 2010-07-03, at 12:14 PM, Naitik Shah wrote:</div> <br> <blockquote type="cite">On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt <span dir="ltr"><<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div style="word-wrap:break-word"><br><div><div><div>On 2010-07-03, at 9:13 AM, Naitik Shah wrote:</div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex"> <div>> I think Naitik is saying that accidentally doing base64 and not base64url will send some '+'s along.<br> <br> </div>if there are '+'s in the token, then it is easy for someone helping to spot the problem. also easy for servers to send back an error message saying, "hey, looks like you are using base64 instead of base64url encoding"<br> <br> ie, it is easy to detect the error -- urlencoding / decoding is hard to detect as an error<br></blockquote><div><br></div><div>The pluses are not guaranteed. They may or may not be there depending on the data stream you're encoding. If you don't urlencode the JSON, you'll get a "{", if you do it once, you'll get a "%7B", if you do it twice, you'll get a "%257B" -- seems easier to detect.</div> </div></blockquote><div><br></div></div><div>Your earlier point was that developers may incorrectly use base64 instead of base64url. If they used base64, and if there is a + / = or % in the string, the server can send a useful note saying what is wrong. There may not be one of those characters depending on the input string, but if there is, then the server can suggest what the error might be using base64 instead of base64url. If the token contains ANY character that is not in base64url, then the server can say that it is not base64url encoded.</div> <div><br></div><div>That seems pretty fool proof to detect. Note that you should never get any %7B or other encoding in the token as it is url safe.</div></div></div></blockquote><div><br></div><div>The thing I was trying to say was that it's less predictable. That it might work just fine when you're experimenting with the API because at that point your token did not contain any pluses, but then suddenly started failing after you sent a link to your app to someone because their encoded token contains a plus. This hit-or-miss to me is worse than being able to tell by looking at the first few characters of the urlencoded JSON blob which will give a definitive answer as to how many times the token has been urlencoded.</div> </div></blockquote><div><br></div></div><div>I understand your point. I still think base64url encoding makes it really clear that it is encoded (nothing is legible anymore), allows there to be one encoding format for all data, makes it easy to support encryption.</div> <div><div><br></div><br><blockquote type="cite"><div class="gmail_quote"> <div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex"><div><font color="#000000"><br> </font> </div>When I wrote a sample in Perl, it was pretty easy to make it base64url which then provides a consistent encoding.<br></blockquote><div><br></div><div>Did it involve a string replace call? Or a third party library?</div> </div></blockquote><div><br></div></div><div>I used a standard CPAN library.</div><div><br></div></div></div></blockquote><div><br></div><div>Exactly :) I'm imagining our documentation where we want to be library agnostic, and have almost psuedo code like code snippets. I said this earlier -- while base64 may be common in standard libraries built into languages, the base64url version isn't. In order to not have a "cpan install base64url" (and gem install, easy_install, mvn install..) -- we'ed most likely document a str_replace() call in addition to a base64 call. And I'm worried that developers will miss this detail.</div> </div></blockquote><div><br></div></div><div>Likely they will install an OAuth library that will deal with it if they are going to have to sign rather than using a bearer token (I believe most people will use a bearer token if they can -- soooo much easier!)</div> <div><br></div><div>Besides base64url, there is HMAC256 and JSON -- not all of which are built in -- but are becoming more built in as time goes on, and if OAuth signing uses base64url, I would expect these will all be part of standard distributions in the future ... </div> <div><br></div><div>(... in case you are unfamiliar with my backgroud, I have delivered Perl, Python and Tcl distributions in the past -- what goes into a packages is what is heavily used or what we thought was a good thing to promote -- and assuming that  making base64url more available is a good thing, than using it in OAuth is a good thing to do. :)</div> <div><br><blockquote type="cite"><div class="gmail_quote"> <div><br></div><div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex"> <div style="word-wrap:break-word"><div><div><blockquote type="cite"><div class="gmail_quote"> <div> </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex"> <div><br> ><br> >> I am unclear on what your point is.<br> >><br> >> The token would be included as one of the headers. This is often preferable as it separates the authorization layer (in header) from application layer parameters (query string or message body)<br> ><br> > With our proposal, we were focussed on url parameters (hence the choice of urlencode after it was all put together). I think it makes total sense to not do the encoding as part of the sig spec, and let the transport choice dictate which encoding to use.<br> <br> </div>I understand what you are saying. having multiple encodings makes libraries harder, and leads to the issues that motivated base64url over url-encoding </blockquote></div></blockquote><div><br></div></div>Glad we agree on that.</div> </div></blockquote><div><br></div><div>I agree multiple encodings makes libraries harder :)</div></div></blockquote><div><br></div></div><div>glad we agree there</div><div><br></div></div><div><div><br><blockquote type="cite"> <div class="gmail_quote"><div><br></div><div>But I think the stark difference between OAuth1 vs 2 wrt to signing actually makes the Authorization header less valuable (again, for signing only). I'm pretty happy with this because I thought this header was more complex for developers anyways (while big corporations with authentication infrastructure love it) :) But the reason I think so is that now the header is not just the signature, but also the signed payload. This means an application isn't just making a http request as before with a bunch of query or post parameters. It's instead making a "JSON request" that may or may not have query/post params. It's just not as separate as before.</div> </div></blockquote><div><br></div></div><div>I am confused on what point you are trying to make here. </div><div><br></div></div></div><br></div></div><div class="im">_______________________________________________<br> OAuth mailing list<br> <a href="mailto:OAuth@ietf.org" target="_blank">OAuth@ietf.org</a><br> <a href="https://www.ietf.org/mailman/listinfo/oauth" target="_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> <br></div></blockquote></div><br></div></div></div></div></div></div></div> </blockquote></div><br> </blockquote></div><br></div></body></html> --Apple-Mail-43--469762011-- From lr@lukasrosenstock.net Wed Jul 7 00:38:56 2010 Return-Path: <lr@lukasrosenstock.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735043A685F for <oauth@core3.amsl.com>; Wed, 7 Jul 2010 00:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tDzVOrfqjlk for <oauth@core3.amsl.com>; Wed, 7 Jul 2010 00:38:52 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 912213A6767 for <oauth@ietf.org>; Wed, 7 Jul 2010 00:38:52 -0700 (PDT) Received: by vws14 with SMTP id 14so7177107vws.31 for <oauth@ietf.org>; Wed, 07 Jul 2010 00:38:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.181.138 with SMTP id by10mr3531256qcb.257.1278488332419; Wed, 07 Jul 2010 00:38:52 -0700 (PDT) Received: by 10.229.100.135 with HTTP; Wed, 7 Jul 2010 00:38:52 -0700 (PDT) In-Reply-To: <fb663df2-1ef3-4248-8124-312f49b504cb@s9g2000yqd.googlegroups.com> References: <fb663df2-1ef3-4248-8124-312f49b504cb@s9g2000yqd.googlegroups.com> Date: Wed, 7 Jul 2010 09:38:52 +0200 Message-ID: <AANLkTinPiBSVHFzzYmUHk44Nm7Ky3PmIid2x92Hr7Uiu@mail.gmail.com> From: Lukas Rosenstock <lr@lukasrosenstock.net> To: epsilonsso@gmail.com, oauth@googlegroups.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] [oauth] Enterprise usage question: Role based access and scope parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 07:38:56 -0000 "scope" is about the permissions that a client application is requesting. But if those permissions are inherently bound to the users becaus the users have certain roles, the Access Token requested for a user can be bound to those roles by the Authorization server. I don't feel there's a requirement to use "scope" at all. If, however, you want client applications to specifically state for which role they're requesting access, there's nothing to prevent you from implementing the scheme suggested. The specification doesn't state any format of scopes and neither does it say anything on how the scope values are converted into actual access privileges. Regards, Lukas Rosenstock 2010/7/6 wjgerritsen <epsilonsso@gmail.com>: > Hi, > > I am playing with the idea of using role names in the scope parameter > (of RequestToken endpoint) for authorizing to our platform. It will > work somehow like this: A user has a number of roles: e.g. SalesRep, > Employee, Manager. To each role a consistent privilege set is > assigned, so the user would also be able to use (part of) the > functionality of the platform with only one role. > > Then the token would be bound to a certain role (e.g. SalesRep), such > that the consumer app cannot excercise all privileges of the user, but > only those limited to the assigned scope, which is a role. Upon app > registration, it will be made clear which roles are liable for the > scope parameter. > > Any comments? > > regards, > Willem Jan > > -- > You received this message because you are subscribed to the Google Groups "OAuth" group. > To post to this group, send email to oauth@googlegroups.com. > To unsubscribe from this group, send email to oauth+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/oauth?hl=en. > > From michael.d.adams@gmail.com Wed Jul 7 00:57:23 2010 Return-Path: <michael.d.adams@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F513A657C for <oauth@core3.amsl.com>; Wed, 7 Jul 2010 00:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n71E+CeLHkM for <oauth@core3.amsl.com>; Wed, 7 Jul 2010 00:57:22 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 75CDD3A67CC for <oauth@ietf.org>; Wed, 7 Jul 2010 00:57:22 -0700 (PDT) Received: by iwn38 with SMTP id 38so1997412iwn.31 for <oauth@ietf.org>; Wed, 07 Jul 2010 00:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=VjidK/zGGYpDJQHD7Gy56THPO6D6ffW/E5ME++g5SSg=; b=iPbORXjVlzu2w7UqMJbL5fnlqE98BWNyWy7o4QxUkiQcOvDe9WduW3EC9k/PXsSqxD YUy/zhnsb++9On18thyEKmAf9nthgpU4jy4A10/NyqREm++P33NTDwsIua208rqzON99 XUzxF7AnWjmXH8GStm9s/qjz+00XUPUTxpt6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=W4YFnue/zAThGr+MhU6vVwyAZc18g5vSIOWBB9A56DuNoYdmcg/HAuk+m0bo32hsrZ TXlNXVJXEHTskTEoGPm225DeivC0CBEvRlPkF41mXm1i2KeKj9TpdoepAOMAIddSabMc dKdkH8i8D21Zidb/fWfyPDKKiZLSxWY+keni4= Received: by 10.231.32.69 with SMTP id b5mr6370854ibd.153.1278489445184; Wed, 07 Jul 2010 00:57:25 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.179.143 with HTTP; Wed, 7 Jul 2010 00:57:04 -0700 (PDT) In-Reply-To: <AANLkTikDx54ypvWMlZXGlgXsBi3wErcs3-SxO2hYVQYW@mail.gmail.com> References: <1278439815.2445.8.camel@localhost.localdomain> <C858C2B1.36C16%eran@hueniverse.com> <AANLkTimWZugW68Gkg_CCYZL8TUIbtaNEAlQS7cMTTSZV@mail.gmail.com> <AANLkTimsxRHsXggcEsQhgD04YgbdUlrm_rojSi_SLc-X@mail.gmail.com> <AANLkTikDx54ypvWMlZXGlgXsBi3wErcs3-SxO2hYVQYW@mail.gmail.com> From: Michael D Adams <mike@automattic.com> Date: Wed, 7 Jul 2010 00:57:04 -0700 X-Google-Sender-Auth: WyK6AHsjxqXAFyl1f4VChGI2TbY Message-ID: <AANLkTinZTSR-ZIe2kZYYLVKDRkr68JEHP7vxtyOroHGa@mail.gmail.com> To: Marius Scurtescu <mscurtescu@google.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 07:57:23 -0000 On Tue, Jul 6, 2010 at 10:24 PM, Marius Scurtescu <mscurtescu@google.com> wrote: > On Tue, Jul 6, 2010 at 10:18 PM, Michael D Adams <mike@automattic.com> wrote: >> For section 6.2 (query parameters on the end-user authorization and >> token endpoints), this should not be an issue for WordPress. >> >> For section 6.3 (header parameters), this should not be an issue for WordPress. > > This is not an issue because whatever query parameter WordPress is > using does not collide with the core OAuth 2 parameters? Or because > WordPress is not using query parameters? Neither: because WordPress is extensible enough to allow for this kind of functionality. WordPress uses query parameters. A WordPress plugin that enables OAuth, though, would have to register new URL handlers with WordPress to act as the token and end-user authorization endpoints. Having done so, the plugin would then have complete control over how to behave under any query parameters, entity-body contents, or headers: core, extension, site specific or otherwise. As evidence, I have written such plugins for OAuth 1.0a, OAuth WRAP, and OAuth 2.0-draft-05. I would be surprised if the story were different for MediaWiki and Drupal; I naively believe a similar plugin could be developed for each of those platforms that would avoid query parameter collision. "Naively" because I am unfamiliar with both of those platforms. Mike --mdawaffe From michael.d.adams@gmail.com Wed Jul 7 01:10:28 2010 Return-Path: <michael.d.adams@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55EE3A6880 for <oauth@core3.amsl.com>; Wed, 7 Jul 2010 01:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXmsPAVtw5ut for <oauth@core3.amsl.com>; Wed, 7 Jul 2010 01:10:27 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7B9123A6883 for <oauth@ietf.org>; Wed, 7 Jul 2010 01:10:27 -0700 (PDT) Received: by iwn38 with SMTP id 38so2007986iwn.31 for <oauth@ietf.org>; Wed, 07 Jul 2010 01:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=wqjFpTSUnOmyDAoXGi3OGlAi4uUIYcxx6GuJ0R+24XY=; b=eRBuH0OnbGu1j+WqCx/lw7+j7F8soYJEgvIrRn7sF9/ri9RJ2FPR7Lcx01b1HlAx9A rGDihuy1dEmFzynUeNVH8F1C4uOXtY+INu/Pbt4VuXh1PSGP0b/cfoUwK6vAComt/OsA KiG/+WX6IF8VPsS9NMJIxNWnM3ugitUjA/MsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=f/RJtf5XR2Dzi+LMXG8suDA5U+bwoNjLWQqYqhAnBZjNTgbyTuFdOOpqMHVhb3oLRL V99mHikI1oc95MTvnA8Ym7FIctqv6LWtu8As3BFBJuch2yL5QP6oCKJMIfEiKv6R9hAr MWcli9r8Pyy1PV4nOjS/nfRHLB31/cdbUrgXE= Received: by 10.231.178.103 with SMTP id bl39mr5404041ibb.138.1278490230119; Wed, 07 Jul 2010 01:10:30 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.179.143 with HTTP; Wed, 7 Jul 2010 01:10:10 -0700 (PDT) In-Reply-To: <AANLkTinZTSR-ZIe2kZYYLVKDRkr68JEHP7vxtyOroHGa@mail.gmail.com> References: <1278439815.2445.8.camel@localhost.localdomain> <C858C2B1.36C16%eran@hueniverse.com> <AANLkTimWZugW68Gkg_CCYZL8TUIbtaNEAlQS7cMTTSZV@mail.gmail.com> <AANLkTimsxRHsXggcEsQhgD04YgbdUlrm_rojSi_SLc-X@mail.gmail.com> <AANLkTikDx54ypvWMlZXGlgXsBi3wErcs3-SxO2hYVQYW@mail.gmail.com> <AANLkTinZTSR-ZIe2kZYYLVKDRkr68JEHP7vxtyOroHGa@mail.gmail.com> From: Michael D Adams <mike@automattic.com> Date: Wed, 7 Jul 2010 01:10:10 -0700 X-Google-Sender-Auth: gMt-y0w6RRoqBA4TTAnPoY4fzEM Message-ID: <AANLkTimY78I-0BC94XVSffwe-sS3HKamXzX39pj04JKE@mail.gmail.com> To: Marius Scurtescu <mscurtescu@google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 08:10:28 -0000 On Wed, Jul 7, 2010 at 12:57 AM, Michael D Adams <mike@automattic.com> wrot= e: > WordPress uses query parameters. =A0A WordPress plugin that enables > OAuth, though, would have to register new URL handlers with WordPress > to act as the token and end-user authorization endpoints. =A0Having done > so, the plugin would then have complete control over how to behave > under any query parameters, entity-body contents, or headers: core, > extension, site specific or otherwise. Actually, for a small minority of WordPress sites wanting to enable OAuth (those not supporting so called "pretty permalinks"), the WordPress plugin would need to internally reserve one query parameter to get the ball rolling. Theoretically, that need leads to the possibility of conflict, but I'm not worried about it. Mike --mdawaffe From jricher@mitre.org Wed Jul 7 07:43:06 2010 Return-Path: <jricher@mitre.org> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551493A6875 for <oauth@core3.amsl.com>; Wed, 7 Jul 2010 07:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 9120hg8tEn+l for <oauth@core3.amsl.com>; Wed, 7 Jul 2010 07:43:05 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 71D323A6877 for <oauth@ietf.org>; Wed, 7 Jul 2010 07:42:55 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o67Egvkj001371 for <oauth@ietf.org>; Wed, 7 Jul 2010 10:42:58 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o67EgvrA001366; Wed, 7 Jul 2010 10:42:57 -0400 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, 7 Jul 2010 10:42:57 -0400 From: Justin Richer <jricher@mitre.org> To: Marius Scurtescu <mscurtescu@google.com> In-Reply-To: <AANLkTimfbRxKhUSV-Ydz_YGv-aE1VaQGgIFsdJ7qgut2@mail.gmail.com> References: <AANLkTintGxCh-Pk1Wd5nubBm8qM96ZUb3TQ5Iuf0GQ07@mail.gmail.com> <AANLkTimfbRxKhUSV-Ydz_YGv-aE1VaQGgIFsdJ7qgut2@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 7 Jul 2010 10:42:56 -0400 Message-ID: <1278513776.2445.26.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Draft 9, Section 4.1.1 missing several parameters X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 14:43:06 -0000 +1 on reference to section 2. Also, in 4.1.1, the wording in the last paragraph makes it sound like the client_secret is REQUIRED for flows using the authorization code, when as per section 2 the secret is only required IF a secret was issued with the client_id. Wording such as found in 4.1.2 is a better fit overall: The authorization server MUST validate the client credentials [link to Section 2 here] ... -- Justin On Tue, 2010-07-06 at 22:42 -0400, Marius Scurtescu wrote: > How the client authenticates itself is covered in section 2, and > client_id plus client_secret in 2.1. > > The first paragraph of section 4 mentions this in a general way, but I > think an explicit pointer to section 2 would help. > > Regarding the last paragraph of 4.1.1, since it explains the example, > it probably makes sense to mention client id and secret. Again, a > direct reference to 2.1 may help. > > Marius > > > > On Sat, Jul 3, 2010 at 2:28 PM, Andrew Arnott <andrewarnott@gmail.com> wrote: > > Section 4.1.1, which deals with requesting an access token using an > > authorization code, doesn't list the client_id and client_secret parameters > > at all, yet mentions verifying them in paragraph form, and they are included > > in the example. > > -- > > Andrew Arnott > > "I [may] not agree with what you have to say, but I'll defend to the death > > your right to say it." - S. G. Tallentyre > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Wed Jul 7 09:40:55 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B08A3A679F for <oauth@core3.amsl.com>; Wed, 7 Jul 2010 09:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.47 X-Spam-Level: X-Spam-Status: No, score=-103.47 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYFXUxeNgoMq for <oauth@core3.amsl.com>; Wed, 7 Jul 2010 09:40:54 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 821C73A6804 for <oauth@ietf.org>; Wed, 7 Jul 2010 09:40:54 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o67GeuWB032266 for <oauth@ietf.org>; Wed, 7 Jul 2010 09:40:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278520857; bh=n4l+6z6eFMEspuFHDx4+HNHQ1Tg=; h=MIME-Version:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=gl+vffgmdObQCngRSRedpkirmRuJghnedW9J44NBOU7o89Y6bK7Hnc33TLm4b+P6F uMqfs2peDP2a7NSKIeNwA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:cc: content-type:x-system-of-record; b=bc10KJrLv/FA4We82wN6PBUETC1LojEy5QXvaGUWdRb9dYUMkccjEieh38hbCPyR+ kKM0dCsNMi3+sY5pnaLwg== Received: from pvd12 (pvd12.prod.google.com [10.241.209.204]) by hpaq5.eem.corp.google.com with ESMTP id o67Gek1W021204 for <oauth@ietf.org>; Wed, 7 Jul 2010 09:40:55 -0700 Received: by pvd12 with SMTP id 12so3119793pvd.3 for <oauth@ietf.org>; Wed, 07 Jul 2010 09:40:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.172.17 with SMTP id u17mr8348169wfe.78.1278520854890; Wed, 07 Jul 2010 09:40:54 -0700 (PDT) Received: by 10.142.187.19 with HTTP; Wed, 7 Jul 2010 09:40:54 -0700 (PDT) Date: Wed, 7 Jul 2010 09:40:54 -0700 Message-ID: <AANLkTimZA96oJMHEhxaKtvK4yx6Bxc636z703Sf_bsoT@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, Blaine Cook <romeda@gmail.com>, Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 16:40:55 -0000 Hi folks - What is the story with the evolution of the assertion profile? As far as I can tell, it keeps changing for no good reason. Everyone who wants to implement the profile has the exact same requirements, and agreed on how it should work a long time ago. Here's the timeline: - a bunch of people get together and do WRAP. It contains a flow that exchanges a signed assertion for a short-lived bearer token. - WRAP becomes OAuth2. Assertion profile is dropped. - People protest. - Assertion profile is added back. - OAuth2 interim meeting: a bunch of people stand up and say they either have implemented or are implementing the assertion profile. (Note that this is a superset of the people who worked on WRAP. More organizations have come on board.) - Everything is fine until draft 7 of the OAuth 2 spec is published. Assertion profile has changed, security is screwed up. People protest. - Draft 8 makes it even worse, adding new secrets with no visible purpose. - Yaron notices, complains, is told that he should write new spec language. - Yaron writes new language. - Argument starts over whether this is really necessary. This is beginning to seem brain dead. Can we please put the assertion profile back the way it was in WRAP and Draft 6 of the OAuth 2 spec? This is a critical use case for a bunch of companies, all of whom have already agreed on how it should work, and most of whom already have working implementations. It's fine with me if people have other use cases for assertions, and need new protocol flows to support those use cases. But that's a terrible reason to screw up the existing use cases. Cheers, Brian From mscurtescu@google.com Wed Jul 7 10:37:00 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117EB3A68C0 for <oauth@core3.amsl.com>; Wed, 7 Jul 2010 10:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[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 FislEXalsKpQ for <oauth@core3.amsl.com>; Wed, 7 Jul 2010 10:36:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id BCDCF3A68BC for <oauth@ietf.org>; Wed, 7 Jul 2010 10:31:41 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id o67HVW3I026485 for <oauth@ietf.org>; Wed, 7 Jul 2010 10:31:32 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278523893; bh=zxGrk37LMMqr/Y2I5b22teGdJDM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=AT+XgRw6fiW50I0Aohp/I1fQbLSdzTossXKAgfNRpg3z8pPkradyaGVxK0OmToicI MfzcsngyVWCJPPSJYlgrw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=h4UKcjSQbIZTpNw0feRnLZJqGMTZrhXY+AnAsQlPNWC4uWtfWdybl/skAhIYHWVED BImgA9xXPP3ZrHe//Qayg== Received: from gwj17 (gwj17.prod.google.com [10.200.10.17]) by hpaq11.eem.corp.google.com with ESMTP id o67HVVuX021388 for <oauth@ietf.org>; Wed, 7 Jul 2010 10:31:31 -0700 Received: by gwj17 with SMTP id 17so4167682gwj.23 for <oauth@ietf.org>; Wed, 07 Jul 2010 10:31:31 -0700 (PDT) Received: by 10.100.194.10 with SMTP id r10mr8447415anf.225.1278523891158; Wed, 07 Jul 2010 10:31:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Wed, 7 Jul 2010 10:31:11 -0700 (PDT) In-Reply-To: <AANLkTimY78I-0BC94XVSffwe-sS3HKamXzX39pj04JKE@mail.gmail.com> References: <1278439815.2445.8.camel@localhost.localdomain> <C858C2B1.36C16%eran@hueniverse.com> <AANLkTimWZugW68Gkg_CCYZL8TUIbtaNEAlQS7cMTTSZV@mail.gmail.com> <AANLkTimsxRHsXggcEsQhgD04YgbdUlrm_rojSi_SLc-X@mail.gmail.com> <AANLkTikDx54ypvWMlZXGlgXsBi3wErcs3-SxO2hYVQYW@mail.gmail.com> <AANLkTinZTSR-ZIe2kZYYLVKDRkr68JEHP7vxtyOroHGa@mail.gmail.com> <AANLkTimY78I-0BC94XVSffwe-sS3HKamXzX39pj04JKE@mail.gmail.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Wed, 7 Jul 2010 10:31:11 -0700 Message-ID: <AANLkTiln5m_ZxSfp6Kt_1Za53E-902gFIHCko_Xj0RN_@mail.gmail.com> To: Michael D Adams <mike@automattic.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 17:37:05 -0000 On Wed, Jul 7, 2010 at 1:10 AM, Michael D Adams <mike@automattic.com> wrote= : > On Wed, Jul 7, 2010 at 12:57 AM, Michael D Adams <mike@automattic.com> wr= ote: >> WordPress uses query parameters. =A0A WordPress plugin that enables >> OAuth, though, would have to register new URL handlers with WordPress >> to act as the token and end-user authorization endpoints. =A0Having done >> so, the plugin would then have complete control over how to behave >> under any query parameters, entity-body contents, or headers: core, >> extension, site specific or otherwise. > > Actually, for a small minority of WordPress sites wanting to enable > OAuth (those not supporting so called "pretty permalinks"), the > WordPress plugin would need to internally reserve one query parameter > to get the ball rolling. =A0Theoretically, that need leads to the > possibility of conflict, but I'm not worried about it. As far as I can tell pretty permalinks also use mod_rewrite so the PHP code still sees the query parameter. Yes, chances for conflict are very small, I agree. Marius From cmortimore@salesforce.com Wed Jul 7 10:52:15 2010 Return-Path: <cmortimore@salesforce.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2F63A68CC for <oauth@core3.amsl.com>; Wed, 7 Jul 2010 10:52:15 -0700 (PDT) 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 xMrlVi4cp9Dm for <oauth@core3.amsl.com>; Wed, 7 Jul 2010 10:52:10 -0700 (PDT) Received: from exprod8og108.obsmtp.com (exprod8og108.obsmtp.com [64.18.3.96]) by core3.amsl.com (Postfix) with SMTP id 514B73A68BE for <oauth@ietf.org>; Wed, 7 Jul 2010 10:52:10 -0700 (PDT) Received: from source ([204.14.239.238]) by exprod8ob108.postini.com ([64.18.7.12]) with SMTP ID DSNKTDS+zUsAcismQidINGSpP7BsxM9ZS/nl@postini.com; Wed, 07 Jul 2010 10:52:14 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Wed, 7 Jul 2010 10:52:12 -0700 From: Chuck Mortimore <cmortimore@salesforce.com> To: Brian Eaton <beaton@google.com>, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, Blaine Cook <romeda@gmail.com>, Eran Hammer-Lahav <eran@hueniverse.com> Date: Wed, 7 Jul 2010 10:52:11 -0700 Thread-Topic: [OAUTH-WG] assertion profile changes Thread-Index: Acsd8zAYMMRFM+CHSiOJagu+uvV8GgACe/YR Message-ID: <C85A0CDB.7EDA%cmortimore@salesforce.com> In-Reply-To: <AANLkTimZA96oJMHEhxaKtvK4yx6Bxc636z703Sf_bsoT@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85A0CDB7EDAcmortimoresalesforcecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 07 Jul 2010 17:52:15 -0000 --_000_C85A0CDB7EDAcmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good catch Brian - client_id and client_secret now seem mandatory when read= ing draft 9. When those were originally added to the flow, they were clea= rly marked as optional. That is lost in the latest drafts. We'd be happy with either optional or removed. Mandatory doesn't work for= us at all. -cmort On 7/7/10 9:40 AM, "Brian Eaton" <beaton@google.com> wrote: Hi folks - What is the story with the evolution of the assertion profile? As far as I can tell, it keeps changing for no good reason. Everyone who wants to implement the profile has the exact same requirements, and agreed on how it should work a long time ago. Here's the timeline: - a bunch of people get together and do WRAP. It contains a flow that exchanges a signed assertion for a short-lived bearer token. - WRAP becomes OAuth2. Assertion profile is dropped. - People protest. - Assertion profile is added back. - OAuth2 interim meeting: a bunch of people stand up and say they either have implemented or are implementing the assertion profile. (Note that this is a superset of the people who worked on WRAP. More organizations have come on board.) - Everything is fine until draft 7 of the OAuth 2 spec is published. Assertion profile has changed, security is screwed up. People protest. - Draft 8 makes it even worse, adding new secrets with no visible purpose. - Yaron notices, complains, is told that he should write new spec language. - Yaron writes new language. - Argument starts over whether this is really necessary. This is beginning to seem brain dead. Can we please put the assertion profile back the way it was in WRAP and Draft 6 of the OAuth 2 spec? This is a critical use case for a bunch of companies, all of whom have already agreed on how it should work, and most of whom already have working implementations. It's fine with me if people have other use cases for assertions, and need new protocol flows to support those use cases. But that's a terrible reason to screw up the existing use cases. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C85A0CDB7EDAcmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [OAUTH-WG] assertion profile changes Good catch Bria= n - client_id and client_secret now seem mandatory when reading draft 9. &n= bsp; When those were originally added to the flow, they were clearly m= arked as optional.   That is lost in the latest drafts.  &nb= sp;

We’d be happy with either optional or removed.   Mandatory = doesn’t work for us at all.

-cmort


On 7/7/10 9:40 AM, "Brian Eaton" <beaton@google.com> wrote:

Hi folks -

What is the story with the evolution of the assertion profile?

As far as I can tell, it keeps changing for no good reason.  Everyone = who
wants to implement the profile has the exact same requirements, and
agreed on how it should work a long time ago.

Here's the timeline:

- a bunch of people get together and do WRAP.  It contains a flow that=
exchanges a signed assertion for a short-lived bearer token.

- WRAP becomes OAuth2.  Assertion profile is dropped.

- People protest.

- Assertion profile is added back.

- OAuth2 interim meeting: a bunch of people stand up and say they
either have implemented or are implementing the assertion profile.
(Note that this is a superset of the people who worked on WRAP.  More<= BR> organizations have come on board.)

- Everything is fine until draft 7 of the OAuth 2 spec is published.
Assertion profile has changed, security is screwed up.  People
protest.

- Draft 8 makes it even worse, adding new secrets with no visible purpose.<= BR>
- Yaron notices, complains, is told that he should write new spec language.=

- Yaron writes new language.

- Argument starts over whether this is really necessary.

This is beginning to seem brain dead.

Can we please put the assertion profile back the way it was
in WRAP and Draft 6 of the OAuth 2 spec?  This is a critical use case<= BR> for a bunch of companies, all of whom have already agreed on how it
should work, and most of whom already have working implementations.

It's fine with me if people have other use cases for assertions, and
need new protocol flows to support those use cases.  But that's a
terrible reason to screw up the existing use cases.

Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C85A0CDB7EDAcmortimoresalesforcecom_-- From michael.d.adams@gmail.com Wed Jul 7 12:16: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 3F3473A68BF for ; Wed, 7 Jul 2010 12:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmSCJXA69Hb3 for ; Wed, 7 Jul 2010 12:15:59 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 645513A6909 for ; Wed, 7 Jul 2010 12:15:57 -0700 (PDT) Received: by iwn38 with SMTP id 38so9777iwn.31 for ; Wed, 07 Jul 2010 12:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=cOzPJaBMxjX2lpchcopDBludH/+S0u0xChkm1HGn6zQ=; b=X/26EfeV5aIDMtOeh3/eRZLb30SxMc5poMd6dLC314/IOAvn8wEYjR4N8dh3McX0vF 8Pv4YHFIzBiqEmiDcSGV5cXh1SJpM5uLHuHq61b2XRAab6Kvr5jSvY9eHATBQ08oClSa FgR+Ynzcg9HuzE/AlkkRtsX2XAgDbUVeirGW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=gHGonz7Fzxgvp3Y7LSHSFW72g9C2Iw5IbkiQWHZp0DXO/UstTUunuFmucqWsl9eNex WDKb7Wm+0SmSW4lsmKDYtO7WRDNvOjQhKGM01oLElELTyqcOWm9GuHDByuzD7LSwKE9q rQtiulbVVtsrjVY+J64dtDxciXrNyBiBL9E58= Received: by 10.231.174.136 with SMTP id t8mr7387892ibz.158.1278530158360; Wed, 07 Jul 2010 12:15:58 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.179.143 with HTTP; Wed, 7 Jul 2010 12:15:38 -0700 (PDT) In-Reply-To: References: <1278439815.2445.8.camel@localhost.localdomain> From: Michael D Adams Date: Wed, 7 Jul 2010 12:15:38 -0700 X-Google-Sender-Auth: uQwI-idc0XYNU9LSuwi0Qvpbops Message-ID: To: Marius Scurtescu Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 19:16:00 -0000 On Wed, Jul 7, 2010 at 10:31 AM, Marius Scurtescu wrote: > On Wed, Jul 7, 2010 at 1:10 AM, Michael D Adams wrote: >> Actually, for a small minority of WordPress sites wanting to enable >> OAuth (those not supporting so called "pretty permalinks"), the >> WordPress plugin would need to internally reserve one query parameter >> to get the ball rolling. Theoretically, that need leads to the >> possibility of conflict, but I'm not worried about it. > > As far as I can tell pretty permalinks also use mod_rewrite so the PHP > code still sees the query parameter. Yes. The point is that the plugin can intercept the request early enough that it doesn't matter. There is a small chance for conflict, but the conflict is not inherent to the core spec or to the spec of an extension, only to the particular implementation of the plugin. In the pretty permalink case, the conflict can easily be addressed with a new release of the plugin (developed, out the door, and pulled to all sites in a day) without changing endpoints or otherwise breaking clients. In the ugly link case, you might need to change the endpoints' URLs. Any "serious" site will be using pretty permalinks. This situation seems acceptable to me. With a new extension, you need a new release of the plugin anyway (or the release of a plugin for the plugin). You're blocking deployment on development, which is always true. All of this to say: WordPress is flexible enough to implement the current spec, and I predict that WordPress is flexible enough to implement the final spec. I believe no special consideration need be given WordPress in the spec writing process. If I see anything, I'll raise the issue. Mike --mdawaffe From eran@hueniverse.com Wed Jul 7 12:47: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 9C10E3A690A for ; Wed, 7 Jul 2010 12:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.173 X-Spam-Level: X-Spam-Status: No, score=-1.173 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_HRDCOR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-wRbjMCJtyR for ; Wed, 7 Jul 2010 12:47:11 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 3E27F3A68FD for ; Wed, 7 Jul 2010 12:47:11 -0700 (PDT) Received: (qmail 29628 invoked from network); 7 Jul 2010 19:47:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Jul 2010 19:47:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 7 Jul 2010 12:47:14 -0700 From: Eran Hammer-Lahav To: Evan Gilbert , Andrew Arnott Date: Wed, 7 Jul 2010 12:47:12 -0700 Thread-Topic: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) Thread-Index: AcsdjYsFyOAhm5idTVa80jbY497rpAAf6Y+w Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85A27D036CE8eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 19:47:22 -0000 --_000_C85A27D036CE8eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The issue is that it is hard (or even impossible) to prevent another user-a= gent client from imitating another user-agent client. A pre-registered redi= rection URI does very little to help. In most cases, such a URI will point = to a web page with a script that will extract the information and pass it t= o the parent frame. This means any client can get hold of the access token = as long as it was the parent. If you use immediate with a user-agent flow, the script running in the user= -agent will get the access token by pretending to be another client which w= as already granted access. Since there is no way to authenticate the user-a= gent client, there is no way for the resource at the redirection URI to aut= henticate the client - meaning that it can be used by others. Immediate mode for user-agent clients takes away the only security safeguar= d which is the explicit end-user approval for whatever is going on on front= of him or her. EHL On 7/6/10 9:31 PM, "Evan Gilbert" wrote: On Tue, Jul 6, 2010 at 12:49 PM, Andrew Arnott wro= te: If we can agree that it is useless from a security perspective (and I think= we agree on that by now), then an auth server must not ever issue an acces= s token to a user agent client without interacting with the user (no "immed= iate" mode issuing of access tokens) so the user is aware that some anonymo= us client on the web page is trying to access their data, since there's no = assurance whatsoever about which client that is, and whether the user trust= s it. If anyone disagrees, please explain how you can justify it, in light of the= fact that leaving it as-is means once one client is authorized, the whole = world is authorized by just pretending to be that one client. It might as = well be a "make my data public" switch at the resource server to authorize = a client such that it gets an access token directly without a client secret= . I'm not sure I understand the concerns. The User Agent flow of course can't= send back a token to an arbitrary URL - regardless of whether there is use= r interaction or not. Callback URLs need to be validated - this can be via pre-registration to as= sociate a URL with a client_id or by the user approving the specific callba= ck URL. Any reasons why this isn't secure? (Not the muddy the waters, but again, I know client secrets don't add value= when the client is on an uncontrolled machine. Please don't let that tech= nical hurdle stop you from justifying the status quo in draft 9 of the spec= ). -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre On Mon, Jul 5, 2010 at 10:27 PM, William Mills wrote= : It's not verifiable, but it is as useful in this case as a "user agent" str= ing. Not usefule formt he security perspective, but has some utility in ap= plication tracking. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Andrew Arnott Sent: Saturday, July 03, 2010 12:16 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth= response code-and-token's scope parameter) (this sounds sarcastic, but I'm no being sarcastic... it's a serious quest= ion/challenge)... Why not just remove the client_id parameter from the user-agent flow? It'= s absolutely meaningless to security. It's only perceivable benefit is th= at the auth server can possible display to the user the client being autho= rized or the list of previously authorized clients. But again, that's tot= ally meaningless if not verified. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death= your right to say it." - S. G. Tallentyre On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott wr= ote: On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav wro= te: You are putting too much weight on the value of redirection URI registrati= on. Since the same problem exists between the user-agent script and the s= erver-side component used in the user-agent profile, anyone can imitate th= at flow. In most cases, the redirection URI will simply include a script t= hat will pass the parameter to the *parent* window which can be anything. = If the server-based page is an active page, it still needs to communicate = with the user-agent, which again, can pretend to be that. Good point. I wasn't imagining that far through it. Not to deny that mos= t redirection URLs may just return a straight script that passes it to the= parent window, but that seems pretty irresponsible to the host that's doi= ng it -- because of the enormous security hole it opens up. Some client i= s trusted enough to authorize (by the user and auth server), receives an a= ccess token it wasn't expecting, and then blindly forwards it onto whoever= wants it. Yikes. I sure hope these access tokens have very limited scop= e (like, I'd prefer none myself). I was about to describe how an active server could alleviate that by signi= ng the original request using the state parameter, but I realized I'm solv= ing a problem that the web server flow (or nowadays that the authorization= code mode as I guess it's called) already solves. So I guess I just need= to bite the bullet and accept that the user agent flow is totally insecur= e for web clients, and thus very special care must be taken to enable nati= ve clients without opening up the web client hole. Sorry to sound so negative about it. Enabling this scenario seems really = important to me as well -- I just am against doing it when it can't be sec= ured in some way. Seriously... as is, once you authorize any client, you'= ve authorized them all, including clients not even running on your compute= r. I guess this answers how I was visiting a site a few days ago and was = amazed that it knew who I was (via Facebook) and was displaying my name an= d photo when I never logged into the site. I was shocked it knew who I wa= s. Enter living in Incognito mode from now on. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C85A27D036CE8eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Security of user agent clients (WAS: End user authres= ponse code-and-token's scope parameter) The issue is that it is hard (or even impossible) to prevent another = user-agent client from imitating another user-agent client. A pre-registere= d redirection URI does very little to help. In most cases, such a URI will = point to a web page with a script that will extract the information and pas= s it to the parent frame. This means any client can get hold of the access = token as long as it was the parent.

If you use immediate with a user-agent flow, the script running in the user= -agent will get the access token by pretending to be another client which w= as already granted access. Since there is no way to authenticate the user-a= gent client, there is no way for the resource at the redirection URI to aut= henticate the client – meaning that it can be used by others.

Immediate mode for user-agent clients takes away the only security safeguar= d which is the explicit end-user approval for whatever is going on on front= of him or her.

EHL


On 7/6/10 9:31 PM, "Evan Gilbert" <uidude@google.com> wrote:



On Tue, Jul 6, 2010 at 12:49 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
If we can agree that it is useless from a s= ecurity perspective (and I think we agree on that by now), then an auth ser= ver must not ever issue an access token to a user agent client without inte= racting with the user (no "immediate" mode issuing of access toke= ns) so the user is aware that some anonymous client on the web page is tryi= ng to access their data, since there's no assurance whatsoever about which = client that is, and whether the user trusts it.=A0

If anyone disagrees, please explain how you can justify it, in light of the= fact that leaving it as-is means once one client is authorized, the whole = world is authorized by just pretending to be that one client. =A0It might a= s well be a "make my data public" switch at the resource server t= o authorize a client such that it gets an access token directly without a c= lient secret.

(Not the muddy the waters, but again, I know client secrets don't add value= when the client is on an uncontrolled machine. =A0Please don't let that te= chnical hurdle stop you from justifying the status quo in draft 9 of the sp= ec).

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the d= eath your right to say it." - S. G. Tallentyre


On Mon, Jul 5, 2010 at 10:27 PM, William Mills <wmills@yahoo-inc.com> wrote:
It's not verifiable, but it is as useful in this= case as a "user agent" string.=A0 Not usefule formt he security = perspective, but has some utility in application tracking.


 

From: oauth-bounces@ietf.org  [mailto:oauth-bounces@ietf.org] On Beha= lf Of Andrew  Arnott
Sent: Saturday, July 03, 2010 12:16 PM
To: Eran  Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re:  [OAUTH-WG] Security of user agent clients (WAS: E= nd user authresponse  code-and-token's scope parameter)

 
(this sounds sarcastic, but I'm no being sarcastic... it's a  serious = question/challenge)...

 
Why not just remove the client_id parameter from the user-agent flow?  = ;=A0It's absolutely meaningless to security. =A0It's only perceivable  = ;benefit is that the auth server can possible display to the user the clien= t  being authorized or the list of previously authorized clients. =A0B= ut  again, that's totally meaningless if not verified.
 

--
Andrew Arnott
"I [may] not agree with what you  have to say, but I'll defend to= the death your right to say it." - S. G.  Tallentyre


 
On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott <andrewarnott@gmail.com>  wrote:
 

 
 
On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
 

 
 

You are  putting too much weight on the value = of redirection URI registration.  Since the same problem exists betwee= n the user-agent script and the  server-side component used in the use= r-agent profile, anyone can imitate  that flow. In most cases, the red= irection URI will simply include a script  that will pass the paramete= r to the *parent* window which can be  anything. If the server-= based page is an active page, it still needs to  communicate with the = user-agent, which again, can pretend to be  that.

Good point. =A0I wasn't imagining that far through it. =A0Not to  deny= that most redirection URLs may just return a straight script that  pa= sses it to the parent window, but that seems pretty irresponsible to the &n= bsp;host that's doing it -- because of the enormous security hole it opens = up.  =A0Some client is trusted enough to authorize (by the user and au= th  server), receives an access token it wasn't expecting, and then bl= indly  forwards it onto whoever wants it. =A0Yikes. =A0I sure hope the= se  access tokens have very=A0limited scope (like, I'd prefer n= one  myself).
 

 
I was about to describe how an active server could alleviate that by  = signing the original request using the state parameter, but I realized I'm =  solving a problem that the web server flow (or nowadays that the &nbs= p;authorization code mode as I guess it's called) already solves. =A0So I &= nbsp;guess I just need to bite the bullet and accept that the user agent fl= ow is  totally insecure for web clients, and thus very special = care must be  taken to enable native clients without opening up the we= b client hole.  =A0
 

 
Sorry to sound so negative about it. =A0Enabling this scenario seems  = really important to me as well -- I just am against doing it when it can't =  be secured in some way. =A0Seriously... as is, once you authorize any=  client, you've authorized them all, including clients not even runni= ng on  your computer. =A0I guess this answers how I was visiting a sit= e a few  days ago and was amazed that it knew who I was (via Facebook)= and was  displaying my name and photo when I never logged into the si= te. =A0I was  shocked it knew who I was. =A0Enter living in Incognito = mode from now  on.



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



 --_000_C85A27D036CE8eranhueniversecom_-- From michael.d.adams@gmail.com Wed Jul 7 13:07: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 E797F3A6948 for ; Wed, 7 Jul 2010 13:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_HRDCOR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xjFTxxS3VSz for ; Wed, 7 Jul 2010 13:07:16 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 18C193A690A for ; Wed, 7 Jul 2010 13:07:16 -0700 (PDT) Received: by iwn38 with SMTP id 38so56197iwn.31 for ; Wed, 07 Jul 2010 13:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=v4TR8QaWQhIrf5zLStvv8VIS7ZIJlVEDvHTP/KB3/Vk=; b=hz10IEfgKdZkIVZ4/Z7BhIko8ZlzwaJWNjDp50J9XVTC9O2PdFuPWhUJP8zTb/BpMU tk9WKwWD+YIYQJQZ5IWy9NkyhzXIw5TSsB54lHO0+2aavvsMEXWQ65bpObpwLG7WnxcS i2NWng9piSauKszIoyLEy7oxIZG6e3MjGZUw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=eec/GHvxLQbHqmC97OJ7qToTEQm97/XPccfROWHlfFLiJezpZa/viMy5X/CLVie/TL jC3SxFZHlLuM1RYxlEsmuxdDh/j6zeYMDOgcul/UfVaMhIXM6XkBzZecMi3U/u/vZkSZ H759F67yOcwvX6RNEkJUa8UWyzeVRLdEu2OEc= Received: by 10.231.170.3 with SMTP id b3mr7189671ibz.122.1278533239186; Wed, 07 Jul 2010 13:07:19 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.179.143 with HTTP; Wed, 7 Jul 2010 13:06:59 -0700 (PDT) In-Reply-To: References: From: Michael D Adams Date: Wed, 7 Jul 2010 13:06:59 -0700 X-Google-Sender-Auth: V-RWLqZ-Lh9dzRMoEHAocMHokl0 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 20:07:17 -0000 On Wed, Jul 7, 2010 at 12:47 PM, Eran Hammer-Lahav wrote: > The issue is that it is hard (or even impossible) to prevent another > user-agent client from imitating another user-agent client. A pre-registered > redirection URI does very little to help. In most cases, such a URI will > point to a web page with a script that will extract the information and pass > it to the parent frame. This means any client can get hold of the access > token as long as it was the parent. The script doesn't have to naively pass information to the parent. It could either make an explicit check to make sure the parent is in the same domain, or rely on communication techniques that respect the same-origin policy. Pros: With a pre-registered redirection URI, this prevents the specific case you mentioned above. Are there other cases where this wouldn't work? Cons: Requiring such a check would add implementation load to clients. Servers would not know if the (good-guy) client is conformant. Does it break the user-agent flow entirely? Are there implementations that require this blind cross domain communication? Mike --mdawaffe From eran@hueniverse.com Wed Jul 7 13:08:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12D983A690A for ; Wed, 7 Jul 2010 13:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k5otvUSMy-G for ; Wed, 7 Jul 2010 13:08:39 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 7FD2E3A68CE for ; Wed, 7 Jul 2010 13:08:39 -0700 (PDT) Received: (qmail 3169 invoked from network); 7 Jul 2010 20:08:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Jul 2010 20:08:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 7 Jul 2010 13:08:41 -0700 From: Eran Hammer-Lahav To: Brian Eaton , Hannes Tschofenig , Blaine Cook Date: Wed, 7 Jul 2010 13:08:40 -0700 Thread-Topic: assertion profile changes Thread-Index: Acsd8zAriZXzPpUwSXWb6i9zOu7KHwAHQDOp Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 20:08:41 -0000 On 7/7/10 9:40 AM, "Brian Eaton" wrote: > Hi folks - >=20 > What is the story with the evolution of the assertion profile? It is pretty much the same as originally proposed. Any recent changes are a= n oversight, not any intentional change. Since it was proposed, the only change made (with full consensus) was to allow client authentication as an optional request parameter, as well as allow a refresh token as an optional response parameter. > As far as I can tell, it keeps changing for no good reason. Everyone who > wants to implement the profile has the exact same requirements, and > agreed on how it should work a long time ago. >=20 > Here's the timeline: >=20 > - a bunch of people get together and do WRAP. It contains a flow that > exchanges a signed assertion for a short-lived bearer token. >=20 > - WRAP becomes OAuth2. Assertion profile is dropped. >=20 > - People protest. >=20 > - Assertion profile is added back. Wrong. The WG drafts have always included the assertion profile. I was missing fro= m David's initial draft and was added by me not because of any such protest but because I wanted the first draft to represent the full combination of OAuth 1.0, WRAP, and the token scheme. > - OAuth2 interim meeting: a bunch of people stand up and say they > either have implemented or are implementing the assertion profile. > (Note that this is a superset of the people who worked on WRAP. More > organizations have come on board.) This is out of context. We had a discussion about moving flows out of the core specification. We discussed each flow. There were some calls for moving the assertion flow out, as well as the device flow and native applications flow. After a productive (and pleasant) discussion, we decided that there are enough active use cases to keep it in. > - Everything is fine until draft 7 of the OAuth 2 spec is published. > Assertion profile has changed, security is screwed up. People > protest. I do not recall any such changes or protest. Draft -07 changed the prose an= d some parameter names, but has not changed the core details of the protocol or the assertion flow. The so called "protest" was a handful of people asking to bring back the 'type' parameter (and some saying it was not needed). The parameter was promptly re-introduced as 'grant_type'. If you have specific issues with regard to "security is screwed up" please raise them. > - Draft 8 makes it even worse, adding new secrets with no visible purpose= . The changes in client authentication were explicitly discussed and requeste= d at the meeting, mostly by those who also promoted the assertion flow. I agree that the fact that the current prose *requires* client authentication (instead of keeping it optional as previously agreed) is a problem. But that's a oversight - not high drama. > - Yaron notices, complains, is told that he should write new spec languag= e. >=20 > - Yaron writes new language. >=20 > - Argument starts over whether this is really necessary. This is not how I understood it, but Yaron is free to correct me if I am wrong. Yaron supported the new language in section 2 and wanted to *add* to it the ability to authenticate the client using an assertion. This is another assertion for client authentication, not as an access grant. > This is beginning to seem brain dead. The same way this timeline represents reality. > Can we please put the assertion profile back the way it was > in WRAP and Draft 6 of the OAuth 2 spec? This is a critical use case > for a bunch of companies, all of whom have already agreed on how it > should work, and most of whom already have working implementations. It is. I will fix the client authentication issue - thanks for the feedback= . But from my understanding, people who care about the assertion flow already implemented it and did not express the same views as you. If you want additional changes, suggest them as feedback to -09. That's the current process. > It's fine with me if people have other use cases for assertions, and > need new protocol flows to support those use cases. But that's a > terrible reason to screw up the existing use cases. The assertion access grant is the built-in profile extensibility mechanism in OAuth 2.0. This makes is a core part of the protocol. However, this does not mean it needs to be (or is) different from what was originally proposed= . I don't know where all this alleged drama is coming from, but from where I sit, this is exactly the same flow, with one mistake made in recent draft making client authentication seem mandatory. EHL From eran@hueniverse.com Wed Jul 7 13:11: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 574C03A68CE for ; Wed, 7 Jul 2010 13:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_HRDCOR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Lyg8eugFdqI for ; Wed, 7 Jul 2010 13:11:54 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 1DED83A6876 for ; Wed, 7 Jul 2010 13:11:54 -0700 (PDT) Received: (qmail 30860 invoked from network); 7 Jul 2010 20:11:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Jul 2010 20:11:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 7 Jul 2010 13:11:41 -0700 From: Eran Hammer-Lahav To: "mike@automattic.com" Date: Wed, 7 Jul 2010 13:11:39 -0700 Thread-Topic: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) Thread-Index: AcseEAHi/uzy+yAHQQyXOkdnxWiRxwAAJnGs Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85A2D8B36CF2eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 20:11:55 -0000 --_000_C85A2D8B36CF2eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks. Browser security is not my area. It seems to me that this must be documented as all the examples I have seen= for such scripts did not include any such security measures. EHL On 7/7/10 1:06 PM, "mike@automattic.com" wrote: On Wed, Jul 7, 2010 at 12:47 PM, Eran Hammer-Lahav wr= ote: > The issue is that it is hard (or even impossible) to prevent another > user-agent client from imitating another user-agent client. A pre-registe= red > redirection URI does very little to help. In most cases, such a URI will > point to a web page with a script that will extract the information and p= ass > it to the parent frame. This means any client can get hold of the access > token as long as it was the parent. The script doesn't have to naively pass information to the parent. It could either make an explicit check to make sure the parent is in the same domain, or rely on communication techniques that respect the same-origin policy. Pros: With a pre-registered redirection URI, this prevents the specific case you mentioned above. Are there other cases where this wouldn't work? Cons: Requiring such a check would add implementation load to clients. Servers would not know if the (good-guy) client is conformant. Does it break the user-agent flow entirely? Are there implementations that require this blind cross domain communication? Mike --mdawaffe --_000_C85A2D8B36CF2eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Security of user agent clients (WAS: End user  a= uthresponse code-and-token's scope parameter) Thanks. Browser security is not my area.

It seems to me that this must be documented as all the examples I have seen= for such scripts did not include any such security measures.

EHL


On 7/7/10 1:06 PM, "mike@automattic.co= m" <mike@automattic.com>= wrote:

On Wed, Jul 7, 2010 at 12:47 PM, Eran Hamme= r-Lahav <eran@hueniverse.com> wro= te:
> The issue is that it is hard (or even impossible) to prevent another > user-agent client from imitating another user-agent client. A pre-regi= stered
> redirection URI does very little to help. In most cases, such a URI wi= ll
> point to a web page with a script that will extract the information an= d pass
> it to the parent frame. This means any client can get hold of the acce= ss
> token as long as it was the parent.

The script doesn't have to naively pass information to the parent.  It=
could either make an explicit check to make sure the parent is in the
same domain, or rely on communication techniques that respect the
same-origin policy.

Pros:
With a pre-registered redirection URI, this prevents the specific case
you mentioned above.  Are there other cases where this wouldn't work?<= BR>
Cons:
Requiring such a check would add implementation load to clients.
Servers would not know if the (good-guy) client is conformant.
Does it break the user-agent flow entirely?  Are there implementations=
that require this blind cross domain communication?

Mike
--mdawaffe

--_000_C85A2D8B36CF2eranhueniversecom_-- From igor.faynberg@alcatel-lucent.com Wed Jul 7 13:40: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 25DC23A6924 for ; Wed, 7 Jul 2010 13:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_HRDCOR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1ukswUeh3wD for ; Wed, 7 Jul 2010 13:40:06 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id C52603A68BC for ; Wed, 7 Jul 2010 13:40:06 -0700 (PDT) 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 o67Ke6Ge001259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jul 2010 15:40:06 -0500 (CDT) Received: from [135.244.18.37] (faynberg.lra.lucent.com [135.244.18.37]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o67Ke56h004213; Wed, 7 Jul 2010 15:40:05 -0500 (CDT) Message-ID: <4C34E620.5070708@alcatel-lucent.com> Date: Wed, 07 Jul 2010 16:40:00 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: OAuth WG Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 20:40:08 -0000 I think this squarely belongs in the Security Consideration section! In fact, I think that all other items there ought to be written using the same template: a) Problem, b) Solution(s) along with pros and cons. Igor Eran Hammer-Lahav wrote: > Thanks. Browser security is not my area. > > It seems to me that this must be documented as all the examples I have > seen for such scripts did not include any such security measures. > > EHL > > > On 7/7/10 1:06 PM, "mike@automattic.com" wrote: > > On Wed, Jul 7, 2010 at 12:47 PM, Eran Hammer-Lahav > wrote: > > The issue is that it is hard (or even impossible) to prevent another > > user-agent client from imitating another user-agent client. A > pre-registered > > redirection URI does very little to help. In most cases, such a > URI will > > point to a web page with a script that will extract the > information and pass > > it to the parent frame. This means any client can get hold of the > access > > token as long as it was the parent. > > The script doesn't have to naively pass information to the parent. It > could either make an explicit check to make sure the parent is in the > same domain, or rely on communication techniques that respect the > same-origin policy. > > Pros: > With a pre-registered redirection URI, this prevents the specific case > you mentioned above. Are there other cases where this wouldn't work? > > Cons: > Requiring such a check would add implementation load to clients. > Servers would not know if the (good-guy) client is conformant. > Does it break the user-agent flow entirely? Are there implementations > that require this blind cross domain communication? > > Mike > --mdawaffe > > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From beaton@google.com Wed Jul 7 14:02:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E8B3A69A6 for ; Wed, 7 Jul 2010 14:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.724 X-Spam-Level: X-Spam-Status: No, score=-104.724 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8GXMhP991uG for ; Wed, 7 Jul 2010 14:02:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A0D773A69A2 for ; Wed, 7 Jul 2010 14:02:31 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o67L2YhM031938 for ; Wed, 7 Jul 2010 14:02:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278536554; bh=+EVT84s3hhP4XyddyE58dvh0hxM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=V265hYO7AX71E6lKeN99furGGZ4fl0x0hPReLCO19r5e3J7JoHL70BUDAyXdP2ve4 2nXMHTLVbVokVLlOQujWg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=oYgv3HS97rfTo/AjueT7UNFGqq+2+d3Mipeuwquisvy/pD6fqcFzyQk8ZUbexBM7C T2FHi0tcbP6nMTV4Hn3gg== Received: from pwi8 (pwi8.prod.google.com [10.241.219.8]) by wpaz17.hot.corp.google.com with ESMTP id o67L2XSc022820 for ; Wed, 7 Jul 2010 14:02:33 -0700 Received: by pwi8 with SMTP id 8so85182pwi.0 for ; Wed, 07 Jul 2010 14:02:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.134.7 with SMTP id h7mr8563487wfd.244.1278536553116; Wed, 07 Jul 2010 14:02:33 -0700 (PDT) Received: by 10.142.187.19 with HTTP; Wed, 7 Jul 2010 14:02:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Jul 2010 14:02:32 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 21:02:33 -0000 On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav wrote: > It is pretty much the same as originally proposed. Any recent changes are an > oversight, not any intentional change. Since it was proposed, the only > change made (with full consensus) was to allow client authentication as an > optional request parameter, as well as allow a refresh token as an optional > response parameter. Can you point me to the e-mail threads that reached consensus on using client authentication? Can you point me to the e-mail threads that reached consensus on returning a refresh token? From eran@hueniverse.com Wed Jul 7 14:18:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6163A6925 for ; Wed, 7 Jul 2010 14:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.482, 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 y+t9BWCgXjS2 for ; Wed, 7 Jul 2010 14:18:35 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 1F44D3A6908 for ; Wed, 7 Jul 2010 14:18:35 -0700 (PDT) Received: (qmail 17445 invoked from network); 7 Jul 2010 21:18:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Jul 2010 21:18:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 7 Jul 2010 14:18:31 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Wed, 7 Jul 2010 14:18:29 -0700 Thread-Topic: assertion profile changes Thread-Index: AcseF7u7fx0h6vJCScyhfgsvuzP3yAAAjYSL Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 21:18:36 -0000 I don't have time to go dig through the list archive. On 7/7/10 2:02 PM, "Brian Eaton" wrote: > On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav w= rote: >> It is pretty much the same as originally proposed. Any recent changes ar= e an >> oversight, not any intentional change. Since it was proposed, the only >> change made (with full consensus) was to allow client authentication as = an >> optional request parameter, as well as allow a refresh token as an optio= nal >> response parameter. >=20 > Can you point me to the e-mail threads that reached consensus on using > client authentication? This was requested a few months ago and was included in -05 as optional. I did not see any feedback requesting to remove this. > Can you point me to the e-mail threads that reached consensus on > returning a refresh token? I raised this a long time ago about making the token endpoint output consistent across all request types. At the time, consensus was that there was no reason not to allow it, but that in general is should not be done (refresh token when using assertions). The current language has a SHOULD NOT issue a refresh token. It is not a MUST NOT because someone recently asked for the ability to issue a refresh token when the client nature prevents it from retaining the original assertion used. If you have an objection to the SHOULD NOT (vs. MUST NOT), please raise it the the group will discuss. EHL =20 From jhart@photobucket.com Wed Jul 7 14:33: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 8A7CF3A69A5 for ; Wed, 7 Jul 2010 14:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nau-i2XaJLRC for ; Wed, 7 Jul 2010 14:33:00 -0700 (PDT) Received: from EXHUB003-2.exch003intermedia.net (exhub003-2.exch003intermedia.net [207.5.74.29]) by core3.amsl.com (Postfix) with ESMTP id 6C7053A69B2 for ; Wed, 7 Jul 2010 14:31:02 -0700 (PDT) Received: from EXVMBX003-4.exch003intermedia.net ([207.5.74.44]) by EXHUB003-2.exch003intermedia.net ([207.5.74.29]) with mapi; Wed, 7 Jul 2010 14:31:04 -0700 From: Justin Hart To: Eran Hammer-Lahav Date: Wed, 7 Jul 2010 14:31:04 -0700 Thread-Topic: [OAUTH-WG] assertion profile changes Thread-Index: AcseG7P47gh5Bde4RomhiZiJ7RBBAQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 21:33:16 -0000 I'm currently finishing an extension spec for client-to-client access deleg= ation based on the assertion profile. I believe it will use the client sec= ret and return a refresh token, because the assertion is meant to be tempor= ary, at least in its current form. If the assertions are moving in a diffe= rent direction I will need to refactor to follow suit. (btw, expect a url = to my draft by the end of the week, I hope) ---- -- Justin Hart -- jhart@photobucket.com On Jul 7, 2010, at 3:18 PM, Eran Hammer-Lahav wrote: > I don't have time to go dig through the list archive. >=20 >=20 > On 7/7/10 2:02 PM, "Brian Eaton" wrote: >=20 >> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav = wrote: >>> It is pretty much the same as originally proposed. Any recent changes a= re an >>> oversight, not any intentional change. Since it was proposed, the only >>> change made (with full consensus) was to allow client authentication as= an >>> optional request parameter, as well as allow a refresh token as an opti= onal >>> response parameter. >>=20 >> Can you point me to the e-mail threads that reached consensus on using >> client authentication? >=20 > This was requested a few months ago and was included in -05 as optional. = I > did not see any feedback requesting to remove this. >=20 >> Can you point me to the e-mail threads that reached consensus on >> returning a refresh token? >=20 > I raised this a long time ago about making the token endpoint output > consistent across all request types. At the time, consensus was that ther= e > was no reason not to allow it, but that in general is should not be done > (refresh token when using assertions). >=20 > The current language has a SHOULD NOT issue a refresh token. It is not a > MUST NOT because someone recently asked for the ability to issue a refres= h > token when the client nature prevents it from retaining the original > assertion used. >=20 > If you have an objection to the SHOULD NOT (vs. MUST NOT), please raise i= t > the the group will discuss. >=20 > EHL >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Wed Jul 7 14:42: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 0066B3A6991 for ; Wed, 7 Jul 2010 14:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[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 KlgwAtGPyRmP for ; Wed, 7 Jul 2010 14:42:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 42A783A6987 for ; Wed, 7 Jul 2010 14:42:29 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o67LgVIR014422 for ; Wed, 7 Jul 2010 14:42:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278538952; bh=iJnjRVNBpb8xldVGWOjTdQeLiZs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=hYTeC03Fea60nqQJJcyuSjn/jhxEZexgoi0T4GG7eocjhm/09Nf0u4mel/8/GCB/R uvSKaa2SDuCFLkPfcmHPg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=sHCctSY9UMCYzMLxdgKz4tK8xSuKYlB5BhMKdH/IzE+5Ixk57il4zTOITgREiWy/f ZaGiT0Iw7aNY1DatI0UFA== Received: from gyd10 (gyd10.prod.google.com [10.243.49.202]) by kpbe17.cbf.corp.google.com with ESMTP id o67LgMrB011301 for ; Wed, 7 Jul 2010 14:42:30 -0700 Received: by gyd10 with SMTP id 10so63384gyd.10 for ; Wed, 07 Jul 2010 14:42:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.118.19 with SMTP id q19mr6186866agc.88.1278538950161; Wed, 07 Jul 2010 14:42:30 -0700 (PDT) Received: by 10.91.216.11 with HTTP; Wed, 7 Jul 2010 14:42:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Jul 2010 14:42:30 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 21:42:31 -0000 On Wed, Jul 7, 2010 at 2:18 PM, Eran Hammer-Lahav wrote: > On 7/7/10 2:02 PM, "Brian Eaton" wrote: >> Can you point me to the e-mail threads that reached consensus on using >> client authentication? > > This was requested a few months ago and was included in -05 as optional. I > did not see any feedback requesting to remove this. OK, here it is: http://www.ietf.org/mail-archive/web/oauth/current/msg02545.html I see that I was +1 on client_id and client_secret, so long as they were optional. =) I'd like to withdraw that +1. Optional input and output parameters have made the specification very confusing. If someone needs client_id and client_secret, great, they can explain their use case and propose a profile to address it. But the original use case for the assertion flow has no use for client ids. >> Can you point me to the e-mail threads that reached consensus on >> returning a refresh token? > > I raised this a long time ago about making the token endpoint output > consistent across all request types. At the time, consensus was that there > was no reason not to allow it, but that in general is should not be done > (refresh token when using assertions). Please review this thread: http://www.ietf.org/mail-archive/web/oauth/current/msg02188.html. I am sure there are people out there who want to use refresh tokens with SAML assertions. Good for them. But it's a different use case. It should be moved to a different profile. It is not a good idea to jam multiple use cases into a single protocol flow with a bunch of optional inputs and outputs. Instead different use cases should be separate profiles, with mandatory inputs and mandatory outputs. If there are going to be optional inputs and outputs, there should be clear guidance as to when they are expected and when they are not. Cheers, Brian From eran@hueniverse.com Wed Jul 7 14:53: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 16AFF3A6822 for ; Wed, 7 Jul 2010 14:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.447, 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 lh7Qn2aTEqkl for ; Wed, 7 Jul 2010 14:52:58 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5C0EF3A6953 for ; Wed, 7 Jul 2010 14:52:58 -0700 (PDT) Received: (qmail 32127 invoked from network); 7 Jul 2010 21:53:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Jul 2010 21:53:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 7 Jul 2010 14:52:59 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Wed, 7 Jul 2010 14:52:57 -0700 Thread-Topic: assertion profile changes Thread-Index: AcseHVEetEuH6jUgSqeTKhZo/MYIXAAAXFNF Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85A454936D54eranhueniversecom_" MIME-Version: 1.0 Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 21:53:04 -0000 --_000_C85A454936D54eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I disagree with this approach. There are plenty of optional parameters in t= he spec. The assertion access grant requires further profiling to be useful. This do= esn't mean it needs another spec, but that when you use it, you need to doc= ument clearly what is expected. When you do that, spell out what you suppor= t and what not. It is not clear what about allowing client authentication or refresh token = breaks security. This is purely a deployment decision for each provider. If you would like to request specific changes to draft -09, please list the= m and explain why you are requesting them. EHL On 7/7/10 2:42 PM, "Brian Eaton" wrote: On Wed, Jul 7, 2010 at 2:18 PM, Eran Hammer-Lahav wro= te: > On 7/7/10 2:02 PM, "Brian Eaton" wrote: >> Can you point me to the e-mail threads that reached consensus on using >> client authentication? > > This was requested a few months ago and was included in -05 as optional. = I > did not see any feedback requesting to remove this. OK, here it is: http://www.ietf.org/mail-archive/web/oauth/current/msg02545= .html I see that I was +1 on client_id and client_secret, so long as they were optional. =3D) I'd like to withdraw that +1. Optional input and output parameters have made the specification very confusing. If someone needs client_id and client_secret, great, they can explain their use case and propose a profile to address it. But the original use case for the assertion flow has no use for client ids. >> Can you point me to the e-mail threads that reached consensus on >> returning a refresh token? > > I raised this a long time ago about making the token endpoint output > consistent across all request types. At the time, consensus was that ther= e > was no reason not to allow it, but that in general is should not be done > (refresh token when using assertions). Please review this thread: http://www.ietf.org/mail-archive/web/oauth/current/msg02188.html. I am sure there are people out there who want to use refresh tokens with SAML assertions. Good for them. But it's a different use case. It should be moved to a different profile. It is not a good idea to jam multiple use cases into a single protocol flow with a bunch of optional inputs and outputs. Instead different use cases should be separate profiles, with mandatory inputs and mandatory outputs. If there are going to be optional inputs and outputs, there should be clear guidance as to when they are expected and when they are not. Cheers, Brian --_000_C85A454936D54eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: assertion profile changes I disagree with this approach. There are plenty of optional parameter= s in the spec.

The assertion access grant requires further profiling to be useful. This do= esn’t mean it needs another spec, but that when you use it, you need = to document clearly what is expected. When you do that, spell out what you = support and what not.

It is not clear what about allowing client authentication or refresh token = breaks security. This is purely a deployment decision for each provider.
If you would like to request specific changes to draft –09, please li= st them and explain why you are requesting them.

EHL


On 7/7/10 2:42 PM, "Brian Eaton" <beaton@google.com> wrote:

On Wed, Jul 7, 2010 at 2:18 PM, Eran Hammer= -Lahav <eran@hueniverse.com> wrot= e:
> On 7/7/10 2:02 PM, "Brian Eaton" <beaton@google.com> wrote:
>> Can you point me to the e-mail threads that reached consensus on u= sing
>> client authentication?
>
> This was requested a few months ago and was included in -05 as optiona= l. I
> did not see any feedback requesting to remove this.

OK, here it is: http://www.ietf.org/mail-archive/web/oauth/current/msg025= 45.html

I see that I was +1 on client_id and client_secret, so long as they
were optional. =3D)

I'd like to withdraw that +1.  Optional input and output parameters have made the specification very confusing.

If someone needs client_id and client_secret, great, they can explain
their use case and propose a profile to address it.  But the original<= BR> use case for the assertion flow has no use for client ids.

>> Can you point me to the e-mail threads that reached consensus on >> returning a refresh token?
>
> I raised this a long time ago about making the token endpoint output > consistent across all request types. At the time, consensus was that t= here
> was no reason not to allow it, but that in general is should not be do= ne
> (refresh token when using assertions).

Please review this thread:
http://www.ietf.org/mail-archive/web/oauth/current/msg02188.html.

I am sure there are people out there who want to use refresh tokens
with SAML assertions.  Good for them.  But it's a different use c= ase.
It should be moved to a different profile.

It is not a good idea to jam multiple use cases into a single protocol
flow with a bunch of optional inputs and outputs.

Instead different use cases should be separate profiles, with
mandatory inputs and mandatory outputs.

If there are going to be optional inputs and outputs, there should be
clear guidance as to when they are expected and when they are not.

Cheers,
Brian

--_000_C85A454936D54eranhueniversecom_-- From beaton@google.com Wed Jul 7 15:01: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 938383A69A5 for ; Wed, 7 Jul 2010 15:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[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 HsnxCQEoTpLe for ; Wed, 7 Jul 2010 15:01:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 63A273A6822 for ; Wed, 7 Jul 2010 15:01:20 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o67M1NWf003872 for ; Wed, 7 Jul 2010 15:01:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278540083; bh=KvWAT/Gz667cVlIWP9IrhXjrTZ8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=KAAoCvEXLAW27zL0jJRDmJrFu2wQivaikiJ7E2szQmdkfdXlvLOktgnn8QwOyj6nc Pbb/WcvQuWRfcwhV8QUYw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=K00aYi2c3VrUkrC8KBGmGEsUbOiN6vw8UFgIDvFXnoMMgqZ0sekK5zYKZEdEffiEB HzxEKCMevq53ETeoh8L5Q== Received: from yxt33 (yxt33.prod.google.com [10.190.5.225]) by hpaq1.eem.corp.google.com with ESMTP id o67M1Gnu027580 for ; Wed, 7 Jul 2010 15:01:22 -0700 Received: by yxt33 with SMTP id 33so35196yxt.1 for ; Wed, 07 Jul 2010 15:01:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.98.20 with SMTP id v20mr2026342agb.172.1278540081704; Wed, 07 Jul 2010 15:01:21 -0700 (PDT) Received: by 10.91.216.11 with HTTP; Wed, 7 Jul 2010 15:01:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Jul 2010 15:01:21 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 22:01:21 -0000 On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav wro= te: > I disagree with this approach. There are plenty of optional parameters in > the spec. Yes. I think most of them are a bad idea. > The assertion access grant requires further profiling to be useful. This > doesn=92t mean it needs another spec, but that when you use it, you need = to > document clearly what is expected. When you do that, spell out what you > support and what not. It doesn't, actually. Lots of people have existing SAML assertion formats that they support, and they are going to use the SAML to access token swap without any further spec writing. > It is not clear what about allowing client authentication or refresh toke= n > breaks security. This is purely a deployment decision for each provider. Please see this thread: http://www.ietf.org/mail-archive/web/oauth/current/msg02218.html. Note multiple voices of approval for dropping the refresh token. Note that people who want the refresh token have *completely different use cases*. Steering multiple use cases into the same profile is how we made OAuth 1.0 complex, slow, and insecure. Let's not make the same mistake with OAuth 2. > If you would like to request specific changes to draft =9609, please list= them > and explain why you are requesting them. I'd like to see the following changes: 1) Separate profiles for separate use cases. The spec started off this way, and recent drafts have made it progressively more compressed. Shorter is not a win. 2) Drop refresh token, client id, and client secret from the SAML flow. If someone needs them, that's OK, but put it in different profile for a different use case. Cheers, Brian From cmortimore@salesforce.com Wed Jul 7 15:23: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 0EA5D3A698C for ; Wed, 7 Jul 2010 15:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmAOQVRLU6BB for ; Wed, 7 Jul 2010 15:23:25 -0700 (PDT) Received: from exprod8og103.obsmtp.com (exprod8og103.obsmtp.com [64.18.3.86]) by core3.amsl.com (Postfix) with SMTP id EA2D83A6915 for ; Wed, 7 Jul 2010 15:23:24 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob103.postini.com ([64.18.7.12]) with SMTP ID DSNKTDT+X0fnLcmWL97PLc24Hwcxk3d6enQu@postini.com; Wed, 07 Jul 2010 15:23:28 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Wed, 7 Jul 2010 15:23:27 -0700 From: Chuck Mortimore To: Brian Eaton , Eran Hammer-Lahav Date: Wed, 7 Jul 2010 15:23:25 -0700 Thread-Topic: [OAUTH-WG] assertion profile changes Thread-Index: AcseH/dVZMmYcjwgRbS1K5tnbmxb0wAAwypN Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85A4C6D7F67cmortimoresalesforcecom_" MIME-Version: 1.0 Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 22:23:34 -0000 --_000_C85A4C6D7F67cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 7/7/10 3:01 PM, "Brian Eaton" wrote: On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav wro= te: > I disagree with this approach. There are plenty of optional parameters in > the spec. Yes. I think most of them are a bad idea. > The assertion access grant requires further profiling to be useful. This > doesn't mean it needs another spec, but that when you use it, you need to > document clearly what is expected. When you do that, spell out what you > support and what not. It doesn't, actually. Lots of people have existing SAML assertion formats that they support, and they are going to use the SAML to access token swap without any further spec writing. I'd probably agree with Eran on this one - additional spec isn't required, = but in absence, additional doc almost certainly will be. We are strongly against any mandatory client credentials, however, as long = as client creds are optional, then it's up to the server or profile to defi= ne. I'm not sure I get the objection, as it remains under your control. > It is not clear what about allowing client authentication or refresh toke= n > breaks security. This is purely a deployment decision for each provider. Please see this thread: http://www.ietf.org/mail-archive/web/oauth/current/msg02218.html. Note multiple voices of approval for dropping the refresh token. Note that people who want the refresh token have *completely different use cases*. Refresh tokens are already labeled as SHOULD NOT, which I find strong enoug= h; if others want to do something crazy with the flow I consider it up to t= hem. We are are strongly against any SHOULD or MUST language on refresh t= okens. Steering multiple use cases into the same profile is how we made OAuth 1.0 complex, slow, and insecure. Let's not make the same mistake with OAuth 2. I don't really view the assertion flow in current form to be anything but a= basis for futher profiling or docs. In both these cases, it seems like t= he server maintains control. I'm certain we can't expect interoperable cl= ients using SAML without further profiling / doc / agreement. -cmort > If you would like to request specific changes to draft -09, please list t= hem > and explain why you are requesting them. I'd like to see the following changes: 1) Separate profiles for separate use cases. The spec started off this way, and recent drafts have made it progressively more compressed. Shorter is not a win. 2) Drop refresh token, client id, and client secret from the SAML flow. If someone needs them, that's OK, but put it in different profile for a different use case. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C85A4C6D7F67cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] assertion profile changes On 7/7/10 3:01 = PM, "Brian Eaton" <beaton@google= .com> wrote:

On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> I disagree with this approach. There are plenty of optional parameters= in
> the spec.

Yes.  I think most of them are a bad idea.

> The assertion access grant requires further profiling to be useful. Th= is
> doesn’t mean it needs another spec, but that when you use it, yo= u need to
> document clearly what is expected. When you do that, spell out what yo= u
> support and what not.

It doesn't, actually.  Lots of people have existing SAML assertion
formats that they support, and they are going to use the SAML to
access token swap without any further spec writing.

I’d probably agree with Eran on this one – addition= al spec isn’t required, but in absence, additional doc almost certain= ly will be.   

We are strongly against any mandatory client credentials, however, as long = as client creds are optional, then it’s up to the server or profile t= o define.   I’m not sure I get the objection, as it remains= under your control.   

> It is not clear what about allowing client authentication or refresh t= oken
> breaks security. This is purely a deployment decision for each provide= r.

Please see this thread:
http://www.ietf.org/mail-archive/web/oauth/current/msg02218.html.

Note multiple voices of approval for dropping the refresh token.

Note that people who want the refresh token have *completely different
use cases*.

Refresh tokens are already labeled as SHOULD NOT, which I find = strong enough; if others want to do something crazy with the flow I conside= r it up to them.   We are are strongly against any SHOULD or MUST= language on refresh tokens.


Steering multiple use cases into the same profile is how we made OAuth
1.0 complex, slow, and insecure.  Let's not make the same mistake with=
OAuth 2.

I don’t really view the assertion flow in current form to= be anything but a basis for futher profiling or docs.   In both = these cases, it seems like the server maintains control.   I̵= 7;m certain we can’t expect interoperable clients using SAML without = further profiling / doc / agreement.

-cmort


> If you would like to request specific changes to draft –09, plea= se list them
> and explain why you are requesting them.

I'd like to see the following changes:

1) Separate profiles for separate use cases.
   The spec started off this way, and recent drafts have mad= e it
progressively more compressed.  Shorter is not a win.

2) Drop refresh token, client id, and client secret from the SAML flow.
    If someone needs them, that's OK, but put it in dif= ferent profile
for a different use case.

Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C85A4C6D7F67cmortimoresalesforcecom_-- From cmortimore@salesforce.com Wed Jul 7 16:51:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3FA33A68D3 for ; Wed, 7 Jul 2010 16:51:20 -0700 (PDT) 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 9dpQ3h+DfsDs for ; Wed, 7 Jul 2010 16:51:20 -0700 (PDT) Received: from exprod8og110.obsmtp.com (exprod8og110.obsmtp.com [64.18.3.100]) by core3.amsl.com (Postfix) with SMTP id C3E0C3A69DB for ; Wed, 7 Jul 2010 16:51:19 -0700 (PDT) Received: from source ([209.85.212.43]) by exprod8ob110.postini.com ([64.18.7.12]) with SMTP ID DSNKTDUS+vv6TfZaBYrmrvCyRG0jP+ZSC3Aa@postini.com; Wed, 07 Jul 2010 16:51:23 PDT Received: by vws4 with SMTP id 4so408511vws.2 for ; Wed, 07 Jul 2010 16:51:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.62.72 with SMTP id w8mr3812919vch.60.1278546682434; Wed, 07 Jul 2010 16:51:22 -0700 (PDT) Received: by 10.220.177.70 with HTTP; Wed, 7 Jul 2010 16:51:22 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Jul 2010 16:51:22 -0700 Message-ID: From: Chuck Mortimore To: Brian Eaton Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 23:51:21 -0000 This thread forced a great deal on internal discussion today, and we actually do have some more immediate use-cases where we'll require client_id with the assertion flow I support leaving it as optional -cmort On Wednesday, July 7, 2010, Brian Eaton wrote: > On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav w= rote: >> I disagree with this approach. There are plenty of optional parameters i= n >> the spec. > > Yes. =A0I think most of them are a bad idea. > >> The assertion access grant requires further profiling to be useful. This >> doesn=92t mean it needs another spec, but that when you use it, you need= to >> document clearly what is expected. When you do that, spell out what you >> support and what not. > > It doesn't, actually. =A0Lots of people have existing SAML assertion > formats that they support, and they are going to use the SAML to > access token swap without any further spec writing. > >> It is not clear what about allowing client authentication or refresh tok= en >> breaks security. This is purely a deployment decision for each provider. > > Please see this thread: > http://www.ietf.org/mail-archive/web/oauth/current/msg02218.html. > > Note multiple voices of approval for dropping the refresh token. > > Note that people who want the refresh token have *completely different > use cases*. > > Steering multiple use cases into the same profile is how we made OAuth > 1.0 complex, slow, and insecure. =A0Let's not make the same mistake with > OAuth 2. > >> If you would like to request specific changes to draft =9609, please lis= t them >> and explain why you are requesting them. > > I'd like to see the following changes: > > 1) Separate profiles for separate use cases. > =A0 The spec started off this way, and recent drafts have made it > progressively more compressed. =A0Shorter is not a win. > > 2) Drop refresh token, client id, and client secret from the SAML flow. > =A0 =A0If someone needs them, that's OK, but put it in different profile > for a different use case. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From michael.d.adams@gmail.com Wed Jul 7 17:48:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0666D3A69E5 for ; Wed, 7 Jul 2010 17:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o03nTT3DBsX for ; Wed, 7 Jul 2010 17:48:18 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 272013A69A1 for ; Wed, 7 Jul 2010 17:48:18 -0700 (PDT) Received: by iwn38 with SMTP id 38so308086iwn.31 for ; Wed, 07 Jul 2010 17:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=KOeQ25roMLOp2aGsVJHM3z5eZOmPwj7gxF4C14H54Dg=; b=VVuvLWfgHJDL0wUwtS25pVQ91UJZliQH6NlLzFhu6JclaEq7SDZffPM8wsuM/fbKqA pzrqaf0rAgc0udCddpVihP1SP8fYHCdXiRcMkXTdVr+xPd0rzynucO50ClMLuGtU5G3B hrNFGXBmPkrBoQHhZtZj+vNITy5W+gzfziGQE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=L7avHoYyH70CjDs0gYj5LtHwr2DJ54kPXiPeXO2qwvFmxEidaoX4UAYzFXUgcVnndJ oS7s3Ly0YryvCADFhHDvVSjaInXP2VwAi3di1y3GuleUXpf3Y+U6ecEub954878m7QII m8vgTaJitTlVivGIe6e6EPad9fBQVzcuT9l7Q= Received: by 10.231.14.200 with SMTP id h8mr7012928iba.188.1278550101329; Wed, 07 Jul 2010 17:48:21 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.179.143 with HTTP; Wed, 7 Jul 2010 17:47:59 -0700 (PDT) In-Reply-To: References: From: Michael D Adams Date: Wed, 7 Jul 2010 17:47:59 -0700 X-Google-Sender-Auth: XQpfBIep_8MP_2oks2xCNu57e5o Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 00:48:19 -0000 On Wed, Jul 7, 2010 at 1:11 PM, Eran Hammer-Lahav wrote: > Thanks. Browser security is not my area. > > It seems to me that this must be documented as all the examples I have seen > for such scripts did not include any such security measures. Nor is it mine. I know some techniques for cross-origin communication, but not intimately enough to know all the security implications raised by each in various browsers. As a general rule, though, iframes can't talk to one another if they have different origins. There are several ways to bend the rule. Doing so would introduce security problems for OAuth. 1. Communication via setting URI fragments in other iframes and detecting such changes in your own iframe. 2. Proxy iframes. So we should tell people not to (blindly) use those or other techniques that don't respect the same-origin restriction. Instead, they could just directly call functions in one iframe from another iframe (parent.doSomething( blah )). Browsers will only allow this between same-origin iframes. If an implementor needs cross domain functionality, there's a new, safer technology that allows both ends to whitelist who they talk to. Cross-document messaging http://www.w3.org/TR/html5/comms.html#crossDocumentMessages I'm not familiar with cross-document messaging or how well it's supported by browsers. Also note that same-origin security does not protect against malicious communication between two iframes on the same origin but different paths. http://example.com/naive-client/ and http://example.com/evil-scraper/, for example. Because of that, the child iframe should probably check its parent's entire URL, not just the domain/origin. Mike --mdawaffe From beaton@google.com Wed Jul 7 18:04: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 791F03A68D9 for ; Wed, 7 Jul 2010 18:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.141 X-Spam-Level: X-Spam-Status: No, score=-105.141 tagged_above=-999 required=5 tests=[AWL=0.836, 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 1JFrQUmO5nSz for ; Wed, 7 Jul 2010 18:04:04 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A3F7F3A68A4 for ; Wed, 7 Jul 2010 18:04:04 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o68147Eq019354 for ; Wed, 7 Jul 2010 18:04:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278551047; bh=JXXGaAro+olV4slco2Np7v7cbA4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ShJDsGbIf0JBD+fFKx534MaoYG+qN/XDB2FUFtBsyvKHxq3rccunoJcUJY9dT/tAz mzRYAS/7Do3s8vMj5iVww== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=sllYHllBS7mMwzhga8+vfGFbdDHKumXkhA5vnnvL7QmrTJcGG5OSs4PMHs1IMYl5u KZe2foYMDI5eL4/slMm0A== Received: from pxi5 (pxi5.prod.google.com [10.243.27.5]) by hpaq7.eem.corp.google.com with ESMTP id o6813jil015990 for ; Wed, 7 Jul 2010 18:04:06 -0700 Received: by pxi5 with SMTP id 5so140109pxi.23 for ; Wed, 07 Jul 2010 18:04:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.171.9 with SMTP id t9mr4202287wfe.62.1278551045515; Wed, 07 Jul 2010 18:04:05 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Wed, 7 Jul 2010 18:04:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Jul 2010 18:04:05 -0700 Message-ID: From: Brian Eaton To: Chuck Mortimore Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 01:04:06 -0000 On Wed, Jul 7, 2010 at 4:51 PM, Chuck Mortimore wrote: > This thread forced a great deal on internal discussion today, and we > actually do have some more immediate use-cases where we'll require > client_id with the assertion flow > > I support leaving it as optional Can you describe the additional use cases? And do they require refresh tokens as well? I'm really worried about jamming multiple use cases into a single profile, and then being surprised when: a) that profile is suboptimal for all of the use cases b) developers are hugely confused by it Cheers, Brian From cmortimore@salesforce.com Wed Jul 7 18:25: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 69F6C3A6781 for ; Wed, 7 Jul 2010 18:25:00 -0700 (PDT) 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 pk3AJIZWqH66 for ; Wed, 7 Jul 2010 18:24:59 -0700 (PDT) Received: from exprod8og108.obsmtp.com (exprod8og108.obsmtp.com [64.18.3.96]) by core3.amsl.com (Postfix) with SMTP id 4BF363A677C for ; Wed, 7 Jul 2010 18:24:59 -0700 (PDT) Received: from source ([209.85.212.43]) by exprod8ob108.postini.com ([64.18.7.12]) with SMTP ID DSNKTDUo7se8hYFLlQ4ZQTo9w0nYGBU/2j87@postini.com; Wed, 07 Jul 2010 18:25:03 PDT Received: by vws4 with SMTP id 4so535261vws.2 for ; Wed, 07 Jul 2010 18:25:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.98 with SMTP id t34mr3848206vcr.130.1278552301697; Wed, 07 Jul 2010 18:25:01 -0700 (PDT) Received: by 10.220.177.70 with HTTP; Wed, 7 Jul 2010 18:25:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Jul 2010 18:25:01 -0700 Message-ID: From: Chuck Mortimore To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 01:25:00 -0000 Use-case: When establishing web federation with customers we allow them to either use their salesforce username ( enforced to be globally unique ) or a federationid ( enforced to be unique to that particular customer/tenant ) as the subject of their SAML assertion. Since our SAML ACS is global for all customers, as is our OAuth token endpoint, when federationid is being used we need an additional piece of data to disabiguate the customer...essentially namespacing the federationid. On our ACS endpoint, we accept a parameter. For this use-case on our token endpoint we'll use client_id. The alternative us we use some other proprietary parameter to identify what org the client belongs to. This is optional for us, and depends on an individual customer configuration. We will not be issuing refresh tokens. Clients will need to get/mint a new one-time-use saml bearer assertion if they want a new access token I'm a believer that devs will have to reference other docs and specs for the assertion flow. Perhaps making this language stronger would help? -cmort On Wednesday, July 7, 2010, Brian Eaton wrote: > On Wed, Jul 7, 2010 at 4:51 PM, Chuck Mortimore > wrote: >> This thread forced a great deal on internal discussion today, and we >> actually do have some more immediate use-cases where we'll require >> client_id with the assertion flow >> >> I support leaving it as optional > > Can you describe the additional use cases? > > And do they require refresh tokens as well? > > I'm really worried about jamming multiple use cases into a single > profile, and then being surprised when: > a) that profile is suboptimal for all of the use cases > b) developers are hugely confused by it > > Cheers, > Brian > From ietf.org@zetafleet.com Wed Jul 7 18:33: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 7C8C53A699D for ; Wed, 7 Jul 2010 18:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+2hjhMQZAXF for ; Wed, 7 Jul 2010 18:33:33 -0700 (PDT) Received: from one.acitia.com (one.acitia.com [66.135.55.251]) by core3.amsl.com (Postfix) with ESMTP id 150793A6988 for ; Wed, 7 Jul 2010 18:33:33 -0700 (PDT) Received: from c-75-73-43-136.hsd1.mn.comcast.net ([75.73.43.136] helo=Trillian.hsd1.mn.comcast.net) by one.acitia.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1OWfzC-0006TN-2k; Thu, 08 Jul 2010 01:33:10 +0000 Message-ID: <4C352AEA.1050503@zetafleet.com> Date: Wed, 07 Jul 2010 20:33:30 -0500 From: Colin Snover User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Luke Shepard References: <4C242B7C.7040002@zetafleet.com> <4C245B02.2060306@zetafleet.com> In-Reply-To: <4C245B02.2060306@zetafleet.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Add an option to authorization endpoint to force end-user re-authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 01:33:34 -0000 Hi, I just wanted to follow up and see if I could solicit a bit more feedback on this request, since it sounds like the end of the OAuth 2 spec is growing near and I would like to see something added to resolve this problem if at all feasible (or suggestions on how else to deal with it; maybe OIDC is the solution but its only half a solution if its optional/supplementary). Thanks, -- original message follows -- On 25/06/2010 02:30, Colin Snover wrote: > On 24/06/2010 23:30, Luke Shepard wrote: >> You're right; this can be an interesting issue. It's very tied up in >> identity - if you are talking about connecting accounts (like you >> would with Facebook) then there's a layer missing from OAuth that >> provides the identity on top of it. At the moment, there are a few >> proposals (for instance, OpenID Connect) which distinguish between an >> immediate request (which returns immediately) vs a regular request >> (which does not). >> >> For now, I think the right behavior is for the client to give the >> user a chance to switch accounts. That means the identity layer needs >> to offer a way to log out as well as authorize ( see >> http://www.sociallipstick.com/?p=189 for more thoughts on this). If >> you are using Facebook, we offer a custom way to log the user out >> (http://developers.facebook.com/docs/reference/javascript/FB.logout ). >> >> In any case, Facebook will likely add this layer on top of OAuth once >> it becomes a little more settled. There has been a lot of discussion >> on this list lately about exactly what form that should take. >> >> Does that answer the question? > > Hi Luke, > > Thanks for writing. Im obviously flying a little blind in regards to > whats already been proposed, so I appreciate the links. > > I took a brief look at OpenID Connect. If I am reading this correctly, > it would resolve our issue since the client would collect and pass the > desired user_id to the authorization server, right? I guess the > biggest problem I see here is that unless OIDC support is mandated in > the OAuth spec, implicit authorisation will probably continue to > happen with providers that dont want to support itand Im guessing > there would be a fair amount of opposition to any sort of strong > coupling between OAuth and OIDC? > > I also did a little more digging through the mailing list while > investigating what you said and saw that there was a suggestion > earlier for an immediate parameter, which appears to address the > opposite of the situation Ive raised and was added in draft 2 (but > removed in draft 7). Notes on draft 7 dont seem to mention its > removal, so Im not entirely sure why it is gone now (because it would > mean that OAuth would need to become an identity layer?), but it > sounds like there is a desire for /three/ different modes of OAuth > operation: an immediate mode, a default or hybrid mode (like > OAuth 1.0a), and an always-reauthenticate mode. Is that accurate? > > Unless Im misinterpreting what is being suggested, I dont think that > an option to provide a Log out link to end-users from within clients > is the right way to solve this problem. The ability to authorise > multiple accounts from one provider at the same time is essential to > what we are trying to do; switching only makes sense if the client can > only handle one account at a time. Beyond that, there are a few other > issues I can think of with this proposal, which I hope have been > raised before: > > 1. Logging a user-agent out of a providers site isnt really what we > want to do here; we just want to provide the end-user an opportunity > to authorise an account that happens to /not/ be the account their > user-agent is already logged into. Maybe the provider decides that > this needs to cause a log out, but OAuth ideally shouldnt /require/ > the interruption of another existing session just because we happen to > be using the same user-agent for authorisation. > > 2. If a programmatic method for logging out was required to solve this > problem, it would be wide open to abuse by people that want to be > annoying and force people to get logged out of their providers sites. > (This isnt terribly uncommon, of course, since most log-outs are > simple GET requests, but it seems like something that would be good to > avoid perpetuating. I dont know how Facebook deals with this.) > > 3. It also seems like a fairly bad idea from a privacy standpoint to > provide a mechanism that allows an unauthorised client to determine > whether or not a visitor is already logged in on a particular > providers site, since it opens up a new avenue for history sniffing, > etc. In order to resolve the issue I have raised through the use of a > log out button in the client, this would seem to be necessary > without compromising look-and-feel through the use of an iframe. (I > seem to have inadvertently neglected to mention in my original message > what happens when an end-users UA is already logged in to a provider, > but the client is /not/ yet authorised: if they want to pick a > different account to authorise instead of the already logged-in > account, they have to log out of the provider, optionally log in with > the correct credentials, then go back to the client and restart the > OAuth request from the beginning. That sucks too!) > > Anyway, TL;DR: Being able to pre-provide information as to which > account is being requested, la OpenID Connect, is one potential > solution, but unless its mandated along with OAuth 2, the implicit > authorisation problem will still exist for providers that opt out of > OIDC. Without turning OAuth into an identity layer, it would seem that > a flag to force reauthentication la my original proposal would be > necessary. Of course, this would not solve the immediate problem, > but it sounds like thats not safely solvable without identity anyway. > Maybe there is another option, but Im not able to think of one. > > Regards, > -- Colin Snover http://zetafleet.com From eran@hueniverse.com Wed Jul 7 18:56:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22C463A6827 for ; Wed, 7 Jul 2010 18:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.417, 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 iKiMzUoCOazf for ; Wed, 7 Jul 2010 18:56:44 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 3EA5E3A69F3 for ; Wed, 7 Jul 2010 18:56:44 -0700 (PDT) Received: (qmail 30726 invoked from network); 8 Jul 2010 01:56:47 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Jul 2010 01:56:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 7 Jul 2010 18:56:47 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Wed, 7 Jul 2010 18:56:45 -0700 Thread-Topic: assertion profile changes Thread-Index: AcseH/MyK3HVzncdQBS791HHO2R7fAAIN4ye Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85A7E6D36D91eranhueniversecom_" MIME-Version: 1.0 Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 01:56:50 -0000 --_000_C85A7E6D36D91eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BTW, I'm not opposed to writing more detailed profiles based on the generic= framework provided by the two endpoints defined and theyr many optional co= mponents. I think the new format helps clarify the overall architecture and= easier to implement a generic client for (given that all the parameters fo= r each endpoint are listed in a single place). If people think this can be useful, I'm happy to give it a try once -10 is = out and declared stable. EHL On 7/7/10 3:01 PM, "Brian Eaton" wrote: On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav wro= te: > I disagree with this approach. There are plenty of optional parameters in > the spec. Yes. I think most of them are a bad idea. > The assertion access grant requires further profiling to be useful. This > doesn't mean it needs another spec, but that when you use it, you need to > document clearly what is expected. When you do that, spell out what you > support and what not. It doesn't, actually. Lots of people have existing SAML assertion formats that they support, and they are going to use the SAML to access token swap without any further spec writing. > It is not clear what about allowing client authentication or refresh toke= n > breaks security. This is purely a deployment decision for each provider. Please see this thread: http://www.ietf.org/mail-archive/web/oauth/current/msg02218.html. Note multiple voices of approval for dropping the refresh token. Note that people who want the refresh token have *completely different use cases*. Steering multiple use cases into the same profile is how we made OAuth 1.0 complex, slow, and insecure. Let's not make the same mistake with OAuth 2. > If you would like to request specific changes to draft -09, please list t= hem > and explain why you are requesting them. I'd like to see the following changes: 1) Separate profiles for separate use cases. The spec started off this way, and recent drafts have made it progressively more compressed. Shorter is not a win. 2) Drop refresh token, client id, and client secret from the SAML flow. If someone needs them, that's OK, but put it in different profile for a different use case. Cheers, Brian --_000_C85A7E6D36D91eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: assertion profile changes BTW, I’m not opposed to writing more detailed profiles based on= the generic framework provided by the two endpoints defined and theyr many= optional components. I think the new format helps clarify the overall arch= itecture and easier to implement a generic client for (given that all the p= arameters for each endpoint are listed in a single place).

If people think this can be useful, I’m happy to give it a try once &= #8211;10 is out and declared stable.

EHL


On 7/7/10 3:01 PM, "Brian Eaton" <beaton@google.com> wrote:

On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer= -Lahav <eran@hueniverse.com> wrot= e:
> I disagree with this approach. There are plenty of optional parameters= in
> the spec.

Yes.  I think most of them are a bad idea.

> The assertion access grant requires further profiling to be useful. Th= is
> doesn’t mean it needs another spec, but that when you use it, yo= u need to
> document clearly what is expected. When you do that, spell out what yo= u
> support and what not.

It doesn't, actually.  Lots of people have existing SAML assertion
formats that they support, and they are going to use the SAML to
access token swap without any further spec writing.

> It is not clear what about allowing client authentication or refresh t= oken
> breaks security. This is purely a deployment decision for each provide= r.

Please see this thread:
http://www.ietf.org/mail-archive/web/oauth/current/msg02218.html.

Note multiple voices of approval for dropping the refresh token.

Note that people who want the refresh token have *completely different
use cases*.

Steering multiple use cases into the same profile is how we made OAuth
1.0 complex, slow, and insecure.  Let's not make the same mistake with=
OAuth 2.

> If you would like to request specific changes to draft –09, plea= se list them
> and explain why you are requesting them.

I'd like to see the following changes:

1) Separate profiles for separate use cases.
   The spec started off this way, and recent drafts have mad= e it
progressively more compressed.  Shorter is not a win.

2) Drop refresh token, client id, and client secret from the SAML flow.
    If someone needs them, that's OK, but put it in dif= ferent profile
for a different use case.

Cheers,
Brian

--_000_C85A7E6D36D91eranhueniversecom_-- From eran@hueniverse.com Wed Jul 7 19:49:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE5AD3A67B7 for ; Wed, 7 Jul 2010 19:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.391, 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 hkNA8YVbXgen for ; Wed, 7 Jul 2010 19:49:00 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 6E63B3A63CB for ; Wed, 7 Jul 2010 19:49:00 -0700 (PDT) Received: (qmail 7598 invoked from network); 8 Jul 2010 02:49:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Jul 2010 02:49:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 7 Jul 2010 19:49:01 -0700 From: Eran Hammer-Lahav To: Dirk Balfanz , OAuth WG Date: Wed, 7 Jul 2010 19:49:00 -0700 Thread-Topic: [OAUTH-WG] proposal for signatures Thread-Index: AcsREBK1USivH/OTSPiixmXBrlWmSwNOAtJ4 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85A8AAC36D96eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 02:49:02 -0000 --_000_C85A8AAC36D96eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can we get an updated document based on the feedback received? EHL On 6/21/10 12:04 AM, "Dirk Balfanz" wrote: Hi guys, I think I owe the list a proposal for signatures. I wrote something down that liberally borrows ideas from Magic Signatures <= http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.ht= ml> , SWT , and (even the na= me from) JSON Web Tokens . Here is a short document (called "JSON Tokens") that just explains how to s= ign something and verify the signature: http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm= 75-FmKwNo4 Here is an extension of JSON Tokens that can be used for signed OAuth token= s: http://docs.google.com/document/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZ= W8OWX9HOUU Here is a different extension of JSON Tokens that can be used for 2-legged = flows. The idea is that this could be used as a drop-in replacement for SAM= L assertions in the OAuth2 assertion flow: http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQ= V_pCoOowzc I also have started to write some code to implement = this as a proof-of-concept. Thoughts? Comments? Dirk. --_000_C85A8AAC36D96eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] proposal for signatures Can we get an updated document based on the feedback received?

EHL


On 6/21/10 12:04 AM, "Dirk Balfanz" <balfanz@google.com> wrote:

</>  </> Hi guys,=A0

I think I owe the list a proposal for signatures.

I wrote something down that=A0liberally=A0borrows ideas from Magic = Signatures <http://salmon-protocol.googlecode.com/svn/tru= nk/draft-panzer-magicsig-00.html> , SWT <http://groups.google.com/group/WRAP-WG/fil= es> , and (even the name from) JSON Web Tokens <h= ttps://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd= 0#> .=A0

Here is a short document (called "JSON Tokens") that just explain= s how to sign something and verify the signature:
http://docs.google.com/document/pub?id=3D1kv6Oz_HRnW= a0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4

Here is an extension of JSON Tokens that can be used for signed OAuth token= s: <http://docs.google.com/document/pub?id=3D1JUn= 3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU>
http://docs.google.com/document/pub?id=3D1JUn3Twd9nX= wFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU

Here is a different extension of JSON Tokens that can be used for 2= -legged flows. The idea is that this could be used as a drop-in replacement= for SAML assertions in the OAuth2 assertion flow:
http://docs.google.com/document/pub?id=3D1s4kjRS9P0f= rG0ulhgP3He01ONlxeTwkFQV_pCoOowzc

I also have started to write some code <= http://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/n= et/oauth/signatures>  to implement this as a proof-of-concept.= =A0

Thoughts? Comments?

Dirk.


--_000_C85A8AAC36D96eranhueniversecom_-- From lr@lukasrosenstock.net Thu Jul 8 00:43: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 5EABA3A6869 for ; Thu, 8 Jul 2010 00:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.53 X-Spam-Level: X-Spam-Status: No, score=0.53 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy3qOjW7j0LA for ; Thu, 8 Jul 2010 00:43:17 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 6478E3A6803 for ; Thu, 8 Jul 2010 00:43:17 -0700 (PDT) Received: by vws14 with SMTP id 14so778577vws.31 for ; Thu, 08 Jul 2010 00:43:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.184.145 with SMTP id ck17mr261194qcb.236.1278574996995; Thu, 08 Jul 2010 00:43:16 -0700 (PDT) Received: by 10.229.100.135 with HTTP; Thu, 8 Jul 2010 00:43:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Jul 2010 09:43:16 +0200 Message-ID: From: Lukas Rosenstock To: Michael D Adams Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 07:43:18 -0000 2010/7/8 Michael D Adams : > If an implementor needs cross domain functionality, there's a new, > safer technology that allows both ends to whitelist who they talk to. > > Cross-document messaging > http://www.w3.org/TR/html5/comms.html#crossDocumentMessages > > I'm not familiar with cross-document messaging or how well it's > supported by browsers. It is supported by Firefox 3+, IE 8+, Opera 9+, Safari 4+ and Chrome, so mostly IE 6/7 should be the problem (as usual ...). And, by the way, the controversial XAuth completely relies on this technique. There could be one flow in which the authentication server, instead of redirecting, would pass the token through postMessage() with a targetOrigin that was pre-configured by the client, but I guess that is nothing for the core spec at this moment. Just an idea. Regards, Lukas Rosenstock From lr@lukasrosenstock.net Thu Jul 8 00:49: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 A1D773A67E9 for ; Thu, 8 Jul 2010 00:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.724 X-Spam-Level: X-Spam-Status: No, score=-0.724 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wvn7Jkm-ZfQ4 for ; Thu, 8 Jul 2010 00:49:42 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 8EA613A67AC for ; Thu, 8 Jul 2010 00:49:42 -0700 (PDT) Received: by qyk1 with SMTP id 1so2784928qyk.10 for ; Thu, 08 Jul 2010 00:49:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.66.211 with SMTP id o19mr4309519qai.199.1278575383309; Thu, 08 Jul 2010 00:49:43 -0700 (PDT) Received: by 10.229.100.135 with HTTP; Thu, 8 Jul 2010 00:49:43 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Jul 2010 09:49:43 +0200 Message-ID: From: Lukas Rosenstock To: Marius Scurtescu Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] sequence diagrams X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 07:49:43 -0000 The sequence diagrams look just fine, I guess they could be really helpful for an OAuth newbie! 2010/7/1 Marius Scurtescu : > I created sequence diagrams for the main profiles supported by draft 09: > https://docs.google.com/leaf?id=0B_5REGY-7RjcMjYxMzE3YTAtZWY4My00YTM5LTgzMmMtY2QwZDc3ZmEwZjhi&hl=en > > Let me know if they make sense and how can they be improved. > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- http://lukasrosenstock.net/ From lvh@laurensvh.be Thu Jul 8 01:51: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 996133A698E for ; Thu, 8 Jul 2010 01:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI29MOQ9bwpl for ; Thu, 8 Jul 2010 01:51:37 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 78D9C3A6980 for ; Thu, 8 Jul 2010 01:51:37 -0700 (PDT) Received: by fxm1 with SMTP id 1so271069fxm.31 for ; Thu, 08 Jul 2010 01:51:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.162.132 with SMTP id l4mr813415hbd.133.1278579097674; Thu, 08 Jul 2010 01:51:37 -0700 (PDT) Received: by 10.239.181.206 with HTTP; Thu, 8 Jul 2010 01:51:36 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Jul 2010 10:51:36 +0200 Message-ID: From: Laurens Van Houtven To: Chuck Mortimore Content-Type: text/plain; charset=UTF-8 Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 08:51:38 -0000 Just pitching in as someone writing something that might want a refresh token but *really* doesn't understand why he'd need them. They make very little sense to me; why not just make the token that allows you to access a protected resource last longer? Use case: we've got protected resources that get updated regularly, and authorizations to read from it are always long-term (generally indefinitely). Not that my vote carries much weight, but I'm definitely in favor of simply dropping refresh tokens. cheers Laurens From kris.selden@gmail.com Thu Jul 8 02:53: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 9F7DD3A6A0B for ; Thu, 8 Jul 2010 02:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBQeTAiiD7LE for ; Thu, 8 Jul 2010 02:53:51 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 060003A6A07 for ; Thu, 8 Jul 2010 02:53:50 -0700 (PDT) Received: by pvd12 with SMTP id 12so345545pvd.31 for ; Thu, 08 Jul 2010 02:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=N5vhCVzlb6Gs7jz7sJVkS8MYPTPn/I5ATEHprg8CXNM=; b=Dt+yHkdkLCjmxiMjqT3Zs9Pt6e3NXev2WspmM+YVw06v8MF86nFp5S3+NHXJ6/ZT1j +yf2uvK0wxXcQa/URAIHXvTHe41dZVXYJtag+0+FGYgV+gElHfpioXe+1HaBZkvSOo0R 4cYAmHlitVPxCDmg5x3iccmbEBLvLHpQnw6DQ= 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=bf2KgYQ0PjWQtoeofLiWUF1xhMjgqh/OpwoVxbCyhrN1jUD07GxBsv+PEz6kzS8gpo w3xOnv/opygq3LVSEHb6+Ke+iRNWf/o6JsJSbcxR1Qm/gdm9UzsePl1bT3bJ5mwb6Eoy d5QyZ//818Kvz8oij5pGJPAch6IvFZGfHKwXo= Received: by 10.142.185.13 with SMTP id i13mr4509819wff.57.1278582832233; Thu, 08 Jul 2010 02:53:52 -0700 (PDT) Received: from [172.16.2.2] (c-76-121-106-185.hsd1.wa.comcast.net [76.121.106.185]) by mx.google.com with ESMTPS id c15sm8316907rvi.11.2010.07.08.02.53.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 08 Jul 2010 02:53:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Kris Selden In-Reply-To: Date: Thu, 8 Jul 2010 02:53:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <70187F4F-9351-4029-A519-4AA9A37E0557@gmail.com> References: To: Laurens Van Houtven X-Mailer: Apple Mail (2.1081) Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 09:53:52 -0000 The refresh token is key to separating concerns of the protected = resource from the auth server. I think this is succinctly explained the original rationale (refresh = token =3D refresh secret): http://wiki.oauth.net/ScalableOAuth#Appendix On Jul 8, 2010, at 1:51 AM, Laurens Van Houtven wrote: > Just pitching in as someone writing something that might want a > refresh token but *really* doesn't understand why he'd need them. They > make very little sense to me; why not just make the token that allows > you to access a protected resource last longer? Use case: we've got > protected resources that get updated regularly, and authorizations to > read from it are always long-term (generally indefinitely). >=20 > Not that my vote carries much weight, but I'm definitely in favor of > simply dropping refresh tokens. >=20 > cheers > Laurens > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From sDronia@gmx.de Thu Jul 8 04:05:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA2E93A6A16 for ; Thu, 8 Jul 2010 04:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyISZKfAOHA5 for ; Thu, 8 Jul 2010 04:05:42 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6A2043A6A4B for ; Thu, 8 Jul 2010 04:05:40 -0700 (PDT) Received: (qmail 18400 invoked by uid 0); 8 Jul 2010 11:05:44 -0000 Received: from 195.243.113.249 by www178.gmx.net with HTTP; Thu, 08 Jul 2010 13:05:42 +0200 (CEST) Content-Type: multipart/alternative; boundary="========GMXBoundary150741278587142970818" Date: Thu, 08 Jul 2010 13:05:42 +0200 From: "Stefanie Dronia" In-Reply-To: Message-ID: <20100708110542.150740@gmx.net> MIME-Version: 1.0 References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2DC7C5.2090009@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F108B.70504@cdatazone.org> To: Marius Scurtescu X-Authenticated: #3259608 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/orgB3HbnoZjyArqlD/sg3clTxFwUczBoJ695sD8 ChPk5qcYkXuUGp07dAhNLg1r76DcnjGMhKEg== X-GMX-UID: YthQDYxOfW47aOLmRmVoXHhudmllcgWx X-FuHaFi: 0.52000000000000002,0.52000000000000002 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 11:05:45 -0000 --========GMXBoundary150741278587142970818 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi,   I took a look at the OAuth 1 Bridge Flow suggested by Marius, the thread "OAuth 1 Bridge Flow" and had some thoughts:   I do not really see the necessity for such a flow. First of all, all participating parties have to be modified and rolled out: - the consumer's application to support (at least) the bridge flow (and OAuth 2 [1]), - the authz server to provide OAuth 2  and additionally the bridge flow and - the resource server to handle OAuth2. Then, sometime later, when at least the authz server doesn't support OAuth 1 anymore, the client application and the resource server should be cleared up - no more OAuth 1, only OAuth 2. Again a new version to roll out.   The only (small) benefit I see, is that the user will not be asked for authorization again. But is it worth it to develop, implement and roll out a Bridge Flow? I do not think so - too much expense for a small user interaction. Better: directly go to OAuth 2, when it is needed.   The other thing I'm missing, is how to migrate completely to OAuth 2 after performing the bridge flow. Issuing a refresh token in the response seems necessary. But this issue was still mentioned (but not solved) in the thread "OAuth 1 Bridge Flow" by Eran.     Thanks, Steffi   [1] if OAuth 2 will not be supported, a new modified client has to be rolled out at the latest, the resource server doesn't support OAuth 1 anymore.   > -------- Original-Nachricht -------- > Datum: Tue, 6 Jul 2010 21:54:16 -0700 > Von: Marius Scurtescu > An: Rob Richards > CC: "oauth@ietf.org" > Betreff: Re: [OAUTH-WG] Versioning > > On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards > wrote: > > Eran Hammer-Lahav wrote: > >> > >> Hi Rob, > >> > >> I agree with you that a migration spec is important - please write > one. > >> > > > > Like I didn't see that coming :) > > I would like to help with this migration spec. Is this a good starting > point: > http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html > > Or, you had something else in mind? > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 --========GMXBoundary150741278587142970818 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

I took a look at the OAuth 1 Bridge Flow sugges= ted by Marius, the thread "OAuth 1 Bridge Flow" and had some tho= ughts:

 

I do not really see the necessity for such a fl= ow.

First of all, all participating parties have to = be modified and rolled out:

- the consumer's application to support (at lea= st) the bridge flow (and OAuth 2 [1]),

- the authz server to provide OAuth 2  and= additionally the bridge flow and

- the resource server to handle OAuth2.

Then, sometime later, when at least the authz se= rver doesn't support OAuth 1 anymore, the client application and the resou= rce server should be cleared up - no more OAuth 1, only OAuth 2. Again a n= ew version to roll out.

 

The only (small) benefit I see, is that the user= will not be asked for authorization again.

But is it worth it to develop, implement and rol= l out a Bridge Flow? I do not think so - too much expense for a small user= interaction.

Better: directly go to OAuth 2, when it is need= ed.

 

The other thing I'm missing, is how to migrate c= ompletely to OAuth 2 after performing the bridge flow. Issuing a refresh t= oken in the response seems necessary. But this issue was still mentioned (= but not solved) in the thread "OAuth 1 Bridge Flow" by Eran.

 

 

Thanks,

Steffi

 

[1] if OAuth 2 will not be supported, a new modi= fied client has to be rolled out at the latest, the resource server doesn'= t support OAuth 1 anymore.

 

-------- Original-Nachricht --------
Datum: Tue, 6 Jul = 2010 21:54:16 -0700
Von: Marius Scurtescu <mscurtescu@google.com>= ;
An: Rob Richards <rrichards@cdatazone.org>
CC: "oaut= h@ietf.org" <oauth@ietf.org>
Betreff: Re: [OAUTH-WG] Versio= ning

On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards <rrichards@cdat= azone.org> wrote:
> Eran Hammer-Lahav wrote:
>>
= >> Hi Rob,
>>
>> I agree with you that a migrat= ion spec is important - please write one.
>>
>
>= Like I didn't see that coming :)

I would like to help with this= migration spec. Is this a good starting point:
http://www.ietf.org/ma= il-archive/web/oauth/current/msg02300.html

Or, you had something= else in mind?

Marius
_____________________________________= __________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth



--
GRATIS f=C3=BCr= alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter= http://portal.gmx.net/de/go/maxdome01
--========GMXBoundary150741278587142970818-- From lvh@laurensvh.be Thu Jul 8 04:29:51 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372CD3A6A53 for ; Thu, 8 Jul 2010 04:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.067 X-Spam-Level: X-Spam-Status: No, score=0.067 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+zjA42fKATv for ; Thu, 8 Jul 2010 04:29:50 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 0DA783A6A43 for ; Thu, 8 Jul 2010 04:29:49 -0700 (PDT) Received: by fxm1 with SMTP id 1so369456fxm.31 for ; Thu, 08 Jul 2010 04:29:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.161.132 with SMTP id h4mr883374hbd.55.1278588590154; Thu, 08 Jul 2010 04:29:50 -0700 (PDT) Received: by 10.239.181.206 with HTTP; Thu, 8 Jul 2010 04:29:49 -0700 (PDT) In-Reply-To: <70187F4F-9351-4029-A519-4AA9A37E0557@gmail.com> References: <70187F4F-9351-4029-A519-4AA9A37E0557@gmail.com> Date: Thu, 8 Jul 2010 13:29:49 +0200 Message-ID: From: Laurens Van Houtven To: Kris Selden Content-Type: text/plain; charset=UTF-8 Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 11:29:51 -0000 On Thu, Jul 8, 2010 at 11:53 AM, Kris Selden wrote: > The refresh token is key to separating concerns of the protected resource from the auth server. > > I think this is succinctly explained the original rationale (refresh token = refresh secret): > http://wiki.oauth.net/ScalableOAuth#Appendix That suggests security issues. If I use tokens that can be used to access protected resources for extended periods of time, why can't I just revoke the compromised tokens (possibly all of them) when a leak is discovered? It seems somewhat convoluted to introduce a new system and then just wait until a timeout happens (although that timeout may be acceptably small)... I do not understand how it separates concerns more than they were already separated under OA1.0a. Under OA1.0a, if I understand correctly, the auth server produces tokens, and the protected resource consumes them. That feels like two separate concerns to me. cheers Laurens From jricher@mitre.org Thu Jul 8 08:21:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38D03A6AFD for ; Thu, 8 Jul 2010 08:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, 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 Qa0F9CKzRr-N for ; Thu, 8 Jul 2010 08:21:28 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id DE7DC3A6AE2 for ; Thu, 8 Jul 2010 08:21:27 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o68FLVq9007837 for ; Thu, 8 Jul 2010 11:21:31 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o68FLV9D007825; Thu, 8 Jul 2010 11:21:31 -0400 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, 8 Jul 2010 11:21:31 -0400 From: Justin Richer To: Brian Eaton In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Thu, 8 Jul 2010 11:21:30 -0400 Message-ID: <1278602490.2445.47.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 15:21:33 -0000 Would it help if the client_ stuff were dropped from the example in the assertion flow? I'm in favor of it being allowed, but if the general use case is going to be without it then the example should reflect that and cut down on the confusion. -- Justin On Wed, 2010-07-07 at 18:01 -0400, Brian Eaton wrote: > On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav wrote: > > I disagree with this approach. There are plenty of optional parameters in > > the spec. > > Yes. I think most of them are a bad idea. > > > The assertion access grant requires further profiling to be useful. This > > doesn’t mean it needs another spec, but that when you use it, you need to > > document clearly what is expected. When you do that, spell out what you > > support and what not. > > It doesn't, actually. Lots of people have existing SAML assertion > formats that they support, and they are going to use the SAML to > access token swap without any further spec writing. > > > It is not clear what about allowing client authentication or refresh token > > breaks security. This is purely a deployment decision for each provider. > > Please see this thread: > http://www.ietf.org/mail-archive/web/oauth/current/msg02218.html. > > Note multiple voices of approval for dropping the refresh token. > > Note that people who want the refresh token have *completely different > use cases*. > > Steering multiple use cases into the same profile is how we made OAuth > 1.0 complex, slow, and insecure. Let's not make the same mistake with > OAuth 2. > > > If you would like to request specific changes to draft –09, please list them > > and explain why you are requesting them. > > I'd like to see the following changes: > > 1) Separate profiles for separate use cases. > The spec started off this way, and recent drafts have made it > progressively more compressed. Shorter is not a win. > > 2) Drop refresh token, client id, and client secret from the SAML flow. > If someone needs them, that's OK, but put it in different profile > for a different use case. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Jul 8 08:53:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A437E3A6B19 for ; Thu, 8 Jul 2010 08:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.368, 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 itMK0pMiBp4q for ; Thu, 8 Jul 2010 08:53:52 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B24A13A6B18 for ; Thu, 8 Jul 2010 08:53:52 -0700 (PDT) Received: (qmail 11175 invoked from network); 8 Jul 2010 15:53:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Jul 2010 15:53:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 8 Jul 2010 08:53:48 -0700 From: Eran Hammer-Lahav To: Justin Richer , Brian Eaton Date: Thu, 8 Jul 2010 08:53:44 -0700 Thread-Topic: [OAUTH-WG] assertion profile changes Thread-Index: AcsesUA64Go9kF+/RJuwfKps/vCr/gABH4GO Message-ID: In-Reply-To: <1278602490.2445.47.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85B429836DE6eranhueniversecom_" MIME-Version: 1.0 Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 15:53:58 -0000 --_000_C85B429836DE6eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Already is. http://github.com/theRazorBlade/draft-ietf-oauth/raw/3e9a1e67807b7bbfe79ca4= 045a44b613ef45c990/draft-ietf-oauth-v2.txt EHL On 7/8/10 8:21 AM, "Justin Richer" wrote: Would it help if the client_ stuff were dropped from the example in the assertion flow? I'm in favor of it being allowed, but if the general use case is going to be without it then the example should reflect that and cut down on the confusion. -- Justin On Wed, 2010-07-07 at 18:01 -0400, Brian Eaton wrote: > On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav w= rote: > > I disagree with this approach. There are plenty of optional parameters = in > > the spec. > > Yes. I think most of them are a bad idea. > > > The assertion access grant requires further profiling to be useful. Thi= s > > doesn't mean it needs another spec, but that when you use it, you need = to > > document clearly what is expected. When you do that, spell out what you > > support and what not. > > It doesn't, actually. Lots of people have existing SAML assertion > formats that they support, and they are going to use the SAML to > access token swap without any further spec writing. > > > It is not clear what about allowing client authentication or refresh to= ken > > breaks security. This is purely a deployment decision for each provider= . > > Please see this thread: > http://www.ietf.org/mail-archive/web/oauth/current/msg02218.html. > > Note multiple voices of approval for dropping the refresh token. > > Note that people who want the refresh token have *completely different > use cases*. > > Steering multiple use cases into the same profile is how we made OAuth > 1.0 complex, slow, and insecure. Let's not make the same mistake with > OAuth 2. > > > If you would like to request specific changes to draft -09, please list= them > > and explain why you are requesting them. > > I'd like to see the following changes: > > 1) Separate profiles for separate use cases. > The spec started off this way, and recent drafts have made it > progressively more compressed. Shorter is not a win. > > 2) Drop refresh token, client id, and client secret from the SAML flow. > If someone needs them, that's OK, but put it in different profile > for a different use case. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_C85B429836DE6eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] assertion profile changes Already is.

http://github.com/th= eRazorBlade/draft-ietf-oauth/raw/3e9a1e67807b7bbfe79ca4045a44b613ef45c990/d= raft-ietf-oauth-v2.txt

EHL


On 7/8/10 8:21 AM, "Justin Richer" <jricher@mitre.org> wrote:

Would it help if the client_ stuff were dro= pped from the example in the
assertion flow? I'm in favor of it being allowed, but if the general use case is going to be without it then the example should reflect that and
cut down on the confusion.

 -- Justin

On Wed, 2010-07-07 at 18:01 -0400, Brian Eaton wrote:
> On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> > I disagree with this approach. There are plenty of optional param= eters in
> > the spec.
>
> Yes.  I think most of them are a bad idea.
>
> > The assertion access grant requires further profiling to be usefu= l. This
> > doesn’t mean it needs another spec, but that when you use i= t, you need to
> > document clearly what is expected. When you do that, spell out wh= at you
> > support and what not.
>
> It doesn't, actually.  Lots of people have existing SAML assertio= n
> formats that they support, and they are going to use the SAML to
> access token swap without any further spec writing.
>
> > It is not clear what about allowing client authentication or refr= esh token
> > breaks security. This is purely a deployment decision for each pr= ovider.
>
> Please see this thread:
> http://www.ietf.org/mail-archive/web/oauth/current/msg02218.html= .
>
> Note multiple voices of approval for dropping the refresh token.
>
> Note that people who want the refresh token have *completely different=
> use cases*.
>
> Steering multiple use cases into the same profile is how we made OAuth=
> 1.0 complex, slow, and insecure.  Let's not make the same mistake= with
> OAuth 2.
>
> > If you would like to request specific changes to draft –09,= please list them
> > and explain why you are requesting them.
>
> I'd like to see the following changes:
>
> 1) Separate profiles for separate use cases.
>    The spec started off this way, and recent drafts hav= e made it
> progressively more compressed.  Shorter is not a win.
>
> 2) Drop refresh token, client id, and client secret from the SAML flow= .
>     If someone needs them, that's OK, but put it i= n different profile
> for a different use case.
>
> Cheers,
> Brian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth



--_000_C85B429836DE6eranhueniversecom_-- From recordond@gmail.com Thu Jul 8 09:29: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 14BEC3A6B2A for ; Thu, 8 Jul 2010 09:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=1.022, 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 MXTwqbA13C23 for ; Thu, 8 Jul 2010 09:29:19 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8F87C3A6AF3 for ; Thu, 8 Jul 2010 09:29:19 -0700 (PDT) Received: by iwn38 with SMTP id 38so1091036iwn.31 for ; Thu, 08 Jul 2010 09:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=M5UtO8lwtIhQTaVmIUtgi75GmL6pPMcQ2qy9VVR3TfM=; b=jFTpCiXxVteb08i4o+XIL/XTElNWtzWsgg87lXRAa41hhN2jsZk/DWXZQ0t7ONfzv1 /ZmdlDk2pXP2r6zqVyAjzUNSfCb26MGZKw+9JDaHhBStFYReMxcS+OoK5tpi8uzqinbo dN+L0/tghLKWYWnlG8hfZQ80c4uar+VXPYcUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AeTvPHHHY45+ZPRtrsGMtbrVSevsYLCJvHd/Q5kfT445v0isDZ1ZfR7KYaEDJsraC1 a30N3urdy2Bj3aEbncts9nhtDHJQ4k8aqrI//X0NcJxDXGyJWOoKXJ5dN+e0HX3FLHYN HwRIF3AKBml3C7tBPkx0yfOSDWqFoeB3GaGEM= MIME-Version: 1.0 Received: by 10.231.171.7 with SMTP id f7mr846906ibz.72.1278606563599; Thu, 08 Jul 2010 09:29:23 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Thu, 8 Jul 2010 09:29:23 -0700 (PDT) Date: Thu, 8 Jul 2010 09:29:23 -0700 Message-ID: From: David Recordon To: OAuth WG Content-Type: multipart/alternative; boundary=0016369f9dc707e5ff048ae2ca79 Subject: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 16:29:22 -0000 --0016369f9dc707e5ff048ae2ca79 Content-Type: text/plain; charset=ISO-8859-1 I'm honestly trying to decide myself and a few other people are in similar situations. Thus a poll: A) Yes, I'm going to be in Maastricht B) Maybe, depends on the number of OAuth WG members going C) Maybe, depends on some other reason D) No If you're missing context, in a few weeks it is the IETF meeting in Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting scheduled all afternoon Tuesday the 27th. Thanks, --David --0016369f9dc707e5ff048ae2ca79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm honestly trying to decide myself and a few other people are in simi= lar situations. Thus a poll:
A) Yes, I'm going to be in=A0Maastrich= t
B) Maybe, depends on the number of OAuth WG members going
C) Maybe, depends on some other reason
D) No

<= /div>
If you're missing context, in a few weeks it is the IETF meet= ing in=A0Maastricht (http://www= .ietf.org/meeting/78/). The OAuth WG has a meeting scheduled all aftern= oon Tuesday the 27th.

Thanks,
--David
--0016369f9dc707e5ff048ae2ca79-- From recordond@gmail.com Thu Jul 8 09:29: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 845023A6B33 for ; Thu, 8 Jul 2010 09:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.681, 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 WQtU3DU7DMdU for ; Thu, 8 Jul 2010 09:29:34 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 43DD73A6B21 for ; Thu, 8 Jul 2010 09:29:34 -0700 (PDT) Received: by mail-iw0-f172.google.com with SMTP id 38so1091036iwn.31 for ; Thu, 08 Jul 2010 09:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=IMeTFWWlBsEGp89NQ91fszduEgYAUVPEzODK4y5vOcE=; b=DQ3csNc2eYimYZtOWWWzfYyaqj0lkyngEBBC5JhUWb0HYNQD6JduPSbEc8aaupxpaw ubcZ0OJgkx0lWo4iLNhvB1OPm5n1wxHeCxzX9MjBMes2hHTQ+pFcDl4AIwr6WHRKR5uM CZ/sF/Otg2IB0lih2L1wTIDF9zfaNFih9vaP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=qRW7LwUjH+Ykune74Bqs7U9lk/hsXHhxNcxUHXzZWBa+g26t86oxeU6ktwynxbxWaZ 4iNVYuzmTvPXKmgY4nh8F58b2cabcRUGVDwp0CRm1HjhvOxV/bl2hAdbYkuSAZVxJLFt HB7clNDEiD1vztkyf6xAX+eAZjz9x2Fxsb0H0= MIME-Version: 1.0 Received: by 10.42.9.1 with SMTP id k1mr1125118ick.70.1278606578292; Thu, 08 Jul 2010 09:29:38 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Thu, 8 Jul 2010 09:29:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Jul 2010 09:29:38 -0700 Message-ID: From: David Recordon To: OAuth WG Content-Type: multipart/alternative; boundary=001636e0a7c1e8195a048ae2ca25 Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 16:29:35 -0000 --001636e0a7c1e8195a048ae2ca25 Content-Type: text/plain; charset=ISO-8859-1 B On Thu, Jul 8, 2010 at 9:29 AM, David Recordon wrote: > I'm honestly trying to decide myself and a few other people are in similar > situations. Thus a poll: > A) Yes, I'm going to be in Maastricht > B) Maybe, depends on the number of OAuth WG members going > C) Maybe, depends on some other reason > D) No > > If you're missing context, in a few weeks it is the IETF meeting > in Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a > meeting scheduled all afternoon Tuesday the 27th. > > Thanks, > --David > --001636e0a7c1e8195a048ae2ca25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable B

On Thu, Jul 8, 2010 at 9:29 AM, David R= ecordon <record= ond@gmail.com> wrote:
I'm honestly trying to decide myself and a few other people are in simi= lar situations. Thus a poll:
A) Yes, I'm going to be in=A0Maastrich= t
B) Maybe, depends on the number of OAuth WG members going
C) Maybe, depends on some other reason
D) No

<= /div>
If you're missing context, in a few weeks it is the IETF meet= ing in=A0Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting sc= heduled all afternoon Tuesday the 27th.

Thanks,
--David

--001636e0a7c1e8195a048ae2ca25-- From cmortimore@salesforce.com Thu Jul 8 09:33: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 48B653A6B03 for ; Thu, 8 Jul 2010 09:33:11 -0700 (PDT) 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 gpBmoMyYuOQi for ; Thu, 8 Jul 2010 09:33:10 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by core3.amsl.com (Postfix) with SMTP id BA1163A6B45 for ; Thu, 8 Jul 2010 09:32:48 -0700 (PDT) Received: from source ([209.85.212.43]) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKTDX9q9TIy4vSHjrAsvLPtdBND6zWSgdf@postini.com; Thu, 08 Jul 2010 09:32:53 PDT Received: by vws4 with SMTP id 4so1647595vws.2 for ; Thu, 08 Jul 2010 09:32:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.49.204 with SMTP id w12mr4409591vcf.243.1278606760491; Thu, 08 Jul 2010 09:32:40 -0700 (PDT) Received: by 10.220.177.70 with HTTP; Thu, 8 Jul 2010 09:32:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Jul 2010 09:32:40 -0700 Message-ID: From: Chuck Mortimore To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 16:33:11 -0000 D On Thursday, July 8, 2010, David Recordon wrote: > B > > On Thu, Jul 8, 2010 at 9:29 AM, David Recordon wrot= e: > > I'm honestly trying to decide myself and a few other people are in simila= r situations. Thus a poll:A) Yes, I'm going to be in=A0MaastrichtB) Maybe, = depends on the number of OAuth WG members going > > C) Maybe, depends on some other reasonD) No > If you're missing context, in a few weeks it is the IETF meeting in=A0Maa= stricht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting sched= uled all afternoon Tuesday the 27th. > > > Thanks,--David > > From igor.faynberg@alcatel-lucent.com Thu Jul 8 09:40: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 B88573A6B2A for ; Thu, 8 Jul 2010 09:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.150, 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 U3yssQq9b50L for ; Thu, 8 Jul 2010 09:40:14 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 18D4A3A6B27 for ; Thu, 8 Jul 2010 09:40:14 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o68GeH5Q007335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2010 11:40:17 -0500 (CDT) Received: from [135.244.33.158] (faynberg.lra.lucent.com [135.244.33.158]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o68GeGpk019325; Thu, 8 Jul 2010 11:40:17 -0500 (CDT) Message-ID: <4C35FF6F.4040309@alcatel-lucent.com> Date: Thu, 08 Jul 2010 12:40:15 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: David Recordon References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: OAuth WG Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? 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, 08 Jul 2010 16:40:15 -0000 A) Igor David Recordon wrote: > I'm honestly trying to decide myself and a few other people are in > similar situations. Thus a poll: > A) Yes, I'm going to be in Maastricht > B) Maybe, depends on the number of OAuth WG members going > C) Maybe, depends on some other reason > D) No > > If you're missing context, in a few weeks it is the IETF meeting > in Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a > meeting scheduled all afternoon Tuesday the 27th. > > Thanks, > --David > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From stpeter@stpeter.im Thu Jul 8 09:40: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 6C6753A6B53 for ; Thu, 8 Jul 2010 09:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.78 X-Spam-Level: X-Spam-Status: No, score=-2.78 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfSgcqP8ZrKx for ; Thu, 8 Jul 2010 09:40:40 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 622EC3A6B40 for ; Thu, 8 Jul 2010 09:40:39 -0700 (PDT) Received: from dhcp-64-101-72-157.cisco.com (dhcp-64-101-72-157.cisco.com [64.101.72.157]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6D75C40E3C for ; Thu, 8 Jul 2010 10:40:43 -0600 (MDT) Message-ID: <4C35FF8B.1010004@stpeter.im> Date: Thu, 08 Jul 2010 10:40:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 16:40:47 -0000 > A) Yes, I'm going to be in Maastricht > If you're missing context, in a few weeks it is the IETF meeting > in Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a > meeting scheduled all afternoon Tuesday the 27th. And don't forget about several other sessions that might be of interest on Monday and Tuesday: HTTPBIS (core HTTP revisions) WG, Monday afternoon HTTPSTATE (web cookies) WG, Monday afternoon FEDAUTH (federated authentication) BOF, Tuesday morning HASMAT (web security) BOF, Tuesday afternoon before OAUTH If desired we could also hold a developer hackfest on Sunday or at some other time (outside of normal meeting hours so as not to overlap with scheduled sessions). The schedule is very full and many working groups were denied extra sessions, so I hope we'll make good use of the two sessions we've been granted. Peter -- Peter Saint-Andre https://stpeter.im/ From eran@hueniverse.com Thu Jul 8 09:42:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D063A69B9 for ; Thu, 8 Jul 2010 09:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.348, 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 EybjpA-rMjiZ for ; Thu, 8 Jul 2010 09:42:38 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2E6B13A6B47 for ; Thu, 8 Jul 2010 09:42:37 -0700 (PDT) Received: (qmail 12292 invoked from network); 8 Jul 2010 16:42:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Jul 2010 16:42:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 8 Jul 2010 09:42:31 -0700 From: Eran Hammer-Lahav To: David Recordon , OAuth WG Date: Thu, 8 Jul 2010 09:42:26 -0700 Thread-Topic: [OAUTH-WG] POLL: Are you going to Maastricht? Thread-Index: AcseusL7h3uA4DyOQmmAPBRbskFfzQAAcjp5 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85B4E0236DF5eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 16:42:44 -0000 --_000_C85B4E0236DF5eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable D. No. But I am looking forward to a long list of feedback for -10 and will do my = best to attend virtually. EHL On 7/8/10 9:29 AM, "David Recordon" wrote: I'm honestly trying to decide myself and a few other people are in similar = situations. Thus a poll: A) Yes, I'm going to be in Maastricht B) Maybe, depends on the number of OAuth WG members going C) Maybe, depends on some other reason D) No If you're missing context, in a few weeks it is the IETF meeting in Maastri= cht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting scheduled= all afternoon Tuesday the 27th. Thanks, --David --_000_C85B4E0236DF5eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] POLL: Are you going to Maastricht? D. No.

But I am looking forward to a long list of feedback for -10 and will do my = best to attend virtually.

EHL


On 7/8/10 9:29 AM, "David Recordon" <recordond@gmail.com> wrote:

I'm honestly trying to decide myself and a = few other people are in similar situations. Thus a poll:
A) Yes, I'm going to be in=A0Maastricht
B) Maybe, depends on the number of OAuth WG members going
C) Maybe, depends on some other reason
D) No

If you're missing context, in a few weeks it is the IETF meeting in=A0Maast= richt (http://www.ietf.org/meet= ing/78/). The OAuth WG has a meeting scheduled all afternoon Tuesday th= e 27th.

Thanks,
--David

--_000_C85B4E0236DF5eranhueniversecom_-- From jricher@mitre.org Thu Jul 8 09:43: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 BC6CF3A6B37 for ; Thu, 8 Jul 2010 09:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 nFElV4sMiozj for ; Thu, 8 Jul 2010 09:43:43 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id D4FDC3A6B2D for ; Thu, 8 Jul 2010 09:43:42 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o68GhknH004502 for ; Thu, 8 Jul 2010 12:43:46 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o68GhkcK004496; Thu, 8 Jul 2010 12:43:46 -0400 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, 8 Jul 2010 12:43:45 -0400 From: Justin Richer To: David Recordon In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Thu, 8 Jul 2010 12:43:45 -0400 Message-ID: <1278607425.2445.81.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 16:43:49 -0000 D On Thu, 2010-07-08 at 12:29 -0400, David Recordon wrote: > I'm honestly trying to decide myself and a few other people are in > similar situations. Thus a poll: > A) Yes, I'm going to be in Maastricht > B) Maybe, depends on the number of OAuth WG members going > C) Maybe, depends on some other reason > D) No > > > If you're missing context, in a few weeks it is the IETF meeting > in Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a > meeting scheduled all afternoon Tuesday the 27th. > > > Thanks, > --David From torsten@lodderstedt.net Thu Jul 8 09:46:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5FD3A69B9 for ; Thu, 8 Jul 2010 09:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sLfhAamewze for ; Thu, 8 Jul 2010 09:46:44 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by core3.amsl.com (Postfix) with ESMTP id A738D3A6B2D for ; Thu, 8 Jul 2010 09:46:43 -0700 (PDT) Received: from [80.187.105.25] (helo=[10.156.235.169]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OWuFI-0000At-QR; Thu, 08 Jul 2010 18:46:46 +0200 References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1--347333610 Message-Id: X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Thu, 8 Jul 2010 18:46:10 +0200 To: David Recordon X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 16:46:44 -0000 --Apple-Mail-1--347333610 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A Am 08.07.2010 um 18:29 schrieb David Recordon : > I'm honestly trying to decide myself and a few other people are in similar= situations. Thus a poll: > A) Yes, I'm going to be in Maastricht > B) Maybe, depends on the number of OAuth WG members going > C) Maybe, depends on some other reason > D) No >=20 > If you're missing context, in a few weeks it is the IETF meeting in Maastr= icht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting scheduled= all afternoon Tuesday the 27th. >=20 > Thanks, > --David > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-1--347333610 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
A



Am 08.07.2010 um 18:29 schrieb David Recordon <recordond@gmail.com>:

I'm honestly trying to decide myself and a few other people are in similar situations. Thus a poll:
A) Yes, I'm going to be in Maastricht
B) Maybe, depends on the number of OAuth WG members going
C) Maybe, depends on some other reason
D) No

If you're missing context, in a few weeks it is the IETF meeting in Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting scheduled all afternoon Tuesday the 27th.

Thanks,
--David
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--Apple-Mail-1--347333610-- From romeda@gmail.com Thu Jul 8 09:47: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 9C22D3A6B37 for ; Thu, 8 Jul 2010 09:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLjvX4Ep+n2g for ; Thu, 8 Jul 2010 09:47:42 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id BE4313A6B1A for ; Thu, 8 Jul 2010 09:47:19 -0700 (PDT) Received: by pwj1 with SMTP id 1so521577pwj.31 for ; Thu, 08 Jul 2010 09:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=V2FyVUJnYInW0VYylMDe61SsLG1eXdySgw6lnSmTG9M=; b=Vx51OwgqD1gwT/fz6G35fmH6QPGQ2xkhezv5NvFXpEVjNyLFAnaR/haEjRk0q3LKQV FPmMG++IqGahX8Rr9/jKU9OHL9HWK+rdoG1HEEdE5G5q+rraYNhqBsc5Zd11O+QCuPIG Hd0bpX9RYG/Hd+wMd1g4cjrzn6nyACKgSPoXA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=rTh8AK8c6ce2E7QmlmIN1RI6adMXyOwXTMCM65FW2hdzN3FG1CaIvEo7xqy4UBc10K 8/+RePIx8GVx2SZE3y7QmON6JwBDIDnE7dzGFeDO2wGXEj0352w+Kz5wv77bsOPa4h/t WXwmLm7EH7Pi970qO1GwWHAEa6L5rW/08n1w0= Received: by 10.142.144.16 with SMTP id r16mr5376111wfd.266.1278607638211; Thu, 08 Jul 2010 09:47:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.41.11 with HTTP; Thu, 8 Jul 2010 09:46:57 -0700 (PDT) In-Reply-To: <1278607425.2445.81.camel@localhost.localdomain> References: <1278607425.2445.81.camel@localhost.localdomain> From: Blaine Cook Date: Thu, 8 Jul 2010 17:46:57 +0100 Message-ID: To: OAuth WG Content-Type: text/plain; charset=UTF-8 Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 16:47:43 -0000 A, BUT I will be unable to attend Monday-Wednesday. I'll be around Thursday / Friday to work on issues and so forth if others will be there, too. b. On 8 July 2010 17:43, Justin Richer wrote: > D > > On Thu, 2010-07-08 at 12:29 -0400, David Recordon wrote: >> I'm honestly trying to decide myself and a few other people are in >> similar situations. Thus a poll: >> A) Yes, I'm going to be in Maastricht >> B) Maybe, depends on the number of OAuth WG members going >> C) Maybe, depends on some other reason >> D) No >> >> >> If you're missing context, in a few weeks it is the IETF meeting >> in Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a >> meeting scheduled all afternoon Tuesday the 27th. >> >> >> Thanks, >> --David > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From sakimura@gmail.com Thu Jul 8 10:09:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17A333A6B16 for ; Thu, 8 Jul 2010 10:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 lTGHZ2e4ybS9 for ; Thu, 8 Jul 2010 10:09:43 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CF65A3A6B13 for ; Thu, 8 Jul 2010 10:09:43 -0700 (PDT) Received: by iwn38 with SMTP id 38so1127977iwn.31 for ; Thu, 08 Jul 2010 10:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/gLjx+F1OCcH2pAP1jakVRDId9uyDBUsYdVSsmdLoKE=; b=Tk3KSBuawX7/4zYwah2HbDcaN2iwlxzuhDxxu/dlnZt3dXMACii4LIhi8uMOJTDVJ2 pHx9bdwgesMt82u2HopNTUuHfEoJ++rhktCVUospjfYeL8vBelYwn8uLB7WBSYqrzxxn H2lVS1iLD9JfkiowhZU47R2p/EGp2ARhAQ9Wc= 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=Ma8/g4xZcmswy02bKlqVjozBz8h7iuF0a85SdDpV7zW9+SDL/BCg8hde8ztWhJ0sWL Zox6zqgULTBX9V5MVAbxfZzIVIK5x0qViAxiMlnxJXmGLLoScvxzBQFkYqIOgIjQWWkC cYxHM1dKDeWv6RNKmppxcsGYZvY1CPARpeYVA= MIME-Version: 1.0 Received: by 10.231.150.16 with SMTP id w16mr8729004ibv.42.1278608987735; Thu, 08 Jul 2010 10:09:47 -0700 (PDT) Received: by 10.231.39.75 with HTTP; Thu, 8 Jul 2010 10:09:47 -0700 (PDT) In-Reply-To: References: <1278607425.2445.81.camel@localhost.localdomain> Date: Fri, 9 Jul 2010 02:09:47 +0900 Message-ID: From: Nat Sakimura To: Blaine Cook Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 17:09:45 -0000 B. On Fri, Jul 9, 2010 at 1:46 AM, Blaine Cook wrote: > A, BUT I will be unable to attend Monday-Wednesday. I'll be around > Thursday / Friday to work on issues and so forth if others will be > there, too. > > b. > > On 8 July 2010 17:43, Justin Richer wrote: >> D >> >> On Thu, 2010-07-08 at 12:29 -0400, David Recordon wrote: >>> I'm honestly trying to decide myself and a few other people are in >>> similar situations. Thus a poll: >>> A) Yes, I'm going to be in Maastricht >>> B) Maybe, depends on the number of OAuth WG members going >>> C) Maybe, depends on some other reason >>> D) No >>> >>> >>> If you're missing context, in a few weeks it is the IETF meeting >>> in Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a >>> meeting scheduled all afternoon Tuesday the 27th. >>> >>> >>> Thanks, >>> --David >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From Bill_Keenan@intuit.com Thu Jul 8 10:31:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B253A6859 for ; Thu, 8 Jul 2010 10:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U7KBhZv+Mhf for ; Thu, 8 Jul 2010 10:31:20 -0700 (PDT) Received: from mail4.intuit.com (mail4.intuit.com [12.149.175.56]) by core3.amsl.com (Postfix) with ESMTP id 9FA413A6B38 for ; Thu, 8 Jul 2010 10:31:20 -0700 (PDT) DomainKey-Signature: s=default; d=intuit.com; c=nofws; q=dns; h=X-SBRS:X-IronPort-AV:Received:Received:Received:From:To: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version: Return-Path:X-OriginalArrivalTime; b=Yh7yhSGDEWRTZsthf4F/hcQ/5YdvNxvDgKIfSbqplQyrxH4Fs8Iq8V1C vtw+1z6eFbgpyE3fQEbuzJ9O0ZKhjZuv5KplKCHMYQNuu/077UPG2Nt3u dQanm3nNs0OmCI2; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intuit.com; i=Bill_Keenan@intuit.com; q=dns/txt; s=default; t=1278610285; x=1310146285; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Keenan,=20Bill"=20|To: =20OAuth=20WG=20|Date:=20Thu,=208=20Jul =202010=2010:31:21=20-0700|Subject:=20Re:=20[OAUTH-WG]=20 POLL:=20Are=20you=20going=20to=20Maastricht?|Message-ID: =20<8B239F74-E1CE-4671-B901-92126E0A0808@intuit.com> |References:=20|In-Reply-To:=20 |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=VoThAsumh4GjGWCIhJWgiKxUicNYl5rewLahyj8mn5k=; b=WGLzxru4XrlpLc3UvBQ3H2WC6wodCPSqEaaaB78Tua2EVZUOi9/jCtoT GpxjtCJF0d9q2W8YJTXXxLDsJzCErqGU+tbbvpU1Cb1fhPEZFtpMnDctn 5Jcuq9SketSI2SY; X-SBRS: None X-IronPort-AV: E=Sophos;i="4.53,559,1272870000"; d="scan'208";a="200287635" Received: from sdgexbh03.corp.intuit.net ([172.17.135.77]) by mail4.sdg.ie.intuit.com with ESMTP; 08 Jul 2010 10:31:24 -0700 Received: from SDGEX01.corp.intuit.net ([172.17.135.223]) by SDGEXBH03.corp.intuit.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 10:31:24 -0700 Received: from SDGEX01.corp.intuit.net ([172.17.135.223]) by sdgex01.corp.intuit.net ([172.17.135.223]) with mapi; Thu, 8 Jul 2010 10:31:24 -0700 From: "Keenan, Bill" To: OAuth WG Date: Thu, 8 Jul 2010 10:31:21 -0700 Thread-Topic: [OAUTH-WG] POLL: Are you going to Maastricht? Thread-Index: Acsew2KydQ0PmUiTSD+8QnhmrS7ZXg== Message-ID: <8B239F74-E1CE-4671-B901-92126E0A0808@intuit.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jul 2010 17:31:24.0209 (UTC) FILETIME=[63356210:01CB1EC3] Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 17:31:33 -0000 D On Jul 8, 2010, at 9:29 AM, David Recordon wrote: I'm honestly trying to decide myself and a few other people are in similar = situations. Thus a poll: A) Yes, I'm going to be in Maastricht B) Maybe, depends on the number of OAuth WG members going C) Maybe, depends on some other reason D) No If you're missing context, in a few weeks it is the IETF meeting in Maastri= cht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting scheduled= all afternoon Tuesday the 27th. Thanks, --David From yarong@microsoft.com Thu Jul 8 10:37: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 7B71E3A63EC for ; Thu, 8 Jul 2010 10:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 VLeztTQAve3w for ; Thu, 8 Jul 2010 10:37:44 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 886C93A6847 for ; Thu, 8 Jul 2010 10:37:44 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 8 Jul 2010 10:37:48 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.44]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0160.007; Thu, 8 Jul 2010 10:37:48 -0700 From: Yaron Goland To: "oauth@ietf.org" Thread-Topic: The meaning of scope Thread-Index: Acsewx59T/SncBiDTAeyhSQV2uiTWw== Date: Thu, 8 Jul 2010 17:37:44 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C5F98786D@TK5EX14MBXC113.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C5F98786DTK5EX14MBXC113r_" MIME-Version: 1.0 Subject: [OAUTH-WG] The meaning of scope X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 17:37:48 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C5F98786DTK5EX14MBXC113r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Today the definition of scope is vague. But I have seen mails on this list = (such as Lukas Rosenstock's post http://www.ietf.org/mail-archive/web/oauth= /current/msg03560.html which is just one example) that assert that scope re= presents the permissions that a client is requesting. When we use scope (going back to its introduction in WRAP) we used it prima= ry for two legged OAuth as a way for a client to tell a token endpoint what= audience (in the SAML sense) it wanted a token for. This had nothing to do= with the specific permission being requested. We used other claims for tha= t. I am not asking the group to agree with our usage. But I do want to check i= f the language in the spec (which really doesn't define scope very tightly)= is actually consistent with what is in people's heads. Does the group see = scope as a generally undefined entity that has to be defined in context (on= e such context could be that scope represents requested permissions) or do = they see it just as a place to stick requested permissions? What say you? Thanks, Yaron --_000_7C01E631FF4B654FA1E783F1C0265F8C5F98786DTK5EX14MBXC113r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Today the definition of scope is vague. But I have s= een mails on this list (such as Lukas Rosenstock’s post http://www.ietf.org/mail-archive/web/oauth/current/msg03560.html whic= h is just one example) that assert that scope represents the permissions th= at a client is requesting.

 

When we use scope (going back to its introduction in= WRAP) we used it primary for two legged OAuth as a way for a client to tel= l a token endpoint what audience (in the SAML sense) it wanted a token for.= This had nothing to do with the specific permission being requested. We used other claims for that.

 

I am not asking the group to agree with our usage. B= ut I do want to check if the language in the spec (which really doesn’= ;t define scope very tightly) is actually consistent with what is in people= ’s heads. Does the group see scope as a generally undefined entity that has to be defined in context (one such con= text could be that scope represents requested permissions) or do they see i= t just as a place to stick requested permissions?

 

        &nbs= p;       What say you?

 

        &nbs= p;            &= nbsp;          Thanks,

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; Yaron

--_000_7C01E631FF4B654FA1E783F1C0265F8C5F98786DTK5EX14MBXC113r_-- From eran@hueniverse.com Thu Jul 8 11:06: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 99D673A686A for ; Thu, 8 Jul 2010 11:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.329, 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 Xf8DOHMvwbXY for ; Thu, 8 Jul 2010 11:05:54 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A31FB3A63C9 for ; Thu, 8 Jul 2010 11:05:54 -0700 (PDT) Received: (qmail 10808 invoked from network); 8 Jul 2010 18:05:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Jul 2010 18:05:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 8 Jul 2010 11:05:45 -0700 From: Eran Hammer-Lahav To: Yaron Goland , OAuth WG Date: Thu, 8 Jul 2010 11:05:42 -0700 Thread-Topic: [OAUTH-WG] The meaning of scope Thread-Index: Acsewx59T/SncBiDTAeyhSQV2uiTWwABQ9Bd Message-ID: In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C5F98786D@TK5EX14MBXC113.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85B618636E09eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] The meaning of scope X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:06:03 -0000 --_000_C85B618636E09eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To me, scope means "the stuff being accessed", but can also mean permission= s, duration, etc. I raised this issue a while back but since we could not a= gree on what exactly is included in scope, it was left vague. The key is th= e space-delimited values and how they relate to each other ("a b" covers "a= " and "b" and is the same as "b a"). That is all the interop help the spec = currently provides. This definition doesn't work well with generic permissions or duration. For= example: "friends photos read 2days" doesn't really work because "read" and "2days" = don't hold on their own. On the other hand: "friends:read:2d photos:write:1y" does work. If someone needs a global permission or duration, they can define an extens= ion parameter but I have not seen any APIs where this was needed, and where= the above example will not work. I think there is value in more standardiz= ation here but I don't have the use cases to suggest what it should look li= ke. EHL On 7/8/10 10:37 AM, "Yaron Goland" wrote: Today the definition of scope is vague. But I have seen mails on this list = (such as Lukas Rosenstock's post http://www.ietf.org/mail-archive/web/oauth= /current/msg03560.html which is just one example) that assert that scope re= presents the permissions that a client is requesting. When we use scope (going back to its introduction in WRAP) we used it prima= ry for two legged OAuth as a way for a client to tell a token endpoint what= audience (in the SAML sense) it wanted a token for. This had nothing to do= with the specific permission being requested. We used other claims for tha= t. I am not asking the group to agree with our usage. But I do want to check i= f the language in the spec (which really doesn't define scope very tightly)= is actually consistent with what is in people's heads. Does the group see = scope as a generally undefined entity that has to be defined in context (on= e such context could be that scope represents requested permissions) or do = they see it just as a place to stick requested permissions? What say you? Thanks, Yaron --_000_C85B618636E09eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] The meaning of scope To me, scope means “the stuff being accessed”, but can al= so mean permissions, duration, etc. I raised this issue a while back but si= nce we could not agree on what exactly is included in scope, it was left va= gue. The key is the space-delimited values and how they relate to each othe= r (“a b” covers “a” and “b” and is the = same as “b a”). That is all the interop help the spec currently= provides.

This definition doesn’t work well with generic permissions or duratio= n. For example:

“friends photos read 2days” doesn’t really work because &= #8220;read” and “2days” don’t hold on their own. On= the other hand:

“friends:read:2d photos:write:1y” does work.

If someone needs a global permission or duration, they can define an extens= ion parameter but I have not seen any APIs where this was needed, and where= the above example will not work. I think there is value in more standardiz= ation here but I don’t have the use cases to suggest what it should l= ook like.

EHL


On 7/8/10 10:37 AM, "Yaron Goland" <yarong@microsoft.com> wrote:

Today the definition of scope is vague. But= I have seen mails on this list (such as Lukas Rosenstock’s post ht= tp://www.ietf.org/mail-archive/web/oauth/current/msg03560.html which is= just one example) that assert that scope represents the permissions that a= client is requesting.
 
When we use scope (going back to its introduction in WRAP) we used it prima= ry for two legged OAuth as a way for a client to tell a token endpoint what= audience (in the SAML sense) it wanted a token for. This had nothing to do= with the specific permission being requested. We used other claims for tha= t.
 
I am not asking the group to agree with our usage. But I do want to check i= f the language in the spec (which really doesn’t define scope very ti= ghtly) is actually consistent with what is in people’s heads. Does th= e group see scope as a generally undefined entity that has to be defined in= context (one such context could be that scope represents requested permiss= ions) or do they see it just as a place to stick requested permissions?  
            &nb= sp;   What say you?
 
            &nb= sp;            =        Thanks,
 
            &nb= sp;            =             &nb= sp;          Yaron

--_000_C85B618636E09eranhueniversecom_-- From wmills@yahoo-inc.com Thu Jul 8 11:19: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 8E1C43A6823 for ; Thu, 8 Jul 2010 11:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.515 X-Spam-Level: X-Spam-Status: No, score=-17.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO1ui+VrY8ts for ; Thu, 8 Jul 2010 11:19:28 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 22CAE3A6804 for ; Thu, 8 Jul 2010 11:19:28 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o68IIRnE055901; Thu, 8 Jul 2010 11:18:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:return-path:x-originalarrivaltime; b=2u/aJcPTOaFGm8IUrOHwXf0zR9QCLvC80fzzxwYrNTF6A4Nfjuwg90jFMgPe0EXQ Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 11:18:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1EC9.F31CA680" Date: Thu, 8 Jul 2010 11:18:22 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6B44@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] The meaning of scope Thread-Index: Acsewx59T/SncBiDTAeyhSQV2uiTWwABQ9BdAABSoQA= References: <7C01E631FF4B654FA1E783F1C0265F8C5F98786D@TK5EX14MBXC113.redmond.corp.microsoft.com> From: "William Mills" To: "Eran Hammer-Lahav" , "Yaron Goland" , "OAuth WG" X-OriginalArrivalTime: 08 Jul 2010 18:18:27.0465 (UTC) FILETIME=[F6000F90:01CB1EC9] Subject: Re: [OAUTH-WG] The meaning of scope X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:19:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1EC9.F31CA680 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Leaving it loosely defined is good in my opinion. =20 =20 The way I see scope is as a way to limit the power of a token. Examples of this might be "mail" to limit to only accessing e-mail, or "read-only" for something like a calendar sync application pulling events out of an online calendar. My mental model of scope does not include expiration, since I believe tokens themselves should have embedded timestamps if you want to support expiration. =20 ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Thursday, July 08, 2010 11:06 AM To: Yaron Goland; OAuth WG Subject: Re: [OAUTH-WG] The meaning of scope =09 =09 To me, scope means "the stuff being accessed", but can also mean permissions, duration, etc. I raised this issue a while back but since we could not agree on what exactly is included in scope, it was left vague. The key is the space-delimited values and how they relate to each other ("a b" covers "a" and "b" and is the same as "b a"). That is all the interop help the spec currently provides. =09 This definition doesn't work well with generic permissions or duration. For example: =09 "friends photos read 2days" doesn't really work because "read" and "2days" don't hold on their own. On the other hand: =09 "friends:read:2d photos:write:1y" does work. =09 If someone needs a global permission or duration, they can define an extension parameter but I have not seen any APIs where this was needed, and where the above example will not work. I think there is value in more standardization here but I don't have the use cases to suggest what it should look like. =09 EHL =09 =09 On 7/8/10 10:37 AM, "Yaron Goland" wrote: =09 =09 Today the definition of scope is vague. But I have seen mails on this list (such as Lukas Rosenstock's post http://www.ietf.org/mail-archive/web/oauth/current/msg03560.html which is just one example) that assert that scope represents the permissions that a client is requesting. =20 When we use scope (going back to its introduction in WRAP) we used it primary for two legged OAuth as a way for a client to tell a token endpoint what audience (in the SAML sense) it wanted a token for. This had nothing to do with the specific permission being requested. We used other claims for that. =20 I am not asking the group to agree with our usage. But I do want to check if the language in the spec (which really doesn't define scope very tightly) is actually consistent with what is in people's heads. Does the group see scope as a generally undefined entity that has to be defined in context (one such context could be that scope represents requested permissions) or do they see it just as a place to stick requested permissions?=20 =20 What say you? =20 Thanks, =20 Yaron =09 =09 ------_=_NextPart_001_01CB1EC9.F31CA680 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] The meaning of scope
Leaving it loosely defined is good in my = opinion. =20
 
The way I see scope is as a way to limit the power = of a=20 token.  Examples of this might be "mail" to limit to only accessing = e-mail,=20 or "read-only" for something like a calendar sync application pulling = events out=20 of an online calendar.  My mental model of scope does not = include=20 expiration, since I believe tokens themselves should have embedded = timestamps if=20 you want to support expiration. 

From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] On Behalf Of Eran=20 Hammer-Lahav
Sent: Thursday, July 08, 2010 11:06 = AM
To:=20 Yaron Goland; OAuth WG
Subject: Re: [OAUTH-WG] The meaning = of=20 scope

To me, scope means “the stuff being = accessed”, but can=20 also mean permissions, duration, etc. I raised this issue a while back = but=20 since we could not agree on what exactly is included in scope, it was = left=20 vague. The key is the space-delimited values and how they relate to = each other=20 (“a b” covers “a” and “b” and is = the same as “b a”). That is all the interop=20 help the spec currently provides.

This definition doesn’t = work well=20 with generic permissions or duration. For = example:

“friends photos read=20 2days” doesn’t really work because “read” and = “2days” don’t hold on their own.=20 On the other hand:

“friends:read:2d = photos:write:1y” does=20 work.

If someone needs a global permission or duration, they = can define=20 an extension parameter but I have not seen any APIs where this was = needed, and=20 where the above example will not work. I think there is value in more=20 standardization here but I don’t have the use cases to suggest = what it should=20 look like.

EHL


On 7/8/10 10:37 AM, "Yaron Goland" = <yarong@microsoft.com>=20 wrote:
Today the definition of scope is vague. = But I have=20 seen mails on this list (such as Lukas Rosenstock’s post http://www.ietf.org/mail-archive/web/oauth/current/msg03560.html=20 which is just one example) that assert that scope represents the = permissions=20 that a client is requesting.
 
When we use scope (going = back to=20 its introduction in WRAP) we used it primary for two legged OAuth as = a way=20 for a client to tell a token endpoint what audience (in the SAML = sense) it=20 wanted a token for. This had nothing to do with the specific = permission=20 being requested. We used other claims for that.
 
I am = not asking=20 the group to agree with our usage. But I do want to check if the = language in=20 the spec (which really doesn’t define scope very tightly) is = actually=20 consistent with what is in people’s heads. Does the group see = scope as a=20 generally undefined entity that has to be defined in context (one = such=20 context could be that scope represents requested permissions) or do = they see=20 it just as a place to stick requested permissions?=20 =
 
          = ;      What=20 say=20 = you?
 
         &= nbsp;           &n= bsp;          Thanks, 
          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; Yaron

------_=_NextPart_001_01CB1EC9.F31CA680-- From mscurtescu@google.com Thu Jul 8 11:26: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 880A13A6804 for ; Thu, 8 Jul 2010 11:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.047 X-Spam-Level: X-Spam-Status: No, score=-101.047 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhVtM1Q3k3rz for ; Thu, 8 Jul 2010 11:26:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 57BE03A6887 for ; Thu, 8 Jul 2010 11:26:46 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o68IQowf023469 for ; Thu, 8 Jul 2010 11:26:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278613610; bh=z8DseATfWlweky+koiW+qLrZ+JY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=A/2dIyvpbp6FR3O87ErhcTnX07yQo7xJRuDLAk4mAPAFkX3SKFP9ILL+oIddpZ+MQ gA8GdZoOGAu0az+etVu+A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=ps8pjrb3OYBGOYYLfoY5Qy1pE/4elOyuyINbI5G+HL6Ma7ielW3LSzwWKCOwqNVbE 4NoWgJrDGTGQGZg3PxFFg== Received: from gyd10 (gyd10.prod.google.com [10.243.49.202]) by hpaq5.eem.corp.google.com with ESMTP id o68IQJDU027446 for ; Thu, 8 Jul 2010 11:26:49 -0700 Received: by gyd10 with SMTP id 10so605112gyd.10 for ; Thu, 08 Jul 2010 11:26:48 -0700 (PDT) Received: by 10.101.129.16 with SMTP id g16mr10309630ann.76.1278613608235; Thu, 08 Jul 2010 11:26:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Thu, 8 Jul 2010 11:26:27 -0700 (PDT) In-Reply-To: <20100708110542.150740@gmx.net> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2DC7C5.2090009@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F108B.70504@cdatazone.org> <20100708110542.150740@gmx.net> From: Marius Scurtescu Date: Thu, 8 Jul 2010 11:26:27 -0700 Message-ID: To: Stefanie Dronia 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] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:26:47 -0000 The bridge flow was meant to be used in a mixed OAuth 1 and OAuth 2 environment, it allows the consumer to obtain a token using signatures and then access protected resources with no signatures. Now that signatures are re-introduced in OAuth 2 I don't think there is a need for such an approach. That being said, migration can be done very similarly, differences from the bridge flow: - an OAuth 2 refresh token is also returned - optionally the OAuth 1 token is revoked Such a migration flow would allow a consumer/client that has OAuth 1 access tokens saved for its users to convert all of them to OAuth 2 refresh tokens without involving the users. Marius On Thu, Jul 8, 2010 at 4:05 AM, Stefanie Dronia wrote: > Hi, > > > > I took a look at the OAuth 1 Bridge Flow suggested by Marius, the thread > "OAuth 1 Bridge Flow" and had some thoughts: > > > > I do not really see the necessity for such a flow. > > First of all, all participating parties have to be modified and rolled ou= t: > > - the consumer's application to support (at least) the bridge flow (and > OAuth 2 [1]), > > - the authz server to provide OAuth 2=A0 and additionally the bridge flow= and > > - the resource server to handle OAuth2. > > Then, sometime later, when at least the authz server doesn't support OAut= h 1 > anymore, the client application and the resource server should be cleared= up > - no more OAuth 1, only OAuth 2. Again a new version to roll out. > > > > The only (small) benefit I see, is that the user will not be asked for > authorization again. > > But is it worth it to develop, implement and roll out a Bridge Flow? I do > not think so - too much expense for a small user interaction. > > Better: directly go to OAuth 2, when it is needed. > > > > The other thing I'm missing, is how to migrate completely to OAuth 2 afte= r > performing the bridge flow. Issuing a refresh token in the response seems > necessary. But this issue was still mentioned (but not solved) in the thr= ead > "OAuth 1 Bridge Flow" by Eran. > > > > > > Thanks, > > Steffi > > > > [1] if OAuth 2 will not be supported, a new modified client has to be rol= led > out at the latest, the resource server doesn't support OAuth 1 anymore. > > > > -------- Original-Nachricht -------- > Datum: Tue, 6 Jul 2010 21:54:16 -0700 > Von: Marius Scurtescu > An: Rob Richards > CC: "oauth@ietf.org" > Betreff: Re: [OAUTH-WG] Versioning > > On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards > wrote: >> Eran Hammer-Lahav wrote: >>> >>> Hi Rob, >>> >>> I agree with you that a migration spec is important - please write one. >>> >> >> Like I didn't see that coming :) > > I would like to help with this migration spec. Is this a good starting > point: > http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html > > Or, you had something else in mind? > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -- > GRATIS f=FCr alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 From mscurtescu@google.com Thu Jul 8 11:31:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05733A6B14 for ; Thu, 8 Jul 2010 11:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsxNWkGFPSdB for ; Thu, 8 Jul 2010 11:31:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A1EB63A6B4E for ; Thu, 8 Jul 2010 11:31:11 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o68IV8Z6018457 for ; Thu, 8 Jul 2010 11:31:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278613869; bh=StOz3EBYIbnd29AACM/nWhaEEtI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type; b=JwrYHCdNd82Ki9JSQKdFvQiNgASgpAYhS/+8JmuYK2CEvLt8CXSOCAAxdjk2dW/+w G/Go5+Xqn/sKw4n2kle1Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:content-type:x-system-of-record; b=VItvisEJ0gWS/BY5O7L4pI39UeQ/lUhup6GElWBnmGWnzOcsacgB4XAoxHDiHrwtL 5ne78mcTkKUtugesgnxJg== Received: from gyd8 (gyd8.prod.google.com [10.243.49.200]) by hpaq13.eem.corp.google.com with ESMTP id o68IV7N2029614 for ; Thu, 8 Jul 2010 11:31:07 -0700 Received: by gyd8 with SMTP id 8so897741gyd.41 for ; Thu, 08 Jul 2010 11:31:07 -0700 (PDT) Received: by 10.100.153.5 with SMTP id a5mr10331948ane.12.1278613867191; Thu, 08 Jul 2010 11:31:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Thu, 8 Jul 2010 11:30:47 -0700 (PDT) In-Reply-To: <8B239F74-E1CE-4671-B901-92126E0A0808@intuit.com> References: <8B239F74-E1CE-4671-B901-92126E0A0808@intuit.com> From: Marius Scurtescu Date: Thu, 8 Jul 2010 11:30:47 -0700 Message-ID: To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 18:31:21 -0000 B/C From dick.hardt@gmail.com Thu Jul 8 12:19:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314433A6834 for ; Thu, 8 Jul 2010 12:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU9upWQYKG13 for ; Thu, 8 Jul 2010 12:19:32 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 77A9D3A67D7 for ; Thu, 8 Jul 2010 12:19:32 -0700 (PDT) Received: by pzk6 with SMTP id 6so321791pzk.31 for ; Thu, 08 Jul 2010 12:19:34 -0700 (PDT) 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=OFEMKZty823jC+V7L1IXEiWkiUeTxVKrh3LEV3NVl9Q=; b=eso0a6VxYPOw75Boh9ZtquDxO4I/+2uxNJDiSxG4UsKohqSCQZgTZzLzSnbjIkgyxA fm2/7+tq/3olWnp/usSVcYYc4oaeZTSsbI150e5Tcosw6+L471JdRqtK6GmX6XZnSWIg VqRDMDLhSKtC7mTHwBSHQVgqNwS8KfxDl5aNw= 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=N6Is2Bgkm/VmbJe7HcPu1U6W37grhcDrHrYjqCOLnUUMdU9e3jU9Pgg7lex0GT5+SQ ZBVY8emJoP+U9LF9FtVnVjcb/2mJPWn3NMMYT2fmshuo/3zNgI1lWpl1TbSiotIE8i2U uzmLFGDqAvuX5xhit0U0W1dmeT68iHinN8Ytw= Received: by 10.142.211.5 with SMTP id j5mr10442044wfg.158.1278616773903; Thu, 08 Jul 2010 12:19:33 -0700 (PDT) Received: from [192.168.1.2] ([24.130.32.55]) by mx.google.com with ESMTPS id f2sm8900713wfp.23.2010.07.08.12.19.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 08 Jul 2010 12:19:33 -0700 (PDT) From: Dick Hardt Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-182--338138432 Date: Thu, 8 Jul 2010 12:19:32 -0700 In-Reply-To: To: OAuth WG References: Message-Id: <441D9464-AA68-492C-B27A-AC515185D6E1@gmail.com> X-Mailer: Apple Mail (2.1078) Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:19:33 -0000 --Apple-Mail-182--338138432 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii D On 2010-07-08, at 9:29 AM, David Recordon wrote: > I'm honestly trying to decide myself and a few other people are in = similar situations. Thus a poll: > A) Yes, I'm going to be in Maastricht > B) Maybe, depends on the number of OAuth WG members going > C) Maybe, depends on some other reason > D) No >=20 > If you're missing context, in a few weeks it is the IETF meeting in = Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting = scheduled all afternoon Tuesday the 27th. >=20 > Thanks, > --David > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-182--338138432 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii D

On 2010-07-08, at 9:29 AM, David Recordon wrote:

I'm honestly trying to decide myself and a few other people are in similar situations. Thus a poll:
A) Yes, I'm going to be in Maastricht
B) Maybe, depends on the number of OAuth WG members going
C) Maybe, depends on some other reason
D) No

If you're missing context, in a few weeks it is the IETF meeting in Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting scheduled all afternoon Tuesday the 27th.

Thanks,
--David
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-182--338138432-- From beaton@google.com Thu Jul 8 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 112323A6885 for ; Thu, 8 Jul 2010 12:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.35 X-Spam-Level: X-Spam-Status: No, score=-105.35 tagged_above=-999 required=5 tests=[AWL=0.627, 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 yllOk1XLhBje for ; Thu, 8 Jul 2010 12:29:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 481AD3A684B for ; Thu, 8 Jul 2010 12:29:09 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o68JTCFl029714 for ; Thu, 8 Jul 2010 12:29:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278617353; bh=IEcxjLsSTLoEdvBRzuI0Za9icug=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=lCJ9ZAXyygQqsig2XhiNcK2jO0JfPlde1cDMKjPxFMg6NksKhL9w9RLEaiYlnio0f etx25LDvy4J7/h//dDuMg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=jNLQLABWFH6m1OMFZxp9vsPpmExsnEmBUN8IBaP6LdV5JwwQ0G0b3yiBGvyNC18ti A/9SgdV3PsLHRcb2Nejwg== Received: from pvc22 (pvc22.prod.google.com [10.241.209.150]) by hpaq5.eem.corp.google.com with ESMTP id o68JT85r027396 for ; Thu, 8 Jul 2010 12:29:09 -0700 Received: by pvc22 with SMTP id 22so513740pvc.1 for ; Thu, 08 Jul 2010 12:29:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.132.12 with SMTP id f12mr10296082wfd.224.1278617348432; Thu, 08 Jul 2010 12:29:08 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Thu, 8 Jul 2010 12:29:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Jul 2010 12:29:08 -0700 Message-ID: From: Brian Eaton To: Chuck Mortimore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:29:14 -0000 OK, I *think* I understand your use-case... Just to be clear, even after your internal discussions, you don't see a need for a client secret in this flow? Our SAML endpoints encode the tenant in the URL like so: https://www.google.com/accounts//acs But I'd have no problem with supporting per tenant urls like this: https://www.google.com/accounts/acs?tenant=3D In fact, our approval endpoints already support that kind of parameterization. For example, see the hd=3D parameter in this documentation: http://code.google.com/apis/accounts/docs/OAuth_ref.html. This is used by partners who need an OAuth token, and already have a good idea of which domain a given user belongs to. It lets us optimize the login experience. I'm a little confused by using client_id to identify something that isn't an API client. It seems like in your proposed flow you're assuming that the client_id is closely connected to the user being authenticated. That's not actually true for most of our use cases. What are your thoughts on adding an optional "tenant" parameter to both the authorization URL and the SAML ACS URL? The format of tenant would be provider specific, but I see value in using consistent parameter names. Cheers, Brian On Wed, Jul 7, 2010 at 6:25 PM, Chuck Mortimore wrote: > Use-case: =A0 When establishing web federation with customers we allow > them to either use their salesforce username ( enforced to be globally > unique ) or a federationid ( enforced to be unique to that particular > customer/tenant ) as the subject of their SAML assertion. =A0 Since our > SAML ACS is global for all customers, as is our OAuth token endpoint, > when federationid is being used we need an additional piece of data to > disabiguate the customer...essentially namespacing the federationid. > =A0On our ACS endpoint, we accept a parameter. =A0For this use-case on ou= r > token endpoint we'll use client_id. The alternative us we use some > other proprietary parameter to identify what org the client belongs > to. > > This is optional for us, and depends on an individual customer configurat= ion. > > We will not be issuing refresh tokens. =A0 Clients will need to get/mint > a new one-time-use saml bearer assertion if they want a new access > token > > I'm a believer that devs will have to reference other docs and specs > for the assertion flow. =A0Perhaps making this language stronger would > help? > > -cmort > > On Wednesday, July 7, 2010, Brian Eaton wrote: >> On Wed, Jul 7, 2010 at 4:51 PM, Chuck Mortimore >> wrote: >>> This thread forced a great deal on internal discussion today, and we >>> actually do have some more immediate use-cases where we'll require >>> client_id with the assertion flow >>> >>> I support leaving it as optional >> >> Can you describe the additional use cases? >> >> And do they require refresh tokens as well? >> >> I'm really worried about jamming multiple use cases into a single >> profile, and then being surprised when: >> a) that profile is suboptimal for all of the use cases >> b) developers are hugely confused by it >> >> Cheers, >> Brian >> > From beaton@google.com Thu Jul 8 12:34: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 0F78B3A6B64 for ; Thu, 8 Jul 2010 12:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[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 dzZHSDyTlSSp for ; Thu, 8 Jul 2010 12:33:54 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id CD7763A6836 for ; Thu, 8 Jul 2010 12:32:08 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o68JVdQR009040 for ; Thu, 8 Jul 2010 12:31:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278617500; bh=nIuDAXYcOVXvh2fCl2Yl2SpHA0Y=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=izZfmMNEwcQ3fT5mZagISLCh7juwtCQdcRuhpP0BflQhHyW4kRCyMM9Lo0L/N7kTa ErKLsIgvhakWgfq2Iw7cw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=e3MXGOi4OywF7C3+qey+dUN9Ta7DhAH4zs/laKp2ndTO17gSd1jVsmAHzBL+fDTpl PFFeGq6eWZZVeltqiggxA== Received: from pxi20 (pxi20.prod.google.com [10.243.27.20]) by kpbe11.cbf.corp.google.com with ESMTP id o68JVcid022739 for ; Thu, 8 Jul 2010 12:31:38 -0700 Received: by pxi20 with SMTP id 20so586923pxi.17 for ; Thu, 08 Jul 2010 12:31:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.48.18 with SMTP id v18mr10244804wfv.102.1278617498183; Thu, 08 Jul 2010 12:31:38 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Thu, 8 Jul 2010 12:31:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Jul 2010 12:31:38 -0700 Message-ID: From: Brian Eaton To: David Recordon 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] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:34:26 -0000 D. On Thu, Jul 8, 2010 at 9:29 AM, David Recordon wrote: > I'm honestly trying to decide myself and a few other people are in simila= r > situations. Thus a poll: > A) Yes, I'm going to be in=A0Maastricht > B) Maybe, depends on the number of OAuth WG members going > C) Maybe, depends on some other reason > D) No > If you're missing context, in a few weeks it is the IETF meeting > in=A0Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a mee= ting > scheduled all afternoon Tuesday the 27th. > Thanks, > --David > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From yarong@microsoft.com Thu Jul 8 12: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 260453A6B5D for ; Thu, 8 Jul 2010 12:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 9yFrgsnLnnwU for ; Thu, 8 Jul 2010 12:34:51 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 4B54B3A6B6F for ; Thu, 8 Jul 2010 12:34:30 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 8 Jul 2010 12:32:53 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.44]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0160.007; Thu, 8 Jul 2010 12:32:55 -0700 From: Yaron Goland To: Brian Eaton , Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] assertion profile changes Thread-Index: AQHLHhBAaZ1SQfISsUeJvLFkeH57+ZKmaKcAgADkn3A= Date: Thu, 8 Jul 2010 19:32:30 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C5F987B82@TK5EX14MBXC113.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:34:52 -0000 Here is what I think happened. In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format ar= guments were used to allow clients to authenticate themselves to token endp= oints in two legged OAuth scenarios. In OAuth 2.0 two legged OAuth as a separate definition was removed and inst= ead merged into three legged OAuth (something that I think is a feature). B= ut in making this transition the original wrap_assertion and wrap_assertion= _format arguments got turned into assertion_type and assertion. But (and this part is tricky so please read carefully) assertion_type and a= ssertion were part of the grant_type structure which was not used for AuthN= (the way client_id/client_secret are) but rather for AuthZ (like refresh t= okens). Having assertion/assertion_type was still a very good improvement in the pr= otocol since we have plenty of real world scenarios where we need to use as= sertions for AuthZ but the change left a big hole - how do use an assertio= n for AuthN? That's where the client_assertion/client_assertion_type come in. So the whole confusion really seems to have come about because OAuth in doi= ng a good thing (unifying 2 and 3 legged patterns) ended up moving assertio= ns from AuthN to AuthZ, which was actually a new (and useful) feature but a= s a consequence created a hole that didn't exist with WRAP when dealing wit= h AuthN. So by putting in client_assertion/client_assertion_type and keeping asserti= on/assertion_type we get the best of all worlds. We can now use assertions = for both AuthN and AuthZ. Yaron > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Wednesday, July 07, 2010 2:03 PM > To: Eran Hammer-Lahav > Cc: Hannes Tschofenig; OAuth WG > Subject: Re: [OAUTH-WG] assertion profile changes >=20 > On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav > wrote: > > It is pretty much the same as originally proposed. Any recent changes > > are an oversight, not any intentional change. Since it was proposed, > > the only change made (with full consensus) was to allow client > > authentication as an optional request parameter, as well as allow a > > refresh token as an optional response parameter. >=20 > Can you point me to the e-mail threads that reached consensus on using > client authentication? >=20 > Can you point me to the e-mail threads that reached consensus on returnin= g > a refresh token? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From yarong@microsoft.com Thu Jul 8 12:36: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 372373A6836 for ; Thu, 8 Jul 2010 12:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.165 X-Spam-Level: X-Spam-Status: No, score=-10.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 JLjrH4o7yXCg for ; Thu, 8 Jul 2010 12:36:08 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 1C2703A68B6 for ; Thu, 8 Jul 2010 12:36:08 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 8 Jul 2010 12:36:11 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.44]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0160.007; Thu, 8 Jul 2010 12:36:12 -0700 From: Yaron Goland To: David Recordon , OAuth WG Thread-Topic: [OAUTH-WG] POLL: Are you going to Maastricht? Thread-Index: AQHLHrq5Uxe3wlUXbkCpchLkzWbrqJKnbA7w Date: Thu, 8 Jul 2010 19:35:48 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C5F987BE7@TK5EX14MBXC113.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C5F987BE7TK5EX14MBXC113r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:36:09 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C5F987BE7TK5EX14MBXC113r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= avid Recordon Sent: Thursday, July 08, 2010 9:29 AM To: OAuth WG Subject: [OAUTH-WG] POLL: Are you going to Maastricht? I'm honestly trying to decide myself and a few other people are in similar = situations. Thus a poll: A) Yes, I'm going to be in Maastricht B) Maybe, depends on the number of OAuth WG members going C) Maybe, depends on some other reason D) No If you're missing context, in a few weeks it is the IETF meeting in Maastri= cht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting scheduled= all afternoon Tuesday the 27th. Thanks, --David --_000_7C01E631FF4B654FA1E783F1C0265F8C5F987BE7TK5EX14MBXC113r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

D

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of David Recordon
Sent: Thursday, July 08, 2010 9:29 AM
To: OAuth WG
Subject: [OAUTH-WG] POLL: Are you going to Maastricht?

 

I'm honestly trying to decide myself and a few other= people are in similar situations. Thus a poll:

A) Yes, I'm going to be in Maastricht

B) Maybe, depends on the number of OAuth WG members = going

C) Maybe, depends on some other reason

D) No

 

If you're missing context, in a few weeks it is the = IETF meeting in Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting schedule= d all afternoon Tuesday the 27th.

 

Thanks,

--David

--_000_7C01E631FF4B654FA1E783F1C0265F8C5F987BE7TK5EX14MBXC113r_-- From beaton@google.com Thu Jul 8 12:43:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3342F3A6B44 for ; Thu, 8 Jul 2010 12:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.475 X-Spam-Level: X-Spam-Status: No, score=-105.475 tagged_above=-999 required=5 tests=[AWL=0.501, 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 9bcg+nWh1wbt for ; Thu, 8 Jul 2010 12:43:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DBEBF3A68A3 for ; Thu, 8 Jul 2010 12:43:15 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o68JhEMY000540 for ; Thu, 8 Jul 2010 12:43:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278618194; bh=jztguEpnzTCwPn0UFc5Cbu2paPA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=JvG4z4QET/TfqX8ojwx3/v9aegfx0nwpAvlN74QAQ4jlE35Fz94HzSRLsGpWw/KRJ 2+MAr9qXCgGfu+jOh3RZg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=L0EWfvyqdkW47AmZ2iLsqWzFPDT6iIVL8R8KP8HlxpkO5KRvLdkZvd2RcQ5P82cMS ee8/KiJCp4xwx1bQTt6Eg== Received: from pwi6 (pwi6.prod.google.com [10.241.219.6]) by hpaq7.eem.corp.google.com with ESMTP id o68JhBPY010308 for ; Thu, 8 Jul 2010 12:43:11 -0700 Received: by pwi6 with SMTP id 6so627300pwi.24 for ; Thu, 08 Jul 2010 12:43:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.48.18 with SMTP id v18mr10254900wfv.102.1278618190005; Thu, 08 Jul 2010 12:43:10 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Thu, 8 Jul 2010 12:43:09 -0700 (PDT) In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C5F987B82@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C5F987B82@TK5EX14MBXC113.redmond.corp.microsoft.com> Date: Thu, 8 Jul 2010 12:43:09 -0700 Message-ID: From: Brian Eaton To: Yaron Goland Content-Type: multipart/alternative; boundary=000e0cd50aa804c8b7048ae57ff0 X-System-Of-Record: true Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:43:17 -0000 --000e0cd50aa804c8b7048ae57ff0 Content-Type: text/plain; charset=ISO-8859-1 And I am now seriously, seriously confused about your use case. Why do you need refresh tokens? Can you give more details? On Thu, Jul 8, 2010 at 12:32 PM, Yaron Goland wrote: > Here is what I think happened. > > In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format > arguments were used to allow clients to authenticate themselves to token > endpoints in two legged OAuth scenarios. > > In OAuth 2.0 two legged OAuth as a separate definition was removed and > instead merged into three legged OAuth (something that I think is a > feature). But in making this transition the original wrap_assertion and > wrap_assertion_format arguments got turned into assertion_type and > assertion. > > But (and this part is tricky so please read carefully) assertion_type and > assertion were part of the grant_type structure which was not used for AuthN > (the way client_id/client_secret are) but rather for AuthZ (like refresh > tokens). > > Having assertion/assertion_type was still a very good improvement in the > protocol since we have plenty of real world scenarios where we need to use > assertions for AuthZ but the change left a big hole - how do use an > assertion for AuthN? > > That's where the client_assertion/client_assertion_type come in. > > So the whole confusion really seems to have come about because OAuth in > doing a good thing (unifying 2 and 3 legged patterns) ended up moving > assertions from AuthN to AuthZ, which was actually a new (and useful) > feature but as a consequence created a hole that didn't exist with WRAP when > dealing with AuthN. > > So by putting in client_assertion/client_assertion_type and keeping > assertion/assertion_type we get the best of all worlds. We can now use > assertions for both AuthN and AuthZ. > > Yaron > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Brian Eaton > > Sent: Wednesday, July 07, 2010 2:03 PM > > To: Eran Hammer-Lahav > > Cc: Hannes Tschofenig; OAuth WG > > Subject: Re: [OAUTH-WG] assertion profile changes > > > > On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav > > wrote: > > > It is pretty much the same as originally proposed. Any recent changes > > > are an oversight, not any intentional change. Since it was proposed, > > > the only change made (with full consensus) was to allow client > > > authentication as an optional request parameter, as well as allow a > > > refresh token as an optional response parameter. > > > > Can you point me to the e-mail threads that reached consensus on using > > client authentication? > > > > Can you point me to the e-mail threads that reached consensus on > returning > > a refresh token? > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --000e0cd50aa804c8b7048ae57ff0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And I am now seriously, seriously confused about your use case.

Why do you need refresh tokens?

Can you gi= ve more details?

On Thu, Jul 8, 2010 at 1= 2:32 PM, Yaron Goland <yarong@microsoft.com> wrote:
Here is what I think happened.

In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format ar= guments were used to allow clients to authenticate themselves to token endp= oints in two legged OAuth scenarios.

In OAuth 2.0 two legged OAuth as a separate definition was removed and inst= ead merged into three legged OAuth (something that I think is a feature). B= ut in making this transition the original wrap_assertion and wrap_assertion= _format arguments got turned into assertion_type and assertion.

But (and this part is tricky so please read carefully) assertion_type and a= ssertion were part of the grant_type structure which was not used for AuthN= (the way client_id/client_secret are) but rather for AuthZ (like refresh t= okens).

Having assertion/assertion_type was still a very good improvement in the pr= otocol since we have plenty of real world scenarios where we need to use as= sertions for AuthZ but the change left =A0a big hole - how do use an assert= ion for AuthN?

That's where the client_assertion/client_assertion_type come in.

So the whole confusion really seems to have come about because OAuth in doi= ng a good thing (unifying 2 and 3 legged patterns) ended up moving assertio= ns from AuthN to AuthZ, which was actually a new (and useful) feature but a= s a consequence created a hole that didn't exist with WRAP when dealing= with AuthN.

So by putting in client_assertion/client_assertion_type and keeping asserti= on/assertion_type we get the best of all worlds. We can now use assertions = for both AuthN and AuthZ.

=A0 =A0 =A0 =A0Yaron

> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf
> Of Brian Eaton
> Sent: Wednesday, July 07, 2010 2:03 PM
> To: Eran Hammer-Lahav
> Cc: Hannes Tschofenig; OAuth WG
> Subject: Re: [OAUTH-WG] assertion profile changes
>
> On Wed, Jul 7, 2010 at 1:08 PM= , Eran Hammer-Lahav
> <eran@hueniverse.com>= wrote:
> > It is pretty much the same as originally proposed. Any recent cha= nges
> > are an oversight, not any intentional change. Since it was propos= ed,
> > the only change made (with full consensus) was to allow client > > authentication as an optional request parameter, as well as allow= a
> > refresh token as an optional response parameter.
>
> Can you point me to the e-mail threads that reached consensus on using=
> client authentication?
>
> Can you point me to the e-mail threads that reached consensus on retur= ning
> a refresh token?
> ________________________= _______________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--000e0cd50aa804c8b7048ae57ff0-- From lvh@laurensvh.be Thu Jul 8 12:47: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 548FA3A68B1 for ; Thu, 8 Jul 2010 12:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.924 X-Spam-Level: X-Spam-Status: No, score=-0.924 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfFv660Ya4hW for ; Thu, 8 Jul 2010 12:47:31 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id ACBF43A686E for ; Thu, 8 Jul 2010 12:47:30 -0700 (PDT) Received: by fxm1 with SMTP id 1so701929fxm.31 for ; Thu, 08 Jul 2010 12:47:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.190.133 with SMTP id x5mr60704hbh.164.1278618445218; Thu, 08 Jul 2010 12:47:25 -0700 (PDT) Received: by 10.239.147.11 with HTTP; Thu, 8 Jul 2010 12:47:25 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Jul 2010 21:47:25 +0200 Message-ID: From: Laurens Van Houtven To: David Recordon Content-Type: text/plain; charset=UTF-8 Cc: OAuth WG Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 19:47:32 -0000 B From oauth@ajkuiper.com Thu Jul 8 13:22: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 3E2CF3A68DE for ; Thu, 8 Jul 2010 13:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.986 X-Spam-Level: X-Spam-Status: No, score=0.986 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 jw7uFFoZGW3k for ; Thu, 8 Jul 2010 13:22:48 -0700 (PDT) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by core3.amsl.com (Postfix) with ESMTP id 29EAF3A68C0 for ; Thu, 8 Jul 2010 13:22:48 -0700 (PDT) Received: from [192.168.178.38] (wedontpanic.xs4all.nl [80.101.173.200]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id o68KMpYR004201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Jul 2010 22:22:51 +0200 (CEST) (envelope-from oauth@ajkuiper.com) Message-ID: <4C363398.2030307@ajkuiper.com> Date: Thu, 08 Jul 2010 22:22:48 +0200 From: "Arnout J. Kuiper" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: multipart/alternative; boundary="------------050107020001020508070805" X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [OAUTH-WG] In dire need of the device flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 20:22:49 -0000 This is a multi-part message in MIME format. --------------050107020001020508070805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Long story short, a while ago we (the company I work for) created our own protocols, which after investigation, matched the device flow in the earlier versions of the OAuth2 spec exactly. I'm in favor of open standards, so I would like to conform to the OAuth2 specification, if possible. Up to version 6 of the spec, I was very happy, because the device flow perfectly matched our specific needs (having to deal with embedded software communicating with our API, with no browser (or no trusted browser) available in some devices). Now the device flow is gone. Can somebody tell me what the current position is on the device flow, and whether there is a place for it in the OAuth2 specification? Cheers, --Arnout Kuiper --------------050107020001020508070805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,

Long story short, a while ago we (the company I work for) created our own protocols, which after investigation, matched the device flow in the earlier versions of the OAuth2 spec exactly. I'm in favor of open standards, so I would like to conform to the OAuth2 specification, if possible.

Up to version 6 of the spec, I was very happy, because the device flow perfectly matched our specific needs (having to deal with embedded software communicating with our API, with no browser (or no trusted browser) available in some devices). Now the device flow is gone.

Can somebody tell me what the current position is on the device flow, and whether there is a place for it in the OAuth2 specification?

Cheers,

  --Arnout Kuiper

--------------050107020001020508070805-- From mscurtescu@google.com Thu Jul 8 13:29: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 9BF683A688F for ; Thu, 8 Jul 2010 13:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.822 X-Spam-Level: X-Spam-Status: No, score=-101.822 tagged_above=-999 required=5 tests=[AWL=0.155, 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 JKB00NM0-Bz0 for ; Thu, 8 Jul 2010 13:29:12 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 55B903A6836 for ; Thu, 8 Jul 2010 13:29:12 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o68KTG7D010860 for ; Thu, 8 Jul 2010 13:29:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278620956; bh=B0lqwYnYkZraRUjcks2M4+L502g=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=o8sJM+ZApMKQZgCeyJyhT8uQtV9tRD3d0gmbnjwwFgzaV/U5+yjCazTEx2ZO1M62/ OIn9yNsOnHsERpMe0p03w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=NSjCcc/c9/HHBG7gXu+nPf6E2uk+w00BwR/nHohp0+PTwHT4tr6BHNn8KV4w53geF kZq0WIjd7RcxXWSxjpXhQ== Received: from yxt33 (yxt33.prod.google.com [10.190.5.225]) by hpaq2.eem.corp.google.com with ESMTP id o68KTEBg031728 for ; Thu, 8 Jul 2010 13:29:15 -0700 Received: by yxt33 with SMTP id 33so253186yxt.15 for ; Thu, 08 Jul 2010 13:29:14 -0700 (PDT) Received: by 10.101.129.16 with SMTP id g16mr10495719ann.76.1278620954235; Thu, 08 Jul 2010 13:29:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Thu, 8 Jul 2010 13:28:54 -0700 (PDT) In-Reply-To: <4C363398.2030307@ajkuiper.com> References: <4C363398.2030307@ajkuiper.com> From: Marius Scurtescu Date: Thu, 8 Jul 2010 13:28:54 -0700 Message-ID: To: "Arnout J. Kuiper" 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] In dire need of the device flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 20:29:13 -0000 I think the idea was to create a separate spec for the device flow, so that the core spec can be finished faster. The device flow described in version 6 can be the starting point for this separate spec, and if you are saying that something like this is already implemented, then it could be quite close to a stable version. Marius On Thu, Jul 8, 2010 at 1:22 PM, Arnout J. Kuiper wrote= : > Hi, > > Long story short, a while ago we (the company I work for) created our own > protocols, which after investigation, matched the device flow in the earl= ier > versions of the OAuth2 spec exactly. I'm in favor of open standards, so I > would like to conform to the OAuth2 specification, if possible. > > Up to version 6 of the spec, I was very happy, because the device flow > perfectly matched our specific needs (having to deal with embedded softwa= re > communicating with our API, with no browser (or no trusted browser) > available in some devices). Now the device flow is gone. > > Can somebody tell me what the current position is on the device flow, and > whether there is a place for it in the OAuth2 specification? > > Cheers, > > =A0 --Arnout Kuiper > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From cmortimore@salesforce.com Thu Jul 8 13:29:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2C53A6836 for ; Thu, 8 Jul 2010 13:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[AWL=1.000, 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 s6GOAIGPvGzu for ; Thu, 8 Jul 2010 13:29:11 -0700 (PDT) Received: from exprod8og110.obsmtp.com (exprod8og110.obsmtp.com [64.18.3.100]) by core3.amsl.com (Postfix) with SMTP id 02AB33A67D0 for ; Thu, 8 Jul 2010 13:29:10 -0700 (PDT) Received: from source ([204.14.239.238]) by exprod8ob110.postini.com ([64.18.7.12]) with SMTP ID DSNKTDY1G3Qh4sWMloMZ8G2aUWlxzzb5q/E4@postini.com; Thu, 08 Jul 2010 13:29:15 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Thu, 8 Jul 2010 13:29:15 -0700 From: Chuck Mortimore To: Yaron Goland , Brian Eaton , Eran Hammer-Lahav Date: Thu, 8 Jul 2010 13:29:13 -0700 Thread-Topic: [OAUTH-WG] assertion profile changes Thread-Index: AQHLHhBAaZ1SQfISsUeJvLFkeH57+ZKmaKcAgADkn3CAAC8OeA== Message-ID: In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C5F987B82@TK5EX14MBXC113.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85B83298020cmortimoresalesforcecom_" MIME-Version: 1.0 Cc: Hannes Tschofenig , OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 20:29:18 -0000 --_000_C85B83298020cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 7/8/10 12:32 PM, "Yaron Goland" wrote: Here is what I think happened. In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format ar= guments were used to allow clients to authenticate themselves to token endp= oints in two legged OAuth scenarios. In OAuth 2.0 two legged OAuth as a separate definition was removed and inst= ead merged into three legged OAuth (something that I think is a feature). B= ut in making this transition the original wrap_assertion and wrap_assertion= _format arguments got turned into assertion_type and assertion. I'm not sure I agree with this. I read the 09 spec as clearly being a 2-l= egged OAuth flow. I actually read your suggested text as enabling asserti= ons for 3 legged flows. How is the current text 3 legged? -cmort But (and this part is tricky so please read carefully) assertion_type and a= ssertion were part of the grant_type structure which was not used for AuthN= (the way client_id/client_secret are) but rather for AuthZ (like refresh t= okens). Having assertion/assertion_type was still a very good improvement in the pr= otocol since we have plenty of real world scenarios where we need to use as= sertions for AuthZ but the change left a big hole - how do use an assertio= n for AuthN? That's where the client_assertion/client_assertion_type come in. So the whole confusion really seems to have come about because OAuth in doi= ng a good thing (unifying 2 and 3 legged patterns) ended up moving assertio= ns from AuthN to AuthZ, which was actually a new (and useful) feature but a= s a consequence created a hole that didn't exist with WRAP when dealing wit= h AuthN. So by putting in client_assertion/client_assertion_type and keeping asserti= on/assertion_type we get the best of all worlds. We can now use assertions = for both AuthN and AuthZ. Yaron > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Wednesday, July 07, 2010 2:03 PM > To: Eran Hammer-Lahav > Cc: Hannes Tschofenig; OAuth WG > Subject: Re: [OAUTH-WG] assertion profile changes > > On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav > wrote: > > It is pretty much the same as originally proposed. Any recent changes > > are an oversight, not any intentional change. Since it was proposed, > > the only change made (with full consensus) was to allow client > > authentication as an optional request parameter, as well as allow a > > refresh token as an optional response parameter. > > Can you point me to the e-mail threads that reached consensus on using > client authentication? > > Can you point me to the e-mail threads that reached consensus on returnin= g > a refresh token? > _______________________________________________ > 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_C85B83298020cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] assertion profile changes


On 7/8/10 12:32 PM, "Yaron Goland" <yarong@microsoft.com> wrote:

Here is what I think happened.

In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format ar= guments were used to allow clients to authenticate themselves to token endp= oints in two legged OAuth scenarios.

In OAuth 2.0 two legged OAuth as a separate definition was removed and inst= ead merged into three legged OAuth (something that I think is a feature). B= ut in making this transition the original wrap_assertion and wrap_assertion= _format arguments got turned into assertion_type and assertion.

I’m not sure I agree with this.   I read the 09= spec as clearly being a 2-legged OAuth flow.   I actually read y= our suggested text as enabling assertions for 3 legged flows.

How is the current text 3 legged?

-cmort


But (and this part is tricky so please read carefully) assertion_type and a= ssertion were part of the grant_type structure which was not used for AuthN= (the way client_id/client_secret are) but rather for AuthZ (like refresh t= okens).

Having assertion/assertion_type was still a very good improvement in the pr= otocol since we have plenty of real world scenarios where we need to use as= sertions for AuthZ but the change left  a big hole - how do use an ass= ertion for AuthN?

That's where the client_assertion/client_assertion_type come in.

So the whole confusion really seems to have come about because OAuth in doi= ng a good thing (unifying 2 and 3 legged patterns) ended up moving assertio= ns from AuthN to AuthZ, which was actually a new (and useful) feature but a= s a consequence created a hole that didn't exist with WRAP when dealing wit= h AuthN.

So by putting in client_assertion/client_assertion_type and keeping asserti= on/assertion_type we get the best of all worlds. We can now use assertions = for both AuthN and AuthZ.

        Yaron

> -----Original Message-----
> From: oauth-bounces@ietf.org [<= a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org]= On Behalf
> Of Brian Eaton
> Sent: Wednesday, July 07, 2010 2:03 PM
> To: Eran Hammer-Lahav
> Cc: Hannes Tschofenig; OAuth WG
> Subject: Re: [OAUTH-WG] assertion profile changes
>
> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav
> <eran@hueniverse.com> wrote:=
> > It is pretty much the same as originally proposed. Any recent cha= nges
> > are an oversight, not any intentional change. Since it was propos= ed,
> > the only change made (with full consensus) was to allow client > > authentication as an optional request parameter, as well as allow= a
> > refresh token as an optional response parameter.
>
> Can you point me to the e-mail threads that reached consensus on using=
> client authentication?
>
> Can you point me to the e-mail threads that reached consensus on retur= ning
> a refresh token?
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth

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

--_000_C85B83298020cmortimoresalesforcecom_-- From yarong@microsoft.com Thu Jul 8 15:06:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 644173A68FA for ; Thu, 8 Jul 2010 15:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.273 X-Spam-Level: X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 4zmvO1CtdxE6 for ; Thu, 8 Jul 2010 15:06:38 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 7C8503A67F0 for ; Thu, 8 Jul 2010 15:06:37 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 8 Jul 2010 15:06:41 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.44]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0160.007; Thu, 8 Jul 2010 15:06:41 -0700 From: Yaron Goland To: "oauth@ietf.org" Thread-Topic: Versioning and namespaces Thread-Index: Acse6Uu7ETo/9rI7TXGJys2UIdCJmg== Date: Thu, 8 Jul 2010 22:06:24 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C5F9880A5@TK5EX14MBXC113.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C5F9880A5TK5EX14MBXC113r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Versioning and namespaces X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 22:06:40 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C5F9880A5TK5EX14MBXC113r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In regards to the discussion of versioning and namespaces I would suggest w= e follow RFC 3864. If someone wants to add an extension to OAuth then they = can either write an RFC or they can use the lightweight review mechanism si= milar to the one RFC 3864 introduced. Just a thought, Yaron --_000_7C01E631FF4B654FA1E783F1C0265F8C5F9880A5TK5EX14MBXC113r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In regards to the discussion of versioning and names= paces I would suggest we follow RFC 3864. If someone wants to add an extens= ion to OAuth then they can either write an RFC or they can use the lightwei= ght review mechanism similar to the one RFC 3864 introduced.

        &nbs= p;       Just a thought,

        &nbs= p;            &= nbsp;          Yaron

--_000_7C01E631FF4B654FA1E783F1C0265F8C5F9880A5TK5EX14MBXC113r_-- From bcampbell@pingidentity.com Thu Jul 8 15:27:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76EE43A681F for ; Thu, 8 Jul 2010 15:27:36 -0700 (PDT) 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 yVkCbvt7HvyU for ; Thu, 8 Jul 2010 15:27:35 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by core3.amsl.com (Postfix) with SMTP id ADB293A67F0 for ; Thu, 8 Jul 2010 15:27:34 -0700 (PDT) Received: from source ([209.85.161.43]) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKTDZQ2tGS8hEiQr74YlXzVpJUiWRqVmLc@postini.com; Thu, 08 Jul 2010 15:27:39 PDT Received: by fxm18 with SMTP id 18so890231fxm.2 for ; Thu, 08 Jul 2010 15:27:37 -0700 (PDT) Received: by 10.223.112.84 with SMTP id v20mr7651136fap.68.1278628057218; Thu, 08 Jul 2010 15:27:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.14.196 with HTTP; Thu, 8 Jul 2010 15:27:06 -0700 (PDT) In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C5F987B82@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C5F987B82@TK5EX14MBXC113.redmond.corp.microsoft.com> From: Brian Campbell Date: Thu, 8 Jul 2010 16:27:06 -0600 Message-ID: To: Yaron Goland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 22:27:36 -0000 Maybe I'm the only one having a hard time following this thread but I suspect I'm not alone. I'm going to try and just summarize the issues - mostly for my own edification but hopefully this may help others too. Please let me know if I'm off base. The thread originally started with a discussion of the assertion grant type as it's now called in -09 section 4.1.3 @ http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3 and there seemed to be two points of contention specifically about it: 1) Should returning a refresh token be allowed? Currently the text in that section says, "The authorization server SHOULD NOT issue a refresh token." Some folks feel that is sufficient but some feel it should be a MUST NOT. 2) Should client authentication be required/optional/forbidden when requesting an access token via an assertion grant type. The text in -09 makes it sound like it might be mandatory (because of text in http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4 maybe?). No one thinks mandatory is a good idea. Eran indicated that the intent was for it to be optional and -10 would reflect that. Some people feel that client authentication in the assertion grant type is necessary/confusing and should explicitly forbidden rather than just optional. More recently the thread has turned to a discussion of client authentication and if/how the spec should allow for clients to authenticate themselves to the token endpoint using means other than the client_secret. Section 2 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2 leaves the means of client authentication pretty open, it seems, but then only provides normative guidance for "Basic Client Credentials" in section 2.1 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2.1 I believe that Yaron is auguring for a something that might become a section 2.2 called "Assertion Client Credentials." But this is not related to the assertion grant type (especially if client authentication is forbidden from that grant type request). How's my characterization of this? If it's accurate, I think there's value in realizing that there are two pretty distinct issues in question here and I feel like some of the conversations around "assertions" have been confused by mixing the two. I'm not, at this point, arguing the merits of anything - just first trying to make sure we are arguing about the same things. -Brian Campbell On Thu, Jul 8, 2010 at 1:32 PM, Yaron Goland wrote: > Here is what I think happened. > > In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format = arguments were used to allow clients to authenticate themselves to token en= dpoints in two legged OAuth scenarios. > > In OAuth 2.0 two legged OAuth as a separate definition was removed and in= stead merged into three legged OAuth (something that I think is a feature).= But in making this transition the original wrap_assertion and wrap_asserti= on_format arguments got turned into assertion_type and assertion. > > But (and this part is tricky so please read carefully) assertion_type and= assertion were part of the grant_type structure which was not used for Aut= hN (the way client_id/client_secret are) but rather for AuthZ (like refresh= tokens). > > Having assertion/assertion_type was still a very good improvement in the = protocol since we have plenty of real world scenarios where we need to use = assertions for AuthZ but the change left =A0a big hole - how do use an asse= rtion for AuthN? > > That's where the client_assertion/client_assertion_type come in. > > So the whole confusion really seems to have come about because OAuth in d= oing a good thing (unifying 2 and 3 legged patterns) ended up moving assert= ions from AuthN to AuthZ, which was actually a new (and useful) feature but= as a consequence created a hole that didn't exist with WRAP when dealing w= ith AuthN. > > So by putting in client_assertion/client_assertion_type and keeping asser= tion/assertion_type we get the best of all worlds. We can now use assertion= s for both AuthN and AuthZ. > > =A0 =A0 =A0 =A0Yaron > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Brian Eaton >> Sent: Wednesday, July 07, 2010 2:03 PM >> To: Eran Hammer-Lahav >> Cc: Hannes Tschofenig; OAuth WG >> Subject: Re: [OAUTH-WG] assertion profile changes >> >> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav >> wrote: >> > It is pretty much the same as originally proposed. Any recent changes >> > are an oversight, not any intentional change. Since it was proposed, >> > the only change made (with full consensus) was to allow client >> > authentication as an optional request parameter, as well as allow a >> > refresh token as an optional response parameter. >> >> Can you point me to the e-mail threads that reached consensus on using >> client authentication? >> >> Can you point me to the e-mail threads that reached consensus on returni= ng >> a refresh token? >> _______________________________________________ >> 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 cmortimore@salesforce.com Thu Jul 8 15:35: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 C890D3A697B for ; Thu, 8 Jul 2010 15:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.667, 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 2qCYnocZ5nY5 for ; Thu, 8 Jul 2010 15:34:18 -0700 (PDT) Received: from exprod8og107.obsmtp.com (exprod8og107.obsmtp.com [64.18.3.94]) by core3.amsl.com (Postfix) with SMTP id A954C3A67F0 for ; Thu, 8 Jul 2010 15:34:16 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob107.postini.com ([64.18.7.12]) with SMTP ID DSNKTDZSbHGoGgVjuXsdaZ9JS94ebvjiw8pt@postini.com; Thu, 08 Jul 2010 15:34:21 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Thu, 8 Jul 2010 15:34:20 -0700 From: Chuck Mortimore To: Brian Campbell , Yaron Goland Date: Thu, 8 Jul 2010 15:34:18 -0700 Thread-Topic: [OAUTH-WG] assertion profile changes Thread-Index: Acse7MlmR5SrzfWZRRivIMrY+v4+GAAAOo5X Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85BA07A8047cmortimoresalesforcecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 22:35:07 -0000 --_000_C85BA07A8047cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That sounds like a very accurate description to me. -cmort On 7/8/10 3:27 PM, "Brian Campbell" wrote: Maybe I'm the only one having a hard time following this thread but I suspect I'm not alone. I'm going to try and just summarize the issues - mostly for my own edification but hopefully this may help others too. Please let me know if I'm off base. The thread originally started with a discussion of the assertion grant type as it's now called in -09 section 4.1.3 @ http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3 and there seemed to be two points of contention specifically about it: 1) Should returning a refresh token be allowed? Currently the text in that section says, "The authorization server SHOULD NOT issue a refresh token." Some folks feel that is sufficient but some feel it should be a MUST NOT. 2) Should client authentication be required/optional/forbidden when requesting an access token via an assertion grant type. The text in -09 makes it sound like it might be mandatory (because of text in http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4 maybe?). No one thinks mandatory is a good idea. Eran indicated that the intent was for it to be optional and -10 would reflect that. Some people feel that client authentication in the assertion grant type is necessary/confusing and should explicitly forbidden rather than just optional. More recently the thread has turned to a discussion of client authentication and if/how the spec should allow for clients to authenticate themselves to the token endpoint using means other than the client_secret. Section 2 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2 leaves the means of client authentication pretty open, it seems, but then only provides normative guidance for "Basic Client Credentials" in section 2.1 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2.1 I believe that Yaron is auguring for a something that might become a section 2.2 called "Assertion Client Credentials." But this is not related to the assertion grant type (especially if client authentication is forbidden from that grant type request). How's my characterization of this? If it's accurate, I think there's value in realizing that there are two pretty distinct issues in question here and I feel like some of the conversations around "assertions" have been confused by mixing the two. I'm not, at this point, arguing the merits of anything - just first trying to make sure we are arguing about the same things. -Brian Campbell On Thu, Jul 8, 2010 at 1:32 PM, Yaron Goland wrote: > Here is what I think happened. > > In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format = arguments were used to allow clients to authenticate themselves to token en= dpoints in two legged OAuth scenarios. > > In OAuth 2.0 two legged OAuth as a separate definition was removed and in= stead merged into three legged OAuth (something that I think is a feature).= But in making this transition the original wrap_assertion and wrap_asserti= on_format arguments got turned into assertion_type and assertion. > > But (and this part is tricky so please read carefully) assertion_type and= assertion were part of the grant_type structure which was not used for Aut= hN (the way client_id/client_secret are) but rather for AuthZ (like refresh= tokens). > > Having assertion/assertion_type was still a very good improvement in the = protocol since we have plenty of real world scenarios where we need to use = assertions for AuthZ but the change left a big hole - how do use an assert= ion for AuthN? > > That's where the client_assertion/client_assertion_type come in. > > So the whole confusion really seems to have come about because OAuth in d= oing a good thing (unifying 2 and 3 legged patterns) ended up moving assert= ions from AuthN to AuthZ, which was actually a new (and useful) feature but= as a consequence created a hole that didn't exist with WRAP when dealing w= ith AuthN. > > So by putting in client_assertion/client_assertion_type and keeping asser= tion/assertion_type we get the best of all worlds. We can now use assertion= s for both AuthN and AuthZ. > > Yaron > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Brian Eaton >> Sent: Wednesday, July 07, 2010 2:03 PM >> To: Eran Hammer-Lahav >> Cc: Hannes Tschofenig; OAuth WG >> Subject: Re: [OAUTH-WG] assertion profile changes >> >> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav >> wrote: >> > It is pretty much the same as originally proposed. Any recent changes >> > are an oversight, not any intentional change. Since it was proposed, >> > the only change made (with full consensus) was to allow client >> > authentication as an optional request parameter, as well as allow a >> > refresh token as an optional response parameter. >> >> Can you point me to the e-mail threads that reached consensus on using >> client authentication? >> >> Can you point me to the e-mail threads that reached consensus on returni= ng >> a refresh token? >> _______________________________________________ >> 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_C85BA07A8047cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] assertion profile changes That sounds lik= e a very accurate description to me.

-cmort


On 7/8/10 3:27 PM, "Brian Campbell" <bcampbell@pingidentity.com> wrote:

Maybe I'm the only one having a hard time following this thread = but I
suspect I'm not alone.   I'm going to try and just summarize the<= BR> issues - mostly for my own edification but hopefully this may help
others too.  Please let me know if I'm off base.

The thread originally started with a discussion of the assertion grant
type as it's now called in -09 section 4.1.3 @
http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3 and there seemed to be two points of contention specifically about it:

1) Should returning a refresh token be allowed?   Currently the t= ext
in that section says, "The authorization server SHOULD NOT issue a
refresh token."   Some folks feel that is sufficient but som= e feel it
should be a MUST NOT.

2) Should client authentication be required/optional/forbidden when
requesting an access token via an assertion grant type.   The tex= t in
-09 makes it sound like it might be mandatory (because of text in
htt= p://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4 maybe?).
No one thinks mandatory is a good idea.  Eran indicated that the
intent was for it to be optional and -10 would reflect that.   So= me
people feel that client authentication in the assertion grant type is
necessary/confusing and should explicitly forbidden rather than just
optional.


More recently the thread has turned to a discussion of client
authentication and if/how the spec should allow for clients to
authenticate themselves to the token endpoint using means other than
the client_secret.  Section 2
htt= p://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2 leaves the
means of client authentication pretty open, it seems, but then only
provides normative guidance for "Basic Client Credentials" in sec= tion
2.1 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2.1

I believe that Yaron is auguring for a something that might become a
section 2.2 called "Assertion Client Credentials."  But this= is not
related to the assertion grant type (especially if client
authentication is forbidden from that grant type request).


How's my characterization of this?  If it's accurate, I think there's<= BR> value in realizing that there are two pretty distinct issues in
question here and I feel like some of the conversations around
"assertions" have been confused by mixing the two.  I'm not,= at this
point, arguing the merits of anything - just first trying to make sure
we are arguing about the same things.

-Brian Campbell

On Thu, Jul 8, 2010 at 1:32 PM, Yaron Goland <yarong@microsoft.com> wrote:
> Here is what I think happened.
>
> In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_form= at arguments were used to allow clients to authenticate themselves to token= endpoints in two legged OAuth scenarios.
>
> In OAuth 2.0 two legged OAuth as a separate definition was removed and= instead merged into three legged OAuth (something that I think is a featur= e). But in making this transition the original wrap_assertion and wrap_asse= rtion_format arguments got turned into assertion_type and assertion.
>
> But (and this part is tricky so please read carefully) assertion_type = and assertion were part of the grant_type structure which was not used for = AuthN (the way client_id/client_secret are) but rather for AuthZ (like refr= esh tokens).
>
> Having assertion/assertion_type was still a very good improvement in t= he protocol since we have plenty of real world scenarios where we need to u= se assertions for AuthZ but the change left =A0a big hole - how do use an a= ssertion for AuthN?
>
> That's where the client_assertion/client_assertion_type come in.
>
> So the whole confusion really seems to have come about because OAuth i= n doing a good thing (unifying 2 and 3 legged patterns) ended up moving ass= ertions from AuthN to AuthZ, which was actually a new (and useful) feature = but as a consequence created a hole that didn't exist with WRAP when dealin= g with AuthN.
>
> So by putting in client_assertion/client_assertion_type and keeping as= sertion/assertion_type we get the best of all worlds. We can now use assert= ions for both AuthN and AuthZ.
>
> =A0 =A0 =A0 =A0Yaron
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org<= /a>] On Behalf
>> Of Brian Eaton
>> Sent: Wednesday, July 07, 2010 2:03 PM
>> To: Eran Hammer-Lahav
>> Cc: Hannes Tschofenig; OAuth WG
>> Subject: Re: [OAUTH-WG] assertion profile changes
>>
>> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav
>> <eran@hueniverse.com> wr= ote:
>> > It is pretty much the same as originally proposed. Any recent= changes
>> > are an oversight, not any intentional change. Since it was pr= oposed,
>> > the only change made (with full consensus) was to allow clien= t
>> > authentication as an optional request parameter, as well as a= llow a
>> > refresh token as an optional response parameter.
>>
>> Can you point me to the e-mail threads that reached consensus on u= sing
>> client authentication?
>>
>> Can you point me to the e-mail threads that reached consensus on r= eturning
>> a refresh token?
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C85BA07A8047cmortimoresalesforcecom_-- From igor.faynberg@alcatel-lucent.com Thu Jul 8 15:45: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 D77823A696B for ; Thu, 8 Jul 2010 15:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, 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 kvW0zTKUcz+W for ; Thu, 8 Jul 2010 15:45:10 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id EDADD3A67F0 for ; Thu, 8 Jul 2010 15:45:09 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o68Mj6dB023560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2010 17:45:08 -0500 (CDT) Received: from [135.244.40.45] (faynberg.lra.lucent.com [135.244.40.45]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o68Mj54R024923; Thu, 8 Jul 2010 17:45:06 -0500 (CDT) Message-ID: <4C3654F1.70506@alcatel-lucent.com> Date: Thu, 08 Jul 2010 18:45:05 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Arnout J. Kuiper" , "Zeltsan, Zachary" References: <4C363398.2030307@ajkuiper.com> In-Reply-To: <4C363398.2030307@ajkuiper.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@ietf.org Subject: Re: [OAUTH-WG] In dire need of the device flow 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, 08 Jul 2010 22:45:11 -0000 Arnout, Please check with Zachary (copied here), who has been compiling the OAuth use cases. The idea has been to keep the use cases and the protocol aligned. So, if your use case is not present, please make sure that it is present in the next version of the draft. (Of course, the WG will need to support the inclusion of the material that had not been there before.) From what I saw on the list, there is no disagreement with the present draft. Igor Arnout J. Kuiper wrote: > Hi, > > Long story short, a while ago we (the company I work for) created our > own protocols, which after investigation, matched the device flow in > the earlier versions of the OAuth2 spec exactly. I'm in favor of open > standards, so I would like to conform to the OAuth2 specification, if > possible. > > Up to version 6 of the spec, I was very happy, because the device flow > perfectly matched our specific needs (having to deal with embedded > software communicating with our API, with no browser (or no trusted > browser) available in some devices). Now the device flow is gone. > > Can somebody tell me what the current position is on the device flow, > and whether there is a place for it in the OAuth2 specification? > > Cheers, > > --Arnout Kuiper > > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From beaton@google.com Thu Jul 8 15:49:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0643A696B for ; Thu, 8 Jul 2010 15:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.559 X-Spam-Level: X-Spam-Status: No, score=-105.559 tagged_above=-999 required=5 tests=[AWL=0.417, 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 YDWKVwuVpHlk for ; Thu, 8 Jul 2010 15:49:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DA8993A6909 for ; Thu, 8 Jul 2010 15:49:20 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o68MnMhX016229 for ; Thu, 8 Jul 2010 15:49:22 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278629362; bh=ZEYBswtj2/0eSRztdZm6Bwo3rzw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=PKfOjcIvyk/2z2XpLqMnpT8aIl0VAM8jXYc18rbHUsLJyYloXrxaHphIOU5S10bbJ P4Tcfi5WlZaQZvCqMl6yg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=ZCCAEArqxo+nI5c7zmLV4W6BzYEuO3mRgOD84vqeoFg9ng6lZaT0yhIh9UKYxVGzA LEqksjjo8hSeMXLoCLiFQ== Received: from pwj2 (pwj2.prod.google.com [10.241.219.66]) by kpbe14.cbf.corp.google.com with ESMTP id o68Mn3L0016509 for ; Thu, 8 Jul 2010 15:49:21 -0700 Received: by pwj2 with SMTP id 2so1063734pwj.35 for ; Thu, 08 Jul 2010 15:49:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.134.13 with SMTP id h13mr192337wfd.78.1278629361268; Thu, 08 Jul 2010 15:49:21 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Thu, 8 Jul 2010 15:49:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Jul 2010 15:49:21 -0700 Message-ID: From: Brian Eaton To: Chuck Mortimore Content-Type: multipart/alternative; boundary=000e0cd32c2ee0b995048ae8186f X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 22:49:33 -0000 --000e0cd32c2ee0b995048ae8186f Content-Type: text/plain; charset=ISO-8859-1 Nice summary, thanks Brian! I think there is a third issue as well, i.e. what the use case for client_id actually is. I think Chuck's use case has client_id used to disambiguate the purpose of the SAML assertion. We have a similar use case, both for SAML assertions and three-legged OAuth approvals, but I don't think overloading client_id for that is wise. Cheers, Brian On Thu, Jul 8, 2010 at 3:34 PM, Chuck Mortimore wrote: > That sounds like a very accurate description to me. > > -cmort > > > > On 7/8/10 3:27 PM, "Brian Campbell" wrote: > > Maybe I'm the only one having a hard time following this thread but I > suspect I'm not alone. I'm going to try and just summarize the > issues - mostly for my own edification but hopefully this may help > others too. Please let me know if I'm off base. > > The thread originally started with a discussion of the assertion grant > type as it's now called in -09 section 4.1.3 @ > http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3 and > there seemed to be two points of contention specifically about it: > > 1) Should returning a refresh token be allowed? Currently the text > in that section says, "The authorization server SHOULD NOT issue a > refresh token." Some folks feel that is sufficient but some feel it > should be a MUST NOT. > > 2) Should client authentication be required/optional/forbidden when > requesting an access token via an assertion grant type. The text in > -09 makes it sound like it might be mandatory (because of text in > http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4 maybe?). > No one thinks mandatory is a good idea. Eran indicated that the > intent was for it to be optional and -10 would reflect that. Some > people feel that client authentication in the assertion grant type is > necessary/confusing and should explicitly forbidden rather than just > optional. > > > More recently the thread has turned to a discussion of client > authentication and if/how the spec should allow for clients to > authenticate themselves to the token endpoint using means other than > the client_secret. Section 2 > http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2 leaves the > means of client authentication pretty open, it seems, but then only > provides normative guidance for "Basic Client Credentials" in section > 2.1 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2.1 > > I believe that Yaron is auguring for a something that might become a > section 2.2 called "Assertion Client Credentials." But this is not > related to the assertion grant type (especially if client > authentication is forbidden from that grant type request). > > > How's my characterization of this? If it's accurate, I think there's > value in realizing that there are two pretty distinct issues in > question here and I feel like some of the conversations around > "assertions" have been confused by mixing the two. I'm not, at this > point, arguing the merits of anything - just first trying to make sure > we are arguing about the same things. > > -Brian Campbell > > On Thu, Jul 8, 2010 at 1:32 PM, Yaron Goland wrote: > > Here is what I think happened. > > > > In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format > arguments were used to allow clients to authenticate themselves to token > endpoints in two legged OAuth scenarios. > > > > In OAuth 2.0 two legged OAuth as a separate definition was removed and > instead merged into three legged OAuth (something that I think is a > feature). But in making this transition the original wrap_assertion and > wrap_assertion_format arguments got turned into assertion_type and > assertion. > > > > But (and this part is tricky so please read carefully) assertion_type and > assertion were part of the grant_type structure which was not used for AuthN > (the way client_id/client_secret are) but rather for AuthZ (like refresh > tokens). > > > > Having assertion/assertion_type was still a very good improvement in the > protocol since we have plenty of real world scenarios where we need to use > assertions for AuthZ but the change left a big hole - how do use an > assertion for AuthN? > > > > That's where the client_assertion/client_assertion_type come in. > > > > So the whole confusion really seems to have come about because OAuth in > doing a good thing (unifying 2 and 3 legged patterns) ended up moving > assertions from AuthN to AuthZ, which was actually a new (and useful) > feature but as a consequence created a hole that didn't exist with WRAP when > dealing with AuthN. > > > > So by putting in client_assertion/client_assertion_type and keeping > assertion/assertion_type we get the best of all worlds. We can now use > assertions for both AuthN and AuthZ. > > > > Yaron > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > On Behalf > >> Of Brian Eaton > >> Sent: Wednesday, July 07, 2010 2:03 PM > >> To: Eran Hammer-Lahav > >> Cc: Hannes Tschofenig; OAuth WG > >> Subject: Re: [OAUTH-WG] assertion profile changes > >> > >> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav > >> wrote: > >> > It is pretty much the same as originally proposed. Any recent changes > >> > are an oversight, not any intentional change. Since it was proposed, > >> > the only change made (with full consensus) was to allow client > >> > authentication as an optional request parameter, as well as allow a > >> > refresh token as an optional response parameter. > >> > >> Can you point me to the e-mail threads that reached consensus on using > >> client authentication? > >> > >> Can you point me to the e-mail threads that reached consensus on > returning > >> a refresh token? > >> _______________________________________________ > >> 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 > > --000e0cd32c2ee0b995048ae8186f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nice summary, thanks Brian!

I think there is a third iss= ue as well, i.e. what the use case for client_id actually is.

I think Chuck's use case has client_id used to disambi= guate the purpose of the SAML assertion. =A0We have a similar use case, bot= h for SAML assertions and three-legged OAuth approvals, but I don't thi= nk overloading client_id for that is wise.

Cheers,
Brian

On Thu, Jul 8, 2010 at 3:34 PM, Chuck Mortimore <cmortimore@salesforce.com= > wrote:
That sounds lik= e a very accurate description to me.

-cmort



On 7/8/10 3:27 PM, "Brian Campbell" <bcampbell@pingidentity.com> w= rote:

Maybe I'm the = only one having a hard time following this thread but I
suspect I'm not alone. =A0=A0I'm going to try and just summarize th= e
issues - mostly for my own edification but hopefully this may help
others too. =A0Please let me know if I'm off base.

The thread originally started with a discussion of the assertion grant
type as it's now called in -09 section 4.1.3 @
http://tools.ietf.org/html/draft-ietf-oauth-v2-09#sectio= n-4.1.3 and
there seemed to be two points of contention specifically about it:

1) Should returning a refresh token be allowed? =A0=A0Currently the text in that section says, "The authorization server SHOULD NOT issue a
refresh token." =A0=A0Some folks feel that is sufficient but some feel= it
should be a MUST NOT.

2) Should client authentication be required/optional/forbidden when
requesting an access token via an assertion grant type. =A0=A0The text in -09 makes it sound like it might be mandatory (because of text in
http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4<= /a> maybe?).
No one thinks mandatory is a good idea. =A0Eran indicated that the
intent was for it to be optional and -10 would reflect that. =A0=A0Some
people feel that client authentication in the assertion grant type is
necessary/confusing and should explicitly forbidden rather than just
optional.


More recently the thread has turned to a discussion of client
authentication and if/how the spec should allow for clients to
authenticate themselves to the token endpoint using means other than
the client_secret. =A0Section 2
http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2<= /a> leaves the
means of client authentication pretty open, it seems, but then only
provides normative guidance for "Basic Client Credentials" in sec= tion
2.1 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#sect= ion-2.1

I believe that Yaron is auguring for a something that might become a
section 2.2 called "Assertion Client Credentials." =A0But this is= not
related to the assertion grant type (especially if client
authentication is forbidden from that grant type request).


How's my characterization of this? =A0If it's accurate, I think the= re's
value in realizing that there are two pretty distinct issues in
question here and I feel like some of the conversations around
"assertions" have been confused by mixing the two. =A0I'm not= , at this
point, arguing the merits of anything - just first trying to make sure
we are arguing about the same things.

-Brian Campbell

On Thu, Jul 8, 2010 at 1:32 PM, Yaron Goland <yarong@microsoft.com> wrote:
> Here is what I think happened.
>
> In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_form= at arguments were used to allow clients to authenticate themselves to token= endpoints in two legged OAuth scenarios.
>
> In OAuth 2.0 two legged OAuth as a separate definition was removed and= instead merged into three legged OAuth (something that I think is a featur= e). But in making this transition the original wrap_assertion and wrap_asse= rtion_format arguments got turned into assertion_type and assertion.
>
> But (and this part is tricky so please read carefully) assertion_type = and assertion were part of the grant_type structure which was not used for = AuthN (the way client_id/client_secret are) but rather for AuthZ (like refr= esh tokens).
>
> Having assertion/assertion_type was still a very good improvement in t= he protocol since we have plenty of real world scenarios where we need to u= se assertions for AuthZ but the change left =A0a big hole - how do use an a= ssertion for AuthN?
>
> That's where the client_assertion/client_assertion_type come in. >
> So the whole confusion really seems to have come about because OAuth i= n doing a good thing (unifying 2 and 3 legged patterns) ended up moving ass= ertions from AuthN to AuthZ, which was actually a new (and useful) feature = but as a consequence created a hole that didn't exist with WRAP when de= aling with AuthN.
>
> So by putting in client_assertion/client_assertion_type and keeping as= sertion/assertion_type we get the best of all worlds. We can now use assert= ions for both AuthN and AuthZ.
>
> =A0 =A0 =A0 =A0Yaron
>
>> -----Original Message-----
>> From: = oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Brian Eaton
>> Sent: Wednesday, July 07, 2010 2:03 PM
>> To: Eran Hammer-Lahav
>> Cc: Hannes Tschofenig; OAuth WG
>> Subject: Re: [OAUTH-WG] assertion profile changes
>>
>> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav
>> <eran@= hueniverse.com> wrote:
>> > It is pretty much the same as originally proposed. Any recent= changes
>> > are an oversight, not any intentional change. Since it was pr= oposed,
>> > the only change made (with full consensus) was to allow clien= t
>> > authentication as an optional request parameter, as well as a= llow a
>> > refresh token as an optional response parameter.
>>
>> Can you point me to the e-mail threads that reached consensus on u= sing
>> client authentication?
>>
>> Can you point me to the e-mail threads that reached consensus on r= eturning
>> a refresh token?
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


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


--000e0cd32c2ee0b995048ae8186f-- From James.H.Manger@team.telstra.com Thu Jul 8 18:16:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FE773A69B0 for ; Thu, 8 Jul 2010 18:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[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 p5w37guo5UCa for ; Thu, 8 Jul 2010 18:16:44 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 7B2623A6971 for ; Thu, 8 Jul 2010 18:16:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,561,1272808800"; d="scan'208";a="5648466" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 09 Jul 2010 11:16:43 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6037"; a="4347763" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbni.tcif.telstra.com.au with ESMTP; 09 Jul 2010 11:16:45 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Fri, 9 Jul 2010 11:16:45 +1000 From: "Manger, James H" To: OAuth WG Date: Fri, 9 Jul 2010 11:16:43 +1000 Thread-Topic: [OAUTH-WG] POLL: Are you going to Maastricht? Thread-Index: Acseur5zrFDg8nKVSKSQezW2oEU62wASR8Rg Message-ID: <255B9BB34FB7D647A506DC292726F6E1126605E128@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 01:16:45 -0000 D (No, I will not be in Maastricht) -- James Manger From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= avid Recordon Sent: Friday, 9 July 2010 2:29 AM To: OAuth WG Subject: [OAUTH-WG] POLL: Are you going to Maastricht? I'm honestly trying to decide myself and a few other people are in similar = situations. Thus a poll: A) Yes, I'm going to be in Maastricht B) Maybe, depends on the number of OAuth WG members going C) Maybe, depends on some other reason D) No If you're missing context, in a few weeks it is the IETF meeting in Maastri= cht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting scheduled= all afternoon Tuesday the 27th. Thanks, --David From beaton@google.com Thu Jul 8 23:37:07 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B06C3A6981 for ; Thu, 8 Jul 2010 23:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.319 X-Spam-Level: X-Spam-Status: No, score=-104.319 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKy2I25T8Zpm for ; Thu, 8 Jul 2010 23:37:05 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B1ECB3A6858 for ; Thu, 8 Jul 2010 23:37:05 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o696b9wV008557 for ; Thu, 8 Jul 2010 23:37:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278657429; bh=icSUFJynKPx3CPXlpilaLpYmLuc=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=hmKE2NtfAhP1aQ+sUuDbqNkRycudjf9qySdFSG4o47HeOdSenxMYwoW6TkC9HfRsu tzMCp6134UH15unWQpsHQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=TNoBtpu1OVzxIMafTvXrbckt5d2uufwi5skdrFBuJ4q8o6iSMSmWeTr7lIZyEMk5s O96Ewet4ZU8LXBA6rxIug== Received: from pvc30 (pvc30.prod.google.com [10.241.209.158]) by hpaq7.eem.corp.google.com with ESMTP id o696b7Wd024107 for ; Thu, 8 Jul 2010 23:37:07 -0700 Received: by pvc30 with SMTP id 30so639290pvc.28 for ; Thu, 08 Jul 2010 23:37:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.127.9 with SMTP id z9mr11097717wfc.335.1278657426666; Thu, 08 Jul 2010 23:37:06 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Thu, 8 Jul 2010 23:37:06 -0700 (PDT) Date: Thu, 8 Jul 2010 23:37:06 -0700 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] nits in oauth2 spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 06:37:07 -0000 Hey - I've got a bunch of nit-type comments on oauth2 draft 9. I'm going to bundle them all together here. There are a few more significant issues, those I'll start separate threads for. Introduction, paragraph 2: "In the traditional client-server authentication model,... presenting the resource owner's credentials.... etc..." I think this paragraph could be made a little more blunt to good effect. How about something like this: "In the traditional client-server model, third-party applications request access to the user's password in order to authenticate and gain access to the user's resources. This creates several problems: - the third-party application is required to save the user's password, in clear-text, in order to access the user's data in the future. - servers that need to allow third-party access must support password authentication, despite the fundamental security weaknesses created by passwords. - the third-party application gains overly broad access to the user's data. OAuth addresses these problems by introducing a third role to the traditional client-server authentication model, the resource owner. In OAuth, the client (which is usually not the resource owner, but is acting on their behalf) requests access to resources controlled by the resource owner and hosted by the resource server." "In OAuth, the client (which is usually not the resource owner, but is acting on its behalf)" I'd suggest saying "acting on their behalf". Using "its" is slightly confusing, it's a little unclear whether the possessive pronoun refers to the client or the resource owner. Introduction, paragraph 6: I love that the photo printing example has been so consistent for so long! Let's hope we never need to describe this again. This section calls the photo sharing service both the resource server and the authorization server. Might be better to call out the authorization server with a separate name here. How about this: "Instead, she authenticates directly with an authentication service trusted by the photo sharing service (authorization server) which issues the printing service delegation-specific credentials (token)." Terminology: token: some of these sentences are long, and can reasonably be broken up. "Specific scope, duration, and other authorization attributes" also reads badly for me. I can't pin down what it is (I think the sentence is grammatically correct), it just sounds wrong. How about this: token: A string representing an access authorization issued to the client. The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization servers. The token may self-contain the authorization information in a verifiable manner (i.e. the token may consist of some data and signature). Alternatively, the token may denote an identifier used to retrieve the authorization information." I'd also add this sentence at the end "tokens may be pure capabilities, or specific authentication credentials may be required in order for a client to use a token." Capability is a term-of-art, it will put people who are looking at the security of the spec in the right mood. Even if people don't like my phrasing, let's please find a way to work it into the definition. The indentation in this section threw me off, I don't think it's necessary. I think we could just define "resource owner" and "end-user" at the top level. Likewise for token, access token, and refresh token. (Look, I said at the beginning of this note these were nits.) Introduction "The client should not interact directly with the resource owner": this just isn't true. This is like saying that the printing service should not interact with the user who wants to use them. How about "The client should not request the resource owner's credentials directly. Instead it should request authorization via..." "The process used to obtain an authorization code utilized the end-user's user-agent and is described in Section 3." I think there's a shift in tense there that reads funny. Also lots of repetition of "uses/used/utilized/end-user/user-agent". How about "The process used to obtain the end-users authorization involves the end-user's user-agent and is described in section 3." "basic credentials". This makes sense if you've read the BNF in the http basic auth spec, and is otherwise weird. I think everywhere that refers in prose to the username and password should call them "username and password" or "password credentials". Let's not use "basic credentials" at all. We could use "basic-credentials" in BNF that refers to the exact format used by the HTTP spec, but otherwise let's skip it. 1.4.1 Web Server Flow Missing a period. "The web client initiates the flow by redirecting the end-user's user-agent to the end-user authorization endpoint as described in Section 3 >.< The client..." 1.4.2 User-Agent "an access token requests" reads wrong, looks like half of this sentence got edited one way and half another. How about "Unlike other profiles in which the client makes separate end-user authorization request and access token requests,..." Description of the user-agent profile has long sentences, and the description of the client secret bits read weird. But I think this section isn't true any longer anyway... I'll save that for a more substantive e-mail. 1.4.3 "Native Application" "Native Application Profile" or "Native application Flow" would both be better titles. Just "Native Application" sounds funny. "generally discouraged as it hands the end-user's password directly to the 3rd party." It's a little unclear who the 3rd party is here. I think this section could be better written as follows: * Prompt end users for their password and use them directly to obtain an access token. This is generally discouraged, as it requires that the application save the password in clear-text. It also requires that the server support password authentication." 1.4.4 Autonomous I think we need a better definition of Autonomous Clients, but I'm damned if I can think of one right now. "The scope of the access token is limited to the protected resources under the control of the client, or that of another resource owner previously arranged with the authorization server." That sounds a lot more complicated than it is. How about "The access token does not allow the client to act on behalf of an end-user. The token identifies the client, and so is scoped to the resources to which the client has direct access." 2. Client Credentials "regardless whether the credentials are identical". How about "regardless of whether the credentials are identical." But honestly I don't understand why this paragraph is necessary. Clients should obey the spec. 3. Obtaining End-User Authorization "the end-user access grant is expressed as an authorization code..." I don't think that's true in all of the profiles. How about "The client is issued tokens that represent the access granted by the end-user." 4.1.2 " The authorization server MUST validate the client credentials and end-user credentials and if valid issues an access token response as described in Section 4.2." There's a change of tense in there. Should be "and if valid issue an access token response..." 4.2 Access Token Response Extra comma. Should be "The sizes of tokens and other values received from the authorization server are left undefined by this specification." Cheers, Brian From mark.mcgloin@ie.ibm.com Fri Jul 9 01:49: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 391E33A6950; Fri, 9 Jul 2010 01:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0GA5rtESVet; Fri, 9 Jul 2010 01:49:07 -0700 (PDT) Received: from mtagate6.uk.ibm.com (mtagate6.uk.ibm.com [194.196.100.166]) by core3.amsl.com (Postfix) with ESMTP id EA68D3A6856; Fri, 9 Jul 2010 01:49:05 -0700 (PDT) Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate6.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o698n9OX013990; Fri, 9 Jul 2010 08:49:09 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o698n5C61564738; Fri, 9 Jul 2010 09:49:09 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o698n4BH008266; Fri, 9 Jul 2010 09:49:05 +0100 Received: from d06ml901.portsmouth.uk.ibm.com (d06ml901.portsmouth.uk.ibm.com [9.149.39.138]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id o698n46t008261; Fri, 9 Jul 2010 09:49:04 +0100 In-Reply-To: To: Brian Eaton X-Mailer: Lotus Notes Release 7.0 HF400 February 20, 2008 Message-ID: From: Mark Mcgloin Date: Fri, 9 Jul 2010 09:49:03 +0100 X-MIMETrack: Serialize by Router on D06ML901/06/M/IBM(Release 8.0.2FP2|June 22, 2009) at 09/07/2010 09:49:04 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 08:49:08 -0000 Agree, good summary Brian C I still haven't seen the use case for refresh tokens with assertion flo= w! We can control that server side but it is easier to just implement the = spec as is. It seems insecure granting a refresh token with potentially longer life= than the assertion. Do people intent on using refresh tokens with assertions intend to link the two? Regards Mark McGloin On 08/07/2010 23:49 Brian Eaton wrote: Nice summary, thanks Brian! I think there is a third issue as well, i.e. what the use case for client_id actually is. I think Chuck's use case has client_id used to disambiguate the purpose= of the SAML assertion. =A0We have a similar use case, both for SAML assert= ions and three-legged OAuth approvals, but I don't think overloading client_= id for that is wise. Cheers, Brian On Thu, Jul 8, 2010 at 3:34 PM, Chuck Mortimore wrote: That sounds like a very accurate description to me. -cmort On 7/8/10 3:27 PM, "Brian Campbell" wrot= e: Maybe I'm the only one having a hard time following this thread= but I suspect I'm not alone. =A0=A0I'm going to try and just summariz= e the issues - mostly for my own edification but hopefully this may h= elp others too. =A0Please let me know if I'm off base. The thread originally started with a discussion of the assertio= n grant type as it's now called in -09 section 4.1.3 @ http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3= and there seemed to be two points of contention specifically about = it: 1) Should returning a refresh token be allowed? =A0=A0Currently= the text in that section says, "The authorization server SHOULD NOT issu= e a refresh token." =A0=A0Some folks feel that is sufficient but so= me feel it should be a MUST NOT. 2) Should client authentication be required/optional/forbidden = when requesting an access token via an assertion grant type. =A0=A0T= he text in -09 makes it sound like it might be mandatory (because of text = in http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4 maybe?). No one thinks mandatory is a good idea. =A0Eran indicated that = the intent was for it to be optional and -10 would reflect that. =A0= =A0Some people feel that client authentication in the assertion grant t= ype is necessary/confusing and should explicitly forbidden rather than= just optional. More recently the thread has turned to a discussion of client authentication and if/how the spec should allow for clients to authenticate themselves to the token endpoint using means other= than the client_secret. =A0Section 2 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2 lea= ves the means of client authentication pretty open, it seems, but then = only provides normative guidance for "Basic Client Credentials" in section 2.1 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2= .1 I believe that Yaron is auguring for a something that might bec= ome a section 2.2 called "Assertion Client Credentials." =A0But this = is not related to the assertion grant type (especially if client authentication is forbidden from that grant type request). How's my characterization of this? =A0If it's accurate, I think= there's value in realizing that there are two pretty distinct issues in= question here and I feel like some of the conversations around "assertions" have been confused by mixing the two. =A0I'm not, = at this point, arguing the merits of anything - just first trying to ma= ke sure we are arguing about the same things. -Brian Campbell = From sDronia@gmx.de Fri Jul 9 04:27: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 62C433A69F5 for ; Fri, 9 Jul 2010 04:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.394 X-Spam-Level: ** X-Spam-Status: No, score=2.394 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKRWYUQoz62X for ; Fri, 9 Jul 2010 04:27:28 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 09FF93A6A07 for ; Fri, 9 Jul 2010 04:27:27 -0700 (PDT) Received: (qmail invoked by alias); 09 Jul 2010 11:27:28 -0000 Received: from tmo-100-108.customers.d1-online.com (EHLO [127.0.0.1]) [80.187.100.108] by mail.gmx.net (mp006) with SMTP; 09 Jul 2010 13:27:28 +0200 X-Authenticated: #3259608 X-Provags-ID: V01U2FsdGVkX1+mEBFY/wumrOzzGegV4x6PI1TEDWirJNs0WU205F jd3EwxGE5qT+99 Message-ID: <4C3707BD.6070201@gmx.de> Date: Fri, 09 Jul 2010 13:27:57 +0200 From: Stefanie Dronia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Marius Scurtescu References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2DC7C5.2090009@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F108B.70504@cdatazone.org> <20100708110542.150740@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 11:27:29 -0000 Hallo Marius, thanks for your statement. Your idea of a migration flow is quite good and necessary. But I still doubt, if the work and effort should be investigated to spare the user from some interaction (authentication and user consent). Latest he will be asked for his consent at the time, the refresh token expired (as long as the refresh token has a limited validity period [1]) and a new one is requested. With the additional aspects (OAuth 2 refresh token returned, OAuth 1 access token revoked), the flow might only be performed once? By the way, the revoke of the OAuth 1 token should not be optionally, but a must IMO. By that way, the consumer is enforced to process with OAuth 2 flows. Have a nice weekend! Steffi [1] That a refresh token has a limited validity period is not defined in the spec. But the authz server should be able to invalidate it. E.g. when the refresh token is issued, a long, but limited validity period is assigned to it. Each time, new access token(s) are requested with the refresh token as access grant, the refresh token's validity period is extended. If not, it gets invalid reaching the assigned limit. This flow represents the user's usage of the consumers application. (Quasi) Infinitely valid refresh token at continuous usage of the consumers application. Limited validity at rare or no usage. Revocation of the granted access is done automatically w/o user intervention. Am 08.07.2010 20:26, schrieb Marius Scurtescu: > The bridge flow was meant to be used in a mixed OAuth 1 and OAuth 2 > environment, it allows the consumer to obtain a token using signatures > and then access protected resources with no signatures. Now that > signatures are re-introduced in OAuth 2 I don't think there is a need > for such an approach. > > That being said, migration can be done very similarly, differences > from the bridge flow: > - an OAuth 2 refresh token is also returned > - optionally the OAuth 1 token is revoked > > Such a migration flow would allow a consumer/client that has OAuth 1 > access tokens saved for its users to convert all of them to OAuth 2 > refresh tokens without involving the users. > > Marius > > > > On Thu, Jul 8, 2010 at 4:05 AM, Stefanie Dronia wrote: > >> Hi, >> >> >> >> I took a look at the OAuth 1 Bridge Flow suggested by Marius, the thread >> "OAuth 1 Bridge Flow" and had some thoughts: >> >> >> >> I do not really see the necessity for such a flow. >> >> First of all, all participating parties have to be modified and rolled out: >> >> - the consumer's application to support (at least) the bridge flow (and >> OAuth 2 [1]), >> >> - the authz server to provide OAuth 2 and additionally the bridge flow and >> >> - the resource server to handle OAuth2. >> >> Then, sometime later, when at least the authz server doesn't support OAuth 1 >> anymore, the client application and the resource server should be cleared up >> - no more OAuth 1, only OAuth 2. Again a new version to roll out. >> >> >> >> The only (small) benefit I see, is that the user will not be asked for >> authorization again. >> >> But is it worth it to develop, implement and roll out a Bridge Flow? I do >> not think so - too much expense for a small user interaction. >> >> Better: directly go to OAuth 2, when it is needed. >> >> >> >> The other thing I'm missing, is how to migrate completely to OAuth 2 after >> performing the bridge flow. Issuing a refresh token in the response seems >> necessary. But this issue was still mentioned (but not solved) in the thread >> "OAuth 1 Bridge Flow" by Eran. >> >> >> >> >> >> Thanks, >> >> Steffi >> >> >> >> [1] if OAuth 2 will not be supported, a new modified client has to be rolled >> out at the latest, the resource server doesn't support OAuth 1 anymore. >> >> >> >> -------- Original-Nachricht -------- >> Datum: Tue, 6 Jul 2010 21:54:16 -0700 >> Von: Marius Scurtescu >> An: Rob Richards >> CC: "oauth@ietf.org" >> Betreff: Re: [OAUTH-WG] Versioning >> >> On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards >> wrote: >> >>> Eran Hammer-Lahav wrote: >>> >>>> Hi Rob, >>>> >>>> I agree with you that a migration spec is important - please write one. >>>> >>>> >>> Like I didn't see that coming :) >>> >> I would like to help with this migration spec. Is this a good starting >> point: >> http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html >> >> Or, you had something else in mind? >> >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> -- >> GRATIS fr alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> > From diogo.borges.almeida@gmail.com Fri Jul 9 04:56:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0023A65A5 for ; Fri, 9 Jul 2010 04:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N+9if5mlZQN for ; Fri, 9 Jul 2010 04:56:55 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id EBC2B3A6A2B for ; Fri, 9 Jul 2010 04:56:54 -0700 (PDT) Received: by wwb13 with SMTP id 13so943832wwb.1 for ; Fri, 09 Jul 2010 04:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=JkOTAso8YDycEBbS168ABnHm/DLjeg2WZ6Lr05l1NIU=; b=W7IM4raHtwkzLUUa50/ydF9QRxJ8HbqqFVtibuhXM8UB1VY+0ZsOcEtPwPo/As0scw x75pzs96UWLJcBxvgc5Dv/Wj8QPkZxc4JTCtaUCO3mdvYcDxMxP42oR3NTy7eEkOO2Yn jx/w2FdRTYrrMhs2bTzQJCYkEy5L2sS2v4Y1k= 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=uN47qamiwCln4V6Q0QjAOSuvK0sCPvD8zbs1zessMpxqem93IIgcL3+eXDxTaqe20i 4vkjCr4ExHoBdXfjD5NP9gbkdjjqH2orLEFdmYNhNYrKu78zBfcOqg/beupDR7o2AZyw 2ZZ65DNOi/bUNNSCSb8GlIgAqZW7lowRZkjOA= Received: by 10.227.9.147 with SMTP id l19mr8247537wbl.55.1278676613897; Fri, 09 Jul 2010 04:56:53 -0700 (PDT) Received: from [172.20.10.57] ([62.28.14.10]) by mx.google.com with ESMTPS id i25sm5992106wbi.4.2010.07.09.04.56.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Jul 2010 04:56:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-13--278300651 From: Diogo Almeida In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6B44@SNV-EXVS08.ds.corp.yahoo.com> Date: Fri, 9 Jul 2010 12:56:49 +0100 Message-Id: <86C75B91-A9EE-4C2F-A168-BAF9549160E5@gmail.com> References: <7C01E631FF4B654FA1E783F1C0265F8C5F98786D@TK5EX14MBXC113.redmond.corp.microsoft.com> <012AB2B223CB3F4BB846962876F47217059B6B44@SNV-EXVS08.ds.corp.yahoo.com> To: OAuth WG X-Mailer: Apple Mail (2.1081) Subject: Re: [OAUTH-WG] The meaning of scope X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 11:56:57 -0000 --Apple-Mail-13--278300651 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello, Even though I realize that the small open-source lib developer voice = might not carry much weight, I would to make a small contribution to = this thread, presenting the WG with the mechanics we currently use to = support scopes in our soon to release -09 Ruby provider lib: 1) a provider registers the clients, assigning them an ID and Secret 2) as with most membership and roles, the provider sets the possible = scope of action for a given client ("outer bound") 3) we allow the provider to define system wide default scopes, or per = client 4) when an authorization request comes in, we validate the client and = the user authentication 4.1) in this same request the client sends an optional scope (eg friends = photos videos extended_user_info) 5) the provider then checks the requested scope 5.1) validates it based on the "outer bound" 5.2) the computed scope is validated against the user (eg some users = might not want to make their extended user info, such as email, = available to the client) 6) we generate the authorization code and, in this case, redirect with = the scope "friends photos" It's -indeed- quite an assumption we're making here [eventually a wrong = one], as it limits the use of scope in our implementation to the = permissions. For instance, we, for now, left out the "duration scopes" = suggested by Eran in his previous email. It would be very valuable for us to have more explicit texts regarding = the use of scopes. Best regards, Diogo Almeida On Jul 8, 2010, at 7:18 PM, William Mills wrote: > Leaving it loosely defined is good in my opinion.=20 > =20 > The way I see scope is as a way to limit the power of a token. = Examples of this might be "mail" to limit to only accessing e-mail, or = "read-only" for something like a calendar sync application pulling = events out of an online calendar. My mental model of scope does not = include expiration, since I believe tokens themselves should have = embedded timestamps if you want to support expiration.=20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Eran Hammer-Lahav > Sent: Thursday, July 08, 2010 11:06 AM > To: Yaron Goland; OAuth WG > Subject: Re: [OAUTH-WG] The meaning of scope >=20 > To me, scope means =93the stuff being accessed=94, but can also mean = permissions, duration, etc. I raised this issue a while back but since = we could not agree on what exactly is included in scope, it was left = vague. The key is the space-delimited values and how they relate to each = other (=93a b=94 covers =93a=94 and =93b=94 and is the same as =93b a=94).= That is all the interop help the spec currently provides. >=20 > This definition doesn=92t work well with generic permissions or = duration. For example: >=20 > =93friends photos read 2days=94 doesn=92t really work because =93read=94= and =932days=94 don=92t hold on their own. On the other hand: >=20 > =93friends:read:2d photos:write:1y=94 does work. >=20 > If someone needs a global permission or duration, they can define an = extension parameter but I have not seen any APIs where this was needed, = and where the above example will not work. I think there is value in = more standardization here but I don=92t have the use cases to suggest = what it should look like. >=20 > EHL >=20 >=20 > On 7/8/10 10:37 AM, "Yaron Goland" wrote: >=20 > Today the definition of scope is vague. But I have seen mails on this = list (such as Lukas Rosenstock=92s post = http://www.ietf.org/mail-archive/web/oauth/current/msg03560.html which = is just one example) that assert that scope represents the permissions = that a client is requesting. > =20 > When we use scope (going back to its introduction in WRAP) we used it = primary for two legged OAuth as a way for a client to tell a token = endpoint what audience (in the SAML sense) it wanted a token for. This = had nothing to do with the specific permission being requested. We used = other claims for that. > =20 > I am not asking the group to agree with our usage. But I do want to = check if the language in the spec (which really doesn=92t define scope = very tightly) is actually consistent with what is in people=92s heads. = Does the group see scope as a generally undefined entity that has to be = defined in context (one such context could be that scope represents = requested permissions) or do they see it just as a place to stick = requested permissions?=20 > =20 > What say you? > =20 > Thanks, > =20 > Yaron >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-13--278300651 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hello,

Even though I = realize that the small open-source lib developer voice might not carry = much weight, I would to make a small contribution to this thread, = presenting the WG with the mechanics we currently use to support scopes = in our soon to release -09  Ruby provider lib:

1) a provider registers the clients, assigning them an ID and = Secret
2) as with most = membership and roles, the provider sets the possible scope of action for = a given client ("outer bound")
3) we allow the provider to define system wide default scopes, = or per client
4) when an = authorization request comes in, we validate the client and the user = authentication
4.1) in this = same request the client sends an optional scope (eg friends photos = videos extended_user_info)
5) = the provider then checks the requested scope
5.1) validates it based on the "outer = bound"
5.2) the computed scope = is validated against the user (eg some users might not want to make = their extended user info, such as email, available to the = client)
6) we generate the = authorization code and, in this case, redirect with the scope "friends = photos"

It's -indeed- quite an assumption we're = making here [eventually a wrong one], as it limits the use of scope in = our implementation to the permissions. For instance, we, for now, left = out the "duration scopes" suggested by Eran in his previous = email.

It would be very valuable for us to have = more explicit texts regarding the use of scopes.

Best regards,
Diogo = Almeida

On Jul 8, 2010, at 7:18 PM, William Mills = wrote:

Leaving it loosely defined = is good in my opinion. =20
 
The way I see scope is as a = way to limit the power of a=20 token.  Examples of this might be "mail" to limit to only accessing = e-mail,=20 or "read-only" for something like a calendar sync application pulling = events out=20 of an online calendar.  My mental model of scope does not = include=20 expiration, since I believe tokens themselves should have embedded = timestamps if=20 you want to support expiration. 

From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] On Behalf Of Eran=20 Hammer-Lahav
Sent: Thursday, July 08, 2010 11:06 = AM
To:=20 Yaron Goland; OAuth WG
Subject: Re: [OAUTH-WG] The meaning = of=20 scope

To me, scope means =93the stuff being = accessed=94, but can=20 also mean permissions, duration, etc. I raised this issue a while back = but=20 since we could not agree on what exactly is included in scope, it was = left=20 vague. The key is the space-delimited values and how they relate to = each other=20 (=93a b=94 covers =93a=94 and =93b=94 and is the same as =93b a=94). = That is all the interop=20 help the spec currently provides.

This definition doesn=92t = work well=20 with generic permissions or duration. For example:

=93friends = photos read=20 2days=94 doesn=92t really work because =93read=94 and =932days=94 = don=92t hold on their own.=20 On the other hand:

=93friends:read:2d photos:write:1y=94 does=20= work.

If someone needs a global permission or duration, they = can define=20 an extension parameter but I have not seen any APIs where this was = needed, and=20 where the above example will not work. I think there is value in more=20= standardization here but I don=92t have the use cases to suggest what = it should=20 look like.

EHL


On 7/8/10 10:37 AM, "Yaron Goland" = <yarong@microsoft.com>=20 wrote:
Today the definition of scope is vague. But I = have=20 seen mails on this list (such as Lukas Rosenstock=92s post = http://www.ietf.org/mail-archive/web/oauth/current/msg03560.html=20 which is just one example) that assert that scope represents the = permissions=20 that a client is requesting.
 
When we use scope (going = back to=20 its introduction in WRAP) we used it primary for two legged OAuth as = a way=20 for a client to tell a token endpoint what audience (in the SAML = sense) it=20 wanted a token for. This had nothing to do with the specific = permission=20 being requested. We used other claims for that.
 
I am = not asking=20 the group to agree with our usage. But I do want to check if the = language in=20 the spec (which really doesn=92t define scope very tightly) is = actually=20 consistent with what is in people=92s heads. Does the group see = scope as a=20 generally undefined entity that has to be defined in context (one = such=20 context could be that scope represents requested permissions) or do = they see=20 it just as a place to stick requested permissions?=20 =
 
          =       What=20 say=20 = you?
 
         &n= bsp;           &nbs= p;          Thanks,
&= nbsp;
           = ;            &= nbsp;           &nb= sp;            = ;Yaron

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

= --Apple-Mail-13--278300651-- From mscurtescu@google.com Fri Jul 9 08:40:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9DCE3A6A91 for ; Fri, 9 Jul 2010 08:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.156 X-Spam-Level: X-Spam-Status: No, score=-104.156 tagged_above=-999 required=5 tests=[AWL=-1.822, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, FRT_BELOW2=2.154, 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 65qXNSaq8A62 for ; Fri, 9 Jul 2010 08:40:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6C3683A69EA for ; Fri, 9 Jul 2010 08:40:43 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o69FelXZ000921 for ; Fri, 9 Jul 2010 08:40:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278690048; bh=b5X3bVKYdZ4NKQmDhGro+gJDFnY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Ps41P+ofTtkjXIq/rFmGXZks17/OOZWNiJBay1eLSnJbPyNqEyK091GzFSTV2HrOt wLFx0gjdiCfMK57+0QJNA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=tjI5/nU93c9o1yfCMcAheAk5pZarNKq/5GfZ2OtXXSAgDRgNIp2JrUQOa9zZlcGsP nO7K8vphiyXhmPFKppaMw== Received: from gxk22 (gxk22.prod.google.com [10.202.11.22]) by kpbe17.cbf.corp.google.com with ESMTP id o69FdQ86004172 for ; Fri, 9 Jul 2010 08:40:47 -0700 Received: by gxk22 with SMTP id 22so2094416gxk.11 for ; Fri, 09 Jul 2010 08:40:46 -0700 (PDT) Received: by 10.100.163.13 with SMTP id l13mr11277865ane.267.1278690046324; Fri, 09 Jul 2010 08:40:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Fri, 9 Jul 2010 08:40:26 -0700 (PDT) In-Reply-To: <4C3707BD.6070201@gmx.de> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2DC7C5.2090009@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F108B.70504@cdatazone.org> <20100708110542.150740@gmx.net> <4C3707BD.6070201@gmx.de> From: Marius Scurtescu Date: Fri, 9 Jul 2010 08:40:26 -0700 Message-ID: To: Stefanie Dronia Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 15:40:44 -0000 See comments bellow... On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia wrote: > Hallo Marius, > > thanks for your statement. > Your idea of a migration flow is quite good and necessary. > > But I still doubt, if the work and effort should be investigated to spare > the user from some interaction (authentication and user consent). It all depends for how many users does the client have OAuth 1 tokens. Asking users to re-approve will confuse them and I guess many will not do it, > Latest he will be asked for his consent at the time, the refresh token > expired (as long as the refresh token has a limited validity period [1]) and > a new one is requested. That's authz implementation specific, but in most cases I think refresh tokens (or OAuth 1 access tokens) never expire. > With the additional aspects (OAuth 2 refresh token returned, OAuth 1 access > token revoked), the flow might only be performed once? Yes, I see this as a one time migration. > By the way, the revoke of the OAuth 1 token should not be optionally, but a > must IMO. By that way, the consumer is enforced to process with OAuth 2 > flows. Yes, the consumer has to switch over to OAuth 2. > > Have a nice weekend! > Steffi > > [1] That a refresh token has a limited validity period is not defined in the > spec. But the authz server should be able to invalidate it. It sure does. Also, I assume that most authz servers will give this option to the end user, some page where they can see all the refresh tokens issued for them and where they can revoke them. > E.g. when the refresh token is issued, a long, but limited validity period > is assigned to it. Each time, new access token(s) are requested with the > refresh token as access grant, the refresh token's validity period is > extended. If not, it gets invalid reaching the assigned limit. This flow > represents the user's usage of the consumers application. (Quasi) Infinitely > valid refresh token at continuous usage of the consumers application. > Limited validity at rare or no usage, Revocation of the granted access is > done automatically w/o user intervention. An interesting idea. I guess it is up to the authz server to implement something like this. Marius From zachary.zeltsan@alcatel-lucent.com Fri Jul 9 09:16: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 BA91E3A6A9E for ; Fri, 9 Jul 2010 09:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTwyl5EDOn88 for ; Fri, 9 Jul 2010 09:16:44 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id C7C5D3A6A1B for ; Fri, 9 Jul 2010 09:16:43 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o69GGjGe002598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jul 2010 11:16:45 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o69GGi8q027468; Fri, 9 Jul 2010 11:16:45 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 9 Jul 2010 11:16:28 -0500 From: "Zeltsan, Zachary (Zachary)" To: "Faynberg, Igor (Igor)" , "Arnout J. Kuiper" Date: Fri, 9 Jul 2010 11:16:27 -0500 Thread-Topic: [OAUTH-WG] In dire need of the device flow Thread-Index: Acse7zZqYk6wz5LdRLqlqXfMvjFifwAkFt/Q Message-ID: <5710F82C0E73B04FA559560098BF95B124F9688DAD@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4C363398.2030307@ajkuiper.com> <4C3654F1.70506@alcatel-lucent.com> In-Reply-To: <4C3654F1.70506@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] In dire need of the device flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 16:16:46 -0000 Arnout, The draft on the use cases that Igor mentions reflects the cases that had b= een discussed before the publication of the OAuth2.0 -06 version. It does i= nclude the device flow. Then there was a proposal to move the device flow f= rom the core specification to a separate draft (see http://www.ietf.org/mail-archive/web/oauth/current/msg03038.html ). Subsequently, the device flow was removed from the draft draft-ietf-oauth-v= 2. Zachary =20 -----Original Message----- From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]=20 Sent: Thursday, July 08, 2010 6:45 PM To: Arnout J. Kuiper; Zeltsan, Zachary (Zachary) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] In dire need of the device flow Arnout, Please check with Zachary (copied here), who has been compiling the=20 OAuth use cases. The idea has been to keep the use cases and the=20 protocol aligned. So, if your use case is not present, please make sure=20 that it is present in the next version of the draft. (Of course, the WG=20 will need to support the inclusion of the material that had not been=20 there before.) From what I saw on the list, there is no disagreement with the present=20 draft. Igor Arnout J. Kuiper wrote: > Hi, > > Long story short, a while ago we (the company I work for) created our=20 > own protocols, which after investigation, matched the device flow in=20 > the earlier versions of the OAuth2 spec exactly. I'm in favor of open=20 > standards, so I would like to conform to the OAuth2 specification, if=20 > possible. > > Up to version 6 of the spec, I was very happy, because the device flow=20 > perfectly matched our specific needs (having to deal with embedded=20 > software communicating with our API, with no browser (or no trusted=20 > browser) available in some devices). Now the device flow is gone. > > Can somebody tell me what the current position is on the device flow,=20 > and whether there is a place for it in the OAuth2 specification? > > Cheers, > > --Arnout Kuiper > > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 From cmortimore@salesforce.com Fri Jul 9 10:23: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 B35A83A67B3 for ; Fri, 9 Jul 2010 10:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.500, 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 LzALGypcLAJw for ; Fri, 9 Jul 2010 10:23:33 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by core3.amsl.com (Postfix) with SMTP id 830C43A6A5A for ; Fri, 9 Jul 2010 10:23:32 -0700 (PDT) Received: from source ([204.14.239.238]) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKTDdbGVQe/3iFRXZPswmBHaXigL7wvNLn@postini.com; Fri, 09 Jul 2010 10:23:38 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Fri, 9 Jul 2010 10:23:37 -0700 From: Chuck Mortimore To: Brian Eaton Date: Fri, 9 Jul 2010 10:23:37 -0700 Thread-Topic: [OAUTH-WG] assertion profile changes Thread-Index: Acse79HLc8SbtlS8Tl2gqzHqa1DeGwAm6VY7 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85CA92980E0cmortimoresalesforcecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 17:23:39 -0000 --_000_C85CA92980E0cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 7/8/10 3:49 PM, "Brian Eaton" wrote: Nice summary, thanks Brian! I think there is a third issue as well, i.e. what the use case for client_i= d actually is. I think Chuck's use case has client_id used to disambiguate the purpose of = the SAML assertion. We have a similar use case, both for SAML assertions a= nd three-legged OAuth approvals, but I don't think overloading client_id fo= r that is wise. I really wouldn't characterize my use-case as disambiguating the purpose. = I really need it to look up the "client" configuration. In my particular= use-case ( customers posting SAML assertions with subjects that are only u= nique when namespaced to a particular IDP ), the client is really defined a= s a SAML IDP, and I'd be looking up it's metadata based upon the client_id.= This seems appropriate to me. -cmort Cheers, Brian On Thu, Jul 8, 2010 at 3:34 PM, Chuck Mortimore = wrote: That sounds like a very accurate description to me. -cmort On 7/8/10 3:27 PM, "Brian Campbell" > wrote: Maybe I'm the only one having a hard time following this thread but I suspect I'm not alone. I'm going to try and just summarize the issues - mostly for my own edification but hopefully this may help others too. Please let me know if I'm off base. The thread originally started with a discussion of the assertion grant type as it's now called in -09 section 4.1.3 @ http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3 and there seemed to be two points of contention specifically about it: 1) Should returning a refresh token be allowed? Currently the text in that section says, "The authorization server SHOULD NOT issue a refresh token." Some folks feel that is sufficient but some feel it should be a MUST NOT. 2) Should client authentication be required/optional/forbidden when requesting an access token via an assertion grant type. The text in -09 makes it sound like it might be mandatory (because of text in http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4 maybe?). No one thinks mandatory is a good idea. Eran indicated that the intent was for it to be optional and -10 would reflect that. Some people feel that client authentication in the assertion grant type is necessary/confusing and should explicitly forbidden rather than just optional. More recently the thread has turned to a discussion of client authentication and if/how the spec should allow for clients to authenticate themselves to the token endpoint using means other than the client_secret. Section 2 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2 leaves the means of client authentication pretty open, it seems, but then only provides normative guidance for "Basic Client Credentials" in section 2.1 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2.1 I believe that Yaron is auguring for a something that might become a section 2.2 called "Assertion Client Credentials." But this is not related to the assertion grant type (especially if client authentication is forbidden from that grant type request). How's my characterization of this? If it's accurate, I think there's value in realizing that there are two pretty distinct issues in question here and I feel like some of the conversations around "assertions" have been confused by mixing the two. I'm not, at this point, arguing the merits of anything - just first trying to make sure we are arguing about the same things. -Brian Campbell On Thu, Jul 8, 2010 at 1:32 PM, Yaron Goland > wrote: > Here is what I think happened. > > In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format = arguments were used to allow clients to authenticate themselves to token en= dpoints in two legged OAuth scenarios. > > In OAuth 2.0 two legged OAuth as a separate definition was removed and in= stead merged into three legged OAuth (something that I think is a feature).= But in making this transition the original wrap_assertion and wrap_asserti= on_format arguments got turned into assertion_type and assertion. > > But (and this part is tricky so please read carefully) assertion_type and= assertion were part of the grant_type structure which was not used for Aut= hN (the way client_id/client_secret are) but rather for AuthZ (like refresh= tokens). > > Having assertion/assertion_type was still a very good improvement in the = protocol since we have plenty of real world scenarios where we need to use = assertions for AuthZ but the change left a big hole - how do use an assert= ion for AuthN? > > That's where the client_assertion/client_assertion_type come in. > > So the whole confusion really seems to have come about because OAuth in d= oing a good thing (unifying 2 and 3 legged patterns) ended up moving assert= ions from AuthN to AuthZ, which was actually a new (and useful) feature but= as a consequence created a hole that didn't exist with WRAP when dealing w= ith AuthN. > > So by putting in client_assertion/client_assertion_type and keeping asser= tion/assertion_type we get the best of all worlds. We can now use assertion= s for both AuthN and AuthZ. > > Yaron > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oa= uth-bounces@ietf.org] On Behalf >> Of Brian Eaton >> Sent: Wednesday, July 07, 2010 2:03 PM >> To: Eran Hammer-Lahav >> Cc: Hannes Tschofenig; OAuth WG >> Subject: Re: [OAUTH-WG] assertion profile changes >> >> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav >> > wrote: >> > It is pretty much the same as originally proposed. Any recent changes >> > are an oversight, not any intentional change. Since it was proposed, >> > the only change made (with full consensus) was to allow client >> > authentication as an optional request parameter, as well as allow a >> > refresh token as an optional response parameter. >> >> Can you point me to the e-mail threads that reached consensus on using >> client authentication? >> >> Can you point me to the e-mail threads that reached consensus on returni= ng >> a refresh token? >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C85CA92980E0cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] assertion profile changes


On 7/8/10 3:49 PM, "Brian Eaton" <beaton@google.com> wrote:

Nice summary, thanks Brian!

I think there is a third issue as well, i.e. what the use case for client_i= d actually is.

I think Chuck's use case has client_id used to disambiguate the purpose of = the SAML assertion. =A0We have a similar use case, both for SAML assertions= and three-legged OAuth approvals, but I don't think overloading client_id = for that is wise.

I really wouldn’t characterize my use-case as disambiguat= ing the purpose.   I really need it to look up the “client&= #8221; configuration.   In my particular use-case ( customers pos= ting SAML assertions with subjects that are only unique when namespaced to = a particular IDP ), the client is really defined as a SAML IDP, and I’= ;d be looking up it’s metadata based upon the client_id.   = This seems appropriate to me.

-cmort


Cheers,
Brian

On Thu, Jul 8, 2010 at 3:34 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:
That sounds like a very accurate description to me.

-cmort



On 7/8/10 3:27 PM, "Brian Campbell" <bcampbell@pingidentity.com <http://bcampbell@pingidentity.com> > wrote:
Maybe I'm the only one having a hard time following this thread = but I
suspect I'm not alone. =A0=A0I'm going to try and just summarize the
issues - mostly for my own edification but hopefully this may help
others too. =A0Please let me know if I'm off base.

The thread originally started with a discussion of the assertion grant
type as it's now called in -09 section 4.1.3 @
http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3 and there seemed to be two points of contention specifically about it:

1) Should returning a refresh token be allowed? =A0=A0Currently the text in that section says, "The authorization server SHOULD NOT issue a
refresh token." =A0=A0Some folks feel that is sufficient but some feel= it
should be a MUST NOT.

2) Should client authentication be required/optional/forbidden when
requesting an access token via an assertion grant type. =A0=A0The text in -09 makes it sound like it might be mandatory (because of text in
htt= p://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4 maybe?).
No one thinks mandatory is a good idea. =A0Eran indicated that the
intent was for it to be optional and -10 would reflect that. =A0=A0Some
people feel that client authentication in the assertion grant type is
necessary/confusing and should explicitly forbidden rather than just
optional.


More recently the thread has turned to a discussion of client
authentication and if/how the spec should allow for clients to
authenticate themselves to the token endpoint using means other than
the client_secret. =A0Section 2
htt= p://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2 leaves the
means of client authentication pretty open, it seems, but then only
provides normative guidance for "Basic Client Credentials" in sec= tion
2.1 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2.1

I believe that Yaron is auguring for a something that might become a
section 2.2 called "Assertion Client Credentials." =A0But this is= not
related to the assertion grant type (especially if client
authentication is forbidden from that grant type request).


How's my characterization of this? =A0If it's accurate, I think there's
value in realizing that there are two pretty distinct issues in
question here and I feel like some of the conversations around
"assertions" have been confused by mixing the two. =A0I'm not, at= this
point, arguing the merits of anything - just first trying to make sure
we are arguing about the same things.

-Brian Campbell

On Thu, Jul 8, 2010 at 1:32 PM, Yaron Goland <yarong@microsoft.com <http://yarong@microsoft.com> > wrote:
> Here is what I think happened.
>
> In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_form= at arguments were used to allow clients to authenticate themselves to token= endpoints in two legged OAuth scenarios.
>
> In OAuth 2.0 two legged OAuth as a separate definition was removed and= instead merged into three legged OAuth (something that I think is a featur= e). But in making this transition the original wrap_assertion and wrap_asse= rtion_format arguments got turned into assertion_type and assertion.
>
> But (and this part is tricky so please read carefully) assertion_type = and assertion were part of the grant_type structure which was not used for = AuthN (the way client_id/client_secret are) but rather for AuthZ (like refr= esh tokens).
>
> Having assertion/assertion_type was still a very good improvement in t= he protocol since we have plenty of real world scenarios where we need to u= se assertions for AuthZ but the change left =A0a big hole - how do use an a= ssertion for AuthN?
>
> That's where the client_assertion/client_assertion_type come in.
>
> So the whole confusion really seems to have come about because OAuth i= n doing a good thing (unifying 2 and 3 legged patterns) ended up moving ass= ertions from AuthN to AuthZ, which was actually a new (and useful) feature = but as a consequence created a hole that didn't exist with WRAP when dealin= g with AuthN.
>
> So by putting in client_assertion/client_assertion_type and keeping as= sertion/assertion_type we get the best of all worlds. We can now use assert= ions for both AuthN and AuthZ.
>
> =A0 =A0 =A0 =A0Yaron
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org <http://oauth-bounces@ietf.o= rg>  [mailto:oauth-bo= unces@ietf.org] On Behalf
>> Of Brian Eaton
>> Sent: Wednesday, July 07, 2010 2:03 PM
>> To: Eran Hammer-Lahav
>> Cc: Hannes Tschofenig; OAuth WG
>> Subject: Re: [OAUTH-WG] assertion profile changes
>>
>> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav
>> <eran@hueniverse.com <http://eran@hueniverse.com> >= ; wrote:
>> > It is pretty much the same as originally proposed. Any recent= changes
>> > are an oversight, not any intentional change. Since it was pr= oposed,
>> > the only change made (with full consensus) was to allow clien= t
>> > authentication as an optional request parameter, as well as a= llow a
>> > refresh token as an optional response parameter.
>>
>> Can you point me to the e-mail threads that reached consensus on u= sing
>> client authentication?
>>
>> Can you point me to the e-mail threads that reached consensus on r= eturning
>> a refresh token?
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <http://OAuth@ietf.org>
>> https://ww= w.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <http://OAuth@ietf.org>
> https://www.ie= tf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <http://OAuth@ietf.org>
https://www.ietf.or= g/mailman/listinfo/oauth


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



--_000_C85CA92980E0cmortimoresalesforcecom_-- From cmortimore@salesforce.com Fri Jul 9 10:41: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 3C0633A6964; Fri, 9 Jul 2010 10:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.400, 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 qExMaLESsGTZ; Fri, 9 Jul 2010 10:41:30 -0700 (PDT) Received: from exprod8og120.obsmtp.com (exprod8og120.obsmtp.com [64.18.3.40]) by core3.amsl.com (Postfix) with SMTP id 0480B3A6AB2; Fri, 9 Jul 2010 10:41:28 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob120.postini.com ([64.18.7.12]) with SMTP ID DSNKTDdfTWv3Xx6jUaRNFw4C9KHw6hsWnhI5@postini.com; Fri, 09 Jul 2010 10:41:34 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Fri, 9 Jul 2010 10:41:34 -0700 From: Chuck Mortimore To: Mark Mcgloin , Brian Eaton Date: Fri, 9 Jul 2010 10:41:34 -0700 Thread-Topic: [OAUTH-WG] assertion profile changes Thread-Index: AcsfQ5g69glw51rxSWedVgcTzP4wIAASmDaT Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85CAD5E80E5cmortimoresalesforcecom_" MIME-Version: 1.0 Cc: OAuth WG , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] assertion profile changes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 17:41:39 -0000 --_000_C85CAD5E80E5cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To directly address the 3 issues in Brian C's summary: 1) I haven't seen any strong use-cases for the issuing of refresh tokens ei= ther, but we do find the SHOULD NOT language to be strong enough. 2) We support client_id being optional, and will have need for it. No su= pport for mandatory, nor do we have any intent to use client_secret with th= is flow. 3) Yaron's suggestion of adding assertion as an authentication type does ha= ve some merit. It basically would allow an alternate client authenticatio= n mechanism beyond the client_secret, allowing for a variety of strategies = that would keep the secret off the wire. One approach would be to: * Add optional language to section 2 as Yaron has suggested. Personall= y I would stick with name/value definitions of "assertion_format" and "asse= rtion" parameters as defined in 4.1.3 These could be used as an alternat= ive for client authentication in any request that normally used client_secr= et. For instance, you could send a grant_type=3Dauthorization-code and i= nclude an assertion to identify the client, rather than the shared secret. * Change the authorization grant_type to make client_id optional (alread= y planned), and simply reference assertion & assertion_format from section = 2 as mandatory. This seems like it would meet the goals of the folks that want to do 2-legg= ed oauth with assertions, by leaving the fundamentals of section 4.1.3 in p= lace, as well as expand the capabilities for assertions to be used as authe= ntication, which is what Yaron is asking for. -cmort On 7/9/10 1:49 AM, "Mark Mcgloin" wrote: Agree, good summary Brian C I still haven't seen the use case for refresh tokens with assertion flow! We can control that server side but it is easier to just implement the spec as is. It seems insecure granting a refresh token with potentially longer life than the assertion. Do people intent on using refresh tokens with assertions intend to link the two? Regards Mark McGloin On 08/07/2010 23:49 Brian Eaton wrote: Nice summary, thanks Brian! I think there is a third issue as well, i.e. what the use case for client_id actually is. I think Chuck's use case has client_id used to disambiguate the purpose of the SAML assertion. We have a similar use case, both for SAML assertions and three-legged OAuth approvals, but I don't think overloading client_id for that is wise. Cheers, Brian On Thu, Jul 8, 2010 at 3:34 PM, Chuck Mortimore wrote: That sounds like a very accurate description to me. -cmort On 7/8/10 3:27 PM, "Brian Campbell" wrote: Maybe I'm the only one having a hard time following this thread but I suspect I'm not alone. I'm going to try and just summarize the issues - mostly for my own edification but hopefully this may help others too. Please let me know if I'm off base. The thread originally started with a discussion of the assertion grant type as it's now called in -09 section 4.1.3 @ http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3 and there seemed to be two points of contention specifically about it: 1) Should returning a refresh token be allowed? Currently the text in that section says, "The authorization server SHOULD NOT issue a refresh token." Some folks feel that is sufficient but some feel it should be a MUST NOT. 2) Should client authentication be required/optional/forbidden when requesting an access token via an assertion grant type. The text in -09 makes it sound like it might be mandatory (because of text in http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4 maybe?). No one thinks mandatory is a good idea. Eran indicated that the intent was for it to be optional and -10 would reflect that. Some people feel that client authentication in the assertion grant type is necessary/confusing and should explicitly forbidden rather than just optional. More recently the thread has turned to a discussion of client authentication and if/how the spec should allow for clients to authenticate themselves to the token endpoint using means other than the client_secret. Section 2 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2 leaves the means of client authentication pretty open, it seems, but then only provides normative guidance for "Basic Client Credentials" in section 2.1 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2.1 I believe that Yaron is auguring for a something that might become a section 2.2 called "Assertion Client Credentials." But this is not related to the assertion grant type (especially if client authentication is forbidden from that grant type request). How's my characterization of this? If it's accurate, I think there's value in realizing that there are two pretty distinct issues in question here and I feel like some of the conversations around "assertions" have been confused by mixing the two. I'm not, at this point, arguing the merits of anything - just first trying to make sure we are arguing about the same things. -Brian Campbell --_000_C85CAD5E80E5cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] assertion profile changes To directly add= ress the 3 issues in Brian C’s summary:

1) I haven’t seen any strong use-cases for the issuing of refresh tok= ens either, but we do find the SHOULD NOT language to be strong enough.

2) We support client_id being optional, and will have need for it.  &n= bsp; No support for mandatory, nor do we have any intent to use client= _secret with this flow.

3) Yaron’s suggestion of adding assertion as an authentication type d= oes have some merit.   It basically would allow an alternate clie= nt authentication mechanism beyond the client_secret, allowing for a variet= y of strategies that would keep the secret off the wire.   

One approach would be to:

  • Add optional language to section 2 as Yaron has suggested.  &nb= sp;Personally I would stick with name/value definitions of “assertion= _format” and “assertion” parameters as defined in 4.1.3 &= nbsp;  These could be used as an alternative for client authentic= ation in any request that normally used client_secret.    Fo= r instance, you could send a grant_type=3Dauthorization-code and include an= assertion to identify the client, rather than the shared secret.  
  • Change the authorization grant_type to make client_id optional (already = planned), and simply reference assertion & assertion_format from sectio= n 2 as mandatory.

This seems like it would meet the goals of the folks that want to do 2-legg= ed oauth with assertions, by leaving the fundamentals of section 4.1.3 in p= lace, as well as expand the capabilities for assertions to be used as authe= ntication, which is what Yaron is asking for.

-cmort


On 7/9/10 1:49 AM, "Mark Mcgloin" <mark.mcgloin@ie.ibm.com> wrote:



Agree, good summary Brian C

I still haven't seen the use case for refresh tokens with assertion flow! We can control that server side but it is easier to just implement the spec=
as is.

It seems insecure granting a refresh token with potentially longer life
than the assertion. Do people intent on using refresh tokens with
assertions intend to link the two?


Regards
Mark McGloin


On 08/07/2010 23:49 Brian Eaton wrote:

Nice summary, thanks Brian!

I think there is a third issue as well, i.e. what the use case for
client_id actually is.

I think Chuck's use case has client_id used to disambiguate the purpose of<= BR> the SAML assertion. =A0We have a similar use case, both for SAML assertions=
and three-legged OAuth approvals, but I don't think overloading client_id for that is wise.

Cheers,
Brian

On Thu, Jul 8, 2010 at 3:34 PM, Chuck Mortimore <cmortimore@salesforce.com>
wrote:
  That sounds like a very accurate description to me.

  -cmort



  On 7/8/10 3:27 PM, "Brian Campbell" <bcampbell@pingidentity.com> wrote:

        Maybe I'm the only one havi= ng a hard time following this thread but
        I
        suspect I'm not alone. =A0= =A0I'm going to try and just summarize the
        issues - mostly for my own = edification but hopefully this may help
        others too. =A0Please let m= e know if I'm off base.

        The thread originally start= ed with a discussion of the assertion
        grant
        type as it's now called in = -09 section 4.1.3 @
        http://tools.ietf.org/html= /draft-ietf-oauth-v2-09#section-4.1.3 and
        there seemed to be two poin= ts of contention specifically about it:

        1) Should returning a refre= sh token be allowed? =A0=A0Currently the
        text
        in that section says, "= ;The authorization server SHOULD NOT issue a
        refresh token." =A0=A0= Some folks feel that is sufficient but some feel
        it
        should be a MUST NOT.

        2) Should client authentica= tion be required/optional/forbidden when
        requesting an access token = via an assertion grant type. =A0=A0The text
        in
        -09 makes it sound like it = might be mandatory (because of text in
        http://tools.ietf.org/html/dra= ft-ietf-oauth-v2-09#section-4
        maybe?).
        No one thinks mandatory is = a good idea. =A0Eran indicated that the
        intent was for it to be opt= ional and -10 would reflect that. =A0=A0Some
        people feel that client aut= hentication in the assertion grant type
        is
        necessary/confusing and sho= uld explicitly forbidden rather than
        just
        optional.


        More recently the thread ha= s turned to a discussion of client
        authentication and if/how t= he spec should allow for clients to
        authenticate themselves to = the token endpoint using means other
        than
        the client_secret. =A0Secti= on 2
        http://tools.ietf.org/html/dra= ft-ietf-oauth-v2-09#section-2 leaves
        the
        means of client authenticat= ion pretty open, it seems, but then only
        provides normative guidance= for "Basic Client Credentials" in
        section
        2.1 http://tools.ietf.org/ht= ml/draft-ietf-oauth-v2-09#section-2.1

        I believe that Yaron is aug= uring for a something that might become
        a
        section 2.2 called "As= sertion Client Credentials." =A0But this is not
        related to the assertion gr= ant type (especially if client
        authentication is forbidden= from that grant type request).


        How's my characterization o= f this? =A0If it's accurate, I think
        there's
        value in realizing that the= re are two pretty distinct issues in
        question here and I feel li= ke some of the conversations around
        "assertions" have= been confused by mixing the two. =A0I'm not, at
        this
        point, arguing the merits o= f anything - just first trying to make
        sure
        we are arguing about the sa= me things.

        -Brian Campbell




--_000_C85CAD5E80E5cmortimoresalesforcecom_-- From balfanz@google.com Fri Jul 9 13:39:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA04B3A68B1 for ; Fri, 9 Jul 2010 13:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1TxSuAfURpV for ; Fri, 9 Jul 2010 13:38:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8DDEA3A681D for ; Fri, 9 Jul 2010 13:38:59 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o69Kd46b001554 for ; Fri, 9 Jul 2010 13:39:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278707944; bh=k/kkyNsRPo8Yqul61Xs5ZEvjg0Y=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=d6pITLVv+eAyZxX+gL/a0P4IBzIYopFIbydeo/Yvo7rf//ti8TssC4G6U0C1GIU/m 0x9lkU/dlx8xEqi04SvPw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=a330eXnaE5lNuyd67efjfciFMGBvEMn47plcGa7rIwXb6r5sTe0DijZ7C5abr4fCo h0Hy5XP8OAFJiz/6v18tg== Received: from iwn9 (iwn9.prod.google.com [10.241.68.73]) by wpaz33.hot.corp.google.com with ESMTP id o69Kd1ql031258 for ; Fri, 9 Jul 2010 13:39:03 -0700 Received: by iwn9 with SMTP id 9so2311768iwn.9 for ; Fri, 09 Jul 2010 13:39:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.35.70 with SMTP id o6mr10218138ibd.92.1278707941310; Fri, 09 Jul 2010 13:39:01 -0700 (PDT) Received: by 10.231.130.9 with HTTP; Fri, 9 Jul 2010 13:39:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Jul 2010 13:39:01 -0700 Message-ID: From: Dirk Balfanz To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000325551a129d1321048afa6432 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 20:39:01 -0000 --000325551a129d1321048afa6432 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 7, 2010 at 7:49 PM, Eran Hammer-Lahav wrote: > Can we get an updated document based on the feedback received? > Sure - I just got back from my vacation. I'll read through the thread and update the docs. Cheers, Dirk. > EHL > > > On 6/21/10 12:04 AM, "Dirk Balfanz" wrote: > > Hi guys, > > > I think I owe the list a proposal for signatures. > > I wrote something down that liberally borrows ideas from Magic Signatures < > http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html> > , SWT , and (even the name > from) JSON Web Tokens < > https://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0#> > . > > > Here is a short document (called "JSON Tokens") that just explains how to > sign something and verify the signature: > > http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > > Here is an extension of JSON Tokens that can be used for signed OAuth > tokens: < > http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU> > > > http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU > > Here is a different extension of JSON Tokens that can be used for 2-legged > flows. The idea is that this could be used as a drop-in replacement for SAML > assertions in the OAuth2 assertion flow: > > http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc > > I also have started to write some code < > http://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/net/oauth/signatures> > to implement this as a proof-of-concept. > > Thoughts? Comments? > > Dirk. > > > --000325551a129d1321048afa6432 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 7, 2010 at 7:49 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrot= e:
Can we get an updated document based on the feedback received?

Sure - I just got back fr= om my vacation. I'll read through the thread and update the docs.

Cheers,=A0

Dirk.=A0
=

=A0
EHL


On 6/21/10 12:04 AM, "Dirk Balfanz" <balfanz@google.com> wrote:

</> =A0</> Hi guys,=A0


I think I owe the list a proposal for signatures.
 I wrote something down that=A0liberally=A0borrows ideas from Magic = Signatures <http://salmon-protocol.goog= lecode.com/svn/trunk/draft-panzer-magicsig-00.html> , SWT <http:/= /groups.google.com/group/WRAP-WG/files> , and (even the name from) J= SON Web Tokens <https://groups.google.= com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0#> .=A0


Here is a short document (called "JSON Tokens") that just explain= s how to sign something and verify the signature:
http://docs.google.com/document/pu= b?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4

Here is an extension of JSON Tokens that can be used for signed OAuth token= s: <http://docs.google.com/docu= ment/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU>
http://docs.google.com/document/pu= b?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU

Here is a different extension of JSON Tokens that can be used for 2= -legged flows. The idea is that this could be used as a drop-in replacement= for SAML assertions in the OAuth2 assertion flow:
http://docs.google.com/document/pu= b?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc

I also have started to write some code <http://code.google.com/p/jsontoken/source/browse/#svn/tru= nk/src/main/java/net/oauth/signatures> =A0to implement this as a pro= of-of-concept.=A0

Thoughts? Comments?

Dirk.



--000325551a129d1321048afa6432-- From eran@hueniverse.com Fri Jul 9 16:24:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FFE63A65A6 for ; Fri, 9 Jul 2010 16:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.313, 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 x7qkh8WviAN5 for ; Fri, 9 Jul 2010 16:23:58 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 3D7753A685A for ; Fri, 9 Jul 2010 16:23:58 -0700 (PDT) Received: (qmail 29838 invoked from network); 9 Jul 2010 23:24:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Jul 2010 23:24:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 9 Jul 2010 16:24:02 -0700 From: Eran Hammer-Lahav To: Dirk Balfanz Date: Fri, 9 Jul 2010 16:23:01 -0700 Thread-Topic: [OAUTH-WG] proposal for signatures Thread-Index: AcsfvdA1kH+weIDjQXWfkoEXqg1KKA== Message-ID: <1AD6FC61-6EA8-4409-A8E8-2B5CE059353F@hueniverse.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_1AD6FC616EA84409A8E82B5CE059353Fhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 23:24:00 -0000 --_000_1AD6FC616EA84409A8E82B5CE059353Fhueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb24ndCB1bmRlcnN0YW5kLiBZb3UgYXJlIEFsbG93ZWQgdGltZSBvZmYgc3BlYyB3b3JrIGR1 cmluZyB2YWNhdGlvbj8gSG1tLiAoLToNCg0KRUhMDQoNCg0KDQpPbiBKdWwgOSwgMjAxMCwgYXQg MTY6MzksIERpcmsgQmFsZmFueiA8YmFsZmFuekBnb29nbGUuY29tPG1haWx0bzpiYWxmYW56QGdv b2dsZS5jb20+PiB3cm90ZToNCg0KT24gV2VkLCBKdWwgNywgMjAxMCBhdCA3OjQ5IFBNLCBFcmFu IEhhbW1lci1MYWhhdiA8PG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPmVyYW5AaHVlbml2ZXJz ZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+PiB3cm90ZToNCkNhbiB3ZSBnZXQgYW4g dXBkYXRlZCBkb2N1bWVudCBiYXNlZCBvbiB0aGUgZmVlZGJhY2sgcmVjZWl2ZWQ/DQoNClN1cmUg LSBJIGp1c3QgZ290IGJhY2sgZnJvbSBteSB2YWNhdGlvbi4gSSdsbCByZWFkIHRocm91Z2ggdGhl IHRocmVhZCBhbmQgdXBkYXRlIHRoZSBkb2NzLg0KDQpDaGVlcnMsDQoNCkRpcmsuDQoNCg0KDQpF SEwNCg0KDQpPbiA2LzIxLzEwIDEyOjA0IEFNLCAiRGlyayBCYWxmYW56IiA8PGh0dHA6Ly9iYWxm YW56QGdvb2dsZS5jb20+YmFsZmFuekBnb29nbGUuY29tPG1haWx0bzpiYWxmYW56QGdvb2dsZS5j b20+PiB3cm90ZToNCg0KPC8+ICA8Lz4gSGkgZ3V5cywNCg0KDQpJIHRoaW5rIEkgb3dlIHRoZSBs aXN0IGEgcHJvcG9zYWwgZm9yIHNpZ25hdHVyZXMuDQoNCkkgd3JvdGUgc29tZXRoaW5nIGRvd24g dGhhdCBsaWJlcmFsbHkgYm9ycm93cyBpZGVhcyBmcm9tIE1hZ2ljIFNpZ25hdHVyZXMgPDxodHRw Oi8vc2FsbW9uLXByb3RvY29sLmdvb2dsZWNvZGUuY29tL3N2bi90cnVuay9kcmFmdC1wYW56ZXIt bWFnaWNzaWctMDAuaHRtbD5odHRwOi8vc2FsbW9uLXByb3RvY29sLmdvb2dsZWNvZGUuY29tL3N2 bi90cnVuay9kcmFmdC1wYW56ZXItbWFnaWNzaWctMDAuaHRtbD4gLCBTV1QgPDxodHRwOi8vZ3Jv dXBzLmdvb2dsZS5jb20vZ3JvdXAvV1JBUC1XRy9maWxlcz5odHRwOi8vZ3JvdXBzLmdvb2dsZS5j b20vZ3JvdXAvV1JBUC1XRy9maWxlcz4gLCBhbmQgKGV2ZW4gdGhlIG5hbWUgZnJvbSkgSlNPTiBX ZWIgVG9rZW5zIDw8aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9ncm91cC9XUkFQLVdHL2Jyb3dz ZV90aHJlYWQvdGhyZWFkL2E5OTM2OWM0Yjc0ZDRjZDAjPmh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5j b20vZ3JvdXAvV1JBUC1XRy9icm93c2VfdGhyZWFkL3RocmVhZC9hOTkzNjljNGI3NGQ0Y2QwIz4g Lg0KDQoNCkhlcmUgaXMgYSBzaG9ydCBkb2N1bWVudCAoY2FsbGVkICJKU09OIFRva2VucyIpIHRo YXQganVzdCBleHBsYWlucyBob3cgdG8gc2lnbiBzb21ldGhpbmcgYW5kIHZlcmlmeSB0aGUgc2ln bmF0dXJlOg0KPGh0dHA6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvcHViP2lkPTFrdjZPel9I Um5XYTBEYUp4X1NRNVFsa195cXNfN3pOQW03NS1GbUt3Tm80Pmh0dHA6Ly9kb2NzLmdvb2dsZS5j b20vZG9jdW1lbnQvcHViP2lkPTFrdjZPel9IUm5XYTBEYUp4X1NRNVFsa195cXNfN3pOQW03NS1G bUt3Tm80DQoNCkhlcmUgaXMgYW4gZXh0ZW5zaW9uIG9mIEpTT04gVG9rZW5zIHRoYXQgY2FuIGJl IHVzZWQgZm9yIHNpZ25lZCBPQXV0aCB0b2tlbnM6IDw8aHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9k b2N1bWVudC9wdWI/aWQ9MUpVbjNUd2Q5blh3RkRnaS1mVEtsLXVuREdfbmR5b3dUWlc4T1dYOUhP VVU+aHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9wdWI/aWQ9MUpVbjNUd2Q5blh3RkRn aS1mVEtsLXVuREdfbmR5b3dUWlc4T1dYOUhPVVU+DQo8aHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9k b2N1bWVudC9wdWI/aWQ9MUpVbjNUd2Q5blh3RkRnaS1mVEtsLXVuREdfbmR5b3dUWlc4T1dYOUhP VVU+aHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9wdWI/aWQ9MUpVbjNUd2Q5blh3RkRn aS1mVEtsLXVuREdfbmR5b3dUWlc4T1dYOUhPVVUNCg0KSGVyZSBpcyBhIGRpZmZlcmVudCBleHRl bnNpb24gb2YgSlNPTiBUb2tlbnMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgMi1sZWdnZWQgZmxvd3Mu IFRoZSBpZGVhIGlzIHRoYXQgdGhpcyBjb3VsZCBiZSB1c2VkIGFzIGEgZHJvcC1pbiByZXBsYWNl bWVudCBmb3IgU0FNTCBhc3NlcnRpb25zIGluIHRoZSBPQXV0aDIgYXNzZXJ0aW9uIGZsb3c6DQo8 aHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9wdWI/aWQ9MXM0a2pSUzlQMGZyRzB1bGhn UDNIZTAxT05seGVUd2tGUVZfcENvT293emM+aHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVu dC9wdWI/aWQ9MXM0a2pSUzlQMGZyRzB1bGhnUDNIZTAxT05seGVUd2tGUVZfcENvT293emMNCg0K SSBhbHNvIGhhdmUgc3RhcnRlZCB0byB3cml0ZSBzb21lIGNvZGUgPDxodHRwOi8vY29kZS5nb29n bGUuY29tL3AvanNvbnRva2VuL3NvdXJjZS9icm93c2UvI3N2bi90cnVuay9zcmMvbWFpbi9qYXZh L25ldC9vYXV0aC9zaWduYXR1cmVzPmh0dHA6Ly9jb2RlLmdvb2dsZS5jb20vcC9qc29udG9rZW4v c291cmNlL2Jyb3dzZS8jc3ZuL3RydW5rL3NyYy9tYWluL2phdmEvbmV0L29hdXRoL3NpZ25hdHVy ZXM+ICB0byBpbXBsZW1lbnQgdGhpcyBhcyBhIHByb29mLW9mLWNvbmNlcHQuDQoNClRob3VnaHRz PyBDb21tZW50cz8NCg0KRGlyay4NCg0KDQoNCg== --_000_1AD6FC616EA84409A8E82B5CE059353Fhueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5JIGRvbid0IHVuZGVyc3RhbmQuIFlv dSBhcmUgQWxsb3dlZCB0aW1lIG9mZiBzcGVjIHdvcmsgZHVyaW5nIHZhY2F0aW9uPyBIbW0uICgt OjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+RUhMPGJyPjxicj48ZGl2Pjxicj48L2Rpdj48L2Rp dj48ZGl2Pjxicj5PbiBKdWwgOSwgMjAxMCwgYXQgMTY6MzksIERpcmsgQmFsZmFueiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJhbGZhbnpAZ29vZ2xlLmNvbSI+YmFsZmFuekBnb29nbGUuY29tPC9hPiZn dDsgd3JvdGU6PGJyPjxicj48L2Rpdj48ZGl2PjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxkaXY+T24gV2VkLCBKdWwgNywgMjAxMCBhdCA3OjQ5IFBNLCBFcmFuIEhhbW1lci1MYWhhdiA8 c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj48 YSBocmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSI+ZXJhbkBodWVuaXZlcnNlLmNvbTwv YT48L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3Jk ZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4OyI+DQoNCg0KDQoNCjxkaXY+ DQo8Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExcHQiPkNhbiB3ZSBnZXQgYW4gdXBkYXRlZCBkb2N1bWVudCBiYXNl ZCBvbiB0aGUgZmVlZGJhY2sgcmVjZWl2ZWQ/PGJyPjwvc3Bhbj48L2ZvbnQ+PC9kaXY+PC9ibG9j a3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+U3VyZSAtIEkganVzdCBnb3QgYmFjayBmcm9tIG15 IHZhY2F0aW9uLiBJJ2xsIHJlYWQgdGhyb3VnaCB0aGUgdGhyZWFkIGFuZCB1cGRhdGUgdGhlIGRv Y3MuPC9kaXY+DQo8ZGl2Pjxicj48L2Rpdj48ZGl2PkNoZWVycywmbmJzcDs8L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PkRpcmsuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl ZnQ6MWV4OyI+PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFy aWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPg0KRUhMPGJyPg0KPGJyPg0KPGJyPg0K T24gNi8yMS8xMCAxMjowNCBBTSwgIkRpcmsgQmFsZmFueiIgJmx0OzxhIGhyZWY9Imh0dHA6Ly9i YWxmYW56QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48YSBocmVmPSJtYWlsdG86YmFsZmFu ekBnb29nbGUuY29tIj5iYWxmYW56QGdvb2dsZS5jb208L2E+PC9hPiZndDsgd3JvdGU6PGJyPg0K PGJyPg0KPC9zcGFuPjwvZm9udD48YmxvY2txdW90ZT48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJk YW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPiAmbHQ7 LyZndDsgJm5ic3A7Jmx0Oy8mZ3Q7IEhpIGd1eXMsJm5ic3A7PGRpdiBjbGFzcz0iaW0iPjxicj4N Cjxicj4NCkkgdGhpbmsgSSBvd2UgdGhlIGxpc3QgYSBwcm9wb3NhbCBmb3Igc2lnbmF0dXJlcy48 YnI+DQo8L2Rpdj48L3NwYW4+PC9mb250PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGZv bnQgZmFjZT0iQXJpYWwiPjxicj4NCjwvZm9udD48L3NwYW4+PGZvbnQgZmFjZT0iQXJpYWwiPjxm b250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdCI+SSB3cm90ZSBzb21ldGhp bmcgZG93biB0aGF0Jm5ic3A7bGliZXJhbGx5Jm5ic3A7Ym9ycm93cyBpZGVhcyBmcm9tIE1hZ2lj IFNpZ25hdHVyZXMgJmx0OzxhIGhyZWY9Imh0dHA6Ly9zYWxtb24tcHJvdG9jb2wuZ29vZ2xlY29k ZS5jb20vc3ZuL3RydW5rL2RyYWZ0LXBhbnplci1tYWdpY3NpZy0wMC5odG1sIiB0YXJnZXQ9Il9i bGFuayI+PGEgaHJlZj0iaHR0cDovL3NhbG1vbi1wcm90b2NvbC5nb29nbGVjb2RlLmNvbS9zdm4v dHJ1bmsvZHJhZnQtcGFuemVyLW1hZ2ljc2lnLTAwLmh0bWwiPmh0dHA6Ly9zYWxtb24tcHJvdG9j b2wuZ29vZ2xlY29kZS5jb20vc3ZuL3RydW5rL2RyYWZ0LXBhbnplci1tYWdpY3NpZy0wMC5odG1s PC9hPjwvYT4mZ3Q7ICwgU1dUICZsdDs8YSBocmVmPSJodHRwOi8vZ3JvdXBzLmdvb2dsZS5jb20v Z3JvdXAvV1JBUC1XRy9maWxlcyIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9Imh0dHA6Ly9ncm91 cHMuZ29vZ2xlLmNvbS9ncm91cC9XUkFQLVdHL2ZpbGVzIj5odHRwOi8vZ3JvdXBzLmdvb2dsZS5j b20vZ3JvdXAvV1JBUC1XRy9maWxlczwvYT48L2E+Jmd0OyAsIGFuZCAoZXZlbiB0aGUgbmFtZSBm cm9tKSBKU09OIFdlYiBUb2tlbnMgJmx0OzxhIGhyZWY9Imh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5j b20vZ3JvdXAvV1JBUC1XRy9icm93c2VfdGhyZWFkL3RocmVhZC9hOTkzNjljNGI3NGQ0Y2QwIyIg dGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9Imh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20vZ3JvdXAv V1JBUC1XRy9icm93c2VfdGhyZWFkL3RocmVhZC9hOTkzNjljNGI3NGQ0Y2QwIyI+aHR0cHM6Ly9n cm91cHMuZ29vZ2xlLmNvbS9ncm91cC9XUkFQLVdHL2Jyb3dzZV90aHJlYWQvdGhyZWFkL2E5OTM2 OWM0Yjc0ZDRjZDAjPC9hPjwvYT4mZ3Q7IC4mbmJzcDs8ZGl2IGNsYXNzPSJpbSI+DQo8YnI+DQo8 YnI+DQpIZXJlIGlzIGEgc2hvcnQgZG9jdW1lbnQgKGNhbGxlZCAiSlNPTiBUb2tlbnMiKSB0aGF0 IGp1c3QgZXhwbGFpbnMgaG93IHRvIHNpZ24gc29tZXRoaW5nIGFuZCB2ZXJpZnkgdGhlIHNpZ25h dHVyZTo8YnI+DQo8YSBocmVmPSJodHRwOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L3B1Yj9p ZD0xa3Y2T3pfSFJuV2EwRGFKeF9TUTVRbGtfeXFzXzd6TkFtNzUtRm1Ld05vNCIgdGFyZ2V0PSJf YmxhbmsiPjxhIGhyZWY9Imh0dHA6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvcHViP2lkPTFr djZPel9IUm5XYTBEYUp4X1NRNVFsa195cXNfN3pOQW03NS1GbUt3Tm80Ij5odHRwOi8vZG9jcy5n b29nbGUuY29tL2RvY3VtZW50L3B1Yj9pZD0xa3Y2T3pfSFJuV2EwRGFKeF9TUTVRbGtfeXFzXzd6 TkFtNzUtRm1Ld05vNDwvYT48L2E+PGJyPg0KPGJyPg0KSGVyZSBpcyBhbiBleHRlbnNpb24gb2Yg SlNPTiBUb2tlbnMgdGhhdCBjYW4gYmUgdXNlZCBmb3Igc2lnbmVkIE9BdXRoIHRva2VuczogJmx0 OzxhIGhyZWY9Imh0dHA6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvcHViP2lkPTFKVW4zVHdk OW5Yd0ZEZ2ktZlRLbC11bkRHX25keW93VFpXOE9XWDlIT1VVIiB0YXJnZXQ9Il9ibGFuayI+PGEg aHJlZj0iaHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9wdWI/aWQ9MUpVbjNUd2Q5blh3 RkRnaS1mVEtsLXVuREdfbmR5b3dUWlc4T1dYOUhPVVUiPmh0dHA6Ly9kb2NzLmdvb2dsZS5jb20v ZG9jdW1lbnQvcHViP2lkPTFKVW4zVHdkOW5Yd0ZEZ2ktZlRLbC11bkRHX25keW93VFpXOE9XWDlI T1VVPC9hPjwvYT4mZ3Q7IDxicj4NCg0KPGEgaHJlZj0iaHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9k b2N1bWVudC9wdWI/aWQ9MUpVbjNUd2Q5blh3RkRnaS1mVEtsLXVuREdfbmR5b3dUWlc4T1dYOUhP VVUiIHRhcmdldD0iX2JsYW5rIj48YSBocmVmPSJodHRwOi8vZG9jcy5nb29nbGUuY29tL2RvY3Vt ZW50L3B1Yj9pZD0xSlVuM1R3ZDluWHdGRGdpLWZUS2wtdW5ER19uZHlvd1RaVzhPV1g5SE9VVSI+ aHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9wdWI/aWQ9MUpVbjNUd2Q5blh3RkRnaS1m VEtsLXVuREdfbmR5b3dUWlc4T1dYOUhPVVU8L2E+PC9hPjxicj4NCjwvZGl2Pjwvc3Bhbj48L2Zv bnQ+PC9mb250PjxkaXYgY2xhc3M9ImltIj48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBI ZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bh bj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiI+PGZvbnQgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTBwdCI+SGVyZSBpcyBhIGRpZmZlcmVudCBleHRlbnNpb24gb2YgSlNPTiBUb2tl bnMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgMi1sZWdnZWQgZmxvd3MuIFRoZSBpZGVhIGlzIHRoYXQg dGhpcyBjb3VsZCBiZSB1c2VkIGFzIGEgZHJvcC1pbiByZXBsYWNlbWVudCBmb3IgU0FNTCBhc3Nl cnRpb25zIGluIHRoZSBPQXV0aDIgYXNzZXJ0aW9uIGZsb3c6PGJyPg0KDQo8YSBocmVmPSJodHRw Oi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L3B1Yj9pZD0xczRralJTOVAwZnJHMHVsaGdQM0hl MDFPTmx4ZVR3a0ZRVl9wQ29Pb3d6YyIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9Imh0dHA6Ly9k b2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvcHViP2lkPTFzNGtqUlM5UDBmckcwdWxoZ1AzSGUwMU9O bHhlVHdrRlFWX3BDb09vd3pjIj5odHRwOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L3B1Yj9p ZD0xczRralJTOVAwZnJHMHVsaGdQM0hlMDFPTmx4ZVR3a0ZRVl9wQ29Pb3d6YzwvYT48L2E+PGJy Pg0KPC9zcGFuPjwvZm9udD48L2ZvbnQ+PC9kaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFu YSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQpJ IGFsc28gaGF2ZSBzdGFydGVkIHRvIHdyaXRlIHNvbWUgY29kZSAmbHQ7PGEgaHJlZj0iaHR0cDov L2NvZGUuZ29vZ2xlLmNvbS9wL2pzb250b2tlbi9zb3VyY2UvYnJvd3NlLyNzdm4vdHJ1bmsvc3Jj L21haW4vamF2YS9uZXQvb2F1dGgvc2lnbmF0dXJlcyIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9 Imh0dHA6Ly9jb2RlLmdvb2dsZS5jb20vcC9qc29udG9rZW4vc291cmNlL2Jyb3dzZS8jc3ZuL3Ry dW5rL3NyYy9tYWluL2phdmEvbmV0L29hdXRoL3NpZ25hdHVyZXMiPmh0dHA6Ly9jb2RlLmdvb2ds ZS5jb20vcC9qc29udG9rZW4vc291cmNlL2Jyb3dzZS8jc3ZuL3RydW5rL3NyYy9tYWluL2phdmEv bmV0L29hdXRoL3NpZ25hdHVyZXM8L2E+PC9hPiZndDsgJm5ic3A7dG8gaW1wbGVtZW50IHRoaXMg YXMgYSBwcm9vZi1vZi1jb25jZXB0LiZuYnNwOzxicj4NCg0KPGJyPg0KVGhvdWdodHM/IENvbW1l bnRzPzxicj4NCjxicj4NCkRpcmsuPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjwvZm9udD48L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCg0KDQo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPg0KPC9kaXY+PC9i bG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --_000_1AD6FC616EA84409A8E82B5CE059353Fhueniversecom_-- From dick.hardt@gmail.com Fri Jul 9 16:45: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 345283A6872 for ; Fri, 9 Jul 2010 16:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZDoToZKqriz for ; Fri, 9 Jul 2010 16:45:22 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id F15053A68FA for ; Fri, 9 Jul 2010 16:45:21 -0700 (PDT) Received: by pwj1 with SMTP id 1so1298712pwj.31 for ; Fri, 09 Jul 2010 16:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=fTdZHagijs00x//zyVDlmChiPuzggijovHOVNkAmDNA=; b=srjHJd/G7iWeztm/L7+fUuKrb8K9XWDGXG5wcC7P+NmpPVmRixBkXzlBpHho/ShXin gzB49uDc0x3gvNHulwZECgxzzOJX9iUXF2dNkVcMIliU8uMVeJihLKafHbQw2Tz9Jb4c GHrpACxL0AAN8d83lpDJfTpLHO2aeXQvZZRBg= 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=PVr9LT0ECN6QTYS1VDJHmHseItjGFsYF8jiEN/Zd8Jb9RRI1uGIm4phgj1BcbszOhr VpPHEKWeLYBwe8XSk71/c3AnDOrDi25ddzqnI8X0he9gcL+ej3sguclMCJ/5t5+eZIhe D+u/XFsuEoQnjG/FwMuOpXVd9GdOT/OvOixII= Received: by 10.114.156.8 with SMTP id d8mr12145271wae.13.1278719124691; Fri, 09 Jul 2010 16:45:24 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id d35sm21656655waa.21.2010.07.09.16.45.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Jul 2010 16:45:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-193--235789493 From: Dick Hardt In-Reply-To: Date: Fri, 9 Jul 2010 16:45:21 -0700 Message-Id: <30A5879D-7476-468B-8280-72691D7FE73B@gmail.com> References: To: Dirk Balfanz X-Mailer: Apple Mail (2.1078) Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 23:45:24 -0000 --Apple-Mail-193--235789493 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Dirk Responding to this now that you are back. From: = http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html (which is the whitepaper talking contrasting "encrypt-then-sign" and = "sign-then-encrypt") The simple solution seems to be to include both sender and recipient in = the plain text. At first glance your proposal of: encrypted_token =3D encryption(JSON_Token) || "." || envelope=20 envelope =3D base64(JSON(everything you need to know to = decrypt)) This seems to work - I am unsure where the signature is. Ideally you = encrypt the binary of the signature rather than the base64url version.=20= Ideally the JSON_Token would also have an envelope so that the same code = could look at the envelope to decide what to do with it regardless of if = it was encrypted or not.=20 Perhaps the first string would always be an envelope that would contain = everything to either decrypt or verify the payload? -- Dick On 2010-06-22, at 10:57 PM, Dirk Balfanz wrote: > Hi Dick,=20 >=20 > interesting point about encrypted payloads.=20 >=20 > People more cryptographically-inclined than me might want to chime in, = but I do seem to remember that there is a "correct" choice among the = "encrypt-then-sign" and "sign-then-encrypt" alternatives. A quick search = seems to suggest that the latter is what you want: = https://www.pluralsight-training.net/community/blogs/craig/archive/2003/06= /30/837.aspx.=20 >=20 > So I would suggest that encrypted payloads are implemented as an = encryption of a JSON Token, as in: >=20 > encrypted_token =3D encryption(JSON_Token) || "." || envelope=20 > envelope =3D base64(JSON(everything you need to know to decrypt)) >=20 > What do you think? >=20 > Dirk. >=20 >=20 > On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt = wrote: > Thanks for writing this up Dirk. >=20 > I would suggest that the token be: >=20 > payload "." envelope "." signature >=20 > This enables the payload to be encrypted and independent from the = envelope.=20 >=20 > Token signing, verification, encryption and decryption code can then = be generic and not understand the payload of the token.=20 >=20 > I would only include issuer, key_id and alg in the envelope.=20 >=20 > Audience, scope, nonce, and validation time information etc. would be = in the payload. >=20 > -- Dick >=20 > On 2010-06-21, at 12:04 AM, Dirk Balfanz wrote: >=20 >> Hi guys,=20 >>=20 >> I think I owe the list a proposal for signatures. >>=20 >> I wrote something down that liberally borrows ideas from Magic = Signatures, SWT, and (even the name from) JSON Web Tokens.=20 >>=20 >> Here is a short document (called "JSON Tokens") that just explains = how to sign something and verify the signature: >> = http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNA= m75-FmKwNo4 >>=20 >> Here is an extension of JSON Tokens that can be used for signed OAuth = tokens: >> = http://docs.google.com/document/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowT= ZW8OWX9HOUU >>=20 >> Here is a different extension of JSON Tokens that can be used for = 2-legged flows. The idea is that this could be used as a drop-in = replacement for SAML assertions in the OAuth2 assertion flow: >> = http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTwkF= QV_pCoOowzc >>=20 >> I also have started to write some code to implement this as a = proof-of-concept.=20 >>=20 >> Thoughts? Comments? >>=20 >> Dirk. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail-193--235789493 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Dirk

Responding to this now that you are = back.

From:

(which is the whitepaper talking contrasting "encrypt-then-sign" = and "sign-then-encrypt")

The simple solution = seems to be to include both sender and recipient in the plain = text.

At first glance your proposal = of:

encrypted_token =3D = encryption(JSON_Token) || "." || envelope 
envelope = =3D base64(JSON(everything you need to know to = decrypt))

This seems to work - I am = unsure where the signature is. Ideally you encrypt the binary of the = signature rather than the base64url = version. 

Ideally the JSON_Token would = also have an envelope so that the same code could look at the envelope = to decide what to do with it regardless of if it was encrypted or = not. 

Perhaps the first string would = always be an envelope that would contain everything to either decrypt or = verify the payload?

-- = Dick

On 2010-06-22, at 10:57 PM, Dirk Balfanz = wrote:

Hi Dick, 

interesting point about = encrypted payloads. 

People more = cryptographically-inclined than me might want to chime in, but I do seem = to remember that there is a "correct" choice among the = "encrypt-then-sign" and "sign-then-encrypt" alternatives. A quick search = seems to suggest that the latter is what you want: https://www.pluralsight-training.net/community/blogs= /craig/archive/2003/06/30/837.aspx. 

So I would suggest that encrypted payloads are = implemented as an encryption of a JSON Token, as = in:

encrypted_token =3D encryption(JSON_Token) = || "." || envelope 
envelope =3D base64(JSON(everything you need to know to = decrypt))

What do you = think?

Dirk.


On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt <dick.hardt@gmail.com> = wrote:
Thanks for writing this up = Dirk.

I would suggest that the token be:

payload = "." envelope "." signature

This enables the = payload to be encrypted and independent from the = envelope. 

Token signing, verification, encryption and decryption = code can then be generic and not understand the payload of the = token. 

I would only include issuer, = key_id and alg in the envelope. 

Audience, scope, nonce, and validation time = information etc. would be in the payload.

-- = Dick

On = 2010-06-21, at 12:04 AM, Dirk Balfanz wrote:

Hi guys, 

I think I owe the list a proposal = for signatures.

I wrote something = down that liberally = borrows ideas from = Magic Signatures, SWT, and (even the name from) JSON Web = Tokens. 

Here is a short = document (called "JSON Tokens") that just explains how to sign something = and verify the signature:
http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0Da= Jx_SQ5Qlk_yqs_7zNAm75-FmKwNo4

Here is an extension = of JSON Tokens that can be used for signed OAuth tokens:

Here is a different = extension of JSON Tokens that can be used for 2-legged flows. The idea = is that this could be used as a drop-in replacement for SAML assertions = in the OAuth2 assertion flow:
http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0u= lhgP3He01ONlxeTwkFQV_pCoOowzc

I also have started to write some code to = implement this as a proof-of-concept. 

Thoughts? = Comments?

Dirk.

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



= --Apple-Mail-193--235789493-- From eran@hueniverse.com Sat Jul 10 07:31: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 41EF83A69F1 for ; Sat, 10 Jul 2010 07:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=-1.002, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7RR4tlfrCzE for ; Sat, 10 Jul 2010 07:31:07 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 3470B3A6818 for ; Sat, 10 Jul 2010 07:31:06 -0700 (PDT) Received: (qmail 2794 invoked from network); 10 Jul 2010 14:31:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Jul 2010 14:31:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 10 Jul 2010 07:31:10 -0700 From: Eran Hammer-Lahav To: Eran Hammer-Lahav , OAuth WG Date: Sat, 10 Jul 2010 07:31:09 -0700 Thread-Topic: [OAUTH-WG] Draft -09 Thread-Index: AcsXVmRrsO6Hfs/LQgKeY82EBJQ0KwAA86rwAjiVpZo= Message-ID: In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85DD23D36F80eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft -09 X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jul 2010 14:31:13 -0000 --_000_C85DD23D36F80eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have any more feedback for -09 please submit today. I plan to publis= h -10 by Monday which will be the last draft for 4 weeks, and hopefully a d= raft we can declare as stable for implementation. So if there is anything y= ou really want to see changed, today is your last chance for a while. EHL On 6/29/10 12:11 AM, "Eran Hammer-Lahav" wrote: For editorial feedback, I am going to try something new and use SharedCopy.= com (no install required). Try it out at: http://r6.sharedcopy.com/6bnqq8v If this doesn't work, I'll let people know and cancel it. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, June 28, 2010 11:56 PM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Draft -09 Draft -09 is now posted. Main changes include: o Fixed typos, editorial changes. Thanks to Dick for his useful feedback. o Added token expiration example. o Added scope parameter to end-user authorization endpoint response and WW= W-Authenticate header. o Added note about parameters with empty values (same as omitted). o Changed parameter values to use '-' instead of '_'. Parameter names sti= ll use '_'. o Changed authorization endpoint client type to response type with values:= code, token, or both. o Complete cleanup of error codes. Added support for error description an= d URI. o Add initial extensibility support. Draft -09 represents what I consider to be the first feature complete propo= sal. While it still needs much work, it has notes for open issues and missi= ng parts. I plan to give people 2 weeks to review and provide extensive fee= dback, and will post one more draft before the 7/12 cutoff date for the mee= ting. My goal is to collect enough feedback to declare the next draft (-10) stabl= e for wider implementation. If you were waiting for a stable draft to study= and provide extensive feedback, this is the draft! When giving feedback pr= etend this is your last chance to making a significant contribution or chan= ges to the core specification. Please submit feedback by 7/9. When submitting feedback please start a new thread for each item. Editorial= commentary can be collected in one post (and please send to the list, even= if it is minor, because I tend to get the same typo correction many times)= . Thanks, EHL --_000_C85DD23D36F80eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Draft -09 If you have any more feedback for –09 please submit today. I pl= an to publish –10 by Monday which will be the last draft for 4 weeks,= and hopefully a draft we can declare as stable for implementation. So if t= here is anything you really want to see changed, today is your last chance = for a while.

EHL


On 6/29/10 12:11 AM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

For editorial feedb= ack, I am going to try something new and use SharedCopy.com (no install req= uired).
 
Try it out at: http://r6.share= dcopy.com/6bnqq8v
 
If this doesn’t work, I’ll let people know and cancel it.
 
EHL
 
 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of <= /B>Eran Hammer-Lahav
Sent: Monday, June 28, 2010 11:56 PM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Draft -09
Draft -09 is now posted. Main changes include:
 

--_000_C85DD23D36F80eranhueniversecom_-- From torsten@lodderstedt.net Sat Jul 10 10:08: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 5093C3A67CF for ; Sat, 10 Jul 2010 10:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4Eh-weMFu7k for ; Sat, 10 Jul 2010 10:07:52 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by core3.amsl.com (Postfix) with ESMTP id ACCE43A6A2F for ; Sat, 10 Jul 2010 10:07:47 -0700 (PDT) Received: from p4fff30bf.dip.t-dialin.net ([79.255.48.191] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OXdWp-0004AS-1h; Sat, 10 Jul 2010 19:07:51 +0200 Message-ID: <4C38A8DA.4010105@lodderstedt.net> Date: Sat, 10 Jul 2010 19:07:38 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> <4C1108C4.9040501@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7473@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7473@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/mixed; boundary="------------000208050506090706060308" X-Df-Sender: 141509 Subject: [OAUTH-WG] I-D: multiple access tokens X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jul 2010 17:08:06 -0000 This is a multi-part message in MIME format. --------------000208050506090706060308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I just finished the first version of my I-D on "multiple access tokens" and would like to initiate a discussion whether the WG sees this as a potential WG item. Due to the pre-meeting cutoff date for submitting new drafts, I cannot submit it to the IETF site now. Since I don't want to lose weeks, I attached the document to this mail. I will upload the document to the IETF site after 2010-07-26. I would appreciate any feedback on the I-D. regards, Torsten. Am 11.06.2010 01:02, schrieb Eran Hammer-Lahav: > I strongly believe that it should be first presented as an I-D. This is true in general for most proposed changes of this size. It is hard to tell how big of an impact a change like this will have without some actual text. Once proposed, the WG can decide if this is of interest as a WG item. If it is, we discuss the technical details. Then, we can have a chat about editorial work and how to best fit it within the OAuth specifications framework. > > Hope this helps. > > EHL --------------000208050506090706060308 Content-Type: text/html; charset=UTF-8; name="draft-lodderstedt-oauth-multiple-access-tokens.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-lodderstedt-oauth-multiple-access-tokens.html" Multiple access tokens
 TOC 
Open Authentication ProtocolT. Lodderstedt
Internet-DraftDeutsche Telekom AG
Intended status: Standards TrackJuly 10, 2010
Expires: January 11, 2011 


Multiple access tokens
draft-lodderstedt-oauth-multiple-access-tokens-00

Abstract

This document proposes changes to the OAuth v2 specification in order to support the issuance of access tokens, which are valid for particular resource servers and the exchange of a single access grant (end-user authorization code, credentials, assertion, refresh token e.t.c) into multiple resource server-specific access tokens.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on January 11, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1.  Introduction
2.  Service-specific tokens
    2.1.  Definitions
    2.2.  Requesting a service-specific token
    2.3.  Access token response
3.  Multiple-tokens mode
    3.1.  Requesting tokens for multiple services
    3.2.  Access token response
    3.3.  Service usage
    3.4.  Refresh token
4.  Proposed changes
    4.1.  Changes to section 3.
    4.2.  Changes to section 3.1.
    4.3.  Changes to section 4.
    4.4.  Changes to section 4.2.
    4.5.  Changes to section 5.
5.  Acknowledgements
6.  IANA Considerations
7.  Security Considerations
8.  Informative References
§  Author's Address



 TOC 

1.  Introduction

OAuth v2 [draft‑ietf‑oauth‑v2‑09] (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Protocol draft-ietf-oauth-v2-09,” June 2010.) distinguishes the role of resource server and authorization server and that way also enables deployments where a single authorization server is responsible for authorizing access to multiple, independent resource servers.

It may be expected that more and more clients will integrate (or mash-up) several of such services. As an example, one might imagine a communication client integrating e-Mail via IMAP, Voice over IP using the SIP protocol, contacts via SyncML over HTTP, and webstorage access (e.g. for e-Mail attachments) using HTTP/WebDAV. For a particular end-user, the client may discover that all of the end-user's services rely on the same OAuth2-based authorization server because they are provided by the same organization (e.g. an isp or a telco). For reasons of simplicity and user experience, the client may want to acquire access authorization to all services in a single authorization flow or for a single access grant. Another example of multi-service clients are OpenId Connect [openid‑connect] (Recordon, D. and E. Hammer-Lahav, Ed., “OpenId Connect,” May 2010.) clients. They will very likely require access to identity data (user data service) and other user resources as well.

There is currently no way to distinguish resource servers on the protocol level. Clients could use the "scope" parameter to indicate the desired resource server in an authorization request. Theoretically, it is also possible for a client to request authorization for multiple resource servers in a single authorization request. Unfortunately, the current protocol design only allows to issue a single access token per end-user authorization flow. Both restrictions force deployments to issue tokens valid for multiple resources servers, which significantly limits applicability of the OAuth2 protocol and imposes a security threats as well.

  • The need to issue multi-audience tokens imposes a major security threat on end-users. Every resource server receiving such a token can use it to invoke requests on behalf of the end-user on other resource servers this particular token is valid for. The token may even be accidentially exposed to an adversary by way of HTTP referers or log files. The impact of such an incident may be significant (e.g. disclosure of health care data, financial looses) since such tokens are powerful like passwords.
  • For reasons of operational security, authorization servers should use different secrets for signing and encrypting self-contained tokens for different servers. This especially holds, if the resource servers are operated at different locations and by partner organisations. An archetype of this approach is the Kerberos protocol.
  • Different services may, for the same end-user, require different identities attested by an access token. Examples range from network identities, such as fixed-line port, radius session, IMSI, to user identities, product booking instances (e-mail box, MSISDN), customer identities, contract numbers or federated identities. Such identities should be asserted by different tokens.
  • Different services may require different if not disjunct attributes and permissions associated with the attested identities. Keeping this data separated in different tokens promotes data privacy (cf. [laws‑of‑identity] (Cameron, K., “The Laws of Identity,” May 2005.) , Law 2). Moreover, it is good practice in identity management to issue service-specific identities.
  • Different services may require different token formats (e.g. SWT vs. SAML assertions vs. session handles)

Approaches have been proposed in the working group to overcome the limitation by issuing a single token and acquire service-specific tokens afterwards by using this single token with the refresh or assertion flow. But instead of solving the problem it just transfers it and endangers interoperability.

This internet draft proposes to

  1. Explicitly support the identification of resource servers accepting the same token by a service id,
  2. To allow for the issuance of service-specific tokens, and
  3. To allow multiple service-specific tokens to be issued at once in a single authorization flow or based on a single access grant.

Every token is valid for exactly one service id. So the relation between resource servers and tokens is transparent to clients.

First, an extension is defined to support different tokens for different services in a multi-service deployment. Second, a further extension is defined in order to allow for the issuance of multiple service-specific access tokens at once. The necessary changes to the OAuth v2 draft are identified afterwards.


 TOC 

2.  Service-specific tokens


 TOC 

2.1.  Definitions

The OAuth core shall support deployments with one authorization server and multiple resource servers, where different servers use different tokens (format, content, signatures/ encryption algorithms, keys).

Resource servers are identified by a services id, that is unique within a particular deployment. Every access token is associated with exactly one service id.

A service id may be any string, e.g. "mail" or "http://mail.example.com". The service id designates a logical service, which may be equivalent to a endpoint URL. It is also possible that the service can be accessed over different channels, e.g. HTTPS, FTP, and IMAP.

[[Note: The relation between service id and sites/endpoints should be worked out when merging this draft with the sites proposal. ]]

The service id of a particular resource server can be obtained by the client either from the server's documentation or by the way of discovery. The following example shows the usage of an additional "service_id" attribute of the WWW-Authenticate header: 

GET /users/meier/inbox/ HTTP/1.1
Host: email.example.com

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Token realm='Example Service' service_id='myservice'

[[Alternative: use the realm value as service id.]]


 TOC 

2.2.  Requesting a service-specific token

In order to request service-specific tokens, a new parameter "service_id" is introduced. It is used in the context of the end-user authorization flow as well as the access token request. The parameter specifies the service id the authorization shall be acquired for.

Note: This parameter is mandatory in multi-service environments.


 TOC 

2.3.  Access token response

The access token issued is valid for the service id specified by the respective request parameter. No further response parameter is needed in order to represent this relation.


 TOC 

3.  Multiple-tokens mode

As an optional feature, authorization servers may support the acquisition of multiple service-specific access tokens from a single access grant.

It is the decision of the client to request multiple tokens at once. The following pre-requistes must be fulfilled:

  • The client must seek authorization for multiple resource servers,
  • At least two of this resource servers must trust the same authorization server [[authz server equivalence should be defined as part of OAuth Discovery]],
  • At least two of these resource servers must have different service ids (Note: multiple-services == multiple-tokens), and
  • The respective authorization server must support the multiple-tokens feature.

Support can be announced by the authorization server using [[OAuth Discovery]]. If an authorization server does not support this feature and a client tries to obtain multiple tokens the request shall be answered with an error response.


 TOC 

3.1.  Requesting tokens for multiple services

It is not sufficient to request tokens for different services just by using the new "service_id" parameter since there might be the need to request server-specific scopes, too. Since scopes are assumed to be resource server specific, there is a need to create a namespace per resource server scope. The service id is used for that purpose.

The service ids and their corresponding scopes are encoded within the request's scope parameter as follows: Scope values are constructed from the service id and the desired resource/permission values by using the service id as prefix and the resource-specific scope enclosed by braces. 

<serviceId>(<scope on resource server>)[, <more resource server scopes>]

So opening and closing braces become delimiters and reserved symbols, which must not be used in the scope (or must be escaped). Empty resource-specific scopes are indicated by ommiting the braces.

To give an example. Assumed there is the scope 

read write delete

for the "email" service, the scope 

read copy

for the "webdav" service and no scope for the "voip" service. The resulting scope parameter would be: 

email(read write delete),webdav(read copy),voip

A client indicates a request for multiple service-specific tokens by setting the parameter service_id to the predefined value 'multiple-services'. If this value is set, the authorization server parses the scope according to the rules given above.

An example request is give below 

   GET /authorize?response_type=code&client_id=s6BhdRkqt3&
     redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&
     scope=email(read+write+delete)%2Cwebdav(read+copy)%2Cvoip HTTP/1.1
   Host: server.example.com

[[Alternative I: generally use a JSON document with an appropriate structure to pass in the required servers, resources and permissions to the authz server]]

[[Alternative II: use the technique proposed by [request‑by‑reference] (Sakimura, N., “Request by Reference ver.1.0 for OAuth 2.0 draft-sakimura-oauth-requrl-00,” June 2010.) , where the request document contains the structure as described in Alternative I.]]


 TOC 

3.2.  Access token response

In multiple-tokens mode, the access token response contains an array of access tokens in the new parameter "access_tokens". The response parameters "access_token", "expires_in", and "scope" are not not used in that case. An example is as follows 

     HTTP/1.1 200 OK
     Content-Type: application/json
     Cache-Control: no-store

     {
       "refresh_token":"8xLOxBtZp8",
       "access_tokens":[
        {
          "access_token":"SlAV32hkKG2",
          "expires_in":3600,
          "service_id":"email"
        },
        {
          "access_token":"SlAV32hkKG3",
          "expires_in":3600,
          "service_id":"webdav"
        },
        {
          "access_token":"SlAV32hkKG4",
          "expires_in":3600,
          "scope":"voip"
        }
       ]
     }

[[Alternative: use the mulitple-tokens response for single token responses, too]]


 TOC 

3.3.  Service usage

Clients select the token for a particular request based on the service id.


 TOC 

3.4.  Refresh token

Refresh tokens issued in multiple-tokens mode represent the access grant on all respective servers (and scopes). Such a refresh token can be used to obtain all access tokens corresponding to the access grant or subsets thereof, which can be specified using the parameters server_id and scope.


 TOC 

4.  Proposed changes

This section list the changes to the protocol specification.


 TOC 

4.1.  Changes to section 3.

Add a new parameter "service_id" and extend definition of the parameter "scope" as follows.

service_id
REQUIRED (for multi-service deployments). Defines the resource server the client seeks access authorization for. A value of "multiple-services" indicates that the client wants to obtain multiple access tokens at once (multiple-tokens mode). In this mode, interpretation of the parameter "scope" differs from single server mode.
scope
OPTIONAL.

Single-token mode: The scope of the access request expressed as a list of space-delimited strings. The value of the "scope" parameter with regard to a certain resource server is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope.

Multiple-tokens mode: A comma-separated list of service-specific scopes. Every entry starts with the server id followed by braces, which enclose the actual scope. For every scope, the definition of the single-token mode holds.


 TOC 

4.2.  Changes to section 3.1.

In multiple-tokens mode, the authorization response shall be returned as JSON document according to the definition of the access token response. The parameter access_token, expires_in, and scope are omited.

If the response type is "token" or "code-and-token", the authorization server applies a URL-safe base64 encoding to the JSON document and adds the resulting string as the redirection URI fragment. This is illustrated in the following example: 

    HTTP/1.1 302 Found
    Location: http://example.com/rd#IHsNCiAgICAgICAiYWNjZXNzX3RvaiU2...

 TOC 

4.3.  Changes to section 4.

Add a new parameter "service_id" and extend definition of the parameter "scope" as given in Section 4.1 (Changes to section 3.).


 TOC 

4.4.  Changes to section 4.2.

The definition shall be extended as follows:

access_token
REQUIRED (used in single-token mode only). The access token issued by the authorization server.
expires_in
OPTIONAL (used in single-token mode only). The duration in seconds of the access token lifetime. For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated by the authorization server.
scope
OPTIONAL (used in single-token mode only). The scope of the access token as a list of space- delimited strings. The value of the "scope" parameter is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope.
access_tokens
REQUIRED (used in multiple-tokens mode only). List of access tokens issued by the authorization server along with their respective service id, expiration and scope.
refresh_token
OPTIONAL. The refresh token used to obtain new access tokens using the same end-user access grant as described in Section 4.1.4.


 TOC 

4.5.  Changes to section 5.

Add attribute "service_id" to WWW-Authenticate header definition.


 TOC 

5.  Acknowledgements

I would like to thank Stefanie Dronia, Sebastian Ebling, James H. Manger, Axel Nennker, and Nat Sakimura for their valuable feedback.


 TOC 

6.  IANA Considerations

This memo includes no request to IANA.


 TOC 

7.  Security Considerations

Implementors of JavScript-based clients must not use the "eval" function to instantiate the access token response JSON document. Instead, JSON libraries or native JSON support should be used. This is to prevent code injection into the client by an adversary.


 TOC 

8. Informative References

[draft-ietf-oauth-v2-09] Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Protocol draft-ietf-oauth-v2-09,” June 2010.
[laws-of-identity] Cameron, K., “The Laws of Identity,” May 2005.
[openid-ax-1.0] specs@openid.net, “OpenID Attribute Exchange 1.0 - Final,” December 2007.
[openid-connect] Recordon, D. and E. Hammer-Lahav, Ed., “OpenId Connect,” May 2010.
[request-by-reference] Sakimura, N., “Request by Reference ver.1.0 for OAuth 2.0 draft-sakimura-oauth-requrl-00,” June 2010.

 TOC 

Author's Address

  Dr.-Ing. Torsten Lodderstedt
  Deutsche Telekom AG
Email:  torsten@lodderstedt.net
--------------000208050506090706060308-- From paul.tarjan@facebook.com Sat Jul 10 10:09: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 C2ED33A68A7 for ; Sat, 10 Jul 2010 10:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8reipMz0udb for ; Sat, 10 Jul 2010 10:09:07 -0700 (PDT) Received: from mx-out.facebook.com (outmail014.snc4.facebook.com [66.220.144.146]) by core3.amsl.com (Postfix) with ESMTP id 568C53A680F for ; Sat, 10 Jul 2010 10:09:07 -0700 (PDT) Received: from [10.18.73.185] ([10.18.73.185:52143] helo=mx-out.facebook.com) by mta026.snc4.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id 32/FB-23442-1D6A83C4; Sat, 10 Jul 2010 09:58:57 -0700 Received: from [10.18.255.125] ([10.18.255.125:25404] helo=mail.thefacebook.com) by mta008.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 53/67-10031-1D6A83C4; Sat, 10 Jul 2010 09:58:57 -0700 Received: from SC-MBX04.TheFacebook.com ([169.254.3.47]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Sat, 10 Jul 2010 09:58:56 -0700 From: Paul Tarjan To: Dirk Balfanz Thread-Topic: [OAUTH-WG] proposal for signatures Thread-Index: AcsREBK1USivH/OTSPiixmXBrlWmSwNOAtJ4AGZUZIAAKplqAA== Date: Sat, 10 Jul 2010 16:58:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A73AD3C673FF43F78395BB62C7C03BBEfacebookcom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jul 2010 17:09:08 -0000 --_000_A73AD3C673FF43F78395BB62C7C03BBEfacebookcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgT0F1dGhlcnMsDQoNCkZpcnN0IG9mIGFsbCwgSSB0aGluayBJIHNob3VsZCBpbnRyb2R1Y2Ug bXlzZWxmLiBJIHdvcmsgYXQgRmFjZWJvb2sgb24gdGhlIFBsYXRmb3JtIHRlYW0gKGFueXRoaW5n IG5vdCBmYWNlYm9vay5jb208aHR0cDovL2ZhY2Vib29rLmNvbT4pLiBCZWZvcmUgdGhpcyBJIHdh cyBhdCBZYWhvbyEgZG9pbmcgU2VhcmNoTW9ua2V5IChzZW1hbnRpYyB3ZWIgc3R1ZmYpLiBJJ3Zl IHdyaXR0ZW4gYSBmZXcgT0F1dGggYXBwbGljYXRpb25zIGFuZCBsaWJyYXJpZXMsIGJvdGggYXQg WWFob28gYW5kIGluIG15IHNwYXJlIHRpbWUuDQoNCkZvciBGYWNlYm9vayBhcHBzIHdlJ3JlIGdv aW5nIHRvIHVzZSB5b3VyIHNpZ25hdHVyZSBzY2hlbWUgd2l0aCB0aGUgZm9sbG93aW5nIGNoYW5n ZXM6DQoNCiogdGhlIHNpZ25hdHVyZSBjb21lcyBiZWZvcmUgdGhlIHBheWxvYWQNCiogd2UgdXNl ZCB0aGUga2V5ICdhbGdvcml0aG0nIGluc3RlYWQgb2YgJ2FsZycgYW5kICdleHBpcmVzJyBpbnN0 ZWFkIG9mICdub3RfYmVmb3JlJw0KKiB3ZSBhcmVuJ3Qgc2VuZGluZyBhbnkga2V5cyBleGNlcHQg YWxnb3JpdGhtLCBleHBpcmVzLCBhbmQgb2F1dGhfdG9rZW4gKHNpbmNlIHdlJ3JlIGEgc3BlY2lh bCB1c2UgY2FzZSkNCiogd2UgbmFtZWQgdGhlIHBhcmFtZXRlciBzaWduZWRfcmVxdWVzdCBiZWNh dXNlIGl0IGlzIHRoZSBzaWduZWQgcGFydCBvZiBhIHJlcXVlc3QNCg0KV2Ugd291bGQgbG92ZSBp ZiB5b3UgY291bGQgYWRvcHQgdGhvc2UgY2hhbmdlcy4gVGhlbiB5b3UnZCBoYXZlIGEgcmVhbCB3 b3JsZCBpbXBsZW1lbnRhdGlvbiBvdXQgdGhlIGRvb3IgYWxyZWFkeSA6KSBXZSBwbGFuIG9uIGxh dW5jaGluZyBKdWx5IDIwLg0KDQpQYXVsDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gSnVs IDksIDIwMTAsIGF0IDE6MzkgUE0sICJEaXJrIEJhbGZhbnoiIDxiYWxmYW56QGdvb2dsZS5jb208 bWFpbHRvOmJhbGZhbnpAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpPbiBXZWQsIEp1bCA3LCAyMDEw IGF0IDc6NDkgUE0sIEVyYW4gSGFtbWVyLUxhaGF2IDw8bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5j b20+ZXJhbkBodWVuaXZlcnNlLmNvbTxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+IHdyb3Rl Og0KQ2FuIHdlIGdldCBhbiB1cGRhdGVkIGRvY3VtZW50IGJhc2VkIG9uIHRoZSBmZWVkYmFjayBy ZWNlaXZlZD8NCg0KU3VyZSAtIEkganVzdCBnb3QgYmFjayBmcm9tIG15IHZhY2F0aW9uLiBJJ2xs IHJlYWQgdGhyb3VnaCB0aGUgdGhyZWFkIGFuZCB1cGRhdGUgdGhlIGRvY3MuDQoNCkNoZWVycywN Cg0KRGlyay4NCg0KDQoNCkVITA0KDQoNCk9uIDYvMjEvMTAgMTI6MDQgQU0sICJEaXJrIEJhbGZh bnoiIDw8aHR0cDovL2JhbGZhbnpAZ29vZ2xlLmNvbT5iYWxmYW56QGdvb2dsZS5jb208bWFpbHRv OmJhbGZhbnpAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQo8Lz4gIDwvPiBIaSBndXlzLA0KDQoNCkkg dGhpbmsgSSBvd2UgdGhlIGxpc3QgYSBwcm9wb3NhbCBmb3Igc2lnbmF0dXJlcy4NCg0KSSB3cm90 ZSBzb21ldGhpbmcgZG93biB0aGF0IGxpYmVyYWxseSBib3Jyb3dzIGlkZWFzIGZyb20gTWFnaWMg U2lnbmF0dXJlcyA8PGh0dHA6Ly9zYWxtb24tcHJvdG9jb2wuZ29vZ2xlY29kZS5jb20vc3ZuL3Ry dW5rL2RyYWZ0LXBhbnplci1tYWdpY3NpZy0wMC5odG1sPmh0dHA6Ly9zYWxtb24tcHJvdG9jb2wu Z29vZ2xlY29kZS5jb20vc3ZuL3RydW5rL2RyYWZ0LXBhbnplci1tYWdpY3NpZy0wMC5odG1sPiAs IFNXVCA8PGh0dHA6Ly9ncm91cHMuZ29vZ2xlLmNvbS9ncm91cC9XUkFQLVdHL2ZpbGVzPmh0dHA6 Ly9ncm91cHMuZ29vZ2xlLmNvbS9ncm91cC9XUkFQLVdHL2ZpbGVzPiAsIGFuZCAoZXZlbiB0aGUg bmFtZSBmcm9tKSBKU09OIFdlYiBUb2tlbnMgPDxodHRwczovL2dyb3Vwcy5nb29nbGUuY29tL2dy b3VwL1dSQVAtV0cvYnJvd3NlX3RocmVhZC90aHJlYWQvYTk5MzY5YzRiNzRkNGNkMCM+aHR0cHM6 Ly9ncm91cHMuZ29vZ2xlLmNvbS9ncm91cC9XUkFQLVdHL2Jyb3dzZV90aHJlYWQvdGhyZWFkL2E5 OTM2OWM0Yjc0ZDRjZDAjPiAuDQoNCg0KSGVyZSBpcyBhIHNob3J0IGRvY3VtZW50IChjYWxsZWQg IkpTT04gVG9rZW5zIikgdGhhdCBqdXN0IGV4cGxhaW5zIGhvdyB0byBzaWduIHNvbWV0aGluZyBh bmQgdmVyaWZ5IHRoZSBzaWduYXR1cmU6DQo8aHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVu dC9wdWI/aWQ9MWt2Nk96X0hSbldhMERhSnhfU1E1UWxrX3lxc183ek5BbTc1LUZtS3dObzQ+aHR0 cDovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9wdWI/aWQ9MWt2Nk96X0hSbldhMERhSnhfU1E1 UWxrX3lxc183ek5BbTc1LUZtS3dObzQNCg0KSGVyZSBpcyBhbiBleHRlbnNpb24gb2YgSlNPTiBU b2tlbnMgdGhhdCBjYW4gYmUgdXNlZCBmb3Igc2lnbmVkIE9BdXRoIHRva2VuczogPDxodHRwOi8v ZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L3B1Yj9pZD0xSlVuM1R3ZDluWHdGRGdpLWZUS2wtdW5E R19uZHlvd1RaVzhPV1g5SE9VVT5odHRwOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L3B1Yj9p ZD0xSlVuM1R3ZDluWHdGRGdpLWZUS2wtdW5ER19uZHlvd1RaVzhPV1g5SE9VVT4NCjxodHRwOi8v ZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L3B1Yj9pZD0xSlVuM1R3ZDluWHdGRGdpLWZUS2wtdW5E R19uZHlvd1RaVzhPV1g5SE9VVT5odHRwOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L3B1Yj9p ZD0xSlVuM1R3ZDluWHdGRGdpLWZUS2wtdW5ER19uZHlvd1RaVzhPV1g5SE9VVQ0KDQpIZXJlIGlz IGEgZGlmZmVyZW50IGV4dGVuc2lvbiBvZiBKU09OIFRva2VucyB0aGF0IGNhbiBiZSB1c2VkIGZv ciAyLWxlZ2dlZCBmbG93cy4gVGhlIGlkZWEgaXMgdGhhdCB0aGlzIGNvdWxkIGJlIHVzZWQgYXMg YSBkcm9wLWluIHJlcGxhY2VtZW50IGZvciBTQU1MIGFzc2VydGlvbnMgaW4gdGhlIE9BdXRoMiBh c3NlcnRpb24gZmxvdzoNCjxodHRwOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L3B1Yj9pZD0x czRralJTOVAwZnJHMHVsaGdQM0hlMDFPTmx4ZVR3a0ZRVl9wQ29Pb3d6Yz5odHRwOi8vZG9jcy5n b29nbGUuY29tL2RvY3VtZW50L3B1Yj9pZD0xczRralJTOVAwZnJHMHVsaGdQM0hlMDFPTmx4ZVR3 a0ZRVl9wQ29Pb3d6Yw0KDQpJIGFsc28gaGF2ZSBzdGFydGVkIHRvIHdyaXRlIHNvbWUgY29kZSA8 PGh0dHA6Ly9jb2RlLmdvb2dsZS5jb20vcC9qc29udG9rZW4vc291cmNlL2Jyb3dzZS8jc3ZuL3Ry dW5rL3NyYy9tYWluL2phdmEvbmV0L29hdXRoL3NpZ25hdHVyZXM+aHR0cDovL2NvZGUuZ29vZ2xl LmNvbS9wL2pzb250b2tlbi9zb3VyY2UvYnJvd3NlLyNzdm4vdHJ1bmsvc3JjL21haW4vamF2YS9u ZXQvb2F1dGgvc2lnbmF0dXJlcz4gIHRvIGltcGxlbWVudCB0aGlzIGFzIGEgcHJvb2Ytb2YtY29u Y2VwdC4NCg0KVGhvdWdodHM/IENvbW1lbnRzPw0KDQpEaXJrLg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_A73AD3C673FF43F78395BB62C7C03BBEfacebookcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZG Ij48ZGl2PkhpIE9BdXRoZXJzLDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Rmlyc3Qgb2YgYWxs LCBJIHRoaW5rIEkgc2hvdWxkIGludHJvZHVjZSBteXNlbGYuIEkgd29yayBhdCBGYWNlYm9vayBv biB0aGUgUGxhdGZvcm0gdGVhbSAoYW55dGhpbmcgbm90IDxhIGhyZWY9Imh0dHA6Ly9mYWNlYm9v ay5jb20iPmZhY2Vib29rLmNvbTwvYT4pLiBCZWZvcmUgdGhpcyBJIHdhcyBhdCBZYWhvbyEgZG9p bmcgU2VhcmNoTW9ua2V5IChzZW1hbnRpYyB3ZWIgc3R1ZmYpLiBJJ3ZlIHdyaXR0ZW4gYSBmZXcg T0F1dGggYXBwbGljYXRpb25zIGFuZCBsaWJyYXJpZXMsIGJvdGggYXQgWWFob28gYW5kIGluIG15 IHNwYXJlIHRpbWUuICZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Rm9yIEZhY2Vib29r IGFwcHMgd2UncmUgZ29pbmcgdG8gdXNlIHlvdXIgc2lnbmF0dXJlIHNjaGVtZSB3aXRoIHRoZSBm b2xsb3dpbmcgY2hhbmdlczo8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PiogdGhlIHNpZ25hdHVy ZSBjb21lcyBiZWZvcmUgdGhlIHBheWxvYWQ8L2Rpdj48ZGl2Piogd2UgdXNlZCB0aGUga2V5ICdh bGdvcml0aG0nIGluc3RlYWQgb2YgJ2FsZycgYW5kICdleHBpcmVzJyBpbnN0ZWFkIG9mICdub3Rf YmVmb3JlJzwvZGl2PjxkaXY+KiB3ZSBhcmVuJ3Qgc2VuZGluZyBhbnkga2V5cyBleGNlcHQgYWxn b3JpdGhtLCBleHBpcmVzLCBhbmQgb2F1dGhfdG9rZW4gKHNpbmNlIHdlJ3JlIGEgc3BlY2lhbCB1 c2UgY2FzZSk8L2Rpdj48ZGl2Piogd2UgbmFtZWQgdGhlIHBhcmFtZXRlciBzaWduZWRfcmVxdWVz dCBiZWNhdXNlIGl0IGlzIHRoZSBzaWduZWQgcGFydCBvZiBhIHJlcXVlc3QgJm5ic3A7PGJyPjxi cj48L2Rpdj48ZGl2PldlIHdvdWxkIGxvdmUgaWYgeW91IGNvdWxkIGFkb3B0IHRob3NlIGNoYW5n ZXMuIFRoZW4geW91J2QgaGF2ZSBhIHJlYWwgd29ybGQgaW1wbGVtZW50YXRpb24gb3V0IHRoZSBk b29yIGFscmVhZHkgOikgV2UgcGxhbiBvbiBsYXVuY2hpbmcgSnVseSAyMC4mbmJzcDs8L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PlBhdWw8L2Rpdj48ZGl2Pjxicj5TZW50IGZyb20gbXkgaVBob25l PC9kaXY+PGRpdj48YnI+T24gSnVsIDksIDIwMTAsIGF0IDE6MzkgUE0sICZxdW90O0RpcmsgQmFs ZmFueiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhbGZhbnpAZ29vZ2xlLmNvbSI+YmFsZmFu ekBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48ZGl2PjwvZGl2PjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+T24gV2VkLCBKdWwgNywgMjAxMCBhdCA3OjQ5IFBNLCBF cmFuIEhhbW1lci1MYWhhdiA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzplcmFu QGh1ZW5pdmVyc2UuY29tIj48YSBocmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSI+ZXJh bkBodWVuaXZlcnNlLmNvbTwvYT48L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4 OyI+DQoNCg0KDQoNCjxkaXY+DQo8Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRp Y2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPkNhbiB3ZSBnZXQgYW4gdXBk YXRlZCBkb2N1bWVudCBiYXNlZCBvbiB0aGUgZmVlZGJhY2sgcmVjZWl2ZWQ/PGJyPjwvc3Bhbj48 L2ZvbnQ+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+U3VyZSAtIEkganVz dCBnb3QgYmFjayBmcm9tIG15IHZhY2F0aW9uLiBJJ2xsIHJlYWQgdGhyb3VnaCB0aGUgdGhyZWFk IGFuZCB1cGRhdGUgdGhlIGRvY3MuPC9kaXY+DQo8ZGl2Pjxicj48L2Rpdj48ZGl2PkNoZWVycywm bmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkRpcmsuJm5ic3A7PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4OyI+PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJk YW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPg0KRUhM PGJyPg0KPGJyPg0KPGJyPg0KT24gNi8yMS8xMCAxMjowNCBBTSwgJnF1b3Q7RGlyayBCYWxmYW56 JnF1b3Q7ICZsdDs8YSBocmVmPSJodHRwOi8vYmFsZmFuekBnb29nbGUuY29tIiB0YXJnZXQ9Il9i bGFuayI+PGEgaHJlZj0ibWFpbHRvOmJhbGZhbnpAZ29vZ2xlLmNvbSI+YmFsZmFuekBnb29nbGUu Y29tPC9hPjwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGJsb2NrcXVv dGU+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij4gJmx0Oy8mZ3Q7ICZuYnNwOyZsdDsvJmd0OyBIaSBndXlz LCZuYnNwOzxkaXYgY2xhc3M9ImltIj48YnI+DQo8YnI+DQpJIHRoaW5rIEkgb3dlIHRoZSBsaXN0 IGEgcHJvcG9zYWwgZm9yIHNpZ25hdHVyZXMuPGJyPg0KPC9kaXY+PC9zcGFuPjwvZm9udD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxmb250IGZhY2U9IkFyaWFsIj48YnI+DQo8L2ZvbnQ+ PC9zcGFuPjxmb250IGZhY2U9IkFyaWFsIj48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwcHQiPkkgd3JvdGUgc29tZXRoaW5nIGRvd24gdGhhdCZuYnNwO2xpYmVyYWxseSZu YnNwO2JvcnJvd3MgaWRlYXMgZnJvbSBNYWdpYyBTaWduYXR1cmVzICZsdDs8YSBocmVmPSJodHRw Oi8vc2FsbW9uLXByb3RvY29sLmdvb2dsZWNvZGUuY29tL3N2bi90cnVuay9kcmFmdC1wYW56ZXIt bWFnaWNzaWctMDAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9Imh0dHA6Ly9zYWxtb24t cHJvdG9jb2wuZ29vZ2xlY29kZS5jb20vc3ZuL3RydW5rL2RyYWZ0LXBhbnplci1tYWdpY3NpZy0w MC5odG1sIj5odHRwOi8vc2FsbW9uLXByb3RvY29sLmdvb2dsZWNvZGUuY29tL3N2bi90cnVuay9k cmFmdC1wYW56ZXItbWFnaWNzaWctMDAuaHRtbDwvYT48L2E+Jmd0OyAsIFNXVCAmbHQ7PGEgaHJl Zj0iaHR0cDovL2dyb3Vwcy5nb29nbGUuY29tL2dyb3VwL1dSQVAtV0cvZmlsZXMiIHRhcmdldD0i X2JsYW5rIj48YSBocmVmPSJodHRwOi8vZ3JvdXBzLmdvb2dsZS5jb20vZ3JvdXAvV1JBUC1XRy9m aWxlcyI+aHR0cDovL2dyb3Vwcy5nb29nbGUuY29tL2dyb3VwL1dSQVAtV0cvZmlsZXM8L2E+PC9h PiZndDsgLCBhbmQgKGV2ZW4gdGhlIG5hbWUgZnJvbSkgSlNPTiBXZWIgVG9rZW5zICZsdDs8YSBo cmVmPSJodHRwczovL2dyb3Vwcy5nb29nbGUuY29tL2dyb3VwL1dSQVAtV0cvYnJvd3NlX3RocmVh ZC90aHJlYWQvYTk5MzY5YzRiNzRkNGNkMCMiIHRhcmdldD0iX2JsYW5rIj48YSBocmVmPSJodHRw czovL2dyb3Vwcy5nb29nbGUuY29tL2dyb3VwL1dSQVAtV0cvYnJvd3NlX3RocmVhZC90aHJlYWQv YTk5MzY5YzRiNzRkNGNkMCMiPmh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20vZ3JvdXAvV1JBUC1X Ry9icm93c2VfdGhyZWFkL3RocmVhZC9hOTkzNjljNGI3NGQ0Y2QwIzwvYT48L2E+Jmd0OyAuJm5i c3A7PGRpdiBjbGFzcz0iaW0iPg0KPGJyPg0KPGJyPg0KSGVyZSBpcyBhIHNob3J0IGRvY3VtZW50 IChjYWxsZWQgJnF1b3Q7SlNPTiBUb2tlbnMmcXVvdDspIHRoYXQganVzdCBleHBsYWlucyBob3cg dG8gc2lnbiBzb21ldGhpbmcgYW5kIHZlcmlmeSB0aGUgc2lnbmF0dXJlOjxicj4NCjxhIGhyZWY9 Imh0dHA6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvcHViP2lkPTFrdjZPel9IUm5XYTBEYUp4 X1NRNVFsa195cXNfN3pOQW03NS1GbUt3Tm80IiB0YXJnZXQ9Il9ibGFuayI+PGEgaHJlZj0iaHR0 cDovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9wdWI/aWQ9MWt2Nk96X0hSbldhMERhSnhfU1E1 UWxrX3lxc183ek5BbTc1LUZtS3dObzQiPmh0dHA6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQv cHViP2lkPTFrdjZPel9IUm5XYTBEYUp4X1NRNVFsa195cXNfN3pOQW03NS1GbUt3Tm80PC9hPjwv YT48YnI+DQo8YnI+DQpIZXJlIGlzIGFuIGV4dGVuc2lvbiBvZiBKU09OIFRva2VucyB0aGF0IGNh biBiZSB1c2VkIGZvciBzaWduZWQgT0F1dGggdG9rZW5zOiAmbHQ7PGEgaHJlZj0iaHR0cDovL2Rv Y3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9wdWI/aWQ9MUpVbjNUd2Q5blh3RkRnaS1mVEtsLXVuREdf bmR5b3dUWlc4T1dYOUhPVVUiIHRhcmdldD0iX2JsYW5rIj48YSBocmVmPSJodHRwOi8vZG9jcy5n b29nbGUuY29tL2RvY3VtZW50L3B1Yj9pZD0xSlVuM1R3ZDluWHdGRGdpLWZUS2wtdW5ER19uZHlv d1RaVzhPV1g5SE9VVSI+aHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9wdWI/aWQ9MUpV bjNUd2Q5blh3RkRnaS1mVEtsLXVuREdfbmR5b3dUWlc4T1dYOUhPVVU8L2E+PC9hPiZndDsgPGJy Pg0KDQo8YSBocmVmPSJodHRwOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L3B1Yj9pZD0xSlVu M1R3ZDluWHdGRGdpLWZUS2wtdW5ER19uZHlvd1RaVzhPV1g5SE9VVSIgdGFyZ2V0PSJfYmxhbmsi PjxhIGhyZWY9Imh0dHA6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvcHViP2lkPTFKVW4zVHdk OW5Yd0ZEZ2ktZlRLbC11bkRHX25keW93VFpXOE9XWDlIT1VVIj5odHRwOi8vZG9jcy5nb29nbGUu Y29tL2RvY3VtZW50L3B1Yj9pZD0xSlVuM1R3ZDluWHdGRGdpLWZUS2wtdW5ER19uZHlvd1RaVzhP V1g5SE9VVTwvYT48L2E+PGJyPg0KPC9kaXY+PC9zcGFuPjwvZm9udD48L2ZvbnQ+PGRpdiBjbGFz cz0iaW0iPjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXpl PSIyIj48Zm9udCBmYWNlPSJBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0Ij5IZXJl IGlzIGEgZGlmZmVyZW50IGV4dGVuc2lvbiBvZiBKU09OIFRva2VucyB0aGF0IGNhbiBiZSB1c2Vk IGZvciAyLWxlZ2dlZCBmbG93cy4gVGhlIGlkZWEgaXMgdGhhdCB0aGlzIGNvdWxkIGJlIHVzZWQg YXMgYSBkcm9wLWluIHJlcGxhY2VtZW50IGZvciBTQU1MIGFzc2VydGlvbnMgaW4gdGhlIE9BdXRo MiBhc3NlcnRpb24gZmxvdzo8YnI+DQoNCjxhIGhyZWY9Imh0dHA6Ly9kb2NzLmdvb2dsZS5jb20v ZG9jdW1lbnQvcHViP2lkPTFzNGtqUlM5UDBmckcwdWxoZ1AzSGUwMU9ObHhlVHdrRlFWX3BDb09v d3pjIiB0YXJnZXQ9Il9ibGFuayI+PGEgaHJlZj0iaHR0cDovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1 bWVudC9wdWI/aWQ9MXM0a2pSUzlQMGZyRzB1bGhnUDNIZTAxT05seGVUd2tGUVZfcENvT293emMi Pmh0dHA6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvcHViP2lkPTFzNGtqUlM5UDBmckcwdWxo Z1AzSGUwMU9ObHhlVHdrRlFWX3BDb09vd3pjPC9hPjwvYT48YnI+DQo8L3NwYW4+PC9mb250Pjwv Zm9udD48L2Rpdj48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCkkgYWxzbyBoYXZlIHN0YXJ0ZWQg dG8gd3JpdGUgc29tZSBjb2RlICZsdDs8YSBocmVmPSJodHRwOi8vY29kZS5nb29nbGUuY29tL3Av anNvbnRva2VuL3NvdXJjZS9icm93c2UvI3N2bi90cnVuay9zcmMvbWFpbi9qYXZhL25ldC9vYXV0 aC9zaWduYXR1cmVzIiB0YXJnZXQ9Il9ibGFuayI+PGEgaHJlZj0iaHR0cDovL2NvZGUuZ29vZ2xl LmNvbS9wL2pzb250b2tlbi9zb3VyY2UvYnJvd3NlLyNzdm4vdHJ1bmsvc3JjL21haW4vamF2YS9u ZXQvb2F1dGgvc2lnbmF0dXJlcyI+aHR0cDovL2NvZGUuZ29vZ2xlLmNvbS9wL2pzb250b2tlbi9z b3VyY2UvYnJvd3NlLyNzdm4vdHJ1bmsvc3JjL21haW4vamF2YS9uZXQvb2F1dGgvc2lnbmF0dXJl czwvYT48L2E+Jmd0OyAmbmJzcDt0byBpbXBsZW1lbnQgdGhpcyBhcyBhIHByb29mLW9mLWNvbmNl cHQuJm5ic3A7PGJyPg0KDQo8YnI+DQpUaG91Z2h0cz8gQ29tbWVudHM/PGJyPg0KPGJyPg0KRGly ay48YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PC9mb250PjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K DQoNCjwvYmxvY2txdW90ZT48L2Rpdj48YnI+DQo8L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+T0F1dGggbWFpbGluZyBsaXN0PC9zcGFu Pjxicj48c3Bhbj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3Jn PC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --_000_A73AD3C673FF43F78395BB62C7C03BBEfacebookcom_-- From dick.hardt@gmail.com Sat Jul 10 11:00:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255733A6973 for ; Sat, 10 Jul 2010 11:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfKPht6ptakg for ; Sat, 10 Jul 2010 11:00:35 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 174753A697D for ; Sat, 10 Jul 2010 11:00:35 -0700 (PDT) Received: by pxi20 with SMTP id 20so1579158pxi.31 for ; Sat, 10 Jul 2010 11:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=XX0Cq2e5aK844CGJ1ITncBJyQQS+avirSBigG4S7QyY=; b=X0ZJP3mIngO23U34Ia+x6kvJ7Sz6jOmHbaQXTxH/RS9vEqmoR0n1Xeopq055/dA+wh ionBey9VdgIRj8vOc4A+wPNYj5qO/cksO18hbDceVtl0DydwjJPunEsvjFUYdSby7uo4 OEcKTXHPiRbkGnYofIHB3HSEfXfJ2C7lvb0Xk= 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=l9FvBmYf2AJ9y+3lz33XLXrKNsLunLq2CMuwoITq9VmD0EfUq5YjGw5KaH0kvHaact zHkKgLPOY8zHutJWeNbIENx+ohzjZEZUUBCd1y1V1WlzGTsD8+OBwgcbVnp16Rl8f5pP hmUZwQ/NV4UAPReoWTJLh4//wdmZxRJDkoVF8= Received: by 10.114.74.19 with SMTP id w19mr3460629waa.25.1278784838511; Sat, 10 Jul 2010 11:00:38 -0700 (PDT) Received: from [192.168.1.2] ([24.130.32.55]) by mx.google.com with ESMTPS id k23sm35588952waf.5.2010.07.10.11.00.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 10 Jul 2010 11:00:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-198--170075427 From: Dick Hardt In-Reply-To: Date: Sat, 10 Jul 2010 11:00:35 -0700 Message-Id: <1C84C062-6E34-4C89-85C8-5809581A02CC@gmail.com> References: To: Paul Tarjan X-Mailer: Apple Mail (2.1078) Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jul 2010 18:00:40 -0000 --Apple-Mail-198--170075427 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-07-10, at 9:58 AM, Paul Tarjan wrote: > Hi OAuthers, >=20 > First of all, I think I should introduce myself. I work at Facebook on = the Platform team (anything not facebook.com). Before this I was at = Yahoo! doing SearchMonkey (semantic web stuff). I've written a few OAuth = applications and libraries, both at Yahoo and in my spare time. =20 >=20 > For Facebook apps we're going to use your signature scheme with the = following changes: I would hope you would think it is "our" signature scheme rather than = "your" signature scheme >=20 > * the signature comes before the payload > * we used the key 'algorithm' instead of 'alg' and 'expires' instead = of 'not_before' Good points to add to the discussion. Perhaps you would articulate why = you made those choices? > * we aren't sending any keys except algorithm, expires, and = oauth_token (since we're a special use case) If you are a special use case, then not sure why there is any point in = being a standard. Assuming you meant "parameters" instead of "keys"? "key" has special = meaning when you are discussing crypto. > * we named the parameter signed_request because it is the signed part = of a request =20 Which parameter? >=20 > We would love if you could adopt those changes. Then you'd have a real = world implementation out the door already :) We plan on launching July = 20.=20 Er, we welcome feedback on the standard. Facebook can deploy whatever = they want to deploy. An early implementation is useful to see what the = issues might be. While possible, it is unlikely what you deploy will be = the standard. >=20 > Paul >=20 > Sent from my iPhone Thanks for letting us know what device you use. -- Dick= --Apple-Mail-198--170075427 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi OAuthers,

First of = all, I think I should introduce myself. I work at Facebook on the = Platform team (anything not facebook.com). Before this I was at = Yahoo! doing SearchMonkey (semantic web stuff). I've written a few OAuth = applications and libraries, both at Yahoo and in my spare time. =  

For Facebook apps we're going to use = your signature scheme with the following = changes:

I would hope you = would think it is "our" signature scheme rather than "your" signature = scheme


* the signature comes before the = payload
* we used the key 'algorithm' instead of 'alg' and = 'expires' instead of = 'not_before'

Good points to = add to the discussion. Perhaps you would articulate why you made those = choices?

* we aren't sending any keys except algorithm, = expires, and oauth_token (since we're a special use = case)

If you are a special = use case, then not sure why there is any point in being a = standard.
Assuming you meant "parameters" instead of "keys"? = "key" has special meaning when  you are discussing = crypto.

*= we named the parameter signed_request because it is the signed part of = a request  

Which = parameter?


We would love if you could adopt = those changes. Then you'd have a real world implementation out the door = already :) We plan on launching July = 20. 

Er, we welcome = feedback on the standard. Facebook can deploy whatever they want to = deploy. An early implementation is useful to see what the issues might = be. While possible, it is unlikely what you deploy will be the = standard.


Paul

Sent from my = iPhone

Thanks for letting us = know what device you use.

-- = Dick
= --Apple-Mail-198--170075427-- From eran@hueniverse.com Sat Jul 10 11:07: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 F252E3A697D for ; Sat, 10 Jul 2010 11:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.344, 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 ruRKwApOb8ZC for ; Sat, 10 Jul 2010 11:07:07 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A62823A6973 for ; Sat, 10 Jul 2010 11:07:07 -0700 (PDT) Received: (qmail 29976 invoked from network); 10 Jul 2010 18:07:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jul 2010 18:07:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 10 Jul 2010 11:07:12 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Sat, 10 Jul 2010 11:06:11 -0700 Thread-Topic: [OAUTH-WG] proposal for signatures Thread-Index: AcsgWriO3zQCJzgsRGamU2BiHf5udQ== Message-ID: <057DBC6F-D702-43EA-8965-C507522D731F@hueniverse.com> References: <1C84C062-6E34-4C89-85C8-5809581A02CC@gmail.com> In-Reply-To: <1C84C062-6E34-4C89-85C8-5809581A02CC@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_057DBC6FD70243EA8965C507522D731Fhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jul 2010 18:07:09 -0000 --_000_057DBC6FD70243EA8965C507522D731Fhueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgbmVlZCB0byBnZXQgdGhpcyBpbnRvIGEgcHJvcGVyIGRyYWZ0ICh3aGljaCBJIHVuZGVyc3Rh bmQgaXMgb24gRGlyaydzIGxpc3QpIGFuZCBkbyBhIHJvdW5kIG9mIGZlZWRiYWNrIGJlZm9yZSB3 ZSBwcm9tb3RlIHRoaXMgdG8gYSBXRyBkcmFmdC4gSSdtIGhhcHB5IHRvIGhlbHAgd2l0aCBlZGl0 b3JpYWwgd29yayBpZiBuZWVkZWQuDQoNCkdpdmVuIHRoZSB3aWRlIHJhbmdlIG9mIHVzZSBjYXNl cywgSSB0aGluayB3ZSBuZWVkIHRvIGtlZXAgdGhpcyB3b3JrIGZvY3VzZWQgb24gdGhlIHVzZSBj YXNlcyBkcml2aW5nIGl0LCBhbmQgbm90IHRyeSB0byBtYWtlIGl0IHRvbyBnZW5lcmljLg0KDQpF SEwNCg0KDQoNCk9uIEp1bCAxMCwgMjAxMCwgYXQgMTQ6MDAsIERpY2sgSGFyZHQgPGRpY2suaGFy ZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCk9u IDIwMTAtMDctMTAsIGF0IDk6NTggQU0sIFBhdWwgVGFyamFuIHdyb3RlOg0KDQpIaSBPQXV0aGVy cywNCg0KRmlyc3Qgb2YgYWxsLCBJIHRoaW5rIEkgc2hvdWxkIGludHJvZHVjZSBteXNlbGYuIEkg d29yayBhdCBGYWNlYm9vayBvbiB0aGUgUGxhdGZvcm0gdGVhbSAoYW55dGhpbmcgbm90IDxodHRw Oi8vZmFjZWJvb2suY29tLz4gZmFjZWJvb2suY29tPGh0dHA6Ly9mYWNlYm9vay5jb20+KS4gQmVm b3JlIHRoaXMgSSB3YXMgYXQgWWFob28hIGRvaW5nIFNlYXJjaE1vbmtleSAoc2VtYW50aWMgd2Vi IHN0dWZmKS4gSSd2ZSB3cml0dGVuIGEgZmV3IE9BdXRoIGFwcGxpY2F0aW9ucyBhbmQgbGlicmFy aWVzLCBib3RoIGF0IFlhaG9vIGFuZCBpbiBteSBzcGFyZSB0aW1lLg0KDQpGb3IgRmFjZWJvb2sg YXBwcyB3ZSdyZSBnb2luZyB0byB1c2UgeW91ciBzaWduYXR1cmUgc2NoZW1lIHdpdGggdGhlIGZv bGxvd2luZyBjaGFuZ2VzOg0KDQpJIHdvdWxkIGhvcGUgeW91IHdvdWxkIHRoaW5rIGl0IGlzICJv dXIiIHNpZ25hdHVyZSBzY2hlbWUgcmF0aGVyIHRoYW4gInlvdXIiIHNpZ25hdHVyZSBzY2hlbWUN Cg0KDQoqIHRoZSBzaWduYXR1cmUgY29tZXMgYmVmb3JlIHRoZSBwYXlsb2FkDQoqIHdlIHVzZWQg dGhlIGtleSAnYWxnb3JpdGhtJyBpbnN0ZWFkIG9mICdhbGcnIGFuZCAnZXhwaXJlcycgaW5zdGVh ZCBvZiAnbm90X2JlZm9yZScNCg0KR29vZCBwb2ludHMgdG8gYWRkIHRvIHRoZSBkaXNjdXNzaW9u LiBQZXJoYXBzIHlvdSB3b3VsZCBhcnRpY3VsYXRlIHdoeSB5b3UgbWFkZSB0aG9zZSBjaG9pY2Vz Pw0KDQoqIHdlIGFyZW4ndCBzZW5kaW5nIGFueSBrZXlzIGV4Y2VwdCBhbGdvcml0aG0sIGV4cGly ZXMsIGFuZCBvYXV0aF90b2tlbiAoc2luY2Ugd2UncmUgYSBzcGVjaWFsIHVzZSBjYXNlKQ0KDQpJ ZiB5b3UgYXJlIGEgc3BlY2lhbCB1c2UgY2FzZSwgdGhlbiBub3Qgc3VyZSB3aHkgdGhlcmUgaXMg YW55IHBvaW50IGluIGJlaW5nIGEgc3RhbmRhcmQuDQpBc3N1bWluZyB5b3UgbWVhbnQgInBhcmFt ZXRlcnMiIGluc3RlYWQgb2YgImtleXMiPyAia2V5IiBoYXMgc3BlY2lhbCBtZWFuaW5nIHdoZW4g IHlvdSBhcmUgZGlzY3Vzc2luZyBjcnlwdG8uDQoNCiogd2UgbmFtZWQgdGhlIHBhcmFtZXRlciBz aWduZWRfcmVxdWVzdCBiZWNhdXNlIGl0IGlzIHRoZSBzaWduZWQgcGFydCBvZiBhIHJlcXVlc3QN Cg0KV2hpY2ggcGFyYW1ldGVyPw0KDQoNCldlIHdvdWxkIGxvdmUgaWYgeW91IGNvdWxkIGFkb3B0 IHRob3NlIGNoYW5nZXMuIFRoZW4geW91J2QgaGF2ZSBhIHJlYWwgd29ybGQgaW1wbGVtZW50YXRp b24gb3V0IHRoZSBkb29yIGFscmVhZHkgOikgV2UgcGxhbiBvbiBsYXVuY2hpbmcgSnVseSAyMC4N Cg0KRXIsIHdlIHdlbGNvbWUgZmVlZGJhY2sgb24gdGhlIHN0YW5kYXJkLiBGYWNlYm9vayBjYW4g ZGVwbG95IHdoYXRldmVyIHRoZXkgd2FudCB0byBkZXBsb3kuIEFuIGVhcmx5IGltcGxlbWVudGF0 aW9uIGlzIHVzZWZ1bCB0byBzZWUgd2hhdCB0aGUgaXNzdWVzIG1pZ2h0IGJlLiBXaGlsZSBwb3Nz aWJsZSwgaXQgaXMgdW5saWtlbHkgd2hhdCB5b3UgZGVwbG95IHdpbGwgYmUgdGhlIHN0YW5kYXJk Lg0KDQoNClBhdWwNCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpUaGFua3MgZm9yIGxldHRpbmcg dXMga25vdyB3aGF0IGRldmljZSB5b3UgdXNlLg0KDQotLSBEaWNrDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0 aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_057DBC6FD70243EA8965C507522D731Fhueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5XZSBuZWVkIHRvIGdldCB0aGlzIGlu dG8gYSBwcm9wZXIgZHJhZnQgKHdoaWNoIEkgdW5kZXJzdGFuZCBpcyBvbiBEaXJrJ3MgbGlzdCkg YW5kIGRvIGEgcm91bmQgb2YgZmVlZGJhY2sgYmVmb3JlIHdlIHByb21vdGUgdGhpcyB0byBhIFdH IGRyYWZ0LiBJJ20gaGFwcHkgdG8gaGVscCB3aXRoIGVkaXRvcmlhbCB3b3JrIGlmIG5lZWRlZC4m bmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkdpdmVuIHRoZSB3aWRlIHJhbmdlIG9mIHVz ZSBjYXNlcywgSSB0aGluayB3ZSBuZWVkIHRvIGtlZXAgdGhpcyB3b3JrIGZvY3VzZWQgb24gdGhl IHVzZSBjYXNlcyBkcml2aW5nIGl0LCBhbmQgbm90IHRyeSB0byBtYWtlIGl0IHRvbyBnZW5lcmlj LiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+RUhMPGJyPjxicj48ZGl2Pjxicj48L2Rp dj48L2Rpdj48ZGl2Pjxicj5PbiBKdWwgMTAsIDIwMTAsIGF0IDE0OjAwLCBEaWNrIEhhcmR0ICZs dDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iPmRpY2suaGFyZHRAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48ZGl2PjwvZGl2PjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxkaXY+PGJyPjxkaXY+PGRpdj5PbiAyMDEwLTA3LTEwLCBhdCA5OjU4IEFNLCBQ YXVsIFRhcmphbiB3cm90ZTo8L2Rpdj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXYgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5I aSBPQXV0aGVycyw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkZpcnN0IG9mIGFsbCwgSSB0aGlu ayBJIHNob3VsZCBpbnRyb2R1Y2UgbXlzZWxmLiBJIHdvcmsgYXQgRmFjZWJvb2sgb24gdGhlIFBs YXRmb3JtIHRlYW0gKGFueXRoaW5nIG5vdCA8YSBocmVmPSJodHRwOi8vZmFjZWJvb2suY29tLyI+ PGEgaHJlZj0iaHR0cDovL2ZhY2Vib29rLmNvbSI+ZmFjZWJvb2suY29tPC9hPjwvYT4pLiBCZWZv cmUgdGhpcyBJIHdhcyBhdCBZYWhvbyEgZG9pbmcgU2VhcmNoTW9ua2V5IChzZW1hbnRpYyB3ZWIg c3R1ZmYpLiBJJ3ZlIHdyaXR0ZW4gYSBmZXcgT0F1dGggYXBwbGljYXRpb25zIGFuZCBsaWJyYXJp ZXMsIGJvdGggYXQgWWFob28gYW5kIGluIG15IHNwYXJlIHRpbWUuICZuYnNwOzwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+Rm9yIEZhY2Vib29rIGFwcHMgd2UncmUgZ29pbmcgdG8gdXNlIHlvdXIg c2lnbmF0dXJlIHNjaGVtZSB3aXRoIHRoZSBmb2xsb3dpbmcgY2hhbmdlczo8L2Rpdj48L2Rpdj48 L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5JIHdvdWxkIGhvcGUgeW91IHdvdWxkIHRo aW5rIGl0IGlzICJvdXIiIHNpZ25hdHVyZSBzY2hlbWUgcmF0aGVyIHRoYW4gInlvdXIiIHNpZ25h dHVyZSBzY2hlbWU8L2Rpdj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdiBiZ2NvbG9y PSIjRkZGRkZGIj48ZGl2Pjxicj48L2Rpdj48ZGl2PiogdGhlIHNpZ25hdHVyZSBjb21lcyBiZWZv cmUgdGhlIHBheWxvYWQ8L2Rpdj48ZGl2Piogd2UgdXNlZCB0aGUga2V5ICdhbGdvcml0aG0nIGlu c3RlYWQgb2YgJ2FsZycgYW5kICdleHBpcmVzJyBpbnN0ZWFkIG9mICdub3RfYmVmb3JlJzwvZGl2 PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pkdvb2QgcG9pbnRzIHRvIGFk ZCB0byB0aGUgZGlzY3Vzc2lvbi4gUGVyaGFwcyB5b3Ugd291bGQgYXJ0aWN1bGF0ZSB3aHkgeW91 IG1hZGUgdGhvc2UgY2hvaWNlcz88L2Rpdj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRp diBiZ2NvbG9yPSIjRkZGRkZGIj48ZGl2Piogd2UgYXJlbid0IHNlbmRpbmcgYW55IGtleXMgZXhj ZXB0IGFsZ29yaXRobSwgZXhwaXJlcywgYW5kIG9hdXRoX3Rva2VuIChzaW5jZSB3ZSdyZSBhIHNw ZWNpYWwgdXNlIGNhc2UpPC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2Pjxk aXY+SWYgeW91IGFyZSBhIHNwZWNpYWwgdXNlIGNhc2UsIHRoZW4gbm90IHN1cmUgd2h5IHRoZXJl IGlzIGFueSBwb2ludCBpbiBiZWluZyBhIHN0YW5kYXJkLjwvZGl2PjxkaXY+QXNzdW1pbmcgeW91 IG1lYW50ICJwYXJhbWV0ZXJzIiBpbnN0ZWFkIG9mICJrZXlzIj8gImtleSIgaGFzIHNwZWNpYWwg bWVhbmluZyB3aGVuICZuYnNwO3lvdSBhcmUgZGlzY3Vzc2luZyBjcnlwdG8uPC9kaXY+PGJyPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXYgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj4qIHdlIG5h bWVkIHRoZSBwYXJhbWV0ZXIgc2lnbmVkX3JlcXVlc3QgYmVjYXVzZSBpdCBpcyB0aGUgc2lnbmVk IHBhcnQgb2YgYSByZXF1ZXN0ICZuYnNwOzxicj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRp dj48YnI+PC9kaXY+PGRpdj5XaGljaCBwYXJhbWV0ZXI/PC9kaXY+PGJyPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxkaXYgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj48YnI+PC9kaXY+PGRpdj5XZSB3 b3VsZCBsb3ZlIGlmIHlvdSBjb3VsZCBhZG9wdCB0aG9zZSBjaGFuZ2VzLiBUaGVuIHlvdSdkIGhh dmUgYSByZWFsIHdvcmxkIGltcGxlbWVudGF0aW9uIG91dCB0aGUgZG9vciBhbHJlYWR5IDopIFdl IHBsYW4gb24gbGF1bmNoaW5nIEp1bHkgMjAuJm5ic3A7PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3Rl PjxkaXY+PGJyPjwvZGl2PjxkaXY+RXIsIHdlIHdlbGNvbWUgZmVlZGJhY2sgb24gdGhlIHN0YW5k YXJkLiBGYWNlYm9vayBjYW4gZGVwbG95IHdoYXRldmVyIHRoZXkgd2FudCB0byBkZXBsb3kuIEFu IGVhcmx5IGltcGxlbWVudGF0aW9uIGlzIHVzZWZ1bCB0byBzZWUgd2hhdCB0aGUgaXNzdWVzIG1p Z2h0IGJlLiBXaGlsZSBwb3NzaWJsZSwgaXQgaXMgdW5saWtlbHkgd2hhdCB5b3UgZGVwbG95IHdp bGwgYmUgdGhlIHN0YW5kYXJkLjwvZGl2Pjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2 IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+PGJyPjwvZGl2PjxkaXY+UGF1bDwvZGl2PjxkaXY+PGJy PlNlbnQgZnJvbSBteSBpUGhvbmU8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9k aXY+PGRpdj5UaGFua3MgZm9yIGxldHRpbmcgdXMga25vdyB3aGF0IGRldmljZSB5b3UgdXNlLjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+LS0gRGljazwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2tx dW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj48c3Bhbj5PQXV0aCBtYWls aW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+ T0F1dGhAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9k eT48L2h0bWw+ --_000_057DBC6FD70243EA8965C507522D731Fhueniversecom_-- From dick.hardt@gmail.com Sat Jul 10 11:48: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 5B6C03A6863 for ; Sat, 10 Jul 2010 11:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tc4eUtlUyFTY for ; Sat, 10 Jul 2010 11:48:21 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 845BB3A67FC for ; Sat, 10 Jul 2010 11:48:21 -0700 (PDT) Received: by pxi20 with SMTP id 20so1588547pxi.31 for ; Sat, 10 Jul 2010 11:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=QLRbV8Htw9fOQi6paKJ+d0a15qyTvi8b6PYUji6TyXs=; b=sAdy2M5tlRM4pDHwB8fMbtxbxazqrHjftXMT1gXYZnp2dkGQOczeqP2YdtRmU4hzIY HYNKED7h3lR0Kg0gL+vCOK0pro5b3vQqzWY4EscIrNCwYF3AQ6DzG3sGHcrS16tXd98T ybIlvsMUIFsXlDCv1WBCPl8QXLb6zVf7kUPHk= 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=RaqbKmTnWapFKjdY/b2usMT+tpCcAlh1bbzne1K5vGLAQEPBOH0RNWRYv/RgfA2Lq3 Sg057HyFPP9i3U6T5SJO6dCS+bnN5EFxNp01eC08Q3Zbonr2k8rhZXowjkFuTVqKOnCb Q2MxkB4EnacyDo+q/rVoOwjjEix4Q0OiVRX+M= Received: by 10.142.230.18 with SMTP id c18mr9819621wfh.269.1278787704284; Sat, 10 Jul 2010 11:48:24 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id c23sm2351587rvf.12.2010.07.10.11.48.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 10 Jul 2010 11:48:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <057DBC6F-D702-43EA-8965-C507522D731F@hueniverse.com> Date: Sat, 10 Jul 2010 11:48:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4EA35F3D-7A3A-41FE-8A26-26BFAD8D898F@gmail.com> References: <1C84C062-6E34-4C89-85C8-5809581A02CC@gmail.com> <057DBC6F-D702-43EA-8965-C507522D731F@hueniverse.com> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1078) Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jul 2010 18:48:22 -0000 I agree we don't want to end up like other protocols that were too = generic. :) The use case I am arguing for is sending encrypted tokens. Higher levels = of assurance require this and various people brought this up as a = requirement when WRAP was presented at IIW 09B. -- Dick On 2010-07-10, at 11:06 AM, Eran Hammer-Lahav wrote: > We need to get this into a proper draft (which I understand is on = Dirk's list) and do a round of feedback before we promote this to a WG = draft. I'm happy to help with editorial work if needed.=20 >=20 > Given the wide range of use cases, I think we need to keep this work = focused on the use cases driving it, and not try to make it too generic.=20= From recordond@gmail.com Sat Jul 10 13:21: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 8A3EE3A679C for ; Sat, 10 Jul 2010 13:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.511, 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 wUNOMKFTvTbk for ; Sat, 10 Jul 2010 13:21:47 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4357D3A67A5 for ; Sat, 10 Jul 2010 13:21:47 -0700 (PDT) Received: by iwn38 with SMTP id 38so3534611iwn.31 for ; Sat, 10 Jul 2010 13:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=lD7SeRnhg27Ue2d2S1hW4F8tG5qm6qbYr3qjUzFc/nA=; b=Lf4TAQF1KUb+6dIL8pIDWetEeWHpT2OhVOdPg94jRzgiy9gm0R+8YiU2EFpwHSWoKE HsA8CKIvJL/LvnklmtsgApOZOPF3GhiRSClaYw66vUYiD6/B93OnzWXiLvrAK1kKeiS0 Xk5jEAKXRIjdq4nm44I5YNEK/vxMp6EvC2oPU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=s+xqZXsY8vhGWjXE9ScyNKHo46nU4AV6WQrI1gXoeIE7ZcD5wngH8PesGNx3vmCvXC gSRbXIOjdfAEtYnfYeZLYJjslxSvzJB8hXvwB5sCApinwRBWkbMhFQ0oOW95Qkg1xgg+ oG5qCSUG9WEOXmrEJlwRGEllKhsRLsRnjo8T8= MIME-Version: 1.0 Received: by 10.231.161.135 with SMTP id r7mr11735414ibx.52.1278793313291; Sat, 10 Jul 2010 13:21:53 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Sat, 10 Jul 2010 13:21:53 -0700 (PDT) In-Reply-To: <1C84C062-6E34-4C89-85C8-5809581A02CC@gmail.com> References: <1C84C062-6E34-4C89-85C8-5809581A02CC@gmail.com> Date: Sat, 10 Jul 2010 13:21:53 -0700 Message-ID: From: David Recordon To: Dick Hardt Content-Type: multipart/alternative; boundary=0016e68fa7342e1024048b0e45f6 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jul 2010 20:21:48 -0000 --0016e68fa7342e1024048b0e45f6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt wrote: > On 2010-07-10, at 9:58 AM, Paul Tarjan wrote: > > Hi OAuthers, > > First of all, I think I should introduce myself. I work at Facebook on th= e > Platform team (anything not facebook.com). Before this I was at Yahoo! > doing SearchMonkey (semantic web stuff). I've written a few OAuth > applications and libraries, both at Yahoo and in my spare time. > > For Facebook apps we're going to use your signature scheme with the > following changes: > > > I would hope you would think it is "our" signature scheme rather than > "your" signature scheme > I think Paul was referring to the proposal Dirk put forward since there isn't anything which has become part of OAuth yet. ;) * the signature comes before the payload > * we used the key 'algorithm' instead of 'alg' and 'expires' instead of > 'not_before' > > > Good points to add to the discussion. Perhaps you would articulate why yo= u > made those choices? > I think Naitik talked about the signature coming before the payload in this thread. Through implementations we've found that lsplit is easier in some languages. The benefit of using 'alg' is unclear compared to spelling out the word 'algorithm' which adds clarity for developers. * we aren't sending any keys except algorithm, expires, and oauth_token > (since we're a special use case) > > > If you are a special use case, then not sure why there is any point in > being a standard. > Some more background is needed here. We're not currently implementing signatures for our protected resources, but rather to send some trusted parameters from the authorization server to the client. We're starting with a use case entirely on Facebook.com (our canvas applications) and thus have a different set of security considerations. There is value in the underlying signature format being the same. Thus making use of signed JSON =96 the hard part =96 even if some of the paramet= ers within are different. > Assuming you meant "parameters" instead of "keys"? "key" has special > meaning when you are discussing crypto. > Yes. * we named the parameter signed_request because it is the signed part of a > request > > > Which parameter? > The context above should be helpful. This would be the parameter name comin= g from the AS to the client. > We would love if you could adopt those changes. Then you'd have a real > world implementation out the door already :) We plan on launching July 20= . > > > Er, we welcome feedback on the standard. Facebook can deploy whatever the= y > want to deploy. An early implementation is useful to see what the issues > might be. While possible, it is unlikely what you deploy will be the > standard. > > > Paul > > Sent from my iPhone > > > Thanks for letting us know what device you use. > > -- Dick > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0016e68fa7342e1024048b0e45f6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt <dick.hardt@gmail.com> wrote:=
On 2010-07-= 10, at 9:58 AM, Paul Tarjan wrote:
Hi OAuthers,

First of all, I = think I should introduce myself. I work at Facebook on the Platform team (a= nything not facebook.com= ). Before this I was at Yahoo! doing SearchMonkey (semantic web stuff).= I've written a few OAuth applications and libraries, both at Yahoo and= in my spare time. =A0

For Facebook apps we're going to use your signature= scheme with the following changes:

=
I would hope you would think it is "our" signature sch= eme rather than "your" signature scheme

I think Paul was referring to = the proposal Dirk put forward since there isn't anything which has beco= me part of OAuth yet. ;)

* the signature comes before the pa= yload
* we used the key 'algorithm' instead of 'alg&#= 39; and 'expires' instead of 'not_before'

Good points to add to the disc= ussion. Perhaps you would articulate why you made those choices?

I think Naitik talked about the sig= nature coming before the payload in this thread. Through implementations we= 've found that lsplit is=A0easier=A0in some languages.

The benefit of using 'alg' is unclear compared = to spelling out the word 'algorithm' which adds clarity for develop= ers.

* we aren't sending any keys ex= cept algorithm, expires, and oauth_token (since we're a special use cas= e)

If you are a special use case,= then not sure why there is any point in being a standard.

Some more background is needed here. We&#= 39;re not currently implementing signatures for our protected resources, bu= t rather to send some trusted parameters from the authorization server to t= he client. We're starting with a use case=A0entirely=A0on Facebook.com = (our canvas applications) and thus have a different set of security conside= rations.

There is value in the underlying signature format being= the same. Thus making use of signed JSON =96 the hard part =96 even if som= e of the parameters within are different.

=A0
Assuming you meant "para= meters" instead of "keys"? "key" has special meani= ng when =A0you are discussing crypto.
Yes.=A0

* we named the parameter signed_request because it is the signed part = of a request =A0

Whic= h parameter?

The context = above should be helpful. This would be the parameter name coming from the A= S to the client.
=A0
We would love if you could adopt those changes. Then you'd have a real = world implementation out the door already :) We plan on launching July 20.= =A0

Er, we welcome feedba= ck on the standard. Facebook can deploy whatever they want to deploy. An ea= rly implementation is useful to see what the issues might be. While possibl= e, it is unlikely what you deploy will be the standard.


Paul

Sent from my iPhone

Thanks for letting us know what device you = use.=A0

-- Dick<= /div>

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


--0016e68fa7342e1024048b0e45f6-- From dick.hardt@gmail.com Sat Jul 10 13:29:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB3A3A67A5 for ; Sat, 10 Jul 2010 13:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRj0shD4i3Jq for ; Sat, 10 Jul 2010 13:29:31 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 8A9483A6861 for ; Sat, 10 Jul 2010 13:29:30 -0700 (PDT) Received: by pwj1 with SMTP id 1so1599137pwj.31 for ; Sat, 10 Jul 2010 13:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=0uRNrSle9AczTHsdLBielzC54L5Ngoq8DrfgfCaz55k=; b=IIeTsuvlSWXUTIcDAKVphS6fgwOjiIWX0ObbioSNn+JmaSV3zLD0DqJfiUiJnH+1+n R6DHcXW4w2NYAQm+esn/GzYPl16GC+XwUt6FxCZ9dAKTBZI2BB/gTUx+P0vAyuZ9SApH k4qNC2oa6J6hVnUv9LHT4Zn6gbfPlHLVpumYE= 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=TBPLVCMcQtWpWgcIVuav9vB08yn+HybWSDQG5b3eLOKzmoJq/NMetiiEsH33M86LAp 8VEuce0G4CXTBYMltl1NvAl9QXqmwz+QU9XAAUAPJsbUxZ50CnZR+LY11+Un0tkTCPZE zw1jKhavo7eED7XIoGa6/yGQmYeRpoMMV96kw= Received: by 10.142.194.15 with SMTP id r15mr9698834wff.274.1278793772309; Sat, 10 Jul 2010 13:29:32 -0700 (PDT) Received: from [192.168.1.2] ([24.130.32.55]) by mx.google.com with ESMTPS id t11sm2744691wfc.16.2010.07.10.13.29.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 10 Jul 2010 13:29:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-199--161141460 From: Dick Hardt In-Reply-To: Date: Sat, 10 Jul 2010 13:29:29 -0700 Message-Id: <3FF0C06C-6707-4D4C-ACB5-5D9D68C03C6D@gmail.com> References: <1C84C062-6E34-4C89-85C8-5809581A02CC@gmail.com> To: David Recordon X-Mailer: Apple Mail (2.1078) Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jul 2010 20:29:33 -0000 --Apple-Mail-199--161141460 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-07-10, at 1:21 PM, David Recordon wrote: > On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt = wrote: > On 2010-07-10, at 9:58 AM, Paul Tarjan wrote: >> Hi OAuthers, >>=20 >> First of all, I think I should introduce myself. I work at Facebook = on the Platform team (anything not facebook.com). Before this I was at = Yahoo! doing SearchMonkey (semantic web stuff). I've written a few OAuth = applications and libraries, both at Yahoo and in my spare time. =20 >>=20 >> For Facebook apps we're going to use your signature scheme with the = following changes: >=20 > I would hope you would think it is "our" signature scheme rather than = "your" signature scheme >=20 > I think Paul was referring to the proposal Dirk put forward since = there isn't anything which has become part of OAuth yet. ;) The email was addressed to "OAuthers" -- I would hope that Paul would = soon consider himself one of those! >=20 >> * the signature comes before the payload >> * we used the key 'algorithm' instead of 'alg' and 'expires' instead = of 'not_before' >=20 > Good points to add to the discussion. Perhaps you would articulate why = you made those choices? >=20 > I think Naitik talked about the signature coming before the payload in = this thread. Through implementations we've found that lsplit is easier = in some languages. I think having an envelope as the first blob enables a parser to know = what to do with the rest of the blobs, and that this trumps the mionor = lsplit argument. >=20 > The benefit of using 'alg' is unclear compared to spelling out the = word 'algorithm' which adds clarity for developers. Agree that 'algorithm' is easier to understand and preferable to 'alg' -- Dick --Apple-Mail-199--161141460 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 2010-07-10, at 1:21 PM, David Recordon wrote:

On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
On 2010-07-10, at 9:58 AM, Paul Tarjan wrote:
Hi OAuthers,

First of all, I think I should introduce myself. I work at Facebook on the Platform team (anything not facebook.com). Before this I was at Yahoo! doing SearchMonkey (semantic web stuff). I've written a few OAuth applications and libraries, both at Yahoo and in my spare time.  

For Facebook apps we're going to use your signature scheme with the following changes:

I would hope you would think it is "our" signature scheme rather than "your" signature scheme

I think Paul was referring to the proposal Dirk put forward since there isn't anything which has become part of OAuth yet. ;)

The email was addressed to "OAuthers" -- I would hope that Paul would soon consider himself one of those!


* the signature comes before the payload
* we used the key 'algorithm' instead of 'alg' and 'expires' instead of 'not_before'

Good points to add to the discussion. Perhaps you would articulate why you made those choices?

I think Naitik talked about the signature coming before the payload in this thread. Through implementations we've found that lsplit is easier in some languages.

I think having an envelope as the first blob enables a parser to know what to do with the rest of the blobs, and that this trumps the mionor lsplit argument.


The benefit of using 'alg' is unclear compared to spelling out the word 'algorithm' which adds clarity for developers.

Agree that 'algorithm' is easier to understand and preferable to 'alg'

-- Dick

--Apple-Mail-199--161141460-- From recordond@gmail.com Sat Jul 10 13:42: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 76F243A6802 for ; Sat, 10 Jul 2010 13:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.409, 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 NFf+QoZRkYg4 for ; Sat, 10 Jul 2010 13:42:02 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 842EB3A676A for ; Sat, 10 Jul 2010 13:42:02 -0700 (PDT) Received: by iwn38 with SMTP id 38so3544189iwn.31 for ; Sat, 10 Jul 2010 13:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=VWrWOYEu0nhs+afoUk0LP7sl6LRu5BKZoipQC+EXmbQ=; b=Bq2ZI+D5P3a1yj+ZtIWfs/+j+09wDp1klbkzwwdmvXvSbdN9CNCTAnZIr4yW3hZ+Ip zJtEFN2Qu+cYOCzzwz2i9fkqHjDhv9F+Jufrn80V892YNI3wzdQSQt7B3QyDfFWcSyqe pbnSLfwgQGG0P6SAoQVMYCXQ5UCOmbJiYf0LE= 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=qsTuyM9k0Ji5c5SA4vgu2OIlRPSf/oDXwd4VdufdAbxjflj5wB4jYoZluqtEgmv4tf 142tg7vu9NvZw/Xdu4oCiQzqWxyxhVH2u3utwZNSDHnmHExXmvGPM8dGkAcbpWM+F7Zo PHmMjlZms3xn09o52lmaEW1BB8fbYD6PWLBWc= MIME-Version: 1.0 Received: by 10.231.149.203 with SMTP id u11mr11783564ibv.6.1278794528461; Sat, 10 Jul 2010 13:42:08 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Sat, 10 Jul 2010 13:42:08 -0700 (PDT) In-Reply-To: <3FF0C06C-6707-4D4C-ACB5-5D9D68C03C6D@gmail.com> References: <1C84C062-6E34-4C89-85C8-5809581A02CC@gmail.com> <3FF0C06C-6707-4D4C-ACB5-5D9D68C03C6D@gmail.com> Date: Sat, 10 Jul 2010 13:42:08 -0700 Message-ID: From: David Recordon To: Dick Hardt Content-Type: multipart/alternative; boundary=0050450146f39c1273048b0e8dbb Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jul 2010 20:42:03 -0000 --0050450146f39c1273048b0e8dbb Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 10, 2010 at 1:29 PM, Dick Hardt wrote: > On 2010-07-10, at 1:21 PM, David Recordon wrote: > > On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt wrote: > > * the signature comes before the payload >> * we used the key 'algorithm' instead of 'alg' and 'expires' instead of >> 'not_before' >> >> >> Good points to add to the discussion. Perhaps you would articulate why you >> made those choices? >> > > I think Naitik talked about the signature coming before the payload in this > thread. Through implementations we've found that lsplit is easier in some > languages. > > > I think having an envelope as the first blob enables a parser to know what > to do with the rest of the blobs, and that this trumps the mionor lsplit > argument. > And we think that adding an envelope creates unnecessary complexity for both server and client developers for the signature use cases. --David --0050450146f39c1273048b0e8dbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jul 10, 2010 at 1:29 PM, Dick Hardt <dick.hardt@gmail.com> wrote:=
On 2010-07-= 10, at 1:21 PM, David Recordon wrote:
On Sat= , Jul 10, 2010 at 11:00 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
<= div>
* the signature comes before the payload
* we used the key 'algorithm' instead of 'alg' and &#= 39;expires' instead of 'not_before'

Good points to add to the disc= ussion. Perhaps you would articulate why you made those choices?

I think Naitik talked about the sig= nature coming before the payload in this thread. Through implementations we= 've found that lsplit is=A0easier=A0in some languages.

I think having an envelope as = the first blob enables a parser to know what to do with the rest of the blo= bs, and that this trumps the mionor lsplit argument.

And we think that adding an=A0envelope=A0creates=A0unne= cessary=A0complexity for both server and client developers for the signatur= e use cases.

--David

--0050450146f39c1273048b0e8dbb-- From dick.hardt@gmail.com Sat Jul 10 14:22: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 1C77C3A67FB for ; Sat, 10 Jul 2010 14:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SudeYYQYLQ3O for ; Sat, 10 Jul 2010 14:22:31 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 2B8C33A687F for ; Sat, 10 Jul 2010 14:22:31 -0700 (PDT) Received: by pxi20 with SMTP id 20so1614962pxi.31 for ; Sat, 10 Jul 2010 14:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=RuCqoex5sOUSJXusrAssQKqLNAkIVFi5zJIu9A3psT8=; b=MrjGVMJ+c+n5XM9xWxvUlYjCTqvYRlC9OnXltBfL3s1K9ihBmjWWhNwdQbKkWyJn9C 2cBpB1MgZJT5agpKRKQ2vuaaGoKYk8G+ZgwD/M7R600jY1w0mgI5/EKGL9dOyX2gezBw IB8JIa0htKqZms+RfA2UF2t/MX5u2LxYuY/BY= 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=A3PMzq9tHyTR39nuyodD8fySYoBpm0wJAIQRKv0tfqlHVafoBPfv33OdhDnxuybktr jrAwWIpdDr9jtOJxEXQ/WN7S3xYuuiavr1ALZdAg7rzhQB4EC6nkPIjKyfjnlKh++JMC BVR1XULbt+eptGE36K91J6S07GIolYO5nZD9g= Received: by 10.142.169.12 with SMTP id r12mr12154645wfe.11.1278796954393; Sat, 10 Jul 2010 14:22:34 -0700 (PDT) Received: from [192.168.1.2] ([24.130.32.55]) by mx.google.com with ESMTPS id t11sm2791304wfc.4.2010.07.10.14.22.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 10 Jul 2010 14:22:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-200--157959041 From: Dick Hardt In-Reply-To: Date: Sat, 10 Jul 2010 14:22:31 -0700 Message-Id: References: <1C84C062-6E34-4C89-85C8-5809581A02CC@gmail.com> <3FF0C06C-6707-4D4C-ACB5-5D9D68C03C6D@gmail.com> To: David Recordon X-Mailer: Apple Mail (2.1078) Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jul 2010 21:22:32 -0000 --Apple-Mail-200--157959041 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-07-10, at 1:42 PM, David Recordon wrote: > On Sat, Jul 10, 2010 at 1:29 PM, Dick Hardt = wrote: > On 2010-07-10, at 1:21 PM, David Recordon wrote: >> On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt = wrote: >=20 >>> * the signature comes before the payload >>> * we used the key 'algorithm' instead of 'alg' and 'expires' instead = of 'not_before' >>=20 >> Good points to add to the discussion. Perhaps you would articulate = why you made those choices? >>=20 >> I think Naitik talked about the signature coming before the payload = in this thread. Through implementations we've found that lsplit is = easier in some languages. >=20 > I think having an envelope as the first blob enables a parser to know = what to do with the rest of the blobs, and that this trumps the mionor = lsplit argument. >=20 > And we think that adding an envelope creates unnecessary complexity = for both server and client developers for the signature use cases. Obviously anything besides what you need for your use case adds = complexity. The question is: are you willing to accept some complexity = so that it works for use cases than yours? If not, then perhaps you = should just define your own signature mechanism. I don't see parsing two base64url encoded JSON strings as being that = much more complex than parsing one. Repeating one step that then enables = extensibility for the future as to how to parse the rest of the token, = and enables the same code to look at encrypted tokens in addition to = tokens that have only been signed. The alternative is the client and = server have to know ahead of time what is being sent and can't mix them = -- that adds complexity later on. -- Dick --Apple-Mail-200--157959041 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Sat, Jul 10, 2010 at 1:29 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:
On = 2010-07-10, at 1:21 PM, David Recordon wrote:
On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt <dick.hardt@gmail.com> = wrote:
* the signature comes before the = payload
* we used the key 'algorithm' instead of 'alg' and = 'expires' instead of 'not_before'

Good points to add to the = discussion. Perhaps you would articulate why you made those = choices?

I think = Naitik talked about the signature coming before the payload in this = thread. Through implementations we've found that lsplit = is easier in some languages.

I think having an envelope = as the first blob enables a parser to know what to do with the rest of = the blobs, and that this trumps the mionor lsplit = argument.

And we think that adding = an envelope creates unnecessary complexity for both = server and client developers for the signature use = cases.

Obviously anything besides = what you need for your use case adds complexity. The question is: are = you willing to accept some complexity so that it works for use cases = than yours? If not, then perhaps you should just define your own = signature mechanism.

I don't see parsing two = base64url encoded JSON strings as being that much more complex than = parsing one. Repeating one step that then enables extensibility for the = future as to how to parse the rest of the token, and enables the same = code to look at encrypted tokens in addition to tokens that have only = been signed. The alternative is the client and server have to know ahead = of time what is being sent and can't mix them -- that adds complexity = later on.

-- Dick

= --Apple-Mail-200--157959041-- From recordond@gmail.com Sat Jul 10 14:49: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 994FD3A689B for ; Sat, 10 Jul 2010 14:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.341, 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 dijZRG2Sbutd for ; Sat, 10 Jul 2010 14:49:53 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8BADF3A688A for ; Sat, 10 Jul 2010 14:49:53 -0700 (PDT) Received: by iwn38 with SMTP id 38so3574099iwn.31 for ; Sat, 10 Jul 2010 14:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ljZO68pl12mZqkTazG6AX/mg6cScawnHTh6dsK2ta8c=; b=XA/ohFs0exYySWUqbkF3yqdbyYP3dmQlAj3c7u8INcJqvYaybx74pjK2XPUytuYrU/ UITeKq8zSywE/f9ltnxaAsKvjdU/eVwsAvYCweLEANBvS5xWhdz/w1VrkGV0XfhAh/cl hNxC6PP3lXqgjfxr0S37XAyUROn0OyHQpARlo= 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=j3LYWC7Wz6sWa1VG9u0gv+N78Q7N3wB7cJUXWg6oZa3f1GuCB+9MmJOjQWaOSHMSPa JJV4pOXqhVphYYT1oq7p0/0np5g81M+w4MKjchc0AETgntHvyWfcf0n9U2X2G7Hkawyn 8p04w8Hp0KwvBFG5tgm6Za8Vc54Auvz5pUdbI= MIME-Version: 1.0 Received: by 10.231.66.79 with SMTP id m15mr11733055ibi.197.1278798597804; Sat, 10 Jul 2010 14:49:57 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Sat, 10 Jul 2010 14:49:57 -0700 (PDT) In-Reply-To: References: <1C84C062-6E34-4C89-85C8-5809581A02CC@gmail.com> <3FF0C06C-6707-4D4C-ACB5-5D9D68C03C6D@gmail.com> Date: Sat, 10 Jul 2010 14:49:57 -0700 Message-ID: From: David Recordon To: Dick Hardt Content-Type: multipart/alternative; boundary=0015176f0a7e29518b048b0f8079 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jul 2010 21:49:54 -0000 --0015176f0a7e29518b048b0f8079 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 10, 2010 at 2:22 PM, Dick Hardt wrote: > Obviously anything besides what you need for your use case adds complexity. > The question is: are you willing to accept some complexity so that it works > for use cases than yours? If not, then perhaps you should just define your > own signature mechanism. > I think that you misunderstood what I was saying. The use case that Paul described is more limited than the signature use cases for OAuth 2.0. An envelope is not required for the signature use cases for OAuth 2.0. As you pointed out later, it could be required for different use cases of encrypting and signing requests. --David --0015176f0a7e29518b048b0f8079 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 10, 2010 at 2:22 PM, Dick Hardt <dick.hardt@gmail.com> wro= te:
Obviou= sly anything besides what you need for your use case adds complexity. The q= uestion is: are you willing to accept some complexity so that it works for = use cases than yours? If not, then perhaps you should just define your own = signature mechanism.

I think that you m= isunderstood what I was saying. The use case that Paul described is more li= mited than the signature use cases for OAuth 2.0. An envelope is not requir= ed for the signature use cases for OAuth 2.0. As you pointed out later, it = could be required for different use cases of encrypting and signing request= s.

--David
--0015176f0a7e29518b048b0f8079-- From beaton@google.com Sat Jul 10 19:46:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3233A6915 for ; Sat, 10 Jul 2010 19:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.757 X-Spam-Level: X-Spam-Status: No, score=-104.757 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dETfmHs22F+Z for ; Sat, 10 Jul 2010 19:46:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 348A83A6914 for ; Sat, 10 Jul 2010 19:46:39 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o6B2kinj003890 for ; Sat, 10 Jul 2010 19:46:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278816405; bh=bskzuun5QOi61/LI38ekDeF7Bbg=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=ECkyVqzvAtx7lYKw10OF85A8AVFp5XbVrs8ZazamXGWX57He7N6EP0h1gDL9H2F2p z8y9dWilXsrgOOsek3HmQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=ZkG6w5k/gFrhyEZfdbAbaeV7ab0ubD3Z5SBtHjzcOqbzsa2mHNtsTop8TFYhSkkRM Pp9Ty8ytIb+ab49RHw4Ww== Received: from pvc21 (pvc21.prod.google.com [10.241.209.149]) by kpbe14.cbf.corp.google.com with ESMTP id o6B2khX1029341 for ; Sat, 10 Jul 2010 19:46:44 -0700 Received: by pvc21 with SMTP id 21so1579068pvc.7 for ; Sat, 10 Jul 2010 19:46:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.225.8 with SMTP id x8mr14077170wfg.291.1278816403155; Sat, 10 Jul 2010 19:46:43 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sat, 10 Jul 2010 19:46:43 -0700 (PDT) Date: Sat, 10 Jul 2010 19:46:43 -0700 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] "access grant" terminology X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 02:46:41 -0000 The term "access grant" in the -09 spec is a bit odd. Normally "access grant" or "permission grant" would refer to a specific policy decision made by a resource owner. But that's not how the -09 spec uses the term. The -09 spec refers to authorization codes and assertions as "access grants". Again, that's weird. Normally an assertion would be referred to as a "credential", not a grant. I think the term "authorization credential" might be a better fit than "access grant". It certainly describes the purpose of the authorization code and the assertion. And the term "credential" is normally used to describe things that need to be verified and protected. Cheers, Brian From eran@hueniverse.com Sat Jul 10 20:03:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E24C3A6909 for ; Sat, 10 Jul 2010 20:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329, 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 wma60WKMCfnZ for ; Sat, 10 Jul 2010 20:03:49 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 4DD8C3A68D9 for ; Sat, 10 Jul 2010 20:03:49 -0700 (PDT) Received: (qmail 6705 invoked from network); 11 Jul 2010 03:03:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 03:03:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 10 Jul 2010 20:03:54 -0700 From: Eran Hammer-Lahav To: Brian Eaton , OAuth WG Date: Sat, 10 Jul 2010 20:03:52 -0700 Thread-Topic: [OAUTH-WG] "access grant" terminology Thread-Index: Acsgo1IqSaP1dBzARzCLBHb7zz8NFwAAl688 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] "access grant" terminology X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 03:03:50 -0000 On 7/10/10 7:46 PM, "Brian Eaton" wrote: > The term "access grant" in the -09 spec is a bit odd. Normally > "access grant" or "permission grant" would refer to a specific policy > decision made by a resource owner. >=20 > But that's not how the -09 spec uses the term. The -09 spec refers to > authorization codes and assertions as "access grants". Again, that's > weird. Normally an assertion would be referred to as a "credential", > not a grant. Access grant is something that represents the decision made by the resource owner. If the resource owner approves access, it is represented by a authorization code. If the resource owner shares its password, it is equivalent to unlimited access grant. I coined the term based on common language, not on any existing terminology= . If there is a real conflict here, I am happy to consider another term, but it doesn't sound like this is the case, or that the term is used against it= s meaning. > I think the term "authorization credential" might be a better fit than > "access grant". >=20 > It certainly describes the purpose of the authorization code and the > assertion. And the term "credential" is normally used to describe > things that need to be verified and protected. I think authorization credential is going to confuse most readers. The spec refers to credentials almost exclusively when dealing with identifier and password (client, end-user), or as a general term for client authentication= . Authorization is specific to the end-user authorization endpoint and will b= e confusing when used with assertions and other grant types. So I'm open to other ideas but not this one. Note that since this term impacts the name of the current 'grant_type' parameter, changing it means code changes. If anyone has a last minute idea please share (or if you are happy with the current grant type). I expect it to be annoying to change once -10 is stabl= e for 4 weeks. EHL From beaton@google.com Sat Jul 10 20:09:16 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C585C3A68D9 for ; Sat, 10 Jul 2010 20:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.471 X-Spam-Level: X-Spam-Status: No, score=-105.471 tagged_above=-999 required=5 tests=[AWL=0.506, 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 sExQ8YYrZPdj for ; Sat, 10 Jul 2010 20:09:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B0C283A66B4 for ; Sat, 10 Jul 2010 20:09:15 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o6B39Lv6026887 for ; Sat, 10 Jul 2010 20:09:22 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278817762; bh=9iPp8Xmp3ZKN14JvzRxhNcmRm90=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=p9mkY9wkigbOFYc71PoYGWIVBpcp6+7IGTQ0yuchTj364F8IIa9v8AMoE0Zu+f5Gg X7kCvwianEUwb/KHh6PCw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=X0j/1NITu3JeBgUzt4zadTrv5oAm8WjZAXBZshIfyTvXdTUvKc4NNx6xJ/nDyB9Md rrtPPZ4KM9Nba33+4zWZA== Received: from pwj8 (pwj8.prod.google.com [10.241.219.72]) by kpbe14.cbf.corp.google.com with ESMTP id o6B39KNU011362 for ; Sat, 10 Jul 2010 20:09:21 -0700 Received: by pwj8 with SMTP id 8so1354628pwj.9 for ; Sat, 10 Jul 2010 20:09:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.207.9 with SMTP id e9mr428685wfg.56.1278817760480; Sat, 10 Jul 2010 20:09:20 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sat, 10 Jul 2010 20:09:20 -0700 (PDT) Date: Sat, 10 Jul 2010 20:09:20 -0700 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] client credentials returning a refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 03:09:16 -0000 Hey folks - The client credentials flow should never return a refresh token, for the following reasons: - it's never necessary - it's a security problem - it's inefficient - it's confusing I'll go over each of those points in detail, but here are the changes to the spec I'd like to see. Page 8: diagram shows "with optional refresh token". Delete that. Somewhere in document: add a specific description of the client_id + client_secret produces access_token equation. (This seems to have been dropped in draft 7... or am I missing something?) Here are the detailed reasons why the refresh token in this flow is a bad idea. 1) it's never necessary In order to use a refresh token to get a new access token, you need to present a client-id and a client-secret. If you have a client-id and client-secret, you can just use the client credentials flow to get a new access token. So keeping the refresh token around serves no purpose. 2) it's a security problem Creating a refresh token is roughly equivalent to creating an alternate password (client secret) for the client. It's one more secret that needs to be protected. When a client using the client credentials flow is compromised, you need to reset their client secret to recover. But because this profile is creating refresh tokens, you also need to go and revoke all of the refresh tokens. 3) it's inefficient Refresh tokens are long-lived secrets. They need server-side storage. So every single time a client authenticates, you're going to have to allocate long-lived storage associated with that authentication. 4) it's confusing The spec offers no guidance as to when servers should return refresh tokens, or what clients ought to do with them. This is basically a trap. From beaton@google.com Sat Jul 10 20:12: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 D48493A68DC for ; Sat, 10 Jul 2010 20:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.522 X-Spam-Level: X-Spam-Status: No, score=-105.522 tagged_above=-999 required=5 tests=[AWL=0.455, 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 XkkslP3tAgux for ; Sat, 10 Jul 2010 20:11:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 7CB883A68D9 for ; Sat, 10 Jul 2010 20:11:58 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o6B3C4oo002556 for ; Sat, 10 Jul 2010 20:12:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278817924; bh=xFXMgXkIPyPilWu0mVIfm/S+DOA=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=MdcI4vzwC9cH4/cdEJThjLSXLEZSQZtulB26zk3p/rpoNv1o2YSZaQRLYElSpcXRP +5Uoz6bDkHGkTSxXVuUhg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=wmQNycQ6dVpKgN2V8CRIlpJObibmCx6yYwCWlaDu+hP5Knq2Czq/LfV8c23PGWEPL 2CaL/5TCDa8v4h9JvyVwQ== Received: from pwi8 (pwi8.prod.google.com [10.241.219.8]) by kpbe17.cbf.corp.google.com with ESMTP id o6B3C3Ji021865 for ; Sat, 10 Jul 2010 20:12:04 -0700 Received: by pwi8 with SMTP id 8so1328925pwi.28 for ; Sat, 10 Jul 2010 20:12:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.171.9 with SMTP id t9mr9497668wfe.257.1278817923386; Sat, 10 Jul 2010 20:12:03 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sat, 10 Jul 2010 20:12:03 -0700 (PDT) Date: Sat, 10 Jul 2010 20:12:03 -0700 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] client credentials flow got dropped? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 03:12:00 -0000 Hi folks - Draft 6 section 2.9.1 had a section called "Client Requests Access Token": http://tools.ietf.org/html/draft-ietf-oauth-v2-06#page-34. In this flow a client presented a client_id and client_secret, and got an access token in return. I can't find the corresponding section in draft 7. It looks like the rewrite dropped this flow. Am I missing something? If this really did get dropped, please add it back. In terms of normative language, the language in the draft 6 spec was great. The only change to that is to drop the refresh token, since it provides no value. I've already sent another note about that. Cheers, Brian From eran@hueniverse.com Sat Jul 10 20:13:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD2E3A68DC for ; Sat, 10 Jul 2010 20:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.315, 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 fhJPnSZTtlgu for ; Sat, 10 Jul 2010 20:13:49 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 85B893A68D9 for ; Sat, 10 Jul 2010 20:13:49 -0700 (PDT) Received: (qmail 18512 invoked from network); 11 Jul 2010 03:13:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 03:13:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 10 Jul 2010 20:13:55 -0700 From: Eran Hammer-Lahav To: Brian Eaton , OAuth WG Date: Sat, 10 Jul 2010 20:13:52 -0700 Thread-Topic: [OAUTH-WG] client credentials returning a refresh token Thread-Index: AcsgpnhqmBmwvBa8R+GFgzOa90//9wAAJ4jN Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85E850036FA9eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] client credentials returning a refresh token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 03:13:51 -0000 --_000_C85E850036FA9eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How about write some new text about what refresh tokens are for and when th= ey should be issued. I think this can benefit from its own section. The res= t is mostly editorial. EHL On 7/10/10 8:09 PM, "Brian Eaton" wrote: Hey folks - The client credentials flow should never return a refresh token, for the following reasons: - it's never necessary - it's a security problem - it's inefficient - it's confusing I'll go over each of those points in detail, but here are the changes to the spec I'd like to see. Page 8: diagram shows "with optional refresh token". Delete that. Somewhere in document: add a specific description of the client_id + client_secret produces access_token equation. (This seems to have been dropped in draft 7... or am I missing something?) Here are the detailed reasons why the refresh token in this flow is a bad i= dea. 1) it's never necessary In order to use a refresh token to get a new access token, you need to present a client-id and a client-secret. If you have a client-id and client-secret, you can just use the client credentials flow to get a new access token. So keeping the refresh token around serves no purpose. 2) it's a security problem Creating a refresh token is roughly equivalent to creating an alternate password (client secret) for the client. It's one more secret that needs to be protected. When a client using the client credentials flow is compromised, you need to reset their client secret to recover. But because this profile is creating refresh tokens, you also need to go and revoke all of the refresh tokens. 3) it's inefficient Refresh tokens are long-lived secrets. They need server-side storage. So every single time a client authenticates, you're going to have to allocate long-lived storage associated with that authentication. 4) it's confusing The spec offers no guidance as to when servers should return refresh tokens, or what clients ought to do with them. This is basically a trap. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C85E850036FA9eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] client credentials returning a refresh token How about write some new text about what refresh tokens are for and w= hen they should be issued. I think this can benefit from its own section. T= he rest is mostly editorial.

EHL


On 7/10/10 8:09 PM, "Brian Eaton" <beaton@google.com> wrote:

Hey folks -

The client credentials flow should never return a refresh token, for
the following reasons:

- it's never necessary
- it's a security problem
- it's inefficient
- it's confusing

I'll go over each of those points in detail, but here are the changes
to the spec I'd like to see.

Page 8: diagram shows "with optional refresh token".  Delete= that.
Somewhere in document: add a specific description of the client_id +
client_secret produces access_token equation.  (This seems to have
been dropped in draft 7... or am I missing something?)


Here are the detailed reasons why the refresh token in this flow is a bad i= dea.

1) it's never necessary

In order to use a refresh token to get a new access token, you need to
present a client-id and a client-secret.

If you have a client-id and client-secret, you can just use the client
credentials flow to get a new access token.

So keeping the refresh token around serves no purpose.

2) it's a security problem

Creating a refresh token is roughly equivalent to creating an
alternate password (client secret) for the client.  It's one more
secret that needs to be protected.

When a client using the client credentials flow is compromised, you
need to reset their client secret to recover.  But because this
profile is creating refresh tokens, you also need to go and revoke all
of the refresh tokens.

3) it's inefficient

Refresh tokens are long-lived secrets.  They need server-side storage.=
 So every single time a client authenticates, you're going to have to<= BR> allocate long-lived storage associated with that authentication.

4) it's confusing

The spec offers no guidance as to when servers should return refresh
tokens, or what clients ought to do with them.

This is basically a trap.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C85E850036FA9eranhueniversecom_-- From eran@hueniverse.com Sat Jul 10 20:16:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7473A68BD for ; Sat, 10 Jul 2010 20:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.302, 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 EyWc9zO4j0Sx for ; Sat, 10 Jul 2010 20:16:23 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 42BEE3A68D9 for ; Sat, 10 Jul 2010 20:16:23 -0700 (PDT) Received: (qmail 20640 invoked from network); 11 Jul 2010 03:16:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 03:16:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 10 Jul 2010 20:16:29 -0700 From: Eran Hammer-Lahav To: Brian Eaton , OAuth WG Date: Sat, 10 Jul 2010 20:16:26 -0700 Thread-Topic: [OAUTH-WG] client credentials flow got dropped? Thread-Index: AcsgptwKrfNPzVWlTYCDmBCv9GMHPwAAJZLg Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85E859A36FADeranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] client credentials flow got dropped? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 03:16:27 -0000 --_000_C85E859A36FADeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable See 'grant_type=3Dnone' described in 4.1. EHL On 7/10/10 8:12 PM, "Brian Eaton" wrote: Hi folks - Draft 6 section 2.9.1 had a section called "Client Requests Access Token": http://tools.ietf.org/html/draft-ietf-oauth-v2-06#page-34. In this flow a client presented a client_id and client_secret, and got an access token in return. I can't find the corresponding section in draft 7. It looks like the rewrite dropped this flow. Am I missing something? If this really did get dropped, please add it back. In terms of normative language, the language in the draft 6 spec was great. The only change to that is to drop the refresh token, since it provides no value. I've already sent another note about that. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C85E859A36FADeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] client credentials flow got dropped? See ‘grant_type=3Dnone’ described in 4.1.

EHL


On 7/10/10 8:12 PM, "Brian Eaton" <beaton@google.com> wrote:

Hi folks -

Draft 6 section 2.9.1 had a section called "Client Requests Access
Token": http://tools.ietf.org/html/draft-ietf-oauth-v2-06#page-34.

In this flow a client presented a client_id and client_secret, and got
an access token in return.

I can't find the corresponding section in draft 7.  It looks like the<= BR> rewrite dropped this flow.  Am I missing something?

If this really did get dropped, please add it back.

In terms of normative language, the language in the draft 6 spec was
great.  The only change to that is to drop the refresh token, since it=
provides no value.  I've already sent another note about that.

Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C85E859A36FADeranhueniversecom_-- From beaton@google.com Sat Jul 10 20:55: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 077813A68D9 for ; Sat, 10 Jul 2010 20:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.47 X-Spam-Level: X-Spam-Status: No, score=-100.47 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6TmNaMtr3uq for ; Sat, 10 Jul 2010 20:55:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 65EEF3A6827 for ; Sat, 10 Jul 2010 20:55:03 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o6B3t9D5012247 for ; Sat, 10 Jul 2010 20:55:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278820509; bh=x3nYA29hboWLmHq5VD7ilvgNRD8=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=QhGZnTt6BjlaIJPd9nKIuccUDazzMPv+qVKrbI0g4wHi5qpao+16JKgnZY21XWh1h /Qi0yfFEKPi6GlNRg/1zw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=Iy5TlFZznGwUUTig/tlvXDcIOSRoboKmNeHiUTbQjuw3QnEtG7k6KEDYASRMcKOgw 8ckUoXmMcIeVcKAGXvwgQ== Received: from pvc7 (pvc7.prod.google.com [10.241.209.135]) by hpaq5.eem.corp.google.com with ESMTP id o6B3t7CM006496 for ; Sat, 10 Jul 2010 20:55:08 -0700 Received: by pvc7 with SMTP id 7so1313087pvc.5 for ; Sat, 10 Jul 2010 20:55:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.133.12 with SMTP id g12mr2837488wfd.118.1278820506843; Sat, 10 Jul 2010 20:55:06 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sat, 10 Jul 2010 20:55:06 -0700 (PDT) Date: Sat, 10 Jul 2010 20:55:06 -0700 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 03:55:05 -0000 The draft 9 spec has no efficient way for a javascript client to request a verification code. The spec creates extra client-to-server round trips. There is also some inaccurate description of the properties of the profile. The problems are located in section 1.4.2: http://tools.ietf.org/html/draft-ietf-oauth-v2-09#page-11. The spec requires that the verification code is always returned on the query string. This ends up busting the browser cache and creating an extra client-to-server round trip. It basically defeats the purpose of the user-agent profile entirely. (If you could afford an extra client-to-server round trip, you would just use the web server flow.) To clarify, here's how the flow works in practice: client web site loads relay page is loaded from the client web site. This page is typically heavily cached. It is almost always loaded from browser cache; it is very rarely actually fetched from the server, for performance reasons. client web site redirects browser to authorization server authorization server redirects back to relay page, with new data on the fragment there is no client-to-server round trip*. the client javascript is loaded from cache, and parses the fragment data if necessary, the client javascript uses XMLHttpRequest (XHR) to pass data up to the web server. This typically happens in the background, however, while the user is otherwise interacting with the web application. Here's what would happen if someone implemented the spec as written, though: client web site loads relay page is loaded from the client web site. This page is typically heavily cached. It is almost always loaded from browser cache; it is very rarely actually fetched from the server, for performance reasons. client web site redirects browser to authorization server authorization server redirects back to relay page, with new data on the fragment, *plus a verification code on the query string* *browser fetches new copy of relay page from web server* *user sits and waits* *kittens die when users have to wait* There are also several problems with the description of the flow. Most of the description seems to be left over from the time when the flow was spec'ed to only return an access token. Now that it can return a verification code, sentences like "does not utilize the client secret" are no longer true. The phrase "because the access token is encoded into the redirection URI, it may be exposed to the end-user and other applications residing on the computer" is just silly. That's equally true of the web server flow. So basically I think section 1.4.2 needs a rewrite, starting with the entire justification of the flow. Here's a brief description of how the flow should work: client web site loads client redirects to authorization server with: type="user_agent" client_id=client identifier redirect_uri=absolute URL on client web site response_type="code-and-token" or "token" (The client chooses the response type based on whether they want long-lived access or short-lived access to the user's data. Short-lived: just use "token".) authorization server confirms user consent (which might or might not require user interaction...) authorization server confirms redirect_uri is associated with the client_id. authorization server redirects to redirect_uri, with all of the return parameters on the URL fragment. Here's my proposed text for section 1.4.2. The user-agent profile is suitable for client applications residing in a user-agent, typically implemented in a browser using a scripting language such as JavaScript. These clients typically have strict latency requirements, and must be implemented using a minimum number of client-to-server calls. The client may have supporting code running on a web server. Authentication of the client-side components is based on the redirect URI and the user-agent's same-origin policy. Authentication of the server-side components is based on the client secret. Unlike other profiles, the user-agent profile returns data on the client on the URI fragment. In addition, the user-agent profile returns an access token directly on the redirect URI, to reduce the number of round trips required before the client can use the token. The client is able to immediately use the token to communicate to resource servers, using client-side cross-domain communication techniques such as window.postMessage, jsonp, and iframes. [Maybe just mention iframes here, better not to clutter the spec with references to all of the ways around same-origin...) Figure 5: this probably needs to change so that it looks more like Figure 4. Changes from Figure 4 would be: Step (C) returns access token and optional verification code New step (D): client using the access token directly with a resource server. Old step D becomes step E, but otherwise looks the same. Except it is optional. Step E: if this step occurs, refresh token is no longer optional More normative language (largely based on merging the user-agent language with the web-server language.) The user-agent flow illustrated in Figure 5 includes the following steps: (A) [no change] The clients sends the user-agent to the end-user authorization endpoint as described in section 3. The client includes its client identifier, requested scope, local state, and a redirect URI to which the authorization server will send the end-user back once authorization is granted. (B) [no change] (C) If the end-user granted access, the authorization server redirects the user-agent to the redirection URI provided earlier. The redirection URI includes the access token, and optional verification code, in the URI fragment. (D) The user-agent follows the redirection instructions by loading the redirection URI. The redirection URI is typically a heavily cached web page, so this is unlikely to result in an additional client to server round trip. (E) The client code parses the URL fragment to retrieve the access token and optional authorization code. (F) The client uses the access token to contact resource servers. (G) In parallel, the client passes the authorization code to the client's server side components. (H) The client's server-side components request an access token and refresh token from the authorization server by authenticating and including the authorization code received in the previous step. (I) The authorization server validates the client credentials and the authorization code and responds back with the refresh token and access token. Rest of the spec doesn't look like it needs to change much. Section 4.1.1. "Authorization Code" needs some modifications to make it clear that the redirect_uri sent to the authorization server MUST include any fragment included on the original authorization request. redirect_uri REQUIRED. The redirection URI used in the initial request. If the client included a URI fragment on the redirect_uri sent to the authorization server on the authorization request, the client MUST include the same URI fragment here. Cheers, Brian From eran@hueniverse.com Sat Jul 10 21:05: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 864A43A680A for ; Sat, 10 Jul 2010 21:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=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 GnSew6xCnKUW for ; Sat, 10 Jul 2010 21:05:01 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D9C563A6403 for ; Sat, 10 Jul 2010 21:05:00 -0700 (PDT) Received: (qmail 28491 invoked from network); 11 Jul 2010 04:05:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 04:05:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 10 Jul 2010 21:05:05 -0700 From: Eran Hammer-Lahav To: Brian Eaton , OAuth WG Date: Sat, 10 Jul 2010 21:05:01 -0700 Thread-Topic: [OAUTH-WG] user-agent flow needs a rewrite Thread-Index: AcsgrN8i8iqpLUyyShyLnR6W/frLfAAAVys4 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85E90FD36FB3eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 04:05:13 -0000 --_000_C85E90FD36FB3eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There is no user-agent flow anymore. There is a profile (of the generic end= points described in the rest of the spec). Draft -09 added the ability to g= et both an authorization code and an access token. Your description makes i= t sound like draft -09 broke something when it was never proposed that a us= er-agent will obtain an authorization code. The request was to allow it to = obtain both when using a web-based component together with the user-agent. I am not arguing against your points, just that the premise of your issue i= s new and was not previously discussed as a requirement (ability of user-ag= ent to obtain authorization codes and use a client secret to get an access = token). EHL On 7/10/10 8:55 PM, "Brian Eaton" wrote: The draft 9 spec has no efficient way for a javascript client to request a verification code. The spec creates extra client-to-server round trips. There is also some inaccurate description of the properties of the profile. The problems are located in section 1.4.2: http://tools.ietf.org/html/draft-ietf-oauth-v2-09#page-11. The spec requires that the verification code is always returned on the query string. This ends up busting the browser cache and creating an extra client-to-server round trip. It basically defeats the purpose of the user-agent profile entirely. (If you could afford an extra client-to-server round trip, you would just use the web server flow.) To clarify, here's how the flow works in practice: client web site loads relay page is loaded from the client web site. This page is typically heavily cached. It is almost always loaded from browser cache; it is very rarely actually fetched from the server, for performance reasons. client web site redirects browser to authorization server authorization server redirects back to relay page, with new data on the fra= gment there is no client-to-server round trip*. the client javascript is loaded from cache, and parses the fragment data if necessary, the client javascript uses XMLHttpRequest (XHR) to pass data up to the web server. This typically happens in the background, however, while the user is otherwise interacting with the web application. Here's what would happen if someone implemented the spec as written, though= : client web site loads relay page is loaded from the client web site. This page is typically heavily cached. It is almost always loaded from browser cache; it is very rarely actually fetched from the server, for performance reasons. client web site redirects browser to authorization server authorization server redirects back to relay page, with new data on the fragment, *plus a verification code on the query string* *browser fetches new copy of relay page from web server* *user sits and waits* *kittens die when users have to wait* There are also several problems with the description of the flow. Most of the description seems to be left over from the time when the flow was spec'ed to only return an access token. Now that it can return a verification code, sentences like "does not utilize the client secret" are no longer true. The phrase "because the access token is encoded into the redirection URI, it may be exposed to the end-user and other applications residing on the computer" is just silly. That's equally true of the web server flow. So basically I think section 1.4.2 needs a rewrite, starting with the entire justification of the flow. Here's a brief description of how the flow should work: client web site loads client redirects to authorization server with: type=3D"user_agent" client_id=3Dclient identifier redirect_uri=3Dabsolute URL on client web site response_type=3D"code-and-token" or "token" (The client chooses the response type based on whether they want long-lived access or short-lived access to the user's data. Short-lived: just use "token".) authorization server confirms user consent (which might or might not require user interaction...) authorization server confirms redirect_uri is associated with the client_id= . authorization server redirects to redirect_uri, with all of the return parameters on the URL fragment. Here's my proposed text for section 1.4.2. The user-agent profile is suitable for client applications residing in a user-agent, typically implemented in a browser using a scripting language such as JavaScript. These clients typically have strict latency requirements, and must be implemented using a minimum number of client-to-server calls. The client may have supporting code running on a web server. Authentication of the client-side components is based on the redirect URI and the user-agent's same-origin policy. Authentication of the server-side components is based on the client secret. Unlike other profiles, the user-agent profile returns data on the client on the URI fragment. In addition, the user-agent profile returns an access token directly on the redirect URI, to reduce the number of round trips required before the client can use the token. The client is able to immediately use the token to communicate to resource servers, using client-side cross-domain communication techniques such as window.postMessage, jsonp, and iframes. [Maybe just mention iframes here, better not to clutter the spec with references to all of the ways around same-origin...) Figure 5: this probably needs to change so that it looks more like Figure 4. Changes from Figure 4 would be: Step (C) returns access token and optional verification code New step (D): client using the access token directly with a resource server= . Old step D becomes step E, but otherwise looks the same. Except it is opti= onal. Step E: if this step occurs, refresh token is no longer optional More normative language (largely based on merging the user-agent language with the web-server language.) The user-agent flow illustrated in Figure 5 includes the following steps: (A) [no change] The clients sends the user-agent to the end-user authorization endpoint as described in section 3. The client includes its client identifier, requested scope, local state, and a redirect URI to which the authorization server will send the end-user back once authorization is granted. (B) [no change] (C) If the end-user granted access, the authorization server redirects the user-agent to the redirection URI provided earlier. The redirection URI includes the access token, and optional verification code, in the URI fragment. (D) The user-agent follows the redirection instructions by loading the redirection URI. The redirection URI is typically a heavily cached web page, so this is unlikely to result in an additional client to server round trip. (E) The client code parses the URL fragment to retrieve the access token and optional authorization code. (F) The client uses the access token to contact resource servers. (G) In parallel, the client passes the authorization code to the client's server side components. (H) The client's server-side components request an access token and refresh token from the authorization server by authenticating and including the authorization code received in the previous step. (I) The authorization server validates the client credentials and the authorization code and responds back with the refresh token and access token. Rest of the spec doesn't look like it needs to change much. Section 4.1.1. "Authorization Code" needs some modifications to make it clear that the redirect_uri sent to the authorization server MUST include any fragment included on the original authorization request. redirect_uri REQUIRED. The redirection URI used in the initial request. If the client included a URI fragment on the redirect_uri sent to the authorization server on the authorization request, the client MUST include the same URI fragment here. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C85E90FD36FB3eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] user-agent flow needs a rewrite There is no user-agent flow anymore. There is a profile (of the gener= ic endpoints described in the rest of the spec). Draft –09 added the = ability to get both an authorization code and an access token. Your descrip= tion makes it sound like draft –09 broke something when it was never = proposed that a user-agent will obtain an authorization code. The request w= as to allow it to obtain both when using a web-based component together wit= h the user-agent.

I am not arguing against your points, just that the premise of your issue i= s new and was not previously discussed as a requirement (ability of user-ag= ent to obtain authorization codes and use a client secret to get an access = token).

EHL


On 7/10/10 8:55 PM, "Brian Eaton" <beaton@google.com> wrote:

The draft 9 spec has no efficient way for a= javascript client to
request a verification code.  The spec creates extra client-to-server<= BR> round trips.  There is also some inaccurate description of the
properties of the profile.  The problems are located in section 1.4.2:=
http:= //tools.ietf.org/html/draft-ietf-oauth-v2-09#page-11.

The spec requires that the verification code is always returned on the
query string.  This ends up busting the browser cache and creating an<= BR> extra client-to-server round trip.  It basically defeats the purpose of the user-agent profile entirely.  (If you could afford an extra
client-to-server round trip, you would just use the web server flow.)
To clarify, here's how the flow works in practice:

client web site loads
relay page is loaded from the client web site.  This page is typically=
heavily cached.  It is almost always loaded from browser cache; it is<= BR> very rarely actually fetched from the server, for performance reasons.
client web site redirects browser to authorization server
authorization server redirects back to relay page, with new data on the fra= gment
there is no client-to-server round trip*.  the client javascript is loaded from cache, and parses the fragment data
if necessary, the client javascript uses XMLHttpRequest (XHR) to pass
data up to the web server.  This typically happens in the background,<= BR> however, while the user is otherwise interacting with the web
application.

Here's what would happen if someone implemented the spec as written, though= :

client web site loads
relay page is loaded from the client web site.  This page is typically=
heavily cached.  It is almost always loaded from browser cache; it is<= BR> very rarely actually fetched from the server, for performance reasons.
client web site redirects browser to authorization server
authorization server redirects back to relay page, with new data on
the fragment, *plus a verification code on the query string*
*browser fetches new copy of relay page from web server*
*user sits and waits*
*kittens die when users have to wait*


There are also several problems with the description of the flow.
Most of the description seems to be left over from the time when the
flow was spec'ed to only return an access token.  Now that it can
return a verification code, sentences like "does not utilize the
client secret" are no longer true.

The phrase "because the access token is encoded into the redirection URI, it may be exposed to the end-user and other applications residing
on the computer" is just silly.  That's equally true of the web s= erver
flow.

So basically I think section 1.4.2 needs a rewrite, starting with the
entire justification of the flow.

Here's a brief description of how the flow should work:

client web site loads
client redirects to authorization server with:
   type=3D"user_agent"
   client_id=3Dclient identifier
   redirect_uri=3Dabsolute URL on client web site
   response_type=3D"code-and-token" or "token= "  (The client chooses the
response type based on whether they want long-lived access or
short-lived access to the user's data.  Short-lived: just use
"token".)

authorization server confirms user consent (which might or might not
require user interaction...)
authorization server confirms redirect_uri is associated with the client_id= .
authorization server redirects to redirect_uri, with all of the return
parameters on the URL fragment.

Here's my proposed text for section 1.4.2.

The user-agent profile is suitable for client applications residing in
a user-agent, typically implemented in a browser using a scripting
language such as JavaScript.  These clients typically have strict
latency requirements, and must be implemented using a minimum number
of client-to-server calls.  The client may have supporting code
running on a web server.  Authentication of the client-side components=
is based on the redirect URI and the user-agent's same-origin policy.
Authentication of the server-side components is based on the client
secret.

Unlike other profiles, the user-agent profile returns data on the
client on the URI fragment.  In addition, the user-agent profile
returns an access token directly on the redirect URI, to reduce the
number of round trips required before the client can use the token.
The client is able to immediately use the token to communicate to
resource servers, using client-side cross-domain communication
techniques such as window.postMessage, jsonp, and iframes.  [Maybe
just mention iframes here, better not to clutter the spec with
references to all of the ways around same-origin...)

Figure 5: this probably needs to change so that it looks more like
Figure 4.  Changes from Figure 4 would be:

Step (C) returns access token and optional verification code

New step (D): client using the access token directly with a resource server= .

Old step D becomes step E, but otherwise looks the same.  Except it is= optional.

Step E: if this step occurs, refresh token is no longer optional


More normative language (largely based on merging the user-agent
language with the web-server language.)

The user-agent flow illustrated in Figure 5 includes the following steps:
(A) [no change] The clients sends the user-agent to the end-user
authorization endpoint as described in section 3.  The client includes=
its client identifier, requested scope, local state, and a redirect
URI to which the authorization server will send the end-user back once
authorization is granted.

(B) [no change]

(C) If the end-user granted access, the authorization server redirects
the user-agent to the redirection URI provided earlier.  The
redirection URI includes the access token, and optional verification
code, in the URI fragment.

(D) The user-agent follows the redirection instructions by loading the
redirection URI.  The redirection URI is typically a heavily cached web page, so this is unlikely to result in an additional client to
server round trip.

(E) The client code parses the URL fragment to retrieve the access
token and optional authorization code.

(F) The client uses the access token to contact resource servers.

(G) In parallel, the client passes the authorization code to the
client's server side components.

(H) The client's server-side components request an access token and
refresh token from the authorization server by authenticating and
including the authorization code received in the previous step.

(I) The authorization server validates the client credentials and the
authorization code and responds back with the refresh token and access
token.


Rest of the spec doesn't look like it needs to change much.

Section 4.1.1.  "Authorization Code" needs some modification= s to make
it clear that the redirect_uri sent to the authorization server MUST
include any fragment included on the original authorization request.

redirect_uri
         REQUIRED.  The r= edirection URI used in the initial request.
If the client included a URI fragment on the redirect_uri sent to the
authorization server on the authorization request, the client MUST
include the same URI fragment here.


Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C85E90FD36FB3eranhueniversecom_-- From beaton@google.com Sat Jul 10 21:15:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0122F3A696B for ; Sat, 10 Jul 2010 21:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.819 X-Spam-Level: X-Spam-Status: No, score=-104.819 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ethCr-lhW7h for ; Sat, 10 Jul 2010 21:15:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E59893A6948 for ; Sat, 10 Jul 2010 21:15:15 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o6B4FLDo015963 for ; Sat, 10 Jul 2010 21:15:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278821721; bh=HlFqMouerQVYSDev37ob5femRZk=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=Hhpi/S2+NFQZUkVt1FeaoEvTzEzRXuo8jhVngu60FoHIFcCIZuyCa7476Wnalm6aE mTbCyb7AVaaS8SjKjrMZQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=VlZjrIDQkEFfy1Zr5Oy0gblE7umnQFUlDLMOhXGIkqsgg/jErqS92TtgI3/wtt3Ng 1A+y82JAu8SWkEj+yW79g== Received: from pwi1 (pwi1.prod.google.com [10.241.219.1]) by wpaz17.hot.corp.google.com with ESMTP id o6B4FKCE004738 for ; Sat, 10 Jul 2010 21:15:21 -0700 Received: by pwi1 with SMTP id 1so1484132pwi.1 for ; Sat, 10 Jul 2010 21:15:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.215.6 with SMTP id n6mr15306207wfg.7.1278821720442; Sat, 10 Jul 2010 21:15:20 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sat, 10 Jul 2010 21:15:20 -0700 (PDT) Date: Sat, 10 Jul 2010 21:15:20 -0700 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] return to draft 6 spec org? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 04:15:17 -0000 I think it would be a good idea to return to the draft 6 organization. Draft 6: normative language for each flow was called out separately, and was described from start to finish, in chronological order, with no interruption. Each step showed what a client should send, and what an authorization server should return. Draft 7 and further: flows are merged to reuse spec language. Steps for any given use case are now interrupted with steps for other use cases. For example, consider a client developer who wants to implement the web server flow. First they have to read section 3.1, to describe the redirect they need to send to the authorization server. Then they read section 3.2, to see the redirect back. Then they read section 4.1.1, to see the request they send to the authorization server. Then they skip a few pages, because they don't care about assertions or passwords or refresh tokens. They they read section 4.2, to see the response from the authorization server. Then they skip several more pages to get to section 5, so they can access data. Then they skip back to section 4.1.4, because they need to refresh their token. Compare this to draft 6: - read section 2.5 this is everything you need to get a token, with no intervening cruft about credentials you don't have. - read section 4 this is everything you need to use a token. - read section 3 this is everything you need to refresh a token. Cheers, Brian From beaton@google.com Sat Jul 10 21:26: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 6BF5F3A6944 for ; Sat, 10 Jul 2010 21:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.6 X-Spam-Level: X-Spam-Status: No, score=-101.6 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lfBE1mnzNVL for ; Sat, 10 Jul 2010 21:26:06 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id CB4B83A68A4 for ; Sat, 10 Jul 2010 21:26:05 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o6B4QBH4010451 for ; Sat, 10 Jul 2010 21:26:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278822371; bh=mwaHKL9c+Jv+gIm07s0MHHzE1YM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=yTXHhLbQFdrzx6eFMUsigUyQOnq1GZT0ug2IrJQIzB4ijbWlFYY/bc7Tqon6TLFk4 u09ZfXuWvJpyaM+rqv4CQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=VrZy2PxXhtv1D7IZb9sKO9wF5QAvcn7QJkQaGaQXqaBwhpjmJo8yrQCWapvNy1veg KEaQgkQjVwrjLyKHB1gUw== Received: from pxi12 (pxi12.prod.google.com [10.243.27.12]) by wpaz5.hot.corp.google.com with ESMTP id o6B4Q96x008426 for ; Sat, 10 Jul 2010 21:26:10 -0700 Received: by pxi12 with SMTP id 12so628363pxi.6 for ; Sat, 10 Jul 2010 21:26:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.148.10 with SMTP id v10mr1734203wfd.327.1278822369159; Sat, 10 Jul 2010 21:26:09 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sat, 10 Jul 2010 21:26:09 -0700 (PDT) In-Reply-To: References: Date: Sat, 10 Jul 2010 21:26:09 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 04:26:08 -0000 On Sat, Jul 10, 2010 at 9:05 PM, Eran Hammer-Lahav wrote: > There is no user-agent flow anymore. Yeah. That's a bug. =( > The request was to allow it to > obtain both when using a web-based component together with the user-agent. Right, this didn't use to be possible, but Brian Ellin asked for this, and several people agreed it was a good idea. Unfortunately when that feature got added, it broke a bunch of other stuff: - all of the descriptive language about the user-agent flow is inaccurate - if anyone tries to use the verification code approach with the user-agent flow, the user-agent flow is no longer efficient So in the quest to add a new feature, we broke other features. Plus we didn't get the new feature right. This sounds like a normal software development project. =) Let me know what you think of the new language I proposed. Note that this pretty much requires that the "type" parameter return to the authorization URL. That's a good thing. If authorization servers know about the client environment, they do a better job of meeting the client's needs. (Also note that we tried leaving this parameter out of WRAP, and regretted it afterwards.) Cheers, Brian From beaton@google.com Sat Jul 10 21:33: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 EE1C03A6946 for ; Sat, 10 Jul 2010 21:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.536 X-Spam-Level: X-Spam-Status: No, score=-105.536 tagged_above=-999 required=5 tests=[AWL=0.441, 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 6JHfZdP9mKje for ; Sat, 10 Jul 2010 21:32:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C91983A696B for ; Sat, 10 Jul 2010 21:31:17 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o6B4VKXP015979 for ; Sat, 10 Jul 2010 21:31:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278822680; bh=2CY+X0o3Y8XbvSoxGtNB6D1o5dY=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=W04LC/Qwr5WJl3trf4MV6yuE74LCj34OvN3gDyhGgjmA6KhN17TiHtKR8iMp3MKAQ 2a2OdGv0il9Iz6h+k0tkg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=d41Sh6EOv9VP++n6hYQc5RppXqa6EaNLRKPYTjMiXZEQzkB9nKSYT7eQGL3++W0u2 i6JJ6sMac1KYkPMLSFZPA== Received: from pzk3 (pzk3.prod.google.com [10.243.19.131]) by wpaz5.hot.corp.google.com with ESMTP id o6B4VJpa012174 for ; Sat, 10 Jul 2010 21:31:20 -0700 Received: by pzk3 with SMTP id 3so909469pzk.22 for ; Sat, 10 Jul 2010 21:31:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.142.1 with SMTP id p1mr14177481wfd.10.1278822678966; Sat, 10 Jul 2010 21:31:18 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sat, 10 Jul 2010 21:31:18 -0700 (PDT) Date: Sat, 10 Jul 2010 21:31:18 -0700 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] temperature check: json input to token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 04:33:15 -0000 Hey folks - Today, the token endpoint takes form-encoded inputs, and sends JSON outputs. This requires developers to use both form encoding and a json parser. Many services expose symmetric APIs for non-browser endpoints. For example, an API call normally takes JSON input and returns JSON output. What do people think about having the token endpoint accept and return JSON? Cheers, Brian From torsten@lodderstedt.net Sat Jul 10 22:21: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 AA2CC3A682F for ; Sat, 10 Jul 2010 22:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFDRzZhMwUCr for ; Sat, 10 Jul 2010 22:21:09 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by core3.amsl.com (Postfix) with ESMTP id E3CA13A6781 for ; Sat, 10 Jul 2010 22:21:07 -0700 (PDT) Received: from p4fff0efc.dip.t-dialin.net ([79.255.14.252] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OXoyW-00040s-W9; Sun, 11 Jul 2010 07:21:13 +0200 Message-ID: <4C3954C3.50802@lodderstedt.net> Date: Sun, 11 Jul 2010 07:21:07 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brian Eaton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] temperature check: json input to token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 05:21:12 -0000 that's a good idea from my point of view since it allows for more structured input. regards, Torsten. > Hey folks - > > Today, the token endpoint takes form-encoded inputs, and sends JSON > outputs. This requires developers to use both form encoding and a > json parser. > > Many services expose symmetric APIs for non-browser endpoints. For > example, an API call normally takes JSON input and returns JSON > output. > > What do people think about having the token endpoint accept and return JSON? > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From andrewarnott@gmail.com Sat Jul 10 22:41:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E887528C0CF for ; Sat, 10 Jul 2010 22:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yt4SLM04wg2 for ; Sat, 10 Jul 2010 22:41:33 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 05F323A6774 for ; Sat, 10 Jul 2010 22:41:31 -0700 (PDT) Received: by pvd12 with SMTP id 12so1696869pvd.31 for ; Sat, 10 Jul 2010 22:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=NlAs2TI72HINu0b8rz2aJfh87ICthZdGhiKw10Y1o6Q=; b=Y16vtTCpZsihcFla46W9vX5evsrlWUR/CLB8VdbHMErh9x4qmG9qmB+k3VW6RYdkEz MSSerk52UkNjG5K6jXl2x8NipNV2fObmhy9L2/wGCdlsTf7YRh1zBeujhUm1dnDh3HDt x5ecCyqSOIy9DyIzipVZxQDFJ2Y+w8SxShRqU= 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=BCx6PFAFxuwjtxCppQg3ZSL/+IHJE9Nmn6zGE9KmAv+R8MAUUD818MLn+BWiwrBKGN mhQTBVS2/PrzMbsmavsrYskaUbY+EoifauRkbCKjESZnrLXNqscmc5oMVCA8clTBAZMY GsAYPy14dQ8dLhXobptjJCikmrchtSdNHzwxs= MIME-Version: 1.0 Received: by 10.114.108.15 with SMTP id g15mr14060637wac.35.1278826895868; Sat, 10 Jul 2010 22:41:35 -0700 (PDT) Received: by 10.114.153.10 with HTTP; Sat, 10 Jul 2010 22:41:35 -0700 (PDT) In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6711@SNV-EXVS08.ds.corp.yahoo.com> References: <012AB2B223CB3F4BB846962876F47217059B6711@SNV-EXVS08.ds.corp.yahoo.com> Date: Sat, 10 Jul 2010 22:41:35 -0700 Message-ID: From: Andrew Arnott To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00163646b7eadb8219048b161689 Cc: oauth Subject: Re: [OAUTH-WG] Basic questions about using the HTTP 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: Sun, 11 Jul 2010 05:41:36 -0000 --00163646b7eadb8219048b161689 Content-Type: text/plain; charset=ISO-8859-1 Eran, Is the draft 10 spec going to outline what characters are allowed in the access token? And if not (or if all characters are allowed), is it going to include details about (or a reference to a doc about) how to properly escape the access token when specifying it in the HTTP Authorization header? Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Sat, Jun 26, 2010 at 9:42 AM, William Mills wrote: > I don't remember where I found it before, but OWS is Optional White > Space, and RWS is Required White Space. There is also no BNF to define > access_token or refresh_token. > > For this spec to be implementable "all this stuff" has to be explicitly > defined.... > > > ------------------------------ > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Andrew Arnott > *Sent:* Saturday, June 26, 2010 7:03 AM > *To:* OAuth WG (oauth@ietf.org) > *Subject:* [OAUTH-WG] Basic questions about using the HTTP Authorization > header > > Can anyone point me to good reference material for understanding the > Authorization header in Section 5.1 of the OAuth 2.0 draft 8 spec and > the WWW-Authenticate section 6? > > Specifically, some questions I have are: > > 1. How to properly escape the access token for inclusion in the header? > (suppose a linefeed or null character were in the token... how to escape > that?) > 2. What do RWS and OWS stand for? > 3. What is the "realm" value? Is the "service" string that is always > set as its value a literal, or a placeholder? What are some actual values > that might appear? > > I'm sure there's an RFC out there that describes all this stuff. RFC 2617 > is mentioned as a source for some of this, but "RWS" doesn't show up > anywhere in that RFC, for example, so I'm not sure where the best place is > to look this up in. > > Thanks. > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > --00163646b7eadb8219048b161689 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Eran,

Is the draft 10 spec going to outline what charact= ers are allowed in the access token? =A0And if not (or if all characters ar= e allowed), is it going to include details about (or a reference to a doc a= bout) how to properly escape the access token when specifying it in the HTT= P Authorization header?

Thanks.

--
Andrew Arnott"I [may] not agree with what you have to say, but I'll defend to = the death your right to say it." - S. G. Tallentyre


On Sat, Jun 26, 2010 at 9:42 AM, William= Mills <wmills= @yahoo-inc.com> wrote:
I don't remember where I found it before, but OWS is Optio= nal=20 White Space, and RWS is Required White Space.=A0 There is also no BNF to=20 define access_token or refresh_token.=A0
=A0
For this spec to be implementable "all this stuff" h= as to be=20 explicitly defined....
=A0

From: oauth-bounces@ietf.org=20 [mailto:oauth= -bounces@ietf.org] On Behalf Of Andrew=20 Arnott
Sent: Saturday, June 26, 2010 7:03 AM
To: OAut= h WG=20 (oauth@ietf.org)<= br>Subject: [OAUTH-WG] Basic questions about using the=20 HTTP Authorization header

Can anyone point me to good reference material for understandi= ng=20 the Authorization header in=A0Section=20 5.1 of the OAuth 2.0 draft 8 spec=A0and the WWW-Authenticate section = 6?

Specifically, some questions I have are:
  1. How to properly escape the access token for inclusion in the header= ?=20 (suppose a linefeed or null character were in the token... how to escap= e=20 that?)=20
  2. What do RWS and OWS stand for?
  3. What is the "realm" value? Is the "service"= ; string that is always set as=20 its value a literal, or a placeholder? =A0What are some actual values= =20 that might appear?
I'm sure there's an RFC out there that describes all this st= uff.=20 =A0RFC 2617 is mentioned as a source for some of this, but "RWS"= ; doesn't=20 show up anywhere in that RFC, for example, so I'm not sure where the = best=20 place is to look this up in.

Thanks.
--
Andrew Arnott
"I [may] not agree with wha= t you have=20 to say, but I'll defend to the death your right to say it." - S.= G.=20 Tallentyre

--00163646b7eadb8219048b161689-- From beaton@google.com Sat Jul 10 23:44: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 D437B3A68BB for ; Sat, 10 Jul 2010 23:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.27 X-Spam-Level: X-Spam-Status: No, score=-104.27 tagged_above=-999 required=5 tests=[AWL=-0.893, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWFNK3L8HrkB for ; Sat, 10 Jul 2010 23:44:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D0B783A6768 for ; Sat, 10 Jul 2010 23:44:09 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o6B6iGx5019864 for ; Sat, 10 Jul 2010 23:44:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278830656; bh=/EH7u3ZEUzfxykHWLIW63B98S4Q=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=PfDhXW38+R1zYvUyvYl+cGmjQtCxmZgYnHMr1hB3GVtcD3S2UP7Cl7C1diHKncRIw p4k/BwzrxFZxHHs1pW4UA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=ba98A845N2DUmvy5Y2N2hL+FcrOZtpN3rqjqzgdCKBxCtn13xdDAyGG4fqRLS5wwm rJr8HlxtA26YD+yKXjrEg== Received: from pvh11 (pvh11.prod.google.com [10.241.210.203]) by wpaz21.hot.corp.google.com with ESMTP id o6B6iEWK006041 for ; Sat, 10 Jul 2010 23:44:15 -0700 Received: by pvh11 with SMTP id 11so1702055pvh.38 for ; Sat, 10 Jul 2010 23:44:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.199.20 with SMTP id w20mr13967327wff.249.1278830654557; Sat, 10 Jul 2010 23:44:14 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sat, 10 Jul 2010 23:44:14 -0700 (PDT) Date: Sat, 10 Jul 2010 23:44:14 -0700 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] redirect URI matching in section 3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 06:44:12 -0000 Section 3 says [[ provide guidance on how to perform matching ]]. I can write the guidance on performing redirect URI matching, but it varies per profile. User-Agent profile with registered client: matching is critical, MUST verify is appropriate Web server profile with client secret you trust: matching is not critical. Matching provides some extra security. MAY is appropriate. MUST is really bad, since it prevents clients from moving redirect URIs. Any profile where you don't trust the client secret (e.g. installed apps): Redirect URI matching is useless. SHOULD NOT is appropriate. So this is another case where the client needs to pass some indicator to the server (either via type= parameter, or as policy associated with client_id) of the environment in which it is running. The type parameter needs to signal: - how the authorization server passes data (fragment or query string) - what data is passed (access token, or just verification code) Here's some proposed language on redirect URI matching. New Section 3.1: Overview of Callback URL Authentication The OAuth 2 protocol distributes authorization credentials to web-based applications by redirecting the user-agent to the client with some form of authorization credential on the URL. The authorization credential is either an access token, or a authorization code. In either case, authenticating the URL to which the credential is returned is critical to the security of the protocol. Credentials returned on redirect URLs may leak in several ways: - Referer headers sent by the browser to untrusted third-party web sites - open redirectors - web server log files - browser history Authorization servers have several techniques available for authenticating callback URLs and defending against those leaks: - using client authentication credentials to authenticate callback URLs - callback URL white-listing - passing authorization credentials on URI fragments - issuing short-lived credentials to ease recovery in the event of compromise 3.1.1 Authorization Policy In certain circumstances the Authorization Server is not able to perfectly authenticate the callback URL. For example, multiple installed applications may use the same callback URL, and there is no way for the Authorization Server to reliably distinguish among them. Authorization Servers deal with this ambiguity by choosing different policies on when to issue authorization credentials. If the authorization server is able to authenticate the callback URL with a high degree of confidence - the authorization server MAY decline to prompt the user to grant authorization, immediately rejecting the authorization request. - the authorization server MAY issue an authorization credential after prompting the user. - the authorization server MAY issue a new authorization credential without prompting the user, if the authorization server knows that the user has previously approved this client. If the authorization server is not able to authenticate the callback URL: - the authorization server MAY decline to prompt the user to grant authorization, immediately rejecting the authorization request. - the authorization server MAY issue an authorization credential after prompting the user. - the authorization server MUST NOT issue an authorization credential without prompting the user. 3.1.2 Callback URL Authentication Techniques Client Credentials MAY be used to authenticate callback URLs. If an Authorization Server wishes to authenticate callback URLs with client credentials, all of the following conditions MUST be met: - the client credentials MUST have been issued to a web application with a server-side component. - the Authorization Server MUST believe that the client credentials are stored securely. - the Authorization Server MUST return only an authorization code to the callback URL. An access token MUST NOT be returned. In all other circumstances, the Authorization Server MUST use callback URL white-listing to authenticate callback URLs. However, appropriate callback URL white-listing varies for different client environments. There are various techniques for callback URL white-listing. The list in this document is not exhaustive, and Authorization Servers MAY implement other techniques at their discretion. This document will consider the following approaches: - domain white-listing Authorization Servers white-list entire domains, e.g. '*.example.com'. Authorization servers may include the protocol in this white-list, e.g. 'all https web sites on *.example.com'. Any page on any host in that domain is accepted. - host white-listing Authorization Servers white-list entire hosts, e.g. 'www.example.com'. Authorization servers may include the protocol in the white-list, e.g. 'https://www.example.com'. Any page on that host is accepted. - path white-listing Authorization Servers white-list specific paths on a particular host, e.g. 'https://www.example.com/path'. Any page beneath that path is accepted. - page white-listing Authorization Servers white-list a specific page on a particular host, e.g. 'https://www.example.com/path/page'. The query string and URI fragment may vary, but all other components of the URL are fixed and must match that page. - full URL white-listing Authorization Servers white-list a specific URL, e.g. 'https://www.example.com/path/page?query'. Any callback URL that does not completely match that URL is rejected. The following sections offer guidance to Authorization Servers and Client developers on how to handle callback URL authentication. For better security, Authorization Servers and Clients should rely on a combination of client credentials and callback URL white-listing to authenticate callback URLs. Section 3.1.3 Secure Callback URLs for the Web Server Profile Client application developers using the web server profile should take care that their callback URLs preserve the security of the profile. Callback URL pages MUST NOT link or or redirect to untrusted content from those pages, since the authorization code may leak in the referer header. Callback URL pages MUST NOT forward the authorization code to an untrusted page. Callback URL pages SHOULD redirect to a trusted page immediately after receiving the authorization code in the URL. This prevents the authorization code from remaining in the browser history, or from inadvertently leaking in a referer header. Callback URL pages SHOULD NOT log the authorization code. Callback URL pages SHOULD be CSRF protected. (TODO: dig up the language in OAuth 1.0a, it was pretty good, I think...) Section 3.1.4 Callback URL Authentication for the Web Server Profile The web server profile returns an authorization code on the callback URL. Authorization codes returned on callback URLs are very prone to leaking in referer headers, open redirectors, web server log files, and browser history. Authorization Servers MAY omit callback URL white-listing, but only if they are using client credentials to authenticate callback URLs. If client credentials are being used, any type of callback URL white-listing will improve security. Different types of white-listing provide different levels of security. - domain- and host- whitelisting Domain and host white-listing rules are very broad, and so are very vulnerable to the leaks discussed in section 3.1. Domain- and host- white-listing MUST NOT be used alone. Domain and host white-listing MAY be used in combination with using client credentials to authenticate callback URLs. - path white-listing Path white-listing is somewhat broad, and may be vulnerable to the leaks discussed in section 3.1. Path white-listing MUST NOT be used alone. Path white-listing MAY be used in combination with using client credentials to authenticate callback URLs. When using path white-listing, Authorization servers MUST defend against directory traversal attacks by canonicalizing the path. Appropriate path canonicalization algorithms vary for different types of web-servers, e.g. "\..\" may represent a parent directory in some web servers, and not in others. - page and URL white-listing Page and URL white-listing are very specific, but may still be vulnerable to some of the leaks discussed in section 3.1 if the callback URL page does not follow the security recommendations in section 3.1.3. These types of white-listing MAY be used alone, or in combination with client credentials to authenticate callback URLs. When full URL white-listing is used, Authorization Servers MUST allow the "state" query parameter to vary. Section 3.1.4 Secure Callback URLs for the User-Agent Profile Client application developers using the user-agent profile should take care that their callback URLs preserve the security of the profile. Because the user-agent profile returns an access token on the URI fragment, many types of leaks are less likely. However, incorrect code can still leak the authorization credentials. Callback URL pages MUST NOT forward the access token or authorization code to an untrusted page. Callback URLs rendered in a top-level browser window cannot prevent the access token from remaining in the browser history. Whenever possible, client applications SHOULD use an iframe to receive callbacks so that the access token does not appear in the browser history. [[Note that Authorization Servers SHOULD NOT allow their approval pages to be iframed due to the risk of click-jacking attacks, so this only works for immediate mode. Browser security gets complicated.]] If callback URLs must be rendered in a top-level browser window, client applications SHOULD redirect immediately after receiving the callback URL to remove the access token from the URL bar. This prevents the user from inadvertently copying their access token. Callback URL pages SHOULD be CSRF protected. (TODO: dig up the language in OAuth 1.0a, it was pretty good, I think...) Section 3.1.4 Callback URL Authentication for the User-Agent profile Because the user-agent profile returns an access token on the callback URL, client credentials cannot be used to authenticate the callback URL. Callback URL white-listing is the only possible way to authenticate the callback URL. However, because the authorization credentials are always returned on the URL fragment, the opportunity for leaking credentials via referer headers and open redirectors is reduced. Different types of white-listing provide different levels of security. - domain- white-listing Domain white-listing is very broad. Domain white-listing MUST NOT be used, because of the risk of malicious code running under some host in the domain. - host- white-listing Host white-listing is very broad. Authorization servers should be conservative in choosing which hosts they trust, but host white-listing MAY be used. - path white-listing Path white-listing is somewhat broad. Path white-listing MAY be used. When using path white-listing, Authorization servers MUST defend against directory traversal attacks by canonicalizing the path. Appropriate path canonicalization algorithms vary for different types of web-servers, e.g. "\..\" may represent a parent directory in some web servers, and not in others. - page and URL white-listing Page and URL white-listing are very specific. These types of white-listing MAY be used When full URL white-listing is used, Authorization Servers MUST allow the "state" query parameter to vary. Cheers, Brian From beaton@google.com Sat Jul 10 23:48: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 015B43A68B6 for ; Sat, 10 Jul 2010 23:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.506 X-Spam-Level: X-Spam-Status: No, score=-105.506 tagged_above=-999 required=5 tests=[AWL=0.471, 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 8HQvRgDbJ72a for ; Sat, 10 Jul 2010 23:48:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id F35653A6840 for ; Sat, 10 Jul 2010 23:48:57 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id o6B6n4wl013531 for ; Sat, 10 Jul 2010 23:49:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278830944; bh=EaiUKzONjvYvYQoaIJblgc4fa/U=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=mHNxXc8dh94nkB/uSSG6BoRJj8Y0PvGrhK2pVYToqVrRcHttoPu1Oo9jQapkjsMFi gvZmzOomMSUPz33Zwptog== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=dORWdd86fjiXft+zzqkFC2aK1tpf9sOXSa/ODtN2AR8IomvIzUT+mtMuAmi0gtn8u RUHwp9gr0R/ARQU25PlKQ== Received: from pxi12 (pxi12.prod.google.com [10.243.27.12]) by wpaz1.hot.corp.google.com with ESMTP id o6B6n33u028259 for ; Sat, 10 Jul 2010 23:49:03 -0700 Received: by pxi12 with SMTP id 12so575844pxi.20 for ; Sat, 10 Jul 2010 23:49:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.142.12 with SMTP id p12mr14595177wfd.13.1278830942922; Sat, 10 Jul 2010 23:49:02 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sat, 10 Jul 2010 23:49:02 -0700 (PDT) Date: Sat, 10 Jul 2010 23:49:02 -0700 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] simplify 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: Sun, 11 Jul 2010 06:48:59 -0000 The current spec has the client create a "name='value'" syntax exactly once, in the Authorization header. We could eliminate a fair chunk of client code by removing the name="value" syntax and going with the approach taken by the Basic, NTLM, and Negotiate schemes: Authorization: OAuth2 No more escaping beyond what your HTTP library provides. Just call setHeader("OAuth2 " + token), and you're on your merry way. We are going to need slightly more flexibility once the signature proposal settles down. For that, I'd suggest using a different scheme name. Authorization: OAuth2Signed Cheers, Brian From beaton@google.com Sat Jul 10 23:49: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 410F43A68B6 for ; Sat, 10 Jul 2010 23:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.676 X-Spam-Level: X-Spam-Status: No, score=-101.676 tagged_above=-999 required=5 tests=[AWL=0.301, 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 lAYmaxX03VCM for ; Sat, 10 Jul 2010 23:49:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 3C6123A6768 for ; Sat, 10 Jul 2010 23:49:45 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o6B6noLA006292 for ; Sat, 10 Jul 2010 23:49:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278830990; bh=18ocgujYlIbkXrxu1qh/OHarAjk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=aS1MnBK6+p/uQ0u0IH0PH7Do+0CW32UXUBA75JAZW/sRSvGJe0p+cpNQHpHUCiQZQ BFBEDR9oXaYu2TyixZFKw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Jnsl51d+r4HsHKpzbwM6PIVHUsx8fk/7VgX6G+gYe/soMFEM3Y5j3WUtWZzQa+P0b V7Q5oXG1LW5OLCiOt2G6g== Received: from pzk3 (pzk3.prod.google.com [10.243.19.131]) by kpbe14.cbf.corp.google.com with ESMTP id o6B6nmxB030041 for ; Sat, 10 Jul 2010 23:49:48 -0700 Received: by pzk3 with SMTP id 3so885941pzk.8 for ; Sat, 10 Jul 2010 23:49:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.48.18 with SMTP id v18mr14299928wfv.102.1278830988267; Sat, 10 Jul 2010 23:49:48 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sat, 10 Jul 2010 23:49:48 -0700 (PDT) In-Reply-To: References: <012AB2B223CB3F4BB846962876F47217059B6711@SNV-EXVS08.ds.corp.yahoo.com> Date: Sat, 10 Jul 2010 23:49:48 -0700 Message-ID: From: Brian Eaton To: Andrew Arnott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth Subject: Re: [OAUTH-WG] Basic questions about using the HTTP 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: Sun, 11 Jul 2010 06:49:46 -0000 On Sat, Jul 10, 2010 at 10:41 PM, Andrew Arnott wr= ote: > Eran, > Is the draft 10 spec going to outline what characters are allowed in the > access token? =A0And if not (or if all characters are allowed), is it goi= ng to > include details about (or a reference to a doc about) how to properly esc= ape > the access token when specifying it in the HTTP Authorization header? Just sent a proposal to the list to drop the Authorization header name=3D"value" syntax completely. We can copy what Basic/NTLM/Negotiate have been doing instead. From beaton@google.com Sat Jul 10 23:55:43 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72EB33A693B for ; Sat, 10 Jul 2010 23:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.537 X-Spam-Level: X-Spam-Status: No, score=-105.537 tagged_above=-999 required=5 tests=[AWL=0.440, 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 NcLjilPIWXWX for ; Sat, 10 Jul 2010 23:55:42 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DB87C3A6907 for ; Sat, 10 Jul 2010 23:55:41 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o6B6tmFU013354 for ; Sat, 10 Jul 2010 23:55:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278831348; bh=euvTe5JMZ4GNghIgfgp6zioAaOU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=r2p3lnFH1vLiGyEQplyOsM90hb0+XCUF1hqQUkNEGdeVNT3XR/mnubDPO6ItYHtLS 8dky0D34ACQbHKR1d4s7g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=V1dRUIBkt6hH/3dZuXYCz4yrQnvjS/5TFB5M+DwqildXgUtv5iYtWuy56hKl6FEnM NmtqF16al6Jg05qULlVfQ== Received: from pwj9 (pwj9.prod.google.com [10.241.219.73]) by kpbe17.cbf.corp.google.com with ESMTP id o6B6tlu4010812 for ; Sat, 10 Jul 2010 23:55:47 -0700 Received: by pwj9 with SMTP id 9so2314961pwj.27 for ; Sat, 10 Jul 2010 23:55:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.232.13 with SMTP id e13mr14307781wfh.196.1278831346855; Sat, 10 Jul 2010 23:55:46 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sat, 10 Jul 2010 23:55:46 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 10 Jul 2010 23:55:46 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 06:55:43 -0000 On Sun, Jun 27, 2010 at 6:51 PM, Eran Hammer-Lahav wr= ote: > 1. Leave it as required under the definition of RFC 2617 (i.e. provide no > help, developers will need to ready 2617 and figure out what to do with i= t). > > 2. Update 2617 to remove the requirement =96 this is not going to be easy= or > possible to predict success. > > 3. Provide specific guidance as to what to do with the realm parameter. > > 4. Something else. Let's do something else. We've made great progress on simplifying the spec and unifying the different formats to minimize the number of parsers and serializers that are needed. The www-authenticate header is one of the bits of nastiness left. Let's use a format like this: WWW-Authenticate: OAuth2 base64() Or even just: WWW-Authenticate: OAuth2 Seriously. There is some precedent for this. The Negotiate and NTLM schemes ditched the name=3D"value" syntax, and they are widely implemented. This demonstrates two things: 1) dropping the name=3D"value" syntax won't break the internet, because widely deployed schemes have already done it. 2) "realm" is not necessary in order to have a successful authentication protocol. As far as I can tell, there is no good reason for RFC 2617 to specify the syntax it does. It's convenient for digest auth, and kind of a pain everywhere else. So let's just drop it. Cheers, Brian From beaton@google.com Sat Jul 10 23:59:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1F03A6907 for ; Sat, 10 Jul 2010 23:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.565 X-Spam-Level: X-Spam-Status: No, score=-105.565 tagged_above=-999 required=5 tests=[AWL=0.412, 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 oHP+4433QOur for ; Sat, 10 Jul 2010 23:59:12 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E86863A68B6 for ; Sat, 10 Jul 2010 23:59:11 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o6B6xHQL001151 for ; Sat, 10 Jul 2010 23:59:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278831558; bh=51+vYznmLOqIBJxZMUVER7ZpdTo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=DUA8gVhTbNYJRaXxzBMbip6/CcO47csP5YspS2FUxLwF8aUkubTZkJGRdryL8l95G OhRzLUyLYP4cGZ08iRipA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=CLHdkqGg5O+bjSKRDAiwcdO09Fv+lS9Lk2EfPZGnToKl8L3wVaDG1wdfNmT0sz2G5 aEsHiiYdaITsBg/D8hbgA== Received: from pwj9 (pwj9.prod.google.com [10.241.219.73]) by hpaq3.eem.corp.google.com with ESMTP id o6B6xG9B020147 for ; Sat, 10 Jul 2010 23:59:16 -0700 Received: by pwj9 with SMTP id 9so1580402pwj.13 for ; Sat, 10 Jul 2010 23:59:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.207.9 with SMTP id e9mr634319wfg.111.1278831555611; Sat, 10 Jul 2010 23:59:15 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sat, 10 Jul 2010 23:59:15 -0700 (PDT) In-Reply-To: References: Date: Sat, 10 Jul 2010 23:59:15 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] "access grant" terminology X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 06:59:12 -0000 On Sat, Jul 10, 2010 at 8:03 PM, Eran Hammer-Lahav wrote: > I think authorization credential is going to confuse most readers. The spec > refers to credentials almost exclusively when dealing with identifier and > password (client, end-user), or as a general term for client authentication. > Authorization is specific to the end-user authorization endpoint and will be > confusing when used with assertions and other grant types. This doesn't hold water. "authorization credential" is consistent with existing practice and definition: http://www.ietf.org/rfc/rfc2828.txt $ credential(s) (I) Data that is transferred or presented to establish either a claimed identity or the authorizations of a system entity. (See: authentication information, capability, ticket.) > Note that since this term impacts the name of the current 'grant_type' > parameter, changing it means code changes. Given the number of bugs in the -09 spec, I don't think this matters. From sayrer@gmail.com Sun Jul 11 00:11:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E723A67CC for ; Sun, 11 Jul 2010 00:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCfl3PmWkT+O for ; Sun, 11 Jul 2010 00:11:40 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id E2D913A67C3 for ; Sun, 11 Jul 2010 00:11:39 -0700 (PDT) Received: by pwj1 with SMTP id 1so1705423pwj.31 for ; Sun, 11 Jul 2010 00:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=dx2SRhjEzHYwhCfy5QUn1o/z7gGrkT5e63tdAJNrMOk=; b=iTkgpzrfjANY3SlHslm4ASV/LALPgvXPQMJdYVU7UJqzUg5/QP/p2t6tZRX3o0oiVj m0r8Nhv62NwYEMPOpr9xzf57Qrwy7UvM05rqlrUJAGyOnbZX8SHXO7Vjv0+ZgFoTjPIq Qb5bLdXkp6zVp68zCGg/wQzkxwqAd5PW89Lwk= 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=xrkA7ENU8PcWFWpOc2sWtUUxC51URkODeKshd6DUD7qriiYRIQJCqIjU8VSfPPa37I V+LmWDRjsB753Bmfqx3Hf4m5UG6ZsC36pO852gi+jMJNo4ARktSEOf098FaekDdv9BMZ FSWDUXTDOzFoF9L1ntSgK7EtxrFGqakaeflXk= MIME-Version: 1.0 Received: by 10.142.171.7 with SMTP id t7mr14288463wfe.48.1278832303899; Sun, 11 Jul 2010 00:11:43 -0700 (PDT) Received: by 10.142.84.8 with HTTP; Sun, 11 Jul 2010 00:11:43 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 11 Jul 2010 00:11:43 -0700 Message-ID: From: Robert Sayre To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 07:11:43 -0000 On Sat, Jul 10, 2010 at 11:55 PM, Brian Eaton wrote: > > Let's use a format like this: > > WWW-Authenticate: OAuth2 base64() > > Or even just: > > WWW-Authenticate: OAuth2 > > Seriously. Looks good. Doesn't matter which the WG picks. > 1) dropping the name="value" syntax won't break the internet, because > widely deployed schemes have already done it. Fully agree. > 2) "realm" is not necessary in order to have a successful > authentication protocol. Indeed. So far, it looks like "realm" is necessary to have an unsuccessful authentication protocol. > > As far as I can tell, there is no good reason for RFC 2617 to specify > the syntax it does. RFC 2617 adopts constraints that predate widespread Unicode adoption. > It's convenient for digest auth, and kind of a > pain everywhere else. > It's not convenient for Digest, and Digest doesn't work anyway. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From eran@hueniverse.com Sun Jul 11 05:57:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58593A67DB for ; Sun, 11 Jul 2010 05:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 VP3dhgLINXIL for ; Sun, 11 Jul 2010 05:57:39 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A23113A67A7 for ; Sun, 11 Jul 2010 05:57:39 -0700 (PDT) Received: (qmail 15952 invoked from network); 11 Jul 2010 12:57:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 12:57:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 11 Jul 2010 05:57:44 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Sun, 11 Jul 2010 05:56:43 -0700 Thread-Topic: [OAUTH-WG] "access grant" terminology Thread-Index: Acsg+Keui+9GES5ITr6zv07z+DHUoQ== Message-ID: <0E3CEEF5-FB7D-46E7-8C06-091AE29D1788@hueniverse.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] "access grant" terminology X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 12:57:40 -0000 According to this logic, everyone should be called a credential - access to= ken, refresh token, authorization code, etc.=20 Having too many similar terms is confusing and a mistake I refuse to repeat= .=20 As for the so called bugs, so far most of your feedback is non-normative or= has little implementation impact. I'll incorporate whatever I can and the rest will have to get consensus and= wait a month.=20 EHL On Jul 11, 2010, at 2:59, Brian Eaton wrote: > On Sat, Jul 10, 2010 at 8:03 PM, Eran Hammer-Lahav = wrote: >> I think authorization credential is going to confuse most readers. The s= pec >> refers to credentials almost exclusively when dealing with identifier an= d >> password (client, end-user), or as a general term for client authenticat= ion. >> Authorization is specific to the end-user authorization endpoint and wil= l be >> confusing when used with assertions and other grant types. >=20 > This doesn't hold water. "authorization credential" is consistent > with existing practice and definition: >=20 > http://www.ietf.org/rfc/rfc2828.txt >=20 > $ credential(s) > (I) Data that is transferred or presented to establish either a > claimed identity or the authorizations of a system entity. (See: > authentication information, capability, ticket.) >=20 >> Note that since this term impacts the name of the current 'grant_type' >> parameter, changing it means code changes. >=20 > Given the number of bugs in the -09 spec, I don't think this matters. From eran@hueniverse.com Sun Jul 11 06:02: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 64E393A65A5 for ; Sun, 11 Jul 2010 06:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, 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 nvwRb4xcRxri for ; Sun, 11 Jul 2010 06:02:38 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id F2D863A6880 for ; Sun, 11 Jul 2010 06:02:37 -0700 (PDT) Received: (qmail 19525 invoked from network); 11 Jul 2010 13:02:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 13:02:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 11 Jul 2010 06:02:44 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Sun, 11 Jul 2010 06:01:43 -0700 Thread-Topic: [OAUTH-WG] What to do about 'realm' Thread-Index: Acsg+VqLkLuB+ScUT9yb7XNv1DDvvA== Message-ID: <19C8AB8C-CC69-473C-95D2-DD774302B3C6@hueniverse.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 13:02:39 -0000 WW91IG1lYW4gdGhlIHN5bnRheCB1c2VkIGJ5IG1vc3QgSFRUUCBoZWFkZXJzPyBUaGVyZSBpcyBj bGVhcmx5IGEgbmVlZCBmb3IgYWRkaW5nIGV4dGVuc2lvbnMuDQoNCkVITA0KDQpPbiBKdWwgMTEs IDIwMTAsIGF0IDI6NTUsIEJyaWFuIEVhdG9uIDxiZWF0b25AZ29vZ2xlLmNvbT4gd3JvdGU6DQoN Cj4gT24gU3VuLCBKdW4gMjcsIDIwMTAgYXQgNjo1MSBQTSwgRXJhbiBIYW1tZXItTGFoYXYgPGVy YW5AaHVlbml2ZXJzZS5jb20+IHdyb3RlOg0KPj4gMS4gTGVhdmUgaXQgYXMgcmVxdWlyZWQgdW5k ZXIgdGhlIGRlZmluaXRpb24gb2YgUkZDIDI2MTcgKGkuZS4gcHJvdmlkZSBubw0KPj4gaGVscCwg ZGV2ZWxvcGVycyB3aWxsIG5lZWQgdG8gcmVhZHkgMjYxNyBhbmQgZmlndXJlIG91dCB3aGF0IHRv IGRvIHdpdGggaXQpLg0KPj4gDQo+PiAyLiBVcGRhdGUgMjYxNyB0byByZW1vdmUgdGhlIHJlcXVp cmVtZW50IOKAkyB0aGlzIGlzIG5vdCBnb2luZyB0byBiZSBlYXN5IG9yDQo+PiBwb3NzaWJsZSB0 byBwcmVkaWN0IHN1Y2Nlc3MuDQo+PiANCj4+IDMuIFByb3ZpZGUgc3BlY2lmaWMgZ3VpZGFuY2Ug YXMgdG8gd2hhdCB0byBkbyB3aXRoIHRoZSByZWFsbSBwYXJhbWV0ZXIuDQo+PiANCj4+IDQuIFNv bWV0aGluZyBlbHNlLg0KPiANCj4gTGV0J3MgZG8gc29tZXRoaW5nIGVsc2UuDQo+IA0KPiBXZSd2 ZSBtYWRlIGdyZWF0IHByb2dyZXNzIG9uIHNpbXBsaWZ5aW5nIHRoZSBzcGVjIGFuZCB1bmlmeWlu ZyB0aGUNCj4gZGlmZmVyZW50IGZvcm1hdHMgdG8gbWluaW1pemUgdGhlIG51bWJlciBvZiBwYXJz ZXJzIGFuZCBzZXJpYWxpemVycw0KPiB0aGF0IGFyZSBuZWVkZWQuICBUaGUgd3d3LWF1dGhlbnRp Y2F0ZSBoZWFkZXIgaXMgb25lIG9mIHRoZSBiaXRzIG9mDQo+IG5hc3RpbmVzcyBsZWZ0Lg0KPiAN Cj4gTGV0J3MgdXNlIGEgZm9ybWF0IGxpa2UgdGhpczoNCj4gDQo+IFdXVy1BdXRoZW50aWNhdGU6 IE9BdXRoMiBiYXNlNjQoPGpzb24+KQ0KPiANCj4gT3IgZXZlbiBqdXN0Og0KPiANCj4gV1dXLUF1 dGhlbnRpY2F0ZTogT0F1dGgyDQo+IA0KPiBTZXJpb3VzbHkuDQo+IA0KPiBUaGVyZSBpcyBzb21l IHByZWNlZGVudCBmb3IgdGhpcy4gIFRoZSBOZWdvdGlhdGUgYW5kIE5UTE0gc2NoZW1lcw0KPiBk aXRjaGVkIHRoZSBuYW1lPSJ2YWx1ZSIgc3ludGF4LCBhbmQgdGhleSBhcmUgd2lkZWx5IGltcGxl bWVudGVkLg0KPiBUaGlzIGRlbW9uc3RyYXRlcyB0d28gdGhpbmdzOg0KPiAxKSBkcm9wcGluZyB0 aGUgbmFtZT0idmFsdWUiIHN5bnRheCB3b24ndCBicmVhayB0aGUgaW50ZXJuZXQsIGJlY2F1c2UN Cj4gd2lkZWx5IGRlcGxveWVkIHNjaGVtZXMgaGF2ZSBhbHJlYWR5IGRvbmUgaXQuDQo+IDIpICJy ZWFsbSIgaXMgbm90IG5lY2Vzc2FyeSBpbiBvcmRlciB0byBoYXZlIGEgc3VjY2Vzc2Z1bA0KPiBh dXRoZW50aWNhdGlvbiBwcm90b2NvbC4NCj4gDQo+IEFzIGZhciBhcyBJIGNhbiB0ZWxsLCB0aGVy ZSBpcyBubyBnb29kIHJlYXNvbiBmb3IgUkZDIDI2MTcgdG8gc3BlY2lmeQ0KPiB0aGUgc3ludGF4 IGl0IGRvZXMuICBJdCdzIGNvbnZlbmllbnQgZm9yIGRpZ2VzdCBhdXRoLCBhbmQga2luZCBvZiBh DQo+IHBhaW4gZXZlcnl3aGVyZSBlbHNlLg0KPiANCj4gU28gbGV0J3MganVzdCBkcm9wIGl0Lg0K PiANCj4gQ2hlZXJzLA0KPiBCcmlhbg0K From James.H.Manger@team.telstra.com Sun Jul 11 06:11: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 DC57E3A67B2 for ; Sun, 11 Jul 2010 06:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[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 ZOiOOjgIAUq3 for ; Sun, 11 Jul 2010 06:11:59 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 9BB2B3A67A7 for ; Sun, 11 Jul 2010 06:11:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,182,1278252000"; d="scan'208";a="7440519" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 11 Jul 2010 23:12:01 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6039"; a="4403778" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbni.tcif.telstra.com.au with ESMTP; 11 Jul 2010 23:12:03 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Sun, 11 Jul 2010 23:12:02 +1000 From: "Manger, James H" To: Brian Eaton , "OAuth WG (oauth@ietf.org)" Date: Sun, 11 Jul 2010 23:12:09 +1000 Thread-Topic: [OAUTH-WG] What to do about 'realm' Thread-Index: Acsgxh/Z7W0KuAYVQwqj6GtbcPVkxQALnRIw Message-ID: <255B9BB34FB7D647A506DC292726F6E112660D9E04@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@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] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 13:12:00 -0000 Brian, > Or even just: > > WWW-Authenticate: OAuth2 > > Seriously. I seriously hope not. It gives no chance for a client to work with a service without being pre-co= nfigured with a whole lot of service-specific knowledge -- in addition to a= n app-id/password. I don't think a realm parameter adds much value to a "WWW-Auth.: OAuth2" he= ader, other than complying with RFC2617. The header does need to provide an= end-user authorization endpoint. Ideally, that one URI would be sufficient= for the protocol to succeed (though currently you need to separately provi= de a token endpoint as well). -- James Manger From eran@hueniverse.com Sun Jul 11 06:37: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 A3E863A6974 for ; Sun, 11 Jul 2010 06:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.271, 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 rlm423ZeVoYw for ; Sun, 11 Jul 2010 06:37:21 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 4BEF43A6985 for ; Sun, 11 Jul 2010 06:37:21 -0700 (PDT) Received: (qmail 24029 invoked from network); 11 Jul 2010 13:37:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 13:37:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 11 Jul 2010 06:37:28 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Sun, 11 Jul 2010 06:37:25 -0700 Thread-Topic: [OAUTH-WG] user-agent flow needs a rewrite Thread-Index: AcsgsTNdzUBzvAJKTDKhTG0SEXY31QATP8Rn Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85F172536FD1eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 13:37:26 -0000 --_000_C85F172536FD1eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The problem with the original 'type' parameter and the flows in general is = that they tried to address a specific use case and then got expanded (or ov= erloaded) with other use cases. The user-agent and web-server flows became = the foundation of native applications, and there were people discussing usi= ng native application techniques for user-agent clients. At the end, the fl= ow names and prose became more confusing than helpful (I'm not talking abou= t the grouping of normative language). The key here is to figure out what information about the client the server = actually needs, what it should obtain during registration, and what it can = figure out from other parameters. For example, if a client_id has a matchin= g secret, do you allow it to request an access token directly in the author= ization endpoint? If you do, is it going to include the same capabilities a= s an access token obtained using an authorization code and client authentic= ation? It seems like we need to address these questions head on. The server can't trust what the client is asking unless the client is authe= nticated *and* the server can trust that authentication (i.e. Client secret= not used in a user-agent). For that, you need to establish some form of tr= ust with the client which in today's world means registration. If you are g= oing to perform registration, that's where you should ask about the nature = of the client so you can optimize the user experience and the overall secur= ity. The way I understand the Twitter use case is that the client isn't just a u= ser-agent trying to get both an access token and authorization code (or ref= resh token), but a more complex client which includes both a user-agent and= web-based components, each providing a different functionality, but both u= sing the same, single end-user authorization (i.e. The end-user is asked on= ce). EHL On 7/10/10 9:26 PM, "Brian Eaton" wrote: On Sat, Jul 10, 2010 at 9:05 PM, Eran Hammer-Lahav wr= ote: > There is no user-agent flow anymore. Yeah. That's a bug. =3D( > The request was to allow it to > obtain both when using a web-based component together with the user-agent= . Right, this didn't use to be possible, but Brian Ellin asked for this, and several people agreed it was a good idea. Unfortunately when that feature got added, it broke a bunch of other stuff: - all of the descriptive language about the user-agent flow is inaccurate - if anyone tries to use the verification code approach with the user-agent flow, the user-agent flow is no longer efficient So in the quest to add a new feature, we broke other features. Plus we didn't get the new feature right. This sounds like a normal software development project. =3D) Let me know what you think of the new language I proposed. Note that this pretty much requires that the "type" parameter return to the authorization URL. That's a good thing. If authorization servers know about the client environment, they do a better job of meeting the client's needs. (Also note that we tried leaving this parameter out of WRAP, and regretted it afterwards.) Cheers, Brian --_000_C85F172536FD1eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] user-agent flow needs a rewrite The problem with the original ‘type’ parameter and the fl= ows in general is that they tried to address a specific use case and then g= ot expanded (or overloaded) with other use cases. The user-agent and web-se= rver flows became the foundation of native applications, and there were peo= ple discussing using native application techniques for user-agent clients. = At the end, the flow names and prose became more confusing than helpful (I&= #8217;m not talking about the grouping of normative language).

The key here is to figure out what information about the client the server = actually needs, what it should obtain during registration, and what it can = figure out from other parameters. For example, if a client_id has a matchin= g secret, do you allow it to request an access token directly in the author= ization endpoint? If you do, is it going to include the same capabilities a= s an access token obtained using an authorization code and client authentic= ation? It seems like we need to address these questions head on.

The server can’t trust what the client is asking unless the client is= authenticated *and* the server can trust that authentication (i.e. Client = secret not used in a user-agent). For that, you need to establish some form= of trust with the client which in today’s world means registration. = If you are going to perform registration, that’s where you should ask= about the nature of the client so you can optimize the user experience and= the overall security.

The way I understand the Twitter use case is that the client isn’t ju= st a user-agent trying to get both an access token and authorization code (= or refresh token), but a more complex client which includes both a user-age= nt and web-based components, each providing a different functionality, but = both using the same, single end-user authorization (i.e. The end-user is as= ked once).

EHL




On 7/10/10 9:26 PM, "Brian Eaton" <beaton@google.com> wrote:

On Sat, Jul 10, 2010 at 9:05 PM, Eran Hamme= r-Lahav <eran@hueniverse.com> wro= te:
> There is no user-agent flow anymore.

Yeah.  That's a bug. =3D(

> The request was to allow it to
> obtain both when using a web-based component together with the user-ag= ent.

Right, this didn't use to be possible, but Brian Ellin asked for this,
and several people agreed it was a good idea.  Unfortunately when that=
feature got added, it broke a bunch of other stuff:
- all of the descriptive language about the user-agent flow is inaccurate - if anyone tries to use the verification code approach with the
user-agent flow, the user-agent flow is no longer efficient

So in the quest to add a new feature, we broke other features.  Plus we didn't get the new feature right.  This sounds like a normal
software development project. =3D)

Let me know what you think of the new language I proposed.

Note that this pretty much requires that the "type" parameter ret= urn
to the authorization URL.  That's a good thing.  If authorization=
servers know about the client environment, they do a better job of
meeting the client's needs.

(Also note that we tried leaving this parameter out of WRAP, and
regretted it afterwards.)

Cheers,
Brian

--_000_C85F172536FD1eranhueniversecom_-- From eve@xmlgrrl.com Sun Jul 11 06:46: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 029DF3A6986 for ; Sun, 11 Jul 2010 06:46:22 -0700 (PDT) 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 bTN-EWZ5utNZ for ; Sun, 11 Jul 2010 06:46:20 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 539033A6981 for ; Sun, 11 Jul 2010 06:46:19 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.3/8.14.3) with ESMTP id o6BDkP4G010434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Jul 2010 06:46:25 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112660D9E04@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 11 Jul 2010 06:46:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112660D9E04@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1081) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 13:46:22 -0000 +1. James states two important requirements (don't stand in the way of = dynamic config, provide end-user authz endpoint at a minimum) we need to = meet, whatever we pick. Eve On 11 Jul 2010, at 6:12 AM, Manger, James H wrote: > Brian, >=20 >> Or even just: >>=20 >> WWW-Authenticate: OAuth2 >>=20 >> Seriously. >=20 > I seriously hope not. > It gives no chance for a client to work with a service without being = pre-configured with a whole lot of service-specific knowledge -- in = addition to an app-id/password. >=20 > I don't think a realm parameter adds much value to a "WWW-Auth.: = OAuth2" header, other than complying with RFC2617. The header does need = to provide an end-user authorization endpoint. Ideally, that one URI = would be sufficient for the protocol to succeed (though currently you = need to separately provide a token endpoint as well). >=20 > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler From eran@hueniverse.com Sun Jul 11 07:37:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF093A6979 for ; Sun, 11 Jul 2010 07:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.262, 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 pNZQl9r74Tz4 for ; Sun, 11 Jul 2010 07:37:40 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 87A6C3A6986 for ; Sun, 11 Jul 2010 07:37:40 -0700 (PDT) Received: (qmail 2346 invoked from network); 11 Jul 2010 14:37:46 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 14:37:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 11 Jul 2010 07:37:45 -0700 From: Eran Hammer-Lahav To: Brian Eaton , OAuth WG Date: Sun, 11 Jul 2010 07:37:43 -0700 Thread-Topic: [OAUTH-WG] return to draft 6 spec org? Thread-Index: AcsgsAgjFOdFxRVORMWvRjo+mDi0HAAVpbJm Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85F254736FD6eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] return to draft 6 spec org? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 14:37:44 -0000 --_000_C85F254736FD6eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The spec organization isn't about reusing prose, but about providing a cons= istent and well-defined protocol architecture. WRAP called the different fl= ows for each client 'profiles' which was wrong in WRAP because it wasn't ac= tually profiling anything - it was describing completely separate flows. Th= e current spec went back to calling them profiles because now they are trul= y profiles of the generic framework defined by the two endpoints. I am unhappy with the current state of the client profiles in the introduct= ion so we agree on that. But where you call for a complete restructure, I p= refer making the current structure more useful. I think the way to solve it is to make them more detailed and normative. Th= is will retain the general framework as current specified, but will provide= a reference-able description of useful profiles. This will also make it ea= sier to discuss the security attributes of each profile. In addition, it is= probably only be useful to define the user-agent and web-based as fully sp= ecified profiles, given that the rest are not really profiles but vague gui= delines as to how to use OAuth for other "stuff". EHL On 7/10/10 9:15 PM, "Brian Eaton" wrote: I think it would be a good idea to return to the draft 6 organization. Draft 6: normative language for each flow was called out separately, and was described from start to finish, in chronological order, with no interruption. Each step showed what a client should send, and what an authorization server should return. Draft 7 and further: flows are merged to reuse spec language. Steps for any given use case are now interrupted with steps for other use cases. For example, consider a client developer who wants to implement the web server flow. First they have to read section 3.1, to describe the redirect they need to send to the authorization server. Then they read section 3.2, to see the redirect back. Then they read section 4.1.1, to see the request they send to the authorization server. Then they skip a few pages, because they don't care about assertions or passwords or refresh tokens. They they read section 4.2, to see the response from the authorization serv= er. Then they skip several more pages to get to section 5, so they can access d= ata. Then they skip back to section 4.1.4, because they need to refresh their to= ken. Compare this to draft 6: - read section 2.5 this is everything you need to get a token, with no intervening cruft about credentials you don't have. - read section 4 this is everything you need to use a token. - read section 3 this is everything you need to refresh a token. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C85F254736FD6eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] return to draft 6 spec org? The spec organization isn’t about reusing prose, but about prov= iding a consistent and well-defined protocol architecture. WRAP called the = different flows for each client ‘profiles’ which was wrong in W= RAP because it wasn’t actually profiling anything – it was desc= ribing completely separate flows. The current spec went back to calling the= m profiles because now they are truly profiles of the generic framework def= ined by the two endpoints.

I am unhappy with the current state of the client profiles in the introduct= ion so we agree on that. But where you call for a complete restructure, I p= refer making the current structure more useful.

I think the way to solve it is to make them more detailed and normative. Th= is will retain the general framework as current specified, but will provide= a reference-able description of useful profiles. This will also make it ea= sier to discuss the security attributes of each profile. In addition, it is= probably only be useful to define the user-agent and web-based as fully sp= ecified profiles, given that the rest are not really profiles but vague gui= delines as to how to use OAuth for other “stuff”.

EHL


On 7/10/10 9:15 PM, "Brian Eaton" <beaton@google.com> wrote:

I think it would be a good idea to return t= o the draft 6 organization.

Draft 6: normative language for each flow was called out separately,
and was described from start to finish, in chronological order, with
no interruption.  Each step showed what a client should send, and what=
an authorization server should return.

Draft 7 and further: flows are merged to reuse spec language.  Steps for any given use case are now interrupted with steps for other use
cases.

For example, consider a client developer who wants to implement the
web server flow.

First they have to read section 3.1, to describe the redirect they
need to send to the authorization server.

Then they read section 3.2, to see the redirect back.

Then they read section 4.1.1, to see the request they send to the
authorization server.

Then they skip a few pages, because they don't care about assertions
or passwords or refresh tokens.

They they read section 4.2, to see the response from the authorization serv= er.

Then they skip several more pages to get to section 5, so they can access d= ata.

Then they skip back to section 4.1.4, because they need to refresh their to= ken.


Compare this to draft 6:
- read section 2.5
   this is everything you need to get a token, with no inter= vening
cruft about credentials you don't have.

- read section 4
   this is everything you need to use a token.

- read section 3
   this is everything you need to refresh a token.

Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C85F254736FD6eranhueniversecom_-- From eve@xmlgrrl.com Sun Jul 11 08:25:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 406EB3A67B1 for ; Sun, 11 Jul 2010 08:25:19 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, 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 5E1ZCkhgnzCA for ; Sun, 11 Jul 2010 08:25:18 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id D4E553A69BB for ; Sun, 11 Jul 2010 08:25:16 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.3/8.14.3) with ESMTP id o6BFPMU0011775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Jul 2010 08:25:22 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-515--92988685 From: Eve Maler In-Reply-To: Date: Sun, 11 Jul 2010 08:25:21 -0700 Message-Id: <6FCD7CB9-803B-4FC2-8F61-41CB38ABF5AF@xmlgrrl.com> References: To: David Recordon X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 15:25:19 -0000 --Apple-Mail-515--92988685 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii D. On 8 Jul 2010, at 9:29 AM, David Recordon wrote: > I'm honestly trying to decide myself and a few other people are in = similar situations. Thus a poll: > A) Yes, I'm going to be in Maastricht > B) Maybe, depends on the number of OAuth WG members going > C) Maybe, depends on some other reason > D) No >=20 > If you're missing context, in a few weeks it is the IETF meeting in = Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting = scheduled all afternoon Tuesday the 27th. >=20 > Thanks, > --David > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler --Apple-Mail-515--92988685 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I'm honestly trying to decide myself and a few other = people are in similar situations. Thus a poll:
A) Yes, I'm going to = be in Maastricht
B) Maybe, depends on the number of OAuth = WG members going
C) Maybe, depends on some other reason
D) = No

If you're missing context, in a few weeks it = is the IETF meeting in Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a meeting scheduled all afternoon Tuesday the = 27th.

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


= --Apple-Mail-515--92988685-- From eran@hueniverse.com Sun Jul 11 08:36: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 237C73A67F5 for ; Sun, 11 Jul 2010 08:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI+qFDRj+qNG for ; Sun, 11 Jul 2010 08:36:23 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 7AC153A67A1 for ; Sun, 11 Jul 2010 08:36:23 -0700 (PDT) Received: (qmail 21978 invoked from network); 11 Jul 2010 15:36:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 15:36:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 11 Jul 2010 08:36:30 -0700 From: Eran Hammer-Lahav To: Brian Eaton , OAuth WG Date: Sun, 11 Jul 2010 08:36:28 -0700 Thread-Topic: [OAUTH-WG] nits in oauth2 spec Thread-Index: AcsfMTw2CYAGm/1+T0ejOHPzuLS4uQB3ZfGX Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85F330C36FDCeranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] nits in oauth2 spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 15:36:32 -0000 --_000_C85F330C36FDCeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This makes sense. I think this requires changing the 'basic client credenti= als' to 'client password credentials'. While not necessary, we might want to change 'client_secret' to 'client_pas= sword' to be more explicit and descriptive (since 'secret' can be many thin= gs, but we are using it in an explicitly limited way - symmetric password). EHL On 7/8/10 11:37 PM, "Brian Eaton" wrote: "basic credentials". This makes sense if you've read the BNF in the http basic auth spec, and is otherwise weird. I think everywhere that refers in prose to the username and password should call them "username and password" or "password credentials". Let's not use "basic credentials" at all. We could use "basic-credentials" in BNF that refers to the exact format used by the HTTP spec, but otherwise let's skip it. --_000_C85F330C36FDCeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] nits in oauth2 spec This makes sense. I think this requires changing the ‘basic cli= ent credentials’ to ‘client password credentials’.

While not necessary, we might want to change ‘client_secret’ to= ‘client_password’ to be more explicit and descriptive (since &= #8216;secret’ can be many things, but we are using it in an explicitl= y limited way – symmetric password).

EHL


On 7/8/10 11:37 PM, "Brian Eaton" <beaton@google.com> wrote:

"basic credentials".  This m= akes sense if you've read the BNF in the
http basic auth spec, and is otherwise weird.  I think everywhere that=
refers in prose to the username and password should call them
"username and password" or "password credentials". &nbs= p;Let's not use
"basic credentials" at all.  We could use "basic-creden= tials" in BNF
that refers to the exact format used by the HTTP spec, but otherwise
let's skip it.
--_000_C85F330C36FDCeranhueniversecom_-- From Jeff.Hodges@KingsMountain.com Sun Jul 11 10:23:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 132613A6862 for ; Sun, 11 Jul 2010 10:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j4rXgJRPJEp for ; Sun, 11 Jul 2010 10:23:48 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 99EB13A684F for ; Sun, 11 Jul 2010 10:23:48 -0700 (PDT) Received: (qmail 823 invoked by uid 0); 11 Jul 2010 17:23:55 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 11 Jul 2010 17:23:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=gJCKJ/nV1nlRZI8DArEj5hH39aQ0eDJbPEHn4yUbaPPBdibsYJgO6rMME7YA/dQP1/a0WN0NYdVfkDprkyH/xb0xshLW8lbbh4kspXbhPqHKpwqlvGIBxwSj4ZTDbQge; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OY0Fv-0004Wm-5b for oauth@ietf.org; Sun, 11 Jul 2010 11:23:55 -0600 Message-ID: <4C39FE29.3020300@KingsMountain.com> Date: Sun, 11 Jul 2010 10:23:53 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF oauth WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [OAUTH-WG] POLL: Are you going to Maastricht? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 17:23:50 -0000 stpeter@stpeter.im wrote: > > And don't forget about several other sessions that might be of interest on > Monday and Tuesday: There's also HyBi aka WebSockets on Friday. =JeffH (who'll be in Maastricht) From eran@hueniverse.com Sun Jul 11 11:22: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 F215E3A68A5 for ; Sun, 11 Jul 2010 11:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 nMDJx4-XN0lE for ; Sun, 11 Jul 2010 11:22:51 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id AC2123A69DB for ; Sun, 11 Jul 2010 11:22:50 -0700 (PDT) Received: (qmail 12233 invoked from network); 11 Jul 2010 18:22:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 18:22:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 11 Jul 2010 11:22:55 -0700 From: Eran Hammer-Lahav To: Brian Eaton , OAuth WG Date: Sun, 11 Jul 2010 11:22:53 -0700 Thread-Topic: [OAUTH-WG] nits in oauth2 spec Thread-Index: AcsfMTw2CYAGm/1+T0ejOHPzuLS4uQB9NdPs Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] nits in oauth2 spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 18:22:52 -0000 On 7/8/10 11:37 PM, "Brian Eaton" wrote: > 1.4.4 Autonomous >=20 > I think we need a better definition of Autonomous Clients, but I'm > damned if I can think of one right now. >=20 > "The scope of the access > token is limited to the protected resources under the control of > the client, or that of another resource owner previously arranged > with the authorization server." >=20 > That sounds a lot more complicated than it is. >=20 > How about "The access token does not allow the client to act on behalf > of an end-user. The token identifies the client, and so is scoped to > the resources to which the client has direct access." This is not true. Autonomous means the authorization is external to the authorization server (i.e. another trust framework). An assertion can still represent an end-user. Previous texts positioned autonomous as the client acting on its own behalf which was largely rejected by the group. EHL From eran@hueniverse.com Sun Jul 11 11:41: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 A498A3A69F7 for ; Sun, 11 Jul 2010 11:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xi415z0fivzp for ; Sun, 11 Jul 2010 11:41:34 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id EB4743A69E9 for ; Sun, 11 Jul 2010 11:41:33 -0700 (PDT) Received: (qmail 18401 invoked from network); 11 Jul 2010 18:41:40 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 18:41:40 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 11 Jul 2010 11:41:40 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Sun, 11 Jul 2010 11:41:37 -0700 Thread-Topic: ' force_auth' request parameter Thread-Index: AcsgWeSCtWnD8MWzS8aE8UFXBLFA1gAzsz1r Message-ID: In-Reply-To: <4c38b569.0309960a.3208.295b@mx.google.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85F5E7136FE7eranhueniversecom_" MIME-Version: 1.0 Subject: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 18:41:39 -0000 --_000_C85F5E7136FE7eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The following was submitted via the shared-copy page but does not belong wi= th editorial feedback. This needs to be discussed and supported on the list= before added the specification. I think it belongs where 'immediate' is sp= ecified. EHL ------ Forwarded Message From: An anonymous reader Date: Sat, 10 Jul 2010 11:01:11 -0700 To: Eran Hammer-Lahav Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol "Colin Snover" left these comments on your copy: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol As proposed on the ML, a new parameter to counteract the current behav= iour of OAuth 1.0a authorization servers which is to assume that the accoun= t logged into the user-agent is the account that should be checked for acce= ss: force_auth OPTIONAL. The parameter value must be set to "true" or "false". If set to "true", the authorization server MUST prompt the end-use= r to authenticate and approve access. The authorization server MUST NOT mak= e any assumptions as to the identity of the entity requesting access, even = if another automatic mechanism is available to do so (e.g. browser cookies)= . If set to "false" or not present, the authorization server MAY aut= omatically grant access to the client if it is able to determine that acces= s was previously granted. link =BB tools.ietf.org/html/draft-ietf-oauth-v2-09 =B7 Original page ________________________________ via sharedcopy.com ------ End of Forwarded Message --_000_C85F5E7136FE7eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ' force_auth' request parameter The following was submitted via the shared-copy page but does not bel= ong with editorial feedback. This needs to be discussed and supported on th= e list before added the specification. I think it belongs where ‘imme= diate’ is specified.

EHL

------ Forwarded Message
From: An anonymous reader <mailman@sharedcopy.com>
Date: Sat, 10 Jul 2010 11:01:11 -0700
To: Eran Hammer-Lahav <eran@hueni= verse.com>
Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol

 "Colin Snover" left= these comments on your copy:
 
draft-ietf-oauth-= v2-09 - The OAuth 2.0 Protocol <http://r6.sharedcopy.com/6bnqq8v>
    &= nbsp;   

     As proposed on the ML, a new parameter to cou= nteract the current behaviour of OAuth 1.0a authorization servers which is = to assume that the account logged into the user-agent is the account that s= hould be checked for access:

force_auth
         OPTIONAL. The paramet= er value must be set to "true" or "false".

         If set to "true&= quot;, the authorization server MUST prompt the end-user to authenticate an= d approve access. The authorization server MUST NOT make any assumptions as= to the identity of the entity requesting access, even if another automatic= mechanism is available to do so (e.g. browser cookies).

         If set to "false= " or not present, the authorization server MAY automatically grant acc= ess to the client if it is able to determine that access was previously gra= nted.         link » <http://r6.sharedcopy.com/6b= nqq8v#shcp21>
 

tools.ietf.org/html/draft-ietf-oauth-v2-09 <http://r6.sharedcopy.com/6bnqq8v>  · Or= iginal page <http://tools.ietf.org/html/draft-ietf-oauth-v2-09>
  
 
via sharedcopy.com <http://sharedcopy.com/?ef>   List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 18:58:16 -0000 --_000_C85F625736FECeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are valid arguments for a SHOULD NOT issue a refresh token. I'll mak= e the necessary changes. EHL On 7/10/10 8:09 PM, "Brian Eaton" wrote: Hey folks - The client credentials flow should never return a refresh token, for the following reasons: - it's never necessary - it's a security problem - it's inefficient - it's confusing I'll go over each of those points in detail, but here are the changes to the spec I'd like to see. Page 8: diagram shows "with optional refresh token". Delete that. Somewhere in document: add a specific description of the client_id + client_secret produces access_token equation. (This seems to have been dropped in draft 7... or am I missing something?) Here are the detailed reasons why the refresh token in this flow is a bad i= dea. 1) it's never necessary In order to use a refresh token to get a new access token, you need to present a client-id and a client-secret. If you have a client-id and client-secret, you can just use the client credentials flow to get a new access token. So keeping the refresh token around serves no purpose. 2) it's a security problem Creating a refresh token is roughly equivalent to creating an alternate password (client secret) for the client. It's one more secret that needs to be protected. When a client using the client credentials flow is compromised, you need to reset their client secret to recover. But because this profile is creating refresh tokens, you also need to go and revoke all of the refresh tokens. 3) it's inefficient Refresh tokens are long-lived secrets. They need server-side storage. So every single time a client authenticates, you're going to have to allocate long-lived storage associated with that authentication. 4) it's confusing The spec offers no guidance as to when servers should return refresh tokens, or what clients ought to do with them. This is basically a trap. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C85F625736FECeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] client credentials returning a refresh token There are valid arguments for a SHOULD NOT issue a refresh token. &nb= sp;I’ll make the necessary changes.

EHL


On 7/10/10 8:09 PM, "Brian Eaton" <beaton@google.com> wrote:

Hey folks -

The client credentials flow should never return a refresh token, for
the following reasons:

- it's never necessary
- it's a security problem
- it's inefficient
- it's confusing

I'll go over each of those points in detail, but here are the changes
to the spec I'd like to see.

Page 8: diagram shows "with optional refresh token".  Delete= that.
Somewhere in document: add a specific description of the client_id +
client_secret produces access_token equation.  (This seems to have
been dropped in draft 7... or am I missing something?)


Here are the detailed reasons why the refresh token in this flow is a bad i= dea.

1) it's never necessary

In order to use a refresh token to get a new access token, you need to
present a client-id and a client-secret.

If you have a client-id and client-secret, you can just use the client
credentials flow to get a new access token.

So keeping the refresh token around serves no purpose.

2) it's a security problem

Creating a refresh token is roughly equivalent to creating an
alternate password (client secret) for the client.  It's one more
secret that needs to be protected.

When a client using the client credentials flow is compromised, you
need to reset their client secret to recover.  But because this
profile is creating refresh tokens, you also need to go and revoke all
of the refresh tokens.

3) it's inefficient

Refresh tokens are long-lived secrets.  They need server-side storage.=
 So every single time a client authenticates, you're going to have to<= BR> allocate long-lived storage associated with that authentication.

4) it's confusing

The spec offers no guidance as to when servers should return refresh
tokens, or what clients ought to do with them.

This is basically a trap.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C85F625736FECeranhueniversecom_-- From eran@hueniverse.com Sun Jul 11 12:28: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 23C283A69FD for ; Sun, 11 Jul 2010 12:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.224, 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 2QcyDD4IgZ1v for ; Sun, 11 Jul 2010 12:28:16 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 931EF3A67FC for ; Sun, 11 Jul 2010 12:28:16 -0700 (PDT) Received: (qmail 4099 invoked from network); 11 Jul 2010 19:28:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 19:28:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 11 Jul 2010 12:28:01 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Sun, 11 Jul 2010 12:27:58 -0700 Thread-Topic: [OAUTH-WG] What to do about 'realm' Thread-Index: Acsgxhn8bBr78OcyQIyiiGuV6BDzdQAaREVM Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85F694F36FF1eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 19:28:23 -0000 --_000_C85F694F36FF1eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [this has noting to do with realm] Any solution should be: - Extensible - we removed the few discovery parameters from the core spec d= ue to lack of maturity and consensus. However, we clearly have enough stron= g interest in reintroducing them as extensions. The WWW-Authenticate header= is the natural place to include them. - Human-friendly - I think being able to look at the header and immediately= see what it means is useful. Is there a JSON profile suitable for inclusio= n in HTTP headers? I would like to avoid BASE64 when a person is likely to = take a look at the header. Otherwise debugging and command line interaction= become impractical. On top of that, I am still not sure about the best way to accommodate both = a signed and unsigned requests, but the idea of a two separately defined sc= hemes isn't appealing (not having two, just defining them in two different = places). As for the scheme name, I have changed my mind about using 'Token' and am n= ow proposing 'OAuth'. The reason for that is that the current scheme extens= ibility is directly linked to the OAuth protocol (for example, 'scope' para= meter). This voids my claim that it is a completely orthogonal scheme. Beca= use we are not using the 'oauth_' prefix, telling the difference is trivial= and there is no need to include a version parameter (since 2.0 is marking = 1.0 as obsolete). So if you can suggest a scheme syntax that accommodates the above, and is b= ased on JSON, I'm very supportive. EHL On 7/10/10 11:55 PM, "Brian Eaton" wrote: On Sun, Jun 27, 2010 at 6:51 PM, Eran Hammer-Lahav wr= ote: > 1. Leave it as required under the definition of RFC 2617 (i.e. provide no > help, developers will need to ready 2617 and figure out what to do with i= t). > > 2. Update 2617 to remove the requirement - this is not going to be easy o= r > possible to predict success. > > 3. Provide specific guidance as to what to do with the realm parameter. > > 4. Something else. Let's do something else. We've made great progress on simplifying the spec and unifying the different formats to minimize the number of parsers and serializers that are needed. The www-authenticate header is one of the bits of nastiness left. Let's use a format like this: WWW-Authenticate: OAuth2 base64() Or even just: WWW-Authenticate: OAuth2 Seriously. There is some precedent for this. The Negotiate and NTLM schemes ditched the name=3D"value" syntax, and they are widely implemented. This demonstrates two things: 1) dropping the name=3D"value" syntax won't break the internet, because widely deployed schemes have already done it. 2) "realm" is not necessary in order to have a successful authentication protocol. As far as I can tell, there is no good reason for RFC 2617 to specify the syntax it does. It's convenient for digest auth, and kind of a pain everywhere else. So let's just drop it. Cheers, Brian --_000_C85F694F36FF1eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] What to do about 'realm' [this has noting to do with realm]

Any solution should be:

- Extensible – we removed the few discovery parameters from the core = spec due to lack of maturity and consensus. However, we clearly have enough= strong interest in reintroducing them as extensions. The WWW-Authenticate = header is the natural place to include them.

- Human-friendly – I think being able to look at the header and immed= iately see what it means is useful. Is there a JSON profile suitable for in= clusion in HTTP headers? I would like to avoid BASE64 when a person is like= ly to take a look at the header. Otherwise debugging and command line inter= action become impractical.

On top of that, I am still not sure about the best way to accommodate both = a signed and unsigned requests, but the idea of a two separately defined sc= hemes isn’t appealing (not having two, just defining them in two diff= erent places).

As for the scheme name, I have changed my mind about using ‘TokenR= 17; and am now proposing ‘OAuth’. The reason for that is that t= he current scheme extensibility is directly linked to the OAuth protocol (f= or example, ‘scope’ parameter). This voids my claim that it is = a completely orthogonal scheme. Because we are not using the ‘oauth_&= #8217; prefix, telling the difference is trivial and there is no need to in= clude a version parameter (since 2.0 is marking 1.0 as obsolete).

So if you can suggest a scheme syntax that accommodates the above, and is b= ased on JSON, I’m very supportive.

EHL


On 7/10/10 11:55 PM, "Brian Eaton" <beaton@google.com> wrote:

On Sun, Jun 27, 2010 at 6:51 PM, Eran Hamme= r-Lahav <eran@hueniverse.com> wro= te:
> 1. Leave it as required under the definition of RFC 2617 (i.e. provide= no
> help, developers will need to ready 2617 and figure out what to do wit= h it).
>
> 2. Update 2617 to remove the requirement – this is not going to = be easy or
> possible to predict success.
>
> 3. Provide specific guidance as to what to do with the realm parameter= .
>
> 4. Something else.

Let's do something else.

We've made great progress on simplifying the spec and unifying the
different formats to minimize the number of parsers and serializers
that are needed.  The www-authenticate header is one of the bits of nastiness left.

Let's use a format like this:

WWW-Authenticate: OAuth2 base64(<json>)

Or even just:

WWW-Authenticate: OAuth2

Seriously.

There is some precedent for this.  The Negotiate and NTLM schemes
ditched the name=3D"value" syntax, and they are widely implemente= d.
This demonstrates two things:
1) dropping the name=3D"value" syntax won't break the internet, b= ecause
widely deployed schemes have already done it.
2) "realm" is not necessary in order to have a successful
authentication protocol.

As far as I can tell, there is no good reason for RFC 2617 to specify
the syntax it does.  It's convenient for digest auth, and kind of a pain everywhere else.

So let's just drop it.

Cheers,
Brian

--_000_C85F694F36FF1eranhueniversecom_-- From eran@hueniverse.com Sun Jul 11 13:03: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 874863A6A02 for ; Sun, 11 Jul 2010 13:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.218, 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 BOCe4B5XCssd for ; Sun, 11 Jul 2010 13:03:27 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9662E3A6A01 for ; Sun, 11 Jul 2010 13:03:27 -0700 (PDT) Received: (qmail 3190 invoked from network); 11 Jul 2010 20:03:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 20:03:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 11 Jul 2010 13:03:34 -0700 From: Eran Hammer-Lahav To: Brian Eaton , OAuth WG Date: Sun, 11 Jul 2010 13:03:31 -0700 Thread-Topic: [OAUTH-WG] simplify authorization header? Thread-Index: AcsgxSnLYYIRqJ1CR+alJI460nDGLwAbvikk Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85F71A336FF4eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] simplify 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: Sun, 11 Jul 2010 20:03:31 -0000 --_000_C85F71A336FF4eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 with the exception of a new scheme name for signatures. I think we need = to get to a stable draft before we can figure it out. But I would like to k= eep the core spec open for (small) changes until we do. I added this to -10: Authorization: OAuth [optional extension key=3D"value" pairs] EHL On 7/10/10 11:49 PM, "Brian Eaton" wrote: The current spec has the client create a "name=3D'value'" syntax exactly once, in the Authorization header. We could eliminate a fair chunk of client code by removing the name=3D"value" syntax and going with the approach taken by the Basic, NTLM, and Negotiate schemes: Authorization: OAuth2 No more escaping beyond what your HTTP library provides. Just call setHeader("OAuth2 " + token), and you're on your merry way. We are going to need slightly more flexibility once the signature proposal settles down. For that, I'd suggest using a different scheme name. Authorization: OAuth2Signed Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C85F71A336FF4eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] simplify authorization header? +1 with the exception of a new scheme name for signatures. I think we= need to get to a stable draft before we can figure it out. But I would lik= e to keep the core spec open for (small) changes until we do.

I added this to -10:

Authorization: OAuth <token> [optional extension key=3D”value&#= 8221; pairs]

EHL



On 7/10/10 11:49 PM, "Brian Eaton" <beaton@google.com> wrote:

The current spec has the client create a &q= uot;name=3D'value'" syntax exactly
once, in the Authorization header.  We could eliminate a fair chunk of=
client code by removing the name=3D"value" syntax and going with = the
approach taken by the Basic, NTLM, and Negotiate schemes:

Authorization: OAuth2 <token>

No more escaping beyond what your HTTP library provides.  Just call setHeader("OAuth2 " + token), and you're on your merry way.

We are going to need slightly more flexibility once the signature
proposal settles down.  For that, I'd suggest using a different scheme=
name.

Authorization: OAuth2Signed <self-describing-signed-token>

Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C85F71A336FF4eranhueniversecom_-- From eran@hueniverse.com Sun Jul 11 13:22: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 972EF3A672E for ; Sun, 11 Jul 2010 13:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.212, 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 bIEt7rwYGC8L for ; Sun, 11 Jul 2010 13:22:02 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 11DE53A6A03 for ; Sun, 11 Jul 2010 13:22:02 -0700 (PDT) Received: (qmail 3799 invoked from network); 11 Jul 2010 20:22:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 20:22:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 11 Jul 2010 13:22:08 -0700 From: Eran Hammer-Lahav To: Brian Eaton , OAuth WG Date: Sun, 11 Jul 2010 13:22:05 -0700 Thread-Topic: [OAUTH-WG] redirect URI matching in section 3 Thread-Index: AcsgxIDHUqmnd6gLSpGN7WcOW8wZswAcjmo4 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85F75FD36FF7eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] redirect URI matching in section 3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 20:22:14 -0000 --_000_C85F75FD36FF7eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a na=EFve questions: Why not just say the server MUST match the redirection URI if one was previ= ously registered, and require registration for user-agent clients? EHL On 7/10/10 11:44 PM, "Brian Eaton" wrote: Section 3 says [[ provide guidance on how to perform matching ]]. I can write the guidance on performing redirect URI matching, but it varies per profile. User-Agent profile with registered client: matching is critical, MUST verify is appropriate Web server profile with client secret you trust: matching is not critical. Matching provides some extra security. MAY is appropriate. MUST is really bad, since it prevents clients from moving redirect URIs. Any profile where you don't trust the client secret (e.g. installed apps): Redirect URI matching is useless. SHOULD NOT is appropriate. So this is another case where the client needs to pass some indicator to the server (either via type=3D parameter, or as policy associated with client_id) of the environment in which it is running. The type parameter needs to signal: - how the authorization server passes data (fragment or query string) - what data is passed (access token, or just verification code) Here's some proposed language on redirect URI matching. New Section 3.1: Overview of Callback URL Authentication The OAuth 2 protocol distributes authorization credentials to web-based applications by redirecting the user-agent to the client with some form of authorization credential on the URL. The authorization credential is either an access token, or a authorization code. In either case, authenticating the URL to which the credential is returned is critical to the security of the protocol. Credentials returned on redirect URLs may leak in several ways: - Referer headers sent by the browser to untrusted third-party web sites - open redirectors - web server log files - browser history Authorization servers have several techniques available for authenticating callback URLs and defending against those leaks: - using client authentication credentials to authenticate callback URLs - callback URL white-listing - passing authorization credentials on URI fragments - issuing short-lived credentials to ease recovery in the event of compromi= se 3.1.1 Authorization Policy In certain circumstances the Authorization Server is not able to perfectly authenticate the callback URL. For example, multiple installed applications may use the same callback URL, and there is no way for the Authorization Server to reliably distinguish among them. Authorization Servers deal with this ambiguity by choosing different policies on when to issue authorization credentials. If the authorization server is able to authenticate the callback URL with a high degree of confidence - the authorization server MAY decline to prompt the user to grant authorization, immediately rejecting the authorization request. - the authorization server MAY issue an authorization credential after prompting the user. - the authorization server MAY issue a new authorization credential without prompting the user, if the authorization server knows that the user has previously approved this client. If the authorization server is not able to authenticate the callback URL: - the authorization server MAY decline to prompt the user to grant authorization, immediately rejecting the authorization request. - the authorization server MAY issue an authorization credential after prompting the user. - the authorization server MUST NOT issue an authorization credential without prompting the user. 3.1.2 Callback URL Authentication Techniques Client Credentials MAY be used to authenticate callback URLs. If an Authorization Server wishes to authenticate callback URLs with client credentials, all of the following conditions MUST be met: - the client credentials MUST have been issued to a web application with a server-side component. - the Authorization Server MUST believe that the client credentials are stored securely. - the Authorization Server MUST return only an authorization code to the callback URL. An access token MUST NOT be returned. In all other circumstances, the Authorization Server MUST use callback URL white-listing to authenticate callback URLs. However, appropriate callback URL white-listing varies for different client environments. There are various techniques for callback URL white-listing. The list in this document is not exhaustive, and Authorization Servers MAY implement other techniques at their discretion. This document will consider the following approaches: - domain white-listing Authorization Servers white-list entire domains, e.g. '*.example.com'. Authorization servers may include the protocol in this white-list, e.g. 'all https web sites on *.example.com'. Any page on any host in that domain is accepted. - host white-listing Authorization Servers white-list entire hosts, e.g. 'www.example.com'. Authorization servers may include the protocol in the white-list, e.g. 'https://www.example.com'. Any page on that host is accepted. - path white-listing Authorization Servers white-list specific paths on a particular host, e.g. 'https://www.example.com/path'. Any page beneath that path is accepted. - page white-listing Authorization Servers white-list a specific page on a particular host, e.g. 'https://www.example.com/path/page'. The query string and URI fragment may vary, but all other components of the URL are fixed and must match that page. - full URL white-listing Authorization Servers white-list a specific URL, e.g. 'https://www.example.com/path/page?query'. Any callback URL that does not completely match that URL is rejected. The following sections offer guidance to Authorization Servers and Client developers on how to handle callback URL authentication. For better security, Authorization Servers and Clients should rely on a combination of client credentials and callback URL white-listing to authenticate callback URLs. Section 3.1.3 Secure Callback URLs for the Web Server Profile Client application developers using the web server profile should take care that their callback URLs preserve the security of the profile. Callback URL pages MUST NOT link or or redirect to untrusted content from those pages, since the authorization code may leak in the referer header. Callback URL pages MUST NOT forward the authorization code to an untrusted = page. Callback URL pages SHOULD redirect to a trusted page immediately after receiving the authorization code in the URL. This prevents the authorization code from remaining in the browser history, or from inadvertently leaking in a referer header. Callback URL pages SHOULD NOT log the authorization code. Callback URL pages SHOULD be CSRF protected. (TODO: dig up the language in OAuth 1.0a, it was pretty good, I think...) Section 3.1.4 Callback URL Authentication for the Web Server Profile The web server profile returns an authorization code on the callback URL. Authorization codes returned on callback URLs are very prone to leaking in referer headers, open redirectors, web server log files, and browser history. Authorization Servers MAY omit callback URL white-listing, but only if they are using client credentials to authenticate callback URLs. If client credentials are being used, any type of callback URL white-listing will improve security. Different types of white-listing provide different levels of security. - domain- and host- whitelisting Domain and host white-listing rules are very broad, and so are very vulnerable to the leaks discussed in section 3.1. Domain- and host- white-listing MUST NOT be used alone. Domain and host white-listing MAY be used in combination with using client credentials to authenticate callback URLs. - path white-listing Path white-listing is somewhat broad, and may be vulnerable to the leaks discussed in section 3.1. Path white-listing MUST NOT be used alone. Path white-listing MAY be used in combination with using client credentials to authenticate callback URLs. When using path white-listing, Authorization servers MUST defend against directory traversal attacks by canonicalizing the path. Appropriate path canonicalization algorithms vary for different types of web-servers, e.g. "\..\" may represent a parent directory in some web servers, and not in others. - page and URL white-listing Page and URL white-listing are very specific, but may still be vulnerable to some of the leaks discussed in section 3.1 if the callback URL page does not follow the security recommendations in section 3.1.3. These types of white-listing MAY be used alone, or in combination with client credentials to authenticate callback URLs. When full URL white-listing is used, Authorization Servers MUST allow the "state" query parameter to vary. Section 3.1.4 Secure Callback URLs for the User-Agent Profile Client application developers using the user-agent profile should take care that their callback URLs preserve the security of the profile. Because the user-agent profile returns an access token on the URI fragment, many types of leaks are less likely. However, incorrect code can still leak the authorization credentials. Callback URL pages MUST NOT forward the access token or authorization code to an untrusted page. Callback URLs rendered in a top-level browser window cannot prevent the access token from remaining in the browser history. Whenever possible, client applications SHOULD use an iframe to receive callbacks so that the access token does not appear in the browser history. [[Note that Authorization Servers SHOULD NOT allow their approval pages to be iframed due to the risk of click-jacking attacks, so this only works for immediate mode. Browser security gets complicated.]] If callback URLs must be rendered in a top-level browser window, client applications SHOULD redirect immediately after receiving the callback URL to remove the access token from the URL bar. This prevents the user from inadvertently copying their access token. Callback URL pages SHOULD be CSRF protected. (TODO: dig up the language in OAuth 1.0a, it was pretty good, I think...) Section 3.1.4 Callback URL Authentication for the User-Agent profile Because the user-agent profile returns an access token on the callback URL, client credentials cannot be used to authenticate the callback URL. Callback URL white-listing is the only possible way to authenticate the callback URL. However, because the authorization credentials are always returned on the URL fragment, the opportunity for leaking credentials via referer headers and open redirectors is reduced. Different types of white-listing provide different levels of security. - domain- white-listing Domain white-listing is very broad. Domain white-listing MUST NOT be used, because of the risk of malicious code running under some host in the domain. - host- white-listing Host white-listing is very broad. Authorization servers should be conservative in choosing which hosts they trust, but host white-listing MAY be used. - path white-listing Path white-listing is somewhat broad. Path white-listing MAY be used. When using path white-listing, Authorization servers MUST defend against directory traversal attacks by canonicalizing the path. Appropriate path canonicalization algorithms vary for different types of web-servers, e.g. "\..\" may represent a parent directory in some web servers, and not in others. - page and URL white-listing Page and URL white-listing are very specific. These types of white-listing MAY be used When full URL white-listing is used, Authorization Servers MUST allow the "state" query parameter to vary. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C85F75FD36FF7eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] redirect URI matching in section 3 This is a naïve questions:

Why not just say the server MUST match the redirection URI if one was previ= ously registered, and require registration for user-agent clients?

EHL


On 7/10/10 11:44 PM, "Brian Eaton" <beaton@google.com> wrote:

Section 3 says [[ provide guidance on how t= o perform matching ]].

I can write the guidance on performing redirect URI matching, but it
varies per profile.

User-Agent profile with registered client: matching is critical, MUST
verify is appropriate

Web server profile with client secret you trust: matching is not
critical.  Matching provides some extra security.  MAY is appropr= iate.
 MUST is really bad, since it prevents clients from moving redirect URIs.

Any profile where you don't trust the client secret (e.g. installed
apps): Redirect URI matching is useless.  SHOULD NOT is appropriate.
So this is another case where the client needs to pass some indicator
to the server (either via type=3D parameter, or as policy associated
with client_id) of the environment in which it is running.  The type parameter needs to signal:
- how the authorization server passes data (fragment or query string)
- what data is passed (access token, or just verification code)

Here's some proposed language on redirect URI matching.

New Section 3.1:  Overview of Callback URL Authentication

The OAuth 2 protocol distributes authorization credentials to
web-based applications by redirecting the user-agent to the client
with some form of authorization credential on the URL.  The
authorization credential is either an access token, or a authorization
code.  In either case, authenticating the URL to which the credential<= BR> is returned is critical to the security of the protocol.

Credentials returned on redirect URLs may leak in several ways:
- Referer headers sent by the browser to untrusted third-party web sites - open redirectors
- web server log files
- browser history

Authorization servers have several techniques available for
authenticating callback URLs and defending against those leaks:
- using client authentication credentials to authenticate callback URLs
- callback URL white-listing
- passing authorization credentials on URI fragments
- issuing short-lived credentials to ease recovery in the event of compromi= se

3.1.1 Authorization Policy

In certain circumstances the Authorization Server is not able to
perfectly authenticate the callback URL.  For example, multiple
installed applications may use the same callback URL, and there is no
way for the Authorization Server to reliably distinguish among them.
Authorization Servers deal with this ambiguity by choosing different
policies on when to issue authorization credentials.

If the authorization server is able to authenticate the callback URL
with a high degree of confidence
- the authorization server MAY decline to prompt the user to grant
authorization, immediately rejecting the authorization request.
- the authorization server MAY issue an authorization credential after
prompting the user.
- the authorization server MAY issue a new authorization credential
without prompting the user, if the authorization server knows that the
user has previously approved this client.

If the authorization server is not able to authenticate the callback URL: - the authorization server MAY decline to prompt the user to grant
authorization, immediately rejecting the authorization request.
- the authorization server MAY issue an authorization credential after
prompting the user.
- the authorization server MUST NOT issue an authorization credential
without prompting the user.

3.1.2 Callback URL Authentication Techniques

Client Credentials MAY be used to authenticate callback URLs.  If an Authorization Server wishes to authenticate callback URLs with client
credentials, all of the following conditions MUST be met:

- the client credentials MUST have been issued to a web application
with a server-side component.
- the Authorization Server MUST believe that the client credentials
are stored securely.
- the Authorization Server MUST return only an authorization code to
the callback URL.  An access token MUST NOT be returned.

In all other circumstances, the Authorization Server MUST use callback
URL white-listing to authenticate callback URLs.  However, appropriate=
callback URL white-listing varies for different client environments.

There are various techniques for callback URL white-listing.  The list=
in this document is not exhaustive, and Authorization Servers MAY
implement other techniques at their discretion.  This document will consider the following approaches:

- domain white-listing
   Authorization Servers white-list entire domains, e.g.
'*.example.com'.  Authorization servers may include the protocol in this white-list, e.g. 'all https web sites on *.example.com'.  Any
page on any host in that domain is accepted.

- host white-listing
   Authorization Servers white-list entire hosts, e.g.
'www.example.com'.  Authorization servers may include the protocol in<= BR> the white-list, e.g. 'https://www.examp= le.com'.  Any page on that host
is accepted.

- path white-listing
   Authorization Servers white-list specific paths on a part= icular
host, e.g. 'https://www.example.co= m/path'.  Any page beneath that path
is accepted.

- page white-listing
   Authorization Servers white-list a specific page on a par= ticular
host, e.g. 'https://www.examp= le.com/path/page'.  The query string and
URI fragment may vary, but all other components of the URL are fixed
and must match that page.

- full URL white-listing
   Authorization Servers white-list a specific URL, e.g.
'https://www.example.co= m/path/page?query'.  Any callback URL that does
not completely match that URL is rejected.


The following sections offer guidance to Authorization Servers and
Client developers on how to handle callback URL authentication.  For better security, Authorization Servers and Clients should rely on a
combination of client credentials and callback URL white-listing to
authenticate callback URLs.


Section 3.1.3 Secure Callback URLs for the Web Server Profile

Client application developers using the web server profile should take
care that their callback URLs preserve the security of the profile.

Callback URL pages MUST NOT link or or redirect to untrusted content
from those pages, since the authorization code may leak in the referer
header.

Callback URL pages MUST NOT forward the authorization code to an untrusted = page.

Callback URL pages SHOULD redirect to a trusted page immediately after
receiving the authorization code in the URL.  This prevents the
authorization code from remaining in the browser history, or from
inadvertently leaking in a referer header.

Callback URL pages SHOULD NOT log the authorization code.

Callback URL pages SHOULD be CSRF protected.  (TODO: dig up the
language in OAuth 1.0a, it was pretty good, I think...)



Section 3.1.4  Callback URL Authentication for the Web Server Profile<= BR>
The web server profile returns an authorization code on the callback
URL.  Authorization codes returned on callback URLs are very prone to<= BR> leaking in referer headers, open redirectors, web server log files,
and browser history.

Authorization Servers MAY omit callback URL white-listing, but only if
they are using client credentials to authenticate callback URLs.  If client credentials are being used, any type of callback URL
white-listing will improve security.

Different types of white-listing provide different levels of security.

- domain- and host- whitelisting
   Domain and host white-listing rules are very broad, and s= o are very
vulnerable to the leaks discussed in section 3.1.  Domain- and host- white-listing MUST NOT be used alone.  Domain and host white-listing MAY be used in combination with using client credentials to
authenticate callback URLs.

- path white-listing
   Path white-listing is somewhat broad, and may be vulnerab= le to the
leaks discussed in section 3.1.  Path white-listing MUST NOT be used alone.  Path white-listing MAY be used in combination with using
client credentials to authenticate callback URLs.
    When using path white-listing, Authorization server= s MUST defend
against directory traversal attacks by canonicalizing the path.
Appropriate path canonicalization algorithms vary for different types
of web-servers, e.g. "\..\" may represent a parent directory in s= ome
web servers, and not in others.

- page and URL white-listing
   Page and URL white-listing are very specific, but may sti= ll be
vulnerable to some of the leaks discussed in section 3.1 if the
callback URL page does not follow the security recommendations in
section 3.1.3.  These types of white-listing MAY be used alone, or in<= BR> combination with client credentials to authenticate callback URLs.

   When full URL white-listing is used, Authorization Server= s MUST
allow the "state" query parameter to vary.


Section 3.1.4 Secure Callback URLs for the User-Agent Profile

Client application developers using the user-agent profile should take
care that their callback URLs preserve the security of the profile.
Because the user-agent profile returns an access token on the URI
fragment, many types of leaks are less likely.  However, incorrect
code can still leak the authorization credentials.

Callback URL pages MUST NOT forward the access token or authorization
code to an untrusted page.

Callback URLs rendered in a top-level browser window cannot prevent
the access token from remaining in the browser history.  Whenever
possible, client applications SHOULD use an iframe to receive
callbacks so that the access token does not appear in the browser
history.  [[Note that Authorization Servers SHOULD NOT allow their
approval pages to be iframed due to the risk of click-jacking attacks,
so this only works for immediate mode.   Browser security gets complicated.]]

If callback URLs must be rendered in a top-level browser window,
client applications SHOULD redirect immediately after receiving the
callback URL to remove the access token from the URL bar.   This<= BR> prevents the user from inadvertently copying their access token.

Callback URL pages SHOULD be CSRF protected.  (TODO: dig up the
language in OAuth 1.0a, it was pretty good, I think...)


Section 3.1.4  Callback URL Authentication for the User-Agent profile<= BR>
Because the user-agent profile returns an access token on the callback
URL, client credentials cannot be used to authenticate the callback
URL.  Callback URL white-listing is the only possible way to
authenticate the callback URL.  However, because the authorization
credentials are always returned on the URL fragment, the opportunity
for leaking credentials via referer headers and open redirectors is
reduced.

Different types of white-listing provide different levels of security.

- domain- white-listing
   Domain white-listing is very broad.  Domain white-li= sting MUST NOT
be used, because of the risk of malicious code running under some host
in the domain.

- host- white-listing
   Host white-listing is very broad.  Authorization ser= vers should be
conservative in choosing which hosts they trust, but host
white-listing MAY be used.

- path white-listing
   Path white-listing is somewhat broad.  Path white-li= sting MAY be used.
    When using path white-listing, Authorization server= s MUST defend
against directory traversal attacks by canonicalizing the path.
Appropriate path canonicalization algorithms vary for different types
of web-servers, e.g. "\..\" may represent a parent directory in s= ome
web servers, and not in others.

- page and URL white-listing
  Page and URL white-listing are very specific.  These types= of
white-listing MAY be used

  When full URL white-listing is used, Authorization Servers MUST=
allow the "state" query parameter to vary.

Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C85F75FD36FF7eranhueniversecom_-- From root@core3.amsl.com Sun Jul 11 14:30:06 2010 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D6E5C3A6875; Sun, 11 Jul 2010 14:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100711213002.D6E5C3A6875@core3.amsl.com> Date: Sun, 11 Jul 2010 14:30:02 -0700 (PDT) Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 21:30:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-10.txt Pages : 44 Date : 2010-07-11 This specification describes the OAuth 2.0 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-10.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-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-11142908.I-D@ietf.org> --NextPart-- From beaton@google.com Sun Jul 11 14: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 B43293A6A0C for ; Sun, 11 Jul 2010 14:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.589 X-Spam-Level: X-Spam-Status: No, score=-105.589 tagged_above=-999 required=5 tests=[AWL=0.388, 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 SIhYzTV3cwY0 for ; Sun, 11 Jul 2010 14:34:00 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E69533A6A06 for ; Sun, 11 Jul 2010 14:33:59 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o6BLY6GY026480 for ; Sun, 11 Jul 2010 14:34:06 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278884046; bh=hM/By0JzNJ7iAHGHb+eSwOzQB3s=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Mb/fLk/14Xw2oiXyWyd63QIs6fcXclbz7qTRKlD7fvFIjPn8h5y+GQ9fm+9vszzuK sFET4l6Vlpj+ouotaqZNQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Olt4Zyzvg+ebyIlDzZUjwFNS3/ABKwaL4SRPp1CIzeKk+Avs95HFaw+2MbnfgofRp 7Bbanv8EvBzMXfJ8oj+rg== Received: from pxi19 (pxi19.prod.google.com [10.243.27.19]) by wpaz29.hot.corp.google.com with ESMTP id o6BLY5IW020826 for ; Sun, 11 Jul 2010 14:34:05 -0700 Received: by pxi19 with SMTP id 19so2327036pxi.26 for ; Sun, 11 Jul 2010 14:34:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.217.6 with SMTP id p6mr914046wfg.243.1278884044856; Sun, 11 Jul 2010 14:34:04 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sun, 11 Jul 2010 14:34:04 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Jul 2010 14:34:04 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] simplify 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: Sun, 11 Jul 2010 21:34:00 -0000 On Sun, Jul 11, 2010 at 1:03 PM, Eran Hammer-Lahav wr= ote: > +1 with the exception of a new scheme name for signatures. I think we nee= d > to get to a stable draft before we can figure it out. Very reasonable. > But I would like to > keep the core spec open for (small) changes until we do. > > I added this to -10: > > Authorization: OAuth [optional extension key=3D=94value=94 pairs] Sure. Hopefully we never need the key=3D"value" stuff. From eran@hueniverse.com Sun Jul 11 14:35:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D4F3A6875 for ; Sun, 11 Jul 2010 14:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 9nhcy4jRmoR7 for ; Sun, 11 Jul 2010 14:35:23 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 6275B3A67EA for ; Sun, 11 Jul 2010 14:35:23 -0700 (PDT) Received: (qmail 18472 invoked from network); 11 Jul 2010 21:35:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 21:35:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 11 Jul 2010 14:35:29 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Sun, 11 Jul 2010 14:35:26 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-10.txt Thread-Index: AcshQEhmGzC526XLTsu8jknqsKWyuwAALE/F Message-ID: In-Reply-To: <20100711213002.D6E5C3A6875@core3.amsl.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85F872E36FFFeranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 21:35:42 -0000 --_000_C85F872E36FFFeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Draft -10 submitted. It includes the following changes: o Fixed typos. Many editorial changes. Rewrote introduction. removed = terminology grouping. o Allowed POST for end-user authorization endpoint. o Fixed token endpoint to not require client authentication. o Made URI query and POST body 'oauth_token' parameter optional. o Moved all parameter names and values to use underscores. o Changed 'basic_credentials' to 'password', 'invalid_client_credential= s' and 'invalid_client_id' to 'invalid_client'. o Added note that access token requests without an access grant should = not include a refresh token. o Changed scheme name from 'Token' to 'OAuth', simplified request forma= t to simple string for token instead of key=3Dvalue pair (still supported f= or extensions). o Defined permitted access token string characters (suitable for inclus= ion in an HTTP header). o Added a note about conflicts with previous versions. o Moved 'client_id' definition from client authentication to access tok= en endpoint. There will not be another official draft until at least August 1st, 2010. Please review and provide detailed feedback on the list. I will post the Sh= aredCopy link for editorial feedback as soon as the draft is up and active = on the tools site. Brian has raised some important issues over the weekend, most of which were= not addressed in the draft due to time or lack of consensus. Please review= and participate in the discussion. EHL On 7/11/10 2:30 PM, "Internet-Drafts@ietf.org" w= rote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Open Authentication Protocol Working Group= of the IETF. Title : The OAuth 2.0 Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-10.txt Pages : 44 Date : 2010-07-11 This specification describes the OAuth 2.0 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-10.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. --_000_C85F872E36FFFeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-10.txt Draft –10 submitted. It includes the following changes:

   o  Fixed typos.  Many editorial changes.  = Rewrote introduction. removed terminology grouping.
   o  Allowed POST for end-user authorization endpoint.=
   o  Fixed token endpoint to not require client authen= tication.
   o  Made URI query and POST body 'oauth_token' parame= ter optional.
   o  Moved all parameter names and values to use under= scores.
   o  Changed 'basic_credentials' to 'password', 'inval= id_client_credentials' and 'invalid_client_id' to 'invalid_client'.
   o  Added note that access token requests without an = access grant should not include a refresh token.
   o  Changed scheme name from 'Token' to 'OAuth', simp= lified request format to simple string for token instead of key=3Dvalue pai= r (still supported for extensions).
   o  Defined permitted access token string characters = (suitable for inclusion in an HTTP header).
   o  Added a note about conflicts with previous versio= ns.
   o  Moved 'client_id' definition from client authenti= cation to access token endpoint.

There will not be another official draft until at least August 1st, 2010.
Please review and provide detailed feedback on the list. I will post the Sh= aredCopy link for editorial feedback as soon as the draft is up and active = on the tools site.

Brian has raised some important issues over the weekend, most of which were= not addressed in the draft due to time or lack of consensus. Please review= and participate in the discussion.

EHL


On 7/11/10 2:30 PM, "Internet-Dra= fts@ietf.org" <Internet-Dr= afts@ietf.org> wrote:

A New Internet-Draft is available from the = on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group= of the IETF.


        Title    &nb= sp;      : The OAuth 2.0 Protocol
        Author(s)    = ;   : E. Hammer-Lahav, et al.
        Filename    =     : draft-ietf-oauth-v2-10.txt
        Pages    &nb= sp;      : 44
        Date    &nbs= p;       : 2010-07-11

This specification describes the OAuth 2.0 protocol.

A URL for this Internet-Draft is:
= http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-10.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.

--_000_C85F872E36FFFeranhueniversecom_-- From beaton@google.com Sun Jul 11 15:11: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 69E763A686D for ; Sun, 11 Jul 2010 15:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.611 X-Spam-Level: X-Spam-Status: No, score=-105.611 tagged_above=-999 required=5 tests=[AWL=0.367, 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 7b10dgil6G3w for ; Sun, 11 Jul 2010 15:11:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 785893A686C for ; Sun, 11 Jul 2010 15:11:03 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o6BMBAFC003090 for ; Sun, 11 Jul 2010 15:11:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278886270; bh=jtBRtYbgy3CDDhxytMACXz2IJ1Y=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=iMKGG4wFKxAvvo10z/rUIvQqAver2052kx9OaB2nr3aU3FaMu3nIDgSRKHjI9En8x zmIWcs4yX0XzThHA6aNSw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=oXNs3nCFVGLnhy2hn85451VZX2Bb0mw8iu019fhxVJ+pm5wawM1V6//m4u1W2lKPB iDlAjr/bFLUVRNyALwXUg== Received: from pxi20 (pxi20.prod.google.com [10.243.27.20]) by wpaz9.hot.corp.google.com with ESMTP id o6BMB8fr031329 for ; Sun, 11 Jul 2010 15:11:09 -0700 Received: by pxi20 with SMTP id 20so1866584pxi.31 for ; Sun, 11 Jul 2010 15:11:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.148.10 with SMTP id v10mr2836304wfd.327.1278886266242; Sun, 11 Jul 2010 15:11:06 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sun, 11 Jul 2010 15:11:06 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Jul 2010 15:11:06 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] redirect URI matching in section 3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 22:11:04 -0000 On Sun, Jul 11, 2010 at 1:22 PM, Eran Hammer-Lahav wr= ote: > This is a na=EFve questions: > > Why not just say the server MUST match the redirection URI if one was > previously registered, and require registration for user-agent clients? I don't know enough to be sure that's the right answer. As far as I can tell, the industry isn't converging on a solution, so I'm reluctant to say MUST to anything. I suspect the FB folks have the most experience with this kind of profile. From sayrer@gmail.com Sun Jul 11 15:32: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 E101A3A68B1 for ; Sun, 11 Jul 2010 15:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDiuCztEaytG for ; Sun, 11 Jul 2010 15:32:00 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id A417528C0CF for ; Sun, 11 Jul 2010 15:31:59 -0700 (PDT) Received: by vws14 with SMTP id 14so3845199vws.31 for ; Sun, 11 Jul 2010 15:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8lTNRbDUWZJbtO89a/764xRmt+RPjfXz+O92NHg3CME=; b=lJMaw9RuV1Lpuj2azlw1wCsFqcz6QggrADg4byHnT5MR1E0vjccSwgMOU0QcI5Gatz QyBLmCUGRq+oc/maa/sH+F03YFKvPECssXv7ygHjIO15bgsRz/nIZWNzshJDF8s3/tLO NIKs2GNlwTVk8ckFPFHvgfY3/8lxzJi4IoWas= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TtI5Dh0tTWPxk2Wtn+KYuC2+VY700dwD6Z2S22BlMuMtmpZwFLGqKQtClXrVAcHrMF K9FpQ7qNH9+5HGdiMMsOQz8RPfWK7t8Nke6Aj4yKBxRQJDxDCFURugdErFd6VXLGJ7aY RoNbXXTnKE73oHqKYc8e5yZ9eIfosXWyzNdq0= MIME-Version: 1.0 Received: by 10.229.38.68 with SMTP id a4mr7835746qce.112.1278887522074; Sun, 11 Jul 2010 15:32:02 -0700 (PDT) Received: by 10.229.83.130 with HTTP; Sun, 11 Jul 2010 15:32:01 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Jul 2010 15:32:01 -0700 Message-ID: From: Robert Sayre To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 22:32:01 -0000 On Sun, Jul 11, 2010 at 12:27 PM, Eran Hammer-Lahav w= rote: > [this has noting to do with realm] > > Any solution should be: > > - Extensible =96 we removed the few discovery parameters from the core sp= ec > due to lack of maturity and consensus. However, we clearly have enough > strong interest in reintroducing them as extensions. The WWW-Authenticate > header is the natural place to include them. This is true. I thought it obvious that implementations would be required to deal with text after the "OAuth2" string. > > - Human-friendly =96 I think being able to look at the header and immedia= tely > see what it means is useful. I'm not sure this is valuable, but it is possible to accomodate the concern anyway. I use a protocol analyzer, like WireShark. > Is there a JSON profile suitable for inclusion > in HTTP headers? I would like to avoid BASE64 when a person is likely to > take a look at the header. Otherwise debugging and command line interacti= on > become impractical. The WG could specify that all control characters and non-ASCII text within the JSON text be escaped. base64 adds overhead to the endeavor, so it's probably best to avoid it, because most of the bits will be ASCII anyway. If browser clients need to set headers in the same manner, this could be more inconvenient, because the JSON serializers shipping in browsers today don't support requiring that the produced text be escaped. This can be done as a follow-up pass, though. [0] Using a JSON serialization neatly sidesteps several i18n issues. If you go with traditional HTTP header syntax, you'll need to deal with that some other way. btw, it just so happens that internationalization of Realm values is a bug in most RFC2617 implemenations. [0] (I happen to be on the ECMAScript committee, and I can be blamed for Mozilla's native JSON object. It would be technically easy to add a JSON.stringifyAsASCII() method, and I think the committee will go for it.) --=20 Robert Sayre "I would have written a shorter letter, but I did not have the time." From eran@hueniverse.com Sun Jul 11 17:52: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 137A928C103 for ; Sun, 11 Jul 2010 17:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 Z9WG0jrmg49J for ; Sun, 11 Jul 2010 17:52:19 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A449B28C0EB for ; Sun, 11 Jul 2010 17:52:19 -0700 (PDT) Received: (qmail 11159 invoked from network); 12 Jul 2010 00:52:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 12 Jul 2010 00:52:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 11 Jul 2010 17:52:24 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Sun, 11 Jul 2010 17:52:19 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-10.txt Thread-Index: AcshQEhmGzC526XLTsu8jknqsKWyuwAALE/FAAbgRrQ= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85FB55337010eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 00:52:26 -0000 --_000_C85FB55337010eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please use this link to post purely editorial feedback: http://r9.sharedcopy.com/6djt2n9v EHL On 7/11/10 2:35 PM, "Eran Hammer-Lahav" wrote: Draft -10 submitted. It includes the following changes: o Fixed typos. Many editorial changes. Rewrote introduction. removed = terminology grouping. o Allowed POST for end-user authorization endpoint. o Fixed token endpoint to not require client authentication. o Made URI query and POST body 'oauth_token' parameter optional. o Moved all parameter names and values to use underscores. o Changed 'basic_credentials' to 'password', 'invalid_client_credential= s' and 'invalid_client_id' to 'invalid_client'. o Added note that access token requests without an access grant should = not include a refresh token. o Changed scheme name from 'Token' to 'OAuth', simplified request forma= t to simple string for token instead of key=3Dvalue pair (still supported f= or extensions). o Defined permitted access token string characters (suitable for inclus= ion in an HTTP header). o Added a note about conflicts with previous versions. o Moved 'client_id' definition from client authentication to access tok= en endpoint. There will not be another official draft until at least August 1st, 2010. Please review and provide detailed feedback on the list. I will post the Sh= aredCopy link for editorial feedback as soon as the draft is up and active = on the tools site. Brian has raised some important issues over the weekend, most of which were= not addressed in the draft due to time or lack of consensus. Please review= and participate in the discussion. EHL On 7/11/10 2:30 PM, "Internet-Drafts@ietf.org" w= rote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Open Authentication Protocol Working Group= of the IETF. Title : The OAuth 2.0 Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-10.txt Pages : 44 Date : 2010-07-11 This specification describes the OAuth 2.0 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-10.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. --_000_C85FB55337010eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-10.txt Please use this link to post purely editorial feedback:

http://r9.sharedcopy.com/6djt= 2n9v

EHL


On 7/11/10 2:35 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

Draft –10 submitted. It includes the = following changes:

   o  Fixed typos.  Many editorial changes.  = Rewrote introduction. removed terminology grouping.
   o  Allowed POST for end-user authorization endpoint.=
   o  Fixed token endpoint to not require client authen= tication.
   o  Made URI query and POST body 'oauth_token' parame= ter optional.
   o  Moved all parameter names and values to use under= scores.
   o  Changed 'basic_credentials' to 'password', 'inval= id_client_credentials' and 'invalid_client_id' to 'invalid_client'.
   o  Added note that access token requests without an = access grant should not include a refresh token.
   o  Changed scheme name from 'Token' to 'OAuth', simp= lified request format to simple string for token instead of key=3Dvalue pai= r (still supported for extensions).
   o  Defined permitted access token string characters = (suitable for inclusion in an HTTP header).
   o  Added a note about conflicts with previous versio= ns.
   o  Moved 'client_id' definition from client authenti= cation to access token endpoint.

There will not be another official draft until at least August 1st, 2010.
Please review and provide detailed feedback on the list. I will post the Sh= aredCopy link for editorial feedback as soon as the draft is up and active = on the tools site.

Brian has raised some important issues over the weekend, most of which were= not addressed in the draft due to time or lack of consensus. Please review= and participate in the discussion.

EHL


On 7/11/10 2:30 PM, "Internet-Dra= fts@ietf.org" <Internet-Dr= afts@ietf.org> wrote:

A New Internet-Draft is available from the = on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group= of the IETF.


        Title    &nb= sp;      : The OAuth 2.0 Protocol
        Author(s)    = ;   : E. Hammer-Lahav, et al.
        Filename    =     : draft-ietf-oauth-v2-10.txt
        Pages    &nb= sp;      : 44
        Date    &nbs= p;       : 2010-07-11

This specification describes the OAuth 2.0 protocol.

A URL for this Internet-Draft is:
= http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-10.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.

Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Authorization Header Format in 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: Mon, 12 Jul 2010 02:17:23 -0000 According to section 5.1.1, commas, equal signs, and quotation marks are all allowed in the access-token. How do I parse the following Authorization header? Authorization: OAuth vF9dft4qmT,foo="bar" 1. The access-token is 'vF9dft4qmT', and the value of some extension parameter 'foo' is 'bar'. 2. The access-token is 'vF9dft4qmT,foo="bar"'. Am I misreading the grammar? If not, I suggest access-token be defined as: access-token = token / quoted-string where token and quoted-string are taken from RFC 2616. It would no longer be ambiguous, but it is a bit confusing since RFCs 1945, 2068, and 2616 all define quoted-string differently. (Does that imply transport dependent header construction/parsing?) Alternatively, we could define CS as: CS = RWS "," OWS but that seems prone to implementation bugs. Mike --mdawaffe From eran@hueniverse.com Sun Jul 11 20:19:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48BCF3A690F for ; Sun, 11 Jul 2010 20:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 GjKdKu7B9kFw for ; Sun, 11 Jul 2010 20:19:17 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id A8C2F3A68F5 for ; Sun, 11 Jul 2010 20:19:17 -0700 (PDT) Received: (qmail 25102 invoked from network); 12 Jul 2010 03:19:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 Jul 2010 03:19:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 11 Jul 2010 20:19:22 -0700 From: Eran Hammer-Lahav To: "mike@automattic.com" , OAuth WG Date: Sun, 11 Jul 2010 20:19:18 -0700 Thread-Topic: [OAUTH-WG] Authorization Header Format in draft-10 Thread-Index: AcshaGPkBTxxQJFTQzKz23JtvVh5IgACJ9eU Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Authorization Header Format in 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: Mon, 12 Jul 2010 03:19:20 -0000 My bad. I forgot to update the ABNF for the parameters. The right answer is 2 in the example below and the correct ABNF is: credentials =3D "OAuth" RWS access-token RWS [ 1#auth-param ] access-token =3D 1*( quoted-char / <"> ) quoted-char =3D "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / DIGIT / ":" / "<" / "=3D" / ">" / "?" / "@" / ALPHA / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" This will be fixed in -11 (already in my github [1] copy which will continu= e to change with pending -11 updates). EHL [1] http://github.com/theRazorBlade/draft-ietf-oauth On 7/11/10 7:17 PM, "mike@automattic.com" wrote: > According to section 5.1.1, commas, equal signs, and quotation marks > are all allowed in the access-token. How do I parse the following > Authorization header? >=20 > Authorization: OAuth vF9dft4qmT,foo=3D"bar" >=20 > 1. The access-token is 'vF9dft4qmT', and the value of some extension > parameter 'foo' is 'bar'. > 2. The access-token is 'vF9dft4qmT,foo=3D"bar"'. >=20 > Am I misreading the grammar? If not, I suggest access-token be defined a= s: >=20 > access-token =3D token / quoted-string >=20 > where token and quoted-string are taken from RFC 2616. >=20 > It would no longer be ambiguous, but it is a bit confusing since RFCs > 1945, 2068, and 2616 all define quoted-string differently. (Does that > imply transport dependent header construction/parsing?) >=20 >=20 > Alternatively, we could define CS as: >=20 > CS =3D RWS "," OWS >=20 > but that seems prone to implementation bugs. >=20 > Mike > --mdawaffe > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Sun Jul 11 20:29: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 776823A6A4C for ; Sun, 11 Jul 2010 20:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+XabsG+yE0w for ; Sun, 11 Jul 2010 20:29:17 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 236A23A6A4B for ; Sun, 11 Jul 2010 20:29:17 -0700 (PDT) Received: (qmail 26796 invoked from network); 12 Jul 2010 03:29:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 Jul 2010 03:29:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 11 Jul 2010 20:29:24 -0700 From: Eran Hammer-Lahav To: Robert Sayre Date: Sun, 11 Jul 2010 20:29:20 -0700 Thread-Topic: [OAUTH-WG] What to do about 'realm' Thread-Index: AcshSOL6JwAvEJ6aRee408FuofcKvwAKYcaZ Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Jul 2010 03:29:19 -0000 On 7/11/10 3:32 PM, "Robert Sayre" wrote: > On Sun, Jul 11, 2010 at 12:27 PM, Eran Hammer-Lahav > wrote: >> [this has noting to do with realm] >>=20 >> Any solution should be: >>=20 >> - Extensible =AD we removed the few discovery parameters from the core s= pec >> due to lack of maturity and consensus. However, we clearly have enough >> strong interest in reintroducing them as extensions. The WWW-Authenticat= e >> header is the natural place to include them. >=20 > This is true. I thought it obvious that implementations would be > required to deal with text after the "OAuth2" string. Yes. We need a format that can be extended. Of course, using JSON means muc= h richer extensibility which needs some adjustment in the registry (maybe onl= y require registration for top level object names?). >> - Human-friendly =AD I think being able to look at the header and immedi= ately >> see what it means is useful. >=20 > I'm not sure this is valuable, but it is possible to accomodate the > concern anyway. I use a protocol analyzer, like WireShark. I think being able to curl a site and work your way manually is useful and something that was a stated goal when we started collecting 2.0 requirements. This was one of the reasons why the bearer token approach was so attractive to so many people. >> Is there a JSON profile suitable for inclusion >> in HTTP headers? I would like to avoid BASE64 when a person is likely to >> take a look at the header. Otherwise debugging and command line interact= ion >> become impractical. >=20 > The WG could specify that all control characters and non-ASCII text > within the JSON text be escaped. base64 adds overhead to the endeavor, > so it's probably best to avoid it, because most of the bits will be > ASCII anyway. Works for me. > If browser clients need to set headers in the same manner, this could > be more inconvenient, because the JSON serializers shipping in > browsers today don't support requiring that the produced text be > escaped. This can be done as a follow-up pass, though. [0] I am not worried about client requests because there is less to debug on that side (most issues are when the client is trying to debug on its side and can easily add helpful information locally). I want to make sure that the server response using the WWW-Authenticate header is plain-text and not some encoded blob. However, we still need to worry about HTTP header restrictions and I am not sure what a browser will do when you try to set an HTTP header with non-ascii characters. > Using a JSON serialization neatly sidesteps several i18n issues. If > you go with traditional HTTP header syntax, you'll need to deal with > that some other way. btw, it just so happens that internationalization > of Realm values is a bug in most RFC2617 implemenations. It would be great to avoid having to use stuff like draft-reschke-rfc2231-in-http, but that seems to be the current solution. EHL >=20 > [0] (I happen to be on the ECMAScript committee, and I can be blamed > for Mozilla's native JSON object. It would be technically easy to add > a JSON.stringifyAsASCII() method, and I think the committee will go > for it.) >=20 >=20 >=20 > -- >=20 > Robert Sayre >=20 > "I would have written a shorter letter, but I did not have the time." >=20 From James.H.Manger@team.telstra.com Sun Jul 11 21:02: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 5FCF628C114 for ; Sun, 11 Jul 2010 21:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[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 RQEBmWh+2SCv for ; Sun, 11 Jul 2010 21:02:21 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id BC5883A68E6 for ; Sun, 11 Jul 2010 21:02:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,185,1278252000"; d="scan'208";a="5755925" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 12 Jul 2010 14:02:23 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6040"; a="4274419" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcavi.tcif.telstra.com.au with ESMTP; 12 Jul 2010 14:02:25 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Mon, 12 Jul 2010 14:02:25 +1000 From: "Manger, James H" To: Eran Hammer-Lahav , "mike@automattic.com" , OAuth WG Date: Mon, 12 Jul 2010 14:02:31 +1000 Thread-Topic: [OAUTH-WG] Authorization Header Format in draft-10 Thread-Index: AcshaGPkBTxxQJFTQzKz23JtvVh5IgACJ9eUAACAA8A= Message-ID: <255B9BB34FB7D647A506DC292726F6E112660DA733@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Authorization Header Format in 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: Mon, 12 Jul 2010 04:02:22 -0000 Eran, Is then any reason to pick this collection of ASCII characters? An access token appears in JSON, URI fragments, URI query parameters, and H= TTP header values. The allowed set includes chars that need escaping in all= of these. However, it is still a very limited set of 94 chars. It excludes= spaces, non-ASCII Unicode etc. This looks like the worst of all worlds. Everyone handling a token has to w= orry about escaping in every situation, but even that isn't enough to suppo= rt arbitrary text or binary tokens. There will need to be escaping mechanis= ms to fit native tokens into the OAuth production, then sepa= rate escaping to transport it. Why not restrict to a URI-safe alphabet (eg the 66 chars: A-Z a-z 0-9 - _ . ~). If you have a binary token there is a simple approach: base64url-encode it. If you have a text token there is a simple approach: base64url-encode its U= TF-8 encoding. If you have a little bit of structure in a token there are a couple of punc= tuation chars available to separate the components. Allowing ( ) " \ =3D but without their usual meaning (as comments, quoting,= escaping, and separating) looks certain to cause confusion. --=20 James Manger -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, 12 July 2010 1:19 PM To: mike@automattic.com; OAuth WG Subject: Re: [OAUTH-WG] Authorization Header Format in draft-10 My bad. I forgot to update the ABNF for the parameters. The right answer is 2 in the example below and the correct ABNF is: credentials =3D "OAuth" RWS access-token RWS [ 1#auth-param ] access-token =3D 1*( quoted-char / <"> ) quoted-char =3D "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / DIGIT / ":" / "<" / "=3D" / ">" / "?" / "@" / ALPHA / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" This will be fixed in -11 (already in my github [1] copy which will continu= e to change with pending -11 updates). EHL [1] http://github.com/theRazorBlade/draft-ietf-oauth From eran@hueniverse.com Sun Jul 11 21:28: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 79F513A68BC for ; Sun, 11 Jul 2010 21:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.178, 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 W53W2LJFfT9C for ; Sun, 11 Jul 2010 21:28:41 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D3FCB3A6915 for ; Sun, 11 Jul 2010 21:28:41 -0700 (PDT) Received: (qmail 7601 invoked from network); 12 Jul 2010 04:28:48 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 12 Jul 2010 04:28:48 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 11 Jul 2010 21:28:48 -0700 From: Eran Hammer-Lahav To: James Manger , "mike@automattic.com" , OAuth WG Date: Sun, 11 Jul 2010 21:28:44 -0700 Thread-Topic: [OAUTH-WG] Authorization Header Format in draft-10 Thread-Index: AcshaGPkBTxxQJFTQzKz23JtvVh5IgACJ9eUAACAA8AAAezG0Q== Message-ID: In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112660DA733@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C85FE80C3701Feranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Authorization Header Format in 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: Mon, 12 Jul 2010 04:28:48 -0000 --_000_C85FE80C3701Feranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I basically took all the characters allowed in headers and removed white-sp= ace characters since they are used as separators. That's it. In other words= , this is what HTTP requires for sending tokens in headers (which is the mo= st consensus I was able to conclude from the list discussions). If people a= gree to reduce the character-set, or allow quoted string (in place or in ad= dition) that's fine with me. As long as you can accommodate base64, I'm per= sonally happy. EHL On 7/11/10 9:02 PM, "James Manger" wrote: Eran, Is then any reason to pick this collection of ASCII characters? An access token appears in JSON, URI fragments, URI query parameters, and H= TTP header values. The allowed set includes chars that need escaping in all= of these. However, it is still a very limited set of 94 chars. It excludes= spaces, non-ASCII Unicode etc. This looks like the worst of all worlds. Everyone handling a token has to w= orry about escaping in every situation, but even that isn't enough to suppo= rt arbitrary text or binary tokens. There will need to be escaping mechanis= ms to fit native tokens into the OAuth production, then sepa= rate escaping to transport it. Why not restrict to a URI-safe alphabet (eg the 66 chars: A-Z a-z 0-9 - _ . ~). If you have a binary token there is a simple approach: base64url-encode it. If you have a text token there is a simple approach: base64url-encode its U= TF-8 encoding. If you have a little bit of structure in a token there are a couple of punc= tuation chars available to separate the components. Allowing ( ) " \ =3D but without their usual meaning (as comments, quoting,= escaping, and separating) looks certain to cause confusion. -- James Manger -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, 12 July 2010 1:19 PM To: mike@automattic.com; OAuth WG Subject: Re: [OAUTH-WG] Authorization Header Format in draft-10 My bad. I forgot to update the ABNF for the parameters. The right answer is 2 in the example below and the correct ABNF is: credentials =3D "OAuth" RWS access-token RWS [ 1#auth-param ] access-token =3D 1*( quoted-char / <"> ) quoted-char =3D "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / DIGIT / ":" / "<" / "=3D" / ">" / "?" / "@" / ALPHA / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" This will be fixed in -11 (already in my github [1] copy which will continu= e to change with pending -11 updates). EHL [1] http://github.com/theRazorBlade/draft-ietf-oauth --_000_C85FE80C3701Feranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Authorization Header Format in draft-10 I basically took all the characters allowed in headers and removed wh= ite-space characters since they are used as separators. That’s it. In= other words, this is what HTTP requires for sending tokens in headers (whi= ch is the most consensus I was able to conclude from the list discussions).= If people agree to reduce the character-set, or allow quoted string (in pl= ace or in addition) that’s fine with me. As long as you can accommoda= te base64, I’m personally happy.

EHL


On 7/11/10 9:02 PM, "James Manger" <James.H.Manger@team.telstra.com> wrote:

Eran,

Is then any reason to pick this collection of ASCII characters?
An access token appears in JSON, URI fragments, URI query parameters, and H= TTP header values. The allowed set includes chars that need escaping in all= of these. However, it is still a very limited set of 94 chars. It excludes= spaces, non-ASCII Unicode etc.

This looks like the worst of all worlds. Everyone handling a token has to w= orry about escaping in every situation, but even that isn't enough to suppo= rt arbitrary text or binary tokens. There will need to be escaping mechanis= ms to fit native tokens into the OAuth <access-token> production, the= n separate escaping to transport it.

Why not restrict <access-token> to a URI-safe alphabet (eg the 66 <= ;unreserved> chars: A-Z a-z 0-9 - _ . ~).
If you have a binary token there is a simple approach: base64url-encode it.=
If you have a text token there is a simple approach: base64url-encode its U= TF-8 encoding.
If you have a little bit of structure in a token there are a couple of punc= tuation chars available to separate the components.

Allowing ( ) " \ =3D but without their usual meaning (as comments, quo= ting, escaping, and separating) looks certain to cause confusion.

--
James Manger



-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On B= ehalf Of Eran Hammer-Lahav
Sent: Monday, 12 July 2010 1:19 PM
To: mike@automattic.com; OAuth WG
Subject: Re: [OAUTH-WG] Authorization Header Format in draft-10

My bad. I forgot to update the ABNF for the parameters.

The right answer is 2 in the example below and the correct ABNF is:

  credentials    =3D "OAuth" RWS access-= token RWS [ 1#auth-param ]
  access-token   =3D 1*( quoted-char / <"> )=

  quoted-char    =3D   "!" / &= quot;#" / "$" / "%" / "&" / "'&= quot; / "("
            &nb= sp;      / ")" / "*" / &q= uot;+" / "-" / "." / "/" / DIGIT
            &nb= sp;      / ":" / "<" /= "=3D" / ">" / "?" / "@" / ALPHA=
            &nb= sp;      / "[" / "]" / &q= uot;^" / "_" / "`" / "{" / "|"=
            &nb= sp;      / "}" / "~" / &q= uot;\" / "," / ";"

This will be fixed in -11 (already in my github [1] copy which will continu= e
to change with pending -11 updates).

EHL

[1] http://git= hub.com/theRazorBlade/draft-ietf-oauth


--_000_C85FE80C3701Feranhueniversecom_-- From wmills@yahoo-inc.com Sun Jul 11 22:28: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 691B83A6905 for ; Sun, 11 Jul 2010 22:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.543 X-Spam-Level: X-Spam-Status: No, score=-17.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxfL7XX2l-b4 for ; Sun, 11 Jul 2010 22:28:52 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id EAD863A68A0 for ; Sun, 11 Jul 2010 22:28:51 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6C5QXVS022630; Sun, 11 Jul 2010 22:26:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:return-path:x-originalarrivaltime; b=c2Ozx3TrdTebuNacvps6aCmH94+DWzmFvzTVy0+LrO1VVLgOlo/+ALtlnOvhWv8o Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Jul 2010 22:26:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Jul 2010 22:26:32 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6BBB@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] "access grant" terminology Thread-Index: Acsgo1IqSaP1dBzARzCLBHb7zz8NFwAAl688ADYdKEA= References: From: "William Mills" To: "Eran Hammer-Lahav" , "Brian Eaton" , "OAuth WG" X-OriginalArrivalTime: 12 Jul 2010 05:26:33.0296 (UTC) FILETIME=[CA41B500:01CB2182] Subject: Re: [OAUTH-WG] "access grant" terminology X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Jul 2010 05:28:53 -0000 I think "access credential" is better that either of those. Using "grant" as a noun is a somewhat obscure usage, a la "land grant", which I think of more as the deed to a property. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Eran Hammer-Lahav > Sent: Saturday, July 10, 2010 8:04 PM > To: Brian Eaton; OAuth WG > Subject: Re: [OAUTH-WG] "access grant" terminology >=20 >=20 >=20 >=20 > On 7/10/10 7:46 PM, "Brian Eaton" wrote: >=20 > > The term "access grant" in the -09 spec is a bit odd. Normally=20 > > "access grant" or "permission grant" would refer to a=20 > specific policy=20 > > decision made by a resource owner. > >=20 > > But that's not how the -09 spec uses the term. The -09=20 > spec refers to=20 > > authorization codes and assertions as "access grants". =20 > Again, that's=20 > > weird. Normally an assertion would be referred to as a=20 > "credential",=20 > > not a grant. >=20 > Access grant is something that represents the decision made=20 > by the resource owner. If the resource owner approves access,=20 > it is represented by a authorization code. If the resource=20 > owner shares its password, it is equivalent to unlimited access grant. >=20 > I coined the term based on common language, not on any=20 > existing terminology. > If there is a real conflict here, I am happy to consider=20 > another term, but it doesn't sound like this is the case, or=20 > that the term is used against its meaning. >=20 > > I think the term "authorization credential" might be a=20 > better fit than=20 > > "access grant". > >=20 > > It certainly describes the purpose of the authorization=20 > code and the=20 > > assertion. And the term "credential" is normally used to describe=20 > > things that need to be verified and protected. >=20 > I think authorization credential is going to confuse most=20 > readers. The spec refers to credentials almost exclusively=20 > when dealing with identifier and password (client, end-user),=20 > or as a general term for client authentication. > Authorization is specific to the end-user authorization=20 > endpoint and will be confusing when used with assertions and=20 > other grant types. >=20 > So I'm open to other ideas but not this one. >=20 > Note that since this term impacts the name of the current 'grant_type' > parameter, changing it means code changes. >=20 > If anyone has a last minute idea please share (or if you are=20 > happy with the current grant type). I expect it to be=20 > annoying to change once -10 is stable for 4 weeks. >=20 > EHL >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From michael.d.adams@gmail.com Sun Jul 11 22:39: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 6DF263A6A2A for ; Sun, 11 Jul 2010 22:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-zZ1QyRmimV for ; Sun, 11 Jul 2010 22:39:40 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 25B703A694D for ; Sun, 11 Jul 2010 22:39:27 -0700 (PDT) Received: by iwn38 with SMTP id 38so4494264iwn.31 for ; Sun, 11 Jul 2010 22:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Yoaii2SEBAz2I1DLLVFlHb3HURW2GDm4uQZOBkBUCLk=; b=LbT78Ni41Wyq+skjyK447zdkc1YZ6bJ0x40VxHm5R7ZNdAmy8g1UF14fumir/r5kuI 6ZbLAxaClxuflBlXGYdN4A8UyHP2g7sizdCzXlhWyyIKju4cHNloFF7dnWsG/KX71rp/ NOK9RZLAbTdiUHvqZyaRoI9ZM85k4P9szBl/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=S7q5TE4qwhwfAtvlJElA4Li6d/6w6fHg/nuLdo1TcZ0erGU+lowh7Khsq3ZjpSHLKP aK5KL4k7o54KyaqtdA4XNbcT99zvujxctmYFZb9QgW8AeyloKYqFQ3sjdi0m9Jkmdthu rICZ06upC5qWC3jlozh+Zd52KfuaU1Bo3fcKg= Received: by 10.231.184.16 with SMTP id ci16mr13460482ibb.23.1278913174272; Sun, 11 Jul 2010 22:39:34 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.179.143 with HTTP; Sun, 11 Jul 2010 22:39:14 -0700 (PDT) In-Reply-To: References: From: Michael D Adams Date: Sun, 11 Jul 2010 22:39:14 -0700 X-Google-Sender-Auth: 4tWFUgWwpKV__5-BhGQhmm_VXpo Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization Header Format in 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: Mon, 12 Jul 2010 05:39:52 -0000 On Sun, Jul 11, 2010 at 8:19 PM, Eran Hammer-Lahav wr= ote: > My bad. I forgot to update the ABNF for the parameters. > > =A0credentials =A0 =A0=3D "OAuth" RWS access-token RWS [ 1#auth-param ] Thanks. I suppose it should be credentials =3D "OAuth" RWS access-token [ RWS 1#auth-param ] which I'll add to the sharedcopy. Mike --mdawaffe From wmills@yahoo-inc.com Sun Jul 11 22:55:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37A53A6A51 for ; Sun, 11 Jul 2010 22:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.39 X-Spam-Level: X-Spam-Status: No, score=-17.39 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNya-TI7ZbH5 for ; Sun, 11 Jul 2010 22:55:43 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 432FC3A6A67 for ; Sun, 11 Jul 2010 22:55:36 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6C5rMls020000; Sun, 11 Jul 2010 22:53:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:x-originalarrivaltime; b=PhmXc39Zx7IhFi48bgD8PABBliEHoTOdPgbmCkOrNXAome++Bd77WvcyH4e4mCrb Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Jul 2010 22:53:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Jul 2010 22:53:20 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6BBC@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] What to do about 'realm' Thread-Index: AcsgxiyXZSK8vk89Q/eV4TGi3XOmmQAwASjw References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" To: "Brian Eaton" , "Eran Hammer-Lahav" X-OriginalArrivalTime: 12 Jul 2010 05:53:21.0973 (UTC) FILETIME=[891A5650:01CB2186] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Jul 2010 05:55:46 -0000 =20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Brian Eaton > Sent: Saturday, July 10, 2010 11:56 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] What to do about 'realm' >=20 > On Sun, Jun 27, 2010 at 6:51 PM, Eran Hammer-Lahav=20 > wrote: > > 1. Leave it as required under the definition of RFC 2617=20 > (i.e. provide=20 > > no help, developers will need to ready 2617 and figure out=20 > what to do with it). > > > > 2. Update 2617 to remove the requirement - this is not going to be=20 > > easy or possible to predict success. > > > > 3. Provide specific guidance as to what to do with the=20 > realm parameter. > > > > 4. Something else. >=20 > Let's do something else. >=20 > We've made great progress on simplifying the spec and=20 > unifying the different formats to minimize the number of=20 > parsers and serializers that are needed. The=20 > www-authenticate header is one of the bits of nastiness left. >=20 > Let's use a format like this: >=20 > WWW-Authenticate: OAuth2 base64() This will work for me in the SASL stuff for discovery information. JSON as a name/value construct works as well as anythign else. >=20 > Or even just: >=20 > WWW-Authenticate: OAuth2 This won't really, and I'll have to stuff the discovery information somwehre else. I don't care what the real specifics of this are as long asn it's extensible. >=20 > Seriously. >=20 > There is some precedent for this. The Negotiate and NTLM=20 > schemes ditched the name=3D"value" syntax, and they are widely=20 > implemented. > This demonstrates two things: > 1) dropping the name=3D"value" syntax won't break the internet,=20 > because widely deployed schemes have already done it. > 2) "realm" is not necessary in order to have a successful=20 > authentication protocol. >=20 > As far as I can tell, there is no good reason for RFC 2617 to=20 > specify the syntax it does. It's convenient for digest auth,=20 > and kind of a pain everywhere else. >=20 > So let's just drop it. >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From jricher@mitre.org Mon Jul 12 05:48: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 A026B3A6989 for ; Mon, 12 Jul 2010 05:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 wQE96fxC9yQc for ; Mon, 12 Jul 2010 05:48:20 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 990553A6922 for ; Mon, 12 Jul 2010 05:48:20 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6CCmRKe020681 for ; Mon, 12 Jul 2010 08:48:28 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6CCmRaf020678; Mon, 12 Jul 2010 08:48:27 -0400 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, 12 Jul 2010 08:48:27 -0400 From: Justin Richer To: Brian Eaton In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 12 Jul 2010 08:48:27 -0400 Message-ID: <1278938907.2445.107.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] temperature check: json input to token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 12:48:21 -0000 I'd like to keep form-encoded inputs. I think it makes sense to use a well-established key-value mechanism, and the asymmetry at play here is what the web is made of (post a form, get HTML/XML/JSON/whatever). Along those lines, I'd actually like to relax the restriction of using "POST" and allow for query arguments on the token endpoint as well. Long ago it was argued that the POST requirement was to keep query parameters from leaking into server logs. That's a fine implementation-specific security optimization, but I don't think it belongs mandated in the spec. As a practical matter, I know that for most of my implementations (on small single servers), anyone who's got access to the web server logs have access to the tokens in the database. Were there other reasons for mandating POST here that I'm forgetting? -- Justin On Sun, 2010-07-11 at 00:31 -0400, Brian Eaton wrote: > Hey folks - > > Today, the token endpoint takes form-encoded inputs, and sends JSON > outputs. This requires developers to use both form encoding and a > json parser. > > Many services expose symmetric APIs for non-browser endpoints. For > example, an API call normally takes JSON input and returns JSON > output. > > What do people think about having the token endpoint accept and return JSON? > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eve@xmlgrrl.com Mon Jul 12 06:39:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F093A6B46 for ; Mon, 12 Jul 2010 06:39:19 -0700 (PDT) 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=[AWL=0.000, 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 K3Ucbh9fPmcZ for ; Mon, 12 Jul 2010 06:39:18 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 551B23A6B4B for ; Mon, 12 Jul 2010 06:39:18 -0700 (PDT) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by mail.promanage-inc.com (8.14.3/8.14.3) with ESMTP id o6CDdPDu028909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Jul 2010 06:39:25 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6BBB@SNV-EXVS08.ds.corp.yahoo.com> Date: Mon, 12 Jul 2010 06:39:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1E249FBE-0C4F-4C64-93F9-DD3172462D38@xmlgrrl.com> References: <012AB2B223CB3F4BB846962876F47217059B6BBB@SNV-EXVS08.ds.corp.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] "access grant" terminology X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Jul 2010 13:39:20 -0000 How about "approval", as in delegation approval or association approval = (since the resource owner is approving or consenting to the association = of these two services on the owner's behalf for delegated access = purposes, with specific tokens later representing specific access = authorizations)? Eve On 11 Jul 2010, at 10:26 PM, William Mills wrote: > I think "access credential" is better that either of those. Using > "grant" as a noun is a somewhat obscure usage, a la "land grant", = which > I think of more as the deed to a property. >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 >> On Behalf Of Eran Hammer-Lahav >> Sent: Saturday, July 10, 2010 8:04 PM >> To: Brian Eaton; OAuth WG >> Subject: Re: [OAUTH-WG] "access grant" terminology >>=20 >>=20 >>=20 >>=20 >> On 7/10/10 7:46 PM, "Brian Eaton" wrote: >>=20 >>> The term "access grant" in the -09 spec is a bit odd. Normally=20 >>> "access grant" or "permission grant" would refer to a=20 >> specific policy=20 >>> decision made by a resource owner. >>>=20 >>> But that's not how the -09 spec uses the term. The -09=20 >> spec refers to=20 >>> authorization codes and assertions as "access grants". =20 >> Again, that's=20 >>> weird. Normally an assertion would be referred to as a=20 >> "credential",=20 >>> not a grant. >>=20 >> Access grant is something that represents the decision made=20 >> by the resource owner. If the resource owner approves access,=20 >> it is represented by a authorization code. If the resource=20 >> owner shares its password, it is equivalent to unlimited access = grant. >>=20 >> I coined the term based on common language, not on any=20 >> existing terminology. >> If there is a real conflict here, I am happy to consider=20 >> another term, but it doesn't sound like this is the case, or=20 >> that the term is used against its meaning. >>=20 >>> I think the term "authorization credential" might be a=20 >> better fit than=20 >>> "access grant". >>>=20 >>> It certainly describes the purpose of the authorization=20 >> code and the=20 >>> assertion. And the term "credential" is normally used to describe=20= >>> things that need to be verified and protected. >>=20 >> I think authorization credential is going to confuse most=20 >> readers. The spec refers to credentials almost exclusively=20 >> when dealing with identifier and password (client, end-user),=20 >> or as a general term for client authentication. >> Authorization is specific to the end-user authorization=20 >> endpoint and will be confusing when used with assertions and=20 >> other grant types. >>=20 >> So I'm open to other ideas but not this one. >>=20 >> Note that since this term impacts the name of the current = 'grant_type' >> parameter, changing it means code changes. >>=20 >> If anyone has a last minute idea please share (or if you are=20 >> happy with the current grant type). I expect it to be=20 >> annoying to change once -10 is stable for 4 weeks. >>=20 >> EHL >>=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 Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler From eran@hueniverse.com Mon Jul 12 06:57: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 2C7F63A67B4 for ; Mon, 12 Jul 2010 06:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 Wbmemlphxmk3 for ; Mon, 12 Jul 2010 06:57:29 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 163023A6870 for ; Mon, 12 Jul 2010 06:57:28 -0700 (PDT) Received: (qmail 3041 invoked from network); 12 Jul 2010 13:57:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 Jul 2010 13:57:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 12 Jul 2010 06:57:33 -0700 From: Eran Hammer-Lahav To: Justin Richer Date: Mon, 12 Jul 2010 06:56:29 -0700 Thread-Topic: [OAUTH-WG] temperature check: json input to token endpoint Thread-Index: AcshyizXO3t9xrMRQ/2vkq8MNGTvVg== Message-ID: References: <1278938907.2445.107.camel@localhost.localdomain> In-Reply-To: <1278938907.2445.107.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] temperature check: json input to token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 13:57:30 -0000 Proxies and caches.=20 EHL On Jul 12, 2010, at 8:48, "Justin Richer" wrote: > I'd like to keep form-encoded inputs. I think it makes sense to use a > well-established key-value mechanism, and the asymmetry at play here is > what the web is made of (post a form, get HTML/XML/JSON/whatever). >=20 > Along those lines, I'd actually like to relax the restriction of using > "POST" and allow for query arguments on the token endpoint as well. Long > ago it was argued that the POST requirement was to keep query parameters > from leaking into server logs. That's a fine implementation-specific > security optimization, but I don't think it belongs mandated in the > spec. As a practical matter, I know that for most of my implementations > (on small single servers), anyone who's got access to the web server > logs have access to the tokens in the database.=20 >=20 > Were there other reasons for mandating POST here that I'm forgetting? >=20 > -- Justin >=20 > On Sun, 2010-07-11 at 00:31 -0400, Brian Eaton wrote: >> Hey folks - >>=20 >> Today, the token endpoint takes form-encoded inputs, and sends JSON >> outputs. This requires developers to use both form encoding and a >> json parser. >>=20 >> Many services expose symmetric APIs for non-browser endpoints. For >> example, an API call normally takes JSON input and returns JSON >> output. >>=20 >> What do people think about having the token endpoint accept and return J= SON? >>=20 >> Cheers, >> Brian >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Jul 12 06:58: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 5CD563A68D9 for ; Mon, 12 Jul 2010 06:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 nWqZNoYHQs3N for ; Mon, 12 Jul 2010 06:58:56 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A19383A6783 for ; Mon, 12 Jul 2010 06:58:56 -0700 (PDT) Received: (qmail 17316 invoked from network); 12 Jul 2010 13:59:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 12 Jul 2010 13:59:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 12 Jul 2010 06:59:02 -0700 From: Eran Hammer-Lahav To: Michael D Adams Date: Mon, 12 Jul 2010 06:58:00 -0700 Thread-Topic: [OAUTH-WG] Authorization Header Format in draft-10 Thread-Index: AcshymJZelXp82m0TESgxPq9lvPUrA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization Header Format in 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: Mon, 12 Jul 2010 13:58:57 -0000 Yep. I should not write ABNF after a day of editing.=20 EHL On Jul 12, 2010, at 1:39, "Michael D Adams" wrote: > On Sun, Jul 11, 2010 at 8:19 PM, Eran Hammer-Lahav = wrote: >> My bad. I forgot to update the ABNF for the parameters. >>=20 >> credentials =3D "OAuth" RWS access-token RWS [ 1#auth-param ] >=20 > Thanks. I suppose it should be >=20 > credentials =3D "OAuth" RWS access-token [ RWS 1#auth-param ] >=20 > which I'll add to the sharedcopy. >=20 > Mike > --mdawaffe From recordond@gmail.com Mon Jul 12 12:51: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 24DF73A6B95 for ; Mon, 12 Jul 2010 12:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.006 X-Spam-Level: X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[AWL=-1.008, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRfni+k3NNp8 for ; Mon, 12 Jul 2010 12:51:06 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 91C893A69BE for ; Mon, 12 Jul 2010 12:51:06 -0700 (PDT) Received: by iwn38 with SMTP id 38so5210393iwn.31 for ; Mon, 12 Jul 2010 12:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=dWu7eFLSlTGgIoHKm26DTpzi+urhpG2gKzBJxszOm0w=; b=KmOPrFdrVWDkG02mkwjY8XYkt8pam/psCNO2DEKgi+506w+lNr+B9q4X42MWUHItB4 Mi2ArqntZCNrL8YN2/XeI7itALIuqgPb4IOCwQDmyCS+lRHA+0jpMPbBqdUJ2rUu0sS/ IZD7VB7ejwuxlCIfLz0+FzZnHcWD4URKg27bM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZMFQc2kRUG15NQLZMCMkINnbQYZ7Vl1UGhdrOQXGurS49ynM7Rc60fYXur6YNr73FH C0sumgQidpzwkK7NkgF12hdB/JM4k/VLsrIkdxgak4WparAJKbBS2GMDdZu+1mp1EGjF Cn49LhVRsJb6VfM79od57JX9jkcmKmUd3bPyU= MIME-Version: 1.0 Received: by 10.231.148.195 with SMTP id q3mr245828ibv.199.1278964273912; Mon, 12 Jul 2010 12:51:13 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Mon, 12 Jul 2010 12:51:13 -0700 (PDT) Date: Mon, 12 Jul 2010 12:51:13 -0700 Message-ID: From: David Recordon To: OAuth WG Content-Type: multipart/mixed; boundary=0016e644ded83a1ec8048b36139d Subject: [OAUTH-WG] Moving the User Experience Extension draft forward X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Jul 2010 19:51:08 -0000 --0016e644ded83a1ec8048b36139d Content-Type: multipart/alternative; boundary=0016e644ded83a1ec1048b36139b --0016e644ded83a1ec1048b36139b Content-Type: text/plain; charset=ISO-8859-1 I wrote this draft last month based on discussions on the mailing list, the OpenID user experience extension (which Facebook, Google, and Yahoo! have deployed), and some OAuth 2.0 implementation experience from Facebook. It defines language and display preferences which the client can include in requests to the end-user authorization endpoint. A previous draft included an immediate mode parameter but further discussion has shown that it should be removed until identity information is also addressed. Identity is outside the scope of this particular extension. I'd like this draft to become a working group document and have done my best to make it represent the group's consensus. Unfortunately the internet draft submission process is closed for a few weeks until after the meeting. :-\ Thanks, --David --0016e644ded83a1ec1048b36139b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I wrote this draft last month based on discussions on the mailing list, the= OpenID user experience extension (which Facebook, Google, and Yahoo! have = deployed), and some OAuth 2.0 implementation experience from Facebook. It d= efines language and display preferences which the client can include in req= uests to the end-user authorization endpoint.

A previous draft included an immediate mode=A0parameter=A0bu= t further discussion has shown that it should be removed until identity inf= ormation is also addressed. Identity is outside the scope of this particula= r extension.

I'd like this draft to become a working group docum= ent and have done my best to make it represent the group's consensus. U= nfortunately the internet draft submission process is closed for a few week= s until after the meeting. :-\

Thanks,
--David
--0016e644ded83a1ec1048b36139b-- --0016e644ded83a1ec8048b36139d Content-Type: text/plain; charset=US-ASCII; name="draft-recordon-oauth-v2-ux-02.txt" Content-Disposition: attachment; filename="draft-recordon-oauth-v2-ux-02.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gbjqao7b0 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBELiBSZWNvcmRvbiwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBGYWNlYm9vawpJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBUb20KRXhwaXJl czogSmFudWFyeSAyLCAyMDExICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgWWFob28hCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBCLiBkZSBNZWRlaXJvcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHb29nbGUKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMLiBTaGVwYXJk CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBGYWNlYm9vawogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSnVsIDIwMTAKCgogICAgICAgICAgICAgICAgICBPQXV0 aCAyLjAgVXNlciBFeHBlcmllbmNlIEV4dGVuc2lvbgogICAgICAgICAgICAgICAgICAgICBkcmFm dC1yZWNvcmRvbi1vYXV0aC12Mi11eC0wMgoKQWJzdHJhY3QKCiAgIFRoaXMgc3BlY2lmaWNhdGlv biBkZWZpbmVzIHR3byB1c2VyIGV4cGVyaWVuY2Ugb3JpZW50ZWQgZXh0ZW5zaW9uCiAgIHBhcmFt ZXRlcnMgZm9yIE9BdXRoIDIuMCB1c2VyIGF1dGhvcml6YXRpb24gcmVxdWVzdHMuCgpTdGF0dXMg b2YgdGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxs IGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzku CgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5l dCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91 cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1E cmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIg ZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50 ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3Ro ZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdp bGwgZXhwaXJlIG9uIEphbnVhcnkgMiwgMjAxMS4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHly aWdodCAoYykgMjAxMCBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRo ZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9j dW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAg UHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0ZWUu aWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGlj YXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAg IGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25z IHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJh Y3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExp Y2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKCgoKUmVjb3Jkb24sIGV0 IGFsLiAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAyLCAyMDExICAgICAgICAgICAgICAgIFtQYWdl IDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgIE9BdXRoIDIuMCBVc2VyIEV4cGVyaWVuY2UgRXh0ZW5z aW9uICAgICAgICAgIEp1bCAyMDEwCgoKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5k IGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2lt cGxpZmllZCBCU0QgTGljZW5zZS4KCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVj dGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAz CiAgICAgMS4xLiAgTm90YXRpb25hbCBDb252ZW50aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMwogICAyLiAgTGFuZ3VhZ2UgUHJlZmVyZW5jZSAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMKICAgMy4gIERpc3BsYXkgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzCiAgIDQuICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNAogICA1LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQKICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0CgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKUmVjb3Jkb24sIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgSmFu dWFyeSAyLCAyMDExICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAg IE9BdXRoIDIuMCBVc2VyIEV4cGVyaWVuY2UgRXh0ZW5zaW9uICAgICAgICAgIEp1bCAyMDEwCgoK MS4gIEludHJvZHVjdGlvbgoKICAgVGhpcyBleHRlbnNpb24gZGVmaW5lcyBhZGRpdGlvbmFsIHBh cmFtZXRlcnMgZm9yIHRoZSBjbGllbnQgdG8KICAgaW5jbHVkZSBpbiBPQXV0aCAyLjAgcmVxdWVz dHMgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiAgV2hpbGUKICAgdGhlcmUgYXJlIG5vdCBy ZXN0cmljdGlvbnMgYXJvdW5kIHdoaWNoIGZsb3dzIHRoaXMgZXh0ZW5zaW9uIGNhbiBiZQogICB1 c2VkIHdpdGgsIGl0IHdpbGwgZ2VuZXJhbGx5IGJlIHVzZWQgd2l0aCB1c2VyIGRlbGVnYXRpb24g Zmxvd3MuCgoxLjEuICBOb3RhdGlvbmFsIENvbnZlbnRpb25zCgogICBUaGUga2V5IHdvcmRzICdN VVNUJywgJ01VU1QgTk9UJywgJ1JFUVVJUkVEJywgJ1NIQUxMJywgJ1NIQUxMIE5PVCcsCiAgICdT SE9VTEQnLCAnU0hPVUxEIE5PVCcsICdSRUNPTU1FTkRFRCcsICdNQVknLCBhbmQgJ09QVElPTkFM JyBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQg aW4gW1JGQzIxMTldLgoKCjIuICBMYW5ndWFnZSBQcmVmZXJlbmNlCgogICBBIGNsaWVudCBNQVkg cHJvdmlkZSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2l0aCBpbmZvcm1hdGlvbiBhYm91dAog ICBhbiBlbmQtdXNlcidzIGxhbmd1YWdlIHByZWZlcmVuY2UuICBUaGUgY2xpZW50IGluY2x1ZGVz IHRoZSBmb2xsb3dpbmcKICAgVVJJIHF1ZXJ5IHBhcmFtZXRlciB3aGVuIGNvbnN0cnVjdGluZyBp dHMgcmVxdWVzdCB0byB0aGUgZW5kLXVzZXIKICAgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkk6 CgogICBsYW5ndWFnZQogICAgICBPUFRJT05BTC4gIFRoZSB1c2VyJ3MgcHJlZmVycmVkIGxhbmd1 YWdlcyByZXByZXNlbnRlZCBhcyBhIGNvbW1hLQogICAgICBzZXBhcmF0ZWQgbGlzdCBvZiBbUkZD NTY0Nl0gYmFzaWMgbGFuZ3VhZ2UgcmFuZ2VzIGluIGRlc2NlbmRpbmcKICAgICAgcHJpb3JpdHkg b3JkZXIuICBGb3IgZXhhbXBsZSwgdGhlIHZhbHVlICJmci1DQSxmci1GUixlbi1DQSIKICAgICAg cmVwcmVzZW50cyB0aGUgcHJlZmVyZW5jZSBmb3IgRnJlbmNoIHNwb2tlbiBpbiBDYW5hZGEsIEZy ZW5jaAogICAgICBzcG9rZW4gaW4gRnJhbmNlLCBmb2xsb3dlZCBieSBFbmdsaXNoIHNwb2tlbiBp biBDYW5hZGEuCgogICBUaGlzIHBhcmFtZXRlciBTSE9VTEQgdGFrZSBwcmVjZWRlbmNlIG92ZXIg Ym90aCB0aGUgSFRUUCBBY2NlcHQtCiAgIExhbmd1YWdlIGhlYWRlciBzZW50IGJ5IHRoZSBlbmQt dXNlcidzIGJyb3dzZXIgYW5kIGFueSBsYW5ndWFnZQogICBwcmVmZXJlbmNlIGluZmVycmVkIHZp YSBJUCBhZGRyZXNzIGdlb2xvY2F0aW9uLgoKCjMuICBEaXNwbGF5CgogICBPQXV0aCAyLjAgdXNl ciBkZWxlZ2F0aW9uIGZsb3dzIGFyZSBkZXNpZ25lZCB0byB3b3JrIGFjcm9zcyBhIHdpZGUKICAg dmFyaWV0eSBvZiBzY3JlZW4gc2l6ZXMsIGRldmljZSB0eXBlcywgYW5kIGNvbnRleHRzLiAgVGhl IGNsaWVudCBNQVkKICAgcmVxdWVzdCBhIHNwZWNpZmljIGZvcm0gZmFjdG9yIG9mIGRpYWxvZyBm cm9tIHRoZSBhdXRob3JpemF0aW9uCiAgIHNlcnZlciBiYXNlZCBvbiB3aGF0IHRoZXkgZmVlbCBp cyBtb3N0IGFwcHJvcHJpYXRlLiAgVGhlIGNsaWVudAogICBpbmNsdWRlcyB0aGUgZm9sbG93aW5n IFVSSSBxdWVyeSBwYXJhbWV0ZXIgd2hlbiBjb25zdHJ1Y3RpbmcgaXRzCiAgIHJlcXVlc3QgdG8g dGhlIGVuZC11c2VyIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgVVJJOgoKICAgZGlzcGxheQogICAg ICBPUFRJT05BTC4gIFRoZSBtb3N0IGFwcHJvcHJpYXRlIGZvcm0gZmFjdG9yIGZvciB0aGUgYXV0 aG9yaXphdGlvbgogICAgICBkaWFsb2cuICBJZiB0aGUgcGFyYW1ldGVyIGlzIGluY2x1ZGVkIGlu IHRoZSByZXF1ZXN0LCB0aGUgdmFsdWUKICAgICAgTVVTVCBiZSBzZXQgdG8gb25lIG9mIHRoZSBm b2xsb3dpbmc6CgoKCgoKUmVjb3Jkb24sIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAy LCAyMDExICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgIE9BdXRo IDIuMCBVc2VyIEV4cGVyaWVuY2UgRXh0ZW5zaW9uICAgICAgICAgIEp1bCAyMDEwCgoKCgogICAg ICBwYWdlCiAgICAgICAgIEEgZnVsbC1wYWdlIGF1dGhvcml6YXRpb24gc2NyZWVuICh0aGUgZGVm YXVsdCkuCgogICAgICBwb3B1cAogICAgICAgICBBIGNvbXBhY3QgZGlhbG9nIG9wdGltaXplZCBm b3IgbW9kZXJuIHdlYiBicm93c2VyIHBvcHVwCiAgICAgICAgIHdpbmRvd3MuCgogICAgICB0b3Vj aAogICAgICAgICBBIG1vYmlsZS1vcHRpbWl6ZWQgZGlhbG9nIGRlc2lnbmVkIGZvciBtb2Rlcm4g c21hcnRwaG9uZXMgc3VjaAogICAgICAgICBhcyBBbmRyb2lkIGFuZCBpUGhvbmUuCgogICAgICB3 YXAKICAgICAgICAgQW4gZXh0cmVtZWx5IGNvbXBhY3QgZGlhbG9nIG9wdGltaXplZCBmb3Igb2xk ZXIgbW9iaWxlIHdlYgogICAgICAgICBicm93c2Vycy4KCgo0LiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMKCiAgIE5vIGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgYmV5b25kIHRob3NlIGRlc2Ny aWJlZCB3aXRoaW4gdGhlIE9BdXRoCiAgIDIuMCBQcm90b2NvbC4KCgo1LiAgTm9ybWF0aXZlIFJl ZmVyZW5jZXMKCiAgIFtJLUQuaWV0Zi5vYXV0aC12Ml0KICAgICAgICAgICAgICBIYW1tZXItTGFo YXYsIEUuLCBFZC4sIFJlY29yZG9uLCBELiwgYW5kIEQuIEhhcmR0LCAiVGhlCiAgICAgICAgICAg ICAgT0F1dGggMi4wIFByb3RvY29sIiwgSnVuIDIwMTAuCgogICBbUkZDMjExOV0gIEJyYWRuZXIs IEIuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAg IFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTkuCgogICBbUkZDNTY0Nl0gIFBo aWxsaXBzLCBBLiwgRWQuIGFuZCBNLiBEYXZpcywgRWQuLCAiVGFncyBmb3IgSWRlbnRpZnlpbmcK ICAgICAgICAgICAgICBMYW5ndWFnZXMiLCBCQ1AgNDcsIFJGQyA1NjQ2LgoKCkF1dGhvcnMnIEFk ZHJlc3NlcwoKICAgRGF2aWQgUmVjb3Jkb24gKGVkaXRvcikKICAgRmFjZWJvb2sKCiAgIEVtYWls OiBkYXZpZHJlY29yZG9uQGZhY2Vib29rLmNvbQoKCgoKCgoKClJlY29yZG9uLCBldCBhbC4gICAg ICAgICBFeHBpcmVzIEphbnVhcnkgMiwgMjAxMSAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCklu dGVybmV0LURyYWZ0ICAgICBPQXV0aCAyLjAgVXNlciBFeHBlcmllbmNlIEV4dGVuc2lvbiAgICAg ICAgICBKdWwgMjAxMAoKCiAgIEFsbGVuIFRvbQogICBZYWhvbyEKCiAgIEVtYWlsOiBhdG9tQHlh aG9vLWluYy5jb20KCgogICBCcmVubyBkZSBNZWRlaXJvcwogICBHb29nbGUKCiAgIEVtYWlsOiBi cmVub0Bnb29nbGUuY29tCgoKICAgTHVrZSBTaGVwYXJkCiAgIEZhY2Vib29rCgogICBFbWFpbDog bHNoZXBhcmRAZmFjZWJvb2suY29tCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK UmVjb3Jkb24sIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAyLCAyMDExICAgICAgICAg ICAgICAgIFtQYWdlIDVdCgwKCg== --0016e644ded83a1ec8048b36139d-- From eran@hueniverse.com Mon Jul 12 13:26:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466173A6878 for ; Mon, 12 Jul 2010 13:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.166, 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 jfVwdmqEHHEF for ; Mon, 12 Jul 2010 13:26:47 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 63DD83A69C5 for ; Mon, 12 Jul 2010 13:26:47 -0700 (PDT) Received: (qmail 1177 invoked from network); 12 Jul 2010 20:26:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 Jul 2010 20:26:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 12 Jul 2010 13:26:52 -0700 From: Eran Hammer-Lahav To: David Recordon , OAuth WG Date: Mon, 12 Jul 2010 13:26:48 -0700 Thread-Topic: [OAUTH-WG] Moving the User Experience Extension draft forward Thread-Index: Acsh+52bFku39QYrTL2mHvMC/FycSQABO/v9 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C860C8983707Ceranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Jul 2010 20:26:48 -0000 --_000_C860C8983707Ceranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Now that core is pretty stable, we should start adding a few new WG items. = This is a no brainer. EHL On 7/12/10 12:51 PM, "David Recordon" wrote: I wrote this draft last month based on discussions on the mailing list, the= OpenID user experience extension (which Facebook, Google, and Yahoo! have = deployed), and some OAuth 2.0 implementation experience from Facebook. It d= efines language and display preferences which the client can include in req= uests to the end-user authorization endpoint. A previous draft included an immediate mode parameter but further discussio= n has shown that it should be removed until identity information is also ad= dressed. Identity is outside the scope of this particular extension. I'd like this draft to become a working group document and have done my bes= t to make it represent the group's consensus. Unfortunately the internet dr= aft submission process is closed for a few weeks until after the meeting. := -\ Thanks, --David --_000_C860C8983707Ceranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Moving the User Experience Extension draft forward</T= ITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>Now that core is pretty stable, we should start adding a few new WG i= tems. This is a no brainer.<BR> <BR> EHL<BR> <BR> <BR> On 7/12/10 12:51 PM, "David Recordon" <<a href=3D"recordond@gm= ail.com">recordond@gmail.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>I wrote this draft last month based on disc= ussions on the mailing list, the OpenID user experience extension (which Fa= cebook, Google, and Yahoo! have deployed), and some OAuth 2.0 implementatio= n experience from Facebook. It defines language and display preferences whi= ch the client can include in requests to the end-user authorization endpoin= t.<BR> <BR> A previous draft included an immediate mode=A0parameter=A0but further discu= ssion has shown that it should be removed until identity information is als= o addressed. Identity is outside the scope of this particular extension.<BR= > <BR> I'd like this draft to become a working group document and have done my bes= t to make it represent the group's consensus. Unfortunately the internet dr= aft submission process is closed for a few weeks until after the meeting. := -\<BR> <BR> Thanks,<BR> --David<BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C860C8983707Ceranhueniversecom_-- From eran@hueniverse.com Mon Jul 12 13:30:00 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553D13A689D for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 13:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 oR6bgSKap9rU for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 13:29:55 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 849A93A6878 for <oauth@ietf.org>; Mon, 12 Jul 2010 13:29:55 -0700 (PDT) Received: (qmail 3594 invoked from network); 12 Jul 2010 20:30:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 Jul 2010 20:30:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 12 Jul 2010 13:30:00 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Eve Maler <eve@xmlgrrl.com>, William Mills <wmills@yahoo-inc.com> Date: Mon, 12 Jul 2010 13:29:56 -0700 Thread-Topic: [OAUTH-WG] "access grant" terminology Thread-Index: Acshx7cjKBIpaM74QxKRw/De7jic/QAOUZwh Message-ID: <C860C954.3707E%eran@hueniverse.com> In-Reply-To: <1E249FBE-0C4F-4C64-93F9-DD3172462D38@xmlgrrl.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C860C9543707Eeranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] "access grant" terminology X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 12 Jul 2010 20:30:00 -0000 --_000_C860C9543707Eeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Approval feels like something temporary that happens in a specific moment, = unlike grant or credential which are 'issued'. EHL On 7/12/10 6:39 AM, "Eve Maler" <eve@xmlgrrl.com> wrote: How about "approval", as in delegation approval or association approval (si= nce the resource owner is approving or consenting to the association of the= se two services on the owner's behalf for delegated access purposes, with s= pecific tokens later representing specific access authorizations)? Eve On 11 Jul 2010, at 10:26 PM, William Mills wrote: > I think "access credential" is better that either of those. Using > "grant" as a noun is a somewhat obscure usage, a la "land grant", which > I think of more as the deed to a property. > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >> On Behalf Of Eran Hammer-Lahav >> Sent: Saturday, July 10, 2010 8:04 PM >> To: Brian Eaton; OAuth WG >> Subject: Re: [OAUTH-WG] "access grant" terminology >> >> >> >> >> On 7/10/10 7:46 PM, "Brian Eaton" <beaton@google.com> wrote: >> >>> The term "access grant" in the -09 spec is a bit odd. Normally >>> "access grant" or "permission grant" would refer to a >> specific policy >>> decision made by a resource owner. >>> >>> But that's not how the -09 spec uses the term. The -09 >> spec refers to >>> authorization codes and assertions as "access grants". >> Again, that's >>> weird. Normally an assertion would be referred to as a >> "credential", >>> not a grant. >> >> Access grant is something that represents the decision made >> by the resource owner. If the resource owner approves access, >> it is represented by a authorization code. If the resource >> owner shares its password, it is equivalent to unlimited access grant. >> >> I coined the term based on common language, not on any >> existing terminology. >> If there is a real conflict here, I am happy to consider >> another term, but it doesn't sound like this is the case, or >> that the term is used against its meaning. >> >>> I think the term "authorization credential" might be a >> better fit than >>> "access grant". >>> >>> It certainly describes the purpose of the authorization >> code and the >>> assertion. And the term "credential" is normally used to describe >>> things that need to be verified and protected. >> >> I think authorization credential is going to confuse most >> readers. The spec refers to credentials almost exclusively >> when dealing with identifier and password (client, end-user), >> or as a general term for client authentication. >> Authorization is specific to the end-user authorization >> endpoint and will be confusing when used with assertions and >> other grant types. >> >> So I'm open to other ideas but not this one. >> >> Note that since this term impacts the name of the current 'grant_type' >> parameter, changing it means code changes. >> >> If anyone has a last minute idea please share (or if you are >> happy with the current grant type). I expect it to be >> annoying to change once -10 is stable for 4 weeks. >> >> 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 Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C860C9543707Eeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [OAUTH-WG] "access grant" terminology Approval feels like something temporary that happens in a specific mo= ment, unlike grant or credential which are ‘issued’.

EHL


On 7/12/10 6:39 AM, "Eve Maler" <e= ve@xmlgrrl.com> wrote:

How about "approval", as in deleg= ation approval or association approval (since the resource owner is approvi= ng or consenting to the association of these two services on the owner's be= half for delegated access purposes, with specific tokens later representing= specific access authorizations)?

        Eve

On 11 Jul 2010, at 10:26 PM, William Mills wrote:

> I think "access credential" is  better that either of t= hose.  Using
> "grant" as a noun is a somewhat obscure usage, a la "la= nd grant", which
> I think of more as the deed to a property.
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org<= /a>]
>> On Behalf Of Eran Hammer-Lahav
>> Sent: Saturday, July 10, 2010 8:04 PM
>> To: Brian Eaton; OAuth WG
>> Subject: Re: [OAUTH-WG] "access grant" terminology
>>
>>
>>
>>
>> On 7/10/10 7:46 PM, "Brian Eaton" <beaton@google.com> wrote:
>>
>>> The term "access grant" in the -09 spec is a bit odd= .  Normally
>>> "access grant" or "permission grant" would= refer to a
>> specific policy
>>> decision made by a resource owner.
>>>
>>> But that's not how the -09 spec uses the term.  The -09 >> spec refers to
>>> authorization codes and assertions as "access grants"= ;.
>> Again, that's
>>> weird.  Normally an assertion would be referred to as a >> "credential",
>>> not a grant.
>>
>> Access grant is something that represents the decision made
>> by the resource owner. If the resource owner approves access,
>> it is represented by a authorization code. If the resource
>> owner shares its password, it is equivalent to unlimited access gr= ant.
>>
>> I coined the term based on common language, not on any
>> existing terminology.
>> If there is a real conflict here, I am happy to consider
>> another term, but it doesn't sound like this is the case, or
>> that the term is used against its meaning.
>>
>>> I think the term "authorization credential" might be= a
>> better fit than
>>> "access grant".
>>>
>>> It certainly describes the purpose of the authorization
>> code and the
>>> assertion.  And the term "credential" is normal= ly used to describe
>>> things that need to be verified and protected.
>>
>> I think authorization credential is going to confuse most
>> readers. The spec refers to credentials almost exclusively
>> when dealing with identifier and password (client, end-user),
>> or as a general term for client authentication.
>> Authorization is specific to the end-user authorization
>> endpoint and will be confusing when used with assertions and
>> other grant types.
>>
>> So I'm open to other ideas but not this one.
>>
>> Note that since this term impacts the name of the current 'grant_t= ype'
>> parameter, changing it means code changes.
>>
>> If anyone has a last minute idea please share (or if you are
>> happy with the current grant type). I expect it to be
>> annoying to change once -10 is stable for 4 weeks.
>>
>> EHL
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth


Eve Maler
http://www.xmlgrrl.com/blog
http://www.twitter.com/xmlgrrl
http://www.linkedin.com/in/= evemaler

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

--_000_C860C9543707Eeranhueniversecom_-- From recordond@gmail.com Mon Jul 12 15: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 821F33A6844 for ; Mon, 12 Jul 2010 15:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csQPoMqswz3l for ; Mon, 12 Jul 2010 15:38:56 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0ACB63A681D for ; Mon, 12 Jul 2010 15:38:55 -0700 (PDT) Received: by iwn38 with SMTP id 38so5368504iwn.31 for ; Mon, 12 Jul 2010 15:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=lJaRfNmvUzfcgl2UQFGuFaEr4p2K8t9T3G9hokCRoC8=; b=eTgmOKOS+uNXLUUVkgLDI71imNJAOJEyFDbXgcyo9EPDVI3a8+3QDgux5u5vHEEh2l T0AuEbV8f7oPrsuIPR4YUXI/e+DvOCzyO58fckGKD/btiBQJXod1P4NMhLdZimZFIHEm uSKheFh1lhLTAlD2m/YVCyMf0kBR49btuiD8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=smIZV+WwtkXtQpl9WF+T9bUJLjec2pBa5BYRBcMzxCaZ2/yNf9D8m7k2+Pp1ZMJaI7 ay6jDPqlndx0O/JGUmDfGBnf6EFSrq4mR4yh245vlwF0twhVXlhCTuLWrXhEobzqI/Bh Axb5S7VOMavmn6VYZrlfXC/wZD8wy+DJ4wRuM= MIME-Version: 1.0 Received: by 10.231.149.202 with SMTP id u10mr16059516ibv.56.1278974342942; Mon, 12 Jul 2010 15:39:02 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Mon, 12 Jul 2010 15:39:02 -0700 (PDT) Date: Mon, 12 Jul 2010 15:39:02 -0700 Message-ID: From: David Recordon To: OAuth WG Content-Type: multipart/mixed; boundary=005045013c62634ee5048b386b66 Subject: [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: Mon, 12 Jul 2010 22:38:57 -0000 --005045013c62634ee5048b386b66 Content-Type: multipart/alternative; boundary=005045013c62634edc048b386b64 --005045013c62634edc048b386b64 Content-Type: text/plain; charset=ISO-8859-1 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 assertion 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 values for the token and token secret. My goal is that this draft become a working group document. A question for the group is if upgrading multiple tokens at once is a necessary use case? The assertion format within the core spec only supports issuing a single access token. Facebook has a custom endpoint which allows upgrading multiple tokens at once, but I don't actually have data about how many developers make use of that functionality. Thanks, --David --005045013c62634edc048b386b64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The ability to upgrade OAuth 1.0 tokens and secrets to OAuth 2.0 access tok= ens has come up on the list a few times. Attached is a draft assertion form= at which allows a client to trade an OAuth 1.0 token/secret pair for an OAu= th 2.0 access token. The assertion format is a JSON object with values for = the token and token secret. My goal is that this draft become a working gro= up 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 endpoin= t which allows upgrading multiple tokens at once, but I don't actually = have data about how many developers make use of that functionality.

Thanks,
--David
--005045013c62634edc048b386b64-- --005045013c62634ee5048b386b66 Content-Type: text/plain; charset=US-ASCII; name="draft-recordon-oauth-v2-upgrade-00.txt" Content-Disposition: attachment; filename="draft-recordon-oauth-v2-upgrade-00.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gbjwalzr0 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBELiBSZWNvcmRvbiwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBGYWNlYm9vawpJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVsIDIwMTAKRXhwaXJl czogSmFudWFyeSAyLCAyMDExCgoKICAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCBUb2tlbiBV cGdyYWRlIEV4dGVuc2lvbgogICAgICAgICAgICAgICAgICAgZHJhZnQtcmVjb3Jkb24tb2F1dGgt djItdXBncmFkZS0wMAoKQWJzdHJhY3QKCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGFu IE9BdXRoIDIuMCBhc3NlcnRpb24gcmVxdWVzdCBmb3JtYXQgZm9yCiAgIHVwZ3JhZGluZyBPQXV0 aCAxLjAgdG9rZW4gYW5kIHNlY3JldCBwYWlycyB0byBPQXV0aCAyLjAgYWNjZXNzCiAgIHRva2Vu cy4KClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0 dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzgg YW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2Yg dGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0 IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFz IEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0 cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAg SW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv ZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRl ZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRl IHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNp dGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJu ZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gSmFudWFyeSAyLCAyMDExLgoKQ29weXJpZ2h0IE5vdGlj ZQoKICAgQ29weXJpZ2h0IChjKSAyMDEwIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50 aWZpZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoK ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3Qn cyBMZWdhbAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRw Oi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBv ZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBk b2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCBy ZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBv bmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxp ZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0 aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFu dHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKCgoKClJl Y29yZG9uICAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMiwgMjAxMSAgICAgICAgICAg ICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgT0F1dGggMi4wIFRva2VuIFVwZ3Jh ZGUgRXh0ZW5zaW9uICAgICAgICAgICBKdWwgMjAxMAoKClRhYmxlIG9mIENvbnRlbnRzCgogICAx LiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDMKICAgICAxLjEuICBOb3RhdGlvbmFsIENvbnZlbnRpb25zICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzCiAgIDIuICBBc3NlcnRpb24gUmVxdWVzdCAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMwogICAzLiAgQXNzZXJ0 aW9uIFJlc3BvbnNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDQKICAgNC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA0CiAgIDUuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNAogICBBdXRob3IncyBBZGRyZXNzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKUmVjb3Jkb24gICAgICAgICAgICAg ICAgIEV4cGlyZXMgSmFudWFyeSAyLCAyMDExICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICBPQXV0aCAyLjAgVG9rZW4gVXBncmFkZSBFeHRlbnNpb24gICAgICAg ICAgIEp1bCAyMDEwCgoKMS4gIEludHJvZHVjdGlvbgoKICAgVGhpcyBleHRlbnNpb24gZGVmaW5l cyBhbiBhc3NlcnRpb24gZm9ybWF0IGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uCiAgIDQuMS4zIG9m IFtJLUQuaWV0Zi5vYXV0aC12Ml0uCgoxLjEuICBOb3RhdGlvbmFsIENvbnZlbnRpb25zCgogICBU aGUga2V5IHdvcmRzICdNVVNUJywgJ01VU1QgTk9UJywgJ1JFUVVJUkVEJywgJ1NIQUxMJywgJ1NI QUxMIE5PVCcsCiAgICdTSE9VTEQnLCAnU0hPVUxEIE5PVCcsICdSRUNPTU1FTkRFRCcsICdNQVkn LCBhbmQgJ09QVElPTkFMJyBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRl ZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKCjIuICBBc3NlcnRpb24gUmVxdWVzdAoKICAg VGhlIGNsaWVudCB3aWxsIG1ha2UgYSByZXF1ZXN0IHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBhcwogICBkZXNjcmliZWQgaW4gc2VjdGlvbiA0LjEuMyBvZiBbSS1ELmlldGYub2F1dGgtdjJd IHdpdGggdGhlIGZvbGxvd2luZwogICBwYXJhbWV0ZXJzOgoKICAgYXNzZXJ0aW9uX3R5cGUKICAg ICAgUkVRVUlSRUQuICJodHRwOi8vb2F1dGgubmV0L3Rva2VuLzEuMCIKCiAgIGFzc2VydGlvbgog ICAgICBSRVFVSVJFRC4gIFRoZSBPQXV0aCAxLjAgdG9rZW4gYW5kIHRva2VuIHNlY3JldCB0byBi ZSB1cGdyYWRlZCBhcwogICAgICBhIEpTT04gb2JqZWN0IHdpdGggdGhlIGtleXMgYHRva2VuYCBh bmQgYHRva2VuX3NlY3JldGAuCgogICBjbGllbnRfaWQKICAgICAgUkVRVUlSRUQuICBUaGUgY2xp ZW50IGlkZW50aWZpZXIgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMiBvZgogICAgICBbSS1ELmll dGYub2F1dGgtdjJdLgoKICAgY2xpZW50X3NlY3JldAogICAgICBSRVFVSVJFRC4gIFRoZSBjbGll bnQgc2VjcmV0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIgb2YKICAgICAgW0ktRC5pZXRmLm9h dXRoLXYyXS4KCiAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IG1ha2VzIHRoZSBmb2xsb3dpbmcg SFRUUCByZXF1ZXN0IHVzaW5nCiAgIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eToKClBPU1QgL3Rv a2VuIEhUVFAvMS4xCkhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQpDb250ZW50LVR5cGU6IGFwcGxp Y2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZAoKZ3JhbnRfdHlwZT1hc3NlcnRpb24mCmFzc2Vy dGlvbl90eXBlPWh0dHAlM0ElMkYlMkZvYXV0aC5uZXQlMkZ0b2tlbiUyRjEuMCYKYXNzZXJ0aW9u PSU3Qid0b2tlbiclM0EncmptYUdhdzQ4WFQ5QVRXZm9mYXonJTJDJ3Rva2VuX3NlY3JldCclM0En T2dGY2ZOOUoyRU1vakJSJyU3RCYKY2xpZW50X2lkPThlU0VJcG5xbU0mCmNsaWVudF9zZWNyZXQ9 czZCaGRSa3F0MwoKCgoKCgpSZWNvcmRvbiAgICAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5 IDIsIDIwMTEgICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgIE9B dXRoIDIuMCBUb2tlbiBVcGdyYWRlIEV4dGVuc2lvbiAgICAgICAgICAgSnVsIDIwMTAKCgozLiAg QXNzZXJ0aW9uIFJlc3BvbnNlCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB2YWxp ZGF0ZSB0aGUgY2xpZW50IGNyZWRlbnRpYWxzLCB0b2tlbiwKICAgYW5kIHRva2VuIHNlY3JldC4g IElmIHRoZXkgYXJlIGFsbCB2YWxpZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgIGlzc3Vl cyBhbiBhY2Nlc3MgdG9rZW4gcmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4yIG9m CiAgIFtJLUQuaWV0Zi5vYXV0aC12Ml0uICBUaGUgbmV3IGFjY2VzcyB0b2tlbiBTSE9VTEQgaGF2 ZSB0aGUgc2FtZQogICBleHBpcmF0aW9uIGFuZCBzY29wZSBhcyB0aGUgT0F1dGggMS4wIHRva2Vu IHdoaWNoIHRoZSBjbGllbnQgaXMKICAgdXBncmFkaW5nLgoKCjQuICBTZWN1cml0eSBDb25zaWRl cmF0aW9ucwoKICAgTm8gYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucyBiZXlvbmQgdGhvc2UgZGVz Y3JpYmVkIHdpdGhpbiB0aGUgT0F1dGgKICAgMi4wIFByb3RvY29sLgoKCjUuICBOb3JtYXRpdmUg UmVmZXJlbmNlcwoKICAgW0ktRC5pZXRmLm9hdXRoLXYyXQogICAgICAgICAgICAgIEhhbW1lci1M YWhhdiwgRS4sIEVkLiwgUmVjb3Jkb24sIEQuLCBhbmQgRC4gSGFyZHQsICJUaGUKICAgICAgICAg ICAgICBPQXV0aCAyLjAgUHJvdG9jb2wiLCBKdW4gMjAxMC4KCiAgIFtSRkMyMTE5XSAgQnJhZG5l ciwgQi4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAg ICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOS4KCgpBdXRob3IncyBBZGRy ZXNzCgogICBEYXZpZCBSZWNvcmRvbiAoZWRpdG9yKQogICBGYWNlYm9vawoKICAgRW1haWw6IGRh dmlkcmVjb3Jkb25AZmFjZWJvb2suY29tCgoKCgoKCgoKCgoKCgoKCgoKCgpSZWNvcmRvbiAgICAg ICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMTEgICAgICAgICAgICAgICAgW1BhZ2Ug NF0KDAoK --005045013c62634ee5048b386b66-- From James.H.Manger@team.telstra.com Mon Jul 12 17:49: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 26BBE3A69DC for ; Mon, 12 Jul 2010 17:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 xHuELD1TCwc7 for ; Mon, 12 Jul 2010 17:49:30 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 8B89D3A6985 for ; Mon, 12 Jul 2010 17:49:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,191,1278252000"; d="scan'208,217";a="5956692" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 13 Jul 2010 10:49:34 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6041"; a="4321602" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcdvi.tcif.telstra.com.au with ESMTP; 13 Jul 2010 10:49:36 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Tue, 13 Jul 2010 10:49:35 +1000 From: "Manger, James H" To: David Recordon , OAuth WG Date: Tue, 13 Jul 2010 10:49:43 +1000 Thread-Topic: [OAUTH-WG] Moving the User Experience Extension draft forward Thread-Index: Acsh+5sHWnM60vrKQGmj+i42y3Vb1QAI3ohQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1126618FCD7@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1126618FCD7WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 00:49:34 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1126618FCD7WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable .David, > I'd like this draft [draft-recordon-oauth-v2-ux-02.txt] to become a worki= ng group document I disagree. This shouldn't be a working group document. It should be moved = into the core. The 2 parameters it defines (language and display) should be moved to the c= ore OAuth doc now they have obtained some consensus (for which a separate d= raft was helpful). I suggest a sub-section of section 3 "Obtaining End-User Authorization" (of= the core spec) for user interface parameters. Possible structure: 3. Obtaining End-User Authorization [keep most of the existing paragraphs, except the definitions of the 5 pa= rameters] [Add a paragraph saying various query parameters can be added to the end-= user authorization URI to provide details or preferences about the style of= response, the client application, the scope of access desired, the user, t= he user interface etc. Some parameters are defined in the following sub-sec= tions. Other parameters can be defined by other specifications, or by servi= ces.] 3.1 Response style parameters response_type ... redirect_uri ... state ... 3.2 Client parameters client_id ... 3.3 User interface parameters language ... display ... 3.4 Scope of access parameters scope ... -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E1126618FCD7WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

.David,

 

> I'd like this draft [draft-recordon-oauth-v2-ux-02.txt] to become a work= ing group document

 

I disagree. This shouldn’t be a work= ing group document. It should be moved into the core.

 

The 2 parameters it defines (language and = display) should be moved to the core OAuth doc now they have obtained some = consensus (for which a separate draft was helpful).

 

I suggest a sub-section of section 3 ̶= 0;Obtaining End-User Authorization” (of the core spec) for user inter= face parameters.

 

Possible structure:

 

3. Obtaining End-User Authorization

  [keep most of the existing paragrap= hs, except the definitions of the 5 parameters]

  [Add a paragraph saying various que= ry parameters can be added to the end-user authorization URI to provide det= ails or preferences about the style of response, the client application, the scope of access desired, the user, the user interface etc. Some parame= ters are defined in the following sub-sections. Other parameters can be def= ined by other specifications, or by services.]

 

3.1 Response style parameters

  response_type …

  redirect_uri …

  state …

 

3.2 Client parameters

  client_id …

 

3.3 User interface parameters

  language …

  display …

 

3.4 Scope of access parameters

  scope …

 

 

--

James Manger

--_000_255B9BB34FB7D647A506DC292726F6E1126618FCD7WSMSG3153Vsrv_-- From recordond@gmail.com Mon Jul 12 19:31: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 B0BEF3A6844 for ; Mon, 12 Jul 2010 19:31:37 -0700 (PDT) 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.379, 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 J-M7O8nLd2uP for ; Mon, 12 Jul 2010 19:31:24 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BDACB3A69A6 for ; Mon, 12 Jul 2010 19:31:02 -0700 (PDT) Received: by iwn38 with SMTP id 38so5579232iwn.31 for ; Mon, 12 Jul 2010 19:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qLczfB6qLG1VRPMJ1WBy5nNsJFTeUZQfHRMY/0K0oOk=; b=jj0c+aT5QRM0CeNCq/ImA6Proj8V5s51GLeZnikDvPQ6d6HSouVf8qkJ3aJneDoTgM bxQ4N6Lov++oIsw7M8HyJrd5SfHY90+QQ7c2mzHymVMeK+oOJ3W9/tpG+dQEbdoUYCCT ckGf0zZvwWhr1ZVOtnjIhwg7tX8OH33rN66qw= 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=jgCt2wsz//XS2f5vXFn7oVP/O5C4qDcdJWQpiB0AvMZJtzIEyLivPr/fOBvJVa/ImK tZGRzWc19vxQg4eZWN1JWIY/kTKJQKw9qOeooz+wfJppEDT2i2HKzF7XZ/JB7NR0M0Xd I9c4956hgpFPzTy8+kbDcuTbqHIuH0jDWN/AA= MIME-Version: 1.0 Received: by 10.231.169.10 with SMTP id w10mr3023203iby.106.1278988270765; Mon, 12 Jul 2010 19:31:10 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Mon, 12 Jul 2010 19:31:10 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1126618FCD7@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1126618FCD7@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 12 Jul 2010 19:31:10 -0700 Message-ID: From: David Recordon To: "Manger, James H" Content-Type: multipart/alternative; boundary=0016e6d26cc88d0675048b3ba9f8 Cc: OAuth WG Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 02:31:43 -0000 --0016e6d26cc88d0675048b3ba9f8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Obviously I'm fine with this being merged into core if that's what the grou= p wants to do. :) On Mon, Jul 12, 2010 at 5:49 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > .David, > > > > > I'd like this draft [draft-recordon-oauth-v2-ux-02.txt] to become a > working group document > > > > I disagree. This shouldn=92t be a working group document. It should be mo= ved > into the core. > > > > The 2 parameters it defines (language and display) should be moved to the > core OAuth doc now they have obtained some consensus (for which a separat= e > draft was helpful). > > > > I suggest a sub-section of section 3 =93Obtaining End-User Authorization= =94 (of > the core spec) for user interface parameters. > > > > Possible structure: > > > > 3. Obtaining End-User Authorization > > [keep most of the existing paragraphs, except the definitions of the 5 > parameters] > > [Add a paragraph saying various query parameters can be added to the > end-user authorization URI to provide details or preferences about the st= yle > of response, the client application, the scope of access desired, the use= r, > the user interface etc. Some parameters are defined in the following > sub-sections. Other parameters can be defined by other specifications, or= by > services.] > > > > 3.1 Response style parameters > > response_type =85 > > redirect_uri =85 > > state =85 > > > > 3.2 Client parameters > > client_id =85 > > > > 3.3 User interface parameters > > language =85 > > display =85 > > > > 3.4 Scope of access parameters > > scope =85 > > > > > > -- > > James Manger > --0016e6d26cc88d0675048b3ba9f8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Obviously I'm fine with this being merged into core if that's what = the group wants to do. :)


On Mon, Ju= l 12, 2010 at 5:49 PM, Manger, James H <James.H.Manger@team.telstra.com>= ; wrote:

.Davi= d,

=A0

> I'd like this draft [draft-recordon-oauth-v2-ux-02.txt] to= become a working group document

=A0

I disagree. This shoul= dn=92t be a working group document. It should be moved into the core.

=A0

The 2 parameters it de= fines (language and display) should be moved to the core OAuth doc now they= have obtained some consensus (for which a separate draft was helpful).

=A0

I suggest a sub-sectio= n of section 3 =93Obtaining End-User Authorization=94 (of the core spec) fo= r user interface parameters.

=A0

Possible structure:

=A0

3. Obtaining End-User = Authorization

=A0 [keep most of the = existing paragraphs, except the definitions of the 5 parameters]

=A0 [Add a paragraph s= aying various query parameters can be added to the end-user authorization U= RI to provide details or preferences about the style of response, the clien= t application, the scope of access desired, the user, the user interface etc. Some parame= ters are defined in the following sub-sections. Other parameters can be def= ined by other specifications, or by services.]

=A0

3.1 Response style par= ameters

=A0 response_type =85<= /span>

=A0 redirect_uri =85

=A0 state =85

=A0

3.2 C= lient parameters

=A0 c= lient_id =85

=A0

3.3 U= ser interface parameters

=A0 l= anguage =85

=A0 d= isplay =85

=A0

3.4 S= cope of access parameters

=A0 s= cope =85

=A0

=A0

--

James= Manger


--0016e6d26cc88d0675048b3ba9f8-- From eran@hueniverse.com Mon Jul 12 19:36: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 C95D83A6844 for ; Mon, 12 Jul 2010 19:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.167, 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 krHzc6fxRGBY for ; Mon, 12 Jul 2010 19:36:41 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 539C33A67AE for ; Mon, 12 Jul 2010 19:36:41 -0700 (PDT) Received: (qmail 14857 invoked from network); 13 Jul 2010 02:36:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 02:36:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 12 Jul 2010 19:36:49 -0700 From: Eran Hammer-Lahav To: David Recordon , James Manger Date: Mon, 12 Jul 2010 19:36:45 -0700 Thread-Topic: [OAUTH-WG] Moving the User Experience Extension draft forward Thread-Index: AcsiM7WqmXButcX7ToGYAuVmUrGvKQAAIZNW Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8611F4D370A0eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 02:36:46 -0000 --_000_C8611F4D370A0eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think it belongs in a separate spec (even if at the end if might mean mor= e work for others and me). I don't think the UX bits are well understood or= enjoy enough experience to become part of core. They also tend to change o= ften as the state of the art in UX evolves. With -10, I am going to take a general approach of objecting any new featur= es in core unless you can show the spec cannot be used without them. EHL On 7/12/10 7:31 PM, "David Recordon" wrote: Obviously I'm fine with this being merged into core if that's what the grou= p wants to do. :) On Mon, Jul 12, 2010 at 5:49 PM, Manger, James H wrote: .David, > I'd like this draft [draft-recordon-oauth-v2-ux-02.txt] to become a worki= ng group document I disagree. This shouldn't be a working group document. It should be moved = into the core. The 2 parameters it defines (language and display) should be moved to the c= ore OAuth doc now they have obtained some consensus (for which a separate d= raft was helpful). I suggest a sub-section of section 3 "Obtaining End-User Authorization" (of= the core spec) for user interface parameters. Possible structure: 3. Obtaining End-User Authorization [keep most of the existing paragraphs, except the definitions of the 5 pa= rameters] [Add a paragraph saying various query parameters can be added to the end-= user authorization URI to provide details or preferences about the style of= response, the client application, the scope of access desired, the user, t= he user interface etc. Some parameters are defined in the following sub-sec= tions. Other parameters can be defined by other specifications, or by servi= ces.] 3.1 Response style parameters response_type ... redirect_uri ... state ... 3.2 Client parameters client_id ... 3.3 User interface parameters language ... display ... 3.4 Scope of access parameters scope ... --_000_C8611F4D370A0eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Moving the User Experience Extension draft forward</T= ITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>I think it belongs in a separate spec (even if at the end if might me= an more work for others and me). I don’t think the UX bits are well u= nderstood or enjoy enough experience to become part of core. They also tend= to change often as the state of the art in UX evolves.<BR> <BR> With –10, I am going to take a general approach of objecting any new = features in core unless you can show the spec cannot be used without them.<= BR> <BR> EHL<BR> <BR> <BR> On 7/12/10 7:31 PM, "David Recordon" <<a href=3D"recordond@gma= il.com">recordond@gmail.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>Obviously I'm fine with this being merged i= nto core if that's what the group wants to do. :)<BR> <BR> <BR> On Mon, Jul 12, 2010 at 5:49 PM, Manger, James H <<a href=3D"James.H.Man= ger@team.telstra.com">James.H.Manger@team.telstra.com</a>> wrote:<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D">.David,<BR> =A0<BR> </FONT>> I'd like this draft [draft-recordon-oauth-v2-ux-02.txt] to beco= me a working group document<BR> <FONT COLOR=3D"#1F497D">=A0<BR> I disagree. This shouldn’t be a working group document. It should be = moved into the core.<BR> =A0<BR> The 2 parameters it defines (language and display) should be moved to the c= ore OAuth doc now they have obtained some consensus (for which a separate d= raft was helpful).<BR> =A0<BR> I suggest a sub-section of section 3 “Obtaining End-User Authorizatio= n” (of the core spec) for user interface parameters.<BR> =A0<BR> Possible structure:<BR> =A0<BR> 3. Obtaining End-User Authorization<BR> =A0 [keep most of the existing paragraphs, except the definitions of the 5 = parameters]<BR> =A0 [Add a paragraph saying various query parameters can be added to the en= d-user authorization URI to provide details or preferences about the style = of response, the client application, the scope of access desired, the user,= the user interface etc. Some parameters are defined in the following sub-s= ections. Other parameters can be defined by other specifications, or by ser= vices.]<BR> =A0<BR> 3.1 Response style parameters<BR> =A0 response_type …<BR> =A0 redirect_uri …<BR> =A0 state …<BR> =A0<BR> 3.2 Client parameters<BR> =A0 client_id …<BR> =A0<BR> 3.3 User interface parameters<BR> =A0 language …<BR> =A0 display …<BR> =A0<BR> 3.4 Scope of access parameters<BR> =A0 scope …<BR> =A0<BR> =A0</FONT><BR> </SPAN></FONT></BLOCKQUOTE></BLOCKQUOTE> </BODY> </HTML> --_000_C8611F4D370A0eranhueniversecom_-- From sakimura@gmail.com Mon Jul 12 19:51:02 2010 Return-Path: <sakimura@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A713A6988 for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 19:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liaVYezw2K0U for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 19:51:00 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 9EAA63A68F0 for <oauth@ietf.org>; Mon, 12 Jul 2010 19:51:00 -0700 (PDT) Received: by iwn38 with SMTP id 38so5596813iwn.31 for <oauth@ietf.org>; Mon, 12 Jul 2010 19:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=E8tc11fg8W6VZVW8bC4mtIY9z/eBe4j+dP9S5AdG1G8=; b=bQNlRphB49XOVKWfgGXBkL0ZgVl6c7cyCwyukyrTRz6Og2RbbjvcB48H8faavZhilV n6L1nrzbLrlVrJH24W0nbvk4pqAYbYmYOOKYIaGZAoDHzAlwiOiLl8VeYaItBKW7EWgw l3cqPeXcBR0yLVuLgoa37cto1qIu0ySj5b81o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jNntiBQSHtydbzsb/CR7Fw1mUZyKNBf7CprplJcmUg5hrkZagRy5qZVZxkTYfLx0Zq jyVfn86iSZQ4t4kAJ3APkSvTBJGSaD9/6bi4RwGFhXpEWIhOzkCwlFJgRjEwgruJJVnn IKPOlxSrRpCw034QegEFRi5klavxNH0BiXAvE= MIME-Version: 1.0 Received: by 10.231.176.16 with SMTP id bc16mr16118628ibb.4.1278989468876; Mon, 12 Jul 2010 19:51:08 -0700 (PDT) Received: by 10.231.19.12 with HTTP; Mon, 12 Jul 2010 19:51:08 -0700 (PDT) Date: Tue, 13 Jul 2010 11:51:08 +0900 Message-ID: <AANLkTinAwGU7mr0HUibTOBJ3rgugIJxJAl5HfTIdwiuq@mail.gmail.com> From: Nat Sakimura <sakimura@gmail.com> To: oauth <oauth@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Alternative ways to pass Authorization Request Parameters X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 13 Jul 2010 02:51:02 -0000 As of -10, the Authorization Request Parameters are required to be passed as part of the Authorization Request URI query component. I would like to see it relaxed a bit so that they do not have to be a part of the URL but can be passed by reference. In the proposal that I have submit a while ago, I proposed to have 1) The parameters to be captured in JSON that can be obtained through a URL 2) Pass this URL to the end-user authorization endpoint through a parameter 'request_url' I have enumerated numerous merit of this approach and I believe we had an agreement that this would be useful from both security and usability perspective. However, as the current text is written, the parameters have to be sent as URI query component. In -10, it is written as: 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]: (parm defs) The client directs the end-user to the constructed URI using an HTTP redirection response, or by other means available to it via the end- user's user-agent. The authorization server MUST support the use of the HTTP "GET" method for the end-user authorization endpoint, and MAY support the use of the "POST" method as well. Instead I would propose something like: In order to obtain the end-user's authorization, the client sends the following parameters to the end-user authorization endpoint. (param defs) The client directs the end-user to the end-user authorization endpoint URI using an HTTP redirection response, or by other means available to it via the end-user's user-agent. The authorization server MUST support the use of the HTTP "GET" method for the end-user authorization endpoint, and MAY support the use of the "POST" method as well. The authorization server MUST support the parameters being passed as the query component using the "application/x-www-form-urlencoded" format as defined by [W3C.REC-html401-19991224]. I also have a comment on the structure of the section 3. I should have noticed this much earlier but currently the section 3 is structured as: 3. Obtaining End-User Authorization 3.1. Authorization Response 3.2. Error Response Would it not be better to be something like below? 3. Obtaining End-User Authorization 3.1. Authorization Request 3.2. Authorization Response 3.3. Error Response -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From beaton@google.com Mon Jul 12 22:36:46 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F64D3A67E1 for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 22:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.63 X-Spam-Level: X-Spam-Status: No, score=-105.63 tagged_above=-999 required=5 tests=[AWL=0.347, 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 rSIGonuAE721 for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 22:36:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 69F523A6875 for <oauth@ietf.org>; Mon, 12 Jul 2010 22:36:43 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o6D5ahD3021340 for <oauth@ietf.org>; Mon, 12 Jul 2010 22:36:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278999403; bh=GaksxviMfdZQ6QsLU2j/iYy3Dso=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=xds0QamL4FYLa8DMcAOcWbmRAhwytcwuYNBgvspP5+vRyvdYL6hm2PXNcF5Q3Eimn Q/sPrdVG83NW2Gnd5UpYQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=CnTwkQRdj2V0ff/EN5w/6P4TpmKZhOrZoXyYiWLmOU5FTJ9K4A1UX795ULMNo1POf cKOQkJUOuxRhxu5fTswHw== Received: from gwj18 (gwj18.prod.google.com [10.200.10.18]) by kpbe17.cbf.corp.google.com with ESMTP id o6D5abFQ032136 for <oauth@ietf.org>; Mon, 12 Jul 2010 22:36:43 -0700 Received: by gwj18 with SMTP id 18so2813494gwj.5 for <oauth@ietf.org>; Mon, 12 Jul 2010 22:36:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.113.9 with SMTP id l9mr5698170agc.24.1278999397392; Mon, 12 Jul 2010 22:36:37 -0700 (PDT) Received: by 10.91.216.11 with HTTP; Mon, 12 Jul 2010 22:36:37 -0700 (PDT) Date: Mon, 12 Jul 2010 22:36:37 -0700 Message-ID: <AANLkTin9GHCvTA0jQziYW3klZe78Yx1b9Op-eaxJDzEK@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 13 Jul 2010 05:36:46 -0000 Draft 10 has the following sentence in section 4.1.4: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4 "The authorization server MAY issue a new refresh token." That carries a surprising amount of baggage. I suggest removing the sentence, or changing it to MUST NOT, pending a discussion of the use cases for issuing new refresh tokens. Does anyone remember why that sentence got added to the spec? There are two reasons I can see for issuing new refresh tokens: 1) secrets are like underwear, change them frequently 2) someone has a cryptographically implemented refresh token that needs to be re-signed or re-issued I'm pretty sure anyone issuing cryptographic refresh tokens is crazy, these pretty much have to be backed by server-side state or there is no way to run your system. So I'm going to ignore that possibility, and guess that someone was interested in changing secrets... So if we want to issue new refresh tokens because we like to change secrets, we should cover: - whether existing refresh tokens are revoked. (I'd vote for MUST be revoked) - the minimum latency between issuing a new refresh token and revoking the old one. (I'd vote for minimum latency measured in hours or longer. Clients that have cached refresh tokens need to refresh their cache within this time period, or they're borked.) - the maxium latency for revoking the old token. (I'd vote for maximum latency measured in hours or days, just for security reasons. But I can't think of what would break if servers ignored this advice.) Cheers, Brian From beaton@google.com Mon Jul 12 22:39:15 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4CF73A6850 for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 22:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.647 X-Spam-Level: X-Spam-Status: No, score=-105.647 tagged_above=-999 required=5 tests=[AWL=0.330, 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 wW-JzflSI+9O for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 22:39:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 13DFE3A686B for <oauth@ietf.org>; Mon, 12 Jul 2010 22:39:13 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o6D5dLfA005809 for <oauth@ietf.org>; Mon, 12 Jul 2010 22:39:22 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278999562; bh=23vKdY73ftqryDPaKnjasFhgECY=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=Q0YXYoOh18p5kx+ZUvhNTq25MX2tbvmD/ztbQUpybDTT9VfDh9LLfuqNiB1EwhfqQ P7RgJWDrOZHnqvRf9wl7A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=ifFrQVmmz5aFx4IeaRQzg4a+MET7+apP/9UYe2qlSMekr0Bakk6gjTE3vkVh50zI4 zM5WKnoeRWUQimmzsLQHQ== Received: from gyh4 (gyh4.prod.google.com [10.243.50.196]) by hpaq3.eem.corp.google.com with ESMTP id o6D5d76h018157 for <oauth@ietf.org>; Mon, 12 Jul 2010 22:39:20 -0700 Received: by gyh4 with SMTP id 4so143293gyh.19 for <oauth@ietf.org>; Mon, 12 Jul 2010 22:39:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.101.12 with SMTP id y12mr5806796agb.116.1278999560422; Mon, 12 Jul 2010 22:39:20 -0700 (PDT) Received: by 10.91.216.11 with HTTP; Mon, 12 Jul 2010 22:39:20 -0700 (PDT) Date: Mon, 12 Jul 2010 22:39:20 -0700 Message-ID: <AANLkTimgMHM9bdEPgcu99gwVyBySM0_RTSYl9mKkmAxU@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 13 Jul 2010 05:39:15 -0000 Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5 Calling access tokens "shared symmetric secrets" is misleading, because if they are implemented well the authorization server and protected resource do not store a copy of the secret. Instead they store a one-way hash of the token. Or they verify the token cryptographically. Under no circumstances do they need to store a copy. I'd suggest the following language: "Access tokens are bearer authentication tokens or capabilities." Cheers, Brian From beaton@google.com Mon Jul 12 22:42:39 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D873A6875 for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 22:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.663 X-Spam-Level: X-Spam-Status: No, score=-105.663 tagged_above=-999 required=5 tests=[AWL=0.314, 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 xtHtZA2dThWb for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 22:42:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A64BC3A686B for <oauth@ietf.org>; Mon, 12 Jul 2010 22:42:38 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o6D5gkNs029937 for <oauth@ietf.org>; Mon, 12 Jul 2010 22:42:47 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278999767; bh=bh0U5FhZL996Q4jAq4CguPBXGuc=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=RV3owdQcZyZJbQAlgjoNL45tty6rWQgzugXMsVrj5LWngubN6yC1w8N3pwKvxdVLV hfo8A2xZShGohAG4RHx/g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=YH03iT0VGF21GiVart1cd+6BXbyJQE5nR5GrXizSeLlcntQBva3DsSNscZ9OP1oIQ chg/zjK08dOqiKtXXFy6w== Received: from yxs7 (yxs7.prod.google.com [10.190.5.135]) by kpbe18.cbf.corp.google.com with ESMTP id o6D5gj1P006526 for <oauth@ietf.org>; Mon, 12 Jul 2010 22:42:46 -0700 Received: by yxs7 with SMTP id 7so316386yxs.11 for <oauth@ietf.org>; Mon, 12 Jul 2010 22:42:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.55.7 with SMTP id d7mr10376449aga.76.1278999763939; Mon, 12 Jul 2010 22:42:43 -0700 (PDT) Received: by 10.91.216.11 with HTTP; Mon, 12 Jul 2010 22:42:43 -0700 (PDT) Date: Mon, 12 Jul 2010 22:42:43 -0700 Message-ID: <AANLkTim5PbPMoOS193rW00ULFE9jy30glx0naSgS0RLo@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] required authentication methods X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 13 Jul 2010 05:42:40 -0000 Section 5 does not appear to list any authentication method that the server is required to support: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5. How about resource servers MUST support the Authorization header and may support other methods? From beaton@google.com Mon Jul 12 22:45:33 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E40EC3A686B for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 22:45:33 -0700 (PDT) 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, 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 fRg1McYwNPHW for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 22:45:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id AA8B33A6816 for <oauth@ietf.org>; Mon, 12 Jul 2010 22:45:27 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o6D5jZOD007258 for <oauth@ietf.org>; Mon, 12 Jul 2010 22:45:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278999936; bh=jKSnZOpV2D5fgcf5jVWOburEExw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=qj+Xf1X0EcCOBJFEpo8f8Ykr4KH9sC0ZxvjJnWHr+gvqUffiBdq3G0X1kTXjNX/CW zHEARwpKWTCj43eXzBM0Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: content-type:x-system-of-record; b=vATwTzx8He6sG7jK37qd/eFTk7wcJgzNQdP09Ctx9h6m4NS2Dn1FwXmprYpvObeMn e7HqcQ1mpG9G9srlcIGAA== Received: from yxk30 (yxk30.prod.google.com [10.190.3.158]) by hpaq2.eem.corp.google.com with ESMTP id o6D5jSWh024339 for <oauth@ietf.org>; Mon, 12 Jul 2010 22:45:34 -0700 Received: by yxk30 with SMTP id 30so1107884yxk.9 for <oauth@ietf.org>; Mon, 12 Jul 2010 22:45:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.98.19 with SMTP id v19mr6632201agb.20.1278999933935; Mon, 12 Jul 2010 22:45:33 -0700 (PDT) Received: by 10.91.216.11 with HTTP; Mon, 12 Jul 2010 22:45:33 -0700 (PDT) In-Reply-To: <AANLkTim5PbPMoOS193rW00ULFE9jy30glx0naSgS0RLo@mail.gmail.com> References: <AANLkTim5PbPMoOS193rW00ULFE9jy30glx0naSgS0RLo@mail.gmail.com> Date: Mon, 12 Jul 2010 22:45:33 -0700 Message-ID: <AANLkTinWkzACFdkEnUKiJdEqP4vRm1DA2Fbo8LRglAT0@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: Re: [OAUTH-WG] required authentication methods X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 13 Jul 2010 05:45:34 -0000 Ah, never mind, this got added to draft-10 already. Thanks. On Mon, Jul 12, 2010 at 10:42 PM, Brian Eaton <beaton@google.com> wrote: > Section 5 does not appear to list any authentication method that the > server is required to support: > http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5. > > How about resource servers MUST support the Authorization header and > may support other methods? > From beaton@google.com Mon Jul 12 23:00:59 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC0D3A6816 for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 23:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.726 X-Spam-Level: X-Spam-Status: No, score=-101.726 tagged_above=-999 required=5 tests=[AWL=0.251, 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 Au8RyS56v2yd for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 23:00:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 93C423A67F1 for <oauth@ietf.org>; Mon, 12 Jul 2010 23:00:57 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o6D615Bn011782 for <oauth@ietf.org>; Mon, 12 Jul 2010 23:01:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279000865; bh=Hddwnmz2Vd+LAX7uDNmkSpp0ykg=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=SvH69lBArizXymAH3nvPWt0b52VBQP+oQE6EP6hQ0qGqpPONQI0GjUEuEf5d+GzFL 3XfsjyeY9vlWQJ4qekDtg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=abBaxyhVYdV3lLJexlKn3ey97NltpqPLehE3FdZ+gzUsCb6TPpYTljCNDjlMEkKBQ bOqD/1PJXYeBlAt4UHnUg== Received: from ywa6 (ywa6.prod.google.com [10.192.1.6]) by wpaz37.hot.corp.google.com with ESMTP id o6D6135L009010 for <oauth@ietf.org>; Mon, 12 Jul 2010 23:01:04 -0700 Received: by ywa6 with SMTP id 6so420117ywa.37 for <oauth@ietf.org>; Mon, 12 Jul 2010 23:01:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.73.18 with SMTP id v18mr9836841aga.59.1279000863628; Mon, 12 Jul 2010 23:01:03 -0700 (PDT) Received: by 10.91.216.11 with HTTP; Mon, 12 Jul 2010 23:01:02 -0700 (PDT) Date: Mon, 12 Jul 2010 23:01:02 -0700 Message-ID: <AANLkTiltWYhnXTDfhF8EekZjekM1gETJZNuJKYx1bJom@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: oauth@ietf.org, b@google.com Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] expired_token error code X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 13 Jul 2010 06:01:00 -0000 http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.2.1 The "expired_token" error code doesn't scale well and won't be implemented reliably. It should be merged with "invalid_token". Suggested language: invalid_token The access token provided is invalid. Resource servers SHOULD use this error code when receiving a token which is expired, revoked, malformed, or invalid for other reasons. The resource server MUST respond with the HTTP 401 (Unauthorized) status code. The client MAY request a new access token and retry the protected resource request. "expired_token" can't be implemented reliably for a few reasons. 1) If you're using server-side storage of tokens (which you need to do if you want to keep your tokens very short...) you have to throw away tokens after they expire. Just because you can't validate the token doesn't mean the client can't refresh the token. 2) If you're using cryptographic access tokens, you need to throw away your old token signing keys at some point. Again, just because you can't validate a token doesn't mean the client can't refresh the token. 3) One common deployment model will have limited communication between authorization servers and protected resource servers. The protected resource server might not be able to contact the authorization server to figure out whether refresh tokens are available or not. 4) The access token may not have enough information in it to look-up the corresponding refresh token and see if it's still valid. Remembering that information requires extra space in the access token for cryptographic token implementations. Space is tight. Cheers, Brian From beaton@google.com Mon Jul 12 23:22:35 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27AB3A6850 for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 23:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.69 X-Spam-Level: X-Spam-Status: No, score=-105.69 tagged_above=-999 required=5 tests=[AWL=0.287, 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 iz1FEqA5K2pA for <oauth@core3.amsl.com>; Mon, 12 Jul 2010 23:22:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A0F753A6816 for <oauth@ietf.org>; Mon, 12 Jul 2010 23:22:34 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o6D6MaDM028041 for <oauth@ietf.org>; Mon, 12 Jul 2010 23:22:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279002156; bh=WDUAtglZSZSqA+L4L84+HAF39ok=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=BvRs3qtHjkX38UKTUSov1JylqxUAy9noKVgpB7TVm33t2DeI5WtKcmihkvi8sud+f ugjv8yYiTuwqDatka2w+w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=MJsY5SJttarN/Zp2jqW2JRBiP13YpKuHcMK6T8V2Hsas81VLSU91JcUcxz1GPMdzj AI9N/QNQRIfpVe3lR63NQ== Received: from gyh4 (gyh4.prod.google.com [10.243.50.196]) by wpaz9.hot.corp.google.com with ESMTP id o6D6MZIn005268 for <oauth@ietf.org>; Mon, 12 Jul 2010 23:22:35 -0700 Received: by gyh4 with SMTP id 4so166858gyh.5 for <oauth@ietf.org>; Mon, 12 Jul 2010 23:22:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.80.4 with SMTP id d4mr9099562agb.11.1279002154848; Mon, 12 Jul 2010 23:22:34 -0700 (PDT) Received: by 10.91.216.11 with HTTP; Mon, 12 Jul 2010 23:22:34 -0700 (PDT) In-Reply-To: <C85F2547.36FD6%eran@hueniverse.com> References: <AANLkTiknyfz3PMoP1l2wLIMB3Qptq34xMYUfyHNuhGLL@mail.gmail.com> <C85F2547.36FD6%eran@hueniverse.com> Date: Mon, 12 Jul 2010 23:22:34 -0700 Message-ID: <AANLkTimcEk_sweiG0unTWegnbJNh4IkkMNiM65GGslvS@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] return to draft 6 spec org? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 13 Jul 2010 06:22:36 -0000 On Sun, Jul 11, 2010 at 7:37 AM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote: > I think the way to solve it is to make them more detailed and normative. > This will retain the general framework as current specified, but will > provide a reference-able description of useful profiles. This will also m= ake > it easier to discuss the security attributes of each profile. In addition= , > it is probably only be useful to define the user-agent and web-based as > fully specified profiles, given that the rest are not really profiles but > vague guidelines as to how to use OAuth for other =93stuff=94. Actually, the old "vague guidelines" weren't vague, and they weren't guidelines. They were very specific instructions on how flows should be implemented. They dated back to the WRAP specification, which multiple organizations reviewed carefully because they were all going to implement those flows the exact same way. The new spec has turned what used to be very precise language into mush. It's introduced confusion and security problems that weren't present originally. Please fix them. The client credentials flow is a great point of comparison. Here's dick's draft: http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.1.2 Here's draft 6: http://tools.ietf.org/html/draft-ietf-oauth-v2-06#section-2= .9.1 Here's draft 10: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-= 4.1 Dick's draft: - clear guidance on use case - obvious normative language specifying exactly one way to send a request, - one success response - one error response - normative language specifying error handling Draft 6: - vague guidance on use case - obvious normative language specifying exactly one way to send a request, - two success responses, with no way to distinguish which the server should send. But one of them is insecure. - one error response - no normative language specifying error handling Draft 10: - no guidance on use case - confusing normative language - two success responses, with no way to distinguish which the server should send. But one of them is insecure. - six different error responses (most of which don't make sense for the use case and will never be used.) - no normative language specifying error handling Cheers, Brian From lshepard@facebook.com Tue Jul 13 01:04:32 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11183A6907 for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 01:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDQKBZkm5gjU for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 01:04:31 -0700 (PDT) Received: from mx-out.facebook.com (outcampmail003.snc4.facebook.com [66.220.144.161]) by core3.amsl.com (Postfix) with ESMTP id E75F43A69A4 for <oauth@ietf.org>; Tue, 13 Jul 2010 01:04:30 -0700 (PDT) Received: from [10.129.72.186] ([10.129.72.186:46279] helo=mx-out.facebook.com) by mta005.snc4.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id 75/9B-24179-2BB1C3C4; Tue, 13 Jul 2010 00:54:26 -0700 Received: from [10.18.255.131] ([10.18.255.131:20522] helo=mail.thefacebook.com) by mta006.ash1.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 2A/66-22682-1BB1C3C4; Tue, 13 Jul 2010 00:54:26 -0700 Received: from SC-MBX05.TheFacebook.com ([fe80::e59b:c260:d8e5:3944]) by sc-hub03.TheFacebook.com ([fe80::1cfe:1f6b:8b35:cf7f%11]) with mapi; Tue, 13 Jul 2010 00:54:25 -0700 From: Luke Shepard <lshepard@facebook.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Thread-Topic: Instead of desktop apps, refer to mobile apps Thread-Index: AQHLImCcqOC5i95WVEGr4TSWLkJs5Q== Date: Tue, 13 Jul 2010 07:54:24 +0000 Message-ID: <15FC999A-7B1C-4B2F-8248-659B8531A3A8@facebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <0662a6ee-2a97-4eb2-849d-b7f88b4bb55b> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Instead of desktop apps, refer to mobile apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 13 Jul 2010 08:04:32 -0000 Minor language change request. We have seen much more demand for use of the= user-agent flow in mobile apps than in desktop apps in the past month. I t= hink that the spec should address that.=20 Instead of this: 1.4.3. Native Application Native application are clients running as native code on the end- user's computer or device (i.e. executing outside a user-agent or as a desktop program). These clients are often capable of interacting with (or embedding) the end-user's user-agent but are limited in how such interaction affects their end-user experience. In many cases, native applications are incapable of receiving direct callback requests from the server (e.g. firewall, operating system restrictions). The spec should mention that mobile applications typically qualify as opera= ting entirely in the user-agent. Going forward I think those are going to b= e way more popular and widespread than desktop apps (well, the whole concep= t of the two is blurring). From lshepard@facebook.com Tue Jul 13 01:16:28 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351F93A6A1E for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 01:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-Rl0-pnB8rK for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 01:16:27 -0700 (PDT) Received: from mx-out.facebook.com (outappmail004.snc4.facebook.com [66.220.144.158]) by core3.amsl.com (Postfix) with ESMTP id 1D1E63A69FB for <oauth@ietf.org>; Tue, 13 Jul 2010 01:16:27 -0700 (PDT) Received: from [10.129.72.184] ([10.129.72.184:61885] helo=mx-out.facebook.com) by mta001.snc4.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id 36/92-04269-E7E1C3C4; Tue, 13 Jul 2010 01:06:23 -0700 Received: from [10.18.255.121] ([10.18.255.121:26867] helo=mail.thefacebook.com) by mta004.ash1.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 7E/5C-26055-E7E1C3C4; Tue, 13 Jul 2010 01:06:22 -0700 Received: from SC-MBX05.TheFacebook.com ([fe80::e59b:c260:d8e5:3944]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Tue, 13 Jul 2010 01:06:21 -0700 From: Luke Shepard <lshepard@facebook.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Thread-Topic: [OAUTH-WG] user-agent flow needs a rewrite Thread-Index: AcsgsTNdzUBzvAJKTDKhTG0SEXY31QATP8RnAGewCIA= Date: Tue, 13 Jul 2010 08:06:19 +0000 Message-ID: <ABEF9F68-F006-4BDD-804D-DEF9CB4C1E29@facebook.com> References: <C85F1725.36FD1%eran@hueniverse.com> In-Reply-To: <C85F1725.36FD1%eran@hueniverse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_ABEF9F68F0064BDD804DDEF9CB4C1E29facebookcom_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 13 Jul 2010 08:16:28 -0000 --_000_ABEF9F68F0064BDD804DDEF9CB4C1E29facebookcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 11, 2010, at 6:37 AM, Eran Hammer-Lahav wrote: The server can=92t trust what the client is asking unless the client is aut= henticated *and* the server can trust that authentication (i.e. Client secr= et not used in a user-agent). For that, you need to establish some form of = trust with the client which in today=92s world means registration. If you a= re going to perform registration, that=92s where you should ask about the n= ature of the client so you can optimize the user experience and the overall= security. There are examples of clients that pre-register, but operate in multiple co= ntexts. For example, an app may have both a web and a mobile version, and r= equire different auth flows depending. We have found it useful to be able t= o specify in the request what type of client is making the request. I am a big fan of pre-registration but I prefer being explicit in the reque= st about what should be returned. The way I understand the Twitter use case is that the client isn=92t just a= user-agent trying to get both an access token and authorization code (or r= efresh token), but a more complex client which includes both a user-agent a= nd web-based components, each providing a different functionality, but both= using the same, single end-user authorization (i.e. The end-user is asked = once). Facebook also really wants this. And we'd like to be able to return the ver= ification code in the fragment. I just read this bit: If the response type is "code_and_token", the authorization server adds the "code" and "state" parameters to the redirection URI query component and the "access_token", "scope", and "expires_in" to the redirection URI fragment using the "application/x-www-form-urlencoded" format as defined by That strikes me as very odd - returning some params in the query, and other= s in the fragment is just weird. I think the request should specify whether= it wants the response in the fragment or query. There are a few ways to do= this: 1/ Use a 'type' param, and define the response format along with the type (= for instance, user-agent means it's returned in the fragment) 2/ If the user requests either token or code_and_token, then the response c= omes in the fragment. Else, in the url. 3/ Create another parameter to specify how the response should come. My preference is for #1, but I know you've tried to wrangle the spec and de= cided not to - and that seems fine. So then I would prefer #2. --_000_ABEF9F68F0064BDD804DDEF9CB4C1E29facebookcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <a9e4ac9a-ff16-4007-ad27-ab0d6bbc6734> Content-Transfer-Encoding: quoted-printable <html><head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space;= -webkit-line-break: after-white-space; "><br><div><div>On Jul 11, 2010, at= 6:37 AM, Eran Hammer-Lahav wrote:</div><div><br></div><blockquote type=3D"= cite"><div><font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D= "font-size:11pt"> The server can=92t trust what the client is asking unless the client is aut= henticated *and* the server can trust that authentication (i.e. Client secr= et not used in a user-agent). For that, you need to establish some form of = trust with the client which in today=92s world means registration. If you a= re going to perform registration, that=92s where you should ask about the n= ature of the client so you can optimize the user experience and the overall= security.<br></span></font></div></blockquote><div><br></div><div>There ar= e examples of clients that pre-register, but operate in multiple contexts. = For example, an app may have both a web and a mobile version, and require d= ifferent auth flows depending. We have found it useful to be able to specif= y in the request what type of client is making the request.</div><div><br><= /div><div>I am a big fan of pre-registration but I prefer being explicit in= the request about what should be returned.</div><br><blockquote type=3D"ci= te"><div><font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"f= ont-size:11pt"> The way I understand the Twitter use case is that the client isn=92t just a= user-agent trying to get both an access token and authorization code (or r= efresh token), but a more complex client which includes both a user-agent a= nd web-based components, each providing a different functionality, but both= using the same, single end-user authorization (i.e. The end-user is asked = once).<br></span></font></div></blockquote><div><br></div><div>Facebook als= o really wants this. And we'd like to be able to return the verification co= de in the fragment.</div><div><br></div><div>I just read this bit:</div><di= v><br></div><div><div>   If the response type is "code_and_t= oken", the authorization server</div><div>   adds the "= code" and "state" parameters to the redirection URI query</d= iv><div>   component and the "access_token", "scop= e", and "expires_in" to the</div><div>   redirecti= on URI fragment using the</div><div>   "application/x-www-fo= rm-urlencoded" format as defined by</div></div><div><br></div><div>Tha= t strikes me as very odd - returning some params in the query, and others i= n the fragment is just weird. I think the request should specify whether it= wants the response in the fragment or query. There are a few ways to do th= is:</div><div><br></div><div>1/ Use a 'type' param, and define the response= format along with the type (for instance, user-agent means it's returned i= n the fragment)</div><div>2/ If the user requests either token or code_and_= token, then the response comes in the fragment. Else, in the url.</div><div= >3/ Create another parameter to specify how the response should come.</div>= <div><br></div><div>My preference is for #1, but I know you've tried to wra= ngle the spec and decided not to - and that seems fine. So then I would pre= fer #2.</div><div><br></div></div></body></html>= --_000_ABEF9F68F0064BDD804DDEF9CB4C1E29facebookcom_-- From jricher@mitre.org Tue Jul 13 05:28:30 2010 Return-Path: <jricher@mitre.org> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369253A6919 for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 05:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 8aB0S9U9-lMU for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 05:28:29 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 3DF933A69DD for <oauth@ietf.org>; Tue, 13 Jul 2010 05:28:29 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6DCSb4s020675 for <oauth@ietf.org>; Tue, 13 Jul 2010 08:28:37 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6DCSaZm020672; Tue, 13 Jul 2010 08:28:36 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Tue, 13 Jul 2010 08:28:37 -0400 From: "Richer, Justin P." <jricher@mitre.org> To: David Recordon <recordond@gmail.com> Date: Tue, 13 Jul 2010 08:28:35 -0400 Thread-Topic: [OAUTH-WG] Moving the User Experience Extension draft forward Thread-Index: Acsh+5kCqXCJQQgHTvqJd6AGP/0EGgAic5Ud Message-ID: <D24C564ACEAD16459EF2526E1D7D605D0C9E7F3570@IMCMBX3.MITRE.ORG> References: <AANLkTilytBoccLsTExf8M8qT5PIT4mjeZxfI7N0Rn-LU@mail.gmail.com> In-Reply-To: <AANLkTilytBoccLsTExf8M8qT5PIT4mjeZxfI7N0Rn-LU@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 13 Jul 2010 12:28:30 -0000 I'd like to propose the addition of two more optional parameters to this ex= tension: instance_name Short, human-readable name that the server SHOULD display to=20 the end-user along with the client name. This name is designed=20 to reflect a per-instance identifier for cases where a single user=20 may authorize multiple copies of a single identified client. The=20 server MAY [SHOULD?] store this information along with its=20 associated access grant to allow the end-user to differentiate=20 between instances of the application in the future (for example, to revoke access tokens). instance_description A longer, human-readable description that the server MAY display to=20 the end-user along with the client name. This description is designed=20 as the name above to reflect a per-instance identifier for cases where=20 a single user may authorize multiple copies of a single identified clien= t. The=20 server MAY [SHOULD?] store this information along with its=20 associated access grant to allow the end-user to differentiate=20 between instances of the application in the future (for example, to revoke access tokens). If a client presents the instance_description, it MUST also present an instance_name. This can be thought of as the new way of Google's xoauth_display_name param= eter. We have a direct use case for this, and it seems like it would fit in= the UX more than its own extension. There was also talk of sending a client-information URL to get more stuff a= bout the client and instances of it, but that seems a better fit for the im= pending discovery spec, to me, as it seems to address full client informati= on and not per-instance information that this is talking about. -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of David Re= cordon [recordond@gmail.com] Sent: Monday, July 12, 2010 3:51 PM To: OAuth WG Subject: [OAUTH-WG] Moving the User Experience Extension draft forward I wrote this draft last month based on discussions on the mailing list, the= OpenID user experience extension (which Facebook, Google, and Yahoo! have = deployed), and some OAuth 2.0 implementation experience from Facebook. It d= efines language and display preferences which the client can include in req= uests to the end-user authorization endpoint. A previous draft included an immediate mode parameter but further discussio= n has shown that it should be removed until identity information is also ad= dressed. Identity is outside the scope of this particular extension. I'd like this draft to become a working group document and have done my bes= t to make it represent the group's consensus. Unfortunately the internet dr= aft submission process is closed for a few weeks until after the meeting. := -\ Thanks, --David From eran@hueniverse.com Tue Jul 13 07:04:13 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080933A67D3 for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 07:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 a8zkh5oOHp+K for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 07:04:11 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id CF2DA3A65A6 for <oauth@ietf.org>; Tue, 13 Jul 2010 07:04:11 -0700 (PDT) Received: (qmail 4758 invoked from network); 13 Jul 2010 14:04:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 14:04:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 13 Jul 2010 07:04:15 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Brian Eaton <beaton@google.com>, OAuth WG <oauth@ietf.org> Date: Tue, 13 Jul 2010 07:04:11 -0700 Thread-Topic: [OAUTH-WG] issuing new refresh tokens Thread-Index: AcsiTZ0q/6T6YchhSUiSsBBWIbQk9gARqdU9 Message-ID: <C861C06B.37142%eran@hueniverse.com> In-Reply-To: <AANLkTin9GHCvTA0jQziYW3klZe78Yx1b9Op-eaxJDzEK@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 13 Jul 2010 14:04:13 -0000 On 7/12/10 10:36 PM, "Brian Eaton" <beaton@google.com> wrote: > Draft 10 has the following sentence in section 4.1.4: > http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4 >=20 > "The authorization server MAY issue a new refresh token." The capability was there since -02. -04 added the following text in an attempt to clarify how the refresh_token output can be used (returning a refresh token was briefly discussed as part of the general idea of always allowing a refresh token in token responses): The authorization server MAY issue a new refresh token in which case the client MUST NOT use the previous refresh token and replace it with the newly issued refresh token. In -10 I dropped the restriction because people expressed a general issue with having to revoke tokens. > That carries a surprising amount of baggage. I suggest removing the > sentence, or changing it to MUST NOT, pending a discussion of the use > cases for issuing new refresh tokens. >=20 > Does anyone remember why that sentence got added to the spec? >=20 > There are two reasons I can see for issuing new refresh tokens: > 1) secrets are like underwear, change them frequently > 2) someone has a cryptographically implemented refresh token that > needs to be re-signed or re-issued >=20 > I'm pretty sure anyone issuing cryptographic refresh tokens is crazy, > these pretty much have to be backed by server-side state or there is > no way to run your system. So I'm going to ignore that possibility, > and guess that someone was interested in changing secrets... There was no requirement to support changing refresh tokens. If there is no interest in this, I suggest we forbid it (otherwise all clients will need t= o accommodate the chance of a new refresh token, and then will need guideline= s on how to handle it). > So if we want to issue new refresh tokens because we like to change > secrets, we should cover: > - whether existing refresh tokens are revoked. (I'd vote for MUST be rev= oked) I agree. > - the minimum latency between issuing a new refresh token and revoking > the old one. (I'd vote for minimum latency measured in hours or > longer. Clients that have cached refresh tokens need to refresh their > cache within this time period, or they're borked.) > - the maxium latency for revoking the old token. (I'd vote for > maximum latency measured in hours or days, just for security reasons. > But I can't think of what would break if servers ignored this advice.) Why is this required? Can it be specified as a general recommendation? EHL > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Tue Jul 13 07:18:50 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7B33A67AC for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 07:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 rsAZfAkXJpgP for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 07:18:49 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 413963A676A for <oauth@ietf.org>; Tue, 13 Jul 2010 07:18:48 -0700 (PDT) Received: (qmail 17683 invoked from network); 13 Jul 2010 14:18:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 14:18:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 13 Jul 2010 07:18:48 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Brian Eaton <beaton@google.com>, OAuth WG <oauth@ietf.org> Date: Tue, 13 Jul 2010 07:18:44 -0700 Thread-Topic: [OAUTH-WG] "shared symmetric secret" Thread-Index: AcsiTcH/q/87788lTIKwa6cnckR+XQASIrbm Message-ID: <C861C3D4.37148%eran@hueniverse.com> In-Reply-To: <AANLkTimgMHM9bdEPgcu99gwVyBySM0_RTSYl9mKkmAxU@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 13 Jul 2010 14:18:50 -0000 >From the client's perspective, they are 'shared symmetric secrets' because the client has to store them as-is and present them as-is. The act exactly like passwords. I added that text to make that stand out. When using passwords, the server doesn't need to store them in plain-text either (e.g. uses a way one hash). I would like the specification to make it clear that bearer tokens are only secure while they remain *secret* and that *anyone* holding them can gain full access to what their protect. EHL On 7/12/10 10:39 PM, "Brian Eaton" <beaton@google.com> wrote: > Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5 >=20 > Calling access tokens "shared symmetric secrets" is misleading, > because if they are implemented well the authorization server and > protected resource do not store a copy of the secret. >=20 > Instead they store a one-way hash of the token. Or they verify the > token cryptographically. Under no circumstances do they need to store > a copy. >=20 > I'd suggest the following language: >=20 > "Access tokens are bearer authentication tokens or capabilities." >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Tue Jul 13 07:20:37 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3483A676A for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 07:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.157, 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 v6i+TNllmVrn for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 07:20:34 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 38B1E3A67AC for <oauth@ietf.org>; Tue, 13 Jul 2010 07:20:34 -0700 (PDT) Received: (qmail 18878 invoked from network); 13 Jul 2010 14:20:43 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 14:20:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 13 Jul 2010 07:20:43 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Brian Eaton <beaton@google.com>, OAuth WG <oauth@ietf.org>, "b@google.com" <b@google.com> Date: Tue, 13 Jul 2010 07:20:39 -0700 Thread-Topic: [OAUTH-WG] expired_token error code Thread-Index: AcsiUMwJ2a6PtfxDTWCpfid8P4tomAARcVeq Message-ID: <C861C447.3714A%eran@hueniverse.com> In-Reply-To: <AANLkTiltWYhnXTDfhF8EekZjekM1gETJZNuJKYx1bJom@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C861C4473714Aeranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] expired_token error code X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 13 Jul 2010 14:20:37 -0000 --_000_C861C4473714Aeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm fine with this. Any objections? EHL On 7/12/10 11:01 PM, "Brian Eaton" <beaton@google.com> wrote: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.2.1 The "expired_token" error code doesn't scale well and won't be implemented reliably. It should be merged with "invalid_token". Suggested language: invalid_token The access token provided is invalid. Resource servers SHOULD use this error code when receiving a token which is expired, revoked, malformed, or invalid for other reasons. The resource server MUST respond with the HTTP 401 (Unauthorized) status code. The client MAY request a new access token and retry the protected resource request. "expired_token" can't be implemented reliably for a few reasons. 1) If you're using server-side storage of tokens (which you need to do if you want to keep your tokens very short...) you have to throw away tokens after they expire. Just because you can't validate the token doesn't mean the client can't refresh the token. 2) If you're using cryptographic access tokens, you need to throw away your old token signing keys at some point. Again, just because you can't validate a token doesn't mean the client can't refresh the token. 3) One common deployment model will have limited communication between authorization servers and protected resource servers. The protected resource server might not be able to contact the authorization server to figure out whether refresh tokens are available or not. 4) The access token may not have enough information in it to look-up the corresponding refresh token and see if it's still valid. Remembering that information requires extra space in the access token for cryptographic token implementations. Space is tight. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C861C4473714Aeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [OAUTH-WG] expired_token error code I’m fine with this. Any objections?

EHL


On 7/12/10 11:01 PM, "Brian Eaton" <beaton@google.com> wrote:

http://tools.ietf.org/html/draft-ietf-oaut= h-v2-10#section-5.2.1

The "expired_token" error code doesn't scale well and won't be implemented reliably.  It should be merged with "invalid_token&qu= ot;.

Suggested language:

invalid_token
         The access token prov= ided is invalid.  Resource servers
SHOULD use this error code when receiving a token which is expired,
revoked, malformed, or invalid for other reasons.  The resource server=
MUST respond with the HTTP 401 (Unauthorized) status code.  The client=
MAY request a new access token and retry the protected resource
request.


"expired_token" can't be implemented reliably for a few reasons.<= BR>
1) If you're using server-side storage of tokens (which you need to do
if you want to keep your tokens very short...) you have to throw away
tokens after they expire.  Just because you can't validate the token doesn't mean the client can't refresh the token.

2) If you're using cryptographic access tokens, you need to throw away
your old token signing keys at some point.  Again, just because you can't validate a token doesn't mean the client can't refresh the
token.

3) One common deployment model will have limited communication between
authorization servers and protected resource servers.  The protected resource server might not be able to contact the authorization server
to figure out whether refresh tokens are available or not.

4) The access token may not have enough information in it to look-up
the corresponding refresh token and see if it's still valid.
Remembering that information requires extra space in the access token
for cryptographic token implementations.  Space is tight.

Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C861C4473714Aeranhueniversecom_-- From eran@hueniverse.com Tue Jul 13 08:11: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 5DA773A6A49 for ; Tue, 13 Jul 2010 08:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ajoyu4HB0IIy for ; Tue, 13 Jul 2010 08:11:16 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 348CD3A6A4C for ; Tue, 13 Jul 2010 08:11:12 -0700 (PDT) Received: (qmail 30936 invoked from network); 13 Jul 2010 15:11:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 15:11:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 13 Jul 2010 08:11:19 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Tue, 13 Jul 2010 08:11:15 -0700 Thread-Topic: [OAUTH-WG] return to draft 6 spec org? Thread-Index: AcsiU8rSpA7WLI38TJGS0lTKlE6utwASdgsy Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] return to draft 6 spec org? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 15:11:18 -0000 On 7/12/10 11:22 PM, "Brian Eaton" wrote: > On Sun, Jul 11, 2010 at 7:37 AM, Eran Hammer-Lahav > wrote: >> I think the way to solve it is to make them more detailed and normative. >> This will retain the general framework as current specified, but will >> provide a reference-able description of useful profiles. This will also = make >> it easier to discuss the security attributes of each profile. In additio= n, >> it is probably only be useful to define the user-agent and web-based as >> fully specified profiles, given that the rest are not really profiles bu= t >> vague guidelines as to how to use OAuth for other =B3stuff=B2. >=20 > Actually, the old "vague guidelines" weren't vague, and they weren't > guidelines. They were very specific instructions on how flows should > be implemented. They dated back to the WRAP specification, which > multiple organizations reviewed carefully because they were all going > to implement those flows the exact same way. I used 'vague guidelines' to described the information provided for *when* to use the flows, not *how* to use them. - user-agent and web-server are suitable for clients other than just code running in a browser or on a web-server, as made clear by the native application text. - assertion flow was always underspecified (for a reason) and provided little to no useful information on when it should be used - it assumed people who currently use SAML or similar assertions will just "know what to do". This isn't very helpful to new readers. - client credentials information was always problematic because people expressed interest in using it with pre-arranged authorizations, in which case, the client may be acting on behalf of an end-user. - username and password is really the only straightforward flow because it doesn't specify any client type, but only client conditions. However, this is the one profile I'd like to make less prominent. - device was removed (at your request) due to lack of deployment experience= . > The new spec has turned what used to be very precise language into > mush. It's introduced confusion and security problems that weren't > present originally. Please fix them. You keep saying that (very dramatically!). However, you offer very little details for these "security problems" and "confusion". I have addressed every specific issue you raised. I suggested adding actual profiles to the spec, which would accomplish what your want to see "restored". However it is not clear to me how to name thes= e and how to guide developers when to use them. We have been unable to reach agreement on these guidelines for months because everyone has other plans for how they plan to use it (user-agent flow for mobile device as native app, client credentials for pre-arranged delegation, assertions for both client only and end-user resources, web server for in-browser). > The client credentials flow is a great point of comparison. >=20 > Here's dick's draft: > http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.1.2 This profile is suitable when the Client is an application calling the Protected Resource on behalf of an organization and the Authorization Server accepts account passwords for authentication. This enables the Authorization Server to use an existing authentication mechanism. This profile SHOULD NOT be used when the Client is acting on behalf of a user. I don't know what this mean. What is an 'organization' (it is the only time the term is used)? What is the difference between an 'organization' and 'end-user'? Why can't this be used for end-user delegation when it is pre-arranged, just like the assertion profile? After all, basic client credentials are nothing more than one special case assertion. > Here's draft 6:=20 > http://tools.ietf.org/html/draft-ietf-oauth-v2-06#section-2.9.1 The client credentials flow is used when the client acts on behalf of itself (the client is the resource owner), or when the client credentials are used to obtain an access token representing a previously established access authorization. The client secret is assumed to be high-entropy since it is not designed to be memorized by an end-user. This is my attempt to represent the group's consensus on when this flow should be used. Previous text limiting it to only "client acts on behalf of itself" were rejected. > Here's draft 10: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#sectio= n-4.1 When requesting an access token using the "none" access grant type (no access grant is included), the client is requesting access to the protected resources under its control, or those of another resource owner which has been previously arranged with the authorization server (the method of which is beyond the scope of this specification). This says the same thing as -06 but from the flip side (what 'none' means instead of describing the use case). However, the introduction includes additional information in section 1.4.4 which is where the client crendetia= l text ended up. http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-1.4.4 Autonomous clients utilize an existing trust relationship or framework to establish authorization. Autonomous clients can be implemented in different ways based on their requirements and the existing trust framework they rely upon. Autonomous clients can: o Obtain an access token by authenticating with the authorization server using their client credentials. The scope of the access token is limited to the protected resources under the control of the client, or that of another resource owner previously arranged with the authorization server. The reason why it is combined with the assertion profile is because I could not come up with any text to really differentiate their user-cases (as I said before, client secret is just a special case assertion). > Dick's draft: > - clear guidance on use case > - obvious normative language specifying exactly one way to send a request= , > - one success response > - one error response > - normative language specifying error handling >=20 > Draft 6: > - vague guidance on use case > - obvious normative language specifying exactly one way to send a request= , > - two success responses, with no way to distinguish which the server > should send. But one of them is insecure. > - one error response > - no normative language specifying error handling >=20 > Draft 10: > - no guidance on use case Section 1.4.4. > - confusing normative language Use 'none'. Seems pretty straightforward. > - two success responses, with no way to distinguish which the server > should send. But one of them is insecure. Where? One in 4.2, where is the other? > - six different error responses (most of which don't make sense for > the use case and will never be used.) Relevant: invalid_request - request sent incorrectly invalid_client - bad client credentials unauthorized_client - client is not allowed to use this profile unsupported_grant_type - server doesn't support this profile invalid_scope - client (explicitly) asked for invalid scope Irrelevant: invalid_grant > - no normative language specifying error handling Section 4.3. --- I'll move the second paragraph of 4.1 into its own section. That will help those looking for the "normative language for client credentials". EHL From eran@hueniverse.com Tue Jul 13 08:18: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 686EE3A67E7 for ; Tue, 13 Jul 2010 08:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.151, 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 mVmXrtPk+mes for ; Tue, 13 Jul 2010 08:18:29 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id C02563A68DD for ; Tue, 13 Jul 2010 08:18:26 -0700 (PDT) Received: (qmail 9933 invoked from network); 13 Jul 2010 15:18:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 15:18:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 13 Jul 2010 08:18:30 -0700 From: Eran Hammer-Lahav To: Luke Shepard , OAuth WG Date: Tue, 13 Jul 2010 08:18:27 -0700 Thread-Topic: [OAUTH-WG] Instead of desktop apps, refer to mobile apps Thread-Index: AQHLImCcqOC5i95WVEGr4TSWLkJs5ZKu+IeX Message-ID: In-Reply-To: <15FC999A-7B1C-4B2F-8248-659B8531A3A8@facebook.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C861D1D337153eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Instead of desktop apps, refer to mobile apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 15:18:34 -0000 --_000_C861D1D337153eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think the profiles section is mostly useless in helping developers pick t= he right profile unless they are clearly a JS browser client or a client ru= nning on a well-protected web server. We have blurred the lines so much in = when each profile should/could be used, that a new reader will be lost. The only way I can come up with to fix this is to move the user-agent and w= eb-server profiles into new normative sections (with new names that don't i= mply client type), and to use the introduction to discuss how different use= cases can be addressed by profiling the generic framework. I'll try that before -11 in my public sandbox. EHL On 7/13/10 12:54 AM, "Luke Shepard" wrote: Minor language change request. We have seen much more demand for use of the= user-agent flow in mobile apps than in desktop apps in the past month. I t= hink that the spec should address that. Instead of this: 1.4.3. Native Application Native application are clients running as native code on the end- user's computer or device (i.e. executing outside a user-agent or as a desktop program). These clients are often capable of interacting with (or embedding) the end-user's user-agent but are limited in how such interaction affects their end-user experience. In many cases, native applications are incapable of receiving direct callback requests from the server (e.g. firewall, operating system restrictions). The spec should mention that mobile applications typically qualify as opera= ting entirely in the user-agent. Going forward I think those are going to b= e way more popular and widespread than desktop apps (well, the whole concep= t of the two is blurring). _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C861D1D337153eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Instead of desktop apps, refer to mobile apps I think the profiles section is mostly useless in helping developers = pick the right profile unless they are clearly a JS browser client or a cli= ent running on a well-protected web server. We have blurred the lines so mu= ch in when each profile should/could be used, that a new reader will be los= t.

The only way I can come up with to fix this is to move the user-agent and w= eb-server profiles into new normative sections (with new names that donR= 17;t imply client type), and to use the introduction to discuss how differe= nt use cases can be addressed by profiling the generic framework.

I’ll try that before –11 in my public sandbox.

EHL


On 7/13/10 12:54 AM, "Luke Shepard" <lshepard@facebook.com> wrote:

Minor language change request. We have seen= much more demand for use of the user-agent flow in mobile apps than in des= ktop apps in the past month. I think that the spec should address that.

Instead of this:

1.4.3.  Native Application


   Native application are clients running as native code on = the end-
   user's computer or device (i.e. executing outside a user-= agent or as
   a desktop program).  These clients are often capable= of interacting
   with (or embedding) the end-user's user-agent but are lim= ited in how
   such interaction affects their end-user experience.  = ;In many cases,
   native applications are incapable of receiving direct cal= lback
   requests from the server (e.g. firewall, operating system=
   restrictions).

The spec should mention that mobile applications typically qualify as opera= ting entirely in the user-agent. Going forward I think those are going to b= e way more popular and widespread than desktop apps (well, the whole concep= t of the two is blurring).

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

--_000_C861D1D337153eranhueniversecom_-- From darren@cliqset.com Tue Jul 13 08:34:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C533C3A6A50 for ; Tue, 13 Jul 2010 08:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoQWPWNVsx-7 for ; Tue, 13 Jul 2010 08:34:43 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id CBEEB3A6A82 for ; Tue, 13 Jul 2010 08:34:41 -0700 (PDT) Received: by gwj19 with SMTP id 19so1111617gwj.31 for ; Tue, 13 Jul 2010 08:34:47 -0700 (PDT) Received: by 10.100.136.3 with SMTP id j3mr1194972and.33.1279035287395; Tue, 13 Jul 2010 08:34:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.34.11 with HTTP; Tue, 13 Jul 2010 08:34:27 -0700 (PDT) In-Reply-To: References: From: Darren Bounds Date: Tue, 13 Jul 2010 11:34:27 -0400 Message-ID: To: Brian Eaton Content-Type: multipart/alternative; boundary=0016e64088a0f5df82048b469bee Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] return to draft 6 spec org? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 15:34:45 -0000 --0016e64088a0f5df82048b469bee Content-Type: text/plain; charset=UTF-8 +1 On Sun, Jul 11, 2010 at 12:15 AM, Brian Eaton wrote: > I think it would be a good idea to return to the draft 6 organization. > > Draft 6: normative language for each flow was called out separately, > and was described from start to finish, in chronological order, with > no interruption. Each step showed what a client should send, and what > an authorization server should return. > > Draft 7 and further: flows are merged to reuse spec language. Steps > for any given use case are now interrupted with steps for other use > cases. > > For example, consider a client developer who wants to implement the > web server flow. > > First they have to read section 3.1, to describe the redirect they > need to send to the authorization server. > > Then they read section 3.2, to see the redirect back. > > Then they read section 4.1.1, to see the request they send to the > authorization server. > > Then they skip a few pages, because they don't care about assertions > or passwords or refresh tokens. > > They they read section 4.2, to see the response from the authorization > server. > > Then they skip several more pages to get to section 5, so they can access > data. > > Then they skip back to section 4.1.4, because they need to refresh their > token. > > > Compare this to draft 6: > - read section 2.5 > this is everything you need to get a token, with no intervening > cruft about credentials you don't have. > > - read section 4 > this is everything you need to use a token. > > - read section 3 > this is everything you need to refresh a token. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- darren bounds darren@cliqset.com --0016e64088a0f5df82048b469bee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1

On Sun, Jul 11, 2010 at 12:15 AM, Bri= an Eaton <beaton@= google.com> wrote:
I think it would be a good idea to return to the draft 6 organization.

Draft 6: normative language for each flow was called out separately,
and was described from start to finish, in chronological order, with
no interruption. =C2=A0Each step showed what a client should send, and what=
an authorization server should return.

Draft 7 and further: flows are merged to reuse spec language. =C2=A0Steps for any given use case are now interrupted with steps for other use
cases.

For example, consider a client developer who wants to implement the
web server flow.

First they have to read section 3.1, to describe the redirect they
need to send to the authorization server.

Then they read section 3.2, to see the redirect back.

Then they read section 4.1.1, to see the request they send to the
authorization server.

Then they skip a few pages, because they don't care about assertions or passwords or refresh tokens.

They they read section 4.2, to see the response from the authorization serv= er.

Then they skip several more pages to get to section 5, so they can access d= ata.

Then they skip back to section 4.1.4, because they need to refresh their to= ken.


Compare this to draft 6:
- read section 2.5
=C2=A0 this is everything you need to get a token, with no intervening
cruft about credentials you don't have.

- read section 4
=C2=A0 this is everything you need to use a token.

- read section 3
=C2=A0 this is everything you need to refresh a token.

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



--
darren bounds
darren@cliqset.com


--0016e64088a0f5df82048b469bee-- From eran@hueniverse.com Tue Jul 13 08:39: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 CD6A13A6848 for ; Tue, 13 Jul 2010 08:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 Gr7mjMJmK7kt for ; Tue, 13 Jul 2010 08:39:02 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5476F3A6870 for ; Tue, 13 Jul 2010 08:39:02 -0700 (PDT) Received: (qmail 29046 invoked from network); 13 Jul 2010 15:32:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 15:32:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 13 Jul 2010 08:32:29 -0700 From: Eran Hammer-Lahav To: Luke Shepard Date: Tue, 13 Jul 2010 08:32:24 -0700 Thread-Topic: [OAUTH-WG] user-agent flow needs a rewrite Thread-Index: AcsgsTNdzUBzvAJKTDKhTG0SEXY31QATP8RnAGewCIAAAOk0zQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 15:39:03 -0000 On 7/13/10 1:06 AM, "Luke Shepard" wrote: >=20 > On Jul 11, 2010, at 6:37 AM, Eran Hammer-Lahav wrote: >=20 >> The server can=B9t trust what the client is asking unless the client is >> authenticated *and* the server can trust that authentication (i.e. Clien= t >> secret not used in a user-agent). For that, you need to establish some f= orm >> of trust with the client which in today=B9s world means registration. If= you >> are going to perform registration, that=B9s where you should ask about t= he >> nature of the client so you can optimize the user experience and the ove= rall >> security. >=20 > There are examples of clients that pre-register, but operate in multiple > contexts. For example, an app may have both a web and a mobile version, a= nd > require different auth flows depending. We have found it useful to be abl= e to > specify in the request what type of client is making the request. The same client credentials should not be used in two different environment where the security considerations are fundamentally different. For example, the same client identifier and secret should not be used by a user-agent an= d web-server to exchange an authorization code. > I am a big fan of pre-registration but I prefer being explicit in the req= uest > about what should be returned. Only when it serves an actual function (i.e. How to return parameters, whic= h parameters to return). Not for enforcing a security policy (that would be silly and insecure). >> The way I understand the Twitter use case is that the client isn=B9t jus= t a >> user-agent trying to get both an access token and authorization code (or >> refresh token), but a more complex client which includes both a user-age= nt >> and web-based components, each providing a different functionality, but = both >> using the same, single end-user authorization (i.e. The end-user is aske= d >> once). >=20 > Facebook also really wants this. And we'd like to be able to return the > verification code in the fragment. How is the client going to exchange this for an access token? > I just read this bit: >=20 > If the response type is "code_and_token", the authorization server > adds the "code" and "state" parameters to the redirection URI query > component and the "access_token", "scope", and "expires_in" to the > redirection URI fragment using the > "application/x-www-form-urlencoded" format as defined by >=20 > That strikes me as very odd - returning some params in the query, and oth= ers > in the fragment is just weird. I think the request should specify whether= it > wants the response in the fragment or query. There are a few ways to do t= his: >=20 > 1/ Use a 'type' param, and define the response format along with the type= (for > instance, user-agent means it's returned in the fragment) I have no problem with a response format request parameter, but I am not sure what the purpose is (other than making it look less odd :-)). The current text is based on the assumption that the user-agent is never going to directly use the authorization code (because that requires it to have access to the client credentials and if that is the case, it can just use the web-server profile). > 2/ If the user requests either token or code_and_token, then the response > comes in the fragment. Else, in the url. This forces the client to make another call to the server (not covered by the redirection call which is the obvious place to handle this) to hand ove= r the authorization code. Again, if the client itself is exchanging the code, what's the point? > 3/ Create another parameter to specify how the response should come. >=20 > My preference is for #1, but I know you've tried to wrangle the spec and > decided not to - and that seems fine. So then I would prefer #2. Any decision made is open for debate. My takeaway from this is that we clearly don't have a well-understood use case. My understanding is that at the end of this hybrid mode, the user-agent ends with one access token, and the web-server ends with another access token. Neither side sees the access token issues to the other side (which allows granting different access levels based on the level of client authentication), and the user-agent never has access to the client credentials. EHL From igor.faynberg@alcatel-lucent.com Tue Jul 13 08:45: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 2054E3A6848 for ; Tue, 13 Jul 2010 08:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 SlVMQEZ0RllI for ; Tue, 13 Jul 2010 08:45:09 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 31BAB3A6A30 for ; Tue, 13 Jul 2010 08:45:09 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o6DFjCti020903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jul 2010 10:45:12 -0500 (CDT) Received: from [135.244.39.28] (faynberg.lra.lucent.com [135.244.39.28]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o6DFjBhY016739; Tue, 13 Jul 2010 10:45:12 -0500 (CDT) Message-ID: <4C3C8A08.40103@alcatel-lucent.com> Date: Tue, 13 Jul 2010 11:45:12 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" 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: Tue, 13 Jul 2010 15:45:10 -0000 I tend to agree with Eran, although it should be qualified that a token is BASED on a shared secret, rather than is a shared secret itself. (By the way, I think the word "symmetric" is redundant here.). I also think that the text in the Security Considerations must contain the last paragraph of Eran's message. Probably the recommendation not to store the token on the server, along with the suggestion of storing the hash should also be in place. Igor Eran Hammer-Lahav wrote: > >From the client's perspective, they are 'shared symmetric secrets' because > the client has to store them as-is and present them as-is. The act exactly > like passwords. I added that text to make that stand out. > > When using passwords, the server doesn't need to store them in plain-text > either (e.g. uses a way one hash). > > I would like the specification to make it clear that bearer tokens are only > secure while they remain *secret* and that *anyone* holding them can gain > full access to what their protect. > > EHL > > On 7/12/10 10:39 PM, "Brian Eaton" wrote: > > >> Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5 >> >> Calling access tokens "shared symmetric secrets" is misleading, >> because if they are implemented well the authorization server and >> protected resource do not store a copy of the secret. >> >> Instead they store a one-way hash of the token. Or they verify the >> token cryptographically. Under no circumstances do they need to store >> a copy. >> >> I'd suggest the following language: >> >> "Access tokens are bearer authentication tokens or capabilities." >> >> Cheers, >> Brian >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From balfanz@google.com Tue Jul 13 08: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 D9FE13A67D3 for ; Tue, 13 Jul 2010 08:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXDZhNyvVr+j for ; Tue, 13 Jul 2010 08:55:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 814CA3A6848 for ; Tue, 13 Jul 2010 08:55:52 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id o6DFu0WQ031062 for ; Tue, 13 Jul 2010 08:56:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279036560; bh=ovjRXD+0OzpatBrbMEG8fJj8AqI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=u327ct7geQf6pyusVk9YPYsn/96/Hi400bhdtDOeXgt1QsHwe4ieGuv081/D5LsFX ePSOSx6h/QOTdP6mIgPkg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=yV5nvejWMMhJnZTw/H+pkifx9Yze9CGCu7fcD4BOOScZyJpHckD4pse3CBrFlRYtw ByHphg1Dfn1MUppx7Lqug== Received: from iwn39 (iwn39.prod.google.com [10.241.68.103]) by hpaq11.eem.corp.google.com with ESMTP id o6DFtxJl020218 for ; Tue, 13 Jul 2010 08:55:59 -0700 Received: by iwn39 with SMTP id 39so5860351iwn.10 for ; Tue, 13 Jul 2010 08:55:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.13.199 with SMTP id d7mr16463461iba.167.1279036557288; Tue, 13 Jul 2010 08:55:57 -0700 (PDT) Received: by 10.231.130.9 with HTTP; Tue, 13 Jul 2010 08:55:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 08:55:57 -0700 Message-ID: From: Dirk Balfanz To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00235452eebca73b82048b46e755 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 15:55:54 -0000 --00235452eebca73b82048b46e755 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav wrote: > From the client's perspective, they are 'shared symmetric secrets' because > the client has to store them as-is and present them as-is. The act exactly > like passwords. I added that text to make that stand out. > > When using passwords, the server doesn't need to store them in plain-text > either (e.g. uses a way one hash). > That's why we don't call passwords "shared symmetric secrets", either. The verifier of a passwords can verify it without knowing the secret. In that sense, it's not "shared" with the verifier. I would like the specification to make it clear that bearer tokens are only > secure while they remain *secret* and that *anyone* holding them can gain > full access to what their protect. > I think the word "capability" expresses that better than the word "shared secret". Dirk. > > EHL > > On 7/12/10 10:39 PM, "Brian Eaton" wrote: > > > Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5 > > > > Calling access tokens "shared symmetric secrets" is misleading, > > because if they are implemented well the authorization server and > > protected resource do not store a copy of the secret. > > > > Instead they store a one-way hash of the token. Or they verify the > > token cryptographically. Under no circumstances do they need to store > > a copy. > > > > I'd suggest the following language: > > > > "Access tokens are bearer authentication tokens or capabilities." > > > > Cheers, > > Brian > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00235452eebca73b82048b46e755 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 13, 2010 at 7:18 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
>From the client's perspective, they are 'shared symmetric secrets&#= 39; because
the client has to store them as-is and present them as-is. The act exactly<= br> like passwords. I added that text to make that stand out.

When using passwords, the server doesn't need to store them in plain-te= xt
either (e.g. uses a way one hash).

That= 's why we don't call passwords "shared symmetric secrets"= , either. The verifier of a passwords can verify it without knowing the sec= ret.=A0In that sense, it's not "shared" with the verifier.=A0=

I would like the specificati= on to make it clear that bearer tokens are only
secure while they remain *secret* and that *anyone* holding them can gain full access to what their protect.

I th= ink the word "capability" expresses that better than the word &qu= ot;shared secret".=A0

Dirk.
=A0

EHL

On 7/12/10 10:39 PM, "Brian Eaton" <beaton@google.com> wrote:

> Section 5: http://tools.ietf.org/html/draft-ietf-oauth-= v2-10#section-5
>
> Calling access tokens "shared symmetric secrets" is misleadi= ng,
> because if they are implemented well the authorization server and
> protected resource do not store a copy of the secret.
>
> Instead they store a one-way hash of the token. =A0Or they verify the<= br> > token cryptographically. =A0Under no circumstances do they need to sto= re
> a copy.
>
> I'd suggest the following language:
>
> "Access tokens are bearer authentication tokens or capabilities.&= quot;
>
> Cheers,
> Brian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

--00235452eebca73b82048b46e755-- From eran@hueniverse.com Tue Jul 13 09:02: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 86D713A6A0F for ; Tue, 13 Jul 2010 09:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.145, 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 KIyFPYd-g485 for ; Tue, 13 Jul 2010 09:02:10 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id EB5223A697D for ; Tue, 13 Jul 2010 09:02:09 -0700 (PDT) Received: (qmail 1602 invoked from network); 13 Jul 2010 16:02:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 16:02:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 13 Jul 2010 09:02:17 -0700 From: Eran Hammer-Lahav To: Dirk Balfanz Date: Tue, 13 Jul 2010 09:02:11 -0700 Thread-Topic: [OAUTH-WG] "shared symmetric secret" Thread-Index: Acsio+zrKl/M8DrJTFKjpBLZ87ntBAAANOaC Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C861DC1337160eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:02:15 -0000 --_000_C861DC1337160eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am ok replacing it with 'acts as a password'. EHL On 7/13/10 8:55 AM, "Dirk Balfanz" wrote: On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav wr= ote: >From the client's perspective, they are 'shared symmetric secrets' because the client has to store them as-is and present them as-is. The act exactly like passwords. I added that text to make that stand out. When using passwords, the server doesn't need to store them in plain-text either (e.g. uses a way one hash). That's why we don't call passwords "shared symmetric secrets", either. The = verifier of a passwords can verify it without knowing the secret. In that s= ense, it's not "shared" with the verifier. I would like the specification to make it clear that bearer tokens are only secure while they remain *secret* and that *anyone* holding them can gain full access to what their protect. I think the word "capability" expresses that better than the word "shared s= ecret". Dirk. EHL On 7/12/10 10:39 PM, "Brian Eaton" wrote: > Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5 > > Calling access tokens "shared symmetric secrets" is misleading, > because if they are implemented well the authorization server and > protected resource do not store a copy of the secret. > > Instead they store a one-way hash of the token. Or they verify the > token cryptographically. Under no circumstances do they need to store > a copy. > > I'd suggest the following language: > > "Access tokens are bearer authentication tokens or capabilities." > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C861DC1337160eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] "shared symmetric secret" I am ok replacing it with ‘acts as a password’.

EHL


On 7/13/10 8:55 AM, "Dirk Balfanz" <balfanz@google.com> wrote:



On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
From the client's perspective, they are 'sh= ared symmetric secrets' because
the client has to store them as-is and present them as-is. The act exactly<= BR> like passwords. I added that text to make that stand out.

When using passwords, the server doesn't need to store them in plain-text either (e.g. uses a way one hash).
I would like the specification to make it c= lear that bearer tokens are only
secure while they remain *secret* and that *anyone* holding them can gain full access to what their protect.

EHL

On 7/12/10 10:39 PM, "Brian Eaton" <beaton@google.com> wrote:

> Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5
>
> Calling access tokens "shared symmetric secrets" is misleadi= ng,
> because if they are implemented well the authorization server and
> protected resource do not store a copy of the secret.
>
> Instead they store a one-way hash of the token. =A0Or they verify the<= BR> > token cryptographically. =A0Under no circumstances do they need to sto= re
> a copy.
>
> I'd suggest the following language:
>
> "Access tokens are bearer authentication tokens or capabilities.&= quot;
>
> Cheers,
> Brian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth
In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C861DE3B37163eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:11:28 -0000 --_000_C861DE3B37163eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New text: Clients access protected resources by presenting an access token to= the resource server. Access tokens are bearer tokens, where the token string acts as a p= assword. This requires treating the access token with the same care as other passwords. Ac= cess tokens SHOULD NOT be sent in the clear over an insecure channel. EHL On 7/13/10 9:02 AM, "Eran Hammer-Lahav" wrote: I am ok replacing it with 'acts as a password'. EHL On 7/13/10 8:55 AM, "Dirk Balfanz" wrote: On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav wr= ote: >From the client's perspective, they are 'shared symmetric secrets' because the client has to store them as-is and present them as-is. The act exactly like passwords. I added that text to make that stand out. When using passwords, the server doesn't need to store them in plain-text either (e.g. uses a way one hash). That's why we don't call passwords "shared symmetric secrets", either. The = verifier of a passwords can verify it without knowing the secret. In that s= ense, it's not "shared" with the verifier. I would like the specification to make it clear that bearer tokens are only secure while they remain *secret* and that *anyone* holding them can gain full access to what their protect. I think the word "capability" expresses that better than the word "shared s= ecret". Dirk. EHL On 7/12/10 10:39 PM, "Brian Eaton" wrote: > Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5 > > Calling access tokens "shared symmetric secrets" is misleading, > because if they are implemented well the authorization server and > protected resource do not store a copy of the secret. > > Instead they store a one-way hash of the token. Or they verify the > token cryptographically. Under no circumstances do they need to store > a copy. > > I'd suggest the following language: > > "Access tokens are bearer authentication tokens or capabilities." > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C861DE3B37163eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] "shared symmetric secret" New text:

        Clients access protected re= sources by presenting an access token to the resource server.
        Access tokens are bearer to= kens, where the token string acts as a password. This requires
        treating the access token w= ith the same care as other passwords. Access tokens SHOULD NOT
        be sent in the clear over a= n insecure channel.

EHL


On 7/13/10 9:02 AM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

I am ok replacing it with ‘acts as a = password’.

EHL


On 7/13/10 8:55 AM, "Dirk Balfanz" <balfanz@google.com> wrote:



On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
From the client's perspective, they are 'sh= ared symmetric secrets' because
the client has to store them as-is and present them as-is. The act exactly<= BR> like passwords. I added that text to make that stand out.

When using passwords, the server doesn't need to store them in plain-text either (e.g. uses a way one hash).
I would like the specification to make it c= lear that bearer tokens are only
secure while they remain *secret* and that *anyone* holding them can gain full access to what their protect.

EHL

On 7/12/10 10:39 PM, "Brian Eaton" <beaton@google.com> wrote:

> Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5
>
> Calling access tokens "shared symmetric secrets" is misleadi= ng,
> because if they are implemented well the authorization server and
> protected resource do not store a copy of the secret.
>
> Instead they store a one-way hash of the token.  Or they verify t= he
> token cryptographically.  Under no circumstances do they need to = store
> a copy.
>
> I'd suggest the following language:
>
> "Access tokens are bearer authentication tokens or capabilities.&= quot;
>
> Cheers,
> Brian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth
Subject: Re: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:22:55 -0000 This is a multi-part message in MIME format. --------------090802040305050508030004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 22/07/28164 13:59, Eran Hammer-Lahav wrote: > The following was submitted via the shared-copy page but does not > belong with editorial feedback. This needs to be discussed and > supported on the list before added the specification. I think it > belongs where 'immediate' is specified. > > EHL > > ------ Forwarded Message > > *From: *An anonymous reader > *Date: *Sat, 10 Jul 2010 11:01:11 -0700 > *To: *Eran Hammer-Lahav > *Subject: *Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol > > > *"Colin Snover"* left these comments on your copy: > > *draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol > > * > > As proposed on the ML, a new parameter to counteract the > current behaviour of OAuth 1.0a authorization servers which is to > assume that the account logged into the user-agent is the account > that should be checked for access: > > force_auth > OPTIONAL. The parameter value must be set to "true" or > "false". > > If set to "true", the authorization server MUST prompt > the end-user to authenticate and approve access. The authorization > server MUST NOT make any assumptions as to the identity of the > entity requesting access, even if another automatic mechanism is > available to do so (e.g. browser cookies). > > If set to "false" or not present, the authorization > server MAY automatically grant access to the client if it is able > to determine that access was previously granted. link > > > > tools.ietf.org/html/draft-ietf-oauth-v2-09 > Original page > > > > ------------------------------------------------------------------------ > via sharedcopy.com > > > ------ End of Forwarded Message Hi Eran, Sorry if that was not the right place for that to go; I didn't know what else to do. I have tried to solicit feedback from the ML regarding this parameter twice and nobody seems very keen in providing any, which is kind of a bummer. I waited until the last possible moment to add it in the hopes that someone would notice my messages and discuss it, but you made it sound like your plan was for draft 10 to be potentially final so I wanted to get it in before the deadline. I'm sure this is not a big deal for most applications that expect at most a single connection, but for me this is a huge deal since it completely immolates our application's authentication flow, and I can't go to every provider asking them to please change the way they implement the authentication portion of their OAuth API. In contrast to 'immediate', which had some concerns vis vis security, force_auth is actually safer than the current normal flow used by most OAuth providers since it requires the provider to make no guesses about who is trying to authorize the app. Frankly, I think that OAuth providers do the wrong thing now in all cases by assuming that browser cookies are a safe way of confirming the identity of the end-user making an authorization request (they aren't!), but the spec says the way the authorization server authenticates the end-user is outside the scope of the spec. I have no objection to this---OAuth *should* be authentication-agnostic---but at the same time this is a very real and present implementation flaw and the only way to solve it is to make sure the spec defines a way for an application to say "hey, I know you *think* you know who should be authenticated, but *I* know that the user has requested to connect a *new* account, so don't use any automatic authentication method". I think it is incredibly important that the OAuth spec gets providers to distinguish between automatic & potentially unsafe authentication methods (like session cookies) versus more "guaranteed" authentication (like password), especially since 99.999% of the time OAuth relies on the end-user's Web browser which is all but guaranteed to contain some cookies for the provider that are unrelated to the requesting application. Examples: 1. Multiple end-users with malicious intent. User 1 is logged into their Facetweetr account. User 2 wants to do bad things using User 1's account. Because the user-agent has cookies for user 1, user 2 gets to authorize their account with our app. Even when user 1 changes their password, unless the provider automatically invalidates their existing connections (the spec does not even mention doing this in an informative manner as far as I can tell), they are almost certainly unaware that the linked application is still able to perform actions on their behalf. 2. Single end-user with multiple accounts. User is logged into Facetweetr account 1, but they want to authorize account 2. They go to authorize the application and are presented with a confirmation for account 1. They log out (because this is the only way to switch accounts on the provider) and suddenly the authorization flow is dropped on the floor. The user may not know immediately what they need to do at this point. They will need to manually return to the original application and restart the authorization request. 3. User has two accounts that they want to authorize with a provider. User authorizes account 1 successfully, then wants to authorize account 2. Because account 1 is still logged in, and because the application already has a link to the account, it automatically redirects back to the application's redirection URI. In order for the user to get what they want, they are forced to manually navigate to the provider's site, log out, *then* begin the authorization request. These aren't imaginary scenarios; they are things that are going on *right now* with several different OAuth providers. The original request: Regards, -- Colin Snover http://zetafleet.com --------------090802040305050508030004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 22/07/28164 13:59, Eran Hammer-Lahav wrote:
' force_auth' request parameter The following was submitted via the shared-copy page but does not belong with editorial feedback. This needs to be discussed and supported on the list before added the specification. I think it belongs where ‘immediate’ is specified.

EHL

------ Forwarded Message
From: An anonymous reader <mailman@sharedcopy.com>
Date: Sat, 10 Jul 2010 11:01:11 -0700
To: Eran Hammer-Lahav <eran@hueniverse.com>
Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol
 "Colin Snover" left these comments on your copy:
 
draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol <http://r6.sharedcopy.com/6bnqq8v>
        

     As proposed on the ML, a new parameter to counteract the current behaviour of OAuth 1.0a authorization servers which is to assume that the account logged into the user-agent is the account that should be checked for access:

force_auth
         OPTIONAL. The parameter value must be set to "true" or "false".

         If set to "true", the authorization server MUST prompt the end-user to authenticate and approve access. The authorization server MUST NOT make any assumptions as to the identity of the entity requesting access, even if another automatic mechanism is available to do so (e.g. browser cookies).

         If set to "false" or not present, the authorization server MAY automatically grant access to the client if it is able to determine that access was previously granted.         link » <http://r6.sharedcopy.com/6bnqq8v#shcp21>
 

tools.ietf.org/html/draft-ietf-oauth-v2-09 <http://r6.sharedcopy.com/6bnqq8v>  · Original page <http://tools.ietf.org/html/draft-ietf-oauth-v2-09>
  
 
via sharedcopy.com <http://sharedcopy.com/?ef>  

------ End of Forwarded Message

Hi Eran,

Sorry if that was not the right place for that to go; I didn’t know what else to do. I have tried to solicit feedback from the ML regarding this parameter twice and nobody seems very keen in providing any, which is kind of a bummer. I waited until the last possible moment to add it in the hopes that someone would notice my messages and discuss it, but you made it sound like your plan was for draft 10 to be potentially final so I wanted to get it in before the deadline.

I’m sure this is not a big deal for most applications that expect at most a single connection, but for me this is a huge deal since it completely immolates our application’s authentication flow, and I can’t go to every provider asking them to please change the way they implement the authentication portion of their OAuth API.

In contrast to ‘immediate’, which had some concerns vis à vis security, force_auth is actually safer than the current normal flow used by most OAuth providers since it requires the provider to make no guesses about who is trying to authorize the app.

Frankly, I think that OAuth providers do the wrong thing now in all cases by assuming that browser cookies are a safe way of confirming the identity of the end-user making an authorization request (they aren’t!), but the spec says the way the authorization server authenticates the end-user is outside the scope of the spec. I have no objection to this—OAuth *should* be authentication-agnostic—but at the same time this is a very real and present implementation flaw and the only way to solve it is to make sure the spec defines a way for an application to say “hey, I know you *think* you know who should be authenticated, but *I* know that the user has requested to connect a *new* account, so don’t use any automatic authentication method”.

I think it is incredibly important that the OAuth spec gets providers to distinguish between automatic & potentially unsafe authentication methods (like session cookies) versus more “guaranteed” authentication (like password), especially since 99.999% of the time OAuth relies on the end-user’s Web browser which is all but guaranteed to contain some cookies for the provider that are unrelated to the requesting application.

Examples:

1. Multiple end-users with malicious intent. User 1 is logged into their Facetweetr account. User 2 wants to do bad things using User 1’s account. Because the user-agent has cookies for user 1, user 2 gets to authorize their account with our app. Even when user 1 changes their password, unless the provider automatically invalidates their existing connections (the spec does not even mention doing this in an informative manner as far as I can tell), they are almost certainly unaware that the linked application is still able to perform actions on their behalf.

2. Single end-user with multiple accounts. User is logged into Facetweetr account 1, but they want to authorize account 2. They go to authorize the application and are presented with a confirmation for account 1. They log out (because this is the only way to switch accounts on the provider) and suddenly the authorization flow is dropped on the floor. The user may not know immediately what they need to do at this point. They will need to manually return to the original application and restart the authorization request.

3. User has two accounts that they want to authorize with a provider. User authorizes account 1 successfully, then wants to authorize account 2. Because account 1 is still logged in, and because the application already has a link to the account, it automatically redirects back to the application’s redirection URI. In order for the user to get what they want, they are forced to manually navigate to the provider’s site, log out, *then* begin the authorization request.

These aren’t imaginary scenarios; they are things that are going on *right now* with several different OAuth providers.

The original request: <http://www.mail-archive.com/oauth@ietf.org/msg02331.html>

Regards,
-- 
Colin Snover
http://zetafleet.com
--------------090802040305050508030004-- From eran@hueniverse.com Tue Jul 13 09:31:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296303A6A5B for ; Tue, 13 Jul 2010 09:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iS89xu6OBDD for ; Tue, 13 Jul 2010 09:31:33 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 6338D3A6A97 for ; Tue, 13 Jul 2010 09:31:26 -0700 (PDT) Received: (qmail 27921 invoked from network); 13 Jul 2010 16:31:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 16:31:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 13 Jul 2010 09:31:24 -0700 From: Eran Hammer-Lahav To: Colin Snover Date: Tue, 13 Jul 2010 09:31:20 -0700 Thread-Topic: [OAUTH-WG] ' force_auth' request parameter Thread-Index: Acsip6b1rueeXuLrRee3Vxdu6o8xXQAASwJk Message-ID: In-Reply-To: <4C3C92D2.80209@zetafleet.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C861E2E837193eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:31:45 -0000 --_000_C861E2E837193eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Building consensus around new ideas is tough. The only advice I can give yo= u is to identify the people most likely to support this idea and ping them = off-list to try and get their support. I don't think it belongs in core bec= ause core currently represents pretty solid consensus on the feature set (a= nd most details). EHL On 7/13/10 9:22 AM, "Colin Snover" wrote: On 22/07/28164 13:59, Eran Hammer-Lahav wrote: ' force_auth' request parameter The following was submitted via the shared-= copy page but does not belong with editorial feedback. This needs to be dis= cussed and supported on the list before added the specification. I think it= belongs where 'immediate' is specified. EHL ------ Forwarded Message From: An anonymous reader Date: Sat, 10 Jul 2010 11:01:11 -0700 To: Eran Hammer-Lahav Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol "Colin Snover" left these comments on your copy: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol As proposed on the ML, a new parameter to counteract the current beha= viour of OAuth 1.0a authorization servers which is to assume that the accou= nt logged into the user-agent is the account that should be checked for acc= ess: force_auth OPTIONAL. The parameter value must be set to "true" or "false". If set to "true", the authorization server MUST prompt the end-us= er to authenticate and approve access. The authorization server MUST NOT ma= ke any assumptions as to the identity of the entity requesting access, even= if another automatic mechanism is available to do so (e.g. browser cookies= ). If set to "false" or not present, the authorization server MAY au= tomatically grant access to the client if it is able to determine that acce= ss was previously granted. link =BB tools.ietf.org/html/draft-ietf-oauth-v2-09 =B7 Original page ________________________________ via sharedcopy.com ------ End of Forwarded Message Hi Eran, Sorry if that was not the right place for that to go; I didn't know what e= lse to do. I have tried to solicit feedback from the ML regarding this para= meter twice and nobody seems very keen in providing any, which is kind of a= bummer. I waited until the last possible moment to add it in the hopes tha= t someone would notice my messages and discuss it, but you made it sound li= ke your plan was for draft 10 to be potentially final so I wanted to get it= in before the deadline. I'm sure this is not a big deal for most applications that expect at most = a single connection, but for me this is a huge deal since it completely imm= olates our application's authentication flow, and I can't go to every provi= der asking them to please change the way they implement the authentication = portion of their OAuth API. In contrast to 'immediate', which had some concerns vis =E0 vis security, = force_auth is actually safer than the current normal flow used by most OAut= h providers since it requires the provider to make no guesses about who is = trying to authorize the app. Frankly, I think that OAuth providers do the wrong thing now in all cases = by assuming that browser cookies are a safe way of confirming the identity = of the end-user making an authorization request (they aren't!), but the spe= c says the way the authorization server authenticates the end-user is outsi= de the scope of the spec. I have no objection to this-OAuth *should* be aut= hentication-agnostic-but at the same time this is a very real and present i= mplementation flaw and the only way to solve it is to make sure the spec de= fines a way for an application to say "hey, I know you *think* you know who= should be authenticated, but *I* know that the user has requested to conne= ct a *new* account, so don't use any automatic authentication method". I think it is incredibly important that the OAuth spec gets providers to d= istinguish between automatic & potentially unsafe authentication methods (l= ike session cookies) versus more "guaranteed" authentication (like password= ), especially since 99.999% of the time OAuth relies on the end-user's Web = browser which is all but guaranteed to contain some cookies for the provide= r that are unrelated to the requesting application. Examples: 1. Multiple end-users with malicious intent. User 1 is logged into their F= acetweetr account. User 2 wants to do bad things using User 1's account. Be= cause the user-agent has cookies for user 1, user 2 gets to authorize their= account with our app. Even when user 1 changes their password, unless the = provider automatically invalidates their existing connections (the spec doe= s not even mention doing this in an informative manner as far as I can tell= ), they are almost certainly unaware that the linked application is still a= ble to perform actions on their behalf. 2. Single end-user with multiple accounts. User is logged into Facetweetr = account 1, but they want to authorize account 2. They go to authorize the a= pplication and are presented with a confirmation for account 1. They log ou= t (because this is the only way to switch accounts on the provider) and sud= denly the authorization flow is dropped on the floor. The user may not know= immediately what they need to do at this point. They will need to manually= return to the original application and restart the authorization request. 3. User has two accounts that they want to authorize with a provider. User= authorizes account 1 successfully, then wants to authorize account 2. Beca= use account 1 is still logged in, and because the application already has a= link to the account, it automatically redirects back to the application's = redirection URI. In order for the user to get what they want, they are forc= ed to manually navigate to the provider's site, log out, *then* begin the a= uthorization request. These aren't imaginary scenarios; they are things that are going on *right= now* with several different OAuth providers. The original request: Regards, --_000_C861E2E837193eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] ' force_auth' request parameter Building consensus around new ideas is tough. The only advice I can g= ive you is to identify the people most likely to support this idea and ping= them off-list to try and get their support. I don’t think it belongs= in core because core currently represents pretty solid consensus on the fe= ature set (and most details).

EHL


On 7/13/10 9:22 AM, "Colin Snover" <ietf.org@zetafleet.com> wrote:

 On 22/07/28164 13:59, Eran Hammer-La= hav wrote:
' force_auth' request parameter The follow= ing was submitted via the shared-copy page but does not belong with editori= al feedback. This needs to be discussed and supported on the list before ad= ded the specification. I think it belongs where ‘immediate’ is = specified.
 
 EHL
 
 ------ Forwarded Message
  
From: An anonymous reader <mailman@sharedcopy.com>
 Date: Sat, 10 Jul 2010 11:01:11 -0700
 To: Eran Hammer-Lahav <eran= @hueniverse.com>
 Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol  
 
 "Colin Snover" left= these comments on your copy:
  
 draft-ietf-= oauth-v2-09 - The OAuth 2.0 Protocol <http://r6.sharedcopy.com/6bnqq8v>
     &= nbsp;    
 
      As proposed on the ML, a new parameter = to counteract the current behaviour of OAuth 1.0a authorization servers whi= ch is to assume that the account logged into the user-agent is the account = that should be checked for access:
 
 force_auth
          OPTIONAL. The p= arameter value must be set to "true" or "false".
 
          If set to "= ;true", the authorization server MUST prompt the end-user to authentic= ate and approve access. The authorization server MUST NOT make any assumpti= ons as to the identity of the entity requesting access, even if another aut= omatic mechanism is available to do so (e.g. browser cookies).
 
          If set to "= ;false" or not present, the authorization server MAY automatically gra= nt access to the client if it is able to determine that access was previous= ly granted.         link » &l= t;http://r6.sharedcopy.= com/6bnqq8v#shcp21>
  
 
 tools.ietf.org/html/draft-ietf-oauth-v2-09 <http://r6.sharedcopy.com/6bnqq8v>  &midd= ot; Original page <http://tools.ietf.org/html/draft-ietf-oauth-v2-09>
   
  
 
via sharedcopy.com <http://sharedcopy.com/?ef>    
http://www.mail-archive.com/oauth@ietf.org/msg023= 31.html>
 
 Regards,
 
--_000_C861E2E837193eranhueniversecom_-- From recordond@gmail.com Tue Jul 13 09:42: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 168EC3A6A70 for ; Tue, 13 Jul 2010 09:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wqg+O8PwYmn9 for ; Tue, 13 Jul 2010 09:42:12 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 13F023A6848 for ; Tue, 13 Jul 2010 09:42:12 -0700 (PDT) Received: by gwj19 with SMTP id 19so1167464gwj.31 for ; Tue, 13 Jul 2010 09:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tZ4v8udv/Qmcm/ZrbrM2OiqAfwYlkT0IvjVOIXT81LU=; b=AOFp+7PsezHgA9eCHKMzflhakTLmT9Bj5q3bzP2kC+XU2I4vWzvkvfqn8o0/6g3cb8 rzObJK4kNMqPH/JSga1VMj4WjKxSgMU3GOqEmm9PZGGaNjzYtswKLlD12yndAHZQM6xh yzkzTAVVz7otnjz39SzUzHHzA0qu2moLgvRWg= 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=QNQHO86qj8h08FGUt7ZDG8hiaxZHeRbxUA9sDfbT7hyzr+R25Uax3ecHwVTSI1ivmj QlxJxseWpB0yL1FKCOH0qDL4fTj0PGuLxnG7c3f+e+Gm802noI99wdo2By+Ih/2AzP9c VGfhxG32xcRFCCmIRlP+ntmpQ+D0qMzyYQZZc= MIME-Version: 1.0 Received: by 10.101.159.1 with SMTP id l1mr14814899ano.60.1279039336377; Tue, 13 Jul 2010 09:42:16 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Tue, 13 Jul 2010 09:42:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 09:42:16 -0700 Message-ID: From: David Recordon To: Luke Shepard Content-Type: multipart/alternative; boundary=0016e68fcff74c7186048b478d92 Cc: OAuth WG Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:42:13 -0000 --0016e68fcff74c7186048b478d92 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Jul 13, 2010 at 1:06 AM, Luke Shepard wrote= : > I just read this bit: > > If the response type is "code_and_token", the authorization server > adds the "code" and "state" parameters to the redirection URI query > component and the "access_token", "scope", and "expires_in" to the > redirection URI fragment using the > "application/x-www-form-urlencoded" format as defined by > > That strikes me as very odd - returning some params in the query, and > others in the fragment is just weird. > I actually think that you want this =96 albiet odd =96 combination when requesting both a code and token. The code and state parameters are needed by the server and thus are query parameters. The access token, scope, and expires in shouldn't be sent to the server via HTTP and thus are within the fragment for the JavaScript to access. I think the request should specify whether it wants the response in the > fragment or query. > You can't always put them into the query because you'd be exposing an acces= s token over HTTP. If you always put them into the fragment then you need to write JavaScript which passes the code and state down to the server. --0016e68fcff74c7186048b478d92 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Jul 13, 2010 at 1:06 AM, Luke Shepard <lshepard@facebook.com> wrot= e:
I just read= this bit:

=A0=A0 If the response type = is "code_and_token", the authorization server
=A0=A0 ad= ds the "code" and "state" parameters to the redirection= URI query
=A0=A0 component and the "access_token", "scope", = and "expires_in" to the
=A0=A0 redirection URI fragment= using the
=A0=A0 "application/x-www-form-urlencoded" f= ormat as defined by

That strikes me as very odd - returning some para= ms in the query, and others in the fragment is just weird.

I actually think that you want this =96 a= lbiet odd =96 combination when requesting both a code and token. The code a= nd state parameters are needed by the server and thus are query=A0parameter= s. The access token, scope, and expires in shouldn't be sent to the ser= ver via HTTP and thus are within the=A0fragment=A0for the JavaScript to acc= ess.


I think the request should specify whether= it wants the response in the fragment or query.

You can't always put them = into the query because you'd be exposing an access token over HTTP. If = you always put them into the fragment then you need to write JavaScript whi= ch passes the code and state down to the server.
--0016e68fcff74c7186048b478d92-- From yarong@microsoft.com Tue Jul 13 09:46:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4B5F3A6B2D for ; Tue, 13 Jul 2010 09:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.339 X-Spam-Level: X-Spam-Status: No, score=-11.339 tagged_above=-999 required=5 tests=[AWL=1.260, BAYES_00=-2.599, GB_I_LETTER=-2, 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 8-SffDV7qck6 for ; Tue, 13 Jul 2010 09:46:35 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id B811A3A6B2B for ; Tue, 13 Jul 2010 09:46:35 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 13 Jul 2010 09:46:44 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.44]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0180.004; Tue, 13 Jul 2010 09:46:44 -0700 From: Yaron Goland To: Eran Hammer-Lahav , Robert Sayre Thread-Topic: [OAUTH-WG] What to do about 'realm' Thread-Index: AcsWZA3VaAGfBKT6Rq+fJ1qCaXCqogKnLTUAABpFMgAABm2JgAAKYjcAAD86ilA= Date: Tue, 13 Jul 2010 16:46:40 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C5F991033@TK5EX14MBXC113.redmond.corp.microsoft.com> References: In-Reply-To: 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 Cc: OAuth WG Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:46:37 -0000 As defined in section 4.2 of RFC 2616 the only characters legally allowed i= n a HTTP header are a fairly small subset of ASCII. So if we want to shove = in Unicode characters they will have to be encoded in a form that only uses= characters that are legal in the subset of ASCII supported by HTTP. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Sunday, July 11, 2010 8:29 PM > To: Robert Sayre > Cc: OAuth WG > Subject: Re: [OAUTH-WG] What to do about 'realm' >=20 >=20 >=20 >=20 > On 7/11/10 3:32 PM, "Robert Sayre" wrote: >=20 > > On Sun, Jul 11, 2010 at 12:27 PM, Eran Hammer-Lahav > > > > wrote: > >> [this has noting to do with realm] > >> > >> Any solution should be: > >> > >> - Extensible we removed the few discovery parameters from the core > >> spec due to lack of maturity and consensus. However, we clearly have > >> enough strong interest in reintroducing them as extensions. The > >> WWW-Authenticate header is the natural place to include them. > > > > This is true. I thought it obvious that implementations would be > > required to deal with text after the "OAuth2" string. >=20 > Yes. We need a format that can be extended. Of course, using JSON means > much richer extensibility which needs some adjustment in the registry > (maybe only require registration for top level object names?). >=20 > >> - Human-friendly I think being able to look at the header and > >> immediately see what it means is useful. > > > > I'm not sure this is valuable, but it is possible to accomodate the > > concern anyway. I use a protocol analyzer, like WireShark. >=20 > I think being able to curl a site and work your way manually is useful an= d > something that was a stated goal when we started collecting 2.0 > requirements. This was one of the reasons why the bearer token approach > was so attractive to so many people. >=20 > >> Is there a JSON profile suitable for inclusion in HTTP headers? I > >> would like to avoid BASE64 when a person is likely to take a look at > >> the header. Otherwise debugging and command line interaction become > >> impractical. > > > > The WG could specify that all control characters and non-ASCII text > > within the JSON text be escaped. base64 adds overhead to the endeavor, > > so it's probably best to avoid it, because most of the bits will be > > ASCII anyway. >=20 > Works for me. >=20 > > If browser clients need to set headers in the same manner, this could > > be more inconvenient, because the JSON serializers shipping in > > browsers today don't support requiring that the produced text be > > escaped. This can be done as a follow-up pass, though. [0] >=20 > I am not worried about client requests because there is less to debug on = that > side (most issues are when the client is trying to debug on its side and = can > easily add helpful information locally). I want to make sure that the ser= ver > response using the WWW-Authenticate header is plain-text and not some > encoded blob. >=20 > However, we still need to worry about HTTP header restrictions and I am n= ot > sure what a browser will do when you try to set an HTTP header with non- > ascii characters. >=20 > > Using a JSON serialization neatly sidesteps several i18n issues. If > > you go with traditional HTTP header syntax, you'll need to deal with > > that some other way. btw, it just so happens that internationalization > > of Realm values is a bug in most RFC2617 implemenations. >=20 > It would be great to avoid having to use stuff like draft-reschke-rfc2231= -in- > http, but that seems to be the current solution. >=20 > EHL >=20 > > > > [0] (I happen to be on the ECMAScript committee, and I can be blamed > > for Mozilla's native JSON object. It would be technically easy to add > > a JSON.stringifyAsASCII() method, and I think the committee will go > > for it.) > > > > > > > > -- > > > > Robert Sayre > > > > "I would have written a shorter letter, but I did not have the time." > > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Tue Jul 13 09:53: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 0C2283A6897 for ; Tue, 13 Jul 2010 09:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.531 X-Spam-Level: X-Spam-Status: No, score=-17.531 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvX00G+z7ZAc for ; Tue, 13 Jul 2010 09:53:37 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 84C313A680D for ; Tue, 13 Jul 2010 09:53:37 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6DGqTnU057228; Tue, 13 Jul 2010 09:52:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=ZKGl8V9Q0z2o3OjnuRaLg9pwHSuI1Kb5HwbGVV3cSONuZ33C55M4uBuRY1uQgz3T Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 09:52:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB22AB.B195F3F2" Date: Tue, 13 Jul 2010 09:51:51 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6C12@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <4C3C92D2.80209@zetafleet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] ' force_auth' request parameter Thread-Index: Acsip/cxl6BqvX4aSiit9Q7Px3rgYwAA0v4A References: <4C3C92D2.80209@zetafleet.com> From: "William Mills" To: "Colin Snover" , "Eran Hammer-Lahav" X-OriginalArrivalTime: 13 Jul 2010 16:52:29.0373 (UTC) FILETIME=[C79A6ED0:01CB22AB] Cc: OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:53:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB22AB.B195F3F2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Colin that some form of force_auth is needed. I haven't = read enough on the "immediate" proposal, but I know that we have run = into the problem of trusting currently set cookies in the browser (even = when we're actually sending a username/password and really do want to = have an authentication). =20 I'm a +1 on the force_auth proposal. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Colin Snover Sent: Tuesday, July 13, 2010 9:23 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter =09 =09 On 22/07/28164 13:59, Eran Hammer-Lahav wrote:=20 The following was submitted via the shared-copy page but does not = belong with editorial feedback. This needs to be discussed and supported = on the list before added the specification. I think it belongs where = 'immediate' is specified. =09 EHL =09 ------ Forwarded Message =09 From: An anonymous reader Date: Sat, 10 Jul 2010 11:01:11 -0700 To: Eran Hammer-Lahav Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol =09 =09 =09 =09 "Colin Snover" left these comments on your copy:=20 =20 draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol = =20 =20 =09 As proposed on the ML, a new parameter to counteract the current = behaviour of OAuth 1.0a authorization servers which is to assume that = the account logged into the user-agent is the account that should be = checked for access: =09 force_auth OPTIONAL. The parameter value must be set to "true" or = "false". =09 If set to "true", the authorization server MUST prompt the = end-user to authenticate and approve access. The authorization server = MUST NOT make any assumptions as to the identity of the entity = requesting access, even if another automatic mechanism is available to = do so (e.g. browser cookies). =09 If set to "false" or not present, the authorization server = MAY automatically grant access to the client if it is able to determine = that access was previously granted. link =BB = =20 =20 =09 tools.ietf.org/html/draft-ietf-oauth-v2-09 = =B7 Original page = =20 =20 =20 =09 ________________________________ via sharedcopy.com =20 =09 =09 ------ End of Forwarded Message =09 Hi Eran, =09 Sorry if that was not the right place for that to go; I didn't know = what else to do. I have tried to solicit feedback from the ML regarding = this parameter twice and nobody seems very keen in providing any, which = is kind of a bummer. I waited until the last possible moment to add it = in the hopes that someone would notice my messages and discuss it, but = you made it sound like your plan was for draft 10 to be potentially = final so I wanted to get it in before the deadline. =09 I'm sure this is not a big deal for most applications that expect at = most a single connection, but for me this is a huge deal since it = completely immolates our application's authentication flow, and I can't = go to every provider asking them to please change the way they implement = the authentication portion of their OAuth API. =09 In contrast to 'immediate', which had some concerns vis =E0 vis = security, force_auth is actually safer than the current normal flow used = by most OAuth providers since it requires the provider to make no = guesses about who is trying to authorize the app. =09 Frankly, I think that OAuth providers do the wrong thing now in all = cases by assuming that browser cookies are a safe way of confirming the = identity of the end-user making an authorization request (they aren't!), = but the spec says the way the authorization server authenticates the = end-user is outside the scope of the spec. I have no objection to = this-OAuth *should* be authentication-agnostic-but at the same time this = is a very real and present implementation flaw and the only way to solve = it is to make sure the spec defines a way for an application to say = "hey, I know you *think* you know who should be authenticated, but *I* = know that the user has requested to connect a *new* account, so don't = use any automatic authentication method". =09 I think it is incredibly important that the OAuth spec gets providers = to distinguish between automatic & potentially unsafe authentication = methods (like session cookies) versus more "guaranteed" authentication = (like password), especially since 99.999% of the time OAuth relies on = the end-user's Web browser which is all but guaranteed to contain some = cookies for the provider that are unrelated to the requesting = application. =09 Examples: =09 1. Multiple end-users with malicious intent. User 1 is logged into = their Facetweetr account. User 2 wants to do bad things using User 1's = account. Because the user-agent has cookies for user 1, user 2 gets to = authorize their account with our app. Even when user 1 changes their = password, unless the provider automatically invalidates their existing = connections (the spec does not even mention doing this in an informative = manner as far as I can tell), they are almost certainly unaware that the = linked application is still able to perform actions on their behalf. =09 2. Single end-user with multiple accounts. User is logged into = Facetweetr account 1, but they want to authorize account 2. They go to = authorize the application and are presented with a confirmation for = account 1. They log out (because this is the only way to switch accounts = on the provider) and suddenly the authorization flow is dropped on the = floor. The user may not know immediately what they need to do at this = point. They will need to manually return to the original application and = restart the authorization request. =09 3. User has two accounts that they want to authorize with a provider. = User authorizes account 1 successfully, then wants to authorize account = 2. Because account 1 is still logged in, and because the application = already has a link to the account, it automatically redirects back to = the application's redirection URI. In order for the user to get what = they want, they are forced to manually navigate to the provider's site, = log out, *then* begin the authorization request. =09 These aren't imaginary scenarios; they are things that are going on = *right now* with several different OAuth providers. =09 The original request: = = =20 =09 Regards, =09 --=20 Colin Snover http://zetafleet.com ------_=_NextPart_001_01CB22AB.B195F3F2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree with Colin that some form of force_auth is = needed.  I haven't read enough on the "immediate" proposal, but I = know that=20 we have run into the problem of trusting currently set cookies in the = browser=20 (even when we're actually sending a username/password and really do want = to have=20 an authentication).
 
I'm a +1 on the force_auth = proposal.

From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] On Behalf Of Colin=20 Snover
Sent: Tuesday, July 13, 2010 9:23 AM
To: = Eran=20 Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] = '=20 force_auth' request parameter

On 22/07/28164 13:59, Eran Hammer-Lahav wrote:=20
The following was submitted via the = shared-copy page=20 but does not belong with editorial feedback. This needs to be = discussed and=20 supported on the list before added the specification. I think it = belongs=20 where =91immediate=92 is specified.

EHL

------ = Forwarded=20 Message
From: An anonymous reader <mailman@sharedcopy.com>
Date: = Sat,=20 10 Jul 2010 11:01:11 -0700
To: Eran Hammer-Lahav <eran@hueniverse.com>
Subject: = Re:=20 draft-ietf-oauth-v2-09 - The OAuth 2.0=20 Protocol
 "Colin Snover" left these = comments on=20 your copy:
 
draft-ietf-oauth-v2-09 - The OAuth = 2.0 Protocol=20 <http://r6.sharedcopy.com/6bnqq8v>=20
        

  = ;   As=20 proposed on the ML, a new parameter to counteract the current = behaviour of=20 OAuth 1.0a authorization servers which is to assume that the = account=20 logged into the user-agent is the account that should be checked = for=20 = access:

force_auth
       &n= bsp; OPTIONAL.=20 The parameter value must be set to "true" or=20 = "false".

         If = set to "true", the authorization server MUST prompt the end-user = to=20 authenticate and approve access. The authorization server MUST NOT = make=20 any assumptions as to the identity of the entity requesting = access, even=20 if another automatic mechanism is available to do so (e.g. browser = = cookies).

         If= =20 set to "false" or not present, the authorization server MAY = automatically=20 grant access to the client if it is able to determine that access = was=20 previously granted. =         link =BB=20 <http://r6.sharedcopy.com/6bnqq8v#shcp21> =
 

tools.ietf.org/html/draft-ietf-oauth-v2-09 = <http://r6.sharedcopy.com/6bnqq8v> =  =B7=20 Original page <http://tools.ietf.org/html/draft-ietf-oauth-v2-0= 9>=20
  
 
via sharedcopy.com <http://sharedcopy.com/?ef>=20  

------ End of Forwarded=20 Message

Hi Eran,

Sorry if = that was=20 not the right place for that to go; I didn=92t know what else to do. I = have=20 tried to solicit feedback from the ML regarding this parameter twice = and=20 nobody seems very keen in providing any, which is kind of a bummer. I = waited=20 until the last possible moment to add it in the hopes that someone = would=20 notice my messages and discuss it, but you made it sound like your = plan was=20 for draft 10 to be potentially final so I wanted to get it in before = the=20 deadline.

I=92m sure this is not a big deal for most = applications that=20 expect at most a single connection, but for me this is a huge deal = since it=20 completely immolates our application=92s authentication flow, and I = can=92t go to=20 every provider asking them to please change the way they implement the = authentication portion of their OAuth API.

In contrast to = =91immediate=92,=20 which had some concerns vis =E0 vis security, force_auth is actually = safer than=20 the current normal flow used by most OAuth providers since it requires = the=20 provider to make no guesses about who is trying to authorize the=20 app.

Frankly, I think that OAuth providers do the wrong thing = now in=20 all cases by assuming that browser cookies are a safe way of = confirming the=20 identity of the end-user making an authorization request (they = aren=92t!), but=20 the spec says the way the authorization server authenticates the = end-user is=20 outside the scope of the spec. I have no objection to this=97OAuth = *should* be=20 authentication-agnostic=97but at the same time this is a very real and = present=20 implementation flaw and the only way to solve it is to make sure the = spec=20 defines a way for an application to say =93hey, I know you *think* you = know who=20 should be authenticated, but *I* know that the user has requested to = connect a=20 *new* account, so don=92t use any automatic authentication = method=94.

I=20 think it is incredibly important that the OAuth spec gets providers to = distinguish between automatic & potentially unsafe authentication = methods=20 (like session cookies) versus more =93guaranteed=94 authentication = (like=20 password), especially since 99.999% of the time OAuth relies on the = end-user=92s=20 Web browser which is all but guaranteed to contain some cookies for = the=20 provider that are unrelated to the requesting=20 application.

Examples:

1. Multiple end-users with = malicious=20 intent. User 1 is logged into their Facetweetr account. User 2 wants = to do bad=20 things using User 1=92s account. Because the user-agent has cookies = for user 1,=20 user 2 gets to authorize their account with our app. Even when user 1 = changes=20 their password, unless the provider automatically invalidates their = existing=20 connections (the spec does not even mention doing this in an = informative=20 manner as far as I can tell), they are almost certainly unaware that = the=20 linked application is still able to perform actions on their = behalf.

2.=20 Single end-user with multiple accounts. User is logged into = Facetweetr=20 account 1, but they want to authorize account 2. They go to authorize = the=20 application and are presented with a confirmation for account 1. They = log out=20 (because this is the only way to switch accounts on the provider) and = suddenly=20 the authorization flow is dropped on the floor. The user may not know=20 immediately what they need to do at this point. They will need to = manually=20 return to the original application and restart the authorization=20 request.

3. User has two accounts that they want to authorize = with a=20 provider. User authorizes account 1 successfully, then wants to = authorize=20 account 2. Because account 1 is still logged in, and because the = application=20 already has a link to the account, it automatically redirects back to = the=20 application=92s redirection URI. In order for the user to get what = they want,=20 they are forced to manually navigate to the provider=92s site, log = out, *then*=20 begin the authorization request.

These aren=92t imaginary = scenarios; they=20 are things that are going on *right now* with several different OAuth=20 providers.

The original request: <htt= p://www.mail-archive.com/oauth@ietf.org/msg02331.html>

Rega= rds,
--=20
Colin Snover
http://zetafleet.com
------_=_NextPart_001_01CB22AB.B195F3F2-- From wmills@yahoo-inc.com Tue Jul 13 09:55:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604C23A69BC for ; Tue, 13 Jul 2010 09:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.543 X-Spam-Level: X-Spam-Status: No, score=-17.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbrfT8KPL-xo for ; Tue, 13 Jul 2010 09:55:44 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 679EA3A680D for ; Tue, 13 Jul 2010 09:55:44 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6DGtTfP007026; Tue, 13 Jul 2010 09:55:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:return-path:x-originalarrivaltime; b=feHMgQKCKxEi2nDuBPDRIjNHAT3utM1ztqYGMrrKqmZCxRg76Afdb+Nip0OdbO/6 Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 09:55:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB22AC.1968DB2A" Date: Tue, 13 Jul 2010 09:54:46 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6C13@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] expired_token error code Thread-Index: AcsiUMwJ2a6PtfxDTWCpfid8P4tomAARcVeqAAVSjzA= References: From: "William Mills" To: "Eran Hammer-Lahav" , "Brian Eaton" , "OAuth WG" , X-OriginalArrivalTime: 13 Jul 2010 16:55:29.0842 (UTC) FILETIME=[332BD120:01CB22AC] Subject: Re: [OAUTH-WG] expired_token error code X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:55:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB22AC.1968DB2A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable +1 ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, July 13, 2010 7:21 AM To: Brian Eaton; OAuth WG; b@google.com Subject: Re: [OAUTH-WG] expired_token error code =09 =09 I'm fine with this. Any objections? =09 EHL =09 =09 On 7/12/10 11:01 PM, "Brian Eaton" wrote: =09 =09 =09 http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.2.1 =09 The "expired_token" error code doesn't scale well and won't be implemented reliably. It should be merged with "invalid_token". =09 Suggested language: =09 invalid_token The access token provided is invalid. Resource servers SHOULD use this error code when receiving a token which is expired, revoked, malformed, or invalid for other reasons. The resource server MUST respond with the HTTP 401 (Unauthorized) status code. The client MAY request a new access token and retry the protected resource request. =09 =09 "expired_token" can't be implemented reliably for a few reasons. =09 1) If you're using server-side storage of tokens (which you need to do if you want to keep your tokens very short...) you have to throw away tokens after they expire. Just because you can't validate the token doesn't mean the client can't refresh the token. =09 2) If you're using cryptographic access tokens, you need to throw away your old token signing keys at some point. Again, just because you can't validate a token doesn't mean the client can't refresh the token. =09 3) One common deployment model will have limited communication between authorization servers and protected resource servers. The protected resource server might not be able to contact the authorization server to figure out whether refresh tokens are available or not. =09 4) The access token may not have enough information in it to look-up the corresponding refresh token and see if it's still valid. Remembering that information requires extra space in the access token for cryptographic token implementations. Space is tight. =09 Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =09 =09 ------_=_NextPart_001_01CB22AC.1968DB2A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] expired_token error code
+1
From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] On Behalf Of Eran=20 Hammer-Lahav
Sent: Tuesday, July 13, 2010 7:21 = AM
To:=20 Brian Eaton; OAuth WG; b@google.com
Subject: Re: [OAUTH-WG]=20 expired_token error code

I’m fine with this. Any=20 objections?

EHL


On 7/12/10 11:01 PM, "Brian Eaton" = <beaton@google.com>=20 wrote:
= http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.2.1
The=20 "expired_token" error code doesn't scale well and won't = be
implemented=20 reliably.  It should be merged with = "invalid_token".

Suggested=20 = language:

invalid_token
      &nb= sp;  The=20 access token provided is invalid.  Resource servers
SHOULD = use this=20 error code when receiving a token which is expired,
revoked, = malformed,=20 or invalid for other reasons.  The resource server
MUST = respond with=20 the HTTP 401 (Unauthorized) status code.  The client
MAY = request a=20 new access token and retry the protected=20 resource
request.


"expired_token" can't be implemented = reliably for a few reasons.

1) If you're using server-side = storage of=20 tokens (which you need to do
if you want to keep your tokens very = short...) you have to throw away
tokens after they expire. =  Just=20 because you can't validate the token
doesn't mean the client = can't=20 refresh the token.

2) If you're using cryptographic access = tokens,=20 you need to throw away
your old token signing keys at some point. =  Again, just because you
can't validate a token doesn't mean = the=20 client can't refresh the
token.

3) One common deployment = model=20 will have limited communication between
authorization servers and = protected resource servers.  The protected
resource server = might not=20 be able to contact the authorization server
to figure out whether = refresh=20 tokens are available or not.

4) The access token may not have = enough=20 information in it to look-up
the corresponding refresh token and = see if=20 it's still valid.
Remembering that information requires extra = space in=20 the access token
for cryptographic token implementations. =  Space is=20 = tight.

Cheers,
Brian
_______________________________________= ________
OAuth=20 mailing list
OAuth@ietf.org
https://www.ietf.org= /mailman/listinfo/oauth

------_=_NextPart_001_01CB22AC.1968DB2A-- From recordond@gmail.com Tue Jul 13 09:57:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F41C53A6824 for ; Tue, 13 Jul 2010 09:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9V9iSP4Y-9V for ; Tue, 13 Jul 2010 09:57:30 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CDAD23A68AF for ; Tue, 13 Jul 2010 09:57:29 -0700 (PDT) Received: by iwn38 with SMTP id 38so6302867iwn.31 for ; Tue, 13 Jul 2010 09:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kBM3JQEiI8nUiTUH80Xbo9TzoTmlcTtybZ++DbhRJYE=; b=HTz1md676em0KJXIMWjpycKEysnrFEgklDXjkyGlXRCj36TUhbCstEIMiNQDFs/ylB btSko+Qa9d8WmfjqBG1l1+ZsDkSR1L82G+RBbKConFhGnPhIZUavcdEX6oHZHJQKObFZ cNaaou5g2rTZ8skmsGSK4hdb9++CdL7fb726I= 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=DG4flYzk+YJxLVQEWiUUpaHB+WQOWt0+7rqsjmQv0WmtMGghp5qIsPFQncjfmbsd/6 2N96xDZwxz7cvqWbEmj3nQjwexkZiiOz6gz6k5d7xbiNZN4ge8UVzeqpY1QEUGK9auFb VEkJ4/x3ed8coDk1lctx/UAGKTW6CB8esqmxA= MIME-Version: 1.0 Received: by 10.231.14.194 with SMTP id h2mr16791771iba.67.1279040258052; Tue, 13 Jul 2010 09:57:38 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Tue, 13 Jul 2010 09:57:37 -0700 (PDT) In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6C12@SNV-EXVS08.ds.corp.yahoo.com> References: <4C3C92D2.80209@zetafleet.com> <012AB2B223CB3F4BB846962876F47217059B6C12@SNV-EXVS08.ds.corp.yahoo.com> Date: Tue, 13 Jul 2010 09:57:37 -0700 Message-ID: From: David Recordon To: William Mills Content-Type: multipart/alternative; boundary=00221534d2673c32fa048b47c4a3 Cc: Colin Snover , OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:57:32 -0000 --00221534d2673c32fa048b47c4a3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I support immediate and a form of forced auth (ala OpenID's PAPE) but not i= n the core spec. They both should be part of an identity extension. On Tue, Jul 13, 2010 at 9:51 AM, William Mills wrote= : > I agree with Colin that some form of force_auth is needed. I haven't > read enough on the "immediate" proposal, but I know that we have run into > the problem of trusting currently set cookies in the browser (even when > we're actually sending a username/password and really do want to have an > authentication). > > I'm a +1 on the force_auth proposal. > > ------------------------------ > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Colin Snover > *Sent:* Tuesday, July 13, 2010 9:23 AM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] ' force_auth' request parameter > > On 22/07/28164 13:59, Eran Hammer-Lahav wrote: > > The following was submitted via the shared-copy page but does not belong > with editorial feedback. This needs to be discussed and supported on the > list before added the specification. I think it belongs where =91immediat= e=92 is > specified. > > EHL > > ------ Forwarded Message > > *From: *An anonymous reader > *Date: *Sat, 10 Jul 2010 11:01:11 -0700 > *To: *Eran Hammer-Lahav > *Subject: *Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol > > > *"Colin Snover"* left these comments on your copy: > > *draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol < > http://r6.sharedcopy.com/6bnqq8v> > * > > As proposed on the ML, a new parameter to counteract the current > behaviour of OAuth 1.0a authorization servers which is to assume that the > account logged into the user-agent is the account that should be checked = for > access: > > force_auth > OPTIONAL. The parameter value must be set to "true" or "false". > > If set to "true", the authorization server MUST prompt the > end-user to authenticate and approve access. The authorization server MUS= T > NOT make any assumptions as to the identity of the entity requesting acce= ss, > even if another automatic mechanism is available to do so (e.g. browser > cookies). > > If set to "false" or not present, the authorization server MAY > automatically grant access to the client if it is able to determine that > access was previously granted. link =BB < > http://r6.sharedcopy.com/6bnqq8v#shcp21> > > > tools.ietf.org/html/draft-ietf-oauth-v2-09 < > http://r6.sharedcopy.com/6bnqq8v> =B7 Original page < > http://tools.ietf.org/html/draft-ietf-oauth-v2-09> > > > ------------------------------ > via sharedcopy.com > > > ------ End of Forwarded Message > > > Hi Eran, > > Sorry if that was not the right place for that to go; I didn=92t know wha= t > else to do. I have tried to solicit feedback from the ML regarding this > parameter twice and nobody seems very keen in providing any, which is kin= d > of a bummer. I waited until the last possible moment to add it in the hop= es > that someone would notice my messages and discuss it, but you made it sou= nd > like your plan was for draft 10 to be potentially final so I wanted to ge= t > it in before the deadline. > > I=92m sure this is not a big deal for most applications that expect at mo= st a > single connection, but for me this is a huge deal since it completely > immolates our application=92s authentication flow, and I can=92t go to ev= ery > provider asking them to please change the way they implement the > authentication portion of their OAuth API. > > In contrast to =91immediate=92, which had some concerns vis =E0 vis secur= ity, > force_auth is actually safer than the current normal flow used by most OA= uth > providers since it requires the provider to make no guesses about who is > trying to authorize the app. > > Frankly, I think that OAuth providers do the wrong thing now in all cases > by assuming that browser cookies are a safe way of confirming the identit= y > of the end-user making an authorization request (they aren=92t!), but the= spec > says the way the authorization server authenticates the end-user is outsi= de > the scope of the spec. I have no objection to this=97OAuth *should* be > authentication-agnostic=97but at the same time this is a very real and pr= esent > implementation flaw and the only way to solve it is to make sure the spec > defines a way for an application to say =93hey, I know you *think* you kn= ow > who should be authenticated, but *I* know that the user has requested to > connect a *new* account, so don=92t use any automatic authentication meth= od=94. > > I think it is incredibly important that the OAuth spec gets providers to > distinguish between automatic & potentially unsafe authentication methods > (like session cookies) versus more =93guaranteed=94 authentication (like > password), especially since 99.999% of the time OAuth relies on the > end-user=92s Web browser which is all but guaranteed to contain some cook= ies > for the provider that are unrelated to the requesting application. > > Examples: > > 1. Multiple end-users with malicious intent. User 1 is logged into their > Facetweetr account. User 2 wants to do bad things using User 1=92s accoun= t. > Because the user-agent has cookies for user 1, user 2 gets to authorize > their account with our app. Even when user 1 changes their password, unle= ss > the provider automatically invalidates their existing connections (the sp= ec > does not even mention doing this in an informative manner as far as I can > tell), they are almost certainly unaware that the linked application is > still able to perform actions on their behalf. > > 2. Single end-user with multiple accounts. User is logged into Facetweetr > account 1, but they want to authorize account 2. They go to authorize the > application and are presented with a confirmation for account 1. They log > out (because this is the only way to switch accounts on the provider) and > suddenly the authorization flow is dropped on the floor. The user may not > know immediately what they need to do at this point. They will need to > manually return to the original application and restart the authorization > request. > > 3. User has two accounts that they want to authorize with a provider. Use= r > authorizes account 1 successfully, then wants to authorize account 2. > Because account 1 is still logged in, and because the application already > has a link to the account, it automatically redirects back to the > application=92s redirection URI. In order for the user to get what they w= ant, > they are forced to manually navigate to the provider=92s site, log out, *= then* > begin the authorization request. > > These aren=92t imaginary scenarios; they are things that are going on *ri= ght > now* with several different OAuth providers. > > The original request: > > > Regards, > > -- > Colin Snoverhttp://zetafleet.com > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00221534d2673c32fa048b47c4a3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I support immediate and a form of forced auth (ala OpenID's PAPE) but n= ot in the core spec. They both should be part of an identity extension.

On Tue, Jul 13, 2010 at 9:51 AM, Willia= m Mills <wmill= s@yahoo-inc.com> wrote:
I agree with Colin that some form of force_auth is=20 needed.=A0 I haven't read enough on the "immediate" proposal,= but I know that=20 we have run into the problem of trusting currently set cookies in the brows= er=20 (even when we're actually sending a username/password and really do wan= t to have=20 an authentication).
=A0
I'm a +1 on the force_auth proposal.
From: oauth-bounces@ietf.org=20 [mailto:oauth= -bounces@ietf.org] On Behalf Of Colin=20 Snover
Sent: Tuesday, July 13, 2010 9:23 AM
To: Eran= =20 Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] = 9;=20 force_auth' request parameter

On 22/07/28164 13:59, Eran Hammer-Lahav wrote:=20
The following was submitted via the share= d-copy page=20 but does not belong with editorial feedback. This needs to be discussed= and=20 supported on the list before added the specification. I think it belong= s=20 where =91immediate=92 is specified.

EHL

------ Forwarded= =20 Message
From: An anonymous reader <mailman@sharedcopy.com><= br> Date: Sat,=20 10 Jul 2010 11:01:11 -0700
To: Eran Hammer-Lahav <eran@hueniverse.com&= gt;
Subject: Re:=20 draft-ietf-oauth-v2-09 - The OAuth 2.0=20 Protocol
=A0"Colin Snover" left these comment= s on=20 your copy:
=A0
draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol=20 <ht= tp://r6.sharedcopy.com/6bnqq8v>=20
=A0=A0=A0=A0=A0= =A0=A0=A0

=A0=A0=A0=A0=A0As=20 proposed on the ML, a new parameter to counteract the current behavio= ur of=20 OAuth 1.0a authorization servers which is to assume that the account= =20 logged into the user-agent is the account that should be checked for= =20 access:

force_auth
=A0=A0=A0=A0=A0=A0=A0=A0=A0OPTIONAL.=20 The parameter value must be set to "true" or=20 "false".

=A0=A0=A0=A0=A0=A0=A0=A0=A0If=20 set to "true", the authorization server MUST prompt the end= -user to=20 authenticate and approve access. The authorization server MUST NOT ma= ke=20 any assumptions as to the identity of the entity requesting access, e= ven=20 if another automatic mechanism is available to do so (e.g. browser=20 cookies).

=A0=A0=A0=A0=A0=A0=A0=A0=A0If=20 set to "false" or not present, the authorization server MAY= automatically=20 grant access to the client if it is able to determine that access was= =20 previously granted. =A0=A0=A0=A0=A0=A0=A0=A0link =BB=20 <http://r6.sharedcopy.com/6bnqq8v#shcp21>=20
=A0

tools.ietf.org/html/draft-ietf-oauth-v2-09 &l= t;http://r6.= sharedcopy.com/6bnqq8v> =A0=B7=20 Original page <http://tools.ietf.org/html/draft-ietf-oauth-v2= -09>=20
=A0=A0
=A0
via sharedcopy.co= m <http://sh= aredcopy.com/?ef>=20 =A0

------ End of Forwarded= =20 Message

Hi Eran,

Sorry if that w= as=20 not the right place for that to go; I didn=92t know what else to do. I ha= ve=20 tried to solicit feedback from the ML regarding this parameter twice and= =20 nobody seems very keen in providing any, which is kind of a bummer. I wai= ted=20 until the last possible moment to add it in the hopes that someone would= =20 notice my messages and discuss it, but you made it sound like your plan w= as=20 for draft 10 to be potentially final so I wanted to get it in before the= =20 deadline.

I=92m sure this is not a big deal for most applications = that=20 expect at most a single connection, but for me this is a huge deal since = it=20 completely immolates our application=92s authentication flow, and I can= =92t go to=20 every provider asking them to please change the way they implement the=20 authentication portion of their OAuth API.

In contrast to =91immed= iate=92,=20 which had some concerns vis =E0 vis security, force_auth is actually safe= r than=20 the current normal flow used by most OAuth providers since it requires th= e=20 provider to make no guesses about who is trying to authorize the=20 app.

Frankly, I think that OAuth providers do the wrong thing now = in=20 all cases by assuming that browser cookies are a safe way of confirming t= he=20 identity of the end-user making an authorization request (they aren=92t!)= , but=20 the spec says the way the authorization server authenticates the end-user= is=20 outside the scope of the spec. I have no objection to this=97OAuth *shoul= d* be=20 authentication-agnostic=97but at the same time this is a very real and pr= esent=20 implementation flaw and the only way to solve it is to make sure the spec= =20 defines a way for an application to say =93hey, I know you *think* you kn= ow who=20 should be authenticated, but *I* know that the user has requested to conn= ect a=20 *new* account, so don=92t use any automatic authentication method=94.
=
I=20 think it is incredibly important that the OAuth spec gets providers to=20 distinguish between automatic & potentially unsafe authentication met= hods=20 (like session cookies) versus more =93guaranteed=94 authentication (like= =20 password), especially since 99.999% of the time OAuth relies on the end-u= ser=92s=20 Web browser which is all but guaranteed to contain some cookies for the= =20 provider that are unrelated to the requesting=20 application.

Examples:

1. Multiple end-users with malicious= =20 intent. User 1 is logged into their Facetweetr account. User 2 wants to d= o bad=20 things using User 1=92s account. Because the user-agent has cookies for u= ser 1,=20 user 2 gets to authorize their account with our app. Even when user 1 cha= nges=20 their password, unless the provider automatically invalidates their exist= ing=20 connections (the spec does not even mention doing this in an informative= =20 manner as far as I can tell), they are almost certainly unaware that the= =20 linked application is still able to perform actions on their behalf.
<= br>2.=20 Single end-user with multiple accounts.=A0User is logged into Facetweetr= =20 account 1, but they want to authorize account 2. They go to authorize the= =20 application and are presented with a confirmation for account 1. They log= out=20 (because this is the only way to switch accounts on the provider) and sud= denly=20 the authorization flow is dropped on the floor. The user may not know=20 immediately what they need to do at this point. They will need to manuall= y=20 return to the original application and restart the authorization=20 request.

3. User has two accounts that they want to authorize with= a=20 provider. User authorizes account 1 successfully, then wants to authorize= =20 account 2. Because account 1 is still logged in, and because the applicat= ion=20 already has a link to the account, it automatically redirects back to the= =20 application=92s redirection URI. In order for the user to get what they w= ant,=20 they are forced to manually navigate to the provider=92s site, log out, *= then*=20 begin the authorization request.

These aren=92t imaginary scenario= s; they=20 are things that are going on *right now* with several different OAuth=20 providers.

The original request: <http://www.mail-a= rchive.com/oauth@ietf.org/msg02331.html>

Regards,
--=20
Colin Snover
http://zetafleet.com

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


--00221534d2673c32fa048b47c4a3-- From jhart@photobucket.com Tue Jul 13 10:01: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 AC51E3A680D for ; Tue, 13 Jul 2010 10:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HUS-ErFml9j for ; Tue, 13 Jul 2010 10:01:00 -0700 (PDT) Received: from EXHUB003-3.exch003intermedia.net (exhub003-3.exch003intermedia.net [207.5.74.110]) by core3.amsl.com (Postfix) with ESMTP id AF1FB3A68AF for ; Tue, 13 Jul 2010 10:01:00 -0700 (PDT) Received: from EXVMBX003-4.exch003intermedia.net ([207.5.74.44]) by EXHUB003-3.exch003intermedia.net ([207.5.74.110]) with mapi; Tue, 13 Jul 2010 10:01:09 -0700 From: Justin Hart To: William Mills Date: Tue, 13 Jul 2010 10:01:08 -0700 Thread-Topic: [OAUTH-WG] ' force_auth' request parameter Thread-Index: AcsirP2mLMaxXOTbQgKlWHTQJzDsUg== Message-ID: <1357DC5A-BC26-4F62-80C9-927D6615FD41@photobucket.com> References: <4C3C92D2.80209@zetafleet.com> <012AB2B223CB3F4BB846962876F47217059B6C12@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6C12@SNV-EXVS08.ds.corp.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1357DC5ABC264F6280C9927D6615FD41photobucketcom_" MIME-Version: 1.0 Cc: Colin Snover , OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:01:02 -0000 --_000_1357DC5ABC264F6280C9927D6615FD41photobucketcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1, though I would like to see it to be a little more specific. Essentiall= y there are four states. 'accept' (allow all cookies and consent as presen= t in browser - for example how Facebook currently works), 'consent' (accept= login, but still prompt for the allow/deny consent - for example, how twit= ter currently works), 'login' (don't accept login, but bypass the allow/den= y consent), 'force' (don't accept login or consent). The 'login' state cou= ld probably be dropped and 'force' used instead. ---- -- Justin Hart -- jhart@photobucket.com On Jul 13, 2010, at 10:51 AM, William Mills wrote: I agree with Colin that some form of force_auth is needed. I haven't read = enough on the "immediate" proposal, but I know that we have run into the pr= oblem of trusting currently set cookies in the browser (even when we're act= ually sending a username/password and really do want to have an authenticat= ion). I'm a +1 on the force_auth proposal. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Colin Snover Sent: Tuesday, July 13, 2010 9:23 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter On 22/07/28164 13:59, Eran Hammer-Lahav wrote: The following was submitted via the shared-copy page but does not belong wi= th editorial feedback. This needs to be discussed and supported on the list= before added the specification. I think it belongs where =91immediate=92 i= s specified. EHL ------ Forwarded Message From: An anonymous reader > Date: Sat, 10 Jul 2010 11:01:11 -0700 To: Eran Hammer-Lahav > Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol "Colin Snover" left these comments on your copy: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol As proposed on the ML, a new parameter to counteract the current behav= iour of OAuth 1.0a authorization servers which is to assume that the accoun= t logged into the user-agent is the account that should be checked for acce= ss: force_auth OPTIONAL. The parameter value must be set to "true" or "false". If set to "true", the authorization server MUST prompt the end-use= r to authenticate and approve access. The authorization server MUST NOT mak= e any assumptions as to the identity of the entity requesting access, even = if another automatic mechanism is available to do so (e.g. browser cookies)= . If set to "false" or not present, the authorization server MAY aut= omatically grant access to the client if it is able to determine that acces= s was previously granted. link =BB tools.ietf.org/html/draft-ietf-oauth-v2-09 =B7 Original page ________________________________ via sharedcopy.com ------ End of Forwarded Message Hi Eran, Sorry if that was not the right place for that to go; I didn=92t know what = else to do. I have tried to solicit feedback from the ML regarding this par= ameter twice and nobody seems very keen in providing any, which is kind of = a bummer. I waited until the last possible moment to add it in the hopes th= at someone would notice my messages and discuss it, but you made it sound l= ike your plan was for draft 10 to be potentially final so I wanted to get i= t in before the deadline. I=92m sure this is not a big deal for most applications that expect at most= a single connection, but for me this is a huge deal since it completely im= molates our application=92s authentication flow, and I can=92t go to every = provider asking them to please change the way they implement the authentica= tion portion of their OAuth API. In contrast to =91immediate=92, which had some concerns vis =E0 vis securit= y, force_auth is actually safer than the current normal flow used by most O= Auth providers since it requires the provider to make no guesses about who = is trying to authorize the app. Frankly, I think that OAuth providers do the wrong thing now in all cases b= y assuming that browser cookies are a safe way of confirming the identity o= f the end-user making an authorization request (they aren=92t!), but the sp= ec says the way the authorization server authenticates the end-user is outs= ide the scope of the spec. I have no objection to this=97OAuth *should* be = authentication-agnostic=97but at the same time this is a very real and pres= ent implementation flaw and the only way to solve it is to make sure the sp= ec defines a way for an application to say =93hey, I know you *think* you k= now who should be authenticated, but *I* know that the user has requested t= o connect a *new* account, so don=92t use any automatic authentication meth= od=94. I think it is incredibly important that the OAuth spec gets providers to di= stinguish between automatic & potentially unsafe authentication methods (li= ke session cookies) versus more =93guaranteed=94 authentication (like passw= ord), especially since 99.999% of the time OAuth relies on the end-user=92s= Web browser which is all but guaranteed to contain some cookies for the pr= ovider that are unrelated to the requesting application. Examples: 1. Multiple end-users with malicious intent. User 1 is logged into their Fa= cetweetr account. User 2 wants to do bad things using User 1=92s account. B= ecause the user-agent has cookies for user 1, user 2 gets to authorize thei= r account with our app. Even when user 1 changes their password, unless the= provider automatically invalidates their existing connections (the spec do= es not even mention doing this in an informative manner as far as I can tel= l), they are almost certainly unaware that the linked application is still = able to perform actions on their behalf. 2. Single end-user with multiple accounts. User is logged into Facetweetr a= ccount 1, but they want to authorize account 2. They go to authorize the ap= plication and are presented with a confirmation for account 1. They log out= (because this is the only way to switch accounts on the provider) and sudd= enly the authorization flow is dropped on the floor. The user may not know = immediately what they need to do at this point. They will need to manually = return to the original application and restart the authorization request. 3. User has two accounts that they want to authorize with a provider. User = authorizes account 1 successfully, then wants to authorize account 2. Becau= se account 1 is still logged in, and because the application already has a = link to the account, it automatically redirects back to the application=92s= redirection URI. In order for the user to get what they want, they are for= ced to manually navigate to the provider=92s site, log out, *then* begin th= e authorization request. These aren=92t imaginary scenarios; they are things that are going on *righ= t now* with several different OAuth providers. The original request: Regards, -- Colin Snover http://zetafleet.com --_000_1357DC5ABC264F6280C9927D6615FD41photobucketcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1, though I would like to= see it to be a little more specific.  Essentially there are four stat= es.  'accept' (allow all cookies and consent as present in browser - f= or example how Facebook currently works), 'consent' (accept login, but stil= l prompt for the allow/deny consent - for example, how twitter currently wo= rks), 'login' (don't accept login, but bypass the allow/deny consent), 'for= ce' (don't accept login or consent).  The 'login' state could probably= be dropped and 'force' used instead.
----
-- Justin Hart



=


On Jul 13, 2010, at 10:51 AM, William Mills wrote:

I agree with Colin that some form= of force_auth is=20 needed.  I haven't read enough on the "immediate" proposal, but I know= that=20 we have run into the problem of trusting currently set cookies in the brows= er=20 (even when we're actually sending a username/password and really do want to= have=20 an authentication).
 
I'm a +1 on the force_auth propos= al.

From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] On Behalf Of Colin=20 Snover
Sent: Tuesday, July 13, 2010 9:23 AM
To: Eran= =20 Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] '=20 force_auth' request parameter

On 22/07/28164 13:59, Eran Hammer-Lahav wrote:=20
The following was submitted via the shared-copy page=20 but does not belong with editorial feedback. This needs to be discussed= and=20 supported on the list before added the specification. I think it belong= s=20 where =91immediate=92 is specified.

EHL

------ Forwarded= =20 Message
From: An anonymous reader <mailman@sharedcopy.= com>
Date: Sat,=20 10 Jul 2010 11:01:11 -0700
To: Eran Hammer-Lahav <eran@hueniver= se.com>
Subject: Re:=20 draft-ietf-oauth-v2-09 - The OAuth 2.0=20 Protocol
 "Colin Snover" left these comments on=20 your copy:
 
draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol=20 <http://r6.sharedcopy.com/6bnqq8v>=20
  &nb= sp;     

     As=20 proposed on the ML, a new parameter to counteract the current behavio= ur of=20 OAuth 1.0a authorization servers which is to assume that the account= =20 logged into the user-agent is the account that should be checked for= =20 access:

force_auth
      &nbs= p;  OPTIONAL.=20 The parameter value must be set to "true" or=20 "false".

         = ;If=20 set to "true", the authorization server MUST prompt the end-user to=20 authenticate and approve access. The authorization server MUST NOT ma= ke=20 any assumptions as to the identity of the entity requesting access, e= ven=20 if another automatic mechanism is available to do so (e.g. browser=20 cookies).

        &nbs= p;If=20 set to "false" or not present, the authorization server MAY automatic= ally=20 grant access to the client if it is able to determine that access was= =20 previously granted.         l= ink =BB=20 <http://r6.sharedcopy.com/6bnqq8v#shcp21>=20
 

tools.ietf.org/html/draft-ietf-oauth-v2-09 <http://r6.sharedco= py.com/6bnqq8v>  =B7=20 Original page <http://tools.ietf.org/html/draft-ietf-o= auth-v2-09>=20
  
 
via sharedcopy.com <http://sharedcopy.c= om/?ef>=20  

------ End of Forward= ed=20 Message

Hi Eran,

Sorry if that w= as=20 not the right place for that to go; I didn=92t know what else to do. I ha= ve=20 tried to solicit feedback from the ML regarding this parameter twice and= =20 nobody seems very keen in providing any, which is kind of a bummer. I wai= ted=20 until the last possible moment to add it in the hopes that someone would= =20 notice my messages and discuss it, but you made it sound like your plan w= as=20 for draft 10 to be potentially final so I wanted to get it in before the= =20 deadline.

I=92m sure this is not a big deal for most applications = that=20 expect at most a single connection, but for me this is a huge deal since = it=20 completely immolates our application=92s authentication flow, and I can= =92t go to=20 every provider asking them to please change the way they implement the=20 authentication portion of their OAuth API.

In contrast to =91immed= iate=92,=20 which had some concerns vis =E0 vis security, force_auth is actually safe= r than=20 the current normal flow used by most OAuth providers since it requires th= e=20 provider to make no guesses about who is trying to authorize the=20 app.

Frankly, I think that OAuth providers do the wrong thing now = in=20 all cases by assuming that browser cookies are a safe way of confirming t= he=20 identity of the end-user making an authorization request (they aren=92t!)= , but=20 the spec says the way the authorization server authenticates the end-user= is=20 outside the scope of the spec. I have no objection to this=97OAuth *shoul= d* be=20 authentication-agnostic=97but at the same time this is a very real and pr= esent=20 implementation flaw and the only way to solve it is to make sure the spec= =20 defines a way for an application to say =93hey, I know you *think* you kn= ow who=20 should be authenticated, but *I* know that the user has requested to conn= ect a=20 *new* account, so don=92t use any automatic authentication method=94.
=
I=20 think it is incredibly important that the OAuth spec gets providers to=20 distinguish between automatic & potentially unsafe authentication met= hods=20 (like session cookies) versus more =93guaranteed=94 authentication (like= =20 password), especially since 99.999% of the time OAuth relies on the end-u= ser=92s=20 Web browser which is all but guaranteed to contain some cookies for the=20 provider that are unrelated to the requesting=20 application.

Examples:

1. Multiple end-users with malicious= =20 intent. User 1 is logged into their Facetweetr account. User 2 wants to d= o bad=20 things using User 1=92s account. Because the user-agent has cookies for u= ser 1,=20 user 2 gets to authorize their account with our app. Even when user 1 cha= nges=20 their password, unless the provider automatically invalidates their exist= ing=20 connections (the spec does not even mention doing this in an informative= =20 manner as far as I can tell), they are almost certainly unaware that the= =20 linked application is still able to perform actions on their behalf.
<= br>2.=20 Single end-user with multiple accounts. User is logged into Facetwee= tr=20 account 1, but they want to authorize account 2. They go to authorize the= =20 application and are presented with a confirmation for account 1. They log= out=20 (because this is the only way to switch accounts on the provider) and sud= denly=20 the authorization flow is dropped on the floor. The user may not know=20 immediately what they need to do at this point. They will need to manuall= y=20 return to the original application and restart the authorization=20 request.

3. User has two accounts that they want to authorize with= a=20 provider. User authorizes account 1 successfully, then wants to authorize= =20 account 2. Because account 1 is still logged in, and because the applicat= ion=20 already has a link to the account, it automatically redirects back to the= =20 application=92s redirection URI. In order for the user to get what they w= ant,=20 they are forced to manually navigate to the provider=92s site, log out, *= then*=20 begin the authorization request.

These aren=92t imaginary scenario= s; they=20 are things that are going on *right now* with several different OAuth=20 providers.

The original request: <htt= p://www.mail-archive.com/oauth@ietf.org/msg02331.html>

Regard= s,
--=20
Colin Snover
http://ze=
tafleet.com
<ATT00001..txt>

= --_000_1357DC5ABC264F6280C9927D6615FD41photobucketcom_-- From wmills@yahoo-inc.com Tue Jul 13 10:05:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4333A6824 for ; Tue, 13 Jul 2010 10:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.55 X-Spam-Level: X-Spam-Status: No, score=-17.55 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6H8F0KKghtR for ; Tue, 13 Jul 2010 10:05:15 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id AE38A3A69E5 for ; Tue, 13 Jul 2010 10:05:15 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6DH2Vjj009602; Tue, 13 Jul 2010 10:02:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=IbHbZxJt2ipQfcy15m5xDW2P6t++7DgMGpapTzInvVWds83PaUqUspCTLrMP3VbB Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 10:02:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB22AD.2822C0BC" Date: Tue, 13 Jul 2010 10:02:20 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6C16@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] ' force_auth' request parameter Thread-Index: AcsirI6pMXUa8X0DQaGXduCKRIxSywAAIoYg References: <4C3C92D2.80209@zetafleet.com><012AB2B223CB3F4BB846962876F47217059B6C12@SNV-EXVS08.ds.corp.yahoo.com> From: "William Mills" To: "David Recordon" X-OriginalArrivalTime: 13 Jul 2010 17:02:31.0920 (UTC) FILETIME=[2EBFCF00:01CB22AD] Cc: Colin Snover , OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:05:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB22AD.2822C0BC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think it's a mistake not to have force_auth in the core. ________________________________ From: David Recordon [mailto:recordond@gmail.com]=20 Sent: Tuesday, July 13, 2010 9:58 AM To: William Mills Cc: Colin Snover; Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter =09 =09 I support immediate and a form of forced auth (ala OpenID's PAPE) but = not in the core spec. They both should be part of an identity extension. = On Tue, Jul 13, 2010 at 9:51 AM, William Mills = wrote: =09 I agree with Colin that some form of force_auth is needed. I haven't = read enough on the "immediate" proposal, but I know that we have run = into the problem of trusting currently set cookies in the browser (even = when we're actually sending a username/password and really do want to = have an authentication). =20 I'm a +1 on the force_auth proposal. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Colin Snover Sent: Tuesday, July 13, 2010 9:23 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter =09 =09 On 22/07/28164 13:59, Eran Hammer-Lahav wrote:=20 The following was submitted via the shared-copy page but does not = belong with editorial feedback. This needs to be discussed and supported = on the list before added the specification. I think it belongs where = 'immediate' is specified. =09 EHL =09 ------ Forwarded Message =09 From: An anonymous reader Date: Sat, 10 Jul 2010 11:01:11 -0700 To: Eran Hammer-Lahav Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol =09 =09 =09 =09 "Colin Snover" left these comments on your copy:=20 =20 draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol = =20 =20 =09 As proposed on the ML, a new parameter to counteract the = current behaviour of OAuth 1.0a authorization servers which is to assume = that the account logged into the user-agent is the account that should = be checked for access: =09 force_auth OPTIONAL. The parameter value must be set to "true" or = "false". =09 If set to "true", the authorization server MUST prompt the = end-user to authenticate and approve access. The authorization server = MUST NOT make any assumptions as to the identity of the entity = requesting access, even if another automatic mechanism is available to = do so (e.g. browser cookies). =09 If set to "false" or not present, the authorization server = MAY automatically grant access to the client if it is able to determine = that access was previously granted. link =BB = =20 =20 =09 tools.ietf.org/html/draft-ietf-oauth-v2-09 = =B7 Original page = =20 =20 =20 =09 ________________________________ via sharedcopy.com =20 =09 =09 ------ End of Forwarded Message =09 Hi Eran, =09 Sorry if that was not the right place for that to go; I didn't know = what else to do. I have tried to solicit feedback from the ML regarding = this parameter twice and nobody seems very keen in providing any, which = is kind of a bummer. I waited until the last possible moment to add it = in the hopes that someone would notice my messages and discuss it, but = you made it sound like your plan was for draft 10 to be potentially = final so I wanted to get it in before the deadline. =09 I'm sure this is not a big deal for most applications that expect at = most a single connection, but for me this is a huge deal since it = completely immolates our application's authentication flow, and I can't = go to every provider asking them to please change the way they implement = the authentication portion of their OAuth API. =09 In contrast to 'immediate', which had some concerns vis =E0 vis = security, force_auth is actually safer than the current normal flow used = by most OAuth providers since it requires the provider to make no = guesses about who is trying to authorize the app. =09 Frankly, I think that OAuth providers do the wrong thing now in all = cases by assuming that browser cookies are a safe way of confirming the = identity of the end-user making an authorization request (they aren't!), = but the spec says the way the authorization server authenticates the = end-user is outside the scope of the spec. I have no objection to = this-OAuth *should* be authentication-agnostic-but at the same time this = is a very real and present implementation flaw and the only way to solve = it is to make sure the spec defines a way for an application to say = "hey, I know you *think* you know who should be authenticated, but *I* = know that the user has requested to connect a *new* account, so don't = use any automatic authentication method". =09 I think it is incredibly important that the OAuth spec gets providers = to distinguish between automatic & potentially unsafe authentication = methods (like session cookies) versus more "guaranteed" authentication = (like password), especially since 99.999% of the time OAuth relies on = the end-user's Web browser which is all but guaranteed to contain some = cookies for the provider that are unrelated to the requesting = application. =09 Examples: =09 1. Multiple end-users with malicious intent. User 1 is logged into = their Facetweetr account. User 2 wants to do bad things using User 1's = account. Because the user-agent has cookies for user 1, user 2 gets to = authorize their account with our app. Even when user 1 changes their = password, unless the provider automatically invalidates their existing = connections (the spec does not even mention doing this in an informative = manner as far as I can tell), they are almost certainly unaware that the = linked application is still able to perform actions on their behalf. =09 2. Single end-user with multiple accounts. User is logged into = Facetweetr account 1, but they want to authorize account 2. They go to = authorize the application and are presented with a confirmation for = account 1. They log out (because this is the only way to switch accounts = on the provider) and suddenly the authorization flow is dropped on the = floor. The user may not know immediately what they need to do at this = point. They will need to manually return to the original application and = restart the authorization request. =09 3. User has two accounts that they want to authorize with a provider. = User authorizes account 1 successfully, then wants to authorize account = 2. Because account 1 is still logged in, and because the application = already has a link to the account, it automatically redirects back to = the application's redirection URI. In order for the user to get what = they want, they are forced to manually navigate to the provider's site, = log out, *then* begin the authorization request. =09 These aren't imaginary scenarios; they are things that are going on = *right now* with several different OAuth providers. =09 The original request: = = =20 =09 Regards, =09 --=20 Colin Snover http://zetafleet.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =09 =09 ------_=_NextPart_001_01CB22AD.2822C0BC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think it's a mistake not to have force_auth in = the=20 core.

From: David Recordon=20 [mailto:recordond@gmail.com]
Sent: Tuesday, July 13, 2010 = 9:58=20 AM
To: William Mills
Cc: Colin Snover; Eran = Hammer-Lahav;=20 OAuth WG
Subject: Re: [OAUTH-WG] ' force_auth' request=20 parameter

I support immediate and a form of forced auth (ala OpenID's = PAPE)=20 but not in the core spec. They both should be part of an identity = extension.


On Tue, Jul 13, 2010 at 9:51 AM, William = Mills <wmills@yahoo-inc.com> = wrote:
I agree=20 with Colin that some form of force_auth is needed.  I haven't = read=20 enough on the "immediate" proposal, but I know that we have run into = the=20 problem of trusting currently set cookies in the browser (even when = we're=20 actually sending a username/password and really do want to have an=20 authentication).
 
I'm a +1=20 on the force_auth proposal.

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Colin=20 Snover
Sent: Tuesday, July 13, 2010 9:23 = AM
To: Eran=20 Hammer-Lahav
Cc: OAuth WG
Subject: Re: = [OAUTH-WG] '=20 force_auth' request parameter

On 22/07/28164 13:59, Eran Hammer-Lahav wrote:=20
The following was submitted via the = shared-copy=20 page but does not belong with editorial feedback. This needs to = be=20 discussed and supported on the list before added the = specification. I=20 think it belongs where =91immediate=92 is=20 specified.

EHL

------ Forwarded = Message
From: An anonymous reader = <mailman@sharedcopy.com>
Date: = Sat, 10=20 Jul 2010 11:01:11 -0700
To: Eran Hammer-Lahav <eran@hueniverse.com>
Subject: = Re:=20 draft-ietf-oauth-v2-09 - The OAuth 2.0=20 Protocol
 "Colin Snover" left = these=20 comments on your copy:
 
draft-ietf-oauth-v2-09 - The = OAuth 2.0=20 Protocol <http://r6.sharedcopy.com/6bnqq8v>=20
        

  = ;   As=20 proposed on the ML, a new parameter to counteract the current=20 behaviour of OAuth 1.0a authorization servers which is to = assume that=20 the account logged into the user-agent is the account that = should be=20 checked for=20 = access:

force_auth
       &n= bsp; OPTIONAL.=20 The parameter value must be set to "true" or=20 = "false".

         If = set to "true", the authorization server MUST prompt the = end-user to=20 authenticate and approve access. The authorization server MUST = NOT=20 make any assumptions as to the identity of the entity = requesting=20 access, even if another automatic mechanism is available to do = so=20 (e.g. browser=20 = cookies).

         If= =20 set to "false" or not present, the authorization server MAY=20 automatically grant access to the client if it is able to = determine=20 that access was previously granted.=20         link =BB = <http://r6.sharedcopy.com/6bnqq8v#shcp21>=20
 

tools.ietf.org/html/draft-ietf-oauth-v2-09 = <http://r6.sharedcopy.com/6bnqq8v> =  =B7=20 Original page <http://tools.ietf.org/html/draft-ietf-oauth-v2-09>= =20
  
 
via sharedcopy.com=20 <http://sharedcopy.com/?ef>=20  

------ End of Forwarded=20 Message

Hi Eran,

Sorry = if that=20 was not the right place for that to go; I didn=92t know what else = to do. I=20 have tried to solicit feedback from the ML regarding this = parameter twice=20 and nobody seems very keen in providing any, which is kind of a = bummer. I=20 waited until the last possible moment to add it in the hopes that = someone=20 would notice my messages and discuss it, but you made it sound = like your=20 plan was for draft 10 to be potentially final so I wanted to get = it in=20 before the deadline.

I=92m sure this is not a big deal for = most=20 applications that expect at most a single connection, but for me = this is a=20 huge deal since it completely immolates our application=92s = authentication=20 flow, and I can=92t go to every provider asking them to please = change the=20 way they implement the authentication portion of their OAuth=20 API.

In contrast to =91immediate=92, which had some = concerns vis =E0 vis=20 security, force_auth is actually safer than the current normal = flow used=20 by most OAuth providers since it requires the provider to make no = guesses=20 about who is trying to authorize the app.

Frankly, I think = that=20 OAuth providers do the wrong thing now in all cases by assuming = that=20 browser cookies are a safe way of confirming the identity of the = end-user=20 making an authorization request (they aren=92t!), but the spec = says the way=20 the authorization server authenticates the end-user is outside the = scope=20 of the spec. I have no objection to this=97OAuth *should* be=20 authentication-agnostic=97but at the same time this is a very real = and=20 present implementation flaw and the only way to solve it is to = make sure=20 the spec defines a way for an application to say =93hey, I know = you *think*=20 you know who should be authenticated, but *I* know that the user = has=20 requested to connect a *new* account, so don=92t use any automatic = authentication method=94.

I think it is incredibly = important that the=20 OAuth spec gets providers to distinguish between automatic &=20 potentially unsafe authentication methods (like session cookies) = versus=20 more =93guaranteed=94 authentication (like password), especially = since 99.999%=20 of the time OAuth relies on the end-user=92s Web browser which is = all but=20 guaranteed to contain some cookies for the provider that are = unrelated to=20 the requesting application.

Examples:

1. Multiple = end-users=20 with malicious intent. User 1 is logged into their Facetweetr = account.=20 User 2 wants to do bad things using User 1=92s account. Because = the=20 user-agent has cookies for user 1, user 2 gets to authorize their = account=20 with our app. Even when user 1 changes their password, unless the = provider=20 automatically invalidates their existing connections (the spec = does not=20 even mention doing this in an informative manner as far as I can = tell),=20 they are almost certainly unaware that the linked application is = still=20 able to perform actions on their behalf.

2. Single end-user = with=20 multiple accounts. User is logged into Facetweetr account 1, = but they=20 want to authorize account 2. They go to authorize the application = and are=20 presented with a confirmation for account 1. They log out (because = this is=20 the only way to switch accounts on the provider) and suddenly the=20 authorization flow is dropped on the floor. The user may not know=20 immediately what they need to do at this point. They will need to = manually=20 return to the original application and restart the authorization=20 request.

3. User has two accounts that they want to = authorize with=20 a provider. User authorizes account 1 successfully, then wants to=20 authorize account 2. Because account 1 is still logged in, and = because the=20 application already has a link to the account, it automatically = redirects=20 back to the application=92s redirection URI. In order for the user = to get=20 what they want, they are forced to manually navigate to the = provider=92s=20 site, log out, *then* begin the authorization = request.

These aren=92t=20 imaginary scenarios; they are things that are going on *right now* = with=20 several different OAuth providers.

The original request: <http://www.mail-archive.com/oauth@ietf.org/msg02331.h= tml>

Regards,
--=20
Colin Snover
http://zetafleet.com

________________________________= _______________
OAuth=20 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


------_=_NextPart_001_01CB22AD.2822C0BC-- From eran@hueniverse.com Tue Jul 13 10:08:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6BB3A696D for ; Tue, 13 Jul 2010 10:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWfZIYztQkSk for ; Tue, 13 Jul 2010 10:08:18 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 688FD3A69A9 for ; Tue, 13 Jul 2010 10:08:18 -0700 (PDT) Received: (qmail 19746 invoked from network); 13 Jul 2010 17:08:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 17:08:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 13 Jul 2010 10:08:25 -0700 From: Eran Hammer-Lahav To: William Mills Date: Tue, 13 Jul 2010 10:08:20 -0700 Thread-Topic: [OAUTH-WG] ' force_auth' request parameter Thread-Index: AcsirgEd+AAX5llfSkKNmCv5xZ8Krg== Message-ID: References: <4C3C92D2.80209@zetafleet.com> <012AB2B223CB3F4BB846962876F47217059B6C12@SNV-EXVS08.ds.corp.yahoo.com> <012AB2B223CB3F4BB846962876F47217059B6C16@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6C16@SNV-EXVS08.ds.corp.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB637441A978438AA4A4EF8D6B05FD2Chueniversecom_" MIME-Version: 1.0 Cc: Colin Snover , OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:08:20 -0000 --_000_CB637441A978438AA4A4EF8D6B05FD2Chueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHF1ZXN0aW9uIGlzIGlmIHdlIGhhdmUgY29uc2Vuc3VzIHRvIGZvcmNlIHByb3ZpZGVycyB0 byBzdXBwb3J0IGl0Lg0KDQpJdCBzZWVtcyB0byBvdmVyc3RlcCB0aGUgYm91bmRhcmllcyB3ZSBz ZXQgb3ZlciB0aGUgeWVhcnMgYW5kIGl0IG1ha2VzIGFzc3VtcHRpb25zIGFib3V0IGhvdyBzZXJ2 aWNlcyBhdXRoZW50aWNhdGUgdXNlcnMgYW5kIG9idGFpbiBhcHByb3ZhbHMuDQoNCkVITA0KDQoN Ck9uIEp1bCAxMywgMjAxMCwgYXQgMTM6MDUsIFdpbGxpYW0gTWlsbHMgPHdtaWxsc0B5YWhvby1p bmMuY29tPG1haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbT4+IHdyb3RlOg0KDQpJIHRoaW5rIGl0 J3MgYSBtaXN0YWtlIG5vdCB0byBoYXZlIGZvcmNlX2F1dGggaW4gdGhlIGNvcmUuDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBEYXZpZCBSZWNvcmRvbiBbbWFpbHRv OnJlY29yZG9uZEBnbWFpbC5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDEzLCAyMDEwIDk6NTgg QU0NClRvOiBXaWxsaWFtIE1pbGxzDQpDYzogQ29saW4gU25vdmVyOyBFcmFuIEhhbW1lci1MYWhh djsgT0F1dGggV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddICcgZm9yY2VfYXV0aCcgcmVxdWVz dCBwYXJhbWV0ZXINCg0KSSBzdXBwb3J0IGltbWVkaWF0ZSBhbmQgYSBmb3JtIG9mIGZvcmNlZCBh dXRoIChhbGEgT3BlbklEJ3MgUEFQRSkgYnV0IG5vdCBpbiB0aGUgY29yZSBzcGVjLiBUaGV5IGJv dGggc2hvdWxkIGJlIHBhcnQgb2YgYW4gaWRlbnRpdHkgZXh0ZW5zaW9uLg0KDQoNCk9uIFR1ZSwg SnVsIDEzLCAyMDEwIGF0IDk6NTEgQU0sIFdpbGxpYW0gTWlsbHMgPDxtYWlsdG86d21pbGxzQHlh aG9vLWluYy5jb20+d21pbGxzQHlhaG9vLWluYy5jb208bWFpbHRvOndtaWxsc0B5YWhvby1pbmMu Y29tPj4gd3JvdGU6DQpJIGFncmVlIHdpdGggQ29saW4gdGhhdCBzb21lIGZvcm0gb2YgZm9yY2Vf YXV0aCBpcyBuZWVkZWQuICBJIGhhdmVuJ3QgcmVhZCBlbm91Z2ggb24gdGhlICJpbW1lZGlhdGUi IHByb3Bvc2FsLCBidXQgSSBrbm93IHRoYXQgd2UgaGF2ZSBydW4gaW50byB0aGUgcHJvYmxlbSBv ZiB0cnVzdGluZyBjdXJyZW50bHkgc2V0IGNvb2tpZXMgaW4gdGhlIGJyb3dzZXIgKGV2ZW4gd2hl biB3ZSdyZSBhY3R1YWxseSBzZW5kaW5nIGEgdXNlcm5hbWUvcGFzc3dvcmQgYW5kIHJlYWxseSBk byB3YW50IHRvIGhhdmUgYW4gYXV0aGVudGljYXRpb24pLg0KDQpJJ20gYSArMSBvbiB0aGUgZm9y Y2VfYXV0aCBwcm9wb3NhbC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IDxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gb2F1dGgtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzo8bWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBDb2xpbiBTbm92ZXINClNlbnQ6IFR1ZXNkYXksIEp1 bHkgMTMsIDIwMTAgOToyMyBBTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2DQpDYzogT0F1dGggV0cN ClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddICcgZm9yY2VfYXV0aCcgcmVxdWVzdCBwYXJhbWV0ZXIN Cg0KT24gMjIvMDcvMjgxNjQgMTM6NTksIEVyYW4gSGFtbWVyLUxhaGF2IHdyb3RlOg0KVGhlIGZv bGxvd2luZyB3YXMgc3VibWl0dGVkIHZpYSB0aGUgc2hhcmVkLWNvcHkgcGFnZSBidXQgZG9lcyBu b3QgYmVsb25nIHdpdGggZWRpdG9yaWFsIGZlZWRiYWNrLiBUaGlzIG5lZWRzIHRvIGJlIGRpc2N1 c3NlZCBhbmQgc3VwcG9ydGVkIG9uIHRoZSBsaXN0IGJlZm9yZSBhZGRlZCB0aGUgc3BlY2lmaWNh dGlvbi4gSSB0aGluayBpdCBiZWxvbmdzIHdoZXJlIOKAmGltbWVkaWF0ZeKAmSBpcyBzcGVjaWZp ZWQuDQoNCkVITA0KDQotLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UNCkZyb206IEFuIGFub255bW91 cyByZWFkZXIgPDxodHRwOi8vbWFpbG1hbkBzaGFyZWRjb3B5LmNvbT5tYWlsbWFuQHNoYXJlZGNv cHkuY29tPG1haWx0bzptYWlsbWFuQHNoYXJlZGNvcHkuY29tPj4NCkRhdGU6IFNhdCwgMTAgSnVs IDIwMTAgMTE6MDE6MTEgLTA3MDANClRvOiBFcmFuIEhhbW1lci1MYWhhdiA8PGh0dHA6Ly9lcmFu QGh1ZW5pdmVyc2UuY29tPmVyYW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJz ZS5jb20+Pg0KU3ViamVjdDogUmU6IGRyYWZ0LWlldGYtb2F1dGgtdjItMDkgLSBUaGUgT0F1dGgg Mi4wIFByb3RvY29sDQoNCg0KICJDb2xpbiBTbm92ZXIiIGxlZnQgdGhlc2UgY29tbWVudHMgb24g eW91ciBjb3B5Og0KDQpkcmFmdC1pZXRmLW9hdXRoLXYyLTA5IC0gVGhlIE9BdXRoIDIuMCBQcm90 b2NvbCA8PGh0dHA6Ly9yNi5zaGFyZWRjb3B5LmNvbS82Ym5xcTh2Pmh0dHA6Ly9yNi5zaGFyZWRj b3B5LmNvbS82Ym5xcTh2Pg0KDQoNCiAgICAgQXMgcHJvcG9zZWQgb24gdGhlIE1MLCBhIG5ldyBw YXJhbWV0ZXIgdG8gY291bnRlcmFjdCB0aGUgY3VycmVudCBiZWhhdmlvdXIgb2YgT0F1dGggMS4w YSBhdXRob3JpemF0aW9uIHNlcnZlcnMgd2hpY2ggaXMgdG8gYXNzdW1lIHRoYXQgdGhlIGFjY291 bnQgbG9nZ2VkIGludG8gdGhlIHVzZXItYWdlbnQgaXMgdGhlIGFjY291bnQgdGhhdCBzaG91bGQg YmUgY2hlY2tlZCBmb3IgYWNjZXNzOg0KDQpmb3JjZV9hdXRoDQogICAgICAgICBPUFRJT05BTC4g VGhlIHBhcmFtZXRlciB2YWx1ZSBtdXN0IGJlIHNldCB0byAidHJ1ZSIgb3IgImZhbHNlIi4NCg0K ICAgICAgICAgSWYgc2V0IHRvICJ0cnVlIiwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Qg cHJvbXB0IHRoZSBlbmQtdXNlciB0byBhdXRoZW50aWNhdGUgYW5kIGFwcHJvdmUgYWNjZXNzLiBU aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBOT1QgbWFrZSBhbnkgYXNzdW1wdGlvbnMgYXMg dG8gdGhlIGlkZW50aXR5IG9mIHRoZSBlbnRpdHkgcmVxdWVzdGluZyBhY2Nlc3MsIGV2ZW4gaWYg YW5vdGhlciBhdXRvbWF0aWMgbWVjaGFuaXNtIGlzIGF2YWlsYWJsZSB0byBkbyBzbyAoZS5nLiBi cm93c2VyIGNvb2tpZXMpLg0KDQogICAgICAgICBJZiBzZXQgdG8gImZhbHNlIiBvciBub3QgcHJl c2VudCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBhdXRvbWF0aWNhbGx5IGdyYW50IGFj Y2VzcyB0byB0aGUgY2xpZW50IGlmIGl0IGlzIGFibGUgdG8gZGV0ZXJtaW5lIHRoYXQgYWNjZXNz IHdhcyBwcmV2aW91c2x5IGdyYW50ZWQuICAgICAgICAgbGluayDCuyA8PGh0dHA6Ly9yNi5zaGFy ZWRjb3B5LmNvbS82Ym5xcTh2I3NoY3AyMT5odHRwOi8vcjYuc2hhcmVkY29weS5jb20vNmJucXE4 diNzaGNwMjE+DQoNCg0KPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1 dGgtdjItMDk+dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLTA5PGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItMDk+IDw8aHR0cDovL3I2 LnNoYXJlZGNvcHkuY29tLzZibnFxOHY+aHR0cDovL3I2LnNoYXJlZGNvcHkuY29tLzZibnFxOHY+ ICDCtyBPcmlnaW5hbCBwYWdlIDw8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1vYXV0aC12Mi0wOT5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRo LXYyLTA5Pg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2aWEgPGh0dHA6 Ly9zaGFyZWRjb3B5LmNvbT4gc2hhcmVkY29weS5jb208aHR0cDovL3NoYXJlZGNvcHkuY29tPiA8 PGh0dHA6Ly9zaGFyZWRjb3B5LmNvbS8/ZWY+aHR0cDovL3NoYXJlZGNvcHkuY29tLz9lZj4NCg0K LS0tLS0tIEVuZCBvZiBGb3J3YXJkZWQgTWVzc2FnZQ0KDQpIaSBFcmFuLA0KDQpTb3JyeSBpZiB0 aGF0IHdhcyBub3QgdGhlIHJpZ2h0IHBsYWNlIGZvciB0aGF0IHRvIGdvOyBJIGRpZG7igJl0IGtu b3cgd2hhdCBlbHNlIHRvIGRvLiBJIGhhdmUgdHJpZWQgdG8gc29saWNpdCBmZWVkYmFjayBmcm9t IHRoZSBNTCByZWdhcmRpbmcgdGhpcyBwYXJhbWV0ZXIgdHdpY2UgYW5kIG5vYm9keSBzZWVtcyB2 ZXJ5IGtlZW4gaW4gcHJvdmlkaW5nIGFueSwgd2hpY2ggaXMga2luZCBvZiBhIGJ1bW1lci4gSSB3 YWl0ZWQgdW50aWwgdGhlIGxhc3QgcG9zc2libGUgbW9tZW50IHRvIGFkZCBpdCBpbiB0aGUgaG9w ZXMgdGhhdCBzb21lb25lIHdvdWxkIG5vdGljZSBteSBtZXNzYWdlcyBhbmQgZGlzY3VzcyBpdCwg YnV0IHlvdSBtYWRlIGl0IHNvdW5kIGxpa2UgeW91ciBwbGFuIHdhcyBmb3IgZHJhZnQgMTAgdG8g YmUgcG90ZW50aWFsbHkgZmluYWwgc28gSSB3YW50ZWQgdG8gZ2V0IGl0IGluIGJlZm9yZSB0aGUg ZGVhZGxpbmUuDQoNCknigJltIHN1cmUgdGhpcyBpcyBub3QgYSBiaWcgZGVhbCBmb3IgbW9zdCBh cHBsaWNhdGlvbnMgdGhhdCBleHBlY3QgYXQgbW9zdCBhIHNpbmdsZSBjb25uZWN0aW9uLCBidXQg Zm9yIG1lIHRoaXMgaXMgYSBodWdlIGRlYWwgc2luY2UgaXQgY29tcGxldGVseSBpbW1vbGF0ZXMg b3VyIGFwcGxpY2F0aW9u4oCZcyBhdXRoZW50aWNhdGlvbiBmbG93LCBhbmQgSSBjYW7igJl0IGdv IHRvIGV2ZXJ5IHByb3ZpZGVyIGFza2luZyB0aGVtIHRvIHBsZWFzZSBjaGFuZ2UgdGhlIHdheSB0 aGV5IGltcGxlbWVudCB0aGUgYXV0aGVudGljYXRpb24gcG9ydGlvbiBvZiB0aGVpciBPQXV0aCBB UEkuDQoNCkluIGNvbnRyYXN0IHRvIOKAmGltbWVkaWF0ZeKAmSwgd2hpY2ggaGFkIHNvbWUgY29u Y2VybnMgdmlzIMOgIHZpcyBzZWN1cml0eSwgZm9yY2VfYXV0aCBpcyBhY3R1YWxseSBzYWZlciB0 aGFuIHRoZSBjdXJyZW50IG5vcm1hbCBmbG93IHVzZWQgYnkgbW9zdCBPQXV0aCBwcm92aWRlcnMg c2luY2UgaXQgcmVxdWlyZXMgdGhlIHByb3ZpZGVyIHRvIG1ha2Ugbm8gZ3Vlc3NlcyBhYm91dCB3 aG8gaXMgdHJ5aW5nIHRvIGF1dGhvcml6ZSB0aGUgYXBwLg0KDQpGcmFua2x5LCBJIHRoaW5rIHRo YXQgT0F1dGggcHJvdmlkZXJzIGRvIHRoZSB3cm9uZyB0aGluZyBub3cgaW4gYWxsIGNhc2VzIGJ5 IGFzc3VtaW5nIHRoYXQgYnJvd3NlciBjb29raWVzIGFyZSBhIHNhZmUgd2F5IG9mIGNvbmZpcm1p bmcgdGhlIGlkZW50aXR5IG9mIHRoZSBlbmQtdXNlciBtYWtpbmcgYW4gYXV0aG9yaXphdGlvbiBy ZXF1ZXN0ICh0aGV5IGFyZW7igJl0ISksIGJ1dCB0aGUgc3BlYyBzYXlzIHRoZSB3YXkgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIGVuZC11c2VyIGlzIG91dHNpZGUg dGhlIHNjb3BlIG9mIHRoZSBzcGVjLiBJIGhhdmUgbm8gb2JqZWN0aW9uIHRvIHRoaXPigJRPQXV0 aCAqc2hvdWxkKiBiZSBhdXRoZW50aWNhdGlvbi1hZ25vc3RpY+KAlGJ1dCBhdCB0aGUgc2FtZSB0 aW1lIHRoaXMgaXMgYSB2ZXJ5IHJlYWwgYW5kIHByZXNlbnQgaW1wbGVtZW50YXRpb24gZmxhdyBh bmQgdGhlIG9ubHkgd2F5IHRvIHNvbHZlIGl0IGlzIHRvIG1ha2Ugc3VyZSB0aGUgc3BlYyBkZWZp bmVzIGEgd2F5IGZvciBhbiBhcHBsaWNhdGlvbiB0byBzYXkg4oCcaGV5LCBJIGtub3cgeW91ICp0 aGluayogeW91IGtub3cgd2hvIHNob3VsZCBiZSBhdXRoZW50aWNhdGVkLCBidXQgKkkqIGtub3cg dGhhdCB0aGUgdXNlciBoYXMgcmVxdWVzdGVkIHRvIGNvbm5lY3QgYSAqbmV3KiBhY2NvdW50LCBz byBkb27igJl0IHVzZSBhbnkgYXV0b21hdGljIGF1dGhlbnRpY2F0aW9uIG1ldGhvZOKAnS4NCg0K SSB0aGluayBpdCBpcyBpbmNyZWRpYmx5IGltcG9ydGFudCB0aGF0IHRoZSBPQXV0aCBzcGVjIGdl dHMgcHJvdmlkZXJzIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gYXV0b21hdGljICYgcG90ZW50aWFs bHkgdW5zYWZlIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgKGxpa2Ugc2Vzc2lvbiBjb29raWVzKSB2 ZXJzdXMgbW9yZSDigJxndWFyYW50ZWVk4oCdIGF1dGhlbnRpY2F0aW9uIChsaWtlIHBhc3N3b3Jk KSwgZXNwZWNpYWxseSBzaW5jZSA5OS45OTklIG9mIHRoZSB0aW1lIE9BdXRoIHJlbGllcyBvbiB0 aGUgZW5kLXVzZXLigJlzIFdlYiBicm93c2VyIHdoaWNoIGlzIGFsbCBidXQgZ3VhcmFudGVlZCB0 byBjb250YWluIHNvbWUgY29va2llcyBmb3IgdGhlIHByb3ZpZGVyIHRoYXQgYXJlIHVucmVsYXRl ZCB0byB0aGUgcmVxdWVzdGluZyBhcHBsaWNhdGlvbi4NCg0KRXhhbXBsZXM6DQoNCjEuIE11bHRp cGxlIGVuZC11c2VycyB3aXRoIG1hbGljaW91cyBpbnRlbnQuIFVzZXIgMSBpcyBsb2dnZWQgaW50 byB0aGVpciBGYWNldHdlZXRyIGFjY291bnQuIFVzZXIgMiB3YW50cyB0byBkbyBiYWQgdGhpbmdz IHVzaW5nIFVzZXIgMeKAmXMgYWNjb3VudC4gQmVjYXVzZSB0aGUgdXNlci1hZ2VudCBoYXMgY29v a2llcyBmb3IgdXNlciAxLCB1c2VyIDIgZ2V0cyB0byBhdXRob3JpemUgdGhlaXIgYWNjb3VudCB3 aXRoIG91ciBhcHAuIEV2ZW4gd2hlbiB1c2VyIDEgY2hhbmdlcyB0aGVpciBwYXNzd29yZCwgdW5s ZXNzIHRoZSBwcm92aWRlciBhdXRvbWF0aWNhbGx5IGludmFsaWRhdGVzIHRoZWlyIGV4aXN0aW5n IGNvbm5lY3Rpb25zICh0aGUgc3BlYyBkb2VzIG5vdCBldmVuIG1lbnRpb24gZG9pbmcgdGhpcyBp biBhbiBpbmZvcm1hdGl2ZSBtYW5uZXIgYXMgZmFyIGFzIEkgY2FuIHRlbGwpLCB0aGV5IGFyZSBh bG1vc3QgY2VydGFpbmx5IHVuYXdhcmUgdGhhdCB0aGUgbGlua2VkIGFwcGxpY2F0aW9uIGlzIHN0 aWxsIGFibGUgdG8gcGVyZm9ybSBhY3Rpb25zIG9uIHRoZWlyIGJlaGFsZi4NCg0KMi4gU2luZ2xl IGVuZC11c2VyIHdpdGggbXVsdGlwbGUgYWNjb3VudHMuIFVzZXIgaXMgbG9nZ2VkIGludG8gRmFj ZXR3ZWV0ciBhY2NvdW50IDEsIGJ1dCB0aGV5IHdhbnQgdG8gYXV0aG9yaXplIGFjY291bnQgMi4g VGhleSBnbyB0byBhdXRob3JpemUgdGhlIGFwcGxpY2F0aW9uIGFuZCBhcmUgcHJlc2VudGVkIHdp dGggYSBjb25maXJtYXRpb24gZm9yIGFjY291bnQgMS4gVGhleSBsb2cgb3V0IChiZWNhdXNlIHRo aXMgaXMgdGhlIG9ubHkgd2F5IHRvIHN3aXRjaCBhY2NvdW50cyBvbiB0aGUgcHJvdmlkZXIpIGFu ZCBzdWRkZW5seSB0aGUgYXV0aG9yaXphdGlvbiBmbG93IGlzIGRyb3BwZWQgb24gdGhlIGZsb29y LiBUaGUgdXNlciBtYXkgbm90IGtub3cgaW1tZWRpYXRlbHkgd2hhdCB0aGV5IG5lZWQgdG8gZG8g YXQgdGhpcyBwb2ludC4gVGhleSB3aWxsIG5lZWQgdG8gbWFudWFsbHkgcmV0dXJuIHRvIHRoZSBv cmlnaW5hbCBhcHBsaWNhdGlvbiBhbmQgcmVzdGFydCB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0 Lg0KDQozLiBVc2VyIGhhcyB0d28gYWNjb3VudHMgdGhhdCB0aGV5IHdhbnQgdG8gYXV0aG9yaXpl IHdpdGggYSBwcm92aWRlci4gVXNlciBhdXRob3JpemVzIGFjY291bnQgMSBzdWNjZXNzZnVsbHks IHRoZW4gd2FudHMgdG8gYXV0aG9yaXplIGFjY291bnQgMi4gQmVjYXVzZSBhY2NvdW50IDEgaXMg c3RpbGwgbG9nZ2VkIGluLCBhbmQgYmVjYXVzZSB0aGUgYXBwbGljYXRpb24gYWxyZWFkeSBoYXMg YSBsaW5rIHRvIHRoZSBhY2NvdW50LCBpdCBhdXRvbWF0aWNhbGx5IHJlZGlyZWN0cyBiYWNrIHRv IHRoZSBhcHBsaWNhdGlvbuKAmXMgcmVkaXJlY3Rpb24gVVJJLiBJbiBvcmRlciBmb3IgdGhlIHVz ZXIgdG8gZ2V0IHdoYXQgdGhleSB3YW50LCB0aGV5IGFyZSBmb3JjZWQgdG8gbWFudWFsbHkgbmF2 aWdhdGUgdG8gdGhlIHByb3ZpZGVy4oCZcyBzaXRlLCBsb2cgb3V0LCAqdGhlbiogYmVnaW4gdGhl IGF1dGhvcml6YXRpb24gcmVxdWVzdC4NCg0KVGhlc2UgYXJlbuKAmXQgaW1hZ2luYXJ5IHNjZW5h cmlvczsgdGhleSBhcmUgdGhpbmdzIHRoYXQgYXJlIGdvaW5nIG9uICpyaWdodCBub3cqIHdpdGgg c2V2ZXJhbCBkaWZmZXJlbnQgT0F1dGggcHJvdmlkZXJzLg0KDQpUaGUgb3JpZ2luYWwgcmVxdWVz dDogPDxodHRwOi8vd3d3Lm1haWwtYXJjaGl2ZS5jb20vb2F1dGhAaWV0Zi5vcmcvbXNnMDIzMzEu aHRtbD5odHRwOi8vd3d3Lm1haWwtYXJjaGl2ZS5jb20vb2F1dGhAaWV0Zi5vcmcvbXNnMDIzMzEu aHRtbD4NCg0KUmVnYXJkcywNCg0KLS0NCkNvbGluIFNub3Zlcg0KPGh0dHA6Ly96ZXRhZmxlZXQu Y29tPmh0dHA6Ly96ZXRhZmxlZXQuY29tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz5PQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo8aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0K --_000_CB637441A978438AA4A4EF8D6B05FD2Chueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5UaGUgcXVlc3Rpb24gaXMgaWYgd2Ug aGF2ZSBjb25zZW5zdXMgdG8gZm9yY2UgcHJvdmlkZXJzIHRvIHN1cHBvcnQgaXQuJm5ic3A7PGJy Pjxicj48L2Rpdj48ZGl2Pkl0IHNlZW1zIHRvIG92ZXJzdGVwIHRoZSBib3VuZGFyaWVzIHdlIHNl dCBvdmVyIHRoZSB5ZWFycyBhbmQgaXQgbWFrZXMgYXNzdW1wdGlvbnMgYWJvdXQgaG93IHNlcnZp Y2VzIGF1dGhlbnRpY2F0ZSB1c2VycyBhbmQgb2J0YWluIGFwcHJvdmFscy4mbmJzcDs8L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PkVITDxicj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2Pjxicj5P biBKdWwgMTMsIDIwMTAsIGF0IDEzOjA1LCBXaWxsaWFtIE1pbGxzICZsdDs8YSBocmVmPSJtYWls dG86d21pbGxzQHlhaG9vLWluYy5jb20iPndtaWxsc0B5YWhvby1pbmMuY29tPC9hPiZndDsgd3Jv dGU6PGJyPjxicj48L2Rpdj48ZGl2PjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+ DQo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PHNwYW4gY2xhc3M9IjAyNTU1MDExNy0xMzA3 MjAxMCI+PGZvbnQgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiIGZhY2U9IkFyaWFsIj5JIHRoaW5r IGl0J3MgYSBtaXN0YWtlIG5vdCB0byBoYXZlIGZvcmNlX2F1dGggaW4gdGhlIA0KY29yZS48L2Zv bnQ+PC9zcGFuPjwvZGl2Pjxicj4NCjxibG9ja3F1b3RlIHN0eWxlPSJCT1JERVItTEVGVDogIzAw MDBmZiAycHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJH SU4tUklHSFQ6IDBweCIgZGlyPSJsdHIiPg0KICA8ZGl2IGRpcj0ibHRyIiBsYW5nPSJlbi11cyIg Y2xhc3M9Ik91dGxvb2tNZXNzYWdlSGVhZGVyIiBhbGlnbj0ibGVmdCI+DQogIDxociB0YWJpbmRl eD0iLTEiPg0KICA8Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBEYXZp ZCBSZWNvcmRvbiANCiAgW21haWx0bzpyZWNvcmRvbmRAZ21haWwuY29tXSA8YnI+PGI+U2VudDo8 L2I+IFR1ZXNkYXksIEp1bHkgMTMsIDIwMTAgOTo1OCANCiAgQU08YnI+PGI+VG86PC9iPiBXaWxs aWFtIE1pbGxzPGJyPjxiPkNjOjwvYj4gQ29saW4gU25vdmVyOyBFcmFuIEhhbW1lci1MYWhhdjsg DQogIE9BdXRoIFdHPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSAnIGZvcmNlX2F1 dGgnIHJlcXVlc3QgDQogIHBhcmFtZXRlcjxicj48L2ZvbnQ+PGJyPjwvZGl2Pg0KICA8ZGl2Pjwv ZGl2Pkkgc3VwcG9ydCBpbW1lZGlhdGUgYW5kIGEgZm9ybSBvZiBmb3JjZWQgYXV0aCAoYWxhIE9w ZW5JRCdzIFBBUEUpIA0KICBidXQgbm90IGluIHRoZSBjb3JlIHNwZWMuIFRoZXkgYm90aCBzaG91 bGQgYmUgcGFydCBvZiBhbiBpZGVudGl0eSBleHRlbnNpb24uDQogIDxkaXY+PGJyPjxicj4NCiAg PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFR1ZSwgSnVsIDEzLCAyMDEwIGF0IDk6NTEgQU0s IFdpbGxpYW0gTWlsbHMgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86d21pbGxz QHlhaG9vLWluYy5jb20iPjxhIGhyZWY9Im1haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbSI+d21p bGxzQHlhaG9vLWluYy5jb208L2E+PC9hPiZndDs8L3NwYW4+IA0KICB3cm90ZTo8YnI+DQogIDxi bG9ja3F1b3RlIHN0eWxlPSJCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQ7IE1BUkdJTjogMHB4 IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4IiBjbGFzcz0iZ21haWxfcXVvdGUiPg0K ICAgIDxkaXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0iI2ZmZmZmZiI+DQogICAgPGRpdiBkaXI9 Imx0ciIgYWxpZ249ImxlZnQiPjxzcGFuPjxmb250IGNvbG9yPSIjMDAwMGZmIiBzaXplPSIyIiBm YWNlPSJBcmlhbCI+SSBhZ3JlZSANCiAgICB3aXRoIENvbGluIHRoYXQgc29tZSBmb3JtIG9mIGZv cmNlX2F1dGggaXMgbmVlZGVkLiZuYnNwOyBJIGhhdmVuJ3QgcmVhZCANCiAgICBlbm91Z2ggb24g dGhlICJpbW1lZGlhdGUiIHByb3Bvc2FsLCBidXQgSSBrbm93IHRoYXQgd2UgaGF2ZSBydW4gaW50 byB0aGUgDQogICAgcHJvYmxlbSBvZiB0cnVzdGluZyBjdXJyZW50bHkgc2V0IGNvb2tpZXMgaW4g dGhlIGJyb3dzZXIgKGV2ZW4gd2hlbiB3ZSdyZSANCiAgICBhY3R1YWxseSBzZW5kaW5nIGEgdXNl cm5hbWUvcGFzc3dvcmQgYW5kIHJlYWxseSBkbyB3YW50IHRvIGhhdmUgYW4gDQogICAgYXV0aGVu dGljYXRpb24pLjwvZm9udD48L3NwYW4+PC9kaXY+DQogICAgPGRpdiBkaXI9Imx0ciIgYWxpZ249 ImxlZnQiPjxzcGFuPjxmb250IGNvbG9yPSIjMDAwMGZmIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+ PC9mb250Pjwvc3Bhbj4mbmJzcDs8L2Rpdj4NCiAgICA8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVm dCI+PHNwYW4+PGZvbnQgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiIGZhY2U9IkFyaWFsIj5JJ20g YSArMSANCiAgICBvbiB0aGUgZm9yY2VfYXV0aCBwcm9wb3NhbC48L2ZvbnQ+PC9zcGFuPjwvZGl2 Pjxicj4NCiAgICA8YmxvY2txdW90ZSBzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwZmYgMnB4IHNv bGlkOyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAw cHgiIGRpcj0ibHRyIj4NCiAgICAgIDxkaXYgZGlyPSJsdHIiIGxhbmc9ImVuLXVzIiBhbGlnbj0i bGVmdCI+DQogICAgICA8aHI+DQogICAgICA8Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxi PkZyb206PC9iPiA8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1i b3VuY2VzQGlldGYub3JnPC9hPjwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPjwvYT5dIDxiPk9uIEJlaGFs ZiBPZiA8L2I+Q29saW4gDQogICAgICBTbm92ZXI8YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1 bHkgMTMsIDIwMTAgOToyMyBBTTxicj48Yj5Ubzo8L2I+IEVyYW4gDQogICAgICBIYW1tZXItTGFo YXY8YnI+PGI+Q2M6PC9iPiBPQXV0aCBXRzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gJyANCiAgICAgIGZvcmNlX2F1dGgnIHJlcXVlc3QgcGFyYW1ldGVyPGJyPjwvZm9udD48YnI+ PC9kaXY+DQogICAgICA8ZGl2Pg0KICAgICAgPGRpdj48L2Rpdj4NCiAgICAgIDxkaXYgY2xhc3M9 Img1Ij4NCiAgICAgIDxkaXY+PC9kaXY+T24gMjIvMDcvMjgxNjQgMTM6NTksIEVyYW4gSGFtbWVy LUxhaGF2IHdyb3RlOiANCiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxmb250IGZhY2U9 IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJGT05ULVNJ WkU6IDExcHQiPlRoZSBmb2xsb3dpbmcgd2FzIHN1Ym1pdHRlZCB2aWEgdGhlIHNoYXJlZC1jb3B5 IA0KICAgICAgICBwYWdlIGJ1dCBkb2VzIG5vdCBiZWxvbmcgd2l0aCBlZGl0b3JpYWwgZmVlZGJh Y2suIFRoaXMgbmVlZHMgdG8gYmUgDQogICAgICAgIGRpc2N1c3NlZCBhbmQgc3VwcG9ydGVkIG9u IHRoZSBsaXN0IGJlZm9yZSBhZGRlZCB0aGUgc3BlY2lmaWNhdGlvbi4gSSANCiAgICAgICAgdGhp bmsgaXQgYmVsb25ncyB3aGVyZSDigJhpbW1lZGlhdGXigJkgaXMgDQogICAgICAgIHNwZWNpZmll ZC48YnI+PGJyPkVITDxicj48YnI+LS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlPGJyPjwvc3Bhbj48 L2ZvbnQ+DQogICAgICAgIDxibG9ja3F1b3RlPjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEs IEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJGT05ULVNJWkU6IDExcHQiPjxiPkZyb206 IDwvYj5BbiBhbm9ueW1vdXMgcmVhZGVyICZsdDs8YSBocmVmPSJodHRwOi8vbWFpbG1hbkBzaGFy ZWRjb3B5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9Im1haWx0bzptYWlsbWFuQHNoYXJl ZGNvcHkuY29tIj5tYWlsbWFuQHNoYXJlZGNvcHkuY29tPC9hPjwvYT4mZ3Q7PGJyPjxiPkRhdGU6 IDwvYj5TYXQsIDEwIA0KICAgICAgICAgIEp1bCAyMDEwIDExOjAxOjExIC0wNzAwPGJyPjxiPlRv OiA8L2I+RXJhbiBIYW1tZXItTGFoYXYgJmx0OzxhIGhyZWY9Imh0dHA6Ly9lcmFuQGh1ZW5pdmVy c2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5j b20iPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+PC9hPiZndDs8YnI+PGI+U3ViamVjdDogPC9iPlJl OiANCiAgICAgICAgICBkcmFmdC1pZXRmLW9hdXRoLXYyLTA5IC0gVGhlIE9BdXRoIDIuMCANCiAg ICAgICAgUHJvdG9jb2w8YnI+PGJyPjwvc3Bhbj48L2ZvbnQ+PC9ibG9ja3F1b3RlPjxmb250IGZh Y2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJGT05U LVNJWkU6IDExcHQiPjxicj48L3NwYW4+PC9mb250Pg0KICAgICAgICA8YmxvY2txdW90ZT48Zm9u dCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0i Rk9OVC1TSVpFOiAxMXB0Ij4mbmJzcDs8Yj4iQ29saW4gU25vdmVyIjwvYj4gbGVmdCB0aGVzZSAN CiAgICAgICAgICBjb21tZW50cyBvbiB5b3VyIGNvcHk6IDxicj4mbmJzcDs8YnI+PC9zcGFuPjxm b250IHNpemU9IjUiPjxzcGFuIHN0eWxlPSJGT05ULVNJWkU6IDE4cHQiPjxiPmRyYWZ0LWlldGYt b2F1dGgtdjItMDkgLSBUaGUgT0F1dGggMi4wIA0KICAgICAgICAgIFByb3RvY29sICZsdDs8YSBo cmVmPSJodHRwOi8vcjYuc2hhcmVkY29weS5jb20vNmJucXE4diIgdGFyZ2V0PSJfYmxhbmsiPjxh IGhyZWY9Imh0dHA6Ly9yNi5zaGFyZWRjb3B5LmNvbS82Ym5xcTh2Ij5odHRwOi8vcjYuc2hhcmVk Y29weS5jb20vNmJucXE4djwvYT48L2E+Jmd0OyANCiAgICAgICAgICA8YnI+PC9iPjwvc3Bhbj48 L2ZvbnQ+PHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTFwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtBcyANCiAgICAgICAgICBwcm9wb3NlZCBvbiB0aGUgTUwsIGEgbmV3IHBhcmFtZXRl ciB0byBjb3VudGVyYWN0IHRoZSBjdXJyZW50IA0KICAgICAgICAgIGJlaGF2aW91ciBvZiBPQXV0 aCAxLjBhIGF1dGhvcml6YXRpb24gc2VydmVycyB3aGljaCBpcyB0byBhc3N1bWUgdGhhdCANCiAg ICAgICAgICB0aGUgYWNjb3VudCBsb2dnZWQgaW50byB0aGUgdXNlci1hZ2VudCBpcyB0aGUgYWNj b3VudCB0aGF0IHNob3VsZCBiZSANCiAgICAgICAgICBjaGVja2VkIGZvciANCiAgICAgICAgICBh Y2Nlc3M6PGJyPjxicj5mb3JjZV9hdXRoPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO09QVElPTkFMLiANCiAgICAgICAgICBUaGUgcGFyYW1l dGVyIHZhbHVlIG11c3QgYmUgc2V0IHRvICJ0cnVlIiBvciANCiAgICAgICAgICAiZmFsc2UiLjxi cj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7SWYgDQogICAgICAgICAgc2V0IHRvICJ0cnVlIiwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IE1VU1QgcHJvbXB0IHRoZSBlbmQtdXNlciB0byANCiAgICAgICAgICBhdXRoZW50aWNhdGUgYW5k IGFwcHJvdmUgYWNjZXNzLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBOT1QgDQogICAg ICAgICAgbWFrZSBhbnkgYXNzdW1wdGlvbnMgYXMgdG8gdGhlIGlkZW50aXR5IG9mIHRoZSBlbnRp dHkgcmVxdWVzdGluZyANCiAgICAgICAgICBhY2Nlc3MsIGV2ZW4gaWYgYW5vdGhlciBhdXRvbWF0 aWMgbWVjaGFuaXNtIGlzIGF2YWlsYWJsZSB0byBkbyBzbyANCiAgICAgICAgICAoZS5nLiBicm93 c2VyIA0KICAgICAgICAgIGNvb2tpZXMpLjxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SWYgDQogICAgICAgICAgc2V0IHRvICJmYWxz ZSIgb3Igbm90IHByZXNlbnQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgDQogICAgICAg ICAgYXV0b21hdGljYWxseSBncmFudCBhY2Nlc3MgdG8gdGhlIGNsaWVudCBpZiBpdCBpcyBhYmxl IHRvIGRldGVybWluZSANCiAgICAgICAgICB0aGF0IGFjY2VzcyB3YXMgcHJldmlvdXNseSBncmFu dGVkLiANCiAgICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtsaW5rIMK7ICZsdDs8YSBocmVmPSJodHRwOi8vcjYuc2hhcmVkY29weS5jb20vNmJu cXE4diNzaGNwMjEiIHRhcmdldD0iX2JsYW5rIj48YSBocmVmPSJodHRwOi8vcjYuc2hhcmVkY29w eS5jb20vNmJucXE4diNzaGNwMjEiPmh0dHA6Ly9yNi5zaGFyZWRjb3B5LmNvbS82Ym5xcTh2I3No Y3AyMTwvYT48L2E+Jmd0OyANCiAgICAgICAgICA8YnI+Jm5ic3A7PGJyPjxicj48YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLTA5IiB0YXJnZXQ9 Il9ibGFuayI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v YXV0aC12Mi0wOSI+dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLTA5PC9h PjwvYT4gJmx0OzxhIGhyZWY9Imh0dHA6Ly9yNi5zaGFyZWRjb3B5LmNvbS82Ym5xcTh2IiB0YXJn ZXQ9Il9ibGFuayI+PGEgaHJlZj0iaHR0cDovL3I2LnNoYXJlZGNvcHkuY29tLzZibnFxOHYiPmh0 dHA6Ly9yNi5zaGFyZWRjb3B5LmNvbS82Ym5xcTh2PC9hPjwvYT4mZ3Q7ICZuYnNwO8K3IA0KICAg ICAgICAgIE9yaWdpbmFsIHBhZ2UgJmx0OzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItMDkiIHRhcmdldD0iX2JsYW5rIj48YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLTA5Ij5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLTA5PC9hPjwvYT4mZ3Q7IA0KICAg ICAgICAgIDxicj4mbmJzcDsmbmJzcDs8YnI+Jm5ic3A7PGJyPg0KICAgICAgICAgIDxociBhbGln bj0iY2VudGVyIiBzaXplPSIzIiB3aWR0aD0iMTAwJSI+DQogICAgICAgICAgdmlhIDxhIGhyZWY9 Imh0dHA6Ly9zaGFyZWRjb3B5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9Imh0dHA6Ly9z aGFyZWRjb3B5LmNvbSI+c2hhcmVkY29weS5jb208L2E+PC9hPiANCiAgICAgICAgICAmbHQ7PGEg aHJlZj0iaHR0cDovL3NoYXJlZGNvcHkuY29tLz9lZiIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9 Imh0dHA6Ly9zaGFyZWRjb3B5LmNvbS8/ZWYiPmh0dHA6Ly9zaGFyZWRjb3B5LmNvbS8/ZWY8L2E+ PC9hPiZndDsgDQogICAgICAgICAgJm5ic3A7PGJyPjwvc3Bhbj48L2ZvbnQ+PC9ibG9ja3F1b3Rl Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0 eWxlPSJGT05ULVNJWkU6IDExcHQiPjxicj4tLS0tLS0gRW5kIG9mIEZvcndhcmRlZCANCiAgICAg ICAgTWVzc2FnZTxicj48L3NwYW4+PC9mb250PjwvYmxvY2txdW90ZT48YnI+SGkgRXJhbiw8YnI+ PGJyPlNvcnJ5IGlmIHRoYXQgDQogICAgICB3YXMgbm90IHRoZSByaWdodCBwbGFjZSBmb3IgdGhh dCB0byBnbzsgSSBkaWRu4oCZdCBrbm93IHdoYXQgZWxzZSB0byBkby4gSSANCiAgICAgIGhhdmUg dHJpZWQgdG8gc29saWNpdCBmZWVkYmFjayBmcm9tIHRoZSBNTCByZWdhcmRpbmcgdGhpcyBwYXJh bWV0ZXIgdHdpY2UgDQogICAgICBhbmQgbm9ib2R5IHNlZW1zIHZlcnkga2VlbiBpbiBwcm92aWRp bmcgYW55LCB3aGljaCBpcyBraW5kIG9mIGEgYnVtbWVyLiBJIA0KICAgICAgd2FpdGVkIHVudGls IHRoZSBsYXN0IHBvc3NpYmxlIG1vbWVudCB0byBhZGQgaXQgaW4gdGhlIGhvcGVzIHRoYXQgc29t ZW9uZSANCiAgICAgIHdvdWxkIG5vdGljZSBteSBtZXNzYWdlcyBhbmQgZGlzY3VzcyBpdCwgYnV0 IHlvdSBtYWRlIGl0IHNvdW5kIGxpa2UgeW91ciANCiAgICAgIHBsYW4gd2FzIGZvciBkcmFmdCAx MCB0byBiZSBwb3RlbnRpYWxseSBmaW5hbCBzbyBJIHdhbnRlZCB0byBnZXQgaXQgaW4gDQogICAg ICBiZWZvcmUgdGhlIGRlYWRsaW5lLjxicj48YnI+SeKAmW0gc3VyZSB0aGlzIGlzIG5vdCBhIGJp ZyBkZWFsIGZvciBtb3N0IA0KICAgICAgYXBwbGljYXRpb25zIHRoYXQgZXhwZWN0IGF0IG1vc3Qg YSBzaW5nbGUgY29ubmVjdGlvbiwgYnV0IGZvciBtZSB0aGlzIGlzIGEgDQogICAgICBodWdlIGRl YWwgc2luY2UgaXQgY29tcGxldGVseSBpbW1vbGF0ZXMgb3VyIGFwcGxpY2F0aW9u4oCZcyBhdXRo ZW50aWNhdGlvbiANCiAgICAgIGZsb3csIGFuZCBJIGNhbuKAmXQgZ28gdG8gZXZlcnkgcHJvdmlk ZXIgYXNraW5nIHRoZW0gdG8gcGxlYXNlIGNoYW5nZSB0aGUgDQogICAgICB3YXkgdGhleSBpbXBs ZW1lbnQgdGhlIGF1dGhlbnRpY2F0aW9uIHBvcnRpb24gb2YgdGhlaXIgT0F1dGggDQogICAgICBB UEkuPGJyPjxicj5JbiBjb250cmFzdCB0byDigJhpbW1lZGlhdGXigJksIHdoaWNoIGhhZCBzb21l IGNvbmNlcm5zIHZpcyDDoCB2aXMgDQogICAgICBzZWN1cml0eSwgZm9yY2VfYXV0aCBpcyBhY3R1 YWxseSBzYWZlciB0aGFuIHRoZSBjdXJyZW50IG5vcm1hbCBmbG93IHVzZWQgDQogICAgICBieSBt b3N0IE9BdXRoIHByb3ZpZGVycyBzaW5jZSBpdCByZXF1aXJlcyB0aGUgcHJvdmlkZXIgdG8gbWFr ZSBubyBndWVzc2VzIA0KICAgICAgYWJvdXQgd2hvIGlzIHRyeWluZyB0byBhdXRob3JpemUgdGhl IGFwcC48YnI+PGJyPkZyYW5rbHksIEkgdGhpbmsgdGhhdCANCiAgICAgIE9BdXRoIHByb3ZpZGVy cyBkbyB0aGUgd3JvbmcgdGhpbmcgbm93IGluIGFsbCBjYXNlcyBieSBhc3N1bWluZyB0aGF0IA0K ICAgICAgYnJvd3NlciBjb29raWVzIGFyZSBhIHNhZmUgd2F5IG9mIGNvbmZpcm1pbmcgdGhlIGlk ZW50aXR5IG9mIHRoZSBlbmQtdXNlciANCiAgICAgIG1ha2luZyBhbiBhdXRob3JpemF0aW9uIHJl cXVlc3QgKHRoZXkgYXJlbuKAmXQhKSwgYnV0IHRoZSBzcGVjIHNheXMgdGhlIHdheSANCiAgICAg IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSBlbmQtdXNlciBpcyBv dXRzaWRlIHRoZSBzY29wZSANCiAgICAgIG9mIHRoZSBzcGVjLiBJIGhhdmUgbm8gb2JqZWN0aW9u IHRvIHRoaXPigJRPQXV0aCAqc2hvdWxkKiBiZSANCiAgICAgIGF1dGhlbnRpY2F0aW9uLWFnbm9z dGlj4oCUYnV0IGF0IHRoZSBzYW1lIHRpbWUgdGhpcyBpcyBhIHZlcnkgcmVhbCBhbmQgDQogICAg ICBwcmVzZW50IGltcGxlbWVudGF0aW9uIGZsYXcgYW5kIHRoZSBvbmx5IHdheSB0byBzb2x2ZSBp dCBpcyB0byBtYWtlIHN1cmUgDQogICAgICB0aGUgc3BlYyBkZWZpbmVzIGEgd2F5IGZvciBhbiBh cHBsaWNhdGlvbiB0byBzYXkg4oCcaGV5LCBJIGtub3cgeW91ICp0aGluayogDQogICAgICB5b3Ug a25vdyB3aG8gc2hvdWxkIGJlIGF1dGhlbnRpY2F0ZWQsIGJ1dCAqSSoga25vdyB0aGF0IHRoZSB1 c2VyIGhhcyANCiAgICAgIHJlcXVlc3RlZCB0byBjb25uZWN0IGEgKm5ldyogYWNjb3VudCwgc28g ZG9u4oCZdCB1c2UgYW55IGF1dG9tYXRpYyANCiAgICAgIGF1dGhlbnRpY2F0aW9uIG1ldGhvZOKA nS48YnI+PGJyPkkgdGhpbmsgaXQgaXMgaW5jcmVkaWJseSBpbXBvcnRhbnQgdGhhdCB0aGUgDQog ICAgICBPQXV0aCBzcGVjIGdldHMgcHJvdmlkZXJzIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gYXV0 b21hdGljICZhbXA7IA0KICAgICAgcG90ZW50aWFsbHkgdW5zYWZlIGF1dGhlbnRpY2F0aW9uIG1l dGhvZHMgKGxpa2Ugc2Vzc2lvbiBjb29raWVzKSB2ZXJzdXMgDQogICAgICBtb3JlIOKAnGd1YXJh bnRlZWTigJ0gYXV0aGVudGljYXRpb24gKGxpa2UgcGFzc3dvcmQpLCBlc3BlY2lhbGx5IHNpbmNl IDk5Ljk5OSUgDQogICAgICBvZiB0aGUgdGltZSBPQXV0aCByZWxpZXMgb24gdGhlIGVuZC11c2Vy 4oCZcyBXZWIgYnJvd3NlciB3aGljaCBpcyBhbGwgYnV0IA0KICAgICAgZ3VhcmFudGVlZCB0byBj b250YWluIHNvbWUgY29va2llcyBmb3IgdGhlIHByb3ZpZGVyIHRoYXQgYXJlIHVucmVsYXRlZCB0 byANCiAgICAgIHRoZSByZXF1ZXN0aW5nIGFwcGxpY2F0aW9uLjxicj48YnI+RXhhbXBsZXM6PGJy Pjxicj4xLiBNdWx0aXBsZSBlbmQtdXNlcnMgDQogICAgICB3aXRoIG1hbGljaW91cyBpbnRlbnQu IFVzZXIgMSBpcyBsb2dnZWQgaW50byB0aGVpciBGYWNldHdlZXRyIGFjY291bnQuIA0KICAgICAg VXNlciAyIHdhbnRzIHRvIGRvIGJhZCB0aGluZ3MgdXNpbmcgVXNlciAx4oCZcyBhY2NvdW50LiBC ZWNhdXNlIHRoZSANCiAgICAgIHVzZXItYWdlbnQgaGFzIGNvb2tpZXMgZm9yIHVzZXIgMSwgdXNl ciAyIGdldHMgdG8gYXV0aG9yaXplIHRoZWlyIGFjY291bnQgDQogICAgICB3aXRoIG91ciBhcHAu IEV2ZW4gd2hlbiB1c2VyIDEgY2hhbmdlcyB0aGVpciBwYXNzd29yZCwgdW5sZXNzIHRoZSBwcm92 aWRlciANCiAgICAgIGF1dG9tYXRpY2FsbHkgaW52YWxpZGF0ZXMgdGhlaXIgZXhpc3RpbmcgY29u bmVjdGlvbnMgKHRoZSBzcGVjIGRvZXMgbm90IA0KICAgICAgZXZlbiBtZW50aW9uIGRvaW5nIHRo aXMgaW4gYW4gaW5mb3JtYXRpdmUgbWFubmVyIGFzIGZhciBhcyBJIGNhbiB0ZWxsKSwgDQogICAg ICB0aGV5IGFyZSBhbG1vc3QgY2VydGFpbmx5IHVuYXdhcmUgdGhhdCB0aGUgbGlua2VkIGFwcGxp Y2F0aW9uIGlzIHN0aWxsIA0KICAgICAgYWJsZSB0byBwZXJmb3JtIGFjdGlvbnMgb24gdGhlaXIg YmVoYWxmLjxicj48YnI+Mi4gU2luZ2xlIGVuZC11c2VyIHdpdGggDQogICAgICBtdWx0aXBsZSBh Y2NvdW50cy4mbmJzcDtVc2VyIGlzIGxvZ2dlZCBpbnRvIEZhY2V0d2VldHIgYWNjb3VudCAxLCBi dXQgdGhleSANCiAgICAgIHdhbnQgdG8gYXV0aG9yaXplIGFjY291bnQgMi4gVGhleSBnbyB0byBh dXRob3JpemUgdGhlIGFwcGxpY2F0aW9uIGFuZCBhcmUgDQogICAgICBwcmVzZW50ZWQgd2l0aCBh IGNvbmZpcm1hdGlvbiBmb3IgYWNjb3VudCAxLiBUaGV5IGxvZyBvdXQgKGJlY2F1c2UgdGhpcyBp cyANCiAgICAgIHRoZSBvbmx5IHdheSB0byBzd2l0Y2ggYWNjb3VudHMgb24gdGhlIHByb3ZpZGVy KSBhbmQgc3VkZGVubHkgdGhlIA0KICAgICAgYXV0aG9yaXphdGlvbiBmbG93IGlzIGRyb3BwZWQg b24gdGhlIGZsb29yLiBUaGUgdXNlciBtYXkgbm90IGtub3cgDQogICAgICBpbW1lZGlhdGVseSB3 aGF0IHRoZXkgbmVlZCB0byBkbyBhdCB0aGlzIHBvaW50LiBUaGV5IHdpbGwgbmVlZCB0byBtYW51 YWxseSANCiAgICAgIHJldHVybiB0byB0aGUgb3JpZ2luYWwgYXBwbGljYXRpb24gYW5kIHJlc3Rh cnQgdGhlIGF1dGhvcml6YXRpb24gDQogICAgICByZXF1ZXN0Ljxicj48YnI+My4gVXNlciBoYXMg dHdvIGFjY291bnRzIHRoYXQgdGhleSB3YW50IHRvIGF1dGhvcml6ZSB3aXRoIA0KICAgICAgYSBw cm92aWRlci4gVXNlciBhdXRob3JpemVzIGFjY291bnQgMSBzdWNjZXNzZnVsbHksIHRoZW4gd2Fu dHMgdG8gDQogICAgICBhdXRob3JpemUgYWNjb3VudCAyLiBCZWNhdXNlIGFjY291bnQgMSBpcyBz dGlsbCBsb2dnZWQgaW4sIGFuZCBiZWNhdXNlIHRoZSANCiAgICAgIGFwcGxpY2F0aW9uIGFscmVh ZHkgaGFzIGEgbGluayB0byB0aGUgYWNjb3VudCwgaXQgYXV0b21hdGljYWxseSByZWRpcmVjdHMg DQogICAgICBiYWNrIHRvIHRoZSBhcHBsaWNhdGlvbuKAmXMgcmVkaXJlY3Rpb24gVVJJLiBJbiBv cmRlciBmb3IgdGhlIHVzZXIgdG8gZ2V0IA0KICAgICAgd2hhdCB0aGV5IHdhbnQsIHRoZXkgYXJl IGZvcmNlZCB0byBtYW51YWxseSBuYXZpZ2F0ZSB0byB0aGUgcHJvdmlkZXLigJlzIA0KICAgICAg c2l0ZSwgbG9nIG91dCwgKnRoZW4qIGJlZ2luIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QuPGJy Pjxicj5UaGVzZSBhcmVu4oCZdCANCiAgICAgIGltYWdpbmFyeSBzY2VuYXJpb3M7IHRoZXkgYXJl IHRoaW5ncyB0aGF0IGFyZSBnb2luZyBvbiAqcmlnaHQgbm93KiB3aXRoIA0KICAgICAgc2V2ZXJh bCBkaWZmZXJlbnQgT0F1dGggcHJvdmlkZXJzLjxicj48YnI+VGhlIG9yaWdpbmFsIHJlcXVlc3Q6 IDxhIGhyZWY9Imh0dHA6Ly93d3cubWFpbC1hcmNoaXZlLmNvbS9vYXV0aEBpZXRmLm9yZy9tc2cw MjMzMS5odG1sIiB0YXJnZXQ9Il9ibGFuayI+Jmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cubWFpbC1h cmNoaXZlLmNvbS9vYXV0aEBpZXRmLm9yZy9tc2cwMjMzMS5odG1sIj5odHRwOi8vd3d3Lm1haWwt YXJjaGl2ZS5jb20vb2F1dGhAaWV0Zi5vcmcvbXNnMDIzMzEuaHRtbDwvYT4mZ3Q7PC9hPjxicj48 YnI+UmVnYXJkcyw8YnI+PHByZSBjb2xzPSI3MiI+LS0gDQpDb2xpbiBTbm92ZXINCjxhIGhyZWY9 Imh0dHA6Ly96ZXRhZmxlZXQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PGEgaHJlZj0iaHR0cDovL3pl dGFmbGVldC5jb20iPmh0dHA6Ly96ZXRhZmxlZXQuY29tPC9hPjwvYT4NCjwvcHJlPjwvZGl2Pjwv ZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+T0F1dGggDQogICAgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9 Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5P QXV0aEBpZXRmLm9yZzwvYT48L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvYT48YnI+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48 YnI+PC9kaXY+PC9ibG9ja3F1b3RlPg0KPC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --_000_CB637441A978438AA4A4EF8D6B05FD2Chueniversecom_-- From wmills@yahoo-inc.com Tue Jul 13 10:18: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 E42E83A6A9C for ; Tue, 13 Jul 2010 10:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.389 X-Spam-Level: X-Spam-Status: No, score=-17.389 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe4-6zu4RCYi for ; Tue, 13 Jul 2010 10:18:57 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id BFC033A6824 for ; Tue, 13 Jul 2010 10:18:56 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6DHIaUJ026286; Tue, 13 Jul 2010 10:18:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=tFneH3wvbrub2yG4+YJm4cRXcyVsmLkRcY+9dUfhk5r1eF7VGRx42CrPdpal2PeR Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 10:18:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB22AF.69D369CE" Date: Tue, 13 Jul 2010 10:18:29 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6C1A@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] ' force_auth' request parameter Thread-Index: AcsirgEd+AAX5llfSkKNmCv5xZ8KrgAAQSXQ References: <4C3C92D2.80209@zetafleet.com> <012AB2B223CB3F4BB846962876F47217059B6C12@SNV-EXVS08.ds.corp.yahoo.com> <012AB2B223CB3F4BB846962876F47217059B6C16@SNV-EXVS08.ds.corp.yahoo.com> From: "William Mills" To: "Eran Hammer-Lahav" X-OriginalArrivalTime: 13 Jul 2010 17:18:36.0429 (UTC) FILETIME=[6DA433D0:01CB22AF] Cc: Colin Snover , OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:18:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB22AF.69D369CE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree it changes the boundaries. I think this one needs moving. As I = said we hit a significant problem with this, which we solved by virtue = of the fact that the target we were working with has an un-crumbed = logout, so we could XSRF the logout. =20 It's something people get wrong and we should make a way to get it = right. ________________________________ From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Tuesday, July 13, 2010 10:08 AM To: William Mills Cc: David Recordon; Colin Snover; OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter =09 =09 The question is if we have consensus to force providers to support it.=20 =09 =09 It seems to overstep the boundaries we set over the years and it makes = assumptions about how services authenticate users and obtain approvals.=20 EHL =09 On Jul 13, 2010, at 13:05, William Mills wrote: =09 =09 I think it's a mistake not to have force_auth in the core. ________________________________ From: David Recordon [mailto:recordond@gmail.com]=20 Sent: Tuesday, July 13, 2010 9:58 AM To: William Mills Cc: Colin Snover; Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter =09 =09 I support immediate and a form of forced auth (ala OpenID's PAPE) but = not in the core spec. They both should be part of an identity extension. = On Tue, Jul 13, 2010 at 9:51 AM, William Mills < = wmills@yahoo-inc.com> wrote: =09 I agree with Colin that some form of force_auth is needed. I = haven't read enough on the "immediate" proposal, but I know that we have = run into the problem of trusting currently set cookies in the browser = (even when we're actually sending a username/password and really do want = to have an authentication). =20 I'm a +1 on the force_auth proposal. ________________________________ From: oauth-bounces@ietf.org = [mailto: oauth-bounces@ietf.org] On = Behalf Of Colin Snover Sent: Tuesday, July 13, 2010 9:23 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter =09 =09 On 22/07/28164 13:59, Eran Hammer-Lahav wrote:=20 The following was submitted via the shared-copy page but does not = belong with editorial feedback. This needs to be discussed and supported = on the list before added the specification. I think it belongs where = 'immediate' is specified. =09 EHL =09 ------ Forwarded Message =09 From: An anonymous reader < = mailman@sharedcopy.com> Date: Sat, 10 Jul 2010 11:01:11 -0700 To: Eran Hammer-Lahav < = eran@hueniverse.com> Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol =09 =09 =09 =09 "Colin Snover" left these comments on your copy:=20 =20 draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol < = http://r6.sharedcopy.com/6bnqq8v>=20 =20 =09 As proposed on the ML, a new parameter to counteract the = current behaviour of OAuth 1.0a authorization servers which is to assume = that the account logged into the user-agent is the account that should = be checked for access: =09 force_auth OPTIONAL. The parameter value must be set to "true" or = "false". =09 If set to "true", the authorization server MUST prompt the = end-user to authenticate and approve access. The authorization server = MUST NOT make any assumptions as to the identity of the entity = requesting access, even if another automatic mechanism is available to = do so (e.g. browser cookies). =09 If set to "false" or not present, the authorization server = MAY automatically grant access to the client if it is able to determine = that access was previously granted. link =BB < = = http://r6.sharedcopy.com/6bnqq8v#shcp21>=20 =20 =09 = tools.ietf.org/html/draft-ietf-oauth-v2-09 < = http://r6.sharedcopy.com/6bnqq8v> = =B7 Original page < = http://tools.ietf.org/html/draft-ietf-oauth-v2-09>=20 =20 =20 =09 ________________________________ via sharedcopy.com < = http://sharedcopy.com/?ef> =20 =09 =09 ------ End of Forwarded Message =09 Hi Eran, =09 Sorry if that was not the right place for that to go; I didn't know = what else to do. I have tried to solicit feedback from the ML regarding = this parameter twice and nobody seems very keen in providing any, which = is kind of a bummer. I waited until the last possible moment to add it = in the hopes that someone would notice my messages and discuss it, but = you made it sound like your plan was for draft 10 to be potentially = final so I wanted to get it in before the deadline. =09 I'm sure this is not a big deal for most applications that expect = at most a single connection, but for me this is a huge deal since it = completely immolates our application's authentication flow, and I can't = go to every provider asking them to please change the way they implement = the authentication portion of their OAuth API. =09 In contrast to 'immediate', which had some concerns vis =E0 vis = security, force_auth is actually safer than the current normal flow used = by most OAuth providers since it requires the provider to make no = guesses about who is trying to authorize the app. =09 Frankly, I think that OAuth providers do the wrong thing now in all = cases by assuming that browser cookies are a safe way of confirming the = identity of the end-user making an authorization request (they aren't!), = but the spec says the way the authorization server authenticates the = end-user is outside the scope of the spec. I have no objection to = this-OAuth *should* be authentication-agnostic-but at the same time this = is a very real and present implementation flaw and the only way to solve = it is to make sure the spec defines a way for an application to say = "hey, I know you *think* you know who should be authenticated, but *I* = know that the user has requested to connect a *new* account, so don't = use any automatic authentication method". =09 I think it is incredibly important that the OAuth spec gets = providers to distinguish between automatic & potentially unsafe = authentication methods (like session cookies) versus more "guaranteed" = authentication (like password), especially since 99.999% of the time = OAuth relies on the end-user's Web browser which is all but guaranteed = to contain some cookies for the provider that are unrelated to the = requesting application. =09 Examples: =09 1. Multiple end-users with malicious intent. User 1 is logged into = their Facetweetr account. User 2 wants to do bad things using User 1's = account. Because the user-agent has cookies for user 1, user 2 gets to = authorize their account with our app. Even when user 1 changes their = password, unless the provider automatically invalidates their existing = connections (the spec does not even mention doing this in an informative = manner as far as I can tell), they are almost certainly unaware that the = linked application is still able to perform actions on their behalf. =09 2. Single end-user with multiple accounts. User is logged into = Facetweetr account 1, but they want to authorize account 2. They go to = authorize the application and are presented with a confirmation for = account 1. They log out (because this is the only way to switch accounts = on the provider) and suddenly the authorization flow is dropped on the = floor. The user may not know immediately what they need to do at this = point. They will need to manually return to the original application and = restart the authorization request. =09 3. User has two accounts that they want to authorize with a = provider. User authorizes account 1 successfully, then wants to = authorize account 2. Because account 1 is still logged in, and because = the application already has a link to the account, it automatically = redirects back to the application's redirection URI. In order for the = user to get what they want, they are forced to manually navigate to the = provider's site, log out, *then* begin the authorization request. =09 These aren't imaginary scenarios; they are things that are going on = *right now* with several different OAuth providers. =09 The original request: < = = http://www.mail-archive.com/oauth@ietf.org/msg02331.html> =09 Regards, =09 --=20 Colin Snover http://zetafleet.com _______________________________________________ OAuth mailing list OAuth@ietf.org = https://www.ietf.org/mailman/listinfo/oauth =09 =09 ------_=_NextPart_001_01CB22AF.69D369CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree it changes the boundaries.  I think = this one=20 needs moving.  As I said we hit a significant problem with this, = which we=20 solved by virtue of the fact that the target we were working with has an = un-crumbed logout, so we could XSRF the logout.
 
It's something people get wrong and we should make = a way to=20 get it right.

From: Eran Hammer-Lahav=20 [mailto:eran@hueniverse.com]
Sent: Tuesday, July 13, 2010 = 10:08=20 AM
To: William Mills
Cc: David Recordon; Colin = Snover;=20 OAuth WG
Subject: Re: [OAUTH-WG] ' force_auth' request=20 parameter

The question is if we have consensus to force providers to = support=20 it. 

It seems to overstep the boundaries we set over the years and it = makes=20 assumptions about how services authenticate users and obtain=20 approvals. 

EHL


On Jul 13, 2010, at 13:05, William Mills <wmills@yahoo-inc.com>=20 wrote:

I think it's a mistake not to have force_auth = in the=20 core.

From: David Recordon=20 [mailto:recordond@gmail.com]
Sent: Tuesday, July 13, = 2010 9:58=20 AM
To: William Mills
Cc: Colin Snover; Eran=20 Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] ' = force_auth'=20 request parameter

I support immediate and a form of forced auth (ala = OpenID's=20 PAPE) but not in the core spec. They both should be part of an = identity=20 extension.=20


On Tue, Jul 13, 2010 at 9:51 AM, William = Mills=20 <wmills@yahoo-inc.com>=20 wrote:
I=20 agree with Colin that some form of force_auth is needed.  I = haven't=20 read enough on the "immediate" proposal, but I know that we have = run=20 into the problem of trusting currently set cookies in the = browser (even=20 when we're actually sending a username/password and really do = want to=20 have an authentication).
 
I'm=20 a +1 on the force_auth proposal.

From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org]=20 On Behalf Of Colin Snover
Sent: Tuesday, July = 13,=20 2010 9:23 AM
To: Eran Hammer-Lahav
Cc: = OAuth=20 WG
Subject: Re: [OAUTH-WG] ' force_auth' request=20 parameter

On 22/07/28164 13:59, Eran Hammer-Lahav wrote:=20
The following was submitted via = the=20 shared-copy page but does not belong with editorial = feedback. This=20 needs to be discussed and supported on the list before added = the=20 specification. I think it belongs where =91immediate=92 is=20 specified.

EHL

------ Forwarded=20 Message
From: An anonymous reader = <mailman@sharedcopy.com>=
Date:=20 Sat, 10 Jul 2010 11:01:11 -0700
To: Eran=20 Hammer-Lahav <eran@hueniverse.com>
Subject:=20 Re: draft-ietf-oauth-v2-09 - The OAuth 2.0=20 Protocol


 "Colin Snover" left = these=20 comments on your copy:
 
draft-ietf-oauth-v2-09 - The = OAuth 2.0=20 Protocol <http://r6.sharedcopy.com/6bnqq8= v>=20
        

  = ;   As=20 proposed on the ML, a new parameter to counteract the = current=20 behaviour of OAuth 1.0a authorization servers which is to = assume=20 that the account logged into the user-agent is the account = that=20 should be checked for=20 = access:

force_auth
       &n= bsp; OPTIONAL.=20 The parameter value must be set to "true" or=20 = "false".

         If = set to "true", the authorization server MUST prompt the = end-user=20 to authenticate and approve access. The authorization = server MUST=20 NOT make any assumptions as to the identity of the entity=20 requesting access, even if another automatic mechanism is=20 available to do so (e.g. browser=20 = cookies).

         If= =20 set to "false" or not present, the authorization server = MAY=20 automatically grant access to the client if it is able to=20 determine that access was previously granted.=20         link =BB = <http://r6.sharedcopy.com= /6bnqq8v#shcp21>=20
 

tools.ietf.org= /html/draft-ietf-oauth-v2-09=20 <http://r6.sharedcopy.com/6bnqq8= v>=20  =B7 Original page <http://tools.i= etf.org/html/draft-ietf-oauth-v2-09>=20
  
 
via sharedcopy.com = <http://sharedcopy.com/?ef> =  

------ End of Forwarded=20 Message

Hi = Eran,

Sorry if=20 that was not the right place for that to go; I didn=92t know = what else=20 to do. I have tried to solicit feedback from the ML regarding = this=20 parameter twice and nobody seems very keen in providing any, = which is=20 kind of a bummer. I waited until the last possible moment to = add it in=20 the hopes that someone would notice my messages and discuss = it, but=20 you made it sound like your plan was for draft 10 to be = potentially=20 final so I wanted to get it in before the = deadline.

I=92m sure=20 this is not a big deal for most applications that expect at = most a=20 single connection, but for me this is a huge deal since it = completely=20 immolates our application=92s authentication flow, and I = can=92t go to=20 every provider asking them to please change the way they = implement the=20 authentication portion of their OAuth API.

In contrast = to=20 =91immediate=92, which had some concerns vis =E0 vis security, = force_auth is=20 actually safer than the current normal flow used by most OAuth = providers since it requires the provider to make no guesses = about who=20 is trying to authorize the app.

Frankly, I think that = OAuth=20 providers do the wrong thing now in all cases by assuming that = browser=20 cookies are a safe way of confirming the identity of the = end-user=20 making an authorization request (they aren=92t!), but the spec = says the=20 way the authorization server authenticates the end-user is = outside the=20 scope of the spec. I have no objection to this=97OAuth = *should* be=20 authentication-agnostic=97but at the same time this is a very = real and=20 present implementation flaw and the only way to solve it is to = make=20 sure the spec defines a way for an application to say =93hey, = I know you=20 *think* you know who should be authenticated, but *I* know = that the=20 user has requested to connect a *new* account, so don=92t use = any=20 automatic authentication method=94.

I think it is = incredibly=20 important that the OAuth spec gets providers to distinguish = between=20 automatic & potentially unsafe authentication methods = (like=20 session cookies) versus more =93guaranteed=94 authentication = (like=20 password), especially since 99.999% of the time OAuth relies = on the=20 end-user=92s Web browser which is all but guaranteed to = contain some=20 cookies for the provider that are unrelated to the requesting=20 application.

Examples:

1. Multiple end-users = with=20 malicious intent. User 1 is logged into their Facetweetr = account. User=20 2 wants to do bad things using User 1=92s account. Because the = user-agent has cookies for user 1, user 2 gets to authorize = their=20 account with our app. Even when user 1 changes their password, = unless=20 the provider automatically invalidates their existing = connections (the=20 spec does not even mention doing this in an informative manner = as far=20 as I can tell), they are almost certainly unaware that the = linked=20 application is still able to perform actions on their=20 behalf.

2. Single end-user with multiple = accounts. User is=20 logged into Facetweetr account 1, but they want to authorize = account=20 2. They go to authorize the application and are presented with = a=20 confirmation for account 1. They log out (because this is the = only way=20 to switch accounts on the provider) and suddenly the = authorization=20 flow is dropped on the floor. The user may not know = immediately what=20 they need to do at this point. They will need to manually = return to=20 the original application and restart the authorization=20 request.

3. User has two accounts that they want to = authorize=20 with a provider. User authorizes account 1 successfully, then = wants to=20 authorize account 2. Because account 1 is still logged in, and = because=20 the application already has a link to the account, it = automatically=20 redirects back to the application=92s redirection URI. In = order for the=20 user to get what they want, they are forced to manually = navigate to=20 the provider=92s site, log out, *then* begin the authorization = request.

These aren=92t imaginary scenarios; they are = things that=20 are going on *right now* with several different OAuth=20 providers.

The original request: <http://= www.mail-archive.com/oauth@ietf.org/msg02331.html>

Rega= rds,
--=20
Colin Snover
http://zetafleet.com

________________________________= _______________
OAuth=20 mailing list
OAuth@ietf.org
https://www.ietf.org= /mailman/listinfo/oauth


------_=_NextPart_001_01CB22AF.69D369CE-- From ietf.org@zetafleet.com Tue Jul 13 10:24: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 6335C3A6A5A for ; Tue, 13 Jul 2010 10:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqZ7RUBZEunS for ; Tue, 13 Jul 2010 10:24:01 -0700 (PDT) Received: from one.acitia.com (one.acitia.com [66.135.55.251]) by core3.amsl.com (Postfix) with ESMTP id F351F3A6824 for ; Tue, 13 Jul 2010 10:24:00 -0700 (PDT) Received: from c-75-73-43-136.hsd1.mn.comcast.net ([75.73.43.136] helo=Trillian.hsd1.mn.comcast.net) by one.acitia.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1OYjCR-0000rR-C3; Tue, 13 Jul 2010 17:23:20 +0000 Message-ID: <4C3CA132.3060201@zetafleet.com> Date: Tue, 13 Jul 2010 12:24:02 -0500 From: Colin Snover User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: David Recordon References: <4C3C92D2.80209@zetafleet.com> <012AB2B223CB3F4BB846962876F47217059B6C12@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050204030107090901080202" Cc: OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:24:03 -0000 This is a multi-part message in MIME format. --------------050204030107090901080202 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit The problem I see with pushing this up into an identity layer is that providers that choose to implement their own identity layer (or no identity layer) may still end up doing this implicit authorization thing. Were neither providing a specific identity to connect nor are we requesting identity information from the providerwe simply want to make sure that the provider is not re-using any previous authorizations (a session cookie is just an authorization key by another name), because doing so leads to the scenarios Ive written about (and probably others that I have not considered). Under an authorization system that did not require the use of a Web browser, I would agree much more strongly with the notion that this should be part of a separate layer, but the problem is that the spec *does* utilize Web browsers heavily, and so we need to make considerations for the spec keeping that in mind. To address Erans concern about overstepping bounds, perhaps the language could be changed from MUST to SHOULD, which would leave it up to the provider to make the ultimate decision whilst still being in compliance with the spec? I certainly dont want to step on any toes in that regard, but I also dont want providers to think they can ignore this just because its a little easier to do so. Regards, On 13/07/2010 11:57, David Recordon wrote: > I support immediate and a form of forced auth (ala OpenID's PAPE) but > not in the core spec. They both should be part of an identity extension. > > > On Tue, Jul 13, 2010 at 9:51 AM, William Mills > wrote: > > I agree with Colin that some form of force_auth is needed. I > haven't read enough on the "immediate" proposal, but I know that > we have run into the problem of trusting currently set cookies in > the browser (even when we're actually sending a username/password > and really do want to have an authentication). > I'm a +1 on the force_auth proposal. > > ------------------------------------------------------------------------ > *From:* oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org > ] *On Behalf Of *Colin Snover > *Sent:* Tuesday, July 13, 2010 9:23 AM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] ' force_auth' request parameter > > On 22/07/28164 13:59, Eran Hammer-Lahav wrote: >> The following was submitted via the shared-copy page but does >> not belong with editorial feedback. This needs to be >> discussed and supported on the list before added the >> specification. I think it belongs where immediate is specified. >> >> EHL >> >> ------ Forwarded Message >> >> *From: *An anonymous reader > > >> *Date: *Sat, 10 Jul 2010 11:01:11 -0700 >> *To: *Eran Hammer-Lahav > > >> *Subject: *Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 >> Protocol >> >> >> *"Colin Snover"* left these comments on your copy: >> >> *draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol >> >> * >> >> As proposed on the ML, a new parameter to counteract >> the current behaviour of OAuth 1.0a authorization servers >> which is to assume that the account logged into the >> user-agent is the account that should be checked for access: >> >> force_auth >> OPTIONAL. The parameter value must be set to >> "true" or "false". >> >> If set to "true", the authorization server MUST >> prompt the end-user to authenticate and approve access. >> The authorization server MUST NOT make any assumptions as >> to the identity of the entity requesting access, even if >> another automatic mechanism is available to do so (e.g. >> browser cookies). >> >> If set to "false" or not present, the >> authorization server MAY automatically grant access to >> the client if it is able to determine that access was >> previously granted. link >> >> >> >> tools.ietf.org/html/draft-ietf-oauth-v2-09 >> >> Original page >> >> >> >> ------------------------------------------------------------------------ >> via sharedcopy.com >> >> >> >> ------ End of Forwarded Message > > Hi Eran, > > Sorry if that was not the right place for that to go; I didnt > know what else to do. I have tried to solicit feedback from > the ML regarding this parameter twice and nobody seems very > keen in providing any, which is kind of a bummer. I waited > until the last possible moment to add it in the hopes that > someone would notice my messages and discuss it, but you made > it sound like your plan was for draft 10 to be potentially > final so I wanted to get it in before the deadline. > > Im sure this is not a big deal for most applications that > expect at most a single connection, but for me this is a huge > deal since it completely immolates our applications > authentication flow, and I cant go to every provider asking > them to please change the way they implement the > authentication portion of their OAuth API. > > In contrast to immediate, which had some concerns vis vis > security, force_auth is actually safer than the current normal > flow used by most OAuth providers since it requires the > provider to make no guesses about who is trying to authorize > the app. > > Frankly, I think that OAuth providers do the wrong thing now > in all cases by assuming that browser cookies are a safe way > of confirming the identity of the end-user making an > authorization request (they arent!), but the spec says the > way the authorization server authenticates the end-user is > outside the scope of the spec. I have no objection to > thisOAuth *should* be authentication-agnosticbut at the same > time this is a very real and present implementation flaw and > the only way to solve it is to make sure the spec defines a > way for an application to say hey, I know you *think* you > know who should be authenticated, but *I* know that the user > has requested to connect a *new* account, so dont use any > automatic authentication method. > > I think it is incredibly important that the OAuth spec gets > providers to distinguish between automatic & potentially > unsafe authentication methods (like session cookies) versus > more guaranteed authentication (like password), especially > since 99.999% of the time OAuth relies on the end-users Web > browser which is all but guaranteed to contain some cookies > for the provider that are unrelated to the requesting application. > > Examples: > > 1. Multiple end-users with malicious intent. User 1 is logged > into their Facetweetr account. User 2 wants to do bad things > using User 1s account. Because the user-agent has cookies for > user 1, user 2 gets to authorize their account with our app. > Even when user 1 changes their password, unless the provider > automatically invalidates their existing connections (the spec > does not even mention doing this in an informative manner as > far as I can tell), they are almost certainly unaware that the > linked application is still able to perform actions on their > behalf. > > 2. Single end-user with multiple accounts. User is logged into > Facetweetr account 1, but they want to authorize account 2. > They go to authorize the application and are presented with a > confirmation for account 1. They log out (because this is the > only way to switch accounts on the provider) and suddenly the > authorization flow is dropped on the floor. The user may not > know immediately what they need to do at this point. They will > need to manually return to the original application and > restart the authorization request. > > 3. User has two accounts that they want to authorize with a > provider. User authorizes account 1 successfully, then wants > to authorize account 2. Because account 1 is still logged in, > and because the application already has a link to the account, > it automatically redirects back to the applications > redirection URI. In order for the user to get what they want, > they are forced to manually navigate to the providers site, > log out, *then* begin the authorization request. > > These arent imaginary scenarios; they are things that are > going on *right now* with several different OAuth providers. > > The original request: > > > Regards, > > -- > Colin Snover > http://zetafleet.com > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Colin Snover --------------050204030107090901080202 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit The problem I see with pushing this up into an identity layer is that providers that choose to implement their own identity layer (or no identity layer) may still end up doing this implicit authorization thing. Were neither providing a specific identity to connect nor are we requesting identity information from the providerwe simply want to make sure that the provider is not re-using any previous authorizations (a session cookie is just an authorization key by another name), because doing so leads to the scenarios Ive written about (and probably others that I have not considered).

Under an authorization system that did not require the use of a Web browser, I would agree much more strongly with the notion that this should be part of a separate layer, but the problem is that the spec *does* utilize Web browsers heavily, and so we need to make considerations for the spec keeping that in mind.

To address Erans concern about overstepping bounds, perhaps the language could be changed from MUST to SHOULD, which would leave it up to the provider to make the ultimate decision whilst still being in compliance with the spec? I certainly dont want to step on any toes in that regard, but I also dont want providers to think they can ignore this just because its a little easier to do so.

Regards,


On 13/07/2010 11:57, David Recordon wrote:
I support immediate and a form of forced auth (ala OpenID's PAPE) but not in the core spec. They both should be part of an identity extension.


On Tue, Jul 13, 2010 at 9:51 AM, William Mills <wmills@yahoo-inc.com> wrote:
I agree with Colin that some form of force_auth is needed. I haven't read enough on the "immediate" proposal, but I know that we have run into the problem of trusting currently set cookies in the browser (even when we're actually sending a username/password and really do want to have an authentication).
I'm a +1 on the force_auth proposal.

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Colin Snover
Sent: Tuesday, July 13, 2010 9:23 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] ' force_auth' request parameter

On 22/07/28164 13:59, Eran Hammer-Lahav wrote:
The following was submitted via the shared-copy page but does not belong with editorial feedback. This needs to be discussed and supported on the list before added the specification. I think it belongs where immediate is specified.

EHL

------ Forwarded Message
From: An anonymous reader <mailman@sharedcopy.com>
Date: Sat, 10 Jul 2010 11:01:11 -0700
To: Eran Hammer-Lahav <eran@hueniverse.com>
Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol
"Colin Snover" left these comments on your copy:

draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol <http://r6.sharedcopy.com/6bnqq8v>


As proposed on the ML, a new parameter to counteract the current behaviour of OAuth 1.0a authorization servers which is to assume that the account logged into the user-agent is the account that should be checked for access:

force_auth
OPTIONAL. The parameter value must be set to "true" or "false".

If set to "true", the authorization server MUST prompt the end-user to authenticate and approve access. The authorization server MUST NOT make any assumptions as to the identity of the entity requesting access, even if another automatic mechanism is available to do so (e.g. browser cookies).

If set to "false" or not present, the authorization server MAY automatically grant access to the client if it is able to determine that access was previously granted. link <http://r6.sharedcopy.com/6bnqq8v#shcp21>


tools.ietf.org/html/draft-ietf-oauth-v2-09 <http://r6.sharedcopy.com/6bnqq8v> Original page <http://tools.ietf.org/html/draft-ietf-oauth-v2-09>


via sharedcopy.com <http://sharedcopy.com/?ef>

------ End of Forwarded Message

Hi Eran,

Sorry if that was not the right place for that to go; I didnt know what else to do. I have tried to solicit feedback from the ML regarding this parameter twice and nobody seems very keen in providing any, which is kind of a bummer. I waited until the last possible moment to add it in the hopes that someone would notice my messages and discuss it, but you made it sound like your plan was for draft 10 to be potentially final so I wanted to get it in before the deadline.

Im sure this is not a big deal for most applications that expect at most a single connection, but for me this is a huge deal since it completely immolates our applications authentication flow, and I cant go to every provider asking them to please change the way they implement the authentication portion of their OAuth API.

In contrast to immediate, which had some concerns vis vis security, force_auth is actually safer than the current normal flow used by most OAuth providers since it requires the provider to make no guesses about who is trying to authorize the app.

Frankly, I think that OAuth providers do the wrong thing now in all cases by assuming that browser cookies are a safe way of confirming the identity of the end-user making an authorization request (they arent!), but the spec says the way the authorization server authenticates the end-user is outside the scope of the spec. I have no objection to thisOAuth *should* be authentication-agnosticbut at the same time this is a very real and present implementation flaw and the only way to solve it is to make sure the spec defines a way for an application to say hey, I know you *think* you know who should be authenticated, but *I* know that the user has requested to connect a *new* account, so dont use any automatic authentication method.

I think it is incredibly important that the OAuth spec gets providers to distinguish between automatic & potentially unsafe authentication methods (like session cookies) versus more guaranteed authentication (like password), especially since 99.999% of the time OAuth relies on the end-users Web browser which is all but guaranteed to contain some cookies for the provider that are unrelated to the requesting application.

Examples:

1. Multiple end-users with malicious intent. User 1 is logged into their Facetweetr account. User 2 wants to do bad things using User 1s account. Because the user-agent has cookies for user 1, user 2 gets to authorize their account with our app. Even when user 1 changes their password, unless the provider automatically invalidates their existing connections (the spec does not even mention doing this in an informative manner as far as I can tell), they are almost certainly unaware that the linked application is still able to perform actions on their behalf.

2. Single end-user with multiple accounts.User is logged into Facetweetr account 1, but they want to authorize account 2. They go to authorize the application and are presented with a confirmation for account 1. They log out (because this is the only way to switch accounts on the provider) and suddenly the authorization flow is dropped on the floor. The user may not know immediately what they need to do at this point. They will need to manually return to the original application and restart the authorization request.

3. User has two accounts that they want to authorize with a provider. User authorizes account 1 successfully, then wants to authorize account 2. Because account 1 is still logged in, and because the application already has a link to the account, it automatically redirects back to the applications redirection URI. In order for the user to get what they want, they are forced to manually navigate to the providers site, log out, *then* begin the authorization request.

These arent imaginary scenarios; they are things that are going on *right now* with several different OAuth providers.

The original request: <http://www.mail-archive.com/oauth@ietf.org/msg02331.html>

Regards,
-- 
Colin Snover
http://zetafleet.com

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




-- 
Colin Snover
--------------050204030107090901080202-- From john@jkemp.net Tue Jul 13 10:24: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 027653A6840 for ; Tue, 13 Jul 2010 10:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9Vn4xwNdubY for ; Tue, 13 Jul 2010 10:24:57 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id D130E3A6824 for ; Tue, 13 Jul 2010 10:24:57 -0700 (PDT) Received: (qmail 16077 invoked by uid 0); 13 Jul 2010 17:25:06 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy3.bluehost.com with SMTP; 13 Jul 2010 17:25:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=uYqIfjAMvIUTRQhoZQAgwYIZFj+C7ppTB63Pv2PiFZNvv6zwPjNl2Xh+Umfwobg50CNXptEkWACsqB/EMxC8ZPcQCLtTcOjPhO3A1Z2iewXni/0joXPt7iHQIG144u3n; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.112]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OYjEA-000370-2e; Tue, 13 Jul 2010 11:25:06 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: John Kemp In-Reply-To: Date: Tue, 13 Jul 2010 13:25:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <97BD2762-F147-4774-9557-AD478338B348@jkemp.net> References: To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1081) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:24:59 -0000 On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote: > I am ok replacing it with =91acts as a password=92. An access token is something used by the server to decide whether a = request is authorized. Although it may also be used for authenticating = the request(er), it's purpose is to authorize the request.=20 In the "bearer token" case (and even over SSL unless client certs are = used), the token clearly SHOULD NOT be used as a password. Rather, = authentication should be performed by some other mechanism, unrelated to = the token itself (such as an HMAC, or via client-certificate SSL/TLS, or = even via an actual username/password)=20 I would be very unhappy if we equated access tokens with passwords.=20 I agree with Dirk that "capability" is a more expressive phrase than = either "shared secret" or "password".=20 Regards, - johnk >=20 > EHL >=20 >=20 > On 7/13/10 8:55 AM, "Dirk Balfanz" wrote: >=20 >=20 >=20 > On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav = wrote: > =46rom the client's perspective, they are 'shared symmetric secrets' = because > the client has to store them as-is and present them as-is. The act = exactly > like passwords. I added that text to make that stand out. >=20 > When using passwords, the server doesn't need to store them in = plain-text > either (e.g. uses a way one hash). >=20 > That's why we don't call passwords "shared symmetric secrets", either. = The verifier of a passwords can verify it without knowing the secret. In = that sense, it's not "shared" with the verifier.=20 >=20 > I would like the specification to make it clear that bearer tokens are = only > secure while they remain *secret* and that *anyone* holding them can = gain > full access to what their protect. >=20 > I think the word "capability" expresses that better than the word = "shared secret".=20 >=20 > Dirk. > =20 >=20 > EHL >=20 > On 7/12/10 10:39 PM, "Brian Eaton" wrote: >=20 > > Section 5: = http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5 > > > > Calling access tokens "shared symmetric secrets" is misleading, > > because if they are implemented well the authorization server and > > protected resource do not store a copy of the secret. > > > > Instead they store a one-way hash of the token. Or they verify the > > token cryptographically. Under no circumstances do they need to = store > > a copy. > > > > I'd suggest the following language: > > > > "Access tokens are bearer authentication tokens or capabilities." > > > > Cheers, > > Brian > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Tue Jul 13 10:28: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 4510D3A67B1 for ; Tue, 13 Jul 2010 10:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC6suEif2XHv for ; Tue, 13 Jul 2010 10:28:08 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 728F03A6824 for ; Tue, 13 Jul 2010 10:28:08 -0700 (PDT) Received: (qmail 2689 invoked from network); 13 Jul 2010 17:28:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 17:28:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 13 Jul 2010 10:28:11 -0700 From: Eran Hammer-Lahav To: William Mills Date: Tue, 13 Jul 2010 10:28:08 -0700 Thread-Topic: [OAUTH-WG] ' force_auth' request parameter Thread-Index: AcsirgEd+AAX5llfSkKNmCv5xZ8KrgAAQSXQAABvKMQ= Message-ID: In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6C1A@SNV-EXVS08.ds.corp.yahoo.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C861F038371B0eranhueniversecom_" MIME-Version: 1.0 Cc: Colin Snover , OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:28:21 -0000 --_000_C861F038371B0eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable User authentication and approval interaction has always been the sole domai= n of the authorization server. This proposal shifts the decision towards th= e client. It is unclear to me why is the client better suited to make this = decision? In the context of identity, if a client relies on the server for = its own identity services (e.g. Facebook connect), it makes sense for the c= lient to request stronger authentication than just cookies. But outside the= identity context, I am unconvinced the client is likely to make a smart de= cision. In addition, if we let the client specify this, it will mean differ= ent client will have different user experience on the same server which is = confusing and odd. I'm not opposed to this, just that I don't think this is well thought out. EHL On 7/13/10 10:18 AM, "William Mills" wrote: I agree it changes the boundaries. I think this one needs moving. As I sa= id we hit a significant problem with this, which we solved by virtue of the= fact that the target we were working with has an un-crumbed logout, so we = could XSRF the logout. It's something people get wrong and we should make a way to get it right. ________________________________ From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Tuesday, July 13, 2010 10:08 AM To: William Mills Cc: David Recordon; Colin Snover; OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter The question is if we have consensus to force providers to support it. It seems to overstep the boundaries we set over the years and it makes ass= umptions about how services authenticate users and obtain approvals. EHL On Jul 13, 2010, at 13:05, William Mills wrote: I think it's a mistake not to have force_auth in the core. ________________________________ From: David Recordon [mailto:recordond@gmail.com] Sent: Tuesday, July 13, 2010 9:58 AM To: William Mills Cc: Colin Snover; Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter I support immediate and a form of forced auth (ala OpenID's PAPE) but not = in the core spec. They both should be part of an identity extension. On Tue, Jul 13, 2010 at 9:51 AM, William Mills > wrote: I agree with Colin that some form of force_auth is needed. I haven't rea= d enough on the "immediate" proposal, but I know that we have run into the= problem of trusting currently set cookies in the browser (even when we're= actually sending a username/password and really do want to have an authen= tication). I'm a +1 on the force_auth proposal. ________________________________ From: oauth-bounces@ietf.org [mailto:oaut= h-bounces@ietf.org ] On Behalf Of Colin Sn= over Sent: Tuesday, July 13, 2010 9:23 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter On 22/07/28164 13:59, Eran Hammer-Lahav wrote: The following was submitted via the shared-copy page but does not belong w= ith editorial feedback. This needs to be discussed and supported on the li= st before added the specification. I think it belongs where 'immediate' is= specified. EHL ------ Forwarded Message From: An anonymous reader > Date: Sat, 10 Jul 2010 11:01:11 -0700 To: Eran Hammer-Lahav > Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol "Colin Snover" left these comments on your copy: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol > As proposed on the ML, a new parameter to counteract the current beh= aviour of OAuth 1.0a authorization servers which is to assume that the acc= ount logged into the user-agent is the account that should be checked for = access: force_auth OPTIONAL. The parameter value must be set to "true" or "false". If set to "true", the authorization server MUST prompt the end-us= er to authenticate and approve access. The authorization server MUST NOT = make any assumptions as to the identity of the entity requesting access, e= ven if another automatic mechanism is available to do so (e.g. browser co= okies). If set to "false" or not present, the authorization server MAY a= utomatically grant access to the client if it is able to determine that ac= cess was previously granted. link =BB > tools.ietf.org/html/draft-ietf-oauth-v2-09 = > = =B7 Original page > ________________________________ via sharedcopy.com > ------ End of Forwarded Message Hi Eran, Sorry if that was not the right place for that to go; I didn't know what e= lse to do. I have tried to solicit feedback from the ML regarding this pa= rameter twice and nobody seems very keen in providing any, which is kind o= f a bummer. I waited until the last possible moment to add it in the hopes= that someone would notice my messages and discuss it, but you made it sou= nd like your plan was for draft 10 to be potentially final so I wanted to = get it in before the deadline. I'm sure this is not a big deal for most applications that expect at most = a single connection, but for me this is a huge deal since it completely i= mmolates our application's authentication flow, and I can't go to every pr= ovider asking them to please change the way they implement the authenticat= ion portion of their OAuth API. In contrast to 'immediate', which had some concerns vis =E0 vis security, = force_auth is actually safer than the current normal flow used by most OAu= th providers since it requires the provider to make no guesses about who = is trying to authorize the app. Frankly, I think that OAuth providers do the wrong thing now in all cases = by assuming that browser cookies are a safe way of confirming the identity= of the end-user making an authorization request (they aren't!), but the s= pec says the way the authorization server authenticates the end-user is ou= tside the scope of the spec. I have no objection to this-OAuth *should* be= authentication-agnostic-but at the same time this is a very real and pre= sent implementation flaw and the only way to solve it is to make sure the = spec defines a way for an application to say "hey, I know you *think* you = know who should be authenticated, but *I* know that the user has requested= to connect a *new* account, so don't use any automatic authentication met= hod". I think it is incredibly important that the OAuth spec gets providers to d= istinguish between automatic & potentially unsafe authentication methods (= like session cookies) versus more "guaranteed" authentication (like passw= ord), especially since 99.999% of the time OAuth relies on the end-user's = Web browser which is all but guaranteed to contain some cookies for the pr= ovider that are unrelated to the requesting application. Examples: 1. Multiple end-users with malicious intent. User 1 is logged into their F= acetweetr account. User 2 wants to do bad things using User 1's account. B= ecause the user-agent has cookies for user 1, user 2 gets to authorize the= ir account with our app. Even when user 1 changes their password, unless = the provider automatically invalidates their existing connections (the spe= c does not even mention doing this in an informative manner as far as I ca= n tell), they are almost certainly unaware that the linked application is = still able to perform actions on their behalf. 2. Single end-user with multiple accounts. User is logged into Facetweetr = account 1, but they want to authorize account 2. They go to authorize the = application and are presented with a confirmation for account 1. They log = out (because this is the only way to switch accounts on the provider) and = suddenly the authorization flow is dropped on the floor. The user may not = know immediately what they need to do at this point. They will need to man= ually return to the original application and restart the authorization re= quest. 3. User has two accounts that they want to authorize with a provider. User= authorizes account 1 successfully, then wants to authorize account 2. Bec= ause account 1 is still logged in, and because the application already has= a link to the account, it automatically redirects back to the application= 's redirection URI. In order for the user to get what they want, they are = forced to manually navigate to the provider's site, log out, *then* begin = the authorization request. These aren't imaginary scenarios; they are things that are going on *right= now* with several different OAuth providers. The original request: Regards, --_000_C861F038371B0eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] ' force_auth' request parameter User authentication and approval interaction has always been the sole= domain of the authorization server. This proposal shifts the decision towa= rds the client. It is unclear to me why is the client better suited to make= this decision? In the context of identity, if a client relies on the serve= r for its own identity services (e.g. Facebook connect), it makes sense for= the client to request stronger authentication than just cookies. But outsi= de the identity context, I am unconvinced the client is likely to make a sm= art decision. In addition, if we let the client specify this, it will mean = different client will have different user experience on the same server whi= ch is confusing and odd.

I’m not opposed to this, just that I don’t think this is well t= hought out.

EHL


On 7/13/10 10:18 AM, "William Mills" <wmills@yahoo-inc.com> wrote:

I agree it changes the boundaries.  I think= this one needs moving.  As I said we hit a significant problem with t= his, which we solved by virtue of the fact that the target we were working = with has an un-crumbed logout, so we could XSRF the logout.
It's something people g= et wrong and we should make a way to get it right.


 
From: Eran Hammer-Lahav  [mailto:eran@hueniverse.com]
Sent: Tuesday, July 13, 2010 10:08  AM
To: William Mills
Cc: David Recordon; Colin Snover;  OAuth WG
Subject: Re: [OAUTH-WG] ' force_auth' request  parameter

 
 
The question is if we have consensus to force providers to support  it= .

 
It seems to overstep the boundaries we set over the years and it makes &nbs= p;assumptions about how services authenticate users and obtain  approv= als.
 

 
EHL
 

 

On Jul 13, 2010, at 13:05, William Mills <wmills@yahoo-inc.com>  wrote:

 
 

 
I think it's a mistake = not to have force_auth in the  core.

 

 
From: David Recordon  [mailto:recordond@gmail.com]
Sent: Tuesday, July 13, 2010 9:58  AM
To: William Mills
Cc: Colin Snover; Eran  Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] ' force_auth'  request parameter

 
I support immediate and a form of forced auth (ala OpenID's  PAPE) but= not in the core spec. They both should be part of an identity  extens= ion.  


 
On Tue, Jul 13, 2010 at 9:51 AM, William Mills  <wmills@yahoo-inc.com <mailto:wmills@yahoo-inc.com> >  wrote:
 

 
I  agree with Coli= n that some form of force_auth is needed.  I haven't  read enough= on the "immediate" proposal, but I know that we have run  i= nto the problem of trusting currently set cookies in the browser (even &nbs= p;when we're actually sending a username/password and really do want to &nb= sp;have an authentication).
 
 
I'm  a +1 on the f= orce_auth proposal.

 

 
From: = oauth-bounces@ietf.org <ma= ilto:oauth-bounces@ietf.org>   [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org> ]  On Be= half Of Colin Snover
Sent: Tuesday, July 13,  2010 9:23 AM
To: Eran Hammer-Lahav
Cc: OAuth  WG
Subject: Re: [OAUTH-WG] ' force_auth' request  parameter

 
 
 
 
On 22/07/28164 13:59, Eran Hammer-Lahav wrote:  
The following was submitted via the  s= hared-copy page but does not belong with editorial feedback. This  nee= ds to be discussed and supported on the list before added the  specifi= cation. I think it belongs where ‘immediate’ is  specified= .

EHL

------ Forwarded  Message
 
From: An anonymous reader <mailman@sharedcopy.com <mailto:mailman@sharedcopy.com> > Date:  Sat, 10 Jul 2010 11:01:11 -0700
To: Eran  Hammer-Lahav <eran= @hueniverse.com <mailto:eran@= hueniverse.com> >
Subject:  Re: draft-ietf-oauth-v2-09 - The OAuth 2.0  Prot= ocol

<= BLOCKQUOTE>

 
"Colin Snover" left t= hese  comments on your copy:
 
draft-ietf-oauth-v2-09 - The OAuth= 2.0  Protocol <http:/= /r6.sharedcopy.com/6bnqq8v <http://r6.sharedcopy.com/6bnqq8v> >  
     &= nbsp;  

     As  proposed on the ML, a new parameter = to counteract the current  behaviour of OAuth 1.0a authorization serve= rs which is to assume  that the account logged into the user-agent is = the account that  should be checked for  access:

force_auth
         OPTIONAL.  The p= arameter value must be set to "true" or  "false".<= BR>
         If  set to "= ;true", the authorization server MUST prompt the end-user  to aut= henticate and approve access. The authorization server MUST  NOT make = any assumptions as to the identity of the entity  requesting access, e= ven if another automatic mechanism is  available to do so (e.g. browse= r  cookies).

         If  set to "= ;false" or not present, the authorization server MAY  automatical= ly grant access to the client if it is able to  determine that access = was previously granted.         &nb= sp;link » <htt= p://r6.sharedcopy.com/6bnqq8v#shcp21 <http://r6.sharedcopy.com/6bnqq8v#shcp21> > =  
 

tools.ietf.org/html/draft-ietf-oauth-v2-09 <http://tools.ietf.org/html/draft-ietf-oau= th-v2-09>  <http://tools.ietf.org/html/draft-ietf-oauth-v2-09> &nb= sp; <http://r6.sharedc= opy.com/6bnqq8v <http:/= /r6.sharedcopy.com/6bnqq8v> >   · Original page = <http://to= ols.ietf.org/html/draft-ietf-oauth-v2-09 <http://tools.ietf.org/html/draft-ietf-o= auth-v2-09> >  
  
 
 
via sharedcopy.com <http://sharedcopy.com>  <http://sharedcopy.com>  <http://sharedcopy.com/?ef <http://sharedcopy.com/?ef> >  &n= bsp;
<= BLOCKQUOTE>

------ End of Forwarded  Message
http://www.mail-archive.com/oauth@ietf.org/msg02331.htm= l> <http://www.mail-archive.com/oauth@ietf.org/msg02331.html>
Regards,
--_000_C861F038371B0eranhueniversecom_-- From eran@hueniverse.com Tue Jul 13 10:29: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 D77C73A67B1 for ; Tue, 13 Jul 2010 10:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_82=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 pfDQF4gQ5ixi for ; Tue, 13 Jul 2010 10:29:34 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 220D23A69A2 for ; Tue, 13 Jul 2010 10:29:34 -0700 (PDT) Received: (qmail 11965 invoked from network); 13 Jul 2010 17:29:43 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 17:29:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 13 Jul 2010 10:29:39 -0700 From: Eran Hammer-Lahav To: Colin Snover , David Recordon Date: Tue, 13 Jul 2010 10:29:37 -0700 Thread-Topic: [OAUTH-WG] ' force_auth' request parameter Thread-Index: AcsisDqIdd6TIdHDTyeVltcn9oGGVQAALzWi Message-ID: In-Reply-To: <4C3CA132.3060201@zetafleet.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:29:35 -0000 On 7/13/10 10:24 AM, "Colin Snover" wrote: > The problem I see with pushing this up into an identity layer is that > providers that choose to implement their own identity layer (or no identi= ty > layer) may still end up doing this implicit authorization thing. We=B9re = neither > providing a specific identity to connect nor are we requesting identity > information from the provider not re-using any previous authorizations (a session cookie is just an > authorization key by another name), because doing so leads to the scenari= os > I=B9ve written about (and probably others that I have not considered). > =20 > Under an authorization system that did not require the use of a Web brow= ser, > I would agree much more strongly with the notion that this should be part= of a > separate layer, but the problem is that the spec *does* utilize Web brows= ers > heavily, and so we need to make considerations for the spec keeping that = in > mind. > =20 > To address Eran=B9s concern about overstepping bounds, perhaps the langu= age > could be changed from MUST to SHOULD, which would leave it up to the prov= ider > to make the ultimate decision whilst still being in compliance with the s= pec? > I certainly don=B9t want to step on any toes in that regard, but I also d= on=B9t > want providers to think they can ignore this just because it=B9s a little= easier > to do so. A SHOULD directive works better with an extension than core. Inclusion in core means it is, well, core... EHL =20 > Regards, > =20 > =20 > On 13/07/2010 11:57, David Recordon wrote: >> I support immediate and a form of forced auth (ala OpenID's PAPE) but no= t in >> the core spec. They both should be part of an identity extension. >>=20 >> =20 >> =20 >> On Tue, Jul 13, 2010 at 9:51 AM, William Mills wr= ote: >> =20 >>> =20 >>> =20 >>> I agree with Colin that some form of force_auth is needed.=A0 I haven't= read >>> enough on the "immediate" proposal, but I know that we have run into th= e >>> problem of trusting currently set cookies in the browser (even when we'= re >>> actually sending a username/password and really do want to have an >>> authentication). >>> =20 >>> =A0 >>> =20 >>> I'm a +1 on the force_auth proposal. >>> =20 >>> =20 >>>> =20 >>>> =20 >>>>=20 >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behal= f Of >>>> Colin Snover >>>> Sent: Tuesday, July 13, 2010 9:23 AM >>>> To: Eran Hammer-Lahav >>>> Cc: OAuth WG >>>> Subject: Re: [OAUTH-WG] ' force_auth' request parameter >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> On 22/07/28164 13:59, Eran Hammer-Lahav wrote: >>>>> The following was submitted via the shared-copy page but does not bel= ong >>>>> with editorial feedback. This needs to be discussed and supported on = the >>>>> list before added the specification. I think it belongs where Oimmedi= ate=B9 >>>>> is specified. >>>>> =20 >>>>> EHL >>>>> =20 >>>>> ------ Forwarded Message >>>>> =20 >>>>>> From: An anonymous reader >>>>> > >>>>>> Date: Sat, 10 Jul 2010 11:01:11 -0700 >>>>>> To: Eran Hammer-Lahav >>>>>> > >>>>>> Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol >>>>>> =20 >>>>>> =20 >>>>> =20 >>>>> =20 >>>>>> =A0"Colin Snover" left these comments on your copy: >>>>>> =A0 >>>>>> draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol >>>>>> >>>>>> =A0=A0=A0=A0=A0=A0=A0=A0 >>>>>> =20 >>>>>> =A0=A0=A0=A0=A0As proposed on the ML, a new parameter to counteract= the current >>>>>> behaviour of OAuth 1.0a authorization servers which is to assume tha= t the >>>>>> account logged into the user-agent is the account that should be che= cked >>>>>> for access: >>>>>> =20 >>>>>> force_auth >>>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0OPTIONAL. The parameter value must be se= t to "true" or "false". >>>>>> =20 >>>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0If set to "true", the authorization serv= er MUST prompt the >>>>>> end-user to authenticate and approve access. The authorization serve= r >>>>>> MUST NOT make any assumptions as to the identity of the entity reque= sting >>>>>> access, even if another automatic mechanism is available to do so (e= .g. >>>>>> browser cookies). >>>>>> =20 >>>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0If set to "false" or not present, the au= thorization server MAY >>>>>> automatically grant access to the client if it is able to determine = that >>>>>> access was previously granted. =A0=A0=A0=A0=A0=A0=A0=A0link =BB >>>>>> >>>>>> =A0 >>>>>> =20 >>>>>> tools.ietf.org/html/draft-ietf-oauth-v2-09 >>>>>> >>>>>> =A0=B7 Original page >>>>>> >>>>>> =A0=A0 >>>>>> =A0 >>>>>> =20 >>>>>>=20 >>>>>> via sharedcopy.com >>>>>> =A0 >>>>>> =20 >>>>> =20 >>>>> ------ End of Forwarded Message >>>>> =20 >>>> =20 >>>> Hi Eran, >>>> =20 >>>> Sorry if that was not the right place for that to go; I didn=B9t know= what >>>> else to do. I have tried to solicit feedback from the ML regarding thi= s >>>> parameter twice and nobody seems very keen in providing any, which is = kind >>>> of a bummer. I waited until the last possible moment to add it in the = hopes >>>> that someone would notice my messages and discuss it, but you made it = sound >>>> like your plan was for draft 10 to be potentially final so I wanted to= get >>>> it in before the deadline. >>>> =20 >>>> I=B9m sure this is not a big deal for most applications that expect a= t most >>>> a single connection, but for me this is a huge deal since it completel= y >>>> immolates our application=B9s authentication flow, and I can=B9t go to= every >>>> provider asking them to please change the way they implement the >>>> authentication portion of their OAuth API. >>>> =20 >>>> In contrast to Oimmediate=B9, which had some concerns vis =E0 vis sec= urity, >>>> force_auth is actually safer than the current normal flow used by most >>>> OAuth providers since it requires the provider to make no guesses abou= t who >>>> is trying to authorize the app. >>>> =20 >>>> Frankly, I think that OAuth providers do the wrong thing now in all c= ases >>>> by assuming that browser cookies are a safe way of confirming the iden= tity >>>> of the end-user making an authorization request (they aren=B9t!), but = the >>>> spec says the way the authorization server authenticates the end-user = is >>>> outside the scope of the spec. I have no objection to this>>> be authentication-agnostic>>> present implementation flaw and the only way to solve it is to make su= re >>>> the spec defines a way for an application to say =B3hey, I know you *t= hink* >>>> you know who should be authenticated, but *I* know that the user has >>>> requested to connect a *new* account, so don=B9t use any automatic >>>> authentication method=B2. >>>> =20 >>>> I think it is incredibly important that the OAuth spec gets providers= to >>>> distinguish between automatic & potentially unsafe authentication meth= ods >>>> (like session cookies) versus more =B3guaranteed=B2 authentication (li= ke >>>> password), especially since 99.999% of the time OAuth relies on the >>>> end-user=B9s Web browser which is all but guaranteed to contain some c= ookies >>>> for the provider that are unrelated to the requesting application. >>>> =20 >>>> Examples: >>>> =20 >>>> 1. Multiple end-users with malicious intent. User 1 is logged into th= eir >>>> Facetweetr account. User 2 wants to do bad things using User 1=B9s acc= ount. >>>> Because the user-agent has cookies for user 1, user 2 gets to authoriz= e >>>> their account with our app. Even when user 1 changes their password, u= nless >>>> the provider automatically invalidates their existing connections (the= spec >>>> does not even mention doing this in an informative manner as far as I = can >>>> tell), they are almost certainly unaware that the linked application i= s >>>> still able to perform actions on their behalf. >>>> =20 >>>> 2. Single end-user with multiple accounts.=A0User is logged into Face= tweetr >>>> account 1, but they want to authorize account 2. They go to authorize = the >>>> application and are presented with a confirmation for account 1. They = log >>>> out (because this is the only way to switch accounts on the provider) = and >>>> suddenly the authorization flow is dropped on the floor. The user may = not >>>> know immediately what they need to do at this point. They will need to >>>> manually return to the original application and restart the authorizat= ion >>>> request. >>>> =20 >>>> 3. User has two accounts that they want to authorize with a provider.= User >>>> authorizes account 1 successfully, then wants to authorize account 2. >>>> Because account 1 is still logged in, and because the application alre= ady >>>> has a link to the account, it automatically redirects back to the >>>> application=B9s redirection URI. In order for the user to get what the= y want, >>>> they are forced to manually navigate to the provider=B9s site, log out= , >>>> *then* begin the authorization request. >>>> =20 >>>> These aren=B9t imaginary scenarios; they are things that are going on= *right >>>> now* with several different OAuth providers. >>>> =20 >>>> The original request: >>>> >>>> =20 >>>> Regards, >>>> =20 From wmills@yahoo-inc.com Tue Jul 13 10:35: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 01B693A6902 for ; Tue, 13 Jul 2010 10:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.775 X-Spam-Level: X-Spam-Status: No, score=-16.775 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6, J_CHICKENPOX_82=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjGEy8Fk9ZIy for ; Tue, 13 Jul 2010 10:35:24 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 8FDE63A69A1 for ; Tue, 13 Jul 2010 10:35:24 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6DHYfFu092946; Tue, 13 Jul 2010 10:34:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:x-originalarrivaltime; b=a0gBWYDOXiH32lO3ZRtclvZK4jLmBno/sWBpXEYuVgn/PO9AsR+mEcIIDkJ1LcM6 Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 10:34:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Jul 2010 10:34:34 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6C21@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] ' force_auth' request parameter Thread-Index: AcsisDqIdd6TIdHDTyeVltcn9oGGVQAALzWiAAAqdzA= References: <4C3CA132.3060201@zetafleet.com> From: "William Mills" To: "Eran Hammer-Lahav" , "Colin Snover" , "David Recordon" X-OriginalArrivalTime: 13 Jul 2010 17:34:41.0523 (UTC) FILETIME=[ACE1DC30:01CB22B1] Cc: OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:35:26 -0000 I can live with SHOULD.=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Eran Hammer-Lahav > Sent: Tuesday, July 13, 2010 10:30 AM > To: Colin Snover; David Recordon > Cc: OAuth WG > Subject: Re: [OAUTH-WG] ' force_auth' request parameter >=20 >=20 >=20 >=20 > On 7/13/10 10:24 AM, "Colin Snover" wrote: >=20 > > The problem I see with pushing this up into an identity=20 > layer is=20 > > that providers that choose to implement their own identity=20 > layer (or=20 > > no identity > > layer) may still end up doing this implicit authorization=20 > thing. We=B9re=20 > > neither providing a specific identity to connect nor are we=20 > requesting=20 > > identity information from the provider > that the provider is not re-using any previous authorizations (a=20 > > session cookie is just an authorization key by another=20 > name), because=20 > > doing so leads to the scenarios I=B9ve written about (and=20 > probably others that I have not considered). > > =20 > > Under an authorization system that did not require the use=20 > of a Web=20 > > browser, I would agree much more strongly with the notion that this=20 > > should be part of a separate layer, but the problem is that=20 > the spec=20 > > *does* utilize Web browsers heavily, and so we need to make=20 > > considerations for the spec keeping that in mind. > > =20 > > To address Eran=B9s concern about overstepping bounds, perhaps the=20 > > language could be changed from MUST to SHOULD, which would=20 > leave it up=20 > > to the provider to make the ultimate decision whilst still=20 > being in compliance with the spec? > > I certainly don=B9t want to step on any toes in that regard,=20 > but I also=20 > > don=B9t want providers to think they can ignore this just=20 > because it=B9s a=20 > > little easier to do so. >=20 > A SHOULD directive works better with an extension than core.=20 > Inclusion in core means it is, well, core... >=20 > EHL > =20 > > Regards, > > =20 > > =20 > > On 13/07/2010 11:57, David Recordon wrote: > >> I support immediate and a form of forced auth (ala=20 > OpenID's PAPE) but=20 > >> not in the core spec. They both should be part of an=20 > identity extension. > >>=20 > >> =20 > >> =20 > >> On Tue, Jul 13, 2010 at 9:51 AM, William Mills=20 > wrote: > >> =20 > >>> =20 > >>> =20 > >>> I agree with Colin that some form of force_auth is needed.=A0 I=20 > >>> haven't read enough on the "immediate" proposal, but I=20 > know that we=20 > >>> have run into the problem of trusting currently set=20 > cookies in the=20 > >>> browser (even when we're actually sending a username/password and=20 > >>> really do want to have an authentication). > >>> =20 > >>> =A0 > >>> =20 > >>> I'm a +1 on the force_auth proposal. > >>> =20 > >>> =20 > >>>> =20 > >>>> =20 > >>>>=20 > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > >>>> Behalf Of Colin Snover > >>>> Sent: Tuesday, July 13, 2010 9:23 AM > >>>> To: Eran Hammer-Lahav > >>>> Cc: OAuth WG > >>>> Subject: Re: [OAUTH-WG] ' force_auth' request parameter > >>>> =20 > >>>> =20 > >>>> =20 > >>>> =20 > >>>> On 22/07/28164 13:59, Eran Hammer-Lahav wrote: > >>>>> The following was submitted via the shared-copy page=20 > but does not=20 > >>>>> belong with editorial feedback. This needs to be discussed and=20 > >>>>> supported on the list before added the specification. I=20 > think it=20 > >>>>> belongs where Oimmediate=B9 is specified. > >>>>> =20 > >>>>> EHL > >>>>> =20 > >>>>> ------ Forwarded Message > >>>>> =20 > >>>>>> From: An anonymous reader >>>>>> > > >>>>>> Date: Sat, 10 Jul 2010 11:01:11 -0700 > >>>>>> To: Eran Hammer-Lahav >>>>>> > >>>>>> > > >>>>>> Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol > >>>>>> =20 > >>>>>> =20 > >>>>> =20 > >>>>> =20 > >>>>>> =A0"Colin Snover" left these comments on your copy: > >>>>>> =A0 > >>>>>> draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol=20 > >>>>>> > >>>>>> =A0=A0=A0=A0=A0=A0=A0=A0 > >>>>>> =20 > >>>>>> =A0=A0=A0=A0=A0As proposed on the ML, a new parameter to = counteract the=20 > >>>>>> current behaviour of OAuth 1.0a authorization servers=20 > which is to=20 > >>>>>> assume that the account logged into the user-agent is=20 > the account=20 > >>>>>> that should be checked for access: > >>>>>> =20 > >>>>>> force_auth > >>>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0OPTIONAL. The parameter value must = be set to=20 > "true" or "false". > >>>>>> =20 > >>>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0If set to "true", the authorization = server=20 > MUST prompt=20 > >>>>>> the end-user to authenticate and approve access. The=20 > >>>>>> authorization server MUST NOT make any assumptions as to the=20 > >>>>>> identity of the entity requesting access, even if=20 > another automatic mechanism is available to do so (e.g. > >>>>>> browser cookies). > >>>>>> =20 > >>>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0If set to "false" or not present, = the authorization=20 > >>>>>> server MAY automatically grant access to the client if=20 > it is able=20 > >>>>>> to determine that access was previously granted. = =A0=A0=A0=A0=A0=A0 > =A0=A0link =BB=20 > >>>>>> > >>>>>> =A0 > >>>>>> =20 > >>>>>> tools.ietf.org/html/draft-ietf-oauth-v2-09 > >>>>>> > >>>>>> =A0=B7 Original page=20 > >>>>>> > >>>>>> =A0=A0 > >>>>>> =A0 > >>>>>> =20 > >>>>>>=20 > >>>>>> via sharedcopy.com =20 > >>>>>> > >>>>>> =A0 > >>>>>> =20 > >>>>> =20 > >>>>> ------ End of Forwarded Message > >>>>> =20 > >>>> =20 > >>>> Hi Eran, > >>>> =20 > >>>> Sorry if that was not the right place for that to go; I didn=B9t = > >>>> know what else to do. I have tried to solicit feedback=20 > from the ML=20 > >>>> regarding this parameter twice and nobody seems very keen in=20 > >>>> providing any, which is kind of a bummer. I waited until=20 > the last=20 > >>>> possible moment to add it in the hopes that someone=20 > would notice my=20 > >>>> messages and discuss it, but you made it sound like your=20 > plan was=20 > >>>> for draft 10 to be potentially final so I wanted to get=20 > it in before the deadline. > >>>> =20 > >>>> I=B9m sure this is not a big deal for most applications=20 > that expect=20 > >>>> at most a single connection, but for me this is a huge=20 > deal since=20 > >>>> it completely immolates our application=B9s authentication=20 > flow, and=20 > >>>> I can=B9t go to every provider asking them to please=20 > change the way=20 > >>>> they implement the authentication portion of their OAuth API. > >>>> =20 > >>>> In contrast to Oimmediate=B9, which had some concerns vis =E0 = vis=20 > >>>> security, force_auth is actually safer than the current=20 > normal flow=20 > >>>> used by most OAuth providers since it requires the=20 > provider to make=20 > >>>> no guesses about who is trying to authorize the app. > >>>> =20 > >>>> Frankly, I think that OAuth providers do the wrong thing now in=20 > >>>> all cases by assuming that browser cookies are a safe way of=20 > >>>> confirming the identity of the end-user making an authorization=20 > >>>> request (they aren=B9t!), but the spec says the way the=20 > authorization=20 > >>>> server authenticates the end-user is outside the scope=20 > of the spec.=20 > >>>> I have no objection to this >>>> authentication-agnostic >>>> and present implementation flaw and the only way to=20 > solve it is to=20 > >>>> make sure the spec defines a way for an application to=20 > say =B3hey, I=20 > >>>> know you *think* you know who should be authenticated,=20 > but *I* know=20 > >>>> that the user has requested to connect a *new* account,=20 > so don=B9t use any automatic authentication method=B2. > >>>> =20 > >>>> I think it is incredibly important that the OAuth spec gets=20 > >>>> providers to distinguish between automatic & potentially unsafe=20 > >>>> authentication methods (like session cookies) versus more=20 > >>>> =B3guaranteed=B2 authentication (like password), especially since = > >>>> 99.999% of the time OAuth relies on the end-user=B9s Web browser=20 > >>>> which is all but guaranteed to contain some cookies for=20 > the provider that are unrelated to the requesting application. > >>>> =20 > >>>> Examples: > >>>> =20 > >>>> 1. Multiple end-users with malicious intent. User 1 is=20 > logged into=20 > >>>> their Facetweetr account. User 2 wants to do bad things=20 > using User 1=B9s account. > >>>> Because the user-agent has cookies for user 1, user 2 gets to=20 > >>>> authorize their account with our app. Even when user 1 changes=20 > >>>> their password, unless the provider automatically=20 > invalidates their=20 > >>>> existing connections (the spec does not even mention=20 > doing this in=20 > >>>> an informative manner as far as I can tell), they are almost=20 > >>>> certainly unaware that the linked application is still=20 > able to perform actions on their behalf. > >>>> =20 > >>>> 2. Single end-user with multiple accounts.=A0User is logged into = > >>>> Facetweetr account 1, but they want to authorize account=20 > 2. They go=20 > >>>> to authorize the application and are presented with a=20 > confirmation=20 > >>>> for account 1. They log out (because this is the only=20 > way to switch=20 > >>>> accounts on the provider) and suddenly the authorization flow is=20 > >>>> dropped on the floor. The user may not know immediately=20 > what they=20 > >>>> need to do at this point. They will need to manually=20 > return to the=20 > >>>> original application and restart the authorization request. > >>>> =20 > >>>> 3. User has two accounts that they want to authorize with a=20 > >>>> provider. User authorizes account 1 successfully, then=20 > wants to authorize account 2. > >>>> Because account 1 is still logged in, and because the=20 > application=20 > >>>> already has a link to the account, it automatically=20 > redirects back=20 > >>>> to the application=B9s redirection URI. In order for the=20 > user to get=20 > >>>> what they want, they are forced to manually navigate to the=20 > >>>> provider=B9s site, log out, > >>>> *then* begin the authorization request. > >>>> =20 > >>>> These aren=B9t imaginary scenarios; they are things that=20 > are going=20 > >>>> on *right > >>>> now* with several different OAuth providers. > >>>> =20 > >>>> The original request: > >>>> > >>>> =20 > >>>> Regards, > >>>> =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Tue Jul 13 10:40:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803543A6B4E for ; Tue, 13 Jul 2010 10:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 aHRufbrAqBw4 for ; Tue, 13 Jul 2010 10:40:42 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id AA7E03A6B45 for ; Tue, 13 Jul 2010 10:40:40 -0700 (PDT) Received: (qmail 30256 invoked from network); 13 Jul 2010 17:40:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 17:40:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 13 Jul 2010 10:40:47 -0700 From: Eran Hammer-Lahav To: John Kemp Date: Tue, 13 Jul 2010 10:40:46 -0700 Thread-Topic: [OAUTH-WG] "shared symmetric secret" Thread-Index: AcsisFeeMlAR4wQoQcWPqGFUYa2sOwAAi6BA Message-ID: In-Reply-To: <97BD2762-F147-4774-9557-AD478338B348@jkemp.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:40:45 -0000 On 7/13/10 10:25 AM, "John Kemp" wrote: > On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote: >=20 >> I am ok replacing it with Oacts as a password=B9. >=20 > An access token is something used by the server to decide whether a reque= st is > authorized. Although it may also be used for authenticating the request(e= r), > it's purpose is to authorize the request. It is used to authenticate the *request*, it is used in the same manner other HTTP authentication schemes operate, and it has the same behavior as = a password (security wise: plain-text storage on the client side, can be phished, usable by any bearer). > In the "bearer token" case (and even over SSL unless client certs are use= d), > the token clearly SHOULD NOT be used as a password. Rather, authenticatio= n > should be performed by some other mechanism, unrelated to the token itsel= f > (such as an HMAC, or via client-certificate SSL/TLS, or even via an actua= l > username/password) OAuth only includes the "bearer token case". There are no other cases specified. > I would be very unhappy if we equated access tokens with passwords. >=20 > I agree with Dirk that "capability" is a more expressive phrase than eith= er > "shared secret" or "password". Expressive to you and people well-versed in security theory. It means nothing to a casual reader. The token definition includes the term, but in this section, it is referring to how an access token is used, and it is use= d just like a password. For better or worse, we turned the 1.0 access token into a 2.0 password. EHL > Regards, >=20 > - johnk >=20 >>=20 >> EHL >>=20 >>=20 >> On 7/13/10 8:55 AM, "Dirk Balfanz" wrote: >>=20 >>=20 >>=20 >> On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav >> wrote: >> From the client's perspective, they are 'shared symmetric secrets' becau= se >> the client has to store them as-is and present them as-is. The act exact= ly >> like passwords. I added that text to make that stand out. >>=20 >> When using passwords, the server doesn't need to store them in plain-tex= t >> either (e.g. uses a way one hash). >>=20 >> That's why we don't call passwords "shared symmetric secrets", either. T= he >> verifier of a passwords can verify it without knowing the secret. In tha= t >> sense, it's not "shared" with the verifier. >>=20 >> I would like the specification to make it clear that bearer tokens are o= nly >> secure while they remain *secret* and that *anyone* holding them can gai= n >> full access to what their protect. >>=20 >> I think the word "capability" expresses that better than the word "share= d >> secret". >>=20 >> Dirk. >>=20 >>=20 >> EHL >>=20 >> On 7/12/10 10:39 PM, "Brian Eaton" wrote: >>=20 >>> Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5 >>>=20 >>> Calling access tokens "shared symmetric secrets" is misleading, >>> because if they are implemented well the authorization server and >>> protected resource do not store a copy of the secret. >>>=20 >>> Instead they store a one-way hash of the token. Or they verify the >>> token cryptographically. Under no circumstances do they need to store >>> a copy. >>>=20 >>> I'd suggest the following language: >>>=20 >>> "Access tokens are bearer authentication tokens or capabilities." >>>=20 >>> Cheers, >>> Brian >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 From beaton@google.com Tue Jul 13 11:17: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 A9FC73A6B4E for ; Tue, 13 Jul 2010 11:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.762 X-Spam-Level: X-Spam-Status: No, score=-101.762 tagged_above=-999 required=5 tests=[AWL=0.215, 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 5NQDD1BbxNt9 for ; Tue, 13 Jul 2010 11:17:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id CA69D3A6B4C for ; Tue, 13 Jul 2010 11:17:04 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o6DIHBRS016248 for ; Tue, 13 Jul 2010 11:17:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279045032; bh=M6IZdmN771JlcH3JDjd2W1XzdwM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Fu9CjZ8RG/MK7llGN4VULs8z+aTs2IcFNgyI8enpwEcV21pSNQdvpWdoWRkbA0vxK ER9DGOVE43i6+cAN8R3OQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=LOiIZhVp24oB4rOA0hlfb5yNTye8x1DAskPjxYPkP++9K++fT8Nnjmvx+VhsHJKvp /7KWpvisMiKiO13+jRTgQ== Received: from pxi3 (pxi3.prod.google.com [10.243.27.3]) by wpaz9.hot.corp.google.com with ESMTP id o6DIHAuF019298 for ; Tue, 13 Jul 2010 11:17:10 -0700 Received: by pxi3 with SMTP id 3so2843601pxi.25 for ; Tue, 13 Jul 2010 11:17:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.144.16 with SMTP id r16mr19203651wfd.60.1279045029705; Tue, 13 Jul 2010 11:17:09 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Tue, 13 Jul 2010 11:17:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 11:17:09 -0700 Message-ID: From: Brian Eaton To: David Recordon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 18:17:48 -0000 On Tue, Jul 13, 2010 at 9:42 AM, David Recordon wrote= : >> That strikes me as very odd - returning some params in the query, and >> others in the fragment is just weird. > > I actually think that you want this =96 albiet odd =96 combination when > requesting both a code and token. The code and state parameters are neede= d > by the server and thus are query=A0parameters. The access token, scope, a= nd > expires in shouldn't be sent to the server via HTTP and thus are within > the=A0fragment=A0for the JavaScript to access. The problem is that if you do it this way you end up busting the browser cache. All of the performance improvements offered by the user-agent profile are lost. Cheers, Brian From ietf.org@zetafleet.com Tue Jul 13 11:21:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FAF03A6B2E for ; Tue, 13 Jul 2010 11:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.014 X-Spam-Level: X-Spam-Status: No, score=-0.014 tagged_above=-999 required=5 tests=[AWL=-1.617, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+vw+3JnYDPM for ; Tue, 13 Jul 2010 11:21:28 -0700 (PDT) Received: from one.acitia.com (one.acitia.com [66.135.55.251]) by core3.amsl.com (Postfix) with ESMTP id 3A7D53A6AA0 for ; Tue, 13 Jul 2010 11:21:28 -0700 (PDT) Received: from c-75-73-43-136.hsd1.mn.comcast.net ([75.73.43.136] helo=Trillian.hsd1.mn.comcast.net) by one.acitia.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1OYk5v-0004oR-T4; Tue, 13 Jul 2010 18:20:45 +0000 Message-ID: <4C3CAEA3.5040106@zetafleet.com> Date: Tue, 13 Jul 2010 13:21:23 -0500 From: Colin Snover User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000007020808050906050503" Cc: OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 18:21:44 -0000 This is a multi-part message in MIME format. --------------000007020808050906050503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit The only other thing I could think of to suggest would be to change the spec to state that an authorization server MUST NOT rely on Cookie or Authorization headers from the user-agent during the end-user redirect phase as being safe for use in authentication. To me, at least, it seems obvious an authorization server should *never* think user-agent authorization tokens (e.g. session cookies, basic auth) are a safe way of authenticating incoming authorization requests. Doing so puts too much trust in the user-agent and allows the client to bypass the first phase of authentication when it can't really do so securely. This is only a problem because OAuth *requires* use of a Web browser during its authorization flow. Unfortunately, lots and lots of providers are already doing this, and the only way I can think of to make it stop it is to make it verboten in the spec, even if it causes the spec to deviate slightly into the authentication arena in this one particular area. As far as (very legitimate) concerns regarding inconsistent user experience go, let's look at how the current OAuth system works in practice. No matter what, *any* authorization action taken by an end-user in a client can potentially mean either "log in and then authorize", "authorize", or "do nothing while we automatically refresh the client with a new token and redirect you back". That's already a *huge* disparity in what happens *within the same client*, and it's painfully bad. I think Justin Hart got it exactly right when he said there should be four options. Even if what happens is not always the same, clients can manage user expectations *much* better than providers by providing cues about what will happen *before* auth flow starts. With the current way it works, basically all the client can tell the user is "we have no idea what will happen once you click this button except maybe your account will get connected to our site if you do it exactly right; good luck!". Regards, On 13/07/2010 12:28, Eran Hammer-Lahav wrote: > User authentication and approval interaction has always been the sole > domain of the authorization server. This proposal shifts the decision > towards the client. It is unclear to me why is the client better > suited to make this decision? In the context of identity, if a client > relies on the server for its own identity services (e.g. Facebook > connect), it makes sense for the client to request stronger > authentication than just cookies. But outside the identity context, I > am unconvinced the client is likely to make a smart decision. In > addition, if we let the client specify this, it will mean different > client will have different user experience on the same server which is > confusing and odd. > > I'm not opposed to this, just that I don't think this is well thought out. > > EHL > > > On 7/13/10 10:18 AM, "William Mills" wrote: > > I agree it changes the boundaries. I think this one needs moving. > As I said we hit a significant problem with this, which we solved > by virtue of the fact that the target we were working with has an > un-crumbed logout, so we could XSRF the logout. > > It's something people get wrong and we should make a way to get it > right. > > > > ------------------------------------------------------------------------ > *From:* Eran Hammer-Lahav [mailto:eran@hueniverse.com] > *Sent:* Tuesday, July 13, 2010 10:08 AM > *To:* William Mills > *Cc:* David Recordon; Colin Snover; OAuth WG > *Subject:* Re: [OAUTH-WG] ' force_auth' request parameter > > > > The question is if we have consensus to force providers to > support it. > > > It seems to overstep the boundaries we set over the years and > it makes assumptions about how services authenticate users > and obtain approvals. > > > > EHL > > > > > On Jul 13, 2010, at 13:05, William Mills > wrote: > > > > > > I think it's a mistake not to have force_auth in the core. > > > > > ------------------------------------------------------------------------ > *From:* David Recordon [mailto:recordond@gmail.com] > *Sent:* Tuesday, July 13, 2010 9:58 AM > *To:* William Mills > *Cc:* Colin Snover; Eran Hammer-Lahav; OAuth WG > *Subject:* Re: [OAUTH-WG] ' force_auth' request parameter > > > I support immediate and a form of forced auth (ala > OpenID's PAPE) but not in the core spec. They both > should be part of an identity extension. > > > > On Tue, Jul 13, 2010 at 9:51 AM, William Mills > > > wrote: > > > > I agree with Colin that some form of force_auth > is needed. I haven't read enough on the > "immediate" proposal, but I know that we have run > into the problem of trusting currently set > cookies in the browser (even when we're actually > sending a username/password and really do want to > have an authentication). > > > > I'm a +1 on the force_auth proposal. > > > > > ------------------------------------------------------------------------ > *From:* oauth-bounces@ietf.org > > [mailto:oauth-bounces@ietf.org > ] *On Behalf > Of *Colin Snover > *Sent:* Tuesday, July 13, 2010 9:23 AM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] ' force_auth' > request parameter > > > > > > On 22/07/28164 13:59, Eran Hammer-Lahav wrote: > > The following was submitted via the > shared-copy page but does not belong with > editorial feedback. This needs to be > discussed and supported on the list before > added the specification. I think it > belongs where 'immediate' is specified. > > EHL > > ------ Forwarded Message > > *From: *An anonymous reader > > *Date: *Sat, 10 Jul 2010 11:01:11 -0700 > *To: *Eran Hammer-Lahav > > *Subject: *Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol > > > > *"Colin Snover"* left these comments on your copy: > > *draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol > > > * > > As proposed on the ML, a new parameter to counteract the current > behaviour of OAuth 1.0a authorization servers which is to assume > that the account logged into the user-agent is the account that > should be checked for access: > > force_auth > OPTIONAL. The parameter value must be set to "true" or "false". > > If set to "true", the authorization server MUST prompt the > end-user to authenticate and approve access. The authorization server > MUST NOT make any assumptions as to the identity of the entity > requesting access, even if another automatic mechanism is available > to do so (e.g. browser cookies). > > If set to "false" or not present, the authorization server > MAY automatically grant access to the client if it is able to > determine that access was previously granted. link > > > > > tools.ietf.org/html/draft-ietf-oauth-v2-09 > > > > > Original page > > > > > ------------------------------------------------------------------------ > via sharedcopy.com > > > > > ------ End of Forwarded Message > > > Hi Eran, > > Sorry if that was not the right place for > that to go; I didn't know what else to do. I > have tried to solicit feedback from the ML > regarding this parameter twice and nobody > seems very keen in providing any, which is > kind of a bummer. I waited until the last > possible moment to add it in the hopes that > someone would notice my messages and discuss > it, but you made it sound like your plan was > for draft 10 to be potentially final so I > wanted to get it in before the deadline. > > I'm sure this is not a big deal for most > applications that expect at most a single > connection, but for me this is a huge deal > since it completely immolates our > application's authentication flow, and I can't > go to every provider asking them to please > change the way they implement the > authentication portion of their OAuth API. > > In contrast to 'immediate', which had some > concerns vis vis security, force_auth is > actually safer than the current normal flow > used by most OAuth providers since it > requires the provider to make no guesses about > who is trying to authorize the app. > > Frankly, I think that OAuth providers do the > wrong thing now in all cases by assuming that > browser cookies are a safe way of confirming > the identity of the end-user making an > authorization request (they aren't!), but the > spec says the way the authorization server > authenticates the end-user is outside the > scope of the spec. I have no objection to > this---OAuth *should* be > authentication-agnostic---but at the same > time this is a very real and present > implementation flaw and the only way to solve > it is to make sure the spec defines a way for > an application to say "hey, I know you > *think* you know who should be authenticated, > but *I* know that the user has requested to > connect a *new* account, so don't use any > automatic authentication method". > > I think it is incredibly important that the > OAuth spec gets providers to distinguish > between automatic & potentially unsafe > authentication methods (like session cookies) > versus more "guaranteed" authentication (like > password), especially since 99.999% of the > time OAuth relies on the end-user's Web > browser which is all but guaranteed to contain > some cookies for the provider that are > unrelated to the requesting application. > > Examples: > > 1. Multiple end-users with malicious intent. > User 1 is logged into their Facetweetr > account. User 2 wants to do bad things using > User 1's account. Because the user-agent has > cookies for user 1, user 2 gets to authorize > their account with our app. Even when user 1 > changes their password, unless the provider > automatically invalidates their existing > connections (the spec does not even mention > doing this in an informative manner as far as > I can tell), they are almost certainly unaware > that the linked application is still able to > perform actions on their behalf. > > 2. Single end-user with multiple accounts. > User is logged into Facetweetr account 1, but > they want to authorize account 2. They go to > authorize the application and are presented > with a confirmation for account 1. They log > out (because this is the only way to switch > accounts on the provider) and suddenly the > authorization flow is dropped on the floor. > The user may not know immediately what they > need to do at this point. They will need to > manually return to the original application > and restart the authorization request. > > 3. User has two accounts that they want to > authorize with a provider. User authorizes > account 1 successfully, then wants to > authorize account 2. Because account 1 is > still logged in, and because the application > already has a link to the account, it > automatically redirects back to the > application's redirection URI. In order for > the user to get what they want, they are > forced to manually navigate to the provider's > site, log out, *then* begin the authorization > request. > > These aren't imaginary scenarios; they are > things that are going on *right now* with > several different OAuth providers. > > The original request: > > > > > Regards, > -- Colin Snover --------------000007020808050906050503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The only other thing I could think of to suggest would be to change the spec to state that an authorization server MUST NOT rely on Cookie or Authorization headers from the user-agent during the end-user redirect phase as being safe for use in authentication.

To me, at least, it seems obvious an authorization server should *never* think user-agent authorization tokens (e.g. session cookies, basic auth) are a safe way of authenticating incoming authorization requests. Doing so puts too much trust in the user-agent and allows the client to bypass the first phase of authentication when it can’t really do so securely. This is only a problem because OAuth *requires* use of a Web browser during its authorization flow. Unfortunately, lots and lots of providers are already doing this, and the only way I can think of to make it stop it is to make it verboten in the spec, even if it causes the spec to deviate slightly into the authentication arena in this one particular area.

As far as (very legitimate) concerns regarding inconsistent user experience go, let’s look at how the current OAuth system works in practice. No matter what, *any* authorization action taken by an end-user in a client can potentially mean either “log in and then authorize”, “authorize”, or “do nothing while we automatically refresh the client with a new token and redirect you back”. That’s already a *huge* disparity in what happens *within the same client*, and it’s painfully bad.

I think Justin Hart got it exactly right when he said there should be four options. Even if what happens is not always the same, clients can manage user expectations *much* better than providers by providing cues about what will happen *before* auth flow starts. With the current way it works, basically all the client can tell the user is “we have no idea what will happen once you click this button except maybe your account will get connected to our site if you do it exactly right; good luck!”.

Regards,


On 13/07/2010 12:28, Eran Hammer-Lahav wrote:
Re: [OAUTH-WG] ' force_auth' request parameter User authentication and approval interaction has always been the sole domain of the authorization server. This proposal shifts the decision towards the client. It is unclear to me why is the client better suited to make this decision? In the context of identity, if a client relies on the server for its own identity services (e.g. Facebook connect), it makes sense for the client to request stronger authentication than just cookies. But outside the identity context, I am unconvinced the client is likely to make a smart decision. In addition, if we let the client specify this, it will mean different client will have different user experience on the same server which is confusing and odd.

I’m not opposed to this, just that I don’t think this is well thought out.

EHL


On 7/13/10 10:18 AM, "William Mills" <wmills@yahoo-inc.com> wrote:
I agree it changes the boundaries.  I think this one needs moving.  As I said we hit a significant problem with this, which we solved by virtue of the fact that the target we were working with has an un-crumbed logout, so we could XSRF the logout.
It's something people get wrong and we should make a way to get it right.

 
From: Eran Hammer-Lahav  [mailto:eran@hueniverse.com]
Sent: Tuesday, July 13, 2010 10:08  AM
To: William Mills
Cc: David Recordon; Colin Snover;  OAuth WG
Subject: Re: [OAUTH-WG] ' force_auth' request  parameter

 
 
The question is if we have consensus to force providers to support  it.

 
It seems to overstep the boundaries we set over the years and it makes  assumptions about how services authenticate users and obtain  approvals.
 

 
EHL
 

 

On Jul 13, 2010, at 13:05, William Mills <wmills@yahoo-inc.com>  wrote:

 
 

 
I think it's a mistake not to have force_auth in the  core.

 

 
From: David Recordon  [mailto:recordond@gmail.com]
Sent: Tuesday, July 13, 2010 9:58  AM
To: William Mills
Cc: Colin Snover; Eran  Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] ' force_auth'  request parameter

 
I support immediate and a form of forced auth (ala OpenID's  PAPE) but not in the core spec. They both should be part of an identity  extension.  


 
On Tue, Jul 13, 2010 at 9:51 AM, William Mills  <wmills@yahoo-inc.com <mailto:wmills@yahoo-inc.com> >  wrote:
 

 
I  agree with Colin that some form of force_auth is needed.  I haven't  read enough on the "immediate" proposal, but I know that we have run  into the problem of trusting currently set cookies in the browser (even  when we're actually sending a username/password and really do want to  have an authentication).
 
 
I'm  a +1 on the force_auth proposal.

 

 
From: oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>   [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org> ]  On Behalf Of Colin Snover
Sent: Tuesday, July 13,  2010 9:23 AM
To: Eran Hammer-Lahav
Cc: OAuth  WG
Subject: Re: [OAUTH-WG] ' force_auth' request  parameter

 
 
 
 
On 22/07/28164 13:59, Eran Hammer-Lahav wrote:  
The following was submitted via the  shared-copy page but does not belong with editorial feedback. This  needs to be discussed and supported on the list before added the  specification. I think it belongs where ‘immediate’ is  specified.

EHL

------ Forwarded  Message
 
From: An anonymous reader <mailman@sharedcopy.com <mailto:mailman@sharedcopy.com> >
Date:  Sat, 10 Jul 2010 11:01:11 -0700
To: Eran  Hammer-Lahav <eran@hueniverse.com <mailto:eran@hueniverse.com> >
Subject:  Re: draft-ietf-oauth-v2-09 - The OAuth 2.0  Protocol

 
"Colin Snover" left these  comments on your copy:
 
draft-ietf-oauth-v2-09 - The OAuth 2.0  Protocol <http://r6.sharedcopy.com/6bnqq8v <http://r6.sharedcopy.com/6bnqq8v> >  
        

     As  proposed on the ML, a new parameter to counteract the current  behaviour of OAuth 1.0a authorization servers which is to assume  that the account logged into the user-agent is the account that  should be checked for  access:

force_auth
         OPTIONAL.  The parameter value must be set to "true" or  "false".

         If  set to "true", the authorization server MUST prompt the end-user  to authenticate and approve access. The authorization server MUST  NOT make any assumptions as to the identity of the entity  requesting access, even if another automatic mechanism is  available to do so (e.g. browser  cookies).

         If  set to "false" or not present, the authorization server MAY  automatically grant access to the client if it is able to  determine that access was previously granted.          link » <http://r6.sharedcopy.com/6bnqq8v#shcp21 <http://r6.sharedcopy.com/6bnqq8v#shcp21> >  
 

tools.ietf.org/html/draft-ietf-oauth-v2-09 <http://tools.ietf.org/html/draft-ietf-oauth-v2-09>  <http://tools.ietf.org/html/draft-ietf-oauth-v2-09>   <http://r6.sharedcopy.com/6bnqq8v <http://r6.sharedcopy.com/6bnqq8v> >   · Original page <http://tools.ietf.org/html/draft-ietf-oauth-v2-09 <http://tools.ietf.org/html/draft-ietf-oauth-v2-09> >  
  
 
 
via sharedcopy.com <http://sharedcopy.com>  <http://sharedcopy.com>  <http://sharedcopy.com/?ef <http://sharedcopy.com/?ef> >   

------ End of Forwarded  Message

Hi Eran,

Sorry if  that was not the right place for that to go; I didn’t know what else  to do. I have tried to solicit feedback from the ML regarding this  parameter twice and nobody seems very keen in providing any, which is  kind of a bummer. I waited until the last possible moment to add it in  the hopes that someone would notice my messages and discuss it, but  you made it sound like your plan was for draft 10 to be potentially  final so I wanted to get it in before the deadline.

I’m sure  this is not a big deal for most applications that expect at most a  single connection, but for me this is a huge deal since it completely  immolates our application’s authentication flow, and I can’t go to  every provider asking them to please change the way they implement the  authentication portion of their OAuth API.

In contrast to  ‘immediate’, which had some concerns vis à vis security, force_auth is  actually safer than the current normal flow used by most OAuth  providers since it requires the provider to make no guesses about who  is trying to authorize the app.

Frankly, I think that OAuth  providers do the wrong thing now in all cases by assuming that browser  cookies are a safe way of confirming the identity of the end-user  making an authorization request (they aren’t!), but the spec says the  way the authorization server authenticates the end-user is outside the  scope of the spec. I have no objection to this—OAuth *should* be  authentication-agnostic—but at the same time this is a very real and  present implementation flaw and the only way to solve it is to make  sure the spec defines a way for an application to say “hey, I know you  *think* you know who should be authenticated, but *I* know that the  user has requested to connect a *new* account, so don’t use any  automatic authentication method”.

I think it is incredibly  important that the OAuth spec gets providers to distinguish between  automatic & potentially unsafe authentication methods (like  session cookies) versus more “guaranteed” authentication (like  password), especially since 99.999% of the time OAuth relies on the  end-user’s Web browser which is all but guaranteed to contain some  cookies for the provider that are unrelated to the requesting  application.

Examples:

1. Multiple end-users with  malicious intent. User 1 is logged into their Facetweetr account. User  2 wants to do bad things using User 1’s account. Because the  user-agent has cookies for user 1, user 2 gets to authorize their  account with our app. Even when user 1 changes their password, unless  the provider automatically invalidates their existing connections (the  spec does not even mention doing this in an informative manner as far  as I can tell), they are almost certainly unaware that the linked  application is still able to perform actions on their  behalf.

2. Single end-user with multiple accounts. User is  logged into Facetweetr account 1, but they want to authorize account  2. They go to authorize the application and are presented with a  confirmation for account 1. They log out (because this is the only way  to switch accounts on the provider) and suddenly the authorization  flow is dropped on the floor. The user may not know immediately what  they need to do at this point. They will need to manually return to  the original application and restart the authorization  request.

3. User has two accounts that they want to authorize  with a provider. User authorizes account 1 successfully, then wants to  authorize account 2. Because account 1 is still logged in, and because  the application already has a link to the account, it automatically  redirects back to the application’s redirection URI. In order for the  user to get what they want, they are forced to manually navigate to  the provider’s site, log out, *then* begin the authorization  request.

These aren’t imaginary scenarios; they are things that  are going on *right now* with several different OAuth  providers.

The original request: <http://www.mail-archive.com/oauth@ietf.org/msg02331.html> <http://www.mail-archive.com/oauth@ietf.org/msg02331.html>

Regards,


-- 
Colin Snover
--------------000007020808050906050503-- From eran@hueniverse.com Tue Jul 13 11:39: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 821CD3A6974 for ; Tue, 13 Jul 2010 11:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.139, 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 IQZsY3om8TAe for ; Tue, 13 Jul 2010 11:39:18 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A7B223A67CF for ; Tue, 13 Jul 2010 11:39:18 -0700 (PDT) Received: (qmail 15546 invoked from network); 13 Jul 2010 18:39:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 18:39:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 13 Jul 2010 11:39:27 -0700 From: Eran Hammer-Lahav To: Brian Eaton , David Recordon Date: Tue, 13 Jul 2010 11:39:25 -0700 Thread-Topic: [OAUTH-WG] user-agent flow needs a rewrite Thread-Index: Acsit77n+C9kltBLTq+CdDlLlYX2sAAAvi0G Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C86200ED371CCeranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 18:39:22 -0000 --_000_C86200ED371CCeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Isn't that better overall than requiring the browser to make another HTTP r= equest to pass the code over? EHL On 7/13/10 11:17 AM, "Brian Eaton" wrote: On Tue, Jul 13, 2010 at 9:42 AM, David Recordon wrote= : >> That strikes me as very odd - returning some params in the query, and >> others in the fragment is just weird. > > I actually think that you want this - albiet odd - combination when > requesting both a code and token. The code and state parameters are neede= d > by the server and thus are query parameters. The access token, scope, and > expires in shouldn't be sent to the server via HTTP and thus are within > the fragment for the JavaScript to access. The problem is that if you do it this way you end up busting the browser cache. All of the performance improvements offered by the user-agent profile are lost. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C86200ED371CCeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] user-agent flow needs a rewrite Isn’t that better overall than requiring the browser to make an= other HTTP request to pass the code over?

EHL


On 7/13/10 11:17 AM, "Brian Eaton" <beaton@google.com> wrote:

On Tue, Jul 13, 2010 at 9:42 AM, David Reco= rdon <recordond@gmail.com> wrote:=
>> That strikes me as very odd - returning some params in the query, = and
>> others in the fragment is just weird.
>
> I actually think that you want this – albiet odd – combina= tion when
> requesting both a code and token. The code and state parameters are ne= eded
> by the server and thus are query=A0parameters. The access token, scope= , and
> expires in shouldn't be sent to the server via HTTP and thus are withi= n
> the=A0fragment=A0for the JavaScript to access.

The problem is that if you do it this way you end up busting the
browser cache.  All of the performance improvements offered by the
user-agent profile are lost.

Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C86200ED371CCeranhueniversecom_-- From john@jkemp.net Tue Jul 13 11:45:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963623A69EF for ; Tue, 13 Jul 2010 11:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNPJkvdRiw1g for ; Tue, 13 Jul 2010 11:45:38 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 5981E3A67D9 for ; Tue, 13 Jul 2010 11:45:38 -0700 (PDT) Received: (qmail 29762 invoked by uid 0); 13 Jul 2010 18:45:47 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy3.bluehost.com with SMTP; 13 Jul 2010 18:45:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=qFpHHzdFP2Anqs+4rk9PtHNepgH6OdYzi9UY1SWJs9rJZgUGsNXRajIgrpJkZv5TB1Vk87IkGr55LdyugwX45bBj8/tW0XYGsKFppvDLR+/gsyTOGopVn88OzAW5b9pU; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.112]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OYkUE-00073Z-OH; Tue, 13 Jul 2010 12:45:47 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: John Kemp In-Reply-To: Date: Tue, 13 Jul 2010 14:45:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1081) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 18:45:39 -0000 Hi Eran, On Jul 13, 2010, at 1:40 PM, Eran Hammer-Lahav wrote: >=20 > On 7/13/10 10:25 AM, "John Kemp" wrote: >=20 >> On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote: >>=20 >>> I am ok replacing it with Oacts as a password=B9. >>=20 >> An access token is something used by the server to decide whether a = request is >> authorized. Although it may also be used for authenticating the = request(er), >> it's purpose is to authorize the request. >=20 > It is used to authenticate the *request* Can you give me a rough pointer to where that text is in the = specification? I see your assertion in section 5, but for example, the glossary = definition of "token" says: "A string representing an access authorization issued to the client." (note "authorization") and: "Specific additional authentication credentials may be required in order for a client to use a token." Which suggests that in addition to the presence of an authorizing token, = the server should authenticate the client. We could be more explicit = about that, but the idea seems to be there already (as it should, in my = opinion).=20 > , it is used in the same manner > other HTTP authentication schemes operate, and it has the same = behavior as a > password (security wise: plain-text storage on the client side, can be > phished, usable by any bearer). You may be right that the token MIGHT be stored plain-text on the = client. MIGHT be phished. MIGHT be used by someone who is not the entity = to which the token was originally given.=20 But it is not required to be used that way, and if the client security = properties that you mention are employed, certainly SHOULD NOT be used = to authenticate the client.=20 >=20 >> In the "bearer token" case (and even over SSL unless client certs are = used), >> the token clearly SHOULD NOT be used as a password. Rather, = authentication >> should be performed by some other mechanism, unrelated to the token = itself >> (such as an HMAC, or via client-certificate SSL/TLS, or even via an = actual >> username/password) >=20 > OAuth only includes the "bearer token case". There are no other cases > specified. Authentication of the request is out of scope for OAuth. OK, but = security considerations should note that requests should be = authenticated as well as being authorized.=20 >=20 >> I would be very unhappy if we equated access tokens with passwords. >>=20 >> I agree with Dirk that "capability" is a more expressive phrase than = either >> "shared secret" or "password". >=20 > Expressive to you and people well-versed in security theory. It means > nothing to a casual reader. The token definition includes the term, And I am happy with the text included in the definition (as shown = above). Why should it be different in section 5? > but in > this section, it is referring to how an access token is used, and it = is used > just like a password. >=20 > For better or worse, we turned the 1.0 access token into a 2.0 = password. I'd really like to understand why you feel that way - is there text that = you feel specifically supports your assertion that the token is used to = *authenticate* rather than *authorize* the request?=20 - johnk >=20 > EHL >=20 >> Regards, >>=20 >> - johnk >>=20 >>>=20 >>> EHL >>>=20 >>>=20 >>> On 7/13/10 8:55 AM, "Dirk Balfanz" wrote: >>>=20 >>>=20 >>>=20 >>> On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav = >>> wrote: >>> =46rom the client's perspective, they are 'shared symmetric secrets' = because >>> the client has to store them as-is and present them as-is. The act = exactly >>> like passwords. I added that text to make that stand out. >>>=20 >>> When using passwords, the server doesn't need to store them in = plain-text >>> either (e.g. uses a way one hash). >>>=20 >>> That's why we don't call passwords "shared symmetric secrets", = either. The >>> verifier of a passwords can verify it without knowing the secret. In = that >>> sense, it's not "shared" with the verifier. >>>=20 >>> I would like the specification to make it clear that bearer tokens = are only >>> secure while they remain *secret* and that *anyone* holding them can = gain >>> full access to what their protect. >>>=20 >>> I think the word "capability" expresses that better than the word = "shared >>> secret". >>>=20 >>> Dirk. >>>=20 >>>=20 >>> EHL >>>=20 >>> On 7/12/10 10:39 PM, "Brian Eaton" wrote: >>>=20 >>>> Section 5: = http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5 >>>>=20 >>>> Calling access tokens "shared symmetric secrets" is misleading, >>>> because if they are implemented well the authorization server and >>>> protected resource do not store a copy of the secret. >>>>=20 >>>> Instead they store a one-way hash of the token. Or they verify the >>>> token cryptographically. Under no circumstances do they need to = store >>>> a copy. >>>>=20 >>>> I'd suggest the following language: >>>>=20 >>>> "Access tokens are bearer authentication tokens or capabilities." >>>>=20 >>>> Cheers, >>>> Brian >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >=20 From jricher@mitre.org Tue Jul 13 11:49: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 D9ACC3A6B4F for ; Tue, 13 Jul 2010 11:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 rfi8snETSbUy for ; Tue, 13 Jul 2010 11:49:25 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 0AC853A6A30 for ; Tue, 13 Jul 2010 11:49:24 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6DInXUD017462 for ; Tue, 13 Jul 2010 14:49:33 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6DInXcQ017459; Tue, 13 Jul 2010 14:49:33 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 13 Jul 2010 14:49:32 -0400 From: "Richer, Justin P." To: Eran Hammer-Lahav , John Kemp Date: Tue, 13 Jul 2010 14:46:41 -0400 Thread-Topic: [OAUTH-WG] "shared symmetric secret" Thread-Index: AcsisFeeMlAR4wQoQcWPqGFUYa2sOwAAi6BAAAJNZ48= Message-ID: References: <97BD2762-F147-4774-9557-AD478338B348@jkemp.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 18:49:26 -0000 >> I would be very unhappy if we equated access tokens with passwords. >> >> I agree with Dirk that "capability" is a more expressive phrase than eit= her >> "shared secret" or "password". > Expressive to you and people well-versed in security theory. It means > nothing to a casual reader. The token definition includes the term, but i= n > this section, it is referring to how an access token is used, and it is u= sed > just like a password. Definitely agree with Eran here. The term "capability" doesn't mean much t= o me in this circumstance, but "like a password" tells me exactly what I, a= s an implementer, can expect.=20 -- Justin= From romeda@gmail.com Tue Jul 13 11:54:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E183A6B4F for ; Tue, 13 Jul 2010 11:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 IW6sJe7TpJMs for ; Tue, 13 Jul 2010 11:54:16 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 1F1663A6849 for ; Tue, 13 Jul 2010 11:54:13 -0700 (PDT) Received: by pzk6 with SMTP id 6so1796081pzk.31 for ; Tue, 13 Jul 2010 11:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=v5IXu+bSefSPpwSnVLt64E8nJAqGrOmMVksC3kPLX/s=; b=SzZWC5s59dvJNhfgk+yKrzpfxZDN/5ttcKGijUcOZaXj8uDqaH9I69kA1GrMqubysn tUEoqr4d0AmEoeU9Js6+snz+PUPA2KqiHV7j7Ts3BsGK4z6Ad2LtfA5OJSUASUSaHbfP uS3MjHuLAfsVTc6JBCKu/S/3CpaWsBH6Btdlk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=SZTTdaNgrSVDNAHtglXRSqfM4Vj5VQHBysjOpjB/7pNNvqmCdxvgepnJmmHlxI2iC4 KecG4egmaiil+Tg0zU0Kqd7kCUtuan4iSFprQqnP3ygBmWC4Ez40eOOxyMMUjguZSi7G vXy9BXAuaW0IG8BNEqwK2QVRbtDz1JTGICGLo= Received: by 10.142.164.3 with SMTP id m3mr19232134wfe.294.1279047258980; Tue, 13 Jul 2010 11:54:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.8.6 with HTTP; Tue, 13 Jul 2010 11:53:57 -0700 (PDT) In-Reply-To: References: From: Blaine Cook Date: Tue, 13 Jul 2010 19:53:57 +0100 Message-ID: To: OAuth WG Content-Type: text/plain; charset=UTF-8 Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 18:54:17 -0000 I don't claim to fully grok what the current state of the various proposals are regarding the user agent flow, but fundamentally, shouldn't we be aiming to replicate what Twitter and Facebook are already doing? We've already moved towards JSON as a standard format, why not go all the way and mandate either JSONP or CORS support, and explicitly build around a Javascript-centric model (since that's really what we're talking about, and that's what is deployed today). b. From john@jkemp.net Tue Jul 13 12:07:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F003A68A7 for ; Tue, 13 Jul 2010 12:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUM+0vfl9YAy for ; Tue, 13 Jul 2010 12:07:00 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 839123A6826 for ; Tue, 13 Jul 2010 12:07:00 -0700 (PDT) Received: (qmail 2443 invoked by uid 0); 13 Jul 2010 19:07:06 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy2.bluehost.com with SMTP; 13 Jul 2010 19:07:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=Tb5vfmjhD+Qd0WY1J0RnXq7UZ+0pMkWNuXMD7aZuvTBrLamdcgnB2t6n/LlYsLgL3CwCk8H+BOtaNzrscN5eKzLrFyRHRmJjFyoK8aX3ZmHk9KAHB+JCmI+p5h7+lj3W; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.112]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OYkos-00032a-Jj; Tue, 13 Jul 2010 13:07:06 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: Date: Tue, 13 Jul 2010 15:07:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <361957FA-3B07-46CB-841B-510249F81788@jkemp.net> References: <97BD2762-F147-4774-9557-AD478338B348@jkemp.net>, To: "Richer, Justin P." X-Mailer: Apple Mail (2.1081) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 19:07:01 -0000 On Jul 13, 2010, at 2:46 PM, Richer, Justin P. wrote: >>> I would be very unhappy if we equated access tokens with passwords. >>>=20 >>> I agree with Dirk that "capability" is a more expressive phrase than = either >>> "shared secret" or "password". >=20 >> Expressive to you and people well-versed in security theory. It means >> nothing to a casual reader. The token definition includes the term, = but in >> this section, it is referring to how an access token is used, and it = is used >> just like a password. >=20 > Definitely agree with Eran here. The term "capability" doesn't mean = much to me in this circumstance, but "like a password" tells me exactly = what I, as an implementer, can expect.=20 Perhaps so, but it doesn't correctly describe how the token should be = used, or deal with the difference between authentication and = authorization. It also doesn't reflect the language used elsewhere in = the specification.=20 Regards, - johnk >=20 > -- Justin From beaton@google.com Tue Jul 13 12:07: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 8FFAD3A69B9 for ; Tue, 13 Jul 2010 12:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.702 X-Spam-Level: X-Spam-Status: No, score=-105.702 tagged_above=-999 required=5 tests=[AWL=0.275, 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 I91t7Ulg4fvO for ; Tue, 13 Jul 2010 12:07:55 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8BF213A6826 for ; Tue, 13 Jul 2010 12:07:55 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o6DJ83I8008845 for ; Tue, 13 Jul 2010 12:08:03 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279048084; bh=zNL0rtpGA3x7xPtaaEiEv523Prs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Fk8da8Th68REC4VwGjYrQpU4wzXaL8TfeU+a6ZpyMlX2+XL8tuOQ2bUepeIeB8kYD MrfHY6aR9u8VIZ9X0oqGQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=xF9wfwL6QigiNLsA8qs5LzM0uemks1uEvbi4zY1gJvA5a7xbYAZJ0e4T6fczAJtss NKOZRTKlaU7RxM5rCEZVA== Received: from pwi1 (pwi1.prod.google.com [10.241.219.1]) by hpaq14.eem.corp.google.com with ESMTP id o6DJ81Bb028371 for ; Tue, 13 Jul 2010 12:08:02 -0700 Received: by pwi1 with SMTP id 1so2586228pwi.1 for ; Tue, 13 Jul 2010 12:08:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.140.18 with SMTP id n18mr19207476wfd.47.1279048080823; Tue, 13 Jul 2010 12:08:00 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Tue, 13 Jul 2010 12:08:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 12:08:00 -0700 Message-ID: From: Brian Eaton To: Blaine Cook Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 19:07:56 -0000 On Tue, Jul 13, 2010 at 11:53 AM, Blaine Cook wrote: > I don't claim to fully grok what the current state of the various > proposals are regarding the user agent flow, but fundamentally, > shouldn't we be aiming to replicate what Twitter and Facebook are > already doing? Yes. They are passing all variable parameter on URL fragments. Other types of cross-domain messaging (e.g. window.postMessage) aren't widely deployed enough to rely on exclusively. Yet. Give it a few more years. > We've already moved towards JSON as a standard format, why not go all > the way and mandate either JSONP or CORS support, and explicitly build > around a Javascript-centric model (since that's really what we're > talking about, and that's what is deployed today). jsonp won't work for this use-case, it ends up requiring an extra client-to-server round trip. Cheers, Brian From romeda@gmail.com Tue Jul 13 12:10: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 82E0A3A6B33 for ; Tue, 13 Jul 2010 12:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+fSTel+NheV for ; Tue, 13 Jul 2010 12:10:05 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 29FFE3A6AA1 for ; Tue, 13 Jul 2010 12:10:05 -0700 (PDT) Received: by pwj1 with SMTP id 1so2882682pwj.31 for ; Tue, 13 Jul 2010 12:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=z7AiEYkOrFW667nDaCaHwQI/qol0yaOnJYEY/wyoDso=; b=qfwoPu9P9eXMPqL0JpyJ77/O7jjPPJ5P+LRAYeIVYApODSEuR5W7/E+kVNwVK3QSia VwtGxXR687uKnjxo3ooaLmcPgt44xN40+t0kyUv6JZVuzgA4K1dlKZx6WaZQY5dOl4a+ awVUtsj8OqJYXlpaWw1WWZfuXbdjuzF1Z84NY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=anernKx37oF/+VjYNaAMpxIVTY5uwt/ayJe2tsScQZ4o0/0vJ0jCDsTKlMbver+RIK zGSQKiuQbtDbYyC3aFTqTlDY+rd9IGhjLC76Kaqw7eG6FbHLYYA6Epaje/CUJI9Fn3YS I+BWVLUoNUG/z83M0lQkg22oMcOER/bhZNSVY= Received: by 10.142.210.2 with SMTP id i2mr6157139wfg.24.1279047809379; Tue, 13 Jul 2010 12:03:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.8.6 with HTTP; Tue, 13 Jul 2010 12:03:08 -0700 (PDT) In-Reply-To: References: <97BD2762-F147-4774-9557-AD478338B348@jkemp.net> From: Blaine Cook Date: Tue, 13 Jul 2010 20:03:08 +0100 Message-ID: To: OAuth WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 19:10:07 -0000 +1 on "like a password", or something similar-and-meaningful because that's exactly how it's being used here. Pre-shared key, shared secret, etc, would be fine. Keep in mind that authentication *will be done* using the bearer token, and the bearer token alone. An OAuth token is unlike capabilities in that capabilities tend to be bound to addressable data =E2=80=93=C2=A0in most OAuth deployments, the dat= a addressing is separate from the token. b. On 13 July 2010 19:46, Richer, Justin P. wrote: >>> I would be very unhappy if we equated access tokens with passwords. >>> >>> I agree with Dirk that "capability" is a more expressive phrase than ei= ther >>> "shared secret" or "password". > >> Expressive to you and people well-versed in security theory. It means >> nothing to a casual reader. The token definition includes the term, but = in >> this section, it is referring to how an access token is used, and it is = used >> just like a password. > > =C2=A0Definitely agree with Eran here. The term "capability" doesn't mean= much to me in this circumstance, but "like a password" tells me exactly wh= at I, as an implementer, can expect. > > =C2=A0-- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jricher@mitre.org Tue Jul 13 12:13:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1DD3A69E6 for ; Tue, 13 Jul 2010 12:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 QYSCyzbV7UzV for ; Tue, 13 Jul 2010 12:13:26 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 2FC523A6B50 for ; Tue, 13 Jul 2010 12:13:25 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6DJDYwZ011754 for ; Tue, 13 Jul 2010 15:13:34 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6DJDYSr011751 for ; Tue, 13 Jul 2010 15:13:34 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 13 Jul 2010 15:13:33 -0400 From: "Richer, Justin P." To: "oauth@ietf.org" Date: Tue, 13 Jul 2010 15:13:32 -0400 Thread-Topic: Proposal: Develop Implementor's Guides for Major Use Cases Thread-Index: AQHLIr75qH79cynv0EyzvecJ8jEcCA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Proposal: Develop Implementor's Guides for Major Use Cases X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 19:13:27 -0000 Brian's brought up the point that the new organization would cause an imple= mentor to have to jump all around the spec to find all the parts needed. I = propose that the working group work on a set of "implementor guides" that d= etail exactly what parts one needs to deal with all of the major use cases.= These would cover both the client and server cases, and would be worded al= ong the lines of "listen like this, accept these five arguments that do thi= s, and return this". In this way, it would be closer to the -06-and-earlier= "profiles".=20 I can see value in this helping adoption. An implementor isn't going to car= e about elegant organization of thoughts if they can't figure out what para= meters to listen for. A set of guides like this would give someone a direct= , non-ambiguous way to go about building stuff. Case in point, in all my im= plementations of OAuth 1.0, I referred more to the connection diagrams than= I ever did to the protocol spec. But this of course does beg us to ask, shouldn't the spec itself fill this = role? Or can it? -- Justin= From eran@hueniverse.com Tue Jul 13 12:19:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8C573A6B52 for ; Tue, 13 Jul 2010 12:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 xc8s6xdRm1jN for ; Tue, 13 Jul 2010 12:19:17 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id F24903A6A83 for ; Tue, 13 Jul 2010 12:19:16 -0700 (PDT) Received: (qmail 10016 invoked from network); 13 Jul 2010 19:19:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 19:19:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 13 Jul 2010 12:19:18 -0700 From: Eran Hammer-Lahav To: "Richer, Justin P." Date: Tue, 13 Jul 2010 12:19:10 -0700 Thread-Topic: [OAUTH-WG] Proposal: Develop Implementor's Guides for Major Use Cases Thread-Index: AcsiwEoAxaiV4aK9RYe1yiM7DhObeQ== Message-ID: <9C97037A-C743-4065-8B72-D0CED385F7B2@hueniverse.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal: Develop Implementor's Guides for Major Use Cases X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 19:19:17 -0000 I think the spec should address this. I don't think it needs to go back to = -06 format. There is a middle ground.=20 Also, keep in mind that the current format is much easier for those impleme= nting multiple flows or servers.=20 The important part is to make the spec instructive, not to optimize linear = reading. It's a spec and internal references are part of the deal. EHL On Jul 13, 2010, at 15:13, "Richer, Justin P." wrote: > Brian's brought up the point that the new organization would cause an imp= lementor to have to jump all around the spec to find all the parts needed. = I propose that the working group work on a set of "implementor guides" that= detail exactly what parts one needs to deal with all of the major use case= s. These would cover both the client and server cases, and would be worded = along the lines of "listen like this, accept these five arguments that do t= his, and return this". In this way, it would be closer to the -06-and-earli= er "profiles".=20 >=20 > I can see value in this helping adoption. An implementor isn't going to c= are about elegant organization of thoughts if they can't figure out what pa= rameters to listen for. A set of guides like this would give someone a dire= ct, non-ambiguous way to go about building stuff. Case in point, in all my = implementations of OAuth 1.0, I referred more to the connection diagrams th= an I ever did to the protocol spec. >=20 > But this of course does beg us to ask, shouldn't the spec itself fill thi= s role? Or can it? >=20 > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From john@jkemp.net Tue Jul 13 12:36: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 007EB3A6A8A for ; Tue, 13 Jul 2010 12:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvJH0srKLFa3 for ; Tue, 13 Jul 2010 12:36:06 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id D97A43A6B2E for ; Tue, 13 Jul 2010 12:33:24 -0700 (PDT) Received: (qmail 11092 invoked by uid 0); 13 Jul 2010 19:32:00 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy2.bluehost.com with SMTP; 13 Jul 2010 19:32:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=SgSSkkI3Z6u+c5hMw/J7mJ9gVLu27ESnqobhahjdjlbfpIE1Tmx35PIH3GTb0t1pUTVGvfSnuVQuSfuVF1JRFb9Oa4csAf/EnWmePjv+fQncYDI+Ry9aPfxARQzKPrcc; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.112]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OYlCy-0005gX-39; Tue, 13 Jul 2010 13:32:00 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: John Kemp In-Reply-To: Date: Tue, 13 Jul 2010 15:31:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <93F20A70-3133-4C5A-BE15-9C85F1D42787@jkemp.net> References: <97BD2762-F147-4774-9557-AD478338B348@jkemp.net> To: Blaine Cook X-Mailer: Apple Mail (2.1081) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 19:36:31 -0000 On Jul 13, 2010, at 3:03 PM, Blaine Cook wrote: > +1 on "like a password", or something similar-and-meaningful because > that's exactly how it's being used here. Pre-shared key, shared > secret, etc, would be fine. Keep in mind that authentication *will be > done* using the bearer token, and the bearer token alone. Where is that specified? Is that required for all implementations? >=20 > An OAuth token is unlike capabilities in that capabilities tend to be > bound to addressable data =96 in most OAuth deployments, the data > addressing is separate from the token. A capability, basically, is a reference to an object and the permission = to use it, bound together. Possession of the capability is enough to = authorize the use of the reference. Bearer tokens follow roughly that = model. They are about authorization and MAY be used alone for = authentication, but may also be used with (specified, or not, in OAuth) = other mechanisms for authentication. At least I hope that is the model = (not to *require* servers to authenticate using the bearer token alone = even if *some* implementations do that)? - johnk >=20 > b. >=20 > On 13 July 2010 19:46, Richer, Justin P. wrote: >>>> I would be very unhappy if we equated access tokens with passwords. >>>>=20 >>>> I agree with Dirk that "capability" is a more expressive phrase = than either >>>> "shared secret" or "password". >>=20 >>> Expressive to you and people well-versed in security theory. It = means >>> nothing to a casual reader. The token definition includes the term, = but in >>> this section, it is referring to how an access token is used, and it = is used >>> just like a password. >>=20 >> Definitely agree with Eran here. The term "capability" doesn't mean = much to me in this circumstance, but "like a password" tells me exactly = what I, as an implementer, can expect. >>=20 >> -- Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From naitiks@gmail.com Tue Jul 13 13:01:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95FA3A6B44 for ; Tue, 13 Jul 2010 13:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V19hqEaGgi5m for ; Tue, 13 Jul 2010 13:01:48 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id DBC4C3A69DF for ; Tue, 13 Jul 2010 13:01:47 -0700 (PDT) Received: by gwj19 with SMTP id 19so1329893gwj.31 for ; Tue, 13 Jul 2010 13:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=28ic/0BzVMUvNs4kWmqSsSx93WXSHbveQ8cSUdE7xw8=; b=hjiAieXCzi5i7KCi6P9GwCIX3TbupbX2l/XciJauPd5CHvHpXrQqGG6+ygI6VnVMi9 P94qv6EdFyY4qmqE99VG9/DDduNVIz4bJ3nPHJINHk/JyttTIBqBxvLuwdRvVX4DcCyx Cz4cU9OLdqNyXUI/KzpiainCGAxhQS7nfq6MQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=durnWVA83KS+UGo7r7yghLHNfPIa1kMzbbBFOYf8n9JLoHa15lWM7woFL6OENeL3/E RGwgUj/JeOxExLyDV503xcRBO+Tne7AUd7M3flpVLukRuwVyKyMkRD6/+Zf9iEJgfZlc dvaALiKd3NuMyhHJtySaPd6imI+peBoIE2V+s= Received: by 10.150.140.6 with SMTP id n6mr6316354ybd.412.1279051313329; Tue, 13 Jul 2010 13:01:53 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.231.159.193 with HTTP; Tue, 13 Jul 2010 13:01:32 -0700 (PDT) In-Reply-To: References: From: Naitik Shah Date: Tue, 13 Jul 2010 13:01:32 -0700 X-Google-Sender-Auth: 8Qly0WfO8AsjC9ZAv0mBidwXE3M Message-ID: To: Brian Eaton Content-Type: multipart/alternative; boundary=000e0cd375922e4716048b4a5784 Cc: OAuth WG Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 20:01:50 -0000 --000e0cd375922e4716048b4a5784 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 13, 2010 at 11:17 AM, Brian Eaton wrote: > On Tue, Jul 13, 2010 at 9:42 AM, David Recordon > wrote: > >> That strikes me as very odd - returning some params in the query, and > >> others in the fragment is just weird. > > > > I actually think that you want this =E2=80=93 albiet odd =E2=80=93 comb= ination when > > requesting both a code and token. The code and state parameters are > needed > > by the server and thus are query parameters. The access token, scope, a= nd > > expires in shouldn't be sent to the server via HTTP and thus are within > > the fragment for the JavaScript to access. > > The problem is that if you do it this way you end up busting the > browser cache. All of the performance improvements offered by the > user-agent profile are lost. > This is one of the key reasons imho. JavaScript can access the query and th= e fragment, so it would technically work in either case. But having the flexibility to choose where it goes saves on one round trip to the client application. For instance, in the Facebook SDK we would like to do this background ping, and save the code in a cookie and fire a JavaScript callback to let the client application know that one is available. The client application can then decide if it wants to trigger a network request to send the code to it's servers, or not. By allowing this data to come in the fragment, we can use a static endpoint (potentially served from a subdomain that goes to a CDN) and reduce the process to a single server request in the common case. -Naitik --000e0cd375922e4716048b4a5784 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 13, 2010 at 11:17 AM, Brian Eaton <beaton@google.com<= /a>> wrote:
On Tue, Jul 13, 2010 at 9:42 AM, David Recordon <recordond@gmail.com> wrote:
>> That strikes me as very odd - returning some params in the query, = and
>> others in the fragment is just weird.
>
> I actually think that you want this =E2=80=93 albiet odd =E2=80=93 com= bination when
> requesting both a code and token. The code and state parameters are ne= eded
> by the server and thus are query=C2=A0parameters. The access token, sc= ope, and
> expires in shouldn't be sent to the server via HTTP and thus are w= ithin
> the=C2=A0fragment=C2=A0for the JavaScript to access.

The problem is that if you do it this way you end up busting the
browser cache. =C2=A0All of the performance improvements offered by the
user-agent profile are lost.

This is on= e of the key reasons imho. JavaScript can access the query and the fragment= , so it would technically work in either case. But having the flexibility t= o choose where it goes saves on one round trip to the client application. F= or instance, in the Facebook SDK we would like to do this background ping, = and save the code in a cookie and fire a JavaScript callback to let the cli= ent application know that one is available. The client application can then= decide if it wants to trigger a network request to send the code to it'= ;s servers, or not. By allowing this data to come in the fragment, we can u= se a static endpoint (potentially served from a subdomain that goes to a CD= N) and reduce the process to a single server request in the common case.


-Naitik
--000e0cd375922e4716048b4a5784-- From romeda@gmail.com Tue Jul 13 13:07:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96573A69BD for ; Tue, 13 Jul 2010 13:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-89lP5FVsbw for ; Tue, 13 Jul 2010 13:07:19 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 81D3E3A6B5F for ; Tue, 13 Jul 2010 13:07:05 -0700 (PDT) Received: by pxi20 with SMTP id 20so2887305pxi.31 for ; Tue, 13 Jul 2010 13:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ZERjOU3Ta23++svOd4va9pAlSsHF9uvbYidf+T2kOV4=; b=pt7nmEtPp6y8hbpYrKbt9RaGi06o6wwOS8StJkoObfFTV3zgX/ai2HgfV2EzYmWHpd 5BGYxKtS2fzxcy9JFMl1/ZAd5fWQaceorvdNHDArWlUQ6sgfGwJjKEpT/9gIHN72BkEJ cRvDyJuLio9KR4vwJC8Juem77L8q2HZNuzzps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=PoHnUcKiU1qJTh6PwsLp+Ansaz2LD85e6zx3w+dtjJag0plFWAPHHNS6vdJ/QnFAHP Q/f36Buad66sxQFAPKEsjZCB7W5Nc0kz0zPuttAKawOIyutqhcd2tyTmZFkhe694MsbZ u5OwT0c0AGpPq8Wd9YrFt/maQ+9NQbd94QNbM= Received: by 10.142.216.21 with SMTP id o21mr9032887wfg.153.1279051621587; Tue, 13 Jul 2010 13:07:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.8.6 with HTTP; Tue, 13 Jul 2010 13:06:41 -0700 (PDT) In-Reply-To: <93F20A70-3133-4C5A-BE15-9C85F1D42787@jkemp.net> References: <97BD2762-F147-4774-9557-AD478338B348@jkemp.net> <93F20A70-3133-4C5A-BE15-9C85F1D42787@jkemp.net> From: Blaine Cook Date: Tue, 13 Jul 2010 21:06:41 +0100 Message-ID: To: John Kemp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 20:07:21 -0000 On 13 July 2010 20:31, John Kemp wrote: > Where is that specified? Is that required for all implementations? It's not specified - I was referring to your earlier comments: > In the "bearer token" case (and even over SSL unless client certs are use= d), the > token clearly SHOULD NOT be used as a password. Rather, authentication sh= ould > be performed by some other mechanism, unrelated to the token itself (such= as an > HMAC, or via client-certificate SSL/TLS, or even via an actual username/p= assword) > I would be very unhappy if we equated access tokens with passwords. The token is never used as the authentication mechanism (i.e., the mechanism to authenticate the user), except in schemes where it explicitly makes sense (e.g., UMA as I understand it, Twitter's OAuth Echo, etc). So there's no concern about that. What I was trying to say, and I'm just re-iterating Eran's comments here, is that once issued [in the context of a request made by an authenticated user that grants authorization to the OAuth client], the token will be used de-facto as a password, passphrase, shared secret, or whatever we want to call it. By calling it a "capability", we don't signal to implementors what the security implications are, and what they can do to avoid disappointment. > A capability, basically, is a reference to an object and the permission t= o use it, bound together. Possession of the capability is enough to authori= ze the use of the reference. Bearer tokens follow roughly that model. They = are about authorization and MAY be used alone for authentication, but may a= lso be used with (specified, or not, in OAuth) other mechanisms for authent= ication. At least I hope that is the model (not to *require* servers to aut= henticate using the bearer token alone even if *some* implementations do th= at)? It's unclear what you mean is being authenticated by the server =E2=80=93= =C2=A0do you mean the user, or the client, or something else? This question is persistent and points to exactly the kind of confusion I think Eran is correct to try to avoid by simply calling the token password-like. If we use language that clearly indicates to developers that "with the clear-text token, requests can be made [modulo reduced permissions] as though they were made by someone in possession of the user's username and password. Don't leak it, and treat it as though it were a password", then we avoid having to explain (embarrassingly) that the "capability" actually meant something like "password". b. From andrewarnott@gmail.com Tue Jul 13 13:11: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 1242A3A69D5 for ; Tue, 13 Jul 2010 13:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dwj6HbgD5rSX for ; Tue, 13 Jul 2010 13:11:14 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 93B763A6888 for ; Tue, 13 Jul 2010 13:11:09 -0700 (PDT) Received: by gwj19 with SMTP id 19so1337425gwj.31 for ; Tue, 13 Jul 2010 13:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=i/AZ2xzoTtFqeEIjRtces+ygXGiD/hHDKmQZMo9hjfc=; b=MQlAlRHU/LacFTEc3Ld/4+gTq4LeojMLFL9rRWrwN1nvAIgqlDtVrTSO2x8tam80An +zpil3BP7x8YyoSM4mmYVYOYnI5g7rKtM86BlxqyjfcX0cASjqxyGVXPhNER7qHszEk2 mUC4RuGI8U7rQ+u02kL5CnE6P/PGMTF+hTg2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=TwSoBWozuv9wefAJDLztfiHBlJn/rtxcq3WdQIKUD+PD6sPvqKHIiCz37bPTZ5PJKd tuzZwkTMyfJQqGJlJb0Ya0MA3yCwudgzj4ryj8we0tVwds9PRC7j4Pg/8YjJzj+Ipznj smq2U4+A0SXmxaJr2RqtO9sMGxeUMLj5IGAyI= Received: by 10.150.233.21 with SMTP id f21mr7294837ybh.388.1279051876976; Tue, 13 Jul 2010 13:11:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.92.8 with HTTP; Tue, 13 Jul 2010 13:10:56 -0700 (PDT) In-Reply-To: References: From: Andrew Arnott Date: Tue, 13 Jul 2010 13:10:56 -0700 Message-ID: To: Brian Eaton Content-Type: multipart/alternative; boundary=000e0cd694c2c6e255048b4a7853 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 20:11:16 -0000 --000e0cd694c2c6e255048b4a7853 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 12, 2010 at 10:36 PM, Brian Eaton wrote: > Draft 10 has the following sentence in section 4.1.4: > http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4 > > "The authorization server MAY issue a new refresh token." > > That carries a surprising amount of baggage. I suggest removing the > sentence, or changing it to MUST NOT, pending a discussion of the use > cases for issuing new refresh tokens. > > Does anyone remember why that sentence got added to the spec? > > There are two reasons I can see for issuing new refresh tokens: > 1) secrets are like underwear, change them frequently > 2) someone has a cryptographically implemented refresh token that > needs to be re-signed or re-issued > > I'm pretty sure anyone issuing cryptographic refresh tokens is crazy, > these pretty much have to be backed by server-side state or there is > no way to run your system. Brian, can you tell me what you mean by cryptographically implemented refresh token, and why using one would be crazy? You say using them would require server-side state. I'd say just the opposite. If you *are* signing your refresh tokens (a cryptographic operation) you don't need to store them on the auth server, but if you aren't using cryptography, then you must store the tokens on the auth server in order to validate them when they come back to you. So in short, I'm thinking the opposite of what you state. So please enlighten me. What am I missing? --000e0cd694c2c6e255048b4a7853 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 12, 2010 at 10:36 PM, Brian Eaton <beaton@google.com<= /a>> wrote:
Draft 10 has the following sentence in section 4.1.4:
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#sectio= n-4.1.4

"The authorization server MAY issue a new refresh token."

That carries a surprising amount of baggage. =A0I suggest removing the
sentence, or changing it to MUST NOT, pending a discussion of the use
cases for issuing new refresh tokens.

Does anyone remember why that sentence got added to the spec?

There are two reasons I can see for issuing new refresh tokens:
1) secrets are like underwear, change them frequently
2) someone has a cryptographically implemented refresh token that
needs to be re-signed or re-issued

I'm pretty sure anyone issuing cryptographic refresh tokens is crazy, these pretty much have to be backed by server-side state or there is
no way to run your system. =A0

Brian, can y= ou tell me what you mean by cryptographically implemented refresh token, an= d why using one would be crazy? =A0You say using them would require server-= side state. =A0I'd say just the opposite. =A0If you are=A0signin= g your refresh tokens=A0(a cryptographic operation) you don't need to s= tore them on the auth server, but if you aren't using cryptography, the= n you must store the tokens on the auth server in order to validate them wh= en they come back to you.

So in short, I'm thinking the opposite of what you = state. =A0So please enlighten me. =A0What am I missing?
--000e0cd694c2c6e255048b4a7853-- From beaton@google.com Tue Jul 13 13:35: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 914A23A6A73 for ; Tue, 13 Jul 2010 13:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.789 X-Spam-Level: X-Spam-Status: No, score=-101.789 tagged_above=-999 required=5 tests=[AWL=0.188, 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 O07t94fl5OYA for ; Tue, 13 Jul 2010 13:35:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 537133A69A5 for ; Tue, 13 Jul 2010 13:35:10 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o6DKZIib016862 for ; Tue, 13 Jul 2010 13:35:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279053318; bh=6j1WHW9BoyiIgqRaU7iGEEdZ7h8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=IthIdj+dW5v5sUMSyO4/ZdKfN+ZjGB5Lk+HsLSD0rcnDM/Z+M4ZMtsxzur5wYqJr2 7JoLoOAlpMU5qq/HhDA7w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=gksefoAM3Pf7Jj71ukcBl+9H0g4d2FjsQ4n286oqh+nCImiM3fmqpFcpZepl7XM+m ab1oA0U7FPrn12JPufTWw== Received: from pvg2 (pvg2.prod.google.com [10.241.210.130]) by kpbe12.cbf.corp.google.com with ESMTP id o6DKZGuX000861 for ; Tue, 13 Jul 2010 13:35:16 -0700 Received: by pvg2 with SMTP id 2so3559712pvg.26 for ; Tue, 13 Jul 2010 13:35:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.211.6 with SMTP id j6mr19434345wfg.165.1279053316264; Tue, 13 Jul 2010 13:35:16 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Tue, 13 Jul 2010 13:35:16 -0700 (PDT) In-Reply-To: References: <97BD2762-F147-4774-9557-AD478338B348@jkemp.net> <93F20A70-3133-4C5A-BE15-9C85F1D42787@jkemp.net> Date: Tue, 13 Jul 2010 13:35:16 -0700 Message-ID: From: Brian Eaton To: Blaine Cook Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 20:35:13 -0000 On Tue, Jul 13, 2010 at 1:06 PM, Blaine Cook wrote: > Don't leak it, and treat it as though it were a > password", then we avoid having to explain (embarrassingly) that the > "capability" actually meant something like "password". For the initiated, that's what "capability" means. How about this language "Access tokens are bearer authentication tokens, such as passwords or capabilities." I'd encourage the use of the word "capability" because a lot of the use cases that OAuth 2 enables over OAuth 1 involve using the token like a capability, sharing it across multiple components to convey authorization. From beaton@google.com Tue Jul 13 13:37: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 68C4C3A69F0 for ; Tue, 13 Jul 2010 13:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.81 X-Spam-Level: X-Spam-Status: No, score=-101.81 tagged_above=-999 required=5 tests=[AWL=0.167, 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 AKzQWg6cQVov for ; Tue, 13 Jul 2010 13:37:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 6936A3A690D for ; Tue, 13 Jul 2010 13:37:45 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o6DKbrV9006619 for ; Tue, 13 Jul 2010 13:37:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279053474; bh=g1kRAIbc2dNPfJE0DDi7iAXszcs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=DNxP/EO8A2XIgGdaeR3ItLsKgzI5YxKcE8Dpwg/c937UKEKVQiQzRQR2bjnaZHQgL LLS3jU4gAznu0tqVy114g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=HumDpcFjZj+NzxMW3j2Eze0GdGxRd9tO/3q/YIj7aXxHNN7+OjRuhraSJwazzPmn3 C5godC7U1Jzt610Y4uRlA== Received: from pwi10 (pwi10.prod.google.com [10.241.219.10]) by kpbe20.cbf.corp.google.com with ESMTP id o6DKbpiq003293 for ; Tue, 13 Jul 2010 13:37:52 -0700 Received: by pwi10 with SMTP id 10so2661686pwi.20 for ; Tue, 13 Jul 2010 13:37:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.233.1 with SMTP id f1mr14067817wfh.169.1279053471750; Tue, 13 Jul 2010 13:37:51 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Tue, 13 Jul 2010 13:37:51 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 13:37:51 -0700 Message-ID: From: Brian Eaton To: Andrew Arnott 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] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 20:37:46 -0000 On Tue, Jul 13, 2010 at 1:10 PM, Andrew Arnott wro= te: >> I'm pretty sure anyone issuing cryptographic refresh tokens is crazy, >> these pretty much have to be backed by server-side state or there is >> no way to run your system. > > Brian, can you tell me what you mean by cryptographically implemented > refresh token, and why using one would be crazy? =A0You say using them wo= uld > require server-side state. =A0I'd say just the opposite. =A0If you are=A0= signing > your refresh tokens=A0(a cryptographic operation) you don't need to store= them > on the auth server, but if you aren't using cryptography, then you must > store the tokens on the auth server in order to validate them when they c= ome > back to you. > So in short, I'm thinking the opposite of what you state. =A0So please > enlighten me. =A0What am I missing? You and I are on the same page. Let me try again. Anyone implementing OAuth 2 needs to store information about issued refresh tokens server-side, otherwise basic functionality such as revocation is not possible. Cryptographically implemented refresh tokens, without that corresponding server-side state, are crazy. From igor.faynberg@alcatel-lucent.com Tue Jul 13 13:40: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 5A4843A69F0 for ; Tue, 13 Jul 2010 13:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, 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 0K18Mx7n+OKi for ; Tue, 13 Jul 2010 13:40:47 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 56D453A69A5 for ; Tue, 13 Jul 2010 13:40:47 -0700 (PDT) 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 o6DKepup026399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jul 2010 15:40:51 -0500 (CDT) Received: from [135.244.39.28] (faynberg.lra.lucent.com [135.244.39.28]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o6DKeocS003488; Tue, 13 Jul 2010 15:40:50 -0500 (CDT) Message-ID: <4C3CCF58.6010102@alcatel-lucent.com> Date: Tue, 13 Jul 2010 16:40:56 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian Eaton References: <97BD2762-F147-4774-9557-AD478338B348@jkemp.net> <93F20A70-3133-4C5A-BE15-9C85F1D42787@jkemp.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" 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: Tue, 13 Jul 2010 20:40:48 -0000 In this case, the term "capability" MUST be defined up front. The word "capability" seems to carry a much broader meaning than password... Igor Brian Eaton wrote: > On Tue, Jul 13, 2010 at 1:06 PM, Blaine Cook wrote: > >> Don't leak it, and treat it as though it were a >> password", then we avoid having to explain (embarrassingly) that the >> "capability" actually meant something like "password". >> > > For the initiated, that's what "capability" means. > > How about this language > > "Access tokens are bearer authentication tokens, such as passwords or > capabilities." > > I'd encourage the use of the word "capability" because a lot of the > use cases that OAuth 2 enables over OAuth 1 involve using the token > like a capability, sharing it across multiple components to convey > authorization. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From beaton@google.com Tue Jul 13 13:43:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5345A3A67F4 for ; Tue, 13 Jul 2010 13:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.826 X-Spam-Level: X-Spam-Status: No, score=-101.826 tagged_above=-999 required=5 tests=[AWL=0.151, 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 VCsD-zdAhrlC for ; Tue, 13 Jul 2010 13:43:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 3AB243A69A3 for ; Tue, 13 Jul 2010 13:43:10 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o6DKhIGa027212 for ; Tue, 13 Jul 2010 13:43:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279053798; bh=zTI4xyS0IcULYV/u6T7rskFqtzQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=brZ5+ejk4/7lFJJK4KKZpBVcOVUsFUnB5JxqXoD5icclo22RWcUyr45XxFVYK7S2U k/XGoih07DBQ3o7exBV9A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=Nd4C3RYgI/PMHXSmoGpA9CfttI2nEY2ZT9oCzk6Z+6PrGx9PJ4ADHb3eeCfJrriot WV3Ik4souSddLi/2QedYw== Received: from pxi18 (pxi18.prod.google.com [10.243.27.18]) by hpaq3.eem.corp.google.com with ESMTP id o6DKhHKj021968 for ; Tue, 13 Jul 2010 13:43:17 -0700 Received: by pxi18 with SMTP id 18so2446006pxi.4 for ; Tue, 13 Jul 2010 13:43:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.157.6 with SMTP id f6mr7210267wfe.181.1279053796689; Tue, 13 Jul 2010 13:43:16 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Tue, 13 Jul 2010 13:43:16 -0700 (PDT) In-Reply-To: <4C3CCF58.6010102@alcatel-lucent.com> References: <97BD2762-F147-4774-9557-AD478338B348@jkemp.net> <93F20A70-3133-4C5A-BE15-9C85F1D42787@jkemp.net> <4C3CCF58.6010102@alcatel-lucent.com> Date: Tue, 13 Jul 2010 13:43:16 -0700 Message-ID: From: Brian Eaton To: igor.faynberg@alcatel-lucent.com Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 20:43:12 -0000 On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg wrote: > In this case, the term "capability" MUST be defined up front. The word > "capability" seems to carry a much broader meaning than password... It has a standard definition we can reference. From http://www.ietf.org/rfc/rfc2828.txt $ capability (I) A token, usually an unforgeable data value (sometimes called a "ticket") that gives the bearer or holder the right to access a system resource. Possession of the token is accepted by a system as proof that the holder has been authorized to access the resource named or indicated by the token. (See: access control list, credential, digital certificate.) (C) This concept can be implemented as a digital certificate. (See: attribute certificate.) From eran@hueniverse.com Tue Jul 13 13: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 327033A69A5 for ; Tue, 13 Jul 2010 13:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.134, 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 Zxlbt4m1jYrh for ; Tue, 13 Jul 2010 13:46:11 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A75EB3A69BF for ; Tue, 13 Jul 2010 13:46:11 -0700 (PDT) Received: (qmail 9186 invoked from network); 13 Jul 2010 20:46:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 20:46:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 13 Jul 2010 13:46:19 -0700 From: Eran Hammer-Lahav To: Brian Eaton , Blaine Cook Date: Tue, 13 Jul 2010 13:46:17 -0700 Thread-Topic: [OAUTH-WG] "shared symmetric secret" Thread-Index: Acsiyu7HZ2fLTWAQRXuV5Ao9joVL7QAAYHwY Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8621EA9371F2eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 20:46:15 -0000 --_000_C8621EA9371F2eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'll work with this text. EHL On 7/13/10 1:35 PM, "Brian Eaton" wrote: On Tue, Jul 13, 2010 at 1:06 PM, Blaine Cook wrote: > Don't leak it, and treat it as though it were a > password", then we avoid having to explain (embarrassingly) that the > "capability" actually meant something like "password". For the initiated, that's what "capability" means. How about this language "Access tokens are bearer authentication tokens, such as passwords or capabilities." I'd encourage the use of the word "capability" because a lot of the use cases that OAuth 2 enables over OAuth 1 involve using the token like a capability, sharing it across multiple components to convey authorization. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C8621EA9371F2eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] "shared symmetric secret" I’ll work with this text.

EHL


On 7/13/10 1:35 PM, "Brian Eaton" <beaton@google.com> wrote:

On Tue, Jul 13, 2010 at 1:06 PM, Blaine Coo= k <romeda@gmail.com> wrote:
> Don't leak it, and treat it as though it were a
> password", then we avoid having to explain (embarrassingly) that = the
> "capability" actually meant something like "password&qu= ot;.

For the initiated, that's what "capability" means.

How about this language

"Access tokens are bearer authentication tokens, such as passwords or<= BR> capabilities."

I'd encourage the use of the word "capability" because a lot of t= he
use cases that OAuth 2 enables over OAuth 1 involve using the token
like a capability, sharing it across multiple components to convey
authorization.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C8621EA9371F2eranhueniversecom_-- From andrewarnott@gmail.com Tue Jul 13 13:46: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 2E8243A6A00 for ; Tue, 13 Jul 2010 13:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.876, 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 4iqvSuKXHhIi for ; Tue, 13 Jul 2010 13:46:37 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id E50183A690D for ; Tue, 13 Jul 2010 13:46:36 -0700 (PDT) Received: by yxm8 with SMTP id 8so1574533yxm.31 for ; Tue, 13 Jul 2010 13:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Yizwe8LPI+jU1jaA+eLWB2KYwELHgwqWh4SDl3XvAYI=; b=B4ujeotMdDylqBwi2NFYLQiXZ2VkxXr2QNyHCvKPHAJUOfO0TOJcGjDWkqq9TCDvmD RhO9RMbx5zKPKbx2Y00+mIkkiJOpQSdwG7Pby5yYKyaRrsIopR9xb6TJRi+KAWxFp3o/ v9Cu4lyQoTAEj9yrm1g22umtQxouJ7Y1OQBs4= 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=lFdCyLBtDLR8Uy2BmnYA6qP0C/mWN7XrEbylcxniws5l4l9DxgS4Rpml1SM3tTOvTK XbQzv1VZye3TQbuHazICrmibwmOEw7i9UrboUqQtPKSO+Eca7Kxdr0NnWXtwcAwPWQVh DTmYXvQdN+3hFDmtAjuLtgykt11mGWAHhYSbY= MIME-Version: 1.0 Received: by 10.151.25.15 with SMTP id c15mr7095648ybj.325.1279054005428; Tue, 13 Jul 2010 13:46:45 -0700 (PDT) Received: by 10.150.92.8 with HTTP; Tue, 13 Jul 2010 13:46:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 13:46:45 -0700 Message-ID: From: Andrew Arnott To: Brian Eaton Content-Type: multipart/alternative; boundary=000e0cd2916ea4625e048b4af782 Cc: oauth Subject: Re: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 20:46:38 -0000 --000e0cd2916ea4625e048b4af782 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 13, 2010 at 1:37 PM, Brian Eaton wrote: > On Tue, Jul 13, 2010 at 1:10 PM, Andrew Arnott > wrote: > >> I'm pretty sure anyone issuing cryptographic refresh tokens is crazy, > >> these pretty much have to be backed by server-side state or there is > >> no way to run your system. > > > > Brian, can you tell me what you mean by cryptographically implemented > > refresh token, and why using one would be crazy? You say using them > would > > require server-side state. I'd say just the opposite. If you > are signing > > your refresh tokens (a cryptographic operation) you don't need to store > them > > on the auth server, but if you aren't using cryptography, then you must > > store the tokens on the auth server in order to validate them when they > come > > back to you. > > So in short, I'm thinking the opposite of what you state. So please > > enlighten me. What am I missing? > > You and I are on the same page. Let me try again. > > Anyone implementing OAuth 2 needs to store information about issued > refresh tokens server-side, otherwise basic functionality such as > revocation is not possible. > > Cryptographically implemented refresh tokens, without that > corresponding server-side state, are crazy. > Ah, got it. Yes, we're on the same page. I happen to store the authorization tuple (mentioned in another thread) rather than the refresh token itself. That way I can issue an arbitrary number of refresh tokens for the same client/user/scope/issued_date set without storing any extra data in the database, but I can still support revocations by deleting the standing authorization from the db. Obviously, each time a refresh token is received, its corresponding tuple in the table is checked to be present to detect revocations. --000e0cd2916ea4625e048b4af782 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 13, 2010 at 1:37 PM, Brian Eaton <beaton@google.com> wrote:
On Tue, Jul 13, 2010 at 1:10 PM, Andrew Arnott <andrewarnott@gmail.com> wrote: >> I'm pretty sure anyone issuing cryptographic refresh tokens is= crazy,
>> these pretty much have to be backed by server-side state or there = is
>> no way to run your system.
>
> Brian, can you tell me what you mean by cryptographically implemented<= br> > refresh token, and why using one would be crazy? =A0You say using them= would
> require server-side state. =A0I'd say just the opposite. =A0If you= are=A0signing
> your refresh tokens=A0(a cryptographic operation) you don't need t= o store them
> on the auth server, but if you aren't using cryptography, then you= must
> store the tokens on the auth server in order to validate them when the= y come
> back to you.
> So in short, I'm thinking the opposite of what you state. =A0So pl= ease
> enlighten me. =A0What am I missing?

You and I are on the same page. =A0Let me try again.

Anyone implementing OAuth 2 needs to store information about issued
refresh tokens server-side, otherwise basic functionality such as
revocation is not possible.

Cryptographically implemented refresh tokens, without that
corresponding server-side state, are crazy.

Ah, got it. =A0Yes, we're on the same page.= =A0

I happen to store the authorization tuple (me= ntioned in another thread) rather than the refresh token itself. =A0That wa= y I can issue an arbitrary number of refresh tokens for the same client/use= r/scope/issued_date set without storing any extra data in the database, but= I can still support revocations by deleting the standing authorization fro= m the db. =A0Obviously, each time a refresh token is received, its correspo= nding tuple in the table is checked to be present to detect revocations. --000e0cd2916ea4625e048b4af782-- From beaton@google.com Tue Jul 13 13:56: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 8A54E3A6A4C for ; Tue, 13 Jul 2010 13:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.84 X-Spam-Level: X-Spam-Status: No, score=-101.84 tagged_above=-999 required=5 tests=[AWL=0.137, 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 7XG4vYNo6q5x for ; Tue, 13 Jul 2010 13:56:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9C3823A67D7 for ; Tue, 13 Jul 2010 13:56:07 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o6DKuFhw001296 for ; Tue, 13 Jul 2010 13:56:15 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279054575; bh=I2J2HGpx53EBWHnmgMr2yHjoS3k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ycuHE82k3ib3b1D89Zh6fM8c56G4QI324L29Na0JLHmJm3BAMKpxMeb3AfQ1/Jemp IOGfAINTM8CM6HGx9q7zA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=hsJYJ3K1t/+6DtPfi3X9qbZNFRWITsG+zMMRj1pga8zFeF/hmQU7xzuvMk+4+fLaM APjYnuLhVcsgn+TTXt9cQ== Received: from pvc7 (pvc7.prod.google.com [10.241.209.135]) by hpaq13.eem.corp.google.com with ESMTP id o6DKuERD009546 for ; Tue, 13 Jul 2010 13:56:14 -0700 Received: by pvc7 with SMTP id 7so2779775pvc.33 for ; Tue, 13 Jul 2010 13:56:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.185.9 with SMTP id i9mr6351245wff.206.1279054573631; Tue, 13 Jul 2010 13:56:13 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Tue, 13 Jul 2010 13:56:13 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 13:56:13 -0700 Message-ID: From: Brian Eaton To: Andrew Arnott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth Subject: Re: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 20:56:08 -0000 On Tue, Jul 13, 2010 at 1:46 PM, Andrew Arnott wro= te: > Ah, got it. =A0Yes, we're on the same page. > I happen to store the authorization tuple (mentioned in another thread) > rather than the refresh token itself. =A0That way I can issue an arbitrar= y > number of refresh tokens for the same client/user/scope/issued_date set > without storing any extra data in the database, but I can still support > revocations by deleting the standing authorization from the db. =A0Obviou= sly, > each time a refresh token is received, its corresponding tuple in the tab= le > is checked to be present to detect revocations. That's a reasonable design trade-off... One possible issue there is compromise of the token database. If a token database leaks for any reason, all of the refresh tokens would have to be revoked. If you stored a one-way hash of the tokens instead, compromise of the token database would be less dangerous. (Note that this depends how the database was compromised, of course...) From john@jkemp.net Tue Jul 13 14:05:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8873A69F9 for ; Tue, 13 Jul 2010 14:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3teHz9XEkcPR for ; Tue, 13 Jul 2010 14:05:19 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id C0EF63A69F1 for ; Tue, 13 Jul 2010 14:05:19 -0700 (PDT) Received: (qmail 10654 invoked by uid 0); 13 Jul 2010 21:05:29 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy3.bluehost.com with SMTP; 13 Jul 2010 21:05:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=0fQ7dQRy8zG1OHErxkBO1JX3pSNIIvhba/xiocGihBtcrNvZI4nfB5WkE7nT8HuSylUEbqqibdkT7nJBiObqOZfi/OXaofBMOQ2u01AOI1SohpNS+ZGQjUYeDr3KgC/A; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.112]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OYmfQ-0002LI-JV; Tue, 13 Jul 2010 15:05:28 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: John Kemp In-Reply-To: Date: Tue, 13 Jul 2010 17:05:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <97BD2762-F147-4774-9557-AD478338B348@jkemp.net> <93F20A70-3133-4C5A-BE15-9C85F1D42787@jkemp.net> To: Blaine Cook X-Mailer: Apple Mail (2.1081) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 21:05:20 -0000 On Jul 13, 2010, at 4:06 PM, Blaine Cook wrote: > On 13 July 2010 20:31, John Kemp wrote: >> Where is that specified? Is that required for all implementations? >=20 > It's not specified - I was referring to your earlier comments: >=20 >> In the "bearer token" case (and even over SSL unless client certs are = used), the >> token clearly SHOULD NOT be used as a password. Rather, = authentication should >> be performed by some other mechanism, unrelated to the token itself = (such as an >> HMAC, or via client-certificate SSL/TLS, or even via an actual = username/password) >=20 >> I would be very unhappy if we equated access tokens with passwords. >=20 > The token is never used as the authentication mechanism (i.e., the > mechanism to authenticate the user), except in schemes where it > explicitly makes sense (e.g., UMA as I understand it, Twitter's OAuth > Echo, etc). So there's no concern about that. >=20 > What I was trying to say, and I'm just re-iterating Eran's comments > here, is that once issued [in the context of a request made by an > authenticated user that grants authorization to the OAuth client], the > token will be used de-facto as a password, passphrase, shared secret, > or whatever we want to call it. By calling it a "capability", we don't > signal to implementors what the security implications are, and what > they can do to avoid disappointment. By using the word "password" to apply to the token itself you are = suggesting that the token is the authenticator for the request, which = may or may not be true. And you are tying in to a rich history of what a = "password" means, which is not necessarily how the token will be used, = particularly if some other means of authenticating the requester is used = _in addition to_ the bearer token being used to authorize the request. =20 >=20 >> A capability, basically, is a reference to an object and the = permission to use it, bound together. Possession of the capability is = enough to authorize the use of the reference. Bearer tokens follow = roughly that model. They are about authorization and MAY be used alone = for authentication, but may also be used with (specified, or not, in = OAuth) other mechanisms for authentication. At least I hope that is the = model (not to *require* servers to authenticate using the bearer token = alone even if *some* implementations do that)? >=20 > It's unclear what you mean is being authenticated by the server =96 do > you mean the user, or the client, or something else? Which thing do you think the bearer token is a password for? I think the bearer token is used by the server to authorize access by = the requester. It MAY be used as an authenticator for the requester.... = but it may not (or not alone) > This question is > persistent and points to exactly the kind of confusion I think Eran is > correct to try to avoid by simply calling the token password-like. "Password-like", in some circumstances, but not a password. In OAuth, as = I understand it, the token is used to authorize the request. = Authenticating the request is then out of scope for OAuth proper, but = various authentication methods for the client may be used in conjunction = with the use of the token, including allowing the token to act as a = "password" for the client.=20 > If > we use language that clearly indicates to developers that "with the > clear-text token, requests can be made [modulo reduced permissions] as > though they were made by someone in possession of the user's username > and password. Don't leak it, and treat it as though it were a > password", then we avoid having to explain (embarrassingly) that the > "capability" actually meant something like "password". You see the bearer token as being a password for the user? Or should it = simply be protected in the same ways that one would protect a user's = password -- in other words, document the security considerations of = tokens in detail (stored securely, not passed in cleartext etc.) rather = than using a single word to indicate something which may or may not be = accurate, and is certainly not wholly descriptive. - johnk From igor.faynberg@alcatel-lucent.com Tue Jul 13 14:05:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C020A3A6A45 for ; Tue, 13 Jul 2010 14:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 L8ce6lU+FAxy for ; Tue, 13 Jul 2010 14:05:21 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 526243A69F1 for ; Tue, 13 Jul 2010 14:05:21 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o6DL5PYK003869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jul 2010 16:05:25 -0500 (CDT) Received: from [135.244.39.28] (faynberg.lra.lucent.com [135.244.39.28]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o6DL5OkY026006; Tue, 13 Jul 2010 16:05:24 -0500 (CDT) Message-ID: <4C3CD51C.7050405@alcatel-lucent.com> Date: Tue, 13 Jul 2010 17:05:32 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian Eaton References: <97BD2762-F147-4774-9557-AD478338B348@jkemp.net> <93F20A70-3133-4C5A-BE15-9C85F1D42787@jkemp.net> <4C3CCF58.6010102@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" 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: Tue, 13 Jul 2010 21:05:22 -0000 YES!!! Brian, could you please add this? Igor Brian Eaton wrote: > On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg > wrote: > >> In this case, the term "capability" MUST be defined up front. The word >> "capability" seems to carry a much broader meaning than password... >> > > It has a standard definition we can reference. From > http://www.ietf.org/rfc/rfc2828.txt > > $ capability > (I) A token, usually an unforgeable data value (sometimes called a > "ticket") that gives the bearer or holder the right to access a > system resource. Possession of the token is accepted by a system > as proof that the holder has been authorized to access the > resource named or indicated by the token. (See: access control > list, credential, digital certificate.) > > (C) This concept can be implemented as a digital certificate. > (See: attribute certificate.) > From andrewarnott@gmail.com Tue Jul 13 14:05:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA223A69F9 for ; Tue, 13 Jul 2010 14:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.766, 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 kWS6SwuIADpx for ; Tue, 13 Jul 2010 14:05:35 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id C6BAF3A69F1 for ; Tue, 13 Jul 2010 14:05:35 -0700 (PDT) Received: by gyh3 with SMTP id 3so3864390gyh.31 for ; Tue, 13 Jul 2010 14:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=AIcW3DIY41OS1AnbNrkRHDVFFU8K+8nZgcirH738XSo=; b=gNHxlducvJtPxDm6i3POpfCA5I3ubs8vMHSWyC050+7btUNCHD+F/V+eoI0sX2DBTv sVkkSe4P1qw53tSfOGi5jERs3XX0lGTq8eausMkW6kiMLIMZWvNIfK/9w8SD45iKfA1w k7rOnJRuCQbrek4frpp6CspQSJpIf2HX3NmkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=KIiG+yOs28fJYnyGxFnMt7rZZ5jGAH/wlw8mX5z1Uj76HBVotS/9VrPeZKM8GKvJA0 oYH01uelgn0qmlN6sJee9RJ2df9kFv1+DZmgBnQT42fRQvH9dcOwQkSEmbdX8SImoafk Pl3Mr6AvDZdUCnVjbxHHPP1la71EHTj22VME0= Received: by 10.151.116.1 with SMTP id t1mr6840532ybm.329.1279055140361; Tue, 13 Jul 2010 14:05:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.92.8 with HTTP; Tue, 13 Jul 2010 14:05:20 -0700 (PDT) In-Reply-To: References: From: Andrew Arnott Date: Tue, 13 Jul 2010 14:05:20 -0700 Message-ID: To: Brian Eaton Content-Type: multipart/alternative; boundary=001e680f13b84a73c7048b4b3ba8 Cc: oauth Subject: Re: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 21:05:37 -0000 --001e680f13b84a73c7048b4b3ba8 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 13, 2010 at 1:56 PM, Brian Eaton wrote: > On Tue, Jul 13, 2010 at 1:46 PM, Andrew Arnott > wrote: > > Ah, got it. Yes, we're on the same page. > > I happen to store the authorization tuple (mentioned in another thread) > > rather than the refresh token itself. That way I can issue an arbitrary > > number of refresh tokens for the same client/user/scope/issued_date set > > without storing any extra data in the database, but I can still support > > revocations by deleting the standing authorization from the db. > Obviously, > > each time a refresh token is received, its corresponding tuple in the > table > > is checked to be present to detect revocations. > > That's a reasonable design trade-off... > > One possible issue there is compromise of the token database. If a > token database leaks for any reason, all of the refresh tokens would > have to be revoked. > > If you stored a one-way hash of the tokens instead, compromise of the > token database would be less dangerous. (Note that this depends how > the database was compromised, of course...) > I'm not storing tokens at all. And a compromise of the database wouldn't expose any tokens or their hashes. I'm only storing that user/client/scope/issued_date tuple -- not the token itself. --001e680f13b84a73c7048b4b3ba8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 13, 2010 at 1:56 PM, Brian Eaton <beaton@google.com> wrote:
On Tue, Jul 13, 2010 at 1:46 PM, Andrew Arnott <andrewarnott@gmail.com> wrote: > Ah, got it. =A0Yes, we're on the same page.
> I happen to store the authorization tuple (mentioned in another thread= )
> rather than the refresh token itself. =A0That way I can issue an arbit= rary
> number of refresh tokens for the same client/user/scope/issued_date se= t
> without storing any extra data in the database, but I can still suppor= t
> revocations by deleting the standing authorization from the db. =A0Obv= iously,
> each time a refresh token is received, its corresponding tuple in the = table
> is checked to be present to detect revocations.

That's a reasonable design trade-off...

One possible issue there is compromise of the token database. =A0If a
token database leaks for any reason, all of the refresh tokens would
have to be revoked.

If you stored a one-way hash of the tokens instead, compromise of the
token database would be less dangerous. =A0(Note that this depends how
the database was compromised, of course...)

I'm not storing tokens at all. =A0And a com= promise of the database wouldn't expose any tokens or their hashes. =A0= I'm only storing that user/client/scope/issued_date tuple -- not the to= ken itself.=A0
--001e680f13b84a73c7048b4b3ba8-- From eran@hueniverse.com Tue Jul 13 14:06:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B19E3A69F9 for ; Tue, 13 Jul 2010 14:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=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 V74epIg4MKxk for ; Tue, 13 Jul 2010 14:06:25 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 51F433A69F1 for ; Tue, 13 Jul 2010 14:06:25 -0700 (PDT) Received: (qmail 6498 invoked from network); 13 Jul 2010 21:06:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 21:06:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 13 Jul 2010 14:06:20 -0700 From: Eran Hammer-Lahav To: Brian Eaton , OAuth WG Date: Tue, 13 Jul 2010 14:06:17 -0700 Thread-Topic: [OAUTH-WG] user-agent flow needs a rewrite Thread-Index: AcsgrN8i8iqpLUyyShyLnR6W/frLfACIlzV9 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C862235A371F8eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 21:06:36 -0000 --_000_C862235A371F8eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This looks reasonable, however, I am no longer see the value in the hybrid = mode of token and code. If the code is passed in the fragment, the client h= as to pass it to the server. If that is the case, why can't the server repl= y back with the access token? Is the entire purpose just a performance opti= mization so the client doesn't have to wait for the server response before = it has an access token? EHL On 7/10/10 8:55 PM, "Brian Eaton" wrote: The draft 9 spec has no efficient way for a javascript client to request a verification code. The spec creates extra client-to-server round trips. There is also some inaccurate description of the properties of the profile. The problems are located in section 1.4.2: http://tools.ietf.org/html/draft-ietf-oauth-v2-09#page-11. The spec requires that the verification code is always returned on the query string. This ends up busting the browser cache and creating an extra client-to-server round trip. It basically defeats the purpose of the user-agent profile entirely. (If you could afford an extra client-to-server round trip, you would just use the web server flow.) To clarify, here's how the flow works in practice: client web site loads relay page is loaded from the client web site. This page is typically heavily cached. It is almost always loaded from browser cache; it is very rarely actually fetched from the server, for performance reasons. client web site redirects browser to authorization server authorization server redirects back to relay page, with new data on the fra= gment there is no client-to-server round trip*. the client javascript is loaded from cache, and parses the fragment data if necessary, the client javascript uses XMLHttpRequest (XHR) to pass data up to the web server. This typically happens in the background, however, while the user is otherwise interacting with the web application. Here's what would happen if someone implemented the spec as written, though= : client web site loads relay page is loaded from the client web site. This page is typically heavily cached. It is almost always loaded from browser cache; it is very rarely actually fetched from the server, for performance reasons. client web site redirects browser to authorization server authorization server redirects back to relay page, with new data on the fragment, *plus a verification code on the query string* *browser fetches new copy of relay page from web server* *user sits and waits* *kittens die when users have to wait* There are also several problems with the description of the flow. Most of the description seems to be left over from the time when the flow was spec'ed to only return an access token. Now that it can return a verification code, sentences like "does not utilize the client secret" are no longer true. The phrase "because the access token is encoded into the redirection URI, it may be exposed to the end-user and other applications residing on the computer" is just silly. That's equally true of the web server flow. So basically I think section 1.4.2 needs a rewrite, starting with the entire justification of the flow. Here's a brief description of how the flow should work: client web site loads client redirects to authorization server with: type=3D"user_agent" client_id=3Dclient identifier redirect_uri=3Dabsolute URL on client web site response_type=3D"code-and-token" or "token" (The client chooses the response type based on whether they want long-lived access or short-lived access to the user's data. Short-lived: just use "token".) authorization server confirms user consent (which might or might not require user interaction...) authorization server confirms redirect_uri is associated with the client_id= . authorization server redirects to redirect_uri, with all of the return parameters on the URL fragment. Here's my proposed text for section 1.4.2. The user-agent profile is suitable for client applications residing in a user-agent, typically implemented in a browser using a scripting language such as JavaScript. These clients typically have strict latency requirements, and must be implemented using a minimum number of client-to-server calls. The client may have supporting code running on a web server. Authentication of the client-side components is based on the redirect URI and the user-agent's same-origin policy. Authentication of the server-side components is based on the client secret. Unlike other profiles, the user-agent profile returns data on the client on the URI fragment. In addition, the user-agent profile returns an access token directly on the redirect URI, to reduce the number of round trips required before the client can use the token. The client is able to immediately use the token to communicate to resource servers, using client-side cross-domain communication techniques such as window.postMessage, jsonp, and iframes. [Maybe just mention iframes here, better not to clutter the spec with references to all of the ways around same-origin...) Figure 5: this probably needs to change so that it looks more like Figure 4. Changes from Figure 4 would be: Step (C) returns access token and optional verification code New step (D): client using the access token directly with a resource server= . Old step D becomes step E, but otherwise looks the same. Except it is opti= onal. Step E: if this step occurs, refresh token is no longer optional More normative language (largely based on merging the user-agent language with the web-server language.) The user-agent flow illustrated in Figure 5 includes the following steps: (A) [no change] The clients sends the user-agent to the end-user authorization endpoint as described in section 3. The client includes its client identifier, requested scope, local state, and a redirect URI to which the authorization server will send the end-user back once authorization is granted. (B) [no change] (C) If the end-user granted access, the authorization server redirects the user-agent to the redirection URI provided earlier. The redirection URI includes the access token, and optional verification code, in the URI fragment. (D) The user-agent follows the redirection instructions by loading the redirection URI. The redirection URI is typically a heavily cached web page, so this is unlikely to result in an additional client to server round trip. (E) The client code parses the URL fragment to retrieve the access token and optional authorization code. (F) The client uses the access token to contact resource servers. (G) In parallel, the client passes the authorization code to the client's server side components. (H) The client's server-side components request an access token and refresh token from the authorization server by authenticating and including the authorization code received in the previous step. (I) The authorization server validates the client credentials and the authorization code and responds back with the refresh token and access token. Rest of the spec doesn't look like it needs to change much. Section 4.1.1. "Authorization Code" needs some modifications to make it clear that the redirect_uri sent to the authorization server MUST include any fragment included on the original authorization request. redirect_uri REQUIRED. The redirection URI used in the initial request. If the client included a URI fragment on the redirect_uri sent to the authorization server on the authorization request, the client MUST include the same URI fragment here. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C862235A371F8eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] user-agent flow needs a rewrite This looks reasonable, however, I am no longer see the value in the h= ybrid mode of token and code. If the code is passed in the fragment, the cl= ient has to pass it to the server. If that is the case, why can’t the= server reply back with the access token? Is the entire purpose just a perf= ormance optimization so the client doesn’t have to wait for the serve= r response before it has an access token?

EHL


On 7/10/10 8:55 PM, "Brian Eaton" <beaton@google.com> wrote:

The draft 9 spec has no efficient way for a= javascript client to
request a verification code.  The spec creates extra client-to-server<= BR> round trips.  There is also some inaccurate description of the
properties of the profile.  The problems are located in section 1.4.2:=
http:= //tools.ietf.org/html/draft-ietf-oauth-v2-09#page-11.

The spec requires that the verification code is always returned on the
query string.  This ends up busting the browser cache and creating an<= BR> extra client-to-server round trip.  It basically defeats the purpose of the user-agent profile entirely.  (If you could afford an extra
client-to-server round trip, you would just use the web server flow.)
To clarify, here's how the flow works in practice:

client web site loads
relay page is loaded from the client web site.  This page is typically=
heavily cached.  It is almost always loaded from browser cache; it is<= BR> very rarely actually fetched from the server, for performance reasons.
client web site redirects browser to authorization server
authorization server redirects back to relay page, with new data on the fra= gment
there is no client-to-server round trip*.  the client javascript is loaded from cache, and parses the fragment data
if necessary, the client javascript uses XMLHttpRequest (XHR) to pass
data up to the web server.  This typically happens in the background,<= BR> however, while the user is otherwise interacting with the web
application.

Here's what would happen if someone implemented the spec as written, though= :

client web site loads
relay page is loaded from the client web site.  This page is typically=
heavily cached.  It is almost always loaded from browser cache; it is<= BR> very rarely actually fetched from the server, for performance reasons.
client web site redirects browser to authorization server
authorization server redirects back to relay page, with new data on
the fragment, *plus a verification code on the query string*
*browser fetches new copy of relay page from web server*
*user sits and waits*
*kittens die when users have to wait*


There are also several problems with the description of the flow.
Most of the description seems to be left over from the time when the
flow was spec'ed to only return an access token.  Now that it can
return a verification code, sentences like "does not utilize the
client secret" are no longer true.

The phrase "because the access token is encoded into the redirection URI, it may be exposed to the end-user and other applications residing
on the computer" is just silly.  That's equally true of the web s= erver
flow.

So basically I think section 1.4.2 needs a rewrite, starting with the
entire justification of the flow.

Here's a brief description of how the flow should work:

client web site loads
client redirects to authorization server with:
   type=3D"user_agent"
   client_id=3Dclient identifier
   redirect_uri=3Dabsolute URL on client web site
   response_type=3D"code-and-token" or "token= "  (The client chooses the
response type based on whether they want long-lived access or
short-lived access to the user's data.  Short-lived: just use
"token".)

authorization server confirms user consent (which might or might not
require user interaction...)
authorization server confirms redirect_uri is associated with the client_id= .
authorization server redirects to redirect_uri, with all of the return
parameters on the URL fragment.

Here's my proposed text for section 1.4.2.

The user-agent profile is suitable for client applications residing in
a user-agent, typically implemented in a browser using a scripting
language such as JavaScript.  These clients typically have strict
latency requirements, and must be implemented using a minimum number
of client-to-server calls.  The client may have supporting code
running on a web server.  Authentication of the client-side components=
is based on the redirect URI and the user-agent's same-origin policy.
Authentication of the server-side components is based on the client
secret.

Unlike other profiles, the user-agent profile returns data on the
client on the URI fragment.  In addition, the user-agent profile
returns an access token directly on the redirect URI, to reduce the
number of round trips required before the client can use the token.
The client is able to immediately use the token to communicate to
resource servers, using client-side cross-domain communication
techniques such as window.postMessage, jsonp, and iframes.  [Maybe
just mention iframes here, better not to clutter the spec with
references to all of the ways around same-origin...)

Figure 5: this probably needs to change so that it looks more like
Figure 4.  Changes from Figure 4 would be:

Step (C) returns access token and optional verification code

New step (D): client using the access token directly with a resource server= .

Old step D becomes step E, but otherwise looks the same.  Except it is= optional.

Step E: if this step occurs, refresh token is no longer optional


More normative language (largely based on merging the user-agent
language with the web-server language.)

The user-agent flow illustrated in Figure 5 includes the following steps:
(A) [no change] The clients sends the user-agent to the end-user
authorization endpoint as described in section 3.  The client includes=
its client identifier, requested scope, local state, and a redirect
URI to which the authorization server will send the end-user back once
authorization is granted.

(B) [no change]

(C) If the end-user granted access, the authorization server redirects
the user-agent to the redirection URI provided earlier.  The
redirection URI includes the access token, and optional verification
code, in the URI fragment.

(D) The user-agent follows the redirection instructions by loading the
redirection URI.  The redirection URI is typically a heavily cached web page, so this is unlikely to result in an additional client to
server round trip.

(E) The client code parses the URL fragment to retrieve the access
token and optional authorization code.

(F) The client uses the access token to contact resource servers.

(G) In parallel, the client passes the authorization code to the
client's server side components.

(H) The client's server-side components request an access token and
refresh token from the authorization server by authenticating and
including the authorization code received in the previous step.

(I) The authorization server validates the client credentials and the
authorization code and responds back with the refresh token and access
token.


Rest of the spec doesn't look like it needs to change much.

Section 4.1.1.  "Authorization Code" needs some modification= s to make
it clear that the redirect_uri sent to the authorization server MUST
include any fragment included on the original authorization request.

redirect_uri
         REQUIRED.  The r= edirection URI used in the initial request.
If the client included a URI fragment on the redirect_uri sent to the
authorization server on the authorization request, the client MUST
include the same URI fragment here.


Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C862235A371F8eranhueniversecom_-- From naitiks@gmail.com Tue Jul 13 14:28:08 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B4FC3A67FC for ; Tue, 13 Jul 2010 14:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdPdrUJOdwt1 for ; Tue, 13 Jul 2010 14:28:07 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2CA573A67F7 for ; Tue, 13 Jul 2010 14:28:07 -0700 (PDT) Received: by iwn38 with SMTP id 38so6546858iwn.31 for ; Tue, 13 Jul 2010 14:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=0oPMcd4XXRK8Way+Vt9ZwIwXc3c1hVytFplKiD09pDE=; b=ZuZTw+RoXU7Pvkc8MuUmelAaJlL0mXy6Vx6QRqm437BsBkkC7bvw8XPohWYl0ZL73t jB8QU7cTXPgDUCBDsxImf1h8WJbkFjqF10AG7Pss+kgMLH/lLpTFe4oHFQQW0urTLSsu kQDyas2mciP3fM4qm8F6gS1fxaP59VVTmzefw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=OT5bN1cUf2EafHVsJkyNWEq2bS7beSDitn0CMWM1mmbC8nT/q/6gHxLK8tDGPRwTmX 6cbETRPIKX55l10kXCVXDdIUf2F4iY4FkG+tH1+TNUIS6GL8wczFVm0TTYdZA5UNnkbt grRmPqb0nJ7efee9RU3FmttuOGYK5Zswlvgx8= Received: by 10.42.1.12 with SMTP id 12mr5256565ice.78.1279056496170; Tue, 13 Jul 2010 14:28:16 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.231.159.193 with HTTP; Tue, 13 Jul 2010 14:27:56 -0700 (PDT) In-Reply-To: References: From: Naitik Shah Date: Tue, 13 Jul 2010 14:27:56 -0700 X-Google-Sender-Auth: sIKYFbFUX6kys7IgfoPojodtecU Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=90e6ba1818821a1600048b4b8c8a Cc: OAuth WG Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 21:28:08 -0000 --90e6ba1818821a1600048b4b8c8a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 13, 2010 at 2:06 PM, Eran Hammer-Lahav wro= te: > This looks reasonable, however, I am no longer see the value in the > hybrid mode of token and code. If the code is passed in the fragment, the > client has to pass it to the server. If that is the case, why can=E2=80= =99t the > server reply back with the access token? Is the entire purpose just a > performance optimization so the client doesn=E2=80=99t have to wait for t= he server > response before it has an access token? > > I think there are two use cases here, and they are not mutually exclusive. Some apps are mostly just server side, and would end up doing a full page refresh, and here the code in the query param would probably be acceptable. Some apps are mostly just client side, and here the code is irrelevant and the access token in the fragment is all that matters. But we also have hybrids where we want the code in a cookie/JS callback, and we'll also use the access token on the client to dynamically update the UI by accessing some protected data (this is what the Data enabled XFBML tags do in the Facebook JS SDK for instance). While the server can do the code to access_token exchange, it can't return it to the JS safely if it does not support https. Even if it did, it would mean more overhead for the develope= r to build an endpoint that does this work and cooperates with a JS SDK which wants the access_token for making API calls. -Naitik --90e6ba1818821a1600048b4b8c8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 13, 2010 at 2:06 PM, Eran Hammer-Lah= av <eran@hueniv= erse.com> wrote:
This looks reasonable, however, I am no longer see the value in the h= ybrid mode of token and code. If the code is passed in the fragment, the cl= ient has to pass it to the server. If that is the case, why can=E2=80=99t t= he server reply back with the access token? Is the entire purpose just a pe= rformance optimization so the client doesn=E2=80=99t have to wait for the s= erver response before it has an access token?


I think there are two use cases here, and they are not mutually exclu= sive. Some apps are mostly just server side, and would end up doing a full = page refresh, and here the code in the query param would probably be accept= able. Some apps are mostly just client side, and here the code is irrelevan= t and the access token in the fragment is all that matters. But we also hav= e hybrids where we want the code in a cookie/JS callback, and we'll als= o use the access token on the client to=C2=A0dynamically=C2=A0update the UI= by accessing some protected data (this is what the Data enabled XFBML tags= do in the Facebook JS SDK for instance). While the server can do the code = to access_token exchange, it can't return it to the JS safely if it doe= s not support https. Even if it did, it would mean more overhead for the de= veloper to build an endpoint that does this work and cooperates with a JS S= DK which wants the access_token for making API calls.


-Naitik

--90e6ba1818821a1600048b4b8c8a-- From eran@hueniverse.com Tue Jul 13 14:33: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 037053A69F0 for ; Tue, 13 Jul 2010 14:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.135, 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 otlHa5p6DygN for ; Tue, 13 Jul 2010 14:33:32 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id BE01A3A6405 for ; Tue, 13 Jul 2010 14:33:32 -0700 (PDT) Received: (qmail 28812 invoked from network); 13 Jul 2010 21:33:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 21:33:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 13 Jul 2010 14:33:37 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Tue, 13 Jul 2010 14:33:35 -0700 Thread-Topic: [OAUTH-WG] "shared symmetric secret" Thread-Index: AcsizyIgPZ5pukpWRt6lfGldShDB+wAA+os5 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C86229BF37200eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 21:33:38 -0000 --_000_C86229BF37200eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is how OAuth works: The client wants to access a protected resource. T= he resource requires authentication (that's the definition of protected). T= he client presents the access token to authenticate (using an HTTP authenti= cation header). The access token has all the security characteristics of a = password: - Opaque to the client - just a string - Client must store it in a way that provides access to the clear-text toke= n - Anyone holding the token can access - the bearer of the token is consider= ed its rightful owner - The token can be leaked or phished - which is sufficient for full access I don't care much about the philosophical debate (authentication vs authori= zation) as I don't think it adds much value here. When it comes to using an= access token, the client uses it just like a password, it serves as the au= thentication construct, and it has all the same problems passwords have. I do recognize that unlike users' passwords, the tokens are not bound to a = person's memory and therefore can be longer, short-lived, and client-specif= ic which is an improvement over users' passwords. But that's just an implem= entation detail. There is little in the protocol today that enforces this. My assumption is that for the most part, OAuth 2.0 will be used without any= additional authentication. For example, my employer (whom I do not represe= nts here in any way) intends to use access tokens over plain HTTP without S= SL/TLS (current BBAuth deployment). As soon as we add discovery, bearer token phishing will become an issue - m= ark my words. This is why I find bearer tokens so offensive (I consider dis= covery a required feature) - but I have lost that battle. All I can do now = is use my editorial capacity to warn readers of what they are dealing with = *in practice*, and in practice, bearer tokens are used just like passwords. -- Either way, this is the new text: Clients access protected resources by presenting an access token to= the resource server. Access tokens are bearer authentication tokens, such as passwords o= r capabilities (as defined by RFC2828). This requires treating the access token with t= he same care as other passwords. Access tokens SHOULD NOT be sent in t= he clear over an insecure channel. EHL --_000_C86229BF37200eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] "shared symmetric secret" This is how OAuth works: The client wants to access a protected resou= rce. The resource requires authentication (that’s the definition of p= rotected). The client presents the access token to authenticate (using an H= TTP authentication header). The access token has all the security character= istics of a password:

- Opaque to the client – just a string
- Client must store it in a way that provides access to the clear-text toke= n
- Anyone holding the token can access – the bearer of the token is co= nsidered its rightful owner
- The token can be leaked or phished – which is sufficient for full a= ccess

I don’t care much about the philosophical debate (authentication vs a= uthorization) as I don’t think it adds much value here. When it comes= to using an access token, the client uses it just like a password, it serv= es as the authentication construct, and it has all the same problems passwo= rds have.

I do recognize that unlike users’ passwords, the tokens are not bound= to a person’s memory and therefore can be longer, short-lived, and c= lient-specific which is an improvement over users’ passwords. But tha= t’s just an implementation detail. There is little in the protocol to= day that enforces this.

My assumption is that for the most part, OAuth 2.0 will be used without any= additional authentication. For example, my employer (whom I do not represe= nts here in any way) intends to use access tokens over plain HTTP without S= SL/TLS (current BBAuth deployment).

As soon as we add discovery, bearer token phishing will become an issue = 211; mark my words. This is why I find bearer tokens so offensive (I consid= er discovery a required feature) – but I have lost that battle. All I= can do now is use my editorial capacity to warn readers of what they are d= ealing with *in practice*, and in practice, bearer tokens are used just lik= e passwords.

--

Either way, this is the new text:

        Clients access protected re= sources by presenting an access token to the resource server.
        Access tokens are bearer au= thentication tokens, such as passwords or capabilities (as
        defined by RFC2828). This r= equires treating the access token with the
        same care as other password= s. Access tokens SHOULD NOT be sent in the clear over an
        insecure channel.


EHL

 --_000_C86229BF37200eranhueniversecom_-- From beaton@google.com Tue Jul 13 14:59:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90163A69C3 for ; Tue, 13 Jul 2010 14:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.851 X-Spam-Level: X-Spam-Status: No, score=-101.851 tagged_above=-999 required=5 tests=[AWL=0.126, 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 jRpBKjNyZ2Zl for ; Tue, 13 Jul 2010 14:59:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D341E3A6833 for ; Tue, 13 Jul 2010 14:59:19 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o6DLxRil013847 for ; Tue, 13 Jul 2010 14:59:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279058368; bh=YUJTFQTuGuHFKrdO1f7vTc0p6B8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Svp6yWU7+HUIq6oohkS+e2tn3bYp8DOCvr9c87kLIRHsae7SLXjixMu/JRRWsVZnA G5MIkuqNAxbll0EwZuY/w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=alimzJVmlnwq/afLmvOs1Aign9hFGkdwwz+pNqhlGs1puNXauUYxMrseDhBWSuZRf v+oU2L+4HLs8ow/IcDHbw== Received: from pxi11 (pxi11.prod.google.com [10.243.27.11]) by wpaz33.hot.corp.google.com with ESMTP id o6DLxQG5023532 for ; Tue, 13 Jul 2010 14:59:26 -0700 Received: by pxi11 with SMTP id 11so2806766pxi.7 for ; Tue, 13 Jul 2010 14:59:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.140.18 with SMTP id n18mr19432928wfd.342.1279058366079; Tue, 13 Jul 2010 14:59:26 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Tue, 13 Jul 2010 14:59:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 14:59:25 -0700 Message-ID: From: Brian Eaton To: Andrew Arnott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth Subject: Re: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 21:59:20 -0000 On Tue, Jul 13, 2010 at 2:05 PM, Andrew Arnott wro= te: > I'm not storing tokens at all. =A0And a compromise of the database wouldn= 't > expose any tokens or their hashes. =A0I'm only storing that > user/client/scope/issued_date tuple -- not the token itself. And a signing key. So the question is what happens if both the signing key and the token database get compromised. Now that I think of it, you may have issues if the signing key alone is compromised. It depends how much other entropy you've added to the tokens... From eran@hueniverse.com Tue Jul 13 15:00: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 34C123A69E5 for ; Tue, 13 Jul 2010 15:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 vj7Q8lMv9nb3 for ; Tue, 13 Jul 2010 15:00:33 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 4E56E3A69C3 for ; Tue, 13 Jul 2010 15:00:33 -0700 (PDT) Received: (qmail 10647 invoked from network); 13 Jul 2010 22:00:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 22:00:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 13 Jul 2010 15:00:42 -0700 From: Eran Hammer-Lahav To: Naitik Shah Date: Tue, 13 Jul 2010 15:00:39 -0700 Thread-Topic: [OAUTH-WG] user-agent flow needs a rewrite Thread-Index: Acsi0lBfPvcSgCPlQgi6FSh1zO2JwgABIPr+ Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 22:00:34 -0000 This is clearly a third flow - hybrid (of user-agent and web-server) - and not just a variant of the user-agent flow. It should be presented with its own flow diagram and description. I also think the user-agent and web-serve= r flow names are misleading. They need to be replaced with more descriptive names. Something like (I don=B9t like these, just trying to demonstrate): Web-server --> 2 step flow (get code, get token) User-agent --> direct flow (get token) Hybrid --> hybrid flow (get code and token, get token) In an attempt to accommodate Brian's request for more concentrated flow descriptions, I am working on coming up with come middle ground between -05 and -10. ---- As for the specification of the end-user authorization endpoint: Please answer this based on actual use cases. When returning parameters using the redirection URI call, which of these combinations make sense? | Code | Token | Code & Token ---------+------+-------+-------------- Fragment | a | 1 | 3 Query | 2 | b | c Split* | n/a | n/a | d * token in fragment, code in query Known use cases: 1 - current user-agent flow 2 - current web-server flow 3 - as described by Brian and Naitik Questionable use cases: a -=20 b - c -=20 d - current -10 code-and-token proposal EHL On 7/13/10 2:27 PM, "Naitik Shah" wrote: > On Tue, Jul 13, 2010 at 2:06 PM, Eran Hammer-Lahav > wrote: >> This looks reasonable, however, I am no longer see the value in the hybr= id >> mode of token and code. If the code is passed in the fragment, the clien= t has >> to pass it to the server. If that is the case, why can=B9t the server re= ply >> back with the access token? Is the entire purpose just a performance >> optimization so the client doesn=B9t have to wait for the server respons= e >> before it has an access token? >>=20 >=20 > I think there are two use cases here, and they are not mutually exclusive= . > Some apps are mostly just server side, and would end up doing a full page > refresh, and here the code in the query param would probably be acceptabl= e. > Some apps are mostly just client side, and here the code is irrelevant an= d the > access token in the fragment is all that matters. But we also have hybrid= s > where we want the code in a cookie/JS callback, and we'll also use the ac= cess > token on the client to=A0dynamically=A0update the UI by accessing some pr= otected > data (this is what the Data enabled XFBML tags do in the Facebook JS SDK = for > instance). While the server can do the code to access_token exchange, it = can't > return it to the JS safely if it does not support https. Even if it did, = it > would mean more overhead for the developer to build an endpoint that does= this > work and cooperates with a JS SDK which wants the access_token for making= API > calls. >=20 >=20 > -Naitik >=20 >=20 From beaton@google.com Tue Jul 13 15:06:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F543A69FF for ; Tue, 13 Jul 2010 15:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.713 X-Spam-Level: X-Spam-Status: No, score=-105.713 tagged_above=-999 required=5 tests=[AWL=0.264, 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 cdH8FmIt1Ebw for ; Tue, 13 Jul 2010 15:06:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8127D3A67D7 for ; Tue, 13 Jul 2010 15:06:16 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id o6DM6PfQ021118 for ; Tue, 13 Jul 2010 15:06:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279058785; bh=xd6GJea1ZFHEplMfp1T7KN2kwAY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=bcL5a1hZo7I0B0O1f2Q3T7RmFgE/7zBLaxHzpvK4PuoFzWAVr+wgtX8jkpbGSPcgi /3bdY7f3Wz9pYhVRTZVQw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=rWf9viBFRxXJjIphPz0LItIc49K/sxTeOJ8A3imOeLS7MJ5cK4B3y8LTDDIyrAXDD mtWs8ZxnJQGwZ5SctTnHA== Received: from pwj9 (pwj9.prod.google.com [10.241.219.73]) by wpaz1.hot.corp.google.com with ESMTP id o6DM6Oru032741 for ; Tue, 13 Jul 2010 15:06:24 -0700 Received: by pwj9 with SMTP id 9so2737095pwj.13 for ; Tue, 13 Jul 2010 15:06:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.142.15 with SMTP id p15mr16216589wfd.207.1279058783835; Tue, 13 Jul 2010 15:06:23 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Tue, 13 Jul 2010 15:06:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 15:06:23 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 22:06:17 -0000 On Tue, Jul 13, 2010 at 3:00 PM, Eran Hammer-Lahav wrote: > In an attempt to accommodate Brian's request for more concentrated flow > descriptions, I am working on coming up with come middle ground between -05 > and -10. Thank you! From zachary.zeltsan@alcatel-lucent.com Tue Jul 13 15:20:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF893A69E5 for ; Tue, 13 Jul 2010 15:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1hrZGHZurPu for ; Tue, 13 Jul 2010 15:20:37 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 617303A6833 for ; Tue, 13 Jul 2010 15:20:36 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o6DMKdhK001972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jul 2010 17:20:39 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6DMKdWY015165 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Jul 2010 17:20:39 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 13 Jul 2010 17:20:39 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Brian Eaton'" , "Faynberg, Igor (Igor)" Date: Tue, 13 Jul 2010 17:20:38 -0500 Thread-Topic: [OAUTH-WG] "shared symmetric secret" Thread-Index: AcsizAn9v2oizrpATQOFeGWmraNc5AABr+MQ Message-ID: <5710F82C0E73B04FA559560098BF95B124F9688DC4@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <97BD2762-F147-4774-9557-AD478338B348@jkemp.net> <93F20A70-3133-4C5A-BE15-9C85F1D42787@jkemp.net> <4C3CCF58.6010102@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 22:20:38 -0000 According to the RFC 2828 an access token is rather a capability than a pas= sword. The passwords are usually associated with the matching identifiers, = but an access token of OAuth 2.0 is used as a single credential that allows= access to a protected resource. >From RFC 2828: $ password =20 (C) A password is usually matched with a user identifier that is explicitly presented in the authentication process, but in some cases the identity may be implicit. Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Eaton Sent: Tuesday, July 13, 2010 4:43 PM To: Faynberg, Igor (Igor) Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg wrote: > In this case, the term "capability" MUST be defined up front. The word > "capability" seems to carry a much broader meaning than password... It has a standard definition we can reference. From http://www.ietf.org/rfc/rfc2828.txt $ capability (I) A token, usually an unforgeable data value (sometimes called a "ticket") that gives the bearer or holder the right to access a system resource. Possession of the token is accepted by a system as proof that the holder has been authorized to access the resource named or indicated by the token. (See: access control list, credential, digital certificate.) =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From sayrer@gmail.com Tue Jul 13 16:00:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F313A6833 for ; Tue, 13 Jul 2010 16:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+A12P6u+67b for ; Tue, 13 Jul 2010 16:00:36 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 0F6543A67EE for ; Tue, 13 Jul 2010 16:00:35 -0700 (PDT) Received: by qyk2 with SMTP id 2so5113762qyk.10 for ; Tue, 13 Jul 2010 16:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=vYx7K9FY30vhFQTyi6b8t5+YcvIWk3KIkl7YgT1qXVs=; b=TyA5giaTv8etD2RzKxE2V9Epwib1prg8EMroFVT1lEu9apUYVxhaq8SHRWQKg/jsZr /UifUZEb/Ej3iy4abd4rQEA83jqNe9HKn599upndhmsbDnOsE/qWT0I25nURhFcH4O6g twWmO4Q+eyQNqXAnT3+gQ8KblUtx0w/lKEs7s= 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=XuR02RGewMjS/b2uMeAscwWoxZ+ywFmrb5b6Sc8H/uduQC2u+IX9StOr0fn/0+EU+E q4DPvHHNIVkEGgvz6P5ZdjJNSEGuZiXVwL3QcW0koL970Epl081nmzaYmfCgFL8IfsO7 wIb8Y1wycwfYlQNCQVZB+sENUz/lDhrYtn+JU= MIME-Version: 1.0 Received: by 10.224.37.137 with SMTP id x9mr9279179qad.155.1279062041628; Tue, 13 Jul 2010 16:00:41 -0700 (PDT) Received: by 10.229.83.130 with HTTP; Tue, 13 Jul 2010 16:00:41 -0700 (PDT) In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C5F991033@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C5F991033@TK5EX14MBXC113.redmond.corp.microsoft.com> Date: Tue, 13 Jul 2010 16:00:41 -0700 Message-ID: From: Robert Sayre To: Yaron Goland Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 23:00:36 -0000 On Tue, Jul 13, 2010 at 9:46 AM, Yaron Goland wrote: > As defined in section 4.2 of RFC 2616 the only characters legally allowed in a HTTP header are a fairly small subset of ASCII. I don't think that is correct. The definition of the TEXT rule in section 2.2 allows most octets. It also references RFC 2047, but I don't think many implementations actually support that RFC. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From eran@hueniverse.com Tue Jul 13 16:34: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 D27BA3A67D4 for ; Tue, 13 Jul 2010 16:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, 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 j3cFtxxKhj-q for ; Tue, 13 Jul 2010 16:34:17 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 03BD33A6881 for ; Tue, 13 Jul 2010 16:34:16 -0700 (PDT) Received: (qmail 28376 invoked from network); 13 Jul 2010 23:34:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Jul 2010 23:34:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 13 Jul 2010 16:34:22 -0700 From: Eran Hammer-Lahav To: Zachary Zeltsan , Brian Eaton , "Faynberg, Igor (Igor)" Date: Tue, 13 Jul 2010 16:34:20 -0700 Thread-Topic: [OAUTH-WG] "shared symmetric secret" Thread-Index: AcsizAn9v2oizrpATQOFeGWmraNc5AABr+MQAARIR20= Message-ID: In-Reply-To: <5710F82C0E73B04FA559560098BF95B124F9688DC4@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C862460C37210eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 23:34:22 -0000 --_000_C862460C37210eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm only using 2828 definition of capability, not password. EHL On 7/13/10 3:20 PM, "Zachary Zeltsan" = wrote: According to the RFC 2828 an access token is rather a capability than a pas= sword. The passwords are usually associated with the matching identifiers, = but an access token of OAuth 2.0 is used as a single credential that allows= access to a protected resource. >From RFC 2828: $ password (C) A password is usually matched with a user identifier that is explicitly presented in the authentication process, but in some cases the identity may be implicit. Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Eaton Sent: Tuesday, July 13, 2010 4:43 PM To: Faynberg, Igor (Igor) Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg wrote: > In this case, the term "capability" MUST be defined up front. The word > "capability" seems to carry a much broader meaning than password... It has a standard definition we can reference. From http://www.ietf.org/rfc/rfc2828.txt $ capability (I) A token, usually an unforgeable data value (sometimes called a "ticket") that gives the bearer or holder the right to access a system resource. Possession of the token is accepted by a system as proof that the holder has been authorized to access the resource named or indicated by the token. (See: access control list, credential, digital certificate.) _______________________________________________ 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_C862460C37210eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] "shared symmetric secret" I’m only using 2828 definition of capability, not password.

EHL


On 7/13/10 3:20 PM, "Zachary Zeltsan" <zachary.zeltsan@alcatel-lucent.com> wrote:
According to the RFC 2828 an access token i= s rather a capability than a password. The passwords are usually associated= with the matching identifiers, but an access token of OAuth 2.0 is used as= a single credential that allows access to a protected resource.

>From RFC 2828:
$ password
     
      (C) A password is usually matched with = a user identifier that is
      explicitly presented in the authenticat= ion process, but in some
      cases the identity may be implicit.

Zachary
-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On B= ehalf Of Brian Eaton
Sent: Tuesday, July 13, 2010 4:43 PM
To: Faynberg, Igor (Igor)
Cc: OAuth WG
Subject: Re: [OAUTH-WG] "shared symmetric secret"

On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg
<igor.faynberg@alcatel-luce= nt.com> wrote:
> In this case, the term "capability" MUST be defined up front= . The word
> "capability" seems to carry a much broader meaning than pass= word...

It has a standard definition we can reference.  From
http://www.ietf.org/rfc/rfc= 2828.txt

   $ capability
      (I) A token, usually an unforgeable dat= a value (sometimes called a
      "ticket") that gives the bear= er or holder the right to access a
      system resource. Possession of the toke= n is accepted by a system
      as proof that the holder has been autho= rized to access the
      resource named or indicated by the toke= n. (See: access control
      list, credential, digital certificate.)=

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

--_000_C862460C37210eranhueniversecom_-- From wmills@yahoo-inc.com Tue Jul 13 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 96E593A6B29 for ; Tue, 13 Jul 2010 17:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.904 X-Spam-Level: X-Spam-Status: No, score=-14.904 tagged_above=-999 required=5 tests=[AWL=-2.441, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_55=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXcxy4qUyorn for ; Tue, 13 Jul 2010 17:06:37 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 1B1E13A6B43 for ; Tue, 13 Jul 2010 17:06:36 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6E06Gwe069870; Tue, 13 Jul 2010 17:06:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=x6FgN/mPiyyk5tElmoLw2HuPXX9qg66HmzaCmknvos51JiEQSEWleF03KV48WkAX Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 17:06:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB22E8.40026A3A" Date: Tue, 13 Jul 2010 17:05:20 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6C45@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <4C3CAEA3.5040106@zetafleet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] ' force_auth' request parameter Thread-Index: AcsiuGl9fVb8oGZ2SBejNwtTiE94NAAL6KIQ References: <4C3CAEA3.5040106@zetafleet.com> From: "William Mills" To: "Colin Snover" , "Eran Hammer-Lahav" X-OriginalArrivalTime: 14 Jul 2010 00:06:16.0887 (UTC) FILETIME=[6135E470:01CB22E8] Cc: OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 00:06:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB22E8.40026A3A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with the below. =20 =20 To be clear, the case where we had a problem with this is a 3 legged = flow, where we as the 3rd party direct a user through an auth flow to be = redir3ected back to us. In this case it's nto the browser specifying, = it's the partner/integrator with a service. ________________________________ From: Colin Snover [mailto:ietf.org@zetafleet.com]=20 Sent: Tuesday, July 13, 2010 11:21 AM To: Eran Hammer-Lahav Cc: William Mills; David Recordon; OAuth WG; jhart@photobucket.com Subject: Re: [OAUTH-WG] ' force_auth' request parameter =09 =09 The only other thing I could think of to suggest would be to change the = spec to state that an authorization server MUST NOT rely on Cookie or = Authorization headers from the user-agent during the end-user redirect = phase as being safe for use in authentication. =09 To me, at least, it seems obvious an authorization server should = *never* think user-agent authorization tokens (e.g. session cookies, = basic auth) are a safe way of authenticating incoming authorization = requests. Doing so puts too much trust in the user-agent and allows the = client to bypass the first phase of authentication when it can't really = do so securely. This is only a problem because OAuth *requires* use of a = Web browser during its authorization flow. Unfortunately, lots and lots = of providers are already doing this, and the only way I can think of to = make it stop it is to make it verboten in the spec, even if it causes = the spec to deviate slightly into the authentication arena in this one = particular area. =09 As far as (very legitimate) concerns regarding inconsistent user = experience go, let's look at how the current OAuth system works in = practice. No matter what, *any* authorization action taken by an = end-user in a client can potentially mean either "log in and then = authorize", "authorize", or "do nothing while we automatically refresh = the client with a new token and redirect you back". That's already a = *huge* disparity in what happens *within the same client*, and it's = painfully bad. =09 I think Justin Hart got it exactly right when he said there should be = four options. Even if what happens is not always the same, clients can = manage user expectations *much* better than providers by providing cues = about what will happen *before* auth flow starts. With the current way = it works, basically all the client can tell the user is "we have no idea = what will happen once you click this button except maybe your account = will get connected to our site if you do it exactly right; good luck!". =09 Regards, =09 =09 On 13/07/2010 12:28, Eran Hammer-Lahav wrote:=20 User authentication and approval interaction has always been the sole = domain of the authorization server. This proposal shifts the decision = towards the client. It is unclear to me why is the client better suited = to make this decision? In the context of identity, if a client relies on = the server for its own identity services (e.g. Facebook connect), it = makes sense for the client to request stronger authentication than just = cookies. But outside the identity context, I am unconvinced the client = is likely to make a smart decision. In addition, if we let the client = specify this, it will mean different client will have different user = experience on the same server which is confusing and odd. =09 I'm not opposed to this, just that I don't think this is well thought = out. =09 EHL =09 =09 On 7/13/10 10:18 AM, "William Mills" wrote: =09 =09 I agree it changes the boundaries. I think this one needs moving. = As I said we hit a significant problem with this, which we solved by = virtue of the fact that the target we were working with has an = un-crumbed logout, so we could XSRF the logout. =09 It's something people get wrong and we should make a way to get it = right. =09 =09 =09 =20 =09 ________________________________ From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Tuesday, July 13, 2010 10:08 AM To: William Mills Cc: David Recordon; Colin Snover; OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter =09 =20 =20 The question is if we have consensus to force providers to support = it.=20 =09 =20 It seems to overstep the boundaries we set over the years and it = makes assumptions about how services authenticate users and obtain = approvals.=20 =20 =09 =20 EHL =20 =09 =20 =09 On Jul 13, 2010, at 13:05, William Mills = wrote: =09 =20 =20 =09 =09 =20 I think it's a mistake not to have force_auth in the core. =09 =20 =09 =09 =20 =09 ________________________________ From: David Recordon [mailto:recordond@gmail.com]=20 Sent: Tuesday, July 13, 2010 9:58 AM To: William Mills Cc: Colin Snover; Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter =09 =20 I support immediate and a form of forced auth (ala OpenID's PAPE) = but not in the core spec. They both should be part of an identity = extension. =20 =09 =09 =20 On Tue, Jul 13, 2010 at 9:51 AM, William Mills = > wrote: =20 =09 =09 =20 I agree with Colin that some form of force_auth is needed. I = haven't read enough on the "immediate" proposal, but I know that we = have run into the problem of trusting currently set cookies in the = browser (even when we're actually sending a username/password and = really do want to have an authentication). =09 =20 =20 I'm a +1 on the force_auth proposal. =09 =20 =09 =09 =20 =09 ________________________________ From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org ] On = Behalf Of Colin Snover Sent: Tuesday, July 13, 2010 9:23 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] ' force_auth' request parameter =09 =20 =20 =20 =20 On 22/07/28164 13:59, Eran Hammer-Lahav wrote: =20 =09 The following was submitted via the shared-copy page but does not = belong with editorial feedback. This needs to be discussed and = supported on the list before added the specification. I think it = belongs where 'immediate' is specified. =09 EHL =09 ------ Forwarded Message =20 =09 From: An anonymous reader > Date: Sat, 10 Jul 2010 11:01:11 -0700 To: Eran Hammer-Lahav > Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol =09 =09 =09 =20 =09 "Colin Snover" left these comments on your copy:=20 =20 draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol = > =20 =20 =09 As proposed on the ML, a new parameter to counteract the current = behaviour of OAuth 1.0a authorization servers which is to assume that = the account logged into the user-agent is the account that should be = checked for access: =09 force_auth OPTIONAL. The parameter value must be set to "true" or = "false". =09 If set to "true", the authorization server MUST prompt the = end-user to authenticate and approve access. The authorization server = MUST NOT make any assumptions as to the identity of the entity = requesting access, even if another automatic mechanism is available to = do so (e.g. browser cookies). =09 If set to "false" or not present, the authorization server = MAY automatically grant access to the client if it is able to = determine that access was previously granted. link =BB = > =20 =20 =09 tools.ietf.org/html/draft-ietf-oauth-v2-09 = = = > = =B7 Original page > =20 =20 =20 =20 =09 ________________________________ via sharedcopy.com = > =20 =09 =09 ------ End of Forwarded Message =09 =09 Hi Eran, =09 Sorry if that was not the right place for that to go; I didn't = know what else to do. I have tried to solicit feedback from the ML = regarding this parameter twice and nobody seems very keen in providing = any, which is kind of a bummer. I waited until the last possible moment = to add it in the hopes that someone would notice my messages and = discuss it, but you made it sound like your plan was for draft 10 to be = potentially final so I wanted to get it in before the deadline. =09 I'm sure this is not a big deal for most applications that expect = at most a single connection, but for me this is a huge deal since it = completely immolates our application's authentication flow, and I can't = go to every provider asking them to please change the way they = implement the authentication portion of their OAuth API. =09 In contrast to 'immediate', which had some concerns vis =E0 vis = security, force_auth is actually safer than the current normal flow = used by most OAuth providers since it requires the provider to make no = guesses about who is trying to authorize the app. =09 Frankly, I think that OAuth providers do the wrong thing now in = all cases by assuming that browser cookies are a safe way of confirming = the identity of the end-user making an authorization request (they = aren't!), but the spec says the way the authorization server = authenticates the end-user is outside the scope of the spec. I have no = objection to this-OAuth *should* be authentication-agnostic-but at the = same time this is a very real and present implementation flaw and the = only way to solve it is to make sure the spec defines a way for an = application to say "hey, I know you *think* you know who should be = authenticated, but *I* know that the user has requested to connect a = *new* account, so don't use any automatic authentication method". =09 I think it is incredibly important that the OAuth spec gets = providers to distinguish between automatic & potentially unsafe = authentication methods (like session cookies) versus more "guaranteed" = authentication (like password), especially since 99.999% of the time = OAuth relies on the end-user's Web browser which is all but guaranteed = to contain some cookies for the provider that are unrelated to the = requesting application. =09 Examples: =09 1. Multiple end-users with malicious intent. User 1 is logged into = their Facetweetr account. User 2 wants to do bad things using User 1's = account. Because the user-agent has cookies for user 1, user 2 gets to = authorize their account with our app. Even when user 1 changes their = password, unless the provider automatically invalidates their existing = connections (the spec does not even mention doing this in an = informative manner as far as I can tell), they are almost certainly = unaware that the linked application is still able to perform actions on = their behalf. =09 2. Single end-user with multiple accounts. User is logged into = Facetweetr account 1, but they want to authorize account 2. They go to = authorize the application and are presented with a confirmation for = account 1. They log out (because this is the only way to switch = accounts on the provider) and suddenly the authorization flow is = dropped on the floor. The user may not know immediately what they need = to do at this point. They will need to manually return to the original = application and restart the authorization request. =09 3. User has two accounts that they want to authorize with a = provider. User authorizes account 1 successfully, then wants to = authorize account 2. Because account 1 is still logged in, and because = the application already has a link to the account, it automatically = redirects back to the application's redirection URI. In order for the = user to get what they want, they are forced to manually navigate to the = provider's site, log out, *then* begin the authorization request. =09 These aren't imaginary scenarios; they are things that are going = on *right now* with several different OAuth providers. =09 The original request: = = =20 =09 Regards, =09 --=20 Colin Snover ------_=_NextPart_001_01CB22E8.40026A3A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] ' force_auth' request = parameter
I agree with the below. 
 
To be clear, the case where we had a problem with = this is a 3=20 legged flow, where we as the 3rd party direct a user through an auth = flow to be=20 redir3ected back to us.  In this case it's nto the browser = specifying, it's=20 the partner/integrator with a service.

From: Colin Snover=20 [mailto:ietf.org@zetafleet.com]
Sent: Tuesday, July 13, = 2010 11:21=20 AM
To: Eran Hammer-Lahav
Cc: William Mills; David=20 Recordon; OAuth WG; jhart@photobucket.com
Subject: Re: = [OAUTH-WG] '=20 force_auth' request parameter

The only other thing I could think of to suggest would be = to change=20 the spec to state that an authorization server MUST NOT rely on Cookie = or=20 Authorization headers from the user-agent during the end-user redirect = phase=20 as being safe for use in authentication.

To me, at least, it = seems=20 obvious an authorization server should *never* think user-agent = authorization=20 tokens (e.g. session cookies, basic auth) are a safe way of = authenticating=20 incoming authorization requests. Doing so puts too much trust in the=20 user-agent and allows the client to bypass the first phase of = authentication=20 when it can=92t really do so securely. This is only a problem because = OAuth=20 *requires* use of a Web browser during its authorization flow. = Unfortunately,=20 lots and lots of providers are already doing this, and the only way I = can=20 think of to make it stop it is to make it verboten in the spec, even = if it=20 causes the spec to deviate slightly into the authentication arena in = this one=20 particular area.

As far as (very legitimate) concerns regarding = inconsistent user experience go, let=92s look at how the current OAuth = system=20 works in practice. No matter what, *any* authorization action taken by = an=20 end-user in a client can potentially mean either =93log in and then = authorize=94,=20 =93authorize=94, or =93do nothing while we automatically refresh the = client with a=20 new token and redirect you back=94. That=92s already a *huge* = disparity in what=20 happens *within the same client*, and it=92s painfully bad.

I = think=20 Justin Hart got it exactly right when he said there should be four = options.=20 Even if what happens is not always the same, clients can manage user=20 expectations *much* better than providers by providing cues about what = will=20 happen *before* auth flow starts. With the current way it works, = basically all=20 the client can tell the user is =93we have no idea what will happen = once you=20 click this button except maybe your account will get connected to our = site if=20 you do it exactly right; good luck!=94.

Regards,


On = 13/07/2010=20 12:28, Eran Hammer-Lahav wrote:=20
User=20 authentication and approval interaction has always been the sole = domain of=20 the authorization server. This proposal shifts the decision towards = the=20 client. It is unclear to me why is the client better suited to make = this=20 decision? In the context of identity, if a client relies on the = server for=20 its own identity services (e.g. Facebook connect), it makes sense = for the=20 client to request stronger authentication than just cookies. But = outside the=20 identity context, I am unconvinced the client is likely to make a = smart=20 decision. In addition, if we let the client specify this, it will = mean=20 different client will have different user experience on the same = server=20 which is confusing and odd.

I=92m not opposed to this, just = that I=20 don=92t think this is well thought out.

EHL


On = 7/13/10 10:18=20 AM, "William Mills" <wmills@yahoo-inc.com>=20 wrote:
I agree it changes the boundaries.  I think this = one needs=20 moving.  As I said we hit a significant problem with this, = which we=20 solved by virtue of the fact that the target we were working with = has an=20 un-crumbed logout, so we could XSRF the = logout.

It's something people get wrong = and we=20 should make a way to get it right.

 
From: Eran=20 Hammer-Lahav  [mailto:eran@hueniverse.com] =
Sent:=20 Tuesday, July 13, 2010 10:08  AM
To: William=20 Mills
Cc: David Recordon; Colin Snover;  OAuth=20 WG
Subject: Re: [OAUTH-WG] ' force_auth' request=20  parameter

 
 
The=20 question is if we have consensus to force providers to support =  it.=20

 
It seems to overstep the boundaries we set = over the=20 years and it makes  assumptions about how services = authenticate=20 users and obtain  approvals.=20 =
 

 
EHL
 

 

On Jul=20 13, 2010, at 13:05, William Mills <wmills@yahoo-inc.com>=20  wrote:

 
 

 
I think it's a mistake not = to have=20 force_auth in the  core.

 

 
From:=20 David Recordon  [mailto:recordond@gmail.com]=20
Sent: Tuesday, July 13, 2010 9:58 =  AM
To:=20 William Mills
Cc: Colin Snover; Eran =  Hammer-Lahav;=20 OAuth WG
Subject: Re: [OAUTH-WG] ' force_auth'=20  request parameter

 
I = support=20 immediate and a form of forced auth (ala OpenID's =  PAPE) but=20 not in the core spec. They both should be part of an = identity=20  extension.  


 
On Tue, Jul 13, = 2010 at=20 9:51 AM, William Mills  <wmills@yahoo-inc.com <mailto:wmills@yahoo-inc.com> = >=20  wrote:
 

 
I  agree with = Colin that some=20 form of force_auth is needed.  I haven't  read = enough on=20 the "immediate" proposal, but I know that we have run =  into=20 the problem of trusting currently set cookies in the = browser (even=20  when we're actually sending a username/password and = really=20 do want to  have an = authentication).

 
 
I'm  a +1 on the = force_auth=20 proposal.

 

 
From: = oauth-bounces@ietf.org = <mailto:oauth-bounces@ietf.org>=20   [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org> ]=20  On Behalf Of Colin Snover
Sent: = Tuesday,=20 July 13,  2010 9:23 AM
To: Eran=20 Hammer-Lahav
Cc: OAuth =  WG
Subject: Re:=20 [OAUTH-WG] ' force_auth' request =  parameter

 
 
 
 
On=20 22/07/28164 13:59, Eran Hammer-Lahav wrote:=20  
The = following was=20 submitted via the  shared-copy page but does not = belong=20 with editorial feedback. This  needs to be = discussed and=20 supported on the list before added the =  specification. I=20 think it belongs where =91immediate=92 is=20  specified.

EHL

------ Forwarded=20 =  Message
 
From: An=20 anonymous reader <mailman@sharedcopy.com <mailto:mailman@sharedcopy.com>=20 >
Date:  Sat, 10 Jul 2010 11:01:11 -0700
To: = Eran  Hammer-Lahav <eran@hueniverse.com <mailto:eran@hueniverse.com>=20 >
Subject:  Re: draft-ietf-oauth-v2-09 - The OAuth = 2.0=20  Protocol


 
"Colin=20 Snover" left these  comments on your copy:=20
 
draft-ietf-oauth-v2-09 - The OAuth 2.0=20  Protocol <http://r6.sharedcopy.com/6bnqq8v <http://r6.sharedcopy.com/6bnqq8v> = >=20  
       

   = ;  As=20  proposed on the ML, a new parameter to counteract the current=20  behaviour of OAuth 1.0a authorization servers which is to = assume=20  that the account logged into the user-agent is the account = that=20  should be checked for=20 =  access:

force_auth
      &n= bsp;  OPTIONAL.=20  The parameter value must be set to "true" or=20 =  "false".

        &nb= sp;If=20  set to "true", the authorization server MUST prompt the = end-user=20  to authenticate and approve access. The authorization server = MUST=20  NOT make any assumptions as to the identity of the entity=20  requesting access, even if another automatic mechanism is=20  available to do so (e.g. browser=20 =  cookies).

        &n= bsp;If=20  set to "false" or not present, the authorization server MAY=20  automatically grant access to the client if it is able to=20  determine that access was previously granted.=20          link =BB = <http://r6.sharedcopy.com/6bnqq8v#shcp21 = <http://r6.sharedcopy.com/6bnqq8v#shcp21> = >=20  
 

tools.ietf.org/html/draft-ietf-oauth-v2-09 = <http://tools.ietf.org/html/draft-ietf-oauth-v2-0= 9>=20  <http://tools.ietf.org/html/draft-ietf-oauth-v2-0= 9>=20   <http://r6.sharedcopy.com/6bnqq8v <http://r6.sharedcopy.com/6bnqq8v> = >=20   =B7 Original page <http://tools.ietf.org/html/draft-ietf-oauth-v2-0= 9=20 <http://tools.ietf.org/html/draft-ietf-oauth-v2-0= 9>=20 >  
  
 
 
via sharedcopy.com <http://sharedcopy.com>  <http://sharedcopy.com>  <http://sharedcopy.com/?ef <http://sharedcopy.com/?ef> >=20   

------ End of Forwarded=20  Message

Hi Eran,

Sorry if =  that=20 was not the right place for that to go; I didn=92t know = what else=20  to do. I have tried to solicit feedback from the = ML=20 regarding this  parameter twice and nobody seems = very keen=20 in providing any, which is  kind of a bummer. I = waited=20 until the last possible moment to add it in  the = hopes that=20 someone would notice my messages and discuss it, but =  you=20 made it sound like your plan was for draft 10 to be = potentially=20  final so I wanted to get it in before the=20 deadline.

I=92m sure  this is not a big deal = for most=20 applications that expect at most a  single = connection, but=20 for me this is a huge deal since it completely =  immolates=20 our application=92s authentication flow, and I can=92t = go to=20  every provider asking them to please change the = way they=20 implement the  authentication portion of their = OAuth=20 API.

In contrast to  =91immediate=92, which = had some=20 concerns vis =E0 vis security, force_auth is =  actually safer=20 than the current normal flow used by most OAuth =  providers=20 since it requires the provider to make no guesses about = who=20  is trying to authorize the app.

Frankly, I = think=20 that OAuth  providers do the wrong thing now in all = cases=20 by assuming that browser  cookies are a safe way of = confirming the identity of the end-user  making an=20 authorization request (they aren=92t!), but the spec = says the=20  way the authorization server authenticates the = end-user is=20 outside the  scope of the spec. I have no objection = to=20 this=97OAuth *should* be =  authentication-agnostic=97but at the=20 same time this is a very real and  present = implementation=20 flaw and the only way to solve it is to make  sure = the spec=20 defines a way for an application to say =93hey, I know = you=20  *think* you know who should be authenticated, but = *I* know=20 that the  user has requested to connect a *new* = account, so=20 don=92t use any  automatic authentication = method=94.

I=20 think it is incredibly  important that the OAuth = spec gets=20 providers to distinguish between  automatic &=20 potentially unsafe authentication methods (like =  session=20 cookies) versus more =93guaranteed=94 authentication = (like=20  password), especially since 99.999% of the time = OAuth=20 relies on the  end-user=92s Web browser which is = all but=20 guaranteed to contain some  cookies for the = provider that=20 are unrelated to the requesting=20  application.

Examples:

1. Multiple = end-users=20 with  malicious intent. User 1 is logged into their = Facetweetr account. User  2 wants to do bad things = using=20 User 1=92s account. Because the  user-agent has = cookies for=20 user 1, user 2 gets to authorize their  account = with our=20 app. Even when user 1 changes their password, unless =  the=20 provider automatically invalidates their existing = connections=20 (the  spec does not even mention doing this in an=20 informative manner as far  as I can tell), they are = almost=20 certainly unaware that the linked  application is = still=20 able to perform actions on their  behalf.

2. = Single=20 end-user with multiple accounts. User is  logged = into=20 Facetweetr account 1, but they want to authorize account =  2. They go to authorize the application and are = presented=20 with a  confirmation for account 1. They log out = (because=20 this is the only way  to switch accounts on the = provider)=20 and suddenly the authorization  flow is dropped on = the=20 floor. The user may not know immediately what  they = need to=20 do at this point. They will need to manually return to =  the=20 original application and restart the authorization=20  request.

3. User has two accounts that they = want to=20 authorize  with a provider. User authorizes account = 1=20 successfully, then wants to  authorize account 2. = Because=20 account 1 is still logged in, and because  the = application=20 already has a link to the account, it automatically=20  redirects back to the application=92s redirection = URI. In=20 order for the  user to get what they want, they are = forced=20 to manually navigate to  the provider=92s site, log = out,=20 *then* begin the authorization =  request.

These=20 aren=92t imaginary scenarios; they are things that =  are going=20 on *right now* with several different OAuth=20  providers.

The original request: <http://www.mail-archive.com/oauth@ietf.org/msg02= 331.html>=20 <http://www.mail-archive.com/oauth@ietf.org/msg02= 331.html>=20 =

Regards,
= 


--=20
Colin Snover
------_=_NextPart_001_01CB22E8.40026A3A-- From kris.selden@gmail.com Tue Jul 13 17: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 0F1343A6822 for ; Tue, 13 Jul 2010 17:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vu+ZqYiaKEGn for ; Tue, 13 Jul 2010 17:55:52 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 13F503A68B9 for ; Tue, 13 Jul 2010 17:55:52 -0700 (PDT) Received: by pvd12 with SMTP id 12so2996510pvd.31 for ; Tue, 13 Jul 2010 17:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=jaA+uyKQYg18jXE0E5XsGm7bfEpe7s/+S46GUOrpAyE=; b=iJucSun8yJUhlTT0B0rrHv+S33lnN1uC2JzOgB8WFm+VGGosOvUkyUr/bLc2h3u9Fa T30SUJQz5+8SOA1zYttW+cLmOBW0nzVpCELfNpuAqKJF54fofj1pr6qcWlp4dkrR7H1G QGBt8SzIIIsfNTpMTLFMyD+n2z77WRDC1N5LA= 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=OX4gojWDkrm3AQwiSXD81pJA+qzVrp+wXFrBJXnL/kTgzPYjaFgeIxPEj9dvCi5/y3 Ik1EQZvZjcbbVKM0ccWZ7xzwUnaw7ek078U+XWqjxiguvwYPNIA6WFfZzAqo1lfafRDa K+4BOB6svdoigvaciHzcvp4D38xdDXvOnGocg= Received: by 10.142.215.6 with SMTP id n6mr8895466wfg.228.1279068957393; Tue, 13 Jul 2010 17:55:57 -0700 (PDT) Received: from [172.16.2.13] (c-76-121-106-185.hsd1.wa.comcast.net [76.121.106.185]) by mx.google.com with ESMTPS id b1sm6483678rvn.2.2010.07.13.17.55.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Jul 2010 17:55:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Kris Selden In-Reply-To: Date: Tue, 13 Jul 2010 17:55:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Eaton , Eran Hammer-Lahav X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 00:55:53 -0000 Torsten Lodderstedt [OAUTH-WG] Refresh tokens security enhancement http://www.ietf.org/mail-archive/web/oauth/current/msg02292.html Eran Hammer-Lahav Re: [OAUTH-WG] Refresh tokens security enhancement http://www.ietf.org/mail-archive/web/oauth/current/msg02390.html On Jul 13, 2010, at 7:04 AM, Eran Hammer-Lahav wrote: >=20 >=20 >=20 > On 7/12/10 10:36 PM, "Brian Eaton" wrote: >=20 >> Draft 10 has the following sentence in section 4.1.4: >> http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4 >>=20 >> "The authorization server MAY issue a new refresh token." >=20 > The capability was there since -02. >=20 > -04 added the following text in an attempt to clarify how the = refresh_token > output can be used (returning a refresh token was briefly discussed as = part > of the general idea of always allowing a refresh token in token = responses): >=20 > The authorization server > MAY issue a new refresh token in which case the client MUST NOT use > the previous refresh token and replace it with the newly issued > refresh token. >=20 > In -10 I dropped the restriction because people expressed a general = issue > with having to revoke tokens. >=20 >> That carries a surprising amount of baggage. I suggest removing the >> sentence, or changing it to MUST NOT, pending a discussion of the use >> cases for issuing new refresh tokens. >>=20 >> Does anyone remember why that sentence got added to the spec? >>=20 >> There are two reasons I can see for issuing new refresh tokens: >> 1) secrets are like underwear, change them frequently >> 2) someone has a cryptographically implemented refresh token that >> needs to be re-signed or re-issued >>=20 >> I'm pretty sure anyone issuing cryptographic refresh tokens is crazy, >> these pretty much have to be backed by server-side state or there is >> no way to run your system. So I'm going to ignore that possibility, >> and guess that someone was interested in changing secrets... >=20 > There was no requirement to support changing refresh tokens. If there = is no > interest in this, I suggest we forbid it (otherwise all clients will = need to > accommodate the chance of a new refresh token, and then will need = guidelines > on how to handle it). >=20 >> So if we want to issue new refresh tokens because we like to change >> secrets, we should cover: >> - whether existing refresh tokens are revoked. (I'd vote for MUST be = revoked) >=20 > I agree. >=20 >> - the minimum latency between issuing a new refresh token and = revoking >> the old one. (I'd vote for minimum latency measured in hours or >> longer. Clients that have cached refresh tokens need to refresh = their >> cache within this time period, or they're borked.) >> - the maxium latency for revoking the old token. (I'd vote for >> maximum latency measured in hours or days, just for security reasons. >> But I can't think of what would break if servers ignored this = advice.) >=20 > Why is this required? Can it be specified as a general recommendation? >=20 > EHL >=20 >> Cheers, >> Brian >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From beaton@google.com Tue Jul 13 18:07: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 2CCB03A6925 for ; Tue, 13 Jul 2010 18:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.723 X-Spam-Level: X-Spam-Status: No, score=-105.723 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRRU2FuTW0sB for ; Tue, 13 Jul 2010 18:07:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 4F1B53A68FD for ; Tue, 13 Jul 2010 18:07:03 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o6E17Bvg017070 for ; Tue, 13 Jul 2010 18:07:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279069632; bh=5+pRc6PspRdFo7rQ7n6OLXYNZZM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=AHvS96/uywpdCRKmrvxjJ78M+Fik1zktPp2xvPVVB6FyRIy7Nns69/0xyIIa1EL3n nSIYYVmhmxVsCCzApDSXA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=tBXlqN1k6Sjkd/24wQoVzZra3wajh0zXcxnlDrAgzgwanbAkZ4E9FyfWHGGwvgeoO KIwdBMlkxewjPGYMAhM2g== Received: from pzk27 (pzk27.prod.google.com [10.243.19.155]) by wpaz21.hot.corp.google.com with ESMTP id o6E17An6025313 for ; Tue, 13 Jul 2010 18:07:10 -0700 Received: by pzk27 with SMTP id 27so1774160pzk.25 for ; Tue, 13 Jul 2010 18:07:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.172.15 with SMTP id u15mr616406wfe.82.1279069629638; Tue, 13 Jul 2010 18:07:09 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Tue, 13 Jul 2010 18:07:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 18:07:09 -0700 Message-ID: From: Brian Eaton To: Kris Selden , Torsten Lodderstedt 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] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 01:07:05 -0000 Kris - Thanks for pointing back to where this started! I more or less agree with what Allen said in response to Torsten's proposal: http://www.ietf.org/mail-archive/web/oauth/current/msg02295.html. The devil is in the details. I'd be interested in tackling client secret rotation at the same time as handling refresh token rotation... they are similar problems. BUT, if we do this, we should do it reasonably well. In particular, I think we'd need: - a way for clients to opt-in to this, probably when they first get a refresh token - a system that worked for distributed clients - a system that allowed rotation of the client secret I don't think any of that would be impractical, long-term. Windows and AD have had automatic rotation of kerberos service keys for a while, for example. And here's a more far-fetched idea... installed applications could self-generate public/private key pairs, which could then be used to authenticate to the authorization server using something like Yaron's recent proposal for client assertion authentication. Cheers, Brian On Tue, Jul 13, 2010 at 5:55 PM, Kris Selden wrote: > Torsten Lodderstedt > [OAUTH-WG] Refresh tokens security enhancement > http://www.ietf.org/mail-archive/web/oauth/current/msg02292.html > > Eran Hammer-Lahav > Re: [OAUTH-WG] Refresh tokens security enhancement > http://www.ietf.org/mail-archive/web/oauth/current/msg02390.html > > On Jul 13, 2010, at 7:04 AM, Eran Hammer-Lahav wrote: > >> >> >> >> On 7/12/10 10:36 PM, "Brian Eaton" wrote: >> >>> Draft 10 has the following sentence in section 4.1.4: >>> http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4 >>> >>> "The authorization server MAY issue a new refresh token." >> >> The capability was there since -02. >> >> -04 added the following text in an attempt to clarify how the refresh_to= ken >> output can be used (returning a refresh token was briefly discussed as p= art >> of the general idea of always allowing a refresh token in token response= s): >> >> =A0 The authorization server >> =A0 MAY issue a new refresh token in which case the client MUST NOT use >> =A0 the previous refresh token and replace it with the newly issued >> =A0 refresh token. >> >> In -10 I dropped the restriction because people expressed a general issu= e >> with having to revoke tokens. >> >>> That carries a surprising amount of baggage. =A0I suggest removing the >>> sentence, or changing it to MUST NOT, pending a discussion of the use >>> cases for issuing new refresh tokens. >>> >>> Does anyone remember why that sentence got added to the spec? >>> >>> There are two reasons I can see for issuing new refresh tokens: >>> 1) secrets are like underwear, change them frequently >>> 2) someone has a cryptographically implemented refresh token that >>> needs to be re-signed or re-issued >>> >>> I'm pretty sure anyone issuing cryptographic refresh tokens is crazy, >>> these pretty much have to be backed by server-side state or there is >>> no way to run your system. =A0So I'm going to ignore that possibility, >>> and guess that someone was interested in changing secrets... >> >> There was no requirement to support changing refresh tokens. If there is= no >> interest in this, I suggest we forbid it (otherwise all clients will nee= d to >> accommodate the chance of a new refresh token, and then will need guidel= ines >> on how to handle it). >> >>> So if we want to issue new refresh tokens because we like to change >>> secrets, we should cover: >>> - whether existing refresh tokens are revoked. =A0(I'd vote for MUST be= revoked) >> >> I agree. >> >>> - the minimum latency between issuing a new refresh token and revoking >>> the old one. =A0(I'd vote for minimum latency measured in hours or >>> longer. =A0Clients that have cached refresh tokens need to refresh thei= r >>> cache within this time period, or they're borked.) >>> - the maxium latency for revoking the old token. =A0(I'd vote for >>> maximum latency measured in hours or days, just for security reasons. >>> But I can't think of what would break if servers ignored this advice.) >> >> Why is this required? Can it be specified as a general recommendation? >> >> EHL >> >>> Cheers, >>> Brian >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > From beaton@google.com Tue Jul 13 21:11:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008303A6976 for ; Tue, 13 Jul 2010 21:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.733 X-Spam-Level: X-Spam-Status: No, score=-105.733 tagged_above=-999 required=5 tests=[AWL=0.244, 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 jnofl8KFFIWZ for ; Tue, 13 Jul 2010 21:11:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B30673A6910 for ; Tue, 13 Jul 2010 21:11:39 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o6E4BmsR028000 for ; Tue, 13 Jul 2010 21:11:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279080708; bh=+2OXRamR8Wk8I5LsicF0bfr3mEA=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=CwU/O9zNYJ29hnnF53B6GI4e/i3/WufTxwmLXec66UAkDAootCqDQx5r7KM+nm5lT LKZ83xGlpjRTVZoEK78Dw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=T2Wj3KLiBnbPkeKf3PIRreT2UhNHyVHf3foWbwu3bsNy/6xQqxoLIHeAZL2Qn/DXz dE5LNC4XT2whdzQnNLArA== Received: from pvg16 (pvg16.prod.google.com [10.241.210.144]) by kpbe17.cbf.corp.google.com with ESMTP id o6E4AjoA019996 for ; Tue, 13 Jul 2010 21:11:47 -0700 Received: by pvg16 with SMTP id 16so124081pvg.1 for ; Tue, 13 Jul 2010 21:11:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.204.17 with SMTP id b17mr9857394wfg.4.1279080706593; Tue, 13 Jul 2010 21:11:46 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Tue, 13 Jul 2010 21:11:46 -0700 (PDT) Date: Tue, 13 Jul 2010 21:11:46 -0700 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] single use authorization codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 04:11:42 -0000 Draft 10 currently requires that the authorization code issued for the web-app profile is a single use token. That won't scale well. This got added in draft 4, I'm not sure why. Anybody know...? Here's the relevant section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-3 "The authorization code SHOULD expire shortly after it is issued. The authorization server MUST invalidate the authorization code after a single usage." I think better language would be something like this: "Under normal circumstances, clients will use the authorization code immediately after receiving a redirect from the Authorization Server. Authorization codes SHOULD expire shortly after they are issued to minimize the risk of leaks. Clients MUST NOT reuse verification codes. Authorization servers MAY make authorization codes single use tokens. If an Authorization Server detects multiple attempts to exchange a single verification code for an access token, the verification code may have leaked. The Authorization Server MAY revoke all tokens previously issued based on that verification code." Justification... "Authorization servers MAY make authorization codes single use tokens": this is not a MUST because single use tokens are expensive and slow to implement. They require synchronous replication of server-side state. Because the oauth client and the user who approved the request may be in geographically distant locations, this is pretty much guaranteed to be either slow, or unreliable, or both. When things like immediate mode with automatic authorization are used, lots and lots verification codes are going to be issued for no good reason. Server-side storage for those tokens is wasteful, so people are going to end up using cryptographic implementations of verification codes. "The authorization code SHOULD expire shortly after it is issued": this is a good idea because we are passing authorization tokens via browser redirects, and browser redirects are leaky channels. If one of these tokens leaks, someone who captures the token can replay it to the client web site, and the client web site will then happily swap the code for an access token. The client web site will then associate the victim's access token with the attacker's account. Cheers, Brian From eran@hueniverse.com Tue Jul 13 21:26: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 014AA3A67AE for ; Tue, 13 Jul 2010 21:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.129, 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 1511gTNnsLPZ for ; Tue, 13 Jul 2010 21:25:59 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 02B853A68CF for ; Tue, 13 Jul 2010 21:25:58 -0700 (PDT) Received: (qmail 25828 invoked from network); 14 Jul 2010 04:26:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Jul 2010 04:26:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 13 Jul 2010 21:26:08 -0700 From: Eran Hammer-Lahav To: Brian Eaton , OAuth WG Date: Tue, 13 Jul 2010 21:26:04 -0700 Thread-Topic: [OAUTH-WG] single use authorization codes Thread-Index: AcsjCrJw/YifGdTgTvKNptx+4HxBdQAAflp3 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8628A6C37229eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] single use authorization codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 04:26:03 -0000 --_000_C8628A6C37229eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How about: Authorization codes SHOULD expire shortly after they are issued to minimize the risk of leaks. Clients MUST NOT reuse authorization codes. If an authorization code is used more than once, the authorization server SHOULD revoke all tokens previously issued based on that authorizati= on code. EHL On 7/13/10 9:11 PM, "Brian Eaton" wrote: Draft 10 currently requires that the authorization code issued for the web-app profile is a single use token. That won't scale well. This got added in draft 4, I'm not sure why. Anybody know...? Here's the relevant section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-3 "The authorization code SHOULD expire shortly after it is issued. The authorization server MUST invalidate the authorization code after a single usage." I think better language would be something like this: "Under normal circumstances, clients will use the authorization code immediately after receiving a redirect from the Authorization Server. Authorization codes SHOULD expire shortly after they are issued to minimize the risk of leaks. Clients MUST NOT reuse verification codes. Authorization servers MAY make authorization codes single use tokens. If an Authorization Server detects multiple attempts to exchange a single verification code for an access token, the verification code may have leaked. The Authorization Server MAY revoke all tokens previously issued based on that verification code." Justification... "Authorization servers MAY make authorization codes single use tokens": this is not a MUST because single use tokens are expensive and slow to implement. They require synchronous replication of server-side state. Because the oauth client and the user who approved the request may be in geographically distant locations, this is pretty much guaranteed to be either slow, or unreliable, or both. When things like immediate mode with automatic authorization are used, lots and lots verification codes are going to be issued for no good reason. Server-side storage for those tokens is wasteful, so people are going to end up using cryptographic implementations of verification codes. "The authorization code SHOULD expire shortly after it is issued": this is a good idea because we are passing authorization tokens via browser redirects, and browser redirects are leaky channels. If one of these tokens leaks, someone who captures the token can replay it to the client web site, and the client web site will then happily swap the code for an access token. The client web site will then associate the victim's access token with the attacker's account. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C8628A6C37229eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] single use authorization codes How about:

Authorization codes SHOULD expire shortly after they are issued to
minimize the risk of leaks.  Clients MUST NOT reuse authorization
codes.  If an authorization code is used more than once, the authoriza= tion
server SHOULD revoke all tokens previously issued based on that authorizati= on
code.

EHL


On 7/13/10 9:11 PM, "Brian Eaton" <beaton@google.com> wrote:

Draft 10 currently requires that the author= ization code issued for the
web-app profile is a single use token.  That won't scale well.

This got added in draft 4, I'm not sure why.  Anybody know...?

Here's the relevant section:
htt= p://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-3

"The authorization code SHOULD expire shortly after it is issued. &nbs= p;The
authorization server MUST invalidate the authorization code after a
single usage."

I think better language would be something like this:

"Under normal circumstances, clients will use the authorization code immediately after receiving a redirect from the Authorization Server.
Authorization codes SHOULD expire shortly after they are issued to
minimize the risk of leaks.  Clients MUST NOT reuse verification
codes.  Authorization servers MAY make authorization codes single use<= BR> tokens.  If an Authorization Server detects multiple attempts to
exchange a single verification code for an access token, the
verification code may have leaked.  The Authorization Server MAY
revoke all tokens previously issued based on that verification code."<= BR>
Justification...

"Authorization servers MAY make authorization codes single use
tokens": this is not a MUST because single use tokens are expensive and slow to implement.  They require synchronous replication of
server-side state.  Because the oauth client and the user who approved=
the request may be in geographically distant locations, this is pretty
much guaranteed to be either slow, or unreliable, or both.  When
things like immediate mode with automatic authorization are used, lots
and lots verification codes are going to be issued for no good reason.
 Server-side storage for those tokens is wasteful, so people are going=
to end up using cryptographic implementations of verification codes.

"The authorization code SHOULD expire shortly after it is issued"= :
this is a good idea because we are passing authorization tokens via
browser redirects, and browser redirects are leaky channels.  If one of these tokens leaks, someone who captures the token can replay it to
the client web site, and the client web site will then happily swap
the code for an access token.  The client web site will then associate=
the victim's access token with the attacker's account.

Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C8628A6C37229eranhueniversecom_-- From beaton@google.com Tue Jul 13 21:32:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787703A681A for ; Tue, 13 Jul 2010 21:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.741 X-Spam-Level: X-Spam-Status: No, score=-105.741 tagged_above=-999 required=5 tests=[AWL=0.236, 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 du+CEMx-6mdC for ; Tue, 13 Jul 2010 21:32:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 5884E3A68CF for ; Tue, 13 Jul 2010 21:32:36 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o6E4WjZe014829 for ; Tue, 13 Jul 2010 21:32:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279081965; bh=vtNpWqOsPEtgbk8lSJK0aKl530U=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=T4TgExZIcB+Q5FWVSQMy+guXA9V1t21vBc3IG7gNlGVWJIpdRleKMPqE234gYuVpS XWsZ1QTWXUoRpEINSnxZw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=QpOkrtrPfTp5sWJ4VjmyMsPPPQHp9vmL4TdCHJTORxz5iPjXz6qCMQAbFsSib80Ig R8xnYPXaf4ZksRVhiWhyw== Received: from pvg7 (pvg7.prod.google.com [10.241.210.135]) by wpaz37.hot.corp.google.com with ESMTP id o6E4Whdt011147 for ; Tue, 13 Jul 2010 21:32:44 -0700 Received: by pvg7 with SMTP id 7so2565018pvg.4 for ; Tue, 13 Jul 2010 21:32:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.233.1 with SMTP id f1mr14762662wfh.169.1279081963689; Tue, 13 Jul 2010 21:32:43 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Tue, 13 Jul 2010 21:32:43 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 21:32:43 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] single use authorization codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 04:32:40 -0000 I'd suggest "authorization server MAY revoke all tokens". Revoking an access token that was just issued is surprisingly tricky. Fast to verify, easy to revoke, scalable: pick two. On Tue, Jul 13, 2010 at 9:26 PM, Eran Hammer-Lahav wr= ote: > How about: > > Authorization codes SHOULD expire shortly after they are issued to > minimize the risk of leaks. =A0Clients MUST NOT reuse authorization > codes. =A0If an authorization code is used more than once, the authorizat= ion > server SHOULD revoke all tokens previously issued based on that > authorization > code. > > EHL > > > On 7/13/10 9:11 PM, "Brian Eaton" wrote: > > Draft 10 currently requires that the authorization code issued for the > web-app profile is a single use token. =A0That won't scale well. > > This got added in draft 4, I'm not sure why. =A0Anybody know...? > > Here's the relevant section: > http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-3 > > "The authorization code SHOULD expire shortly after it is issued. =A0The > authorization server MUST invalidate the authorization code after a > single usage." > > I think better language would be something like this: > > "Under normal circumstances, clients will use the authorization code > immediately after receiving a redirect from the Authorization Server. > Authorization codes SHOULD expire shortly after they are issued to > minimize the risk of leaks. =A0Clients MUST NOT reuse verification > codes. =A0Authorization servers MAY make authorization codes single use > tokens. =A0If an Authorization Server detects multiple attempts to > exchange a single verification code for an access token, the > verification code may have leaked. =A0The Authorization Server MAY > revoke all tokens previously issued based on that verification code." > > Justification... > > "Authorization servers MAY make authorization codes single use > tokens": this is not a MUST because single use tokens are expensive > and slow to implement. =A0They require synchronous replication of > server-side state. =A0Because the oauth client and the user who approved > the request may be in geographically distant locations, this is pretty > much guaranteed to be either slow, or unreliable, or both. =A0When > things like immediate mode with automatic authorization are used, lots > and lots verification codes are going to be issued for no good reason. > =A0Server-side storage for those tokens is wasteful, so people are going > to end up using cryptographic implementations of verification codes. > > "The authorization code SHOULD expire shortly after it is issued": > this is a good idea because we are passing authorization tokens via > browser redirects, and browser redirects are leaky channels. =A0If one > of these tokens leaks, someone who captures the token can replay it to > the client web site, and the client web site will then happily swap > the code for an access token. =A0The client web site will then associate > the victim's access token with the attacker's account. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From wmills@yahoo-inc.com Tue Jul 13 21:49: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 8A82A3A6969 for ; Tue, 13 Jul 2010 21:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.249 X-Spam-Level: X-Spam-Status: No, score=-17.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTYeCJNFKiSU for ; Tue, 13 Jul 2010 21:49:33 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 094CD3A695A for ; Tue, 13 Jul 2010 21:49:30 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6E4nQ99036693; Tue, 13 Jul 2010 21:49:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:return-path:x-originalarrivaltime; b=wFNjuQQbje0ctVSAKfhSLB0+/9ZZNsej6vC0NIL0eiQtW+NAhnNUzrYZUTLenTWc Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 21:49:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB230E.BEFEAD78" Date: Tue, 13 Jul 2010 21:40:54 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6C4D@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] single use authorization codes Thread-Index: AcsjCrJw/YifGdTgTvKNptx+4HxBdQAAflp3AAAkseA= References: From: "William Mills" To: "Eran Hammer-Lahav" , "Brian Eaton" , "OAuth WG" X-OriginalArrivalTime: 14 Jul 2010 04:49:26.0293 (UTC) FILETIME=[EFAF8450:01CB230F] Subject: Re: [OAUTH-WG] single use authorization codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 04:49:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB230E.BEFEAD78 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable That's even worse I think, it's a harder problem. Why do we want to revoke previously issued tokens here? It closes one door but opens a DOS attack. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, July 13, 2010 9:26 PM To: Brian Eaton; OAuth WG Subject: Re: [OAUTH-WG] single use authorization codes =09 =09 How about: =09 Authorization codes SHOULD expire shortly after they are issued to minimize the risk of leaks. Clients MUST NOT reuse authorization codes. If an authorization code is used more than once, the authorization server SHOULD revoke all tokens previously issued based on that authorization code. =09 EHL =09 =09 On 7/13/10 9:11 PM, "Brian Eaton" wrote: =09 =09 Draft 10 currently requires that the authorization code issued for the web-app profile is a single use token. That won't scale well. =09 This got added in draft 4, I'm not sure why. Anybody know...? =09 Here's the relevant section: =09 http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-3 =09 "The authorization code SHOULD expire shortly after it is issued. The authorization server MUST invalidate the authorization code after a single usage." =09 I think better language would be something like this: =09 "Under normal circumstances, clients will use the authorization code immediately after receiving a redirect from the Authorization Server. Authorization codes SHOULD expire shortly after they are issued to minimize the risk of leaks. Clients MUST NOT reuse verification codes. Authorization servers MAY make authorization codes single use tokens. If an Authorization Server detects multiple attempts to exchange a single verification code for an access token, the verification code may have leaked. The Authorization Server MAY revoke all tokens previously issued based on that verification code." =09 Justification... =09 "Authorization servers MAY make authorization codes single use tokens": this is not a MUST because single use tokens are expensive and slow to implement. They require synchronous replication of server-side state. Because the oauth client and the user who approved the request may be in geographically distant locations, this is pretty much guaranteed to be either slow, or unreliable, or both. When things like immediate mode with automatic authorization are used, lots and lots verification codes are going to be issued for no good reason. Server-side storage for those tokens is wasteful, so people are going to end up using cryptographic implementations of verification codes. =09 "The authorization code SHOULD expire shortly after it is issued": this is a good idea because we are passing authorization tokens via browser redirects, and browser redirects are leaky channels. If one of these tokens leaks, someone who captures the token can replay it to the client web site, and the client web site will then happily swap the code for an access token. The client web site will then associate the victim's access token with the attacker's account. =09 Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =09 =09 ------_=_NextPart_001_01CB230E.BEFEAD78 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] single use authorization codes
That's even worse I think, it's a harder = problem.  Why do=20 we want to revoke previously issued tokens here?  It closes one = door but=20 opens a DOS attack.

From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] On Behalf Of Eran=20 Hammer-Lahav
Sent: Tuesday, July 13, 2010 9:26 = PM
To:=20 Brian Eaton; OAuth WG
Subject: Re: [OAUTH-WG] single use=20 authorization codes

How about:

Authorization codes SHOULD = expire=20 shortly after they are issued to
minimize the risk of leaks. =  Clients=20 MUST NOT reuse authorization
codes.  If an authorization code = is used=20 more than once, the authorization
server SHOULD revoke all tokens=20 previously issued based on that=20 authorization
code.

EHL


On 7/13/10 9:11 PM, = "Brian Eaton"=20 <beaton@google.com>=20 wrote:
Draft 10 currently requires that the = authorization=20 code issued for the
web-app profile is a single use token. =  That=20 won't scale well.

This got added in draft 4, I'm not sure = why.=20  Anybody know...?

Here's the relevant section:
http= ://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-3

"The=20 authorization code SHOULD expire shortly after it is issued.=20  The
authorization server MUST invalidate the authorization = code=20 after a
single usage."

I think better language would be = something=20 like this:

"Under normal circumstances, clients will use the=20 authorization code
immediately after receiving a redirect from = the=20 Authorization Server.
Authorization codes SHOULD expire shortly = after=20 they are issued to
minimize the risk of leaks.  Clients MUST = NOT=20 reuse verification
codes.  Authorization servers MAY make=20 authorization codes single use
tokens.  If an Authorization = Server=20 detects multiple attempts to
exchange a single verification code = for an=20 access token, the
verification code may have leaked.  The=20 Authorization Server MAY
revoke all tokens previously issued = based on=20 that verification = code."

Justification...

"Authorization=20 servers MAY make authorization codes single use
tokens": this is = not a=20 MUST because single use tokens are expensive
and slow to = implement.=20  They require synchronous replication of
server-side state.=20  Because the oauth client and the user who approved
the = request may=20 be in geographically distant locations, this is pretty
much = guaranteed to=20 be either slow, or unreliable, or both.  When
things like = immediate=20 mode with automatic authorization are used, lots
and lots = verification=20 codes are going to be issued for no good = reason.
 Server-side=20 storage for those tokens is wasteful, so people are going
to end = up using=20 cryptographic implementations of verification codes.

"The=20 authorization code SHOULD expire shortly after it is = issued":
this is a=20 good idea because we are passing authorization tokens via
browser = redirects, and browser redirects are leaky channels.  If = one
of=20 these tokens leaks, someone who captures the token can replay it = to
the=20 client web site, and the client web site will then happily = swap
the code=20 for an access token.  The client web site will then = associate
the=20 victim's access token with the attacker's=20 = account.

Cheers,
Brian
_____________________________________= __________
OAuth=20 mailing list
OAuth@ietf.org
https://www.ietf.org= /mailman/listinfo/oauth

------_=_NextPart_001_01CB230E.BEFEAD78-- From torsten@lodderstedt.net Tue Jul 13 21:59:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC2B23A6976 for ; Tue, 13 Jul 2010 21:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[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 6KGWPKJ4e1Il for ; Tue, 13 Jul 2010 21:59:00 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id 831203A6969 for ; Tue, 13 Jul 2010 21:59:00 -0700 (PDT) Received: from [79.253.58.218] (helo=[192.168.71.41]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OYu3n-0000z9-Iu; Wed, 14 Jul 2010 06:59:07 +0200 References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Wed, 14 Jul 2010 06:58:26 +0200 To: Brian Eaton X-Df-Sender: 141509 Cc: Kris Selden , OAuth WG Subject: Re: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 04:59:01 -0000 We plan to issue new refresh tokens for certain clients only (mobile, deskto= p), it's part of the client-related policy. So the behavior for a particular= client is predictable. Regards, Torsten. Am 14.07.2010 um 03:07 schrieb Brian Eaton : > Kris - >=20 > Thanks for pointing back to where this started! >=20 > I more or less agree with what Allen said in response to Torsten's > proposal: http://www.ietf.org/mail-archive/web/oauth/current/msg02295.html= . > The devil is in the details. >=20 > I'd be interested in tackling client secret rotation at the same time > as handling refresh token rotation... they are similar problems. >=20 > BUT, if we do this, we should do it reasonably well. In particular, I > think we'd need: > - a way for clients to opt-in to this, probably when they first get a > refresh token > - a system that worked for distributed clients > - a system that allowed rotation of the client secret >=20 > I don't think any of that would be impractical, long-term. Windows > and AD have had automatic rotation of kerberos service keys for a > while, for example. >=20 > And here's a more far-fetched idea... installed applications could > self-generate public/private key pairs, which could then be used to > authenticate to the authorization server using something like Yaron's > recent proposal for client assertion authentication. >=20 > Cheers, > Brian >=20 > On Tue, Jul 13, 2010 at 5:55 PM, Kris Selden wrote= : >> Torsten Lodderstedt >> [OAUTH-WG] Refresh tokens security enhancement >> http://www.ietf.org/mail-archive/web/oauth/current/msg02292.html >>=20 >> Eran Hammer-Lahav >> Re: [OAUTH-WG] Refresh tokens security enhancement >> http://www.ietf.org/mail-archive/web/oauth/current/msg02390.html >>=20 >> On Jul 13, 2010, at 7:04 AM, Eran Hammer-Lahav wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On 7/12/10 10:36 PM, "Brian Eaton" wrote: >>>=20 >>>> Draft 10 has the following sentence in section 4.1.4: >>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4 >>>>=20 >>>> "The authorization server MAY issue a new refresh token." >>>=20 >>> The capability was there since -02. >>>=20 >>> -04 added the following text in an attempt to clarify how the refresh_to= ken >>> output can be used (returning a refresh token was briefly discussed as p= art >>> of the general idea of always allowing a refresh token in token response= s): >>>=20 >>> The authorization server >>> MAY issue a new refresh token in which case the client MUST NOT use >>> the previous refresh token and replace it with the newly issued >>> refresh token. >>>=20 >>> In -10 I dropped the restriction because people expressed a general issu= e >>> with having to revoke tokens. >>>=20 >>>> That carries a surprising amount of baggage. I suggest removing the >>>> sentence, or changing it to MUST NOT, pending a discussion of the use >>>> cases for issuing new refresh tokens. >>>>=20 >>>> Does anyone remember why that sentence got added to the spec? >>>>=20 >>>> There are two reasons I can see for issuing new refresh tokens: >>>> 1) secrets are like underwear, change them frequently >>>> 2) someone has a cryptographically implemented refresh token that >>>> needs to be re-signed or re-issued >>>>=20 >>>> I'm pretty sure anyone issuing cryptographic refresh tokens is crazy, >>>> these pretty much have to be backed by server-side state or there is >>>> no way to run your system. So I'm going to ignore that possibility, >>>> and guess that someone was interested in changing secrets... >>>=20 >>> There was no requirement to support changing refresh tokens. If there is= no >>> interest in this, I suggest we forbid it (otherwise all clients will nee= d to >>> accommodate the chance of a new refresh token, and then will need guidel= ines >>> on how to handle it). >>>=20 >>>> So if we want to issue new refresh tokens because we like to change >>>> secrets, we should cover: >>>> - whether existing refresh tokens are revoked. (I'd vote for MUST be r= evoked) >>>=20 >>> I agree. >>>=20 >>>> - the minimum latency between issuing a new refresh token and revoking >>>> the old one. (I'd vote for minimum latency measured in hours or >>>> longer. Clients that have cached refresh tokens need to refresh their >>>> cache within this time period, or they're borked.) >>>> - the maxium latency for revoking the old token. (I'd vote for >>>> maximum latency measured in hours or days, just for security reasons. >>>> But I can't think of what would break if servers ignored this advice.) >>>=20 >>> Why is this required? Can it be specified as a general recommendation? >>>=20 >>> EHL >>>=20 >>>> Cheers, >>>> Brian >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >>=20 From naitiks@gmail.com Tue Jul 13 22:58: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 8ECE03A680A for ; Tue, 13 Jul 2010 22:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+T3R9W-Q0RR for ; Tue, 13 Jul 2010 22:58:55 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 466D23A67FB for ; Tue, 13 Jul 2010 22:58:55 -0700 (PDT) Received: by pxi20 with SMTP id 20so3106868pxi.31 for ; Tue, 13 Jul 2010 22:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=hzatA2lvfLO28WQ8G2k14odr7IJYz9nb0vRTnqXyr10=; b=C/rB4cj6P+8GawxpcMSiAFw475rdg07vdM0cB5G+gGAq7L9JzOKkOHOjx76L/3dVp8 b97TOW0VYPwD81vI6KJlPxCPe0nQuNKF++5Pyso/Sdngy94oxciv2O/rhIz0TYO5nfAk IrZtQLDpYIVqJVZtT+SsB/xA/ueQGGCvlQvK4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Aa9e9IFD23j3ChpT3xBaPDgZU5UvM1/v0apKbq3Oms52dW6minDfdIdS1GDABpyU4K O3fb0soXaCNiNY6BTLH5A7elpRCKvsdOvro08w4Ev1xb/UASC/zVpcgNZokFQn4sf6K2 Mc+psoDY7Nq8t5kIky53YKORqBTncYHdAsuII= Received: by 10.142.140.18 with SMTP id n18mr19948265wfd.349.1279087142322; Tue, 13 Jul 2010 22:59:02 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.142.203.12 with HTTP; Tue, 13 Jul 2010 22:58:42 -0700 (PDT) In-Reply-To: References: From: Naitik Shah Date: Tue, 13 Jul 2010 22:58:42 -0700 X-Google-Sender-Auth: TZWxybxivQXgOWBwJkyWlMO96LI Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000e0cd18572c14435048b52aed2 Cc: OAuth WG Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 05:58:56 -0000 --000e0cd18572c14435048b52aed2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks! That sounds great. On Tue, Jul 13, 2010 at 3:00 PM, Eran Hammer-Lahav wro= te: > This is clearly a third flow - hybrid (of user-agent and web-server) - an= d > not just a variant of the user-agent flow. It should be presented with it= s > own flow diagram and description. I also think the user-agent and > web-server > flow names are misleading. They need to be replaced with more descriptive > names. Something like (I don=C2=B9t like these, just trying to demonstrat= e): > > Web-server --> 2 step flow (get code, get token) > User-agent --> direct flow (get token) > Hybrid --> hybrid flow (get code and token, get token) > > In an attempt to accommodate Brian's request for more concentrated flow > descriptions, I am working on coming up with come middle ground between -= 05 > and -10. > > ---- > > As for the specification of the end-user authorization endpoint: > > Please answer this based on actual use cases. When returning parameters > using the redirection URI call, which of these combinations make sense? > > | Code | Token | Code & Token > ---------+------+-------+-------------- > Fragment | a | 1 | 3 > Query | 2 | b | c > Split* | n/a | n/a | d > > * token in fragment, code in query > > Known use cases: > > 1 - current user-agent flow > 2 - current web-server flow > 3 - as described by Brian and Naitik > > Questionable use cases: > > a - > b - > c - > d - current -10 code-and-token proposal > > EHL > > > On 7/13/10 2:27 PM, "Naitik Shah" wrote: > > > On Tue, Jul 13, 2010 at 2:06 PM, Eran Hammer-Lahav > > wrote: > >> This looks reasonable, however, I am no longer see the value in the > hybrid > >> mode of token and code. If the code is passed in the fragment, the > client has > >> to pass it to the server. If that is the case, why can=C2=B9t the serv= er > reply > >> back with the access token? Is the entire purpose just a performance > >> optimization so the client doesn=C2=B9t have to wait for the server re= sponse > >> before it has an access token? > >> > > > > I think there are two use cases here, and they are not mutually > exclusive. > > Some apps are mostly just server side, and would end up doing a full pa= ge > > refresh, and here the code in the query param would probably be > acceptable. > > Some apps are mostly just client side, and here the code is irrelevant > and the > > access token in the fragment is all that matters. But we also have > hybrids > > where we want the code in a cookie/JS callback, and we'll also use the > access > > token on the client to dynamically update the UI by accessing some > protected > > data (this is what the Data enabled XFBML tags do in the Facebook JS SD= K > for > > instance). While the server can do the code to access_token exchange, i= t > can't > > return it to the JS safely if it does not support https. Even if it did= , > it > > would mean more overhead for the developer to build an endpoint that do= es > this > > work and cooperates with a JS SDK which wants the access_token for maki= ng > API > > calls. > > > > > > -Naitik > > > > > > --000e0cd18572c14435048b52aed2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks! That sounds great.

On Tue, Jul 13= , 2010 at 3:00 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
This is clearly a third flow - hybrid (of user-agent and web-server) - and<= br> not just a variant of the user-agent flow. It should be presented with its<= br> own flow diagram and description. I also think the user-agent and web-serve= r
flow names are misleading. They need to be replaced with more descriptive names. Something like (I don=C2=B9t like these, just trying to demonstrate)= :

Web-server --> 2 step flow (get code, get token)
User-agent --> direct flow (get token)
Hybrid --> hybrid flow (get code and token, get token)

In an attempt to accommodate Brian's request for more concentrated flow=
descriptions, I am working on coming up with come middle ground between -05=
and -10.

----

As for the specification of the end-user authorization endpoint:

Please answer this based on actual use cases. When returning parameters
using the redirection URI call, which of these combinations make sense?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Code | Token | Code & Token
---------+------+-------+--------------
Fragment | =C2=A0a =C2=A0 | =C2=A0 1 =C2=A0 | =C2=A0 3
Query =C2=A0 =C2=A0| =C2=A02 =C2=A0 | =C2=A0 b =C2=A0 | =C2=A0 c
Split* =C2=A0 | n/a =C2=A0| =C2=A0n/a =C2=A0| =C2=A0 d

* token in fragment, code in query

Known use cases:

1 - current user-agent flow
2 - current web-server flow
3 - as described by Brian and Naitik

Questionable use cases:

a -
b -
c -
d - current -10 code-and-token proposal

EHL


On 7/13/10 2:27 PM, "Naitik Shah" <n@daaku.org> wrote:

> On Tue, Jul 13, 2010 at 2:06 PM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>> This looks reasonable, however, I am no longer see the value in th= e hybrid
>> mode of token and code. If the code is passed in the fragment, the= client has
>> to pass it to the server. If that is the case, why can=C2=B9t the = server reply
>> back with the access token? Is the entire purpose just a performan= ce
>> optimization so the client doesn=C2=B9t have to wait for the serve= r response
>> before it has an access token?
>>
>
> I think there are two use cases here, and they are not mutually exclus= ive.
> Some apps are mostly just server side, and would end up doing a full p= age
> refresh, and here the code in the query param would probably be accept= able.
> Some apps are mostly just client side, and here the code is irrelevant= and the
> access token in the fragment is all that matters. But we also have hyb= rids
> where we want the code in a cookie/JS callback, and we'll also use= the access
> token on the client to=C2=A0dynamically=C2=A0update the UI by accessin= g some protected
> data (this is what the Data enabled XFBML tags do in the Facebook JS S= DK for
> instance). While the server can do the code to access_token exchange, = it can't
> return it to the JS safely if it does not support https. Even if it di= d, it
> would mean more overhead for the developer to build an endpoint that d= oes this
> work and cooperates with a JS SDK which wants the access_token for mak= ing API
> calls.
>
>
> -Naitik
>
>


--000e0cd18572c14435048b52aed2-- From eran@hueniverse.com Wed Jul 14 05:10: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 08B313A6986 for ; Wed, 14 Jul 2010 05:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 v6bTg2g0npWS for ; Wed, 14 Jul 2010 05:10:09 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9E6D53A6825 for ; Wed, 14 Jul 2010 05:10:09 -0700 (PDT) Received: (qmail 16041 invoked from network); 14 Jul 2010 12:10:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jul 2010 12:10:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 14 Jul 2010 05:10:17 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 14 Jul 2010 05:10:14 -0700 Thread-Topic: Quick survey: fragment vs. query Thread-Index: AcsjTYO/D1HEd/0XFEy3vjXZwJopfQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 12:10:11 -0000 Please answer this based on actual use cases. When returning parameters using the redirection URI call, which of these combinations make sense? | Code | Token | Code & Token ---------+------+-------+-------------- Fragment | a | 1 | 3 Query | 2 | b | c Split* | n/a | n/a | d * token in fragment, code in query Known use cases: 1 - current user-agent flow 2 - current web-server flow 3 - as described by Brian and Naitik Do you need any of these? a -=20 b - c -=20 d - current -10 code-and-token proposal EHL From andrewarnott@gmail.com Wed Jul 14 08:25:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11563A69C0 for ; Wed, 14 Jul 2010 08:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsL6BCXE+t5B for ; Wed, 14 Jul 2010 08:25:00 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id AEA073A6978 for ; Wed, 14 Jul 2010 08:25:00 -0700 (PDT) Received: by gwj19 with SMTP id 19so1848557gwj.31 for ; Wed, 14 Jul 2010 08:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xfqNAfiGIfZl3FoGQSH/spQU9TvbcQxLHtZhig2CtU4=; b=RdV204N2Zs0gec0jTfEIbkzdVtJkBSgPfSCbwkqkyMlWmGQaaVUr+b1andNNu16hDf 38Sb7x00yLk+doHFvJsXSOvjtMZGYdpIJr3eTbQpVE980HcAkXxxW7uE0DSEgd0buFMH z2Dh2fgxrGEXiV924SyTJkUErFs7ZS+75xCdU= 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=P/PV1umz/nOz90SErE8theVrIKBX/OadF/ymK0ohqSjfo8TPl185Xc/B4e2NuYWqLe 9Jb2KYHJr2kyBje1T7t5pbvUs36W7gBdlUDP41wJguZOYxl9T/Lu3uJYp1eHFzfLNwNh Ya91T2P8FR0UYZOd1K3DaOlN9QaBidj/M8FLw= MIME-Version: 1.0 Received: by 10.150.150.2 with SMTP id x2mr7950150ybd.277.1279121104945; Wed, 14 Jul 2010 08:25:04 -0700 (PDT) Received: by 10.150.92.8 with HTTP; Wed, 14 Jul 2010 08:25:04 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Jul 2010 08:25:04 -0700 Message-ID: From: Andrew Arnott To: Brian Eaton Content-Type: multipart/alternative; boundary=000e0cd70e1215c3c6048b5a9746 Cc: oauth Subject: Re: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 15:25:01 -0000 --000e0cd70e1215c3c6048b5a9746 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 13, 2010 at 2:59 PM, Brian Eaton wrote: > the question is what happens if both the > signing key and the token database get compromised. > > Now that I think of it, you may have issues if the signing key alone > is compromised. It depends how much other entropy you've added to the > tokens... > Um, if the signing key is lost, you're sunk. Forget about the database, with the signing key you can forge your own tokens till doomsday (which will come much more quickly). The keys are definitely the most confidential part of the system, naturally. --000e0cd70e1215c3c6048b5a9746 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 13, 2010 at 2:59 PM, Brian Eaton <beaton@google.com> wrote:
=A0the question is what happens if both the
signing key and the token database get compromised.

Now that I think of it, you may have issues if the signing key alone
is compromised. =A0It depends how much other entropy you've added to th= e
tokens...

Um, if the signing key is lost, you're sunk= . =A0Forget about the database, with the signing key you can forge your own= tokens till doomsday (which will come much more quickly). =A0The keys are = definitely the most confidential part of the system, naturally.
--000e0cd70e1215c3c6048b5a9746-- From jricher@mitre.org Wed Jul 14 08:38: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 8302E3A68DC for ; Wed, 14 Jul 2010 08:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 76ViWMBpdHEP for ; Wed, 14 Jul 2010 08:38:20 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id A4D8D3A6981 for ; Wed, 14 Jul 2010 08:38:19 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6EFcSJB019132 for ; Wed, 14 Jul 2010 11:38:28 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6EFcRTB019129; Wed, 14 Jul 2010 11:38:27 -0400 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, 14 Jul 2010 11:38:27 -0400 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: References: <1278938907.2445.107.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Wed, 14 Jul 2010 11:38:27 -0400 Message-ID: <1279121907.18579.37.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] POST-only on token endpoint? [was: temperature check: json input to token endpoint] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 15:38:21 -0000 Again, it's a good security optimization, and it makes sense for large internet providers. But I don't think this argument holds for small intranet providers, where there won't be proxies in the middle and many of the clients will largely be non-browser-based and cacheless anyway. At least, that's how it will be in most of my deployments. I think it would be better to call out the cache/proxy/leakage issues directly, recommend POST for most instances to address these concerns, but say that a server MAY accept GET requests with query parameters on the token endpoint. -- Justin On Mon, 2010-07-12 at 09:56 -0400, Eran Hammer-Lahav wrote: > Proxies and caches. > > EHL > > > > On Jul 12, 2010, at 8:48, "Justin Richer" wrote: > > > I'd like to keep form-encoded inputs. I think it makes sense to use a > > well-established key-value mechanism, and the asymmetry at play here is > > what the web is made of (post a form, get HTML/XML/JSON/whatever). > > > > Along those lines, I'd actually like to relax the restriction of using > > "POST" and allow for query arguments on the token endpoint as well. Long > > ago it was argued that the POST requirement was to keep query parameters > > from leaking into server logs. That's a fine implementation-specific > > security optimization, but I don't think it belongs mandated in the > > spec. As a practical matter, I know that for most of my implementations > > (on small single servers), anyone who's got access to the web server > > logs have access to the tokens in the database. > > > > Were there other reasons for mandating POST here that I'm forgetting? > > > > -- Justin > > > > On Sun, 2010-07-11 at 00:31 -0400, Brian Eaton wrote: > >> Hey folks - > >> > >> Today, the token endpoint takes form-encoded inputs, and sends JSON > >> outputs. This requires developers to use both form encoding and a > >> json parser. > >> > >> Many services expose symmetric APIs for non-browser endpoints. For > >> example, an API call normally takes JSON input and returns JSON > >> output. > >> > >> What do people think about having the token endpoint accept and return JSON? > >> > >> Cheers, > >> Brian > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Wed Jul 14 09:40: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 1B6763A65A5 for ; Wed, 14 Jul 2010 09:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.861 X-Spam-Level: X-Spam-Status: No, score=-101.861 tagged_above=-999 required=5 tests=[AWL=0.116, 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 nAhCjDMCxKIf for ; Wed, 14 Jul 2010 09:40:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 2920A3A68DD for ; Wed, 14 Jul 2010 09:40:13 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o6EGeMFv015791 for ; Wed, 14 Jul 2010 09:40:22 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279125623; bh=WyrQG2NUSNYbBJC5z9ZeV2uh/iY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=uw81M/GCTrlLlwM7LTjJb4VX7hAe91wQq/LURG2qypQlS7mvtwFNbFdxzGJeLFLRK 1B7Y9t0lp6kuqhSfyDf1A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=f7+eQNZtjNSf2iAYsdNB2YOSXAmUlB9lMp5RlFJgFOxC8L0flRlx91Vz4H0t7UsMq lkZRndcVH1O1rLmbacIBw== Received: from pxi8 (pxi8.prod.google.com [10.243.27.8]) by wpaz17.hot.corp.google.com with ESMTP id o6EGeKQ4009284 for ; Wed, 14 Jul 2010 09:40:21 -0700 Received: by pxi8 with SMTP id 8so50640pxi.13 for ; Wed, 14 Jul 2010 09:40:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.164.3 with SMTP id m3mr21297669wfe.294.1279125616546; Wed, 14 Jul 2010 09:40:16 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Wed, 14 Jul 2010 09:40:15 -0700 (PDT) In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6C4D@SNV-EXVS08.ds.corp.yahoo.com> References: <012AB2B223CB3F4BB846962876F47217059B6C4D@SNV-EXVS08.ds.corp.yahoo.com> Date: Wed, 14 Jul 2010 09:40:15 -0700 Message-ID: From: Brian Eaton To: William Mills Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] single use authorization codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 16:40:16 -0000 On Tue, Jul 13, 2010 at 9:40 PM, William Mills wrote: > That's even worse I think, it's a harder problem. Revoking previously issued refresh tokens is pretty easy. Revoking the corresponding access tokens is hard in general, but in some environments is feasible. > Why do we want to revoke previously issued tokens here? The threat model is an attacker who somehow grabs a verification code from a user on the fly, then races to be the first one to exchange the verification code with the authorization server. The idea is to make sure that if there is a race, the attacker always loses eventually. This is sort of a remote scenario, though. In practice if verification codes leak, we're going to have trouble keeping the protocol secure. > It closes one door but opens a DOS attack. What's the DOS attack? From beaton@google.com Wed Jul 14 09:49:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6CA3A69B6 for ; Wed, 14 Jul 2010 09:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.75 X-Spam-Level: X-Spam-Status: No, score=-105.75 tagged_above=-999 required=5 tests=[AWL=0.227, 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 IPdtFRUwtvdF for ; Wed, 14 Jul 2010 09:49:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E31213A659C for ; Wed, 14 Jul 2010 09:49:43 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id o6EGnrE9011073 for ; Wed, 14 Jul 2010 09:49:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279126193; bh=wAi6xCK2QDdukEZDGevq/ZoRkx0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=cWMdlFuYFzXeNdczZqgu+/JltP8VA3Buy5TJ6WKPjbZhF3/WW1swxugxQ8fR8sjax dt/3wvlK+X8I4P48/PKFQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=mg5Go8wk+btRpVaWnP2xtMzLyQeCUKDJ1ISpnKO1FJhZbdxy9vcw/Od85atJsBNng L/Iz2TU2hc9uOd1V3oEFA== Received: from pxi7 (pxi7.prod.google.com [10.243.27.7]) by hpaq12.eem.corp.google.com with ESMTP id o6EGnpKv029243 for ; Wed, 14 Jul 2010 09:49:51 -0700 Received: by pxi7 with SMTP id 7so46175pxi.28 for ; Wed, 14 Jul 2010 09:49:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.211.6 with SMTP id j6mr21512666wfg.34.1279126187461; Wed, 14 Jul 2010 09:49:47 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Wed, 14 Jul 2010 09:49:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Jul 2010 09:49:47 -0700 Message-ID: From: Brian Eaton To: Andrew Arnott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth Subject: Re: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 16:49:44 -0000 On Wed, Jul 14, 2010 at 8:25 AM, Andrew Arnott wro= te: > Um, if the signing key is lost, you're sunk. =A0Forget about the database= , > with the signing key you can forge your own tokens till doomsday (which w= ill > come much more quickly). =A0The keys are definitely the most confidential= part > of the system, naturally. It doesn't have to be that way. Refresh tokens can be backed by server-side state and stored as one-way hashes in a database. So no signing key involved there. And access token signing keys can be rotated quickly, so that even if they leak, you can recover quickly. Cheers, Brian From beaton@google.com Wed Jul 14 09:54: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 C00863A6927 for ; Wed, 14 Jul 2010 09:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.757 X-Spam-Level: X-Spam-Status: No, score=-105.757 tagged_above=-999 required=5 tests=[AWL=0.220, 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 p1PCKVKOICjD for ; Wed, 14 Jul 2010 09:54:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id EBD1F3A6870 for ; Wed, 14 Jul 2010 09:54:29 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o6EGsdP3003762 for ; Wed, 14 Jul 2010 09:54:39 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279126479; bh=s1bP5vpWZ3HAlW9MiMDrFUW2jI4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=YQBAdzHDPUyqyC17EKZEeJOW6aBn44UuM3PAGJh/l4wCsE+XogMfWO1pdR9HmI/KL lWP1TBgbDf/tSTXMA/n4w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=oSPRWeKRjvO3daOpiO8nituLNjSnb2zP7tOwYFFE+1LJzS+YWHWzyOUYT7xS4HaZx PzAqGbI896D6rwu4/didw== Received: from pwi8 (pwi8.prod.google.com [10.241.219.8]) by wpaz24.hot.corp.google.com with ESMTP id o6EGsVUP011023 for ; Wed, 14 Jul 2010 09:54:38 -0700 Received: by pwi8 with SMTP id 8so6911205pwi.0 for ; Wed, 14 Jul 2010 09:54:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.172.3 with SMTP id u3mr21685842wfe.51.1279126478237; Wed, 14 Jul 2010 09:54:38 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Wed, 14 Jul 2010 09:54:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Jul 2010 09:54:37 -0700 Message-ID: From: Brian Eaton To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Kris Selden , OAuth WG Subject: Re: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 16:54:30 -0000 On Tue, Jul 13, 2010 at 9:58 PM, Torsten Lodderstedt wrote: > We plan to issue new refresh tokens for certain clients only (mobile, desktop), > it's part of the client-related policy. So the behavior for a particular client is predictable. Nice. Would you be willing to expand on the current spec language a bit, to explain the use cases, and offer more normative language about how clients should handle refresh token exchange? This is a cool feature, but the current language is kind of vague. Cheers, Brian From beaton@google.com Wed Jul 14 10:04:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5313E3A6B73 for ; Wed, 14 Jul 2010 10:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.869 X-Spam-Level: X-Spam-Status: No, score=-101.869 tagged_above=-999 required=5 tests=[AWL=0.108, 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 TwFYiaPZpYyz for ; Wed, 14 Jul 2010 10:04:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 548E23A6B78 for ; Wed, 14 Jul 2010 10:04:39 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o6EH4maP015618 for ; Wed, 14 Jul 2010 10:04:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279127088; bh=yL8s+tssk4kZFL5oCloc7cnG+B8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=BmKwaPxZLImMQm+70x/zNoA7JJmNu0nNh1Dmd9ntLRwAaIHGQ7qkyifkZRwDX+err HBbzHV1snUINfihAHOBDg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=SDVYkpOs1E4NxSZiUIE2WNj7g4fsxMeZIgcVNOEKhj4RRAtZK8mQEhY4raiNZUnKg 4Q+eOir6UKU4h96QudLgw== Received: from pzk33 (pzk33.prod.google.com [10.243.19.161]) by wpaz5.hot.corp.google.com with ESMTP id o6EH4kFX017009 for ; Wed, 14 Jul 2010 10:04:47 -0700 Received: by pzk33 with SMTP id 33so1721097pzk.28 for ; Wed, 14 Jul 2010 10:04:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.211.6 with SMTP id j6mr21545138wfg.34.1279127081256; Wed, 14 Jul 2010 10:04:41 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Wed, 14 Jul 2010 10:04:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Jul 2010 10:04:37 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 17:04:40 -0000 I can't parse this diagam, but here's my take: - web server flow should always return just a code. parameter always goes in the query string it would be sort of reasonable to have the code exchange return just an access token, instead of a refresh token and an access token. Or a refresh token with a shorter lifetime than indefinite. - user-agent flow can reasonably return either just a token, or a token and a code both parameters always go in the fragment, to avoid busting the browser = cache same comments about lifetime of refresh tokens... Cheers, Brian On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav wr= ote: > Please answer this based on actual use cases. When returning parameters > using the redirection URI call, which of these combinations make sense? > > =A0 =A0 =A0 =A0 | Code | Token | Code & Token > ---------+------+-------+-------------- > Fragment | =A0a =A0 | =A0 1 =A0 | =A0 3 > Query =A0 =A0| =A02 =A0 | =A0 b =A0 | =A0 c > Split* =A0 | n/a =A0| =A0n/a =A0| =A0 d > > * token in fragment, code in query > > Known use cases: > > 1 - current user-agent flow > 2 - current web-server flow > 3 - as described by Brian and Naitik > > Do you need any of these? > > a - > b - > c - > d - current -10 code-and-token proposal > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From recordond@gmail.com Wed Jul 14 11:11: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 63B7F3A69E0 for ; Wed, 14 Jul 2010 11:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.310, 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 v2N78DxWiigk for ; Wed, 14 Jul 2010 11:11:03 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6DEFE3A6A9C for ; Wed, 14 Jul 2010 11:11:01 -0700 (PDT) Received: by iwn38 with SMTP id 38so29321iwn.31 for ; Wed, 14 Jul 2010 11:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=olmy8YjGmuTM8X/CGln2EBOKE02ZLZG2HowxqENbaVA=; b=QXDG7/nHrF+JvqtoWAQ759dq89MAD7iAH9c27lEZq2IQbiTMKlSm3xtHxVChQVLUTy GFbkdX1sl7pj9kWlsOPxg1VUClJjQpZcz4GhR8HDgtDs733NC9wXuRm3zScEShgLjwz6 jaqaGqMnzS1UdxZyaY6zOjkzQjRcLG/Hmsy1c= 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=xSSCACFzLPO4XgNGDFJh8Lf7/Z0w95HkGLZdKxesNfICDMAjBgY39HHRqXxlZLREnH Fgaqlycab5O5P5OyyvZHbmfqoY/8if0J3BhKlmJVTt86d7BskVo7nU0DkKs0BCudDWgG BT+JbayfnYOFIC1qQk1QwLp5QrUlLRyjJQG9A= MIME-Version: 1.0 Received: by 10.231.166.9 with SMTP id k9mr15830125iby.127.1279131071236; Wed, 14 Jul 2010 11:11:11 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Wed, 14 Jul 2010 11:11:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Jul 2010 11:11:11 -0700 Message-ID: From: David Recordon To: Brian Eaton Content-Type: multipart/alternative; boundary=005045013dcc1f4c3c048b5ce927 Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 18:11:14 -0000 --005045013dcc1f4c3c048b5ce927 Content-Type: text/plain; charset=ISO-8859-1 I caught up on the thread and with Luke yesterday afternoon and am fine with the user-agent flow using the fragment in the token and code case. On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton wrote: > I can't parse this diagam, but here's my take: > > - web server flow should always return just a code. > parameter always goes in the query string > it would be sort of reasonable to have the code exchange return > just an access token, instead of a refresh token and an access token. > Or a refresh token with a shorter lifetime than indefinite. > > - user-agent flow can reasonably return either just a token, or a > token and a code > both parameters always go in the fragment, to avoid busting the browser > cache > same comments about lifetime of refresh tokens... > > Cheers, > Brian > > On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav > wrote: > > Please answer this based on actual use cases. When returning parameters > > using the redirection URI call, which of these combinations make sense? > > > > | Code | Token | Code & Token > > ---------+------+-------+-------------- > > Fragment | a | 1 | 3 > > Query | 2 | b | c > > Split* | n/a | n/a | d > > > > * token in fragment, code in query > > > > Known use cases: > > > > 1 - current user-agent flow > > 2 - current web-server flow > > 3 - as described by Brian and Naitik > > > > Do you need any of these? > > > > a - > > b - > > c - > > d - current -10 code-and-token proposal > > > > 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 > --005045013dcc1f4c3c048b5ce927 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I caught up on the thread and with Luke yesterday afternoon and am fine wit= h the user-agent flow using the fragment in the token and code case.

On Wed, Jul 14, 2010 at 10:04 AM, Brian Ea= ton <beaton@googl= e.com> wrote:
I can't parse this diagam, but here'= ;s my take:

- web server flow should always return just a code.
=A0 parameter always goes in the query string
=A0 it would be sort of reasonable to have the code exchange return
just an access token, instead of a refresh token and an access token.
Or a refresh token with a shorter lifetime than indefinite.

- user-agent flow can reasonably return either just a token, or a
token and a code
=A0 both parameters always go in the fragment, to avoid busting the browse= r cache
=A0 same comments about lifetime of refresh tokens...

Cheers,
Brian

On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> Please answer this based on actual use cases. When returning parameter= s
> using the redirection URI call, which of these combinations make sense= ?
>
> =A0 =A0 =A0 =A0 | Code | Token | Code & Token
> ---------+------+-------+--------------
> Fragment | =A0a =A0 | =A0 1 =A0 | =A0 3
> Query =A0 =A0| =A02 =A0 | =A0 b =A0 | =A0 c
> Split* =A0 | n/a =A0| =A0n/a =A0| =A0 d
>
> * token in fragment, code in query
>
> Known use cases:
>
> 1 - current user-agent flow
> 2 - current web-server flow
> 3 - as described by Brian and Naitik
>
> Do you need any of these?
>
> a -
> b -
> c -
> d - current -10 code-and-token proposal
>
> EHL
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--005045013dcc1f4c3c048b5ce927-- From rrichards@cdatazone.org Wed Jul 14 11:46:06 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C983A69DE for ; Wed, 14 Jul 2010 11:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.414 X-Spam-Level: * X-Spam-Status: No, score=1.414 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FRT_BELOW2=2.154] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zQ0xJQ1+9WA for ; Wed, 14 Jul 2010 11:46:06 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by core3.amsl.com (Postfix) with ESMTP id C51933A69D9 for ; Wed, 14 Jul 2010 11:46:05 -0700 (PDT) Received: from [67.158.171.203] (helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1OZ6y7-0008Ba-41; Wed, 14 Jul 2010 18:46:07 +0000 Message-ID: <4C3E05EE.4050903@cdatazone.org> Date: Wed, 14 Jul 2010 14:46:06 -0400 From: Rob Richards User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Marius Scurtescu References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2DC7C5.2090009@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F108B.70504@cdatazone.org> <20100708110542.150740@gmx.net> <4C3707BD.6070201@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP2Go-MailScanner-Information: Please contact support@smtp2go.com for more information X-SMTP2Go-MailScanner-ID: 1OZ6y7-0008Ba-41 X-SMTP2Go-MailScanner: Found to be clean X-SMTP2Go-MailScanner-From: rrichards@cdatazone.org Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 18:46:06 -0000 Finally getting a chance to catchup and respond to this thread. Marius Scurtescu wrote: > See comments bellow... > > > On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia wrote: > >> Hallo Marius, >> >> thanks for your statement. >> Your idea of a migration flow is quite good and necessary. >> >> But I still doubt, if the work and effort should be investigated to spare >> the user from some interaction (authentication and user consent). >> > > It all depends for how many users does the client have OAuth 1 tokens. > Asking users to re-approve will confuse them and I guess many will not > do it, > I think the user should not be excluded from this interaction and should be required to re-approve. IMO they should be involved as its also informational to know that the client they have previously authorized is now requesting new credentials under a different security scheme. The user should be the one to decide whether or not they want to allow this. When it comes right down to it the only concrete thing I can think of when migrating from 1.0 to 2.0 is the need to determine which version is being used at the resource endpoint. For most clients moving from 1.0 to 2.0 they will most likely just create the next version of their client/app with 2.0 support and completely drop 1.0 support rather than going through any migration flow. More work that they don't need to deal with so why would they. I can envision a SP providing support for both 1.0 and 2.0 with an end of life to 1.0 support. This will give the client developers enough time to migrate and distribute their client/apps. As far as the version determination on the endpoint, this is really just a paragraph of text and seems a bit overkill to put into its own proposal when it could easily be handled even as an appendix in the core 2.0 spec. Rob From naitiks@gmail.com Wed Jul 14 11:48: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 BE6333A6A76 for ; Wed, 14 Jul 2010 11:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNrB56HDNX7Y for ; Wed, 14 Jul 2010 11:48:55 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 40EDF3A6A72 for ; Wed, 14 Jul 2010 11:48:55 -0700 (PDT) Received: by iwn38 with SMTP id 38so64167iwn.31 for ; Wed, 14 Jul 2010 11:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=VXPiiN2TcS+Lh9pl5UCNgNRnny8XiZfSmf2JHNIAOCs=; b=Yb5qwxenMvKcbTkku/5qe1Z91ZJgnnjgxefKR1xu7f8aqm+N3eMynnkEzZEjeb7fmm UHJoriOehYugsR11jWpQbhIth3FbO4p9e++crXFyeLTlDWR5YUTt4HZ9mcS2BD4vOD3s /41KeMlwi8fAyRLxzLPTu+lYLJUcIP8YMU478= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=c8B9I9M8GdGBFtlO0XOQLocDLRi5cePSUYkCes6FJ15d53je+rTvPfdwdiReleZL5v WM8w/djIdsknWIXAN62Suue7O8pGfxAJkpwBLmBRf+3XIqnRL76LJk+IkW/Yji9nBc/A krM+5hVkd/4wi96qnMILzgTcYQeM1ml/+yDdM= Received: by 10.231.184.168 with SMTP id ck40mr17197843ibb.174.1279133345140; Wed, 14 Jul 2010 11:49:05 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.231.159.193 with HTTP; Wed, 14 Jul 2010 11:48:44 -0700 (PDT) In-Reply-To: References: From: Naitik Shah Date: Wed, 14 Jul 2010 11:48:44 -0700 X-Google-Sender-Auth: R1SjFE-upfRxnz5uFBG1JyVVh40 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=005045016033a84f3a048b5d70c2 Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 18:48:56 -0000 --005045016033a84f3a048b5d70c2 Content-Type: text/plain; charset=UTF-8 2 and 3 are practically most interesting imho. (b) is interesting in that if a client application does have SSL, then it's the simplest flow of all. -Naitik On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav wrote: > Please answer this based on actual use cases. When returning parameters > using the redirection URI call, which of these combinations make sense? > > | Code | Token | Code & Token > ---------+------+-------+-------------- > Fragment | a | 1 | 3 > Query | 2 | b | c > Split* | n/a | n/a | d > > * token in fragment, code in query > > Known use cases: > > 1 - current user-agent flow > 2 - current web-server flow > 3 - as described by Brian and Naitik > > Do you need any of these? > > a - > b - > c - > d - current -10 code-and-token proposal > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --005045016033a84f3a048b5d70c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2 and 3 are practically most interesting imho.

(b) is in= teresting in that if a client application does have SSL, then it's the = simplest flow of all.


-Naitik

On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer= -Lahav <eran@hu= eniverse.com> wrote:
Please answer this based on actual use cases. When returning parameters
using the redirection URI call, which of these combinations make sense?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Code | Token | Code & Token
---------+------+-------+--------------
Fragment | =C2=A0a =C2=A0 | =C2=A0 1 =C2=A0 | =C2=A0 3
Query =C2=A0 =C2=A0| =C2=A02 =C2=A0 | =C2=A0 b =C2=A0 | =C2=A0 c
Split* =C2=A0 | n/a =C2=A0| =C2=A0n/a =C2=A0| =C2=A0 d

* token in fragment, code in query

Known use cases:

1 - current user-agent flow
2 - current web-server flow
3 - as described by Brian and Naitik

Do you need any of these?

a -
b -
c -
d - current -10 code-and-token proposal

EHL

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

--005045016033a84f3a048b5d70c2-- From wmills@yahoo-inc.com Wed Jul 14 11:58: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 671CE3A6A71 for ; Wed, 14 Jul 2010 11:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.279 X-Spam-Level: X-Spam-Status: No, score=-17.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2l5cvdiO+Hr for ; Wed, 14 Jul 2010 11:58:55 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id ACD733A6972 for ; Wed, 14 Jul 2010 11:58:55 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6EIwZsx004068; Wed, 14 Jul 2010 11:58:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=0sJbzPxgTSmYJlCsMPuhPzgw4YqYNWM1LxjIX/4KilZ3+CDfw9s8yGt+fL/ZXMCC Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 11:58:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Jul 2010 11:58:09 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6C7A@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] single use authorization codes Thread-Index: Acsjc3bFOHCCz3RKR1utNkJl9y0yCAAEutXw References: <012AB2B223CB3F4BB846962876F47217059B6C4D@SNV-EXVS08.ds.corp.yahoo.com> From: "William Mills" To: "Brian Eaton" X-OriginalArrivalTime: 14 Jul 2010 18:58:35.0569 (UTC) FILETIME=[8FD21210:01CB2386] Cc: OAuth WG Subject: Re: [OAUTH-WG] single use authorization codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 18:58:56 -0000 If I can see things go by on the fly I can submit the token late and mess with the user by revoking their session. >=20 > > It closes one door but opens a DOS attack. >=20 > What's the DOS attack? >=20 From beaton@google.com Wed Jul 14 13:37:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DCCF3A6B50 for ; Wed, 14 Jul 2010 13:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.877 X-Spam-Level: X-Spam-Status: No, score=-101.877 tagged_above=-999 required=5 tests=[AWL=0.100, 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 D5mLa2TKuStj for ; Wed, 14 Jul 2010 13:36:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 60A2F3A6A76 for ; Wed, 14 Jul 2010 13:35:28 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o6EKZImv015986 for ; Wed, 14 Jul 2010 13:35:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279139719; bh=68tcduW3p7cqOMxJpeBqsDK8fpM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=cm+OkaVI5GrSY7gdDd4QakjWZtPWz2s5p0mFDEYSX4Epm94UNVyjZaHJBCXPr3G0p 94xRt6Mg3JmOkX5AQG/iQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=EKEWp8EKhuWVdO1dwztrB7VjXkV5Gk7avwR31EKEQ/tN6bC5Dqpd2Fl/TqrFIkttf y6hgX6VUN2vHrChBraQqQ== Received: from pwj1 (pwj1.prod.google.com [10.241.219.65]) by kpbe19.cbf.corp.google.com with ESMTP id o6EKZHSp019565 for ; Wed, 14 Jul 2010 13:35:17 -0700 Received: by pwj1 with SMTP id 1so13148pwj.17 for ; Wed, 14 Jul 2010 13:35:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.164.14 with SMTP id m14mr20246845wfe.152.1279139710470; Wed, 14 Jul 2010 13:35:10 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Wed, 14 Jul 2010 13:35:10 -0700 (PDT) In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6C7A@SNV-EXVS08.ds.corp.yahoo.com> References: <012AB2B223CB3F4BB846962876F47217059B6C4D@SNV-EXVS08.ds.corp.yahoo.com> <012AB2B223CB3F4BB846962876F47217059B6C7A@SNV-EXVS08.ds.corp.yahoo.com> Date: Wed, 14 Jul 2010 13:35:10 -0700 Message-ID: From: Brian Eaton To: William Mills Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] single use authorization codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 20:37:02 -0000 On Wed, Jul 14, 2010 at 11:58 AM, William Mills wrote: > If I can see things go by on the fly I can submit the token late and > mess with the user by revoking their session. Meh. If the best the attacker can do in those circumstances is DOS, we're in good shape. Bear in mind that if we do nothing, the attacker can probably get the user's data. From wmills@yahoo-inc.com Wed Jul 14 14:30: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 9964C3A69BF for ; Wed, 14 Jul 2010 14:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.303 X-Spam-Level: X-Spam-Status: No, score=-17.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+3kLzHk+Utw for ; Wed, 14 Jul 2010 14:30:51 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id B87993A67F4 for ; Wed, 14 Jul 2010 14:30:51 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6ELSv23069803; Wed, 14 Jul 2010 14:28:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=tTZQTUlfB5A9443v0lZjOfJ2id2OvE9Uiq1iky5jX7D3uwXjq7V2yZnHR//N1J8T Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 14:28:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Jul 2010 14:28:54 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6C92@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] single use authorization codes Thread-Index: AcsjlEHLkIBAgXizSmOffd8gfNA4GQAByw/A References: <012AB2B223CB3F4BB846962876F47217059B6C4D@SNV-EXVS08.ds.corp.yahoo.com><012AB2B223CB3F4BB846962876F47217059B6C7A@SNV-EXVS08.ds.corp.yahoo.com> From: "William Mills" To: "Brian Eaton" X-OriginalArrivalTime: 14 Jul 2010 21:28:57.0517 (UTC) FILETIME=[915215D0:01CB239B] Cc: OAuth WG Subject: Re: [OAUTH-WG] single use authorization codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 21:30:53 -0000 We're trying to design around transport security with short expiration and single use tokens. SSL solves the problem=20 > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com]=20 > Sent: Wednesday, July 14, 2010 1:35 PM > To: William Mills > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] single use authorization codes >=20 > On Wed, Jul 14, 2010 at 11:58 AM, William Mills=20 > wrote: > > If I can see things go by on the fly I can submit the token=20 > late and=20 > > mess with the user by revoking their session. >=20 > Meh. >=20 > If the best the attacker can do in those circumstances is=20 > DOS, we're in good shape. >=20 > Bear in mind that if we do nothing, the attacker can probably=20 > get the user's data. >=20 From torsten@lodderstedt.net Wed Jul 14 14:32:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96AFF3A69A5 for ; Wed, 14 Jul 2010 14:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=0.698, 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 NFFA3R2QDyja for ; Wed, 14 Jul 2010 14:32:44 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id 12ABD3A6979 for ; Wed, 14 Jul 2010 14:32:38 -0700 (PDT) Received: from p4ffd2d01.dip.t-dialin.net ([79.253.45.1] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OZ9ZL-0007sE-GY; Wed, 14 Jul 2010 23:32:43 +0200 Message-ID: <4C3E2CF2.1000108@lodderstedt.net> Date: Wed, 14 Jul 2010 23:32:34 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brian Eaton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: Kris Selden , OAuth WG Subject: Re: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 21:32:51 -0000 > > On Tue, Jul 13, 2010 at 9:58 PM, Torsten Lodderstedt > wrote: > >> We plan to issue new refresh tokens for certain clients only (mobile, desktop), >> it's part of the client-related policy. So the behavior for a particular client is predictable. >> > Nice. > > Would you be willing to expand on the current spec language a bit, to > explain the use cases, and offer more normative language about how > clients should handle refresh token exchange? > > This is a cool feature, but the current language is kind of vague. > > Cheers, > Brian > I'm not sure what you would like me to write. But let's get started: We expected the clients to discard the old refresh token and to use the newly issued refresh token instead. The old refresh tokens is revoked instantly. Any attempt to use it afterwards is interpreted as a potential misuse because the assumption would be that an adversary has copied the token or cloned the device. The client should notify the user of the problem and recommend him/her to check its application authorizations (refresh tokens) in our user self care portal. There, the user will have acces to information on when the token has been used the last time and therewith detect any odd behavior. The user could then revoke the token and/or alarm its providers helpdesk. regards, Torsten. From torsten@lodderstedt.net Wed Jul 14 14:36:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60B63A6862 for ; Wed, 14 Jul 2010 14:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.349, 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 FPGGDCIoXd9c for ; Wed, 14 Jul 2010 14:36:17 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by core3.amsl.com (Postfix) with ESMTP id BD5473A6994 for ; Wed, 14 Jul 2010 14:36:17 -0700 (PDT) Received: from p4ffd2d01.dip.t-dialin.net ([79.253.45.1] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OZ9cw-0004JR-Tn; Wed, 14 Jul 2010 23:36:26 +0200 Message-ID: <4C3E2DDA.3070905@lodderstedt.net> Date: Wed, 14 Jul 2010 23:36:26 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 21:36:18 -0000 2 is a must have from my point of view. I would also like to see support for b. In this case, additional means for client authentication should be considered. regards, Torsten. > Please answer this based on actual use cases. When returning parameters > using the redirection URI call, which of these combinations make sense? > > | Code | Token | Code& Token > ---------+------+-------+-------------- > Fragment | a | 1 | 3 > Query | 2 | b | c > Split* | n/a | n/a | d > > * token in fragment, code in query > > Known use cases: > > 1 - current user-agent flow > 2 - current web-server flow > 3 - as described by Brian and Naitik > > Do you need any of these? > > a - > b - > c - > d - current -10 code-and-token proposal > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From beaton@google.com Wed Jul 14 14:40:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115053A6979 for ; Wed, 14 Jul 2010 14:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.764 X-Spam-Level: X-Spam-Status: No, score=-105.764 tagged_above=-999 required=5 tests=[AWL=0.213, 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 bdOg9iR6mGvB for ; Wed, 14 Jul 2010 14:40:42 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 22FC93A672E for ; Wed, 14 Jul 2010 14:40:41 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o6ELeoLI005304 for ; Wed, 14 Jul 2010 14:40:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279143650; bh=CI4LJQ1CcF+PGFDDxP8IM8zYKE0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Z8/quAo7T8apOjEVPCy9p8Dy330gb5OizfRstYE5l3Olu9HsJdcYExIy3cw77EX2P XEynKMM1bIiitHx3zNh2A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=x36rYS8hiO8Upw103A6mqC16X39E/6gKb2C+A6s+Eb2y3Fxm34Qw/4ZTJPQLDHyXd 96LmO4rqX3v+h3Zji/QTg== Received: from pvd12 (pvd12.prod.google.com [10.241.209.204]) by hpaq6.eem.corp.google.com with ESMTP id o6ELemHV009623 for ; Wed, 14 Jul 2010 14:40:48 -0700 Received: by pvd12 with SMTP id 12so36562pvd.17 for ; Wed, 14 Jul 2010 14:40:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.233.10 with SMTP id f10mr22731973wfh.215.1279143647691; Wed, 14 Jul 2010 14:40:47 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Wed, 14 Jul 2010 14:40:47 -0700 (PDT) In-Reply-To: <4C3E2DDA.3070905@lodderstedt.net> References: <4C3E2DDA.3070905@lodderstedt.net> Date: Wed, 14 Jul 2010 14:40:47 -0700 Message-ID: From: Brian Eaton To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 21:40:44 -0000 On Wed, Jul 14, 2010 at 2:36 PM, Torsten Lodderstedt wrote: > I would also like to see support for b. In this case, additional means for > client authentication should be considered. b is token on query string? What's the use case for that? From torsten@lodderstedt.net Wed Jul 14 14:44: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 E2C063A69D5 for ; Wed, 14 Jul 2010 14:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.233, 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 FsePcj1l84aY for ; Wed, 14 Jul 2010 14:44:57 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by core3.amsl.com (Postfix) with ESMTP id 6FD983A672E for ; Wed, 14 Jul 2010 14:44:57 -0700 (PDT) Received: from p4ffd2d01.dip.t-dialin.net ([79.253.45.1] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OZ9lI-0002Vx-NV; Wed, 14 Jul 2010 23:45:04 +0200 Message-ID: <4C3E2FDA.9050006@lodderstedt.net> Date: Wed, 14 Jul 2010 23:44:58 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: William Mills References: <012AB2B223CB3F4BB846962876F47217059B6C4D@SNV-EXVS08.ds.corp.yahoo.com><012AB2B223CB3F4BB846962876F47217059B6C7A@SNV-EXVS08.ds.corp.yahoo.com> <012AB2B223CB3F4BB846962876F47217059B6C92@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6C92@SNV-EXVS08.ds.corp.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] single use authorization codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 21:44:59 -0000 what about guessing/brute force attacks on the code? Supposed an authorization server issuing tokens for a client w/o secret. Then the number of attempts needed to obtain a token issued to that client only depends on the length and randomness of the code. Should the spec state something about that? regards, Torsten. > We're trying to design around transport security with short expiration > and single use tokens. SSL solves the problem > > >> -----Original Message----- >> From: Brian Eaton [mailto:beaton@google.com] >> Sent: Wednesday, July 14, 2010 1:35 PM >> To: William Mills >> Cc: Eran Hammer-Lahav; OAuth WG >> Subject: Re: [OAUTH-WG] single use authorization codes >> >> On Wed, Jul 14, 2010 at 11:58 AM, William Mills >> wrote: >> >>> If I can see things go by on the fly I can submit the token >>> >> late and >> >>> mess with the user by revoking their session. >>> >> Meh. >> >> If the best the attacker can do in those circumstances is >> DOS, we're in good shape. >> >> Bear in mind that if we do nothing, the attacker can probably >> get the user's data. >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Wed Jul 14 14:48:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204353A6A00 for ; Wed, 14 Jul 2010 14:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.175, 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 G2PysZYMqmHA for ; Wed, 14 Jul 2010 14:48:44 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by core3.amsl.com (Postfix) with ESMTP id 2543C3A69D5 for ; Wed, 14 Jul 2010 14:48:43 -0700 (PDT) Received: from p4ffd2d01.dip.t-dialin.net ([79.253.45.1] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OZ9oz-00029O-DS; Wed, 14 Jul 2010 23:48:53 +0200 Message-ID: <4C3E30C4.8090901@lodderstedt.net> Date: Wed, 14 Jul 2010 23:48:52 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brian Eaton References: <4C3E2DDA.3070905@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 21:48:45 -0000 > > On Wed, Jul 14, 2010 at 2:36 PM, Torsten Lodderstedt > wrote: > >> I would also like to see support for b. In this case, additional means for >> client authentication should be considered. >> > b is token on query string? > > What's the use case for that? > Yepp. That's an optimization of use case 2. That way the authz server does not need to store the authorization transaction's results in a database and there is no need to perform a a second request. regards, Torsten. From beaton@google.com Wed Jul 14 14:52:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19C13A6979 for ; Wed, 14 Jul 2010 14:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.771 X-Spam-Level: X-Spam-Status: No, score=-105.771 tagged_above=-999 required=5 tests=[AWL=0.206, 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 9xJjkha1e7oA for ; Wed, 14 Jul 2010 14:52:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C9DAE3A6405 for ; Wed, 14 Jul 2010 14:52:12 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o6ELqMfB018330 for ; Wed, 14 Jul 2010 14:52:22 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279144342; bh=hMrIWM6N9nbbLO63BZnMJ4wtPuc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=NHQKsgvHaO6AiOa547DdJz/5tReV9FF+LQHVNmEyj5vU//bprMvuY8UQyc7Fj/jy6 AaEUPmVDjw6Ma4k5FYs7Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=oIU6gNicSltlOOGfUCzzycZrs0t2D5GjaabvRO+XfCuFW2ktZ4I93ON8w8JQ7DLVk YJErcY7fCMTGIhaDg8C4w== Received: from pwj6 (pwj6.prod.google.com [10.241.219.70]) by hpaq3.eem.corp.google.com with ESMTP id o6ELqKHQ005298 for ; Wed, 14 Jul 2010 14:52:20 -0700 Received: by pwj6 with SMTP id 6so104131pwj.2 for ; Wed, 14 Jul 2010 14:52:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.188.13 with SMTP id l13mr20307681wff.126.1279144332521; Wed, 14 Jul 2010 14:52:12 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Wed, 14 Jul 2010 14:52:12 -0700 (PDT) In-Reply-To: <4C3E30C4.8090901@lodderstedt.net> References: <4C3E2DDA.3070905@lodderstedt.net> <4C3E30C4.8090901@lodderstedt.net> Date: Wed, 14 Jul 2010 14:52:12 -0700 Message-ID: From: Brian Eaton To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 21:52:13 -0000 On Wed, Jul 14, 2010 at 2:48 PM, Torsten Lodderstedt wrote: > Yepp. That's an optimization of use case 2. That way the authz server does > not need to store the authorization transaction's results in a database and > there is no need to perform a a second request. The authorization server doesn't need to store the transaction results in a database regardless, the authorization code can be a signed message. The second request (as you pointed out in your original mail) is currently used to verify the client identity. Do you have a suggestion for an alternate mechanism? From beaton@google.com Wed Jul 14 14:57:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20563A6A00 for ; Wed, 14 Jul 2010 14:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.777 X-Spam-Level: X-Spam-Status: No, score=-105.777 tagged_above=-999 required=5 tests=[AWL=0.200, 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 jVmMbFp1wanK for ; Wed, 14 Jul 2010 14:57:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C64573A69B0 for ; Wed, 14 Jul 2010 14:57:27 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o6ELvbbc010491 for ; Wed, 14 Jul 2010 14:57:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279144657; bh=MssiyTACLIhw7JEYAob3DNzxtTg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=T6sV3Nods1LN8JXINVQLdnIhHG2NiHIFsKQ70frUAeYGuKK5SMCX+CspnSZhz9NTv OLoerse78+/kFUG8hH87g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=shdMDr3IYtKQANVwK8KINcc7PC6LnXBRe01C4DAZteE2hPwekisQFXQuovWlC2hL8 qpcuHJQcqQ5QpuEiWl1/Q== Received: from pzk27 (pzk27.prod.google.com [10.243.19.155]) by wpaz17.hot.corp.google.com with ESMTP id o6ELvauB005969 for ; Wed, 14 Jul 2010 14:57:36 -0700 Received: by pzk27 with SMTP id 27so74175pzk.39 for ; Wed, 14 Jul 2010 14:57:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.180.1 with SMTP id c1mr7887703wff.25.1279144656283; Wed, 14 Jul 2010 14:57:36 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Wed, 14 Jul 2010 14:57:36 -0700 (PDT) In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6C92@SNV-EXVS08.ds.corp.yahoo.com> References: <012AB2B223CB3F4BB846962876F47217059B6C4D@SNV-EXVS08.ds.corp.yahoo.com> <012AB2B223CB3F4BB846962876F47217059B6C7A@SNV-EXVS08.ds.corp.yahoo.com> <012AB2B223CB3F4BB846962876F47217059B6C92@SNV-EXVS08.ds.corp.yahoo.com> Date: Wed, 14 Jul 2010 14:57:36 -0700 Message-ID: From: Brian Eaton To: William Mills Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] single use authorization codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 21:57:28 -0000 On Wed, Jul 14, 2010 at 2:28 PM, William Mills wrote: > We're trying to design around transport security with short expiration > and single use tokens. SSL solves the problem. No, we're not, and no, it doesn't. The issue here is not that tokens are sent over unencrypted channels, or unauthenticated channels. The issue here is that browsers make it hard for server A to pass information through the client in such a way that only server B can read the information. I have some notes on the challenges here: http://www.ietf.org/mail-archive/web/oauth/current/msg03662.html. Cheers, Brian From torsten@lodderstedt.net Wed Jul 14 14:58: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 4205B3A6994 for ; Wed, 14 Jul 2010 14:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.140, 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 dqlZFMUAORXq for ; Wed, 14 Jul 2010 14:58:57 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by core3.amsl.com (Postfix) with ESMTP id 66B063A69B0 for ; Wed, 14 Jul 2010 14:58:57 -0700 (PDT) Received: from p4ffd2d01.dip.t-dialin.net ([79.253.45.1] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OZ9ys-0006g7-Oq; Wed, 14 Jul 2010 23:59:06 +0200 Message-ID: <4C3E3326.6020401@lodderstedt.net> Date: Wed, 14 Jul 2010 23:59:02 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brian Eaton References: <4C3E2DDA.3070905@lodderstedt.net> <4C3E30C4.8090901@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 21:58:58 -0000 Am 14.07.2010 23:52, schrieb Brian Eaton: > On Wed, Jul 14, 2010 at 2:48 PM, Torsten Lodderstedt > wrote: > >> Yepp. That's an optimization of use case 2. That way the authz server does >> not need to store the authorization transaction's results in a database and >> there is no need to perform a a second request. >> > The authorization server doesn't need to store the transaction results > in a database regardless, the authorization code can be a signed > message. > That's an indeed option. But then the whole data is transported twice between authz server and client. > The second request (as you pointed out in your original mail) is > currently used to verify the client identity. Do you have a > suggestion for an alternate mechanism? > A digital signature over the authz request? Alternatively, the authz server could encrypt the authz response. regards, Torsten. From zachary.zeltsan@alcatel-lucent.com Wed Jul 14 15:01: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 C31163A68D0 for ; Wed, 14 Jul 2010 15:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 aMvP+xlxED0s for ; Wed, 14 Jul 2010 15:01:56 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 13CD73A6814 for ; Wed, 14 Jul 2010 15:01:54 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o6EM22pl024935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jul 2010 17:02:02 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6EM2160003887; Wed, 14 Jul 2010 17:02:02 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 14 Jul 2010 17:01:41 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Eran Hammer-Lahav'" , OAuth WG Date: Wed, 14 Jul 2010 17:01:40 -0500 Thread-Topic: Quick survey: fragment vs. query Thread-Index: AcsjTYO/D1HEd/0XFEy3vjXZwJopfQAUJlPQ Message-ID: <5710F82C0E73B04FA559560098BF95B124F9688DCC@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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.11 Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 22:01:56 -0000 I do not quite understand the combination table: what are a, b, and c param= eters? Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Wednesday, July 14, 2010 8:10 AM To: OAuth WG Subject: [OAUTH-WG] Quick survey: fragment vs. query Please answer this based on actual use cases. When returning parameters using the redirection URI call, which of these combinations make sense? | Code | Token | Code & Token ---------+------+-------+-------------- Fragment | a | 1 | 3 Query | 2 | b | c Split* | n/a | n/a | d * token in fragment, code in query Known use cases: 1 - current user-agent flow 2 - current web-server flow 3 - as described by Brian and Naitik Do you need any of these? a -=20 b - c -=20 d - current -10 code-and-token proposal EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Jul 14 15:15:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 397A63A67FA for ; Wed, 14 Jul 2010 15:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_00=-2.599, FRT_BELOW2=2.154] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jJ3bm7C5rZi for ; Wed, 14 Jul 2010 15:15:44 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BFB6B3A679F for ; Wed, 14 Jul 2010 15:15:43 -0700 (PDT) Received: (qmail 9836 invoked from network); 14 Jul 2010 22:15:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jul 2010 22:15:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 14 Jul 2010 15:15:48 -0700 From: Eran Hammer-Lahav To: Rob Richards Date: Wed, 14 Jul 2010 15:15:37 -0700 Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcsjohwNw0d/1xZER6y8wdoKQUBobA== Message-ID: <4A8399B3-F14F-48B2-8A7F-6CC923EDD128@hueniverse.com> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2DC7C5.2090009@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F108B.70504@cdatazone.org> <20100708110542.150740@gmx.net> <4C3707BD.6070201@gmx.de> <4C3E05EE.4050903@cdatazone.org> In-Reply-To: <4C3E05EE.4050903@cdatazone.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@ietf.org" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 22:15:45 -0000 Already in -10.=20 EHL On Jul 14, 2010, at 14:46, Rob Richards wrote: > Finally getting a chance to catchup and respond to this thread. >=20 > Marius Scurtescu wrote: >> See comments bellow... >>=20 >>=20 >> On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia wrote: >>=20 >>> Hallo Marius, >>>=20 >>> thanks for your statement. >>> Your idea of a migration flow is quite good and necessary. >>>=20 >>> But I still doubt, if the work and effort should be investigated to spa= re >>> the user from some interaction (authentication and user consent). >>>=20 >>=20 >> It all depends for how many users does the client have OAuth 1 tokens. >> Asking users to re-approve will confuse them and I guess many will not >> do it, >>=20 >=20 > I think the user should not be excluded from this interaction and should= =20 > be required to re-approve. IMO they should be involved as its also=20 > informational to know that the client they have previously authorized is= =20 > now requesting new credentials under a different security scheme. The=20 > user should be the one to decide whether or not they want to allow this. >=20 > When it comes right down to it the only concrete thing I can think of=20 > when migrating from 1.0 to 2.0 is the need to determine which version is= =20 > being used at the resource endpoint. For most clients moving from 1.0 to= =20 > 2.0 they will most likely just create the next version of their=20 > client/app with 2.0 support and completely drop 1.0 support rather than=20 > going through any migration flow. More work that they don't need to deal= =20 > with so why would they. I can envision a SP providing support for both=20 > 1.0 and 2.0 with an end of life to 1.0 support. This will give the=20 > client developers enough time to migrate and distribute their client/apps= . >=20 > As far as the version determination on the endpoint, this is really just= =20 > a paragraph of text and seems a bit overkill to put into its own=20 > proposal when it could easily be handled even as an appendix in the core= =20 > 2.0 spec. >=20 > Rob > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Wed Jul 14 15:22:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65743A6802 for ; Wed, 14 Jul 2010 15:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 1QsPPZbqC-E6 for ; Wed, 14 Jul 2010 15:22:17 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id E1F513A67FA for ; Wed, 14 Jul 2010 15:22:16 -0700 (PDT) Received: from p4ffd2d01.dip.t-dialin.net ([79.253.45.1] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OZALR-0001Hn-JX for oauth@ietf.org; Thu, 15 Jul 2010 00:22:25 +0200 Message-ID: <4C3E389D.5080300@lodderstedt.net> Date: Thu, 15 Jul 2010 00:22:21 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Subject: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 22:22:17 -0000 I have a question concerning the OAuth philosophy: How many resource servers may be managed by a single OAuth authorization server? (a) A single resource server or (b) several of them exposing different resource types? If the answer is (b) then how is a particular resource server identified in the protocol? Clients have Ids, end-users as well (at least in a future protocol extension), but what about resource server Ids? I think resource servers must be identifiable in multi-server deployments for several reasons: - Interpretation of the scope parameter should be resource server specific - "read" may have different meanings in mail and address book - An authorization server probably wants to apply server-specific security policy, e.g. different access token durations - It will be possible to create special tokens per server I think we should introduce a resource server id in the authz and access token request. Any thoughts? regards, Torsten. From eran@hueniverse.com Wed Jul 14 15:33: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 25C583A6814 for ; Wed, 14 Jul 2010 15:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 0E8ao7zIEG7T for ; Wed, 14 Jul 2010 15:33:15 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D1D5D3A67D7 for ; Wed, 14 Jul 2010 15:33:14 -0700 (PDT) Received: (qmail 31831 invoked from network); 14 Jul 2010 22:33:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jul 2010 22:33:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 14 Jul 2010 15:33:25 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Wed, 14 Jul 2010 15:33:15 -0700 Thread-Topic: [OAUTH-WG] Quick survey: fragment vs. query Thread-Index: AcsjpJIIuqeOcZz6SWyN9iRshhhrnQ== Message-ID: References: <4C3E2DDA.3070905@lodderstedt.net> <4C3E30C4.8090901@lodderstedt.net> <4C3E3326.6020401@lodderstedt.net> In-Reply-To: <4C3E3326.6020401@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 22:33:16 -0000 At some point this brings us back to 1.0... EHL On Jul 14, 2010, at 17:59, Torsten Lodderstedt wr= ote: > Am 14.07.2010 23:52, schrieb Brian Eaton: >> On Wed, Jul 14, 2010 at 2:48 PM, Torsten Lodderstedt >> wrote: >>=20 >>> Yepp. That's an optimization of use case 2. That way the authz server d= oes >>> not need to store the authorization transaction's results in a database= and >>> there is no need to perform a a second request. >>>=20 >> The authorization server doesn't need to store the transaction results >> in a database regardless, the authorization code can be a signed >> message. >>=20 >=20 > That's an indeed option. But then the whole data is transported twice=20 > between authz server and client. >=20 >> The second request (as you pointed out in your original mail) is >> currently used to verify the client identity. Do you have a >> suggestion for an alternate mechanism? >>=20 >=20 > A digital signature over the authz request? Alternatively, the authz=20 > server could encrypt the authz response. >=20 > regards, > Torsten. >=20 From mscurtescu@google.com Wed Jul 14 15:34: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 C87873A67D7 for ; Wed, 14 Jul 2010 15:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.293 X-Spam-Level: X-Spam-Status: No, score=-104.293 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_BELOW2=2.154, 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 wcf7Fh8GN7PX for ; Wed, 14 Jul 2010 15:34:02 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2C7713A69B9 for ; Wed, 14 Jul 2010 15:34:01 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o6EMYBFJ007493 for ; Wed, 14 Jul 2010 15:34:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279146851; bh=K/LCSup2/Jtsff+7QBBqWFJq+VI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Qa3jzCxVfrL7M5LeXB5IjKTMBHUXcpWSUFVdd+Uyk1Gqk326Uoz3KklCroH2dv56k 5Zd0TEJNTVtGNtO4Iz02A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=DRtql1zumZfImDS/KWcjVmj3LzJwn3tOL7Yi+d9JsIOIdjiYJAkmBA7HOmMrxuyz1 eTC2QEq/l2sjyvZfy8E8g== Received: from gwaa20 (gwaa20.prod.google.com [10.200.27.20]) by wpaz13.hot.corp.google.com with ESMTP id o6EMYAvn007243 for ; Wed, 14 Jul 2010 15:34:10 -0700 Received: by gwaa20 with SMTP id a20so105272gwa.24 for ; Wed, 14 Jul 2010 15:34:10 -0700 (PDT) Received: by 10.100.12.17 with SMTP id 17mr18505853anl.199.1279146848589; Wed, 14 Jul 2010 15:34:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Wed, 14 Jul 2010 15:33:27 -0700 (PDT) In-Reply-To: <4C3E05EE.4050903@cdatazone.org> References: <4C2C6D4A.5010401@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C3E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2DC7C5.2090009@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F108B.70504@cdatazone.org> <20100708110542.150740@gmx.net> <4C3707BD.6070201@gmx.de> <4C3E05EE.4050903@cdatazone.org> From: Marius Scurtescu Date: Wed, 14 Jul 2010 15:33:27 -0700 Message-ID: To: Rob Richards Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 22:34:04 -0000 On Wed, Jul 14, 2010 at 11:46 AM, Rob Richards wrote: > Finally getting a chance to catchup and respond to this thread. > > Marius Scurtescu wrote: >> >> See comments bellow... >> >> >> On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia wrote: >> >>> >>> Hallo Marius, >>> >>> thanks for your statement. >>> Your idea of a migration flow is quite good and necessary. >>> >>> But I still doubt, if the work and effort should be investigated to spare >>> the user from some interaction (authentication and user consent). >>> >> >> It all depends for how many users does the client have OAuth 1 tokens. >> Asking users to re-approve will confuse them and I guess many will not >> do it, >> > > I think the user should not be excluded from this interaction and should be > required to re-approve. IMO they should be involved as its also > informational to know that the client they have previously authorized is now > requesting new credentials under a different security scheme. The user > should be the one to decide whether or not they want to allow this. Why would you re-prompt the user? The only thing that really changes is the underlying protocol, something most end users are not made aware of. How would the new approval page be any different from the initial one? The user granted a client access to some of its resources, that stays the same. If the authorization server makes it explicit on the approval page that OAuth 1 is used, then yes, a re-approval is needed, but I don't think this normally happens. > When it comes right down to it the only concrete thing I can think of when > migrating from 1.0 to 2.0 is the need to determine which version is being > used at the resource endpoint. For most clients moving from 1.0 to 2.0 they > will most likely just create the next version of their client/app with 2.0 > support and completely drop 1.0 support rather than going through any > migration flow. That depends on the client. If the client is a web site that has several thousand users, and it stores OAuth 1 access tokens for all these users, then migration totally makes sense. If the client is an iPhone app with only one user, then maybe you are right. Even in this case, I am sure the app would prefer not to annoy the user and just silently move to OAuth 2. If you are the app developer and your app has a large install base, would you risk losing even a small percentage of those users simply because you presented them with a confusing approval page? Marius From eran@hueniverse.com Wed Jul 14 15:35: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 A572D3A69C5 for ; Wed, 14 Jul 2010 15:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 9Iyv1SVr7WbS for ; Wed, 14 Jul 2010 15:35:52 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 7F91B3A69C2 for ; Wed, 14 Jul 2010 15:35:52 -0700 (PDT) Received: (qmail 16316 invoked from network); 14 Jul 2010 22:36:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Jul 2010 22:36:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 14 Jul 2010 15:35:57 -0700 From: Eran Hammer-Lahav To: Eran Hammer-Lahav Date: Wed, 14 Jul 2010 15:35:49 -0700 Thread-Topic: [OAUTH-WG] Quick survey: fragment vs. query Thread-Index: AcsjpO19YEmKIZJZRimbMGF+CybFWQ== Message-ID: <23A5D7FA-333C-44DF-B132-EEFB615C1494@hueniverse.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 22:35:53 -0000 a - code in fragment b - token in query c - code and token in query d - code and token split -10 EHL On Jul 14, 2010, at 8:10, Eran Hammer-Lahav wrote: > Please answer this based on actual use cases. When returning parameters > using the redirection URI call, which of these combinations make sense? >=20 > | Code | Token | Code & Token > ---------+------+-------+-------------- > Fragment | a | 1 | 3 > Query | 2 | b | c > Split* | n/a | n/a | d >=20 > * token in fragment, code in query >=20 > Known use cases: >=20 > 1 - current user-agent flow > 2 - current web-server flow > 3 - as described by Brian and Naitik >=20 > Do you need any of these? >=20 > a -=20 > b - > c -=20 > d - current -10 code-and-token proposal >=20 > EHL >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Wed Jul 14 15:37: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 BA3CC3A6994 for ; Wed, 14 Jul 2010 15:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.844 X-Spam-Level: X-Spam-Status: No, score=-101.844 tagged_above=-999 required=5 tests=[AWL=0.133, 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 uPLsMksNhbXG for ; Wed, 14 Jul 2010 15:37:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 8E26D3A6814 for ; Wed, 14 Jul 2010 15:37:28 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o6EMbbaY032549 for ; Wed, 14 Jul 2010 15:37:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279147058; bh=GpF66WKbm63xNZT274D2MkvlUiU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=BSOy6y6to5hgLaSCMeLCE9WbsrNUDw9ZumptopbxQ5LEzmAj3neeYXw/N835newel XqxgO043qCspTdarw4plw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=f7OfGqOmOf0BkGR0T78gRjg0OYYkDUZcYqueTsCMrbPZkCpcHXAGFM9gTmrgUbqwX mpqrsW+wjIEJ+ePPjlepQ== Received: from gyg8 (gyg8.prod.google.com [10.243.50.136]) by wpaz21.hot.corp.google.com with ESMTP id o6EMbR4d022374 for ; Wed, 14 Jul 2010 15:37:36 -0700 Received: by gyg8 with SMTP id 8so238197gyg.30 for ; Wed, 14 Jul 2010 15:37:36 -0700 (PDT) Received: by 10.100.6.5 with SMTP id 5mr19737213anf.243.1279147056340; Wed, 14 Jul 2010 15:37:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Wed, 14 Jul 2010 15:37:16 -0700 (PDT) In-Reply-To: <4C3E389D.5080300@lodderstedt.net> References: <4C3E389D.5080300@lodderstedt.net> From: Marius Scurtescu Date: Wed, 14 Jul 2010 15:37:16 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 22:37:29 -0000 On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt wrote: > I have a question concerning the OAuth philosophy: How many resource servers > may be managed by a single OAuth authorization server? (a) A single resource > server or (b) several of them exposing different resource types? > > If the answer is (b) then how is a particular resource server identified in > the protocol? Clients have Ids, end-users as well (at least in a future > protocol extension), but what about resource server Ids? > > I think resource servers must be identifiable in multi-server deployments > for several reasons: > - Interpretation of the scope parameter should be resource server specific - > "read" may have different meanings in mail and address book > - An authorization server probably wants to apply server-specific security > policy, e.g. different access token durations > - It will be possible to create special tokens per server > > I think we should introduce a resource server id in the authz and access > token request. > > Any thoughts? I think the scope fills this role. Scopes implemented as URIs, for example, allow the authz server to map them to resource servers. Marius From eran@hueniverse.com Wed Jul 14 15:39:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3123A6994 for ; Wed, 14 Jul 2010 15:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3ufmdp-ghX7 for ; Wed, 14 Jul 2010 15:39:32 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D99F03A69B0 for ; Wed, 14 Jul 2010 15:39:31 -0700 (PDT) Received: (qmail 7066 invoked from network); 14 Jul 2010 22:39:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jul 2010 22:39:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 14 Jul 2010 15:39:42 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Wed, 14 Jul 2010 15:39:32 -0700 Thread-Topic: [OAUTH-WG] resource server id needed? Thread-Index: AcsjpXMBpiPIRqVwRvKAFETKL/uMdA== Message-ID: <95C3FB14-F5C4-4ECB-91EF-9ED988C367DE@hueniverse.com> References: <4C3E389D.5080300@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 22:39:33 -0000 If your deployment is that complicated, even my discovery proposal is not g= oing to help you...=20 EHL On Jul 14, 2010, at 18:37, "Marius Scurtescu" wrote= : > On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt > wrote: >> I have a question concerning the OAuth philosophy: How many resource ser= vers >> may be managed by a single OAuth authorization server? (a) A single reso= urce >> server or (b) several of them exposing different resource types? >>=20 >> If the answer is (b) then how is a particular resource server identified= in >> the protocol? Clients have Ids, end-users as well (at least in a future >> protocol extension), but what about resource server Ids? >>=20 >> I think resource servers must be identifiable in multi-server deployment= s >> for several reasons: >> - Interpretation of the scope parameter should be resource server specif= ic - >> "read" may have different meanings in mail and address book >> - An authorization server probably wants to apply server-specific securi= ty >> policy, e.g. different access token durations >> - It will be possible to create special tokens per server >>=20 >> I think we should introduce a resource server id in the authz and access >> token request. >>=20 >> Any thoughts? >=20 > I think the scope fills this role. Scopes implemented as URIs, for > example, allow the authz server to map them to resource servers. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Wed Jul 14 16:02:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80AB3A69A3 for ; Wed, 14 Jul 2010 16:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.783 X-Spam-Level: X-Spam-Status: No, score=-105.783 tagged_above=-999 required=5 tests=[AWL=0.194, 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 Z4+eJOuff1Tq for ; Wed, 14 Jul 2010 16:02:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B6BE23A6814 for ; Wed, 14 Jul 2010 16:02:39 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o6EN2nb2031100 for ; Wed, 14 Jul 2010 16:02:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279148569; bh=6Q5bvL4T16wwIetW3hutbK+noio=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=EopNFAgmMBw9xkq8ShcOCcf96vIujvJLNiVTGZo8XyNEehMRBlSLPtQzMCp5dNJMT +a6ndz2MqDSvoyHy4SzGg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=T3xRCFU1uUh+kVwIxfKKNTHVJfcl1ndX3siKKjKv2i8xDtoXsEBo9/DSZWh0WyffE AhEuHCKqdasvsV3CZI9og== Received: from pvh1 (pvh1.prod.google.com [10.241.210.193]) by wpaz5.hot.corp.google.com with ESMTP id o6EN2m45016532 for ; Wed, 14 Jul 2010 16:02:48 -0700 Received: by pvh1 with SMTP id 1so64618pvh.41 for ; Wed, 14 Jul 2010 16:02:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.158.14 with SMTP id g14mr9975822wfe.30.1279148567704; Wed, 14 Jul 2010 16:02:47 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Wed, 14 Jul 2010 16:02:47 -0700 (PDT) In-Reply-To: <4C3E3326.6020401@lodderstedt.net> References: <4C3E2DDA.3070905@lodderstedt.net> <4C3E30C4.8090901@lodderstedt.net> <4C3E3326.6020401@lodderstedt.net> Date: Wed, 14 Jul 2010 16:02:47 -0700 Message-ID: From: Brian Eaton To: Torsten Lodderstedt 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] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 23:02:40 -0000 On Wed, Jul 14, 2010 at 2:59 PM, Torsten Lodderstedt wrote: >> The second request (as you pointed out in your original mail) is >> currently used to verify the client identity. =A0Do you have a >> suggestion for an alternate mechanism? >> > > A digital signature over the authz request? Alternatively, the authz serv= er > could encrypt the authz response. Is anybody else implementing that model...? From beaton@google.com Wed Jul 14 22:14: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 81AB43A6805 for ; Wed, 14 Jul 2010 22:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.883 X-Spam-Level: X-Spam-Status: No, score=-101.883 tagged_above=-999 required=5 tests=[AWL=0.094, 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 8EwFZDQekgjR for ; Wed, 14 Jul 2010 22:14:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 006573A66B4 for ; Wed, 14 Jul 2010 22:14:30 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o6F5EeCp019113 for ; Wed, 14 Jul 2010 22:14:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279170880; bh=pQle3X5ntYVT8I/QpWfoos7ECtc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=uHon4pkx0/NiRbUQk9kau43pBwbkTsQtTS+EqhMPVAmN4d7euciB5SapNTwwMwnpT QOBUdW29MslgWd1ZfTJhQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=aIgJKNUAWvzQBGtmnNpMpcRfibTUYw4bScs0GvggQiphndCcB8PsZoeG0SKUVgqyV 1wUuJiIYRcBE6GLdh2k8w== Received: from pwi6 (pwi6.prod.google.com [10.241.219.6]) by hpaq6.eem.corp.google.com with ESMTP id o6F5EcjT019382 for ; Wed, 14 Jul 2010 22:14:39 -0700 Received: by pwi6 with SMTP id 6so162077pwi.38 for ; Wed, 14 Jul 2010 22:14:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.233.10 with SMTP id f10mr23547006wfh.215.1279170878485; Wed, 14 Jul 2010 22:14:38 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Wed, 14 Jul 2010 22:14:38 -0700 (PDT) In-Reply-To: <4C3E2CF2.1000108@lodderstedt.net> References: <4C3E2CF2.1000108@lodderstedt.net> Date: Wed, 14 Jul 2010 22:14:38 -0700 Message-ID: From: Brian Eaton To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Kris Selden , OAuth WG Subject: Re: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 05:14:34 -0000 On Wed, Jul 14, 2010 at 2:32 PM, Torsten Lodderstedt wrote: > We expected the clients to discard the old refresh token and to use the > newly issued refresh token instead. The old refresh tokens is revoked > instantly. Any attempt to use it afterwards is interpreted as a potential > misuse because the assumption would be that an adversary has copied the > token or cloned the device. The client should notify the user of the problem > and recommend him/her to check its application authorizations (refresh > tokens) in our user self care portal. There, the user will have acces to > information on when the token has been used the last time and therewith > detect any odd behavior. The user could then revoke the token and/or alarm > its providers helpdesk. My use cases for this are a little different. 1) I'm interested in the two-legged flows as well as three-legged flows. For example, imagine an autonomous client that is registered once, and then after that maintains its own key material. Regular rotation of the key material is good cryptographic hygiene. 2) I'm interested in distributed scenarios. For example, imagine a geographically distributed client application, or a client application that is extremely busy. In both these cases, you run into race conditions where refresh tokens are changed even as they are being used. 3) I'm interested in authentication besides bearer tokens, in particular public keys used to verify assertions. 4) I'm less interested in installed applications. I understand your use case for rotating refresh tokens, but it's somewhat less important for me. That said, maybe we could arrive at a set of protocol flows that we would both implement the same way, and would meet all of those use cases? For example, would a protocol where the client secret for installed applications changed regularly work for you? Maybe something like this: - when a client contacts the authorization server, it would provide a hint that it supports key rotation - the authorization server may return an error code that says "key rotation needed" - the client would then generate a new secret key (this could be either a machine-generated password, or an HMAC key, or a public/private key pair.) - the client would then contact the authorization server again, signing the message with the old key, and providing the verification material for the new key. - the authorization server would then store the new key, and mark the old key for expiration. - subsequent requests from the client would be signed with the new key Note that in the case of installed applications using the user-approval flows, you would associate the new key material with the client-id and refresh token together, rather than the client-id alone. Otherwise it's impossible to look up the verification material for requests, since you would quickly run into problems with a single client-id mapping to zillions of secrets. Cheers, Brian From beaton@google.com Wed Jul 14 22:32:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BF593A6A0E for ; Wed, 14 Jul 2010 22:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.789 X-Spam-Level: X-Spam-Status: No, score=-105.789 tagged_above=-999 required=5 tests=[AWL=0.188, 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 LiKIp3uJAQvd for ; Wed, 14 Jul 2010 22:32:00 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BF47C3A6A58 for ; Wed, 14 Jul 2010 22:31:58 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o6F5W80Y012992 for ; Wed, 14 Jul 2010 22:32:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279171928; bh=ER5BFXM1sHPVjAGzHcQHyKfpAkA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=aeWSZx5eqAtmgglAdKVpACJhljZN62cheR0CA+yb+13GbJ4JclOeicINqfFXFI73k skAbKjg5hnV2lCQnqGNnw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=hi9ASQizKqhGDitia0/zGvjaxHBgSv2MawqTYjwog3+8b0xvAvHkeO9IrhPd/4Rf7 djuoDztz2Pjxqk291vTcg== Received: from pwj7 (pwj7.prod.google.com [10.241.219.71]) by wpaz21.hot.corp.google.com with ESMTP id o6F5W7xS013188 for ; Wed, 14 Jul 2010 22:32:07 -0700 Received: by pwj7 with SMTP id 7so172617pwj.36 for ; Wed, 14 Jul 2010 22:32:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.158.14 with SMTP id g14mr7543684wfe.93.1279171926797; Wed, 14 Jul 2010 22:32:06 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Wed, 14 Jul 2010 22:32:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Jul 2010 22:32:06 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] return to draft 6 spec org? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 05:32:02 -0000 On Tue, Jul 13, 2010 at 8:11 AM, Eran Hammer-Lahav wrote: > - client credentials information was always problematic because people > expressed interest in using it with pre-arranged authorizations, in which > case, the client may be acting on behalf of an end-user. ... > I suggested adding actual profiles to the spec, which would accomplish what > your want to see "restored". However it is not clear to me how to name these > and how to guide developers when to use them. ... I've been giving some thought to this problem. As far as I can tell, here is what has happened. 1) several people have gotten together and put together a tightly-specified proposal to meet a particular use case 2) that's gotten added 3) others have chimed in with slight modifications to meet slightly different use cases 4) that's gotten added 5) step 3 and 4 repeat for a while. 6) the detailed proposal written in step 1 and 2 has gotten screwed up We haven't gotten to step 7 yet, but I'm pretty sure it involves non-interoperable implementations. I think the problem here is step 4. Rather than making everything optional so we can meet every possible use case, we need to start telling people to go write up new profiles to meet their use cases. Given the choice between two tightly specified protocol flows and a single vague protocol flow, we should prefer tightly specified. Cheers, Brian From beaton@google.com Wed Jul 14 22:38:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43B63A69C3 for ; Wed, 14 Jul 2010 22:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.794 X-Spam-Level: X-Spam-Status: No, score=-105.794 tagged_above=-999 required=5 tests=[AWL=0.183, 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 9CnommSrXGzq for ; Wed, 14 Jul 2010 22:38:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3E8A33A690F for ; Wed, 14 Jul 2010 22:38:36 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o6F5ckYp001287 for ; Wed, 14 Jul 2010 22:38:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279172326; bh=Dg39p0kzKnn60mkQfQOm9kpxYi4=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=i756e4TDDjvtcYMGN+OV12E5tvEhImI4uFMpI4yCZWxNJAa86J/B3GEizI6naaI/Y qCiv9w6NOJ+Tp6boNoucA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=DgDyMm60o5mPgUdFHrKtudDdQos9iIapnx+PRiYnjpfzF4rNu/a48/o8Ed8KNX8Nj MPsQuaDmytype6pHv+iEA== Received: from pxi18 (pxi18.prod.google.com [10.243.27.18]) by wpaz33.hot.corp.google.com with ESMTP id o6F5cj6G011716 for ; Wed, 14 Jul 2010 22:38:45 -0700 Received: by pxi18 with SMTP id 18so281178pxi.4 for ; Wed, 14 Jul 2010 22:38:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.210.2 with SMTP id i2mr9383346wfg.299.1279172323874; Wed, 14 Jul 2010 22:38:43 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Wed, 14 Jul 2010 22:38:43 -0700 (PDT) Date: Wed, 14 Jul 2010 22:38:43 -0700 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 05:38:41 -0000 Draft 10 switched from "Token" scheme in the authorization header to "OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great. "Token" is ugly as sin, but is better than "OAuth". Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30 The problem with reusing "OAuth" is that there are existing implementations in the wild that have special behavior implemented for OAuth authorization headers. Since OAuth2 headers don't have the same semantics, we're going to break those implementations. We shouldn't reuse "OAuth" for the same reasons we shouldn't reuse "Negotiate", "NTLM", "Digest", or "Basic. Cheers, Brian From torsten@lodderstedt.net Wed Jul 14 22:50: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 CBC823A688F for ; Wed, 14 Jul 2010 22:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=-0.598, 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 D7iS-IvIUsyk for ; Wed, 14 Jul 2010 22:50:36 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by core3.amsl.com (Postfix) with ESMTP id 8913D3A69A6 for ; Wed, 14 Jul 2010 22:50:08 -0700 (PDT) Received: from [79.253.14.82] (helo=[192.168.71.41]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OZHKh-0003xZ-Ti; Thu, 15 Jul 2010 07:50:08 +0200 References: <4C3E389D.5080300@lodderstedt.net> <95C3FB14-F5C4-4ECB-91EF-9ED988C367DE@hueniverse.com> In-Reply-To: <95C3FB14-F5C4-4ECB-91EF-9ED988C367DE@hueniverse.com> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6345F9F9-2EDD-4199-9C90-339CB1757B0A@lodderstedt.net> X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Thu, 15 Jul 2010 07:49:33 +0200 To: Eran Hammer-Lahav X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 05:50:56 -0000 Did I get you right? Your answer is: Oauth is not suited for deployments wit= h different resource servers which rely in a single authz server? I don't know why you categorize this as "complex". Is it so unusual to have= let's say mail, webstorage, telephony, and payment services? At Deutsche Telekom, we operate such a deployment (with much more different r= esource servers) and I had hoped to move our token service towards OAuth v2.= =20 So would you recommend me zo stick to our proprietary protocol? regards, Torsten. Am 15.07.2010 um 00:39 schrieb Eran Hammer-Lahav : > If your deployment is that complicated, even my discovery proposal is not g= oing to help you...=20 >=20 > EHL >=20 >=20 >=20 > On Jul 14, 2010, at 18:37, "Marius Scurtescu" wrot= e: >=20 >> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt >> wrote: >>> I have a question concerning the OAuth philosophy: How many resource ser= vers >>> may be managed by a single OAuth authorization server? (a) A single reso= urce >>> server or (b) several of them exposing different resource types? >>>=20 >>> If the answer is (b) then how is a particular resource server identified= in >>> the protocol? Clients have Ids, end-users as well (at least in a future >>> protocol extension), but what about resource server Ids? >>>=20 >>> I think resource servers must be identifiable in multi-server deployment= s >>> for several reasons: >>> - Interpretation of the scope parameter should be resource server specif= ic - >>> "read" may have different meanings in mail and address book >>> - An authorization server probably wants to apply server-specific securi= ty >>> policy, e.g. different access token durations >>> - It will be possible to create special tokens per server >>>=20 >>> I think we should introduce a resource server id in the authz and access= >>> token request. >>>=20 >>> Any thoughts? >>=20 >> I think the scope fills this role. Scopes implemented as URIs, for >> example, allow the authz server to map them to resource servers. >>=20 >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From ivan.pulleyn@gmail.com Wed Jul 14 22:54: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 F0BA93A690F for ; Wed, 14 Jul 2010 22:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNLwBOVUjyKI for ; Wed, 14 Jul 2010 22:54:52 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id F20EB3A6872 for ; Wed, 14 Jul 2010 22:54:51 -0700 (PDT) Received: by gxk1 with SMTP id 1so105232gxk.31 for ; Wed, 14 Jul 2010 22:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=hnWupiAwRuf5XucjTIMhjZBojrmUCPDK+yjYpcBjxUU=; b=VsYFy60IzDA1qGonWmpru+1afsHUOlXRqrRFd4d5dXuEExjMtFzBbGGX2AASYwci71 l7p+UoPEpGqWTTpRjf7i/qyG0W91pVrpTidp5CAAfLFoQqfjiUh6QxD7Di7d0SjFGzTj yvruCZkkFf9u3UzyWKXkyB8zGHeXrCHP97LY4= 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=mLx3KfDu4+UN8xx0wUeQ/PHmeEuxpwzwGk1TZ3F3+KrCI80NLpu4yfwL39bnrcoWNJ bDJZvM8Ms6wDuggGvHMYElcBaNqcUqyWF+goL5/EfetwmEWgZVkEjl31fUXth119s3gM yo+P0NXLKFIacZZgK+kxkP6RAjhzgT/n7RnsI= MIME-Version: 1.0 Received: by 10.150.240.16 with SMTP id n16mr9329090ybh.316.1279173299387; Wed, 14 Jul 2010 22:54:59 -0700 (PDT) Received: by 10.150.95.19 with HTTP; Wed, 14 Jul 2010 22:54:59 -0700 (PDT) In-Reply-To: <6345F9F9-2EDD-4199-9C90-339CB1757B0A@lodderstedt.net> References: <4C3E389D.5080300@lodderstedt.net> <95C3FB14-F5C4-4ECB-91EF-9ED988C367DE@hueniverse.com> <6345F9F9-2EDD-4199-9C90-339CB1757B0A@lodderstedt.net> Date: Wed, 14 Jul 2010 22:54:59 -0700 Message-ID: From: Ivan Pulleyn To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=000e0cd23e081dbe28048b66beaa Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 05:54:53 -0000 --000e0cd23e081dbe28048b66beaa Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 14, 2010 at 10:49 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Did I get you right? Your answer is: Oauth is not suited for deployments > with different resource servers which rely in a single authz server? > > I don't know why you categorize this as "complex". Is it so unusual to > have let's say mail, webstorage, telephony, and payment services? > > At Deutsche Telekom, we operate such a deployment (with much more different > resource servers) and I had hoped to move our token service towards OAuth > v2. > > So would you recommend me zo stick to our proprietary protocol? > > I'm confused why scope isn't sufficient for your needs. Ivan... --000e0cd23e081dbe28048b66beaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 14, 2010 at 10:49 PM, Torste= n Lodderstedt <torsten@lodderstedt.net> wrote:
Did I get you right? Your answer is: Oauth is not suited for deployments wi= th different resource servers which rely in a single authz server?

I don't know why you categorize this as =A0"complex". Is it s= o unusual to have let's say mail, webstorage, telephony, and payment se= rvices?

At Deutsche Telekom, we operate such a deployment (with much more different= resource servers) and I had hoped to move our token service towards OAuth = v2.

So would you recommend me zo stick to our proprietary protocol?


I'm confused why scope isn't sufficien= t for your needs.

Ivan...

=A0
--000e0cd23e081dbe28048b66beaa-- From wmills@yahoo-inc.com Wed Jul 14 22:57: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 B47323A69C3 for ; Wed, 14 Jul 2010 22:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.158 X-Spam-Level: X-Spam-Status: No, score=-17.158 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGrIrvke-geY for ; Wed, 14 Jul 2010 22:57:13 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 5E61D3A6872 for ; Wed, 14 Jul 2010 22:57:13 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6F5uh5x088305; Wed, 14 Jul 2010 22:56:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:x-originalarrivaltime; b=Q6POhF2koQV64zul/qJrWWqDOXM0pDDS4gUA+ADs3OGe2UIXln64AsGV1v81FLdl Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 22:56:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Jul 2010 22:51:03 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6CB0@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] OAuth vs OAuth2 in Authorization header Thread-Index: Acsj4HAAyxAyb1p+TkCewvXCWFcpxwAARtzg References: From: "William Mills" To: "Brian Eaton" , X-OriginalArrivalTime: 15 Jul 2010 05:56:42.0881 (UTC) FILETIME=[8017B710:01CB23E2] Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 05:57:17 -0000 Token makes sense in the context of provisioning a more general token auth header which we overload on. That said I'm glad we're getting simpler. =20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Brian Eaton > Sent: Wednesday, July 14, 2010 10:39 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] OAuth vs OAuth2 in Authorization header >=20 > Draft 10 switched from "Token" scheme in the authorization=20 > header to "OAuth". I'd rather we didn't reuse OAuth. =20 > 'OAuth2' would be great. > "Token" is ugly as sin, but is better than "OAuth". >=20 > Spec section:=20 > http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30 >=20 > The problem with reusing "OAuth" is that there are existing=20 > implementations in the wild that have special behavior=20 > implemented for OAuth authorization headers. Since OAuth2=20 > headers don't have the same semantics, we're going to break=20 > those implementations. We shouldn't reuse "OAuth" for the=20 > same reasons we shouldn't reuse "Negotiate", "NTLM",=20 > "Digest", or "Basic. >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From torsten@lodderstedt.net Wed Jul 14 22:57:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4C03A6A76 for ; Wed, 14 Jul 2010 22:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=-0.523, 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 p4vvuZ3e-MH6 for ; Wed, 14 Jul 2010 22:57:47 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id 14D4C3A6A6A for ; Wed, 14 Jul 2010 22:57:46 -0700 (PDT) Received: from [79.253.14.82] (helo=[192.168.71.41]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OZHSF-0007o8-Il; Thu, 15 Jul 2010 07:57:55 +0200 References: <4C3E2DDA.3070905@lodderstedt.net> <4C3E30C4.8090901@lodderstedt.net> <4C3E3326.6020401@lodderstedt.net> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Thu, 15 Jul 2010 07:57:17 +0200 To: Brian Eaton X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 05:57:49 -0000 We implement the second option in our SSO protocol.=20 Am 15.07.2010 um 01:02 schrieb Brian Eaton : > On Wed, Jul 14, 2010 at 2:59 PM, Torsten Lodderstedt > wrote: >>> The second request (as you pointed out in your original mail) is >>> currently used to verify the client identity. Do you have a >>> suggestion for an alternate mechanism? >>>=20 >>=20 >> A digital signature over the authz request? Alternatively, the authz serv= er >> could encrypt the authz response. >=20 > Is anybody else implementing that model...? From lshepard@facebook.com Wed Jul 14 22:59: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 3F2243A6A0A for ; Wed, 14 Jul 2010 22:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFb+aQjvSWKO for ; Wed, 14 Jul 2010 22:59:08 -0700 (PDT) Received: from mx-out.facebook.com (outmail004.snc1.tfbnw.net [69.63.178.163]) by core3.amsl.com (Postfix) with ESMTP id 606033A69F6 for ; Wed, 14 Jul 2010 22:59:07 -0700 (PDT) Received: from [10.18.255.131] ([10.18.255.131:25913] helo=mail.thefacebook.com) by mta025.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 95/14-05162-3B3AE3C4; Wed, 14 Jul 2010 22:59:15 -0700 Received: from SC-MBX06.TheFacebook.com ([169.254.5.94]) by sc-hub03.TheFacebook.com ([fe80::1cfe:1f6b:8b35:cf7f%11]) with mapi; Wed, 14 Jul 2010 22:59:14 -0700 From: Luke Shepard To: Ivan Pulleyn Thread-Topic: [OAUTH-WG] resource server id needed? Thread-Index: AQHLI6MNM1sZjSQrmUirO3QaOcvB4JKxeEsAgAAAogCAAHglgIAAAYSAgAABLgA= Date: Thu, 15 Jul 2010 05:59:12 +0000 Message-ID: <032F9645-1006-440B-B684-A3932F213C68@facebook.com> References: <4C3E389D.5080300@lodderstedt.net> <95C3FB14-F5C4-4ECB-91EF-9ED988C367DE@hueniverse.com> <6345F9F9-2EDD-4199-9C90-339CB1757B0A@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_032F96451006440BB684A3932F213C68facebookcom_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 05:59:18 -0000 --_000_032F96451006440BB684A3932F213C68facebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yeah ... seems like OAuth is definitely suited for different resource servi= ces - as written, scope takes care of that. For instance Facebook offers me= ssages, photos, and a bunch of other services, across two different APIs (t= he Graph and REST) and we distinguish permissions using scope. As others have asked, why can't you just have a bunch of different scopes l= ike read_mail, read_webstorage, read_phone, etc? On Jul 14, 2010, at 10:54 PM, Ivan Pulleyn wrote: On Wed, Jul 14, 2010 at 10:49 PM, Torsten Lodderstedt > wrote: Did I get you right? Your answer is: Oauth is not suited for deployments wi= th different resource servers which rely in a single authz server? I don't know why you categorize this as "complex". Is it so unusual to hav= e let's say mail, webstorage, telephony, and payment services? At Deutsche Telekom, we operate such a deployment (with much more different= resource servers) and I had hoped to move our token service towards OAuth = v2. So would you recommend me zo stick to our proprietary protocol? I'm confused why scope isn't sufficient for your needs. Ivan... _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_032F96451006440BB684A3932F213C68facebookcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Yeah ... seems like OAuth is definite= ly suited for different resource services - as written, scope takes care of= that. For instance Facebook offers messages, photos, and a bunch of o= ther services, across two different APIs (the Graph and REST) and we distin= guish permissions using scope.

As others have asked, why= can't you just have a bunch of different scopes like read_mail, read_webst= orage, read_phone, etc?


On Jul 14, 2= 010, at 10:54 PM, Ivan Pulleyn wrote:



On Wed= , Jul 14, 2010 at 10:49 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Did I get you right? Your answer is: Oauth is not suited for deployments wi= th different resource servers which rely in a single authz server?

I don't know why you categorize this as  "complex". Is it so= unusual to have let's say mail, webstorage, telephony, and payment service= s?

At Deutsche Telekom, we operate such a deployment (with much more different= resource servers) and I had hoped to move our token service towards OAuth = v2.

So would you recommend me zo stick to our proprietary protocol?


I'm confused why scope isn't sufficient for yo= ur needs.

Ivan...

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

= --_000_032F96451006440BB684A3932F213C68facebookcom_-- From torsten@lodderstedt.net Wed Jul 14 23:02: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 415923A69F6 for ; Wed, 14 Jul 2010 23:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.233, 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 3Gwtyo9fHWGa for ; Wed, 14 Jul 2010 23:02:17 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by core3.amsl.com (Postfix) with ESMTP id 02F9D3A684A for ; Wed, 14 Jul 2010 23:02:16 -0700 (PDT) Received: from [79.253.14.82] (helo=[192.168.71.23]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1OZHWa-0004Xj-EF; Thu, 15 Jul 2010 08:02:24 +0200 Message-ID: <4C3EA46B.7070703@lodderstedt.net> Date: Thu, 15 Jul 2010 08:02:19 +0200 From: Torsten Lodderstedt User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4C3E2DDA.3070905@lodderstedt.net> <4C3E30C4.8090901@lodderstedt.net> <4C3E3326.6020401@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 06:02:18 -0000 why that? If there will be a signature proposal for resource server access, the same (simplified?) model could be applied to the authz server's API. And as I pointed out in my original posting, I see this as a _further_ option not the only one. While it is technically more complicated, it has its adavantages (we already discussed). One further advantage of already signing the inbound request is that the authz server can refuse unauthorized requests early. regards, Torsten. Eran Hammer-Lahav schrieb: > At some point this brings us back to 1.0... > > EHL > > > > On Jul 14, 2010, at 17:59, Torsten Lodderstedt wrote: > > >> Am 14.07.2010 23:52, schrieb Brian Eaton: >> >>> On Wed, Jul 14, 2010 at 2:48 PM, Torsten Lodderstedt >>> wrote: >>> >>> >>>> Yepp. That's an optimization of use case 2. That way the authz server does >>>> not need to store the authorization transaction's results in a database and >>>> there is no need to perform a a second request. >>>> >>>> >>> The authorization server doesn't need to store the transaction results >>> in a database regardless, the authorization code can be a signed >>> message. >>> >>> >> That's an indeed option. But then the whole data is transported twice >> between authz server and client. >> >> >>> The second request (as you pointed out in your original mail) is >>> currently used to verify the client identity. Do you have a >>> suggestion for an alternate mechanism? >>> >>> >> A digital signature over the authz request? Alternatively, the authz >> server could encrypt the authz response. >> >> regards, >> Torsten. >> >> From uidude@google.com Wed Jul 14 23:04: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 DDE403A67AE for ; Wed, 14 Jul 2010 23:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.376 X-Spam-Level: X-Spam-Status: No, score=-104.376 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_63=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 JBmV0ybLpE95 for ; Wed, 14 Jul 2010 23:04:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 192713A681A for ; Wed, 14 Jul 2010 23:04:38 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id o6F64lvL012513 for ; Wed, 14 Jul 2010 23:04:47 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279173888; bh=T9ZiSvJ5Ehp3f34WXFDnmZGPu3o=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=PF3WsF2yOb83f8FZhHBp4xO7teLAOrgni1TEktWovRn39p2kHvYOzapk9d6m4QUMi nhMfSgWQdrfZ87GsVRoMg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=pKiDm98ne2R3Kknays+iSPDM+YNZ6lcuNXsEvqXTZj9RuI+0m1h5uln9CDuzZYgxW ljOAfTQuVSeLXnIC3wgNw== Received: from qyk1 (qyk1.prod.google.com [10.241.83.129]) by kpbe15.cbf.corp.google.com with ESMTP id o6F64kYi005263 for ; Wed, 14 Jul 2010 23:04:46 -0700 Received: by qyk1 with SMTP id 1so2784340qyk.3 for ; Wed, 14 Jul 2010 23:04:46 -0700 (PDT) Received: by 10.224.113.85 with SMTP id z21mr509310qap.214.1279173886203; Wed, 14 Jul 2010 23:04:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.93.12 with HTTP; Wed, 14 Jul 2010 23:04:26 -0700 (PDT) In-Reply-To: References: <5710F82C0E73B04FA559560098BF95B124F9688DC4@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: Evan Gilbert Date: Wed, 14 Jul 2010 23:04:26 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000feaead82317d7b1048b66e113 X-System-Of-Record: true Cc: Zachary Zeltsan , OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 06:04:40 -0000 --000feaead82317d7b1048b66e113 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable "Password" doesn't seem to be the right analogy. You don't (or really shouldn't) store passwords in plain text or in cookies. How about "cookies"? Most web developers understand that cookies are used a= s a token that grants access to resources. We've also called these tokens"API cookies" when trying to describe them internally. On Tue, Jul 13, 2010 at 4:34 PM, Eran Hammer-Lahav wro= te: > I=92m only using 2828 definition of capability, not password. > > EHL > > > > On 7/13/10 3:20 PM, "Zachary Zeltsan" > wrote: > > According to the RFC 2828 an access token is rather a capability than a > password. The passwords are usually associated with the matching > identifiers, but an access token of OAuth 2.0 is used as a single credent= ial > that allows access to a protected resource. > > From RFC 2828: > $ password > > (C) A password is usually matched with a user identifier that is > explicitly presented in the authentication process, but in some > cases the identity may be implicit. > > Zachary > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > On Behalf Of Brian Eaton > Sent: Tuesday, July 13, 2010 4:43 PM > To: Faynberg, Igor (Igor) > Cc: OAuth WG > Subject: Re: [OAUTH-WG] "shared symmetric secret" > > On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg > wrote: > > In this case, the term "capability" MUST be defined up front. The word > > "capability" seems to carry a much broader meaning than password... > > It has a standard definition we can reference. From > http://www.ietf.org/rfc/rfc2828.txt > > $ capability > (I) A token, usually an unforgeable data value (sometimes called a > "ticket") that gives the bearer or holder the right to access a > system resource. Possession of the token is accepted by a system > as proof that the holder has been authorized to access the > resource named or indicated by the token. (See: access control > list, credential, digital certificate.) > > > _______________________________________________ > 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 > > --000feaead82317d7b1048b66e113 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable "Password" doesn't seem to be the right analogy. You don'= t (or really shouldn't) store passwords in plain text or in cookies.
How about "cookies"? Most web developers underst= and that cookies are used as a token that grants access to resources. We= 9;ve also called these tokens"API cookies" when trying to describ= e them internally.


On Tue, Jul 13, 201= 0 at 4:34 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
I=92m only using 2828 definition of capability, not password.

EHL



On 7/13/10 3:20 PM, "Zachary Zeltsan" <zachary.zeltsan@alcatel-lu= cent.com> wrote:

According to the RFC 2828 an access token is rather a capability than a = password. The passwords are usually associated with the matching identifier= s, but an access token of OAuth 2.0 is used as a single credential that all= ows access to a protected resource.

>From RFC 2828:
$ password
=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0(C) A password is usually matched with a user identifier = that is
=A0=A0=A0=A0=A0=A0explicitly presented in the authentication process, but i= n some
=A0=A0=A0=A0=A0=A0cases the identity may be implicit.

Zachary
-----Original Message-----
From: oauth-bou= nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Eaton
Sent: Tuesday, July 13, 2010 4:43 PM
To: Faynberg, Igor (Igor)
Cc: OAuth WG
Subject: Re: [OAUTH-WG] "shared symmetric secret"

On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg
<i= gor.faynberg@alcatel-lucent.com> wrote:
> In this case, the term "capability" MUST be defined up front= . The word
> "capability" seems to carry a much broader meaning than pass= word...

It has a standard definition we can reference. =A0From
http://ww= w.ietf.org/rfc/rfc2828.txt

=A0=A0=A0$ capability
=A0=A0=A0=A0=A0=A0(I) A token, usually an unforgeable data value (sometimes= called a
=A0=A0=A0=A0=A0=A0"ticket") that gives the bearer or holder the r= ight to access a
=A0=A0=A0=A0=A0=A0system resource. Possession of the token is accepted by a= system
=A0=A0=A0=A0=A0=A0as proof that the holder has been authorized to access th= e
=A0=A0=A0=A0=A0=A0resource named or indicated by the token. (See: access co= ntrol
=A0=A0=A0=A0=A0=A0list, credential, digital certificate.)

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


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


--000feaead82317d7b1048b66e113-- From wmills@yahoo-inc.com Wed Jul 14 23:09:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2A53A68D3 for ; Wed, 14 Jul 2010 23:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.332 X-Spam-Level: X-Spam-Status: No, score=-17.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSR7PrxF8WR4 for ; Wed, 14 Jul 2010 23:09:41 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id AAA433A68CF for ; Wed, 14 Jul 2010 23:09:41 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6F69T8Y028476; Wed, 14 Jul 2010 23:09:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=lzAmyTz4pjlIcjjPywZ6Z/kP+bi7YvuiZeyXmqV8hU5t8+uZtURrXdXTjKihpVA8 Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 23:09:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Jul 2010 23:09:28 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6CB2@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <6345F9F9-2EDD-4199-9C90-339CB1757B0A@lodderstedt.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] resource server id needed? Thread-Index: Acsj4dTykgDXgF9wSTCwBhsfrnndrwAAkzuA References: <4C3E389D.5080300@lodderstedt.net><95C3FB14-F5C4-4ECB-91EF-9ED988C367DE@hueniverse.com> <6345F9F9-2EDD-4199-9C90-339CB1757B0A@lodderstedt.net> From: "William Mills" To: "Torsten Lodderstedt" , "Eran Hammer-Lahav" X-OriginalArrivalTime: 15 Jul 2010 06:09:29.0449 (UTC) FILETIME=[4900B590:01CB23E4] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 06:09:43 -0000 I haven't seen the proposed discovery stuff yet, but discovery in the SASL stuff will solve this, and so would discovery advertized from the resource server.=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Torsten Lodderstedt > Sent: Wednesday, July 14, 2010 10:50 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] resource server id needed? >=20 > Did I get you right? Your answer is: Oauth is not suited for=20 > deployments with different resource servers which rely in a=20 > single authz server? >=20 > I don't know why you categorize this as "complex". Is it so=20 > unusual to have let's say mail, webstorage, telephony, and=20 > payment services? >=20 > At Deutsche Telekom, we operate such a deployment (with much=20 > more different resource servers) and I had hoped to move our=20 > token service towards OAuth v2.=20 >=20 > So would you recommend me zo stick to our proprietary protocol? >=20 > regards, > Torsten. >=20 >=20 >=20 > Am 15.07.2010 um 00:39 schrieb Eran Hammer-Lahav=20 > : >=20 > > If your deployment is that complicated, even my discovery=20 > proposal is not going to help you...=20 > >=20 > > EHL > >=20 > >=20 > >=20 > > On Jul 14, 2010, at 18:37, "Marius Scurtescu"=20 > wrote: > >=20 > >> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt=20 > >> wrote: > >>> I have a question concerning the OAuth philosophy: How=20 > many resource=20 > >>> servers may be managed by a single OAuth authorization=20 > server? (a) A=20 > >>> single resource server or (b) several of them exposing=20 > different resource types? > >>>=20 > >>> If the answer is (b) then how is a particular resource server=20 > >>> identified in the protocol? Clients have Ids, end-users=20 > as well (at=20 > >>> least in a future protocol extension), but what about=20 > resource server Ids? > >>>=20 > >>> I think resource servers must be identifiable in multi-server=20 > >>> deployments for several reasons: > >>> - Interpretation of the scope parameter should be resource server=20 > >>> specific - "read" may have different meanings in mail and address=20 > >>> book > >>> - An authorization server probably wants to apply server-specific=20 > >>> security policy, e.g. different access token durations > >>> - It will be possible to create special tokens per server > >>>=20 > >>> I think we should introduce a resource server id in the authz and=20 > >>> access token request. > >>>=20 > >>> Any thoughts? > >>=20 > >> I think the scope fills this role. Scopes implemented as URIs, for=20 > >> example, allow the authz server to map them to resource servers. > >>=20 > >> 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 >=20 From wmills@yahoo-inc.com Wed Jul 14 23:15: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 59EC83A6974 for ; Wed, 14 Jul 2010 23:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.181 X-Spam-Level: X-Spam-Status: No, score=-17.181 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+BBJskRTLbv for ; Wed, 14 Jul 2010 23:15:00 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id CDE7A3A67AE for ; Wed, 14 Jul 2010 23:14:58 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6F6B9Ir092529; Wed, 14 Jul 2010 23:11:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:x-originalarrivaltime; b=IcQSg7qOEwCXwo/2dfl0m21+vMxV1s0VJQjbi13+YGOEW5K+lRXgQuHlgMMcdBit Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 23:11:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Jul 2010 23:11:08 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6CB3@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <6345F9F9-2EDD-4199-9C90-339CB1757B0A@lodderstedt.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] resource server id needed? Thread-Index: Acsj4dTykgDXgF9wSTCwBhsfrnndrwAApP6w References: <4C3E389D.5080300@lodderstedt.net><95C3FB14-F5C4-4ECB-91EF-9ED988C367DE@hueniverse.com> <6345F9F9-2EDD-4199-9C90-339CB1757B0A@lodderstedt.net> From: "William Mills" To: "Torsten Lodderstedt" , "Eran Hammer-Lahav" X-OriginalArrivalTime: 15 Jul 2010 06:11:09.0569 (UTC) FILETIME=[84ADCF10:01CB23E4] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 06:15:06 -0000 No hang on. A single auth server should be able to handle man resource servers. It only gets hairy I think if you want multiple auth servers.=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Torsten Lodderstedt > Sent: Wednesday, July 14, 2010 10:50 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] resource server id needed? >=20 > Did I get you right? Your answer is: Oauth is not suited for=20 > deployments with different resource servers which rely in a=20 > single authz server? >=20 > I don't know why you categorize this as "complex". Is it so=20 > unusual to have let's say mail, webstorage, telephony, and=20 > payment services? >=20 > At Deutsche Telekom, we operate such a deployment (with much=20 > more different resource servers) and I had hoped to move our=20 > token service towards OAuth v2.=20 >=20 > So would you recommend me zo stick to our proprietary protocol? >=20 > regards, > Torsten. >=20 >=20 >=20 > Am 15.07.2010 um 00:39 schrieb Eran Hammer-Lahav=20 > : >=20 > > If your deployment is that complicated, even my discovery=20 > proposal is not going to help you...=20 > >=20 > > EHL > >=20 > >=20 > >=20 > > On Jul 14, 2010, at 18:37, "Marius Scurtescu"=20 > wrote: > >=20 > >> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt=20 > >> wrote: > >>> I have a question concerning the OAuth philosophy: How=20 > many resource=20 > >>> servers may be managed by a single OAuth authorization=20 > server? (a) A=20 > >>> single resource server or (b) several of them exposing=20 > different resource types? > >>>=20 > >>> If the answer is (b) then how is a particular resource server=20 > >>> identified in the protocol? Clients have Ids, end-users=20 > as well (at=20 > >>> least in a future protocol extension), but what about=20 > resource server Ids? > >>>=20 > >>> I think resource servers must be identifiable in multi-server=20 > >>> deployments for several reasons: > >>> - Interpretation of the scope parameter should be resource server=20 > >>> specific - "read" may have different meanings in mail and address=20 > >>> book > >>> - An authorization server probably wants to apply server-specific=20 > >>> security policy, e.g. different access token durations > >>> - It will be possible to create special tokens per server > >>>=20 > >>> I think we should introduce a resource server id in the authz and=20 > >>> access token request. > >>>=20 > >>> Any thoughts? > >>=20 > >> I think the scope fills this role. Scopes implemented as URIs, for=20 > >> example, allow the authz server to map them to resource servers. > >>=20 > >> 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 >=20 From torsten@lodderstedt.net Wed Jul 14 23:19: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 D049A3A681A for ; Wed, 14 Jul 2010 23:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.209, 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 wBbWS6hcfkYE for ; Wed, 14 Jul 2010 23:19:50 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by core3.amsl.com (Postfix) with ESMTP id 8BF473A67E6 for ; Wed, 14 Jul 2010 23:19:50 -0700 (PDT) Received: from [79.253.14.82] (helo=[192.168.71.23]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1OZHnc-0007hf-18; Thu, 15 Jul 2010 08:20:00 +0200 Message-ID: <4C3EA88A.1050509@lodderstedt.net> Date: Thu, 15 Jul 2010 08:19:54 +0200 From: Torsten Lodderstedt User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Marius Scurtescu References: <4C3E389D.5080300@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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 06:19:51 -0000 Marius Scurtescu schrieb: > On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt > wrote: > >> I have a question concerning the OAuth philosophy: How many resource servers >> may be managed by a single OAuth authorization server? (a) A single resource >> server or (b) several of them exposing different resource types? >> >> If the answer is (b) then how is a particular resource server identified in >> the protocol? Clients have Ids, end-users as well (at least in a future >> protocol extension), but what about resource server Ids? >> >> I think resource servers must be identifiable in multi-server deployments >> for several reasons: >> - Interpretation of the scope parameter should be resource server specific - >> "read" may have different meanings in mail and address book >> - An authorization server probably wants to apply server-specific security >> policy, e.g. different access token durations >> - It will be possible to create special tokens per server >> >> I think we should introduce a resource server id in the authz and access >> token request. >> >> Any thoughts? >> > > I think the scope fills this role. Scopes implemented as URIs, for > example, allow the authz server to map them to resource servers. > > Marius > That's an option indeed and would very much like to adopt it. But is the current draft specific enough to make that work? Let's take the example of a valid scope Eran gave in on of his recent postings: friends:read:2d photos:write:1y Where would you include the resource server's URI? I assume in front of every value, like this: http://myserver.example.com/friends:read:2d http://myserver.example.com/photos:write:1y Let's now take this example one step further and extend the first resource description. http://myserver.example.com/friends/max.mustermann/:read:2d http://myserver.example.com/photos:write:1y How shall a standard compliant authz server parse that scope? And what is the resource server part? The host part only or everything up to the last '/'? BTW: This example assumes ':' as internal delimiter between resources, permissions and durations. In my opinion, in order to support the use case I described, we have to come up with a more detailed specification of the syntax and semantics of scopes. What do you think? regards, Torsten. From torsten@lodderstedt.net Wed Jul 14 23:22: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 695A33A69D0 for ; Wed, 14 Jul 2010 23:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.190, 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 2Kz9QKlakK4l for ; Wed, 14 Jul 2010 23:22:56 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by core3.amsl.com (Postfix) with ESMTP id 8415D3A681A for ; Wed, 14 Jul 2010 23:22:56 -0700 (PDT) Received: from [79.253.14.82] (helo=[192.168.71.23]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1OZHqb-0003ev-JR; Thu, 15 Jul 2010 08:23:05 +0200 Message-ID: <4C3EA944.1060302@lodderstedt.net> Date: Thu, 15 Jul 2010 08:23:00 +0200 From: Torsten Lodderstedt User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian Eaton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 06:22:57 -0000 +1 for "OAuth2" Brian Eaton schrieb: > Draft 10 switched from "Token" scheme in the authorization header to > "OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great. > "Token" is ugly as sin, but is better than "OAuth". > > Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30 > > The problem with reusing "OAuth" is that there are existing > implementations in the wild that have special behavior implemented for > OAuth authorization headers. Since OAuth2 headers don't have the same > semantics, we're going to break those implementations. We shouldn't > reuse "OAuth" for the same reasons we shouldn't reuse "Negotiate", > "NTLM", "Digest", or "Basic. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From beaton@google.com Wed Jul 14 23:25:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C143C3A67AE for ; Wed, 14 Jul 2010 23:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.888 X-Spam-Level: X-Spam-Status: No, score=-101.888 tagged_above=-999 required=5 tests=[AWL=0.089, 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 dJ0AgF5Boqwa for ; Wed, 14 Jul 2010 23:25:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id BED143A6872 for ; Wed, 14 Jul 2010 23:25:38 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o6F6Pm6x006617 for ; Wed, 14 Jul 2010 23:25:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279175148; bh=NDEs4XzzeWlQQQTI0jiPgjnBa3U=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=kwsQLgQsrClHKh/+OFqPGFmUP1rZgor1xnv8VH78Nc81L7Ewk9TKqWLocDlR8BQaH 437lEebGss2p6jUiYXhAQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=pFU6tNFsxJOT94XV1mlSmNzMOCt7PVbsFV0/9f6PjSJu9tg30kJHVa1rApCA7f6ib AxrCpjPP7nL3xkkwwYQrQ== Received: from pxi19 (pxi19.prod.google.com [10.243.27.19]) by hpaq7.eem.corp.google.com with ESMTP id o6F6PklO023658 for ; Wed, 14 Jul 2010 23:25:47 -0700 Received: by pxi19 with SMTP id 19so332075pxi.12 for ; Wed, 14 Jul 2010 23:25:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.144.2 with SMTP id r2mr7307495wfd.300.1279175146236; Wed, 14 Jul 2010 23:25:46 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Wed, 14 Jul 2010 23:25:46 -0700 (PDT) In-Reply-To: <4C3EA46B.7070703@lodderstedt.net> References: <4C3E2DDA.3070905@lodderstedt.net> <4C3E30C4.8090901@lodderstedt.net> <4C3E3326.6020401@lodderstedt.net> <4C3EA46B.7070703@lodderstedt.net> Date: Wed, 14 Jul 2010 23:25:46 -0700 Message-ID: From: Brian Eaton To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 06:25:39 -0000 On Wed, Jul 14, 2010 at 11:02 PM, Torsten Lodderstedt wrote: > why that? If there will be a signature proposal for resource server access, > the same (simplified?) model could be applied to the authz server's API. Sure. Other folks have used signed URLs in this kind of protocol as well: http://developer.yahoo.com/bbauth/user.html. Why not write up your proposal as an alternate flow (right next to "user-agent" and "web-server") and see whether other people will implement it? From James.H.Manger@team.telstra.com Thu Jul 15 00:00: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 3BAB03A6A6A for ; Thu, 15 Jul 2010 00:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, 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 OHjwFAtH1Sze for ; Thu, 15 Jul 2010 00:00:13 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id 0B38E3A69F9 for ; Thu, 15 Jul 2010 00:00:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,206,1278252000"; d="scan'208";a="6017870" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 15 Jul 2010 17:00:20 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6043"; a="4623904" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipccni.tcif.telstra.com.au with ESMTP; 15 Jul 2010 17:00:22 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Thu, 15 Jul 2010 17:00:21 +1000 From: "Manger, James H" To: "oauth@ietf.org" , Brian Eaton Date: Thu, 15 Jul 2010 17:00:44 +1000 Thread-Topic: [OAUTH-WG] OAuth vs OAuth2 in Authorization header Thread-Index: Acsj5jSIaOM5cIMoRqCCxMmpinVPbwAANi3A Message-ID: <255B9BB34FB7D647A506DC292726F6E112662F02E7@WSMSG3153V.srv.dir.telstra.com> References: <4C3EA944.1060302@lodderstedt.net> In-Reply-To: <4C3EA944.1060302@lodderstedt.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 07:00:14 -0000 > Draft 10 switched from "Token" scheme in the authorization header to > "OAuth". I'd rather we didn't reuse OAuth. I agree that "OAuth" is taken as a scheme name. I like "Bearer" for the Authorization header scheme holding an access token= . We should use a different name for the WWW-Authentication scheme that annou= nces that user delegation or credential-swapping can be used to get credent= ials to access this service. "OAuth2" would be a decent choice for this, "D= elegate" might be even better. --> GET ... <-- 401 WWW-Authenticate: Delegate realm=3D... user_uri=3D... token_uri=3D... f= eatures=3D... <-> do the OAuth2 stuff --> GET ... Authorization: Bearer a=3D... --=20 James Manger From igor.faynberg@alcatel-lucent.com Thu Jul 15 00:24: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 57F863A6987 for ; Thu, 15 Jul 2010 00:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 BGtWzVLvPSBA for ; Thu, 15 Jul 2010 00:24:20 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 4F2CD3A67E6 for ; Thu, 15 Jul 2010 00:24:20 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o6F7OSR3017869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jul 2010 02:24:29 -0500 (CDT) Received: from [135.244.1.40] (faynberg.lra.lucent.com [135.244.1.40]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o6F7ORIL002353; Thu, 15 Jul 2010 02:24:28 -0500 (CDT) Message-ID: <4C3EB77C.5090809@alcatel-lucent.com> Date: Thu, 15 Jul 2010 03:23:40 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Torsten Lodderstedt References: <012AB2B223CB3F4BB846962876F47217059B6C4D@SNV-EXVS08.ds.corp.yahoo.com><012AB2B223CB3F4BB846962876F47217059B6C7A@SNV-EXVS08.ds.corp.yahoo.com> <012AB2B223CB3F4BB846962876F47217059B6C92@SNV-EXVS08.ds.corp.yahoo.com> <4C3E2FDA.9050006@lodderstedt.net> In-Reply-To: <4C3E2FDA.9050006@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: OAuth WG Subject: Re: [OAUTH-WG] single use authorization codes 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, 15 Jul 2010 07:24:21 -0000 An important point, which I think should be captured in the security consideration section. Igor Torsten Lodderstedt wrote: > what about guessing/brute force attacks on the code? Supposed an > authorization server issuing tokens for a client w/o secret. Then the > number of attempts needed to obtain a token issued to that client only > depends on the length and randomness of the code. Should the spec > state something about that? > > regards, > Torsten. > >> We're trying to design around transport security with short expiration >> and single use tokens. SSL solves the problem >> >> >>> -----Original Message----- >>> From: Brian Eaton [mailto:beaton@google.com] >>> Sent: Wednesday, July 14, 2010 1:35 PM >>> To: William Mills >>> Cc: Eran Hammer-Lahav; OAuth WG >>> Subject: Re: [OAUTH-WG] single use authorization codes >>> >>> On Wed, Jul 14, 2010 at 11:58 AM, William Mills >>> wrote: >>> >>>> If I can see things go by on the fly I can submit the token >>>> >>> late and >>> >>>> mess with the user by revoking their session. >>>> >>> Meh. >>> >>> If the best the attacker can do in those circumstances is >>> DOS, we're in good shape. >>> >>> Bear in mind that if we do nothing, the attacker can probably >>> get the user's data. >>> >>> >> _______________________________________________ >> 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 elena.lozano@rediris.es Thu Jul 15 03:54: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 7644A3A6403 for ; Thu, 15 Jul 2010 03:54:16 -0700 (PDT) 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 GNOQpsP5Le2Q for ; Thu, 15 Jul 2010 03:54:15 -0700 (PDT) Received: from irisout1.rediris.es (irisout1.rediris.es [130.206.24.3]) by core3.amsl.com (Postfix) with ESMTP id F19B13A67F0 for ; Thu, 15 Jul 2010 03:54:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,207,1278280800"; d="scan'208,217";a="27859926" Received: from snail.rediris.es.6.206.130.in-addr.arpa ([130.206.6.77]) by abel.rediris.es with ESMTP/TLS/AES128-SHA; 15 Jul 2010 12:50:53 +0200 From: Elena Lozano Content-Type: multipart/alternative; boundary=Apple-Mail-1-236352007 Date: Thu, 15 Jul 2010 12:54:22 +0200 Message-Id: <2D0B937E-1222-469B-8500-227237550F94@rediris.es> To: oauth@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [OAUTH-WG] Assertion profile + client_secret and client_id security X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 10:54:16 -0000 --Apple-Mail-1-236352007 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi everyone, As we adapt the RedIRIS PHP OAuth2 library[1] to the last version of the = draft we have found some issues regarding the client secret and client = id. The thing is that we don't understand the security given with the = client_id and client_secret of the assertion profile. The last changes on the protocol said that: "the authorization server MUST verify that the redirection URI received matches the registered URI associated with the client identifier." This provides one way to perform the correct identification of the = client but doesn't work with the assertion profile. In the assertion profile, we understand that the client_id is optional = and that the assertion could have the information about the client = identification.=20 This could happen when the assertion authorizes an application, but in = our use cases, the assertions doesn't have information about the client = application. This is a problem because in our request to the Auth Server we cannot = check if the application is registered correctly. We can send the = client_id in the request, but we have the same problem, because someone = can 'steal' our client id and impersonate the client.=20 We think that we can solve that signing parameters in the request, = adding the client_id signature or something like this but we're not sure = that this is referred in the protocol. What do you think it's better to solve this issue? I don't know if i'm understanding something in a wrong way, so please = correct me if i'm wrong. Thanks! Elena. [1] http://www.rediris.es/oauth2= --Apple-Mail-1-236352007 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
   redirection URI received matches the = registered URI associated with
   the client = identifier."

This provides one way to perform = the correct identification of the client but doesn't work with the =  assertion profile.

In the assertion = profile, we understand that the client_id is optional and that the = assertion could have the information about the client = identification. 
This could happen when the assertion = authorizes an application, but in our use cases, the assertions doesn't = have information about the client application.
This is a = problem because in our request to the Auth Server we cannot check if the = application is registered correctly. We can send the client_id in the = request, but we have the same problem, because someone can 'steal' our = client id and impersonate the client. 

We = think that we can solve that signing parameters in the request, adding = the client_id signature or something like this but we're not sure that = this is referred in the protocol.

What do you = think it's better to solve this issue?

I don't = know if i'm understanding something in a wrong way, so = please correct me if i'm wrong.

http://www.rediris.es/oauth2
= --Apple-Mail-1-236352007-- From torsten@lodderstedt.net Thu Jul 15 04:10: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 0C8B03A68C7 for ; Thu, 15 Jul 2010 04:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 2PHYB6fVS+bB for ; Thu, 15 Jul 2010 04:10:37 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by core3.amsl.com (Postfix) with ESMTP id 327F63A695D for ; Thu, 15 Jul 2010 04:10:36 -0700 (PDT) Received: from [80.187.144.91] (helo=[10.135.144.217]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OZMKz-0006fO-P1; Thu, 15 Jul 2010 13:10:46 +0200 References: <2D0B937E-1222-469B-8500-227237550F94@rediris.es> In-Reply-To: <2D0B937E-1222-469B-8500-227237550F94@rediris.es> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-9-237305322 Message-Id: <1EB65D29-AEFE-420F-841D-E0B69A4236E7@lodderstedt.net> X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Thu, 15 Jul 2010 13:10:08 +0200 To: Elena Lozano X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion profile + client_secret and client_id security X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 11:10:39 -0000 --Apple-Mail-9-237305322 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Why don't you use the client secret to authenticate the application? The spe= c allows you to use a BASIC authorization header for that purpose. Regards, Torsten. Am 15.07.2010 um 12:54 schrieb Elena Lozano : > Hi everyone, >=20 > As we adapt the RedIRIS PHP OAuth2 library[1] to the last version of the d= raft we have found some issues regarding the client secret and client id. >=20 > The thing is that we don't understand the security given with the client_i= d and client_secret of the assertion profile. >=20 > The last changes on the protocol said that: >=20 > "the authorization server MUST verify that the > redirection URI received matches the registered URI associated with > the client identifier." >=20 > This provides one way to perform the correct identification of the client b= ut doesn't work with the assertion profile. >=20 > In the assertion profile, we understand that the client_id is optional and= that the assertion could have the information about the client identificati= on.=20 > This could happen when the assertion authorizes an application, but in our= use cases, the assertions doesn't have information about the client applica= tion. > This is a problem because in our request to the Auth Server we cannot chec= k if the application is registered correctly. We can send the client_id in t= he request, but we have the same problem, because someone can 'steal' our cl= ient id and impersonate the client.=20 >=20 > We think that we can solve that signing parameters in the request, adding t= he client_id signature or something like this but we're not sure that this i= s referred in the protocol. >=20 > What do you think it's better to solve this issue? >=20 > I don't know if i'm understanding something in a wrong way, so please corr= ect me if i'm wrong. >=20 > Thanks! >=20 > Elena. >=20 > [1] http://www.rediris.es/oauth2 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-9-237305322 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Why don't you use the client secret to a= uthenticate the application? The spec allows you to use a BASIC authorizatio= n header for that purpose.

Regards,
Torst= en.


Am 15.07.2010 um 12:54 schrieb Elena Lozano <elena.lozano@rediris.es>:
Hi everyone,

As we adapt the RedIRIS PHP OAuth2 library[1] to the last version of t= he draft we have found some issues regarding the client secret and client id= .

The thing is that we don't understand the securit= y given with the client_id and client_secret of the assertion profile.
=

The last changes on the protocol said that:
"the authorization server MUST verify that the
 =   redirection URI received matches the registered URI associated with
   the client identifier."

This p= rovides one way to perform the correct identification of the client but does= n't work with the  assertion profile.

In the a= ssertion profile, we understand that the client_id is optional and that the a= ssertion could have the information about the client identification. 
This could happen when the assertion authorizes an application, but= in our use cases, the assertions doesn't have information about the client a= pplication.
This is a problem because in our request to the Auth S= erver we cannot check if the application is registered correctly. We can sen= d the client_id in the request, but we have the same problem, because someon= e can 'steal' our client id and impersonate the client. 

=
We think that we can solve that signing parameters in the request= , adding the client_id signature or something like this but we're not sure t= hat this is referred in the protocol.

What do you t= hink it's better to solve this issue?

I don't know i= f i'm understanding something in a wrong way, so please correct me if i= 'm wrong.

Thank= s!

=
Elena.=

_______________________________________________
OAut= h mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-9-237305322-- From eran@hueniverse.com Thu Jul 15 06:07:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88EDD3A6976 for ; Thu, 15 Jul 2010 06:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 EYcQ8bRAOWZa for ; Thu, 15 Jul 2010 06:07:19 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 409673A68C5 for ; Thu, 15 Jul 2010 06:07:19 -0700 (PDT) Received: (qmail 4316 invoked from network); 15 Jul 2010 13:07:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jul 2010 13:07:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 15 Jul 2010 06:07:28 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Thu, 15 Jul 2010 06:07:20 -0700 Thread-Topic: [OAUTH-WG] OAuth vs OAuth2 in Authorization header Thread-Index: AcskHqx2cjOATDosRQaiLmQjDRJ6Bg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 13:07:20 -0000 I would like people to raise their hand and explain how this will break act= ual 1.0 deployments.=20 EHL On Jul 15, 2010, at 1:38, Brian Eaton wrote: > Draft 10 switched from "Token" scheme in the authorization header to > "OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great. > "Token" is ugly as sin, but is better than "OAuth". >=20 > Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30 >=20 > The problem with reusing "OAuth" is that there are existing > implementations in the wild that have special behavior implemented for > OAuth authorization headers. Since OAuth2 headers don't have the same > semantics, we're going to break those implementations. We shouldn't > reuse "OAuth" for the same reasons we shouldn't reuse "Negotiate", > "NTLM", "Digest", or "Basic. >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Jul 15 06:25: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 F33763A6A44 for ; Thu, 15 Jul 2010 06:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, 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 C6FSgbDiKcA0 for ; Thu, 15 Jul 2010 06:25:50 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 921103A6A21 for ; Thu, 15 Jul 2010 06:25:50 -0700 (PDT) Received: (qmail 8137 invoked from network); 15 Jul 2010 13:26:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jul 2010 13:25:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 15 Jul 2010 06:25:59 -0700 From: Eran Hammer-Lahav To: Eran Hammer-Lahav , Brian Eaton Date: Thu, 15 Jul 2010 06:25:57 -0700 Thread-Topic: [OAUTH-WG] OAuth vs OAuth2 in Authorization header Thread-Index: AcskHqx2cjOATDosRQaiLmQjDRJ6BgAApWLF Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8645A75372D5eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 13:25:57 -0000 --_000_C8645A75372D5eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To elaborate a bit: Since there is no discovery in 1.0, the only place this can create a confli= ct is on the server side, when servers support both new and old schemes, an= d need to tell which version the client is using. This is the same issue as= using the 'oauth_token' parameter in the query or body. Since there is no = discovery, no 2.0 client is going to try and talk to a 1.0 server because t= hat would be a like trying to speak SMTP to an XMPP port. On the server sid= e, adding support for 2.0 already requires code changes. If this proves to be an actual issue with a deployed system, I don't care a= bout using a different name but: - 'OAuth2' is "ugly as sin", and puts us on the broken path to produce an '= OAuth3', etc. - We need to have more discussions about using different schemes with diffe= rent token properties (i.e. Bearer, Signed, etc.). Some here want to break = this into highly specialized schemes, while others want to use 2, and some = a single scheme for everything (similar to 1.0). Using multiple headers doe= sn't break much on the 'Authorization' side because the server can easily h= andle it. But on the 'WWW-Authenticate' side it means having to define mult= iple schemes with their own discovery parameters, their own extensions, etc= . This will turn into an complex and messy framework with too many confusin= g headers, etc. So bikeshedding aside, we need to reach consensus on how to architect the h= eaders first, then we can find a name or names that don't annoy people like= 'Token', 'OAuth', or 'OAuth2'. EHL On 7/15/10 6:07 AM, "Eran Hammer-Lahav" wrote: I would like people to raise their hand and explain how this will break act= ual 1.0 deployments. EHL On Jul 15, 2010, at 1:38, Brian Eaton wrote: > Draft 10 switched from "Token" scheme in the authorization header to > "OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great. > "Token" is ugly as sin, but is better than "OAuth". > > Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30 > > The problem with reusing "OAuth" is that there are existing > implementations in the wild that have special behavior implemented for > OAuth authorization headers. Since OAuth2 headers don't have the same > semantics, we're going to break those implementations. We shouldn't > reuse "OAuth" for the same reasons we shouldn't reuse "Negotiate", > "NTLM", "Digest", or "Basic. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C8645A75372D5eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] OAuth vs OAuth2 in Authorization header To elaborate a bit:

Since there is no discovery in 1.0, the only place this can create a confli= ct is on the server side, when servers support both new and old schemes, an= d need to tell which version the client is using. This is the same issue as= using the ‘oauth_token’ parameter in the query or body. Since = there is no discovery, no 2.0 client is going to try and talk to a 1.0 serv= er because that would be a like trying to speak SMTP to an XMPP port. On th= e server side, adding support for 2.0 already requires code changes.

If this proves to be an actual issue with a deployed system, I don’t = care about using a different name but:

- ‘OAuth2’ is “ugly as sin”, and puts us on the bro= ken path to produce an ‘OAuth3’, etc.
- We need to have more discussions about using different schemes with diffe= rent token properties (i.e. Bearer, Signed, etc.). Some here want to break = this into highly specialized schemes, while others want to use 2, and some = a single scheme for everything (similar to 1.0). Using multiple headers doe= sn’t break much on the ‘Authorization’ side because the s= erver can easily handle it. But on the ‘WWW-Authenticate’ side = it means having to define multiple schemes with their own discovery paramet= ers, their own extensions, etc. This will turn into an complex and messy fr= amework with too many confusing headers, etc.

So bikeshedding aside, we need to reach consensus on how to architect the h= eaders first, then we can find a name or names that don’t annoy peopl= e like ‘Token’, ‘OAuth’, or ‘OAuth2’.
EHL


On 7/15/10 6:07 AM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

I would like people to raise their hand and= explain how this will break actual 1.0 deployments.

EHL



On Jul 15, 2010, at 1:38, Brian Eaton <bea= ton@google.com> wrote:

> Draft 10 switched from "Token" scheme in the authorization h= eader to
> "OAuth".  I'd rather we didn't reuse OAuth.  'OAut= h2' would be great.
> "Token" is ugly as sin, but is better than "OAuth"= .
>
> Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30=
>
> The problem with reusing "OAuth" is that there are existing<= BR> > implementations in the wild that have special behavior implemented for=
> OAuth authorization headers.  Since OAuth2 headers don't have the= same
> semantics, we're going to break those implementations.  We should= n't
> reuse "OAuth" for the same reasons we shouldn't reuse "= Negotiate",
> "NTLM", "Digest", or "Basic.
>
> Cheers,
> Brian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C8645A75372D5eranhueniversecom_-- From eran@hueniverse.com Thu Jul 15 06:30: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 7EF503A6951 for ; Thu, 15 Jul 2010 06:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.129, 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 RrRAOh4SseVD for ; Thu, 15 Jul 2010 06:30:23 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E6F8E3A6A15 for ; Thu, 15 Jul 2010 06:30:22 -0700 (PDT) Received: (qmail 13654 invoked from network); 15 Jul 2010 13:30:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jul 2010 13:30:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 15 Jul 2010 06:30:31 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Thu, 15 Jul 2010 06:30:29 -0700 Thread-Topic: [OAUTH-WG] resource server id needed? Thread-Index: Acsj4ZeLS3+Z+HvxQEWCY7W95HLkuQAQEyWu Message-ID: In-Reply-To: <6345F9F9-2EDD-4199-9C90-339CB1757B0A@lodderstedt.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8645B85372D8eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 13:30:30 -0000 --_000_C8645B85372D8eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No. It is. Let me ask you this: why can't you use 'photos:server1' and 'photos:server2= ' as scopes? EHL On 7/14/10 10:49 PM, "Torsten Lodderstedt" wrote: Did I get you right? Your answer is: Oauth is not suited for deployments wi= th different resource servers which rely in a single authz server? I don't know why you categorize this as "complex". Is it so unusual to hav= e let's say mail, webstorage, telephony, and payment services? At Deutsche Telekom, we operate such a deployment (with much more different= resource servers) and I had hoped to move our token service towards OAuth = v2. So would you recommend me zo stick to our proprietary protocol? regards, Torsten. Am 15.07.2010 um 00:39 schrieb Eran Hammer-Lahav : > If your deployment is that complicated, even my discovery proposal is not= going to help you... > > EHL > > > > On Jul 14, 2010, at 18:37, "Marius Scurtescu" wro= te: > >> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt >> wrote: >>> I have a question concerning the OAuth philosophy: How many resource se= rvers >>> may be managed by a single OAuth authorization server? (a) A single res= ource >>> server or (b) several of them exposing different resource types? >>> >>> If the answer is (b) then how is a particular resource server identifie= d in >>> the protocol? Clients have Ids, end-users as well (at least in a future >>> protocol extension), but what about resource server Ids? >>> >>> I think resource servers must be identifiable in multi-server deploymen= ts >>> for several reasons: >>> - Interpretation of the scope parameter should be resource server speci= fic - >>> "read" may have different meanings in mail and address book >>> - An authorization server probably wants to apply server-specific secur= ity >>> policy, e.g. different access token durations >>> - It will be possible to create special tokens per server >>> >>> I think we should introduce a resource server id in the authz and acces= s >>> token request. >>> >>> Any thoughts? >> >> I think the scope fills this role. Scopes implemented as URIs, for >> example, allow the authz server to map them to resource servers. >> >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --_000_C8645B85372D8eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] resource server id needed? No. It is.

Let me ask you this: why can’t you use ‘photos:server1’ a= nd ‘photos:server2’ as scopes?

EHL


On 7/14/10 10:49 PM, "Torsten Lodderstedt" <torsten@lodderstedt.net> wrote:

Did I get you right? Your answer is: Oauth = is not suited for deployments with different resource servers which rely in= a single authz server?

I don't know why you categorize this as  "complex". Is it so= unusual to have let's say mail, webstorage, telephony, and payment service= s?

At Deutsche Telekom, we operate such a deployment (with much more different= resource servers) and I had hoped to move our token service towards OAuth = v2.

So would you recommend me zo stick to our proprietary protocol?

regards,
Torsten.



Am 15.07.2010 um 00:39 schrieb Eran Hammer-Lahav <eran@hueniverse.com>:

> If your deployment is that complicated, even my discovery proposal is = not going to help you...
>
> EHL
>
>
>
> On Jul 14, 2010, at 18:37, "Marius Scurtescu" <mscurtescu@google.com> wrote:
>
>> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
>> <torsten@lodderstedt.net> wrote:
>>> I have a question concerning the OAuth philosophy: How many re= source servers
>>> may be managed by a single OAuth authorization server? (a) A s= ingle resource
>>> server or (b) several of them exposing different resource type= s?
>>>
>>> If the answer is (b) then how is a particular resource server = identified in
>>> the protocol? Clients have Ids, end-users as well (at least in= a future
>>> protocol extension), but what about resource server Ids?
>>>
>>> I think resource servers must be identifiable in multi-server = deployments
>>> for several reasons:
>>> - Interpretation of the scope parameter should be resource ser= ver specific -
>>> "read" may have different meanings in mail and addre= ss book
>>> - An authorization server probably wants to apply server-speci= fic security
>>> policy, e.g. different access token durations
>>> - It will be possible to create special tokens per server
>>>
>>> I think we should introduce a resource server id in the authz = and access
>>> token request.
>>>
>>> Any thoughts?
>>
>> I think the scope fills this role. Scopes implemented as URIs, for=
>> example, allow the authz server to map them to resource servers. >>
>> Marius
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/oauth

--_000_C8645B85372D8eranhueniversecom_-- From eran@hueniverse.com Thu Jul 15 06:35: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 3C14F3A6A05 for ; Thu, 15 Jul 2010 06:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=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 CfseB3ejLA9v for ; Thu, 15 Jul 2010 06:35:47 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 0FDB53A696C for ; Thu, 15 Jul 2010 06:35:44 -0700 (PDT) Received: (qmail 20644 invoked from network); 15 Jul 2010 13:35:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jul 2010 13:35:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 15 Jul 2010 06:35:41 -0700 From: Eran Hammer-Lahav To: Evan Gilbert Date: Thu, 15 Jul 2010 06:35:39 -0700 Thread-Topic: [OAUTH-WG] "shared symmetric secret" Thread-Index: Acsj46O8Omf4x8BSS3OMw7TLIDwAbQAPvkoz Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8645CBB372DAeranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 13:35:55 -0000 --_000_C8645CBB372DAeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Access tokens should not be stored in plain text either since stealing them= is just like stealing a password. As for cookies, client developers do very little to protect cookies today. = While the theory might be similar, in practice, telling a client developer = this is just like a cookies doesn't warn them enough. EHL On 7/14/10 11:04 PM, "Evan Gilbert" wrote: "Password" doesn't seem to be the right analogy. You don't (or really shoul= dn't) store passwords in plain text or in cookies. How about "cookies"? Most web developers understand that cookies are used a= s a token that grants access to resources. We've also called these tokens"A= PI cookies" when trying to describe them internally. On Tue, Jul 13, 2010 at 4:34 PM, Eran Hammer-Lahav wr= ote: I'm only using 2828 definition of capability, not password. EHL On 7/13/10 3:20 PM, "Zachary Zeltsan" > wrote: According to the RFC 2828 an access token is rather a capability than a pas= sword. The passwords are usually associated with the matching identifiers, = but an access token of OAuth 2.0 is used as a single credential that allows= access to a protected resource. >From RFC 2828: $ password (C) A password is usually matched with a user identifier that is explicitly presented in the authentication process, but in some cases the identity may be implicit. Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf Of Brian Eaton Sent: Tuesday, July 13, 2010 4:43 PM To: Faynberg, Igor (Igor) Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg = > wrote: > In this case, the term "capability" MUST be defined up front. The word > "capability" seems to carry a much broader meaning than password... It has a standard definition we can reference. From http://www.ietf.org/rfc/rfc2828.txt $ capability (I) A token, usually an unforgeable data value (sometimes called a "ticket") that gives the bearer or holder the right to access a system resource. Possession of the token is accepted by a system as proof that the holder has been authorized to access the resource named or indicated by the token. (See: access control list, credential, digital certificate.) _______________________________________________ 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_C8645CBB372DAeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] "shared symmetric secret" Access tokens should not be stored in plain text either since stealin= g them is just like stealing a password.

As for cookies, client developers do very little to protect cookies today. = While the theory might be similar, in practice, telling a client developer = this is just like a cookies doesn’t warn them enough.

EHL


On 7/14/10 11:04 PM, "Evan Gilbert" <uidude@google.com> wrote:

"Password" doesn't seem to be the= right analogy. You don't (or really shouldn't) store passwords in plain te= xt or in cookies.

How about "cookies"? Most web developers understand that cookies = are used as a token that grants access to resources. We've also called thes= e tokens"API cookies" when trying to describe them internally.

On Tue, Jul 13, 2010 at 4:34 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
I’m only using 2828 definition of cap= ability, not password.

EHL



On 7/13/10 3:20 PM, "Zachary Zeltsan" <zachary.zeltsan@alcatel-lucent.com <http://zachary.zeltsan@alcat= el-lucent.com> > wrote:

According to the RFC 2828 an access token i= s rather a capability than a password. The passwords are usually associated= with the matching identifiers, but an access token of OAuth 2.0 is used as= a single credential that allows access to a protected resource.

>From RFC 2828:
$ password
=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0(C) A password is usually matched with a user identifier = that is
=A0=A0=A0=A0=A0=A0explicitly presented in the authentication process, but i= n some
=A0=A0=A0=A0=A0=A0cases the identity may be implicit.

Zachary
-----Original Message-----
From: oauth-bounces@ietf.org <http://oauth-bounces@ietf.org>= ;  [mailto:oauth-bounces@iet= f.org] On Behalf Of Brian Eaton
Sent: Tuesday, July 13, 2010 4:43 PM
To: Faynberg, Igor (Igor)
Cc: OAuth WG
Subject: Re: [OAUTH-WG] "shared symmetric secret"

On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg
<igor.faynberg@alcatel-luce= nt.com <http://i= gor.faynberg@alcatel-lucent.com> > wrote:
> In this case, the term "capability" MUST be defined up front= . The word
> "capability" seems to carry a much broader meaning than pass= word...

It has a standard definition we can reference. =A0From
http://www.ietf.org/rfc/rfc= 2828.txt

=A0=A0=A0$ capability
=A0=A0=A0=A0=A0=A0(I) A token, usually an unforgeable data value (sometimes= called a
=A0=A0=A0=A0=A0=A0"ticket") that gives the bearer or holder the r= ight to access a
=A0=A0=A0=A0=A0=A0system resource. Possession of the token is accepted by a= system
=A0=A0=A0=A0=A0=A0as proof that the holder has been authorized to access th= e
=A0=A0=A0=A0=A0=A0resource named or indicated by the token. (See: access co= ntrol
=A0=A0=A0=A0=A0=A0list, credential, digital certificate.)

=A0=A0=A0=A0=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org <http://OAuth@ietf.org>
https://www.ietf.or= g/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <http://OAuth@ietf.org>
https://www.ietf.or= g/mailman/listinfo/oauth

OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 13:54:26 -0000 --_000_C8646126372DDeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You need to verify that when you use an authorization code, not when you us= e an assertion. EHL On 7/15/10 3:54 AM, "Elena Lozano" wrote: Hi everyone, As we adapt the RedIRIS PHP OAuth2 library[1] to the last version of the dr= aft we have found some issues regarding the client secret and client id. The thing is that we don't understand the security given with the client_id= and client_secret of the assertion profile. The last changes on the protocol said that: "the authorization server MUST verify that the redirection URI received matches the registered URI associated with the client identifier." This provides one way to perform the correct identification of the client b= ut doesn't work with the assertion profile. In the assertion profile, we understand that the client_id is optional and = that the assertion could have the information about the client identificati= on. This could happen when the assertion authorizes an application, but in our = use cases, the assertions doesn't have information about the client applica= tion. This is a problem because in our request to the Auth Server we cannot check= if the application is registered correctly. We can send the client_id in t= he request, but we have the same problem, because someone can 'steal' our c= lient id and impersonate the client. We think that we can solve that signing parameters in the request, adding t= he client_id signature or something like this but we're not sure that this = is referred in the protocol. What do you think it's better to solve this issue? I don't know if i'm understanding something in a wrong way, so please corre= ct me if i'm wrong. Thanks! Elena. [1] http://www.rediris.es/oauth2 --_000_C8646126372DDeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Assertion profile + client_secret and client_id secur= ity You need to verify that when you use an authorization code, not when = you use an assertion.

EHL


On 7/15/10 3:54 AM, "Elena Lozano" <elena.lozano@rediris.es> wrote:

Hi everyone,

As we adapt the RedIRIS PHP OAuth2 library[1] to the last version of the dr= aft we have found some issues regarding the client secret and client id.
The thing is that we don't understand the security given with the client_id= and client_secret of the assertion profile.

The last changes on the protocol said that:

"the authorization server MUST verify that the
   redirection URI received matches the registered URI assoc= iated with
   the client identifier."

This provides one way to perform the correct identification of the client b= ut doesn't work with the  assertion profile.

In the assertion profile, we understand that the client_id is optional and = that the assertion could have the information about the client identificati= on.
This could happen when the assertion authorizes an application, but in our = use cases, the assertions doesn't have information about the client applica= tion.
This is a problem because in our request to the Auth Server we cannot check= if the application is registered correctly. We can send the client_id in t= he request, but we have the same problem, because someone can 'steal' our c= lient id and impersonate the client.

We think that we can solve that signing parameters in the request, adding t= he client_id signature or something like this but we're not sure that this = is referred in the protocol.

What do you think it's better to solve this issue?

I don't know if i'm understanding something in a wrong way, so please corre= ct me if i'm wrong.

Thanks!

Elena.

[1] http://www.rediris.es/oauth2

--_000_C8646126372DDeranhueniversecom_-- From csoa@digitalvitamin.de Thu Jul 15 06:53:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6993A6919 for ; Thu, 15 Jul 2010 06:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 vEv509Rtt346 for ; Thu, 15 Jul 2010 06:53:41 -0700 (PDT) Received: from jordan.mc0.hosteurope.de (jordan.mc0.hosteurope.de [80.237.138.9]) by core3.amsl.com (Postfix) with ESMTP id 989A83A6909 for ; Thu, 15 Jul 2010 06:53:41 -0700 (PDT) Received: from server02.webmailer.hosteurope.de ([10.9.0.181]); by mailout.hosteurope.de (jordan.mc0.hosteurope.de) running EXperimental Internet Mailer with esmtps (TLSv1:AES256-SHA:256) id 1OZOsk-0006Nf-4d for oauth@ietf.org; Thu, 15 Jul 2010 15:53:46 +0200 Received: from nobody by server02.webmailer.hosteurope.de with local (Exim 4.69) (envelope-from ) id 1OZOsk-00079C-36 for oauth@ietf.org; Thu, 15 Jul 2010 15:53:46 +0200 To: MIME-Version: 1.0 Date: Thu, 15 Jul 2010 15:53:46 +0200 From: =?UTF-8?Q?Christian_St=C3=BCbner?= Message-ID: X-Sender: csoa@digitalvitamin.de User-Agent: Host Europe Webmailer/2.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-HE-Access: Yes X-bounce-key: webpack.hosteurope.de; csoa@digitalvitamin.de; 1279202026; 2ee8d3e0; Subject: [OAUTH-WG] OAuth2 Spec Feedback for v2-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: Thu, 15 Jul 2010 13:59:48 -0000 Hi @all! Here is my feedback to the current version (-10) of the draft. So far it looks really promising to me. Just a view thoughts/ideas/questions: 1.4: Is it necessary for an authorization server to support all client profiles in order to be standard complaint? 1.4.1. Wording: Profile "Web Server" sounds kind of misleading to me. What do you think of "Web Application" as a name for this profile? 4.2. refresh_token: With respect to 4.1.3. the authorization server SHOULD NOT issue a refresh token when the access grant type is set "assertion" (and not only "none"). 5.1.1. In my opinion the access token in this example is (unrealistic) short. Can you think of anyone using tokens this short? 5.2.1. I suppose "The resource server includes ..." not "The authorization server includes ..." is meant in the first sentence here. What I'm still missing in the draft is a way of distinguishing different protected resources when authorizing access. All I can see is a 1:1 relation between AS and PR. Nit-pick: o 1.4.4. para. 2, second sentence: "an assertion". o I would prefer one notation; either "access token" or "access-token", not both in the whole document. Keep up the good work. Regards, Christian From bcampbell@pingidentity.com Thu Jul 15 07:23: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 86DAA3A691A for ; Thu, 15 Jul 2010 07:23:14 -0700 (PDT) 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 I0Tflzh+k+B8 for ; Thu, 15 Jul 2010 07:23:12 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by core3.amsl.com (Postfix) with SMTP id 2D7B93A68F5 for ; Thu, 15 Jul 2010 07:23:12 -0700 (PDT) Received: from source ([209.85.161.53]) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTD8Z2VxGGjnuuzAUEw4NhpkrO60qhAEq@postini.com; Thu, 15 Jul 2010 07:23:23 PDT Received: by mail-fx0-f53.google.com with SMTP id 19so565704fxm.40 for ; Thu, 15 Jul 2010 07:23:21 -0700 (PDT) Received: by 10.223.121.147 with SMTP id h19mr666974far.76.1279203800158; Thu, 15 Jul 2010 07:23:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.105.135 with HTTP; Thu, 15 Jul 2010 07:22:50 -0700 (PDT) From: Brian Campbell Date: Thu, 15 Jul 2010 08:22:50 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] authz code randomness (was: single use authorization codes) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 14:23:14 -0000 I agree it's important but it belong in security considerations or perhaps somewhere in the definition of the Authorization Code itself? Either way here's some text that could be used as a starting point. I borrowed heavily from concepts and language in SAML regarding artifacts and IDs which bear many similarities (artifacts especially) to authorization codes. The Authorization Code value MUST be constructed from a cryptographically strong random or pseudo-random number sequence [RFC1750] generated by the Authorization Server. The probability of any two Authorization Code values being identical MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160). Also perhaps there should be a suggestion or requirement on the maximum size of the code as well? -Brian On Thu, Jul 15, 2010 at 1:23 AM, Igor Faynberg wrote: > An important point, which I think should be captured in the security > consideration section. > > Igor > > Torsten Lodderstedt wrote: >> >> what about guessing/brute force attacks on the code? Supposed an >> authorization server issuing tokens for a client w/o secret. Then the number >> of attempts needed to obtain a token issued to that client only depends on >> the length and randomness of the code. Should the spec state something about >> that? >> >> regards, >> Torsten. From csoa@digitalvitamin.de Thu Jul 15 07:27:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2013A6958 for ; Thu, 15 Jul 2010 07:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.312 X-Spam-Level: X-Spam-Status: No, score=-5.312 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 oYTXbH0b6BXR for ; Thu, 15 Jul 2010 07:27:49 -0700 (PDT) Received: from jordan.mc0.hosteurope.de (jordan.mc0.hosteurope.de [80.237.138.9]) by core3.amsl.com (Postfix) with ESMTP id D3E593A6A44 for ; Thu, 15 Jul 2010 07:27:45 -0700 (PDT) Received: from server02.webmailer.hosteurope.de ([10.9.0.181]); by mailout.hosteurope.de (jordan.mc0.hosteurope.de) running EXperimental Internet Mailer with esmtps (TLSv1:AES256-SHA:256) id 1OZPPj-00009X-3n for OAuth@ietf.org; Thu, 15 Jul 2010 16:27:51 +0200 Received: from nobody by server02.webmailer.hosteurope.de with local (Exim 4.69) (envelope-from ) id 1OZPPj-0007ww-2Q for OAuth@ietf.org; Thu, 15 Jul 2010 16:27:51 +0200 To: OAuth-WG MIME-Version: 1.0 Date: Thu, 15 Jul 2010 16:27:51 +0200 From: =?UTF-8?Q?Christian_St=C3=BCbner?= Message-ID: <8c60f06bb60829df8380bb91a353b40f-EhVcWl5FQQVCCQEbN11YFl1ccR9UVl1BW0gqA1ZfR0JcVkYJXlxoA1BVMl5dRkwAX15ZR1k=-webmailer2@server02.webmailer.hosteurope.de> X-Sender: csoa@digitalvitamin.de User-Agent: Host Europe Webmailer/2.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-HE-Access: Yes X-bounce-key: webpack.hosteurope.de; csoa@digitalvitamin.de; 1279204071; 05142c62; Subject: Re: [OAUTH-WG] I-D: multiple access tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 14:27:50 -0000 Torsten, I came across your I-D when looking for a way to distinguish between different protected resources. Just some remarks and questions: o In 3.1. I suppose your example request is missing the service_id, right? o 3.4. Replace server_id by service_id and you comply with the rest of the document. After all, your approach seems feasible but overly complicated to me. I wouldn't want different 'modes' in the protocol and think we should go the whole way by only offering the 'multiple tokens mode'. In single service environments one could simply define one single service but still use mechanisms capable of supporting multiple service. Don't you think? However I'm much in favor of the idea to support multiple PRs. If the others decide your I-D is the way to go - I'm fine with it. Regard, Christian From csoa@digitalvitamin.de Thu Jul 15 07:43:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97E853A6868 for ; Thu, 15 Jul 2010 07:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.524 X-Spam-Level: X-Spam-Status: No, score=-5.524 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 jmAq7MkvggNN for ; Thu, 15 Jul 2010 07:43:41 -0700 (PDT) Received: from jordan.mc0.hosteurope.de (jordan.mc0.hosteurope.de [80.237.138.9]) by core3.amsl.com (Postfix) with ESMTP id 987F63A69BE for ; Thu, 15 Jul 2010 07:43:41 -0700 (PDT) Received: from server02.webmailer.hosteurope.de ([10.9.0.181]); by mailout.hosteurope.de (jordan.mc0.hosteurope.de) running EXperimental Internet Mailer with esmtps (TLSv1:AES256-SHA:256) id 1OZPfD-0001Gx-VM; Thu, 15 Jul 2010 16:43:52 +0200 Received: from nobody by server02.webmailer.hosteurope.de with local (Exim 4.69) (envelope-from ) id 1OZPfD-0008HQ-Ts; Thu, 15 Jul 2010 16:43:51 +0200 To: =?UTF-8?Q?Christian_St=C3=BCbner?= MIME-Version: 1.0 Date: Thu, 15 Jul 2010 16:43:51 +0200 From: =?UTF-8?Q?Christian_St=C3=BCbner?= In-Reply-To: <8c60f06bb60829df8380bb91a353b40f-EhVcWl5FQQVCCQEbN11YFl1ccR9UVl1BW0gqA1ZfR0JcVkYJXlxoA1BVMl5dRkwAX15ZR1k=-webmailer2@server02.webmailer.hosteurope.de> References: <8c60f06bb60829df8380bb91a353b40f-EhVcWl5FQQVCCQEbN11YFl1ccR9UVl1BW0gqA1ZfR0JcVkYJXlxoA1BVMl5dRkwAX15ZR1k=-webmailer2@server02.webmailer.hosteurope.de> Message-ID: X-Sender: csoa@digitalvitamin.de User-Agent: Host Europe Webmailer/2.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-HE-Access: Yes X-bounce-key: webpack.hosteurope.de; csoa@digitalvitamin.de; 1279205032; f7c3b421; Cc: OAuth-WG Subject: Re: [OAUTH-WG] I-D: multiple access tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 14:43:42 -0000 My post was a reply to http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html. (Something obviously went wrong with the Thread Index.) Regards, Christian > Torsten, > > I came across your I-D when looking for a way to distinguish between > different protected resources. > > Just some remarks and questions: > o In 3.1. I suppose your example request is missing the service_id, right? > o 3.4. Replace server_id by service_id and you comply with the rest of the > document. > > After all, your approach seems feasible but overly complicated to me. I > wouldn't want different 'modes' in the protocol and think we should go the > whole way by only offering the 'multiple tokens mode'. In single service > environments one could simply define one single service but still use > mechanisms capable of supporting multiple service. Don't you think? > > However I'm much in favor of the idea to support multiple PRs. If the > others decide your I-D is the way to go - I'm fine with it. > > Regard, > Christian > From jricher@mitre.org Thu Jul 15 07:59: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 996AA3A688A for ; Thu, 15 Jul 2010 07:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 SxYauC2tGYYG for ; Thu, 15 Jul 2010 07:59:20 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id B2F5A3A682A for ; Thu, 15 Jul 2010 07:59:20 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6FExUWf004294 for ; Thu, 15 Jul 2010 10:59:31 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6FExUu3004289; Thu, 15 Jul 2010 10:59:30 -0400 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, 15 Jul 2010 10:59:30 -0400 From: Justin Richer To: Brian Eaton In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Thu, 15 Jul 2010 10:59:29 -0400 Message-ID: <1279205969.18579.55.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 14:59:21 -0000 +1 on OAuth2 header, and I also want to see oauth2_token in URI and form parameter methods. 1.0 clients will talk to systems that support both oauth2 and oauth1 simultaneously. Most likely on the same PR endpoints as well. Since the protocols are not backwards compatible, they should be able to coexist. -- Justin On Thu, 2010-07-15 at 01:38 -0400, Brian Eaton wrote: > Draft 10 switched from "Token" scheme in the authorization header to > "OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great. > "Token" is ugly as sin, but is better than "OAuth". > > Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30 > > The problem with reusing "OAuth" is that there are existing > implementations in the wild that have special behavior implemented for > OAuth authorization headers. Since OAuth2 headers don't have the same > semantics, we're going to break those implementations. We shouldn't > reuse "OAuth" for the same reasons we shouldn't reuse "Negotiate", > "NTLM", "Digest", or "Basic. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From romeda@gmail.com Thu Jul 15 08:13: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 67B753A6B35 for ; Thu, 15 Jul 2010 08:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5BTfMYRb0Bm for ; Thu, 15 Jul 2010 08:13:57 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 79AAA3A6AC6 for ; Thu, 15 Jul 2010 08:13:57 -0700 (PDT) Received: by pvd12 with SMTP id 12so430709pvd.31 for ; Thu, 15 Jul 2010 08:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=QCAUobId90gixkyEgmTqwDxFYfWT7iNgWLKxSb7342c=; b=Zwv5dXvMrTE9B32RPSPiQKRI7zUXKHYngFPGSscnHZnGysiK9c74oa87VW6EiOnWEg pollWFl6puEavWyuIHja3zlQlzpnXNPxaRII1Y7C4t9NjRpNs1vQhKEP7fKJdxBOHDKE 61O2eGccYaq7CT9/Vu/fh2yiKVwA3tYlSm+n4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=PgieteeinkfbDIgJ19MbCXUeoVWK2gfQYMOYYfDFFbk06ou/lOzKoFlYk5cYIcIwea ZGghOJv/H7IzwpTfuOtOUK+jRXHNQj7xgylEFZCycf5K9qDPXTDBnaGgztgfkon93qms T8Yx/ZQavFR7d/ltzaAXrpkXgWAhS/cicX1Po= Received: by 10.142.233.21 with SMTP id f21mr24088356wfh.20.1279206844508; Thu, 15 Jul 2010 08:14:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.8.6 with HTTP; Thu, 15 Jul 2010 08:13:40 -0700 (PDT) In-Reply-To: <1279205969.18579.55.camel@localhost.localdomain> References: <1279205969.18579.55.camel@localhost.localdomain> From: Blaine Cook Date: Thu, 15 Jul 2010 16:13:40 +0100 Message-ID: To: Justin Richer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 15:13:59 -0000 On 15 July 2010 15:59, Justin Richer wrote: > +1 on OAuth2 header, and I also want to see oauth2_token in URI and form > parameter methods. > > 1.0 clients will talk to systems that support both oauth2 and oauth1 > simultaneously. Most likely on the same PR endpoints as well. Since the > protocols are not backwards compatible, they should be able to coexist. I tend to agree with Eran here =E2=80=93 1.0 clients talking to systems tha= t support both OAuth 2 and OAuth 1 will notice no difference. The server will have to switch protocol handling, but can do so on the presence of OAuth 1 or OAuth 2-specific parameters. Clients using OAuth 1.0 shouldn't have to do anything, and shouldn't notice any change. This absolutely makes things a tiny bit more complicated for service providers that have already deployed OAuth 1 services and wish to move to OAuth 2, but frankly if the provider can't figure it out, they have larger problems (unless someone can provide a really compelling reason why switching in this way is actually really hard, I just can't buy it). OAuth is dead, long live OAuth. Right? I mean, you don't move the White House to another address every time you get a new president... b. From wmills@yahoo-inc.com Thu Jul 15 09:22: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 5B4863A6A47 for ; Thu, 15 Jul 2010 09:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.186 X-Spam-Level: X-Spam-Status: No, score=-17.186 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHgk7031U4ig for ; Thu, 15 Jul 2010 09:22:52 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 401F03A6A28 for ; Thu, 15 Jul 2010 09:22:45 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6FGMclT066390; Thu, 15 Jul 2010 09:22:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=LARTYZfRwp+bC4LMj6bu+3876SvuiyDF6JCAf9ydCzg9tS3BEydl3z9sDOKO2QSI Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 09:22:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Jul 2010 09:22:36 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6CC4@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] OAuth vs OAuth2 in Authorization header Thread-Index: AcskMI9vErNMmMARR4u6cwUpj1xo/AACTBXg References: <1279205969.18579.55.camel@localhost.localdomain> From: "William Mills" To: "Blaine Cook" , "Justin Richer" X-OriginalArrivalTime: 15 Jul 2010 16:22:38.0073 (UTC) FILETIME=[F0BB3E90:01CB2439] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 16:22:53 -0000 Well, no. We're rolling out new Oauth 1.0a stuf even now, because 2.0 isn't ready and Oauth 1.0a is better than many alternatives. >=20 > OAuth is dead, long live OAuth. Right? I mean, you don't move=20 > the White House to another address every time you get a new=20 > president... >=20 > b. From torsten@lodderstedt.net Thu Jul 15 10:03:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0303A6A35 for ; Thu, 15 Jul 2010 10:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8q5-XFncSb1 for ; Thu, 15 Jul 2010 10:03:34 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by core3.amsl.com (Postfix) with ESMTP id 28D983A6970 for ; Thu, 15 Jul 2010 10:03:33 -0700 (PDT) Received: from p4ffd0e52.dip.t-dialin.net ([79.253.14.82] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OZRqY-0002SB-HP; Thu, 15 Jul 2010 19:03:42 +0200 Message-ID: <4C3F3F6A.5000409@lodderstedt.net> Date: Thu, 15 Jul 2010 19:03:38 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060408020505010607000500" X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 17:03:40 -0000 This is a multi-part message in MIME format. --------------060408020505010607000500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As I have written in my reply to Marius's posting. I'm fine with including server ids in scopes. But this requires a definition of the scope's syntax and semantics in the spec. Otherwise, scope interpretation (and server identification) will be deployment specific. In your example, ':' is used as delimiter between server id and (I guess) resource id. I could also imagine to use another syntax, like ::. regards, Torsten. Am 15.07.2010 15:30, schrieb Eran Hammer-Lahav: > No. It is. > > Let me ask you this: why can't you use 'photos:server1' and > 'photos:server2' as scopes? > > EHL > > > On 7/14/10 10:49 PM, "Torsten Lodderstedt" > wrote: > > Did I get you right? Your answer is: Oauth is not suited for > deployments with different resource servers which rely in a single > authz server? > > I don't know why you categorize this as "complex". Is it so > unusual to have let's say mail, webstorage, telephony, and payment > services? > > At Deutsche Telekom, we operate such a deployment (with much more > different resource servers) and I had hoped to move our token > service towards OAuth v2. > > So would you recommend me zo stick to our proprietary protocol? > > regards, > Torsten. > > > > Am 15.07.2010 um 00:39 schrieb Eran Hammer-Lahav > : > > > If your deployment is that complicated, even my discovery > proposal is not going to help you... > > > > EHL > > > > > > > > On Jul 14, 2010, at 18:37, "Marius Scurtescu" > wrote: > > > >> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt > >> wrote: > >>> I have a question concerning the OAuth philosophy: How many > resource servers > >>> may be managed by a single OAuth authorization server? (a) A > single resource > >>> server or (b) several of them exposing different resource types? > >>> > >>> If the answer is (b) then how is a particular resource server > identified in > >>> the protocol? Clients have Ids, end-users as well (at least in > a future > >>> protocol extension), but what about resource server Ids? > >>> > >>> I think resource servers must be identifiable in multi-server > deployments > >>> for several reasons: > >>> - Interpretation of the scope parameter should be resource > server specific - > >>> "read" may have different meanings in mail and address book > >>> - An authorization server probably wants to apply > server-specific security > >>> policy, e.g. different access token durations > >>> - It will be possible to create special tokens per server > >>> > >>> I think we should introduce a resource server id in the authz > and access > >>> token request. > >>> > >>> Any thoughts? > >> > >> I think the scope fills this role. Scopes implemented as URIs, for > >> example, allow the authz server to map them to resource servers. > >> > >> Marius > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > --------------060408020505010607000500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As I have written in my reply to Marius's posting. I'm fine with including server ids in scopes. But this requires a definition of the scope's syntax and semantics in the spec. Otherwise, scope interpretation (and server identification) will be deployment specific.

In your example, ':' is used as delimiter between server id and (I guess) resource id. I could also imagine to use another syntax, like <resource server>:<resource>:<permissions>.

regards,
Torsten.


Am 15.07.2010 15:30, schrieb Eran Hammer-Lahav:
Re: [OAUTH-WG] resource server id needed? No. It is.

Let me ask you this: why can’t you use ‘photos:server1’ and ‘photos:server2’ as scopes?

EHL


On 7/14/10 10:49 PM, "Torsten Lodderstedt" <torsten@lodderstedt.net> wrote:
Did I get you right? Your answer is: Oauth is not suited for deployments with different resource servers which rely in a single authz server?

I don't know why you categorize this as  "complex". Is it so unusual to have let's say mail, webstorage, telephony, and payment services?

At Deutsche Telekom, we operate such a deployment (with much more different resource servers) and I had hoped to move our token service towards OAuth v2.

So would you recommend me zo stick to our proprietary protocol?

regards,
Torsten.



Am 15.07.2010 um 00:39 schrieb Eran Hammer-Lahav <eran@hueniverse.com>:

> If your deployment is that complicated, even my discovery proposal is not going to help you...
>
> EHL
>
>
>
> On Jul 14, 2010, at 18:37, "Marius Scurtescu" <mscurtescu@google.com> wrote:
>
>> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
>> <torsten@lodderstedt.net> wrote:
>>> I have a question concerning the OAuth philosophy: How many resource servers
>>> may be managed by a single OAuth authorization server? (a) A single resource
>>> server or (b) several of them exposing different resource types?
>>>
>>> If the answer is (b) then how is a particular resource server identified in
>>> the protocol? Clients have Ids, end-users as well (at least in a future
>>> protocol extension), but what about resource server Ids?
>>>
>>> I think resource servers must be identifiable in multi-server deployments
>>> for several reasons:
>>> - Interpretation of the scope parameter should be resource server specific -
>>> "read" may have different meanings in mail and address book
>>> - An authorization server probably wants to apply server-specific security
>>> policy, e.g. different access token durations
>>> - It will be possible to create special tokens per server
>>>
>>> I think we should introduce a resource server id in the authz and access
>>> token request.
>>>
>>> Any thoughts?
>>
>> I think the scope fills this role. Scopes implemented as URIs, for
>> example, allow the authz server to map them to resource servers.
>>
>> Marius
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

--------------060408020505010607000500-- From torsten@lodderstedt.net Thu Jul 15 10:06: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 B8A4C3A6A2A for ; Thu, 15 Jul 2010 10:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.161, 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 C13zTh-iQN5P for ; Thu, 15 Jul 2010 10:06:51 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by core3.amsl.com (Postfix) with ESMTP id 93D843A6970 for ; Thu, 15 Jul 2010 10:06:51 -0700 (PDT) Received: from p4ffd0e52.dip.t-dialin.net ([79.253.14.82] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OZRtk-0007HX-6N; Thu, 15 Jul 2010 19:07:00 +0200 Message-ID: <4C3F4033.3030309@lodderstedt.net> Date: Thu, 15 Jul 2010 19:06:59 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brian Campbell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: oauth Subject: Re: [OAUTH-WG] authz code randomness (was: single use authorization codes) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 17:06:54 -0000 sounds really good. +1 for adding this to the authorization code's specification. Am 15.07.2010 16:22, schrieb Brian Campbell: > I agree it's important but it belong in security considerations or > perhaps somewhere in the definition of the Authorization Code itself? > > Either way here's some text that could be used as a starting point. I > borrowed heavily from concepts and language in SAML regarding > artifacts and IDs which bear many similarities (artifacts especially) > to authorization codes. > > The Authorization Code value MUST be constructed from > a cryptographically strong random or pseudo-random number > sequence [RFC1750] generated by the Authorization Server. > The probability of any two Authorization Code values being > identical MUST be less than or equal to 2^(-128) and SHOULD > be less than or equal to 2^(-160). > > Also perhaps there should be a suggestion or requirement on the > maximum size of the code as well? > > -Brian > > On Thu, Jul 15, 2010 at 1:23 AM, Igor Faynberg > wrote: > >> An important point, which I think should be captured in the security >> consideration section. >> >> Igor >> >> Torsten Lodderstedt wrote: >> >>> what about guessing/brute force attacks on the code? Supposed an >>> authorization server issuing tokens for a client w/o secret. Then the number >>> of attempts needed to obtain a token issued to that client only depends on >>> the length and randomness of the code. Should the spec state something about >>> that? >>> >>> regards, >>> Torsten. >>> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From beaton@google.com Thu Jul 15 10:12: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 02C0B3A6A2A for ; Thu, 15 Jul 2010 10:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.178, 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 cyTrHxpXUdUj for ; Thu, 15 Jul 2010 10:12:54 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 134A13A69C6 for ; Thu, 15 Jul 2010 10:12:53 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o6FHD4aJ003668 for ; Thu, 15 Jul 2010 10:13:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279213984; bh=IZBjR8/T7JFhjxBEjtEnuSMX+Oo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=g645D6apONpDHdwTCDRuOFzB+LaTs1r5ODhQ93CWd3mJJqUNmRLuvDp4ou/wUQGq4 9T4bjupC3ZtOTeDIqwDzw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=JK07QlUuUosNzK/oUMlwwPo9/I6X/YI31XgynRx2NukEe8tnztExpJ8vFtKhPp3JV LWycKY7Q3P1eGLIVWbkHA== Received: from pwi5 (pwi5.prod.google.com [10.241.219.5]) by kpbe12.cbf.corp.google.com with ESMTP id o6FHD2nn003556 for ; Thu, 15 Jul 2010 10:13:03 -0700 Received: by pwi5 with SMTP id 5so359428pwi.19 for ; Thu, 15 Jul 2010 10:13:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.213.14 with SMTP id l14mr25220768wfg.90.1279213976883; Thu, 15 Jul 2010 10:12:56 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Thu, 15 Jul 2010 10:12:56 -0700 (PDT) In-Reply-To: <1279205969.18579.55.camel@localhost.localdomain> References: <1279205969.18579.55.camel@localhost.localdomain> Date: Thu, 15 Jul 2010 10:12:56 -0700 Message-ID: From: Brian Eaton To: Justin Richer Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 17:12:56 -0000 On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer wrote: > +1 on OAuth2 header, and I also want to see oauth2_token in URI and form > parameter methods. Good point about the query parameter names needing to be unambiguous. From ivan.pulleyn@gmail.com Thu Jul 15 10:33: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 71E2F3A6B65 for ; Thu, 15 Jul 2010 10:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBf92pxajole for ; Thu, 15 Jul 2010 10:33:45 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 804C03A6B36 for ; Thu, 15 Jul 2010 10:33:40 -0700 (PDT) Received: by ywa8 with SMTP id 8so142094ywa.31 for ; Thu, 15 Jul 2010 10:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=cJotTSlpjLQ6lBnqQCQC28NH3HA+lCTBtMD3iJQecik=; b=OKsxwsMEZuRo3T+fAtGG1gJTuEJKPW26Jknn61GonLFJuRYJznoMStTDX9ytyjq8m7 7r+B8HmN/wgzO4gXJlpdDJqGnKF/kGKWLQmXWqLJscm/8VCkUZgGcJbh30dBlaHiiVMC NlYXNKP8mmUvJjT5tCCi9jnccQn2w5pMXRc3E= 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=osmyTYZJ1tmPsctrIVCRq9BzV0ET0+FjxRY5tMqN3wWQksvea1FC7rCrZCn/XEWK3u Y/mQkX+3MHfkuJcpP4/X0dfStNkg3bKRgqU84t+CNTP0Qi8M6iseMZ6+IUFqY3mPNTc7 vQnY6EIrT1FPTGSQz0YbYXIDnZ0QDXRQTimKM= MIME-Version: 1.0 Received: by 10.150.146.9 with SMTP id t9mr235049ybd.76.1279215228440; Thu, 15 Jul 2010 10:33:48 -0700 (PDT) Received: by 10.150.95.19 with HTTP; Thu, 15 Jul 2010 10:33:48 -0700 (PDT) In-Reply-To: <4C3F3F6A.5000409@lodderstedt.net> References: <4C3F3F6A.5000409@lodderstedt.net> Date: Thu, 15 Jul 2010 10:33:48 -0700 Message-ID: From: Ivan Pulleyn To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=000e0cd4854e4851b7048b70817d Cc: OAuth WG Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 17:33:57 -0000 --000e0cd4854e4851b7048b70817d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > As I have written in my reply to Marius's posting. I'm fine with including > server ids in scopes. But this requires a definition of the scope's syntax > and semantics in the spec. Otherwise, scope interpretation (and server > identification) will be deployment specific. > > Yes, I believe the definition of scope implies this. Ivan... --000e0cd4854e4851b7048b70817d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jul 15, 2010 at 10:03 AM, Torste= n Lodderstedt <torsten@lodderstedt.net> wrote:
=20
As I have written in my reply to Marius's posting. I'm fine with including server ids in scopes. But this requires a definition of the scope's syntax and semantics in the spec. Otherwise, scope interpretation (and server identification) will be deployment specific.


Yes, I believe the definition of scope impli= es this.

Ivan...

--000e0cd4854e4851b7048b70817d-- From lr@lukasrosenstock.net Thu Jul 15 10:36:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28AC43A67BD for ; Thu, 15 Jul 2010 10:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q2OLY2sszFa for ; Thu, 15 Jul 2010 10:36:19 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 235C03A6A95 for ; Thu, 15 Jul 2010 10:36:19 -0700 (PDT) Received: by qwe5 with SMTP id 5so326686qwe.31 for ; Thu, 15 Jul 2010 10:36:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.45.213 with SMTP id g21mr3420394qaf.382.1279215386102; Thu, 15 Jul 2010 10:36:26 -0700 (PDT) Received: by 10.229.100.135 with HTTP; Thu, 15 Jul 2010 10:36:25 -0700 (PDT) In-Reply-To: <1279205969.18579.55.camel@localhost.localdomain> References: <1279205969.18579.55.camel@localhost.localdomain> Date: Thu, 15 Jul 2010 19:36:25 +0200 Message-ID: From: Lukas Rosenstock To: Justin Richer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 17:36:20 -0000 +1 for both 2010/7/15 Justin Richer : > +1 on OAuth2 header, and I also want to see oauth2_token in URI and form > parameter methods. > > 1.0 clients will talk to systems that support both oauth2 and oauth1 > simultaneously. Most likely on the same PR endpoints as well. Since the > protocols are not backwards compatible, they should be able to coexist. > > =A0-- Justin > From recordond@gmail.com Thu Jul 15 10:37: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 9BC153A6A55 for ; Thu, 15 Jul 2010 10:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.284, 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 WY-EqtuCAwQX for ; Thu, 15 Jul 2010 10:37:45 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id AE76F3A69B4 for ; Thu, 15 Jul 2010 10:37:45 -0700 (PDT) Received: by iwn38 with SMTP id 38so1276128iwn.31 for ; Thu, 15 Jul 2010 10:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=7DFeIJhyPvfy4CU7Y5X3pFxty5429OL+JPI0tGErqFU=; b=lYb2cFm7oIfPilp5yPm+5jnFp010iwwVwNkpVEPJg9UDvK9Sh76W1rQEk/5yGQVaeb LxAxtZ2m5dnDZwcfWJh4Tar/zqz9ObqmYlEJaoVqH6zWNsLdIxkkPVg31P7bFMyPCf8C sGyF8ChWBmjoSfuPJFSrtGEiSwP6BivK7MaOk= 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=MTyEL80hhPKSE7Jo/Ybn4u6PVDEAdDq4qcrSUMw30S8ZJiYAVGtgIsYf4ErU2Xd3xg 6C+tutauHHY3QEhlWzTDqKWRMnmyxatye5MKnYbEI8tUvutt6Dj5ldP27DQz8rMuaKcZ q8sDRcMh8D58jV3wWZXr8fQDQdPVOHhyauMHE= MIME-Version: 1.0 Received: by 10.231.150.16 with SMTP id w16mr19987108ibv.42.1279215476227; Thu, 15 Jul 2010 10:37:56 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Thu, 15 Jul 2010 10:37:56 -0700 (PDT) In-Reply-To: References: <1279205969.18579.55.camel@localhost.localdomain> Date: Thu, 15 Jul 2010 10:37:56 -0700 Message-ID: From: David Recordon To: Brian Eaton Content-Type: multipart/alternative; boundary=0016e68dda0d0d3f1d048b7090a1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 17:37:46 -0000 --0016e68dda0d0d3f1d048b7090a1 Content-Type: text/plain; charset=ISO-8859-1 I thought this topic had been beaten to death before. An OAuth 1.0 protected resource request includes a variety of oauth_ parameters whereas OAuth 2.0 just has oauth_token. --David On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton wrote: > On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer wrote: > > +1 on OAuth2 header, and I also want to see oauth2_token in URI and form > > parameter methods. > > Good point about the query parameter names needing to be unambiguous. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e68dda0d0d3f1d048b7090a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I thought this topic had been beaten to death before. An OAuth 1.0 protecte= d resource request includes a variety of oauth_ parameters whereas OAuth 2.= 0 just has oauth_token.

--David


On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton <beaton@google.com<= /a>> wrote:
On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer <jricher@mitre.org> wrote:
> +1 on OAuth2 header, and I also want to see oauth2_token in URI and fo= rm
> parameter methods.

Good point about the query parameter names needing to be unambiguous.=
_________________________________________= ______
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016e68dda0d0d3f1d048b7090a1-- From beaton@google.com Thu Jul 15 10:39: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 F3C8C3A6B32 for ; Thu, 15 Jul 2010 10:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.893 X-Spam-Level: X-Spam-Status: No, score=-101.893 tagged_above=-999 required=5 tests=[AWL=0.084, 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 dislqlvnp9ty for ; Thu, 15 Jul 2010 10:39:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id DD75C3A69B4 for ; Thu, 15 Jul 2010 10:39:02 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o6FHdBpi023347 for ; Thu, 15 Jul 2010 10:39:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279215552; bh=DZP8K3wldsbDDgqkgFjljh4/IwE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=h6FniFj5G2YvgT17vrN7bVLL+43T46AVoGgtOKG608ZjD+i63Fw281mqd1BQqnh24 cTASrcFDSev1zS5RqTsww== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=B7iRvsITJdW/Bx4DXdQQye4jcIALKnJxeCEd/VMPGWoEejJpPRcPl1DSgPp8EjIdM G1cXgVD8PqN1QP3bW4pMw== Received: from pxi20 (pxi20.prod.google.com [10.243.27.20]) by kpbe12.cbf.corp.google.com with ESMTP id o6FHdAZZ031734 for ; Thu, 15 Jul 2010 10:39:10 -0700 Received: by pxi20 with SMTP id 20so521580pxi.3 for ; Thu, 15 Jul 2010 10:39:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.232.13 with SMTP id e13mr23683614wfh.191.1279215549526; Thu, 15 Jul 2010 10:39:09 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Thu, 15 Jul 2010 10:39:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Jul 2010 10:39:09 -0700 Message-ID: From: Brian Eaton To: Brian Campbell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth Subject: Re: [OAUTH-WG] authz code randomness (was: single use authorization codes) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 17:39:07 -0000 On Thu, Jul 15, 2010 at 7:22 AM, Brian Campbell wrote: > =A0 =A0The Authorization Code value MUST be constructed from > =A0 =A0a cryptographically strong random or pseudo-random number > =A0 =A0sequence [RFC1750] generated by the Authorization Server. > =A0 =A0The probability of any two Authorization Code values being > =A0 =A0identical MUST be less than or equal to 2^(-128) and SHOULD > =A0 =A0be less than or equal to 2^(-160). Does that text preclude using stateless authorization code implementations? Authorization codes are issued frequently and change rapidly, so I am very interested in supporting stateless implementations. From beaton@google.com Thu Jul 15 10:40:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A643A69B6 for ; Thu, 15 Jul 2010 10:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.803 X-Spam-Level: X-Spam-Status: No, score=-105.803 tagged_above=-999 required=5 tests=[AWL=0.174, 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 xomPMK5vlNOD for ; Thu, 15 Jul 2010 10:40:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DA6B03A68AD for ; Thu, 15 Jul 2010 10:40:15 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o6FHeQGl011133 for ; Thu, 15 Jul 2010 10:40:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279215626; bh=TB5GAPNr6nq0CBV4ZybNsZHAZ3Q=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=BxXDmI7x004CeX/m93MM/bjbIS47kEIvTEyf+swIyQbbIuFlPceUDREImM4gBemNr gci0TxWKo1I5f7UIGa6xw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=UGGjICgpfmu8Ryjcbg71YDa5lpokgGXBDbqc688CX//C9wfdDrZSOz1GzLG6TDFNE SXBJeWo8hpeIDH1Zd4kXw== Received: from pzk6 (pzk6.prod.google.com [10.243.19.134]) by kpbe20.cbf.corp.google.com with ESMTP id o6FHePKK020360 for ; Thu, 15 Jul 2010 10:40:25 -0700 Received: by pzk6 with SMTP id 6so329506pzk.3 for ; Thu, 15 Jul 2010 10:40:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.148.10 with SMTP id v10mr23947901wfd.103.1279215617554; Thu, 15 Jul 2010 10:40:17 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Thu, 15 Jul 2010 10:40:17 -0700 (PDT) In-Reply-To: References: <1279205969.18579.55.camel@localhost.localdomain> Date: Thu, 15 Jul 2010 10:40:17 -0700 Message-ID: From: Brian Eaton To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 17:40:20 -0000 On Thu, Jul 15, 2010 at 10:37 AM, David Recordon wrote: > I thought this topic had been beaten to death before. Can you give me a pointer to the earlier threads? From wmills@yahoo-inc.com Thu Jul 15 10:42:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099693A6A56 for ; Thu, 15 Jul 2010 10:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.89 X-Spam-Level: X-Spam-Status: No, score=-16.89 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZH6OrBK7a-f2 for ; Thu, 15 Jul 2010 10:42:19 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id C8F873A69AA for ; Thu, 15 Jul 2010 10:42:18 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6FHfotw093208; Thu, 15 Jul 2010 10:41:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=na3JYCdeSyTeAeTVA958ZCXl85ZidB/Ob2x9YVAbjfnYURppraX11IJJbD2o7hu4 Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 10:41:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2445.0113EB4C" Date: Thu, 15 Jul 2010 10:41:49 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6CD3@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] OAuth vs OAuth2 in Authorization header Thread-Index: AcskRIld3e5LkrNDRTGz4U/ljUagRAAAFP7Q References: <1279205969.18579.55.camel@localhost.localdomain> From: "William Mills" To: "David Recordon" , "Brian Eaton" X-OriginalArrivalTime: 15 Jul 2010 17:41:50.0305 (UTC) FILETIME=[01484D10:01CB2445] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 17:42:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2445.0113EB4C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable No, the people who don't like the sharing of the namespace between the 2 still don't like it, and the people that can;t stand teh idea of using oauth2 for anything still won't move. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of David Recordon Sent: Thursday, July 15, 2010 10:38 AM To: Brian Eaton Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth vs OAuth2 in Authorization header =09 =09 I thought this topic had been beaten to death before. An OAuth 1.0 protected resource request includes a variety of oauth_ parameters whereas OAuth 2.0 just has oauth_token.=20 --David On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton wrote: =09 On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer wrote: > +1 on OAuth2 header, and I also want to see oauth2_token in URI and form > parameter methods. =09 =09 Good point about the query parameter names needing to be unambiguous. =09 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =09 ------_=_NextPart_001_01CB2445.0113EB4C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
No, the people who don't like the sharing of the = namespace=20 between the 2 still don't like it, and the people that can;t stand teh = idea of=20 using oauth2 for anything still won't move.

From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] On Behalf Of David=20 Recordon
Sent: Thursday, July 15, 2010 10:38 = AM
To: Brian=20 Eaton
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = OAuth vs=20 OAuth2 in Authorization header

I thought this topic had been beaten to death before. An = OAuth 1.0=20 protected resource request includes a variety of oauth_ parameters = whereas=20 OAuth 2.0 just has oauth_token.

--David


On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton = <beaton@google.com> = wrote:
On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer = <jricher@mitre.org> = wrote:
> +1=20 on OAuth2 header, and I also want to see oauth2_token in URI and=20 form
> parameter methods.

Good point about the = query=20 parameter names needing to be unambiguous.
_______________________________________________
OAuth=20 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=

------_=_NextPart_001_01CB2445.0113EB4C-- From jricher@mitre.org Thu Jul 15 10:51: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 DDBC33A6B6B for ; Thu, 15 Jul 2010 10:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 ElOIPhLVtDTK for ; Thu, 15 Jul 2010 10:51:22 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 56E533A6B4C for ; Thu, 15 Jul 2010 10:51:22 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6FHpWxT005794 for ; Thu, 15 Jul 2010 13:51:32 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6FHpWo6005786; Thu, 15 Jul 2010 13:51:32 -0400 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, 15 Jul 2010 13:51:32 -0400 From: Justin Richer To: David Recordon In-Reply-To: References: <1279205969.18579.55.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Thu, 15 Jul 2010 13:51:31 -0400 Message-ID: <1279216291.18579.61.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 17:51:24 -0000 It was discussed before, but I don't remember there being any consensus in the group. What are the practical reasons for not using "oauth2" namespacing in the one place we still use namespacing? Most of what I've heard seems to sound like "I don't like it to have a 2 on it". I don't want to have to set up the OAuth 2 system to have to catch failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad OAuth 1 call should be distinguishable from the start. Also, what about when we finally get a signed-request going? I would assume that that's going to add back in things like oauth_signature, oauth_nonce, and the other parameters whose absence you should filter on. -- Justin On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote: > I thought this topic had been beaten to death before. An OAuth 1.0 > protected resource request includes a variety of oauth_ parameters > whereas OAuth 2.0 just has oauth_token. > > > --David > > > On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton > wrote: > On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer > wrote: > > +1 on OAuth2 header, and I also want to see oauth2_token in > URI and form > > parameter methods. > > > Good point about the query parameter names needing to be > unambiguous. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > From mscurtescu@google.com Thu Jul 15 11:15: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 65C643A67B1 for ; Thu, 15 Jul 2010 11:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.252 X-Spam-Level: X-Spam-Status: No, score=-105.252 tagged_above=-999 required=5 tests=[AWL=0.725, 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 pvoGO1l3vZbd for ; Thu, 15 Jul 2010 11:15:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 155753A6891 for ; Thu, 15 Jul 2010 11:15:12 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id o6FIFNak027791 for ; Thu, 15 Jul 2010 11:15:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279217723; bh=0XecPkSEDkZhMeb06FcMCu+ZQh8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=IfpE8ANnco8qEl5xeyt3zgO+flxWKyJmB66W2CENv/x2MjuKABHs1/oi7/YSYX1H3 v7WRuIOzBwN8INFLdEL7w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=oSqOHTfS9KagCa/62WmlIFs8Zd/yMEKwEfLBR36OxOqRlZiyeI+6ZQdSQnKXv1/en UijNSkYXbQTQfhU4FBlzA== Received: from gxk27 (gxk27.prod.google.com [10.202.11.27]) by wpaz1.hot.corp.google.com with ESMTP id o6FIFMcb023018 for ; Thu, 15 Jul 2010 11:15:22 -0700 Received: by gxk27 with SMTP id 27so785727gxk.22 for ; Thu, 15 Jul 2010 11:15:22 -0700 (PDT) Received: by 10.100.8.5 with SMTP id 5mr18927anh.110.1279217716428; Thu, 15 Jul 2010 11:15:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Thu, 15 Jul 2010 11:14:55 -0700 (PDT) In-Reply-To: <4C3F3F6A.5000409@lodderstedt.net> References: <4C3F3F6A.5000409@lodderstedt.net> From: Marius Scurtescu Date: Thu, 15 Jul 2010 11:14:55 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 18:15:15 -0000 On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt wrote: > As I have written in my reply to Marius's posting. I'm fine with including > server ids in scopes. But this requires a definition of the scope's syntax > and semantics in the spec. Otherwise, scope interpretation (and server > identification) will be deployment specific. Sure, it is deployment specific, but why is that an issue? In your case, the authz server and all the resource servers are managed by the same organization, right? Do clients need to be aware of the actual resource server? You can probably create a separate spec that defines scope syntax for this purpose, if really needed. Does it have to be in core? Marius From lshepard@facebook.com Thu Jul 15 11:24: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 4B9193A69F5 for ; Thu, 15 Jul 2010 11:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbPUm19MSlsn for ; Thu, 15 Jul 2010 11:24:10 -0700 (PDT) Received: from mx-out.facebook.com (outmail023.snc1.tfbnw.net [69.63.178.182]) by core3.amsl.com (Postfix) with ESMTP id 723F83A6902 for ; Thu, 15 Jul 2010 11:24:10 -0700 (PDT) Received: from [10.18.255.121] ([10.18.255.121:10743] helo=mail.thefacebook.com) by mta004.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id A0/37-15591-5525F3C4; Thu, 15 Jul 2010 11:24:21 -0700 Received: from SC-MBX06.TheFacebook.com ([169.254.5.94]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Thu, 15 Jul 2010 11:24:20 -0700 From: Luke Shepard To: Justin Richer Thread-Topic: [OAUTH-WG] OAuth vs OAuth2 in Authorization header Thread-Index: AQHLI+AFCubwzq32zUudFjbZypq1V5Kyij6AgAAlSQCAAAb8AIAAA8yAgAAJKwA= Date: Thu, 15 Jul 2010 18:24:20 +0000 Message-ID: <74AEEFD7-04B3-4B28-970E-0DB554728BED@facebook.com> References: <1279205969.18579.55.camel@localhost.localdomain> <1279216291.18579.61.camel@localhost.localdomain> In-Reply-To: <1279216291.18579.61.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <50622063-b812-4985-8964-df3482cc153b> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 18:24:11 -0000 On Jul 15, 2010, at 10:51 AM, Justin Richer wrote: > It was discussed before, but I don't remember there being any consensus > in the group. What are the practical reasons for not using "oauth2" > namespacing in the one place we still use namespacing? Most of what I've > heard seems to sound like "I don't like it to have a 2 on it".=20 I don't like it to have a 2 in it. > I don't want to have to set up the OAuth 2 system to have to catch > failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad > OAuth 1 call should be distinguishable from the start. Also, what about > when we finally get a signed-request going? I would assume that that's > going to add back in things like oauth_signature, oauth_nonce, and the > other parameters whose absence you should filter on.=20 The latest signature discussions have all focused on a single, self-contain= ed, signed parameter that includes both data and signature. I think it's un= likely that we will introduce the plethora of parameters that we had in OAu= th 1.0. > -- Justin >=20 > On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote: >> I thought this topic had been beaten to death before. An OAuth 1.0 >> protected resource request includes a variety of oauth_ parameters >> whereas OAuth 2.0 just has oauth_token. >>=20 >>=20 >> --David >>=20 >>=20 >> On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton >> wrote: >> On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer >> wrote: >>> +1 on OAuth2 header, and I also want to see oauth2_token in >> URI and form >>> parameter methods. >>=20 >>=20 >> Good point about the query parameter names needing to be >> unambiguous. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From john@jkemp.net Thu Jul 15 11:33: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 6708B3A68AF for ; Thu, 15 Jul 2010 11:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0IbSaElpcR1 for ; Thu, 15 Jul 2010 11:33:14 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 600403A6820 for ; Thu, 15 Jul 2010 11:33:14 -0700 (PDT) Received: (qmail 18876 invoked by uid 0); 15 Jul 2010 18:33:25 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy3.bluehost.com with SMTP; 15 Jul 2010 18:33:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=lKc3xRb6C+5NSJhCN018Ql4/CSu18IJ62xtKoK5p71hFc21cUVtpcqJuYzdBIDDnIGihBhYxckxT7CBAUsejiPbk4+7gjaLWABpn1Q50DK72wKfmIpURg1MVgUdaukrV; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.112]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OZTFM-00044e-Ny; Thu, 15 Jul 2010 12:33:24 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: Date: Thu, 15 Jul 2010 14:33:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02D7ABE3-5B51-43B6-B7A2-6CB9AA045AAA@jkemp.net> References: To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1081) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 18:33:18 -0000 On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote: > I would like people to raise their hand and explain how this will = break actual 1.0 deployments.=20 What happens if a 1.0 client receives a WWW-Authenticate header from a = 2.0 protected resource with the 'OAuth' mechanism specified? Might it = then attempt OAuth 1 with a 2.0 token service (and thus just fail = without being able to know what went wrong)?=20 - johnk >=20 > EHL >=20 >=20 >=20 > On Jul 15, 2010, at 1:38, Brian Eaton wrote: >=20 >> Draft 10 switched from "Token" scheme in the authorization header to >> "OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great. >> "Token" is ugly as sin, but is better than "OAuth". >>=20 >> Spec section: = http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30 >>=20 >> The problem with reusing "OAuth" is that there are existing >> implementations in the wild that have special behavior implemented = for >> OAuth authorization headers. Since OAuth2 headers don't have the = same >> semantics, we're going to break those implementations. We shouldn't >> reuse "OAuth" for the same reasons we shouldn't reuse "Negotiate", >> "NTLM", "Digest", or "Basic. >>=20 >> Cheers, >> Brian >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From recordond@gmail.com Thu Jul 15 11:35: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 E9E453A67B1 for ; Thu, 15 Jul 2010 11:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.262, 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 IVhCk3oAF4W4 for ; Thu, 15 Jul 2010 11:35:28 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 79DB93A6820 for ; Thu, 15 Jul 2010 11:35:28 -0700 (PDT) Received: by yxj4 with SMTP id 4so206961yxj.31 for ; Thu, 15 Jul 2010 11:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/veATxrKmuGwJ/MLtJbPkgKb/s8DNOYfICNBfhPbq8o=; b=GEHDFwCWyi25dgoBSAtImOc5w28Xs7KKq5LrksgVJ+ge6urNgHUUoqK02EXOADWCl4 cY2WOHgKqMa+lW+6VWvOiY1+ImbhJE0Au/92rpPokf0Xse67rigUz5cfz+aGf5o/IPAG c2K4M1bKlIM4/tmld1AdbauwM4jLROBdJzcl8= 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=EnYU2UBzYJKiQzRU/8n95umS/wD1Yvbm6bWaV6eAyTl1jVl5WcnyXiFiBLO8tTOMEV +iJecTW6yatKm+ZhFEZhpTZk2ht0y6R+OdqXBYrcEjVR1B8/WghCqAUZHF0V9CaMny3N /NzVYBezb682kWGnJ1+kc3G3oFtaJvyRgFG60= MIME-Version: 1.0 Received: by 10.101.10.39 with SMTP id n39mr60074ani.97.1279218938967; Thu, 15 Jul 2010 11:35:38 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Thu, 15 Jul 2010 11:35:38 -0700 (PDT) In-Reply-To: <02D7ABE3-5B51-43B6-B7A2-6CB9AA045AAA@jkemp.net> References: <02D7ABE3-5B51-43B6-B7A2-6CB9AA045AAA@jkemp.net> Date: Thu, 15 Jul 2010 11:35:38 -0700 Message-ID: From: David Recordon To: John Kemp Content-Type: multipart/alternative; boundary=0016e68ee1eb727774048b715e69 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 18:35:30 -0000 --0016e68ee1eb727774048b715e69 Content-Type: text/plain; charset=ISO-8859-1 Given that OAuth discovery hasn't been written yet, how would an OAuth 1.0 client know about a 2.0 protected resource in the first place? On Thu, Jul 15, 2010 at 11:33 AM, John Kemp wrote: > On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote: > > > I would like people to raise their hand and explain how this will break > actual 1.0 deployments. > > What happens if a 1.0 client receives a WWW-Authenticate header from a 2.0 > protected resource with the 'OAuth' mechanism specified? Might it then > attempt OAuth 1 with a 2.0 token service (and thus just fail without being > able to know what went wrong)? > > - johnk > > > > > EHL > > > > > > > > On Jul 15, 2010, at 1:38, Brian Eaton wrote: > > > >> Draft 10 switched from "Token" scheme in the authorization header to > >> "OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great. > >> "Token" is ugly as sin, but is better than "OAuth". > >> > >> Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30 > >> > >> The problem with reusing "OAuth" is that there are existing > >> implementations in the wild that have special behavior implemented for > >> OAuth authorization headers. Since OAuth2 headers don't have the same > >> semantics, we're going to break those implementations. We shouldn't > >> reuse "OAuth" for the same reasons we shouldn't reuse "Negotiate", > >> "NTLM", "Digest", or "Basic. > >> > >> Cheers, > >> Brian > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e68ee1eb727774048b715e69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given that OAuth discovery hasn't been written yet, how would an OAuth = 1.0 client know about a 2.0 protected resource in the first place?

=
On Thu, Jul 15, 2010 at 11:33 AM, John Kemp = <john@jkemp.net&= gt; wrote:
On Jul 15, 2010, at 9:07 = AM, Eran Hammer-Lahav wrote:

> I would like people to raise their hand and explain how this will brea= k actual 1.0 deployments.

What happens if a 1.0 client receives a WWW-Authenticate header from = a 2.0 protected resource with the 'OAuth' mechanism specified? Migh= t it then attempt OAuth 1 with a 2.0 token service (and thus just fail with= out being able to know what went wrong)?

- johnk

>
> EHL
>
>
>
> On Jul 15, 2010, at 1:38, Brian Eaton <beaton@google.com> wrote:
>
>> Draft 10 switched from "Token" scheme in the authorizati= on header to
>> "OAuth". =A0I'd rather we didn't reuse OAuth. = =A0'OAuth2' would be great.
>> "Token" is ugly as sin, but is better than "OAuth&q= uot;.
>>
>> Spec section: http://tools.ietf.org/html/draft-ietf-o= auth-v2-10#page-30
>>
>> The problem with reusing "OAuth" is that there are exist= ing
>> implementations in the wild that have special behavior implemented= for
>> OAuth authorization headers. =A0Since OAuth2 headers don't hav= e the same
>> semantics, we're going to break those implementations. =A0We s= houldn't
>> reuse "OAuth" for the same reasons we shouldn't reus= e "Negotiate",
>> "NTLM", "Digest", or "Basic.
>>
>> Cheers,
>> Brian
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

--0016e68ee1eb727774048b715e69-- From eran@hueniverse.com Thu Jul 15 11:36: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 0EEF73A6971 for ; Thu, 15 Jul 2010 11:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 AbA7vjgGmXWU for ; Thu, 15 Jul 2010 11:36:25 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 976FA3A6A74 for ; Thu, 15 Jul 2010 11:36:20 -0700 (PDT) Received: (qmail 29522 invoked from network); 15 Jul 2010 18:36:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jul 2010 18:36:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 15 Jul 2010 11:36:21 -0700 From: Eran Hammer-Lahav To: Luke Shepard Date: Thu, 15 Jul 2010 11:36:13 -0700 Thread-Topic: [OAUTH-WG] OAuth vs OAuth2 in Authorization header Thread-Index: AcskTJ7hBPsBn3XQQyWpNc2p2vpumg== Message-ID: References: <1279205969.18579.55.camel@localhost.localdomain> <1279216291.18579.61.camel@localhost.localdomain> <74AEEFD7-04B3-4B28-970E-0DB554728BED@facebook.com> In-Reply-To: <74AEEFD7-04B3-4B28-970E-0DB554728BED@facebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 18:36:28 -0000 X-List-Received-Date: Thu, 15 Jul 2010 18:36:28 -0000 Framing the argument against "having a 2 in it" as bikeshedding is missing = the point. My reason against using OAuth2 is that is will undermine all the= work put in to build an extensible framework that can evolve without needi= ng a whole new version. By putting a version number, we make it more attrac= tive to change the protocol than extend it. So far the arguments made are all theoretical. I will maintain my objection and preference to reuse the existing names un= til someone with an existing 1.0 deployment can make a compelling reason wh= y they can rely on the presence of the oauth_signature_method to differenti= ate.=20 EHL On Jul 15, 2010, at 14:24, "Luke Shepard" wrote: >=20 > On Jul 15, 2010, at 10:51 AM, Justin Richer wrote: >=20 >> It was discussed before, but I don't remember there being any consensus >> in the group. What are the practical reasons for not using "oauth2" >> namespacing in the one place we still use namespacing? Most of what I've >> heard seems to sound like "I don't like it to have a 2 on it".=20 >=20 > I don't like it to have a 2 in it. >=20 >> I don't want to have to set up the OAuth 2 system to have to catch >> failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad >> OAuth 1 call should be distinguishable from the start. Also, what about >> when we finally get a signed-request going? I would assume that that's >> going to add back in things like oauth_signature, oauth_nonce, and the >> other parameters whose absence you should filter on.=20 >=20 > The latest signature discussions have all focused on a single, self-conta= ined, signed parameter that includes both data and signature. I think it's = unlikely that we will introduce the plethora of parameters that we had in O= Auth 1.0. >=20 >> -- Justin >>=20 >> On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote: >>> I thought this topic had been beaten to death before. An OAuth 1.0 >>> protected resource request includes a variety of oauth_ parameters >>> whereas OAuth 2.0 just has oauth_token. >>>=20 >>>=20 >>> --David >>>=20 >>>=20 >>> On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton >>> wrote: >>> On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer >>> wrote: >>>> +1 on OAuth2 header, and I also want to see oauth2_token in >>> URI and form >>>> parameter methods. >>>=20 >>>=20 >>> Good point about the query parameter names needing to be >>> unambiguous. >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From john@jkemp.net Thu Jul 15 11:38: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 800863A6AB4 for ; Thu, 15 Jul 2010 11:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHHZqVBbCgHv for ; Thu, 15 Jul 2010 11:37:58 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 2A2743A6958 for ; Thu, 15 Jul 2010 11:37:52 -0700 (PDT) Received: (qmail 1824 invoked by uid 0); 15 Jul 2010 18:37:58 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy2.bluehost.com with SMTP; 15 Jul 2010 18:37:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=g+3/ZeX6QkZiOSmDdi9dc7rZ7IGGEfjUfTx4zoIv2bhZoVmk9w4S3LpzgxyuwaA2SxLlqrDTlx7uzL8NPStm55wSZ+rK6nzcQE2B+xxn7UKo/ij8lqZHDNavx6ro/Zq8; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.112]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OZTJl-0006Qk-QT; Thu, 15 Jul 2010 12:37:58 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: Date: Thu, 15 Jul 2010 14:37:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <02D7ABE3-5B51-43B6-B7A2-6CB9AA045AAA@jkemp.net> To: David Recordon X-Mailer: Apple Mail (2.1081) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 18:38:08 -0000 On Jul 15, 2010, at 2:35 PM, David Recordon wrote: > Given that OAuth discovery hasn't been written yet, how would an OAuth = 1.0 client know about a 2.0 protected resource in the first place? It wouldn't know anything other than it got back a WWW-Authenticate = header when accessing the resource, and (thought it) knew what to do = with the OAuth mechanism. - johnk >=20 >=20 > On Thu, Jul 15, 2010 at 11:33 AM, John Kemp wrote: > On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote: >=20 > > I would like people to raise their hand and explain how this will = break actual 1.0 deployments. >=20 > What happens if a 1.0 client receives a WWW-Authenticate header from a = 2.0 protected resource with the 'OAuth' mechanism specified? Might it = then attempt OAuth 1 with a 2.0 token service (and thus just fail = without being able to know what went wrong)? >=20 > - johnk >=20 > > > > EHL > > > > > > > > On Jul 15, 2010, at 1:38, Brian Eaton wrote: > > > >> Draft 10 switched from "Token" scheme in the authorization header = to > >> "OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be = great. > >> "Token" is ugly as sin, but is better than "OAuth". > >> > >> Spec section: = http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30 > >> > >> The problem with reusing "OAuth" is that there are existing > >> implementations in the wild that have special behavior implemented = for > >> OAuth authorization headers. Since OAuth2 headers don't have the = same > >> semantics, we're going to break those implementations. We = shouldn't > >> reuse "OAuth" for the same reasons we shouldn't reuse "Negotiate", > >> "NTLM", "Digest", or "Basic. > >> > >> Cheers, > >> Brian > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Thu Jul 15 11:40: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 221243A6A9D for ; Thu, 15 Jul 2010 11:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 mx2IbCrYgMWh for ; Thu, 15 Jul 2010 11:40:49 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E07383A6A82 for ; Thu, 15 Jul 2010 11:39:24 -0700 (PDT) Received: (qmail 31628 invoked from network); 15 Jul 2010 18:39:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jul 2010 18:39:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 15 Jul 2010 11:39:23 -0700 From: Eran Hammer-Lahav To: John Kemp Date: Thu, 15 Jul 2010 11:39:15 -0700 Thread-Topic: [OAUTH-WG] OAuth vs OAuth2 in Authorization header Thread-Index: AcskTQuPQEcTB0yXR/m52up+YUcDkQ== Message-ID: <23375931-39B5-4267-925D-5AD5698AAF15@hueniverse.com> References: <02D7ABE3-5B51-43B6-B7A2-6CB9AA045AAA@jkemp.net> In-Reply-To: <02D7ABE3-5B51-43B6-B7A2-6CB9AA045AAA@jkemp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 18:40:51 -0000 There is no such thing. Since there is no discovery for 1.0, all calls are = hardcoded into the client today. There is no 'trying things out'.=20 EHL On Jul 15, 2010, at 14:33, "John Kemp" wrote: > On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote: >=20 >> I would like people to raise their hand and explain how this will break = actual 1.0 deployments.=20 >=20 > What happens if a 1.0 client receives a WWW-Authenticate header from a 2.= 0 protected resource with the 'OAuth' mechanism specified? Might it then at= tempt OAuth 1 with a 2.0 token service (and thus just fail without being ab= le to know what went wrong)?=20 >=20 > - johnk >=20 >>=20 >> EHL >>=20 >>=20 >>=20 >> On Jul 15, 2010, at 1:38, Brian Eaton wrote: >>=20 >>> Draft 10 switched from "Token" scheme in the authorization header to >>> "OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great. >>> "Token" is ugly as sin, but is better than "OAuth". >>>=20 >>> Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30 >>>=20 >>> The problem with reusing "OAuth" is that there are existing >>> implementations in the wild that have special behavior implemented for >>> OAuth authorization headers. Since OAuth2 headers don't have the same >>> semantics, we're going to break those implementations. We shouldn't >>> reuse "OAuth" for the same reasons we shouldn't reuse "Negotiate", >>> "NTLM", "Digest", or "Basic. >>>=20 >>> Cheers, >>> Brian >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From wmills@yahoo-inc.com Thu Jul 15 11:50: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 D99EA3A6AA5 for ; Thu, 15 Jul 2010 11:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.346 X-Spam-Level: X-Spam-Status: No, score=-17.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B24uiu5R5Hmm for ; Thu, 15 Jul 2010 11:50:52 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 541853A6A59 for ; Thu, 15 Jul 2010 11:50:52 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6FIo89t073854; Thu, 15 Jul 2010 11:50:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=T497iw2zCxE/J63BoV4GsYYYDnXYSq+3c7dQdY1kpi/hkMT653j2RERutpTRB1Rv Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 11:50:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Jul 2010 11:50:07 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6CD5@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] OAuth vs OAuth2 in Authorization header Thread-Index: AcskTJ7hBPsBn3XQQyWpNc2p2vpumgAAVGWw References: <1279205969.18579.55.camel@localhost.localdomain><1279216291.18579.61.camel@localhost.localdomain><74AEEFD7-04B3-4B28-970E-0DB554728BED@facebook.com> From: "William Mills" To: "Eran Hammer-Lahav" , "Luke Shepard" X-OriginalArrivalTime: 15 Jul 2010 18:50:08.0341 (UTC) FILETIME=[8BE6F850:01CB244E] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 18:50:55 -0000 Lots of things can be done. Checking presence of oauth_signature_method implies that the format is the same in all cases including the auth header right? What you seem to be arguing for right now is parsing the entire line to decide which auth you do. I would *much* prefer a leading tag or scheme name so I don't have to go there. To me this is an argument about complexity. Your solution involves more complex code to differentiate.=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Eran Hammer-Lahav > Sent: Thursday, July 15, 2010 11:36 AM > To: Luke Shepard > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth vs OAuth2 in Authorization header >=20 > Framing the argument against "having a 2 in it" as=20 > bikeshedding is missing the point. My reason against using=20 > OAuth2 is that is will undermine all the work put in to build=20 > an extensible framework that can evolve without needing a=20 > whole new version. By putting a version number, we make it=20 > more attractive to change the protocol than extend it. >=20 > So far the arguments made are all theoretical. >=20 > I will maintain my objection and preference to reuse the=20 > existing names until someone with an existing 1.0 deployment=20 > can make a compelling reason why they can rely on the=20 > presence of the oauth_signature_method to differentiate.=20 >=20 > EHL >=20 >=20 >=20 > On Jul 15, 2010, at 14:24, "Luke Shepard"=20 > wrote: >=20 > >=20 > > On Jul 15, 2010, at 10:51 AM, Justin Richer wrote: > >=20 > >> It was discussed before, but I don't remember there being any=20 > >> consensus in the group. What are the practical reasons for=20 > not using "oauth2" > >> namespacing in the one place we still use namespacing?=20 > Most of what=20 > >> I've heard seems to sound like "I don't like it to have a 2 on it". > >=20 > > I don't like it to have a 2 in it. > >=20 > >> I don't want to have to set up the OAuth 2 system to have to catch=20 > >> failed cases of the OAuth 1 protocol. A good OAuth 2 call=20 > and a bad=20 > >> OAuth 1 call should be distinguishable from the start. Also, what=20 > >> about when we finally get a signed-request going? I would=20 > assume that=20 > >> that's going to add back in things like oauth_signature,=20 > oauth_nonce,=20 > >> and the other parameters whose absence you should filter on. > >=20 > > The latest signature discussions have all focused on a=20 > single, self-contained, signed parameter that includes both=20 > data and signature. I think it's unlikely that we will=20 > introduce the plethora of parameters that we had in OAuth 1.0. > >=20 > >> -- Justin > >>=20 > >> On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote: > >>> I thought this topic had been beaten to death before. An=20 > OAuth 1.0=20 > >>> protected resource request includes a variety of oauth_=20 > parameters=20 > >>> whereas OAuth 2.0 just has oauth_token. > >>>=20 > >>>=20 > >>> --David > >>>=20 > >>>=20 > >>> On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton > >>> wrote: > >>> On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer > >>> wrote: > >>>> +1 on OAuth2 header, and I also want to see oauth2_token in > >>> URI and form > >>>> parameter methods. > >>>=20 > >>>=20 > >>> Good point about the query parameter names needing to be > >>> unambiguous. > >>>=20 > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>>=20 > >>>=20 > >>>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From mscurtescu@google.com Thu Jul 15 11:57:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7B53A6971 for ; Thu, 15 Jul 2010 11:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.861 X-Spam-Level: X-Spam-Status: No, score=-101.861 tagged_above=-999 required=5 tests=[AWL=0.116, 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 xz6377F-3I7c for ; Thu, 15 Jul 2010 11:57:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id E303F3A6A9E for ; Thu, 15 Jul 2010 11:57:00 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id o6FIvB6Q026683 for ; Thu, 15 Jul 2010 11:57:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279220231; bh=zKvJthAmGfPJ06vX/xS7kxDXurE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=RYWRksS+vMx6+QdmrH9Oq6iTpIwFaYcbpvhQDhdu5i/zWXLQp7Hvmp2HUcVuoqFNF 9j3ciMZ8wzVZgxT0Q4Iiw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=IV0NmZPp1dH/bSFYUwmqMQ/Y+6vieOtiqupwKBPYEQbP2vNrgIRzch3KwaMxToj1S PDpaTnfxU51XtFJr+2EUA== Received: from yxm8 (yxm8.prod.google.com [10.190.4.8]) by hpaq12.eem.corp.google.com with ESMTP id o6FIv9Z0031084 for ; Thu, 15 Jul 2010 11:57:10 -0700 Received: by yxm8 with SMTP id 8so334077yxm.11 for ; Thu, 15 Jul 2010 11:57:09 -0700 (PDT) Received: by 10.101.3.34 with SMTP id f34mr59154ani.185.1279220229230; Thu, 15 Jul 2010 11:57:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Thu, 15 Jul 2010 11:56:49 -0700 (PDT) In-Reply-To: References: <1279205969.18579.55.camel@localhost.localdomain> <1279216291.18579.61.camel@localhost.localdomain> <74AEEFD7-04B3-4B28-970E-0DB554728BED@facebook.com> From: Marius Scurtescu Date: Thu, 15 Jul 2010 11:56:49 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 18:57:01 -0000 On Thu, Jul 15, 2010 at 11:36 AM, Eran Hammer-Lahav w= rote: > Framing the argument against "having a 2 in it" as bikeshedding is missin= g the point. My reason against using OAuth2 is that is will undermine all t= he work put in to build an extensible framework that can evolve without nee= ding a whole new version. By putting a version number, we make it more attr= active to change the protocol than extend it. Sure, but clearly there is no evolution from OAuth 1 to OAuth 2. If the next version of OAuth is an evolution of OAuth 2 then it probably should not be called OAuth 3 but rather OAtuh 2.1 and then header and parameter names can be kept the same. At some point a new revolution will be needed and then OAuth 3 is appropriate, as well as new header and parameter names. Marius From jricher@mitre.org Thu Jul 15 12:15: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 4B4C93A6B38 for ; Thu, 15 Jul 2010 12:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 d34BS2eABOui for ; Thu, 15 Jul 2010 12:15:08 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 81BAA3A69CE for ; Thu, 15 Jul 2010 12:15:06 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6FJFFmo000594 for ; Thu, 15 Jul 2010 15:15:16 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6FJFF2f000585; Thu, 15 Jul 2010 15:15:15 -0400 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, 15 Jul 2010 15:15:15 -0400 From: Justin Richer To: Luke Shepard In-Reply-To: <74AEEFD7-04B3-4B28-970E-0DB554728BED@facebook.com> References: <1279205969.18579.55.camel@localhost.localdomain> <1279216291.18579.61.camel@localhost.localdomain> <74AEEFD7-04B3-4B28-970E-0DB554728BED@facebook.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 15 Jul 2010 15:15:15 -0400 Message-ID: <1279221315.11628.17.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 19:15:15 -0000 > > It was discussed before, but I don't remember there being any consensus > > in the group. What are the practical reasons for not using "oauth2" > > namespacing in the one place we still use namespacing? Most of what I've > > heard seems to sound like "I don't like it to have a 2 on it". > > I don't like it to have a 2 in it. OK, I would. :) > > I don't want to have to set up the OAuth 2 system to have to catch > > failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad > > OAuth 1 call should be distinguishable from the start. Also, what about > > when we finally get a signed-request going? I would assume that that's > > going to add back in things like oauth_signature, oauth_nonce, and the > > other parameters whose absence you should filter on. > > The latest signature discussions have all focused on a single, self-contained, signed parameter that includes both data and signature. I think it's unlikely that we will introduce the plethora of parameters that we had in OAuth 1.0. Yeah, I'd noticed that; but those all stemmed around cryptographic verification of the token itself, and not the request that contained the token. There seems to be a lot of interest in coming up with a way for the AS to sign the token so that the PR can verify its authenticity, but what about the original use case of the PR being able to verify the authenticity of the call? -- Justin > > On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote: > >> I thought this topic had been beaten to death before. An OAuth 1.0 > >> protected resource request includes a variety of oauth_ parameters > >> whereas OAuth 2.0 just has oauth_token. > >> > >> > >> --David > >> > >> > >> On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton > >> wrote: > >> On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer > >> wrote: > >>> +1 on OAuth2 header, and I also want to see oauth2_token in > >> URI and form > >>> parameter methods. > >> > >> > >> Good point about the query parameter names needing to be > >> unambiguous. > >> > >> _______________________________________________ > >> 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 Thu Jul 15 12:26: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 1533E3A6A9A for ; Thu, 15 Jul 2010 12:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 gQEvncu+7o98 for ; Thu, 15 Jul 2010 12:26:38 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id D259C3A6A72 for ; Thu, 15 Jul 2010 12:26:37 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6FJQlKZ011663 for ; Thu, 15 Jul 2010 15:26:48 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6FJQlZw011657; Thu, 15 Jul 2010 15:26:47 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Thu, 15 Jul 2010 15:26:47 -0400 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: References: <1279205969.18579.55.camel@localhost.localdomain> <1279216291.18579.61.camel@localhost.localdomain> <74AEEFD7-04B3-4B28-970E-0DB554728BED@facebook.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 15 Jul 2010 15:26:47 -0400 Message-ID: <1279222007.11628.29.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 19:26:39 -0000 > Framing the argument against "having a 2 in it" as bikeshedding is missing the point. My reason against using OAuth2 is that is will undermine all the work put in to build an extensible framework that can evolve without needing a whole new version. By putting a version number, we make it more attractive to change the protocol than extend it. I think that it is bikeshedding. You can build new and amazing things on a framework named oauth2 as much as you can on something named oauth. If OAuth3 is as backwards-incompatible as OAuth2 is, then it's going to need its own namespace anyway, isn't it? > So far the arguments made are all theoretical. Putting the '2' in there solves an issue that several WG members have brought up when dealing with both OAuth1 and 2 simultaneously -- a case that I think is actually going to happen. I have servers that need to support both 1.0 and 1.0a flows simultaneously, right now. I cannot see OAuth2 adoption and cutover being instantaneous enough across all these different systems for these endpoints to not also support OAuth2. > I will maintain my objection and preference to reuse the existing names until someone with an existing 1.0 deployment can make a compelling reason why they can rely on the presence of the oauth_signature_method to differentiate. I'm sorry, but I simply don't understand your staunch opposition to a simple, low-negative-impact, and decently supported request such as this. I've heard two supporting reasons on the list already: how do I tell the difference between a misbehaving OAuth1 and a properly-behaving OAuth2, and how do I branch early? And I'll also add in something that I admit is more style than anything: It just feels better to branch on the *presence* of something rather than the *absence* of something, if we have that choice. Conversely, I see no compelling reason (technical, political, or otherwise) to *not* have it be named "oauth2". -- Justin PS: I think the bikeshed is where we keep the boatcar... :) > On Jul 15, 2010, at 14:24, "Luke Shepard" wrote: > > > > > On Jul 15, 2010, at 10:51 AM, Justin Richer wrote: > > > >> It was discussed before, but I don't remember there being any consensus > >> in the group. What are the practical reasons for not using "oauth2" > >> namespacing in the one place we still use namespacing? Most of what I've > >> heard seems to sound like "I don't like it to have a 2 on it". > > > > I don't like it to have a 2 in it. > > > >> I don't want to have to set up the OAuth 2 system to have to catch > >> failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad > >> OAuth 1 call should be distinguishable from the start. Also, what about > >> when we finally get a signed-request going? I would assume that that's > >> going to add back in things like oauth_signature, oauth_nonce, and the > >> other parameters whose absence you should filter on. > > > > The latest signature discussions have all focused on a single, self-contained, signed parameter that includes both data and signature. I think it's unlikely that we will introduce the plethora of parameters that we had in OAuth 1.0. > > > >> -- Justin > >> > >> On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote: > >>> I thought this topic had been beaten to death before. An OAuth 1.0 > >>> protected resource request includes a variety of oauth_ parameters > >>> whereas OAuth 2.0 just has oauth_token. > >>> > >>> > >>> --David > >>> > >>> > >>> On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton > >>> wrote: > >>> On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer > >>> wrote: > >>>> +1 on OAuth2 header, and I also want to see oauth2_token in > >>> URI and form > >>>> parameter methods. > >>> > >>> > >>> Good point about the query parameter names needing to be > >>> unambiguous. > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From recordond@gmail.com Thu Jul 15 12:46: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 A1C923A6B8B for ; Thu, 15 Jul 2010 12:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.244, 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 OPUMqylRPW4s for ; Thu, 15 Jul 2010 12:46:54 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 5C22B3A6B86 for ; Thu, 15 Jul 2010 12:46:54 -0700 (PDT) Received: by gyh3 with SMTP id 3so929190gyh.31 for ; Thu, 15 Jul 2010 12:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=wtG6o9dVrbiBzK1+E/S1b47S0gmazshwa/LYfejZJvg=; b=qOn2tm60TaNqy/ue1D1eYK2ZO0Yc+0yrAw9lIPCiTK7HtRiNmiRpNR7fIYst6BB4q9 hbgiBKNXwgBNxe1Ozr5V841lCmYzqhT2IoKdaeZ7qxKvqNbxHWt+ANCknoYC2ieuYHu6 MY0P62jy1TX3hUW/IgooH3bqXiuQfaAn2rPfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=JtyIjEc+ypoaWg1zHgV9Tyr2B6t9LwvUtmRmZRWy3Xf+WwiDbsimZF4xyb7QebbGB2 FTiHZRuHj0H6+16Wcu4+ASuo+wabghhGlnJ9vEInOY2hWkc3AhUMnAbgAAohIDYXMD1/ sakgzgePa0SMFmo0+ga2VBcB9TapCmEwX6++4= MIME-Version: 1.0 Received: by 10.150.55.5 with SMTP id d5mr361718yba.149.1279223222068; Thu, 15 Jul 2010 12:47:02 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Thu, 15 Jul 2010 12:47:02 -0700 (PDT) Date: Thu, 15 Jul 2010 12:47:02 -0700 Message-ID: From: David Recordon To: OAuth WG Content-Type: multipart/alternative; boundary=000e0cd7093abd6781048b725dfa Cc: Jim Brusstar Subject: [OAUTH-WG] Device profile draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 19:46:55 -0000 --000e0cd7093abd6781048b725dfa Content-Type: text/plain; charset=ISO-8859-1 I've broken the device profile out of draft 06 so that it now lives in a separate document as an extension and have updated it to fit into the draft 10 structure. It defines a new "device endpoint" for the initial setup request where the client gets the two codes and URL. It then uses the existing token endpoint for polling for an access token. Jim is currently working on an implementation of it and we're generally looking for feedback from implementors. The current polling mechanism hasn't been tested in production deployments so it's possible that it may change in future drafts. My goal is for this to become a working group draft. http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2-device-00.txt Thanks! --David --000e0cd7093abd6781048b725dfa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've broken the device profile out of draft 06 so that it now lives in = a separate document as an extension and have updated it to fit into the dra= ft 10 structure. It defines a new "device endpoint" for the initi= al setup request where the client gets the two codes and URL. It then uses = the existing token endpoint for polling for an access token.

Jim is currently working on an implementation of it and= we're generally looking for feedback from implementors. The current po= lling mechanism hasn't been tested in production deployments so it'= s possible that it may change in future drafts. My goal is for this to beco= me a working group draft.

Thanks!

--David
--000e0cd7093abd6781048b725dfa-- From gffletch@aol.com Thu Jul 15 13:05:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747223A6B2F for ; Thu, 15 Jul 2010 13:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0A0LkGfkQ1l for ; Thu, 15 Jul 2010 13:05:38 -0700 (PDT) Received: from imr-ma02.mx.aol.com (imr-ma02.mx.aol.com [64.12.206.40]) by core3.amsl.com (Postfix) with ESMTP id 4577D3A685E for ; Thu, 15 Jul 2010 13:05:34 -0700 (PDT) Received: from mtaout-db06.r1000.mx.aol.com (mtaout-db06.r1000.mx.aol.com [172.29.51.198]) by imr-ma02.mx.aol.com (8.14.1/8.14.1) with ESMTP id o6FK5RsH015968; Thu, 15 Jul 2010 16:05:27 -0400 Received: from palantir.local (unknown [10.181.183.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2DC81E0000B7; Thu, 15 Jul 2010 16:05:27 -0400 (EDT) Message-ID: <4C3F6A06.6030804@aol.com> Date: Thu, 15 Jul 2010 16:05:26 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: David Recordon References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010003010600090707060800" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:444397056:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33c64c3f6a071920 X-AOL-IP: 10.181.183.128 Cc: OAuth WG , Jim Brusstar Subject: Re: [OAUTH-WG] Device profile draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 20:05:40 -0000 This is a multi-part message in MIME format. --------------010003010600090707060800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Looks good. Are there any restrictions on the device_code such that it has to be under a certain size? Seems like it would be good to protect against random polling attacks (I presume this is what the Google research refers to). If there are no size restrictions then the device_code could be an encrypted blob with things like the client IP which make verification that it's the right client a little stronger. Also, for devices like a digital photo frame or refrigerator, it seems like client_secrets would be appropriate. Is there a particular reason while they are excluded rather than just optional? Thanks, George On 7/15/10 3:47 PM, David Recordon wrote: > I've broken the device profile out of draft 06 so that it now lives in > a separate document as an extension and have updated it to fit into > the draft 10 structure. It defines a new "device endpoint" for the > initial setup request where the client gets the two codes and URL. It > then uses the existing token endpoint for polling for an access token. > > Jim is currently working on an implementation of it and we're > generally looking for feedback from implementors. The current polling > mechanism hasn't been tested in production deployments so it's > possible that it may change in future drafts. My goal is for this to > become a working group draft. > > http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2-device-00.txt > > Thanks! > > --David > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------010003010600090707060800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Looks good.

Are there any restrictions on the device_code such that it has to be under a certain size? Seems like it would be good to protect against random polling attacks (I presume this is what the Google research refers to). If there are no size restrictions then the device_code could be an encrypted blob with things like the client IP which make verification that it's the right client a little stronger.

Also, for devices like a digital photo frame or refrigerator, it seems like client_secrets would be appropriate. Is there a particular reason while they are excluded rather than just optional?

Thanks,
George

On 7/15/10 3:47 PM, David Recordon wrote:
I've broken the device profile out of draft 06 so that it now lives in a separate document as an extension and have updated it to fit into the draft 10 structure. It defines a new "device endpoint" for the initial setup request where the client gets the two codes and URL. It then uses the existing token endpoint for polling for an access token.

Jim is currently working on an implementation of it and we're generally looking for feedback from implementors. The current polling mechanism hasn't been tested in production deployments so it's possible that it may change in future drafts. My goal is for this to become a working group draft.


Thanks!

--David

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------010003010600090707060800-- From recordond@gmail.com Thu Jul 15 13:12:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B38E3A69DB for ; Thu, 15 Jul 2010 13:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.227, 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 ZR6CMWMgfkLP for ; Thu, 15 Jul 2010 13:12:17 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6A5D83A67F5 for ; Thu, 15 Jul 2010 13:12:17 -0700 (PDT) Received: by iwn38 with SMTP id 38so1403914iwn.31 for ; Thu, 15 Jul 2010 13:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Pi3yOrB+Wf0/CZrq+R7vuY7E72qWHJNcpwfeQ4g7jJc=; b=sNWfK7IjOL/kPR/IGPElMhe6faUbw4dp2Bug+m1vqerVHHIJq7HIAtdX+HdVhPizd+ Cg6n0YOs6wh4UkgEGS/EhxCfmMs06Muj9d9p3qJ86iSnbHoo8j92WYMzkmG9jIAsAPXR ZKPy7+L8z3PjD+pO6UMkvV9iwCE4I/LbfwQ7c= 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=EMIvDtBeGcfEWkxOh/kOp1Mq8d5ta8Ua311GPBEQRw/B5P94UnyukaYHc0XIzTPDJt mZygWxDuKi3zDk2AsDefu/6rnfMQUht9cPcKU4rZ9lEc10UrvEEc1+A3wm0MtxLuU6mT fEGdA+PRDU0H7ouhPLAAALFwaqFUh15jsPdg4= MIME-Version: 1.0 Received: by 10.231.200.146 with SMTP id ew18mr19188124ibb.117.1279224747930; Thu, 15 Jul 2010 13:12:27 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Thu, 15 Jul 2010 13:12:27 -0700 (PDT) In-Reply-To: <4C3F6A06.6030804@aol.com> References: <4C3F6A06.6030804@aol.com> Date: Thu, 15 Jul 2010 13:12:27 -0700 Message-ID: From: David Recordon To: George Fletcher Content-Type: multipart/alternative; boundary=90e6ba615326b03464048b72b895 Cc: OAuth WG , Jim Brusstar Subject: Re: [OAUTH-WG] Device profile draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 20:12:19 -0000 --90e6ba615326b03464048b72b895 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 15, 2010 at 1:05 PM, George Fletcher wrote: > Looks good. > > Are there any restrictions on the device_code such that it has to be under > a certain size? Seems like it would be good to protect against random > polling attacks (I presume this is what the Google research refers to). If > there are no size restrictions then the device_code could be an encrypted > blob with things like the client IP which make verification that it's the > right client a little stronger. > No, there aren't currently any restrictions around the device_code. Just needs to be something which the authorization server issues and the device can hold onto for a few minutes. The Google research is on the length of the user code since you want those to be short and easy to type. Also, for devices like a digital photo frame or refrigerator, it seems like > client_secrets would be appropriate. Is there a particular reason while they > are excluded rather than just optional? > Like with desktop apps, it's hard to guarantee that a device can keep secrets. I should definitely discuss this in the security considerations. There are basically two thoughts in terms of how to solve it: 1) Devices which have TPM can use it to sign requests and thus securely authenticate themselves to authorization servers. 2) An authorization server can issue a second client secret which is only for the device profile. If it is compromised then the client secret used by the application's web servers would still be secure. > Thanks, > George > > On 7/15/10 3:47 PM, David Recordon wrote: > > I've broken the device profile out of draft 06 so that it now lives in a > separate document as an extension and have updated it to fit into the draft > 10 structure. It defines a new "device endpoint" for the initial setup > request where the client gets the two codes and URL. It then uses the > existing token endpoint for polling for an access token. > > Jim is currently working on an implementation of it and we're generally > looking for feedback from implementors. The current polling mechanism hasn't > been tested in production deployments so it's possible that it may change in > future drafts. My goal is for this to become a working group draft. > > > http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2-device-00.txt > > Thanks! > > --David > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > --90e6ba615326b03464048b72b895 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 15, 2010 at 1:05 PM, George Fletcher <gffletch@aol.com> wrote:
<= div class=3D"gmail_quote">
=20
Looks good.

Are there any restrictions on the device_code such that it has to be under a certain size? Seems like it would be good to protect against random polling attacks (I presume this is what the Google research refers to). If there are no size restrictions then the device_code could be an encrypted blob with things like the client IP which make verification that it's the right client a little stronger.

No, there aren't currently any res= trictions around the device_code. Just needs to be something which the auth= orization server issues and the device can hold onto for a few minutes.

The Google research is on the length of the user code s= ince you want those to be short and easy to type.
=A0
<= br>
Also, for devices like a digital photo frame or refrigerator, it= seems like client_secrets would be appropriate. Is there a particular reason while they are excluded rather than just optional?

Like with desktop apps, it's hard to guarantee= that a device can keep secrets. I should=A0definitely=A0discuss this in th= e security considerations. There are basically two thoughts in terms of how= to solve it:
1) Devices which have TPM can use it to sign requests and thus=A0secur= ely=A0authenticate themselves to authorization servers.
2) An aut= horization server can issue a second client secret which is only for the de= vice profile. If it is compromised then the client secret used by the appli= cation's web servers would still be secure.

=A0
T= hanks,
George

On 7/15/10 3:47 PM, David Recordon wrote:
I&#= 39;ve broken the device profile out of draft 06 so that it now lives in a separate document as an extension and have updated it to fit into the draft 10 structure. It defines a new "device endpoint&quo= t; for the initial setup request where the client gets the two codes and URL. It then uses the existing token endpoint for polling for an access token.

Jim is currently working on an implementation of it and we're generally looking for feedback from implementors. The current polling mechanism hasn't been tested in production deployments so it's poss= ible that it may change in future drafts. My goal is for this to become a working group draft.


Thanks!

--David

_______________________________________________
OAuth mailing list

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

--90e6ba615326b03464048b72b895-- From zachary.zeltsan@alcatel-lucent.com Thu Jul 15 13:36:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0492A3A6A30 for ; Thu, 15 Jul 2010 13:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ+apjR8SPTQ for ; Thu, 15 Jul 2010 13:36:11 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 94C983A67F5 for ; Thu, 15 Jul 2010 13:36:11 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o6FKaJDn018037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jul 2010 15:36:20 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6FKaH6T016100; Thu, 15 Jul 2010 15:36:19 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 15 Jul 2010 15:36:19 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'David Recordon'" , OAuth WG Date: Thu, 15 Jul 2010 15:36:19 -0500 Thread-Topic: [OAUTH-WG] Device profile draft Thread-Index: AcskVoMNXi14aszUS3Gm7rsoBCcFpQAAsJWg Message-ID: <5710F82C0E73B04FA559560098BF95B124F9688DD4@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_5710F82C0E73B04FA559560098BF95B124F9688DD4USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: Jim Brusstar Subject: Re: [OAUTH-WG] Device profile draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 20:36:17 -0000 --_000_5710F82C0E73B04FA559560098BF95B124F9688DD4USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 1.5: "The client makes the following request at an arbitrary but reasonable interval which MUST NOT exceed the minimum interval rate provided by the authorization server (if present via the "interval" parameter)." My understanding is that the intervals between the client's subsequent requ= ests must not be less than the value provided by the "interval" parameter (= if it is present). If that is correct than the intervals between the subseq= uent requests MUST exceed (or be equal to) the value of the "interval" para= meter. Section 1.4: "interval OPTIONAL. The minimum amount of time in seconds that the client SHOULD wait between polling requests to the token endpoint" The definition uses the SHOULD requirement, while in section 1.5 the MUST r= equirement is used. Should not the requirement be the same in both places? Zachary ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= avid Recordon Sent: Thursday, July 15, 2010 3:47 PM To: OAuth WG Cc: Jim Brusstar Subject: [OAUTH-WG] Device profile draft I've broken the device profile out of draft 06 so that it now lives in a se= parate document as an extension and have updated it to fit into the draft 1= 0 structure. It defines a new "device endpoint" for the initial setup reque= st where the client gets the two codes and URL. It then uses the existing t= oken endpoint for polling for an access token. Jim is currently working on an implementation of it and we're generally loo= king for feedback from implementors. The current polling mechanism hasn't b= een tested in production deployments so it's possible that it may change in= future drafts. My goal is for this to become a working group draft. http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2-d= evice-00.txt Thanks! --David --_000_5710F82C0E73B04FA559560098BF95B124F9688DD4USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 1.5:<= /p> 

“The client makes the fol=
lowing request at an arbitrary but reasonable
interval whi=
ch MUST NOT exceed the minimum interval rate provided by<=
/font>

  the authorization server (if present via the "interval" parameter).”

 

My understanding is that the intervals between the client’s subsequent requests must not be less than the value provided by the “= interval” parameter (if it is present). If that is correct than the intervals between= the subsequent requests MUST exceed (or be equal to) the value of the “in= terval” parameter.

 

Section 1.4:

&=
#8220;interval
  =
       OPTIONAL.  The minimum amount of =
time in seconds that the
  =
       client SHOULD wait between polling req=
uests to the token

         endpoint”

 

The definition uses the SHOULD requirement, while in section 1.5 th= e MUST requirement is used. Should not the requirement be the same in both places?

 

Zachary<= /font>

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of David Recordon
Sent: Thursday, July 15, 201= 0 3:47 PM
To: OAuth WG
Cc: Jim Brusstar
Subject: [OAUTH-WG] Device p= rofile draft

 

I've broken the device profile out of draft 06 so that it now lives= in a separate document as an extension and have updated it to fit into the dra= ft 10 structure. It defines a new "device endpoint" for the initial setup request where the client gets the two codes and URL. It then uses the existing token endpoint for polling for an access token.<= /font>

 

Jim is currently working on an implementation of it and we're gener= ally looking for feedback from implementors. The current polling mechanism hasn'= t been tested in production deployments so it's possible that it may change i= n future drafts. My goal is for this to become a working group draft.

 

 

Thanks!

 

--David

--_000_5710F82C0E73B04FA559560098BF95B124F9688DD4USNAVSXCHMBSA_-- From bcampbell@pingidentity.com Thu Jul 15 13:50:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE46B3A6A42 for ; Thu, 15 Jul 2010 13:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[AWL=-1.367, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, 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 2YXcxCtwJU1v for ; Thu, 15 Jul 2010 13:50:31 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by core3.amsl.com (Postfix) with SMTP id 7A9403A69B5 for ; Thu, 15 Jul 2010 13:50:30 -0700 (PDT) Received: from source ([209.85.161.49]) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTD90ob7pZN4ZaQo7LVH7ndNN71rOSPM/@postini.com; Thu, 15 Jul 2010 13:50:41 PDT Received: by mail-fx0-f49.google.com with SMTP id 3so770520fxm.36 for ; Thu, 15 Jul 2010 13:50:40 -0700 (PDT) Received: by 10.223.112.12 with SMTP id u12mr1151964fap.33.1279227040159; Thu, 15 Jul 2010 13:50:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.105.135 with HTTP; Thu, 15 Jul 2010 13:50:10 -0700 (PDT) From: Brian Campbell Date: Thu, 15 Jul 2010 14:50:10 -0600 Message-ID: To: oauth Content-Type: multipart/mixed; boundary=001636c5aa5150d82d048b73416c Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 20:50:34 -0000 --001636c5aa5150d82d048b73416c Content-Type: text/plain; charset=ISO-8859-1 I'm gong to join the growing list of people attaching a potential I-D to an email due to he cut off time for the I-D submissions. Attached is a draft that aims to tightly define the particular format of a SAML 2.0 bearer assertion in requesting an access token using the assertion grant_type. I've been working with Chuck at Salesforce.com on this and the primary goal is to have some documentation or specification that is sufficient to facilitate interoperability between independently developed implementations or products. This, of course, wouldn't preclude using SAML in other ways - it would only provide one concrete definition to implement against. I intend to submit this as an I-D when the submission process reopens. Any feedback from this group would be appreciated as well as thoughts about this eventually becoming a working group draft. Thanks, Brian Campbell --001636c5aa5150d82d048b73416c Content-Type: text/plain; charset=US-ASCII; name="draft-campbell-oauth-saml-00-f.txt" Content-Disposition: attachment; filename="draft-campbell-oauth-saml-00-f.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gbo1k0qs0 CgoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBCLiBDYW1wYmVsbCwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUGluZyBJZGVudGl0eSBDb3JwLgpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICBDLiBNb3J0aW1vcmUKRXhwaXJl czogSmFudWFyeSAxNCwgMjAxMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNhbGVz Zm9yY2UuY29tCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSnVseSAxMywgMjAxMAoKCiAgICAgICAgICAgIFNBTUwgMi4wIEJlYXJlciBB c3NlcnRpb24gUHJvZmlsZSBmb3IgT0F1dGggMi4wCiAgICAgICAgICAgICAgICAgICAgIGRyYWZ0 LWNhbXBiZWxsLW9hdXRoLXNhbWwtMDAtZgoKQWJzdHJhY3QKCiAgIFRoaXMgc3BlY2lmaWNhdGlv biBkZWZpbmVzIHRoZSB1c2Ugb2YgYSBTQU1MIDIuMCBiZWFyZXIgYXNzZXJ0aW9uIGFzCiAgIG1l YW5zIGZvciByZXF1ZXN0aW5nIGFuIE9BdXRoIDIuMCBhY2Nlc3MgdG9rZW4uCgpTdGF0dXMgb2Yg dGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNv bmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgog ICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBF bmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFm dHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwog ICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9j dW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJu ZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIg dGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwg ZXhwaXJlIG9uIEphbnVhcnkgMTQsIDIwMTEuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmln aHQgKGMpIDIwMTAgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUK ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3Vt ZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFBy b3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90cnVzdGVlLmll dGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0 aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBj YXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3 aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0 ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNl bnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdh bCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNj cmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgoKCgoKQ2FtcGJlbGwgJiBNb3J0 aW1vcmUgICAgRXhwaXJlcyBKYW51YXJ5IDE0LCAyMDExICAgICAgICAgICAgICAgIFtQYWdlIDFd CgwKSW50ZXJuZXQtRHJhZnQgICAgIE9BdXRoIFNBTUwgQmVhcmVyIEFzc2VydGlvbiBQcm9maWxl ICAgICAgICAgSnVseSAyMDEwCgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rp b24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMwog ICAgIDEuMS4gIE5vdGF0aW9uYWwgQ29udmVudGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDMKICAgMi4gIFNBTUwgQXNzZXJ0aW9uIEFjY2VzcyBUb2tlbiBSZXF1ZXN0 IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzCiAgICAgMi4xLiAgQ2xpZW50IFJlcXVlc3Rz IEFjY2VzcyBUb2tlbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNAogICAgIDIuMi4g IEFzc2VydGlvbiBGb3JtYXQgYW5kIFByb2Nlc3NpbmcgUmVxdWlyZW1lbnRzICAuIC4gLiAuIC4g LiAuIDUKICAgICAyLjMuICBFcnJvciBSZXNwb25zZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA2CiAgICAgMi40LiAgRXhhbXBsZSAobm9uLW5vcm1hdGl2ZSkg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNwogICAzLiAgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgKICAg NC4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA4CiAgIEFwcGVuZGl4IEEuICBDb250cmlidXRvcnMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gOAogICA1LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgKICAgICA1LjEuICBO b3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA4CiAgICAgNS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gOQogICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDkKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgpDYW1wYmVsbCAmIE1vcnRpbW9yZSAgICBFeHBpcmVzIEphbnVhcnkgMTQs IDIwMTEgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgT0F1dGgg U0FNTCBCZWFyZXIgQXNzZXJ0aW9uIFByb2ZpbGUgICAgICAgICBKdWx5IDIwMTAKCgoxLiAgSW50 cm9kdWN0aW9uCgogICBUaGUgU2VjdXJpdHkgQXNzZXJ0aW9uIE1hcmt1cCBMYW5ndWFnZSAoU0FN TCkgMi4wCiAgIFtPQVNJUy5zYW1sLWNvcmUtMi4wLW9zXSwgaXMgYW4gWE1MLWJhc2VkIGZyYW1l d29yayB0aGF0IHByb3ZpZGVzIGEKICAgbWVhbnMgZm9yIGEgc3ViamVjdCB0byBiZSBpZGVudGlm aWVkIGFjcm9zcyBzZWN1cml0eSBkb21haW5zLiAgVGhlCiAgIFNBTUwgc3BlY2lmaWNhdGlvbiwg d2hpbGUgcHJpbWFyaWx5IHRhcmdldGVkIGF0IHByb3ZpZGluZyBjcm9zcwogICBkb21haW4gd2Vi IGJyb3dzZXIgc2luZ2xlIHNpZ24tb24sIHdhcyBhbHNvIGRlc2lnbmVkIHRvIGJlIG1vZHVsYXIK ICAgYW5kIGV4dGVuc2libGUgdG8gZmFjaWxpdGF0ZSB1c2UgaW4gb3RoZXIgY29udGV4dHMuICBU aGUgQXNzZXJ0aW9uLAogICBhbiBYTUwgc2VjdXJpdHkgdG9rZW4sIGlzIGEgZnVuZGFtZW50YWwg Y29uc3RydWN0IG9mIFNBTUwgdGhhdCBpcwogICBtb3N0IG9mdGVuIGFkb3B0ZWQgZm9yIHVzZSBp biBvdGhlciBwcm90b2NvbHMgYW5kIHNwZWNpZmljYXRpb25zLiAgQW4KICAgYXNzZXJ0aW9uIGlz IGdlbmVyYWxseSBpc3N1ZWQgYnkgYW4gaWRlbnRpdHkgcHJvdmlkZXIgYW5kIGNvbnN1bWVkIGJ5 CiAgIGEgc2VydmljZSBwcm92aWRlciB3aG8gcmVsaWVzIG9uIGl0cyBjb250ZW50IHRvIGlkZW50 aWZ5IHRoZSBzdWJqZWN0CiAgIGZvciBzZWN1cml0eSByZWxhdGVkIHB1cnBvc2VzLgoKICAgT0F1 dGggMi4wIFtJLUQuaWV0Zi5vYXV0aC12Ml0gcHJvdmlkZXMgYSBtZXRob2QgZm9yIG1ha2luZwog ICBhdXRoZW50aWNhdGVkIEhUVFAgcmVxdWVzdHMgdG8gYSByZXNvdXJjZSB1c2luZyBhbiBhY2Nl c3MgdG9rZW4uCiAgIFRva2VucyBhcmUgaXNzdWVkIHRvIHRoaXJkLXBhcnR5IGNsaWVudHMgYnkg YW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgd2l0aCB0aGUgKHNvbWV0aW1lcyBpbXBsaWNpdCkg YXBwcm92YWwgb2YgdGhlIHJlc291cmNlIG93bmVyLiAgT0F1dGgKICAgZGVmaW5lcyBtdWx0aXBs ZSBwcm9maWxlcyBmb3Igb2J0YWluaW5nIGFjY2VzcyB0b2tlbnMgdG8gc3VwcG9ydCBhCiAgIHdp ZGUgcmFuZ2Ugb2YgY2xpZW50IHR5cGVzIGFuZCB1c2VyIGV4cGVyaWVuY2VzLiAgT25lIHN1Y2gg bWV0aG9kIGlzCiAgIHRoZSB1c2Ugb2YgYW4gYXNzZXJ0aW9uIHdoaWNoIHN1cHBvcnRzIHRoZSBj YXNlIHdoZW4gYSBjbGllbnQgd2lzaGVzCiAgIHRvIGV4Y2hhbmdlIGFuIGV4aXN0aW5nIHNlY3Vy aXR5IHRva2VuIGZvciBhbiBhY2Nlc3MgdG9rZW4uICBIb3dldmVyCiAgIHRoZSBPYXV0aCAyLjAg bGVhdmVzIHRoZSBzcGVjaWZpYyBmb3JtYXQgYW5kIHZhbGlkYXRpb24gb2YgdGhlCiAgIGFzc2Vy dGlvbiBvdXQgb2Ygc2NvcGUuCgogICBUaGlzIHNwZWNpZmljYXRpb24gcHJvZmlsZXMgdGhlIHNw ZWNpZmljIHVzZSBvZiBhIFNBTUwgMi4wIGJlYXJlcgogICBhc3NlcnRpb24gaW4gcmVxdWVzdGlu ZyBhbiBhY2Nlc3MgdG9rZW4gdXNpbmcgdGhlIGFzc2VydGlvbgogICBncmFudF90eXBlIGZyb20g T0F1dGggMi4wLgoKMS4xLiAgTm90YXRpb25hbCBDb252ZW50aW9ucwoKICAgVGhlIGtleSB3b3Jk cyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAog ICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJ T05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3Jp YmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4KCiAgIFVubGVzcyBvdGhlcndpc2Ugbm90ZWQsIGFs bCB0aGUgcHJvdG9jb2wgcGFyYW1ldGVyIG5hbWVzIGFuZCB2YWx1ZXMKICAgYXJlIGNhc2Ugc2Vu c2l0aXZlLgoKCjIuICBTQU1MIEFzc2VydGlvbiBBY2Nlc3MgVG9rZW4gUmVxdWVzdAoKICAgQSBT QU1MIGFzc2VydGlvbiBpcyB1c2VkIHRvIHJlcXVlc3QgYW4gYWNjZXNzIHRva2VuIHdoZW4gYSBj bGllbnQKICAgd2lzaGVzIHRvIHV0aWxpemUgYW4gZXhpc3RpbmcgdHJ1c3QgcmVsYXRpb25zaGlw LCBleHByZXNzZWQgdGhvdWdoCiAgIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIFNBTUwgYXNzZXJ0aW9u LCB0byBlc3RhYmxpc2ggYXV0aG9yaXphdGlvbgogICB3aXRob3V0IGRpcmVjdGx5IGludm9sdmlu ZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBhcHByb3ZhbCBhdCB0aGUKICAgcmVzb3VyY2Ugc2VydmVy LgoKICAgVGhlIHByb2Nlc3MgYnkgd2hpY2ggdGhlIGNsaWVudCBvYnRhaW5zIHRoZSBhc3NlcnRp b24gaXMgb3V0IG9mCgoKCkNhbXBiZWxsICYgTW9ydGltb3JlICAgIEV4cGlyZXMgSmFudWFyeSAx NCwgMjAxMSAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICBPQXV0 aCBTQU1MIEJlYXJlciBBc3NlcnRpb24gUHJvZmlsZSAgICAgICAgIEp1bHkgMjAxMAoKCiAgIHNj b3BlLgoKCgogICAgICAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLSsKICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgICAgICAgfCAgICAgICAgfD4tLShB KS0tIFNBTUwgMi4wIEFzc2VydGlvbiAtLS0tLT58IEF1dGhvcml6YXRpb24gfAogICAgICAgIHwg Q2xpZW50IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgU2VydmVyICAg IHwKICAgICAgICB8ICAgICAgICB8PC0tKEIpLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tLS0tPHwg ICAgICAgICAgICAgICB8CiAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAgICAgICstLS0tLS0tLSsgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKCgogICAgICAgICAgICAg ICAgIEZpZ3VyZSAxOiBBc3NlcnRpb24gQWNjZXNzIFRva2VuIFJlcXVlc3QKCiAgIFRoZSByZXF1 ZXN0L3Jlc3BvbnNlIGZsb3cgaWxsdXN0cmF0ZWQgaW4gRmlndXJlIDEgaW5jbHVkZXMgdGhlCiAg IGZvbGxvd2luZyBzdGVwczoKCiAgIChBKSAgVGhlIGNsaWVudCBzZW5kcyBhbiBhY2Nlc3MgdG9r ZW4gcmVxdWVzdCB0byB0aGUgYXV0aG9yaXphdGlvbgogICAgICAgIHNlcnZlciBhbmQgaW5jbHVk ZXMgYSBTQU1MIDIuMCBhc3NlcnRpb24uCgogICAoQikgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciB2YWxpZGF0ZXMgdGhlIGFzc2VydGlvbiBwZXIgdGhlCiAgICAgICAgcHJvY2Vzc2luZyBydWxl cyBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBhbmQgaXNzdWVzIGFuCiAgICAgICAgYWNj ZXNzIHRva2VuLgoKMi4xLiAgQ2xpZW50IFJlcXVlc3RzIEFjY2VzcyBUb2tlbgoKICAgVGhlIGNs aWVudCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9rZW4gYnkgbWFraW5nIGFuIEhUVFAgIlBPU1QiIHJl cXVlc3QKICAgdG8gdGhlIHRva2VuIGVuZHBvaW50IHVzaW5nIGFuIGFzc2VydGlvbiBhcyBhbiBh Y2Nlc3MgZ3JhbnQuICBUaGUKICAgY2xpZW50IG1ha2VzIGFuIGFjY2VzcyB0b2tlbiByZXF1ZXN0 LCBhcyBkZWZpbmVkIGluIHRoZSBPQXV0aCwgd2l0aAogICB0aGUgZm9sbG93aW5nIHBhcmFtZXRl ciBkZWZpbml0aW9ucyB0YWtpbmcgcHJlY2VkZW5jZSBpbiB0aGUKICAgY29uc3RydWN0ZWQgVVJJ OgoKICAgYXNzZXJ0aW9uX3R5cGUKICAgICAgICAgUkVRVUlSRUQuICBUaGUgdmFsdWUgb2YgdGhl IGFzc2VydGlvbl9mb3JtYXQgcGFyYW1ldGVyIE1VU1QgYmUKICAgICAgICAgImh0dHA6Ly9vYXV0 aC5uZXQvYXNzZXJ0aW9uX3R5cGUvc2FtbC8yLjAvYmVhcmVyIgoKICAgYXNzZXJ0aW9uCiAgICAg ICAgIFJFUVVJUkVELiAgVGhlIHZhbHVlIG9mIHRoZSBhc3NlcnRpb24gcGFyYW1ldGVyIE1VU1Qg Y29udGFpbiBhCiAgICAgICAgIHNpbmdsZSBTQU1MIDIuMCBBc3NlcnRpb24uICBUaGUgU0FNTCBh c3NlcnRpb24gWE1MIGRhdGEgTVVTVCBiZQogICAgICAgICBlbmNvZGVkIHVzaW5nIGJhc2U2NHVy bCwgd2hlcmUgdGhlIGVuY29kaW5nIGFkaGVyZXMgdG8gdGhlCiAgICAgICAgIGRlZmluaXRpb24g aW4gU2VjdGlvbiA1IG9mIFJGQzQ2NDggW1JGQzQ2NDhdIGFuZCB3aGVyZSB0aGUKICAgICAgICAg cGFkZGluZyBiaXRzIHNldCB0byB6ZXJvLiAgVG8gdG8gYXZvaWQgdGhlIG5lZWQgZm9yIHN1YnNl cXVlbnQKICAgICAgICAgZW5jb2Rpbmcgc3RlcHMgKGJ5ICJhcHBsaWNhdGlvbi94LXd3dy1mb3Jt LXVybGVuY29kZWQiCiAgICAgICAgIFtXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjRdLCBmb3IgZXhh bXBsZSksIHRoZSBiYXNlNjR1cmwgZW5jb2RlZAogICAgICAgICBkYXRhIFNIT1VMRCBOT1QgYmUg bGluZSB3cmFwcGVkIGFuZCBwYWQgY2hhcmFjdGVycyAoIj0iKSBTSE9VTEQKICAgICAgICAgTk9U IGJlIGluY2x1ZGVkLgoKCgoKQ2FtcGJlbGwgJiBNb3J0aW1vcmUgICAgRXhwaXJlcyBKYW51YXJ5 IDE0LCAyMDExICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgIE9B dXRoIFNBTUwgQmVhcmVyIEFzc2VydGlvbiBQcm9maWxlICAgICAgICAgSnVseSAyMDEwCgoKMi4y LiAgQXNzZXJ0aW9uIEZvcm1hdCBhbmQgUHJvY2Vzc2luZyBSZXF1aXJlbWVudHMKCiAgIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHZhbGlkYXRlIHRoZSBhc3NlcnRpb24gYWNjb3JkaW5n IHRvIHRoZQogICBjcml0ZXJpYSBiZWxvdyBhbmQsIGlmIHZhbGlkLCBpc3N1ZXMgYW4gYWNjZXNz IHRva2VuIHJlc3BvbnNlIGFzCiAgIGRlc2NyaWJlZCBpbiBbSS1ELmlldGYub2F1dGgtdjJdLiAg VGhlIGFjY2VzcyB0b2tlbiBTSE9VTEQgYmUgaXNzdWVkCiAgIG9ubHkgZm9yIHRoZSBzdWJqZWN0 IG9mIHRoZSBhc3NlcnRpb24KCiAgIG8gIFRoZSBBc3NlcnRpb24ncyA8SXNzdWVyPiBlbGVtZW50 IE1VU1QgY29udGFpbiBhIHVuaXF1ZSBpZGVudGlmaWVyCiAgICAgIGZvciB0aGUgZW50aXR5IHRo YXQgaXNzdWVkIHRoZSBhc3NlcnRpb247IHRoZSBGb3JtYXQgYXR0cmlidXRlCiAgICAgIE1VU1Qg YmUgb21pdHRlZCBvciBoYXZlIGEgdmFsdWUgb2YKICAgICAgInVybjpvYXNpczpuYW1lczp0YzpT QU1MOjIuMDpuYW1laWQtZm9ybWF0OmVudGl0eSIuCgogICBvICBUaGUgYXNzZXJ0aW9uIE1VU1Qg Y29udGFpbiBhIDxTdWJqZWN0PiBlbGVtZW50IHRoYXQgaWRlbnRpZmllcyB0aGUKICAgICAgcmVz b3VyY2Ugb3duZXIgZm9yIHdob20gdGhlIGFjY2VzcyB0b2tlbiBpcyBiZWluZyByZXF1ZXN0ZWQu CgogICBvICBUaGUgPFN1YmplY3Q+IGVsZW1lbnQgTVVTVCBjb250YWluIGEgc2luZ2xlIDxTdWJq ZWN0Q29uZmlybWF0aW9uPgogICAgICBlbGVtZW50IGFuZCBpdCBNVVNUIGhhdmUgYSBNZXRob2Qg YXR0cmlidXRlIHdpdGggYSB2YWx1ZSBvZgogICAgICAidXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6 Mi4wOmNtOmJlYXJlciIuCgogICBvICBUaGUgPFN1YmplY3RDb25maXJtYXRpb24+IGVsZW1lbnQg TVVTVCBjb250YWluIGEgc2luZ2xlCiAgICAgIDxTdWJqZWN0Q29uZmlybWF0aW9uRGF0YT4gZWxl bWVudC4KCiAgIG8gIFRoZSA8U3ViamVjdENvbmZpcm1hdGlvbkRhdGE+IGVsZW1lbnQgTVVTVCBo YXZlIGEgUmVjaXBpZW50CiAgICAgIGF0dHJpYnV0ZSB3aXRoIGEgdmFsdWUgaW5kaWNhdGluZyB0 aGUgdG9rZW4gZW5kcG9pbnQgVVJMIG9mIHRoZQogICAgICBhdXRob3JpemF0aW9uIHNlcnZlci4g IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHZlcmlmeSB0aGF0CiAgICAgIHRoZSB2YWx1 ZSBvZiB0aGUgUmVjaXBpZW50IGF0dHJpYnV0ZSBtYXRjaGVzIHRoZSB0b2tlbiBlbmRwb2ludAog ICAgICBVUkwgKG9yIGFuIGFjY2VwdGFibGUgYWxpYXMpIHRvIHdoaWNoIHRoZSBhc3NlcnRpb24g d2FzIGRlbGl2ZXJlZC4KCiAgIG8gIFRoZSA8U3ViamVjdENvbmZpcm1hdGlvbkRhdGE+IGVsZW1l bnQgTVVTVCBoYXZlIGEgTm90T25PckFmdGVyCiAgICAgIGF0dHJpYnV0ZSB0aGF0IGxpbWl0cyB0 aGUgd2luZG93IGR1cmluZyB3aGljaCB0aGUgYXNzZXJ0aW9uIGNhbiBiZQogICAgICBjb25maXJt ZWQuICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB2ZXJpZnkgdGhhdCB0aGUKICAgICAg Tm90T25PckFmdGVyIGluc3RhbnQgaGFzIG5vdCBwYXNzZWQsIHN1YmplY3QgdG8gYWxsb3dhYmxl IGNsb2NrCiAgICAgIHNrZXcgYmV0d2VlbiBzeXN0ZW1zLgoKICAgbyAgVGhlIDxTdWJqZWN0Q29u ZmlybWF0aW9uRGF0YT4gZWxlbWVudCBNVVNUIE5PVCBjb250YWluIGEgTm90QmVmb3JlCiAgICAg IGF0dHJpYnV0ZS4KCiAgIG8gIFRoZSA8U3ViamVjdENvbmZpcm1hdGlvbkRhdGE+IGVsZW1lbnQg TUFZIGFsc28gY29udGFpbiBhbiBBZGRyZXNzCiAgICAgIGF0dHJpYnV0ZSBsaW1pdGluZyB0aGUg Y2xpZW50IGFkZHJlc3MgZnJvbSB3aGljaCB0aGUgYXNzZXJ0aW9uIGNhbgogICAgICBiZSBkZWxp dmVyZWQuICBWZXJpZmljYXRpb24gb2YgdGhlIEFkZHJlc3MgaXMgYXQgdGhlIGRpc2NyZXRpb24g b2YKICAgICAgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgoKICAgbyAgSWYgdGhlIGFzc2VydGlv biBpc3N1ZXIgYXV0aGVudGljYXRlZCB0aGUgc3ViamVjdCwgdGhlIGFzc2VydGlvbgogICAgICBT SE9VTEQgY29udGFpbiBhIHNpbmdsZSA8QXV0aG5TdGF0ZW1lbnQ+IHJlcHJlc2VudGluZyB0aGF0 CiAgICAgIGF1dGhlbnRpY2F0aW9uIGV2ZW50LgoKICAgbyAgSWYgdGhlIGFzc2VydGlvbiB3YXMg aXNzdWVkIHdpdGggdGhlIGludGVudGlvbiB0aGF0IHRoZSBjbGllbnQgYWN0CiAgICAgIGF1dG9u b21vdXNseSBvbiBiZWhhbGYgb2YgdGhlIHN1YmplY3QsIGFuIDxBdXRoblN0YXRlbWVudD4gU0hP VUxECgoKCkNhbXBiZWxsICYgTW9ydGltb3JlICAgIEV4cGlyZXMgSmFudWFyeSAxNCwgMjAxMSAg ICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICBPQXV0aCBTQU1MIEJl YXJlciBBc3NlcnRpb24gUHJvZmlsZSAgICAgICAgIEp1bHkgMjAxMAoKCiAgICAgIE5PVCBiZSBp bmNsdWRlZC4KCiAgIG8gIE90aGVyIHN0YXRlbWVudHMsIGluIHBhcnRpY3VsYXIsIDxBdHRyaWJ1 dGVTdGF0ZW1lbnQ+IGVsZW1lbnRzIE1BWQogICAgICBiZSBpbmNsdWRlZCBpbiB0aGUgYXNzZXJ0 aW9uLgoKICAgbyAgVGhlIGFzc2VydGlvbiBNVVNUIGNvbnRhaW4gYW4gPEF1ZGllbmNlUmVzdHJp Y3Rpb24+IGVsZW1lbnQgd2l0aAogICAgICBhbiA8QXVkaWVuY2U+IGVsZW1lbnQgY29udGFpbmlu ZyBhIFVSSSByZWZlcmVuY2UgdGhhdCBpZGVudGlmaWVzCiAgICAgIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciwgb3IgdGhlIHNlcnZpY2UgcHJvdmlkZXIgU0FNTCBlbnRpdHkgb2YKICAgICAgaXRz IGNvbnRyb2xsaW5nIGRvbWFpbiwgYXMgYW4gaW50ZW5kZWQgYXVkaWVuY2UuICBUaGUKICAgICAg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB2ZXJpZnkgdGhhdCBpdCBpcyBhbiBpbnRlbmRlZCBh dWRpZW5jZQogICAgICBmb3IgdGhlIGFzc2VydGlvbi4KCiAgIG8gIFRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBNVVNUIGVuc3VyZSB0aGF0IGJlYXJlciBhc3NlcnRpb25zIGFyZQogICAgICBub3Qg cmVwbGF5ZWQsIGJ5IG1haW50YWluaW5nIHRoZSBzZXQgb2YgdXNlZCBJRCB2YWx1ZXMgZm9yIHRo ZQogICAgICBsZW5ndGggb2YgdGltZSBmb3Igd2hpY2ggdGhlIGFzc2VydGlvbiB3b3VsZCBiZSBj b25zaWRlcmVkIHZhbGlkCiAgICAgIGJhc2VkIG9uIHRoZSBOb3RPbk9yQWZ0ZXIgYXR0cmlidXRl IGluIHRoZQogICAgICA8U3ViamVjdENvbmZpcm1hdGlvbkRhdGE+LgoKICAgbyAgVGhlIGFzc2Vy dGlvbiBNVVNUIGJlIGRpZ2l0YWxseSBzaWduZWQgYnkgdGhlIGlzc3VlciBhbmQgdGhlCiAgICAg IGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgdmVyaWZ5IHRoZSBzaWduYXR1cmUuCgogICBvICBF bmNyeXB0ZWQgZWxlbWVudHMgTUFZIGFwcGVhciBpbiBwbGFjZSBvZiB0aGVpciBwbGFpbiB0ZXh0 CiAgICAgIGNvdW50ZXJwYXJ0cyBhcyBkZWZpbmVkIGluIFtPQVNJUy5zYW1sLWNvcmUtMi4wLW9z XS4KCiAgIG8gIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHZlcmlmeSB0aGF0IHRoZSBh c3NlcnRpb24gaXMgdmFsaWQKICAgICAgaW4gYWxsIG90aGVyIHJlc3BlY3RzIHBlciBbT0FTSVMu c2FtbC1jb3JlLTIuMC1vc10uCgoyLjMuICBFcnJvciBSZXNwb25zZQoKICAgSWYgdGhlIGFzc2Vy dGlvbiBpcyBub3QgdmFsaWQsIG9yIGl0cyBzdWJqZWN0IGNvbmZpcm1hdGlvbgogICByZXF1aXJl bWVudHMgY2Fubm90IGJlIG1ldCwgdGhlIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUCiAg IGNvbnN0cnVjdCBhbiBlcnJvciByZXNwb25zZSBhcyBkZWZpbmVkIGluIFtJLUQuaWV0Zi5vYXV0 aC12Ml0uICBUaGUKICAgdmFsdWUgb2YgdGhlIGVycm9yIHBhcmFtZXRlciBNVVNUIGJlIHRoZSAi aW52YWxpZF9ncmFudCIgZXJyb3IgY29kZS4KICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1B WSBpbmNsdWRlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gcmVnYXJkaW5nCiAgIHRoZSByZWFzb25z IHRoZSBhc3NlcnRpb24gd2FzIGNvbnNpZGVyZWQgaW52YWxpZCB1c2luZyB0aGUKICAgZXJyb3Jf ZGVzY3JpcHRpb24gb3IgZXJyb3JfdXJpIHBhcmFtZXRlcnMuCgogICBGb3IgZXhhbXBsZToKCgog ICBIVFRQLzEuMSA0MDAgQmFkIFJlcXVlc3QKICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9q c29uCiAgIENhY2hlLUNvbnRyb2w6IG5vLXN0b3JlCgogICB7CiAgICAgImVycm9yIjoiaW52YWxp ZF9ncmFudCIsCiAgICAgImVycm9yX2Rlc2NyaXB0aW9uIjoiaW52YWxpZCBzaWduYXR1cmUiCiAg IH0KCgoKQ2FtcGJlbGwgJiBNb3J0aW1vcmUgICAgRXhwaXJlcyBKYW51YXJ5IDE0LCAyMDExICAg ICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgIE9BdXRoIFNBTUwgQmVh cmVyIEFzc2VydGlvbiBQcm9maWxlICAgICAgICAgSnVseSAyMDEwCgoKMi40LiAgRXhhbXBsZSAo bm9uLW5vcm1hdGl2ZSkKCiAgIFRob3VnaCBub24tbm9ybWF0aXZlLCB0aGUgZm9sbG93aW5nIGV4 YW1wbGVzIGlsbHVzdHJhdGUgd2hhdCBhCiAgIGNvbmZvcm1hbnQgYXNzZXJ0aW9uIGFuZCBhY2Nl c3MgdG9rZW4gcmVxdWVzdCB3b3VsZCBsb29rIGxpa2UuCgogICBCZWxvdyBpcyBhbiBleGFtcGxl IFNBTUwgMi4wIEFzc2VydGlvbiAod2hpdGVzcGFjZSBmb3JtYXR0aW5nIGlzIGZvcgogICBkaXNw bGF5IHB1cnBvc2VzIG9ubHkpOgoKCiAgIDxBc3NlcnRpb24gSXNzdWVJbnN0YW50PSIxOTcwLTAx LTAxVDAwOjAwOjAwLjAwMFoiCiAgICAgSUQ9ImVmMXhzYlp4UFYyb3FqZDdIVExSTElCbEJiNyIK ICAgICBWZXJzaW9uPSIyLjAiCiAgICAgeG1sbnM9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIu MDphc3NlcnRpb24iPgogICAgPElzc3Vlcj5odHRwczovL3NhbWwtaWRwLmV4YW1wbGUuY29tPC9J c3N1ZXI+CiAgICA8ZHM6U2lnbmF0dXJlIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAw LzA5L3htbGRzaWcjIj4KICAgICBbLi4ub21pdHRlZCBmb3IgYnJldml0eS4uLl0KICAgIDwvZHM6 U2lnbmF0dXJlPgogICAgPFN1YmplY3Q+CiAgICAgPE5hbWVJRAogICAgICAgRm9ybWF0PSJ1cm46 b2FzaXM6bmFtZXM6dGM6U0FNTDoxLjE6bmFtZWlkLWZvcm1hdDplbWFpbEFkZHJlc3MiPgogICAg ICBicmlhbkBleGFtcGxlLmNvbQogICAgIDwvTmFtZUlEPgogICAgIDxTdWJqZWN0Q29uZmlybWF0 aW9uCiAgICAgICBNZXRob2Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpjbTpiZWFyZXIi PgogICAgICA8U3ViamVjdENvbmZpcm1hdGlvbkRhdGEKICAgICAgIE5vdE9uT3JBZnRlcj0iMTk3 MC0wMS0wMVQwMDowNTowMC4wMDBaIgogICAgICAgUmVjaXBpZW50PSJodHRwczovL2F1dGh6LmV4 YW1wbGUubmV0L3Rva2VuLm9hdXRoMiIvPgogICAgICA8L1N1YmplY3RDb25maXJtYXRpb24+CiAg ICA8L1N1YmplY3Q+CiAgICA8Q29uZGl0aW9ucz4KICAgICA8QXVkaWVuY2VSZXN0cmljdGlvbj4K ICAgICAgPEF1ZGllbmNlPmh0dHBzOi8vc2FtbC1zcC5leGFtcGxlLm5ldDwvQXVkaWVuY2U+CiAg ICAgPC9BdWRpZW5jZVJlc3RyaWN0aW9uPgogICAgPC9Db25kaXRpb25zPgogICA8L0Fzc2VydGlv bj4KCiAgICAgICAgICAgICAgICAgICBGaWd1cmUgMjogRXhhbXBsZSBTQU1MIDIuMCBBc3NlcnRp b24KCgoKCgoKCgoKCgoKCgpDYW1wYmVsbCAmIE1vcnRpbW9yZSAgICBFeHBpcmVzIEphbnVhcnkg MTQsIDIwMTEgICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAgICAgT0F1 dGggU0FNTCBCZWFyZXIgQXNzZXJ0aW9uIFByb2ZpbGUgICAgICAgICBKdWx5IDIwMTAKCgogICBU byBwcmVzZW50IHRoZSBhc3NlcnRpb24gc2hvd24gaW4gdGhlIHByZXZpb3VzIGV4YW1wbGUgYXMg cGFydCBvZiBhbgogICBhY2Nlc3MgdG9rZW4gcmVxdWVzdCwgZm9yIGV4YW1wbGUsIHRoZSBjbGll bnQgbWFrZXMgdGhlIGZvbGxvd2luZwogICBIVFRQUyByZXF1ZXN0IChsaW5lIGJyZWFrcyBhcmUg Zm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6CgoKICAgUE9TVCAvdG9rZW4ub2F1dGgyIEhUVFAv MS4xCiAgIEhvc3Q6IGF1dGh6LmV4YW1wbGUubmV0CiAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRp b24veC13d3ctZm9ybS11cmxlbmNvZGVkCgogICBncmFudF90eXBlPWFzc2VydGlvbiZhc3NlcnRp b25fdHlwZT1odHRwJTNBJTJGJTJGb2F1dGgubmV0JTJGYXNzZQogICBydGlvbl90eXBlJTJGc2Ft bCUyRjIuMCUyRmJlYXJlciZhc3NlcnRpb249UEVGemMyVnlkR2x2YmlCSmMzTjFaVQogICBbLi4u b21pdHRlZCBmb3IgYnJldml0eS4uLl1iMjQtUEM5RGIyNWthWFJwYjI1elBqd3ZRWE56WlhKMGFX OXVQZwoKICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAzOiBFeGFtcGxlIFJlcXVlc3QK CgozLiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIE5vIGFkZGl0aW9uYWwgY29uc2lkZXJh dGlvbnMgYmV5b25kIHRob3NlIGRlc2NyaWJlZCB3aXRoaW4gdGhlIE9BdXRoCiAgIDIuMCBQcm90 b2NvbCBbSS1ELmlldGYub2F1dGgtdjJdIGFuZCBpbiB0aGUgU2VjdXJpdHkgYW5kIFByaXZhY3kK ICAgQ29uc2lkZXJhdGlvbnMgZm9yIHRoZSBPQVNJUyBTZWN1cml0eSBBc3NlcnRpb24gTWFya3Vw IExhbmd1YWdlCiAgIChTQU1MKSBWMi4wIFtPQVNJUy5zYW1sLXNlYy1jb25zaWRlci0yLjAtb3Nd LgoKCjQuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBUaGlzIGRvY3VtZW50IGhhcyBubyBhY3Rp b25zIGZvciBJQU5BLgoKCkFwcGVuZGl4IEEuICBDb250cmlidXRvcnMKCiAgIFRoZSBmb2xsb3dp bmcgcGVvcGxlIGNvbnRyaWJ1dGVkIHdvcmRpbmcgYW5kIGNvbmNlcHRzIHRvIHRoaXMKICAgZG9j dW1lbnQ6IFBhdHJpY2sgSGFyZGluZywgUGV0ZXIgTW90eWthLCBQZXRlciBTYWludC1BbmRyZSBh bmQgRGF2aWQKICAgV2FpdGUKCgo1LiAgUmVmZXJlbmNlcwoKNS4xLiAgTm9ybWF0aXZlIFJlZmVy ZW5jZXMKCiAgIFtJLUQuaWV0Zi5vYXV0aC12Ml0KICAgICAgICAgICAgICBIYW1tZXItTGFoYXYs IEUuLCBFZC4sIFJlY29yZG9uLCBELiwgYW5kIEQuIEhhcmR0LCAiVGhlCiAgICAgICAgICAgICAg T0F1dGggMi4wIFByb3RvY29sIiwgSnVuIDIwMTAuCgogICBbT0FTSVMuc2FtbC1jb3JlLTIuMC1v c10KICAgICAgICAgICAgICBDYW50b3IsIFMuLCBLZW1wLCBKLiwgUGhpbHBvdHQsIFIuLCBhbmQg RS4gTWFsZXIsCiAgICAgICAgICAgICAgIkFzc2VydGlvbnMgYW5kIFByb3RvY29sIGZvciB0aGUg T0FTSVMgU2VjdXJpdHkgQXNzZXJ0aW9uCiAgICAgICAgICAgICAgTWFya3VwIExhbmd1YWdlIChT QU1MKSBWMi4wIiwgT0FTSVMgU3RhbmRhcmQgc2FtbC1jb3JlLQoKCgpDYW1wYmVsbCAmIE1vcnRp bW9yZSAgICBFeHBpcmVzIEphbnVhcnkgMTQsIDIwMTEgICAgICAgICAgICAgICAgW1BhZ2UgOF0K DApJbnRlcm5ldC1EcmFmdCAgICAgT0F1dGggU0FNTCBCZWFyZXIgQXNzZXJ0aW9uIFByb2ZpbGUg ICAgICAgICBKdWx5IDIwMTAKCgogICAgICAgICAgICAgIDIuMC1vcywgTWFyY2ggMjAwNS4KCiAg IFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIElu ZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjEx OSwgTWFyY2ggMTk5Ny4KCiAgIFtSRkM0NjQ4XSAgSm9zZWZzc29uLCBTLiwgIlRoZSBCYXNlMTYs IEJhc2UzMiwgYW5kIEJhc2U2NCBEYXRhCiAgICAgICAgICAgICAgRW5jb2RpbmdzIiwgUkZDIDQ2 NDgsIE9jdG9iZXIgMjAwNi4KCjUuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtPQVNJ Uy5zYW1sLXNlYy1jb25zaWRlci0yLjAtb3NdCiAgICAgICAgICAgICAgSGlyc2NoLCBGLiwgUGhp bHBvdHQsIFIuLCBhbmQgRS4gTWFsZXIsICJTZWN1cml0eSBhbmQKICAgICAgICAgICAgICBQcml2 YWN5IENvbnNpZGVyYXRpb25zIGZvciB0aGUgT0FTSVMgU2VjdXJpdHkgTWFya3VwCiAgICAgICAg ICAgICAgTGFuZ3VhZ2UgKFNBTUwpIFYyLjAiLCBPQVNJUyBTdGFuZGFyZCBzYW1sLXNlYy1jb25z aWRlci0KICAgICAgICAgICAgICAyLjAtb3MsIE1hcmNoIDIwMDUuCgogICBbVzNDLlJFQy1odG1s NDAxLTE5OTkxMjI0XQogICAgICAgICAgICAgIFJhZ2dldHQsIEQuLCBIb3JzLCBBLiwgYW5kIEku IEphY29icywgIkhUTUwgNC4wMQogICAgICAgICAgICAgIFNwZWNpZmljYXRpb24iLCBXb3JsZCBX aWRlIFdlYiBDb25zb3J0aXVtCiAgICAgICAgICAgICAgUmVjb21tZW5kYXRpb24gUkVDLWh0bWw0 MDEtMTk5OTEyMjQsIERlY2VtYmVyIDE5OTksCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cudzMu b3JnL1RSLzE5OTkvUkVDLWh0bWw0MDEtMTk5OTEyMjQ+LgoKCkF1dGhvcnMnIEFkZHJlc3NlcwoK ICAgQnJpYW4gQ2FtcGJlbGwgKGVkaXRvcikKICAgUGluZyBJZGVudGl0eSBDb3JwLgoKICAgRW1h aWw6IGJyaWFuLmQuY2FtcGJlbGxAZ21haWwuY29tCgoKICAgQ2h1Y2sgTW9ydGltb3JlCiAgIFNh bGVzZm9yY2UuY29tCgogICBFbWFpbDogY21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbQoKCgoKCgoK CgoKCgoKCgoKQ2FtcGJlbGwgJiBNb3J0aW1vcmUgICAgRXhwaXJlcyBKYW51YXJ5IDE0LCAyMDEx ICAgICAgICAgICAgICAgIFtQYWdlIDldCgwKCg== --001636c5aa5150d82d048b73416c-- From recordond@gmail.com Thu Jul 15 14:11: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 4BF663A6B8D for ; Thu, 15 Jul 2010 14:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.213, 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 wByd9hre3Apz for ; Thu, 15 Jul 2010 14:11:07 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3CFE83A6B9F for ; Thu, 15 Jul 2010 14:11:06 -0700 (PDT) Received: by iwn38 with SMTP id 38so1454671iwn.31 for ; Thu, 15 Jul 2010 14:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=iF65kSk6vrRokWsRmqLmNhZEgxlZ/hctXq/Dsbe3Fuk=; b=p7/BuoEvkDcTSs5GL/z++qiXJ38ak6eMElYegclq/4AP6lW7wkgDaUfIvh4AICnZj+ EW0wuR4BoTSerOk/8ASvmvXgmH4yIaK3mOnurgXCKz3qzRQOUTUWwzznmBMMXVxckHeK y6/OlFTY6OoYh4C6N+APAn6CbF1QAdG1Ggprk= 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=FuMoJ4+y7f5hBaW6Zf8H+aQmwybJOjTYuDTsWm1Eb5TJG7LzMNe4bTy2J8cl7jLjgv 7zw8Hi7E0DstOPfaVA8LPZfkufDMGtrmc5UL48KEK3p3iQAzm9GOnif4v3WcXwEH/gyd T+qFBqHtdBYHNNeA+Q3gdGUG7jm/6dcUjcq1A= MIME-Version: 1.0 Received: by 10.231.150.15 with SMTP id w15mr19948672ibv.115.1279228277002; Thu, 15 Jul 2010 14:11:17 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Thu, 15 Jul 2010 14:11:16 -0700 (PDT) In-Reply-To: <5710F82C0E73B04FA559560098BF95B124F9688DD4@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688DD4@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Date: Thu, 15 Jul 2010 14:11:16 -0700 Message-ID: From: David Recordon To: "Zeltsan, Zachary (Zachary)" Content-Type: multipart/alternative; boundary=005045013d24099253048b738b83 Cc: OAuth WG , Jim Brusstar Subject: Re: [OAUTH-WG] Device profile draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 21:11:16 -0000 --005045013d24099253048b738b83 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary) < zachary.zeltsan@alcatel-lucent.com> wrote: > Section 1.5: > > =93The client makes the following request at an arbitrary but reasonable > > interval which MUST NOT exceed the minimum interval rate provided by > > the authorization server (if present via the "interval" parameter).=94 > > > > My understanding is that the intervals between the client=92s subsequent > requests must not be less than the value provided by the =93interval=94 > parameter (if it is present). If that is correct than the intervals betwe= en > the subsequent requests MUST exceed (or be equal to) the value of the > =93interval=94 parameter. > Thanks! Reworded to "The client makes the following request at an arbitrary but reasonable interval which MUST NOT be less than the minimum interval rate provided by the authorization server" Section 1.4: > > =93interval > > OPTIONAL. The minimum amount of time in seconds that the > > client SHOULD wait between polling requests to the token > > endpoint=94 > > > > The definition uses the SHOULD requirement, while in section 1.5 the MUST > requirement is used. Should not the requirement be the same in both place= s? > Changed this should to a must. > > > Zachary > > > ------------------------------ > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *David Recordon > *Sent:* Thursday, July 15, 2010 3:47 PM > *To:* OAuth WG > *Cc:* Jim Brusstar > *Subject:* [OAUTH-WG] Device profile draft > > > > I've broken the device profile out of draft 06 so that it now lives in a > separate document as an extension and have updated it to fit into the dra= ft > 10 structure. It defines a new "device endpoint" for the initial setup > request where the client gets the two codes and URL. It then uses the > existing token endpoint for polling for an access token. > > > > Jim is currently working on an implementation of it and we're generally > looking for feedback from implementors. The current polling mechanism has= n't > been tested in production deployments so it's possible that it may change= in > future drafts. My goal is for this to become a working group draft. > > > > > http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2= -device-00.txt > > > > Thanks! > > > > --David > --005045013d24099253048b738b83 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary) <zachary.zeltsa= n@alcatel-lucent.com> wrote:

Section 1.5:

=93The client makes th=
e following request at an arbitrary but reasonable
interval which MUS=
T NOT exceed the minimum interval rate provided by

=A0=A0the authorization server (if present via the "interval" parameter).=94

=A0

My understanding is that the intervals between the c= lient=92s subsequent requests must not be less than the value provided by the =93inte= rval=94 parameter (if it is present). If that is correct than the intervals between= the subsequent requests MUST exceed (or be equal to) the value of the =93interv= al=94 parameter.

Thanks! Reworded = to "The client makes the following request at an arbitrary but reasona= ble interval which=A0MUST NOT be less than the minimum interval rate provid= ed by the authorization server"


Section 1.4:

=93interval
=
=A0=A0=A0=A0=A0=A0=A0=A0 OPTIONAL.=A0 The =
minimum amount of time in seconds that the
=A0=A0=A0=A0=A0=A0=A0=A0 client SHOULD wait between polling requests to th=
e token

=A0=A0=A0=A0=A0=A0=A0=A0 endpoint=94

=A0

The definition uses the SHOULD requirement, while in= section 1.5 the MUST requirement is used. Should not the requirement be the same in both places?

Changed this should = to a must.

=A0

=A0

Zachary

=A0<= /p>

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Beh= alf Of David Recordon
Sent: Thursday, July 15, 201= 0 3:47 PM
To: OAuth WG
Cc: Jim Brusstar
Subject: [OAUTH-WG] Device p= rofile draft

=A0

I've broken the device profile out of draft 06 s= o that it now lives in a separate document as an extension and have updated it to fit into the dra= ft 10 structure. It defines a new "device endpoint" for the initial setup request where the client gets the two codes and URL. It then uses the existing token endpoint for polling for an access token.

=A0

Jim is currently working on an implementation of it = and we're generally looking for feedback from implementors. The current polling mechanism hasn&= #39;t been tested in production deployments so it's possible that it may chan= ge in future drafts. My goal is for this to become a working group draft.<= /font>

=A0

=A0

Thanks!

=A0

--David


--005045013d24099253048b738b83-- From bcampbell@pingidentity.com Thu Jul 15 14:16:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4223A6831 for ; Thu, 15 Jul 2010 14:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.521 X-Spam-Level: X-Spam-Status: No, score=-5.521 tagged_above=-999 required=5 tests=[AWL=0.456, 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 z8gwBRCO7jyc for ; Thu, 15 Jul 2010 14:16:39 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by core3.amsl.com (Postfix) with SMTP id A3BF93A67F5 for ; Thu, 15 Jul 2010 14:16:38 -0700 (PDT) Received: from source ([209.85.161.48]) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTD96wSeKg3eJer5FgWw+MhMCUykblp9B@postini.com; Thu, 15 Jul 2010 14:16:50 PDT Received: by mail-fx0-f48.google.com with SMTP id 16so917493fxm.35 for ; Thu, 15 Jul 2010 14:16:49 -0700 (PDT) Received: by 10.223.118.71 with SMTP id u7mr1174473faq.58.1279228609237; Thu, 15 Jul 2010 14:16:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.105.135 with HTTP; Thu, 15 Jul 2010 14:16:19 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 15 Jul 2010 15:16:19 -0600 Message-ID: To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] authz code randomness (was: single use authorization codes) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 21:16:40 -0000 As written it probably does preclude that but I'm sure we could massage it to be more flexible while still keeping the intent that the code isn't something that can be easily guessed or is likely to collide. I must admit to never having considered the authz code as anything but a random string as a reference that must be resolved. Can you expand on your thinking a bit, if only to enlighten me? Are you thinking of embedding what would be the entire access token response to the eventual authorization_code grant type request inside the access token itself and encrypting and/or singing it? On Thu, Jul 15, 2010 at 11:39 AM, Brian Eaton wrote: > > Does that text preclude using stateless authorization code implementations? > > Authorization codes are issued frequently and change rapidly, so I am > very interested in supporting stateless implementations. > From beaton@google.com Thu Jul 15 14:30:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2E53A6831 for ; Thu, 15 Jul 2010 14:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.898 X-Spam-Level: X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[AWL=0.079, 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 W4RhiPvOx9-i for ; Thu, 15 Jul 2010 14:30:06 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 806CF3A67CF for ; Thu, 15 Jul 2010 14:30:01 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o6FLUAa2027294 for ; Thu, 15 Jul 2010 14:30:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279229411; bh=TTuSKt7WVe0zfjD9mWetViZ9Bew=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Ap2DjHob8jIj3hRK1u3nuxCKj3xP6Mp1j58EJS6ROn7D8DE3CU3YUZgxz4bLgJyI9 LtdJTDTeqQugvlNKHfxmw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=gtafkbhJrlevF4+yZZQtueGHmRRa2vH5xv9Kq6LqYWVZGILHB3N5C3fJz2ZEKaHPN cG4wURH/9HlXDA64+eMoA== Received: from yxj4 (yxj4.prod.google.com [10.190.3.68]) by kpbe11.cbf.corp.google.com with ESMTP id o6FLU9t5021056 for ; Thu, 15 Jul 2010 14:30:09 -0700 Received: by yxj4 with SMTP id 4so247019yxj.22 for ; Thu, 15 Jul 2010 14:30:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.94.17 with SMTP id r17mr340627agb.15.1279229408776; Thu, 15 Jul 2010 14:30:08 -0700 (PDT) Received: by 10.91.216.11 with HTTP; Thu, 15 Jul 2010 14:30:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Jul 2010 14:30:08 -0700 Message-ID: From: Brian Eaton To: Brian Campbell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth Subject: Re: [OAUTH-WG] authz code randomness (was: single use authorization codes) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 21:30:11 -0000 On Thu, Jul 15, 2010 at 2:16 PM, Brian Campbell wrote: > I must admit to never having considered the authz code as anything but > a random string as a reference that must be resolved. =A0Can you expand > on your thinking a bit, if only to enlighten me? > > Are you thinking of embedding what would be the entire access token > response to the eventual authorization_code grant type request inside > the access token itself and encrypting and/or singing it? Yes. The oauth2 authorization code and the SAML artifact are similar in that they end up creating this pattern: user in location A creates some value value is transferred to location B server in location B resolves value value expires If A and B are geographically distant, you end up having to replicate rapidly changing state. that's expensive, and not terribly useful. If you use a stateless implementation (e.g. authorization code is a signed blob containing the client-id, the user-id, the list of scopes granted, a timestamp, and a hash of the callback URL) things are much more efficient. The code is a bit longer. Cheers, Brian From michael.d.adams@gmail.com Thu Jul 15 14:32: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 EAA983A6831 for ; Thu, 15 Jul 2010 14:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyEMWlmoMwi1 for ; Thu, 15 Jul 2010 14:32:03 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BED4D3A67CF for ; Thu, 15 Jul 2010 14:32:02 -0700 (PDT) Received: by iwn38 with SMTP id 38so1474012iwn.31 for ; Thu, 15 Jul 2010 14:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; bh=4Q4iDjSrh3SdICzQs6KnXGbOCsmT9JDwrHZJ4K73M94=; b=LqQGRGgRwEZWGgt7hFeGCILQNIdy1cg0t/L3gpnkre1tLPTB16FVfLeWRz35MBbRdT Qei7nzow6NjiEnLFZtHs1Ov1/xt02XKI2kKNuGxs/eBcXDsRr9wOHYtxE+EB9Q/IBdW0 ttMklnrR32dAxkYWJjIwdaOQjuNR2wshIIDIY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=LQO/KikM2b9DU89cTOrfBbTuNjmi/Z5hxohoD4+KqfidtpoQg5i30+EDloI6DABi0G HeGLeGXc+pyhvQS5jwB6jMrt7WGpWOOt08pJooeeo0l+VF2ueKFFuSHJ7p7FMg0LC+6h R5zSGNIpDne8QVT8qrsHShJ/DAF4yNfOQuw6E= Received: by 10.231.16.76 with SMTP id n12mr18847835iba.194.1279229533293; Thu, 15 Jul 2010 14:32:13 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.179.143 with HTTP; Thu, 15 Jul 2010 14:31:53 -0700 (PDT) In-Reply-To: References: <5710F82C0E73B04FA559560098BF95B124F9688DD4@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: Michael D Adams Date: Thu, 15 Jul 2010 14:31:53 -0700 X-Google-Sender-Auth: vyxjYgCT7j4_EEJlbTiKKN0WPms Message-ID: To: OAuth WG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Device profile draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 21:32:05 -0000 On Thu, Jul 15, 2010 at 2:11 PM, David Recordon wrote= : > On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary) >> =93The client makes the following request at an arbitrary but reasonable >> interval which MUST NOT exceed the minimum interval rate provided by >> =A0=A0the authorization server (if present via the "interval" parameter)= .=94 >> >> My understanding is that the intervals between the client=92s subsequent >> requests must not be less than the value provided by the =93interval=94 >> parameter (if it is present). If that is correct than the intervals betw= een >> the subsequent requests MUST exceed (or be equal to) the value of the >> =93interval=94 parameter. > > Thanks! Reworded to "The client makes the following request at an arbitra= ry > but reasonable interval which=A0MUST NOT be less than the minimum interva= l > rate provided by the authorization server" It still sounds confusing to me. Part of the problem is that we're talking both about an interval (a length of time) and a frequency (requests per unit of time). How about: The client makes the next request after an arbitrary but reasonable length of time, which MUST be longer than or equal to the minimum length of time provided by the authorization server in the "interval" parameter if present. I changed "following" to "next" because the former makes it sound like the next paragraph will have details about the request. I changed "at an arbitrary" to "after an arbitrary" since we're talking here about lengths of time. I replaced "interval" with "length of time" to make it clear we're talking about the length of time and not the corresponding frequency. Mike --mdawaffe From naitiks@gmail.com Thu Jul 15 14:34:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0F003A6840 for ; Thu, 15 Jul 2010 14:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjxSdvGEEfc7 for ; Thu, 15 Jul 2010 14:34:16 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 5806C3A6A6B for ; Thu, 15 Jul 2010 14:34:16 -0700 (PDT) Received: by gxk1 with SMTP id 1so657046gxk.31 for ; Thu, 15 Jul 2010 14:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=3UW7h5sXrWGhlJ0qJLyeOCKZUW5Dejo3/fPiVbR26Fw=; b=to/Z7vebnQx8lnZuhTsf3w74g+6W1+GApZ+sNNd8HHXEoY4i/Ut+1l5rD8V+ZlcbBv R17n64fKyaw8hLYsDJBSWE6Tt7zg9UYT6yy7t+yrn0Qa0z5rTWRIXH0D+7EL7F59JiIx zUn9Tg65s5aT1lsEnBwwf0x22ciX/JSHM8Ttg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=fWSywKmDZa21IRt2q0yja/3WCUMGZAms+Ydr+JAphKbOCZz584gecxbD+YIHZEGzTx 4n2yq5RXNQWsOj/cvEIEXnqtuTB1z1XJVjyBUoZpuCX+dNbHXFVUzzAOCj3luskBTziD avfTKrgEo3hY68MliJYL/tLEQbGGGVKhVVJhg= Received: by 10.150.69.32 with SMTP id r32mr612573yba.107.1279229664333; Thu, 15 Jul 2010 14:34:24 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.231.159.193 with HTTP; Thu, 15 Jul 2010 14:34:04 -0700 (PDT) In-Reply-To: <1279216291.18579.61.camel@localhost.localdomain> References: <1279205969.18579.55.camel@localhost.localdomain> <1279216291.18579.61.camel@localhost.localdomain> From: Naitik Shah Date: Thu, 15 Jul 2010 14:34:04 -0700 X-Google-Sender-Auth: 9tvAFnHp8pvYEZGsxt-zcpvav50 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=000e0cd598ccba9041048b73dd64 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 21:34:17 -0000 --000e0cd598ccba9041048b73dd64 Content-Type: text/plain; charset=UTF-8 I though we'd come to a decision on the versioning too :) IMHO, it's better to push this burden of versioning into the token itself if necessary. I think it's better from a developers perspective to pass an oauth_token, because it's cleaner. Most deployments will already have versioned tokens to enable upgrading these for internal changes, so why can't the OAuth version be contained in there too? Given the option to simplify the implementation for a API provider (Big Company, or someone who has to know how OAuth works) vs API consumer (Developer, or someone who usually just wants some data), I hope everyone agrees our focus should be the Developer. While we (Facebook) didn't have OAuth 1.0 tokens to deal with and so don't have the same backward compatibility issues, we've already changed our tokens and introduced new ones a couple of times and this had no impact on the parameter name being used. -Naitik On Thu, Jul 15, 2010 at 10:51 AM, Justin Richer wrote: > It was discussed before, but I don't remember there being any consensus > in the group. What are the practical reasons for not using "oauth2" > namespacing in the one place we still use namespacing? Most of what I've > heard seems to sound like "I don't like it to have a 2 on it". > > I don't want to have to set up the OAuth 2 system to have to catch > failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad > OAuth 1 call should be distinguishable from the start. Also, what about > when we finally get a signed-request going? I would assume that that's > going to add back in things like oauth_signature, oauth_nonce, and the > other parameters whose absence you should filter on. > > -- Justin > > On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote: > > I thought this topic had been beaten to death before. An OAuth 1.0 > > protected resource request includes a variety of oauth_ parameters > > whereas OAuth 2.0 just has oauth_token. > > > > > > --David > > > > > > On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton > > wrote: > > On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer > > wrote: > > > +1 on OAuth2 header, and I also want to see oauth2_token in > > URI and form > > > parameter methods. > > > > > > Good point about the query parameter names needing to be > > unambiguous. > > > > _______________________________________________ > > 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 > --000e0cd598ccba9041048b73dd64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I though we'd come to a decision on the=C2=A0versioning=C2=A0too :) IMH= O, it's better to push this burden of=C2=A0versioning into the token it= self if necessary. I think it's better from a developers perspective to= pass an oauth_token, because it's cleaner. Most deployments will alrea= dy have versioned tokens to enable upgrading these for internal changes, so= why can't the OAuth version be contained in there too? Given the optio= n to simplify the implementation for a API provider (Big Company, or someon= e who has to know how OAuth works) vs API consumer (Developer, or someone w= ho usually just wants some data), I hope everyone agrees our focus should b= e the Developer.

While we (Facebook) didn't have OAuth 1.0 tokens to deal= with and so don't have the same backward compatibility issues, we'= ve already changed our tokens and introduced new ones a couple of times and= this had no impact on the parameter name being used.


-Naitik

On Thu, Jul 15, 2010 at 10:51 AM, Justin Richer <jricher@mitre.org>= wrote:
It was discussed before, but I don't re= member there being any consensus
in the group. What are the practical reasons for not using "oauth2&quo= t;
namespacing in the one place we still use namespacing? Most of what I'v= e
heard seems to sound like "I don't like it to have a 2 on it"= .

I don't want to have to set up the OAuth 2 system to have to catch
failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad
OAuth 1 call should be distinguishable from the start. Also, what about
when we finally get a signed-request going? I would assume that that's<= br> going to add back in things like oauth_signature, oauth_nonce, and the
other parameters whose absence you should filter on.

=C2=A0-- Justin

On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote:
> I thought this topic had been beaten to death before. An OAuth 1.0
> protected resource request includes a variety of oauth_ parameters
> whereas OAuth 2.0 just has oauth_token.
>
>
> --David
>
>
> On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton <beaton@google.com>
> wrote:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jul 15, 2010 at 7:59 AM, Justin Ri= cher
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <j= richer@mitre.org> wrote:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 > +1 on OAuth2 header, and I also want = to see oauth2_token in
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 URI and form
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 > parameter methods.
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Good point about the query parameter names= needing to be
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 unambiguous.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________= _____
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth mailing list
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth@ie= tf.org
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/oauth=
>
>
>


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

--000e0cd598ccba9041048b73dd64-- From recordond@gmail.com Thu Jul 15 14:41: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 ED2553A69DE for ; Thu, 15 Jul 2010 14:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.201, 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 MVXFPVtoI5q0 for ; Thu, 15 Jul 2010 14:41:24 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BD9F43A67F4 for ; Thu, 15 Jul 2010 14:41:24 -0700 (PDT) Received: by iwn38 with SMTP id 38so1482766iwn.31 for ; Thu, 15 Jul 2010 14:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=UKhffldCdNDAwbIwoHgOomnolVrtcZq9zLlpfl9ZBCw=; b=QGwa/ckAuSRUnNlZk6+CnuvDVu/jPHFtZpnVA9n8h/5VlgT8nrwfZhY+9s8MLBubHz 8N/o5v27FrLnHkPDPFqa/yPVKG1qqhm038aS6UJPVBHK5E23fYnzsXpP3RXLOs+V0Pz1 8uL9qL6/ZffIao+tr4BusafGBtlWhUJMy8ZT4= 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=DJlb7Sd4mGGLhT9L+pm0U7EPGBQc4Imjtj19KfWniXEX0bvsQ/9tQqtoxvrMk0+boC WR0nkRKrwDhPutiMqH2elL0w6jSDxtcWTOVryI1XRlhx7P3lwmafy4dpzpKAVXGYglaZ SEu7qu3LZYRDvO4Yi+vFE+gK9QvqxV7miNkU0= MIME-Version: 1.0 Received: by 10.231.168.135 with SMTP id u7mr20119911iby.125.1279230095682; Thu, 15 Jul 2010 14:41:35 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Thu, 15 Jul 2010 14:41:35 -0700 (PDT) In-Reply-To: References: <5710F82C0E73B04FA559560098BF95B124F9688DD4@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Date: Thu, 15 Jul 2010 14:41:35 -0700 Message-ID: From: David Recordon To: Michael D Adams Content-Type: multipart/alternative; boundary=005045013df5706b2d048b73f797 Cc: OAuth WG Subject: Re: [OAUTH-WG] Device profile draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 21:41:26 -0000 --005045013df5706b2d048b73f797 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Even better, thanks! On Thu, Jul 15, 2010 at 2:31 PM, Michael D Adams wrote= : > On Thu, Jul 15, 2010 at 2:11 PM, David Recordon > wrote: > > On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary) > >> =93The client makes the following request at an arbitrary but reasonab= le > >> interval which MUST NOT exceed the minimum interval rate provided by > >> the authorization server (if present via the "interval" parameter).= =94 > >> > >> My understanding is that the intervals between the client=92s subseque= nt > >> requests must not be less than the value provided by the =93interval= =94 > >> parameter (if it is present). If that is correct than the intervals > between > >> the subsequent requests MUST exceed (or be equal to) the value of the > >> =93interval=94 parameter. > > > > Thanks! Reworded to "The client makes the following request at an > arbitrary > > but reasonable interval which MUST NOT be less than the minimum interva= l > > rate provided by the authorization server" > > It still sounds confusing to me. Part of the problem is that we're > talking both about an interval (a length of time) and a frequency > (requests per unit of time). > > How about: > > The client makes the next request after an arbitrary but reasonable > length of time, which MUST be longer than or equal to the minimum > length of time provided by the authorization server in the "interval" > parameter if present. > > > I changed "following" to "next" because the former makes it sound like > the next paragraph will have details about the request. > > I changed "at an arbitrary" to "after an arbitrary" since we're > talking here about lengths of time. > > I replaced "interval" with "length of time" to make it clear we're > talking about the length of time and not the corresponding frequency. > > Mike > --mdawaffe > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --005045013df5706b2d048b73f797 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Even better, thanks!

On Thu, Jul 15, 2010= at 2:31 PM, Michael D Adams <mike@automattic.com> wrote:
On Thu, Jul 15, 2010 at 2:11 PM, David Recordon <recordond@gmail.com> wrote:
> On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary)
>> =93The client makes the following request = at an arbitrary but reasonable
>> interval which MUST NOT exceed the minimum interval rate provided = by
>> =A0=A0the authorization server (if present via the "interval&= quot; parameter).=94
>>
>> My understanding is that the intervals between the client=92s subs= equent
>> requests must not be less than the value provided by the =93interv= al=94
>> parameter (if it is present). If that is correct than the interval= s between
>> the subsequent requests MUST exceed (or be equal to) the value of = the
>> =93interval=94 parameter.
>
> Thanks! Reworded to "The client makes the following request at an= arbitrary
> but reasonable interval which=A0MUST NOT be less than the minimum inte= rval
> rate provided by the authorization server"

It still sounds confusing to me. =A0Part of the problem is that we= 9;re
talking both about an interval (a length of time) and a frequency
(requests per unit of time).

How about:

The client makes the next request after an arbitrary but reasonable
length of time, which MUST be longer than or equal to the minimum
length of time provided by the authorization server in the "interval&q= uot;
parameter if present.


I changed "following" to "next" because the former make= s it sound like
the next paragraph will have details about the request.

I changed "at an arbitrary" to "after an arbitrary" sin= ce we're
talking here about lengths of time.

I replaced "interval" with "length of time" to make it = clear we're
talking about the length of time and not the corresponding frequency.

Mike
--mdawaffe
_________________________________________= ______
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--005045013df5706b2d048b73f797-- From torsten@lodderstedt.net Thu Jul 15 15:49: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 9FA2B3A6B9B for ; Thu, 15 Jul 2010 15:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, 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 rd4geA5fkQX9 for ; Thu, 15 Jul 2010 15:49:22 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by core3.amsl.com (Postfix) with ESMTP id BCA8F3A6BB8 for ; Thu, 15 Jul 2010 15:49:20 -0700 (PDT) Received: from p4ffd0e52.dip.t-dialin.net ([79.253.14.82] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OZXEu-0002AN-DQ; Fri, 16 Jul 2010 00:49:12 +0200 Message-ID: <4C3F9064.6060604@lodderstedt.net> Date: Fri, 16 Jul 2010 00:49:08 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Marius Scurtescu References: <4C3F3F6A.5000409@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 22:49:23 -0000 Am 15.07.2010 20:14, schrieb Marius Scurtescu: > On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt > wrote: > >> As I have written in my reply to Marius's posting. I'm fine with including >> server ids in scopes. But this requires a definition of the scope's syntax >> and semantics in the spec. Otherwise, scope interpretation (and server >> identification) will be deployment specific. >> > Sure, it is deployment specific, but why is that an issue? > > In your case, the authz server and all the resource servers are > managed by the same organization, right? > > Do clients need to be aware of the actual resource server? > > You can probably create a separate spec that defines scope syntax for > this purpose, if really needed. Does it have to be in core? > > Marius > Solving the challenge I described in a deployment specific way is not an issue. But the consequence is that authz server, resource servers and clients are tight together. Let me ask you one question: Why are we working together towards a standard protocol? I can tell you my expectations: I hope there will be broad support not only by libraries, but also by ready-to-use services and clients, so we could integrate such services into our deployment easily. Moreover, I would like to see OAuth to be included in application/service protocols like PortableContacts, SIP, WebDAV, IMAP, ... So what if I would like to use standard clients to access our services? Using scopes for specifying resource server id's in this case is also simple - if you take an isolated view. But since scopes may be used to specifiy a lot of other things, like resources, permissions, and durations, handling w/o a more detailed spec will in practice be impossible. Suppose a WebDAV service for media data access. Any WebDAV client knows the WebDAV protocol (== interface), e.g. the supported methods (GET, PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. So it is sufficient to configure the client with the URL of my personal web storage. To start with let's assume, scopes are used to designate resource servers only. So the server's scope could be "webstorage". WWW-Authenticate OAuth realm='webstorage' scope="webstorage" The client could just pass this parameter to the authz server and everything is fine. On the next level, let's assume the (future) WebDAV standard with OAuth-support uses one permission per method type. So the full scope could be as follows: WWW-Authenticate OAuth realm='webstorage' scope="webstorage:GET webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY webstorage:MOVE" Passing this scope w/o any unmodified to the authz server is not an issue. But this implies the client asks for full access to the users media storage. Since our client is a gallery application, it requires the "GET" permission only. How does the client know which of the scope values to pick for the end-user authorization process? It must somehow select "webstorage:GET". But how? In my personal opinion, clients should be enabled to interpret, combine and even create scopes. And yes, this should go to the core of the spec. regards, Torsten. From torsten@lodderstedt.net Thu Jul 15 15:56: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 7F1493A6802 for ; Thu, 15 Jul 2010 15:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIJykQz8a7Lt for ; Thu, 15 Jul 2010 15:56:25 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by core3.amsl.com (Postfix) with ESMTP id E0FA73A6800 for ; Thu, 15 Jul 2010 15:56:24 -0700 (PDT) Received: from p4ffd0e52.dip.t-dialin.net ([79.253.14.82] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OZXM2-0003bn-7h; Fri, 16 Jul 2010 00:56:34 +0200 Message-ID: <4C3F921E.7040304@lodderstedt.net> Date: Fri, 16 Jul 2010 00:56:30 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Naitik Shah References: <1279205969.18579.55.camel@localhost.localdomain> <1279216291.18579.61.camel@localhost.localdomain> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070608050108040407040000" X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 22:56:26 -0000 This is a multi-part message in MIME format. --------------070608050108040407040000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit where is the relation between token version and HTTP authentication scheme version? regards, Torsten. Am 15.07.2010 23:34, schrieb Naitik Shah: > I though we'd come to a decision on the versioning too :) IMHO, it's > better to push this burden of versioning into the token itself if > necessary. I think it's better from a developers perspective to pass > an oauth_token, because it's cleaner. Most deployments will already > have versioned tokens to enable upgrading these for internal changes, > so why can't the OAuth version be contained in there too? Given the > option to simplify the implementation for a API provider (Big Company, > or someone who has to know how OAuth works) vs API consumer > (Developer, or someone who usually just wants some data), I hope > everyone agrees our focus should be the Developer. > > While we (Facebook) didn't have OAuth 1.0 tokens to deal with and so > don't have the same backward compatibility issues, we've already > changed our tokens and introduced new ones a couple of times and this > had no impact on the parameter name being used. > > > -Naitik > > On Thu, Jul 15, 2010 at 10:51 AM, Justin Richer > wrote: > > It was discussed before, but I don't remember there being any > consensus > in the group. What are the practical reasons for not using "oauth2" > namespacing in the one place we still use namespacing? Most of > what I've > heard seems to sound like "I don't like it to have a 2 on it". > > I don't want to have to set up the OAuth 2 system to have to catch > failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad > OAuth 1 call should be distinguishable from the start. Also, what > about > when we finally get a signed-request going? I would assume that that's > going to add back in things like oauth_signature, oauth_nonce, and the > other parameters whose absence you should filter on. > > -- Justin > > On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote: > > I thought this topic had been beaten to death before. An OAuth 1.0 > > protected resource request includes a variety of oauth_ parameters > > whereas OAuth 2.0 just has oauth_token. > > > > > > --David > > > > > > On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton > > > wrote: > > On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer > > > wrote: > > > +1 on OAuth2 header, and I also want to see oauth2_token in > > URI and form > > > parameter methods. > > > > > > Good point about the query parameter names needing to be > > unambiguous. > > > > _______________________________________________ > > 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 > --------------070608050108040407040000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit where is the relation between token version and HTTP authentication scheme version?

regards,
Torsten.

Am 15.07.2010 23:34, schrieb Naitik Shah:
I though we'd come to a decision on the versioning too :) IMHO, it's better to push this burden of versioning into the token itself if necessary. I think it's better from a developers perspective to pass an oauth_token, because it's cleaner. Most deployments will already have versioned tokens to enable upgrading these for internal changes, so why can't the OAuth version be contained in there too? Given the option to simplify the implementation for a API provider (Big Company, or someone who has to know how OAuth works) vs API consumer (Developer, or someone who usually just wants some data), I hope everyone agrees our focus should be the Developer.

While we (Facebook) didn't have OAuth 1.0 tokens to deal with and so don't have the same backward compatibility issues, we've already changed our tokens and introduced new ones a couple of times and this had no impact on the parameter name being used.


-Naitik

On Thu, Jul 15, 2010 at 10:51 AM, Justin Richer <jricher@mitre.org> wrote:
It was discussed before, but I don't remember there being any consensus
in the group. What are the practical reasons for not using "oauth2"
namespacing in the one place we still use namespacing? Most of what I've
heard seems to sound like "I don't like it to have a 2 on it".

I don't want to have to set up the OAuth 2 system to have to catch
failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad
OAuth 1 call should be distinguishable from the start. Also, what about
when we finally get a signed-request going? I would assume that that's
going to add back in things like oauth_signature, oauth_nonce, and the
other parameters whose absence you should filter on.

 -- Justin

On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote:
> I thought this topic had been beaten to death before. An OAuth 1.0
> protected resource request includes a variety of oauth_ parameters
> whereas OAuth 2.0 just has oauth_token.
>
>
> --David
>
>
> On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton <beaton@google.com>
> wrote:
>         On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer
>         <jricher@mitre.org> wrote:
>         > +1 on OAuth2 header, and I also want to see oauth2_token in
>         URI and form
>         > parameter methods.
>
>
>         Good point about the query parameter names needing to be
>         unambiguous.
>
>         _______________________________________________
>         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
--------------070608050108040407040000-- From bcampbell@pingidentity.com Thu Jul 15 16:05: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 9889F3A67D7 for ; Thu, 15 Jul 2010 16:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.635 X-Spam-Level: X-Spam-Status: No, score=-5.635 tagged_above=-999 required=5 tests=[AWL=0.342, 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 Z3wzumE1RE5A for ; Thu, 15 Jul 2010 16:05:05 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by core3.amsl.com (Postfix) with SMTP id 3F0123A679F for ; Thu, 15 Jul 2010 16:05:05 -0700 (PDT) Received: from source ([209.85.161.46]) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTD+UK4mYysI+3+QcmYKltPDgTxpY1le5@postini.com; Thu, 15 Jul 2010 16:05:16 PDT Received: by fxm14 with SMTP id 14so841284fxm.5 for ; Thu, 15 Jul 2010 16:05:15 -0700 (PDT) Received: by 10.223.123.73 with SMTP id o9mr1251112far.90.1279235113400; Thu, 15 Jul 2010 16:05:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.105.135 with HTTP; Thu, 15 Jul 2010 16:04:43 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 15 Jul 2010 17:04:43 -0600 Message-ID: To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] authz code randomness (was: single use authorization codes) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 23:05:07 -0000 Okay, I'm with you. Some text guiding the more obvious (to me anyway) usage might still be useful. Something like, "If Authorization Code value is a reference to state on the server, the value MUST/SHOULD be constructed from a cryptographically strong random or pseudo-random number sequence [RFC1750] where the probability of two Authorization Code values being identical is less than or equal to 2^(-160)." It's not as clean the previous text but still maybe useful. I'm guessing you don't want any language restricting the length of the code? Though there is some practical limit due to the URL length in the 302 (I think it has to be a redirect). On Thu, Jul 15, 2010 at 3:30 PM, Brian Eaton wrote: > On Thu, Jul 15, 2010 at 2:16 PM, Brian Campbell > wrote: >> I must admit to never having considered the authz code as anything but >> a random string as a reference that must be resolved. =A0Can you expand >> on your thinking a bit, if only to enlighten me? >> >> Are you thinking of embedding what would be the entire access token >> response to the eventual authorization_code grant type request inside >> the access token itself and encrypting and/or singing it? > > Yes. > > The oauth2 authorization code and the SAML artifact are similar in > that they end up creating this pattern: > > user in location A creates some value > value is transferred to location B > server in location B resolves value > value expires > > If A and B are geographically distant, you end up having to replicate > rapidly changing state. =A0that's expensive, and not terribly useful. > > If you use a stateless implementation (e.g. authorization code is a > signed blob containing the client-id, the user-id, the list of scopes > granted, a timestamp, and a hash of the callback URL) things are much > more efficient. =A0The code is a bit longer. > > Cheers, > Brian > From eran@hueniverse.com Thu Jul 15 16:07:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02ABF3A6BB0 for ; Thu, 15 Jul 2010 16:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 h6111+K0J2Ys for ; Thu, 15 Jul 2010 16:07:10 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id A344F3A69D5 for ; Thu, 15 Jul 2010 16:07:10 -0700 (PDT) Received: (qmail 3293 invoked from network); 15 Jul 2010 23:07:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jul 2010 23:07:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 15 Jul 2010 16:07:21 -0700 From: Eran Hammer-Lahav To: Brian Campbell Date: Thu, 15 Jul 2010 16:07:07 -0700 Thread-Topic: [OAUTH-WG] authz code randomness (was: single use authorization codes) Thread-Index: AcskcnpNwS1WjdkGRXWOPwGsF+2V0g== Message-ID: <89B2A6B3-B205-4860-9366-E32CC91F8000@hueniverse.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] authz code randomness (was: single use authorization codes) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 23:07:12 -0000 No normative language needed. Security consideration is the right approach.= =20 EHL On Jul 15, 2010, at 19:05, "Brian Campbell" wr= ote: > Okay, I'm with you. Some text guiding the more obvious (to me anyway) > usage might still be useful. Something like, >=20 > "If Authorization Code value is a reference to state on the server, > the value MUST/SHOULD be constructed from a cryptographically strong > random or pseudo-random number sequence [RFC1750] where the > probability of two Authorization Code values being identical is less > than or equal to 2^(-160)." >=20 > It's not as clean the previous text but still maybe useful. >=20 > I'm guessing you don't want any language restricting the length of the > code? Though there is some practical limit due to the URL length in > the 302 (I think it has to be a redirect). >=20 >=20 >=20 > On Thu, Jul 15, 2010 at 3:30 PM, Brian Eaton wrote: >> On Thu, Jul 15, 2010 at 2:16 PM, Brian Campbell >> wrote: >>> I must admit to never having considered the authz code as anything but >>> a random string as a reference that must be resolved. Can you expand >>> on your thinking a bit, if only to enlighten me? >>>=20 >>> Are you thinking of embedding what would be the entire access token >>> response to the eventual authorization_code grant type request inside >>> the access token itself and encrypting and/or singing it? >>=20 >> Yes. >>=20 >> The oauth2 authorization code and the SAML artifact are similar in >> that they end up creating this pattern: >>=20 >> user in location A creates some value >> value is transferred to location B >> server in location B resolves value >> value expires >>=20 >> If A and B are geographically distant, you end up having to replicate >> rapidly changing state. that's expensive, and not terribly useful. >>=20 >> If you use a stateless implementation (e.g. authorization code is a >> signed blob containing the client-id, the user-id, the list of scopes >> granted, a timestamp, and a hash of the callback URL) things are much >> more efficient. The code is a bit longer. >>=20 >> Cheers, >> Brian >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Thu Jul 15 16: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 B64583A6BB5 for ; Thu, 15 Jul 2010 16:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWAHp4qlaQMI for ; Thu, 15 Jul 2010 16:10:46 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by core3.amsl.com (Postfix) with ESMTP id D98623A6AD6 for ; Thu, 15 Jul 2010 16:10:45 -0700 (PDT) Received: from p4ffd0e52.dip.t-dialin.net ([79.253.14.82] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OZXZv-0003Tb-8Y; Fri, 16 Jul 2010 01:10:55 +0200 Message-ID: <4C3F957B.80200@lodderstedt.net> Date: Fri, 16 Jul 2010 01:10:51 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Christian_St=FCbner?= References: <8c60f06bb60829df8380bb91a353b40f-EhVcWl5FQQVCCQEbN11YFl1ccR9UVl1BW0gqA1ZfR0JcVkYJXlxoA1BVMl5dRkwAX15ZR1k=-webmailer2@server02.webmailer.hosteurope.de> In-Reply-To: <8c60f06bb60829df8380bb91a353b40f-EhVcWl5FQQVCCQEbN11YFl1ccR9UVl1BW0gqA1ZfR0JcVkYJXlxoA1BVMl5dRkwAX15ZR1k=-webmailer2@server02.webmailer.hosteurope.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: 141509 Cc: OAuth-WG Subject: Re: [OAUTH-WG] I-D: multiple access tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 23:10:48 -0000 Am 15.07.2010 16:27, schrieb Christian Stbner: > Torsten, > > I came across your I-D when looking for a way to distinguish between > different protected resources. > > Just some remarks and questions: > o In 3.1. I suppose your example request is missing the service_id, right? > Yepp. > o 3.4. Replace server_id by service_id and you comply with the rest of the > document. > ok. > After all, your approach seems feasible but overly complicated to me. I > wouldn't want different 'modes' in the protocol and think we should go the > whole way by only offering the 'multiple tokens mode'. In single service > environments one could simply define one single service but still use > mechanisms capable of supporting multiple service. Don't you think? > > I intended to not change the API for single server environments. That's why it happend to become more complicated for multi-server environments. From the thread about "resource server id needed?" I see consensus that scopes should be used for representing resource server ids instead of a dedicated parameter. This would help to simplify the I-D, given we can find consensus on a scope syntax. > However I'm much in favor of the idea to support multiple PRs. If the > others decide your I-D is the way to go - I'm fine with it. > thank you for your feedback and the ideas. regards, Torsten. > Regard, > Christian > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From beaton@google.com Thu Jul 15 16:36: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 DA28F3A6867 for ; Thu, 15 Jul 2010 16:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=0.075, 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 6VGdSeZDMNbW for ; Thu, 15 Jul 2010 16:36:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D69693A67E5 for ; Thu, 15 Jul 2010 16:36:06 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o6FNaGGb008142 for ; Thu, 15 Jul 2010 16:36:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279236977; bh=N5jKrK2yGrSHrN8szvQfgf0bGpg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=G8lR9ndyIAFFtWtk8cCznQsS26avCd4Hr25HfbkMIaiYWo320FY5iHPwFkac+zlcb ErShbYk7JFt6PSVAJ0nng== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=WZgQG91LpX8WMiqobGLAyndUrN5fddu94gg1mhgoYP3VYaNFjEbzi13MmLFjCXzzI 8t1VHVHv1AK6L3uV09GZg== Received: from pvd12 (pvd12.prod.google.com [10.241.209.204]) by wpaz9.hot.corp.google.com with ESMTP id o6FNaFaq028570 for ; Thu, 15 Jul 2010 16:36:15 -0700 Received: by pvd12 with SMTP id 12so720429pvd.31 for ; Thu, 15 Jul 2010 16:36:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.207.9 with SMTP id e9mr166665wfg.143.1279236975057; Thu, 15 Jul 2010 16:36:15 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Thu, 15 Jul 2010 16:36:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Jul 2010 16:36:14 -0700 Message-ID: From: Brian Eaton To: Brian Campbell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth Subject: Re: [OAUTH-WG] authz code randomness (was: single use authorization codes) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 23:36:07 -0000 On Thu, Jul 15, 2010 at 4:04 PM, Brian Campbell wrote: > I'm guessing you don't want any language restricting the length of the > code? =A0Though there is some practical limit due to the URL length in > the 302 (I think it has to be a redirect). There are certain practical limits, but I think there is still blood on the specification from the last time normative language was discussed. From naitiks@gmail.com Thu Jul 15 16: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 447013A6982 for ; Thu, 15 Jul 2010 16:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 ygVz5eK4m4iW for ; Thu, 15 Jul 2010 16:37:57 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id AA9773A67E5 for ; Thu, 15 Jul 2010 16:37:57 -0700 (PDT) Received: by iwn38 with SMTP id 38so1590367iwn.31 for ; Thu, 15 Jul 2010 16:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=FU3BgveGKero04vn8JLTD+gr0ETYMzeJmMHEBQya7mI=; b=SmsROUCA9U1EX5ckrIgO/Spz+SldoStDzgY6xoCq6eSnIA/bhmGxDcYKRVlpJAuNm7 T6yZCP5jePnj9dX30oBe4WmvJhdgKe/1MbO05A+Lk4g5bzvv+l9Hv/2gqjPYtc+klTJX S+7t5rFHT5BMV9CV/KtVSqYjLQxRt1ye8tztw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=v/QhT4AGtRmcmnpvkem94UY/T4qymHufZO3HgSbgK9dz25ZOrBWdvQ77+74bATSdqV 7epBgRwrUWnZPD69KtVhjE00BWU3HmzkBJ+hMaP8Vlxk7IX/OQM/MXFkMcDCHWjiMRTK WQQXkBmZq5XTHgDvwkEVSkYy2KSQa3ZyN2pd4= Received: by 10.231.30.129 with SMTP id u1mr21191489ibc.63.1279237084216; Thu, 15 Jul 2010 16:38:04 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.231.159.193 with HTTP; Thu, 15 Jul 2010 16:37:44 -0700 (PDT) In-Reply-To: <4C3F921E.7040304@lodderstedt.net> References: <1279205969.18579.55.camel@localhost.localdomain> <1279216291.18579.61.camel@localhost.localdomain> <4C3F921E.7040304@lodderstedt.net> From: Naitik Shah Date: Thu, 15 Jul 2010 16:37:44 -0700 X-Google-Sender-Auth: ehn0wvwL82JpHjs26VOWYWYC82k Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=00032557317efd0030048b759723 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 23:37:59 -0000 --00032557317efd0030048b759723 Content-Type: text/plain; charset=UTF-8 The formats for 1.0 and 2.0 are sufficiently different that it is possible to unambiguously figure out what version is being used. -Naitik On Thu, Jul 15, 2010 at 3:56 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > where is the relation between token version and HTTP authentication scheme > version? > > regards, > Torsten. > > Am 15.07.2010 23:34, schrieb Naitik Shah: > > I though we'd come to a decision on the versioning too :) IMHO, it's better > to push this burden of versioning into the token itself if necessary. I > think it's better from a developers perspective to pass an oauth_token, > because it's cleaner. Most deployments will already have versioned tokens to > enable upgrading these for internal changes, so why can't the OAuth version > be contained in there too? Given the option to simplify the implementation > for a API provider (Big Company, or someone who has to know how OAuth works) > vs API consumer (Developer, or someone who usually just wants some data), I > hope everyone agrees our focus should be the Developer. > > While we (Facebook) didn't have OAuth 1.0 tokens to deal with and so > don't have the same backward compatibility issues, we've already changed our > tokens and introduced new ones a couple of times and this had no impact on > the parameter name being used. > > > -Naitik > > On Thu, Jul 15, 2010 at 10:51 AM, Justin Richer wrote: > >> It was discussed before, but I don't remember there being any consensus >> in the group. What are the practical reasons for not using "oauth2" >> namespacing in the one place we still use namespacing? Most of what I've >> heard seems to sound like "I don't like it to have a 2 on it". >> >> I don't want to have to set up the OAuth 2 system to have to catch >> failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad >> OAuth 1 call should be distinguishable from the start. Also, what about >> when we finally get a signed-request going? I would assume that that's >> going to add back in things like oauth_signature, oauth_nonce, and the >> other parameters whose absence you should filter on. >> >> -- Justin >> >> On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote: >> > I thought this topic had been beaten to death before. An OAuth 1.0 >> > protected resource request includes a variety of oauth_ parameters >> > whereas OAuth 2.0 just has oauth_token. >> > >> > >> > --David >> > >> > >> > On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton >> > wrote: >> > On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer >> > wrote: >> > > +1 on OAuth2 header, and I also want to see oauth2_token in >> > URI and form >> > > parameter methods. >> > >> > >> > Good point about the query parameter names needing to be >> > unambiguous. >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > --00032557317efd0030048b759723 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The formats for 1.0 and 2.0 are=C2=A0sufficiently=C2=A0different that it is= possible to=C2=A0unambiguously=C2=A0figure out what version is being used.=


-Naitik

On Thu, Jul 15, 2010 at 3:56 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=20
where is the relation between token version and HTTP authentication scheme version?

regards,
Torsten.

Am 15.07.2010 23:34, schrieb Naitik Shah:
I though we'= ;d come to a decision on the=C2=A0versioning=C2=A0too :) IMHO, it's better to push this burden of=C2=A0versioning into the token itself if necessary. I think it's better from a developers perspective to pass an oauth_token, because it's cleaner. Most deployments will already have versioned tokens to enable upgrading these for internal changes, so why can't the OAuth version be contained in there too? Given the option to simplify the implementation for a API provider (Big Company, or someone who has to know how OAuth works) vs API consumer (Developer, or someone who usually just wants some data), I hope everyone agrees our focus should be the Developer.

While we (Facebook) didn't have OAuth 1.0 tokens to deal with and so don't have the same backward compatibility issues, we've alr= eady changed our tokens and introduced new ones a couple of times and this had no impact on the parameter name being used.


-Naitik

On Thu, Jul 15, 2010 at 10:51 AM, Justin Richer <jricher@mitre.org> wrote:
It was discussed before, but I don't remember there being any consensus in the group. What are the practical reasons for not using "oauth2&quo= t;
namespacing in the one place we still use namespacing? Most of what I'v= e
heard seems to sound like "I don't like it to have a 2 on it"= .

I don't want to have to set up the OAuth 2 system to have to catch
failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad
OAuth 1 call should be distinguishable from the start. Also, what about
when we finally get a signed-request going? I would assume that that's<= br> going to add back in things like oauth_signature, oauth_nonce, and the
other parameters whose absence you should filter on.

=C2=A0-- Justin

On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote:
> I thought this topic had been beaten to death before. An OAuth 1.0
> protected resource request includes a variety of oauth_ parameters
> whereas OAuth 2.0 just has oauth_token.
>
>
> --David
>
>
> On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton <beaton@google.com>
> wrote:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jul 15, 2010 at 7:59 AM, Justin Ri= cher
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <jricher@mitre.org> wrote:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 > +1 on OAuth2 header, and I also want = to see oauth2_token in
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 URI and form
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 > parameter methods.
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Good point about the query parameter names= needing to be
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 unambiguous.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________= _____
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth mailing list
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth@ietf.org
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/oauth=
>
>
>


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


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

--00032557317efd0030048b759723-- From wmills@yahoo-inc.com Thu Jul 15 16:54: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 B4DFB3A6833 for ; Thu, 15 Jul 2010 16:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.358 X-Spam-Level: X-Spam-Status: No, score=-17.358 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls0pV1Dpa465 for ; Thu, 15 Jul 2010 16:54:23 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 437E03A67E5 for ; Thu, 15 Jul 2010 16:54:23 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6FNrpqI062664; Thu, 15 Jul 2010 16:53:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=ktK9+18R2QfQ34MYfIpZRLI8qSpaJ7fVPfKYrEGwu/h0VUYrcceGniL+SbSdA96M Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 16:53:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2478.F93E883A" Date: Thu, 15 Jul 2010 16:53:50 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6CF0@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] OAuth vs OAuth2 in Authorization header Thread-Index: Acskdv6drazdAvkkTnSiqx+KYenAIQAAc1Ng References: <1279205969.18579.55.camel@localhost.localdomain> <1279216291.18579.61.camel@localhost.localdomain> <4C3F921E.7040304@lodderstedt.net> From: "William Mills" To: "Naitik Shah" , "Torsten Lodderstedt" X-OriginalArrivalTime: 15 Jul 2010 23:53:51.0044 (UTC) FILETIME=[F97AC840:01CB2478] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth vs OAuth2 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: Thu, 15 Jul 2010 23:54:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2478.F93E883A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Sure, but it's not easy to early branch, you have to actually parse the whole header. It's also fragile if extensions are not careful. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Naitik Shah Sent: Thursday, July 15, 2010 4:38 PM To: Torsten Lodderstedt Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth vs OAuth2 in Authorization header =09 =09 The formats for 1.0 and 2.0 are sufficiently different that it is possible to unambiguously figure out what version is being used.=20 -Naitik =09 =09 On Thu, Jul 15, 2010 at 3:56 PM, Torsten Lodderstedt wrote: =09 where is the relation between token version and HTTP authentication scheme version? =09 regards, Torsten. =09 Am 15.07.2010 23:34, schrieb Naitik Shah:=20 I though we'd come to a decision on the versioning too :) IMHO, it's better to push this burden of versioning into the token itself if necessary. I think it's better from a developers perspective to pass an oauth_token, because it's cleaner. Most deployments will already have versioned tokens to enable upgrading these for internal changes, so why can't the OAuth version be contained in there too? Given the option to simplify the implementation for a API provider (Big Company, or someone who has to know how OAuth works) vs API consumer (Developer, or someone who usually just wants some data), I hope everyone agrees our focus should be the Developer.=20 While we (Facebook) didn't have OAuth 1.0 tokens to deal with and so don't have the same backward compatibility issues, we've already changed our tokens and introduced new ones a couple of times and this had no impact on the parameter name being used. -Naitik =09 =09 On Thu, Jul 15, 2010 at 10:51 AM, Justin Richer wrote: =09 It was discussed before, but I don't remember there being any consensus in the group. What are the practical reasons for not using "oauth2" namespacing in the one place we still use namespacing? Most of what I've heard seems to sound like "I don't like it to have a 2 on it". =09 I don't want to have to set up the OAuth 2 system to have to catch failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad OAuth 1 call should be distinguishable from the start. Also, what about when we finally get a signed-request going? I would assume that that's going to add back in things like oauth_signature, oauth_nonce, and the other parameters whose absence you should filter on. =09 -- Justin =09 On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote: > I thought this topic had been beaten to death before. An OAuth 1.0 > protected resource request includes a variety of oauth_ parameters > whereas OAuth 2.0 just has oauth_token. > > > --David > > > On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton > wrote: > On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer > wrote: > > +1 on OAuth2 header, and I also want to see oauth2_token in > URI and form > > parameter methods. > > > Good point about the query parameter names needing to be > unambiguous. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > =09 =09 =09 _______________________________________________ OAuth mailing list OAuth@ietf.org =09 https://www.ietf.org/mailman/listinfo/oauth =09 =09 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------_=_NextPart_001_01CB2478.F93E883A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Sure, but it's not easy to early branch, you have = to actually=20 parse the whole header.  It's also fragile if extensions are not=20 careful.

From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] On Behalf Of Naitik=20 Shah
Sent: Thursday, July 15, 2010 4:38 PM
To: = Torsten=20 Lodderstedt
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG]=20 OAuth vs OAuth2 in Authorization header

The formats for 1.0 and 2.0 = are sufficiently different=20 that it is possible to unambiguously figure out what version = is=20 being used.


-Naitik

On Thu, Jul 15, 2010 at 3:56 PM, Torsten = Lodderstedt=20 <torsten@lodderstedt.net>=20 wrote:
where is the relation = between token=20 version and HTTP authentication scheme=20 version?

regards,
Torsten.

Am 15.07.2010 23:34, = schrieb=20 Naitik Shah:=20
I though we'd come to a decision on=20 the versioning too :) IMHO, it's better to push this = burden=20 of versioning into the token itself if necessary. I think = it's better=20 from a developers perspective to pass an oauth_token, because it's = cleaner. Most deployments will already have versioned tokens to = enable=20 upgrading these for internal changes, so why can't the OAuth = version be=20 contained in there too? Given the option to simplify the = implementation=20 for a API provider (Big Company, or someone who has to know how = OAuth=20 works) vs API consumer (Developer, or someone who usually just = wants some=20 data), I hope everyone agrees our focus should be the Developer.=20

While we (Facebook) didn't have OAuth 1.0 tokens to deal with = and so=20 don't have the same backward compatibility issues, we've already = changed=20 our tokens and introduced new ones a couple of times and this had = no=20 impact on the parameter name being used.


-Naitik

On Thu, Jul 15, 2010 at 10:51 AM, Justin = Richer=20 <jricher@mitre.org> wrote:
It was discussed before, but I don't remember = there=20 being any consensus
in the group. What are the practical = reasons for=20 not using "oauth2"
namespacing in the one place we still use=20 namespacing? Most of what I've
heard seems to sound like "I = don't=20 like it to have a 2 on it".

I don't want to have to set = up the=20 OAuth 2 system to have to catch
failed cases of the OAuth 1 = protocol.=20 A good OAuth 2 call and a bad
OAuth 1 call should be = distinguishable=20 from the start. Also, what about
when we finally get a = signed-request=20 going? I would assume that that's
going to add back in things = like=20 oauth_signature, oauth_nonce, and the
other parameters whose = absence=20 you should filter on.

 --=20 Justin

On Thu, 2010-07-15 at 13:37 -0400, David Recordon=20 wrote:
> I thought this topic had been beaten to death = before. An=20 OAuth 1.0
> protected resource request includes a variety = of=20 oauth_ parameters
> whereas OAuth 2.0 just has=20 oauth_token.
>
>
> = --David
>
>
> On=20 Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton <beaton@google.com>
> wrote:
> =  =20       On Thu, Jul 15, 2010 at 7:59 AM, Justin=20 Richer
>         <jricher@mitre.org>=20 wrote:
>         > +1 on OAuth2 = header, and=20 I also want to see oauth2_token in
>       =  =20 URI and form
>         > parameter=20 methods.
>
>
>         = Good point=20 about the query parameter names needing to be
>   =  =20     unambiguous.
>
>       =  =20 _______________________________________________
>   =  =20     OAuth mailing list
>       =   OAuth@ietf.org
>=20         https://www.ietf.org/mailman/listinfo/oauth
>>
>


_______________________________________________=
OAuth=20 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
  =

<= /DIV> ------_=_NextPart_001_01CB2478.F93E883A-- From sakimura@gmail.com Thu Jul 15 17:09: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 9CC273A6893 for ; Thu, 15 Jul 2010 17:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 x7gFlI7K0xcI for ; Thu, 15 Jul 2010 17:09:49 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 6AC553A67EE for ; Thu, 15 Jul 2010 17:09:49 -0700 (PDT) Received: by pwj1 with SMTP id 1so739828pwj.31 for ; Thu, 15 Jul 2010 17:09:57 -0700 (PDT) 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=5qS/xNYUg6imFYQwcHzZibmgtECniJl2WiuUpJc20OU=; b=SuTpbCkiLzLnldM+7zSBnyx3vc8qu29ts/bJIzQRNzcaTWTROBr6mp2u+nBbMqdILV BXHNTtEXc6ebrwb9ulXdCSV4f9/OMbfRnzzJ79LrFqCB9IREmfWeWGvL0dTPcSyCy1SX Ww6UuCi6tZQu1ZzqDM4N7EREVafXPoXCOtqlc= 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=ppw6/lESlojNSpNABO0CLUco9XhCMrJ97PaH2h4FsVR3uoCamW+UzpXlgYo1vtCQFE DmB1GQF0ucDbw163ITsEhdxkrxRUCPqM9DP7U0vS/a7TfqX0gGdbE+h7tyS4c1ac4Ue1 /uDvSZpJL4J/7FQbwpaqC4R8BafQFED/yqNS8= Received: by 10.114.39.7 with SMTP id m7mr337838wam.92.1279238997298; Thu, 15 Jul 2010 17:09:57 -0700 (PDT) Received: from [126.251.161.250] (pw126251161250.11.tss.panda-world.ne.jp [126.251.161.250]) by mx.google.com with ESMTPS id x9sm12236909waj.15.2010.07.15.17.09.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Jul 2010 17:09:54 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <99AAAB32-624D-4C33-A9D4-D0A6A6F643FC@gmail.com> X-Mailer: iPhone Mail (8A293) From: Nat Date: Fri, 16 Jul 2010 09:10:18 +0900 To: Brian Eaton Cc: OAuth WG Subject: Re: [OAUTH-WG] return to draft 6 spec org? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 00:09:53 -0000 As I see, the current draft is half way towards the complete modularization.= It has abstracted what parameters are needed for each end points from vario= us flows but failed to stop there and included how they are to be passed as w= ell. IMHO, how they are passed is the profile/binding issue and all these la= nguage should be removed and moved to profile specs.=20 =3Dnat @ Tokyo via iPhone On 2010/07/15, at 14:32, Brian Eaton wrote: > On Tue, Jul 13, 2010 at 8:11 AM, Eran Hammer-Lahav w= rote: >> - client credentials information was always problematic because people >> expressed interest in using it with pre-arranged authorizations, in which= >> case, the client may be acting on behalf of an end-user. > ... >> I suggested adding actual profiles to the spec, which would accomplish wh= at >> your want to see "restored". However it is not clear to me how to name th= ese >> and how to guide developers when to use them. > ... >=20 > I've been giving some thought to this problem. >=20 > As far as I can tell, here is what has happened. >=20 > 1) several people have gotten together and put together a > tightly-specified proposal to meet a particular use case > 2) that's gotten added > 3) others have chimed in with slight modifications to meet slightly > different use cases > 4) that's gotten added > 5) step 3 and 4 repeat for a while. > 6) the detailed proposal written in step 1 and 2 has gotten screwed up >=20 > We haven't gotten to step 7 yet, but I'm pretty sure it involves > non-interoperable implementations. >=20 > I think the problem here is step 4. Rather than making everything > optional so we can meet every possible use case, we need to start > telling people to go write up new profiles to meet their use cases. >=20 > Given the choice between two tightly specified protocol flows and a > single vague protocol flow, we should prefer tightly specified. >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From balfanz@google.com Thu Jul 15 17:29: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 709BF3A6804 for ; Thu, 15 Jul 2010 17:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.476 X-Spam-Level: X-Spam-Status: No, score=-105.476 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_42=1, 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 MBjRIzlQyS6e for ; Thu, 15 Jul 2010 17:29:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 4BC753A67E5 for ; Thu, 15 Jul 2010 17:29:29 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o6G0Td59011943 for ; Thu, 15 Jul 2010 17:29:39 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279240180; bh=sYRGlu5ymtgnzvZCYKHedDBzVpw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=U3L+Jze/bm0twfvbrvuufqaVFdfcekUeIlShI6pJrn2Px30V3XDbHEczGClZdLRvN Q6pWSHANJmcqGLlxXSkUA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=WDG8+OOJnlhtSlZ2XLxSOnC2fhJmYWeBMFWv1cXw7N4EGOOD/kM9gZoZb4hqPkaRd +xQXBHTr0a2UPx+g2SJ6Q== Received: from iwn42 (iwn42.prod.google.com [10.241.68.106]) by hpaq1.eem.corp.google.com with ESMTP id o6G0TbKc015560 for ; Thu, 15 Jul 2010 17:29:37 -0700 Received: by iwn42 with SMTP id 42so1455298iwn.26 for ; Thu, 15 Jul 2010 17:29:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.191.74 with SMTP id dl10mr11711ibb.157.1279240176877; Thu, 15 Jul 2010 17:29:36 -0700 (PDT) Received: by 10.231.130.9 with HTTP; Thu, 15 Jul 2010 17:29:36 -0700 (PDT) In-Reply-To: <30A5879D-7476-468B-8280-72691D7FE73B@gmail.com> References: <30A5879D-7476-468B-8280-72691D7FE73B@gmail.com> Date: Thu, 15 Jul 2010 17:29:36 -0700 Message-ID: From: Dirk Balfanz To: Dick Hardt Content-Type: multipart/alternative; boundary=0016367d62985342ae048b765012 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 00:29:31 -0000 --0016367d62985342ae048b765012 Content-Type: text/plain; charset=ISO-8859-1 Hi Dick, you're right - after actually reading the paper :-), I agree that if you have both sender and receiver in your payload, the order (of encrypting and signing) doesn't seem to matter. I'm still hesitant, though, to optimize for the encryption use case now (even though I do believe it will be important down the road). If I understand correctly, then the envelope would remain unencrypted. What goes in there? key_id? audience? issuer? timestamp? Do we know whether those things can always remain unencrypted for the use cases we (vaguely) envision? Rather than guessing what would remain unencrypted, and what would be encrypted (which I would have to decide today by specifying what goes into the envelope and what doesn't), I think we should just spec out the unencrypted version today, and spec out the encrypted version later when we get to that bridge, taking care of the issues you brought up, like not double-base64-encoding, etc. Dirk. On Fri, Jul 9, 2010 at 4:45 PM, Dick Hardt wrote: > Hi Dirk > > Responding to this now that you are back. > > From: > http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > > (which is the whitepaper talking contrasting "encrypt-then-sign" and > "sign-then-encrypt") > > The simple solution seems to be to include both sender and recipient in the > plain text. > > At first glance your proposal of: > > encrypted_token = encryption(JSON_Token) || "." || envelope > envelope = base64(JSON(everything you need to know to decrypt)) > > This seems to work - I am unsure where the signature is. Ideally you > encrypt the binary of the signature rather than the base64url version. > > Ideally the JSON_Token would also have an envelope so that the same code > could look at the envelope to decide what to do with it regardless of if it > was encrypted or not. > > Perhaps the first string would always be an envelope that would contain > everything to either decrypt or verify the payload? > > -- Dick > > On 2010-06-22, at 10:57 PM, Dirk Balfanz wrote: > > Hi Dick, > > interesting point about encrypted payloads. > > People more cryptographically-inclined than me might want to chime in, but > I do seem to remember that there is a "correct" choice among the > "encrypt-then-sign" and "sign-then-encrypt" alternatives. A quick search > seems to suggest that the latter is what you want: > https://www.pluralsight-training.net/community/blogs/craig/archive/2003/06/30/837.aspx > . > > So I would suggest that encrypted payloads are implemented as an encryption > of a JSON Token, as in: > > encrypted_token = encryption(JSON_Token) || "." || envelope > envelope = base64(JSON(everything you need to know to decrypt)) > > What do you think? > > Dirk. > > > On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt wrote: > >> Thanks for writing this up Dirk. >> >> I would suggest that the token be: >> >> payload "." envelope "." signature >> >> This enables the payload to be encrypted and independent from the >> envelope. >> >> Token signing, verification, encryption and decryption code can then be >> generic and not understand the payload of the token. >> >> I would only include issuer, key_id and alg in the envelope. >> >> Audience, scope, nonce, and validation time information etc. would be in >> the payload. >> >> -- Dick >> >> On 2010-06-21, at 12:04 AM, Dirk Balfanz wrote: >> >> Hi guys, >> >> I think I owe the list a proposal for signatures. >> >> I wrote something down that liberally borrows ideas from Magic Signatures, >> SWT , and (even the name >> from) JSON Web Tokens >> . >> >> Here is a short document (called "JSON Tokens") that just explains how to >> sign something and verify the signature: >> >> http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 >> >> Here is an extension of JSON Tokens that can be used for signed OAuth >> tokens: >> >> http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU >> >> Here is a different extension of JSON Tokens that can be used for 2-legged >> flows. The idea is that this could be used as a drop-in replacement for SAML >> assertions in the OAuth2 assertion flow: >> >> http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc >> >> I also have started to write some codeto implement this as a proof-of-concept. >> >> Thoughts? Comments? >> >> Dirk. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > --0016367d62985342ae048b765012 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dick,=A0

you're right - after actually reading th= e paper :-), I agree that if you have both sender and receiver in your payl= oad, the order (of encrypting and signing) doesn't seem to matter.

I'm still hesitant, though, to optimize for the enc= ryption use case now (even though I do believe it will be important down th= e road). If I understand correctly, then the envelope would remain unencryp= ted. What goes in there? key_id? audience? issuer? timestamp? Do we know wh= ether those things can always remain unencrypted for the use cases we (vagu= ely) envision?

Rather than guessing what would remain unencrypted, and= what would be encrypted (which I would have to decide today by specifying = what goes into the envelope and what doesn't), I think we should just s= pec out the unencrypted version today, and spec out the encrypted version l= ater when we get to that bridge, taking care of the issues you brought up, = like not double-base64-encoding, etc.

Dirk.

On Fri, Jul 9, = 2010 at 4:45 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Dirk

Responding t= o this now that you are back.

From:

(which is the whitepaper talking contrasting "encr= ypt-then-sign" and "sign-then-encrypt")

=
The simple solution seems to be to include both sender and recipient i= n the plain text.

At first glance your proposal of:

enc= rypted_token =3D encryption(JSON_Token) || "." || envelope=A0
envelope =3D base64(JSON(every= thing you need to know to decrypt))

Th= is seems to work - I am unsure where the signature is. Ideally you encrypt = the binary of the signature rather than the base64url version.=A0

Ideally the JSON_Token would also have an envelope so t= hat the same code could look at the envelope to decide what to do with it r= egardless of if it was encrypted or not.=A0

Perhap= s the first string would always be an envelope that would contain everythin= g to either decrypt or verify the payload?

-- Dick
<= /div>

On 2010-06-22, at 10:57 PM, Dirk = Balfanz wrote:

Hi Dick,=A0

interesting point about encrypted payloads.=A0

Peo= ple more cryptographically-inclined than me might want to chime in, but I d= o seem to remember that there is a "correct" choice among the &qu= ot;encrypt-then-sign" and "sign-then-encrypt" alternatives. = A quick search seems to suggest that the latter is what you want:=A0https://www.pluralsight-training.net/com= munity/blogs/craig/archive/2003/06/30/837.aspx.=A0

So I would suggest that encrypted payloads are implemen= ted as an encryption of a JSON Token, as in:

encry= pted_token =3D encryption(JSON_Token) || "." || envelope=A0
envelope =3D base64(JSON(everything you need to know to decrypt))

What do you think?

Dirk.


On Mon, Jun 21, 2010 at= 7:43 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
Thanks f= or writing this up Dirk.

I would suggest that the token = be:

payload ".= " envelope "." signature

This enabl= es the payload to be encrypted and independent from the envelope.=A0

Token signing, verification, encryption and decryption code = can then be generic and not understand the payload of the token.=A0

I would only include issuer, key_id and alg in the envelo= pe.=A0

Audience, scope, nonce, and validation time information= etc. would be in the payload.

-- Dick
<= br>
On 2010-06-21, at 12:04 AM, Dirk Balfanz = wrote:

Hi guys,=A0

<= /div>
I think I owe the list a proposal for signatures.
I wrote something down that=A0liberally= =A0borrows ideas from Ma= gic Signatures, SWT, and (even the name from) JSON = Web Tokens.=A0

Here is a short document (called &quo= t;JSON Tokens") that just explains how to sign something and verify th= e signature:
http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0Da= Jx_SQ5Qlk_yqs_7zNAm75-FmKwNo4

Here is an extension of JSON Tokens= that can be used for signed OAuth tokens:

Here is a different extension of JSON Tokens= that can be used for 2-legged flows. The idea is that this could be used a= s a drop-in replacement for SAML assertions in the OAuth2 assertion flow:
http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0u= lhgP3He01ONlxeTwkFQV_pCoOowzc

I also have started to write some code to implement this as a proof-of-conce= pt.=A0

Thoughts? Comments?

Dirk.

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




--0016367d62985342ae048b765012-- From uidude@google.com Thu Jul 15 17:43:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FEEF3A687F for ; Thu, 15 Jul 2010 17:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.676 X-Spam-Level: X-Spam-Status: No, score=-101.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dysVR5pP3DC2 for ; Thu, 15 Jul 2010 17:43:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D4F463A6859 for ; Thu, 15 Jul 2010 17:43:37 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o6G0hmWZ018362 for ; Thu, 15 Jul 2010 17:43:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279241028; bh=zjG8krEGcrcaEHH9XLlbjo8B3p0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=fW1LeRZjRsSJ/JO2KpRmPfxNVWipbD/CAUI0/Qj7jFS7nfItYHCL+OEjgf/qI1jKd cj4gL9sl4S5mmxVYTXytQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=Xxp/Q+SUMpE3t4kMV4olhRlerUF6jeeAXr3nGvSZ6GvC74RGaML7R9xRGecos7VQG BUaz3iedi+OBl6GctTqYA== Received: from qyk9 (qyk9.prod.google.com [10.241.83.137]) by hpaq5.eem.corp.google.com with ESMTP id o6G0hkjs024347 for ; Thu, 15 Jul 2010 17:43:47 -0700 Received: by qyk9 with SMTP id 9so3627820qyk.2 for ; Thu, 15 Jul 2010 17:43:46 -0700 (PDT) Received: by 10.224.10.70 with SMTP id o6mr254523qao.72.1279241026193; Thu, 15 Jul 2010 17:43:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.217 with HTTP; Thu, 15 Jul 2010 17:43:26 -0700 (PDT) In-Reply-To: References: From: Evan Gilbert Date: Thu, 15 Jul 2010 17:43:26 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00c09f923ddaf2c9c6048b7682fe X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 00:43:40 -0000 --00c09f923ddaf2c9c6048b7682fe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Jul 15, 2010 at 6:35 AM, Eran Hammer-Lahav wro= te: > Access tokens should not be stored in plain text either since stealing > them is just like stealing a password. > Access tokens are designed to be stored in plain text in less secure environments - web browser cookie JAR, in RAM in installed apps, etc. They last only a short period, can only be used to access specific resources, can be traced back to a specific 3rd party who is granted access= , and are sent with every request. This is very similar to cookies. This is not very similar to passwords. > > As for cookies, client developers do very little to protect cookies today= . > While the theory might be similar, in practice, telling a client develope= r > this is just like a cookies doesn=92t warn them enough. > I think that's about the right message to give, actually. If you can steal the cookie on the 3rd party web site you will likely be able to access the same data as the access token (web site uses refresh token on backend to make API calls on behalf of the logged in user... which is based on the cookie that was stolen). > > EHL > > > > On 7/14/10 11:04 PM, "Evan Gilbert" wrote: > > "Password" doesn't seem to be the right analogy. You don't (or really > shouldn't) store passwords in plain text or in cookies. > > How about "cookies"? Most web developers understand that cookies are used > as a token that grants access to resources. We've also called these > tokens"API cookies" when trying to describe them internally. > > > On Tue, Jul 13, 2010 at 4:34 PM, Eran Hammer-Lahav > wrote: > > I=92m only using 2828 definition of capability, not password. > > EHL > > > > On 7/13/10 3:20 PM, "Zachary Zeltsan" http://zachary.zeltsan@alcatel-lucent.com> > wrote: > > According to the RFC 2828 an access token is rather a capability than a > password. The passwords are usually associated with the matching > identifiers, but an access token of OAuth 2.0 is used as a single credent= ial > that allows access to a protected resource. > > From RFC 2828: > $ password > > (C) A password is usually matched with a user identifier that is > explicitly presented in the authentication process, but in some > cases the identity may be implicit. > > Zachary > -----Original Message----- > From: oauth-bounces@ietf.org [ > mailto:oauth-bounces@ietf.org ] On Behalf Of Bria= n > Eaton > Sent: Tuesday, July 13, 2010 4:43 PM > To: Faynberg, Igor (Igor) > Cc: OAuth WG > Subject: Re: [OAUTH-WG] "shared symmetric secret" > > On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg > > > wrote: > > In this case, the term "capability" MUST be defined up front. The word > > "capability" seems to carry a much broader meaning than password... > > It has a standard definition we can reference. From > http://www.ietf.org/rfc/rfc2828.txt > > $ capability > (I) A token, usually an unforgeable data value (sometimes called a > "ticket") that gives the bearer or holder the right to access a > system resource. Possession of the token is accepted by a system > as proof that the holder has been authorized to access the > resource named or indicated by the token. (See: access control > list, credential, digital certificate.) > > > _______________________________________________ > 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 > > > > --00c09f923ddaf2c9c6048b7682fe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, Jul 15, 2010 at 6:35 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
Access tokens should not be stored in plain text either since stealin= g them is just like stealing a password.

Access tokens are designed to be stored in plain text i= n less secure environments - web browser cookie JAR, in RAM in installed ap= ps, etc.

They last only a short period, can only b= e used to access specific resources, can be traced back to a specific 3rd p= arty who is granted access, and are sent with every request.

This is very similar to cookies. This is not very similar to passw= ords.
=A0

As for cookies, client developers do very little to protect cookies today. = While the theory might be similar, in practice, telling a client developer = this is just like a cookies doesn=92t warn them enough.

I think that's about the right message= to give, actually. If you can steal the cookie on the 3rd party web site y= ou will likely be able to access the same data as the access token (web sit= e uses refresh token on backend to make API calls on behalf of the logged i= n user... which is based on the cookie that was stolen).
=A0

EHL



On 7/14/10 11:04 PM, "Evan Gilbert" <uidude@google.com> wrote:

"Password"= ; doesn't seem to be the right analogy. You don't (or really should= n't) store passwords in plain text or in cookies.

How about "cookies"? Most web developers understand that cookies = are used as a token that grants access to resources. We've also called = these tokens"API cookies" when trying to describe them internally= .


On Tue, Jul 13, 2010 at 4:34 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
I=92m only using 28= 28 definition of capability, not password.

EHL



On 7/13/10 3:20 PM, "Zachary Zeltsan" <zachary.zeltsan@alcatel-lu= cent.com <http://zachary.zeltsan@alcatel-lucent.com> > wrote:=

According to the RF= C 2828 an access token is rather a capability than a password. The password= s are usually associated with the matching identifiers, but an access token= of OAuth 2.0 is used as a single credential that allows access to a protec= ted resource.

>From RFC 2828:
$ password
=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0(C) A password is usually matched with a user identifier = that is
=A0=A0=A0=A0=A0=A0explicitly presented in the authentication process, but i= n some
=A0=A0=A0=A0=A0=A0cases the identity may be implicit.

Zachary
-----Original Message-----
From: oauth-bou= nces@ietf.org <http://oauth-bounces@ietf.org> =A0[mailto:oauth-bounces@ietf.org] On Beh= alf Of Brian Eaton
Sent: Tuesday, July 13, 2010 4:43 PM
To: Faynberg, Igor (Igor)
Cc: OAuth WG
Subject: Re: [OAUTH-WG] "shared symmetric secret"

On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg
<i= gor.faynberg@alcatel-lucent.com <http://igor.faynberg@alcatel-lucent.com<= /a>> > wrote:
> In this case, the term "capability" MUST be defined up front= . The word
> "capability" seems to carry a much broader meaning than pass= word...

It has a standard definition we can reference. =A0From
http://ww= w.ietf.org/rfc/rfc2828.txt

=A0=A0=A0$ capability
=A0=A0=A0=A0=A0=A0(I) A token, usually an unforgeable data value (sometimes= called a
=A0=A0=A0=A0=A0=A0"ticket") that gives the bearer or holder the r= ight to access a
=A0=A0=A0=A0=A0=A0system resource. Possession of the token is accepted by a= system
=A0=A0=A0=A0=A0=A0as proof that the holder has been authorized to access th= e
=A0=A0=A0=A0=A0=A0resource named or indicated by the token. (See: access co= ntrol
=A0=A0=A0=A0=A0=A0list, credential, digital certificate.)

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


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




--00c09f923ddaf2c9c6048b7682fe-- From balfanz@google.com Thu Jul 15 17:43:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8695B3A6893 for ; Thu, 15 Jul 2010 17:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhyXDrI2yaVv for ; Thu, 15 Jul 2010 17:43:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 09F013A6860 for ; Thu, 15 Jul 2010 17:43:38 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o6G0hnJh029912 for ; Thu, 15 Jul 2010 17:43:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279241029; bh=lD78cindvK39niqkGFKkLZXw0S4=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=b+SspwZOS205/m5BZIKY7T2NQ2J7FiF31t5UWXMxqVGSLH+GOhcT4HGvywz+BdoBt 12ZzEum14MBBnrHpmAXgg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=UFCNmXXRgkZu8u0v69Dv55EGmj1qOBTgEFpBqU4R73VeCn0WcGrFBpTBBzwOeljNy hxqqZvqPgA0RPQZdbhyRA== Received: from iwn37 (iwn37.prod.google.com [10.241.68.101]) by kpbe20.cbf.corp.google.com with ESMTP id o6G0hQQU027166 for ; Thu, 15 Jul 2010 17:43:48 -0700 Received: by iwn37 with SMTP id 37so1838228iwn.21 for ; Thu, 15 Jul 2010 17:43:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.77.155 with SMTP id g27mr12972ibk.195.1279241027988; Thu, 15 Jul 2010 17:43:47 -0700 (PDT) Received: by 10.231.130.9 with HTTP; Thu, 15 Jul 2010 17:43:47 -0700 (PDT) Date: Thu, 15 Jul 2010 17:43:47 -0700 Message-ID: From: Dirk Balfanz To: OAuth WG Content-Type: multipart/alternative; boundary=000e0cd254140e2de3048b768303 X-System-Of-Record: true Subject: [OAUTH-WG] signatures, v2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 00:43:40 -0000 --000e0cd254140e2de3048b768303 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, after reading through the feedback, we did a pass over the OAuth signature proposals. As a reminder, there are three documents: - a document (called "JSON Tokens") that just explains how to sign something and verify the signature: http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 - an extension of JSON Tokens that can be used for signed OAuth tokens: http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU - a different extension of JSON Tokens that can be used whenever the spec calls for an "assertion": http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc (When used in the assertion flow, this last token can also be used to do "2-legged" OAuth) A summary of the (scant) changes: - we spelled out what we mean by RSA-SHA256.* Ben Laurie *- can you double-check that that sounds good? - we decided on unpadded websafe-base64 throughout. - some changes to parameter names. - some small changes I might be forgetting now... As explained in my message to the previous thread, there is still no envelope in there to help with encrypted tokens (b/c we don't understand well enough what the envelopes for encrypted tokens would look like). One question: What's the deal with having the signature go first? If you can explain to me why that is a good idea, I'm happy to oblige. Cheers, Dirk & Marius. --000e0cd254140e2de3048b768303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi guys,= =A0

after readin= g through the feedback, we did a pass over the OAuth signature proposals.

As a reminde= r, there are three documents:

- a document (called "JSON Tokens") that just= explains how to sign something and verify the signature:
- an extension of JSON Tokens that can be used for signed OA= uth tokens:

- a different extension of JSON Token= s that can be used whenever the spec calls for an "assertion":
http://docs.google.com/document/pub?id=3D1s4k= jRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc
(When used in the assertion flow, this last token can also be used to = do "2-legged" OAuth)

A summary of th= e (scant) changes:

- we spelled out what we mean b= y RSA-SHA256. Ben Laurie - can you double-check that that sounds goo= d?
- we decided on unpadded websafe-base64 throughout.
- some c= hanges to parameter names.
- some small changes I might be forget= ting now...

As explained in my message to the prev= ious thread, there is still no envelope in there to help with encrypted tok= ens (b/c we don't understand well enough what the envelopes for encrypt= ed tokens would look like).=A0

One question: What's the deal with having the signa= ture go first? If you can explain to me why that is a good idea, I'm ha= ppy to oblige.

Cheers,

Dirk & Marius.

--000e0cd254140e2de3048b768303-- From naitiks@gmail.com Thu Jul 15 18:46: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 7DF8C3A6807 for ; Thu, 15 Jul 2010 18:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MW0el4bdRgAR for ; Thu, 15 Jul 2010 18:46:08 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id A54C03A63D3 for ; Thu, 15 Jul 2010 18:46:08 -0700 (PDT) Received: by pxi20 with SMTP id 20so944875pxi.31 for ; Thu, 15 Jul 2010 18:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=O29FxgqIt/bGZ0106L8LsQiutCEPP+J/cS2PB47WN8w=; b=DNrViMn15OszCcpLr/k4QLK5v81VPAEYJpBzUjs0bqtKyHE/CX77meposVPDwyOs09 CUCw5S++i4NLPjmFIfVvdIRXsS/WP9pHiFVFhzJU9bwakqI5JigS9ppw8E8CLDYN208g mKCysis5mZIA7szWwMzAHowVwre6JxYZiAnBM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=IEdME7Kre+ivjC8WuMmbdA3X6tiEizkAqAgTNvq7pZyksFPsk2CwfEIpY5LeIjFUuC scnf6HGmsCPDs7imkDalwISg2jesrXZcquIuvVkjDEjtWlT/GxITT+hchN5X74L5AqW0 frjaaMfDwV4Hxnr4HlpF7g67lSWTCjzuqmrZY= Received: by 10.142.212.2 with SMTP id k2mr323936wfg.264.1279244777256; Thu, 15 Jul 2010 18:46:17 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.142.203.12 with HTTP; Thu, 15 Jul 2010 18:45:56 -0700 (PDT) In-Reply-To: References: From: Naitik Shah Date: Thu, 15 Jul 2010 18:45:56 -0700 X-Google-Sender-Auth: IPZQQVuNqcmRek9IQ9PtBnNLu9I Message-ID: To: Dirk Balfanz Content-Type: multipart/alternative; boundary=000e0cd33196877646048b776203 Cc: OAuth WG Subject: Re: [OAUTH-WG] signatures, v2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 01:46:09 -0000 --000e0cd33196877646048b776203 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 15, 2010 at 5:43 PM, Dirk Balfanz wrote: > > One question: What's the deal with having the signature go first? If you > can explain to me why that is a good idea, I'm happy to oblige. > > When we were talking about base64url or not, putting the signature before the dot meant it was okay for a dot to show up in the payload in an unencoded fashion, which was coupled with the fact that lsplit or split with a limit are more common in standard libraries based on some rough exploration. But that's not relevant anymore. Is there a downside to having the signature first? I like it better because the signature length is predictable, meaning the first X chars will be the sig, and then the X+1 char will be the dot. I like the consistency it provides :) -Naitik --000e0cd33196877646048b776203 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 15, 2010 at 5:43 PM, Dirk Balfanz <balfanz@google.com> wrote:
=

One question: What's the deal with havin= g the signature go first? If you can explain to me why that is a good idea,= I'm happy to oblige.


When we were talking about base64url or not, putting the signature before= the dot meant it was okay for a dot to show up in the payload in an unenco= ded fashion, which was coupled with the fact that lsplit or split with a li= mit are more common in standard libraries based on some rough exploration. = But that's not relevant anymore.

Is there a downside to having the signature first? I li= ke it better because the signature length is predictable, meaning the first= X chars will be the sig, and then the X+1 char will be the dot. I like the= consistency it provides :)


-Naitik
--000e0cd33196877646048b776203-- From bcampbell@pingidentity.com Thu Jul 15 20:03: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 619353A68AE for ; Thu, 15 Jul 2010 20:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.704 X-Spam-Level: X-Spam-Status: No, score=-5.704 tagged_above=-999 required=5 tests=[AWL=0.273, 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 56Dvim6TNj1e for ; Thu, 15 Jul 2010 20:03:31 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by core3.amsl.com (Postfix) with SMTP id 163F53A689C for ; Thu, 15 Jul 2010 20:03:30 -0700 (PDT) Received: from source ([209.85.161.41]) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTD/MDYQKaJtHasEhMkcJ/qy5qxIe8MUU@postini.com; Thu, 15 Jul 2010 20:03:42 PDT Received: by fxm20 with SMTP id 20so1017771fxm.14 for ; Thu, 15 Jul 2010 20:03:40 -0700 (PDT) Received: by 10.223.112.65 with SMTP id v1mr152219fap.34.1279249419244; Thu, 15 Jul 2010 20:03:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.105.135 with HTTP; Thu, 15 Jul 2010 20:03:09 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 15 Jul 2010 21:03:09 -0600 Message-ID: To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] authz code randomness (was: single use authorization codes) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 03:03:32 -0000 On Thu, Jul 15, 2010 at 5:36 PM, Brian Eaton wrote: > There are certain practical limits, but I think there is still blood > on the specification from the last time normative language was > discussed. That must have been been before my time - sorry for bringing it up again. We can put those skeletons back in the closet and move on. From dick.hardt@gmail.com Thu Jul 15 21: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 B55C33A67F0 for ; Thu, 15 Jul 2010 21:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lalJJ+BozGiU for ; Thu, 15 Jul 2010 21:19:26 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 98F7F3A6405 for ; Thu, 15 Jul 2010 21:19:26 -0700 (PDT) Received: by pvd12 with SMTP id 12so842368pvd.31 for ; Thu, 15 Jul 2010 21:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=PiyoT1E+7roKg7PNwoTPnX8e/0A2KjLvm6VIIrMxCsM=; b=dB/BFSqPjiszca2ELJEpxeaXfX9AZEGIrTKQdW4hVCxGCXoRJ+AMOs3ic7iN7bzScx 0Nxb46olV65R9dWcQ78KaDjHLGLPAWzpUnA3llaeXhmwnY0dJyNokmTNR8h4tyTnNM0N DUt0ziETqKpsoTSpyEilsdxoGEANz5MWYlCEY= 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=JLiEglyLPIqCCoEYHDmS6aZs8Rr84jwTQarUu+JtWdQuzPtTnscNWkPhtH2SyZLklm UKPA/8+xsCr33JUVj7uP6w0aB/an5Nt5REv9fvnVc0cqCbc5xP9bfG/zLmS6+z2CdKJE x08jXcraVwNVwrCvJIpg8ExpJ87s9XVsl5V7Y= Received: by 10.142.158.14 with SMTP id g14mr633452wfe.30.1279253975086; Thu, 15 Jul 2010 21:19:35 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id 33sm2120562wfg.9.2010.07.15.21.19.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Jul 2010 21:19:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-10-299061630 From: Dick Hardt In-Reply-To: Date: Thu, 15 Jul 2010 21:19:32 -0700 Message-Id: References: <30A5879D-7476-468B-8280-72691D7FE73B@gmail.com> To: Dirk Balfanz X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 04:19:28 -0000 --Apple-Mail-10-299061630 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-07-15, at 5:29 PM, Dirk Balfanz wrote: > Hi Dick,=20 >=20 > you're right - after actually reading the paper :-), I agree that if = you have both sender and receiver in your payload, the order (of = encrypting and signing) doesn't seem to matter. >=20 > I'm still hesitant, though, to optimize for the encryption use case = now (even though I do believe it will be important down the road). If I = understand correctly, then the envelope would remain unencrypted. What = goes in there? key_id? audience? issuer? timestamp? Do we know whether = those things can always remain unencrypted for the use cases we = (vaguely) envision? The envelope contains what is needed to do the crypto, regardless of it = being signature verification or decryption. That would mean algorithm = and key_id if used. Issuer would be needed if you need that to determine = the key. Audience and issuer should also be in the payload per the = paper. A library looking at the envelope would be able to decrypt the token and = check the signature or just check the signature. The idea of the = envelope is that the library only needs to look at the envelope to = decide what to do.=20 Message verification is something implementors get wrong all the time, = so the easier we make it for libraries, the more likely there will be = good libraries that people can use in different situations. >=20 > Rather than guessing what would remain unencrypted, and what would be = encrypted (which I would have to decide today by specifying what goes = into the envelope and what doesn't), I think we should just spec out the = unencrypted version today, and spec out the encrypted version later when = we get to that bridge, taking care of the issues you brought up, like = not double-base64-encoding, etc. I don't think we need to guess now at all. We don't even have to figure = out what needs to be in the envelope to do encryption. I am arguing for = an architectural approach of an envelope and a payload rather than just = a payload. (or in the case of digital signing, I am arguing for = envelope, payload and signature rather than just signature and payload) This has several benefits: 1) the payload now can be encrypted independant of envelope (encryption = inherently means there is a separate envelope -- only signing can take a = shortcut and mix envelope data with payload since the payload is clear = text) 2) we can use the same libraries in the future for all tokens 3) we have an extensibility model The benefits seem to outweigh the downside of having two JSON entities = instead of just one. In many ways, this is similar to the header and body in HTTP requests. A = separation of transport parameters from payload data has proven useful = in many other architectures and protocols. -- Dick >=20 > Dirk. >=20 > On Fri, Jul 9, 2010 at 4:45 PM, Dick Hardt = wrote: > Hi Dirk >=20 > Responding to this now that you are back. >=20 > From: > = http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html >=20 > (which is the whitepaper talking contrasting "encrypt-then-sign" and = "sign-then-encrypt") >=20 > The simple solution seems to be to include both sender and recipient = in the plain text. >=20 > At first glance your proposal of: >=20 > encrypted_token =3D encryption(JSON_Token) || "." || envelope=20 > envelope =3D base64(JSON(everything you need to know to = decrypt)) >=20 > This seems to work - I am unsure where the signature is. Ideally you = encrypt the binary of the signature rather than the base64url version.=20= >=20 > Ideally the JSON_Token would also have an envelope so that the same = code could look at the envelope to decide what to do with it regardless = of if it was encrypted or not.=20 >=20 > Perhaps the first string would always be an envelope that would = contain everything to either decrypt or verify the payload? >=20 > -- Dick >=20 > On 2010-06-22, at 10:57 PM, Dirk Balfanz wrote: >=20 >> Hi Dick,=20 >>=20 >> interesting point about encrypted payloads.=20 >>=20 >> People more cryptographically-inclined than me might want to chime = in, but I do seem to remember that there is a "correct" choice among the = "encrypt-then-sign" and "sign-then-encrypt" alternatives. A quick search = seems to suggest that the latter is what you want: = https://www.pluralsight-training.net/community/blogs/craig/archive/2003/06= /30/837.aspx.=20 >>=20 >> So I would suggest that encrypted payloads are implemented as an = encryption of a JSON Token, as in: >>=20 >> encrypted_token =3D encryption(JSON_Token) || "." || envelope=20 >> envelope =3D base64(JSON(everything you need to know to decrypt)) >>=20 >> What do you think? >>=20 >> Dirk. >>=20 >>=20 >> On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt = wrote: >> Thanks for writing this up Dirk. >>=20 >> I would suggest that the token be: >>=20 >> payload "." envelope "." signature >>=20 >> This enables the payload to be encrypted and independent from the = envelope.=20 >>=20 >> Token signing, verification, encryption and decryption code can then = be generic and not understand the payload of the token.=20 >>=20 >> I would only include issuer, key_id and alg in the envelope.=20 >>=20 >> Audience, scope, nonce, and validation time information etc. would be = in the payload. >>=20 >> -- Dick >>=20 >> On 2010-06-21, at 12:04 AM, Dirk Balfanz wrote: >>=20 >>> Hi guys,=20 >>>=20 >>> I think I owe the list a proposal for signatures. >>>=20 >>> I wrote something down that liberally borrows ideas from Magic = Signatures, SWT, and (even the name from) JSON Web Tokens.=20 >>>=20 >>> Here is a short document (called "JSON Tokens") that just explains = how to sign something and verify the signature: >>> = http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNA= m75-FmKwNo4 >>>=20 >>> Here is an extension of JSON Tokens that can be used for signed = OAuth tokens: >>> = http://docs.google.com/document/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowT= ZW8OWX9HOUU >>>=20 >>> Here is a different extension of JSON Tokens that can be used for = 2-legged flows. The idea is that this could be used as a drop-in = replacement for SAML assertions in the OAuth2 assertion flow: >>> = http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTwkF= QV_pCoOowzc >>>=20 >>> I also have started to write some code to implement this as a = proof-of-concept.=20 >>>=20 >>> Thoughts? Comments? >>>=20 >>> Dirk. >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >=20 >=20 --Apple-Mail-10-299061630 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi = Dick, 

you're right - after actually reading the = paper :-), I agree that if you have both sender and receiver in your = payload, the order (of encrypting and signing) doesn't seem to = matter.

I'm still hesitant, though, to optimize for the = encryption use case now (even though I do believe it will be important = down the road). If I understand correctly, then the envelope would = remain unencrypted. What goes in there? key_id? audience? issuer? = timestamp? Do we know whether those things can always remain unencrypted = for the use cases we (vaguely) = envision?

The envelope contains = what is needed to do the crypto, regardless of it being  signature = verification or decryption. That would mean algorithm and key_id if = used. Issuer would be needed if you need that to determine the key. = Audience and issuer should also be in the payload per the = paper.

A library looking at the envelope would = be able to decrypt the token and check the signature or just check the = signature. The idea of the envelope is that the library only needs to = look at the envelope to decide what to = do. 

Message verification is something = implementors get wrong all the time, so the easier we make it for = libraries, the more likely there will be good libraries that people can = use in different situations.


Rather than guessing what would remain unencrypted, = and what would be encrypted (which I would have to decide today by = specifying what goes into the envelope and what doesn't), I think we = should just spec out the unencrypted version today, and spec out the = encrypted version later when we get to that bridge, taking care of the = issues you brought up, like not double-base64-encoding, = etc.

I don't think we need to = guess now at all. We don't even have to figure out what needs to be in = the envelope to do encryption. I am arguing for an architectural = approach of an envelope and a payload rather than just a payload. (or in = the case of digital signing, I am arguing for envelope, payload and = signature rather than just signature and = payload)

This has several = benefits:

1) the payload now can be encrypted = independant of envelope (encryption inherently means there is a separate = envelope -- only signing can take a shortcut and mix envelope data with = payload since the payload is clear text)

2) we = can use the same libraries in the future for all = tokens

3) we have an extensibility = model

The benefits seem to outweigh the = downside of having two JSON entities instead of just = one.

In many ways, this is similar to the = header and body in HTTP requests. A separation of transport parameters = from payload data has proven useful in many other architectures and = protocols.

-- Dick


Dirk.

On Fri, Jul = 9, 2010 at 4:45 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:
Hi = Dirk

Responding to this now that you are = back.

From:

(which is the whitepaper talking contrasting = "encrypt-then-sign" and = "sign-then-encrypt")

The simple solution seems = to be to include both sender and recipient in the plain text.

At first glance your proposal of:

encrypted_token =3D = encryption(JSON_Token) || "." || envelope 
envelope =3D = base64(JSON(everything you need to know to = decrypt))

This seems to work - I am = unsure where the signature is. Ideally you encrypt the binary of the = signature rather than the base64url version. 

Ideally the JSON_Token would also have an envelope = so that the same code could look at the envelope to decide what to do = with it regardless of if it was encrypted or = not. 

Perhaps the first string would = always be an envelope that would contain everything to either decrypt or = verify the payload?

-- = Dick

On = 2010-06-22, at 10:57 PM, Dirk Balfanz wrote:

Hi Dick, 

interesting point about encrypted = payloads. 

People more = cryptographically-inclined than me might want to chime in, but I do seem = to remember that there is a "correct" choice among the = "encrypt-then-sign" and "sign-then-encrypt" alternatives. A quick search = seems to suggest that the latter is what you want: https://www.pluralsight-training.net/community/blogs/cra= ig/archive/2003/06/30/837.aspx. 

So I would suggest that encrypted payloads are = implemented as an encryption of a JSON Token, as = in:

encrypted_token =3D encryption(JSON_Token) = || "." || envelope 
envelope =3D base64(JSON(everything you need to know to = decrypt))

What do you = think?

Dirk.


On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
Thanks for writing this up = Dirk.

I would suggest that the token be:

payload = "." envelope "." signature

This enables the = payload to be encrypted and independent from the envelope. 

Token signing, verification, encryption and decryption = code can then be generic and not understand the payload of the = token. 

I would only include issuer, = key_id and alg in the envelope. 

Audience, scope, nonce, and validation time = information etc. would be in the payload.

-- = Dick

On 2010-06-21, at = 12:04 AM, Dirk Balfanz wrote:

= Hi guys, 

I think I = owe the list a proposal for signatures.

I wrote something = down that liberally = borrows ideas from = Magic Signatures, SWT, and (even the name from) JSON Web = Tokens. 

Here is a short = document (called "JSON Tokens") that just explains how to sign something = and verify the signature:
http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0Da= Jx_SQ5Qlk_yqs_7zNAm75-FmKwNo4

Here is an extension = of JSON Tokens that can be used for signed OAuth tokens:

Here is a different = extension of JSON Tokens that can be used for 2-legged flows. The idea = is that this could be used as a drop-in replacement for SAML assertions = in the OAuth2 assertion flow:
http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0u= lhgP3He01ONlxeTwkFQV_pCoOowzc

I also have started to write some code to = implement this as a proof-of-concept. 

Thoughts? = Comments?

Dirk.

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


=



= --Apple-Mail-10-299061630-- From James.H.Manger@team.telstra.com Thu Jul 15 21:21: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 A7A373A63CB for ; Thu, 15 Jul 2010 21:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, 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 uWTAYNP7rdcr for ; Thu, 15 Jul 2010 21:21:27 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 61F463A6452 for ; Thu, 15 Jul 2010 21:21:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,212,1278252000"; d="scan'208";a="6053717" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 16 Jul 2010 14:21:34 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6044"; a="4665214" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipccni.tcif.telstra.com.au with ESMTP; 16 Jul 2010 14:21:37 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 16 Jul 2010 14:21:36 +1000 From: "Manger, James H" To: Eran Hammer-Lahav , John Kemp , "oauth@ietf.org" Date: Fri, 16 Jul 2010 14:21:53 +1000 Thread-Topic: [OAUTH-WG] OAuth vs OAuth2 in Authorization header Thread-Index: AcskTQuPQEcTB0yXR/m52up+YUcDkQATLB0A Message-ID: <255B9BB34FB7D647A506DC292726F6E112662F0D3A@WSMSG3153V.srv.dir.telstra.com> References: <02D7ABE3-5B51-43B6-B7A2-6CB9AA045AAA@jkemp.net> <23375931-39B5-4267-925D-5AD5698AAF15@hueniverse.com> In-Reply-To: <23375931-39B5-4267-925D-5AD5698AAF15@hueniverse.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] OAuth vs OAuth2 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: Fri, 16 Jul 2010 04:21:28 -0000 >> What happens if a 1.0 client receives a WWW-Authenticate header >> from a 2.0 protected resource with the 'OAuth' mechanism specified? >> Might it then attempt OAuth 1 with a 2.0 token service (and thus >> just fail without being able to know what went wrong)? > There is no such thing. Since there is no discovery for 1.0, > all calls are hardcoded into the client today. > There is no 'trying things out'. There was "discovery" in OAuth 1: it was inadequate, but it was present in = the spec. RFC 5849 "OAuth 1.0", section 3.5.1 "Authorization header" defines "WWW-Authenticate: OAuth realm= =3D..." as indicating a server supports OAuth 1.0. Servers MAY indicate their support for the "OAuth" auth-scheme by returning the HTTP "WWW-Authenticate" response header field upon client requests for protected resources. As per [RFC2617], such a response MAY include additional HTTP "WWW-Authenticate" header fields: For example: WWW-Authenticate: OAuth realm=3D"http://server.example.com/" Perhaps it wasn't used much, but reusing the "OAuth" scheme to indicate sup= port for OAuth2 is incompatible. It adds human confusion, regardless of any= technical ability to distinguish OAuth 1 & 2. --=20 James Manger From dick.hardt@gmail.com Thu Jul 15 21:53: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 A9B693A684B for ; Thu, 15 Jul 2010 21:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bh5omhx4VVX3 for ; Thu, 15 Jul 2010 21:53:51 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id AE9623A687F for ; Thu, 15 Jul 2010 21:53:51 -0700 (PDT) Received: by pvd12 with SMTP id 12so856181pvd.31 for ; Thu, 15 Jul 2010 21:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=+HJqdNYKnlUzTAejBJJGZxaSQj99o2z4q0Uqnk3pfXg=; b=bbuGMEbue5YeNiKT3AAjJUq/MkLBazA3sJ55MkvfZG0O38nBCKOXOZQDSzW7GTw5Dl 5AYzO17a6y8kOEgxcu6eIWD2mma/Mv221vyPgnOM4/OVnhA7qGKlZoro6uK1I0ow2hO2 Tv3Bk5DMHcEP4Q9655NwzFA1vVGutAQJ+TeQ8= 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=VFVaTF20uG92r+JQZcUjvk55JdtrFeAkWNLpzYbgnVQ1f3H1GOPTSAcmKWNJxTdu3f eCQgPEJs8lXxMQOKeLUmHUZLEv9DergNNeYqy9C6pJR35cMPXZJIYm2ao59iuOAx0wYK 5cMC7ym79GxgF7FKRGPs0VdiR7GPjYuYpvFyQ= Received: by 10.114.95.19 with SMTP id s19mr819619wab.31.1279256040377; Thu, 15 Jul 2010 21:54:00 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id g4sm12602111wae.14.2010.07.15.21.53.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Jul 2010 21:53:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-22-301126254 From: Dick Hardt In-Reply-To: Date: Thu, 15 Jul 2010 21:53:56 -0700 Message-Id: References: To: Naitik Shah X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] signatures, v2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 04:53:52 -0000 --Apple-Mail-22-301126254 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-07-15, at 6:45 PM, Naitik Shah wrote: > On Thu, Jul 15, 2010 at 5:43 PM, Dirk Balfanz = wrote: >=20 > One question: What's the deal with having the signature go first? If = you can explain to me why that is a good idea, I'm happy to oblige. >=20 >=20 > When we were talking about base64url or not, putting the signature = before the dot meant it was okay for a dot to show up in the payload in = an unencoded fashion, which was coupled with the fact that lsplit or = split with a limit are more common in standard libraries based on some = rough exploration. But that's not relevant anymore. >=20 > Is there a downside to having the signature first? I like it better = because the signature length is predictable, meaning the first X chars = will be the sig, and then the X+1 char will be the dot. I like the = consistency it provides :) If we put the envelope first, then we know what to do with the token. = Signatures don't exist in an encrypted token. Think of the envelope like = HTTP headers. They makes sense to go first. After the envelope, I don't = have a preference between signature and payload or payload and = signature. btw: signature length is not predictable -- it is dependant on the = algorithm. *when* a different hash algorithm is used the length will = likely change. The only way to know this is to look at algorithm first. -- Dick --Apple-Mail-22-301126254 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 2010-07-15, at 6:45 PM, Naitik Shah wrote:

On Thu, Jul 15, 2010 at 5:43 PM, Dirk Balfanz <balfanz@google.com> wrote:

One question: What's the deal with having the signature go first? If you can explain to me why that is a good idea, I'm happy to oblige.


When we were talking about base64url or not, putting the signature before the dot meant it was okay for a dot to show up in the payload in an unencoded fashion, which was coupled with the fact that lsplit or split with a limit are more common in standard libraries based on some rough exploration. But that's not relevant anymore.

Is there a downside to having the signature first? I like it better because the signature length is predictable, meaning the first X chars will be the sig, and then the X+1 char will be the dot. I like the consistency it provides :)

If we put the envelope first, then we know what to do with the token. Signatures don't exist in an encrypted token. Think of the envelope like HTTP headers. They makes sense to go first. After the envelope, I don't have a preference between signature and payload or payload and signature.

btw: signature length is not predictable -- it is dependant on the algorithm. *when* a different hash algorithm is used the length will likely change. The only way to know this is to look at algorithm first.

-- Dick

--Apple-Mail-22-301126254-- From elena.lozano@rediris.es Fri Jul 16 02:02: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 A5EC33A695E for ; Fri, 16 Jul 2010 02:02:58 -0700 (PDT) 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 UkFYxRAPLHhI for ; Fri, 16 Jul 2010 02:02:57 -0700 (PDT) Received: from irisout1.rediris.es (irisout1.rediris.es [130.206.24.3]) by core3.amsl.com (Postfix) with ESMTP id 650CB3A68FD for ; Fri, 16 Jul 2010 02:02:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,213,1278280800"; d="scan'208,217";a="27931506" Received: from snail.rediris.es.6.206.130.in-addr.arpa ([130.206.6.77]) by abel.rediris.es with ESMTP/TLS/AES128-SHA; 16 Jul 2010 10:59:34 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-1-316074130 From: Elena Lozano In-Reply-To: <1EB65D29-AEFE-420F-841D-E0B69A4236E7@lodderstedt.net> Date: Fri, 16 Jul 2010 11:03:04 +0200 Message-Id: References: <2D0B937E-1222-469B-8500-227237550F94@rediris.es> <1EB65D29-AEFE-420F-841D-E0B69A4236E7@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1081) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion profile + client_secret and client_id security X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 09:02:58 -0000 --Apple-Mail-1-316074130 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 15, 2010, at 1:10 PM, Torsten Lodderstedt wrote: > Why don't you use the client secret to authenticate the application? = The spec allows you to use a BASIC authorization header for that = purpose. We hadn't thought of that, but suits perfectly to our use case! Thanks! >=20 > Regards, > Torsten. >=20 >=20 > Am 15.07.2010 um 12:54 schrieb Elena Lozano : >=20 >> Hi everyone, >>=20 >> As we adapt the RedIRIS PHP OAuth2 library[1] to the last version of = the draft we have found some issues regarding the client secret and = client id. >>=20 >> The thing is that we don't understand the security given with the = client_id and client_secret of the assertion profile. >>=20 >> The last changes on the protocol said that: >>=20 >> "the authorization server MUST verify that the >> redirection URI received matches the registered URI associated = with >> the client identifier." >>=20 >> This provides one way to perform the correct identification of the = client but doesn't work with the assertion profile. >>=20 >> In the assertion profile, we understand that the client_id is = optional and that the assertion could have the information about the = client identification.=20 >> This could happen when the assertion authorizes an application, but = in our use cases, the assertions doesn't have information about the = client application. >> This is a problem because in our request to the Auth Server we cannot = check if the application is registered correctly. We can send the = client_id in the request, but we have the same problem, because someone = can 'steal' our client id and impersonate the client.=20 >>=20 >> We think that we can solve that signing parameters in the request, = adding the client_id signature or something like this but we're not sure = that this is referred in the protocol. >>=20 >> What do you think it's better to solve this issue? >>=20 >> I don't know if i'm understanding something in a wrong way, so please = correct me if i'm wrong. >>=20 >> Thanks! >>=20 >> Elena. >>=20 >> [1] http://www.rediris.es/oauth2 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-1-316074130 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Why don't you use the client = secret to authenticate the application? The spec allows you to use a = BASIC authorization header for that = purpose.
We hadn't thought of that, but = suits perfectly to our use = case!
Thanks!

Regards,
Torsten.

Am 15.07.2010 um 12:54 schrieb Elena Lozano <elena.lozano@rediris.es>:
Hi 
   redirection URI received matches the = registered URI associated with
   the client = identifier."

This provides one way to perform = the correct identification of the client but doesn't work with the =  assertion profile.

In the assertion = profile, we understand that the client_id is optional and that the = assertion could have the information about the client = identification. 
This could happen when the assertion = authorizes an application, but in our use cases, the assertions doesn't = have information about the client application.
This is a = problem because in our request to the Auth Server we cannot check if the = application is registered correctly. We can send the client_id in the = request, but we have the same problem, because someone can 'steal' our = client id and impersonate the client. 

We = think that we can solve that signing parameters in the request, adding = the client_id signature or something like this but we're not sure that = this is referred in the protocol.

What do you = think it's better to solve this issue?

I don't = know if i'm understanding something in a wrong way, so = please correct me if i'm wrong.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail-1-316074130-- From rrichards@cdatazone.org Fri Jul 16 02:33:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32673A6897 for ; Fri, 16 Jul 2010 02:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.484 X-Spam-Level: X-Spam-Status: No, score=0.484 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FRT_BELOW2=2.154] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH+q9w0Rw5ir for ; Fri, 16 Jul 2010 02:33:35 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by core3.amsl.com (Postfix) with ESMTP id AC7F33A67B7 for ; Fri, 16 Jul 2010 02:33:35 -0700 (PDT) Received: from [67.158.171.203] (helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1OZhIZ-0000V3-Ey; Fri, 16 Jul 2010 09:33:39 +0000 Message-ID: <4C402772.1020601@cdatazone.org> Date: Fri, 16 Jul 2010 05:33:38 -0400 From: Rob Richards User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Marius Scurtescu References: <4C2C6D4A.5010401@cdatazone.org> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2DC7C5.2090009@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F108B.70504@cdatazone.org> <20100708110542.150740@gmx.net> <4C3707BD.6070201@gmx.de> <4C3E05EE.4050903@cdatazone.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP2Go-MailScanner-Information: Please contact support@smtp2go.com for more information X-SMTP2Go-MailScanner-ID: 1OZhIZ-0000V3-Ey X-SMTP2Go-MailScanner: Found to be clean X-SMTP2Go-MailScanner-From: rrichards@cdatazone.org Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 09:33:36 -0000 On 7/14/10 6:33 PM, Marius Scurtescu wrote: > On Wed, Jul 14, 2010 at 11:46 AM, Rob Richards wrote: >> Finally getting a chance to catchup and respond to this thread. >> >> Marius Scurtescu wrote: >>> See comments bellow... >>> >>> >>> On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia wrote: >>> >>>> Hallo Marius, >>>> >>>> thanks for your statement. >>>> Your idea of a migration flow is quite good and necessary. >>>> >>>> But I still doubt, if the work and effort should be investigated to spare >>>> the user from some interaction (authentication and user consent). >>>> >>> It all depends for how many users does the client have OAuth 1 tokens. >>> Asking users to re-approve will confuse them and I guess many will not >>> do it, >>> >> I think the user should not be excluded from this interaction and should be >> required to re-approve. IMO they should be involved as its also >> informational to know that the client they have previously authorized is now >> requesting new credentials under a different security scheme. The user >> should be the one to decide whether or not they want to allow this. > Why would you re-prompt the user? The only thing that really changes > is the underlying protocol, something most end users are not made > aware of. How would the new approval page be any different from the > initial one? The user granted a client access to some of its > resources, that stays the same. If the authorization server makes it > explicit on the approval page that OAuth 1 is used, then yes, a > re-approval is needed, but I don't think this normally happens. > > >> When it comes right down to it the only concrete thing I can think of when >> migrating from 1.0 to 2.0 is the need to determine which version is being >> used at the resource endpoint. For most clients moving from 1.0 to 2.0 they >> will most likely just create the next version of their client/app with 2.0 >> support and completely drop 1.0 support rather than going through any >> migration flow. > That depends on the client. If the client is a web site that has > several thousand users, and it stores OAuth 1 access tokens for all > these users, then migration totally makes sense. If the client is an > iPhone app with only one user, then maybe you are right. Even in this > case, I am sure the app would prefer not to annoy the user and just > silently move to OAuth 2. If you are the app developer and your app > has a large install base, would you risk losing even a small > percentage of those users simply because you presented them with a > confusing approval page? > > > As a user I would say yes, I want to be re-prompted or at least explicitly request the migration of my tokens rather than having something done silently, behind the scenes and unbeknownst to me. The underlying protocol has changed, whether or not I know it, and for all purposes could be the most insure protocol out there. When something this fundamental changes, I would want to have to re-authorize the application because I could just as easily at this point decline. Perhaps I went and read the changelog, the change was made known on the site, or someone discovered the change and made it public. As you can probably tell I lean way more towards the side of the user and personally think it is more responsible of the app or web site in question here to require the re-authorization and risk losing some users (if that is the case then clearly the application is not worth the users time in the first place) than to silently change the protocol on me. Rob From rrichards@cdatazone.org Fri Jul 16 02:48: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 634483A6827 for ; Fri, 16 Jul 2010 02:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FRT_BELOW2=2.154] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4M7dscjsDEl for ; Fri, 16 Jul 2010 02:48:53 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by core3.amsl.com (Postfix) with ESMTP id 6D6BE3A696B for ; Fri, 16 Jul 2010 02:48:53 -0700 (PDT) Received: from [67.158.171.203] (helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1OZhXQ-00033W-IY; Fri, 16 Jul 2010 09:49:01 +0000 Message-ID: <4C402B0B.5070708@cdatazone.org> Date: Fri, 16 Jul 2010 05:48:59 -0400 From: Rob Richards User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4C2C6D4A.5010401@cdatazone.org> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2DC7C5.2090009@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F108B.70504@cdatazone.org> <20100708110542.150740@gmx.net> <4C3707BD.6070201@gmx.de> <4C3E05EE.4050903@cdatazone.org> <4A8399B3-F14F-48B2-8A7F-6CC923EDD128@hueniverse.com> In-Reply-To: <4A8399B3-F14F-48B2-8A7F-6CC923EDD128@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP2Go-MailScanner-Information: Please contact support@smtp2go.com for more information X-SMTP2Go-MailScanner-ID: 1OZhXQ-00033W-IY X-SMTP2Go-MailScanner: Found to be clean X-SMTP2Go-MailScanner-From: rrichards@cdatazone.org Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 09:48:54 -0000 Outside of what happens based on the newly refreshed conversation about this, currently this point should be moved to 5.1 rather than 5.1.1 as its not specific to the Authorization header. Rob On 7/14/10 6:15 PM, Eran Hammer-Lahav wrote: > Already in -10. > > EHL > > > > On Jul 14, 2010, at 14:46, Rob Richards wrote: > >> Finally getting a chance to catchup and respond to this thread. >> >> Marius Scurtescu wrote: >>> See comments bellow... >>> >>> >>> On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia wrote: >>> >>>> Hallo Marius, >>>> >>>> thanks for your statement. >>>> Your idea of a migration flow is quite good and necessary. >>>> >>>> But I still doubt, if the work and effort should be investigated to spare >>>> the user from some interaction (authentication and user consent). >>>> >>> It all depends for how many users does the client have OAuth 1 tokens. >>> Asking users to re-approve will confuse them and I guess many will not >>> do it, >>> >> I think the user should not be excluded from this interaction and should >> be required to re-approve. IMO they should be involved as its also >> informational to know that the client they have previously authorized is >> now requesting new credentials under a different security scheme. The >> user should be the one to decide whether or not they want to allow this. >> >> When it comes right down to it the only concrete thing I can think of >> when migrating from 1.0 to 2.0 is the need to determine which version is >> being used at the resource endpoint. For most clients moving from 1.0 to >> 2.0 they will most likely just create the next version of their >> client/app with 2.0 support and completely drop 1.0 support rather than >> going through any migration flow. More work that they don't need to deal >> with so why would they. I can envision a SP providing support for both >> 1.0 and 2.0 with an end of life to 1.0 support. This will give the >> client developers enough time to migrate and distribute their client/apps. >> >> As far as the version determination on the endpoint, this is really just >> a paragraph of text and seems a bit overkill to put into its own >> proposal when it could easily be handled even as an appendix in the core >> 2.0 spec. >> >> Rob >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From Wolfgang.Steigerwald@telekom.de Fri Jul 16 04:46: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 D0DA13A69CF for ; Fri, 16 Jul 2010 04:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5gEUA5uo-Ss for ; Fri, 16 Jul 2010 04:46:56 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 66D6B3A6947 for ; Fri, 16 Jul 2010 04:46:55 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 16 Jul 2010 13:47:00 +0200 Received: from S4DE9JSAACX.ost.t-com.de ([10.125.177.232]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 13:47:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 13:47:00 +0200 Message-ID: <6B1F8C6947A5DC48B613C46E7B420A3A074C1804@S4DE9JSAACX.ost.t-com.de> In-Reply-To: <4C3F9064.6060604@lodderstedt.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [OAUTH-WG] resource server id needed? Thread-index: AcskcAgxzzjwAip8S9uF3Ynlp5da2gAa5bmQ References: <4C3F3F6A.5000409@lodderstedt.net> <4C3F9064.6060604@lodderstedt.net> From: To: X-OriginalArrivalTime: 16 Jul 2010 11:47:00.0715 (UTC) FILETIME=[9A1C6BB0:01CB24DC] Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 11:46:57 -0000 +1 to Thorstens statement. There are use cases beyond local deployments. Best regards Wolfgang -----Urspr=FCngliche Nachricht----- Von: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] Im Auftrag = von Torsten Lodderstedt Gesendet: Freitag, 16. Juli 2010 00:49 An: Marius Scurtescu Cc: OAuth WG Betreff: Re: [OAUTH-WG] resource server id needed? Am 15.07.2010 20:14, schrieb Marius Scurtescu: > On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt > wrote: > =20 >> As I have written in my reply to Marius's posting. I'm fine with = including >> server ids in scopes. But this requires a definition of the scope's = syntax >> and semantics in the spec. Otherwise, scope interpretation (and = server >> identification) will be deployment specific. >> =20 > Sure, it is deployment specific, but why is that an issue? > > In your case, the authz server and all the resource servers are > managed by the same organization, right? > > Do clients need to be aware of the actual resource server? > > You can probably create a separate spec that defines scope syntax for > this purpose, if really needed. Does it have to be in core? > > Marius > =20 Solving the challenge I described in a deployment specific way is not an = issue. But the consequence is that authz server, resource servers and=20 clients are tight together. Let me ask you one question: Why are we working together towards a=20 standard protocol? I can tell you my expectations: I hope there will be=20 broad support not only by libraries, but also by ready-to-use services=20 and clients, so we could integrate such services into our deployment=20 easily. Moreover, I would like to see OAuth to be included in=20 application/service protocols like PortableContacts, SIP, WebDAV, IMAP, = ... So what if I would like to use standard clients to access our services?=20 Using scopes for specifying resource server id's in this case is also=20 simple - if you take an isolated view. But since scopes may be used to=20 specifiy a lot of other things, like resources, permissions, and=20 durations, handling w/o a more detailed spec will in practice be = impossible. Suppose a WebDAV service for media data access. Any WebDAV client knows=20 the WebDAV protocol (=3D=3D interface), e.g. the supported methods (GET, = PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. So it is = sufficient to configure the client with the URL of my personal web=20 storage. To start with let's assume, scopes are used to designate=20 resource servers only. So the server's scope could be "webstorage". WWW-Authenticate OAuth realm=3D'webstorage' scope=3D"webstorage" The client could just pass this parameter to the authz server and=20 everything is fine. On the next level, let's assume the (future) WebDAV standard with=20 OAuth-support uses one permission per method type. So the full scope=20 could be as follows: WWW-Authenticate OAuth realm=3D'webstorage' scope=3D"webstorage:GET = webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY=20 webstorage:MOVE" Passing this scope w/o any unmodified to the authz server is not an=20 issue. But this implies the client asks for full access to the users=20 media storage. Since our client is a gallery application, it requires=20 the "GET" permission only. How does the client know which of the scope=20 values to pick for the end-user authorization process? It must somehow=20 select "webstorage:GET". But how? In my personal opinion, clients should be enabled to interpret, combine=20 and even create scopes. And yes, this should go to the core of the spec. regards, Torsten. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Fri Jul 16 09:14: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 EC6CC3A6A76 for ; Fri, 16 Jul 2010 09:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.293 X-Spam-Level: X-Spam-Status: No, score=-16.293 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, FRT_BELOW2=2.154, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTyK+e2WWLOk for ; Fri, 16 Jul 2010 09:14:12 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id A43EB3A6A73 for ; Fri, 16 Jul 2010 09:14:12 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6GGDLea055704; Fri, 16 Jul 2010 09:13:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=1bVKQek2gys8eU20tk9AAmWIGpw3GSyfePSXlscoWrNXQ/epGbPOBWE3EPPwe9ng Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 09:13:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 09:13:20 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6D0A@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <4C402772.1020601@cdatazone.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Versioning Thread-Index: AcskyjBlvBmwcZ4bQV+dGv7aSQEc9gANtK5A References: <4C2C6D4A.5010401@cdatazone.org><012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET><4C2DC7C5.2090009@cdatazone.org><90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET><4C2F108B.70504@cdatazone.org><20100708110542.150740@gmx.net><4C3707BD.6070201@gmx.de><4C3E05EE.4050903@cdatazone.org> <4C402772.1020601@cdatazone.org> From: "William Mills" To: "Rob Richards" , "Marius Scurtescu" X-OriginalArrivalTime: 16 Jul 2010 16:13:21.0319 (UTC) FILETIME=[CF4B1370:01CB2501] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 16:14:14 -0000 For token migration from Oauth 1 to 2 are we ever really going to need to do that silently for a user in a client? It's reasonable when the user gets a new client install that supports a new protocol for them to have to re-authenticate. Where I see this happening is in a big server migration where you're integrating with somone like Google IMAP and you already have a huge store of tokens for IMAP and you want yo convert to Oauth 2 but you don't want to prompt all your users. Do I have this right?=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Rob Richards > Sent: Friday, July 16, 2010 2:34 AM > To: Marius Scurtescu > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Versioning >=20 >=20 > On 7/14/10 6:33 PM, Marius Scurtescu wrote: > > On Wed, Jul 14, 2010 at 11:46 AM, Rob=20 > Richards wrote: > >> Finally getting a chance to catchup and respond to this thread. > >> > >> Marius Scurtescu wrote: > >>> See comments bellow... > >>> > >>> > >>> On Fri, Jul 9, 2010 at 4:27 AM, Stefanie=20 > Dronia wrote: > >>> > >>>> Hallo Marius, > >>>> > >>>> thanks for your statement. > >>>> Your idea of a migration flow is quite good and necessary. > >>>> > >>>> But I still doubt, if the work and effort should be=20 > investigated to=20 > >>>> spare the user from some interaction (authentication and=20 > user consent). > >>>> > >>> It all depends for how many users does the client have=20 > OAuth 1 tokens. > >>> Asking users to re-approve will confuse them and I guess=20 > many will=20 > >>> not do it, > >>> > >> I think the user should not be excluded from this interaction and=20 > >> should be required to re-approve. IMO they should be=20 > involved as its=20 > >> also informational to know that the client they have previously=20 > >> authorized is now requesting new credentials under a different=20 > >> security scheme. The user should be the one to decide=20 > whether or not they want to allow this. > > Why would you re-prompt the user? The only thing that=20 > really changes=20 > > is the underlying protocol, something most end users are not made=20 > > aware of. How would the new approval page be any different from the=20 > > initial one? The user granted a client access to some of its=20 > > resources, that stays the same. If the authorization server=20 > makes it=20 > > explicit on the approval page that OAuth 1 is used, then yes, a=20 > > re-approval is needed, but I don't think this normally happens. > > > > > >> When it comes right down to it the only concrete thing I=20 > can think of=20 > >> when migrating from 1.0 to 2.0 is the need to determine=20 > which version=20 > >> is being used at the resource endpoint. For most clients=20 > moving from=20 > >> 1.0 to 2.0 they will most likely just create the next version of=20 > >> their client/app with 2.0 support and completely drop 1.0 support=20 > >> rather than going through any migration flow. > > That depends on the client. If the client is a web site that has=20 > > several thousand users, and it stores OAuth 1 access tokens for all=20 > > these users, then migration totally makes sense. If the=20 > client is an=20 > > iPhone app with only one user, then maybe you are right.=20 > Even in this=20 > > case, I am sure the app would prefer not to annoy the user and just=20 > > silently move to OAuth 2. If you are the app developer and your app=20 > > has a large install base, would you risk losing even a small=20 > > percentage of those users simply because you presented them with a=20 > > confusing approval page? > > > > > > > As a user I would say yes, I want to be re-prompted or at=20 > least explicitly request the migration of my tokens rather=20 > than having something done silently, behind the scenes and=20 > unbeknownst to me. The underlying protocol has changed,=20 > whether or not I know it, and for all purposes could be the=20 > most insure protocol out there. When something this=20 > fundamental changes, I would want to have to re-authorize the=20 > application because I could just as easily at this point decline.=20 > Perhaps I went and read the changelog, the change was made=20 > known on the site, or someone discovered the change and made=20 > it public. As you can probably tell I lean way more towards=20 > the side of the user and personally think it is more=20 > responsible of the app or web site in question here to=20 > require the re-authorization and risk losing some users (if=20 > that is the case then clearly the application is not worth=20 > the users time in the first place) than to silently change=20 > the protocol on me. >=20 > Rob >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From jricher@mitre.org Fri Jul 16 09:30:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67D433A6A94 for ; Fri, 16 Jul 2010 09:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TOZzUFcscPD for ; Fri, 16 Jul 2010 09:30:23 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 7BC0D3A67F3 for ; Fri, 16 Jul 2010 09:30:23 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6GGURvZ025790 for ; Fri, 16 Jul 2010 12:30:27 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6GGURIe025783 for ; Fri, 16 Jul 2010 12:30:27 -0400 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; Fri, 16 Jul 2010 12:30:27 -0400 From: Justin Richer To: OAuth WG Content-Type: text/plain; charset="UTF-8" Date: Fri, 16 Jul 2010 12:30:26 -0400 Message-ID: <1279297826.11628.61.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 16:30:44 -0000 The choice of the value "none" for the grant_type parameter in the client-credentials case is confusing. I understand the philosophy behind this choice, but I think that calling it "none" here gives the wrong impression. It almost sounds like it's a deny-request on first glance, or even a revoke request of some type. Furthermore, I'd say that there really is an access grant being made here, but it's implicit, and given to the client directly and not to an end user. I propose we change this key to "client", "implicit", "direct", or something other than "none" to avoid this kind of confusion. Along with this, I would also like the paragraph in 4.1 describing the usage of this grant type to be pulled into its own (admittedly short) subsection. In this way, someone looking to implement this style of auth will have somewhere concrete to look, bringing this method on par with others in section 4.1. -- Justin From beaton@google.com Fri Jul 16 09:35: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 D2C3D3A69C8 for ; Fri, 16 Jul 2010 09:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.905 X-Spam-Level: X-Spam-Status: No, score=-101.905 tagged_above=-999 required=5 tests=[AWL=0.072, 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 0V1Hq8djir3T for ; Fri, 16 Jul 2010 09:35:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id B84CD3A67F3 for ; Fri, 16 Jul 2010 09:35:37 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o6GGZmeH008713 for ; Fri, 16 Jul 2010 09:35:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279298148; bh=Epg/Io5CuR5BKqbbweI3BBiopGE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=JMvSgIcprLczHYoiBnecOJkNlHqYfRlPO3j1jaU2hSNud3CFwjNW/gnEVg/asRapC nXukF8sB8drUCw1w6hPMQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=esKxrAKTZ5oTRpub4vEMditvXwGAKGwwhCRv17Jk+lU6T83yyE+4cYt8BUajFY6kG Iurn70pG2I0igGPcU/n9g== Received: from pva4 (pva4.prod.google.com [10.241.209.4]) by hpaq6.eem.corp.google.com with ESMTP id o6GGZlPR032133 for ; Fri, 16 Jul 2010 09:35:47 -0700 Received: by pva4 with SMTP id 4so923597pva.16 for ; Fri, 16 Jul 2010 09:35:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.211.6 with SMTP id j6mr1774905wfg.166.1279298142251; Fri, 16 Jul 2010 09:35:42 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Fri, 16 Jul 2010 09:35:41 -0700 (PDT) In-Reply-To: <6B1F8C6947A5DC48B613C46E7B420A3A074C1804@S4DE9JSAACX.ost.t-com.de> References: <4C3F3F6A.5000409@lodderstedt.net> <4C3F9064.6060604@lodderstedt.net> <6B1F8C6947A5DC48B613C46E7B420A3A074C1804@S4DE9JSAACX.ost.t-com.de> Date: Fri, 16 Jul 2010 09:35:41 -0700 Message-ID: From: Brian Eaton To: Wolfgang.Steigerwald@telekom.de Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 16:35:39 -0000 On Fri, Jul 16, 2010 at 4:47 AM, wrote: > +1 to Thorstens statement. There are use cases beyond local deployments. Definitely. For example, I'm interested in deployments where neither clients nor resource servers need secret keys. This makes adding new clients and resource servers trivial. The challenge here is that even though lots of people are interested in various semantics for "scope", and various types of relations between clients, resource servers, and authorization servers, not everyone has the same use cases and requirements. From mscurtescu@google.com Fri Jul 16 09:37: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 0FB3A3A6A26 for ; Fri, 16 Jul 2010 09:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.797 X-Spam-Level: X-Spam-Status: No, score=-100.797 tagged_above=-999 required=5 tests=[AWL=-0.974, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_BELOW2=2.154, 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 w2DXb8kOGHfW for ; Fri, 16 Jul 2010 09:37:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7B92D3A690C for ; Fri, 16 Jul 2010 09:37:02 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o6GGbDqb018864 for ; Fri, 16 Jul 2010 09:37:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279298233; bh=6yN8/B7CfZzaYpn+Nznti4aFUPE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Qi9F92RvKrSgOxzZgYMecQ5Leu+itxLdslRtBtk3NQpO5kUyhouz4Tw8KEqo4/vMU e+Sg42OzOVINcBP4dG4Vw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=iz2XS65Su/5WmGuwawIon5PY3ShE2HT/Kg7vFANQow7cuIxaaMMMrmcZgMyySF2u5 gVwqbot1GEHYyn7D4UAoA== Received: from gxk22 (gxk22.prod.google.com [10.202.11.22]) by hpaq5.eem.corp.google.com with ESMTP id o6GGaH6l015945 for ; Fri, 16 Jul 2010 09:37:12 -0700 Received: by gxk22 with SMTP id 22so1338635gxk.25 for ; Fri, 16 Jul 2010 09:37:12 -0700 (PDT) Received: by 10.101.59.14 with SMTP id m14mr1570695ank.127.1279298231860; Fri, 16 Jul 2010 09:37:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Fri, 16 Jul 2010 09:36:51 -0700 (PDT) In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6D0A@SNV-EXVS08.ds.corp.yahoo.com> References: <4C2C6D4A.5010401@cdatazone.org> <012AB2B223CB3F4BB846962876F47217059B693B@SNV-EXVS08.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C454@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C475@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C515@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2DC7C5.2090009@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C623@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F108B.70504@cdatazone.org> <20100708110542.150740@gmx.net> <4C3707BD.6070201@gmx.de> <4C3E05EE.4050903@cdatazone.org> <4C402772.1020601@cdatazone.org> <012AB2B223CB3F4BB846962876F47217059B6D0A@SNV-EXVS08.ds.corp.yahoo.com> From: Marius Scurtescu Date: Fri, 16 Jul 2010 09:36:51 -0700 Message-ID: To: William Mills 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] Versioning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 16:37:04 -0000 On Fri, Jul 16, 2010 at 9:13 AM, William Mills wrote= : > For token migration from Oauth 1 to 2 are we ever really going to need > to do that silently for a user in a client? =A0It's reasonable when the > user gets a new client install that supports a new protocol for them to > have to re-authenticate. =A0Where I see this happening is in a big server > migration where you're integrating with somone like Google IMAP and you > already have a huge store of tokens for IMAP and you want yo convert to > Oauth 2 but you don't want to prompt all your users. > > Do I have this right? I think so. I don't think we have to decide if silent upgrade should always be used or not, just that it is a valid option. Marius > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >> On Behalf Of Rob Richards >> Sent: Friday, July 16, 2010 2:34 AM >> To: Marius Scurtescu >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Versioning >> >> >> =A0 On 7/14/10 6:33 PM, Marius Scurtescu wrote: >> > On Wed, Jul 14, 2010 at 11:46 AM, Rob >> Richards =A0wrote: >> >> Finally getting a chance to catchup and respond to this thread. >> >> >> >> Marius Scurtescu wrote: >> >>> See comments bellow... >> >>> >> >>> >> >>> On Fri, Jul 9, 2010 at 4:27 AM, Stefanie >> Dronia =A0wrote: >> >>> >> >>>> Hallo Marius, >> >>>> >> >>>> thanks for your statement. >> >>>> Your idea of a migration flow is quite good and necessary. >> >>>> >> >>>> But I still doubt, if the work and effort should be >> investigated to >> >>>> spare the user from some interaction (authentication and >> user consent). >> >>>> >> >>> It all depends for how many users does the client have >> OAuth 1 tokens. >> >>> Asking users to re-approve will confuse them and I guess >> many will >> >>> not do it, >> >>> >> >> I think the user should not be excluded from this interaction and >> >> should be required to re-approve. IMO they should be >> involved as its >> >> also informational to know that the client they have previously >> >> authorized is now requesting new credentials under a different >> >> security scheme. The user should be the one to decide >> whether or not they want to allow this. >> > Why would you re-prompt the user? The only thing that >> really changes >> > is the underlying protocol, something most end users are not made >> > aware of. How would the new approval page be any different from the >> > initial one? The user granted a client access to some of its >> > resources, that stays the same. If the authorization server >> makes it >> > explicit on the approval page that OAuth 1 is used, then yes, a >> > re-approval is needed, but I don't think this normally happens. >> > >> > >> >> When it comes right down to it the only concrete thing I >> can think of >> >> when migrating from 1.0 to 2.0 is the need to determine >> which version >> >> is being used at the resource endpoint. For most clients >> moving from >> >> 1.0 to 2.0 they will most likely just create the next version of >> >> their client/app with 2.0 support and completely drop 1.0 support >> >> rather than going through any migration flow. >> > That depends on the client. If the client is a web site that has >> > several thousand users, and it stores OAuth 1 access tokens for all >> > these users, then migration totally makes sense. If the >> client is an >> > iPhone app with only one user, then maybe you are right. >> Even in this >> > case, I am sure the app would prefer not to annoy the user and just >> > silently move to OAuth 2. If you are the app developer and your app >> > has a large install base, would you risk losing even a small >> > percentage of those users simply because you presented them with a >> > confusing approval page? >> > >> > >> > >> As a user I would say yes, I want to be re-prompted or at >> least explicitly request the migration of my tokens rather >> than having something done silently, behind the scenes and >> unbeknownst to me. The underlying protocol has changed, >> whether or not I know it, and for all purposes could be the >> most insure protocol out there. When something this >> fundamental changes, I would want to have to re-authorize the >> application because I could just as easily at this point decline. >> Perhaps I went and read the changelog, the change was made >> known on the site, or someone discovered the change and made >> it public. As you can probably tell I lean way more towards >> the side of the user and personally think it is more >> responsible of the app or web site in question here to >> require the re-authorization and risk losing some users (if >> that is the case then clearly the application is not worth >> the users time in the first place) than to silently change >> the protocol on me. >> >> Rob >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From mscurtescu@google.com Fri Jul 16 09:40: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 3401F3A6A26 for ; Fri, 16 Jul 2010 09:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.776 X-Spam-Level: X-Spam-Status: No, score=-101.776 tagged_above=-999 required=5 tests=[AWL=0.201, 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 Rnai+vMU2sxz for ; Fri, 16 Jul 2010 09:40:05 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 11A963A6A8A for ; Fri, 16 Jul 2010 09:40:04 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o6GGeGp2015710 for ; Fri, 16 Jul 2010 09:40:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279298416; bh=YDqs7hwKaK/rxtGK+lTxfe8xXbY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Q2ke0/J4FUG86+gJVbLFg7tCnhdxSblaSkvjtZmnYy17+Q0w5d7Wfk6jQNWoAWX5r wMqnVNIqqmnwdZLp4Pwig== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=fQ+S6Qsgj4IeDlyed/TOPK1368lRzK7nf67yrd9U+R8ODIxVHkrjWt3DGIg+th+7x sB0RGXXvmhGyq2Xj/B8sg== Received: from gwaa20 (gwaa20.prod.google.com [10.200.27.20]) by hpaq14.eem.corp.google.com with ESMTP id o6GGdVYv023582 for ; Fri, 16 Jul 2010 09:40:15 -0700 Received: by gwaa20 with SMTP id a20so1517028gwa.24 for ; Fri, 16 Jul 2010 09:40:15 -0700 (PDT) Received: by 10.100.198.9 with SMTP id v9mr609887anf.245.1279298414312; Fri, 16 Jul 2010 09:40:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Fri, 16 Jul 2010 09:39:54 -0700 (PDT) In-Reply-To: <1279297826.11628.61.camel@localhost.localdomain> References: <1279297826.11628.61.camel@localhost.localdomain> From: Marius Scurtescu Date: Fri, 16 Jul 2010 09:39:54 -0700 Message-ID: To: Justin Richer 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] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 16:40:06 -0000 I agree that grant_type=3Dnone is confusing. "client" or "direct" sound bet= ter. Marius On Fri, Jul 16, 2010 at 9:30 AM, Justin Richer wrote: > The choice of the value "none" for the grant_type parameter in the > client-credentials case is confusing. I understand the philosophy behind > this choice, but I think that calling it "none" here gives the wrong > impression. It almost sounds like it's a deny-request on first glance, > or even a revoke request of some type. Furthermore, I'd say that there > really is an access grant being made here, but it's implicit, and given > to the client directly and not to an end user. > > I propose we change this key to "client", "implicit", "direct", or > something other than "none" to avoid this kind of confusion. Along with > this, I would also like the paragraph in 4.1 describing the usage of > this grant type to be pulled into its own (admittedly short) subsection. > In this way, someone looking to implement this style of auth will have > somewhere concrete to look, bringing this method on par with others in > section 4.1. > > =A0-- Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Fri Jul 16 09:41:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B4F3A6A8A for ; Fri, 16 Jul 2010 09:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.132, 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 XYzp4OTQ8ydg for ; Fri, 16 Jul 2010 09:41:17 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by core3.amsl.com (Postfix) with ESMTP id C1F7F3A695B for ; Fri, 16 Jul 2010 09:41:16 -0700 (PDT) Received: from p4ffd0f3a.dip.t-dialin.net ([79.253.15.58] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OZnyZ-0008Ue-6H; Fri, 16 Jul 2010 18:41:27 +0200 Message-ID: <4C408BB2.7090409@lodderstedt.net> Date: Fri, 16 Jul 2010 18:41:22 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brian Eaton References: <4C3F3F6A.5000409@lodderstedt.net> <4C3F9064.6060604@lodderstedt.net> <6B1F8C6947A5DC48B613C46E7B420A3A074C1804@S4DE9JSAACX.ost.t-com.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: Wolfgang.Steigerwald@telekom.de, oauth@ietf.org Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 16:41:19 -0000 Am 16.07.2010 18:35, schrieb Brian Eaton: > On Fri, Jul 16, 2010 at 4:47 AM, wrote: > >> +1 to Thorstens statement. There are use cases beyond local deployments. >> > Definitely. > > For example, I'm interested in deployments where neither clients nor > resource servers need secret keys. This makes adding new clients and > resource servers trivial. > > The challenge here is that even though lots of people are interested > in various semantics for "scope", and various types of relations > between clients, resource servers, and authorization servers, not > everyone has the same use cases and requirements. > then we should put those use cases and requirements on the table and try to find a solution fulfilling these different needs. That's what (from my point of view) standard definition is all about. What do you think? regards, Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From beaton@google.com Fri Jul 16 09:41:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C622F3A6A6A for ; Fri, 16 Jul 2010 09:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.808 X-Spam-Level: X-Spam-Status: No, score=-105.808 tagged_above=-999 required=5 tests=[AWL=0.169, 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 r7G2X-3HT93L for ; Fri, 16 Jul 2010 09:41:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B2D3F3A6A7C for ; Fri, 16 Jul 2010 09:41:43 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o6GGftGq011525 for ; Fri, 16 Jul 2010 09:41:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279298515; bh=DRZRptjZ8y8YDtCKTiJ6n1cIbyI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=C670JyUaLnnsEiEEXLLMYiqrvv4G51bjQa6zfd8NSnSp2riy4cxnkSWRDLNlDQ+TK ufjuw/ZQYekM42jqP/lag== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=iugkkrRrs8eNTIrG0qxMohBnoe4vVrhuRGJtWtVACQVRMwIFHbtUpiewKYNFePR9B rgLn9tgjHiaeW+55y/AJg== Received: from pvh11 (pvh11.prod.google.com [10.241.210.203]) by wpaz33.hot.corp.google.com with ESMTP id o6GGfrmB011033 for ; Fri, 16 Jul 2010 09:41:54 -0700 Received: by pvh11 with SMTP id 11so1054699pvh.38 for ; Fri, 16 Jul 2010 09:41:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.216.21 with SMTP id o21mr1735306wfg.282.1279298513213; Fri, 16 Jul 2010 09:41:53 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Fri, 16 Jul 2010 09:41:53 -0700 (PDT) In-Reply-To: References: <1279297826.11628.61.camel@localhost.localdomain> Date: Fri, 16 Jul 2010 09:41:53 -0700 Message-ID: From: Brian Eaton To: Marius Scurtescu 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] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 16:41:44 -0000 +1. How about calling it "client password", or something along those lines...? That's what Dick called it for WRAP. http://tools.ietf.org/html/draft-hardt-oauth-01#page-13 Cheers, Brian On Fri, Jul 16, 2010 at 9:39 AM, Marius Scurtescu w= rote: > I agree that grant_type=3Dnone is confusing. "client" or "direct" sound b= etter. > > Marius > > > > On Fri, Jul 16, 2010 at 9:30 AM, Justin Richer wrote: >> The choice of the value "none" for the grant_type parameter in the >> client-credentials case is confusing. I understand the philosophy behind >> this choice, but I think that calling it "none" here gives the wrong >> impression. It almost sounds like it's a deny-request on first glance, >> or even a revoke request of some type. Furthermore, I'd say that there >> really is an access grant being made here, but it's implicit, and given >> to the client directly and not to an end user. >> >> I propose we change this key to "client", "implicit", "direct", or >> something other than "none" to avoid this kind of confusion. Along with >> this, I would also like the paragraph in 4.1 describing the usage of >> this grant type to be pulled into its own (admittedly short) subsection. >> In this way, someone looking to implement this style of auth will have >> somewhere concrete to look, bringing this method on par with others in >> section 4.1. >> >> =A0-- Justin >> >> _______________________________________________ >> 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 Fri Jul 16 09:48: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 938EE3A6ABD for ; Fri, 16 Jul 2010 09:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 oF6EF7+HSAts for ; Fri, 16 Jul 2010 09:48:19 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 3656F3A6A0C for ; Fri, 16 Jul 2010 09:48:15 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6GGmPm4009563 for ; Fri, 16 Jul 2010 12:48:25 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6GGmPmD009560 for ; Fri, 16 Jul 2010 12:48:25 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Fri, 16 Jul 2010 12:48:24 -0400 From: Justin Richer To: "oauth@ietf.org" Content-Type: text/plain; charset="UTF-8" Date: Fri, 16 Jul 2010 12:48:24 -0400 Message-ID: <1279298904.11628.74.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] Alternative Upgrade Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 16:48:28 -0000 The current proposal for a 1.0->2.0 upgrade flow is to use the assertion profile and pass the OAuth token in there. Instead, one could create an endpoint that speaks the 1.0 protocol fully, signatures and client secrets and everything, but issues 2.0 tokens, JSON and all. It's a hybridized endpoint also, but put together with the opposite pieces. In both cases, you put a 1.0 token in one end and get a 2.0 token out the other. But in this case, the request being made is a completely vanilla OAuth 1.0 protected resource access request. Does this really need a separate endpoint, or can we extend the grant_type options to include "oath1.0" in an extension? I know that extensions aren't currently allowed to make new grant_types -- I think they should be able to and and proposing that we allow that extension point. I dislike the reasoning of "just cram it all into an assertion to extend", since it doesn't allow for clients to separate out their parameters easily. -- Justin From mscurtescu@google.com Fri Jul 16 09:56: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 1A30B3A67B2 for ; Fri, 16 Jul 2010 09:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.397 X-Spam-Level: X-Spam-Status: No, score=-105.397 tagged_above=-999 required=5 tests=[AWL=0.580, 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 B-uDUG6J2Xrp for ; Fri, 16 Jul 2010 09:56:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 145433A697D for ; Fri, 16 Jul 2010 09:56:27 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id o6GGuc5K003672 for ; Fri, 16 Jul 2010 09:56:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279299398; bh=ajyXtdKFTHYsT5tfYcLXvvYoOO0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=U6mCTFuC5wHyChYOZO6bYlX1VfL8PSx9BYmwKc5EScWDXxxrv08a46r9PCXsZLnuN SNVRuIGPvSHzxO9RGNHWg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=C13H/nBRun9p3lf7vpXS4UD8YqdlvP1QAMLXXraMRbYM8EZI3lOZc/Tjo7hSjGyiB UFCUoUyVzFBKK1VIwHwiA== Received: from yxk8 (yxk8.prod.google.com [10.190.3.136]) by kpbe15.cbf.corp.google.com with ESMTP id o6GGuOYB031065 for ; Fri, 16 Jul 2010 09:56:37 -0700 Received: by yxk8 with SMTP id 8so599111yxk.16 for ; Fri, 16 Jul 2010 09:56:37 -0700 (PDT) Received: by 10.101.171.40 with SMTP id y40mr1631189ano.7.1279299397134; Fri, 16 Jul 2010 09:56:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Fri, 16 Jul 2010 09:56:17 -0700 (PDT) In-Reply-To: <1279298904.11628.74.camel@localhost.localdomain> References: <1279298904.11628.74.camel@localhost.localdomain> From: Marius Scurtescu Date: Fri, 16 Jul 2010 09:56:17 -0700 Message-ID: To: Justin Richer Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Alternative Upgrade Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 16:56:29 -0000 On Fri, Jul 16, 2010 at 9:48 AM, Justin Richer wrote: > The current proposal for a 1.0->2.0 upgrade flow is to use the assertion > profile and pass the OAuth token in there. Instead, one could create an > endpoint that speaks the 1.0 protocol fully, signatures and client > secrets and everything, but issues 2.0 tokens, JSON and all. It's a > hybridized endpoint also, but put together with the opposite pieces. In > both cases, you put a 1.0 token in one end and get a 2.0 token out the > other. But in this case, the request being made is a completely vanilla > OAuth 1.0 protected resource access request. I already proposed something like that, if there is interest I can update the proposal to be in line with the latest spec: http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html Marius From jricher@mitre.org Fri Jul 16 10:03: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 A91833A6A0C for ; Fri, 16 Jul 2010 10:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 kRx71R+Wi7Qb for ; Fri, 16 Jul 2010 10:03:36 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 0DF5F3A69C8 for ; Fri, 16 Jul 2010 10:03:35 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6GH3lBU023587 for ; Fri, 16 Jul 2010 13:03:47 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6GH3lEs023584; Fri, 16 Jul 2010 13:03:47 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Fri, 16 Jul 2010 13:03:46 -0400 From: Justin Richer To: Marius Scurtescu In-Reply-To: References: <1279298904.11628.74.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Fri, 16 Jul 2010 13:03:46 -0400 Message-ID: <1279299826.11628.81.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Alternative Upgrade Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 17:03:37 -0000 Oh hey, so you did. And I even agreed to it back then! Yeah, let's update it. Between this and the other proposed upgrade flow, we should cover most ways people would want to trade one flavor of token for another. -- Justin On Fri, 2010-07-16 at 12:56 -0400, Marius Scurtescu wrote: > On Fri, Jul 16, 2010 at 9:48 AM, Justin Richer wrote: > > The current proposal for a 1.0->2.0 upgrade flow is to use the assertion > > profile and pass the OAuth token in there. Instead, one could create an > > endpoint that speaks the 1.0 protocol fully, signatures and client > > secrets and everything, but issues 2.0 tokens, JSON and all. It's a > > hybridized endpoint also, but put together with the opposite pieces. In > > both cases, you put a 1.0 token in one end and get a 2.0 token out the > > other. But in this case, the request being made is a completely vanilla > > OAuth 1.0 protected resource access request. > > I already proposed something like that, if there is interest I can > update the proposal to be in line with the latest spec: > http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html > > Marius From beaton@google.com Fri Jul 16 10:05: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 1E2B33A695B for ; Fri, 16 Jul 2010 10:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[AWL=0.069, 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 Bp-cInp83saO for ; Fri, 16 Jul 2010 10:05:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id EFD9A3A69C8 for ; Fri, 16 Jul 2010 10:05:18 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o6GH5Te1019719 for ; Fri, 16 Jul 2010 10:05:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279299930; bh=qWbXnQHnDJZbuePQBSdtbrbipSo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Tvhke8zjbkLZBWeJVQqKrtnwQxz8GZdfLQkBI4iKLoVB3kFJawv2RLyqB1/LhwIHi pH64LE5tuSr3/Q0FztCqg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=Zxn14y8hkdjLbOUNkU2pH9fz45uBemD7EJDPk01BxF8YDA2wybnSmuYjM4kX8GWuH lXaF02OAfZoPx/8obA3/Q== Received: from pvh1 (pvh1.prod.google.com [10.241.210.193]) by wpaz9.hot.corp.google.com with ESMTP id o6GH5Sjv014285 for ; Fri, 16 Jul 2010 10:05:28 -0700 Received: by pvh1 with SMTP id 1so1262343pvh.27 for ; Fri, 16 Jul 2010 10:05:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.230.18 with SMTP id c18mr1865633wfh.139.1279299614488; Fri, 16 Jul 2010 10:00:14 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Fri, 16 Jul 2010 10:00:13 -0700 (PDT) In-Reply-To: <4C408BB2.7090409@lodderstedt.net> References: <4C3F3F6A.5000409@lodderstedt.net> <4C3F9064.6060604@lodderstedt.net> <6B1F8C6947A5DC48B613C46E7B420A3A074C1804@S4DE9JSAACX.ost.t-com.de> <4C408BB2.7090409@lodderstedt.net> Date: Fri, 16 Jul 2010 10:00:13 -0700 Message-ID: From: Brian Eaton To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Wolfgang.Steigerwald@telekom.de, oauth@ietf.org Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 17:05:21 -0000 On Fri, Jul 16, 2010 at 9:41 AM, Torsten Lodderstedt wrote: > then we should put those use cases and requirements on the table and try to > find a solution fulfilling these different needs. That's what (from my point > of view) standard definition is all about. > > What do you think? Sounds fine to me. I don't think we could realistically target the work for the core oauth spec. An extension would work well. For my future use cases, at any rate, the core oauth spec is fine. the web-server flow and the user-agent flow are both compatible with what I'd want to do. Cheers, Brian From yarong@microsoft.com Fri Jul 16 11:20: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 EC1463A6AC9 for ; Fri, 16 Jul 2010 11:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.549 X-Spam-Level: X-Spam-Status: No, score=-11.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, GB_I_LETTER=-2, 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 mQBF9S5EkU1O for ; Fri, 16 Jul 2010 11:20:56 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id D5A2D3A6A56 for ; Fri, 16 Jul 2010 11:20:55 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 16 Jul 2010 11:21:04 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.44]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0180.004; Fri, 16 Jul 2010 11:21:06 -0700 From: Yaron Goland To: Robert Sayre Thread-Topic: [OAUTH-WG] What to do about 'realm' Thread-Index: AcsWZA3VaAGfBKT6Rq+fJ1qCaXCqogKnLTUAABpFMgAABm2JgAAKYjcAAD86ilAAG/jAgAB+QVdg Date: Fri, 16 Jul 2010 18:21:02 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C5F998076@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C5F991033@TK5EX14MBXC113.redmond.corp.microsoft.com> In-Reply-To: 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 Cc: OAuth WG Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 18:20:57 -0000 That's my point. The spec says " Words of *TEXT MAY contain characters from= character sets other than ISO- 8859-1 [22] only when encoded according to = the rules of RFC 2047 [14]." But since RFC 2047 is a dead letter as a pract= ical matter the only safe way to move non-ASCII content in a HTTP header is= to use some form of ASCII encoding. So, for example, we couldn't use UTF-1= 6 because it produces characters that aren't safe in ASCII. > -----Original Message----- > From: Robert Sayre [mailto:sayrer@gmail.com] > Sent: Tuesday, July 13, 2010 4:01 PM > To: Yaron Goland > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] What to do about 'realm' >=20 > On Tue, Jul 13, 2010 at 9:46 AM, Yaron Goland > wrote: > > As defined in section 4.2 of RFC 2616 the only characters legally allow= ed in a > HTTP header are a fairly small subset of ASCII. >=20 > I don't think that is correct. The definition of the TEXT rule in section= 2.2 > allows most octets. It also references RFC 2047, but I don't think many > implementations actually support that RFC. >=20 >=20 > -- >=20 > Robert Sayre >=20 > "I would have written a shorter letter, but I did not have the time." From torsten@lodderstedt.net Fri Jul 16 11:41: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 B916B3A6870 for ; Fri, 16 Jul 2010 11:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.125, 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 hsQLm91lHbT2 for ; Fri, 16 Jul 2010 11:41:03 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by core3.amsl.com (Postfix) with ESMTP id A2E153A67E3 for ; Fri, 16 Jul 2010 11:41:02 -0700 (PDT) Received: from p4ffd0f3a.dip.t-dialin.net ([79.253.15.58] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OZpqS-000159-5o; Fri, 16 Jul 2010 20:41:12 +0200 Message-ID: <4C40A7C4.4070909@lodderstedt.net> Date: Fri, 16 Jul 2010 20:41:08 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brian Eaton References: <4C3F3F6A.5000409@lodderstedt.net> <4C3F9064.6060604@lodderstedt.net> <6B1F8C6947A5DC48B613C46E7B420A3A074C1804@S4DE9JSAACX.ost.t-com.de> <4C408BB2.7090409@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: Wolfgang.Steigerwald@telekom.de, oauth@ietf.org Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 18:41:03 -0000 Am 16.07.2010 19:00, schrieb Brian Eaton: > On Fri, Jul 16, 2010 at 9:41 AM, Torsten Lodderstedt > wrote: > >> then we should put those use cases and requirements on the table and try to >> find a solution fulfilling these different needs. That's what (from my point >> of view) standard definition is all about. >> >> What do you think? >> > Sounds fine to me. I don't think we could realistically target the > work for the core oauth spec. An extension would work well. > Why not? And if an extension is the right place to define scope syntax and semantics, then I would suggest to move the scope parameter(s) to that extension, too. A scope parameter without a clear definition in the core endangers interoperability. > For my future use cases, at any rate, the core oauth spec is fine. > the web-server flow and the user-agent flow are both compatible with > what I'd want to do. > Regarding relations between authz servers, resource server and clients, we have the following requirements: We definitely need support for deployments w/ 1 authz server, n resources servers, and m clients. At least resource servers and clients must be identifiable at the protocol level. I don't prefer a certain way of resource server identification: dedicated server_ids, including the server id within scopes or any other solution is acceptable. We would like to see support for specifying permissions on resource servers. I think scope would be the natural way of specifying them. What do others think? regards, Torsten. > Cheers, > Brian > From bcampbell@pingidentity.com Fri Jul 16 12:23: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 F08F23A6ADD for ; Fri, 16 Jul 2010 12:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.228, 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 Il5WaTuTutBn for ; Fri, 16 Jul 2010 12:23:00 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by core3.amsl.com (Postfix) with SMTP id A45653A6991 for ; Fri, 16 Jul 2010 12:22:59 -0700 (PDT) Received: from source ([209.85.161.41]) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTECxnpjVPauoLqXIVOyhte72HUwse0bF@postini.com; Fri, 16 Jul 2010 12:23:12 PDT Received: by fxm20 with SMTP id 20so1336199fxm.28 for ; Fri, 16 Jul 2010 12:23:10 -0700 (PDT) Received: by 10.223.111.200 with SMTP id t8mr1060546fap.31.1279308190301; Fri, 16 Jul 2010 12:23:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.105.135 with HTTP; Fri, 16 Jul 2010 12:22:40 -0700 (PDT) In-Reply-To: References: <1279297826.11628.61.camel@localhost.localdomain> From: Brian Campbell Date: Fri, 16 Jul 2010 13:22:40 -0600 Message-ID: To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 19:23:01 -0000 +1 for something different but not "client password" as sounds like it would preclude other methods of client authentication On Fri, Jul 16, 2010 at 10:41 AM, Brian Eaton wrote: > +1. > > How about calling it "client password", or something along those > lines...? =A0That's what Dick called it for WRAP. > > http://tools.ietf.org/html/draft-hardt-oauth-01#page-13 > > Cheers, > Brian > > On Fri, Jul 16, 2010 at 9:39 AM, Marius Scurtescu = wrote: >> I agree that grant_type=3Dnone is confusing. "client" or "direct" sound = better. >> >> Marius >> >> >> >> On Fri, Jul 16, 2010 at 9:30 AM, Justin Richer wrote= : >>> The choice of the value "none" for the grant_type parameter in the >>> client-credentials case is confusing. I understand the philosophy behin= d >>> this choice, but I think that calling it "none" here gives the wrong >>> impression. It almost sounds like it's a deny-request on first glance, >>> or even a revoke request of some type. Furthermore, I'd say that there >>> really is an access grant being made here, but it's implicit, and given >>> to the client directly and not to an end user. >>> >>> I propose we change this key to "client", "implicit", "direct", or >>> something other than "none" to avoid this kind of confusion. Along with >>> this, I would also like the paragraph in 4.1 describing the usage of >>> this grant type to be pulled into its own (admittedly short) subsection= . >>> In this way, someone looking to implement this style of auth will have >>> somewhere concrete to look, bringing this method on par with others in >>> section 4.1. >>> >>> =A0-- Justin >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From beaton@google.com Fri Jul 16 12:26: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 7AFAE3A6AEA for ; Fri, 16 Jul 2010 12:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.812 X-Spam-Level: X-Spam-Status: No, score=-105.812 tagged_above=-999 required=5 tests=[AWL=0.165, 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 rCu4wau83YOk for ; Fri, 16 Jul 2010 12:26:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1F0983A6A9E for ; Fri, 16 Jul 2010 12:26:23 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o6GJQYNI030838 for ; Fri, 16 Jul 2010 12:26:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279308394; bh=3bDcYb1HgGdXQQNDYbrMHjO9/T0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=rmYHX4yTGbqsZ0CYJsPSMq0KgIrgGjqnq4VrQQK3UQr70a3KEACr74silmMC6jXM6 o4JGOE/fkk2lE9V0fjJZg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=BOZ/GYa/WVYl4/EFNJfvqcDhPOb8hvNFjD2UjmpwDnBE9LxZz7nbcuU8Ct4fYd2tM 6XeNVzBUxL04t/yvmIKng== Received: from pxi2 (pxi2.prod.google.com [10.243.27.2]) by hpaq7.eem.corp.google.com with ESMTP id o6GJQWMD016837 for ; Fri, 16 Jul 2010 12:26:33 -0700 Received: by pxi2 with SMTP id 2so1363381pxi.10 for ; Fri, 16 Jul 2010 12:26:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.213.14 with SMTP id l14mr2054686wfg.90.1279308391517; Fri, 16 Jul 2010 12:26:31 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Fri, 16 Jul 2010 12:26:31 -0700 (PDT) In-Reply-To: References: <1279297826.11628.61.camel@localhost.localdomain> Date: Fri, 16 Jul 2010 12:26:31 -0700 Message-ID: From: Brian Eaton To: Brian Campbell Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 19:26:24 -0000 On Fri, Jul 16, 2010 at 12:22 PM, Brian Campbell wrote: > +1 for something different but not "client password" as sounds like it > would preclude other methods of client authentication I think it would work like this: grant_type=client_password: maps to the "client password flow" from http://tools.ietf.org/html/draft-hardt-oauth-01#page-13. grant_type=client_assertion maps to the "client assertion" profile http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2 Cheers, Brian From beaton@google.com Fri Jul 16 13:16:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527493A6849 for ; Fri, 16 Jul 2010 13:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.911 X-Spam-Level: X-Spam-Status: No, score=-102.911 tagged_above=-999 required=5 tests=[AWL=1.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 6Dsr5Mgqark4 for ; Fri, 16 Jul 2010 13:16:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 4C2103A6848 for ; Fri, 16 Jul 2010 13:16:14 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o6GKGOIq010873 for ; Fri, 16 Jul 2010 13:16:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279311385; bh=ykOaVWTX42K7FgTWGZ+8e8ylVEc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=j+u+N4+V+6UpJ8FqYxBzrelKZdgBdm0vItZn504ElfshXwzB41iSdNAGGmobmTySU WCtZXHwBpZw7dPWgzUGGg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=NlfuLQDCh8S30p1Hj8D0kBVClUf/OroHf2XFpsHwiOMjD9LTThDqM2GSqi3rfPivz KSzBzuv198JTYeWql6XTA== Received: from pwi10 (pwi10.prod.google.com [10.241.219.10]) by wpaz24.hot.corp.google.com with ESMTP id o6GKGNIG023419 for ; Fri, 16 Jul 2010 13:16:23 -0700 Received: by pwi10 with SMTP id 10so1587118pwi.20 for ; Fri, 16 Jul 2010 13:16:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.171.7 with SMTP id t7mr2136319wfe.48.1279311382903; Fri, 16 Jul 2010 13:16:22 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Fri, 16 Jul 2010 13:16:22 -0700 (PDT) In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C5F998076@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C5F991033@TK5EX14MBXC113.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C5F998076@TK5EX14MBXC113.redmond.corp.microsoft.com> Date: Fri, 16 Jul 2010 13:16:22 -0700 Message-ID: From: Brian Eaton To: Yaron Goland 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] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 20:16:17 -0000 On Fri, Jul 16, 2010 at 11:21 AM, Yaron Goland wrote= : > That's my point. The spec says " Words of *TEXT MAY contain characters fr= om character sets other than ISO- 8859-1 [22] only when encoded according t= o the rules of RFC 2047 [14]." But since RFC 2047 is a dead letter as a pra= ctical matter the only safe way to move non-ASCII content in a HTTP header = is to use some form of ASCII encoding. So, for example, we couldn't use UTF= -16 because it produces characters that aren't safe in ASCII. Of course, JSON does support unicode escapes, which will work just fine in an HTTP header. From torsten@lodderstedt.net Fri Jul 16 13:29: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 B6CB73A6B5D for ; Fri, 16 Jul 2010 13:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.118, 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 UGh0oaQUVwYx for ; Fri, 16 Jul 2010 13:29:24 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by core3.amsl.com (Postfix) with ESMTP id AB15A3A6B5C for ; Fri, 16 Jul 2010 13:29:24 -0700 (PDT) Received: from p4ffd0f3a.dip.t-dialin.net ([79.253.15.58] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OZrXK-0002jY-22; Fri, 16 Jul 2010 22:29:34 +0200 Message-ID: <4C40C12A.7040408@lodderstedt.net> Date: Fri, 16 Jul 2010 22:29:30 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brian Eaton References: <1279297826.11628.61.camel@localhost.localdomain> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 20:29:25 -0000 good idea. Am 16.07.2010 21:26, schrieb Brian Eaton: > On Fri, Jul 16, 2010 at 12:22 PM, Brian Campbell > wrote: > >> +1 for something different but not "client password" as sounds like it >> would preclude other methods of client authentication >> > I think it would work like this: > > grant_type=client_password: > maps to the "client password flow" from > http://tools.ietf.org/html/draft-hardt-oauth-01#page-13. > > grant_type=client_assertion > maps to the "client assertion" profile > http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2 > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From recordond@gmail.com Fri Jul 16 13:36: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 866233A6B54 for ; Fri, 16 Jul 2010 13:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.190, 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 WtgCzg5jO7AD for ; Fri, 16 Jul 2010 13:36:58 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7BAFA3A6B47 for ; Fri, 16 Jul 2010 13:36:58 -0700 (PDT) Received: by iwn38 with SMTP id 38so2678273iwn.31 for ; Fri, 16 Jul 2010 13:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=vh/nlNHQ1pKsXzpQ7oNfvt3q9tkJBuI+qIQUjmn4nug=; b=sGg3pLuCB2gwScx04xuoWl+amGRX68fSF5oxwqoPaBcoRfl+KExRDVL6DUmHhOj4Dn YbeRsTHESIhp+x91B+azRtRA5EhJzlit2Gjpwe6hdX+jFERTdT8iUqXgQl6exS4FoZbX clBhCz8MdbSLQPzHKBYXdiqx0+VHiTedTJwyM= 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=VWuPgchIgKhYIYikrnE77lofXYiwcIJiXNWbTeQ5acV5nREdf/bZY5N4+GNQNPl+lP 6qTrbNkXPKgGlLgEeYjJ+1nSs0NcFRTdiIR7YplARffpLzyMThoYeizC3JtzTD6DIkxH W6FtNcfFceH/IKSdjOX752x+FGYZGPVogLNeo= MIME-Version: 1.0 Received: by 10.231.174.72 with SMTP id s8mr1454292ibz.41.1279312630179; Fri, 16 Jul 2010 13:37:10 -0700 (PDT) Received: by 10.231.196.88 with HTTP; Fri, 16 Jul 2010 13:37:10 -0700 (PDT) In-Reply-To: References: <1279297826.11628.61.camel@localhost.localdomain> Date: Fri, 16 Jul 2010 13:37:10 -0700 Message-ID: From: David Recordon To: Brian Eaton Content-Type: multipart/alternative; boundary=0016364ed35ee0e84f048b872e26 Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 20:36:59 -0000 --0016364ed35ee0e84f048b872e26 Content-Type: text/plain; charset=ISO-8859-1 I've always found "client password" to be a confusing term. On Fri, Jul 16, 2010 at 12:26 PM, Brian Eaton wrote: > On Fri, Jul 16, 2010 at 12:22 PM, Brian Campbell > wrote: > > +1 for something different but not "client password" as sounds like it > > would preclude other methods of client authentication > > I think it would work like this: > > grant_type=client_password: > maps to the "client password flow" from > http://tools.ietf.org/html/draft-hardt-oauth-01#page-13. > > grant_type=client_assertion > maps to the "client assertion" profile > http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2 > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016364ed35ee0e84f048b872e26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've always found "client password" to be a confusing term.

On Fri, Jul 16, 2010 at 12:26 PM, Bri= an Eaton <beaton@= google.com> wrote:
On Fri, Jul 16, 2010 at 1= 2:22 PM, Brian Campbell
<bcampbell@pingidentity.co= m> wrote:
> +1 for something different but not "client password" as soun= ds like it
> would preclude other methods of client authentication

I think it would work like this:

grant_type=3Dclient_password:
=A0 =A0 maps to the "client password flow" from
http://tools.ietf.org/html/draft-hardt-oauth-01#page-13.
grant_type=3Dclient_assertion
=A0 =A0 maps to the "client assertion" profile
http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2<= /a>

Cheers,
Brian

--0016364ed35ee0e84f048b872e26-- From beaton@google.com Fri Jul 16 13:57: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 553033A67F9 for ; Fri, 16 Jul 2010 13:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.956 X-Spam-Level: X-Spam-Status: No, score=-101.956 tagged_above=-999 required=5 tests=[AWL=0.021, 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 3s9r4Y9Di7mT for ; Fri, 16 Jul 2010 13:57:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 4166A3A6407 for ; Fri, 16 Jul 2010 13:57:15 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o6GKvOnW012514 for ; Fri, 16 Jul 2010 13:57:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279313845; bh=EPHRp02ikDu5qmPhPSG6Y8XdV14=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=vOzEALwa56t8EukgUSiGEd0W9MlFkXyYQF9DufjQACl6XLPoVO8KQht5IXiF3qWs+ BOPSPkY96KDGCfJ0UGNng== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=XyLENFYbKYqCO4w/gRwL4vQ/6ICcZ77MZTIqxRaOVIQikP/WBy3Zzk4AuKhEvekfV k4lQMKx9vrkJWN7EtsW6A== Received: from pwj9 (pwj9.prod.google.com [10.241.219.73]) by wpaz33.hot.corp.google.com with ESMTP id o6GKvNIg022969 for ; Fri, 16 Jul 2010 13:57:23 -0700 Received: by pwj9 with SMTP id 9so1377467pwj.27 for ; Fri, 16 Jul 2010 13:57:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.140.18 with SMTP id n18mr2164996wfd.151.1279313843200; Fri, 16 Jul 2010 13:57:23 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Fri, 16 Jul 2010 13:57:23 -0700 (PDT) In-Reply-To: References: <1279297826.11628.61.camel@localhost.localdomain> Date: Fri, 16 Jul 2010 13:57:23 -0700 Message-ID: From: Brian Eaton To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 20:57:16 -0000 On Fri, Jul 16, 2010 at 1:37 PM, David Recordon wrote: > I've always found "client password" to be a confusing term. Are you going to support this flow at all...? From bcampbell@pingidentity.com Fri Jul 16 14:15: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 40B193A69D9 for ; Fri, 16 Jul 2010 14:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.782 X-Spam-Level: X-Spam-Status: No, score=-5.782 tagged_above=-999 required=5 tests=[AWL=0.195, 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 eLDO8-P4SaQf for ; Fri, 16 Jul 2010 14:15:45 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by core3.amsl.com (Postfix) with SMTP id E5DE73A684E for ; Fri, 16 Jul 2010 14:15:44 -0700 (PDT) Received: from source ([209.85.161.50]) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTEDMDAyILUw0AA2T9AddyNA20drCUDUl@postini.com; Fri, 16 Jul 2010 14:15:57 PDT Received: by mail-fx0-f50.google.com with SMTP id 9so1315993fxm.9 for ; Fri, 16 Jul 2010 14:15:56 -0700 (PDT) Received: by 10.223.116.136 with SMTP id m8mr1143307faq.50.1279314956213; Fri, 16 Jul 2010 14:15:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.105.135 with HTTP; Fri, 16 Jul 2010 14:15:26 -0700 (PDT) In-Reply-To: References: <1279297826.11628.61.camel@localhost.localdomain> From: Brian Campbell Date: Fri, 16 Jul 2010 15:15:26 -0600 Message-ID: To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 21:15:46 -0000 I guess I don't see why there's a need to distinguish between, in the grant type identifier, how the client authenticates? (this is all presupposes, of course, some kind of assertion based client authentication technique) On Fri, Jul 16, 2010 at 1:26 PM, Brian Eaton wrote: > On Fri, Jul 16, 2010 at 12:22 PM, Brian Campbell > wrote: >> +1 for something different but not "client password" as sounds like it >> would preclude other methods of client authentication > > I think it would work like this: > > grant_type=3Dclient_password: > =A0 =A0 maps to the "client password flow" from > http://tools.ietf.org/html/draft-hardt-oauth-01#page-13. > > grant_type=3Dclient_assertion > =A0 =A0 maps to the "client assertion" profile > http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.2 > > Cheers, > Brian > From eran@hueniverse.com Fri Jul 16 14:23: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 1D5C73A6B66 for ; Fri, 16 Jul 2010 14:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 6-ZqWiSAgMvT for ; Fri, 16 Jul 2010 14:23:38 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 588593A6407 for ; Fri, 16 Jul 2010 14:23:38 -0700 (PDT) Received: (qmail 26103 invoked from network); 16 Jul 2010 21:23:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jul 2010 21:23:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 16 Jul 2010 14:23:44 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Fri, 16 Jul 2010 14:23:31 -0700 Thread-Topic: [OAUTH-WG] Change grant_type="none" to something less confusing Thread-Index: AcslLStlEwg33G4dSq+0DcKZCEGKEw== Message-ID: <3AF1FD6F-2178-42ED-833C-D93C534DDA8A@hueniverse.com> References: <1279297826.11628.61.camel@localhost.localdomain> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 21:23:39 -0000 And that matters how? EHL On Jul 16, 2010, at 16:57, "Brian Eaton" wrote: > On Fri, Jul 16, 2010 at 1:37 PM, David Recordon wro= te: >> I've always found "client password" to be a confusing term. >=20 > Are you going to support this flow at all...? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Jul 16 14:25: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 353F73A6B2F for ; Fri, 16 Jul 2010 14:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 a93DQJ8YaW-c for ; Fri, 16 Jul 2010 14:25:42 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 0A2913A6407 for ; Fri, 16 Jul 2010 14:25:42 -0700 (PDT) Received: (qmail 28426 invoked from network); 16 Jul 2010 21:25:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jul 2010 21:25:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 16 Jul 2010 14:25:53 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Fri, 16 Jul 2010 14:25:39 -0700 Thread-Topic: [OAUTH-WG] Change grant_type="none" to something less confusing Thread-Index: AcslLXhVGIrlsgsFTb+NPFYP9bj2mQ== Message-ID: <5F922BD8-22C9-4E87-9D5B-BAC0529F94C7@hueniverse.com> References: <1279297826.11628.61.camel@localhost.localdomain> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 21:25:43 -0000 External, out-of-band, implicit. It cannot be client because that is not always the case.=20 EHL On Jul 16, 2010, at 12:40, Marius Scurtescu wrote: > I agree that grant_type=3Dnone is confusing. "client" or "direct" sound b= etter. >=20 > Marius >=20 >=20 >=20 > On Fri, Jul 16, 2010 at 9:30 AM, Justin Richer wrote: >> The choice of the value "none" for the grant_type parameter in the >> client-credentials case is confusing. I understand the philosophy behind >> this choice, but I think that calling it "none" here gives the wrong >> impression. It almost sounds like it's a deny-request on first glance, >> or even a revoke request of some type. Furthermore, I'd say that there >> really is an access grant being made here, but it's implicit, and given >> to the client directly and not to an end user. >>=20 >> I propose we change this key to "client", "implicit", "direct", or >> something other than "none" to avoid this kind of confusion. Along with >> this, I would also like the paragraph in 4.1 describing the usage of >> this grant type to be pulled into its own (admittedly short) subsection. >> In this way, someone looking to implement this style of auth will have >> somewhere concrete to look, bringing this method on par with others in >> section 4.1. >>=20 >> -- Justin >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Jul 16 14:26: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 D1D3A3A6B6F for ; Fri, 16 Jul 2010 14:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EshnUDUyOb8J for ; Fri, 16 Jul 2010 14:26:31 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id F1B313A6B2F for ; Fri, 16 Jul 2010 14:26:30 -0700 (PDT) Received: (qmail 29386 invoked from network); 16 Jul 2010 21:26:43 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jul 2010 21:26:43 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 16 Jul 2010 14:26:42 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Fri, 16 Jul 2010 14:26:30 -0700 Thread-Topic: [OAUTH-WG] What to do about 'realm' Thread-Index: AcslLZYip0pw7EARS1e0FS7gY0e00g== Message-ID: <56441EC7-DC70-4DEE-9DBA-0BF1B7F549A3@hueniverse.com> References: <7C01E631FF4B654FA1E783F1C0265F8C5F991033@TK5EX14MBXC113.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C5F998076@TK5EX14MBXC113.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 21:26:31 -0000 If you specify it. It is supported but not required.=20 EHL On Jul 16, 2010, at 16:16, "Brian Eaton" wrote: > On Fri, Jul 16, 2010 at 11:21 AM, Yaron Goland wro= te: >> That's my point. The spec says " Words of *TEXT MAY contain characters f= rom character sets other than ISO- 8859-1 [22] only when encoded according = to the rules of RFC 2047 [14]." But since RFC 2047 is a dead letter as a pr= actical matter the only safe way to move non-ASCII content in a HTTP header= is to use some form of ASCII encoding. So, for example, we couldn't use UT= F-16 because it produces characters that aren't safe in ASCII. >=20 > Of course, JSON does support unicode escapes, which will work just > fine in an HTTP header. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Fri Jul 16 15:19: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 C3A383A67F4 for ; Fri, 16 Jul 2010 15:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.816 X-Spam-Level: X-Spam-Status: No, score=-105.816 tagged_above=-999 required=5 tests=[AWL=0.161, 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 yAEqK8SED1rp for ; Fri, 16 Jul 2010 15:19:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DAC953A6992 for ; Fri, 16 Jul 2010 15:19:09 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o6GMJL8v000759 for ; Fri, 16 Jul 2010 15:19:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279318761; bh=1RLNCnVUUx4deZhObaM8bX/6E98=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=eotRCvO7SW++clslYcPUDkb9hV3YzqJ6+DoFwjUZ5CfwsiW4PYlFA6p3YAxlpr9xq d1eviJIohJ/2+VQm0WZ5A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=T5vjHnJ6G50ZC1WyzJo3Lp2xNxBscIkPJiYYGNSnJk33rCoAVc4NxTDkdDfF5PE4u PAEF7+6+WfsG8kBtBafVg== Received: from pzk5 (pzk5.prod.google.com [10.243.19.133]) by kpbe18.cbf.corp.google.com with ESMTP id o6GMJKs1017432 for ; Fri, 16 Jul 2010 15:19:20 -0700 Received: by pzk5 with SMTP id 5so1177617pzk.24 for ; Fri, 16 Jul 2010 15:19:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.213.14 with SMTP id l14mr2280516wfg.90.1279318759560; Fri, 16 Jul 2010 15:19:19 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Fri, 16 Jul 2010 15:19:19 -0700 (PDT) In-Reply-To: <5F922BD8-22C9-4E87-9D5B-BAC0529F94C7@hueniverse.com> References: <1279297826.11628.61.camel@localhost.localdomain> <5F922BD8-22C9-4E87-9D5B-BAC0529F94C7@hueniverse.com> Date: Fri, 16 Jul 2010 15:19:19 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 22:19:10 -0000 On Fri, Jul 16, 2010 at 2:25 PM, Eran Hammer-Lahav wrote: > External, out-of-band, implicit. > > It cannot be client because that is not always the case. Can you point to a use case where someone is going to use the client password flow to authenticate something besides a client? Because I'm pretty sure that use case is crazy, and can safely be ignored. From mscurtescu@google.com Fri Jul 16 15:23: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 056CA3A69A5 for ; Fri, 16 Jul 2010 15:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.494 X-Spam-Level: X-Spam-Status: No, score=-105.494 tagged_above=-999 required=5 tests=[AWL=0.483, 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 R7d9HEEWr6Ip for ; Fri, 16 Jul 2010 15:23:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 931973A67F4 for ; Fri, 16 Jul 2010 15:23:23 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o6GMNZno020224 for ; Fri, 16 Jul 2010 15:23:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279319015; bh=zFQNIrlt20I+Lb+ZayKqWmGu5W8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=QSOOraMsI0CgYIVyHVjhTeJJWAdJBkyrh2yze09VL37rjnttGUZPrL8Y4/DfhfkrA Tueq/axyobkHfPLJOr6EQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=xw7dB0s+ofKYIKUyxFjBJM8LNRqkhsX4n7ZRV1nJ7+tC9+R0+cuU1HDvtQMqfXBER TlP3nHeZC3Zw045yHBTmg== Received: from yxi11 (yxi11.prod.google.com [10.190.3.11]) by kpbe14.cbf.corp.google.com with ESMTP id o6GMNYZS019841 for ; Fri, 16 Jul 2010 15:23:34 -0700 Received: by yxi11 with SMTP id 11so711020yxi.20 for ; Fri, 16 Jul 2010 15:23:34 -0700 (PDT) Received: by 10.100.44.8 with SMTP id r8mr1701303anr.13.1279319011206; Fri, 16 Jul 2010 15:23:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.3 with HTTP; Fri, 16 Jul 2010 15:23:08 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Fri, 16 Jul 2010 15:23:08 -0700 Message-ID: To: "Richer, Justin P." 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] Moving the User Experience Extension draft forward X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 22:23:26 -0000 I agree that these parameters are useful, but not sure if they belong in the User Experience extension. I think we should create a separate extension for unregistered clients: - how to signal that this client is unregistered, maybe use a special value like "anonymous" as the client id - what client name/description should be used, as you suggest here Instead of instance_name and instance_description maybe we can call these client_name and client_description? Marius On Tue, Jul 13, 2010 at 5:28 AM, Richer, Justin P. wrot= e: > I'd like to propose the addition of two more optional parameters to this = extension: > > instance_name > =A0 Short, human-readable name that the server SHOULD display to > =A0 the end-user along with the client name. This name is designed > =A0 to reflect a per-instance identifier for cases where a single user > =A0 may authorize multiple copies of a single identified client. The > =A0 server MAY [SHOULD?] store this information along with its > =A0 associated access grant to allow the end-user to differentiate > =A0 between instances of the application in the future (for example, > =A0 to revoke access tokens). > > instance_description > =A0 A longer, human-readable description that the server MAY display to > =A0 the end-user along with the client name. This description =A0is desig= ned > =A0 as the name above to reflect a per-instance identifier for cases wher= e > =A0 a single user may authorize multiple copies of a single identified cl= ient. The > =A0 server MAY [SHOULD?] store this information along with its > =A0 associated access grant to allow the end-user to differentiate > =A0 between instances of the application in the future (for example, > =A0 to revoke access tokens). If a client presents the instance_descripti= on, > =A0 it MUST also present an instance_name. > > This can be thought of as the new way of Google's xoauth_display_name par= ameter. We have a direct use case for this, and it seems like it would fit = in the UX more than its own extension. > > There was also talk of sending a client-information URL to get more stuff= about the client and instances of it, but that seems a better fit for the = impending discovery spec, to me, as it seems to address full client informa= tion and not per-instance information that this is talking about. > > =A0-- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of David = Recordon [recordond@gmail.com] > Sent: Monday, July 12, 2010 3:51 PM > To: OAuth WG > Subject: [OAUTH-WG] Moving the User Experience Extension draft forward > > I wrote this draft last month based on discussions on the mailing list, t= he OpenID user experience extension (which Facebook, Google, and Yahoo! hav= e deployed), and some OAuth 2.0 implementation experience from Facebook. It= defines language and display preferences which the client can include in r= equests to the end-user authorization endpoint. > > A previous draft included an immediate mode parameter but further discuss= ion has shown that it should be removed until identity information is also = addressed. Identity is outside the scope of this particular extension. > > I'd like this draft to become a working group document and have done my b= est to make it represent the group's consensus. Unfortunately the internet = draft submission process is closed for a few weeks until after the meeting.= :-\ > > Thanks, > --David > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Fri Jul 16 15:27: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 2425E3A69A5 for ; Fri, 16 Jul 2010 15:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 s5JpfjW-bSbD for ; Fri, 16 Jul 2010 15:27:05 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 2B29C3A6862 for ; Fri, 16 Jul 2010 15:27:05 -0700 (PDT) Received: (qmail 1791 invoked from network); 16 Jul 2010 22:27:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jul 2010 22:27:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 16 Jul 2010 15:27:16 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Fri, 16 Jul 2010 15:27:03 -0700 Thread-Topic: [OAUTH-WG] Change grant_type="none" to something less confusing Thread-Index: AcslNgtqPxJK3RFmTOW5ykAWUzOQ/g== Message-ID: <32537D24-A84A-482C-8B9B-ECA14CB5325C@hueniverse.com> References: <1279297826.11628.61.camel@localhost.localdomain> <5F922BD8-22C9-4E87-9D5B-BAC0529F94C7@hueniverse.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 22:27:06 -0000 The client authentication can be used to retrieve a grant previously arrang= ed. While the grant is linked to the client, it is not always about the cli= ent's resources. Calling it 'client' implies it is about the client's resou= rces.=20 EHL On Jul 16, 2010, at 18:19, Brian Eaton wrote: > On Fri, Jul 16, 2010 at 2:25 PM, Eran Hammer-Lahav = wrote: >> External, out-of-band, implicit. >>=20 >> It cannot be client because that is not always the case. >=20 > Can you point to a use case where someone is going to use the client > password flow to authenticate something besides a client? >=20 > Because I'm pretty sure that use case is crazy, and can safely be ignored= . From beaton@google.com Fri Jul 16 15:27: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 441D23A6924 for ; Fri, 16 Jul 2010 15:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.82 X-Spam-Level: X-Spam-Status: No, score=-105.82 tagged_above=-999 required=5 tests=[AWL=0.157, 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 GdmZW84TMPss for ; Fri, 16 Jul 2010 15:27:24 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3C4683A67F4 for ; Fri, 16 Jul 2010 15:27:24 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o6GMRaoW012905 for ; Fri, 16 Jul 2010 15:27:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279319256; bh=QjwpI25GB7b1dmNb4Xjo03k+IgM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=uZC1eb0LvAvstWOpdbtmZPawr9vM+a52vlS9CBP3HZLBZvvAA15PRrW+MZljiBxUi hqHXB9j+AqE7GNJhmzSLQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=BbcpqVbmg3IMuPtkStJK5gZHRRXhwIbjAtbNU7OqvdddUptNTAaT7PXeQ/gFK2nqO wyIVE5n74eU4YpIZBBw9Q== Received: from pxi12 (pxi12.prod.google.com [10.243.27.12]) by kpbe16.cbf.corp.google.com with ESMTP id o6GMRYbX025205 for ; Fri, 16 Jul 2010 15:27:35 -0700 Received: by pxi12 with SMTP id 12so1819965pxi.20 for ; Fri, 16 Jul 2010 15:27:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.134.13 with SMTP id h13mr2368853wfd.119.1279319254518; Fri, 16 Jul 2010 15:27:34 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Fri, 16 Jul 2010 15:27:34 -0700 (PDT) In-Reply-To: <3AF1FD6F-2178-42ED-833C-D93C534DDA8A@hueniverse.com> References: <1279297826.11628.61.camel@localhost.localdomain> <3AF1FD6F-2178-42ED-833C-D93C534DDA8A@hueniverse.com> Date: Fri, 16 Jul 2010 15:27:34 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 22:27:25 -0000 I withdraw my question. David might not be interested in implementing the client password flow, but he is certainly interested in implementing other flows that involve the client password term. So he's entitled to an opinion on what color the client password bike shed should be painted. =) (David, no offense, I'm just trying to stick by my guns on the whole "stop screwing up the spec by merging separate use cases into single flows" thing...) On Fri, Jul 16, 2010 at 2:23 PM, Eran Hammer-Lahav wrote: > And that matters how? > > EHL > > > > On Jul 16, 2010, at 16:57, "Brian Eaton" wrote: > >> On Fri, Jul 16, 2010 at 1:37 PM, David Recordon wrote: >>> I've always found "client password" to be a confusing term. >> >> Are you going to support this flow at all...? >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From beaton@google.com Fri Jul 16 15:30: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 221F03A685E for ; Fri, 16 Jul 2010 15:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.824 X-Spam-Level: X-Spam-Status: No, score=-105.824 tagged_above=-999 required=5 tests=[AWL=0.153, 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 6re16M480o8d for ; Fri, 16 Jul 2010 15:30:19 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 666A13A6823 for ; Fri, 16 Jul 2010 15:30:19 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o6GMUUfD030325 for ; Fri, 16 Jul 2010 15:30:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279319431; bh=RSanxpZxjGEglobOua6KcNwKc74=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=oBb0xsB5oOOIRLwym+u0B0ahvUadiLXMAV5RMkO/KM0ky3feuIMiRqWGQFi707tzh OYQlHGlKRInHlUaufYSIw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=BvxYRfcevbIHWrSahgCss0f3mapXUhrAMY+or/4Zab5hg2CSbE4KcyrF98nIwDH+O BtB62cE/IujQ5IrjLQ5ZQ== Received: from pwi5 (pwi5.prod.google.com [10.241.219.5]) by hpaq7.eem.corp.google.com with ESMTP id o6GMUSps018117 for ; Fri, 16 Jul 2010 15:30:29 -0700 Received: by pwi5 with SMTP id 5so987956pwi.19 for ; Fri, 16 Jul 2010 15:30:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.232.21 with SMTP id e21mr2416424wfh.92.1279319428219; Fri, 16 Jul 2010 15:30:28 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Fri, 16 Jul 2010 15:30:28 -0700 (PDT) In-Reply-To: <32537D24-A84A-482C-8B9B-ECA14CB5325C@hueniverse.com> References: <1279297826.11628.61.camel@localhost.localdomain> <5F922BD8-22C9-4E87-9D5B-BAC0529F94C7@hueniverse.com> <32537D24-A84A-482C-8B9B-ECA14CB5325C@hueniverse.com> Date: Fri, 16 Jul 2010 15:30:28 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 22:30:25 -0000 On Fri, Jul 16, 2010 at 3:27 PM, Eran Hammer-Lahav wrote: > The client authentication can be used to retrieve a grant previously arranged. Really? Who is going to implement that? I'm pretty sure that if the only inputs to the protocol are a client name and a client password, the output is going to be an authentication credential that belongs to the client. From torsten@lodderstedt.net Sat Jul 17 05:30: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 707A53A6403 for ; Sat, 17 Jul 2010 05:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.112, 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 s7N92AwgKOdU for ; Sat, 17 Jul 2010 05:30:53 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by core3.amsl.com (Postfix) with ESMTP id 96AB13A698D for ; Sat, 17 Jul 2010 05:30:51 -0700 (PDT) Received: from p4ffd12f0.dip.t-dialin.net ([79.253.18.240] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Oa6Xm-0003Sl-Ij; Sat, 17 Jul 2010 14:31:02 +0200 Message-ID: <4C41A281.7080809@lodderstedt.net> Date: Sat, 17 Jul 2010 14:30:57 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Justin Richer References: <1279298904.11628.74.camel@localhost.localdomain> In-Reply-To: <1279298904.11628.74.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Alternative Upgrade Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 12:30:55 -0000 I think we gonna need additional end points anyway, e.g. for token revocation. So why not use another endpoint for that purpose? That way the tokens endpoint is not overloaded to much. regards, Torsten. Am 16.07.2010 18:48, schrieb Justin Richer: > The current proposal for a 1.0->2.0 upgrade flow is to use the assertion > profile and pass the OAuth token in there. Instead, one could create an > endpoint that speaks the 1.0 protocol fully, signatures and client > secrets and everything, but issues 2.0 tokens, JSON and all. It's a > hybridized endpoint also, but put together with the opposite pieces. In > both cases, you put a 1.0 token in one end and get a 2.0 token out the > other. But in this case, the request being made is a completely vanilla > OAuth 1.0 protected resource access request. > > Does this really need a separate endpoint, or can we extend the > grant_type options to include "oath1.0" in an extension? I know that > extensions aren't currently allowed to make new grant_types -- I think > they should be able to and and proposing that we allow that extension > point. I dislike the reasoning of "just cram it all into an assertion to > extend", since it doesn't allow for clients to separate out their > parameters easily. > > -- Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From lshepard@facebook.com Sat Jul 17 08:52: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 B3CB63A6951 for ; Sat, 17 Jul 2010 08:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIeL16UTSzUg for ; Sat, 17 Jul 2010 08:52:47 -0700 (PDT) Received: from mx-out.facebook.com (outmail024.snc1.tfbnw.net [69.63.178.183]) by core3.amsl.com (Postfix) with ESMTP id E1BA63A6868 for ; Sat, 17 Jul 2010 08:52:47 -0700 (PDT) Received: from [10.18.255.139] ([10.18.255.139:48979] helo=mail.thefacebook.com) by mta021.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 9F/28-17956-8D1D14C4; Sat, 17 Jul 2010 08:52:56 -0700 Received: from SC-MBX06.TheFacebook.com ([169.254.5.94]) by sc-hub03.TheFacebook.com ([fe80::1cfe:1f6b:8b35:cf7f%11]) with mapi; Sat, 17 Jul 2010 08:52:55 -0700 From: Luke Shepard To: Brian Eaton Thread-Topic: [OAUTH-WG] Change grant_type="none" to something less confusing Thread-Index: AcslLStlY2bWOda0k0GQasbZ66+p+QAQ5ccAACSCKIA= Date: Sat, 17 Jul 2010 15:52:55 +0000 Message-ID: References: <1279297826.11628.61.camel@localhost.localdomain> <3AF1FD6F-2178-42ED-833C-D93C534DDA8A@hueniverse.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <5d186609-3fc8-469b-b25c-1d7f5a34fdf7> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Jul 2010 15:52:48 -0000 Facebook does need to implement this - formerly the "client_cred" flow. We = need apps to be able to interact directly with the service without a user i= nvolved. As far as consistency, it is just a little weird to call it "client passwor= d" in one part of the spec, when it's defined as "client secret" elsewhere.= We wouldn't call it the "client secret" flow because the client secret is = used in other flows; I think the same argument applies to the term "client = password". How about just "client_only" ? Eran, I don't think I understand the other u= se cases you're talking about. On Jul 16, 2010, at 3:27 PM, Brian Eaton wrote: > I withdraw my question. David might not be interested in implementing > the client password flow, but he is certainly interested in > implementing other flows that involve the client password term. So > he's entitled to an opinion on what color the client password bike > shed should be painted. =3D) >=20 > (David, no offense, I'm just trying to stick by my guns on the whole > "stop screwing up the spec by merging separate use cases into single > flows" thing...) >=20 > On Fri, Jul 16, 2010 at 2:23 PM, Eran Hammer-Lahav = wrote: >> And that matters how? >>=20 >> EHL >>=20 >>=20 >>=20 >> On Jul 16, 2010, at 16:57, "Brian Eaton" wrote: >>=20 >>> On Fri, Jul 16, 2010 at 1:37 PM, David Recordon w= rote: >>>> I've always found "client password" to be a confusing term. >>>=20 >>> Are you going to support this flow at all...? >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sat Jul 17 11: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 A132B3A68AD for ; Sat, 17 Jul 2010 11:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.106, 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 6KZbZm6Qcfc0 for ; Sat, 17 Jul 2010 11:50:06 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 4AF833A67D3 for ; Sat, 17 Jul 2010 11:50:05 -0700 (PDT) Received: (qmail 31900 invoked from network); 17 Jul 2010 18:50:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Jul 2010 18:50:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 17 Jul 2010 11:50:17 -0700 From: Eran Hammer-Lahav To: Luke Shepard , Brian Eaton Date: Sat, 17 Jul 2010 11:50:15 -0700 Thread-Topic: [OAUTH-WG] Change grant_type="none" to something less confusing Thread-Index: AcslLStlY2bWOda0k0GQasbZ66+p+QAQ5ccAACSCKIAACHmbyw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8674977374B1eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Jul 2010 18:50:13 -0000 --_000_C8674977374B1eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The use case is pretty simple: the user uses the server and approves a thir= d party site access to their data directly (i.e. They are not sent to the s= erver from the client, but just use the server). The third part then uses t= heir client credentials to request a token. That token has access to whatev= er data was authorized previously by any user on the server side. This is s= till a client-only flow, but the grant isn't just for the client's own reso= urces, but to whatever has been authorized to that client. All I was trying to say was that when the client uses client credentials al= one, it can access resources beyond those under its control (i.e. Its own r= esources) if such grant was previously arranged. For example, I think FireE= agle had an API to ask if any of the users who authorized a client have cha= nged location since last time the client checked. That was done using a cli= ent-only token, but it provided some information about individual users (wh= ich one was updated). IOW, the client-credentials flow is not limited to cases where the client i= s also the resource owner. The client can also access other resources as au= thorized. EHL On 7/17/10 8:52 AM, "Luke Shepard" wrote: Facebook does need to implement this - formerly the "client_cred" flow. We = need apps to be able to interact directly with the service without a user i= nvolved. As far as consistency, it is just a little weird to call it "client passwor= d" in one part of the spec, when it's defined as "client secret" elsewhere.= We wouldn't call it the "client secret" flow because the client secret is = used in other flows; I think the same argument applies to the term "client = password". How about just "client_only" ? Eran, I don't think I understand the other u= se cases you're talking about. On Jul 16, 2010, at 3:27 PM, Brian Eaton wrote: > I withdraw my question. David might not be interested in implementing > the client password flow, but he is certainly interested in > implementing other flows that involve the client password term. So > he's entitled to an opinion on what color the client password bike > shed should be painted. =3D) > > (David, no offense, I'm just trying to stick by my guns on the whole > "stop screwing up the spec by merging separate use cases into single > flows" thing...) > > On Fri, Jul 16, 2010 at 2:23 PM, Eran Hammer-Lahav = wrote: >> And that matters how? >> >> EHL >> >> >> >> On Jul 16, 2010, at 16:57, "Brian Eaton" wrote: >> >>> On Fri, Jul 16, 2010 at 1:37 PM, David Recordon w= rote: >>>> I've always found "client password" to be a confusing term. >>> >>> Are you going to support this flow at all...? >>> _______________________________________________ >>> 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_C8674977374B1eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Change grant_type=3D"none" to something les= s confusing The use case is pretty simple: the user uses the server and approves = a third party site access to their data directly (i.e. They are not sent to= the server from the client, but just use the server). The third part then = uses their client credentials to request a token. That token has access to = whatever data was authorized previously by any user on the server side. Thi= s is still a client-only flow, but the grant isn’t just for the clien= t’s own resources, but to whatever has been authorized to that client= .

All I was trying to say was that when the client uses client credentials al= one, it can access resources beyond those under its control (i.e. Its own r= esources) if such grant was previously arranged. For example, I think FireE= agle had an API to ask if any of the users who authorized a client have cha= nged location since last time the client checked. That was done using a cli= ent-only token, but it provided some information about individual users (wh= ich one was updated).

IOW, the client-credentials flow is not limited to cases where the client i= s also the resource owner. The client can also access other resources as au= thorized.

EHL


On 7/17/10 8:52 AM, "Luke Shepard" <lshepard@facebook.com> wrote:

Facebook does need to implement this - form= erly the "client_cred" flow. We need apps to be able to interact = directly with the service without a user involved.

As far as consistency, it is just a little weird to call it "client pa= ssword" in one part of the spec, when it's defined as "client sec= ret" elsewhere. We wouldn't call it the "client secret" flow= because the client secret is used in other flows; I think the same argumen= t applies to the term "client password".

How about just "client_only" ? Eran, I don't think I understand t= he other use cases you're talking about.

On Jul 16, 2010, at 3:27 PM, Brian Eaton wrote:

> I withdraw my question.  David might not be interested in impleme= nting
> the client password flow, but he is certainly interested in
> implementing other flows that involve the client password term.  = So
> he's entitled to an opinion on what color the client password bike
> shed should be painted. =3D)
>
> (David, no offense, I'm just trying to stick by my guns on the whole > "stop screwing up the spec by merging separate use cases into sin= gle
> flows" thing...)
>
> On Fri, Jul 16, 2010 at 2:23 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>> And that matters how?
>>
>> EHL
>>
>>
>>
>> On Jul 16, 2010, at 16:57, "Brian Eaton" <beaton@google.com> wrote:
>>
>>> On Fri, Jul 16, 2010 at 1:37 PM, David Recordon <recordond@gmail.com> wrote:
>>>> I've always found "client password" to be a conf= using term.
>>>
>>> Are you going to support this flow at all...?
>>> _______________________________________________
>>> 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_C8674977374B1eranhueniversecom_-- From beaton@google.com Sat Jul 17 12:41:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEBA43A69CB for ; Sat, 17 Jul 2010 12:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.827 X-Spam-Level: X-Spam-Status: No, score=-105.827 tagged_above=-999 required=5 tests=[AWL=0.150, 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 qm0RYV4o6YqX for ; Sat, 17 Jul 2010 12:41:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 96C6E3A684F for ; Sat, 17 Jul 2010 12:41:42 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o6HJfsuP028779 for ; Sat, 17 Jul 2010 12:41:54 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279395715; bh=n4F6ibW23BuR4uGCWB2GuhCOncw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=P85CIWd6IPDFk+q8NkrrAAUNlYBbpRT9jRCOg4S5WnmK8HMOgkGZ7XlfQaadvgRYq 91fbG/Ju0XU3RwVElHBdg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=IzSGicfzxBh9inmiDdByn5y4vfTRkYmTTg8pNHcd+xplYv2abg33YlyTeMummp3GQ h7Ak8265bx2ij4GZKr5sA== Received: from pxi20 (pxi20.prod.google.com [10.243.27.20]) by kpbe20.cbf.corp.google.com with ESMTP id o6HJfruk000806 for ; Sat, 17 Jul 2010 12:41:53 -0700 Received: by pxi20 with SMTP id 20so1396140pxi.3 for ; Sat, 17 Jul 2010 12:41:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.134.13 with SMTP id h13mr3830257wfd.119.1279395713225; Sat, 17 Jul 2010 12:41:53 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sat, 17 Jul 2010 12:41:53 -0700 (PDT) In-Reply-To: References: Date: Sat, 17 Jul 2010 12:41:53 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Jul 2010 19:41:44 -0000 On Sat, Jul 17, 2010 at 11:50 AM, Eran Hammer-Lahav w= rote: > The use case is pretty simple: the user uses the server and approves a th= ird > party site access to their data directly (i.e. They are not sent to the > server from the client, but just use the server). The third part then use= s > their client credentials to request a token. That token has access to > whatever data was authorized previously by any user on the server side. T= his > is still a client-only flow, but the grant isn=92t just for the client=92= s own > resources, but to whatever has been authorized to that client. Let's pretend we're talking about a human user instead of an API client. The user enters their username, and their password. They get a token that can be used to access resources. Those might not be their resources; they might be viewing a friend's calendar, for example. Would you say calling that a "user password" profile would be misleading? Because the grant isn't just for the user's own resources? My guess is not. What we are doing with the client password profile is exactly equivalent. Except instead of a human user, we're dealing with an API client. Cheers, Brian From beaton@google.com Sat Jul 17 12:49: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 77EE23A69C9 for ; Sat, 17 Jul 2010 12:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.957 X-Spam-Level: X-Spam-Status: No, score=-101.957 tagged_above=-999 required=5 tests=[AWL=0.020, 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 LUa2W-5mztp7 for ; Sat, 17 Jul 2010 12:49:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7DF743A69C6 for ; Sat, 17 Jul 2010 12:49:02 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o6HJnEN6024287 for ; Sat, 17 Jul 2010 12:49:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279396154; bh=ANxl54tZ4awkOzzei5YdI/ntKWM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=KGeoJ36zchmNDGWW8119e5wA5o3S5QOwkOkCRVvBzk6J7kTR62w0Y2BoLyLp8LKn9 SdZbdRNOEx1OS2ijOMJjg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=yoaMHufRN4FmRbyat2urs967JNcpc3nLbQgjJD/al8FaClJjd3Ar5/g3rnpIBkaEm oSsalyeiBd1opXeKBJu6g== Received: from pxi19 (pxi19.prod.google.com [10.243.27.19]) by wpaz37.hot.corp.google.com with ESMTP id o6HJnCGB024557 for ; Sat, 17 Jul 2010 12:49:13 -0700 Received: by pxi19 with SMTP id 19so2004808pxi.40 for ; Sat, 17 Jul 2010 12:49:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.232.21 with SMTP id e21mr3915308wfh.92.1279396152426; Sat, 17 Jul 2010 12:49:12 -0700 (PDT) Received: by 10.142.193.19 with HTTP; Sat, 17 Jul 2010 12:49:12 -0700 (PDT) In-Reply-To: References: <1279297826.11628.61.camel@localhost.localdomain> <3AF1FD6F-2178-42ED-833C-D93C534DDA8A@hueniverse.com> Date: Sat, 17 Jul 2010 12:49:12 -0700 Message-ID: From: Brian Eaton To: Luke Shepard Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Jul 2010 19:49:06 -0000 On Sat, Jul 17, 2010 at 8:52 AM, Luke Shepard wrote: > As far as consistency, it is just a little weird to call it "client password" in one > part of the spec, when it's defined as "client secret" elsewhere. Agreed, we could be more consistent. The value we're talking about is the same in all of the flows, no sense in switching terminology. I prefer client_password, because "password", for me, evokes all the right kinds of security concerns. Password storage, encryption on the wire, etc... I'm less happy with client_secret, though I can certainly live with it. My main concern with client_secret is that people might confuse it with a signing secret. The value is not used for signing. If we are going to have flows where clients have secrets that are used for cryptographic authentication, then I would want to call those "keys" instead. > How about just "client_only" ? That would be fine by me. From eran@hueniverse.com Sat Jul 17 12:51: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 08ED23A69C8 for ; Sat, 17 Jul 2010 12:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 kz3S4-5Ax3f6 for ; Sat, 17 Jul 2010 12:51:58 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 241CA3A69C6 for ; Sat, 17 Jul 2010 12:51:58 -0700 (PDT) Received: (qmail 31702 invoked from network); 17 Jul 2010 19:52:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Jul 2010 19:52:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 17 Jul 2010 12:52:10 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Sat, 17 Jul 2010 12:51:54 -0700 Thread-Topic: [OAUTH-WG] Change grant_type="none" to something less confusing Thread-Index: Acsl6YqHbH1cJs5CSgawf+rpVY/XEA== Message-ID: <81CECB0D-6AFE-4E21-9211-86648FC6EAA8@hueniverse.com> References: <1279297826.11628.61.camel@localhost.localdomain> <3AF1FD6F-2178-42ED-833C-D93C534DDA8A@hueniverse.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Jul 2010 19:51:59 -0000 client_credentials worked fine before. I'll just replace none with that. No= one had an issue with the name in -05.=20 EHL On Jul 17, 2010, at 15:49, Brian Eaton wrote: > On Sat, Jul 17, 2010 at 8:52 AM, Luke Shepard wro= te: >> As far as consistency, it is just a little weird to call it "client pass= word" in one >> part of the spec, when it's defined as "client secret" elsewhere. >=20 > Agreed, we could be more consistent. The value we're talking about is > the same in all of the flows, no sense in switching terminology. >=20 > I prefer client_password, because "password", for me, evokes all the > right kinds of security concerns. Password storage, encryption on the > wire, etc... >=20 > I'm less happy with client_secret, though I can certainly live with > it. My main concern with client_secret is that people might confuse > it with a signing secret. The value is not used for signing. If we > are going to have flows where clients have secrets that are used for > cryptographic authentication, then I would want to call those "keys" > instead. >=20 >> How about just "client_only" ? >=20 > That would be fine by me. From dick.hardt@gmail.com Sat Jul 17 13:50:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EDB73A69E7 for ; Sat, 17 Jul 2010 13:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 bWIxV09pVhB8 for ; Sat, 17 Jul 2010 13:50:11 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 6D3C33A69E5 for ; Sat, 17 Jul 2010 13:50:11 -0700 (PDT) Received: by pvd12 with SMTP id 12so1781137pvd.31 for ; Sat, 17 Jul 2010 13:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=SHTtRo68pxekznSNs340Wi4c9GHC9JJEHn/RBxNHUKY=; b=VJHVhUv2qFVPbguZrbCk2jU3+fwoBJ8+gLxSHSR9Z+rBEIbmYEBKRE9PvR50pHnaUb WAgqWAiTdZuazZH4xxVU5Y5catH3U58iaSVaQjSog4KXbI4ktQMEpzVP+M//SBgHdlKR n7l4fXK7M7YptDKOu2oNs9PlaLl8p2g4mYQSw= 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=LH1GX88+tbdOM7ndq1hL9MAcQmwSiCWLOk3HJKKnAKaDkaQVlIfWlRnAvYyHO2PSAs I+hj1QZXHFpfVLmDTZZFeaXzoj6dtGDPqbnz6q1hB7zt9P5bUw8NRmN4Tib83jMFR4It E6r4FB2LX85my4STSoqLGX2W3Uz9hoJ+l761Y= Received: by 10.142.73.1 with SMTP id v1mr3792262wfa.171.1279399824211; Sat, 17 Jul 2010 13:50:24 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id g37sm14914797rvb.5.2010.07.17.13.50.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 17 Jul 2010 13:50:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <81CECB0D-6AFE-4E21-9211-86648FC6EAA8@hueniverse.com> Date: Sat, 17 Jul 2010 13:50:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <48172FA8-49B5-4589-9C52-7D302BD82BC0@gmail.com> References: <1279297826.11628.61.camel@localhost.localdomain> <3AF1FD6F-2178-42ED-833C-D93C534DDA8A@hueniverse.com> <81CECB0D-6AFE-4E21-9211-86648FC6EAA8@hueniverse.com> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Jul 2010 20:50:12 -0000 On 2010-07-17, at 12:51 PM, Eran Hammer-Lahav wrote: > client_credentials worked fine before. I'll just replace none with = that. No one had an issue with the name in -05.=20 +1 From andrewarnott@gmail.com Sat Jul 17 22:13: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 58EF03A68E9 for ; Sat, 17 Jul 2010 22:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.681, 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 fT5oSZcF6-t2 for ; Sat, 17 Jul 2010 22:13:00 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 622A13A68DA for ; Sat, 17 Jul 2010 22:13:00 -0700 (PDT) Received: by iwn38 with SMTP id 38so3821856iwn.31 for ; Sat, 17 Jul 2010 22:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=6GwoRh9CaNeBPAKNY9ETYqyGiBr8Q7/T7kI0A7EnaM0=; b=Wlg/BuGZhi158ZaBCqFzDGxNZMFB00lfgDKXzAVsDoKVNIplWaMROD2wSlPzcJofWj wx4mfAeStiIrqO/tsVmfMxZd+FedG9GpxJXTzYn5T0O3EuqgGiADEXPjiIjkapTZBj6q lmuOTgqCyPjm93otXXhczG2FLtIDD9iJCRlP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=f0TFIIpggJMP5/3+oPv7aZCkB3sdcVGSktxzYnFUCZdffkUaQlnnytUUxtq2WSUuyX SlMg5bjUXfn7ifYSw9xE7vWjpkzNhsiFCBhf/mc1Pw3hhQ2sm5HrvrKdJfifXlnOp7jU hqaA9bk2x28XppWSCYvqpcJjABp3TapkF4dBk= MIME-Version: 1.0 Received: by 10.231.119.229 with SMTP id a37mr2724035ibr.169.1279429993320; Sat, 17 Jul 2010 22:13:13 -0700 (PDT) Received: by 10.231.154.199 with HTTP; Sat, 17 Jul 2010 22:13:13 -0700 (PDT) Date: Sat, 17 Jul 2010 22:13:13 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=001636920ccf444fec048ba2829f Subject: [OAUTH-WG] Section 2.1 Client Password Credentials missing normative form X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Jul 2010 05:13:02 -0000 --001636920ccf444fec048ba2829f Content-Type: text/plain; charset=ISO-8859-1 Section 2.1 of draft 10 lacks a normative form definition of the client_id parameter. It appears only in the example, which itself contains parts not discussed until later in the spec, which some may find confusing. It is also not clear (to me) whether client_id must appear in the POST entity when it appears in the HTTP Basic authorization header since there is no discussion of it. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --001636920ccf444fec048ba2829f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Section 2.1 of draft 10 lacks a normative form definition of the client_id = parameter. =A0It appears only in the example, which itself contains parts n= ot discussed until later in the spec, which some may find confusing. =A0It = is also not clear (to me) whether client_id must appear in the POST entity = when it appears in the HTTP Basic authorization header since there is no di= scussion of it.

--
Andrew Arnott
"I [may] not agree with what = you have to say, but I'll defend to the death your right to say it.&quo= t; - S. G. Tallentyre
--001636920ccf444fec048ba2829f-- From torsten@lodderstedt.net Sun Jul 18 06:12: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 D06D13A6844 for ; Sun, 18 Jul 2010 06:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.107, 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 8+K99EtEmfZQ for ; Sun, 18 Jul 2010 06:12:22 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by core3.amsl.com (Postfix) with ESMTP id 7AA693A68B8 for ; Sun, 18 Jul 2010 06:12:21 -0700 (PDT) Received: from p4ffd3f9f.dip.t-dialin.net ([79.253.63.159] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OaTfU-0001MG-Dm; Sun, 18 Jul 2010 15:12:32 +0200 Message-ID: <4C42FDB6.6040501@lodderstedt.net> Date: Sun, 18 Jul 2010 15:12:22 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brian Eaton References: <4C3E2DDA.3070905@lodderstedt.net> <4C3E30C4.8090901@lodderstedt.net> <4C3E3326.6020401@lodderstedt.net> <4C3EA46B.7070703@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Jul 2010 13:12:22 -0000 Am 15.07.2010 08:25, schrieb Brian Eaton: > On Wed, Jul 14, 2010 at 11:02 PM, Torsten Lodderstedt > wrote: > >> why that? If there will be a signature proposal for resource server access, >> the same (simplified?) model could be applied to the authz server's API. >> > Sure. Other folks have used signed URLs in this kind of protocol as > well: http://developer.yahoo.com/bbauth/user.html. > > Why not write up your proposal as an alternate flow (right next to > "user-agent" and "web-server") and see whether other people will > implement it? > I already proposed such an alternative flow (http://www.ietf.org/mail-archive/web/oauth/current/msg02112.html), but did not gain support. I probably will give it another try once the WG reached consensus regading a new signature mechanism. It's not my current focus. There are more important open issue, e.g. scope definition, resource server identification, and token revocation. I just contributed my honest opinion to Eran's survey :-) regards, Torsten. From torsten@lodderstedt.net Sun Jul 18 08: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 CCD813A6934 for ; Sun, 18 Jul 2010 08:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYdSEzTfsxx8 for ; Sun, 18 Jul 2010 08:19:58 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id BFE0C3A6926 for ; Sun, 18 Jul 2010 08:19:57 -0700 (PDT) Received: from p4ffd3f9f.dip.t-dialin.net ([79.253.63.159] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OaVez-0000EB-MA; Sun, 18 Jul 2010 17:20:09 +0200 Message-ID: <4C431BA3.2000907@lodderstedt.net> Date: Sun, 18 Jul 2010 17:20:03 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Dirk Balfanz References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040105000905070104040108" X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] signatures, v2 X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Jul 2010 15:19:59 -0000 This is a multi-part message in MIME format. --------------040105000905070104040108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dirk, I have some questions concerning your proposal: - As far as I understand, the difference to "magic signatures" lays in the usage of a JSON token carrying issuer, not_before, not_after and audience. While such properties are important for security tokens (assertions), I cannot see an advantage of using this format for signatures of HTTP requests. Would you please explain? - Key management From my point of view, your proposal does cover key management for web applications using RSA signatures. What about web applications intending to sign resource server requests using HMAC (for performance reasons)? Do they need to exchange secrets with the resource server? What about installed applications (mobile, desktop, set top boxes, gaming devices)? 1) RSA: Do they need to provide their public key on a web server? This would be an additional requirement for such applications. 2) HMAC: Same as for web apps, but even harder because either (a) the installed app has a static secret burned into source code or (b) it needs to use a protocol for dynamic key management the resource server has to implement. Is this the plan? Remark on (https://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4): "To obtain an HMAC verification key, the client has to exchange, in an out-of-band fashion, shared keys with the issuer." I assume "client" should be "verifier", shouldn't it? regards, Torsten. Am 16.07.2010 02:43, schrieb Dirk Balfanz: > Hi guys, > > after reading through the feedback, we did a pass over the OAuth > signature proposals. > > As a reminder, there are three documents: > > - a document (called "JSON Tokens") that just explains how to sign > something and verify the signature: > http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > > - an extension of JSON Tokens that can be used for signed OAuth tokens: > http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU > > - a different extension of JSON Tokens that can be used whenever the > spec calls for an "assertion": > http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc > (When used in the assertion flow, this last token can also be used to > do "2-legged" OAuth) > > A summary of the (scant) changes: > > - we spelled out what we mean by RSA-SHA256.* Ben Laurie *- can you > double-check that that sounds good? > - we decided on unpadded websafe-base64 throughout. > - some changes to parameter names. > - some small changes I might be forgetting now... > > As explained in my message to the previous thread, there is still no > envelope in there to help with encrypted tokens (b/c we don't > understand well enough what the envelopes for encrypted tokens would > look like). > > One question: What's the deal with having the signature go first? If > you can explain to me why that is a good idea, I'm happy to oblige. > > Cheers, > > Dirk & Marius. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------040105000905070104040108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Dirk,

I have some questions concerning your proposal:

- As far as I understand, the difference to "magic signatures" lays in the usage of a JSON token carrying issuer, not_before, not_after and audience. While such properties are important for security tokens (assertions), I cannot see an advantage of using this format for signatures of HTTP requests. Would you please explain?

- Key management
>From my point of view, your proposal does cover key management for web applications using RSA signatures. What about web applications intending to sign resource server requests using HMAC (for performance reasons)? Do they need to exchange secrets with the resource server?

What about installed applications (mobile, desktop, set top boxes, gaming devices)?
 1) RSA: Do they need to provide their public key on a web server? This would be an additional requirement for such applications.
 2) HMAC: Same as for web apps, but even harder because either (a) the installed app has a static secret burned
into source code or (b) it needs to use a protocol for dynamic key management the resource server has to implement. Is this the plan?

Remark on (https://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4):
"To obtain an HMAC verification key, the client has to exchange, in an out-of-band fashion, shared keys with the issuer."

I assume "client" should be "verifier", shouldn't it?

regards,
Torsten.

Am 16.07.2010 02:43, schrieb Dirk Balfanz:
Hi guys, 

after reading through the feedback, we did a pass over the OAuth signature proposals.

As a reminder, there are three documents:

- a document (called "JSON Tokens") that just explains how to sign something and verify the signature:
- an extension of JSON Tokens that can be used for signed OAuth tokens:

- a different extension of JSON Tokens that can be used whenever the spec calls for an "assertion":
http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc
(When used in the assertion flow, this last token can also be used to do "2-legged" OAuth)

A summary of the (scant) changes:

- we spelled out what we mean by RSA-SHA256. Ben Laurie - can you double-check that that sounds good?
- we decided on unpadded websafe-base64 throughout.
- some changes to parameter names.
- some small changes I might be forgetting now...

As explained in my message to the previous thread, there is still no envelope in there to help with encrypted tokens (b/c we don't understand well enough what the envelopes for encrypted tokens would look like). 

One question: What's the deal with having the signature go first? If you can explain to me why that is a good idea, I'm happy to oblige.

Cheers,

Dirk & Marius.

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------040105000905070104040108-- From torsten@lodderstedt.net Sun Jul 18 08:48: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 2C04D3A695A for ; Sun, 18 Jul 2010 08:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgAHWhzMZ8-k for ; Sun, 18 Jul 2010 08:48:46 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by core3.amsl.com (Postfix) with ESMTP id D99D03A6979 for ; Sun, 18 Jul 2010 08:48:45 -0700 (PDT) Received: from p4ffd3f9f.dip.t-dialin.net ([79.253.63.159] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OaW6r-00051q-22; Sun, 18 Jul 2010 17:48:57 +0200 Message-ID: <4C432262.40204@lodderstedt.net> Date: Sun, 18 Jul 2010 17:48:50 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brian Campbell References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000504090804060900080302" X-Df-Sender: 141509 Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Jul 2010 15:48:48 -0000 This is a multi-part message in MIME format. --------------000504090804060900080302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Brian, thank you for taking the effort to write this I-D. I have the following remarks: Why do you prescribe to include the token endpoint URL into the SubjectConfirmationData and similar data also in the AudienceRestriction? I would expect such data in the AudienceRestriction only. Why do you prohibit NotBefore-Attributes? What the reason for that statement? "If the assertion was issued with the intention that the client act autonomously on behalf of the subject, an SHOULD NOT be included." Do you expect the OAuth authorization server to authenticate the client anyway? Your I-D states: "The authorization server MUST ensure that bearer assertions are not replayed, by maintaining the set of used ID values for the length of time for which the assertion would be considered valid based on the NotOnOrAfter attribute in the ." Why do you want to force a one-time usage for SAML assertions? This is to restrictive, in my opinion. Any issuing authority could enforce such a policy by using the "OneTimeUse" element. 2.3. Error Response: I would suggest to return a 401 status code for invalid assertions since I see them as invalid credentials. regards, Torsten. Am 15.07.2010 22:50, schrieb Brian Campbell: > I'm gong to join the growing list of people attaching a potential I-D > to an email due to he cut off time for the I-D submissions. Attached > is a draft that aims to tightly define the particular format of a SAML > 2.0 bearer assertion in requesting an access token using the assertion > grant_type. I've been working with Chuck at Salesforce.com on this > and the primary goal is to have some documentation or specification > that is sufficient to facilitate interoperability between > independently developed implementations or products. This, of > course, wouldn't preclude using SAML in other ways - it would only > provide one concrete definition to implement against. > > I intend to submit this as an I-D when the submission process reopens. > Any feedback from this group would be appreciated as well as > thoughts about this eventually becoming a working group draft. > > Thanks, > Brian Campbell > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------000504090804060900080302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Brian,

thank you for taking the effort to write this I-D.

I have the following remarks:

Why do you prescribe to include the token endpoint URL into the SubjectConfirmationData and similar data also in the AudienceRestriction? I would expect such data in the AudienceRestriction only.

Why do you prohibit NotBefore-Attributes?

What the reason for that statement? "If the assertion was issued with the intention that the client act autonomously on behalf of the subject, an <AuthnStatement> SHOULD NOT be included." Do you expect the OAuth authorization server to authenticate the client anyway?

Your I-D states:
"The authorization server MUST ensure that bearer assertions are
      not replayed, by maintaining the set of used ID values for the
      length of time for which the assertion would be considered valid
      based on the NotOnOrAfter attribute in the
      <SubjectConfirmationData>."

Why do you want to force a one-time usage for SAML assertions? This is to restrictive, in my opinion. Any issuing authority could enforce such a policy by using the "OneTimeUse" element.
 
2.3.  Error Response: I would suggest to return a 401 status code for invalid assertions since I see them as invalid credentials.

regards,
Torsten.

Am 15.07.2010 22:50, schrieb Brian Campbell: 
I'm gong to join the growing list of people attaching a potential I-D
to an email due to he cut off time for the I-D submissions.  Attached
is a draft that aims to tightly define the particular format of a SAML
2.0 bearer assertion in requesting an access token using the assertion
grant_type.   I've been working with Chuck at Salesforce.com on this
and the primary goal is to have some documentation or specification
that is sufficient to facilitate interoperability between
independently developed implementations or products.    This, of
course, wouldn't preclude using SAML in other ways - it would only
provide one concrete definition to implement against.

I intend to submit this as an I-D when the submission process reopens.
  Any feedback from this group would be appreciated as well as
thoughts about this eventually becoming a working group draft.

Thanks,
Brian Campbell
  

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------000504090804060900080302-- From bcampbell@pingidentity.com Sun Jul 18 21:35: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 041893A6783 for ; Sun, 18 Jul 2010 21:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.806 X-Spam-Level: X-Spam-Status: No, score=-5.806 tagged_above=-999 required=5 tests=[AWL=0.171, 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 x2R9mrvy6s55 for ; Sun, 18 Jul 2010 21:35:24 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by core3.amsl.com (Postfix) with SMTP id 7CA8D3A63C9 for ; Sun, 18 Jul 2010 21:35:19 -0700 (PDT) Received: from source ([209.85.161.44]) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTEPWFMshA1R9vbMV1qSidivvVGYiK7v1@postini.com; Sun, 18 Jul 2010 21:35:34 PDT Received: by fxm1 with SMTP id 1so2225505fxm.17 for ; Sun, 18 Jul 2010 21:35:31 -0700 (PDT) Received: by 10.223.122.194 with SMTP id m2mr3145431far.85.1279514107101; Sun, 18 Jul 2010 21:35:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.105.135 with HTTP; Sun, 18 Jul 2010 21:34:37 -0700 (PDT) In-Reply-To: <4C432262.40204@lodderstedt.net> References: <4C432262.40204@lodderstedt.net> From: Brian Campbell Date: Sun, 18 Jul 2010 22:34:37 -0600 Message-ID: To: Torsten Lodderstedt , oauth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 04:35:26 -0000 Torsten, Thanks for taking the time to review and comment. I've tried to address your questions inline below (though in some cases only raising more questions). On Sun, Jul 18, 2010 at 9:48 AM, Torsten Lodderstedt wrote: > Why do you prescribe to include the token endpoint URL into the > SubjectConfirmationData and similar data also in the AudienceRestriction?= I > would expect such data in the AudienceRestriction only. One of the primary motivators behind much of this document was wanting to align the assertion format and processing rules as much as was reasonable with requirements in SAML Web SSO. The seemingly redundant data in Reciepent of SubjectConfirmationData and in the AudienceRestriction is very similar to what is required in Web SSO. That's the main reason they are both there. However, there is a subtle distinction between the two - the SubjectConfirmationData/Recipient identifies the endpoint to which the assertion can be delivered (where) and the Audience identifies the more general entity to whom it can be delivered (who). In general practice the two are tightly coupled but they need not necessarily be. > Why do you prohibit NotBefore-Attributes? Again trying to follow what was done in Web SSO - the prohibition of the NotBefore in SubjectConfirmationData was taken directly from section 4.1.4.2 of saml-profiles-2.0-os. Honestly, I've never understood the reason for the restriction and really the reason I had it here was just to mimic web sso in the hope of facilitating better reuse of existing software. Anyway, that was my reasoning but I woudn't be opposed to removing that language from this document. Regardless which way we go with that - note that the use of a NotBefore attribute is allowed in the Conditions element. > What the reason for that statement? "If the assertion was issued with the > intention that the client act autonomously on behalf of the subject, an > SHOULD NOT be included." Do you expect the OAuth > authorization server to authenticate the client anyway? Client authentication to the authorization server is an orthogonal concern. This is about the subject of the assertion (which may be the client but probably won't be in most cases) authenticating with the issuer of the assertion. It seems like there are cases where the end user (or subject) is present during the transaction and will have authenticated directly with the issuer of the assertion. But there may also be cases where the end user is not present and the client is trusted to act on their behalf. That bullet and the one before it that says, "If the assertion issuer authenticated the subject, the assertion SHOULD contain a single representing that authentication event" were intended to try and accommodate those two situations and provide a way to tell the difference based on the content of the assertion. It also just seemed like the "right" thing to do - if the issuer authenticated the subject, say so in the assertion. If not, say nothing about it in the assertion. > Your I-D states: > "The authorization server MUST ensure that bearer assertions are > =A0=A0=A0=A0=A0 not replayed, by maintaining the set of used ID values fo= r the > =A0=A0=A0=A0=A0 length of time for which the assertion would be considere= d valid > =A0=A0=A0=A0=A0 based on the NotOnOrAfter attribute in the > =A0=A0=A0=A0=A0 ." > > Why do you want to force a one-time usage for SAML assertions? > This is to restrictive, in my opinion. This is also a carryover from web SSO via the POST binding. I was actually leaning towards not including this language but a couple early reviews were interesting in having it in there. My co-author on this draft, Mr. Chuck Mortimore, was one of those folks so maybe he could provide more insight into his reasoning there. Chuck? > Any issuing authority could enforce such a > policy by using the "OneTimeUse" element. Personally, I've always found the spec language around OneTimeUse to be confusing and somewhat ambiguous. Maybe I'm wrong but take a look at "2.5.1.5 Element " and the treatment of OneTimeUse in "2.5.1 Element " of saml-core-2.0-os. There are parts of that language that do suggest OneTimeUse is intended to indicate that some replay check is required but other parts seem to say something entirely different. I don't believe that OneTimeUse is widely used or supported. > 2.3.=A0 Error Response: I would suggest to return a 401 status code for > invalid assertions since I see them as invalid credentials. That's a good point. I had 400 largely as a copy/paste error from another example. However, as I take a closer look at the text in draft -10 of the core OAuth spec, it would seem that it prescribes a 400 for this case. Section "4.3. Error Response" says, "If the client provided invalid credentials using an HTTP authentication scheme via the "Authorization" request header field, the authorization server MUST respond with the HTTP 401 (Unauthorized) status code. Otherwise, the authorization server SHALL respond with the HTTP 400 (Bad Request) status code." -- http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.3 Now I'm not sure which makes sense. Is it really an HTTP Unauthorized? It's not an HTTP authentication that is failing but rather a higher level protocol. Maybe this is a question to be addressed at the core spec level? I might just drop the example I have in section 2.3 of this document and defer completed to the core spec :) -Brian BTW, I referenced the SAML specs a few times in this email and should say that http://saml.xml.org/saml-specifications is a nice place to find all the OASIS SAML specs, including the latest errata, in one place. From wmills@yahoo-inc.com Mon Jul 19 08:58: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 8DB583A6914 for ; Mon, 19 Jul 2010 08:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.164 X-Spam-Level: X-Spam-Status: No, score=-17.164 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCx58MKTKJeS for ; Mon, 19 Jul 2010 08:58:33 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 70F483A688F for ; Mon, 19 Jul 2010 08:58:33 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6JFwcf3012528; Mon, 19 Jul 2010 08:58:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=WdaN5lfA2n+y5fMD8BaRe5Z4DF5cV+gaaQRAd4e7EB+Xa8VbCyes4PXmy5wBt2r0 Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 08:58:38 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Jul 2010 08:58:36 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6D4F@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <4C41A281.7080809@lodderstedt.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Alternative Upgrade Flow Thread-Index: Acslq/9X9MKrbFU2R8aX7gJxE3xkjQBrxDBA References: <1279298904.11628.74.camel@localhost.localdomain> <4C41A281.7080809@lodderstedt.net> From: "William Mills" To: "Torsten Lodderstedt" , "Justin Richer" X-OriginalArrivalTime: 19 Jul 2010 15:58:38.0395 (UTC) FILETIME=[4044D0B0:01CB275B] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Alternative Upgrade Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:58:34 -0000 Seems like we could also simply put up a 1.0a PR that issues a 2.0 token. That avoids wedging 1.0 stuff into 2.0.=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Torsten Lodderstedt > Sent: Saturday, July 17, 2010 5:31 AM > To: Justin Richer > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Alternative Upgrade Flow >=20 > I think we gonna need additional end points anyway, e.g. for=20 > token revocation. So why not use another endpoint for that=20 > purpose? That way the tokens endpoint is not overloaded to much. >=20 > regards, > Torsten. >=20 > Am 16.07.2010 18:48, schrieb Justin Richer: > > The current proposal for a 1.0->2.0 upgrade flow is to use the=20 > > assertion profile and pass the OAuth token in there. Instead, one=20 > > could create an endpoint that speaks the 1.0 protocol fully,=20 > > signatures and client secrets and everything, but issues=20 > 2.0 tokens,=20 > > JSON and all. It's a hybridized endpoint also, but put=20 > together with=20 > > the opposite pieces. In both cases, you put a 1.0 token in=20 > one end and=20 > > get a 2.0 token out the other. But in this case, the request being=20 > > made is a completely vanilla OAuth 1.0 protected resource=20 > access request. > > > > Does this really need a separate endpoint, or can we extend the=20 > > grant_type options to include "oath1.0" in an extension? I=20 > know that=20 > > extensions aren't currently allowed to make new grant_types=20 > -- I think=20 > > they should be able to and and proposing that we allow that=20 > extension=20 > > point. I dislike the reasoning of "just cram it all into an=20 > assertion=20 > > to extend", since it doesn't allow for clients to separate=20 > out their=20 > > parameters easily. > > > > -- Justin > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From jricher@mitre.org Mon Jul 19 10:17: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 DA3563A67D4 for ; Mon, 19 Jul 2010 10:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 975HZpF1ZF70 for ; Mon, 19 Jul 2010 10:16:59 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 2CCA43A6781 for ; Mon, 19 Jul 2010 10:16:59 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6JHHCUi007893 for ; Mon, 19 Jul 2010 13:17:12 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6JHHCXb007890; Mon, 19 Jul 2010 13:17:12 -0400 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, 19 Jul 2010 13:17:11 -0400 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: <81CECB0D-6AFE-4E21-9211-86648FC6EAA8@hueniverse.com> References: <1279297826.11628.61.camel@localhost.localdomain> <3AF1FD6F-2178-42ED-833C-D93C534DDA8A@hueniverse.com> <81CECB0D-6AFE-4E21-9211-86648FC6EAA8@hueniverse.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 19 Jul 2010 13:17:11 -0400 Message-ID: <1279559831.6181.17.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 17:17:00 -0000 "client_credentials" is fine with me for the name of this grant type. I'd also like the paragraph describing its use to be pulled out into a subsection, to be parallel with all the other grant types. -- Justin On Sat, 2010-07-17 at 15:51 -0400, Eran Hammer-Lahav wrote: > client_credentials worked fine before. I'll just replace none with that. No one had an issue with the name in -05. > > EHL > > > > On Jul 17, 2010, at 15:49, Brian Eaton wrote: > > > On Sat, Jul 17, 2010 at 8:52 AM, Luke Shepard wrote: > >> As far as consistency, it is just a little weird to call it "client password" in one > >> part of the spec, when it's defined as "client secret" elsewhere. > > > > Agreed, we could be more consistent. The value we're talking about is > > the same in all of the flows, no sense in switching terminology. > > > > I prefer client_password, because "password", for me, evokes all the > > right kinds of security concerns. Password storage, encryption on the > > wire, etc... > > > > I'm less happy with client_secret, though I can certainly live with > > it. My main concern with client_secret is that people might confuse > > it with a signing secret. The value is not used for signing. If we > > are going to have flows where clients have secrets that are used for > > cryptographic authentication, then I would want to call those "keys" > > instead. > > > >> How about just "client_only" ? > > > > That would be fine by me. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Mon Jul 19 10:37:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C177C3A6B39 for ; Mon, 19 Jul 2010 10:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.563 X-Spam-Level: X-Spam-Status: No, score=-105.563 tagged_above=-999 required=5 tests=[AWL=0.414, 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 59eolvKPUimf for ; Mon, 19 Jul 2010 10:37:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BEEAF3A6958 for ; Mon, 19 Jul 2010 10:37:35 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o6JHbnIJ020737 for ; Mon, 19 Jul 2010 10:37:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279561070; bh=E6jTwqbKdKDpjoTV4TegKO6qBt8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=diDeFO5etOdCFeVr6I7z6T5tDSQribsVpKlTRlkZVkWoYiBWir49ZT/labuJr6a7i Fehxtqmi+iFKm0y687+IA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=ypRZ8fxCzkq8HYqFAiISgJIsD//jKgOWU7N1liGq/MIiv722t0+FbIOjyQ6s4nLxf IFI9iS41m1jYc3sIMmBog== Received: from yxk8 (yxk8.prod.google.com [10.190.3.136]) by kpbe12.cbf.corp.google.com with ESMTP id o6JHbmvR027213 for ; Mon, 19 Jul 2010 10:37:48 -0700 Received: by yxk8 with SMTP id 8so1465857yxk.2 for ; Mon, 19 Jul 2010 10:37:48 -0700 (PDT) Received: by 10.101.144.11 with SMTP id w11mr5126261ann.236.1279561066252; Mon, 19 Jul 2010 10:37:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.33.1 with HTTP; Mon, 19 Jul 2010 10:37:26 -0700 (PDT) In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B6D4F@SNV-EXVS08.ds.corp.yahoo.com> References: <1279298904.11628.74.camel@localhost.localdomain> <4C41A281.7080809@lodderstedt.net> <012AB2B223CB3F4BB846962876F47217059B6D4F@SNV-EXVS08.ds.corp.yahoo.com> From: Marius Scurtescu Date: Mon, 19 Jul 2010 10:37:26 -0700 Message-ID: To: William Mills 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] Alternative Upgrade Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 17:37:36 -0000 On Mon, Jul 19, 2010 at 8:58 AM, William Mills wrote= : > Seems like we could also simply put up a 1.0a PR that issues a 2.0 > token. =A0That avoids wedging 1.0 stuff into 2.0. That's exactly what the bridge endpoint is doing. Marius From zachary.zeltsan@alcatel-lucent.com Mon Jul 19 10:52:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28C223A6809 for ; Mon, 19 Jul 2010 10:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqGrOjXBAAtw for ; Mon, 19 Jul 2010 10:52:09 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id D91223A6803 for ; Mon, 19 Jul 2010 10:52:08 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o6JHqHtO018557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 12:52:18 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6JHqF2m020959; Mon, 19 Jul 2010 12:52:17 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 19 Jul 2010 12:52:04 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Eran Hammer-Lahav'" , Brian Eaton Date: Mon, 19 Jul 2010 12:52:03 -0500 Thread-Topic: [OAUTH-WG] Change grant_type="none" to something less confusing Thread-Index: AcslNgtqPxJK3RFmTOW5ykAWUzOQ/gCMx3og Message-ID: <5710F82C0E73B04FA559560098BF95B124F9688DDC@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <1279297826.11628.61.camel@localhost.localdomain> <5F922BD8-22C9-4E87-9D5B-BAC0529F94C7@hueniverse.com> <32537D24-A84A-482C-8B9B-ECA14CB5325C@hueniverse.com> In-Reply-To: <32537D24-A84A-482C-8B9B-ECA14CB5325C@hueniverse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 17:52:10 -0000 I am not aware of the use cases where the client credentials flow is used f= or authenticating anything, but a client. But the flow is used for authoriz= ing access to the resources other than those owned by a client. >From OAuth2.0 -05.txt: The client credentials flow is used when the client acts on behalf of itself (the client is the resource owner), or when the client credentials are used to obtain an access token representing a previously established access authorization. I am for the initial proposal to replace "none". Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, July 16, 2010 6:27 PM To: Brian Eaton Cc: OAuth WG Subject: Re: [OAUTH-WG] Change grant_type=3D"none" to something less confus= ing The client authentication can be used to retrieve a grant previously arrang= ed. While the grant is linked to the client, it is not always about the cli= ent's resources. Calling it 'client' implies it is about the client's resou= rces.=20 EHL On Jul 16, 2010, at 18:19, Brian Eaton wrote: > On Fri, Jul 16, 2010 at 2:25 PM, Eran Hammer-Lahav = wrote: >> External, out-of-band, implicit. >>=20 >> It cannot be client because that is not always the case. >=20 > Can you point to a use case where someone is going to use the client > password flow to authenticate something besides a client? >=20 > Because I'm pretty sure that use case is crazy, and can safely be ignored= . _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Mon Jul 19 14:31: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 EA5F53A6B7A for ; Mon, 19 Jul 2010 14:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.83 X-Spam-Level: X-Spam-Status: No, score=-105.83 tagged_above=-999 required=5 tests=[AWL=0.147, 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 4ZFt1g7yFPWr for ; Mon, 19 Jul 2010 14:31:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1A7C43A6B85 for ; Mon, 19 Jul 2010 14:30:52 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o6JLUt2O006402 for ; Mon, 19 Jul 2010 14:30:56 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279575056; bh=3napwc2+42nuquwMcBZGu7h9cBE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ucucH6ZTZcFe3UXdK9Jg35w/4uoO0rHU9qa8EqmLN3+UpnUfEAi/lBY3HW7l558T8 /uury5zEuoKBgxWB2QZTA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=aQr/2DSSLp8nrRWQr0xkQkGo4DidLRt5WfJmKeQtu689FH2xww6ra+DDh5E1RjGzy 0wKmHUJtMduR3tQn39bjQ== Received: from pxi11 (pxi11.prod.google.com [10.243.27.11]) by hpaq5.eem.corp.google.com with ESMTP id o6JLUrYJ008494 for ; Mon, 19 Jul 2010 14:30:54 -0700 Received: by pxi11 with SMTP id 11so2467354pxi.21 for ; Mon, 19 Jul 2010 14:30:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.177.21 with SMTP id z21mr1778666wfe.160.1279575043608; Mon, 19 Jul 2010 14:30:43 -0700 (PDT) Received: by 10.143.132.1 with HTTP; Mon, 19 Jul 2010 14:30:43 -0700 (PDT) In-Reply-To: <1279559831.6181.17.camel@localhost.localdomain> References: <1279297826.11628.61.camel@localhost.localdomain> <3AF1FD6F-2178-42ED-833C-D93C534DDA8A@hueniverse.com> <81CECB0D-6AFE-4E21-9211-86648FC6EAA8@hueniverse.com> <1279559831.6181.17.camel@localhost.localdomain> Date: Mon, 19 Jul 2010 14:30:43 -0700 Message-ID: From: Brian Eaton To: Justin Richer 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] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 21:31:03 -0000 client credentials works for me as well. On Mon, Jul 19, 2010 at 10:17 AM, Justin Richer wrote: > "client_credentials" is fine with me for the name of this grant type. > I'd also like the paragraph describing its use to be pulled out into a > subsection, to be parallel with all the other grant types. > > =A0-- Justin > > On Sat, 2010-07-17 at 15:51 -0400, Eran Hammer-Lahav wrote: >> client_credentials worked fine before. I'll just replace none with that.= No one had an issue with the name in -05. >> >> EHL >> >> >> >> On Jul 17, 2010, at 15:49, Brian Eaton wrote: >> >> > On Sat, Jul 17, 2010 at 8:52 AM, Luke Shepard = wrote: >> >> As far as consistency, it is just a little weird to call it "client p= assword" in one >> >> part of the spec, when it's defined as "client secret" elsewhere. >> > >> > Agreed, we could be more consistent. =A0The value we're talking about = is >> > the same in all of the flows, no sense in switching terminology. >> > >> > I prefer client_password, because "password", for me, evokes all the >> > right kinds of security concerns. =A0Password storage, encryption on t= he >> > wire, etc... >> > >> > I'm less happy with client_secret, though I can certainly live with >> > it. =A0My main concern with client_secret is that people might confuse >> > it with a signing secret. =A0The value is not used for signing. =A0If = we >> > are going to have flows where clients have secrets that are used for >> > cryptographic authentication, then I would want to call those "keys" >> > instead. >> > >> >> How about just "client_only" ? >> > >> > That would be fine by me. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > From balfanz@google.com Mon Jul 19 17:22:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E52E3A6BA5 for ; Mon, 19 Jul 2010 17:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.726 X-Spam-Level: X-Spam-Status: No, score=-105.726 tagged_above=-999 required=5 tests=[AWL=0.250, 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 AbcW2dxcn5fs for ; Mon, 19 Jul 2010 17:22:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8F8773A6838 for ; Mon, 19 Jul 2010 17:22:31 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o6K0MivG009512 for ; Mon, 19 Jul 2010 17:22:44 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279585364; bh=jWyeg0QamOmWOwfDUx7CDeKSrcU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=i+px1sAhZLW8iaof0do1R9CpxHdU1ITfYShR3fIO3mUKf11T8VbgVGdhBCgE68Ygh Lg2fZcnozWjiYCSdG8FkA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=e0mHl3+QEhGiD+fC/vzCZhxmGCLD9YLHr92MIo6rpItoO8+Li4dIcaCN2hpplMO6X SKJ6vGGeL/R53LnBU/p9Q== Received: from iwn41 (iwn41.prod.google.com [10.241.68.105]) by wpaz13.hot.corp.google.com with ESMTP id o6K0Mh9N026352 for ; Mon, 19 Jul 2010 17:22:43 -0700 Received: by iwn41 with SMTP id 41so6845629iwn.2 for ; Mon, 19 Jul 2010 17:22:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.152.143 with SMTP id g15mr6719058ibw.76.1279585362659; Mon, 19 Jul 2010 17:22:42 -0700 (PDT) Received: by 10.231.130.9 with HTTP; Mon, 19 Jul 2010 17:22:42 -0700 (PDT) In-Reply-To: <4C431BA3.2000907@lodderstedt.net> References: <4C431BA3.2000907@lodderstedt.net> Date: Mon, 19 Jul 2010 17:22:42 -0700 Message-ID: From: Dirk Balfanz To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001636d34573004bb3048bc6af4c X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] signatures, v2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 00:22:33 -0000 --001636d34573004bb3048bc6af4c Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Dirk, > > I have some questions concerning your proposal: > > - As far as I understand, the difference to "magic signatures" lays in the > usage of a JSON token carrying issuer, not_before, not_after and audience. > While such properties are important for security tokens (assertions), I > cannot see an advantage of using this format for signatures of HTTP > requests. Would you please explain? > You mean advantage over magic signatures? It's really a similar idea - it's just that magic signatures as is don't quite fit the bill. For example, they have newlines in them: http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html#anchor5 > - Key management > From my point of view, your proposal does cover key management for web > applications using RSA signatures. What about web applications intending to > sign resource server requests using HMAC (for performance reasons)? Do they > need to exchange secrets with the resource server? > Correct - I'm not saying how HMAC keys are being distributed. Presumably, you would use a similar system to what many platform providers use today - you sign up as a developer, and they give you a "developer key" (or "API key"). > What about installed applications (mobile, desktop, set top boxes, gaming > devices)? > I don't think that installed apps can ever authenticate themselves (i.e., prove the statement "I am a copy of the FooBar app"), so I'm not trying to solve that. What we _can_ do is deliver OAuth tokens to an installed app of the user's choice, but the server won't know who received the token - only the user does. > 1) RSA: Do they need to provide their public key on a web server? This > would be an additional requirement for such applications. > 2) HMAC: Same as for web apps, but even harder because either (a) the > installed app has a static secret burned > into source code or (b) it needs to use a protocol for dynamic key > management the resource server has to implement. Is this the plan? > > Remark on ( > https://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > ): > "To obtain an HMAC verification key, the client has to exchange, in an > out-of-band fashion, shared keys with the issuer." > > I assume "client" should be "verifier", shouldn't it? > Yes. Thanks - fixed! Dirk. > > regards, > Torsten. > > Am 16.07.2010 02:43, schrieb Dirk Balfanz: > > Hi guys, > > after reading through the feedback, we did a pass over the OAuth > signature proposals. > > As a reminder, there are three documents: > > - a document (called "JSON Tokens") that just explains how to sign > something and verify the signature: > > http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > > - an extension of JSON Tokens that can be used for signed OAuth tokens: > > http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU > > - a different extension of JSON Tokens that can be used whenever the spec > calls for an "assertion": > > http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc > (When used in the assertion flow, this last token can also be used to do > "2-legged" OAuth) > > A summary of the (scant) changes: > > - we spelled out what we mean by RSA-SHA256.* Ben Laurie *- can you > double-check that that sounds good? > - we decided on unpadded websafe-base64 throughout. > - some changes to parameter names. > - some small changes I might be forgetting now... > > As explained in my message to the previous thread, there is still no > envelope in there to help with encrypted tokens (b/c we don't understand > well enough what the envelopes for encrypted tokens would look like). > > One question: What's the deal with having the signature go first? If you > can explain to me why that is a good idea, I'm happy to oblige. > > Cheers, > > Dirk & Marius. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > --001636d34573004bb3048bc6af4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jul 18, 2010 at 8:20 AM, Torsten= Lodderstedt <torsten@lodderstedt.net> wrote:
=20
Hi Dirk,

I have some questions concerning your proposal:

- As far as I understand, the difference to "magic signatures" la= ys in the usage of a JSON token carrying issuer, not_before, not_after and audience. While such properties are important for security tokens (assertions), I cannot see an advantage of using this format for signatures of HTTP requests. Would you please explain?

You mean advantage over magic signatures? It's re= ally a similar idea - it's just that magic signatures as is don't q= uite fit the bill. For example, they have newlines in them:=A0http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magi= csig-00.html#anchor5

=A0
- Key management
>From my point of view, your proposal does cover key management for web applications using RSA signatures. What about web applications intending to sign resource server requests using HMAC (for performance reasons)? Do they need to exchange secrets with the resource server?

Correct - I'm not saying how HMAC k= eys are being distributed. Presumably, you would use a similar system to wh= at many platform providers use today - you sign up as a developer, and they= give you a "developer key" (or "API key").=A0
=A0
What about installed applications (mobile, desktop, set top bo= xes, gaming devices)?

I don't thin= k that installed apps can ever authenticate themselves (i.e., prove the sta= tement "I am a copy of the FooBar app"), so I'm not trying to= solve that. What we _can_ do is deliver OAuth tokens to an installed app o= f the user's choice, but the server won't know who received the tok= en - only the user does.
=A0
=A01) RSA: Do they need to provide their public key on a web server? This would be an additional requirement for such applications.
=A02) HMAC: Same as for web apps, but even harder because either (a) the installed app has a static secret burned
into source code or (b) it needs to use a protocol for dynamic key management the resource server has to implement. Is this the plan?

Remark on (https://docs.google.com/document= /pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4):
"To obtain an HMAC verification key, the client has to exchange, in an out-of-band fashion, shared keys with the issuer."

I assume "client" should be "verifier", shouldn't i= t?

Yes. Thanks - fixed!

Dirk.
=A0

regards,
Torsten.

Am 16.07.2010 02:43, schrieb Dirk Balfanz:
=20
Hi guys,=A0

after reading through the feedback, we did a pass over the OAuth signature proposals.

As a reminder, there are three documents:

- a document (called "JSON Tokens") that just explains how= to sign something and verify the signature:
- an extension of JSON Tokens that can be used for signed OAuth tokens:

- a different extension of JSON Tokens that can be used whenever the spec calls for an "assertion":
http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0= ulhgP3He01ONlxeTwkFQV_pCoOowzc
(When used in the assertion flow, this last token can also be used to do "2-legged" OAuth)

A summary of the (scant) changes:

- we spelled out what we mean by RSA-SHA256. Ben Laurie - can you double-check that that sounds good?
- we decided on unpadded websafe-base64 throughout.
- some changes to parameter names.
- some small changes I might be forgetting now...

As explained in my message to the previous thread, there is still no envelope in there to help with encrypted tokens (b/c we don't understand well enough what the envelopes for encrypted tokens would look like).=A0

One question: What's the deal with having the signature go first? If you can explain to me why that is a good idea, I'm happy to oblige.

Cheers,

Dirk & Marius.

 

_______________________________________________
OAuth mailing list

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

--001636d34573004bb3048bc6af4c-- From James.H.Manger@team.telstra.com Mon Jul 19 18:25:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A3E3A68DE for ; Mon, 19 Jul 2010 18:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, 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 o-FMVcHU903E for ; Mon, 19 Jul 2010 18:25:40 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id CAA3C3A6885 for ; Mon, 19 Jul 2010 18:25:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,229,1278252000"; d="scan'208";a="6226283" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipobni.tcif.telstra.com.au with ESMTP; 20 Jul 2010 11:25:49 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6048"; a="4773262" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcdni.tcif.telstra.com.au with ESMTP; 20 Jul 2010 11:25:52 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Tue, 20 Jul 2010 11:25:51 +1000 From: "Manger, James H" To: OAuth WG Date: Tue, 20 Jul 2010 11:26:25 +1000 Thread-Topic: [OAUTH-WG] Change grant_type="none" to something less confusing Thread-Index: AcsnicRurGipo9LwR6iF/u6jNWkW2gAFpz1w Message-ID: <255B9BB34FB7D647A506DC292726F6E11266423B3A@WSMSG3153V.srv.dir.telstra.com> References: <1279297826.11628.61.camel@localhost.localdomain> <3AF1FD6F-2178-42ED-833C-D93C534DDA8A@hueniverse.com> <81CECB0D-6AFE-4E21-9211-86648FC6EAA8@hueniverse.com> <1279559831.6181.17.camel@localhost.localdomain> 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] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 01:25:41 -0000 grant_type=3Dclient_credential sounds ok. An even better approach to addressing the discussions about grant_type and = assertions would be to focus on the *token response* as a standalone media = type, instead of focusing on a common token endpoint. I don't think requiring the same token endpoint for the different flows is = actually that helpful for anyone -- and it has caused confusion/complexity = by *coupling* a variety of quite disparate flows (with a continuing debate = on what is core vs extension). Any particular app is likely to only be interested in one section 4 flow ("= Obtaining an access token"). Services are free to use a common base URI for any section 4 flows even if = that commonality isn't required by the spec. A common token URI might help if there was a single way to discover it for = all flows. So far there isn't, and I doubt there needs to be, nor should be= . Discovering a token endpoint by itself is not that useful. A client needs t= o know which flows work at that endpoint. Was discovery mentions a specific= flow, it may as well provide the endpoint for that flow. * The token endpoint to send an authorization code could be "discovered" fr= om the code itself (make the code a URI). * The token endpoint for an assertion flow could be discovered in the same = place that describes the required assertion profile -- perhaps WS-MetadataE= xchange? * The token endpoint to refresh a token should be discovered when the token= is initially provided (ie as part of the token response media type -- make= the token info self-descriptive). * The token endpoint for a client to use on its own behalf should be provid= ed as part of the signal that says the client needs to make this swap (eg a= WWW-Auth response, either the same or different from the WWW-Auth response= signalling user-delegation is supported). draft-campbell-oauth-saml, for instance, could define an HTTP request with = assertion_type and assertion parameters, and state that the result uses the= token response media type. The media type is a cleaner dividing line betwe= en draft-campbell-oauth-saml and OAuth2 core. --=20 James Manger From eran@hueniverse.com Mon Jul 19 21:34: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 65A8C3A69B3 for ; Mon, 19 Jul 2010 21:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 DnHTsXQgaYh5 for ; Mon, 19 Jul 2010 21:34:13 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 476AD3A68A3 for ; Mon, 19 Jul 2010 21:33:51 -0700 (PDT) Received: (qmail 12687 invoked from network); 20 Jul 2010 04:33:46 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Jul 2010 04:33:46 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 19 Jul 2010 21:33:46 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , OAuth WG Date: Mon, 19 Jul 2010 21:33:50 -0700 Thread-Topic: [OAUTH-WG] Change grant_type="none" to something less confusing Thread-Index: AcsnicRurGipo9LwR6iF/u6jNWkW2gAFpz1wAAkQ9NA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EEBDE73@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1279297826.11628.61.camel@localhost.localdomain> <3AF1FD6F-2178-42ED-833C-D93C534DDA8A@hueniverse.com> <81CECB0D-6AFE-4E21-9211-86648FC6EAA8@hueniverse.com> <1279559831.6181.17.camel@localhost.localdomain> <255B9BB34FB7D647A506DC292726F6E11266423B3A@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11266423B3A@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] Change grant_type="none" to something less confusing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 04:34:21 -0000 I don't have anything against this approach but I suspect others might. I t= hink a few examples would be useful to demonstrate these ideas. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Monday, July 19, 2010 6:26 PM > To: OAuth WG > Subject: Re: [OAUTH-WG] Change grant_type=3D"none" to something less > confusing >=20 > grant_type=3Dclient_credential sounds ok. > An even better approach to addressing the discussions about grant_type an= d > assertions would be to focus on the *token response* as a standalone medi= a > type, instead of focusing on a common token endpoint. >=20 > I don't think requiring the same token endpoint for the different flows i= s > actually that helpful for anyone -- and it has caused confusion/complexit= y by > *coupling* a variety of quite disparate flows (with a continuing debate o= n > what is core vs extension). >=20 > Any particular app is likely to only be interested in one section 4 flow > ("Obtaining an access token"). > Services are free to use a common base URI for any section 4 flows even i= f > that commonality isn't required by the spec. >=20 > A common token URI might help if there was a single way to discover it fo= r all > flows. So far there isn't, and I doubt there needs to be, nor should be. > Discovering a token endpoint by itself is not that useful. A client needs= to > know which flows work at that endpoint. Was discovery mentions a specific > flow, it may as well provide the endpoint for that flow. >=20 > * The token endpoint to send an authorization code could be "discovered" > from the code itself (make the code a URI). > * The token endpoint for an assertion flow could be discovered in the sam= e > place that describes the required assertion profile -- perhaps WS- > MetadataExchange? > * The token endpoint to refresh a token should be discovered when the > token is initially provided (ie as part of the token response media type = -- > make the token info self-descriptive). > * The token endpoint for a client to use on its own behalf should be prov= ided > as part of the signal that says the client needs to make this swap (eg a = WWW- > Auth response, either the same or different from the WWW-Auth response > signalling user-delegation is supported). >=20 >=20 > draft-campbell-oauth-saml, for instance, could define an HTTP request wit= h > assertion_type and assertion parameters, and state that the result uses t= he > token response media type. The media type is a cleaner dividing line > between draft-campbell-oauth-saml and OAuth2 core. >=20 >=20 > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sakimura@gmail.com Wed Jul 21 01:26:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563163A67FC for ; Wed, 21 Jul 2010 01:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nu-JqBhdgEpm for ; Wed, 21 Jul 2010 01:26:11 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id DF8AD3A68B3 for ; Wed, 21 Jul 2010 01:26:10 -0700 (PDT) Received: by gxk1 with SMTP id 1so3609899gxk.31 for ; Wed, 21 Jul 2010 01:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u7DVzXkFnVMsPEkZrLSuiEUE8wtyYtsin80rxxPhHBk=; b=W42jptDPIKvT0WUPtL5w5yNUCEQX5iiT7yh51U8TapvhNSWsdZ2lL7+JQ+UYe6VHXk R98JvJcKO7WLub/9rzSD29NKAJCMnftLSi3ar0kuwGLgESbkQ8q96o026ITRLvcD9EC5 3hR3+By+GRX/1mgm40vIp5YB9ePY2lROct0hw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qUb+oFssXI6+EllPGNMUjEqD6Lu4Esjvd0B71AXS6XMI0syJbiFsI2BaJFL9A+O961 oh7IvT6DoK+Ls/2vAw3TiWUdxaLqE/MuMDbA5c7rURR1M5d2J1AIivIzqzi/iAmLGbqV r/kfOGeEfU1+rrUnmx+fhCiehFnOCqr3xfzoM= MIME-Version: 1.0 Received: by 10.90.102.8 with SMTP id z8mr1039064agb.101.1279700784050; Wed, 21 Jul 2010 01:26:24 -0700 (PDT) Received: by 10.231.158.67 with HTTP; Wed, 21 Jul 2010 01:26:23 -0700 (PDT) In-Reply-To: References: <4C431BA3.2000907@lodderstedt.net> Date: Wed, 21 Jul 2010 17:26:23 +0900 Message-ID: From: Nat Sakimura To: Dirk Balfanz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] signatures, v2 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Jul 2010 08:26:12 -0000 Hi Dirk, Inline: On Tue, Jul 20, 2010 at 9:22 AM, Dirk Balfanz wrote: > > > On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt > wrote: >> >> Hi Dirk, >> >> I have some questions concerning your proposal: >> >> - As far as I understand, the difference to "magic signatures" lays in t= he >> usage of a JSON token carrying issuer, not_before, not_after and audienc= e. >> While such properties are important for security tokens (assertions), I >> cannot see an advantage of using this format for signatures of HTTP >> requests. Would you please explain? > > You mean advantage over magic signatures? It's really a similar idea - it= 's > just that magic signatures as is don't quite fit the bill. For example, t= hey > have newlines in > them:=A0http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magi= csig-00.html#anchor5 Well, they MAY, but they do not have to. Would not profiling Magic Signatures so that it does not contain newlines do? --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From sakimura@gmail.com Wed Jul 21 01:50: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 2E8E53A67BD for ; Wed, 21 Jul 2010 01:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 5XgROTj8Zg1c for ; Wed, 21 Jul 2010 01:50:10 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 05F453A6855 for ; Wed, 21 Jul 2010 01:50:09 -0700 (PDT) Received: by iwn38 with SMTP id 38so7310358iwn.31 for ; Wed, 21 Jul 2010 01:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DL5z8uTUZotPHy5bp13rldqcXTwj2yM4AgP89F1U5Dc=; b=UNdQ32q0I6bGKckce9S8JO4L4nfgPcjuikJAcZCR5bczE2+UUvgyYzlaE1ZGpcnivA 7mrLKIn0LUk/6Oq9MWkIpTDcCrw34Cq0wd8i6cMj9yO9cPvpmszIi12No1poWs+CKuYe Q4CONcpXXWnVsnMD2NbPp35HNw1vghsrU12rM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mJNIX3GV6Ja1/RsAISs0i8FT+cxCOdLKi7lZQvhItB7KJq1cXhUH9hTB6PzOuije/z InRP6xx4UCtvPUSqB52fv1ymM19XOOTNdRKeQGxBm8OLUmK66v/lGeVqd5/h5U2FGTo3 UaHaS3yWc/RuhIOMGx903V3Bf5sfr3Orz/Quw= MIME-Version: 1.0 Received: by 10.231.182.204 with SMTP id cd12mr9229284ibb.101.1279702225939; Wed, 21 Jul 2010 01:50:25 -0700 (PDT) Received: by 10.231.158.67 with HTTP; Wed, 21 Jul 2010 01:50:25 -0700 (PDT) In-Reply-To: References: <4C431BA3.2000907@lodderstedt.net> Date: Wed, 21 Jul 2010 17:50:25 +0900 Message-ID: From: Nat Sakimura To: Dirk Balfanz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] signatures, v2 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Jul 2010 08:50:11 -0000 On Wed, Jul 21, 2010 at 5:26 PM, Nat Sakimura wrote: > Hi Dirk, > > Inline: > > On Tue, Jul 20, 2010 at 9:22 AM, Dirk Balfanz wrote: >> >> >> On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt >> wrote: >>> >>> Hi Dirk, >>> >>> I have some questions concerning your proposal: >>> >>> - As far as I understand, the difference to "magic signatures" lays in = the >>> usage of a JSON token carrying issuer, not_before, not_after and audien= ce. >>> While such properties are important for security tokens (assertions), I >>> cannot see an advantage of using this format for signatures of HTTP >>> requests. Would you please explain? >> >> You mean advantage over magic signatures? It's really a similar idea - i= t's >> just that magic signatures as is don't quite fit the bill. For example, = they >> have newlines in >> them:=A0http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-mag= icsig-00.html#anchor5 > > Well, they MAY, but they do not have to. Would not profiling Magic > Signatures so that it does not contain newlines do? > e.g., base64url_encode(magic_sig_envelope). Downside of course is that it is one more base64url_encode. I really do not have much preference of one over another, but I have some preference on the convergence of the two. --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From bouiaw@gmail.com Wed Jul 21 02:47:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54303A6BA8 for ; Wed, 21 Jul 2010 02:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbV+dNq9MQgl for ; Wed, 21 Jul 2010 02:47:41 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 55F263A6BA3 for ; Wed, 21 Jul 2010 02:47:41 -0700 (PDT) Received: by wwj40 with SMTP id 40so1712737wwj.13 for ; Wed, 21 Jul 2010 02:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=anZG7x7Y35oZuvhDMfxLXAyPxgsheJl7edGRuEBphgk=; b=Uq/Z7pTZtVbhLBQ/tJZVuGhMKDCs+9SjR5FM162H4qakCIrKQsLCJwEtpreKNZQ0J2 gFOevFfYEZ2j//xXoZwYDFPdd5oMGzSrDBU/Q6OPqYdUWV8zGLDn/uoB3XBfKTdKuNQo THYNES4cuSYe6LPCZRHfjK+xYex/gElcGcYZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NqFTzFmg1kxsVA15ZMt4IRwulX2b4Qot1d4+TAKIKCYJypFfZwHNcS+71//Ja+BHDw L3SjpioOKv6BLSnhiUaym5JwAmTu4HDlFayZ5RSO/nSqRMmQI1oRNxSqn4G1whb90vCO fcLSmtZaFuVNAz/3N8pSfrlwon5BPH1LG7Jpk= MIME-Version: 1.0 Received: by 10.216.185.131 with SMTP id u3mr6167739wem.28.1279705676746; Wed, 21 Jul 2010 02:47:56 -0700 (PDT) Received: by 10.216.176.3 with HTTP; Wed, 21 Jul 2010 02:47:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Jul 2010 11:47:56 +0200 Message-ID: From: Bouiaw To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] user-agent flow needs a rewrite X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Jul 2010 09:47:42 -0000 Could you explain how the token fragment is removed between step C and D in the user agent profile ? I don't understand how the http redirect request can be modified by the user agent .... On Wed, Jul 14, 2010 at 7:58 AM, Naitik Shah wrote: > Thanks! That sounds great. > > On Tue, Jul 13, 2010 at 3:00 PM, Eran Hammer-Lahav > wrote: >> >> This is clearly a third flow - hybrid (of user-agent and web-server) - a= nd >> not just a variant of the user-agent flow. It should be presented with i= ts >> own flow diagram and description. I also think the user-agent and >> web-server >> flow names are misleading. They need to be replaced with more descriptiv= e >> names. Something like (I don=B9t like these, just trying to demonstrate)= : >> >> Web-server --> 2 step flow (get code, get token) >> User-agent --> direct flow (get token) >> Hybrid --> hybrid flow (get code and token, get token) >> >> In an attempt to accommodate Brian's request for more concentrated flow >> descriptions, I am working on coming up with come middle ground between >> -05 >> and -10. >> >> ---- >> >> As for the specification of the end-user authorization endpoint: >> >> Please answer this based on actual use cases. When returning parameters >> using the redirection URI call, which of these combinations make sense? >> >> =A0 =A0 =A0 =A0 | Code | Token | Code & Token >> ---------+------+-------+-------------- >> Fragment | =A0a =A0 | =A0 1 =A0 | =A0 3 >> Query =A0 =A0| =A02 =A0 | =A0 b =A0 | =A0 c >> Split* =A0 | n/a =A0| =A0n/a =A0| =A0 d >> >> * token in fragment, code in query >> >> Known use cases: >> >> 1 - current user-agent flow >> 2 - current web-server flow >> 3 - as described by Brian and Naitik >> >> Questionable use cases: >> >> a - >> b - >> c - >> d - current -10 code-and-token proposal >> >> EHL >> >> >> On 7/13/10 2:27 PM, "Naitik Shah" wrote: >> >> > On Tue, Jul 13, 2010 at 2:06 PM, Eran Hammer-Lahav >> > wrote: >> >> This looks reasonable, however, I am no longer see the value in the >> >> hybrid >> >> mode of token and code. If the code is passed in the fragment, the >> >> client has >> >> to pass it to the server. If that is the case, why can=B9t the server >> >> reply >> >> back with the access token? Is the entire purpose just a performance >> >> optimization so the client doesn=B9t have to wait for the server resp= onse >> >> before it has an access token? >> >> >> > >> > I think there are two use cases here, and they are not mutually >> > exclusive. >> > Some apps are mostly just server side, and would end up doing a full >> > page >> > refresh, and here the code in the query param would probably be >> > acceptable. >> > Some apps are mostly just client side, and here the code is irrelevant >> > and the >> > access token in the fragment is all that matters. But we also have >> > hybrids >> > where we want the code in a cookie/JS callback, and we'll also use the >> > access >> > token on the client to=A0dynamically=A0update the UI by accessing some >> > protected >> > data (this is what the Data enabled XFBML tags do in the Facebook JS S= DK >> > for >> > instance). While the server can do the code to access_token exchange, = it >> > can't >> > return it to the JS safely if it does not support https. Even if it di= d, >> > it >> > would mean more overhead for the developer to build an endpoint that >> > does this >> > work and cooperates with a JS SDK which wants the access_token for >> > making API >> > calls. >> > >> > >> > -Naitik >> > >> > >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From Hannes.Tschofenig@gmx.net Wed Jul 21 03:18: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 1E16B3A6B8D for ; Wed, 21 Jul 2010 03:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol1YLzYk1mFx for ; Wed, 21 Jul 2010 03:18:23 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 6C4E53A6BB5 for ; Wed, 21 Jul 2010 03:18:23 -0700 (PDT) Received: (qmail 27470 invoked by uid 0); 21 Jul 2010 10:18:38 -0000 Received: from 212.67.227.34 by www106.gmx.net with HTTP; Wed, 21 Jul 2010 12:18:37 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Wed, 21 Jul 2010 12:18:37 +0200 From: "Hannes Tschofenig" Message-ID: <20100721101837.160080@gmx.net> MIME-Version: 1.0 To: oauth@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18Rz2RzQGkRcyOc75UKzytnmAdqI+JkeVXPOzP2c2 E0/sFXOf9gWaiX/QBid+k6Ebj2YgTInMHB4w== Content-Transfer-Encoding: 8bit X-GMX-UID: Sft/dL4LYW0tVJcQo2dpaFl8amthcxsU X-FuHaFi: 0.77000000000000002 Subject: [OAUTH-WG] OAuth Meeting Agenda X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Jul 2010 10:18:25 -0000 Hi all, please find the latest agenda at: http://www.ietf.org/proceedings/78/agenda/oauth.txt Make sure that you read to provide input during the meeting: http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ Ciao Hannes & Blaine From benl@google.com Wed Jul 21 04:27: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 6A8033A69CB for ; Wed, 21 Jul 2010 04:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[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 Ep+sHvfwrtuX for ; Wed, 21 Jul 2010 04:27:06 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 420C93A6960 for ; Wed, 21 Jul 2010 04:27:06 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o6LBRL6Q005560 for ; Wed, 21 Jul 2010 04:27:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279711641; bh=FAWfhocc6vSEV8zGJYnQ+LVMoDU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=a3vX2Mh5kzNnlEl36W3RO2VCW/CLzvCBsH9BgFmr2G7iuM33Lt+thIvQKvqntj8FR qPc2X+CNH9s6F+O4x6S4w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=uTPzzVn2btWAfscgWeMvZ6MaI6Hi1ivlFGCFmGqCmPP+SlsqavV/klL3pBN4vaEHs fNNvYcnFoTPW2RO5AlixA== Received: from pzk10 (pzk10.prod.google.com [10.243.19.138]) by kpbe17.cbf.corp.google.com with ESMTP id o6LBRJmK024299 for ; Wed, 21 Jul 2010 04:27:20 -0700 Received: by pzk10 with SMTP id 10so2378266pzk.4 for ; Wed, 21 Jul 2010 04:27:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.147.7 with SMTP id u7mr2115wfd.221.1279711639413; Wed, 21 Jul 2010 04:27:19 -0700 (PDT) Received: by 10.143.132.2 with HTTP; Wed, 21 Jul 2010 04:27:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Jul 2010 12:27:19 +0100 Message-ID: From: Ben Laurie To: Dirk Balfanz Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] signatures, v2 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Jul 2010 11:27:07 -0000 On 16 July 2010 01:43, Dirk Balfanz wrote: > Hi guys, > after reading through the feedback, we did a pass over the OAuth signature > proposals. > As a reminder, there are three documents: > - a document (called "JSON Tokens") that just explains how to sign something > and verify the signature: > http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > > - an extension of JSON Tokens that can be used for signed OAuth tokens: > http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU > - a different extension of JSON Tokens that can be used whenever the spec > calls for an "assertion": > http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc > (When used in the assertion flow, this last token can also be used to do > "2-legged" OAuth) > > A summary of the (scant) changes: > - we spelled out what we mean by RSA-SHA256. Ben Laurie - can you > double-check that that sounds good? Nearly missed this, somehow. Yes, looks good to me. A reference would be nice (RFC 3447, for example). > - we decided on unpadded websafe-base64 throughout. > - some changes to parameter names. > - some small changes I might be forgetting now... > As explained in my message to the previous thread, there is still no > envelope in there to help with encrypted tokens (b/c we don't understand > well enough what the envelopes for encrypted tokens would look like). > One question: What's the deal with having the signature go first? If you can > explain to me why that is a good idea, I'm happy to oblige. > Cheers, > Dirk & Marius. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From stpeter@stpeter.im Wed Jul 21 09:51:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF583A68C8 for ; Wed, 21 Jul 2010 09:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 RzIxmADvY3zZ for ; Wed, 21 Jul 2010 09:51:16 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9A88F3A6896 for ; Wed, 21 Jul 2010 09:51:16 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C6A4E400EE for ; Wed, 21 Jul 2010 10:51:32 -0600 (MDT) Message-ID: <4C472593.4060901@stpeter.im> Date: Wed, 21 Jul 2010 10:51:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] draft-hardjono-oauth-kerberos-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: Wed, 21 Jul 2010 16:51:17 -0000 Thomas, thanks for writing this draft. I finally got a chance to read it this morning and it is quite helpful and relevant. Do you plan to update it at some point in the light of more recent versions of the core draft? On 6/9/10 1:17 PM, Thomas Hardjono wrote: > > I was prompted to write this draft after the OATH WG meeting at the last > IETF in March, in which several folks in the room were comparing OAuth with > Kerberos. Some people also suggested to me that a comparative doc might be > useful. > > http://www.ietf.org/internet-drafts/draft-hardjono-oauth-kerberos-00.txt > > The hope is that if OAuth 2.0 wanted to use the Needham-Schroeder (Kerberos) > authentication paradigm, that OAuth could learn from the two decades of > Kerberos development. > > /thomas/ > > > __________________________________________ > > > --- On Wed, 6/9/10, Internet-Drafts@ietf.org > wrote: > >> From: Internet-Drafts@ietf.org >> Subject: I-D Action:draft-hardjono-oauth-kerberos-00.txt >> To: i-d-announce@ietf.org >> Date: Wednesday, June 9, 2010, 12:00 PM >> 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-00.txt >> Pages >> : 21 >> Date >> : 2010-06-09 >> >> 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-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. >> >> -----Inline Attachment Follows----- >> From recordond@gmail.com Wed Jul 21 10:58:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 610F73A68ED for ; Wed, 21 Jul 2010 10:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.180, 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 HAiaiNH3gBQx for ; Wed, 21 Jul 2010 10:58:35 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8B1E13A68A3 for ; Wed, 21 Jul 2010 10:58:35 -0700 (PDT) Received: by iwn38 with SMTP id 38so7672324iwn.31 for ; Wed, 21 Jul 2010 10:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=nMGCABxDSBIEdjm9AWI8icQ3nqbgjJEJl0/5m9KOClM=; b=nVMyNOAlcTtjnc7NgpuuGrBjX8h/4TNkvh7Ut0TVXhxsZwgOibpcWKW5TBBWUja852 9oRkCRElEecEYkobw8DfBwCjfLnfOQlfdbmZLhneain5NmEFhlSqy0yUzU4V1DEaHXK9 mrMIfaGnbXKWNuYPknC5TvmYb5v80tY9bq8Jw= 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=f5H8umm/uBSZMxjF8zoAr3ppHcT8khiv/bpC59Ggzo/togqkYPsZYwnYEZeqFJd70I obZht0hMCH49kplCxWonpxWAREe3NudwsG4cVvRVHx4XQ8usD8luKo5uymLoc2kS1bvs QGJ2yR96qXcvoy73vBt8BvtStugSMndM6NEZQ= MIME-Version: 1.0 Received: by 10.231.14.201 with SMTP id h9mr368633iba.129.1279735129052; Wed, 21 Jul 2010 10:58:49 -0700 (PDT) Received: by 10.231.174.2 with HTTP; Wed, 21 Jul 2010 10:58:48 -0700 (PDT) In-Reply-To: <20100721101837.160080@gmx.net> References: <20100721101837.160080@gmx.net> Date: Wed, 21 Jul 2010 10:58:48 -0700 Message-ID: From: David Recordon To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=00221534d4d3d62cad048be98db2 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Meeting Agenda X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Jul 2010 17:58:36 -0000 --00221534d4d3d62cad048be98db2 Content-Type: text/plain; charset=ISO-8859-1 What is the rechartering discussion? Thanks, --David On Wed, Jul 21, 2010 at 3:18 AM, Hannes Tschofenig < Hannes.Tschofenig@gmx.net> wrote: > Hi all, > > please find the latest agenda at: > http://www.ietf.org/proceedings/78/agenda/oauth.txt > > Make sure that you read to provide input during the meeting: > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ > > Ciao > Hannes & Blaine > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00221534d4d3d62cad048be98db2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What is the rechartering discussion?

Thanks,
-= -David


On Wed, Jul 21, 2010 at= 3:18 AM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:
Hi all,

please find the latest agenda at:
http://www.ietf.org/proceedings/78/agenda/oauth.txt

Make sure that you read to provide input during the meeting:
http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/

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

--00221534d4d3d62cad048be98db2-- From stpeter@stpeter.im Wed Jul 21 11:06: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 045F53A693E for ; Wed, 21 Jul 2010 11:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 t6DdTyxA9z-1 for ; Wed, 21 Jul 2010 11:06:49 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C082C3A68EA for ; Wed, 21 Jul 2010 11:06:49 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8777B400EE; Wed, 21 Jul 2010 12:07:05 -0600 (MDT) Message-ID: <4C473747.2070800@stpeter.im> Date: Wed, 21 Jul 2010 12:07:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: David Recordon References: <20100721101837.160080@gmx.net> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Hannes Tschofenig , oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Meeting Agenda X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Jul 2010 18:06:51 -0000 On 7/21/10 11:58 AM, David Recordon wrote: > What is the rechartering discussion? Our charter says we're working on OAuth 1.1. Clearly that is not the case. Aligning the charter with reality might be a good idea. :) Peter -- Peter Saint-Andre https://stpeter.im/ From sakimura@gmail.com Wed Jul 21 11:22: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 B5F653A68A3 for ; Wed, 21 Jul 2010 11:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6in+sWl0LxUC for ; Wed, 21 Jul 2010 11:22:11 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id DB9823A6946 for ; Wed, 21 Jul 2010 11:22:08 -0700 (PDT) Received: by gxk1 with SMTP id 1so3993756gxk.31 for ; Wed, 21 Jul 2010 11:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=WX2Rk3w59TkMfT0DK8L5MdaHkirxrYNPZ1EykbNKiTs=; b=itfeIa1n69qKPHL+wOZbGqzfcH47HgsnnJ8gGKzNp9X3o03Gcx/ZBJitCu42+uhdtI o8nELOm/aP8HV6tNJdw44xxLfcBItZ4LENZYfJffXLR3kQeyt++oH888dOEDQnVHFMtZ s3HUC0w1TZe3re/U8X9qm2xgAfdDsWIqxZZQ4= 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=Uc46cnVQt2TSA0TGZf0I20DeAaIGEUFV7aAFVQiG4GuA79+fT6+dWGwdfL4Ee44I1G rrqsVkqIQZO3s+ZBdeRN7VfNdyEGp0k8+Hh3Dfuke7X0oXJUevCqCZah90kfxSs91ADx qP3R0skkPRtm+xEW38vI9N09bgtsHGnTubuLU= MIME-Version: 1.0 Received: by 10.101.170.3 with SMTP id x3mr668203ano.142.1279736533169; Wed, 21 Jul 2010 11:22:13 -0700 (PDT) Received: by 10.231.158.67 with HTTP; Wed, 21 Jul 2010 11:22:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Jul 2010 03:22:13 +0900 Message-ID: From: Nat Sakimura To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] signatures, v2 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Jul 2010 18:22:14 -0000 On Wed, Jul 21, 2010 at 8:27 PM, Ben Laurie wrote: > On 16 July 2010 01:43, Dirk Balfanz wrote: >> Hi guys, >> after reading through the feedback, we did a pass over the OAuth signature >> proposals. >> As a reminder, there are three documents: >> - a document (called "JSON Tokens") that just explains how to sign something >> and verify the signature: >> http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 >> >> - an extension of JSON Tokens that can be used for signed OAuth tokens: >> http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU >> - a different extension of JSON Tokens that can be used whenever the spec >> calls for an "assertion": >> http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc >> (When used in the assertion flow, this last token can also be used to do >> "2-legged" OAuth) >> >> A summary of the (scant) changes: >> - we spelled out what we mean by RSA-SHA256. Ben Laurie - can you >> double-check that that sounds good? > > Nearly missed this, somehow. Yes, looks good to me. A reference would > be nice (RFC 3447, for example). Magic Signatures is using EMSA-PKCS1-v1_5 instead of PSS because it has wider library supports, I believe. For example, OpenSSL library interface in PHP does not seem to support PSS. > >> - we decided on unpadded websafe-base64 throughout. >> - some changes to parameter names. >> - some small changes I might be forgetting now... >> As explained in my message to the previous thread, there is still no >> envelope in there to help with encrypted tokens (b/c we don't understand >> well enough what the envelopes for encrypted tokens would look like). Perhaps http://tools.ietf.org/html/draft-sakimura-jsonenc-00 help? >> One question: What's the deal with having the signature go first? If you can >> explain to me why that is a good idea, I'm happy to oblige. With Sign + Encrypt, you are signing the (almost) plain text, while with Encrypt + Sign, you are sining the cypher text so you would have to have full trust on the Encrypt process that it did not tamper the original text. Also, with Sign + Encrypt, you can store the decrypted text and still verify the integrity of the data at a later date, but with Encrypt + Sign, you cannot. Thus, to me, Sign + Encrypt seem to be a better approach. -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From gbrail@sonoasystems.com Thu Jul 22 11:57: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 EC8CC3A68DE for ; Thu, 22 Jul 2010 11:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EF2CMFP+GRs7 for ; Thu, 22 Jul 2010 11:57:46 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 026F73A6829 for ; Thu, 22 Jul 2010 11:57:45 -0700 (PDT) Received: by fxm1 with SMTP id 1so5019028fxm.31 for ; Thu, 22 Jul 2010 11:58:02 -0700 (PDT) Received: by 10.103.181.10 with SMTP id i10mr731189mup.99.1279825082654; Thu, 22 Jul 2010 11:58:02 -0700 (PDT) From: Greg Brail References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acskf/uNIcTdYtRwSDW+mHEpKrB3NwFTlU1A Date: Thu, 22 Jul 2010 14:57:58 -0400 Message-ID: <79fcb9fe160d318b7fdc77e7671d4b0a@mail.gmail.com> To: OAuth WG Content-Type: multipart/alternative; boundary=001636416ce96d1fe4048bfe7f08 Subject: Re: [OAUTH-WG] signatures, v2 X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2010 18:57:48 -0000 --001636416ce96d1fe4048bfe7f08 Content-Type: text/plain; charset=ISO-8859-1 I apologize since I have a feeling that this decision was made long ago but I'd like to understand... OAuth 1.0 had a secret associated with every token and used an HMAC to generate the signature. So, there is no way for an intermediary to see the token secret, regardless of whether SSL is used. OAuth 2.0 removed the token secret, which means that SSL must be used and any "legitimate" intermediaries like proxies and load balancers can see the token. We all agreed that this was a good thing and it greatly simplifies OAuth but it does eliminate some of the old OAuth 1.0 use cases. Are there still cases in which an API provider wishes to *avoid* using SSL, but still wants to ensure that a network eavesdropper or a legitimate intermediary cannot deduce the token and secret? I can imagine that such a mechanism might still be useful in environments where SSL is cost-prohibitive, such as for storage APIs that return very large data sets that are not sensitive enough to require SSL. For instance, Amazon uses something like OAuth 1.0 signatures in their AWS APIs. Does anyone have an idea whether they are still happy with that decision, or do they wish that they had just required SSL for everything? Is there any proposal to introduce an extension that works like the "old" OAuth 1.0 signature mechanism, including the usage of a token secret? Is that idea totally dead or just dormant? *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf Of *Dirk Balfanz *Sent:* Thursday, July 15, 2010 8:44 PM *To:* OAuth WG *Subject:* [OAUTH-WG] signatures, v2 Hi guys, after reading through the feedback, we did a pass over the OAuth signature proposals. As a reminder, there are three documents: - a document (called "JSON Tokens") that just explains how to sign something and verify the signature: http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 - an extension of JSON Tokens that can be used for signed OAuth tokens: http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU - a different extension of JSON Tokens that can be used whenever the spec calls for an "assertion": http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc (When used in the assertion flow, this last token can also be used to do "2-legged" OAuth) A summary of the (scant) changes: - we spelled out what we mean by RSA-SHA256.* Ben Laurie *- can you double-check that that sounds good? - we decided on unpadded websafe-base64 throughout. - some changes to parameter names. - some small changes I might be forgetting now... As explained in my message to the previous thread, there is still no envelope in there to help with encrypted tokens (b/c we don't understand well enough what the envelopes for encrypted tokens would look like). One question: What's the deal with having the signature go first? If you can explain to me why that is a good idea, I'm happy to oblige. Cheers, Dirk & Marius. --001636416ce96d1fe4048bfe7f08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I apologize since I have a feeling that this decision was made long ago but I= 'd like to understand...

=A0

OAuth 1.0 had a secret associated with every token and used an HMAC to generate t= he signature. So, there is no way for an intermediary to see the token secret, regardless of whether SSL is used.

=A0

OAuth 2.0 removed the token secret, which means that SSL must be used and any "legitimate" intermediaries like proxies and load balancers can s= ee the token. We all agreed that this was a good thing and it greatly simplifi= es OAuth but it does eliminate some of the old OAuth 1.0 use cases.

=A0

Are there still cases in which an API provider wishes to avoid using SSL= , but still wants to ensure that a network eavesdropper or a legitimate intermediary cannot deduce the token and secret?

=A0

I can imagine that such a mechanism might still be useful in environments whe= re SSL is cost-prohibitive, such as for storage APIs that return very large da= ta sets that are not sensitive enough to require SSL.

=A0

For instance, Amazon uses something like OAuth 1.0 signatures in their AWS APIs= . Does anyone have an idea whether they are still happy with that decision, o= r do they wish that they had just required SSL for everything?

=A0

Is there any proposal to introduce an extension that works like the "old" OAuth 1.0 signature mechanism, including the usage of a tok= en secret? Is that idea totally dead or just dormant?

=A0

From: oauth-bounces@ietf.org [mailt= o:oauth-bounces@ietf.org] = On Behalf Of Dirk Balfanz
Sent: Thursday, July 15, 2010 8:44 PM
To: OAuth WG
Subject: [OAUTH-WG] signatures, v2

=A0

Hi guys,=A0

=A0

after reading through the feedback, we did a pass over the OAuth signature propos= als.

=A0

As a reminder, there are three documents:

=A0

- a document (called "JSON Tokens") that just explains how to sign something and verify the signature:

- an extension of JSON Tokens that can be used for signed OAuth tokens:

=A0

- a different extension of JSON Tokens that can be used whenever the spec cal= ls for an "assertion":
http= ://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pC= oOowzc

(When used in the assertion flow, this last token can also be used to do "2-legged" OAuth)

=A0

A summary of the (scant) changes:

=A0

- we spelled out what we mean by RSA-SHA256. Ben Laurie - can you double-check that that sounds good?

- we decided on unpadded websafe-base64 throughout.

- some changes to parameter names.

- some small changes I might be forgetting now...

=A0

As explained in my message to the previous thread, there is still no envelope = in there to help with encrypted tokens (b/c we don't understand well enoug= h what the envelopes for encrypted tokens would look like).=A0

=A0

One question: What's the deal with having the signature go first? If you ca= n explain to me why that is a good idea, I'm happy to oblige.

=A0

Cheers,

=A0

Dirk & Marius.

=A0

--001636416ce96d1fe4048bfe7f08-- From gbrail@sonoasystems.com Thu Jul 22 12:01:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF2153A6829 for ; Thu, 22 Jul 2010 12:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqaHXfXUcHAA for ; Thu, 22 Jul 2010 12:01:29 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 317BA3A69AA for ; Thu, 22 Jul 2010 12:01:19 -0700 (PDT) Received: by pzk6 with SMTP id 6so3934859pzk.31 for ; Thu, 22 Jul 2010 12:01:36 -0700 (PDT) Received: by 10.142.229.13 with SMTP id b13mr2805153wfh.61.1279825296330; Thu, 22 Jul 2010 12:01:36 -0700 (PDT) From: Greg Brail References: 79fcb9fe160d318b7fdc77e7671d4b0a@mail.gmail.com In-Reply-To: 79fcb9fe160d318b7fdc77e7671d4b0a@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acskf/uNIcTdYtRwSDW+mHEpKrB3NwFTlU1AAABvCzA= Date: Thu, 22 Jul 2010 15:01:34 -0400 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary=000e0cd32b5c298eb2048bfe8c66 Subject: Re: [OAUTH-WG] signatures, v2 X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2010 19:01:33 -0000 --000e0cd32b5c298eb2048bfe8c66 Content-Type: text/plain; charset=ISO-8859-1 Looks like I didn't read all the specs before writing such a long e-mail. Sorry! "JSON Signatures" does indeed support a key and says that, for HMAC and RSA, there should be an out-of-band mechanism for a client to retrieve a key to go along with a particular token. Should we have a spec that specifies how an OAuth 2.0 client can securely retrieve a key for each token in a way that makes sense for OAuth 2.0 and is easy to implement? Or is this already specified somewhere else? *From:* Greg Brail [mailto:gbrail@sonoasystems.com] *Sent:* Thursday, July 22, 2010 2:58 PM *To:* 'OAuth WG' *Subject:* RE: [OAUTH-WG] signatures, v2 I apologize since I have a feeling that this decision was made long ago but I'd like to understand... OAuth 1.0 had a secret associated with every token and used an HMAC to generate the signature. So, there is no way for an intermediary to see the token secret, regardless of whether SSL is used. OAuth 2.0 removed the token secret, which means that SSL must be used and any "legitimate" intermediaries like proxies and load balancers can see the token. We all agreed that this was a good thing and it greatly simplifies OAuth but it does eliminate some of the old OAuth 1.0 use cases. Are there still cases in which an API provider wishes to *avoid* using SSL, but still wants to ensure that a network eavesdropper or a legitimate intermediary cannot deduce the token and secret? I can imagine that such a mechanism might still be useful in environments where SSL is cost-prohibitive, such as for storage APIs that return very large data sets that are not sensitive enough to require SSL. For instance, Amazon uses something like OAuth 1.0 signatures in their AWS APIs. Does anyone have an idea whether they are still happy with that decision, or do they wish that they had just required SSL for everything? Is there any proposal to introduce an extension that works like the "old" OAuth 1.0 signature mechanism, including the usage of a token secret? Is that idea totally dead or just dormant? *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf Of *Dirk Balfanz *Sent:* Thursday, July 15, 2010 8:44 PM *To:* OAuth WG *Subject:* [OAUTH-WG] signatures, v2 Hi guys, after reading through the feedback, we did a pass over the OAuth signature proposals. As a reminder, there are three documents: - a document (called "JSON Tokens") that just explains how to sign something and verify the signature: http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 - an extension of JSON Tokens that can be used for signed OAuth tokens: http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU - a different extension of JSON Tokens that can be used whenever the spec calls for an "assertion": http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc (When used in the assertion flow, this last token can also be used to do "2-legged" OAuth) A summary of the (scant) changes: - we spelled out what we mean by RSA-SHA256.* Ben Laurie *- can you double-check that that sounds good? - we decided on unpadded websafe-base64 throughout. - some changes to parameter names. - some small changes I might be forgetting now... As explained in my message to the previous thread, there is still no envelope in there to help with encrypted tokens (b/c we don't understand well enough what the envelopes for encrypted tokens would look like). One question: What's the deal with having the signature go first? If you can explain to me why that is a good idea, I'm happy to oblige. Cheers, Dirk & Marius. --000e0cd32b5c298eb2048bfe8c66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Looks like I didn't read all the specs before writing such a long e-mail. Sor= ry!

=A0

"JSON Signatures" does indeed support a key and says that, for HMAC and RSA, there should be an out-of-band mechanism for a client to retrieve a key to = go along with a particular token.

=A0

Should we have a spec that specifies how an OAuth 2.0 client can securely retrieve= a key for each token in a way that makes sense for OAuth 2.0 and is easy to implement? Or is this already specified somewhere else?

=A0

=A0

I apologize since I have a feeling that this decision was made long ago but I= 'd like to understand...

=A0

OAuth 1.0 had a secret associated with every token and used an HMAC to generate t= he signature. So, there is no way for an intermediary to see the token secret, regardless of whether SSL is used.

=A0

OAuth 2.0 removed the token secret, which means that SSL must be used and any "legitimate" intermediaries like proxies and load balancers can s= ee the token. We all agreed that this was a good thing and it greatly simplifi= es OAuth but it does eliminate some of the old OAuth 1.0 use cases.

=A0

Are there still cases in which an API provider wishes to avoid using SSL= , but still wants to ensure that a network eavesdropper or a legitimate intermediary cannot deduce the token and secret?

=A0

I can imagine that such a mechanism might still be useful in environments whe= re SSL is cost-prohibitive, such as for storage APIs that return very large da= ta sets that are not sensitive enough to require SSL.

=A0

For instance, Amazon uses something like OAuth 1.0 signatures in their AWS APIs= . Does anyone have an idea whether they are still happy with that decision, o= r do they wish that they had just required SSL for everything?

=A0

Is there any proposal to introduce an extension that works like the "old" OAuth 1.0 signature mechanism, including the usage of a tok= en secret? Is that idea totally dead or just dormant?

=A0

From: oauth-bounces@ietf.org [mailt= o:oauth-bounces@ietf.org] = On Behalf Of Dirk Balfanz
Sent: Thursday, July 15, 2010 8:44 PM
To: OAuth WG
Subject: [OAUTH-WG] signatures, v2

=A0

Hi guys,=A0

=A0

after reading through the feedback, we did a pass over the OAuth signature propos= als.

=A0

As a reminder, there are three documents:

=A0

- a document (called "JSON Tokens") that just explains how to sign something and verify the signature:

- an extension of JSON Tokens that can be used for signed OAuth tokens:

=A0

- a different extension of JSON Tokens that can be used whenever the spec cal= ls for an "assertion":
http= ://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pC= oOowzc

(When used in the assertion flow, this last token can also be used to do "2-legged" OAuth)

=A0

A summary of the (scant) changes:

=A0

- we spelled out what we mean by RSA-SHA256. Ben Laurie - can you double-check that that sounds good?

- we decided on unpadded websafe-base64 throughout.

- some changes to parameter names.

- some small changes I might be forgetting now...

=A0

As explained in my message to the previous thread, there is still no envelope = in there to help with encrypted tokens (b/c we don't understand well enoug= h what the envelopes for encrypted tokens would look like).=A0

=A0

One question: What's the deal with having the signature go first? If you ca= n explain to me why that is a good idea, I'm happy to oblige.

=A0

Cheers,

=A0

Dirk & Marius.

=A0

--000e0cd32b5c298eb2048bfe8c66-- From torsten@lodderstedt.net Thu Jul 22 14:10:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155C83A69B7 for ; Thu, 22 Jul 2010 14:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.226 X-Spam-Level: X-Spam-Status: No, score=-1.226 tagged_above=-999 required=5 tests=[AWL=-0.836, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfbmIr5PiCvt for ; Thu, 22 Jul 2010 14:10:34 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id BAC1E3A69BE for ; Thu, 22 Jul 2010 14:10:31 -0700 (PDT) Received: from p4ffd12ee.dip.t-dialin.net ([79.253.18.238] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Oc32S-0004xh-3N; Thu, 22 Jul 2010 23:10:44 +0200 Message-ID: <4C48B3CC.2010708@lodderstedt.net> Date: Thu, 22 Jul 2010 23:10:36 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brian Eaton References: <4C3E2CF2.1000108@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: Kris Selden , OAuth WG Subject: Re: [OAUTH-WG] issuing new refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2010 21:10:38 -0000 Am 15.07.2010 07:14, schrieb Brian Eaton: > ... > My use cases for this are a little different. > > 1) I'm interested in the two-legged flows as well as three-legged flows. > For example, imagine an autonomous client that is registered once, > and then after that maintains its own key material. Regular rotation > of the key material is good cryptographic hygiene. > How is the client registered? Out of band or via API? > 2) I'm interested in distributed scenarios. > For example, imagine a geographically distributed client > application, or a client application that is extremely busy. In both > these cases, you run into race conditions where refresh tokens are > changed even as they are being used. > What is the difference between rotating a key and changing the refresh token with respect to such race conditions? > 3) I'm interested in authentication besides bearer tokens, in > particular public keys used to verify assertions. > Authentication between which parties? client and authz server, client and resource server? > 4) I'm less interested in installed applications. > I understand your use case for rotating refresh tokens, but it's > somewhat less important for me. > > That said, maybe we could arrive at a set of protocol flows that we > would both implement the same way, and would meet all of those use > cases? For example, would a protocol where the client secret for > installed applications changed regularly work for you? > Why not? Let's talk about :-) The following comments are given with focus on installed application. > Maybe something like this: > > - when a client contacts the authorization server, it would provide a > hint that it supports key rotation > where would the initial secret come from? Would it be the same secret for all installations? I assume there is no initial secret and key material is used to protect the refresh tokens only. It is not used to authenticate the client. > - the authorization server may return an error code that says "key > rotation needed" > - the client would then generate a new secret key (this could be > either a machine-generated password, or an HMAC key, or a > public/private key pair.) > I would prefer if the authz server would issue the fresh secrets (at least for shared secrets). > - the client would then contact the authorization server again, > signing the message with the old key, and providing the verification > material for the new key. > - the authorization server would then store the new key, and mark the > old key for expiration. > when will the old key expire? Instantly? > - subsequent requests from the client would be signed with the new key > > Note that in the case of installed applications using the > user-approval flows, you would associate the new key material with the > client-id and refresh token together, rather than the client-id alone. > Otherwise it's impossible to look up the verification material for > requests, since you would quickly run into problems with a single > client-id mapping to zillions of secrets. > what about clients with multiple refresh tokens from the same authz server? Would they need different secrets? Or would you suggest to associate all refresh tokens with the respective key material? I would rather suggest the following approach: We distinguish clients (application type) and client instances (installation). Every installed application is registered with the authz server as a separate client instance (identified by an new client_id). As far as I remember, there has been a proposal on the list to introduce instance identifiers recently. Key material is managed per client instance. Refresh tokens are assigned to a particular client instance. That way an authz server can identify and lock out particular installations (e.g. the media center app on my iPhone). The same holds for end-users, a self care UI could vizualize different installations and their authorizations. If the authz server also manages the relation between clients and client instances, a particular application can be black listed, too. Bottom line: it's an viable alternative to rotate keys instead of issuing new refresh tokens. In my opinion, this is the more complex way to protected installed applications because it requires a client registration and key rotation protocol. On the other hand, (in combination with instances) it has some additional advantages. What is your assessment? regards, Torsten. > Cheers, > Brian > Assumptions in the case of installed applications, the secret is used to protect refresh tokens only no client authentication From torsten@lodderstedt.net Thu Jul 22 14:39:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 353D13A69BE for ; Thu, 22 Jul 2010 14:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.192 X-Spam-Level: X-Spam-Status: No, score=-1.192 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRdNl9BbDNmm for ; Thu, 22 Jul 2010 14:39:40 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by core3.amsl.com (Postfix) with ESMTP id BCC7D3A69B9 for ; Thu, 22 Jul 2010 14:39:39 -0700 (PDT) Received: from p4ffd12ee.dip.t-dialin.net ([79.253.18.238] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Oc3Uh-0005RI-9p; Thu, 22 Jul 2010 23:39:55 +0200 Message-ID: <4C48BAA6.8050702@lodderstedt.net> Date: Thu, 22 Jul 2010 23:39:50 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brian Campbell References: <4C432262.40204@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2010 21:39:43 -0000 Am 19.07.2010 06:34, schrieb Brian Campbell: > Torsten, > Thanks for taking the time to review and comment. I've tried to > address your questions inline below (though in some cases only raising > more questions). > > On Sun, Jul 18, 2010 at 9:48 AM, Torsten Lodderstedt > wrote: > >> Why do you prescribe to include the token endpoint URL into the >> SubjectConfirmationData and similar data also in the AudienceRestriction? I >> would expect such data in the AudienceRestriction only. >> > One of the primary motivators behind much of this document was wanting > to align the assertion format and processing rules as much as was > reasonable with requirements in SAML Web SSO. > Sounds like you defining a profile of the OAuth assertion flow for using SAML assertions complying to the SAML "Web Browser SSO Profile". I think you should state that somewhere. There will probably be other assertion flow profiles for other SAML assertion "dialects". > The seemingly redundant data in Reciepent of SubjectConfirmationData > and in the AudienceRestriction is very similar to what is required in > Web SSO. That's the main reason they are both there. > > However, there is a subtle distinction between the two - the > SubjectConfirmationData/Recipient identifies the endpoint to which the > assertion can be delivered (where) and the Audience identifies the > more general entity to whom it can be delivered (who). In general > practice the two are tightly coupled but they need not necessarily be. > > >> Why do you prohibit NotBefore-Attributes? >> > Again trying to follow what was done in Web SSO - the prohibition of > the NotBefore in SubjectConfirmationData was taken directly from > section 4.1.4.2 of saml-profiles-2.0-os. Honestly, I've never > understood the reason for the restriction and really the reason I had > it here was just to mimic web sso in the hope of facilitating better > reuse of existing software. Anyway, that was my reasoning but I > woudn't be opposed to removing that language from this document. > > Regardless which way we go with that - note that the use of a > NotBefore attribute is allowed in the Conditions element. > ok, seems I mixed both attributes up. The conditions element is more important. > >> What the reason for that statement? "If the assertion was issued with the >> intention that the client act autonomously on behalf of the subject, an >> SHOULD NOT be included." Do you expect the OAuth >> authorization server to authenticate the client anyway? >> > Client authentication to the authorization server is an orthogonal > concern. This is about the subject of the assertion (which may be > the client but probably won't be in most cases) authenticating with > the issuer of the assertion. > > It seems like there are cases where the end user (or subject) is > present during the transaction and will have authenticated directly > with the issuer of the assertion. But there may also be cases where > the end user is not present and the client is trusted to act on their > behalf. That bullet and the one before it that says, "If the > assertion issuer authenticated the subject, the assertion SHOULD > contain a single representing that authentication > event" were intended to try and accommodate those two situations and > provide a way to tell the difference based on the content of the > assertion. > > It also just seemed like the "right" thing to do - if the issuer > authenticated the subject, say so in the assertion. If not, say > nothing about it in the assertion. > understood. > >> Your I-D states: >> "The authorization server MUST ensure that bearer assertions are >> not replayed, by maintaining the set of used ID values for the >> length of time for which the assertion would be considered valid >> based on the NotOnOrAfter attribute in the >> ." >> >> Why do you want to force a one-time usage for SAML assertions? >> This is to restrictive, in my opinion. >> > This is also a carryover from web SSO via the POST binding. I was > actually leaning towards not including this language but a couple > early reviews were interesting in having it in there. My co-author on > this draft, Mr. Chuck Mortimore, was one of those folks so maybe he > could provide more insight into his reasoning there. Chuck? > > >> Any issuing authority could enforce such a >> policy by using the "OneTimeUse" element. >> > Personally, I've always found the spec language around OneTimeUse to > be confusing and somewhat ambiguous. Maybe I'm wrong but take a look > at "2.5.1.5 Element" and the treatment of OneTimeUse in > "2.5.1 Element" of saml-core-2.0-os. There are parts of > that language that do suggest OneTimeUse is intended to indicate that > some replay check is required but other parts seem to say something > entirely different. I don't believe that OneTimeUse is widely used > or supported. > We don't use it, too :-) > >> 2.3. Error Response: I would suggest to return a 401 status code for >> invalid assertions since I see them as invalid credentials. >> > That's a good point. I had 400 largely as a copy/paste error from > another example. However, as I take a closer look at the text in > draft -10 of the core OAuth spec, it would seem that it prescribes a > 400 for this case. Section "4.3. Error Response" says, > > "If the client provided invalid credentials using an HTTP > authentication scheme via the "Authorization" request header field, > the authorization server MUST respond with the HTTP 401 > (Unauthorized) status code. Otherwise, the authorization server > SHALL respond with the HTTP 400 (Bad Request) status code." > -- http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.3 > > > Now I'm not sure which makes sense. Is it really an HTTP > Unauthorized? It's not an HTTP authentication that is failing but > rather a higher level protocol. Maybe this is a question to be > addressed at the core spec level? > > You are right, status code 401 is used in case of invalid client credentials. An invalid assertion is an error on a higher protocol level. > I might just drop the example I have in section 2.3 of this document > and defer completed to the core spec :) > > -Brian > > BTW, I referenced the SAML specs a few times in this email and should > say that http://saml.xml.org/saml-specifications is a nice place to > find all the OASIS SAML specs, including the latest errata, in one > place. > Thank you for this hint, I'm more (SAML Core) or less (Profiles) familiar with the specs. regards, Torsten. From torsten@lodderstedt.net Thu Jul 22 15:01: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 AA5943A6A0B for ; Thu, 22 Jul 2010 15:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGswQfczJv-9 for ; Thu, 22 Jul 2010 15:01:48 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by core3.amsl.com (Postfix) with ESMTP id F40F63A680C for ; Thu, 22 Jul 2010 15:01:47 -0700 (PDT) Received: from p4ffd12ee.dip.t-dialin.net ([79.253.18.238] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Oc3q7-00007p-SU; Fri, 23 Jul 2010 00:02:04 +0200 Message-ID: <4C48BFD2.9060406@lodderstedt.net> Date: Fri, 23 Jul 2010 00:01:54 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Dirk Balfanz References: <4C431BA3.2000907@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080300090502000107070000" X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] signatures, v2 X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2010 22:01:49 -0000 This is a multi-part message in MIME format. --------------080300090502000107070000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt > > wrote: > > Hi Dirk, > > I have some questions concerning your proposal: > > - As far as I understand, the difference to "magic signatures" > lays in the usage of a JSON token carrying issuer, not_before, > not_after and audience. While such properties are important for > security tokens (assertions), I cannot see an advantage of using > this format for signatures of HTTP requests. Would you please explain? > > > You mean advantage over magic signatures? It's really a similar idea - > it's just that magic signatures as is don't quite fit the bill. For > example, they have newlines in them: > http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html#anchor5 I mean, what is the reason for including issuer, not_before, not_after and audience into a signature? > - Key management > From my point of view, your proposal does cover key management for > web applications using RSA signatures. What about web applications > intending to sign resource server requests using HMAC (for > performance reasons)? Do they need to exchange secrets with the > resource server? > > > Correct - I'm not saying how HMAC keys are being distributed. > Presumably, you would use a similar system to what many platform > providers use today - you sign up as a developer, and they give you a > "developer key" (or "API key"). Such a system will work for a relatively static relation between client and server only. Do you suggest a client should register with every resource server in advance? What about dynamic clients? Suppose a client is just configured with a URL pointing to a PortableContacts resource. The client discovers the respective authz server and obtains a token. What if the client wants to sign the messages to the resource server? > What about installed applications (mobile, desktop, set top boxes, > gaming devices)? > > > I don't think that installed apps can ever authenticate themselves > (i.e., prove the statement "I am a copy of the FooBar app"), so I'm > not trying to solve that. What we _can_ do is deliver OAuth tokens to > an installed app of the user's choice, but the server won't know who > received the token - only the user does. I think we can do more. Even installed applications can use signatures to protect messages on transport. What about that use case? Clearly they need appropriate key material. The token secret issued by the authorization server could server that purpose. > 1) RSA: Do they need to provide their public key on a web server? > This would be an additional requirement for such applications. > 2) HMAC: Same as for web apps, but even harder because either (a) > the installed app has a static secret burned > into source code or (b) it needs to use a protocol for dynamic key > management the resource server has to implement. Is this the plan? > regards, Torsten. --------------080300090502000107070000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Dirk,

I have some questions concerning your proposal:

- As far as I understand, the difference to "magic signatures" lays in the usage of a JSON token carrying issuer, not_before, not_after and audience. While such properties are important for security tokens (assertions), I cannot see an advantage of using this format for signatures of HTTP requests. Would you please explain?

You mean advantage over magic signatures? It's really a similar idea - it's just that magic signatures as is don't quite fit the bill. For example, they have newlines in them: http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html#anchor5

I mean, what is the reason for including issuer, not_before, not_after and audience into a signature?

- Key management
>From my point of view, your proposal does cover key management for web applications using RSA signatures. What about web applications intending to sign resource server requests using HMAC (for performance reasons)? Do they need to exchange secrets with the resource server?

Correct - I'm not saying how HMAC keys are being distributed. Presumably, you would use a similar system to what many platform providers use today - you sign up as a developer, and they give you a "developer key" (or "API key").

Such a system will work for a relatively static relation between client and server only. Do you suggest a client should register with every resource server in advance?

What about dynamic clients? Suppose a client is just configured with a URL pointing to a PortableContacts resource. The client discovers the respective authz server and obtains a token. What if the client wants to sign the messages to the resource server?


What about installed applications (mobile, desktop, set top boxes, gaming devices)?

I don't think that installed apps can ever authenticate themselves (i.e., prove the statement "I am a copy of the FooBar app"), so I'm not trying to solve that. What we _can_ do is deliver OAuth tokens to an installed app of the user's choice, but the server won't know who received the token - only the user does.

I think we can do more. Even installed applications can use signatures to protect messages on transport. What about that use case? Clearly they need appropriate key material. The token secret  issued by the authorization server could server that purpose.

 
 1) RSA: Do they need to provide their public key on a web server? This would be an additional requirement for such applications.
 2) HMAC: Same as for web apps, but even harder because either (a) the installed app has a static secret burned
into source code or (b) it needs to use a protocol for dynamic key management the resource server has to implement. Is this the plan?


regards,
Torsten.
--------------080300090502000107070000-- From torsten@lodderstedt.net Thu Jul 22 15:07: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 352A23A69E2 for ; Thu, 22 Jul 2010 15:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.152, 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 yOIi7ecH14nK for ; Thu, 22 Jul 2010 15:07:07 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by core3.amsl.com (Postfix) with ESMTP id EF2D53A6A12 for ; Thu, 22 Jul 2010 15:07:06 -0700 (PDT) Received: from p4ffd12ee.dip.t-dialin.net ([79.253.18.238] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Oc3vG-0000EH-Q9; Fri, 23 Jul 2010 00:07:23 +0200 Message-ID: <4C48C116.9000609@lodderstedt.net> Date: Fri, 23 Jul 2010 00:07:18 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Marius Scurtescu References: <4C3F3F6A.5000409@lodderstedt.net> <4C3F9064.6060604@lodderstedt.net> In-Reply-To: <4C3F9064.6060604@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2010 22:07:08 -0000 no one else in the group having an opinion on this topic? > Am 15.07.2010 20:14, schrieb Marius Scurtescu: >> On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt >> wrote: >>> As I have written in my reply to Marius's posting. I'm fine with >>> including >>> server ids in scopes. But this requires a definition of the scope's >>> syntax >>> and semantics in the spec. Otherwise, scope interpretation (and server >>> identification) will be deployment specific. >> Sure, it is deployment specific, but why is that an issue? >> >> In your case, the authz server and all the resource servers are >> managed by the same organization, right? >> >> Do clients need to be aware of the actual resource server? >> >> You can probably create a separate spec that defines scope syntax for >> this purpose, if really needed. Does it have to be in core? >> >> Marius > > Solving the challenge I described in a deployment specific way is not > an issue. But the consequence is that authz server, resource servers > and clients are tight together. > > Let me ask you one question: Why are we working together towards a > standard protocol? I can tell you my expectations: I hope there will > be broad support not only by libraries, but also by ready-to-use > services and clients, so we could integrate such services into our > deployment easily. Moreover, I would like to see OAuth to be included > in application/service protocols like PortableContacts, SIP, WebDAV, > IMAP, ... > > So what if I would like to use standard clients to access our > services? Using scopes for specifying resource server id's in this > case is also simple - if you take an isolated view. But since scopes > may be used to specifiy a lot of other things, like resources, > permissions, and durations, handling w/o a more detailed spec will in > practice be impossible. > > Suppose a WebDAV service for media data access. Any WebDAV client > knows the WebDAV protocol (== interface), e.g. the supported methods > (GET, PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. > So it is sufficient to configure the client with the URL of my > personal web storage. To start with let's assume, scopes are used to > designate resource servers only. So the server's scope could be > "webstorage". > > WWW-Authenticate OAuth realm='webstorage' scope="webstorage" > > The client could just pass this parameter to the authz server and > everything is fine. > > On the next level, let's assume the (future) WebDAV standard with > OAuth-support uses one permission per method type. So the full scope > could be as follows: > > WWW-Authenticate OAuth realm='webstorage' scope="webstorage:GET > webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY > webstorage:MOVE" > > Passing this scope w/o any unmodified to the authz server is not an > issue. But this implies the client asks for full access to the users > media storage. Since our client is a gallery application, it requires > the "GET" permission only. How does the client know which of the scope > values to pick for the end-user authorization process? It must somehow > select "webstorage:GET". > > But how? > > In my personal opinion, clients should be enabled to interpret, > combine and even create scopes. And yes, this should go to the core of > the spec. > > regards, > Torsten. > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From recordond@gmail.com Thu Jul 22 22:43:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5D43A68C2 for ; Thu, 22 Jul 2010 22:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.171, 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 Ttcb502H5XrH for ; Thu, 22 Jul 2010 22:43:21 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BDC8E3A6860 for ; Thu, 22 Jul 2010 22:43:21 -0700 (PDT) Received: by iwn38 with SMTP id 38so9401250iwn.31 for ; Thu, 22 Jul 2010 22:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=dHMmB4Ag/Qijk6X5IBroY9F+kGExemvUlernD2TAaws=; b=l/ptsmespIrX0xMulNQrzqhgm9+f2bZn9cyjWwkLH+VvuKaLhvkQTmk9FBaBnOU1CJ PLOfDrXQyAWxJgMgyqcYH/yjYZMcy3C29uB6EOUogQl5kWFrYE0F8Ev3bS4owrFHJ9PL 7fREIObMbCqhJd6kFyXVGhtVwR/sLYX6s+OGY= 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=JJg2NpI9UukqBN9gQUmoIguhjLibhauOaH5aX7TGeKxv0NFuxAGGrwWzcMph4f0ype KrgWEWvsXoQP6NuA1oo+AP2kli+wX47yRmxtpGQSNArv0db4/TIRJHE3odf2SlbYqjzD FmpxiUsTGcG03lvs9usK8a5H9LXHejLvnvRhc= MIME-Version: 1.0 Received: by 10.231.80.213 with SMTP id u21mr3024283ibk.173.1279863806413; Thu, 22 Jul 2010 22:43:26 -0700 (PDT) Received: by 10.231.174.2 with HTTP; Thu, 22 Jul 2010 22:43:23 -0700 (PDT) In-Reply-To: <4C48C116.9000609@lodderstedt.net> References: <4C3F3F6A.5000409@lodderstedt.net> <4C3F9064.6060604@lodderstedt.net> <4C48C116.9000609@lodderstedt.net> Date: Thu, 22 Jul 2010 22:43:23 -0700 Message-ID: From: David Recordon To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=0015176f0f348b498d048c07838f Cc: OAuth WG Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 05:43:25 -0000 --0015176f0f348b498d048c07838f Content-Type: text/plain; charset=ISO-8859-1 I don't have a need for anything beyond the scope parameter here. On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > no one else in the group having an opinion on this topic? > > > > Am 15.07.2010 20:14, schrieb Marius Scurtescu: >> >>> On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt >>> wrote: >>> >>>> As I have written in my reply to Marius's posting. I'm fine with >>>> including >>>> server ids in scopes. But this requires a definition of the scope's >>>> syntax >>>> and semantics in the spec. Otherwise, scope interpretation (and server >>>> identification) will be deployment specific. >>>> >>> Sure, it is deployment specific, but why is that an issue? >>> >>> In your case, the authz server and all the resource servers are >>> managed by the same organization, right? >>> >>> Do clients need to be aware of the actual resource server? >>> >>> You can probably create a separate spec that defines scope syntax for >>> this purpose, if really needed. Does it have to be in core? >>> >>> Marius >>> >> >> Solving the challenge I described in a deployment specific way is not an >> issue. But the consequence is that authz server, resource servers and >> clients are tight together. >> >> Let me ask you one question: Why are we working together towards a >> standard protocol? I can tell you my expectations: I hope there will be >> broad support not only by libraries, but also by ready-to-use services and >> clients, so we could integrate such services into our deployment easily. >> Moreover, I would like to see OAuth to be included in application/service >> protocols like PortableContacts, SIP, WebDAV, IMAP, ... >> >> So what if I would like to use standard clients to access our services? >> Using scopes for specifying resource server id's in this case is also simple >> - if you take an isolated view. But since scopes may be used to specifiy a >> lot of other things, like resources, permissions, and durations, handling >> w/o a more detailed spec will in practice be impossible. >> >> Suppose a WebDAV service for media data access. Any WebDAV client knows >> the WebDAV protocol (== interface), e.g. the supported methods (GET, PUT, >> POST, DELETE, COPY, MOVE) and how to traverse directories. So it is >> sufficient to configure the client with the URL of my personal web storage. >> To start with let's assume, scopes are used to designate resource servers >> only. So the server's scope could be "webstorage". >> >> WWW-Authenticate OAuth realm='webstorage' scope="webstorage" >> >> The client could just pass this parameter to the authz server and >> everything is fine. >> >> On the next level, let's assume the (future) WebDAV standard with >> OAuth-support uses one permission per method type. So the full scope could >> be as follows: >> >> WWW-Authenticate OAuth realm='webstorage' scope="webstorage:GET >> webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY >> webstorage:MOVE" >> >> Passing this scope w/o any unmodified to the authz server is not an issue. >> But this implies the client asks for full access to the users media storage. >> Since our client is a gallery application, it requires the "GET" permission >> only. How does the client know which of the scope values to pick for the >> end-user authorization process? It must somehow select "webstorage:GET". >> >> But how? >> >> In my personal opinion, clients should be enabled to interpret, combine >> and even create scopes. And yes, this should go to the core of the spec. >> >> regards, >> Torsten. >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0015176f0f348b498d048c07838f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't have a need for anything beyond the scope parameter here.
<= br>

On Thu, Jul 22, 2010 at 3:07 PM, Tor= sten Lodderstedt <torsten@lodderstedt.net> wrote:
no one else in the group having an opinion = on this topic?



Am 15.07.2010 20:14, schrieb Marius Scurtescu:
On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
<torsten@lo= dderstedt.net> =A0wrote:
As I have written in my reply to Marius's posting. I'm fine with in= cluding
server ids in scopes. But this requires a definition of the scope's syn= tax
and semantics in the spec. Otherwise, scope interpretation (and server
identification) will be deployment specific.
Sure, it is deployment specific, but why is that an issue?

In your case, the authz server and all the resource servers are
managed by the same organization, right?

Do clients need to be aware of the actual resource server?

You can probably create a separate spec that defines scope syntax for
this purpose, if really needed. Does it have to be in core?

Marius

Solving the challenge I described in a deployment specific way is not an is= sue. But the consequence is that authz server, resource servers and clients= are tight together.

Let me ask you one question: Why are we working together towards a standard= protocol? I can tell you my expectations: I hope there will be broad suppo= rt not only by libraries, but also by ready-to-use services and clients, so= we could integrate such services into our deployment easily. Moreover, I w= ould like to see OAuth to be included in application/service protocols like= PortableContacts, SIP, WebDAV, IMAP, ...

So what if I would like to use standard clients to access our services? Usi= ng scopes for specifying resource server id's in this case is also simp= le - if you take an isolated view. But since scopes may be used to specifiy= a lot of other things, like resources, permissions, and durations, handlin= g w/o a more detailed spec will in practice be impossible.

Suppose a WebDAV service for media data access. Any WebDAV client knows the= WebDAV protocol (=3D=3D interface), e.g. the supported methods (GET, PUT, = POST, DELETE, COPY, MOVE) and how to traverse directories. So it is suffici= ent to configure the client with the URL of my personal web storage. To sta= rt with let's assume, scopes are used to designate resource servers onl= y. So the server's scope could be "webstorage".

=A0 =A0WWW-Authenticate OAuth realm=3D'webstorage' scope=3D"w= ebstorage"

The client could just pass this parameter to the authz server and everythin= g is fine.

On the next level, let's assume the (future) WebDAV standard with OAuth= -support uses one permission per method type. So the full scope could be as= follows:

=A0 =A0WWW-Authenticate OAuth realm=3D'webstorage' scope=3D"w= ebstorage:GET webstorage:PUT webstorage:POST webstorage:DELETE webstorage:C= OPY webstorage:MOVE"

Passing this scope w/o any unmodified to the authz server is not an issue. = But this implies the client asks for full access to the users media storage= . Since our client is a gallery application, it requires the "GET"= ; permission only. How does the client know which of the scope values to pi= ck for the end-user authorization process? It must somehow select "web= storage:GET".

But how?

In my personal opinion, clients should be enabled to interpret, combine and= even create scopes. And yes, this should go to the core of the spec.

regards,
Torsten.




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

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

--0015176f0f348b498d048c07838f-- From hannes.tschofenig@nsn.com Fri Jul 23 02:24: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 C42B63A681E for ; Fri, 23 Jul 2010 02:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJcpafSOAqzB for ; Fri, 23 Jul 2010 02:24:53 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 97CBD3A69D0 for ; Fri, 23 Jul 2010 02:24:52 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o6N9P94h012599 for ; Fri, 23 Jul 2010 11:25:09 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o6N9OtXj004374 for ; Fri, 23 Jul 2010 11:25:08 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 11:24:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2A48.DAE17C71" Date: Fri, 23 Jul 2010 12:23:17 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45028698A0@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OAuth Tutorial on Friday, 9am Thread-Index: AcsqR9YZOD/7mqgUSWO6CHBu2u5ePA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 23 Jul 2010 09:24:55.0712 (UTC) FILETIME=[E9B47200:01CB2A48] Subject: [OAUTH-WG] OAuth Tutorial on Friday, 9am X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 09:24:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2A48.DAE17C71 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 As mentioned in the meeting agenda Blaine and myself thought it would be useful to schedule a tutorial about OAuth during the IETF week.=20 The morning slot (9am till max 11:30am) on Friday seems to be good. I will organize a meeting room. Details will be provided later.=20 Ciao Hannes & Blaine ------_=_NextPart_001_01CB2A48.DAE17C71 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OAuth Tutorial on Friday, 9am

Hi all,

As mentioned in the meeting agenda = Blaine and myself thought it would be useful to schedule a tutorial = about OAuth during the IETF week.

The morning slot (9am till max 11:30am) = on Friday seems to be good.

I will organize a meeting room. Details = will be provided later.

Ciao
Hannes & Blaine

------_=_NextPart_001_01CB2A48.DAE17C71-- From balfanz@google.com Fri Jul 23 10:58: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 50BBF3A676A for ; Fri, 23 Jul 2010 10:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.809 X-Spam-Level: X-Spam-Status: No, score=-105.809 tagged_above=-999 required=5 tests=[AWL=0.167, 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 xer-Uu43oOxR for ; Fri, 23 Jul 2010 10:58:17 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DD7503A69EF for ; Fri, 23 Jul 2010 10:58:16 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o6NHwXuB014563 for ; Fri, 23 Jul 2010 10:58:33 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279907914; bh=et2e0ezYaWukIx3N9CSVpq+2zkQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=jR58dLlryVrUDwWe6spdK2rx5ULexgWKYIhgRdKShczgjwthEMl4lsgqEkMBbEgz4 v46a+hjSdcS/W4H1gSBHg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=S4SyaNqMa3eTURWms3/Kk+BmPK0eM/OTuC+BQXFEqTtZLAWhxi5PI/5z+a22h0HbT mbQacbodmLwQq3Lfcc3sw== Received: from yxs7 (yxs7.prod.google.com [10.190.5.135]) by wpaz37.hot.corp.google.com with ESMTP id o6NHvuc1002112 for ; Fri, 23 Jul 2010 10:58:32 -0700 Received: by yxs7 with SMTP id 7so4035039yxs.0 for ; Fri, 23 Jul 2010 10:58:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.99.12 with SMTP id w12mr4281045anb.157.1279907912023; Fri, 23 Jul 2010 10:58:32 -0700 (PDT) Received: by 10.231.130.9 with HTTP; Fri, 23 Jul 2010 10:58:31 -0700 (PDT) In-Reply-To: References: <4C431BA3.2000907@lodderstedt.net> Date: Fri, 23 Jul 2010 10:58:31 -0700 Message-ID: From: Dirk Balfanz To: Nat Sakimura Content-Type: multipart/alternative; boundary=0016e645ada07101c7048c11c8ab X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] signatures, v2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 17:58:18 -0000 --0016e645ada07101c7048c11c8ab Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 21, 2010 at 1:26 AM, Nat Sakimura wrote: > Hi Dirk, > > Inline: > > On Tue, Jul 20, 2010 at 9:22 AM, Dirk Balfanz wrote: > > > > > > On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt > > wrote: > >> > >> Hi Dirk, > >> > >> I have some questions concerning your proposal: > >> > >> - As far as I understand, the difference to "magic signatures" lays in > the > >> usage of a JSON token carrying issuer, not_before, not_after and > audience. > >> While such properties are important for security tokens (assertions), I > >> cannot see an advantage of using this format for signatures of HTTP > >> requests. Would you please explain? > > > > You mean advantage over magic signatures? It's really a similar idea - > it's > > just that magic signatures as is don't quite fit the bill. For example, > they > > have newlines in > > them: > http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html#anchor5 > > Well, they MAY, but they do not have to. Would not profiling Magic > Signatures so that it does not contain newlines do? > I'll look into it. There are some other differences, like HMAC signatures in addition to RSA, X.509 encodings of certs, but perhaps those differences can be smoothed over in favor for a common spec. I'll talk to John Panzer. Dirk. > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > --0016e645ada07101c7048c11c8ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 21, 2010 at 1:26 AM, Nat Sak= imura <sakimura@= gmail.com> wrote:
Hi Dirk,

Inline:

On Tue, Jul 20, 2010 at 9:22 AM, Dirk Balfanz <balfanz@google.com> wrote:
>
>
> On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt
> <torsten@lodderstedt.net= > wrote:
>>
>> Hi Dirk,
>>
>> I have some questions concerning your proposal:
>>
>> - As far as I understand, the difference to "magic signatures= " lays in the
>> usage of a JSON token carrying issuer, not_before, not_after and a= udience.
>> While such properties are important for security tokens (assertion= s), I
>> cannot see an advantage of using this format for signatures of HTT= P
>> requests. Would you please explain?
>
> You mean advantage over magic signatures? It's really a similar id= ea - it's
> just that magic signatures as is don't quite fit the bill. For exa= mple, they
> have newlines in
> them:=A0http://salmon-protoco= l.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html#anchor5

Well, they MAY, but they do not have to. Would not profiling Magic Signatures so that it does not contain newlines do?
I'll look into it. There are some other differences, like = HMAC signatures in addition to RSA, X.509 encodings of certs, but perhaps t= hose differences can be smoothed over in favor for a common spec. I'll = talk to John Panzer.

Dirk.
=A0



--
Nat Sakimura (=3Dnat)
http://www.sakimu= ra.org/en/
http://twitter.com= /_nat_en

--0016e645ada07101c7048c11c8ab-- From balfanz@google.com Fri Jul 23 11:45: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 8994B3A6A10 for ; Fri, 23 Jul 2010 11:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU-2bz-QBpgj for ; Fri, 23 Jul 2010 11:45:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 5FDBD3A6A6C for ; Fri, 23 Jul 2010 11:45:16 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o6NIjW7q027843 for ; Fri, 23 Jul 2010 11:45:32 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279910732; bh=Qw2/k5vgCMLeO49WfAK4Bi4+L0w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=lSF/gJFXj3uTi+Wqi2qCLommNH3GAB1/lIYj/gmV7wL0lhB/wuP7l0zWLajLu770L TZX4xhfCEOwrs6yVtxFGA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=q8NwFRn34cWUkhDHtFlsQW6KhiRTMzlZlL8zXjXDehcPQsAST53Qd8hlv89vhBeQ8 RW1uIgIKxg4+Nujjt7pmw== Received: from iwn7 (iwn7.prod.google.com [10.241.68.71]) by hpaq7.eem.corp.google.com with ESMTP id o6NIjUrk021280 for ; Fri, 23 Jul 2010 11:45:31 -0700 Received: by iwn7 with SMTP id 7so589206iwn.33 for ; Fri, 23 Jul 2010 11:45:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.139 with SMTP id m11mr3897176iby.136.1279910730408; Fri, 23 Jul 2010 11:45:30 -0700 (PDT) Received: by 10.231.130.9 with HTTP; Fri, 23 Jul 2010 11:45:30 -0700 (PDT) In-Reply-To: <4C48BFD2.9060406@lodderstedt.net> References: <4C431BA3.2000907@lodderstedt.net> <4C48BFD2.9060406@lodderstedt.net> Date: Fri, 23 Jul 2010 11:45:30 -0700 Message-ID: From: Dirk Balfanz To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=005045013c646e2f54048c127073 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] signatures, v2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 18:45:29 -0000 --005045013c646e2f54048c127073 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 22, 2010 at 3:01 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > > On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi Dirk, >> >> I have some questions concerning your proposal: >> >> - As far as I understand, the difference to "magic signatures" lays in the >> usage of a JSON token carrying issuer, not_before, not_after and audience. >> While such properties are important for security tokens (assertions), I >> cannot see an advantage of using this format for signatures of HTTP >> requests. Would you please explain? >> > > You mean advantage over magic signatures? It's really a similar idea - > it's just that magic signatures as is don't quite fit the bill. For example, > they have newlines in them: > http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html#anchor5 > > > I mean, what is the reason for including issuer, not_before, not_after and > audience into a signature? > If the attacker could change the audience field without invalidating the token, then parties other than the one for which the token is intended could be tricked into accepting it. Similarly, if the attacker could change the not_before and not_after fields without invalidating the token, then the attacker could re-use an old token without detection. I'm not sure what would happen if the issuer field was outside the signed payload, but I'd rather be safe than sorry, and include it in the signature. > - Key management >> From my point of view, your proposal does cover key management for web >> applications using RSA signatures. What about web applications intending to >> sign resource server requests using HMAC (for performance reasons)? Do they >> need to exchange secrets with the resource server? >> > > Correct - I'm not saying how HMAC keys are being distributed. Presumably, > you would use a similar system to what many platform providers use today - > you sign up as a developer, and they give you a "developer key" (or "API > key"). > > > Such a system will work for a relatively static relation between client and > server only. Do you suggest a client should register with every resource > server in advance? > I'm personally in favor of using RSA keys and not requiring registration, but there are legitimate reasons for taking the opposite approach - for example, resource servers might require registration because they want developers to sign ToSs and such. > What about dynamic clients? Suppose a client is just configured with a URL > pointing to a PortableContacts resource. The client discovers the respective > authz server and obtains a token. What if the client wants to sign the > messages to the resource server? > I would propose to use RSA signing in this case. > What about installed applications (mobile, desktop, set top boxes, >> gaming devices)? >> > > I don't think that installed apps can ever authenticate themselves (i.e., > prove the statement "I am a copy of the FooBar app"), so I'm not trying to > solve that. What we _can_ do is deliver OAuth tokens to an installed app of > the user's choice, but the server won't know who received the token - only > the user does. > > > I think we can do more. Even installed applications can use signatures to > protect messages on transport. What about that use case? Clearly they need > appropriate key material. The token secret issued by the authorization > server could server that purpose. > What would the purpose of that signature be? Let's look at a few possibilities: - "I prove that I'm really a copy of the FooBar app"? You're just not gonna be able to do that, because client apps can't keep secrets. - "I prove that I'm the legitimate holder of this token"? If you don't leak the token, then presenting the token itself proves this. Use SSL if you're worried about leaking the token in transport. - "I prove that the request wasn't tampered with in transport."? Use SSL. What do you think? Dirk. > > > >> 1) RSA: Do they need to provide their public key on a web server? This >> would be an additional requirement for such applications. >> 2) HMAC: Same as for web apps, but even harder because either (a) the >> installed app has a static secret burned >> into source code or (b) it needs to use a protocol for dynamic key >> management the resource server has to implement. Is this the plan? >> >> > regards, > Torsten. > --005045013c646e2f54048c127073 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jul 22, 2010 at 3:01 PM, Torsten= Lodderstedt <torsten@lodderstedt.net> wrote:
=20

On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Dirk,

I have some questions concerning your proposal:

- As far as I understand, the difference to "magic signatures" la= ys in the usage of a JSON token carrying issuer, not_before, not_after and audience. While such properties are important for security tokens (assertions), I cannot see an advantage of using this format for signatures of HTTP requests. Would you please explain?

You mean advantage over magic signatures? It's really a similar idea - it's just that magic signatures as is don't quite fit the bi= ll. For example, they have newlines in them:=A0http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magic= sig-00.html#anchor5

I mean, what is the reason for including issuer, not_before, not_after and audience into a signature?

If the att= acker could change the audience field without invalidating the token, then = parties other than the one for which the token is intended could be tricked= into accepting it.
Similarly, if the attacker could change the not_before and not_after f= ields without invalidating the token, then the attacker could re-use an old= token without detection.
I'm not sure what would happen if t= he issuer field was outside the signed payload, but I'd rather be safe = than sorry, and include it in the signature.
=A0
- Key management
>From my point of view, your proposal does cover key management for web applications using RSA signatures. What about web applications intending to sign resource server requests using HMAC (for performance reasons)? Do they need to exchange secrets with the resource server?

Correct - I'm not saying how HMAC keys are being distributed. Presumably, you would use a similar system to what many platform providers use today - you sign up as a developer, and they give you a "developer key" (or "API key").

Such a system will work for a relatively static relation between client and server only. Do you suggest a client should register with every resource server in advance?

I'= ;m personally in favor of using RSA keys and not requiring registration, bu= t there are legitimate reasons for taking the opposite approach - for examp= le, resource servers might require registration because they want developer= s to sign ToSs and such.
=A0
What about dynamic clients? Suppose a client is just configured with a URL pointing to a PortableContacts resource. The client discovers the respective authz server and obtains a token. What if the client wants to sign the messages to the resource server?

I would propose to use RSA signing in this case.
=
=A0
What about installed applications (mobile, desktop, set top boxes, gaming devices)?

I don't think that installed apps can ever authenticate themselves (i.e., prove the statement "I am a copy of the FooBar app&q= uot;), so I'm not trying to solve that. What we _can_ do is deliver OAuth tokens to an installed app of the user's choice, but the server won'= ;t know who received the token - only the user does.

I think we can do more. Even installed applications can use signatures to protect messages on transport. What about that use case? Clearly=A0they need appropriate key material.=A0The token secret=A0 issued = by the authorization server could server that purpose.
=
What would the purpose of that signature be? Let's look = at a few possibilities:

- "I prove that I'= ;m really a copy of the FooBar app"? You're just not gonna be able= to do that, because client apps can't keep secrets.
- "I prove that I'm the legitimate holder of this token"= ? If you don't leak the token, then presenting the token itself proves = this. Use SSL if you're worried about leaking the token in transport.
- "I prove that the request wasn't tampered with in transport= ."? Use SSL.

What do you think?
=A0=
Dirk.



=A0
=A01) RSA: Do they need to provide their public key on a web server? This would be an additional requirement for such applications.
=A02) HMAC: Same as for web apps, but even harder because either (a) the installed app has a static secret burned
into source code or (b) it needs to use a protocol for dynamic key management the resource server has to implement. Is this the plan?


regards,
Torsten.

--005045013c646e2f54048c127073-- From ketanpadegaonkar@gmail.com Fri Jul 23 20:16:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2CE73A6958 for ; Fri, 23 Jul 2010 20:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN24nso0dJ1V for ; Fri, 23 Jul 2010 20:16:19 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 8981B3A6903 for ; Fri, 23 Jul 2010 20:16:19 -0700 (PDT) Received: by pzk6 with SMTP id 6so420409pzk.31 for ; Fri, 23 Jul 2010 20:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=n3fI89+zMsklCuhC968gjPoY5etdbl7blSY3yk7YN/c=; b=kEcY9ltl0xCNiaF9AqBbUNL29BrD7bQ0DE3E8R7Q3SDePbNE67OxnsOnB/KZYdyUzB OjC3e6awqotx8jM/oQeHYDrVzo9P6icKbh5UOCALdV4NypJBCODeI5DrBH4pZu0pcuoR Lch4Z27TlOsniStgW2+Q8h61JkAsClYZziT+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=g7ZuD4ReUS+4HCE4h0DiSnXKQkAt6SR7thwXLF1cOVRtx9vefDJv0MA14IeMalzrMy RsoNXZ8PofIlssRmZDKN0mdlez0sdSrBb3XO0Ewat2i1AGggKortRPR0X+sCKiPp8Ml6 J4K2LQybuwjNIyY7cZ7UoaP2UuvZ6g8GoY+gI= Received: by 10.142.231.12 with SMTP id d12mr5171866wfh.242.1279941398164; Fri, 23 Jul 2010 20:16:38 -0700 (PDT) Received: from storm.corporate.thoughtworks.com (c-98-210-165-74.hsd1.ca.comcast.net [98.210.165.74]) by mx.google.com with ESMTPS id r27sm1048127rvq.9.2010.07.23.20.16.35 (version=SSLv3 cipher=RC4-MD5); Fri, 23 Jul 2010 20:16:36 -0700 (PDT) Message-ID: <4C4A5B12.4000600@gmail.com> Date: Fri, 23 Jul 2010 20:16:34 -0700 From: Ketan Padegaonkar User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: OAuth-WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] [ANN] OSS OAuth 2.0 Provider Implementation based on v09 of the OAuth 2 draft X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Jul 2010 03:16:20 -0000 Hi all, We've put together an open-source implementation based on the v09 of OAuth 2.0 draft spec. This implementation currently supports the Web-Server flow. This has been brewing for a few weeks and is starting to get ready. Any feedback, inputs and contributions from people wanting to adopt oauth2 are welcome. We'll try our best to implement them :-) The implementation is currently written in Ruby On Rails, has adequate tests that may be useful for developers writing implementations based on other languages and platforms. Read more about getting started with it on the github page: http://github.com/ThoughtWorksStudios/oauth2_provider Some videos we planed on using internally to educate people about oauth. We think they might be useful outside of our organization as well: http://www.youtube.com/view_play_list?p=675281900139F609 Cheers! -- Ketan http://studios.thoughtworks.com | @ketanpkr From michael.d.adams@gmail.com Sat Jul 24 02:23: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 599933A67D7 for ; Sat, 24 Jul 2010 02:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ue4+AkJI9Fkm for ; Sat, 24 Jul 2010 02:23:46 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2AFEE3A693F for ; Sat, 24 Jul 2010 02:23:46 -0700 (PDT) Received: by iwn38 with SMTP id 38so1102022iwn.31 for ; Sat, 24 Jul 2010 02:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; bh=9/Ao9bheUz9RkoLBwWQeX1QKanDzRrZSjt0UprwvuTY=; b=thsl1O6yicDXC0pci8/zIWF+l8+uC5SOZ1/lISmxDThVGq6bAbGPmvPCsNfabe8V+B FGDId8DBD3V43u2bhlJVmIy1EI0zMJfphUxzb/6lXQb1pC2zVqQGnU/eLWgbQo6CCLRD hLiTXapdLL1DSDfb8VLjWdUf7haNV8T0eWUOE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=UlHFJ++FC6ZKLF3AjfSX/mDblZ5LCOLWOfICjYAtoFQxIApgQlWYgaTMxqMXNXOuEi 7lGKUtTQepTaphBJx5xg5CWDhvitF0X4eY/gEWpwJz+xsjNJMjZ3iwBFDJOUXQE5QEkJ k0Ah3jvzmU+FjjhbRcIeIJSIYF8niZ/fRhfCU= Received: by 10.231.174.136 with SMTP id t8mr5091091ibz.158.1279963445122; Sat, 24 Jul 2010 02:24:05 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.179.143 with HTTP; Sat, 24 Jul 2010 02:23:45 -0700 (PDT) In-Reply-To: References: From: Michael D Adams Date: Sat, 24 Jul 2010 02:23:45 -0700 X-Google-Sender-Auth: ZNqHIMz8mMyfOFvxkkhrXmfwt54 Message-ID: To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] End-User Authorization Endpoint is an Open Redirect X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Jul 2010 09:23:48 -0000 The second to last paragraph in section 3 of draft-10 states: > The authorization server validates the request to ensure all required > parameters are present and valid. =A0If the request is invalid, the > authorization server immediately redirects the user-agent back to the > client using the redirection URI provided with the appropriate error > code as described in Section 3.2. There's a couple problems here. 1. What if the client didn't register a redirect_uri and also didn't include one in the request? =A0The request is invalid, but there's nowhere to redirect the user-agent. 2. A malicious client can use the end-user authorization endpoint as an open redirect by intentionally making an invalid request. =A0For example: End-User Authorization Endpoint: http://service.example.com/oauth/authorize= / Malicious Site: http://jerk.example.net/ I send a phishing attempt to a user of service.example.com with something like the following link in it: http://service.example.com/oauth/authorize/?redirect_uri=3Dhttp%3A%2F%2Fjer= k.example.net%2Fsteal-your-identity%2F&response_type=3Dhaha The link looks OK at a glance, but clicking on it takes the victim to: http://jerk.example.net/steal-your-identity/?error=3Dunsupported_response_t= ype And now I do whatever evil thing I've planned. Mike --mdawaffe From andrewarnott@gmail.com Sun Jul 25 10:11:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DC4B3A6826 for ; Sun, 25 Jul 2010 10:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.613, 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 aBaHt1Wud2GX for ; Sun, 25 Jul 2010 10:11:08 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 437CB3A68AE for ; Sun, 25 Jul 2010 10:11:08 -0700 (PDT) Received: by iwn38 with SMTP id 38so2178557iwn.31 for ; Sun, 25 Jul 2010 10:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=41uqSgaJnVWmS6sNguEPZ5D85QzYiQLWXOSwOdYGlfo=; b=U6O8oet4DrjUbruSxVBXMtuMJjo+D+1efVcNC2+Dh9Jl3Z1CTZyf01so1WXneQYS9s K+73ZFu1+YhMofw9uM30c9cE0t76W6UbgJND3FZ7FYA1zvYBHwDseadzM9/cV2gYxlsV Sbe8D94ECBjxpCTSzWmGaUZWx561XSSCiHKZY= 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=BjSnlBH574HAXAZ7czy1vnPsPiDQz+QnCkSBqjSGAf9u+3MyHTS6NFxK5GKBGsnrEj qmja5rw8azIcYD9kGU5Eh01MZYRTYeVCJ2I81xwh1rDJQHaDpdGgZf6J1YcuWsQ3uz4X 1mdU2/8hfUrfJLaAVYYY9Zn7Ldy7Nn2zXuPlw= MIME-Version: 1.0 Received: by 10.231.39.69 with SMTP id f5mr7194999ibe.53.1280077886833; Sun, 25 Jul 2010 10:11:26 -0700 (PDT) Received: by 10.231.154.199 with HTTP; Sun, 25 Jul 2010 10:11:26 -0700 (PDT) In-Reply-To: <4C48C116.9000609@lodderstedt.net> References: <4C3F3F6A.5000409@lodderstedt.net> <4C3F9064.6060604@lodderstedt.net> <4C48C116.9000609@lodderstedt.net> Date: Sun, 25 Jul 2010 10:11:26 -0700 Message-ID: From: Andrew Arnott To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=00032557543ebac584048c395b25 Cc: OAuth WG Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Jul 2010 17:11:10 -0000 --00032557543ebac584048c395b25 Content-Type: text/plain; charset=ISO-8859-1 It seems to me that if one auth server can create tokens for a diverse set of resource servers, then why not have different user authorization endpoint URLs for each type of resource server, as an added differentiator for the scope (a namespace, if you will)? So suppose one auth server serves two different photo services, both using overlapping scopes such that a client requesting access of some scope is otherwise ambiguous between which resource server the client needs access to. The auth server that serves both resource servers could have two end user authorization endpoints: http://auth.server.org/authorize?resourceserver=1 http://auth.server.org/authorize?resourceserver=2 And that way the auth server knows exactly what the client needs. The only scenario this doesn't allow for is for a user to authorize a client's access to *both* resource servers in one redirect. If this were an issue, perhaps you can apply a namespace-like prefix to each scope substring: rs1:photo:read rs2:photo:read Which would serve a similar purpose. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > no one else in the group having an opinion on this topic? > > > > Am 15.07.2010 20:14, schrieb Marius Scurtescu: >> >>> On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt >>> wrote: >>> >>>> As I have written in my reply to Marius's posting. I'm fine with >>>> including >>>> server ids in scopes. But this requires a definition of the scope's >>>> syntax >>>> and semantics in the spec. Otherwise, scope interpretation (and server >>>> identification) will be deployment specific. >>>> >>> Sure, it is deployment specific, but why is that an issue? >>> >>> In your case, the authz server and all the resource servers are >>> managed by the same organization, right? >>> >>> Do clients need to be aware of the actual resource server? >>> >>> You can probably create a separate spec that defines scope syntax for >>> this purpose, if really needed. Does it have to be in core? >>> >>> Marius >>> >> >> Solving the challenge I described in a deployment specific way is not an >> issue. But the consequence is that authz server, resource servers and >> clients are tight together. >> >> Let me ask you one question: Why are we working together towards a >> standard protocol? I can tell you my expectations: I hope there will be >> broad support not only by libraries, but also by ready-to-use services and >> clients, so we could integrate such services into our deployment easily. >> Moreover, I would like to see OAuth to be included in application/service >> protocols like PortableContacts, SIP, WebDAV, IMAP, ... >> >> So what if I would like to use standard clients to access our services? >> Using scopes for specifying resource server id's in this case is also simple >> - if you take an isolated view. But since scopes may be used to specifiy a >> lot of other things, like resources, permissions, and durations, handling >> w/o a more detailed spec will in practice be impossible. >> >> Suppose a WebDAV service for media data access. Any WebDAV client knows >> the WebDAV protocol (== interface), e.g. the supported methods (GET, PUT, >> POST, DELETE, COPY, MOVE) and how to traverse directories. So it is >> sufficient to configure the client with the URL of my personal web storage. >> To start with let's assume, scopes are used to designate resource servers >> only. So the server's scope could be "webstorage". >> >> WWW-Authenticate OAuth realm='webstorage' scope="webstorage" >> >> The client could just pass this parameter to the authz server and >> everything is fine. >> >> On the next level, let's assume the (future) WebDAV standard with >> OAuth-support uses one permission per method type. So the full scope could >> be as follows: >> >> WWW-Authenticate OAuth realm='webstorage' scope="webstorage:GET >> webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY >> webstorage:MOVE" >> >> Passing this scope w/o any unmodified to the authz server is not an issue. >> But this implies the client asks for full access to the users media storage. >> Since our client is a gallery application, it requires the "GET" permission >> only. How does the client know which of the scope values to pick for the >> end-user authorization process? It must somehow select "webstorage:GET". >> >> But how? >> >> In my personal opinion, clients should be enabled to interpret, combine >> and even create scopes. And yes, this should go to the core of the spec. >> >> regards, >> Torsten. >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00032557543ebac584048c395b25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It seems to me that if one auth server can create tokens for a diverse set = of resource servers, then why not have different user authorization endpoin= t URLs for each type of resource server, as an added differentiator for the= scope (a namespace, if you will)?

So suppose one auth server serves two different photo servic= es, both using overlapping scopes such that a client requesting access of s= ome scope is otherwise ambiguous between which resource server the client n= eeds access to. =A0The auth server that serves both resource servers could = have two end user authorization endpoints:

And that way the auth server knows exactly what the cli= ent needs.

The only scenario this doesn't allo= w for is for a user to authorize a client's access to both=A0res= ource servers in one redirect. =A0If this were an issue, perhaps you can ap= ply a namespace-like prefix to each scope substring:

rs1:photo:read rs2:photo:read

= Which would serve a similar purpose.

--
Andr= ew Arnott
"I [may] not agree with what you have to say, but I'l= l defend to the death your right to say it." - S. G. Tallentyre


On Thu, Jul 22, 2010 at 3:07 PM, Torsten= Lodderstedt <torsten@lodderstedt.net> wrote:
no one else in the group having an opinion on this topic?



Am 15.07.2010 20:14, schrieb Marius Scurtescu:
On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
<torsten@lo= dderstedt.net> =A0wrote:
As I have written in my reply to Marius's posting. I'm fine with in= cluding
server ids in scopes. But this requires a definition of the scope's syn= tax
and semantics in the spec. Otherwise, scope interpretation (and server
identification) will be deployment specific.
Sure, it is deployment specific, but why is that an issue?

In your case, the authz server and all the resource servers are
managed by the same organization, right?

Do clients need to be aware of the actual resource server?

You can probably create a separate spec that defines scope syntax for
this purpose, if really needed. Does it have to be in core?

Marius

Solving the challenge I described in a deployment specific way is not an is= sue. But the consequence is that authz server, resource servers and clients= are tight together.

Let me ask you one question: Why are we working together towards a standard= protocol? I can tell you my expectations: I hope there will be broad suppo= rt not only by libraries, but also by ready-to-use services and clients, so= we could integrate such services into our deployment easily. Moreover, I w= ould like to see OAuth to be included in application/service protocols like= PortableContacts, SIP, WebDAV, IMAP, ...

So what if I would like to use standard clients to access our services? Usi= ng scopes for specifying resource server id's in this case is also simp= le - if you take an isolated view. But since scopes may be used to specifiy= a lot of other things, like resources, permissions, and durations, handlin= g w/o a more detailed spec will in practice be impossible.

Suppose a WebDAV service for media data access. Any WebDAV client knows the= WebDAV protocol (=3D=3D interface), e.g. the supported methods (GET, PUT, = POST, DELETE, COPY, MOVE) and how to traverse directories. So it is suffici= ent to configure the client with the URL of my personal web storage. To sta= rt with let's assume, scopes are used to designate resource servers onl= y. So the server's scope could be "webstorage".

=A0 =A0WWW-Authenticate OAuth realm=3D'webstorage' scope=3D"w= ebstorage"

The client could just pass this parameter to the authz server and everythin= g is fine.

On the next level, let's assume the (future) WebDAV standard with OAuth= -support uses one permission per method type. So the full scope could be as= follows:

=A0 =A0WWW-Authenticate OAuth realm=3D'webstorage' scope=3D"w= ebstorage:GET webstorage:PUT webstorage:POST webstorage:DELETE webstorage:C= OPY webstorage:MOVE"

Passing this scope w/o any unmodified to the authz server is not an issue. = But this implies the client asks for full access to the users media storage= . Since our client is a gallery application, it requires the "GET"= ; permission only. How does the client know which of the scope values to pi= ck for the end-user authorization process? It must somehow select "web= storage:GET".

But how?

In my personal opinion, clients should be enabled to interpret, combine and= even create scopes. And yes, this should go to the core of the spec.

regards,
Torsten.




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

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

--00032557543ebac584048c395b25-- From lshepard@facebook.com Sun Jul 25 17:36: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 46F823A6817 for ; Sun, 25 Jul 2010 17:36:26 -0700 (PDT) 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.757, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3iR+9a97k0L for ; Sun, 25 Jul 2010 17:36:25 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 527F53A67EC for ; Sun, 25 Jul 2010 17:36:25 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.198]) by pp-master.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o6Q0a6tK027501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 25 Jul 2010 17:36:09 -0700 Received: from SC-MBX06.TheFacebook.com ([169.254.5.17]) by sc-hub03.TheFacebook.com ([fe80::1cfe:1f6b:8b35:cf7f%11]) with mapi; Sun, 25 Jul 2010 17:20:01 -0700 From: Luke Shepard To: Michael D Adams Thread-Topic: [OAUTH-WG] End-User Authorization Endpoint is an Open Redirect Thread-Index: AQHLKxH71feAsN0cgk2TmkMqUQCpkpLCz8MA Date: Mon, 26 Jul 2010 00:19:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <57e96042-83c7-4dc8-858e-a509a0d24238> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-25_02:2010-07-25, 2010-07-25, 1970-01-01 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] End-User Authorization Endpoint is an Open Redirect X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Jul 2010 00:36:26 -0000 This is a great point. Facebook validates that the client_id matches the registered redirect_uri b= efore giving a redirect error. Otherwise, just display a screen directly sa= ying that the app is misconfigured. Mis-specifying the redirect_uri is the = type of error that should normally be caught in development, so there's no = need for an official error code for it (since it shouldn't ever happen in p= roduction). We should specify that the provider should only redirect an error code to a= known-good location (or at least, a somewhat vetted one) to prevent open r= edirectors. On Jul 24, 2010, at 2:23 AM, Michael D Adams wrote: > The second to last paragraph in section 3 of draft-10 states: >=20 >> The authorization server validates the request to ensure all required >> parameters are present and valid. If the request is invalid, the >> authorization server immediately redirects the user-agent back to the >> client using the redirection URI provided with the appropriate error >> code as described in Section 3.2. >=20 > There's a couple problems here. >=20 > 1. What if the client didn't register a redirect_uri and also didn't > include one in the request? The request is invalid, but there's > nowhere to redirect the user-agent. >=20 > 2. A malicious client can use the end-user authorization endpoint as > an open redirect by intentionally making an invalid request. For > example: >=20 > End-User Authorization Endpoint: http://service.example.com/oauth/authori= ze/ > Malicious Site: http://jerk.example.net/ >=20 > I send a phishing attempt to a user of service.example.com with > something like the following link in it: >=20 > http://service.example.com/oauth/authorize/?redirect_uri=3Dhttp%3A%2F%2Fj= erk.example.net%2Fsteal-your-identity%2F&response_type=3Dhaha >=20 > The link looks OK at a glance, but clicking on it takes the victim to: >=20 > http://jerk.example.net/steal-your-identity/?error=3Dunsupported_response= _type >=20 > And now I do whatever evil thing I've planned. >=20 > Mike > --mdawaffe > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Mon Jul 26 05:08:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6513A68FD for ; Mon, 26 Jul 2010 05:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 9s98kI2Xa757 for ; Mon, 26 Jul 2010 05:08:19 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 7BF7E3A68D9 for ; Mon, 26 Jul 2010 05:08:18 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6QC8cai012621 for ; Mon, 26 Jul 2010 08:08:38 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6QC8cAn012618; Mon, 26 Jul 2010 08:08:38 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.210]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 26 Jul 2010 08:08:38 -0400 From: "Richer, Justin P." To: Luke Shepard , Michael D Adams Date: Mon, 26 Jul 2010 08:07:06 -0400 Thread-Topic: [OAUTH-WG] End-User Authorization Endpoint is an Open Redirect Thread-Index: AQHLKxH71feAsN0cgk2TmkMqUQCpkpLCz8MAgABQOyM= Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] End-User Authorization Endpoint is an Open Redirect X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Jul 2010 12:08:20 -0000 And this is even a bigger potential problem when you combine it with unregi= stered or dynamically-registered clients, which we know some instances are = going to support. In these cases, though, it's hard to trust *any* URL that= the client is asking for, even for valid responses.=20 -- justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Luke She= pard [lshepard@facebook.com] Sent: Sunday, July 25, 2010 8:19 PM To: Michael D Adams Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] End-User Authorization Endpoint is an Open Redirect This is a great point. Facebook validates that the client_id matches the registered redirect_uri b= efore giving a redirect error. Otherwise, just display a screen directly sa= ying that the app is misconfigured. Mis-specifying the redirect_uri is the = type of error that should normally be caught in development, so there's no = need for an official error code for it (since it shouldn't ever happen in p= roduction). We should specify that the provider should only redirect an error code to a= known-good location (or at least, a somewhat vetted one) to prevent open r= edirectors. On Jul 24, 2010, at 2:23 AM, Michael D Adams wrote: > The second to last paragraph in section 3 of draft-10 states: > >> The authorization server validates the request to ensure all required >> parameters are present and valid. If the request is invalid, the >> authorization server immediately redirects the user-agent back to the >> client using the redirection URI provided with the appropriate error >> code as described in Section 3.2. > > There's a couple problems here. > > 1. What if the client didn't register a redirect_uri and also didn't > include one in the request? The request is invalid, but there's > nowhere to redirect the user-agent. > > 2. A malicious client can use the end-user authorization endpoint as > an open redirect by intentionally making an invalid request. For > example: > > End-User Authorization Endpoint: http://service.example.com/oauth/authori= ze/ > Malicious Site: http://jerk.example.net/ > > I send a phishing attempt to a user of service.example.com with > something like the following link in it: > > http://service.example.com/oauth/authorize/?redirect_uri=3Dhttp%3A%2F%2Fj= erk.example.net%2Fsteal-your-identity%2F&response_type=3Dhaha > > The link looks OK at a glance, but clicking on it takes the victim to: > > http://jerk.example.net/steal-your-identity/?error=3Dunsupported_response= _type > > And now I do whatever evil thing I've planned. > > Mike > --mdawaffe > _______________________________________________ > 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 Jul 26 10:29: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 EE81C3A6883 for ; Mon, 26 Jul 2010 10:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.615 X-Spam-Level: X-Spam-Status: No, score=-105.615 tagged_above=-999 required=5 tests=[AWL=0.362, 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 Syly0RkHalvy for ; Mon, 26 Jul 2010 10:29:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 083403A67E3 for ; Mon, 26 Jul 2010 10:29:57 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o6QHUIb2023330 for ; Mon, 26 Jul 2010 10:30:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280165418; bh=G5A63QWdP6CU9YlDePLhp4mbnlc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ZYb/6JOjAfR9GYYv9F2gPx7ue89UR0yTlfZUkQvas7DUU7y5e0KQ26DVuKu3Af5Xp wc5/aw2znJ32kTo/VAN9A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=Cl8uojhtL9EpFQGrvF0O1DMpPq+Qh9BjoxlNXA5c2faWMYdkOWgFtqXpppvejfjdG fTnU0123ddAqy8UEtvrFw== Received: from gwb20 (gwb20.prod.google.com [10.200.2.20]) by hpaq5.eem.corp.google.com with ESMTP id o6QHSkCF017926 for ; Mon, 26 Jul 2010 10:30:17 -0700 Received: by gwb20 with SMTP id 20so152816gwb.19 for ; Mon, 26 Jul 2010 10:30:16 -0700 (PDT) Received: by 10.100.31.7 with SMTP id e7mr8116160ane.58.1280165416195; Mon, 26 Jul 2010 10:30:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.33.1 with HTTP; Mon, 26 Jul 2010 10:29:56 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Mon, 26 Jul 2010 10:29:56 -0700 Message-ID: To: "Richer, Justin P." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] End-User Authorization Endpoint is an Open Redirect X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Jul 2010 17:29:59 -0000 On Mon, Jul 26, 2010 at 5:07 AM, Richer, Justin P. wrot= e: > And this is even a bigger potential problem when you combine it with unre= gistered or dynamically-registered clients, which we know some instances ar= e going to support. In these cases, though, it's hard to trust *any* URL th= at the client is asking for, even for valid responses. The user must approve a valid response, so it should not work as a redirector. Right? An immediate mode will only work if the user explicitly approved at least once in the past. Marius From lshepard@facebook.com Mon Jul 26 12:01: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 D8DF53A6934 for ; Mon, 26 Jul 2010 12:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hp01XNFG4yk5 for ; Mon, 26 Jul 2010 12:01:16 -0700 (PDT) Received: from mx-out.facebook.com (outmail015.snc1.tfbnw.net [69.63.178.174]) by core3.amsl.com (Postfix) with ESMTP id 3870D3A6886 for ; Mon, 26 Jul 2010 12:00:58 -0700 (PDT) Received: from [10.18.255.123] ([10.18.255.123:22656] helo=mail.thefacebook.com) by mta007.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 32/B8-11806-F7BDD4C4; Mon, 26 Jul 2010 12:01:19 -0700 Received: from SC-MBX06.TheFacebook.com ([169.254.5.17]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Mon, 26 Jul 2010 12:01:18 -0700 From: Luke Shepard To: Marius Scurtescu Thread-Topic: [OAUTH-WG] End-User Authorization Endpoint is an Open Redirect Thread-Index: AQHLKxH71feAsN0cgk2TmkMqUQCpkpLCz8MAgABQOyOAAM+KAIAAGYaA Date: Mon, 26 Jul 2010 19:01:17 +0000 Message-ID: <2FA80E40-B112-457A-9179-040EDD8B1642@facebook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <9030aae3-e545-4f71-ae0c-baf2b89a910f> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] End-User Authorization Endpoint is an Open Redirect X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Jul 2010 19:01:17 -0000 Correct. If the user has to approve the response, then it doesn't function = as an open redirector. I'm only worried about returning an error immediatel= y. On Jul 26, 2010, at 10:29 AM, Marius Scurtescu wrote: > On Mon, Jul 26, 2010 at 5:07 AM, Richer, Justin P. wr= ote: >> And this is even a bigger potential problem when you combine it with unr= egistered or dynamically-registered clients, which we know some instances a= re going to support. In these cases, though, it's hard to trust *any* URL t= hat the client is asking for, even for valid responses. >=20 > The user must approve a valid response, so it should not work as a > redirector. Right? >=20 > An immediate mode will only work if the user explicitly approved at > least once in the past. >=20 > Marius From yarong@microsoft.com Mon Jul 26 13:22:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EBF33A698C for ; Mon, 26 Jul 2010 13:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.491 X-Spam-Level: X-Spam-Status: No, score=-9.491 tagged_above=-999 required=5 tests=[AWL=-1.307, BAYES_40=-0.185, 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 SZ9HYcHUpO0d for ; Mon, 26 Jul 2010 13:22:09 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 703CF3A69AC for ; Mon, 26 Jul 2010 13:22:07 -0700 (PDT) Received: from TK5EX14CASC130.redmond.corp.microsoft.com (157.54.52.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 26 Jul 2010 13:22:27 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.180]) by TK5EX14CASC130.redmond.corp.microsoft.com ([157.54.52.9]) with mapi id 14.01.0180.004; Mon, 26 Jul 2010 13:22:26 -0700 From: Yaron Goland To: "oauth@ietf.org" Thread-Topic: Proposed language for section 2.2 on Client Assertions Thread-Index: Acss+/FbLVdP6lGhTzeiP/E0ASfiwQ== Date: Mon, 26 Jul 2010 20:22:28 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C6294F782@TK5EX14MBXC113.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_7C01E631FF4B654FA1E783F1C0265F8C6294F782TK5EX14MBXC113r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Jul 2010 20:22:19 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C6294F782TK5EX14MBXC113r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following is proposed language for inclusion in the spec as section 2.2= . I would like to thank Brian Campbell, Brain Eaton, Chuck Mortimore, Dirk = Balfanz, Eric Sachs, Justin Smith and Marius Scurtescu for taking the time = to review and improve this proposal. Please note that the named folks contr= ibuted the good ideas and I just focused on introducing anything that is br= oken. So what does the group think? +1? -1? Thanks, Yaron 2.2 Assertion Client Credentials While Client Passwords provide a simple mechanism for authenticating client= s they require that a secret, the password, be sent over the network. Even = when the network connection is encrypted sending secrets over a network con= nection is considered a potentially serious security threat. In scenarios w= here security is at a premium, it is preferred to use mechanisms such as Ha= sh-based Message Authentication Codes (HMACs) or digital signatures that do= not require sending secrets across the wire. The most common way to use HM= ACs or digital signatures is in assertions. Therefore this section defines = how to authenticate a client using an assertion instead of a password. The following parameters are used when a client authenticates itself using = an assertion: client_assertion_type REQUIRED. The format of the assertion as defined by the aut= horization server. The value MUST be an absolute URI. client_assertion REQUIRED. The client assertion. For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=3Dauthorization_code& client_assertion=3DPHNhbWxwOl...[omitted for brevity]...ZT4= %3D& client_assertion_type=3Durn%3Aoasis%3Anames%sAtc%3ASAML%3A2= .0%3Aassertion& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb In the previous example the client is submitting an authorization code to a= token endpoint using a SAML assertion to authenticate itself. The client_id and client_secret parameters MUST NOT be used with the client= _assertion and client_assertion_type parameters. Requests for end user authorization as defined in section 3 are required to= contain a client_id parameter. If the response to the authorization reques= t is a code then that code is submitted to a token endpoint to obtain an ac= cess token. For this flow to work with assertions there must exist some mec= hanism to map the value in the client_id parameter of the authorization req= uest to the assertion that is subsequently submitted with the code to get a= n access token. How this works with any particular assertion type is out of= scope for this document. However, any document that defines how to use an = assertion of a particular type with OAuth 2.0 MUST define how to map the va= lue from the client_id parameter in the authorization request to a value or= values in the assertion subsequently submitted with the code to obtain an = access token. Token endpoints MUST reject assertions that do not contain HMAC/signed valu= es that identify that the assertion is specifically intended to be consumed= by the receiving endpoint. This requirement is typically met by some value= in the assertion such as audience or recipient which contains the token en= dpoint's URI or other agreed upon identifier. Token endpoints MUST reject assertions that do not contain HMAC/signed valu= es that identify the entity that generated the assertion. This requirement = is typically met by some value in the assertion such as issuer which contai= ns a URI or other agreed upon identifier that identifies the entity that ge= nerated the assertion. Token endpoints MUST reject assertions that do not contain HMAC/signed valu= es that identify when the assertion is to expire as an absolute time. This = requirement is typically met by some value in the assertion such as expirat= ion that contains a UTC date/time value or equivalent time stamp identifyin= g when the assertion will expire. Token endpoints MUST reject assertions wh= ose expiration time is beyond a certain limit in the future. The definition= of that limit MUST be based on the security requirements of the resource b= eing protected. The limits to choose for any particular type of resource/da= ta are application specific and depend upon a combination of what technolog= ies are being used, what key policies are being followed, what laws may app= ly, etc. and therefore are out of scope for this document. --_000_7C01E631FF4B654FA1E783F1C0265F8C6294F782TK5EX14MBXC113r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The following is proposed language for inclusion in = the spec as section 2.2. I would like to thank Brian Campbell, Brain Eaton,= Chuck Mortimore, Dirk Balfanz, Eric Sachs, Justin Smith and Marius Scurtes= cu for taking the time to review and improve this proposal. Please note that the named folks contributed the go= od ideas and I just focused on introducing anything that is broken.

 

So what does the group think? +1? -1?=

 

        &nbs= p;       Thanks,

        &nbs= p;            &= nbsp;          Yaron

 

2.2 Assertion Client C= redentials

 

While Client Passwords= provide a simple mechanism for authenticating clients they require that a = secret, the password, be sent over the network. Even when the network conne= ction is encrypted sending secrets over a network connection is considered a potentially serious security threat. = In scenarios where security is at a premium, it is preferred to use mechani= sms such as Hash-based Message Authentication Codes (HMACs) or digital sign= atures that do not require sending secrets across the wire. The most common way to use HMACs or digital signa= tures is in assertions. Therefore this section defines how to authenticate = a client using an assertion instead of a password.

 

The following paramete= rs are used when a client authenticates itself using an assertion:

 

client_assertion_type<= o:p>

   &nbs= p;            REQUIR= ED. The format of the assertion as defined by the authorization server.&nbs= p; The value MUST be an absolute URI.

client_assertion<= /o:p>

   &nbs= p;            REQUIR= ED. The client assertion.

For example (line brea= ks are for display purposes only):

 

   &nbs= p;            POST /= token HTTP/1.1

   &nbs= p;            Host: = server.example.com

   &nbs= p;            Conten= t-Type: application/x-www-form-urlencoded

 

   &nbs= p;            grant_= type=3Dauthorization_code&

   &nbs= p;            client= _assertion=3DPHNhbWxwOl...[omitted for brevity]...ZT4%3D&

   &nbs= p;            client= _assertion_type=3Durn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&

   &nbs= p;            redire= ct_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

 

In the previous exampl= e the client is submitting an authorization code to a token endpoint using = a SAML assertion to authenticate itself.

 

The client_id and clie= nt_secret parameters MUST NOT be used with the client_assertion and client_= assertion_type parameters.

 

Requests for end user = authorization as defined in section 3 are required to contain a client_id p= arameter. If the response to the authorization request is a code then that = code is submitted to a token endpoint to obtain an access token. For this flow to work with assertions there mus= t exist some mechanism to map the value in the client_id parameter of the a= uthorization request to the assertion that is subsequently submitted with t= he code to get an access token. How this works with any particular assertion type is out of scope for this= document. However, any document that defines how to use an assertion of a = particular type with OAuth 2.0 MUST define how to map the value from the cl= ient_id parameter in the authorization request to a value or values in the assertion subsequently submitted with = the code to obtain an access token.

 

Token endpoints MUST r= eject assertions that do not contain HMAC/signed values that identify that = the assertion is specifically intended to be consumed by the receiving endp= oint. This requirement is typically met by some value in the assertion such as audience or recipient which con= tains the token endpoint’s URI or other agreed upon identifier.<= /o:p>

 

Token endpoints MUST r= eject assertions that do not contain HMAC/signed values that identify the e= ntity that generated the assertion. This requirement is typically met by so= me value in the assertion such as issuer which contains a URI or other agreed upon identifier that identifies the e= ntity that generated the assertion.

 

Token endpoints MUST r= eject assertions that do not contain HMAC/signed values that identify when = the assertion is to expire as an absolute time. This requirement is typical= ly met by some value in the assertion such as expiration that contains a UTC date/time value or equivalent time = stamp identifying when the assertion will expire. Token endpoints MUST reje= ct assertions whose expiration time is beyond a certain limit in the future= . The definition of that limit MUST be based on the security requirements of the resource being protected. The= limits to choose for any particular type of resource/data are application = specific and depend upon a combination of what technologies are being used,= what key policies are being followed, what laws may apply, etc. and therefore are out of scope for this document= .

 

--_000_7C01E631FF4B654FA1E783F1C0265F8C6294F782TK5EX14MBXC113r_-- From eran@hueniverse.com Mon Jul 26 14: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 896573A6842 for ; Mon, 26 Jul 2010 14:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.136, 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 fIB-E+AbdjdB for ; Mon, 26 Jul 2010 14:08:12 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id A46F03A6832 for ; Mon, 26 Jul 2010 14:08:12 -0700 (PDT) Received: (qmail 10687 invoked from network); 26 Jul 2010 21:08:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jul 2010 21:08:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 26 Jul 2010 14:08:20 -0700 From: Eran Hammer-Lahav To: Yaron Goland , "oauth@ietf.org" Date: Mon, 26 Jul 2010 14:08:24 -0700 Thread-Topic: Proposed language for section 2.2 on Client Assertions Thread-Index: Acss+/FbLVdP6lGhTzeiP/E0ASfiwQACjJQw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EF900AE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C6294F782@TK5EX14MBXC113.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C6294F782@TK5EX14MBXC113.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: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3EF900AEP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Jul 2010 21:08:23 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EF900AEP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable By not incorporating the client_id parameter, you are preventing this clien= t authentication mode from being used with the end-user authorization endpo= int. In -09 I tried to separate the client_id from the client_secret, basic= ally moving the client_id to the token endpoint as an endpoint parameter, a= nd only using client_secret as the authentication method (which at the time= was in-line with your earlier proposal). I understand that in many assertions, the client identifier is established = internally, but this approach will completely prevent using the assertion c= lient authentication method with other flows that involve getting a code. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Monday, July 26, 2010 1:22 PM To: oauth@ietf.org Subject: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions The following is proposed language for inclusion in the spec as section 2.2= . I would like to thank Brian Campbell, Brain Eaton, Chuck Mortimore, Dirk = Balfanz, Eric Sachs, Justin Smith and Marius Scurtescu for taking the time = to review and improve this proposal. Please note that the named folks contr= ibuted the good ideas and I just focused on introducing anything that is br= oken. So what does the group think? +1? -1? Thanks, Yaron 2.2 Assertion Client Credentials While Client Passwords provide a simple mechanism for authenticating client= s they require that a secret, the password, be sent over the network. Even = when the network connection is encrypted sending secrets over a network con= nection is considered a potentially serious security threat. In scenarios w= here security is at a premium, it is preferred to use mechanisms such as Ha= sh-based Message Authentication Codes (HMACs) or digital signatures that do= not require sending secrets across the wire. The most common way to use HM= ACs or digital signatures is in assertions. Therefore this section defines = how to authenticate a client using an assertion instead of a password. The following parameters are used when a client authenticates itself using = an assertion: client_assertion_type REQUIRED. The format of the assertion as defined by the aut= horization server. The value MUST be an absolute URI. client_assertion REQUIRED. The client assertion. For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=3Dauthorization_code& client_assertion=3DPHNhbWxwOl...[omitted for brevity]...ZT4= %3D& client_assertion_type=3Durn%3Aoasis%3Anames%sAtc%3ASAML%3A2= .0%3Aassertion& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb In the previous example the client is submitting an authorization code to a= token endpoint using a SAML assertion to authenticate itself. The client_id and client_secret parameters MUST NOT be used with the client= _assertion and client_assertion_type parameters. Requests for end user authorization as defined in section 3 are required to= contain a client_id parameter. If the response to the authorization reques= t is a code then that code is submitted to a token endpoint to obtain an ac= cess token. For this flow to work with assertions there must exist some mec= hanism to map the value in the client_id parameter of the authorization req= uest to the assertion that is subsequently submitted with the code to get a= n access token. How this works with any particular assertion type is out of= scope for this document. However, any document that defines how to use an = assertion of a particular type with OAuth 2.0 MUST define how to map the va= lue from the client_id parameter in the authorization request to a value or= values in the assertion subsequently submitted with the code to obtain an = access token. Token endpoints MUST reject assertions that do not contain HMAC/signed valu= es that identify that the assertion is specifically intended to be consumed= by the receiving endpoint. This requirement is typically met by some value= in the assertion such as audience or recipient which contains the token en= dpoint's URI or other agreed upon identifier. Token endpoints MUST reject assertions that do not contain HMAC/signed valu= es that identify the entity that generated the assertion. This requirement = is typically met by some value in the assertion such as issuer which contai= ns a URI or other agreed upon identifier that identifies the entity that ge= nerated the assertion. Token endpoints MUST reject assertions that do not contain HMAC/signed valu= es that identify when the assertion is to expire as an absolute time. This = requirement is typically met by some value in the assertion such as expirat= ion that contains a UTC date/time value or equivalent time stamp identifyin= g when the assertion will expire. Token endpoints MUST reject assertions wh= ose expiration time is beyond a certain limit in the future. The definition= of that limit MUST be based on the security requirements of the resource b= eing protected. The limits to choose for any particular type of resource/da= ta are application specific and depend upon a combination of what technolog= ies are being used, what key policies are being followed, what laws may app= ly, etc. and therefore are out of scope for this document. --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EF900AEP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

By not incorporating the client_id parameter, you are prevent= ing this client authentication mode from being used with the end-user autho= rization endpoint. In -09 I tried to separate the client_id from the client= _secret, basically moving the client_id to the token endpoint as an endpoin= t parameter, and only using client_secret as the authentication method (whi= ch at the time was in-line with your earlier proposal).

 

I understand that = in many assertions, the client identifier is established internally, but th= is approach will completely prevent using the assertion client authenticati= on method with other flows that involve getting a code.

 

EHL

 =

From: oauth-bounces@ietf= .org [mailto:oauth-bounces@ietf.org] On Behalf Of Yaron Goland
Sent: Monday, July 26, 2010 1:22 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Proposed language for section 2.2 on Client Assert= ions

 

The following is proposed language for inclusion = in the spec as section 2.2. I would like to thank Brian Campbell, Brain Eat= on, Chuck Mortimore, Dirk Balfanz, Eric Sachs, Justin Smith and Marius Scur= tescu for taking the time to review and improve this proposal. Please note = that the named folks contributed the good ideas and I just focused on intro= ducing anything that is broken.

&nb= sp;

So what does the group think? +1? -1?

 

&= nbsp;           &nbs= p;   Thanks,

   = ;            &n= bsp;            = ;    Yaron

 

2.2 Assertion Cli= ent Credentials

 

While Client Passwords provide a simple mechanism for au= thenticating clients they require that a secret, the password, be sent over= the network. Even when the network connection is encrypted sending secrets= over a network connection is considered a potentially serious security thr= eat. In scenarios where security is at a premium, it is preferred to use me= chanisms such as Hash-based Message Authentication Codes (HMACs) or digital= signatures that do not require sending secrets across the wire. The most c= ommon way to use HMACs or digital signatures is in assertions. Therefore th= is section defines how to authenticate a client using an assertion instead = of a password.

 

The following parameters are used when a client authenticat= es itself using an assertion:

 

client_assertion_type

<= p class=3DMsoNormal>    &= nbsp;           REQUIRED.= The format of the assertion as defined by the authorization server.  = The value MUST be an absolute URI.

client_assertion

     = ;           REQUIRED. The= client assertion.

For example (line breaks are for display purposes only):

=  

&= nbsp;           &nbs= p;   POST /token HTTP/1.1

       =          Host: server.example.com

&nbs= p;            &= nbsp;  Content-Type: application/x-www-form-urlencoded

 <= /span>

  &n= bsp;            = ; grant_type=3Dauthorization_code&

      &nb= sp;         client_assertion=3DPHNh= bWxwOl...[omitted for brevity]...ZT4%3D&

     &n= bsp;          client_assertion= _type=3Durn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&

  &nb= sp;             = ;redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb=

 

In the previous = example the client is submitting an authorization code to a token endpoint = using a SAML assertion to authenticate itself.

 

The client_id and client_s= ecret parameters MUST NOT be used with the client_assertion and client_asse= rtion_type parameters.

 

Requests for end user authorization as defined in s= ection 3 are required to contain a client_id parameter. If the response to = the authorization request is a code then that code is submitted to a token = endpoint to obtain an access token. For this flow to work with assertions t= here must exist some mechanism to map the value in the client_id parameter = of the authorization request to the assertion that is subsequently submitte= d with the code to get an access token. How this works with any particular = assertion type is out of scope for this document. However, any document tha= t defines how to use an assertion of a particular type with OAuth 2.0 MUST = define how to map the value from the client_id parameter in the authorizati= on request to a value or values in the assertion subsequently submitted wit= h the code to obtain an access token.

 

Token endpoints MUST reject assertio= ns that do not contain HMAC/signed values that identify that the assertion = is specifically intended to be consumed by the receiving endpoint. This req= uirement is typically met by some value in the assertion such as audience o= r recipient which contains the token endpoint’s URI or other agreed u= pon identifier.

 

Token endpoints MUST reject assertions that do not conta= in HMAC/signed values that identify the entity that generated the assertion= . This requirement is typically met by some value in the assertion such as = issuer which contains a URI or other agreed upon identifier that identifies= the entity that generated the assertion.

 

Token endpoints MUST reject asse= rtions that do not contain HMAC/signed values that identify when the assert= ion is to expire as an absolute time. This requirement is typically met by = some value in the assertion such as expiration that contains a UTC date/tim= e value or equivalent time stamp identifying when the assertion will expire= . Token endpoints MUST reject assertions whose expiration time is beyond a = certain limit in the future. The definition of that limit MUST be based on = the security requirements of the resource being protected. The limits to ch= oose for any particular type of resource/data are application specific and = depend upon a combination of what technologies are being used, what key pol= icies are being followed, what laws may apply, etc. and therefore are out o= f scope for this document.

&= nbsp;

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EF900AEP3PW5EX1MB01E_-- From paul.tarjan@facebook.com Mon Jul 26 15:28:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1B93A6872 for ; Mon, 26 Jul 2010 15:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.542 X-Spam-Level: X-Spam-Status: No, score=-0.542 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aly0cuXrDXZr for ; Mon, 26 Jul 2010 15:28:53 -0700 (PDT) Received: from mx-out.facebook.com (outmail006.ash1.tfbnw.net [69.63.184.106]) by core3.amsl.com (Postfix) with ESMTP id C8CDB3A6843 for ; Mon, 26 Jul 2010 15:28:52 -0700 (PDT) Received: from [10.18.255.131] ([10.18.255.131:58146] helo=mail.thefacebook.com) by mta010.ash1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id EC/E5-14944-6D90E4C4; Mon, 26 Jul 2010 15:19:03 -0700 Received: from SC-MBX04.TheFacebook.com ([169.254.3.239]) by sc-hub03.TheFacebook.com ([fe80::1cfe:1f6b:8b35:cf7f%11]) with mapi; Mon, 26 Jul 2010 15:19:01 -0700 From: Paul Tarjan To: OAuth WG Thread-Topic: Facebook's experience with OAuth2.0 signatures Thread-Index: AQHLLRCMnrgzlsPYgkSoyahPAUH7pA== Date: Mon, 26 Jul 2010 22:18:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <424c68d1-f4d6-4583-a080-2cf0467e11a2> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Facebook's experience with OAuth2.0 signatures X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Jul 2010 22:28:54 -0000 Facebook released an early version of the proposed signature method, with t= he aim of getting real-life implementation experience. We are not currently= using this for protected resource requests, but rather more like if the au= thorization server returned signed data as part of the access token respons= e.=20 It was generally a success with many people really liking the scheme.=20 Our main takeaway is that MANY developers used normal base64 instead of bas= e64url encoding either because they didn't read the spec thoroughly or just= recognized the scheme and started decoding it. This caused weird errors wh= ich they weren't ready for (sometimes working when - and _ weren't present,= sometimes cutting off some json characters when their language needed padd= ing =3D, etc).=20 We created an open source set of examples that developers have found helpfu= l, and which could be incorporated into the OAuth example set: http://githu= b.com/ptarjan/base64url So, I suggest to keep the signature scheme, but message the fact that it is= n't normal base64 VERY loudly and clearly in the spec, and to use examples = that will fail hard with normal base64. Our implementation followed the OAuth2.0 signature scheme except for 4 chan= ges: * signature came before payload * not_after was renamed expires * not all required parameters were present given the difference in use case * the parameter was called signed_request instead of signed_token You can read our docs here: http://developers.facebook.com/docs/authenticat= ion/canvas Here is a few snippets of developer feedback that we had about them not und= erstanding to use base64url instead of base64 encoding: --- We're seeing bogus JSON in the new parameter. It looks like a few characte= rs are being left off the end. --- Imcompatible Base64 Encoding between PHP and Java (sun.misc.Base64Encoder) The problem was, I get an extra byte at the end of the Base64 Decoded Sig, comparing to the result I got from Hashing the Payload with my app secret. My guess is that PHP is not encoding base64 strictly following the Base64 convention, or, Facebook has removed the tailing "=3D" from Sig which is r= equired in most Java Base64 implementations. The sun.misc.Base64Decoder decoded the sig with a tailing ">", while anoth= er example I found from Internet tail with "0x00". =09 --- Isn't this just turning into a total mess - telling people that they need = to refer to Wiki articles to use specific Base64 encode and decode functions = and having to post chunks of code in order to try to get it working. =09 --- The problem is actually that there library is buggy and others actually fo= llow the spec. Base64 is well defined. URLencoding is well defined. Unpadded ba= se64 with several character substitutions is now well defined :) =09 =09 Then people started posting code to each other, some got it wrong: > # Ruby >=20 > def base64_url_decode(str)=20 > return Base64.decode64(str.tr('-_', '+/')) > end >=20 that does not account for missing padding. =20 =09 Then someone actually read the spec: Facebook is following RFC. http://www.faqs.org/rfcs/rfc3548.html - Section 4.=20 =09 That said, I don't really agree with the use of the "filename safe" style.= I'd implement base64 with the protocol and/or filesystem specific encoding separated, because I don't think the spec should be concerned with that. A= lso, not many people use this style, so most libraries don't have support for i= t. But hey, I'm just one of those well-read ruby hipsters, what do I know? We got lots of positive feedback about it: --- I'm a fan *cough* of the new auth mechanism; =09 --- I agree that this is much cleaner. I like allowing the original request me= thod to be used. I just wish things followed the actual specification or had th= eir differences documented. As a library maintainer, I would also like to know before things like this are released. --- I'm also perfectly happy with the direction FB is going here. =09 --- I have to say too, I'm also a big fan of the new authentication system, th= ank you. It has cut out a lot of code for us, and it's a lot easier to debug. = This is a good verification system too.= From beaton@google.com Mon Jul 26 15:51: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 2720D3A6897 for ; Mon, 26 Jul 2010 15:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.958 X-Spam-Level: X-Spam-Status: No, score=-101.958 tagged_above=-999 required=5 tests=[AWL=0.020, 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 fmkFEcfL9eHu for ; Mon, 26 Jul 2010 15:51:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1C7AC3A6847 for ; Mon, 26 Jul 2010 15:51:02 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o6QMpMeX006192 for ; Mon, 26 Jul 2010 15:51:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280184683; bh=BgOkivxpHbZ33McvjgzDIGp+45k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=UHVG/NgISsMtdxSIXY2/+wQIzOYsi24xm6xHcvs0RJudyldjEkCQxNoJagpdpeoEK fUFREnoYYTaXfjYTGKXVQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=eqWj5W1cgxhFbAdQfn3HR2nB06L0BG0zpV5/6XUOiU7d9tdQqdS9+/wqbO8juvIlf AOYavTcsjJ9Z+Hm1i6vNQ== Received: from pxi7 (pxi7.prod.google.com [10.243.27.7]) by kpbe19.cbf.corp.google.com with ESMTP id o6QMpLuJ017329 for ; Mon, 26 Jul 2010 15:51:21 -0700 Received: by pxi7 with SMTP id 7so314238pxi.14 for ; Mon, 26 Jul 2010 15:51:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.233.1 with SMTP id f1mr1793081wfh.175.1280184681189; Mon, 26 Jul 2010 15:51:21 -0700 (PDT) Received: by 10.143.132.1 with HTTP; Mon, 26 Jul 2010 15:51:21 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EF900AE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C6294F782@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EF900AE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 26 Jul 2010 15:51:21 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Jul 2010 22:51:04 -0000 On Mon, Jul 26, 2010 at 2:08 PM, Eran Hammer-Lahav wrote: > I understand that in many assertions, the client identifier is established > internally, but this approach will completely prevent using the assertion > client authentication method with other flows that involve getting a code. I'm pretty sure that's exactly the opposite of what Yaron was trying to achieve. client_id will continue to be passed on the authorization URL. No client_id will be passed on the token endpoint, because it's either insecure, or not necessary. The assertion has to contain the client identifier. From eran@hueniverse.com Mon Jul 26 16:10: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 AE2C33A6A0D for ; Mon, 26 Jul 2010 16:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEfPXjGvwGY7 for ; Mon, 26 Jul 2010 16:10:50 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E52993A67D3 for ; Mon, 26 Jul 2010 16:10:49 -0700 (PDT) Received: (qmail 15905 invoked from network); 26 Jul 2010 23:11:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jul 2010 23:11:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 26 Jul 2010 16:11:09 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Mon, 26 Jul 2010 16:11:14 -0700 Thread-Topic: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions Thread-Index: AcstFRRt0fDcL5mWRk2dB5Xa4EyPrAAArBxg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EF90102@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C6294F782@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EF900AE@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] Proposed language for section 2.2 on Client Assertions X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Jul 2010 23:10:51 -0000 How do you link the client_id using in the authorization endpoint with the = client assertion using in the token endpoint? EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Monday, July 26, 2010 3:51 PM > To: Eran Hammer-Lahav > Cc: Yaron Goland; oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client > Assertions >=20 > On Mon, Jul 26, 2010 at 2:08 PM, Eran Hammer-Lahav > wrote: > > I understand that in many assertions, the client identifier is > > established internally, but this approach will completely prevent > > using the assertion client authentication method with other flows that > involve getting a code. >=20 > I'm pretty sure that's exactly the opposite of what Yaron was trying to > achieve. >=20 > client_id will continue to be passed on the authorization URL. >=20 > No client_id will be passed on the token endpoint, because it's either > insecure, or not necessary. The assertion has to contain the client iden= tifier. From beaton@google.com Mon Jul 26 16:18:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E36F3A6890 for ; Mon, 26 Jul 2010 16:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.834 X-Spam-Level: X-Spam-Status: No, score=-105.834 tagged_above=-999 required=5 tests=[AWL=0.143, 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 lUloDOsH7SBt for ; Mon, 26 Jul 2010 16:18:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 28D653A67D3 for ; Mon, 26 Jul 2010 16:18:25 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o6QNIk3f012190 for ; Mon, 26 Jul 2010 16:18:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280186326; bh=l7zxdI4vHqSZfcSUIKBj5+gO/A4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=gt9QysUwZ1EikusP+77hO0EaVTPaihzQCCxCGLxCLDNgw1vkoWVF2E9dnH5KKjWT7 qomCwmaJzhNlZyJ8PjPWg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=v8Pwmoa4L5AmJ2kyFiRZNq39WRNjpeOWsfY11ZS6hf4hRqlhmoF/CuG9VnC+h8vtE Rn5cyJDH7LoDSnLlhdOQQ== Received: from pvc7 (pvc7.prod.google.com [10.241.209.135]) by kpbe18.cbf.corp.google.com with ESMTP id o6QNIfQv023443 for ; Mon, 26 Jul 2010 16:18:45 -0700 Received: by pvc7 with SMTP id 7so261564pvc.19 for ; Mon, 26 Jul 2010 16:18:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.127.9 with SMTP id z9mr9575075wfc.302.1280186325071; Mon, 26 Jul 2010 16:18:45 -0700 (PDT) Received: by 10.143.132.1 with HTTP; Mon, 26 Jul 2010 16:18:45 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EF90102@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C6294F782@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EF900AE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EF90102@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 26 Jul 2010 16:18:45 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Jul 2010 23:18:27 -0000 On Mon, Jul 26, 2010 at 4:11 PM, Eran Hammer-Lahav wrote: > How do you link the client_id using in the authorization endpoint with the client assertion using in the token endpoint? In theory: "any document that defines how to use an assertion of a particular type with OAuth 2.0 MUST define how to map the value from the client_id parameter in the authorization request to a value or values in the assertion subsequently submitted with the code to obtain an access token." In practice: you do it the same way you handle any kind of identity assertion. There is some combination of issuer and subject and signature that ends up producing an identity that you trust. From dick.hardt@gmail.com Mon Jul 26 16:56: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 B4F303A6877 for ; Mon, 26 Jul 2010 16:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf4yK5ikYpm7 for ; Mon, 26 Jul 2010 16:56:21 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3EABB3A6872 for ; Mon, 26 Jul 2010 16:56:21 -0700 (PDT) Received: by iwn38 with SMTP id 38so3363083iwn.31 for ; Mon, 26 Jul 2010 16:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=hA02DOF2gvi+2Brnn+KGTwi1EGLulBusDH/+E4C/Egk=; b=vxlbBvYBzSWZKoMf5mVjDvuxKb/7lmMwX10n4JXg5p46WVkLDo+RwzUOoU0RuP0Tv7 GL8ZtKDSjUjH/LvB9f3/4K6hqwBednj+NdeDC9Gny2IB9aBAd/wwOk1OQ9WDa9DYmylR V7hgRfWAqQhnRECW0LLut10tlDq7Bg02cGRRk= 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=OECfTRc0J7xbYmvhzbtUh2S0kbZ8wL3hRgYdIL9ymtBzl2t/ITg4DGgn5fzMr6NX2o lQVoQ+P1f+gcMIMkcQB2S28/uMLED5fbWZ2uDVRu/NNDbvHxc2PSanwJkis2TUn/1QkH 01YWjQth2jYr62NbVMjq0bMMxbEjhmIoIDXUE= Received: by 10.231.149.207 with SMTP id u15mr9569402ibv.13.1280188601641; Mon, 26 Jul 2010 16:56:41 -0700 (PDT) Received: from [192.168.1.5] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id h8sm4102875ibk.15.2010.07.26.16.56.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Jul 2010 16:56:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Mon, 26 Jul 2010 16:56:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Tarjan X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] Facebook's experience with OAuth2.0 signatures X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Jul 2010 23:56:22 -0000 Thanks for sharing Paul! On 2010-07-26, at 3:18 PM, Paul Tarjan wrote: > Facebook released an early version of the proposed signature method, = with the aim of getting real-life implementation experience. We are not = currently using this for protected resource requests, but rather more = like if the authorization server returned signed data as part of the = access token response.=20 >=20 > It was generally a success with many people really liking the scheme.=20= >=20 > Our main takeaway is that MANY developers used normal base64 instead = of base64url encoding either because they didn't read the spec = thoroughly or just recognized the scheme and started decoding it. This = caused weird errors which they weren't ready for (sometimes working when = - and _ weren't present, sometimes cutting off some json characters when = their language needed padding =3D, etc).=20 >=20 > We created an open source set of examples that developers have found = helpful, and which could be incorporated into the OAuth example set: = http://github.com/ptarjan/base64url >=20 > So, I suggest to keep the signature scheme, but message the fact that = it isn't normal base64 VERY loudly and clearly in the spec, and to use = examples that will fail hard with normal base64. >=20 >=20 > Our implementation followed the OAuth2.0 signature scheme except for 4 = changes: > * signature came before payload > * not_after was renamed expires > * not all required parameters were present given the difference in use = case > * the parameter was called signed_request instead of signed_token >=20 > You can read our docs here: = http://developers.facebook.com/docs/authentication/canvas >=20 >=20 > Here is a few snippets of developer feedback that we had about them = not understanding to use base64url instead of base64 encoding: >=20 > --- > We're seeing bogus JSON in the new parameter. It looks like a = few characters > are being left off the end. >=20 > --- > Imcompatible Base64 Encoding between PHP and Java = (sun.misc.Base64Encoder) >=20 > The problem was, I get an extra byte at the end of the Base64 = Decoded Sig, > comparing to the result I got from Hashing the Payload with my = app secret. >=20 > My guess is that PHP is not encoding base64 strictly following = the Base64 > convention, or, Facebook has removed the tailing "=3D" from Sig = which is required > in most Java Base64 implementations. >=20 > The sun.misc.Base64Decoder decoded the sig with a tailing ">", = while another > example I found from Internet tail with "0x00". > =09 > --- > Isn't this just turning into a total mess - telling people that = they need to > refer to Wiki articles to use specific Base64 encode and decode = functions and > having to post chunks of code in order to try to get it working. > =09 > --- > The problem is actually that there library is buggy and others = actually follow > the spec. Base64 is well defined. URLencoding is well defined. = Unpadded base64 > with several character substitutions is now well defined :) > =09 > =09 > Then people started posting code to each other, some got it wrong: >=20 > > # Ruby > >=20 > > def base64_url_decode(str)=20 > > return Base64.decode64(str.tr('-_', '+/')) > > end > >=20 >=20 > that does not account for missing padding. =20 > =09 >=20 > Then someone actually read the spec: >=20 > Facebook is following RFC. http://www.faqs.org/rfcs/rfc3548.html = - > Section 4.=20 > =09 > That said, I don't really agree with the use of the "filename = safe" style. I'd > implement base64 with the protocol and/or filesystem specific = encoding > separated, because I don't think the spec should be concerned = with that. Also, > not many people use this style, so most libraries don't have = support for it. > But hey, I'm just one of those well-read ruby hipsters, what do = I know? >=20 >=20 > We got lots of positive feedback about it: >=20 > --- > I'm a fan *cough* of the new auth mechanism; > =09 > --- > I agree that this is much cleaner. I like allowing the original = request method > to be used. I just wish things followed the actual specification = or had their > differences documented. As a library maintainer, I would also = like to know > before things like this are released. >=20 > --- > I'm also perfectly happy with the direction FB is going here. > =09 > --- > I have to say too, I'm also a big fan of the new authentication = system, thank > you. It has cut out a lot of code for us, and it's a lot easier = to debug. This > is a good verification system too. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sakimura@gmail.com Mon Jul 26 22:34:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49123A6841 for ; Mon, 26 Jul 2010 22:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw8uLDxH-wTC for ; Mon, 26 Jul 2010 22:34:36 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4ED553A685F for ; Mon, 26 Jul 2010 22:34:33 -0700 (PDT) Received: by iwn38 with SMTP id 38so3684869iwn.31 for ; Mon, 26 Jul 2010 22:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=fS6AoCMulpwf54RWnX62Ppa9plxYxuARHrhKoHeHSuU=; b=tQBz2GE1aotPwze6QOWlIfktq9OrlnypLx6Z1kjamL5dbMTihRYI3cUUueC3uOvE7p QzZ1MjBS4fgjKIIJep7DcDaT2PHN1yxFgTxjTcGN6gzTtZP2HhRkpVDFJjAK/0CJrTvc wzaD83835Bv2/x+tjRj+9/5L2p1ZMCkoNbxnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=aaSPieisSu7ZiN/92N/KQZKYkpgwOCOd+HWHLPTarPHRwMP5zQo+ciP4bEK/b5s1qa XlhlD3O+Qu44ImbsIN4GITLlRwYSmBXTmuGHxLV0wZU5QSBkaSJ00MsYRknpzp2aq78P 8lBykQDmQ1WgqOq0vhIF3wWJ4JqQR/7fk5R+8= MIME-Version: 1.0 Received: by 10.231.170.21 with SMTP id b21mr3771931ibz.122.1280208890018; Mon, 26 Jul 2010 22:34:50 -0700 (PDT) Received: by 10.231.158.67 with HTTP; Mon, 26 Jul 2010 22:34:49 -0700 (PDT) Date: Tue, 27 Jul 2010 14:34:49 +0900 Message-ID: From: Nat Sakimura To: David Recordon , oauth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] Separation of parameters and bindings (was: Alternative ways to pass Authorization Request 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: Tue, 27 Jul 2010 05:34:41 -0000 Hi David, Good to see you on Saturday. This is what I was referring to over the lunch. Separate endpoint still does not seem to meet the current section 3. =3Dnat ---------- Forwarded message ---------- From: Nat Sakimura Date: Tue, Jul 13, 2010 at 11:51 AM Subject: Alternative ways to pass Authorization Request Parameters To: oauth As of -10, the Authorization Request Parameters are required to be passed as part of the Authorization Request URI query component. I would like to see it relaxed a bit so that they do not have to be a part of the URL but can be passed by reference. In the proposal that I have submit a while ago, I proposed to have 1) The parameters to be captured in JSON that can be obtained through a URL 2) Pass this URL to the end-user authorization endpoint through a parameter 'request_url' I have enumerated numerous merit of this approach and I believe we had an agreement that this would be useful from both security and usability perspective. However, as the current text is written, the parameters have to be sent as URI query component. In -10, it is written as: =A0 In order to direct the end-user's user-agent to the authorization =A0 server, the client constructs the request URI by adding the following =A0 parameters to the end-user authorization endpoint URI query component =A0 using the "application/x-www-form-urlencoded" format as defined by =A0 [W3C.REC-html401-19991224]: =A0 =A0 (parm defs) =A0 The client directs the end-user to the constructed URI using an HTTP =A0 redirection response, or by other means available to it via the end- =A0 user's user-agent. =A0The authorization server MUST support the use of =A0 the HTTP "GET" method for the end-user authorization endpoint, and =A0 MAY support the use of the "POST" method as well. Instead I would propose something like: =A0 In order to obtain the end-user's authorization, the client sends the =A0 following parameters to the end-user authorization endpoint. =A0 =A0(param defs) =A0 The client directs the end-user to the end-user authorization endpoint =A0 URI using an HTTP redirection response, or by other means available to =A0 it via the end-user's user-agent. The authorization server MUST support the use of =A0 the HTTP "GET" method for the end-user authorization endpoint, and =A0 MAY support the use of the "POST" method as well. The authorization =A0 server MUST support the parameters being passed as the query component =A0 using the "application/x-www-form-urlencoded" format as defined by =A0 [W3C.REC-html401-19991224]. I also have a comment on the structure of the section 3. I should have noticed this much earlier but currently the section 3 is structured as: 3. =A0Obtaining End-User Authorization =A0 =A0 3.1. =A0Authorization Response =A0 =A0 3.2. =A0Error Response Would it not be better to be something like below? 3. =A0Obtaining End-User Authorization =A0 =A0 3.1. Authorization Request =A0 =A0 3.2. Authorization Response =A0 =A0 3.3. =A0Error Response -- Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From sakimura@gmail.com Mon Jul 26 23:58: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 44C023A6907 for ; Mon, 26 Jul 2010 23:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=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 bgRkurTdEg9y for ; Mon, 26 Jul 2010 23:58:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1F45E3A68D7 for ; Mon, 26 Jul 2010 23:58:23 -0700 (PDT) Received: by iwn38 with SMTP id 38so3745393iwn.31 for ; Mon, 26 Jul 2010 23:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=sIGOOiRXDtnaN6tWKwCKzBdsIG7kmXmkj49Uk5ZLLek=; b=DwU8zd3fx2b++eBGaTYshkVcXVxLJL2WhiYgIAvVYOcDEPx7FV6/4Gmxui3xoTvWXb RDn9k7U3+smpKt9SvjEkbX35H/64j5UluOkzW2xh5hMGkeFU7nIoeUlfsttWiwTZ4Oxi W4Cy6ag4w4X/Pb9j2sKSCV3j3j35OBAoJ8U3A= 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=fHdQIXt4Nl0XBMHUe7zh+XZ8XIFraiA72PejwrP5ZnkrIxInv+vxYTBSTW9oBKPlOc fpB+40gD2YVU3t6++pz2VIwYfWaHJzUWzsy+ZoVmTuSwXwVG/MfIqb7gbilg5K5ced/G cVkLGxNz2AO3Otib2i5hOOUgNviqzGzzGq1no= MIME-Version: 1.0 Received: by 10.231.203.15 with SMTP id fg15mr9259858ibb.187.1280213924762; Mon, 26 Jul 2010 23:58:44 -0700 (PDT) Received: by 10.231.158.67 with HTTP; Mon, 26 Jul 2010 23:58:44 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11264272EBE@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 27 Jul 2010 15:58:44 +0900 Message-ID: From: Nat Sakimura To: Ben Laurie , Dirk Balfanz Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 06:58:24 -0000 If we were using PKCS#7 for certs, then why not PKCS#7 the payload as well? (No - I am not proposing to do it. Doing so with AES-128,192,256 is prohibitive in some language such as PHP, but just as a point of discussion to close this.) On Tue, Jun 22, 2010 at 6:33 PM, Ben Laurie wrote: > On 22 June 2010 02:40, Manger, James H wrote: >> Nat and Ben, >> >> >> >>>>> In addition to Ben's questions, I have another. For X.509, you seem to >> >>>>> be using DER. How do you express the entire certificate chain using >> >>>>> DER? >> >>>>> (With PEM, you can just concatenate ... ) >> >>>> >> >>>> With DER you can concatenate, too, of course. There's also PKCS#n (for >> >>>> some value of n which I forget ... 12?) which allows bundling of cert >> >>>> chains. >> >>> >> >>> That's PKCS#12, I suppose. I had under an impression that PKCS#12 includes >>> the >> >>> private key, though. >> >> >> >> >> >> A *.p7c file can be used to hold any number of certificates. It is a >> BER-encoded PKCS#7 value, now known as Cryptographic Message Syntax (CMS) >> standard [RFC 5652]. It is the ASN.1 syntax used for S/MIME signed email. If >> you only want to send certificates, just leaving out the >> content-to-be-signed, and the signatures. > > Ah, thanks, I thought there was something less kludgey than PKCS#12. > >> >> >> >> Such a file can hold any number of certificates, including public-key >> certificates, attribute certificates, or other certificate formats. >> >> It can also hold CRLs and other revocation information (including OCSP >> responses as per draft-turner-additional-cms-ri-choices). >> >> >> >> CMS/PKCS#7 is better for this purpose than PKCS#12. >> >> >> >> -- >> >> 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 > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From sakimura@gmail.com Tue Jul 27 00:34: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 DD5543A69E2 for ; Tue, 27 Jul 2010 00:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 tUID7-L4MZ5q for ; Tue, 27 Jul 2010 00:34:03 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 33A143A69F9 for ; Tue, 27 Jul 2010 00:34:03 -0700 (PDT) Received: by iwn38 with SMTP id 38so3772617iwn.31 for ; Tue, 27 Jul 2010 00:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=3eNaTjxiqt4zpfwBsMNUxme31mckzzB/i3dR36ehuAs=; b=jc1VBS9iFQppVsGk8uqLq2W4Xcdc+04nVHvVDSgsAv43+O9LUC84CXbUm2V/sWAt4i hCyEkmPRsUTOrOzHLLk/+Ki/1xlmz4J8L/SbPgDjz4mUIRZRLYHEHFE8IIgXc6Mnt0CA JL29arUiqbBLGvCeOT4swr27KQg0n8BVE29Ks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=WyLKefPAhm3SZp7Ow1xp+YA5I4uw+Ft8Ls3htdD1YzpYrv6As5s/SOG5F44WUMiqf7 LclP9UZlypxQXTRSi6MQMpoiQ8rdbeIY80BedYnBDk5vV4h/bAL9AEZReFA9oFF2/HOC XTbkL1mx/brreuuJ9/C0IzpWoppE7ft+dEKMc= MIME-Version: 1.0 Received: by 10.231.155.206 with SMTP id t14mr9869222ibw.34.1280216064815; Tue, 27 Jul 2010 00:34:24 -0700 (PDT) Received: by 10.231.158.67 with HTTP; Tue, 27 Jul 2010 00:34:24 -0700 (PDT) Date: Tue, 27 Jul 2010 16:34:24 +0900 Message-ID: From: Nat Sakimura To: Dirk Balfanz , oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] OAuth Signature X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 07:34:05 -0000 I have a fundamental question. While separating signature and payload by a dot "." seems ok, I still have not the answer for the question "why not make everything into JSON and base64url it?". i.e., Right now, you are proposing: base64url_encode(JSON(payload,envelope)).base64url_encode(signature) Why not base64url_encode(JSON(payload,envelope,signature) It probably is less hassle in terms of coding. (It is true that some parameters gets base64url encoded twice but BTW, some of the envelope parameters such as alg needs to be signed as well to thwart the algorithm replacing attack. -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From torsten@lodderstedt.net Tue Jul 27 03:48: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 080623A6AD2 for ; Tue, 27 Jul 2010 03:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 e97XpMu4YgWe for ; Tue, 27 Jul 2010 03:48:13 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by core3.amsl.com (Postfix) with ESMTP id ACA733A6BB1 for ; Tue, 27 Jul 2010 03:48:12 -0700 (PDT) Received: from dhcp-87ec.meeting.ietf.org ([130.129.135.236] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Odhi4-00070q-Sm; Tue, 27 Jul 2010 12:48:32 +0200 Message-ID: <4C4EB974.7050102@lodderstedt.net> Date: Tue, 27 Jul 2010 12:48:20 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Marius Scurtescu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 10:48:14 -0000 I think the proposed parameters are useful for registered clients, too. For installed applications, there is always the chance a user authorizes the same application (==binary==client_id?) several times, every time on a different device. It would be helpful to differentiate those copies. regards, Torsten. Am 17.07.2010 00:23, schrieb Marius Scurtescu: > I agree that these parameters are useful, but not sure if they belong > in the User Experience extension. > > I think we should create a separate extension for unregistered clients: > - how to signal that this client is unregistered, maybe use a special > value like "anonymous" as the client id > - what client name/description should be used, as you suggest here > > Instead of instance_name and instance_description maybe we can call > these client_name and client_description? > > Marius > > > > On Tue, Jul 13, 2010 at 5:28 AM, Richer, Justin P. wrote: > >> I'd like to propose the addition of two more optional parameters to this extension: >> >> instance_name >> Short, human-readable name that the server SHOULD display to >> the end-user along with the client name. This name is designed >> to reflect a per-instance identifier for cases where a single user >> may authorize multiple copies of a single identified client. The >> server MAY [SHOULD?] store this information along with its >> associated access grant to allow the end-user to differentiate >> between instances of the application in the future (for example, >> to revoke access tokens). >> >> instance_description >> A longer, human-readable description that the server MAY display to >> the end-user along with the client name. This description is designed >> as the name above to reflect a per-instance identifier for cases where >> a single user may authorize multiple copies of a single identified client. The >> server MAY [SHOULD?] store this information along with its >> associated access grant to allow the end-user to differentiate >> between instances of the application in the future (for example, >> to revoke access tokens). If a client presents the instance_description, >> it MUST also present an instance_name. >> >> This can be thought of as the new way of Google's xoauth_display_name parameter. We have a direct use case for this, and it seems like it would fit in the UX more than its own extension. >> >> There was also talk of sending a client-information URL to get more stuff about the client and instances of it, but that seems a better fit for the impending discovery spec, to me, as it seems to address full client information and not per-instance information that this is talking about. >> >> -- Justin >> ________________________________________ >> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of David Recordon [recordond@gmail.com] >> Sent: Monday, July 12, 2010 3:51 PM >> To: OAuth WG >> Subject: [OAUTH-WG] Moving the User Experience Extension draft forward >> >> I wrote this draft last month based on discussions on the mailing list, the OpenID user experience extension (which Facebook, Google, and Yahoo! have deployed), and some OAuth 2.0 implementation experience from Facebook. It defines language and display preferences which the client can include in requests to the end-user authorization endpoint. >> >> A previous draft included an immediate mode parameter but further discussion has shown that it should be removed until identity information is also addressed. Identity is outside the scope of this particular extension. >> >> I'd like this draft to become a working group document and have done my best to make it represent the group's consensus. Unfortunately the internet draft submission process is closed for a few weeks until after the meeting. :-\ >> >> Thanks, >> --David >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Tue Jul 27 03:51: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 A04743A6B9D for ; Tue, 27 Jul 2010 03:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crUqIrPmNJ9F for ; Tue, 27 Jul 2010 03:51:33 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by core3.amsl.com (Postfix) with ESMTP id 6C2653A6AEB for ; Tue, 27 Jul 2010 03:51:33 -0700 (PDT) Received: from dhcp-87ec.meeting.ietf.org ([130.129.135.236] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OdhlJ-00021Y-Vp; Tue, 27 Jul 2010 12:51:54 +0200 Message-ID: <4C4EBA47.6000700@lodderstedt.net> Date: Tue, 27 Jul 2010 12:51:51 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: David Recordon References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050709020607050808010100" X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 10:51:34 -0000 This is a multi-part message in MIME format. --------------050709020607050808010100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit If I understand your proposal correctly, you assume the clients knows better than the authz server how to fit the client presentation capabilities the best. Wouldn't it be neccessary to also tell the authz server the screen orientation and available size? regards, Torsten. Am 12.07.2010 21:51, schrieb David Recordon: > I wrote this draft last month based on discussions on the mailing > list, the OpenID user experience extension (which Facebook, Google, > and Yahoo! have deployed), and some OAuth 2.0 implementation > experience from Facebook. It defines language and display preferences > which the client can include in requests to the end-user authorization > endpoint. > > A previous draft included an immediate mode parameter but further > discussion has shown that it should be removed until identity > information is also addressed. Identity is outside the scope of this > particular extension. > > I'd like this draft to become a working group document and have done > my best to make it represent the group's consensus. Unfortunately the > internet draft submission process is closed for a few weeks until > after the meeting. :-\ > > Thanks, > --David > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------050709020607050808010100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If I understand your proposal correctly, you assume the clients knows better than the authz server how to fit the client presentation capabilities the best.

Wouldn't it be neccessary to also tell the authz server the screen orientation and available size?

regards,
Torsten.

Am 12.07.2010 21:51, schrieb David Recordon:
I wrote this draft last month based on discussions on the mailing list, the OpenID user experience extension (which Facebook, Google, and Yahoo! have deployed), and some OAuth 2.0 implementation experience from Facebook. It defines language and display preferences which the client can include in requests to the end-user authorization endpoint.

A previous draft included an immediate mode parameter but further discussion has shown that it should be removed until identity information is also addressed. Identity is outside the scope of this particular extension.

I'd like this draft to become a working group document and have done my best to make it represent the group's consensus. Unfortunately the internet draft submission process is closed for a few weeks until after the meeting. :-\

Thanks,
--David

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------050709020607050808010100-- From bcampbell@pingidentity.com Tue Jul 27 05:49:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E7A3A699E for ; Tue, 27 Jul 2010 05:49:19 -0700 (PDT) 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 VK+7jIQeXako for ; Tue, 27 Jul 2010 05:49:03 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by core3.amsl.com (Postfix) with SMTP id CC1B33A6A49 for ; Tue, 27 Jul 2010 05:49:02 -0700 (PDT) Received: from source ([74.125.82.43]) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTE7V0tE0v/blNuBnMUeAnbob3uKMEebZ@postini.com; Tue, 27 Jul 2010 05:49:25 PDT Received: by mail-ww0-f43.google.com with SMTP id 39so1184558wwb.0 for ; Tue, 27 Jul 2010 05:49:22 -0700 (PDT) Received: by 10.216.187.16 with SMTP id x16mr8832702wem.104.1280234962312; Tue, 27 Jul 2010 05:49:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.71.5 with HTTP; Tue, 27 Jul 2010 05:48:52 -0700 (PDT) In-Reply-To: References: <7C01E631FF4B654FA1E783F1C0265F8C6294F782@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EF900AE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EF90102@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Tue, 27 Jul 2010 06:48:52 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 12:49:19 -0000 A client_id parameter would still be presented in the end user authorization request. The text Brian E. quoted is what mandates any specifications/documents/agreements that define how to use client assertions must also define the association between the client_id and some field(s) in the assertion. If someone sees a cleaner way to deal with client identity on the user authorization request when using assertions to authenticate the client to the token endpoint, please speak up and lets discuss it. However, in general I do feel it's important to have better defined support in the core OAuth spec to allow for client authentication methods beyond just password. -Brian On Mon, Jul 26, 2010 at 5:18 PM, Brian Eaton wrote: > On Mon, Jul 26, 2010 at 4:11 PM, Eran Hammer-Lahav = wrote: >> How do you link the client_id using in the authorization endpoint with t= he client assertion using in the token endpoint? > > In theory: > > "any document that defines how to use an assertion of a particular > type with OAuth 2.0 MUST define how to map the value from the > client_id parameter in the authorization request to a value or values > in the assertion subsequently submitted with the code to obtain an > access token." > > In practice: you do it the same way you handle any kind of identity > assertion. =A0There is some combination of issuer and subject and > signature that ends up producing an identity that you trust. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jricher@mitre.org Tue Jul 27 06:35: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 F2BEF3A6A8B for ; Tue, 27 Jul 2010 06:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 TQdR+--MW-iU for ; Tue, 27 Jul 2010 06:35:23 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 54AC63A6ABC for ; Tue, 27 Jul 2010 06:35:22 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6RDZVYw018922 for ; Tue, 27 Jul 2010 09:35:32 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6RDZVAZ018919; Tue, 27 Jul 2010 09:35:31 -0400 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; Tue, 27 Jul 2010 09:35:31 -0400 From: Justin Richer To: Torsten Lodderstedt In-Reply-To: <4C4EB974.7050102@lodderstedt.net> References: <4C4EB974.7050102@lodderstedt.net> Content-Type: text/plain; charset="UTF-8" Date: Tue, 27 Jul 2010 09:35:31 -0400 Message-ID: <1280237731.31401.3.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 13:35:28 -0000 Right, Torsten has nailed this use case: it's not tied to unregistered clients, though they could be useful there, too. We've seen need for this in both an installed app (actually, a Java Web Start app) and a server-based email gateway system. In both cases, one user can register multiple instances of the client -- in the former, different browsers or machines with the same app, in the latter, different email addresses. In both cases, the client could potentially provide some instance-identifiable information while using the same client ID for all instances. -- Justin On Tue, 2010-07-27 at 06:48 -0400, Torsten Lodderstedt wrote: > I think the proposed parameters are useful for registered clients, too. > For installed applications, there is always the chance a user authorizes > the same application (==binary==client_id?) several times, every time on > a different device. It would be helpful to differentiate those copies. > > regards, > Torsten. > > Am 17.07.2010 00:23, schrieb Marius Scurtescu: > > I agree that these parameters are useful, but not sure if they belong > > in the User Experience extension. > > > > I think we should create a separate extension for unregistered clients: > > - how to signal that this client is unregistered, maybe use a special > > value like "anonymous" as the client id > > - what client name/description should be used, as you suggest here > > > > Instead of instance_name and instance_description maybe we can call > > these client_name and client_description? > > > > Marius > > > > > > > > On Tue, Jul 13, 2010 at 5:28 AM, Richer, Justin P. wrote: > > > >> I'd like to propose the addition of two more optional parameters to this extension: > >> > >> instance_name > >> Short, human-readable name that the server SHOULD display to > >> the end-user along with the client name. This name is designed > >> to reflect a per-instance identifier for cases where a single user > >> may authorize multiple copies of a single identified client. The > >> server MAY [SHOULD?] store this information along with its > >> associated access grant to allow the end-user to differentiate > >> between instances of the application in the future (for example, > >> to revoke access tokens). > >> > >> instance_description > >> A longer, human-readable description that the server MAY display to > >> the end-user along with the client name. This description is designed > >> as the name above to reflect a per-instance identifier for cases where > >> a single user may authorize multiple copies of a single identified client. The > >> server MAY [SHOULD?] store this information along with its > >> associated access grant to allow the end-user to differentiate > >> between instances of the application in the future (for example, > >> to revoke access tokens). If a client presents the instance_description, > >> it MUST also present an instance_name. > >> > >> This can be thought of as the new way of Google's xoauth_display_name parameter. We have a direct use case for this, and it seems like it would fit in the UX more than its own extension. > >> > >> There was also talk of sending a client-information URL to get more stuff about the client and instances of it, but that seems a better fit for the impending discovery spec, to me, as it seems to address full client information and not per-instance information that this is talking about. > >> > >> -- Justin > >> ________________________________________ > >> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of David Recordon [recordond@gmail.com] > >> Sent: Monday, July 12, 2010 3:51 PM > >> To: OAuth WG > >> Subject: [OAUTH-WG] Moving the User Experience Extension draft forward > >> > >> I wrote this draft last month based on discussions on the mailing list, the OpenID user experience extension (which Facebook, Google, and Yahoo! have deployed), and some OAuth 2.0 implementation experience from Facebook. It defines language and display preferences which the client can include in requests to the end-user authorization endpoint. > >> > >> A previous draft included an immediate mode parameter but further discussion has shown that it should be removed until identity information is also addressed. Identity is outside the scope of this particular extension. > >> > >> I'd like this draft to become a working group document and have done my best to make it represent the group's consensus. Unfortunately the internet draft submission process is closed for a few weeks until after the meeting. :-\ > >> > >> Thanks, > >> --David > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > From eran@hueniverse.com Tue Jul 27 08:35: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 7D9843A6807 for ; Tue, 27 Jul 2010 08:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 fcz0LjZPtvsW for ; Tue, 27 Jul 2010 08:35:21 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 653AF3A689F for ; Tue, 27 Jul 2010 08:35:21 -0700 (PDT) Received: (qmail 1845 invoked from network); 27 Jul 2010 15:35:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 Jul 2010 15:35:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 27 Jul 2010 08:35:39 -0700 From: Eran Hammer-Lahav To: Brian Campbell , oauth Date: Tue, 27 Jul 2010 08:35:45 -0700 Thread-Topic: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions Thread-Index: AcstijFt9s0MTkHpSAyxsHxOODNNNAAFwlLQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EF901EC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C6294F782@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EF900AE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EF90102@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 Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 15:35:22 -0000 Makes sense. Personally, I don't have any preference on including it or not= . EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Campbell > Sent: Tuesday, July 27, 2010 5:49 AM > To: oauth > Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client > Assertions >=20 > A client_id parameter would still be presented in the end user authorizat= ion > request. The text Brian E. quoted is what mandates any > specifications/documents/agreements that define how to use client > assertions must also define the association between the client_id and som= e > field(s) in the assertion. >=20 > If someone sees a cleaner way to deal with client identity on the user > authorization request when using assertions to authenticate the client > to the token endpoint, please speak up and lets discuss it. However, > in general I do feel it's important to have better defined support in the= core > OAuth spec to allow for client authentication methods beyond just > password. >=20 > -Brian >=20 > On Mon, Jul 26, 2010 at 5:18 PM, Brian Eaton wrote: > > On Mon, Jul 26, 2010 at 4:11 PM, Eran Hammer-Lahav > wrote: > >> How do you link the client_id using in the authorization endpoint with= the > client assertion using in the token endpoint? > > > > In theory: > > > > "any document that defines how to use an assertion of a particular > > type with OAuth 2.0 MUST define how to map the value from the > > client_id parameter in the authorization request to a value or values > > in the assertion subsequently submitted with the code to obtain an > > access token." > > > > In practice: you do it the same way you handle any kind of identity > > assertion. =A0There is some combination of issuer and subject and > > signature that ends up producing an identity that you trust. > > _______________________________________________ > > 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 balfanz@google.com Tue Jul 27 09:12: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 4F46E3A6A90 for ; Tue, 27 Jul 2010 09:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.851 X-Spam-Level: X-Spam-Status: No, score=-105.851 tagged_above=-999 required=5 tests=[AWL=0.125, 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 6aefxsd+X-To for ; Tue, 27 Jul 2010 09:12:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C25D83A681E for ; Tue, 27 Jul 2010 09:12:06 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o6RGCSLg024537 for ; Tue, 27 Jul 2010 09:12:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280247148; bh=qAW5l0tXgWr6HlwIBeD8VlmvY0I=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=oT6t7BjbhZ3j2RKAARRKrBS6afk53BiDbRfPvhHFmnxHLz7ORDgrmYXJtpOwD//KW Df59d/MpDEp+98oDYiskQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=XXszFl0mAJiYgFOCNtIjzhjyJg71LxnuREDWm5L2+hQjRszizOM6mE59N2arndS2v 9Q+YN78lrrJRl3NuL267g== Received: from qwk4 (qwk4.prod.google.com [10.241.195.132]) by hpaq3.eem.corp.google.com with ESMTP id o6RGCQ5f009995 for ; Tue, 27 Jul 2010 09:12:26 -0700 Received: by qwk4 with SMTP id 4so866884qwk.28 for ; Tue, 27 Jul 2010 09:12:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.40.10 with SMTP id i10mr7642512qae.389.1280247145792; Tue, 27 Jul 2010 09:12:25 -0700 (PDT) Received: by 10.231.130.9 with HTTP; Tue, 27 Jul 2010 09:12:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Jul 2010 09:12:24 -0700 Message-ID: From: Dirk Balfanz To: Nat Sakimura Content-Type: multipart/alternative; boundary=000feaf2267759945b048c60c486 X-System-Of-Record: true Cc: oauth Subject: Re: [OAUTH-WG] OAuth Signature X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 16:12:11 -0000 --000feaf2267759945b048c60c486 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura wrote: > I have a fundamental question. > > While separating signature and payload by a dot "." seems ok, > I still have not the answer for the question "why not make everything > into JSON and base64url it?". > > i.e., Right now, you are proposing: > > base64url_encode(JSON(payload,envelope)).base64url_encode(signature) > > Why not > > base64url_encode(JSON(payload,envelope,signature) > You need to say what exactly the signature is over. Presumably, it's over some representation of the payload and envelope, but you need to specify exactly which representation. So in this case you would have to say something like "the signature is over the concatenation of the base64-encodings of the JSON-encodings of the payload and envelope", or something along those lines. If you did exactly this, then you would base-64 encode twice. Similar issues come up if you change the definition of what the signature is over slightly. > It probably is less hassle in terms of coding. (It is true that some > parameters gets base64url encoded twice but > How is encoding things twice "less hassle"? > BTW, some of the envelope parameters such as alg needs to be signed as > well to thwart the algorithm replacing attack. Yes, of course. Remember that in the current proposal I don't have an envelope - everything is in the payload. That's partly because I didn't want to decide what gets signed and what doesn't - everything is signed. Which in this case is easy (alternatively, I guess, you could just say that both the envelope and the payload are signed). But it gets harder when you want to encrypt the token. In this case you really need to leave some parts unencrypted (so the recipient has _some_ information on how to decrypt the thing) - presumably those parts would go into an envelope. Dirk. > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > --000feaf2267759945b048c60c486 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 27, 2010 at 12:34 AM, Nat Sa= kimura <sakimura= @gmail.com> wrote:
I have a fundamental question.

While separating signature and payload by a dot "." seems ok,
I still have not the answer for the question "why not make everything<= br> into JSON and base64url it?".

i.e., Right now, you are proposing:

base64url_encode(JSON(payload,envelope)).base64url_encode(signature)

Why not

base64url_encode(JSON(payload,envelope,signature)

=
You need to say what exactly the signature is over. Presumably, = it's over some representation of the payload and envelope, but you need= to specify exactly which representation. So in this case you would have to= say something like "the signature is over the concatenation of the ba= se64-encodings of the JSON-encodings of the payload and envelope", or = something along those lines. If you did exactly this, then you would base-6= 4 encode twice. Similar issues come up if you change the definition of what= the signature is over slightly.=A0
=A0
It probably is less hassle in= terms of coding. (It is true that some
parameters gets base64url encoded twice but

=
How is encoding things twice "less hassle"?
=A0
BTW, some of the envelope parameters such as alg needs to be signed as
well to thwart the algorithm replacing attack.

<= div>Yes, of course. Remember that in the current proposal I don't have = an envelope - everything is in the payload. That's partly because I did= n't want to decide what gets signed and what doesn't - everything i= s signed. Which in this case is easy (alternatively, I guess, you could jus= t say that both the envelope and the payload are signed). But it gets harde= r when you want to encrypt the token. In this case you really need to leave= some parts unencrypted (so the recipient has _some_ information on how to = decrypt the thing) - presumably those parts would go into an envelope.=A0

Dirk.


=A0
=
--
Nat Sakimura (=3Dnat)
http://www.sakimu= ra.org/en/
http://twitter.com= /_nat_en

--000feaf2267759945b048c60c486-- From mscurtescu@google.com Tue Jul 27 09:39: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 05D5C3A67B7 for ; Tue, 27 Jul 2010 09:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.655 X-Spam-Level: X-Spam-Status: No, score=-105.655 tagged_above=-999 required=5 tests=[AWL=0.322, 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 vnVt1K7ZezWz for ; Tue, 27 Jul 2010 09:39:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6F77F3A6784 for ; Tue, 27 Jul 2010 09:39:52 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o6RGeDBQ013897 for ; Tue, 27 Jul 2010 09:40:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280248814; bh=AXfYF6BAVA+aSAEHQm5I6qW57mk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=YjJIT4mxNJC+f8cbtp7ybi9MLaJkVCcQTSrpc1pbXR5MCaV6JwDlrk27+09xFMAiI 4Mdd1kTsFYdIWYUhtya0g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=yQDMIL93SdxdvVfSCevBM+fCi2o9Qldmw0d4hXK5MU8/TFKn8hwd5GyLAAqF8pGFZ rvQnTQJhSZ94Nxe66GlaQ== Received: from yxn35 (yxn35.prod.google.com [10.190.4.99]) by hpaq6.eem.corp.google.com with ESMTP id o6RGe6q4020938 for ; Tue, 27 Jul 2010 09:40:07 -0700 Received: by yxn35 with SMTP id 35so647930yxn.23 for ; Tue, 27 Jul 2010 09:40:06 -0700 (PDT) Received: by 10.101.106.7 with SMTP id i7mr9816600anm.176.1280248785171; Tue, 27 Jul 2010 09:39:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.33.1 with HTTP; Tue, 27 Jul 2010 09:39:25 -0700 (PDT) In-Reply-To: <1280237731.31401.3.camel@localhost.localdomain> References: <4C4EB974.7050102@lodderstedt.net> <1280237731.31401.3.camel@localhost.localdomain> From: Marius Scurtescu Date: Tue, 27 Jul 2010 09:39:25 -0700 Message-ID: To: Justin Richer 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] Moving the User Experience Extension draft forward X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 16:39:54 -0000 Is there value in pre-registering a binary that gets distributed? How is this better than this application acting anonymously? At some point it was suggested that applications that are distributed could do automatic registration of each instance, at which point they are also issued a secret. During this registration step they can specify an instance specific client name. It could be more important to have an instance specific client id, than an instance specific client name. Marius On Tue, Jul 27, 2010 at 6:35 AM, Justin Richer wrote: > Right, Torsten has nailed this use case: it's not tied to unregistered > clients, though they could be useful there, too. We've seen need for > this in both an installed app (actually, a Java Web Start app) and a > server-based email gateway system. In both cases, one user can register > multiple instances of the client -- in the former, different browsers or > machines with the same app, in the latter, different email addresses. In > both cases, the client could potentially provide some > instance-identifiable information while using the same client ID for all > instances. > > =A0-- Justin > > On Tue, 2010-07-27 at 06:48 -0400, Torsten Lodderstedt wrote: >> I think the proposed parameters are useful for registered clients, too. >> For installed applications, there is always the chance a user authorizes >> the same application (=3D=3Dbinary=3D=3Dclient_id?) several times, every= time on >> a different device. It would be helpful to differentiate those copies. >> >> regards, >> Torsten. >> >> Am 17.07.2010 00:23, schrieb Marius Scurtescu: >> > I agree that these parameters are useful, but not sure if they belong >> > in the User Experience extension. >> > >> > I think we should create a separate extension for unregistered clients= : >> > - how to signal that this client is unregistered, maybe use a special >> > value like "anonymous" as the client id >> > - what client name/description should be used, as you suggest here >> > >> > Instead of instance_name and instance_description maybe we can call >> > these client_name and client_description? >> > >> > Marius >> > >> > >> > >> > On Tue, Jul 13, 2010 at 5:28 AM, Richer, Justin P. = =A0wrote: >> > >> >> I'd like to propose the addition of two more optional parameters to t= his extension: >> >> >> >> instance_name >> >> =A0 =A0Short, human-readable name that the server SHOULD display to >> >> =A0 =A0the end-user along with the client name. This name is designed >> >> =A0 =A0to reflect a per-instance identifier for cases where a single = user >> >> =A0 =A0may authorize multiple copies of a single identified client. T= he >> >> =A0 =A0server MAY [SHOULD?] store this information along with its >> >> =A0 =A0associated access grant to allow the end-user to differentiate >> >> =A0 =A0between instances of the application in the future (for exampl= e, >> >> =A0 =A0to revoke access tokens). >> >> >> >> instance_description >> >> =A0 =A0A longer, human-readable description that the server MAY displ= ay to >> >> =A0 =A0the end-user along with the client name. This description =A0i= s designed >> >> =A0 =A0as the name above to reflect a per-instance identifier for cas= es where >> >> =A0 =A0a single user may authorize multiple copies of a single identi= fied client. The >> >> =A0 =A0server MAY [SHOULD?] store this information along with its >> >> =A0 =A0associated access grant to allow the end-user to differentiate >> >> =A0 =A0between instances of the application in the future (for exampl= e, >> >> =A0 =A0to revoke access tokens). If a client presents the instance_de= scription, >> >> =A0 =A0it MUST also present an instance_name. >> >> >> >> This can be thought of as the new way of Google's xoauth_display_name= parameter. We have a direct use case for this, and it seems like it would = fit in the UX more than its own extension. >> >> >> >> There was also talk of sending a client-information URL to get more s= tuff about the client and instances of it, but that seems a better fit for = the impending discovery spec, to me, as it seems to address full client inf= ormation and not per-instance information that this is talking about. >> >> >> >> =A0 -- Justin >> >> ________________________________________ >> >> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Da= vid Recordon [recordond@gmail.com] >> >> Sent: Monday, July 12, 2010 3:51 PM >> >> To: OAuth WG >> >> Subject: [OAUTH-WG] Moving the User Experience Extension draft forwar= d >> >> >> >> I wrote this draft last month based on discussions on the mailing lis= t, the OpenID user experience extension (which Facebook, Google, and Yahoo!= have deployed), and some OAuth 2.0 implementation experience from Facebook= . It defines language and display preferences which the client can include = in requests to the end-user authorization endpoint. >> >> >> >> A previous draft included an immediate mode parameter but further dis= cussion has shown that it should be removed until identity information is a= lso addressed. Identity is outside the scope of this particular extension. >> >> >> >> I'd like this draft to become a working group document and have done = my best to make it represent the group's consensus. Unfortunately the inter= net draft submission process is closed for a few weeks until after the meet= ing. :-\ >> >> >> >> Thanks, >> >> --David >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > > > From bcampbell@pingidentity.com Tue Jul 27 09:48: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 5E5B63A6A59 for ; Tue, 27 Jul 2010 09:48:58 -0700 (PDT) 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 DRlB0dVYon2e for ; Tue, 27 Jul 2010 09:48:57 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by core3.amsl.com (Postfix) with SMTP id 0FD7C3A6952 for ; Tue, 27 Jul 2010 09:48:56 -0700 (PDT) Received: from source ([74.125.82.173]) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTE8ODp/Oxxf0sAjcY4cOtIOzuN4/Safp@postini.com; Tue, 27 Jul 2010 09:49:19 PDT Received: by mail-wy0-f173.google.com with SMTP id 11so3127512wyi.32 for ; Tue, 27 Jul 2010 09:49:18 -0700 (PDT) Received: by 10.216.62.206 with SMTP id y56mr9191987wec.59.1280249358246; Tue, 27 Jul 2010 09:49:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.71.5 with HTTP; Tue, 27 Jul 2010 09:48:48 -0700 (PDT) In-Reply-To: <4C48BAA6.8050702@lodderstedt.net> References: <4C432262.40204@lodderstedt.net> <4C48BAA6.8050702@lodderstedt.net> From: Brian Campbell Date: Tue, 27 Jul 2010 10:48:48 -0600 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 16:48:58 -0000 On Thu, Jul 22, 2010 at 3:39 PM, Torsten Lodderstedt wrote: > Sounds like you defining a profile of the OAuth assertion flow for using > SAML assertions complying to the SAML "Web Browser SSO Profile". I think = you > should state that somewhere. There will probably be other assertion flow > profiles for other SAML assertion "dialects". It's not *exactly* like the the Web SSO Profile but similar in most respects. I'll work in some language about that intent in the next draft. >>> Your I-D states: >>> "The authorization server MUST ensure that bearer assertions are >>> =A0 =A0 =A0 not replayed, by maintaining the set of used ID values for = the >>> =A0 =A0 =A0 length of time for which the assertion would be considered = valid >>> =A0 =A0 =A0 based on the NotOnOrAfter attribute in the >>> =A0 =A0 =A0 ." >>> >>> Why do you want to force a one-time usage for SAML assertions? >>> This is to =A0restrictive, in my opinion. >>> >> >> This is also a carryover from web SSO via the POST binding. =A0I was >> actually leaning towards not including this language but a couple >> early reviews were interesting in having it in there. =A0My co-author on >> this draft, Mr. Chuck Mortimore, was one of those folks so maybe he >> could provide more insight into his reasoning there. =A0Chuck? >> >> >>> >>> Any issuing authority could enforce such a >>> policy by using the "OneTimeUse" element. >>> >> >> Personally, I've always found the spec language around OneTimeUse to >> be confusing and somewhat ambiguous. =A0 Maybe I'm wrong but take a look >> at "2.5.1.5 Element" and the treatment of OneTimeUse in >> "2.5.1 Element" of saml-core-2.0-os. =A0There are parts of >> that language that do suggest OneTimeUse is intended to indicate that >> some replay check is required but other parts seem to say something >> entirely different. =A0 I don't believe that OneTimeUse is widely used >> or supported. >> > > We don't use it, too :-) :) Anyone else have thoughts on the "not replayed" clause in here? I'm on the fence about it, as I said. Chuck, I know your busy conference hopping but if you get a chance, can you describe again why you thought this was important? From torsten@lodderstedt.net Tue Jul 27 10:08: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 135A53A694D for ; Tue, 27 Jul 2010 10:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[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 fAIY5d-WV6SA for ; Tue, 27 Jul 2010 10:08:53 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by core3.amsl.com (Postfix) with ESMTP id 926393A6ACA for ; Tue, 27 Jul 2010 10:08:53 -0700 (PDT) Received: from [84.26.84.97] (helo=[192.168.1.47]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OdneT-0006wX-Rh; Tue, 27 Jul 2010 19:09:14 +0200 References: <4C4EB974.7050102@lodderstedt.net> <1280237731.31401.3.camel@localhost.localdomain> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Tue, 27 Jul 2010 19:08:28 +0200 To: Marius Scurtescu X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 17:08:55 -0000 Good question. Probably because the authz servers wants to realize the relat= ionship in order to apply a client (=3D=3D partner) specific policy to all i= nstances or to present the end user with a tree like view in user self care,= like this=20 My EPG Epg on iPhone=20 Epg on Nexus One regards, Torsten. Am 27.07.2010 um 18:39 schrieb Marius Scurtescu : > Is there value in pre-registering a binary that gets distributed? How > is this better than this application acting anonymously? >=20 > At some point it was suggested that applications that are distributed > could do automatic registration of each instance, at which point they > are also issued a secret. During this registration step they can > specify an instance specific client name. >=20 > It could be more important to have an instance specific client id, > than an instance specific client name. >=20 > Marius >=20 >=20 >=20 > On Tue, Jul 27, 2010 at 6:35 AM, Justin Richer wrote: >> Right, Torsten has nailed this use case: it's not tied to unregistered >> clients, though they could be useful there, too. We've seen need for >> this in both an installed app (actually, a Java Web Start app) and a >> server-based email gateway system. In both cases, one user can register >> multiple instances of the client -- in the former, different browsers or >> machines with the same app, in the latter, different email addresses. In >> both cases, the client could potentially provide some >> instance-identifiable information while using the same client ID for all >> instances. >>=20 >> -- Justin >>=20 >> On Tue, 2010-07-27 at 06:48 -0400, Torsten Lodderstedt wrote: >>> I think the proposed parameters are useful for registered clients, too. >>> For installed applications, there is always the chance a user authorizes= >>> the same application (=3D=3Dbinary=3D=3Dclient_id?) several times, every= time on >>> a different device. It would be helpful to differentiate those copies. >>>=20 >>> regards, >>> Torsten. >>>=20 >>> Am 17.07.2010 00:23, schrieb Marius Scurtescu: >>>> I agree that these parameters are useful, but not sure if they belong >>>> in the User Experience extension. >>>>=20 >>>> I think we should create a separate extension for unregistered clients:= >>>> - how to signal that this client is unregistered, maybe use a special >>>> value like "anonymous" as the client id >>>> - what client name/description should be used, as you suggest here >>>>=20 >>>> Instead of instance_name and instance_description maybe we can call >>>> these client_name and client_description? >>>>=20 >>>> Marius >>>>=20 >>>>=20 >>>>=20 >>>> On Tue, Jul 13, 2010 at 5:28 AM, Richer, Justin P. w= rote: >>>>=20 >>>>> I'd like to propose the addition of two more optional parameters to th= is extension: >>>>>=20 >>>>> instance_name >>>>> Short, human-readable name that the server SHOULD display to >>>>> the end-user along with the client name. This name is designed >>>>> to reflect a per-instance identifier for cases where a single user >>>>> may authorize multiple copies of a single identified client. The >>>>> server MAY [SHOULD?] store this information along with its >>>>> associated access grant to allow the end-user to differentiate >>>>> between instances of the application in the future (for example, >>>>> to revoke access tokens). >>>>>=20 >>>>> instance_description >>>>> A longer, human-readable description that the server MAY display to= >>>>> the end-user along with the client name. This description is desig= ned >>>>> as the name above to reflect a per-instance identifier for cases wh= ere >>>>> a single user may authorize multiple copies of a single identified c= lient. The >>>>> server MAY [SHOULD?] store this information along with its >>>>> associated access grant to allow the end-user to differentiate >>>>> between instances of the application in the future (for example, >>>>> to revoke access tokens). If a client presents the instance_descrip= tion, >>>>> it MUST also present an instance_name. >>>>>=20 >>>>> This can be thought of as the new way of Google's xoauth_display_name p= arameter. We have a direct use case for this, and it seems like it would fit= in the UX more than its own extension. >>>>>=20 >>>>> There was also talk of sending a client-information URL to get more st= uff about the client and instances of it, but that seems a better fit for th= e impending discovery spec, to me, as it seems to address full client inform= ation and not per-instance information that this is talking about. >>>>>=20 >>>>> -- Justin >>>>> ________________________________________ >>>>> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dav= id Recordon [recordond@gmail.com] >>>>> Sent: Monday, July 12, 2010 3:51 PM >>>>> To: OAuth WG >>>>> Subject: [OAUTH-WG] Moving the User Experience Extension draft forward= >>>>>=20 >>>>> I wrote this draft last month based on discussions on the mailing list= , the OpenID user experience extension (which Facebook, Google, and Yahoo! h= ave deployed), and some OAuth 2.0 implementation experience from Facebook. I= t defines language and display preferences which the client can include in r= equests to the end-user authorization endpoint. >>>>>=20 >>>>> A previous draft included an immediate mode parameter but further disc= ussion has shown that it should be removed until identity information is als= o addressed. Identity is outside the scope of this particular extension. >>>>>=20 >>>>> I'd like this draft to become a working group document and have done m= y best to make it represent the group's consensus. Unfortunately the interne= t draft submission process is closed for a few weeks until after the meeting= . :-\ >>>>>=20 >>>>> Thanks, >>>>> --David >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >>=20 >>=20 From jricher@mitre.org Tue Jul 27 10:47: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 1910B3A6894 for ; Tue, 27 Jul 2010 10:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 zMPWc9elqXX7 for ; Tue, 27 Jul 2010 10:47:16 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 457FE28C0E6 for ; Tue, 27 Jul 2010 10:31:14 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6RHVU1i015932 for ; Tue, 27 Jul 2010 13:31:31 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6RHVUjb015929; Tue, 27 Jul 2010 13:31:30 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Tue, 27 Jul 2010 13:31:30 -0400 From: Justin Richer To: Marius Scurtescu In-Reply-To: References: <4C4EB974.7050102@lodderstedt.net> <1280237731.31401.3.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Tue, 27 Jul 2010 13:31:29 -0400 Message-ID: <1280251889.31401.12.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 17:47:18 -0000 The second use case I outlined is not a distributed app and does not fit the case for dynamic registration at all. It is a server with a securely stored and guarded secret. The same user can have multiple authorized inputs (email addresses in this case) to this server, and all are stored with separate tokens and require separate authorization steps. What we end up with is a user having four instances of this app in their apps list on the PR with no good way to differentiate between the instances. While I'm all for allowing dynamic registration, I also don't see why this couldn't be used to augment the information in a distributed binary, whether the client_id be pre-registered, anonymous, or some kind of user-agent-string. The idea behind the name is to make it something human-readable, something that the client_id and its attendant bits have no real business being. -- Justin On Tue, 2010-07-27 at 12:39 -0400, Marius Scurtescu wrote: > Is there value in pre-registering a binary that gets distributed? How > is this better than this application acting anonymously? > > At some point it was suggested that applications that are distributed > could do automatic registration of each instance, at which point they > are also issued a secret. During this registration step they can > specify an instance specific client name. > > It could be more important to have an instance specific client id, > than an instance specific client name. > > Marius > > > > On Tue, Jul 27, 2010 at 6:35 AM, Justin Richer wrote: > > Right, Torsten has nailed this use case: it's not tied to unregistered > > clients, though they could be useful there, too. We've seen need for > > this in both an installed app (actually, a Java Web Start app) and a > > server-based email gateway system. In both cases, one user can register > > multiple instances of the client -- in the former, different browsers or > > machines with the same app, in the latter, different email addresses. In > > both cases, the client could potentially provide some > > instance-identifiable information while using the same client ID for all > > instances. > > > > -- Justin > > > > On Tue, 2010-07-27 at 06:48 -0400, Torsten Lodderstedt wrote: > >> I think the proposed parameters are useful for registered clients, too. > >> For installed applications, there is always the chance a user authorizes > >> the same application (==binary==client_id?) several times, every time on > >> a different device. It would be helpful to differentiate those copies. > >> > >> regards, > >> Torsten. > >> > >> Am 17.07.2010 00:23, schrieb Marius Scurtescu: > >> > I agree that these parameters are useful, but not sure if they belong > >> > in the User Experience extension. > >> > > >> > I think we should create a separate extension for unregistered clients: > >> > - how to signal that this client is unregistered, maybe use a special > >> > value like "anonymous" as the client id > >> > - what client name/description should be used, as you suggest here > >> > > >> > Instead of instance_name and instance_description maybe we can call > >> > these client_name and client_description? > >> > > >> > Marius > >> > > >> > > >> > > >> > On Tue, Jul 13, 2010 at 5:28 AM, Richer, Justin P. wrote: > >> > > >> >> I'd like to propose the addition of two more optional parameters to this extension: > >> >> > >> >> instance_name > >> >> Short, human-readable name that the server SHOULD display to > >> >> the end-user along with the client name. This name is designed > >> >> to reflect a per-instance identifier for cases where a single user > >> >> may authorize multiple copies of a single identified client. The > >> >> server MAY [SHOULD?] store this information along with its > >> >> associated access grant to allow the end-user to differentiate > >> >> between instances of the application in the future (for example, > >> >> to revoke access tokens). > >> >> > >> >> instance_description > >> >> A longer, human-readable description that the server MAY display to > >> >> the end-user along with the client name. This description is designed > >> >> as the name above to reflect a per-instance identifier for cases where > >> >> a single user may authorize multiple copies of a single identified client. The > >> >> server MAY [SHOULD?] store this information along with its > >> >> associated access grant to allow the end-user to differentiate > >> >> between instances of the application in the future (for example, > >> >> to revoke access tokens). If a client presents the instance_description, > >> >> it MUST also present an instance_name. > >> >> > >> >> This can be thought of as the new way of Google's xoauth_display_name parameter. We have a direct use case for this, and it seems like it would fit in the UX more than its own extension. > >> >> > >> >> There was also talk of sending a client-information URL to get more stuff about the client and instances of it, but that seems a better fit for the impending discovery spec, to me, as it seems to address full client information and not per-instance information that this is talking about. > >> >> > >> >> -- Justin > >> >> ________________________________________ > >> >> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of David Recordon [recordond@gmail.com] > >> >> Sent: Monday, July 12, 2010 3:51 PM > >> >> To: OAuth WG > >> >> Subject: [OAUTH-WG] Moving the User Experience Extension draft forward > >> >> > >> >> I wrote this draft last month based on discussions on the mailing list, the OpenID user experience extension (which Facebook, Google, and Yahoo! have deployed), and some OAuth 2.0 implementation experience from Facebook. It defines language and display preferences which the client can include in requests to the end-user authorization endpoint. > >> >> > >> >> A previous draft included an immediate mode parameter but further discussion has shown that it should be removed until identity information is also addressed. Identity is outside the scope of this particular extension. > >> >> > >> >> I'd like this draft to become a working group document and have done my best to make it represent the group's consensus. Unfortunately the internet draft submission process is closed for a few weeks until after the meeting. :-\ > >> >> > >> >> Thanks, > >> >> --David > >> >> _______________________________________________ > >> >> OAuth mailing list > >> >> OAuth@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> >> > >> >> > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > > > > > > From cmortimore@salesforce.com Tue Jul 27 11:27: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 4E7383A66B4 for ; Tue, 27 Jul 2010 11:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=0.334, 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 n-D3mFEVCY7k for ; Tue, 27 Jul 2010 11:27:12 -0700 (PDT) Received: from exprod8og120.obsmtp.com (exprod8og120.obsmtp.com [64.18.3.40]) by core3.amsl.com (Postfix) with SMTP id 23CB53A695E for ; Tue, 27 Jul 2010 11:27:11 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob120.postini.com ([64.18.7.12]) with SMTP ID DSNKTE8lFQKs3XgaxgdioeFEk/XmA4FnJ2u7@postini.com; Tue, 27 Jul 2010 11:27:34 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Tue, 27 Jul 2010 11:27:32 -0700 From: Chuck Mortimore To: Brian Campbell Date: Tue, 27 Jul 2010 11:26:55 -0700 Thread-Topic: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft Thread-Index: AcstuWD877lxKELzQfydqA4cSxRU6Q== Message-ID: <66D3B03F-544A-4EEB-8AA7-137165BF1BBE@salesforce.com> References: <4C432262.40204@lodderstedt.net> <4C48BAA6.8050702@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] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 18:27:13 -0000 Yes - this is intended to be a simplified parallel to web sso profile. We = also intend to ship a straight adaptation of websso, as do others I believe For both of these, We intend to enforce one time use; I suspect that type o= f state maintenance will get argued against by those running the large scal= e consumer systems...it's manageable for us given how our Multi-tenancy is = setup. I could see relaxing this to a should if people feel strongly. It = would be good to see some arguments/use-cases along with the objections I would also like to see other profiles, such as a holder of key profile. = This is a good starting point for what our customers need /request, but we = intend to expand profiles as customers and the industry evolve - cmort On Jul 27, 2010, at 9:49 AM, Brian Campbell wr= ote: > On Thu, Jul 22, 2010 at 3:39 PM, Torsten Lodderstedt > wrote: >> Sounds like you defining a profile of the OAuth assertion flow for using >> SAML assertions complying to the SAML "Web Browser SSO Profile". I think= you >> should state that somewhere. There will probably be other assertion flow >> profiles for other SAML assertion "dialects". >=20 > It's not *exactly* like the the Web SSO Profile but similar in most > respects. I'll work in some language about that intent in the next > draft. >=20 >=20 >>>> Your I-D states: >>>> "The authorization server MUST ensure that bearer assertions are >>>> not replayed, by maintaining the set of used ID values for the >>>> length of time for which the assertion would be considered valid >>>> based on the NotOnOrAfter attribute in the >>>> ." >>>>=20 >>>> Why do you want to force a one-time usage for SAML assertions? >>>> This is to restrictive, in my opinion. >>>>=20 >>>=20 >>> This is also a carryover from web SSO via the POST binding. I was >>> actually leaning towards not including this language but a couple >>> early reviews were interesting in having it in there. My co-author on >>> this draft, Mr. Chuck Mortimore, was one of those folks so maybe he >>> could provide more insight into his reasoning there. Chuck? >>>=20 >>>=20 >>>>=20 >>>> Any issuing authority could enforce such a >>>> policy by using the "OneTimeUse" element. >>>>=20 >>>=20 >>> Personally, I've always found the spec language around OneTimeUse to >>> be confusing and somewhat ambiguous. Maybe I'm wrong but take a look >>> at "2.5.1.5 Element" and the treatment of OneTimeUse in >>> "2.5.1 Element" of saml-core-2.0-os. There are parts of >>> that language that do suggest OneTimeUse is intended to indicate that >>> some replay check is required but other parts seem to say something >>> entirely different. I don't believe that OneTimeUse is widely used >>> or supported. >>>=20 >>=20 >> We don't use it, too :-) >=20 > :) > Anyone else have thoughts on the "not replayed" clause in here? I'm > on the fence about it, as I said. Chuck, I know your busy conference > hopping but if you get a chance, can you describe again why you > thought this was important? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Tue Jul 27 11:38:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727B73A67E3 for ; Tue, 27 Jul 2010 11:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.795 X-Spam-Level: X-Spam-Status: No, score=-101.795 tagged_above=-999 required=5 tests=[AWL=0.182, 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 NQ6oCivah6Yw for ; Tue, 27 Jul 2010 11:38:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C3A6B3A6358 for ; Tue, 27 Jul 2010 11:38:42 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o6RId3Xf001357 for ; Tue, 27 Jul 2010 11:39:03 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280255944; bh=vYjFqKkPW1e6h7Em+h0GJVrjRiI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=C0TxVtKpP0RQ1Dp671Lrmx6mPO3sRsqqoen97iCsM3U8PiVhsIp8AavHducZZpZXr FykjMMvZDhz+5uLLHyHgQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=uJOLF4lIjBJEy9QJ7TorqcCPHxLLzQYt3edpoFzZxPWphCcY5a10RqOF+DQbCGyTr FjtLemTXCroUj6pEdrNHA== Received: from yxk8 (yxk8.prod.google.com [10.190.3.136]) by hpaq14.eem.corp.google.com with ESMTP id o6RIcPN1005943 for ; Tue, 27 Jul 2010 11:39:02 -0700 Received: by yxk8 with SMTP id 8so920869yxk.2 for ; Tue, 27 Jul 2010 11:39:02 -0700 (PDT) Received: by 10.100.174.16 with SMTP id w16mr10144933ane.258.1280255942365; Tue, 27 Jul 2010 11:39:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.33.1 with HTTP; Tue, 27 Jul 2010 11:38:42 -0700 (PDT) In-Reply-To: <1280251889.31401.12.camel@localhost.localdomain> References: <4C4EB974.7050102@lodderstedt.net> <1280237731.31401.3.camel@localhost.localdomain> <1280251889.31401.12.camel@localhost.localdomain> From: Marius Scurtescu Date: Tue, 27 Jul 2010 11:38:42 -0700 Message-ID: To: Justin Richer 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] Moving the User Experience Extension draft forward X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 18:38:44 -0000 On Tue, Jul 27, 2010 at 10:31 AM, Justin Richer wrote: > The second use case I outlined is not a distributed app and does not fit > the case for dynamic registration at all. It is a server with a securely > stored and guarded secret. The same user can have multiple authorized > inputs (email addresses in this case) to this server, and all are stored > with separate tokens and require separate authorization steps. What we > end up with is a user having four instances of this app in their apps > list on the PR with no good way to differentiate between the instances. I see, that's an interesting use case. On the client side the user can have multiple accounts or personae. You can have a many-to-many relationship between accounts on the client side and on the authz server side. Since there is no explicit support for this in oauth (something like client_user_account), I assume you would have to use the 'state' parameter to pass this information through? What about adding the notion of a client side user account? > While I'm all for allowing dynamic registration, I also don't see why > this couldn't be used to augment the information in a distributed > binary, whether the client_id be pre-registered, anonymous, or some kind > of user-agent-string. The idea behind the name is to make it something > human-readable, something that the client_id and its attendant bits have > no real business being. You are probably right, having client_name/client_description parameters that can be used in all flows and with all clients (not only unregistered) is useful. It is up to the authz server to use this info however it sees fit (even ignore for registered clients). Marius > > =A0-- Justin > > On Tue, 2010-07-27 at 12:39 -0400, Marius Scurtescu wrote: >> Is there value in pre-registering a binary that gets distributed? How >> is this better than this application acting anonymously? >> >> At some point it was suggested that applications that are distributed >> could do automatic registration of each instance, at which point they >> are also issued a secret. During this registration step they can >> specify an instance specific client name. >> >> It could be more important to have an instance specific client id, >> than an instance specific client name. >> >> Marius >> >> >> >> On Tue, Jul 27, 2010 at 6:35 AM, Justin Richer wrote= : >> > Right, Torsten has nailed this use case: it's not tied to unregistered >> > clients, though they could be useful there, too. We've seen need for >> > this in both an installed app (actually, a Java Web Start app) and a >> > server-based email gateway system. In both cases, one user can registe= r >> > multiple instances of the client -- in the former, different browsers = or >> > machines with the same app, in the latter, different email addresses. = In >> > both cases, the client could potentially provide some >> > instance-identifiable information while using the same client ID for a= ll >> > instances. >> > >> > =A0-- Justin >> > >> > On Tue, 2010-07-27 at 06:48 -0400, Torsten Lodderstedt wrote: >> >> I think the proposed parameters are useful for registered clients, to= o. >> >> For installed applications, there is always the chance a user authori= zes >> >> the same application (=3D=3Dbinary=3D=3Dclient_id?) several times, ev= ery time on >> >> a different device. It would be helpful to differentiate those copies= . >> >> >> >> regards, >> >> Torsten. >> >> >> >> Am 17.07.2010 00:23, schrieb Marius Scurtescu: >> >> > I agree that these parameters are useful, but not sure if they belo= ng >> >> > in the User Experience extension. >> >> > >> >> > I think we should create a separate extension for unregistered clie= nts: >> >> > - how to signal that this client is unregistered, maybe use a speci= al >> >> > value like "anonymous" as the client id >> >> > - what client name/description should be used, as you suggest here >> >> > >> >> > Instead of instance_name and instance_description maybe we can call >> >> > these client_name and client_description? >> >> > >> >> > Marius >> >> > >> >> > >> >> > >> >> > On Tue, Jul 13, 2010 at 5:28 AM, Richer, Justin P. =A0wrote: >> >> > >> >> >> I'd like to propose the addition of two more optional parameters t= o this extension: >> >> >> >> >> >> instance_name >> >> >> =A0 =A0Short, human-readable name that the server SHOULD display t= o >> >> >> =A0 =A0the end-user along with the client name. This name is desig= ned >> >> >> =A0 =A0to reflect a per-instance identifier for cases where a sing= le user >> >> >> =A0 =A0may authorize multiple copies of a single identified client= . The >> >> >> =A0 =A0server MAY [SHOULD?] store this information along with its >> >> >> =A0 =A0associated access grant to allow the end-user to differenti= ate >> >> >> =A0 =A0between instances of the application in the future (for exa= mple, >> >> >> =A0 =A0to revoke access tokens). >> >> >> >> >> >> instance_description >> >> >> =A0 =A0A longer, human-readable description that the server MAY di= splay to >> >> >> =A0 =A0the end-user along with the client name. This description = =A0is designed >> >> >> =A0 =A0as the name above to reflect a per-instance identifier for = cases where >> >> >> =A0 =A0a single user may authorize multiple copies of a single ide= ntified client. The >> >> >> =A0 =A0server MAY [SHOULD?] store this information along with its >> >> >> =A0 =A0associated access grant to allow the end-user to differenti= ate >> >> >> =A0 =A0between instances of the application in the future (for exa= mple, >> >> >> =A0 =A0to revoke access tokens). If a client presents the instance= _description, >> >> >> =A0 =A0it MUST also present an instance_name. >> >> >> >> >> >> This can be thought of as the new way of Google's xoauth_display_n= ame parameter. We have a direct use case for this, and it seems like it wou= ld fit in the UX more than its own extension. >> >> >> >> >> >> There was also talk of sending a client-information URL to get mor= e stuff about the client and instances of it, but that seems a better fit f= or the impending discovery spec, to me, as it seems to address full client = information and not per-instance information that this is talking about. >> >> >> >> >> >> =A0 -- Justin >> >> >> ________________________________________ >> >> >> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of= David Recordon [recordond@gmail.com] >> >> >> Sent: Monday, July 12, 2010 3:51 PM >> >> >> To: OAuth WG >> >> >> Subject: [OAUTH-WG] Moving the User Experience Extension draft for= ward >> >> >> >> >> >> I wrote this draft last month based on discussions on the mailing = list, the OpenID user experience extension (which Facebook, Google, and Yah= oo! have deployed), and some OAuth 2.0 implementation experience from Faceb= ook. It defines language and display preferences which the client can inclu= de in requests to the end-user authorization endpoint. >> >> >> >> >> >> A previous draft included an immediate mode parameter but further = discussion has shown that it should be removed until identity information i= s also addressed. Identity is outside the scope of this particular extensio= n. >> >> >> >> >> >> I'd like this draft to become a working group document and have do= ne my best to make it represent the group's consensus. Unfortunately the in= ternet draft submission process is closed for a few weeks until after the m= eeting. :-\ >> >> >> >> >> >> Thanks, >> >> >> --David >> >> >> _______________________________________________ >> >> >> OAuth mailing list >> >> >> OAuth@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> >> >> > _______________________________________________ >> >> > OAuth mailing list >> >> > OAuth@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/oauth >> >> > >> >> >> > >> > >> > > > > From bcampbell@pingidentity.com Tue Jul 27 11:56:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E389A3A684A for ; Tue, 27 Jul 2010 11:56:17 -0700 (PDT) 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 aDetxfldF9Ri for ; Tue, 27 Jul 2010 11:56:17 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by core3.amsl.com (Postfix) with SMTP id 8FC933A680F for ; Tue, 27 Jul 2010 11:56:16 -0700 (PDT) Received: from source ([74.125.82.172]) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTE8r5aFxUkVtpGXgfE7gGrkqWOzlKkPF@postini.com; Tue, 27 Jul 2010 11:56:39 PDT Received: by mail-wy0-f172.google.com with SMTP id 40so3597578wyb.31 for ; Tue, 27 Jul 2010 11:56:37 -0700 (PDT) Received: by 10.227.155.10 with SMTP id q10mr7583847wbw.92.1280256997296; Tue, 27 Jul 2010 11:56:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.71.5 with HTTP; Tue, 27 Jul 2010 11:56:06 -0700 (PDT) In-Reply-To: <66D3B03F-544A-4EEB-8AA7-137165BF1BBE@salesforce.com> References: <4C432262.40204@lodderstedt.net> <4C48BAA6.8050702@lodderstedt.net> <66D3B03F-544A-4EEB-8AA7-137165BF1BBE@salesforce.com> From: Brian Campbell Date: Tue, 27 Jul 2010 12:56:06 -0600 Message-ID: To: Chuck Mortimore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 18:56:18 -0000 On Tue, Jul 27, 2010 at 12:26 PM, Chuck Mortimore wrote: > For both of these, We intend to enforce one time use; I suspect that type= of state maintenance will get argued against by those running the large > scale consumer systems...it's manageable for us given how our Multi-tenan= cy is setup. =A0I could see relaxing this to a should if people feel strong= ly. > It would be good to see some arguments/use-cases along with the objection= s There seem to be two potential arguments against it - the burden of tracking the state and the potential that it's unnecessarily restrictive. I don't personally see either as being a major issue but would like to hear from folks if they feel differently. I could change the language from a MUST to a SHOULD or MAY to allow for more flexibility at deployment/development time? That would slightly increase the opportunity for interop problems but I don't think it's really much of a concern. I don't really want to rely on the OneTimeUse condition for the reasons I mentioned previously as well as the fact that it seems to me to be a decision of the assertion consumer just as much as (or more than) it is of the assertion issuer. From bcampbell@pingidentity.com Tue Jul 27 12:51: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 65A2C3A68B8 for ; Tue, 27 Jul 2010 12:51:18 -0700 (PDT) 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 SYIqdlXfQb9z for ; Tue, 27 Jul 2010 12:51:17 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by core3.amsl.com (Postfix) with SMTP id 176B13A679C for ; Tue, 27 Jul 2010 12:51:16 -0700 (PDT) Received: from source ([74.125.82.171]) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTE84ybuVfHSCoZzFUdVFWDE+QAQjZnHc@postini.com; Tue, 27 Jul 2010 12:51:39 PDT Received: by mail-wy0-f171.google.com with SMTP id 29so3970500wyb.16 for ; Tue, 27 Jul 2010 12:51:37 -0700 (PDT) Received: by 10.227.145.148 with SMTP id d20mr7333201wbv.117.1280260296663; Tue, 27 Jul 2010 12:51:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.71.5 with HTTP; Tue, 27 Jul 2010 12:51:06 -0700 (PDT) In-Reply-To: References: <20100727191420.3ADFD3A68BC@core3.amsl.com> From: Brian Campbell Date: Tue, 27 Jul 2010 13:51:06 -0600 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-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 19:51:18 -0000 Now that the I-D submission process/tool is open again, I went ahead and submitted the "SAML 2.0 Bearer Assertion Profile for OAuth 2.0" as an I-D. It's basically the same as the version I posted to the WG mailing list except I added some language in the introduction stating the intended similarities to Web SSO (thanks Torsten) and changed the MUST to MAY on replay checking/enforcement. It's just a draft though so that can be changed again if people feel strongly about it. Any additional thoughts or comments are of course welcome. I'd love to hear from anyone who might consider implementing/supporting this. Here's the link: http://www.ietf.org/id/draft-campbell-oauth-saml-00.txt Thanks, Brian Campbell ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Tue, Jul 27, 2010 at 1:14 PM Subject: New Version Notification for draft-campbell-oauth-saml-00 A new version of I-D, draft-campbell-oauth-saml-00.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 =A000 Title: =A0 =A0 =A0 =A0 =A0 SAML 2.0 Bearer Assertion Profile for OAuth 2.0 Creation_date: =A0 2010-07-27 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 9 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 dick.hardt@gmail.com Tue Jul 27 13:43: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 3EDE13A6927 for ; Tue, 27 Jul 2010 13:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay9J3T3GAwLP for ; Tue, 27 Jul 2010 13:43:15 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 2E2E73A6814 for ; Tue, 27 Jul 2010 13:43:15 -0700 (PDT) Received: by yxj4 with SMTP id 4so740027yxj.31 for ; Tue, 27 Jul 2010 13:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=ybPxpV1pG58sf/6RbFLo+Gx1L9ORR7vA0ibdNc6sqEw=; b=roWS2R9BkY4+sl6V5XDGKm+NeIPJMU3Ms+LYBoidn7ignvgFo6ZW8qNciOccZ6jlJn ZXVnMEmZUBHSFejO3WrfcSHGfGbt1JTWTEzN+RixOBp8bHkTwQ2gOrZauQKIYVQTxDQi lFQz2dRek7noVjdD1MSb8Tk+034YlbB7Q/WAk= 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=MDljaA3JdasS40WJNAm6lhqvjdD6VuUZd9xtBtzegqQMQ8sPWg8qucnmW1ADOv6Nyn p25TyyDZ51ox9IYUlb1CC4kkfSY4KCcM34Qug7tGLtweBjykNduxYlvKHPNkZ9GWLBSm BeXaA/jqvrYVyBEcxMWuS/c0T/eczK9Mps0Ag= Received: by 10.100.25.23 with SMTP id 23mr10202546any.225.1280263416935; Tue, 27 Jul 2010 13:43:36 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id x18sm6106737wfd.8.2010.07.27.13.43.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 13:43:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Tue, 27 Jul 2010 13:43:34 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Nat Sakimura X-Mailer: Apple Mail (2.1081) Cc: oauth Subject: Re: [OAUTH-WG] OAuth Signature X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 20:43:16 -0000 On 2010-07-27, at 12:34 AM, Nat Sakimura wrote: > I have a fundamental question. > > While separating signature and payload by a dot "." seems ok, > I still have not the answer for the question "why not make everything > into JSON and base64url it?". bloat from base64 encoding twice > > BTW, some of the envelope parameters such as alg needs to be signed as > well to thwart the algorithm replacing attack. would you elaborate on the attack? From sakimura@gmail.com Tue Jul 27 15:11: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 B481A3A696C for ; Tue, 27 Jul 2010 15:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 B1dF4FdynjdT for ; Tue, 27 Jul 2010 15:11:04 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 9F1373A697F for ; Tue, 27 Jul 2010 15:11:04 -0700 (PDT) Received: by iwn38 with SMTP id 38so4338604iwn.31 for ; Tue, 27 Jul 2010 15:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=bRmAQDSXlwAEQKjLFzcu1FodMrx1DhznD2vC9ox/9H8=; b=OvzoPPd9ljRAQK4cy7JyIVtVNFj2mvC+SvG6rK2Ko6VCc5/EvzwwFeKRD1fS7K642y dXl73rhGvviMG5YWFXaeebpPO1W9LRsKqzuNDUe6E7iUKxtVUmFOOLHzVjYbQMT7btVR 0JaOKSM4qv1ZOGYsbNh5G4FYxpiR3lnModqC4= 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=IZm44NrlingFxXp8HithT+yffeYCNyUmm1Q7g9k1P5rQk+/4eMGQ2aa0AiFDZsjeXj uX7YI7kyfK58qCj4tuT+Jch9eplYDhmH5XgqF+W2kODcrk4OovJWwohXqg4g4qTS59Uk aZ/+HUYgBSCK/qMMnjSoln9epXaUu4+POfkkk= MIME-Version: 1.0 Received: by 10.231.171.3 with SMTP id f3mr10976093ibz.145.1280268686574; Tue, 27 Jul 2010 15:11:26 -0700 (PDT) Received: by 10.231.158.67 with HTTP; Tue, 27 Jul 2010 15:11:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Jul 2010 07:11:26 +0900 Message-ID: From: Nat Sakimura To: Dick Hardt Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] OAuth Signature X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 22:11:06 -0000 On Wed, Jul 28, 2010 at 5:43 AM, Dick Hardt wrote: > > > On 2010-07-27, at 12:34 AM, Nat Sakimura wrote: > >> I have a fundamental question. >> >> While separating signature and payload by a dot "." seems ok, >> I still have not the answer for the question "why not make everything >> into JSON and base64url it?". > > bloat from base64 encoding twice Right. Then, what about just removing any newlines from the Magic Signature JSON representation? > >> >> BTW, some of the envelope parameters such as alg needs to be signed as >> well to thwart the algorithm replacing attack. > > would you elaborate on the attack? > It is the atack that was talked about sometime ago around XML Dsig. Basically, the attacker replaces the algorithm to a good one to a compromised one so that he can create a new signature for the tampered data. -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From sakimura@gmail.com Tue Jul 27 15:34: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 767C328C100 for ; Tue, 27 Jul 2010 15:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 v5szbO-0TynG for ; Tue, 27 Jul 2010 15:34:57 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 240E228C0EF for ; Tue, 27 Jul 2010 15:34:57 -0700 (PDT) Received: by iwn38 with SMTP id 38so4361617iwn.31 for ; Tue, 27 Jul 2010 15:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=GRLCsQyYpML0lyobMAFZOlcEt9QwJjn2ZMta42lnlfM=; b=TvAjZr05kD5v08OtINRmRbIUBTsH7uIaiR1wxLGIUJMs0U5fM99KrUPiPth/qsh2X4 voD6RnLq7IFLVMfsS0z+WupQLwfko2cbe90wO28EMZeO6KBXOGgFllMJULax26iPcLWt Li/yxAYQcYmLGRa5ZYn1cwaJJ/nf1wSAbCU5k= 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=Omka9PSPUEoB4hbAfEuiYKGNhkQA8LpdH0p7uFs25FNkRIsBR28JIfAx3uG0W0/s5S zlAW89Cqhwh11WKR+5RuSBjfAPBtLcSXsRwxslG08SJWx3MtZ+0sJgoeRDAmD26lVxyh 3a2+4u9hDDtuuMdO07u6PsR1X23sdO9jtA/Rc= MIME-Version: 1.0 Received: by 10.231.146.141 with SMTP id h13mr11232686ibv.1.1280270118574; Tue, 27 Jul 2010 15:35:18 -0700 (PDT) Received: by 10.231.158.67 with HTTP; Tue, 27 Jul 2010 15:35:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Jul 2010 07:35:18 +0900 Message-ID: From: Nat Sakimura To: Dirk Balfanz Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] OAuth Signature X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 22:34:58 -0000 On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz wrote: > > > On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura wrote: >> >> I have a fundamental question. >> >> While separating signature and payload by a dot "." seems ok, >> I still have not the answer for the question "why not make everything >> into JSON and base64url it?". >> >> i.e., Right now, you are proposing: >> >> base64url_encode(JSON(payload,envelope)).base64url_encode(signature) >> >> Why not >> >> base64url_encode(JSON(payload,envelope,signature) > > You need to say what exactly the signature is over. Presumably, it's over > some representation of the payload and envelope, but you need to specify > exactly which representation. So in this case you would have to say > something like "the signature is over the concatenation of the > base64-encodings of the JSON-encodings of the payload and envelope", or > something along those lines. If you did exactly this, then you would base-64 > encode twice. Similar issues come up if you change the definition of what > the signature is over slightly. I did not spell out my question correctly. The pseudo code was very misleading. By "JSON()" I was meaning something similar to magic signature json encoding or something similar because I was mainly comparing JSON Token and Magic Signature. Of course, that cannot be read from what I wrote. Sorry for that. My question is: "why not just use a profiled/modified version of Magic Signature" I do not want to have two signature methods. If the currently proposed signature method can be unified with magic signature, it would be great. > >> >> It probably is less hassle in terms of coding. (It is true that some >> parameters gets base64url encoded twice but > > How is encoding things twice "less hassle"? > >> >> BTW, some of the envelope parameters such as alg needs to be signed as >> well to thwart the algorithm replacing attack. > > Yes, of course. Remember that in the current proposal I don't have an > envelope - everything is in the payload. That's partly because I didn't want > to decide what gets signed and what doesn't - everything is signed. Which in > this case is easy (alternatively, I guess, you could just say that both the > envelope and the payload are signed). But it gets harder when you want to > encrypt the token. In this case you really need to leave some parts > unencrypted (so the recipient has _some_ information on how to decrypt the > thing) - presumably those parts would go into an envelope. > Dirk. > > >> >> -- >> Nat Sakimura (=nat) >> http://www.sakimura.org/en/ >> http://twitter.com/_nat_en > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From balfanz@google.com Tue Jul 27 16:03:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9E23A6405 for ; Tue, 27 Jul 2010 16:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZhR6l2Wwq07 for ; Tue, 27 Jul 2010 16:03:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 610303A6781 for ; Tue, 27 Jul 2010 16:03:31 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o6RN3qX1012278 for ; Tue, 27 Jul 2010 16:03:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280271833; bh=dt6VxbeEMQ8xf5/4/g133DMwfw0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ySDhcGneXwB9YZKxSfzhFAuMTiIVxgvRbYmipcxC/S5AB2qWW75RtnoHpTjA6++sL 49jXR0iHpaEBYK0SP00/w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=UFlnwIlgj+k2pesfpk579RL5azECRuPBvaJ1gQSTKbdQoEytRA50glefe90FTtpYd yT4FgnLppEvlT9zCdsj9g== Received: from iwn38 (iwn38.prod.google.com [10.241.68.102]) by wpaz9.hot.corp.google.com with ESMTP id o6RN3p5k014629 for ; Tue, 27 Jul 2010 16:03:51 -0700 Received: by iwn38 with SMTP id 38so4390725iwn.31 for ; Tue, 27 Jul 2010 16:03:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.150.7 with SMTP id w7mr11245041ibv.14.1280271829545; Tue, 27 Jul 2010 16:03:49 -0700 (PDT) Received: by 10.231.130.9 with HTTP; Tue, 27 Jul 2010 16:03:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Jul 2010 16:03:49 -0700 Message-ID: From: Dirk Balfanz To: Nat Sakimura Content-Type: multipart/alternative; boundary=00504501690a9db44c048c66831b X-System-Of-Record: true Cc: oauth Subject: Re: [OAUTH-WG] OAuth Signature X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 23:03:33 -0000 --00504501690a9db44c048c66831b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 27, 2010 at 3:35 PM, Nat Sakimura wrote: > On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz wrote: > > > > > > On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura > wrote: > >> > >> I have a fundamental question. > >> > >> While separating signature and payload by a dot "." seems ok, > >> I still have not the answer for the question "why not make everything > >> into JSON and base64url it?". > >> > >> i.e., Right now, you are proposing: > >> > >> base64url_encode(JSON(payload,envelope)).base64url_encode(signature) > >> > >> Why not > >> > >> base64url_encode(JSON(payload,envelope,signature) > > > > You need to say what exactly the signature is over. Presumably, it's over > > some representation of the payload and envelope, but you need to specify > > exactly which representation. So in this case you would have to say > > something like "the signature is over the concatenation of the > > base64-encodings of the JSON-encodings of the payload and envelope", or > > something along those lines. If you did exactly this, then you would > base-64 > > encode twice. Similar issues come up if you change the definition of what > > the signature is over slightly. > > I did not spell out my question correctly. The pseudo code was very > misleading. > By "JSON()" I was meaning something similar to magic signature json > encoding > or something similar because I was mainly comparing JSON Token and > Magic Signature. > Of course, that cannot be read from what I wrote. Sorry for that. > > My question is: > "why not just use a profiled/modified version of Magic Signature" > I think that's a fair question - in fact, I was sort of aiming for just that. Once I get a free minute, I'll see whether there is a way to write this as an MS profile... Dirk. > > I do not want to have two signature methods. > If the currently proposed signature method can be unified with magic > signature, > it would be great. > > > > >> > >> It probably is less hassle in terms of coding. (It is true that some > >> parameters gets base64url encoded twice but > > > > How is encoding things twice "less hassle"? > > > >> > >> BTW, some of the envelope parameters such as alg needs to be signed as > >> well to thwart the algorithm replacing attack. > > > > Yes, of course. Remember that in the current proposal I don't have an > > envelope - everything is in the payload. That's partly because I didn't > want > > to decide what gets signed and what doesn't - everything is signed. Which > in > > this case is easy (alternatively, I guess, you could just say that both > the > > envelope and the payload are signed). But it gets harder when you want to > > encrypt the token. In this case you really need to leave some parts > > unencrypted (so the recipient has _some_ information on how to decrypt > the > > thing) - presumably those parts would go into an envelope. > > Dirk. > > > > > >> > >> -- > >> Nat Sakimura (=nat) > >> http://www.sakimura.org/en/ > >> http://twitter.com/_nat_en > > > > > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > --00504501690a9db44c048c66831b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 27, 2010 at 3:35 PM, Nat Sak= imura <sakimura@= gmail.com> wrote:
On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz <balfanz@google.com> wrote:
>
>
> On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>> I have a fundamental question.
>>
>> While separating signature and payload by a dot "." seem= s ok,
>> I still have not the answer for the question "why not make ev= erything
>> into JSON and base64url it?".
>>
>> i.e., Right now, you are proposing:
>>
>> base64url_encode(JSON(payload,envelope)).base64url_encode(signatur= e)
>>
>> Why not
>>
>> base64url_encode(JSON(payload,envelope,signature)
>
> You need to say what exactly the signature is over. Presumably, it'= ;s over
> some representation of the payload and envelope, but you need to speci= fy
> exactly which representation. So in this case you would have to say > something like "the signature is over the concatenation of the > base64-encodings of the JSON-encodings of the payload and envelope&quo= t;, or
> something along those lines. If you did exactly this, then you would b= ase-64
> encode twice. Similar issues come up if you change the definition of w= hat
> the signature is over slightly.

I did not spell out my question correctly. The pseudo code was very m= isleading.
By "JSON()" I was meaning something similar to magic signature js= on encoding
or something similar because I was mainly comparing JSON Token and
Magic Signature.
Of course, that cannot be read from what I wrote. Sorry for that.

My question is:
"why not just use a profiled/modified version of Magic Signature"=

I think that's a fair question - i= n fact, I was sort of aiming for just that. Once I get a free minute, I'= ;ll see whether there is a way to write this as an MS profile...

Dirk.
=A0

>
>>
>> It probably is less hassle in terms of coding. (It is true that so= me
>> parameters gets base64url encoded twice but
>
> How is encoding things twice "less hassle"?
>
>>
>> BTW, some of the envelope parameters such as alg needs to be signe= d as
>> well to thwart the algorithm replacing attack.
>
> Yes, of course. Remember that in the current proposal I don't have= an
> envelope - everything is in the payload. That's partly because I d= idn't want
> to decide what gets signed and what doesn't - everything is signed= . Which in
> this case is easy (alternatively, I guess, you could just say that bot= h the
> envelope and the payload are signed). But it gets harder when you want= to
> encrypt the token. In this case you really need to leave some parts > unencrypted (so the recipient has _some_ information on how to decrypt= the
> thing) - presumably those parts would go into an envelope.
> Dirk.
>
>
>>
>> --
>> Nat Sakimura (=3Dnat)
>> http://w= ww.sakimura.org/en/
>> http://tw= itter.com/_nat_en
>
>



--

--00504501690a9db44c048c66831b-- From sakimura@gmail.com Tue Jul 27 16:10:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A239F3A6985 for ; Tue, 27 Jul 2010 16:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 rlr6tb1B0epT for ; Tue, 27 Jul 2010 16:10:49 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id F3B413A697F for ; Tue, 27 Jul 2010 16:10:48 -0700 (PDT) Received: by iwn38 with SMTP id 38so4398083iwn.31 for ; Tue, 27 Jul 2010 16:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tlcJYYuqTlYf3Ybf/XndZ+kPY98Xt9uSbL0J9CIlwRs=; b=egUX8YH2zFSPor1856Ly5UxiqmLnzb/qTryNLPtAbGPdq9+7m2UYCui5+dvo+R6m6H uxoN1mI3Q9dqtEqhdAH14Ge77xoNnMGdOZ7+0j9d8FpDfT2G9o4vQlKv6ieTax7heaKY odwtUx1gX+17/pJ9vfoRGlR+hQmMhAjKm4Tg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lW0hKxJRedtdQsPHxIsWMwiwu6B4C2GB+s0NQnft4vPefdTWDj000YWmV7T/AERBD2 fWQHVrHs2PRHLovGBCiOXAKCiEnfxwS7EwNdKRcWWKBRqyAUopdLEx43+0F8keJcLhSw U5bXIuseD5bzb/SuWqzsE5cMn3JGNMD6QyWzQ= MIME-Version: 1.0 Received: by 10.231.12.76 with SMTP id w12mr10904239ibw.87.1280272218432; Tue, 27 Jul 2010 16:10:18 -0700 (PDT) Received: by 10.231.158.67 with HTTP; Tue, 27 Jul 2010 16:10:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Jul 2010 08:10:18 +0900 Message-ID: From: Nat Sakimura To: Paul Tarjan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Facebook's experience with OAuth2.0 signatures X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 23:10:51 -0000 Thanks for sharing! One question: Was there a particular reason for having signature first instead of the payload? On Tue, Jul 27, 2010 at 7:18 AM, Paul Tarjan wro= te: > Facebook released an early version of the proposed signature method, with= the aim of getting real-life implementation experience. We are not current= ly using this for protected resource requests, but rather more like if the = authorization server returned signed data as part of the access token respo= nse. > > It was generally a success with many people really liking the scheme. > > Our main takeaway is that MANY developers used normal base64 instead of b= ase64url encoding either because they didn't read the spec thoroughly or ju= st recognized the scheme and started decoding it. This caused weird errors = which they weren't ready for (sometimes working when - and _ weren't presen= t, sometimes cutting off some json characters when their language needed pa= dding =3D, etc). > > We created an open source set of examples that developers have found help= ful, and which could be incorporated into the OAuth example set: http://git= hub.com/ptarjan/base64url > > So, I suggest to keep the signature scheme, but message the fact that it = isn't normal base64 VERY loudly and clearly in the spec, and to use example= s that will fail hard with normal base64. > > > Our implementation followed the OAuth2.0 signature scheme except for 4 ch= anges: > * signature came before payload > * not_after was renamed expires > * not all required parameters were present given the difference in use ca= se > * the parameter was called signed_request instead of signed_token > > You can read our docs here: http://developers.facebook.com/docs/authentic= ation/canvas > > > Here is a few snippets of developer feedback that we had about them not u= nderstanding to use base64url instead of base64 encoding: > > =A0 =A0 =A0 =A0--- > =A0 =A0 =A0 =A0We're seeing bogus JSON in the new parameter. It looks lik= e a few characters > =A0 =A0 =A0 =A0are being left off the end. > > =A0 =A0 =A0 =A0--- > =A0 =A0 =A0 =A0Imcompatible Base64 Encoding between PHP and Java (sun.mis= c.Base64Encoder) > > =A0 =A0 =A0 =A0The problem was, I get an extra byte at the end of the Bas= e64 Decoded Sig, > =A0 =A0 =A0 =A0comparing to the result I got from Hashing the Payload wit= h my app secret. > > =A0 =A0 =A0 =A0My guess is that PHP is not encoding base64 strictly follo= wing the Base64 > =A0 =A0 =A0 =A0convention, or, Facebook has removed the tailing "=3D" fro= m Sig which is required > =A0 =A0 =A0 =A0in most Java Base64 implementations. > > =A0 =A0 =A0 =A0The sun.misc.Base64Decoder decoded the sig with a tailing = ">", while another > =A0 =A0 =A0 =A0example I found from Internet tail with "0x00". > > =A0 =A0 =A0 =A0--- > =A0 =A0 =A0 =A0Isn't this just turning into a total mess - telling people= that they need to > =A0 =A0 =A0 =A0refer to Wiki articles to use specific Base64 encode and d= ecode functions and > =A0 =A0 =A0 =A0having to post chunks of code in order to try to get it wo= rking. > > =A0 =A0 =A0 =A0--- > =A0 =A0 =A0 =A0The problem is actually that there library is buggy and ot= hers actually follow > =A0 =A0 =A0 =A0the spec. Base64 is well defined. URLencoding is well defi= ned. Unpadded base64 > =A0 =A0 =A0 =A0with several character substitutions is now well defined := ) > > > Then people started posting code to each other, some got it wrong: > > =A0 =A0 =A0 =A0> # Ruby > =A0 =A0 =A0 =A0> > =A0 =A0 =A0 =A0> def base64_url_decode(str) > =A0 =A0 =A0 =A0> =A0 =A0 return Base64.decode64(str.tr('-_', '+/')) > =A0 =A0 =A0 =A0> end > =A0 =A0 =A0 =A0> > > =A0 =A0 =A0 =A0that does not account for missing padding. > > > Then someone actually read the spec: > > =A0 =A0 =A0 =A0Facebook is following RFC. http://www.faqs.org/rfcs/rfc354= 8.html - > =A0 =A0 =A0 =A0Section 4. > > =A0 =A0 =A0 =A0That said, I don't really agree with the use of the "filen= ame safe" style. I'd > =A0 =A0 =A0 =A0implement base64 with the protocol and/or filesystem speci= fic encoding > =A0 =A0 =A0 =A0separated, because I don't think the spec should be concer= ned with that. Also, > =A0 =A0 =A0 =A0not many people use this style, so most libraries don't ha= ve support for it. > =A0 =A0 =A0 =A0But hey, I'm just one of those well-read ruby hipsters, wh= at do I know? > > > We got lots of positive feedback about it: > > =A0 =A0 =A0 =A0--- > =A0 =A0 =A0 =A0I'm a fan *cough* of the new auth mechanism; > > =A0 =A0 =A0 =A0--- > =A0 =A0 =A0 =A0I agree that this is much cleaner. I like allowing the ori= ginal request method > =A0 =A0 =A0 =A0to be used. I just wish things followed the actual specifi= cation or had their > =A0 =A0 =A0 =A0differences documented. As a library maintainer, I would a= lso like to know > =A0 =A0 =A0 =A0before things like this are released. > > =A0 =A0 =A0 =A0--- > =A0 =A0 =A0 =A0I'm also perfectly happy with the direction FB is going he= re. > > =A0 =A0 =A0 =A0--- > =A0 =A0 =A0 =A0I have to say too, I'm also a big fan of the new authentic= ation system, thank > =A0 =A0 =A0 =A0you. It has cut out a lot of code for us, and it's a lot e= asier to debug. This > =A0 =A0 =A0 =A0is a good verification system too. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From sakimura@gmail.com Tue Jul 27 16:31:05 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74863A67E2 for ; Tue, 27 Jul 2010 16:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 P8QbzgcuYvek for ; Tue, 27 Jul 2010 16:31:03 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DCC7028C0F6 for ; Tue, 27 Jul 2010 16:31:02 -0700 (PDT) Received: by iwn38 with SMTP id 38so4419440iwn.31 for ; Tue, 27 Jul 2010 16:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=JctzWUXWbWvjbNzix/DYDJCbei4scizNp1sILxTz5dc=; b=giZJGD73cb0ytK6JZ3tUCtLxnHnWds5XvrGH3hgcoPou7yHOcxhR4+WglDxSGro5Ky FaDCm0C5jU00tZgg4sb/K3UWAch9i3ltq9+zkFteIiL+WL+MS6Px0gvah/QAwdVXLe7I ZbKfb8DH8s7Av7lp97KBYaaMGn/vDl8ShiSTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YgozGMdhhPwhgsmmrL7hmvFvw8BYRF8Tho6zHJV1//NfTfZATtKfeJgDwlGn/UIoXy jDToN+lAjIo8reyl5YRNRjV7Ith/xa1U+Oc3f82ne0a/6zxhz2IzV5ewLd/BOvivdqgp Emn2Uw1iMdNGW6PgbPjCuWH7MqeuzQdxl8CPo= MIME-Version: 1.0 Received: by 10.231.34.70 with SMTP id k6mr10813186ibd.25.1280273485018; Tue, 27 Jul 2010 16:31:25 -0700 (PDT) Received: by 10.231.158.67 with HTTP; Tue, 27 Jul 2010 16:31:24 -0700 (PDT) Date: Wed, 28 Jul 2010 08:31:24 +0900 Message-ID: From: Nat Sakimura To: Dirk Balfanz , oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] On the discovery of the OAuth Signature X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 23:31:05 -0000 Hi. Currently, the discovery document would have something like: { "verification_keys": { "key1":"RSA.ALqcwR...", "key2":"X509. } } It defines RSA and X509. Could we define a third type "certs_url" that points to the file that stores PEM format certificates (chain as well)? =nat -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From beaton@google.com Tue Jul 27 16:40:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70073A6860 for ; Tue, 27 Jul 2010 16:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.958 X-Spam-Level: X-Spam-Status: No, score=-101.958 tagged_above=-999 required=5 tests=[AWL=0.019, 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 OVhiFT+TBEcT for ; Tue, 27 Jul 2010 16:40:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id E4EEB3A684E for ; Tue, 27 Jul 2010 16:40:31 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o6RNeqtp001136 for ; Tue, 27 Jul 2010 16:40:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280274052; bh=inzhQfJZvUfvKO5Efnrmd2bHn+U=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=lhKGuxJndp1jIIWj++Zmk3qP2GNRMoCWkgFRJbR5/awH8Jxr9ZuRmZVeX4cSOtXR8 NiXrW1/x7tAWqmKN69sGA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=hsbTu/VDVJWTnWEdJ/DtFooo8b/NDgAWMW7nqpwNr50RujVyNQalgKgf3VvyIMDfi 4x6olcIv9iyzb4L+McqQw== Received: from yxm8 (yxm8.prod.google.com [10.190.4.8]) by kpbe16.cbf.corp.google.com with ESMTP id o6RNeoNP018103 for ; Tue, 27 Jul 2010 16:40:51 -0700 Received: by yxm8 with SMTP id 8so1145882yxm.11 for ; Tue, 27 Jul 2010 16:40:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.101.15 with SMTP id y15mr7173891agb.192.1280274050489; Tue, 27 Jul 2010 16:40:50 -0700 (PDT) Received: by 10.91.215.2 with HTTP; Tue, 27 Jul 2010 16:40:50 -0700 (PDT) In-Reply-To: References: <4C432262.40204@lodderstedt.net> <4C48BAA6.8050702@lodderstedt.net> <66D3B03F-544A-4EEB-8AA7-137165BF1BBE@salesforce.com> Date: Tue, 27 Jul 2010 16:40:50 -0700 Message-ID: From: Brian Eaton To: Brian Campbell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2010 23:40:33 -0000 On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell wrote: > There seem to be two potential arguments against it - the burden of > tracking the state and the potential that it's unnecessarily > restrictive. =A0I don't personally see either as being a major issue but > would like to hear from folks if they feel differently. =A0 I could > change the language from a MUST to a SHOULD or MAY to allow for more > flexibility at deployment/development time? =A0That would slightly > increase the opportunity for interop problems but I don't think it's > really much of a concern. MAY seems reasonable to me. From eran@hueniverse.com Tue Jul 27 17:36: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 7FAE63A65A6 for ; Tue, 27 Jul 2010 17:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.132, 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 2WeNivLhg4AU for ; Tue, 27 Jul 2010 17:36:13 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D14223A6781 for ; Tue, 27 Jul 2010 17:36:12 -0700 (PDT) Received: (qmail 14067 invoked from network); 28 Jul 2010 00:36:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 28 Jul 2010 00:36:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 27 Jul 2010 17:36:02 -0700 From: Eran Hammer-Lahav To: Dirk Balfanz , Nat Sakimura Date: Tue, 27 Jul 2010 17:36:10 -0700 Thread-Topic: [OAUTH-WG] OAuth Signature Thread-Index: Acst3/+W6ldu2uXFTny6yUeC+spfugADNgqw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EF903F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3EF903F7P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] OAuth Signature X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jul 2010 00:36:14 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EF903F7P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is someone going to turn this into an I-D anytime soon? EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= irk Balfanz Sent: Tuesday, July 27, 2010 4:04 PM To: Nat Sakimura Cc: oauth Subject: Re: [OAUTH-WG] OAuth Signature On Tue, Jul 27, 2010 at 3:35 PM, Nat Sakimura > wrote: On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz > wrote: > > > On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura > wrote: >> >> I have a fundamental question. >> >> While separating signature and payload by a dot "." seems ok, >> I still have not the answer for the question "why not make everything >> into JSON and base64url it?". >> >> i.e., Right now, you are proposing: >> >> base64url_encode(JSON(payload,envelope)).base64url_encode(signature) >> >> Why not >> >> base64url_encode(JSON(payload,envelope,signature) > > You need to say what exactly the signature is over. Presumably, it's over > some representation of the payload and envelope, but you need to specify > exactly which representation. So in this case you would have to say > something like "the signature is over the concatenation of the > base64-encodings of the JSON-encodings of the payload and envelope", or > something along those lines. If you did exactly this, then you would base= -64 > encode twice. Similar issues come up if you change the definition of what > the signature is over slightly. I did not spell out my question correctly. The pseudo code was very mislead= ing. By "JSON()" I was meaning something similar to magic signature json encodin= g or something similar because I was mainly comparing JSON Token and Magic Signature. Of course, that cannot be read from what I wrote. Sorry for that. My question is: "why not just use a profiled/modified version of Magic Signature" I think that's a fair question - in fact, I was sort of aiming for just tha= t. Once I get a free minute, I'll see whether there is a way to write this = as an MS profile... Dirk. I do not want to have two signature methods. If the currently proposed signature method can be unified with magic signat= ure, it would be great. > >> >> It probably is less hassle in terms of coding. (It is true that some >> parameters gets base64url encoded twice but > > How is encoding things twice "less hassle"? > >> >> BTW, some of the envelope parameters such as alg needs to be signed as >> well to thwart the algorithm replacing attack. > > Yes, of course. Remember that in the current proposal I don't have an > envelope - everything is in the payload. That's partly because I didn't w= ant > to decide what gets signed and what doesn't - everything is signed. Which= in > this case is easy (alternatively, I guess, you could just say that both t= he > envelope and the payload are signed). But it gets harder when you want to > encrypt the token. In this case you really need to leave some parts > unencrypted (so the recipient has _some_ information on how to decrypt th= e > thing) - presumably those parts would go into an envelope. > Dirk. > > >> >> -- >> Nat Sakimura (=3Dnat) >> http://www.sakimura.org/en/ >> http://twitter.com/_nat_en > > -- Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EF903F7P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is someon= e going to turn this into an I-D anytime soon?

 

EHL

 

From: oauth-bounces@ietf.or= g [mailto:oauth-bounces@ietf.org] On Behalf Of Dirk Balfanz
Se= nt: Tuesday, July 27, 2010 4:04 PM
To: Nat Sakimura
Cc:= oauth
Subject: Re: [OAUTH-WG] OAuth Signature

 

 

On Tue, Jul 27, 2010 at 3:35 PM, Nat Sakimura <sakimura@gmail.com> wrote:

On Wed, Jul 28, 2010 a= t 1:12 AM, Dirk Balfanz <balfanz@g= oogle.com> wrote:
>
>
> On Tue, Jul 27, 2010 at 12= :34 AM, Nat Sakimura <sakimura@gma= il.com> wrote:
>>
>> I have a fundamental question= .
>>
>> While separating signature and payload by a dot &= quot;." seems ok,
>> I still have not the answer for the ques= tion "why not make everything
>> into JSON and base64url it?&= quot;.
>>
>> i.e., Right now, you are proposing:
>&= gt;
>> base64url_encode(JSON(payload,envelope)).base64url_encode(s= ignature)
>>
>> Why not
>>
>> base64url= _encode(JSON(payload,envelope,signature)
>
> You need to say wh= at exactly the signature is over. Presumably, it's over
> some repres= entation of the payload and envelope, but you need to specify
> exact= ly which representation. So in this case you would have to say
> some= thing like "the signature is over the concatenation of the
> bas= e64-encodings of the JSON-encodings of the payload and envelope", or> something along those lines. If you did exactly this, then you would= base-64
> encode twice. Similar issues come up if you change the def= inition of what
> the signature is over slightly.

I did not spell out my question correctly. The pseudo= code was very misleading.
By "JSON()" I was meaning something= similar to magic signature json encoding
or something similar because I= was mainly comparing JSON Token and
Magic Signature.
Of course, that= cannot be read from what I wrote. Sorry for that.

My question is:"why not just use a profiled/modified version of Magic Signature&quo= t;

 

=

I think that's a fair question - in fact, I was sort o= f aiming for just that. Once I get a free minute, I'll see whether there is= a way to write this as an MS profile...

 

Dirk.

 


I d= o not want to have two signature methods.
If the currently proposed sign= ature method can be unified with magic signature,
it would be great.


>= ;
>>
>> It probably is less hassle in terms of coding. (I= t is true that some
>> parameters gets base64url encoded twice but=
>
> How is encoding things twice "less hassle"?
&= gt;
>>
>> BTW, some of the envelope parameters such as al= g needs to be signed as
>> well to thwart the algorithm replacing = attack.
>
> Yes, of course. Remember that in the current propos= al I don't have an
> envelope - everything is in the payload. That's = partly because I didn't want
> to decide what gets signed and what do= esn't - everything is signed. Which in
> this case is easy (alternati= vely, I guess, you could just say that both the
> envelope and the pa= yload are signed). But it gets harder when you want to
> encrypt the = token. In this case you really need to leave some parts
> unencrypted= (so the recipient has _some_ information on how to decrypt the
> thi= ng) - presumably those parts would go into an envelope.
> Dirk.
&g= t;
>
>>
>> --
>> Nat Sakimura (=3Dnat)
= >> http://w= ww.sakimura.org/en/
>> http://twitter.com/_nat_en
>
>

--

 <= /o:p>

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EF903F7P3PW5EX1MB01E_-- From sakimura@gmail.com Tue Jul 27 21:24: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 551EE3A681C for ; Tue, 27 Jul 2010 21:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xYXr+hMudeq4 for ; Tue, 27 Jul 2010 21:24:54 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B92133A6767 for ; Tue, 27 Jul 2010 21:24:53 -0700 (PDT) Received: by vws10 with SMTP id 10so4368298vws.31 for ; Tue, 27 Jul 2010 21:25:16 -0700 (PDT) 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=BKvgCcqKRB5uCR/p8KoTojeoMsVRc4QQIwTt73uO3cE=; b=HBsOIDHfFP3sx/2Vu5zucinPjOM1GyXazaNWl0CZfdNK3fJ5IjXsJup5CrgQL0lH1P jqX0iSQhxlxmFwcvyE1vunhmK6lMMYfQoAmg60fg5fKgEBP0dT9+3Vh7b1tC0gBA/w4U I0/rYeIY4HPgh01h4WdXJvYUH1kDswBYsG15E= 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=J7/uP0QOfgdQyDq8Y+D6EZw1ahSsLxRXy9vBV/SKjrXvoC9qHib91olwaDESEVzi64 Q4IePD8vFslFGVS4WATGNrRxL1oGSUFTTfwIYwrc3+nxYjWgf/NVn+iOK8DtZicgRArL 4pOLKAZZjgUKPTma4f8Q9XBNZlkKYIlZufFys= Received: by 10.220.122.1 with SMTP id j1mr5736077vcr.262.1280291115015; Tue, 27 Jul 2010 21:25:15 -0700 (PDT) Received: from [172.16.217.87] ([12.157.157.133]) by mx.google.com with ESMTPS id v11sm3831673vbb.3.2010.07.27.21.25.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 21:25:13 -0700 (PDT) References: <90C41DD21FB7C64BB94121FBBC2E72343B3EF903F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EF903F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPhone Mail 8A306) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1--811236608 Message-Id: <48ED6E89-637C-4A3B-87EC-36C800F39552@gmail.com> X-Mailer: iPhone Mail (8A306) From: Nat Date: Tue, 27 Jul 2010 21:25:54 -0700 To: Eran Hammer-Lahav Cc: oauth Subject: Re: [OAUTH-WG] OAuth Signature X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jul 2010 04:24:55 -0000 --Apple-Mail-1--811236608 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If nobody does, I could since this is one of the most crucial piece that I n= eed.=20 =3Dnat @ Tokyo via iPhone On 2010/07/27, at 17:36, Eran Hammer-Lahav wrote: > Is someone going to turn this into an I-D anytime soon? >=20 > =20 >=20 > EHL >=20 > =20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= irk Balfanz > Sent: Tuesday, July 27, 2010 4:04 PM > To: Nat Sakimura > Cc: oauth > Subject: Re: [OAUTH-WG] OAuth Signature >=20 > =20 >=20 > =20 >=20 > On Tue, Jul 27, 2010 at 3:35 PM, Nat Sakimura wrote: >=20 > On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz wrote: > > > > > > On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura wrot= e: > >> > >> I have a fundamental question. > >> > >> While separating signature and payload by a dot "." seems ok, > >> I still have not the answer for the question "why not make everything > >> into JSON and base64url it?". > >> > >> i.e., Right now, you are proposing: > >> > >> base64url_encode(JSON(payload,envelope)).base64url_encode(signature) > >> > >> Why not > >> > >> base64url_encode(JSON(payload,envelope,signature) > > > > You need to say what exactly the signature is over. Presumably, it's ove= r > > some representation of the payload and envelope, but you need to specify= > > exactly which representation. So in this case you would have to say > > something like "the signature is over the concatenation of the > > base64-encodings of the JSON-encodings of the payload and envelope", or > > something along those lines. If you did exactly this, then you would bas= e-64 > > encode twice. Similar issues come up if you change the definition of wha= t > > the signature is over slightly. >=20 > I did not spell out my question correctly. The pseudo code was very mislea= ding. > By "JSON()" I was meaning something similar to magic signature json encodi= ng > or something similar because I was mainly comparing JSON Token and > Magic Signature. > Of course, that cannot be read from what I wrote. Sorry for that. >=20 > My question is: > "why not just use a profiled/modified version of Magic Signature" >=20 > =20 >=20 > I think that's a fair question - in fact, I was sort of aiming for just th= at. Once I get a free minute, I'll see whether there is a way to write this a= s an MS profile... >=20 > =20 >=20 > Dirk. >=20 > =20 >=20 >=20 > I do not want to have two signature methods. > If the currently proposed signature method can be unified with magic signa= ture, > it would be great. >=20 >=20 > > > >> > >> It probably is less hassle in terms of coding. (It is true that some > >> parameters gets base64url encoded twice but > > > > How is encoding things twice "less hassle"? > > > >> > >> BTW, some of the envelope parameters such as alg needs to be signed as > >> well to thwart the algorithm replacing attack. > > > > Yes, of course. Remember that in the current proposal I don't have an > > envelope - everything is in the payload. That's partly because I didn't w= ant > > to decide what gets signed and what doesn't - everything is signed. Whic= h in > > this case is easy (alternatively, I guess, you could just say that both t= he > > envelope and the payload are signed). But it gets harder when you want t= o > > encrypt the token. In this case you really need to leave some parts > > unencrypted (so the recipient has _some_ information on how to decrypt t= he > > thing) - presumably those parts would go into an envelope. > > Dirk. > > > > > >> > >> -- > >> Nat Sakimura (=3Dnat) > >> http://www.sakimura.org/en/ > >> http://twitter.com/_nat_en > > > > >=20 >=20 >=20 > -- >=20 > Nat Sakimura (=3Dnat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en >=20 > =20 --Apple-Mail-1--811236608 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
If nobody does, I could since this is o= ne of the most crucial piece that I need. 

=3Dnat @ Tokyo via iP= hone

On 2010/07/27, at 17:36, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Is someone going to turn this in= to an I-D anytime soon?

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org= ] On Behalf Of Dirk Balfanz
Sent: Tuesday, July 27, 2010 4:= 04 PM
To: Nat Sakimura
Cc: oauth
Subject: Re: [= OAUTH-WG] OAuth Signature

 

 

On Tue, Jul 27, 2010 a= t 3:35 PM, Nat Sakimura <sakimura@gmail.com> wrote:=

On Wed, Jul 2= 8, 2010 at 1:12 AM, Dirk Balfanz <<= a href=3D"mailto:balfanz@google.com">balfanz@google.com> wrote:>
>
> On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura <sa= kimura@gmail.com> wrote:
>>
>> I have a fundame= ntal question.
>>
>> While separating signature and payloa= d by a dot "." seems ok,
>> I still have not the answer for the que= stion "why not make everything
>> into JSON and base64url it?".
= >>
>> i.e., Right now, you are proposing:
>>
>= > base64url_encode(JSON(payload,envelope)).base64url_encode(signature)>>
>> Why not
>>
>> base64url_encode(JSON(= payload,envelope,signature)
>
> You need to say what exactly the= signature is over. Presumably, it's over
> some representation of the= payload and envelope, but you need to specify
> exactly which represe= ntation. So in this case you would have to say
> something like "the s= ignature is over the concatenation of the
> base64-encodings of the JS= ON-encodings of the payload and envelope", or
> something along those l= ines. If you did exactly this, then you would base-64
> encode twice. S= imilar issues come up if you change the definition of what
> the signa= ture is over slightly.

I did not s= pell out my question correctly. The pseudo code was very misleading.
By "= JSON()" I was meaning something similar to magic signature json encoding
= or something similar because I was mainly comparing JSON Token and
Magic S= ignature.
Of course, that cannot be read from what I wrote. Sorry for tha= t.

My question is:
"why not just use a profiled/modified version o= f Magic Signature"

 

I think that's a fair question - in f= act, I was sort of aiming for just that. Once I get a free minute, I'll see w= hether there is a way to write this as an MS profile...

=

 

Dirk.

 


I do not want to have two signature methods.
If the current= ly proposed signature method can be unified with magic signature,
it woul= d be great.


>
>>
>> It probably is less hassle in term= s of coding. (It is true that some
>> parameters gets base64url enc= oded twice but
>
> How is encoding things twice "less hassle"?>
>>
>> BTW, some of the envelope parameters such as a= lg needs to be signed as
>> well to thwart the algorithm replacing a= ttack.
>
> Yes, of course. Remember that in the current proposal= I don't have an
> envelope - everything is in the payload. That's par= tly because I didn't want
> to decide what gets signed and what doesn'= t - everything is signed. Which in
> this case is easy (alternatively,= I guess, you could just say that both the
> envelope and the payload a= re signed). But it gets harder when you want to
> encrypt the token. I= n this case you really need to leave some parts
> unencrypted (so the r= ecipient has _some_ information on how to decrypt the
> thing) - presu= mably those parts would go into an envelope.
> Dirk.
>
>>>
>> --
>> Nat Sakimura (=3Dnat)
>> http://www.sakimura.org/en/
>> http://twitter.com/_nat_en
>
>


--

&n= bsp;

= --Apple-Mail-1--811236608-- From sakimura@gmail.com Tue Jul 27 21:26: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 EBF7E3A6869 for ; Tue, 27 Jul 2010 21:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Acj9jG0xHhZR for ; Tue, 27 Jul 2010 21:26:56 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 404FC3A681C for ; Tue, 27 Jul 2010 21:26:56 -0700 (PDT) Received: by vws10 with SMTP id 10so4369423vws.31 for ; Tue, 27 Jul 2010 21:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:references:from :content-type:x-mailer:in-reply-to:message-id:date:cc :content-transfer-encoding:mime-version; bh=bsD3IFaQ4jC/M0ZlPgRFtpzrgoiP53iKhkwX/MD5FtA=; b=sIMks+FoxX8w0JkqS+FE9tqEm7nib2DUEZ+zYyVVoPonfv8JbNBNRsDvxwh4+i2KWW Mot9q00VNtZ4Bjf4pnWXFlZKQjJliUtS3XdbHD9HHquaIUmHf8Bsya1Mt8vleiRU+eL7 LnGx/ybOqbRXGdTDbyMbybesZ38Uo2CmqaOyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:cc:content-transfer-encoding:mime-version; b=IiNVh6Zht4MTsO5exFVyN7VwYiLT49h9Dp/34szP+tPCyDBI/sxAuLlfXUBIrKwoDW q/k2RDvvQNYCQ9zY0ydGHbpc2rPARBQDAjENhhls3GhZUHz7A3bLZ2s8zZO25ud6jEmO KDhjBqaJGfOZxEMAOrD4p8qwp0ZcgYDeernak= Received: by 10.220.89.212 with SMTP id f20mr5732449vcm.120.1280291235746; Tue, 27 Jul 2010 21:27:15 -0700 (PDT) Received: from [172.16.217.87] ([12.157.157.133]) by mx.google.com with ESMTPS id v11sm3834599vbb.3.2010.07.27.21.27.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 21:27:14 -0700 (PDT) References: <90C41DD21FB7C64BB94121FBBC2E72343B3EF903F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Nat Content-Type: multipart/alternative; boundary=Apple-Mail-2--811114340 X-Mailer: iPhone Mail (8A306) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EF903F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-Id: <763AD7DB-CBC1-4D2B-BE20-7092CE144367@gmail.com> Date: Tue, 27 Jul 2010 21:27:56 -0700 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 8A306) Cc: oauth Subject: Re: [OAUTH-WG] OAuth Signature X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jul 2010 04:26:58 -0000 --Apple-Mail-2--811114340 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If nobody does, I could since this is one of the most crucial piece that I n= eed.=20 =3Dnat @ Tokyo via iPhone On 2010/07/27, at 17:36, Eran Hammer-Lahav wrote: > Is someone going to turn this into an I-D anytime soon? >=20 > =20 >=20 > EHL >=20 > =20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= irk Balfanz > Sent: Tuesday, July 27, 2010 4:04 PM > To: Nat Sakimura > Cc: oauth > Subject: Re: [OAUTH-WG] OAuth Signature >=20 > =20 >=20 > =20 >=20 > On Tue, Jul 27, 2010 at 3:35 PM, Nat Sakimura wrote: >=20 > On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz wrote: > > > > > > On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura wrot= e: > >> > >> I have a fundamental question. > >> > >> While separating signature and payload by a dot "." seems ok, > >> I still have not the answer for the question "why not make everything > >> into JSON and base64url it?". > >> > >> i.e., Right now, you are proposing: > >> > >> base64url_encode(JSON(payload,envelope)).base64url_encode(signature) > >> > >> Why not > >> > >> base64url_encode(JSON(payload,envelope,signature) > > > > You need to say what exactly the signature is over. Presumably, it's ove= r > > some representation of the payload and envelope, but you need to specify= > > exactly which representation. So in this case you would have to say > > something like "the signature is over the concatenation of the > > base64-encodings of the JSON-encodings of the payload and envelope", or > > something along those lines. If you did exactly this, then you would bas= e-64 > > encode twice. Similar issues come up if you change the definition of wha= t > > the signature is over slightly. >=20 > I did not spell out my question correctly. The pseudo code was very mislea= ding. > By "JSON()" I was meaning something similar to magic signature json encodi= ng > or something similar because I was mainly comparing JSON Token and > Magic Signature. > Of course, that cannot be read from what I wrote. Sorry for that. >=20 > My question is: > "why not just use a profiled/modified version of Magic Signature" >=20 > =20 >=20 > I think that's a fair question - in fact, I was sort of aiming for just th= at. Once I get a free minute, I'll see whether there is a way to write this a= s an MS profile... >=20 > =20 >=20 > Dirk. >=20 > =20 >=20 >=20 > I do not want to have two signature methods. > If the currently proposed signature method can be unified with magic signa= ture, > it would be great. >=20 >=20 > > > >> > >> It probably is less hassle in terms of coding. (It is true that some > >> parameters gets base64url encoded twice but > > > > How is encoding things twice "less hassle"? > > > >> > >> BTW, some of the envelope parameters such as alg needs to be signed as > >> well to thwart the algorithm replacing attack. > > > > Yes, of course. Remember that in the current proposal I don't have an > > envelope - everything is in the payload. That's partly because I didn't w= ant > > to decide what gets signed and what doesn't - everything is signed. Whic= h in > > this case is easy (alternatively, I guess, you could just say that both t= he > > envelope and the payload are signed). But it gets harder when you want t= o > > encrypt the token. In this case you really need to leave some parts > > unencrypted (so the recipient has _some_ information on how to decrypt t= he > > thing) - presumably those parts would go into an envelope. > > Dirk. > > > > > >> > >> -- > >> Nat Sakimura (=3Dnat) > >> http://www.sakimura.org/en/ > >> http://twitter.com/_nat_en > > > > >=20 >=20 >=20 > -- >=20 > Nat Sakimura (=3Dnat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en >=20 > =20 --Apple-Mail-2--811114340 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
If nobody does, I could= since this is one of the most crucial piece that I need. 
=3Dnat @ Tokyo via iPhone

On 2010/07/27, at 17:36, Eran Hamm= er-Lahav <eran@hueniverse.com&= gt; wrote:

Is someon= e going to turn this into an I-D anytime soon?

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oau= th-bounces@ietf.org] On Behalf Of Dirk Balfanz
Sent: Tuesda= y, July 27, 2010 4:04 PM
To: Nat Sakimura
Cc: oauth
<= b>Subject: Re: [OAUTH-WG] OAuth Signature

 

 

On T= ue, Jul 27, 2010 at 3:35 PM, Nat Sakimura <sakimura@gmail.com>= wrote:

On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz <balfanz@google.com> wrote:
>
>
> On Tue, Jul 27, 2010 at 12:34 AM, N= at Sakimura <sakimura@gmail.com> wrote:
>>
>>= ; I have a fundamental question.
>>
>> While separating si= gnature and payload by a dot "." seems ok,
>> I still have not the a= nswer for the question "why not make everything
>> into JSON and ba= se64url it?".
>>
>> i.e., Right now, you are proposing:>>
>> base64url_encode(JSON(payload,envelope)).base64url_enc= ode(signature)
>>
>> Why not
>>
>> base6= 4url_encode(JSON(payload,envelope,signature)
>
> You need to say= what exactly the signature is over. Presumably, it's over
> some repr= esentation of the payload and envelope, but you need to specify
> exac= tly which representation. So in this case you would have to say
> some= thing like "the signature is over the concatenation of the
> base64-en= codings of the JSON-encodings of the payload and envelope", or
> somet= hing along those lines. If you did exactly this, then you would base-64
&= gt; encode twice. Similar issues come up if you change the definition of wha= t
> the signature is over slightly.

I did not spell out my question correctly. The pseudo code was very= misleading.
By "JSON()" I was meaning something similar to magic signatu= re json encoding
or something similar because I was mainly comparing JSON= Token and
Magic Signature.
Of course, that cannot be read from what I= wrote. Sorry for that.

My question is:
"why not just use a profil= ed/modified version of Magic Signature"

 

I think that's a= fair question - in fact, I was sort of aiming for just that. Once I get a f= ree minute, I'll see whether there is a way to write this as an MS profile..= .

 

Dirk.

 


I do not want to have two signature meth= ods.
If the currently proposed signature method can be unified with magic= signature,
it would be great.


>
>>
>> It probably i= s less hassle in terms of coding. (It is true that some
>> paramete= rs gets base64url encoded twice but
>
> How is encoding things t= wice "less hassle"?
>
>>
>> BTW, some of the envelop= e parameters such as alg needs to be signed as
>> well to thwart th= e algorithm replacing attack.
>
> Yes, of course. Remember that i= n the current proposal I don't have an
> envelope - everything is in t= he payload. That's partly because I didn't want
> to decide what gets s= igned and what doesn't - everything is signed. Which in
> this case is= easy (alternatively, I guess, you could just say that both the
> enve= lope and the payload are signed). But it gets harder when you want to
>= ; encrypt the token. In this case you really need to leave some parts
>= ; unencrypted (so the recipient has _some_ information on how to decrypt the=
> thing) - presumably those parts would go into an envelope.
> D= irk.
>
>
>>
>> --
>> Nat Sakimura (=3D= nat)
>> <= a href=3D"http://www.sakimura.org/en/">http://www.sakimura.org/en/>> http://twitter.com/_nat_en
>
&= gt;


--

=

 

= --Apple-Mail-2--811114340-- From torsten@lodderstedt.net Tue Jul 27 23:42:06 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F5F3A67E6 for ; Tue, 27 Jul 2010 23:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=0.698, 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 KyMuH6F6MPqt for ; Tue, 27 Jul 2010 23:42:05 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by core3.amsl.com (Postfix) with ESMTP id 345283A67F9 for ; Tue, 27 Jul 2010 23:42:04 -0700 (PDT) Received: from [84.26.84.97] (helo=[192.168.1.47]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Oe0LR-0007sT-IO; Wed, 28 Jul 2010 08:42:25 +0200 References: <4C432262.40204@lodderstedt.net> <4C48BAA6.8050702@lodderstedt.net> <66D3B03F-544A-4EEB-8AA7-137165BF1BBE@salesforce.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <86B9BEA8-3237-4404-9D04-FEEC93389ADE@lodderstedt.net> X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Wed, 28 Jul 2010 08:41:45 +0200 To: Brian Eaton X-Df-Sender: 141509 Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jul 2010 06:42:06 -0000 Am 28.07.2010 um 01:40 schrieb Brian Eaton : > On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell > wrote: >> There seem to be two potential arguments against it - the burden of >> tracking the state and the potential that it's unnecessarily >> restrictive. I don't personally see either as being a major issue but >> would like to hear from folks if they feel differently. I could >> change the language from a MUST to a SHOULD or MAY to allow for more >> flexibility at deployment/development time? That would slightly >> increase the opportunity for interop problems but I don't think it's >> really much of a concern. > > MAY seems reasonable to me. +1 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Wed Jul 28 01:23: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 D644328C106 for ; Wed, 28 Jul 2010 01:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYL9NjU7rZKN for ; Wed, 28 Jul 2010 01:23:38 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id 6C8443A67A4 for ; Wed, 28 Jul 2010 01:23:36 -0700 (PDT) Received: from dhcp-87ec.meeting.ietf.org ([130.129.135.236] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Oe1vi-0007P2-FQ; Wed, 28 Jul 2010 10:23:58 +0200 Message-ID: <4C4FE913.9030508@lodderstedt.net> Date: Wed, 28 Jul 2010 10:23:47 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Andrew Arnott References: <4C3F3F6A.5000409@lodderstedt.net> <4C3F9064.6060604@lodderstedt.net> <4C48C116.9000609@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060508000708030408070607" X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jul 2010 08:23:39 -0000 This is a multi-part message in MIME format. --------------060508000708030408070607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit thanks for sharing your thoughts. Differentiating resource servers by using different end-user authorization endpoint URLs is an option. I dont't know how this will work in conjunction with discovery, especially since this differentiation might by required on other endpoints, too. For example, if a client wants to obtain an access token for the end-user's credentials, it has to identify the resource server also on the tokens endpoint. There might be additional endpoint for other flows with similar requirements, e.g. the device flow. Based on your proposal, a derived solution could be to define a standard parameter "resourceserver" and to state how clients should use this parameter on the different endpoints. On the coding level, there would be no difference to your proposal :-) But the client would be able to construct such a URL on its own. Authorizing access for different resource servers is indeed an issue for me. How would you propose to add the namespace? Shall the scope obtained from the resource server already contain such a namespace are shall there be a rule to construct such namespaced-ed scopes in the spec? regards, Torsten. Am 25.07.2010 19:11, schrieb Andrew Arnott: > It seems to me that if one auth server can create tokens for a diverse > set of resource servers, then why not have different user > authorization endpoint URLs for each type of resource server, as an > added differentiator for the scope (a namespace, if you will)? > > So suppose one auth server serves two different photo services, both > using overlapping scopes such that a client requesting access of some > scope is otherwise ambiguous between which resource server the client > needs access to. The auth server that serves both resource servers > could have two end user authorization endpoints: > http://auth.server.org/authorize?resourceserver=1 > http://auth.server.org/authorize?resourceserver=2 > > And that way the auth server knows exactly what the client needs. > > The only scenario this doesn't allow for is for a user to authorize a > client's access to /both/ resource servers in one redirect. If this > were an issue, perhaps you can apply a namespace-like prefix to each > scope substring: > > rs1:photo:read rs2:photo:read > > Which would serve a similar purpose. > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the > death your right to say it." - S. G. Tallentyre > > > On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt > > wrote: > > no one else in the group having an opinion on this topic? > > > > Am 15.07.2010 20:14, schrieb Marius Scurtescu: > > On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt > > > wrote: > > As I have written in my reply to Marius's posting. I'm > fine with including > server ids in scopes. But this requires a definition > of the scope's syntax > and semantics in the spec. Otherwise, scope > interpretation (and server > identification) will be deployment specific. > > Sure, it is deployment specific, but why is that an issue? > > In your case, the authz server and all the resource > servers are > managed by the same organization, right? > > Do clients need to be aware of the actual resource server? > > You can probably create a separate spec that defines scope > syntax for > this purpose, if really needed. Does it have to be in core? > > Marius > > > Solving the challenge I described in a deployment specific way > is not an issue. But the consequence is that authz server, > resource servers and clients are tight together. > > Let me ask you one question: Why are we working together > towards a standard protocol? I can tell you my expectations: I > hope there will be broad support not only by libraries, but > also by ready-to-use services and clients, so we could > integrate such services into our deployment easily. Moreover, > I would like to see OAuth to be included in > application/service protocols like PortableContacts, SIP, > WebDAV, IMAP, ... > > So what if I would like to use standard clients to access our > services? Using scopes for specifying resource server id's in > this case is also simple - if you take an isolated view. But > since scopes may be used to specifiy a lot of other things, > like resources, permissions, and durations, handling w/o a > more detailed spec will in practice be impossible. > > Suppose a WebDAV service for media data access. Any WebDAV > client knows the WebDAV protocol (== interface), e.g. the > supported methods (GET, PUT, POST, DELETE, COPY, MOVE) and how > to traverse directories. So it is sufficient to configure the > client with the URL of my personal web storage. To start with > let's assume, scopes are used to designate resource servers > only. So the server's scope could be "webstorage". > > WWW-Authenticate OAuth realm='webstorage' scope="webstorage" > > The client could just pass this parameter to the authz server > and everything is fine. > > On the next level, let's assume the (future) WebDAV standard > with OAuth-support uses one permission per method type. So the > full scope could be as follows: > > WWW-Authenticate OAuth realm='webstorage' > scope="webstorage:GET webstorage:PUT webstorage:POST > webstorage:DELETE webstorage:COPY webstorage:MOVE" > > Passing this scope w/o any unmodified to the authz server is > not an issue. But this implies the client asks for full access > to the users media storage. Since our client is a gallery > application, it requires the "GET" permission only. How does > the client know which of the scope values to pick for the > end-user authorization process? It must somehow select > "webstorage:GET". > > But how? > > In my personal opinion, clients should be enabled to > interpret, combine and even create scopes. And yes, this > should go to the core of the spec. > > regards, > Torsten. > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --------------060508000708030408070607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit thanks for sharing your thoughts.

Differentiating resource servers by using different end-user authorization endpoint URLs is an option. I dont't know how this will work in conjunction with discovery, especially since this differentiation might by required on other endpoints, too. For example, if a client wants to obtain an access token for the end-user's credentials, it has to identify the resource server also on the tokens endpoint. There might be additional endpoint for other flows with similar requirements, e.g. the device flow.

Based on your proposal, a derived solution could be to define a standard parameter "resourceserver" and to state how clients should use this parameter on the different endpoints. On the coding level, there would be no difference to your proposal :-) But the client would be able to construct such a URL on its own.

Authorizing access for different resource servers is indeed an issue for me. How would you propose to add the namespace? Shall the scope obtained from the resource server already contain such a namespace are shall there be a rule to construct such namespaced-ed scopes in the spec?

regards,
Torsten.

Am 25.07.2010 19:11, schrieb Andrew Arnott:
It seems to me that if one auth server can create tokens for a diverse set of resource servers, then why not have different user authorization endpoint URLs for each type of resource server, as an added differentiator for the scope (a namespace, if you will)?

So suppose one auth server serves two different photo services, both using overlapping scopes such that a client requesting access of some scope is otherwise ambiguous between which resource server the client needs access to.  The auth server that serves both resource servers could have two end user authorization endpoints:

And that way the auth server knows exactly what the client needs.

The only scenario this doesn't allow for is for a user to authorize a client's access to both resource servers in one redirect.  If this were an issue, perhaps you can apply a namespace-like prefix to each scope substring:

rs1:photo:read rs2:photo:read

Which would serve a similar purpose.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre


On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
no one else in the group having an opinion on this topic?



Am 15.07.2010 20:14, schrieb Marius Scurtescu:
On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
<torsten@lodderstedt.net>  wrote:
As I have written in my reply to Marius's posting. I'm fine with including
server ids in scopes. But this requires a definition of the scope's syntax
and semantics in the spec. Otherwise, scope interpretation (and server
identification) will be deployment specific.
Sure, it is deployment specific, but why is that an issue?

In your case, the authz server and all the resource servers are
managed by the same organization, right?

Do clients need to be aware of the actual resource server?

You can probably create a separate spec that defines scope syntax for
this purpose, if really needed. Does it have to be in core?

Marius

Solving the challenge I described in a deployment specific way is not an issue. But the consequence is that authz server, resource servers and clients are tight together.

Let me ask you one question: Why are we working together towards a standard protocol? I can tell you my expectations: I hope there will be broad support not only by libraries, but also by ready-to-use services and clients, so we could integrate such services into our deployment easily. Moreover, I would like to see OAuth to be included in application/service protocols like PortableContacts, SIP, WebDAV, IMAP, ...

So what if I would like to use standard clients to access our services? Using scopes for specifying resource server id's in this case is also simple - if you take an isolated view. But since scopes may be used to specifiy a lot of other things, like resources, permissions, and durations, handling w/o a more detailed spec will in practice be impossible.

Suppose a WebDAV service for media data access. Any WebDAV client knows the WebDAV protocol (== interface), e.g. the supported methods (GET, PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. So it is sufficient to configure the client with the URL of my personal web storage. To start with let's assume, scopes are used to designate resource servers only. So the server's scope could be "webstorage".

   WWW-Authenticate OAuth realm='webstorage' scope="webstorage"

The client could just pass this parameter to the authz server and everything is fine.

On the next level, let's assume the (future) WebDAV standard with OAuth-support uses one permission per method type. So the full scope could be as follows:

   WWW-Authenticate OAuth realm='webstorage' scope="webstorage:GET webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY webstorage:MOVE"

Passing this scope w/o any unmodified to the authz server is not an issue. But this implies the client asks for full access to the users media storage. Since our client is a gallery application, it requires the "GET" permission only. How does the client know which of the scope values to pick for the end-user authorization process? It must somehow select "webstorage:GET".

But how?

In my personal opinion, clients should be enabled to interpret, combine and even create scopes. And yes, this should go to the core of the spec.

regards,
Torsten.




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

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

--------------060508000708030408070607-- From igor.faynberg@alcatel-lucent.com Wed Jul 28 03:06:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12DF03A6A65 for ; Wed, 28 Jul 2010 03:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 xWQgoIMm-yA5 for ; Wed, 28 Jul 2010 03:06:19 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id EF4BA3A6A53 for ; Wed, 28 Jul 2010 03:06:18 -0700 (PDT) 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 o6SA6Zhv012833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jul 2010 05:06:37 -0500 (CDT) Received: from [135.244.20.108] (faynberg.lra.lucent.com [135.244.20.108]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o6SA6PRD010761; Wed, 28 Jul 2010 05:06:27 -0500 (CDT) Message-ID: <4C500120.8060609@alcatel-lucent.com> Date: Wed, 28 Jul 2010 06:06:24 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Torsten Lodderstedt References: <4C432262.40204@lodderstedt.net> <4C48BAA6.8050702@lodderstedt.net> <66D3B03F-544A-4EEB-8AA7-137165BF1BBE@salesforce.com> <86B9BEA8-3237-4404-9D04-FEEC93389ADE@lodderstedt.net> In-Reply-To: <86B9BEA8-3237-4404-9D04-FEEC93389ADE@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 10:06:20 -0000 +1 on MAY; (+0.3 on SHOULD). Igor Torsten Lodderstedt wrote: > Am 28.07.2010 um 01:40 schrieb Brian Eaton : > > >> On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell >> wrote: >> >>> There seem to be two potential arguments against it - the burden of >>> tracking the state and the potential that it's unnecessarily >>> restrictive. I don't personally see either as being a major issue but >>> would like to hear from folks if they feel differently. I could >>> change the language from a MUST to a SHOULD or MAY to allow for more >>> flexibility at deployment/development time? That would slightly >>> increase the opportunity for interop problems but I don't think it's >>> really much of a concern. >>> >> MAY seems reasonable to me. >> > > +1 > > >> _______________________________________________ >> 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 Wed Jul 28 04:01: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 95C5D28C153 for ; Wed, 28 Jul 2010 04:01:51 -0700 (PDT) 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=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-3ActITXmSp for ; Wed, 28 Jul 2010 04:01:50 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id 3CD0028C128 for ; Wed, 28 Jul 2010 04:01:49 -0700 (PDT) Received: from source ([74.125.82.45]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTFAOM1cNb1BKLHhoTYx7fJSClRsKF8BQ@postini.com; Wed, 28 Jul 2010 04:02:13 PDT Received: by mail-ww0-f45.google.com with SMTP id 26so2104261wwf.26 for ; Wed, 28 Jul 2010 04:02:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.1.208 with SMTP id 58mr10420075wed.22.1280314929728; Wed, 28 Jul 2010 04:02:09 -0700 (PDT) Received: by 10.216.71.5 with HTTP; Wed, 28 Jul 2010 04:02:09 -0700 (PDT) Received: by 10.216.71.5 with HTTP; Wed, 28 Jul 2010 04:02:09 -0700 (PDT) In-Reply-To: References: <4C432262.40204@lodderstedt.net> <4C48BAA6.8050702@lodderstedt.net> <66D3B03F-544A-4EEB-8AA7-137165BF1BBE@salesforce.com> <86B9BEA8-3237-4404-9D04-FEEC93389ADE@lodderstedt.net> <4C500120.8060609@alcatel-lucent.com> Date: Wed, 28 Jul 2010 05:02:09 -0600 Message-ID: From: Brian Campbell To: igor.faynberg@alcatel-lucent.com Content-Type: multipart/alternative; boundary=00163683302a964fff048c708ca0 Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jul 2010 11:01:51 -0000 --00163683302a964fff048c708ca0 Content-Type: text/plain; charset=ISO-8859-1 MAY it is. Thanks On Jul 28, 2010 4:06 AM, "Igor Faynberg" wrote: +1 on MAY; (+0.3 on SHOULD). Igor Torsten Lodderstedt wrote: > > Am 28.07.2010 um 01:40 schrieb Brian Eaton : > >... --00163683302a964fff048c708ca0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

MAY it is.=A0 Thanks

On Jul 28, 2010 4:06 AM, "Igor Faynberg&q= uot; <igor.faynberg@= alcatel-lucent.com> wrote:

+1 on MAY; =A0(+0.3 on SHOULD).
Igor



Torsten Lodderstedt wrote:>
> Am 28.07.2010 um 01:40 schrieb Brian Eaton <beaton@google.com>:
>
>...=

--00163683302a964fff048c708ca0-- From balfanz@google.com Wed Jul 28 09:27:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80BC428C192 for ; Wed, 28 Jul 2010 09:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.876 X-Spam-Level: X-Spam-Status: No, score=-105.876 tagged_above=-999 required=5 tests=[AWL=0.100, 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 l0uiQdNGljfB for ; Wed, 28 Jul 2010 09:27:19 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C2E483A6969 for ; Wed, 28 Jul 2010 09:27:18 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o6SGRfDo018488 for ; Wed, 28 Jul 2010 09:27:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280334461; bh=JXZT3aS0bSNQu8dHTSHFLxI2X5w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=UVN6MF1Uy+dh4wbLrcBpj4eyvjtlMmzkOqenj8vEuxxtvKmN31p1rsnm8hiELHCCV 9+MKpEcOE82pBBaFyRxMA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=GNTsMTGXboEuJOemMfEqqqcF3fc/ltINORpwv/Iy9m/ifxTARVIWoxfF2l+pFakpz LxwM+RBKy7+idWT//j9bg== Received: from ywg8 (ywg8.prod.google.com [10.192.7.8]) by wpaz17.hot.corp.google.com with ESMTP id o6SGR8Eh029307 for ; Wed, 28 Jul 2010 09:27:40 -0700 Received: by ywg8 with SMTP id 8so1132536ywg.14 for ; Wed, 28 Jul 2010 09:27:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.68.16 with SMTP id q16mr8207751aga.0.1280334459804; Wed, 28 Jul 2010 09:27:39 -0700 (PDT) Received: by 10.231.130.9 with HTTP; Wed, 28 Jul 2010 09:27:39 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Jul 2010 09:27:39 -0700 Message-ID: From: Dirk Balfanz To: Nat Sakimura Content-Type: multipart/alternative; boundary=00163613a328ab9dbf048c7518a6 X-System-Of-Record: true Cc: oauth Subject: Re: [OAUTH-WG] On the discovery of the OAuth Signature X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jul 2010 16:27:20 -0000 --00163613a328ab9dbf048c7518a6 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 27, 2010 at 4:31 PM, Nat Sakimura wrote: > Hi. > > Currently, the discovery document would have something like: > > { > "verification_keys": { > "key1":"RSA.ALqcwR...", > "key2":"X509. > } > } > > It defines RSA and X509. Could we define a third type "certs_url" that > points to the > file that stores PEM format certificates (chain as well)? > I'm a bit hesitant to add more formats, since the client libraries would have to support all of them. I'd be more comfortable actually replacing, say, the X509. version with this indirection. One question, though: in my proposal, I'm saying that the validity of the public key is controlled by the caching directives of this document. I.e., if you fetch this document, it has a key in it, and it says "you can cache this for 24 hours", then it's ok to use the public keys in there for the next 24 hours. If you use self-signed certs (the X509. version), you're supposed to ignore the not-before and not-after fields in there. How does that work for this additional level of indirection? Let's say the "server info" document is cacheable for 10 hours, the PEM you download from there says that it can be cached for 24 hours, and the not-after field in the cert says that it's valid for another week. Which of those takes precedence? Dirk. > > =nat > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > --00163613a328ab9dbf048c7518a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 27, 2010 at 4:31 PM, Nat Sak= imura <sakimura@= gmail.com> wrote:
Hi.

Currently, the discovery document would have something like:

{
=A0 =A0 =A0 =A0"verification_keys": =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"key1":"RSA.ALqcwR...",=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"key2":"X509.<certificate= >
=A0 =A0 =A0 =A0}
}

It defines RSA and X509. Could we define a third type "certs_url"= that
points to the
file that stores PEM format certificates (chain as well)?
<= div>
I'm a bit hesitant to add more formats, since the cl= ient libraries would have to support all of them. I'd be more comfortab= le actually replacing, say, the X509.<certificate> version with this = indirection.=A0

One question, though: in my proposal, I'm saying th= at the validity of the public key is controlled by the caching directives o= f this document. I.e., if you fetch this document, it has a key in it, and = it says "you can cache this for 24 hours", then it's ok to us= e the public keys in there for the next 24 hours. If you use self-signed ce= rts (the X509.<certificate> version), you're supposed to ignore t= he not-before and not-after fields in there. How does that work for this ad= ditional level of indirection? Let's say the "server info" do= cument is cacheable for 10 hours, the PEM you download from there says that= it can be cached for 24 hours, and the not-after field in the cert says th= at it's valid for another week. Which of those takes=A0precedence?

Dirk.
=A0

--
Nat Sakimura (=3Dnat)
http://www.sakimu= ra.org/en/
http://twitter.com= /_nat_en

--00163613a328ab9dbf048c7518a6-- From paul.tarjan@facebook.com Wed Jul 28 12:37: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 490373A68A9 for ; Wed, 28 Jul 2010 12:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN7ckksj+dUt for ; Wed, 28 Jul 2010 12:37:04 -0700 (PDT) Received: from mx-out.facebook.com (outmail002.ash1.tfbnw.net [69.63.184.102]) by core3.amsl.com (Postfix) with ESMTP id 26FBF3A6952 for ; Wed, 28 Jul 2010 12:37:04 -0700 (PDT) Received: from [10.18.255.131] ([10.18.255.131:10174] helo=mail.thefacebook.com) by mta007.ash1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 4A/B7-01074-394805C4; Wed, 28 Jul 2010 12:27:16 -0700 Received: from SC-MBX04.TheFacebook.com ([169.254.3.239]) by sc-hub03.TheFacebook.com ([fe80::1cfe:1f6b:8b35:cf7f%11]) with mapi; Wed, 28 Jul 2010 12:27:15 -0700 From: Paul Tarjan To: Nat Sakimura Thread-Topic: [OAUTH-WG] Facebook's experience with OAuth2.0 signatures Thread-Index: AQHLLlQ4R4ZrwnMX20avFqAnWxwWmZLHLnCA Date: Wed, 28 Jul 2010 19:27:11 +0000 Message-ID: <5CAAB672-33F6-494D-98A3-5E167AFB9273@facebook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_5CAAB67233F6494D98A35E167AFB9273facebookcom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Facebook's experience with OAuth2.0 signatures X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jul 2010 19:37:06 -0000 --_000_5CAAB67233F6494D98A35E167AFB9273facebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From http://developers.facebook.com/docs/authentication/canvas Why is the signature first? Doing a left split is usually easier than a right one. It also allows us to= pursue other encodings, like hex for the signature and percent encoding fo= r the payload. Why is it called signed_request? It's the part of the HTTP request that is signed. You can remember the sign= ature comes first in both the name of the parameter and the parameter itsel= f. :) Paul On Jul 27, 2010, at 4:10 PM, Nat Sakimura wrote: Thanks for sharing! One question: Was there a particular reason for having signature first instead of the payload? On Tue, Jul 27, 2010 at 7:18 AM, Paul Tarjan > wrote: Facebook released an early version of the proposed signature method, with t= he aim of getting real-life implementation experience. We are not currently= using this for protected resource requests, but rather more like if the au= thorization server returned signed data as part of the access token respons= e. It was generally a success with many people really liking the scheme. Our main takeaway is that MANY developers used normal base64 instead of bas= e64url encoding either because they didn't read the spec thoroughly or just= recognized the scheme and started decoding it. This caused weird errors wh= ich they weren't ready for (sometimes working when - and _ weren't present,= sometimes cutting off some json characters when their language needed padd= ing =3D, etc). We created an open source set of examples that developers have found helpfu= l, and which could be incorporated into the OAuth example set: http://githu= b.com/ptarjan/base64url So, I suggest to keep the signature scheme, but message the fact that it is= n't normal base64 VERY loudly and clearly in the spec, and to use examples = that will fail hard with normal base64. Our implementation followed the OAuth2.0 signature scheme except for 4 chan= ges: * signature came before payload * not_after was renamed expires * not all required parameters were present given the difference in use case * the parameter was called signed_request instead of signed_token You can read our docs here: http://developers.facebook.com/docs/authenticat= ion/canvas Here is a few snippets of developer feedback that we had about them not und= erstanding to use base64url instead of base64 encoding: --- We're seeing bogus JSON in the new parameter. It looks like a few ch= aracters are being left off the end. --- Imcompatible Base64 Encoding between PHP and Java (sun.misc.Base64En= coder) The problem was, I get an extra byte at the end of the Base64 Decode= d Sig, comparing to the result I got from Hashing the Payload with my app s= ecret. My guess is that PHP is not encoding base64 strictly following the B= ase64 convention, or, Facebook has removed the tailing "=3D" from Sig whic= h is required in most Java Base64 implementations. The sun.misc.Base64Decoder decoded the sig with a tailing ">", while= another example I found from Internet tail with "0x00". --- Isn't this just turning into a total mess - telling people that they= need to refer to Wiki articles to use specific Base64 encode and decode func= tions and having to post chunks of code in order to try to get it working. --- The problem is actually that there library is buggy and others actua= lly follow the spec. Base64 is well defined. URLencoding is well defined. Unpad= ded base64 with several character substitutions is now well defined :) Then people started posting code to each other, some got it wrong: > # Ruby > > def base64_url_decode(str) > return Base64.decode64(str.tr('-_', '+/')) > end > that does not account for missing padding. Then someone actually read the spec: Facebook is following RFC. http://www.faqs.org/rfcs/rfc3548.html - Section 4. That said, I don't really agree with the use of the "filename safe" = style. I'd implement base64 with the protocol and/or filesystem specific encodi= ng separated, because I don't think the spec should be concerned with t= hat. Also, not many people use this style, so most libraries don't have support= for it. But hey, I'm just one of those well-read ruby hipsters, what do I kn= ow? We got lots of positive feedback about it: --- I'm a fan *cough* of the new auth mechanism; --- I agree that this is much cleaner. I like allowing the original requ= est method to be used. I just wish things followed the actual specification or = had their differences documented. As a library maintainer, I would also like t= o know before things like this are released. --- I'm also perfectly happy with the direction FB is going here. --- I have to say too, I'm also a big fan of the new authentication syst= em, thank you. It has cut out a lot of code for us, and it's a lot easier to d= ebug. This is a good verification system too. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --_000_5CAAB67233F6494D98A35E167AFB9273facebookcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable From 


=
W= hy is the signature first?
Doing a left split is usually easier than a right one. It also = allows us to pursue other encodings, like hex for the signature and percent= encoding for the payload.
Why is it called signed_request?
It's th= e part of the HTTP request that is signed. You can remember the signature c= omes first in both the name of the parameter and the parameter itself.
=
:)
Paul

On Jul 27, 2010, at = 4:10 PM, Nat Sakimura wrote:

Thanks for sharing!

One que= stion: Was there a particular reason for having signature first
instead = of the payload?

On Tue, Jul 27, 2010 at 7:18 AM, Paul Tarjan <paul.tarjan@facebook.com> w= rote:
Facebook released an early version of th= e proposed signature method, with the aim of getting real-life implementati= on experience. We are not currently using this for protected resource reque= sts, but rather more like if the authorization server returned signed data = as part of the access token response.

It was generally a success = with many people really liking the scheme.

Our main takeaway is t= hat MANY developers used normal base64 instead of base64url encoding either= because they didn't read the spec thoroughly or just recognized the scheme= and started decoding it. This caused weird errors which they weren't ready= for (sometimes working when - and _ weren't present, sometimes cutting off= some json characters when their language needed padding =3D, etc).

We created an open source set of examples that developers have found hel= pful, and which could be incorporated into the OAuth example set: http://github.com/ptarjan/base64ur= l

So, I suggest to keep the signature scheme, but message the= fact that it isn't normal base64 VERY loudly and clearly in the spec, and = to use examples that will fail hard with normal base64.


Our implementation followed the OAuth2.0 = signature scheme except for 4 changes:
* signature came before payload
* not_after was renamed expires
* not all required parameters were present given the difference in use = case
* the parameter was called s= igned_request instead of signed_token

You can read our docs here:= http= ://developers.facebook.com/docs/authentication/canvas
<= blockquote type=3D"cite">

Here is a few snippets of developer fee= dback that we had about them not understanding to use base64url instead of = base64 encoding:

       ---
<= blockquote type=3D"cite">       We're seeing bogus JSON= in the new parameter. It looks like a few characters
       are being left off the end.=

       ---
       Imcompatible Base64 Encoding between P= HP and Java (sun.misc.Base64Encoder)

       T= he problem was, I get an extra byte at the end of the Base64 Decoded Sig,
       compari= ng to the result I got from Hashing the Payload with my app secret.

       My guess is that PHP is not encoding base64 s= trictly following the Base64
&nbs= p;      convention, or, Facebook has removed the tailing &qu= ot;=3D" from Sig which is required
       in most Java Base64 implementations.
<= /blockquote>

       The sun.misc.Base64Decoder decoded the sig= with a tailing ">", while another
       example I found from Internet tai= l with "0x00".

       ---
       Isn't this just= turning into a total mess - telling people that they need to
       refer to Wiki artic= les to use specific Base64 encode and decode functions and
=
       having to post chunks = of code in order to try to get it working.

      &= nbsp;---
      &nb= sp;The problem is actually that there library is buggy and others actually = follow
       = ;the spec. Base64 is well defined. URLencoding is well defined. Unpadded ba= se64
       w= ith several character substitutions is now well defined :)
=


Then people started posting code to ea= ch other, some got it wrong:

=
       > # Ru= by
       >= ;
       >= def base64_url_decode(str)
 = ;      >     return Base64.decode64(str.tr('-_', '+/'))
       > end
       >

     =  that does not account for missing padding.


Then someone actually read the spec:

=        Facebook is following RFC. http://www.faqs.org/rfcs/rfc3548.html -
       Section = 4.

       That said, I don't really agree wit= h the use of the "filename safe" style. I'd
       implement base64 with the p= rotocol and/or filesystem specific encoding
       separated, because I don't think the = spec should be concerned with that. Also,
       not many people use this style, so mos= t libraries don't have support for it.
       But hey, I'm just one of those well-read r= uby hipsters, what do I know?

We got lots of positive feedback about it:

   = ;    ---
    =    I'm a fan *cough* of the new auth mechanism;
<= blockquote type=3D"cite">
  =      ---
  &n= bsp;    I agree that this is much cleaner. I like allowing the or= iginal request method
  &nbs= p;    to be used. I just wish things followed the actual specific= ation or had their
    =    differences documented. As a library maintainer, I would also = like to know
     =  before things like this are released.

     =  ---
      &= nbsp;I'm also perfectly happy with the direction FB is going here.

       ---
=        I have to say too, I'm also a big fan of the new= authentication system, thank
&nb= sp;      you. It has cut out a lot of code for us, and it's = a lot easier to debug. This
 = ;      is a good verification system too.
_______________________________________________
=
OAuth mailing list
<= blockquote type=3D"cite">OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




-- Nat Sakimura (=3Dnat)
http://w= ww.sakimura.org/en/
http://twitter.com/_nat_en

= --_000_5CAAB67233F6494D98A35E167AFB9273facebookcom_-- From darren@cliqset.com Wed Jul 28 13:28: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 A3A743A67F8 for ; Wed, 28 Jul 2010 13:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.437 X-Spam-Level: X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lU0JkstLixQU for ; Wed, 28 Jul 2010 13:28:57 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 270A23A6849 for ; Wed, 28 Jul 2010 13:28:56 -0700 (PDT) Received: by gxk1 with SMTP id 1so2197495gxk.31 for ; Wed, 28 Jul 2010 13:29:20 -0700 (PDT) Received: by 10.100.197.7 with SMTP id u7mr245439anf.104.1280348957841; Wed, 28 Jul 2010 13:29:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.7.19 with HTTP; Wed, 28 Jul 2010 13:28:57 -0700 (PDT) From: Darren Bounds Date: Wed, 28 Jul 2010 16:28:57 -0400 Message-ID: To: oauth@ietf.org, pubsubhubbub@googlegroups.com, federated-social-web@googlegroups.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jul 2010 20:28:58 -0000 Please excuse the cross posting. Following the Federated Social Web Summit in Portland a couple weeks ago, there has been a lot of chatter around protected feeds and how they'll function to achieve SWAT0 (http://federatedsocialweb.net/wiki/SWAT0). Protected feed subscriptions are clearly an important component of DiSo and necessary for features like remote follow/friending. During the summit Brett Stlakin published and discussed a document (http://tinyurl.com/push-oauth) where he proposes one technique for how OAuth may be used with PuSH to achieve the requirements. The proposal details an OAuth 2 flow (in addition to OAuth 1x) for handling a usecase that involves ToS acknowledgement before a protected feed subscription may be granted. The flow is essentially the web server client profile combined with the assertion grant type. While the flow will work and achieve the goals it also has a fundamental need for a user-agent redirect, something that not all providers may desire or require. What I'd like to propose is a variant of the assertion grant type that would make the user-agent redirect optional. The goal here was to stay within the bounds of the current spec where ever possible. That said; it may be desirable to break this out into it's own client profile. The flow detailed below is using the OAuth 2 scenario described in Brett's document (http://tinyurl.com/push-oauth). 1) cliqset.com would like to request an access token from google.com. Sends a request with grant_type=3Dassertion. Request: POST /token HTTP/1.1 Host: google.com Content-Type: application/x-www-form-urlencoded grant_type=3Dassertion&assertion_type=3Dhttp://webfinger.org/& assertion=3DeyJ1cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwibWFnaWNfc2lnbmF= 0dXJlIjogImFzZGxra2xhZnNkamtsZHNmamxraj0ifQ=3D=3D The assertion value in the request is a Base64 encoded JSON string with two properties, uri and magic_signature. Example: { "uri": "acct:dbounds@cliqset.com", "magic_signature": "asdlkklafsdjkldsfjlkj=3D" } Response: HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"supersecrettoken" "precondition_uri","http://google.com/oauth/authorize?state=3Dopaquevalue "code","myrandomcode123" } The access token response introduces two new optional properties: precondition_uri and code The existence of a precondition_uri means the consumer will be required to redirect the user to this uri in order to complete the activation of the provided access token. The precondition_uri resource has the same characteristics of the OAuth 2.0 Web Server client profile with the =E2=80=98state=E2=80=99 proper= ty being used to maintain state between the assertion request and the user redirect. Successful acknowledgement of the precondition results in a 302 response with the code provided in the assertion response (see example below). The existence of a code is required upon the presence of a precondition_uri= . If no precondition_uri is provided, the access token should be considered active and immediately usable barring any provider specific back-end authorization (e.g. user acceptance of remote follow). 2) access token received optional precondition_uri. Issuing user redirect to precondition_uri with redirect_uri. Request: GET /oauth/authorize?state=3Dopaquevalue&response_type=3Dtoken&client_id=3D= acct:dbounds@cliqset.com&redirect_uri=3Dhttp://cliqset.com/callback HTTP/1.1 Host: google.com User acknowledges the precondition. This could be any number of activities, including authenticating. Response: HTTP/1.1 302 Found Location: http://cliqset.com/callback?code=3Dmyrandomcode123 3) Subscription has been authorized. ToS has been acknowledged. Compete. The consumer is able to activate the access_token by confirming the code provided in the redirect. This flow offers what we feel are several significant advantages over the hybrid approach. 1) Redirection becomes optional and is only required when the precondition_uri is defined by the provider in the access token response. 2) For providers who require TOS acknowledgement, it enables additional flexibility in how they go about it. For example, if a provider only requires TOS acknowledgement on the initial subscription request by a given user, subsequent requests will not provide a precondition_uri. 3) It is also worth exploring this flow as a suitable and more flexible alternative to the traditional Web Server flow. Questions? Comments? Suggestions? --=20 darren bounds darren@cliqset.com From eve@xmlgrrl.com Wed Jul 28 17:23: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 0E4BE3A67AF for ; Wed, 28 Jul 2010 17:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 cMgD6TDSl35x for ; Wed, 28 Jul 2010 17:23:29 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id DD8623A68D4 for ; Wed, 28 Jul 2010 17:23:28 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.3) with ESMTP id o6T0Nmdp024983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Jul 2010 17:23:48 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Eve Maler In-Reply-To: Date: Wed, 28 Jul 2010 17:23:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C1DA1CC-32CF-495B-85C6-9FA336CD086E@xmlgrrl.com> References: To: Darren Bounds X-Mailer: Apple Mail (2.1081) Cc: pubsubhubbub@googlegroups.com, oauth@ietf.org, federated-social-web@googlegroups.com Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 00:23:30 -0000 Folks interested in protected feeds may be interested in UMA's solution, = which proposes mechanisms to demand "claims" from the requesting side = based on user-specified policyon the authorizing server side. An = example of UMA-protected resources that require agreement to terms can = be seen in the SMART project documented here (if you want, you can sign = up to take part in a UX study they're conducting right now: http://smartjisc.wordpress.com/ More general info about UMA is here: http://kantarainitiative.org/confluence/display/uma/Home Note that UMA is OAuth-based and tries to make its profiling and = extensions as small as possible to achieve its requirements, but I = suspect its requirements list is a bit longer/more comprehensive than = what is described below. Eve On 28 Jul 2010, at 1:28 PM, Darren Bounds wrote: > Please excuse the cross posting. >=20 > Following the Federated Social Web Summit in Portland a couple weeks > ago, there has been a lot of chatter around protected feeds and how > they'll function to achieve SWAT0 > (http://federatedsocialweb.net/wiki/SWAT0). Protected feed > subscriptions are clearly an important component of DiSo and necessary > for features like remote follow/friending. >=20 > During the summit Brett Stlakin published and discussed a document > (http://tinyurl.com/push-oauth) where he proposes one technique for > how OAuth may be used with PuSH to achieve the requirements. The > proposal details an OAuth 2 flow (in addition to OAuth 1x) for > handling a usecase that involves ToS acknowledgement before a > protected feed subscription may be granted. The flow is essentially > the web server client profile combined with the assertion grant type. > While the flow will work and achieve the goals it also has a > fundamental need for a user-agent redirect, something that not all > providers may desire or require. >=20 > What I'd like to propose is a variant of the assertion grant type that > would make the user-agent redirect optional. The goal here was to stay > within the bounds of the current spec where ever possible. That said; > it may be desirable to break this out into it's own client profile. >=20 > The flow detailed below is using the OAuth 2 scenario described in > Brett's document (http://tinyurl.com/push-oauth). >=20 > 1) cliqset.com would like to request an access token from google.com. > Sends a request with grant_type=3Dassertion. >=20 > Request: > POST /token HTTP/1.1 > Host: google.com > Content-Type: application/x-www-form-urlencoded >=20 > grant_type=3Dassertion&assertion_type=3Dhttp://webfinger.org/& > = assertion=3DeyJ1cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwibWFnaWNfc2lnbm= F0dXJlIjogImFzZGxra2xhZnNkamtsZHNmamxraj0ifQ=3D=3D >=20 > The assertion value in the request is a Base64 encoded JSON string > with two properties, uri and magic_signature. Example: >=20 > { > "uri": "acct:dbounds@cliqset.com", > "magic_signature": "asdlkklafsdjkldsfjlkj=3D" > } >=20 > Response: > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store >=20 > { > "access_token":"supersecrettoken" > = "precondition_uri","http://google.com/oauth/authorize?state=3Dopaquevalue > "code","myrandomcode123" > } >=20 > The access token response introduces two new optional properties: > precondition_uri and code >=20 > The existence of a precondition_uri means the consumer will be > required to redirect the user to this uri in order to complete the > activation of the provided access token. >=20 > The precondition_uri resource has the same characteristics of the > OAuth 2.0 Web Server client profile with the =91state=92 property = being > used to maintain state between the assertion request and the user > redirect. Successful acknowledgement of the precondition results in a > 302 response with the code provided in the assertion response (see > example below). >=20 > The existence of a code is required upon the presence of a = precondition_uri. >=20 > If no precondition_uri is provided, the access token should be > considered active and immediately usable barring any provider specific > back-end authorization (e.g. user acceptance of remote follow). >=20 > 2) access token received optional precondition_uri. Issuing user > redirect to precondition_uri with redirect_uri. >=20 > Request: > GET = /oauth/authorize?state=3Dopaquevalue&response_type=3Dtoken&client_id=3Dacc= t:dbounds@cliqset.com&redirect_uri=3Dhttp://cliqset.com/callback > HTTP/1.1 > Host: google.com >=20 > User acknowledges the precondition. This could be any number of > activities, including authenticating. >=20 >=20 > Response: > HTTP/1.1 302 Found > Location: http://cliqset.com/callback?code=3Dmyrandomcode123 >=20 > 3) Subscription has been authorized. ToS has been acknowledged. = Compete. >=20 > The consumer is able to activate the access_token by confirming the > code provided in the redirect. >=20 > This flow offers what we feel are several significant advantages over > the hybrid approach. >=20 > 1) Redirection becomes optional and is only required when the > precondition_uri is defined by the provider in the access token > response. >=20 > 2) For providers who require TOS acknowledgement, it enables > additional flexibility in how they go about it. For example, if a > provider only requires TOS acknowledgement on the initial subscription > request by a given user, subsequent requests will not provide a > precondition_uri. >=20 > 3) It is also worth exploring this flow as a suitable and more > flexible alternative to the traditional Web Server flow. >=20 >=20 > Questions? Comments? Suggestions? >=20 >=20 > --=20 > darren bounds > darren@cliqset.com > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler From eve@xmlgrrl.com Wed Jul 28 17:37: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 BBFCA3A67BD for ; Wed, 28 Jul 2010 17:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, 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 n-KlF9b6-usJ for ; Wed, 28 Jul 2010 17:37:57 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 49AF53A6ACA for ; Wed, 28 Jul 2010 17:37:10 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.3) with ESMTP id o6T0bSS6026940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Jul 2010 17:37:29 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-620--738545438 From: Eve Maler In-Reply-To: <4C4FE913.9030508@lodderstedt.net> Date: Wed, 28 Jul 2010 17:37:28 -0700 Message-Id: References: <4C3F3F6A.5000409@lodderstedt.net> <4C3F9064.6060604@lodderstedt.net> <4C48C116.9000609@lodderstedt.net> <4C4FE913.9030508@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 00:37:58 -0000 --Apple-Mail-620--738545438 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Belatedly... Sorry if I sound like a broken record on this, but: Most = of UMA's use involve letting a user introduce their various hosts = (UMA-flavored resource servers) to their single chosen "authorization = manager" (UMA-flavored authorization server), by treating the former as = a dynamically introduced OAuth client of the latter. This sounds an = awful lot like the question originally posed in this thread. We have = exactly the problem of figuring out how the host can tell the AM what = resources the AM should be protecting and what can be done to them, = which we've begun to solve with what we're calling a "resource = registration API" (RRAPI). (BTW, we're also working on an I-D to submit here that proposes a = solution for discovery/dynamic registration that meets our needs. Hoping = it can feed into Eran's discovery work.) Eve On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote: > thanks for sharing your thoughts. >=20 > Differentiating resource servers by using different end-user = authorization endpoint URLs is an option. I dont't know how this will = work in conjunction with discovery, especially since this = differentiation might by required on other endpoints, too. For example, = if a client wants to obtain an access token for the end-user's = credentials, it has to identify the resource server also on the tokens = endpoint. There might be additional endpoint for other flows with = similar requirements, e.g. the device flow. >=20 > Based on your proposal, a derived solution could be to define a = standard parameter "resourceserver" and to state how clients should use = this parameter on the different endpoints. On the coding level, there = would be no difference to your proposal :-) But the client would be able = to construct such a URL on its own. >=20 > Authorizing access for different resource servers is indeed an issue = for me. How would you propose to add the namespace? Shall the scope = obtained from the resource server already contain such a namespace are = shall there be a rule to construct such namespaced-ed scopes in the = spec? >=20 > regards, > Torsten. >=20 > Am 25.07.2010 19:11, schrieb Andrew Arnott: >>=20 >> It seems to me that if one auth server can create tokens for a = diverse set of resource servers, then why not have different user = authorization endpoint URLs for each type of resource server, as an = added differentiator for the scope (a namespace, if you will)? >>=20 >> So suppose one auth server serves two different photo services, both = using overlapping scopes such that a client requesting access of some = scope is otherwise ambiguous between which resource server the client = needs access to. The auth server that serves both resource servers = could have two end user authorization endpoints: >> http://auth.server.org/authorize?resourceserver=3D1 >> http://auth.server.org/authorize?resourceserver=3D2 >>=20 >> And that way the auth server knows exactly what the client needs. >>=20 >> The only scenario this doesn't allow for is for a user to authorize a = client's access to both resource servers in one redirect. If this were = an issue, perhaps you can apply a namespace-like prefix to each scope = substring: >>=20 >> rs1:photo:read rs2:photo:read >>=20 >> Which would serve a similar purpose. >>=20 >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the = death your right to say it." - S. G. Tallentyre >>=20 >>=20 >> On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt = wrote: >> no one else in the group having an opinion on this topic? >>=20 >>=20 >>=20 >> Am 15.07.2010 20:14, schrieb Marius Scurtescu: >> On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt >> wrote: >> As I have written in my reply to Marius's posting. I'm fine with = including >> server ids in scopes. But this requires a definition of the scope's = syntax >> and semantics in the spec. Otherwise, scope interpretation (and = server >> identification) will be deployment specific. >> Sure, it is deployment specific, but why is that an issue? >>=20 >> In your case, the authz server and all the resource servers are >> managed by the same organization, right? >>=20 >> Do clients need to be aware of the actual resource server? >>=20 >> You can probably create a separate spec that defines scope syntax for >> this purpose, if really needed. Does it have to be in core? >>=20 >> Marius >>=20 >> Solving the challenge I described in a deployment specific way is not = an issue. But the consequence is that authz server, resource servers and = clients are tight together. >>=20 >> Let me ask you one question: Why are we working together towards a = standard protocol? I can tell you my expectations: I hope there will be = broad support not only by libraries, but also by ready-to-use services = and clients, so we could integrate such services into our deployment = easily. Moreover, I would like to see OAuth to be included in = application/service protocols like PortableContacts, SIP, WebDAV, IMAP, = ... >>=20 >> So what if I would like to use standard clients to access our = services? Using scopes for specifying resource server id's in this case = is also simple - if you take an isolated view. But since scopes may be = used to specifiy a lot of other things, like resources, permissions, and = durations, handling w/o a more detailed spec will in practice be = impossible. >>=20 >> Suppose a WebDAV service for media data access. Any WebDAV client = knows the WebDAV protocol (=3D=3D interface), e.g. the supported methods = (GET, PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. So = it is sufficient to configure the client with the URL of my personal web = storage. To start with let's assume, scopes are used to designate = resource servers only. So the server's scope could be "webstorage". >>=20 >> WWW-Authenticate OAuth realm=3D'webstorage' scope=3D"webstorage" >>=20 >> The client could just pass this parameter to the authz server and = everything is fine. >>=20 >> On the next level, let's assume the (future) WebDAV standard with = OAuth-support uses one permission per method type. So the full scope = could be as follows: >>=20 >> WWW-Authenticate OAuth realm=3D'webstorage' scope=3D"webstorage:GET = webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY = webstorage:MOVE" >>=20 >> Passing this scope w/o any unmodified to the authz server is not an = issue. But this implies the client asks for full access to the users = media storage. Since our client is a gallery application, it requires = the "GET" permission only. How does the client know which of the scope = values to pick for the end-user authorization process? It must somehow = select "webstorage:GET". >>=20 >> But how? >>=20 >> In my personal opinion, clients should be enabled to interpret, = combine and even create scopes. And yes, this should go to the core of = the spec. >>=20 >> regards, >> Torsten. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler --Apple-Mail-620--738545438 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

(BTW, we're also = working on an I-D to submit here that proposes a solution for = discovery/dynamic registration that meets our needs. Hoping it can feed = into Eran's discovery work.)

= Eve

On 28 Jul 2010, at 1:23 AM, Torsten = Lodderstedt wrote:

thanks for sharing your thoughts.

Differentiating resource servers by using different end-user authorization endpoint URLs is an option. I dont't know how this will work in conjunction with discovery, especially since this differentiation might by required on other endpoints, too. For example, if a client wants to obtain an access token for the end-user's credentials, it has to identify the resource server also on the tokens endpoint. There might be additional endpoint for other flows with similar requirements, e.g. the device flow.

Based on your proposal, a derived solution could be to define a standard parameter "resourceserver" and to state how clients should use this parameter on the different endpoints. On the coding level, there would be no difference to your proposal :-) But the client would be able to construct such a URL on its own.

Authorizing access for different resource servers is indeed an issue for me. How would you propose to add the namespace? Shall the scope obtained from the resource server already contain such a namespace are shall there be a rule to construct such namespaced-ed scopes in the spec?

regards,
Torsten.

Am 25.07.2010 19:11, schrieb Andrew Arnott:
It seems to me that if one auth server can create tokens for a diverse set of resource servers, then why not have different user authorization endpoint URLs for each type of resource server, as an added differentiator for the scope (a namespace, if you will)?

So suppose one auth server serves two different photo services, both using overlapping scopes such that a client requesting access of some scope is otherwise ambiguous between which resource server the client needs access to.  The auth server that serves both resource servers could have two end user authorization endpoints:

And that way the auth server knows exactly what the client = needs.

The only scenario this doesn't allow for is for a user to authorize a client's access to both resource servers in one redirect.  If this were an issue, perhaps you can apply a namespace-like prefix to each scope substring:

rs1:photo:read rs2:photo:read

Which would serve a similar purpose.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre


On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
no one else in the group having an opinion on this topic?



Am 15.07.2010 20:14, schrieb Marius Scurtescu:
On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
<torsten@lodderstedt.net>  wrote:
As I have written in my reply to Marius's posting. I'm fine with including
server ids in scopes. But this requires a definition of the scope's syntax
and semantics in the spec. Otherwise, scope interpretation (and = server
identification) will be deployment specific.
Sure, it is deployment specific, but why is that an issue?

In your case, the authz server and all the resource servers are
managed by the same organization, right?

Do clients need to be aware of the actual resource server?

You can probably create a separate spec that defines scope syntax = for
this purpose, if really needed. Does it have to be in core?

Marius

Solving the challenge I described in a deployment specific way is not an issue. But the consequence is that authz server, resource servers and clients are tight together.

Let me ask you one question: Why are we working together towards a standard protocol? I can tell you my expectations: I hope there will be broad support not only by libraries, but also by ready-to-use services and clients, so we could integrate such services into our deployment easily. Moreover, I would like to see OAuth to be included in application/service protocols like PortableContacts, SIP, WebDAV, IMAP, ...

So what if I would like to use standard clients to access our services? Using scopes for specifying resource server id's in this case is also simple - if you take an isolated view. But since scopes may be used to specifiy a lot of other things, like resources, permissions, and durations, handling w/o a more detailed spec will in practice be impossible.

Suppose a WebDAV service for media data access. Any WebDAV client knows the WebDAV protocol (=3D=3D interface), e.g. the supported methods (GET, PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. So it is sufficient to configure the client with the URL of my personal web storage. To start with let's assume, scopes are used to designate resource servers only. So the server's scope could be "webstorage".

   WWW-Authenticate OAuth realm=3D'webstorage' = scope=3D"webstorage"

The client could just pass this parameter to the authz server and everything is fine.

On the next level, let's assume the (future) WebDAV standard with OAuth-support uses one permission per method type. So the full scope could be as follows:

   WWW-Authenticate OAuth realm=3D'webstorage' = scope=3D"webstorage:GET webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY webstorage:MOVE"

Passing this scope w/o any unmodified to the authz server is not an issue. But this implies the client asks for full access to the users media storage. Since our client is a gallery application, it requires the "GET" permission only. How does the client know which of the scope values to pick for the end-user authorization process? It must somehow select "webstorage:GET".

But how?

In my personal opinion, clients should be enabled to interpret, combine and even create scopes. And yes, this should go to the core of the = spec.

regards,
Torsten.




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

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

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


= --Apple-Mail-620--738545438-- From torsten@lodderstedt.net Wed Jul 28 23:34: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 9F24F3A6915 for ; Wed, 28 Jul 2010 23:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 4mQJq76Wzeza for ; Wed, 28 Jul 2010 23:34:16 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by core3.amsl.com (Postfix) with ESMTP id 569A23A6991 for ; Wed, 28 Jul 2010 23:32:57 -0700 (PDT) Received: from dhcp-87ec.meeting.ietf.org ([130.129.135.236] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OeMfx-0000ic-Ot; Thu, 29 Jul 2010 08:33:05 +0200 Message-ID: <4C512095.5050802@lodderstedt.net> Date: Thu, 29 Jul 2010 08:32:53 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Eve Maler References: <4C3F3F6A.5000409@lodderstedt.net> <4C3F9064.6060604@lodderstedt.net> <4C48C116.9000609@lodderstedt.net> <4C4FE913.9030508@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080602010009070704030708" X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 06:34:26 -0000 X-List-Received-Date: Thu, 29 Jul 2010 06:34:26 -0000 X-List-Received-Date: Thu, 29 Jul 2010 06:34:26 -0000 This is a multi-part message in MIME format. --------------080602010009070704030708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eve, how does UMA plan to address resource servers during the OAuth end-user authorization process? regards, Torsten. Am 29.07.2010 02:37, schrieb Eve Maler: > Belatedly... Sorry if I sound like a broken record on this, but: Most > of UMA's use involve letting a user introduce their various hosts > (UMA-flavored resource servers) to their single chosen "authorization > manager" (UMA-flavored authorization server), by treating the former > as a dynamically introduced OAuth client of the latter. This sounds an > awful lot like the question originally posed in this thread. We have > exactly the problem of figuring out how the host can tell the AM what > resources the AM should be protecting and what can be done to them, > which we've begun to solve with what we're calling a "resource > registration API" (RRAPI). > > (BTW, we're also working on an I-D to submit here that proposes a > solution for discovery/dynamic registration that meets our needs. > Hoping it can feed into Eran's discovery work.) > > Eve > > On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote: > >> thanks for sharing your thoughts. >> >> Differentiating resource servers by using different end-user >> authorization endpoint URLs is an option. I dont't know how this will >> work in conjunction with discovery, especially since this >> differentiation might by required on other endpoints, too. For >> example, if a client wants to obtain an access token for the >> end-user's credentials, it has to identify the resource server also >> on the tokens endpoint. There might be additional endpoint for other >> flows with similar requirements, e.g. the device flow. >> >> Based on your proposal, a derived solution could be to define a >> standard parameter "resourceserver" and to state how clients should >> use this parameter on the different endpoints. On the coding level, >> there would be no difference to your proposal :-) But the client >> would be able to construct such a URL on its own. >> >> Authorizing access for different resource servers is indeed an issue >> for me. How would you propose to add the namespace? Shall the scope >> obtained from the resource server already contain such a namespace >> are shall there be a rule to construct such namespaced-ed scopes in >> the spec? >> >> regards, >> Torsten. >> >> Am 25.07.2010 19:11, schrieb Andrew Arnott: >>> It seems to me that if one auth server can create tokens for a >>> diverse set of resource servers, then why not have different user >>> authorization endpoint URLs for each type of resource server, as an >>> added differentiator for the scope (a namespace, if you will)? >>> >>> So suppose one auth server serves two different photo services, both >>> using overlapping scopes such that a client requesting access of >>> some scope is otherwise ambiguous between which resource server the >>> client needs access to. The auth server that serves both resource >>> servers could have two end user authorization endpoints: >>> http://auth.server.org/authorize?resourceserver=1 >>> http://auth.server.org/authorize?resourceserver=2 >>> >>> And that way the auth server knows exactly what the client needs. >>> >>> The only scenario this doesn't allow for is for a user to authorize >>> a client's access to /both/ resource servers in one redirect. If >>> this were an issue, perhaps you can apply a namespace-like prefix to >>> each scope substring: >>> >>> rs1:photo:read rs2:photo:read >>> >>> Which would serve a similar purpose. >>> >>> -- >>> Andrew Arnott >>> "I [may] not agree with what you have to say, but I'll defend to the >>> death your right to say it." - S. G. Tallentyre >>> >>> >>> On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt >>> > wrote: >>> >>> no one else in the group having an opinion on this topic? >>> >>> >>> >>> Am 15.07.2010 20:14, schrieb Marius Scurtescu: >>> >>> On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt >>> >> > wrote: >>> >>> As I have written in my reply to Marius's posting. >>> I'm fine with including >>> server ids in scopes. But this requires a definition >>> of the scope's syntax >>> and semantics in the spec. Otherwise, scope >>> interpretation (and server >>> identification) will be deployment specific. >>> >>> Sure, it is deployment specific, but why is that an issue? >>> >>> In your case, the authz server and all the resource >>> servers are >>> managed by the same organization, right? >>> >>> Do clients need to be aware of the actual resource server? >>> >>> You can probably create a separate spec that defines >>> scope syntax for >>> this purpose, if really needed. Does it have to be in core? >>> >>> Marius >>> >>> >>> Solving the challenge I described in a deployment specific >>> way is not an issue. But the consequence is that authz >>> server, resource servers and clients are tight together. >>> >>> Let me ask you one question: Why are we working together >>> towards a standard protocol? I can tell you my expectations: >>> I hope there will be broad support not only by libraries, >>> but also by ready-to-use services and clients, so we could >>> integrate such services into our deployment easily. >>> Moreover, I would like to see OAuth to be included in >>> application/service protocols like PortableContacts, SIP, >>> WebDAV, IMAP, ... >>> >>> So what if I would like to use standard clients to access >>> our services? Using scopes for specifying resource server >>> id's in this case is also simple - if you take an isolated >>> view. But since scopes may be used to specifiy a lot of >>> other things, like resources, permissions, and durations, >>> handling w/o a more detailed spec will in practice be >>> impossible. >>> >>> Suppose a WebDAV service for media data access. Any WebDAV >>> client knows the WebDAV protocol (== interface), e.g. the >>> supported methods (GET, PUT, POST, DELETE, COPY, MOVE) and >>> how to traverse directories. So it is sufficient to >>> configure the client with the URL of my personal web >>> storage. To start with let's assume, scopes are used to >>> designate resource servers only. So the server's scope could >>> be "webstorage". >>> >>> WWW-Authenticate OAuth realm='webstorage' scope="webstorage" >>> >>> The client could just pass this parameter to the authz >>> server and everything is fine. >>> >>> On the next level, let's assume the (future) WebDAV standard >>> with OAuth-support uses one permission per method type. So >>> the full scope could be as follows: >>> >>> WWW-Authenticate OAuth realm='webstorage' >>> scope="webstorage:GET webstorage:PUT webstorage:POST >>> webstorage:DELETE webstorage:COPY webstorage:MOVE" >>> >>> Passing this scope w/o any unmodified to the authz server is >>> not an issue. But this implies the client asks for full >>> access to the users media storage. Since our client is a >>> gallery application, it requires the "GET" permission only. >>> How does the client know which of the scope values to pick >>> for the end-user authorization process? It must somehow >>> select "webstorage:GET". >>> >>> But how? >>> >>> In my personal opinion, clients should be enabled to >>> interpret, combine and even create scopes. And yes, this >>> should go to the core of the spec. >>> >>> regards, >>> Torsten. >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > Eve Maler > http://www.xmlgrrl.com/blog > http://www.twitter.com/xmlgrrl > http://www.linkedin.com/in/evemaler > --------------080602010009070704030708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eve,

how does UMA plan to address resource servers during the OAuth end-user authorization process?

regards,
Torsten.

Am 29.07.2010 02:37, schrieb Eve Maler:
Belatedly...  Sorry if I sound like a broken record on this, but: Most of UMA's use involve letting a user introduce their various hosts (UMA-flavored resource servers) to their single chosen "authorization manager" (UMA-flavored authorization server), by treating the former as a dynamically introduced OAuth client of the latter. This sounds an awful lot like the question originally posed in this thread. We have exactly the problem of figuring out how the host can tell the AM what resources the AM should be protecting and what can be done to them, which we've begun to solve with what we're calling a "resource registration API" (RRAPI).

(BTW, we're also working on an I-D to submit here that proposes a solution for discovery/dynamic registration that meets our needs. Hoping it can feed into Eran's discovery work.)

Eve

On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote:

thanks for sharing your thoughts.

Differentiating resource servers by using different end-user authorization endpoint URLs is an option. I dont't know how this will work in conjunction with discovery, especially since this differentiation might by required on other endpoints, too. For example, if a client wants to obtain an access token for the end-user's credentials, it has to identify the resource server also on the tokens endpoint. There might be additional endpoint for other flows with similar requirements, e.g. the device flow.

Based on your proposal, a derived solution could be to define a standard parameter "resourceserver" and to state how clients should use this parameter on the different endpoints. On the coding level, there would be no difference to your proposal :-) But the client would be able to construct such a URL on its own.

Authorizing access for different resource servers is indeed an issue for me. How would you propose to add the namespace? Shall the scope obtained from the resource server already contain such a namespace are shall there be a rule to construct such namespaced-ed scopes in the spec?

regards,
Torsten.

Am 25.07.2010 19:11, schrieb Andrew Arnott:
It seems to me that if one auth server can create tokens for a diverse set of resource servers, then why not have different user authorization endpoint URLs for each type of resource server, as an added differentiator for the scope (a namespace, if you will)?

So suppose one auth server serves two different photo services, both using overlapping scopes such that a client requesting access of some scope is otherwise ambiguous between which resource server the client needs access to.  The auth server that serves both resource servers could have two end user authorization endpoints:

And that way the auth server knows exactly what the client needs.

The only scenario this doesn't allow for is for a user to authorize a client's access to both resource servers in one redirect.  If this were an issue, perhaps you can apply a namespace-like prefix to each scope substring:

rs1:photo:read rs2:photo:read

Which would serve a similar purpose.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre


On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
no one else in the group having an opinion on this topic?



Am 15.07.2010 20:14, schrieb Marius Scurtescu:
On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
<torsten@lodderstedt.net>  wrote:
As I have written in my reply to Marius's posting. I'm fine with including
server ids in scopes. But this requires a definition of the scope's syntax
and semantics in the spec. Otherwise, scope interpretation (and server
identification) will be deployment specific.
Sure, it is deployment specific, but why is that an issue?

In your case, the authz server and all the resource servers are
managed by the same organization, right?

Do clients need to be aware of the actual resource server?

You can probably create a separate spec that defines scope syntax for
this purpose, if really needed. Does it have to be in core?

Marius

Solving the challenge I described in a deployment specific way is not an issue. But the consequence is that authz server, resource servers and clients are tight together.

Let me ask you one question: Why are we working together towards a standard protocol? I can tell you my expectations: I hope there will be broad support not only by libraries, but also by ready-to-use services and clients, so we could integrate such services into our deployment easily. Moreover, I would like to see OAuth to be included in application/service protocols like PortableContacts, SIP, WebDAV, IMAP, ...

So what if I would like to use standard clients to access our services? Using scopes for specifying resource server id's in this case is also simple - if you take an isolated view. But since scopes may be used to specifiy a lot of other things, like resources, permissions, and durations, handling w/o a more detailed spec will in practice be impossible.

Suppose a WebDAV service for media data access. Any WebDAV client knows the WebDAV protocol (== interface), e.g. the supported methods (GET, PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. So it is sufficient to configure the client with the URL of my personal web storage. To start with let's assume, scopes are used to designate resource servers only. So the server's scope could be "webstorage".

   WWW-Authenticate OAuth realm='webstorage' scope="webstorage"

The client could just pass this parameter to the authz server and everything is fine.

On the next level, let's assume the (future) WebDAV standard with OAuth-support uses one permission per method type. So the full scope could be as follows:

   WWW-Authenticate OAuth realm='webstorage' scope="webstorage:GET webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY webstorage:MOVE"

Passing this scope w/o any unmodified to the authz server is not an issue. But this implies the client asks for full access to the users media storage. Since our client is a gallery application, it requires the "GET" permission only. How does the client know which of the scope values to pick for the end-user authorization process? It must somehow select "webstorage:GET".

But how?

In my personal opinion, clients should be enabled to interpret, combine and even create scopes. And yes, this should go to the core of the spec.

regards,
Torsten.




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

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

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


--------------080602010009070704030708-- From torsten@lodderstedt.net Wed Jul 28 23:40:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69FA3A69B1 for ; Wed, 28 Jul 2010 23:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.101, 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 ppD0MJaq-4Vl for ; Wed, 28 Jul 2010 23:40:32 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by core3.amsl.com (Postfix) with ESMTP id 71C883A69AA for ; Wed, 28 Jul 2010 23:39:56 -0700 (PDT) Received: from dhcp-87ec.meeting.ietf.org ([130.129.135.236] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OeMmu-0002vo-0r; Thu, 29 Jul 2010 08:40:16 +0200 Message-ID: <4C512248.1080707@lodderstedt.net> Date: Thu, 29 Jul 2010 08:40:08 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Darren Bounds References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: pubsubhubbub@googlegroups.com, oauth@ietf.org, federated-social-web@googlegroups.com Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 06:40:33 -0000 Darren, I have got some questions regarding your posting, esp. the assertion. > 1) cliqset.com would like to request an access token from google.com. > Sends a request with grant_type=assertion. > > Request: > POST /token HTTP/1.1 > Host: google.com > Content-Type: application/x-www-form-urlencoded > > grant_type=assertion&assertion_type=http://webfinger.org/& > assertion=eyJ1cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwibWFnaWNfc2lnbmF0dXJlIjogImFzZGxra2xhZnNkamtsZHNmamxraj0ifQ== > > The assertion value in the request is a Base64 encoded JSON string > with two properties, uri and magic_signature. Example: > > { > "uri": "acct:dbounds@cliqset.com", > "magic_signature": "asdlkklafsdjkldsfjlkj=" > } > > What is the meaning of the assertion? Does the uri represent an end-user or the client? How does the assertion represent an authorization, given that you try to make end-user authorization via browser redirect an optional step. regards, Torsten, From James.H.Manger@team.telstra.com Thu Jul 29 00:51:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CBE13A68B5 for ; Thu, 29 Jul 2010 00:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.716 X-Spam-Level: X-Spam-Status: No, score=0.716 tagged_above=-999 required=5 tests=[AWL=-0.983, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6woRnnCOWhz for ; Thu, 29 Jul 2010 00:50:59 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id ED5993A63C9 for ; Thu, 29 Jul 2010 00:50:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,279,1278252000"; d="scan'208";a="6801140" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipobni.tcif.telstra.com.au with ESMTP; 29 Jul 2010 17:51:19 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6057"; a="5218800" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcdni.tcif.telstra.com.au with ESMTP; 29 Jul 2010 17:51:21 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Thu, 29 Jul 2010 17:51:20 +1000 From: "Manger, James H" To: Darren Bounds , "oauth@ietf.org" Date: Thu, 29 Jul 2010 17:51:19 +1000 Thread-Topic: [OAUTH-WG] OAuth & Protected feeds Thread-Index: Acsuk5O0hgC/irj1SGyQ+Ci6mS3nOgAXsHkw Message-ID: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 07:51:01 -0000 RGFycmVuLA0KDQpJdCBzb3VuZHMgbGlrZSB5b3Ugd2FudCB0byB1c2UgT0F1dGgyIHRvIGluc2Vy dCBhbiBodW1hbi9IVE1MIGludGVyYWN0aW9uIGludG8gYSBhcHAvQXRvbSBleGNoYW5nZS4NCg0K T0F1dGgyIGNhbiBkbyB0aGF0Lg0KDQpZb3UgYWxzbyB3YW50IHRvIHVzZSBhIGRpcmVjdCBPQXV0 aDIgZmxvdyBmb3IgYWNjZXNzIGNvbnRyb2wgdG8gdGhlIGZlZWQuDQoNCllvdXIgInByZWNvbmRp dGlvbl91cmkiIGFkZGl0aW9uIHRvIHRoZSB0b2tlbiByZXNwb25zZSBpcyBhbiBhdHRlbXB0IHRv IGNvbWJpbmUgdGhlIDIgT0F1dGgyIGZsb3dzLg0KDQpBbiBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0 byBydW4gdGhlIDIgT0F1dGgyIGZsb3dzIHNlcXVlbnRpYWxseS4NCjEuIGFwcCB1c2UgYSBkaXJl Y3QgT0F1dGgyIGZsb3cgKGVnIHRoZSBhc3NlcnRpb24gZmxvdykgdG8gZ2V0IGEgdG9rZW47DQoy LiBhcHAgdHJpZXMgdG8gZ2V0IGZlZWQgd2l0aCB0b2tlbiwgYnV0IHNlcnZlciBkZW1hbmRzIGEg dXNlci1kZWxlZ2F0aW9uIE9BdXRoMiBmbG93Ow0KMy4gYXBwIHJlZGlyZWN0cyB1c2VyIHRvIHNl cnZpY2U7IFRlcm1zIG9mIFNlcnZpY2UgYXJlIHNob3duOyB1c2VyIHJlZGlyZWN0ZWQgYmFjazsN CjQuIGFwcCB0cmllcyB0byBnZXQgZmVlZCBhZ2Fpbiwgd2hpY2ggc3VjY2VlZHMgdGhpcyB0aW1l Lg0KDQpUaGlzIGV4YW1wbGUgaWxsdXN0cmF0ZXMgdGhhdCBPQXV0aDIgZGlzY292ZXJ5IG5lZWRz IHRvIGxldCBhIHNlcnZpY2UNCmV4cGxpY2l0bHkgaW5kaWNhdGUgd2hldGhlciBhIGRpcmVjdCBh bmQvb3IgdXNlci1kZWxlZ2F0aW9uIGZsb3cgaXMgcmVxdWlyZWQuDQpGb3IgaW5zdGFuY2UsIGEg IldXVy1BdXRoZW50aWNhdGU6IE9BdXRoMiIgcmVzcG9uc2UgY291bGQgZGVmaW5lIDIgcGFyYW1l dGVyczoNCid1c2VyLXVyaScgYW5kICd0b2tlbi11cmknLiBJZiBvbmx5IG9uZSBpcyBwcmVzZW50 LCBvbmx5IHRoZSBjb3JyZXNwb25kaW5nIG1vZGUNCmlzIHVzZWZ1bCBpbiB0aGlzIGludGVyYWN0 aW9uLg0KDQoNCkFub3RoZXIgaW50ZXJlc3RpbmcgZmFjZXQgb2YgdGhpcyBleGFtcGxlIGlzIHdo YXQgdG9rZW4gdGhlIGFwcCB1c2VzDQphdCBzdGVwIDQuIElzIGl0IHRoZSB0b2tlbiB0aGUgYXBw IGdvdCBpbiB0aGUgZmlyc3QgT0F1dGgyIGZsb3cgKHN0ZXAgMSksDQpvciB0aGUgdG9rZW4gZnJv bSB0aGUgc2Vjb25kIE9BdXRoMiBmbG93IChzdGVwIDMpPw0KDQpQcmVzdW1hYmx5IHRoZSBzZWNv bmQgdG9rZW4gb3ZlcnJpZGVzIHRoZSBmaXJzdC4NCkluIHRoaXMgZXhhbXBsZSwgaG93ZXZlciwg aXQgbWF5IGJlIHN1ZmZpY2llbnQgdG8ga2VlcCB1c2luZyB0aGUgZmlyc3QgdG9rZW4uDQpPQXV0 aDIgZG9lc27igJl0IG5lZWQgdG8gbWFrZSByZXR1cm5pbmcgYSB0b2tlbiBtYW5kYXRvcnkgLS0g aXQgaXMgbm90DQphbHdheXMgcmVxdWlyZWQgaW4gYSB1c2VyLWRlbGVnYXRpb24gZmxvdy4NCg0K LS0NCkphbWVzIE1hbmdlcg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgRGFycmVuIEJvdW5kcw0KU2VudDogVGh1cnNkYXksIDI5IEp1bHkgMjAxMCA2 OjI5IEFNDQpUbzogb2F1dGhAaWV0Zi5vcmc7IHB1YnN1Ymh1YmJ1YkBnb29nbGVncm91cHMuY29t OyBmZWRlcmF0ZWQtc29jaWFsLXdlYkBnb29nbGVncm91cHMuY29tDQpTdWJqZWN0OiBbT0FVVEgt V0ddIE9BdXRoICYgUHJvdGVjdGVkIGZlZWRzDQoNClBsZWFzZSBleGN1c2UgdGhlIGNyb3NzIHBv c3RpbmcuDQoNCkZvbGxvd2luZyB0aGUgRmVkZXJhdGVkIFNvY2lhbCBXZWIgU3VtbWl0IGluIFBv cnRsYW5kIGEgY291cGxlIHdlZWtzDQphZ28sIHRoZXJlIGhhcyBiZWVuIGEgbG90IG9mIGNoYXR0 ZXIgYXJvdW5kIHByb3RlY3RlZCBmZWVkcyBhbmQgaG93DQp0aGV5J2xsIGZ1bmN0aW9uIHRvIGFj aGlldmUgU1dBVDANCihodHRwOi8vZmVkZXJhdGVkc29jaWFsd2ViLm5ldC93aWtpL1NXQVQwKS4g IFByb3RlY3RlZCBmZWVkDQpzdWJzY3JpcHRpb25zIGFyZSBjbGVhcmx5IGFuIGltcG9ydGFudCBj b21wb25lbnQgb2YgRGlTbyBhbmQgbmVjZXNzYXJ5DQpmb3IgZmVhdHVyZXMgbGlrZSByZW1vdGUg Zm9sbG93L2ZyaWVuZGluZy4NCg0KRHVyaW5nIHRoZSBzdW1taXQgQnJldHQgU3RsYWtpbiBwdWJs aXNoZWQgYW5kIGRpc2N1c3NlZCBhIGRvY3VtZW50DQooaHR0cDovL3Rpbnl1cmwuY29tL3B1c2gt b2F1dGgpIHdoZXJlIGhlIHByb3Bvc2VzIG9uZSB0ZWNobmlxdWUgZm9yDQpob3cgT0F1dGggbWF5 IGJlIHVzZWQgd2l0aCBQdVNIIHRvIGFjaGlldmUgdGhlIHJlcXVpcmVtZW50cy4gVGhlDQpwcm9w b3NhbCBkZXRhaWxzIGFuIE9BdXRoIDIgZmxvdyAoaW4gYWRkaXRpb24gdG8gT0F1dGggMXgpIGZv cg0KaGFuZGxpbmcgYSB1c2VjYXNlIHRoYXQgaW52b2x2ZXMgVG9TIGFja25vd2xlZGdlbWVudCBi ZWZvcmUgYQ0KcHJvdGVjdGVkIGZlZWQgc3Vic2NyaXB0aW9uIG1heSBiZSBncmFudGVkLiBUaGUg ZmxvdyBpcyBlc3NlbnRpYWxseQ0KdGhlIHdlYiBzZXJ2ZXIgY2xpZW50IHByb2ZpbGUgY29tYmlu ZWQgd2l0aCB0aGUgYXNzZXJ0aW9uIGdyYW50IHR5cGUuDQpXaGlsZSB0aGUgZmxvdyB3aWxsIHdv cmsgYW5kIGFjaGlldmUgdGhlIGdvYWxzIGl0IGFsc28gaGFzIGENCmZ1bmRhbWVudGFsIG5lZWQg Zm9yIGEgdXNlci1hZ2VudCByZWRpcmVjdCwgc29tZXRoaW5nIHRoYXQgbm90IGFsbA0KcHJvdmlk ZXJzIG1heSBkZXNpcmUgb3IgcmVxdWlyZS4NCg0KV2hhdCBJJ2QgbGlrZSB0byBwcm9wb3NlIGlz IGEgdmFyaWFudCBvZiB0aGUgYXNzZXJ0aW9uIGdyYW50IHR5cGUgdGhhdA0Kd291bGQgbWFrZSB0 aGUgdXNlci1hZ2VudCByZWRpcmVjdCBvcHRpb25hbC4gVGhlIGdvYWwgaGVyZSB3YXMgdG8gc3Rh eQ0Kd2l0aGluIHRoZSBib3VuZHMgb2YgdGhlIGN1cnJlbnQgc3BlYyB3aGVyZSBldmVyIHBvc3Np YmxlLiBUaGF0IHNhaWQ7DQppdCBtYXkgYmUgZGVzaXJhYmxlIHRvIGJyZWFrIHRoaXMgb3V0IGlu dG8gaXQncyBvd24gY2xpZW50IHByb2ZpbGUuDQoNClRoZSBmbG93IGRldGFpbGVkIGJlbG93IGlz IHVzaW5nIHRoZSBPQXV0aCAyIHNjZW5hcmlvIGRlc2NyaWJlZCBpbg0KQnJldHQncyBkb2N1bWVu dCAoaHR0cDovL3Rpbnl1cmwuY29tL3B1c2gtb2F1dGgpLg0KDQoxKSBjbGlxc2V0LmNvbSB3b3Vs ZCBsaWtlIHRvIHJlcXVlc3QgYW4gYWNjZXNzIHRva2VuIGZyb20gZ29vZ2xlLmNvbS4NClNlbmRz IGEgcmVxdWVzdCB3aXRoIGdyYW50X3R5cGU9YXNzZXJ0aW9uLg0KDQpSZXF1ZXN0Og0KUE9TVCAv dG9rZW4gSFRUUC8xLjENCkhvc3Q6IGdvb2dsZS5jb20NCkNvbnRlbnQtVHlwZTogYXBwbGljYXRp b24veC13d3ctZm9ybS11cmxlbmNvZGVkDQoNCmdyYW50X3R5cGU9YXNzZXJ0aW9uJmFzc2VydGlv bl90eXBlPWh0dHA6Ly93ZWJmaW5nZXIub3JnLyYNCmFzc2VydGlvbj1leUoxY21raU9pQWlZV05q ZERwa1ltOTFibVJ6UUdOc2FYRnpaWFF1WTI5dElpd2liV0ZuYVdOZmMybG5ibUYwZFhKbElqb2dJ bUZ6Wkd4cmEyeGhabk5rYW10c1pITm1hbXhyYWowaWZRPT0NCg0KVGhlIGFzc2VydGlvbiB2YWx1 ZSBpbiB0aGUgcmVxdWVzdCBpcyBhIEJhc2U2NCBlbmNvZGVkIEpTT04gc3RyaW5nDQp3aXRoIHR3 byBwcm9wZXJ0aWVzLCB1cmkgYW5kIG1hZ2ljX3NpZ25hdHVyZS4gRXhhbXBsZToNCg0Kew0KICJ1 cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwNCiAibWFnaWNfc2lnbmF0dXJlIjogImFz ZGxra2xhZnNkamtsZHNmamxraj0iDQp9DQoNClJlc3BvbnNlOg0KSFRUUC8xLjEgMjAwIE9LDQpD b250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb24NCkNhY2hlLUNvbnRyb2w6IG5vLXN0b3JlDQoN CnsNCiAiYWNjZXNzX3Rva2VuIjoic3VwZXJzZWNyZXR0b2tlbiINCiAicHJlY29uZGl0aW9uX3Vy aSIsImh0dHA6Ly9nb29nbGUuY29tL29hdXRoL2F1dGhvcml6ZT9zdGF0ZT1vcGFxdWV2YWx1ZQ0K ICJjb2RlIiwibXlyYW5kb21jb2RlMTIzIg0KfQ0KDQpUaGUgYWNjZXNzIHRva2VuIHJlc3BvbnNl IGludHJvZHVjZXMgdHdvIG5ldyBvcHRpb25hbCBwcm9wZXJ0aWVzOg0KcHJlY29uZGl0aW9uX3Vy aSBhbmQgY29kZQ0KDQpUaGUgZXhpc3RlbmNlIG9mIGEgcHJlY29uZGl0aW9uX3VyaSBtZWFucyB0 aGUgY29uc3VtZXIgd2lsbCBiZQ0KcmVxdWlyZWQgdG8gcmVkaXJlY3QgdGhlIHVzZXIgdG8gdGhp cyB1cmkgaW4gb3JkZXIgdG8gY29tcGxldGUgdGhlDQphY3RpdmF0aW9uIG9mIHRoZSBwcm92aWRl ZCBhY2Nlc3MgdG9rZW4uDQoNClRoZSBwcmVjb25kaXRpb25fdXJpIHJlc291cmNlIGhhcyB0aGUg c2FtZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlDQpPQXV0aCAyLjAgV2ViIFNlcnZlciBjbGllbnQg cHJvZmlsZSB3aXRoIHRoZSDigJhzdGF0ZeKAmSBwcm9wZXJ0eSBiZWluZw0KdXNlZCB0byBtYWlu dGFpbiBzdGF0ZSBiZXR3ZWVuIHRoZSBhc3NlcnRpb24gcmVxdWVzdCBhbmQgdGhlIHVzZXINCnJl ZGlyZWN0LiBTdWNjZXNzZnVsIGFja25vd2xlZGdlbWVudCBvZiB0aGUgcHJlY29uZGl0aW9uIHJl c3VsdHMgaW4gYQ0KMzAyIHJlc3BvbnNlIHdpdGggdGhlIGNvZGUgcHJvdmlkZWQgaW4gdGhlIGFz c2VydGlvbiByZXNwb25zZSAoc2VlDQpleGFtcGxlIGJlbG93KS4NCg0KVGhlIGV4aXN0ZW5jZSBv ZiBhIGNvZGUgaXMgcmVxdWlyZWQgdXBvbiB0aGUgcHJlc2VuY2Ugb2YgYSBwcmVjb25kaXRpb25f dXJpLg0KDQpJZiBubyBwcmVjb25kaXRpb25fdXJpIGlzIHByb3ZpZGVkLCB0aGUgYWNjZXNzIHRv a2VuIHNob3VsZCBiZQ0KY29uc2lkZXJlZCBhY3RpdmUgYW5kIGltbWVkaWF0ZWx5IHVzYWJsZSBi YXJyaW5nIGFueSBwcm92aWRlciBzcGVjaWZpYw0KYmFjay1lbmQgYXV0aG9yaXphdGlvbiAoZS5n LiB1c2VyIGFjY2VwdGFuY2Ugb2YgcmVtb3RlIGZvbGxvdykuDQoNCjIpIGFjY2VzcyB0b2tlbiBy ZWNlaXZlZCBvcHRpb25hbCBwcmVjb25kaXRpb25fdXJpLiBJc3N1aW5nIHVzZXINCnJlZGlyZWN0 IHRvIHByZWNvbmRpdGlvbl91cmkgd2l0aCByZWRpcmVjdF91cmkuDQoNClJlcXVlc3Q6DQpHRVQg L29hdXRoL2F1dGhvcml6ZT9zdGF0ZT1vcGFxdWV2YWx1ZSZyZXNwb25zZV90eXBlPXRva2VuJmNs aWVudF9pZD1hY2N0OmRib3VuZHNAY2xpcXNldC5jb20mcmVkaXJlY3RfdXJpPWh0dHA6Ly9jbGlx c2V0LmNvbS9jYWxsYmFjaw0KSFRUUC8xLjENCkhvc3Q6IGdvb2dsZS5jb20NCg0KVXNlciBhY2tu b3dsZWRnZXMgdGhlIHByZWNvbmRpdGlvbi4gVGhpcyBjb3VsZCBiZSBhbnkgbnVtYmVyIG9mDQph Y3Rpdml0aWVzLCBpbmNsdWRpbmcgYXV0aGVudGljYXRpbmcuDQoNCg0KUmVzcG9uc2U6DQpIVFRQ LzEuMSAzMDIgRm91bmQNCkxvY2F0aW9uOiBodHRwOi8vY2xpcXNldC5jb20vY2FsbGJhY2s/Y29k ZT1teXJhbmRvbWNvZGUxMjMNCg0KMykgU3Vic2NyaXB0aW9uIGhhcyBiZWVuIGF1dGhvcml6ZWQu IFRvUyBoYXMgYmVlbiBhY2tub3dsZWRnZWQuIENvbXBldGUuDQoNClRoZSBjb25zdW1lciBpcyBh YmxlIHRvIGFjdGl2YXRlIHRoZSBhY2Nlc3NfdG9rZW4gYnkgY29uZmlybWluZyB0aGUNCmNvZGUg cHJvdmlkZWQgaW4gdGhlIHJlZGlyZWN0Lg0KDQpUaGlzIGZsb3cgb2ZmZXJzIHdoYXQgd2UgZmVl bCBhcmUgc2V2ZXJhbCBzaWduaWZpY2FudCBhZHZhbnRhZ2VzIG92ZXINCnRoZSBoeWJyaWQgYXBw cm9hY2guDQoNCjEpIFJlZGlyZWN0aW9uIGJlY29tZXMgb3B0aW9uYWwgYW5kIGlzIG9ubHkgcmVx dWlyZWQgd2hlbiB0aGUNCnByZWNvbmRpdGlvbl91cmkgaXMgZGVmaW5lZCBieSB0aGUgcHJvdmlk ZXIgaW4gdGhlIGFjY2VzcyB0b2tlbg0KcmVzcG9uc2UuDQoNCjIpIEZvciBwcm92aWRlcnMgd2hv IHJlcXVpcmUgVE9TIGFja25vd2xlZGdlbWVudCwgaXQgZW5hYmxlcw0KYWRkaXRpb25hbCBmbGV4 aWJpbGl0eSBpbiBob3cgdGhleSBnbyBhYm91dCBpdC4gRm9yIGV4YW1wbGUsIGlmIGENCnByb3Zp ZGVyIG9ubHkgcmVxdWlyZXMgVE9TIGFja25vd2xlZGdlbWVudCBvbiB0aGUgaW5pdGlhbCBzdWJz Y3JpcHRpb24NCnJlcXVlc3QgYnkgYSBnaXZlbiB1c2VyLCBzdWJzZXF1ZW50IHJlcXVlc3RzIHdp bGwgbm90IHByb3ZpZGUgYQ0KcHJlY29uZGl0aW9uX3VyaS4NCg0KMykgSXQgaXMgYWxzbyB3b3J0 aCBleHBsb3JpbmcgdGhpcyBmbG93IGFzIGEgc3VpdGFibGUgYW5kIG1vcmUNCmZsZXhpYmxlIGFs dGVybmF0aXZlIHRvIHRoZSB0cmFkaXRpb25hbCBXZWIgU2VydmVyIGZsb3cuDQoNCg0KUXVlc3Rp b25zPyBDb21tZW50cz8gU3VnZ2VzdGlvbnM/DQoNCg0KLS0NCmRhcnJlbiBib3VuZHMNCmRhcnJl bkBjbGlxc2V0LmNvbQ0K From Hannes.Tschofenig@gmx.net Thu Jul 29 04:20:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9381E28C143 for ; Thu, 29 Jul 2010 04:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNcwZdrKJeev for ; Thu, 29 Jul 2010 04:20:45 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id E6C8528C129 for ; Thu, 29 Jul 2010 04:20:44 -0700 (PDT) Received: (qmail invoked by alias); 29 Jul 2010 11:14:28 -0000 Received: from dhcp-85c8.meeting.ietf.org (EHLO [130.129.133.200]) [130.129.133.200] by mail.gmx.net (mp049) with SMTP; 29 Jul 2010 13:14:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX183y4BSg4o3g1PknIm3UlNtExnP/vuPIJNOSx6k+r p7jXuQgCtGmFEc Message-ID: <4C5162C5.8030905@gmx.net> Date: Thu, 29 Jul 2010 13:15:17 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: oauth@ietf.org References: <3D3C75174CB95F42AD6BCC56E5555B45028698A0@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45028698A0@FIESEXC015.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------090109030100030003090903" X-Y-GMX-Trusted: 0 Cc: saag@ietf.org, hasmat@ietf.org Subject: Re: [OAUTH-WG] OAuth Tutorial on Friday, 9am X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 11:20:45 -0000 This is a multi-part message in MIME format. --------------090109030100030003090903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The meeting room is 2.14 Amazon On 23.07.2010 11:23, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > Hi all, > > As mentioned in the meeting agenda Blaine and myself thought it would > be useful to schedule a tutorial about OAuth during the IETF week. > > The morning slot (9am till max 11:30am) on Friday seems to be good. > > I will organize a meeting room. Details will be provided later. > > Ciao > Hannes & Blaine > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------090109030100030003090903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The meeting room is 2.14 Amazon

On 23.07.2010 11:23, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
OAuth Tutorial on Friday, 9am

Hi all,

As mentioned in the meeting agenda Blaine and myself thought it would be useful to schedule a tutorial about OAuth during the IETF week.

The morning slot (9am till max 11:30am) on Friday seems to be good.

I will organize a meeting room. Details will be provided later.

Ciao
Hannes & Blaine 


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

--------------090109030100030003090903-- From gregory.ietf@gmail.com Thu Jul 29 04:49: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 907B728C142; Thu, 29 Jul 2010 04:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.842 X-Spam-Level: X-Spam-Status: No, score=-101.842 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqd1YdYsXj-2; Thu, 29 Jul 2010 04:49:34 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id C3E3728C12A; Thu, 29 Jul 2010 04:49:33 -0700 (PDT) Received: by ewy22 with SMTP id 22so85407ewy.31 for ; Thu, 29 Jul 2010 04:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=96EEQ34QofTKHHb68GLxJWD286Pt5v2VEO1T8t+9xQ8=; b=LaR61OuAq301x2ZNjogzv9grFeEiM/suvn4YdRI/85tKGkPxubeY0i8VAVun0ty7CE ZHsPrUP+ybHWxLUWlggxc0UQunaOspTMlqo8wRCL6BpBLc8gL2PY/nZfKzrUyDvMEhzP 7dZfnm/iJ/DLFlfxcP2kh/SxzzU8/iKVGRKtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=KfZEP6HiRo418sXX1TZymxLb3Gctuve5SCh4NYQQcFJypoE1i9qsH/uI1uS0Ze6PJS VtzBAX81AWLVVwKlg8eMxDOKy6NsYZnc9WCx2LbXBjI6xcF7IKKm1Attwt+M38JjpM1L jmb2n9q0VM1ua+BlElnBS5BFs0W5NS8XwJMj0= Received: by 10.14.29.70 with SMTP id h46mr3195285eea.94.1280404189995; Thu, 29 Jul 2010 04:49:49 -0700 (PDT) Received: from dhcp-26d2.meeting.ietf.org (dhcp-26d2.meeting.ietf.org [130.129.38.210]) by mx.google.com with ESMTPS id v8sm1124675eeh.14.2010.07.29.04.49.48 (version=SSLv3 cipher=RC4-MD5); Thu, 29 Jul 2010 04:49:48 -0700 (PDT) Message-ID: <4C516ADB.6010501@gmail.com> Date: Thu, 29 Jul 2010 04:49:47 -0700 From: Gregory Lebovitz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <3D3C75174CB95F42AD6BCC56E5555B45028698A0@FIESEXC015.nsn-intra.net> <4C5162C5.8030905@gmx.net> In-Reply-To: <4C5162C5.8030905@gmx.net> Content-Type: multipart/alternative; boundary="------------020208060804020405020404" X-Mailman-Approved-At: Thu, 29 Jul 2010 04:50:12 -0700 Cc: hasmat@ietf.org, oauth@ietf.org, saag@ietf.org Subject: Re: [OAUTH-WG] [saag] OAuth Tutorial on Friday, 9am X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 11:49:35 -0000 This is a multi-part message in MIME format. --------------020208060804020405020404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hannes, Will the session be recorded, i.e. audio archive and notes/minutes created? I think this would be VERY useful. Gregory. On 7/29/10 4:15 AM, Hannes Tschofenig wrote: > The meeting room is 2.14 Amazon > > On 23.07.2010 11:23, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> >> Hi all, >> >> As mentioned in the meeting agenda Blaine and myself thought it would >> be useful to schedule a tutorial about OAuth during the IETF week. >> >> The morning slot (9am till max 11:30am) on Friday seems to be good. >> >> I will organize a meeting room. Details will be provided later. >> >> Ciao >> Hannes & Blaine >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- ~~~~~~~~~~~~~~ IETF related Email from Gregory Lebovitz Juniper Networks --------------020208060804020405020404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hannes,
Will the session be recorded, i.e. audio archive and notes/minutes created? I think this would be VERY useful.

Gregory.

On 7/29/10 4:15 AM, Hannes Tschofenig wrote:
The meeting room is 2.14 Amazon

On 23.07.2010 11:23, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
OAuth Tutorial on Friday, 9am

Hi all,

As mentioned in the meeting agenda Blaine and myself thought it would be useful to schedule a tutorial about OAuth during the IETF week.

The morning slot (9am till max 11:30am) on Friday seems to be good.

I will organize a meeting room. Details will be provided later.

Ciao
Hannes & Blaine 


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


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


-- 
~~~~~~~~~~~~~~
IETF related Email from
Gregory Lebovitz
Juniper Networks
--------------020208060804020405020404-- From darren@cliqset.com Thu Jul 29 08:32:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4760F3A690F for ; Thu, 29 Jul 2010 08:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsS5keLt1N7R for ; Thu, 29 Jul 2010 08:32:10 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 9B8AD3A69FD for ; Thu, 29 Jul 2010 08:32:04 -0700 (PDT) Received: by yxj4 with SMTP id 4so194118yxj.31 for ; Thu, 29 Jul 2010 08:32:27 -0700 (PDT) Received: by 10.101.11.29 with SMTP id o29mr307629ani.151.1280417547757; Thu, 29 Jul 2010 08:32:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.7.19 with HTTP; Thu, 29 Jul 2010 08:32:07 -0700 (PDT) In-Reply-To: <4C512248.1080707@lodderstedt.net> References: <4C512248.1080707@lodderstedt.net> From: Darren Bounds Date: Thu, 29 Jul 2010 11:32:07 -0400 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: pubsubhubbub@googlegroups.com, oauth@ietf.org, federated-social-web@googlegroups.com Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 15:32:12 -0000 Torsten, The URI represents an end-user at a domain. Through this assertion the provider is able to verify the magic signature and thus confirm user dbounds at host cliqset.com has requested an access token. References: http://code.google.com/p/webfinger/wiki/WebFingerProtocol http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.html http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.ht= ml On Thu, Jul 29, 2010 at 2:40 AM, Torsten Lodderstedt wrote: > Darren, > > I have got some questions regarding your posting, esp. the assertion. >> >> 1) cliqset.com would like to request an access token from google.com. >> Sends a request with grant_type=3Dassertion. >> >> Request: >> POST /token HTTP/1.1 >> Host: google.com >> Content-Type: application/x-www-form-urlencoded >> >> grant_type=3Dassertion&assertion_type=3Dhttp://webfinger.org/& >> >> assertion=3DeyJ1cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwibWFnaWNfc2ln= bmF0dXJlIjogImFzZGxra2xhZnNkamtsZHNmamxraj0ifQ=3D=3D >> >> The assertion value in the request is a Base64 encoded JSON string >> with two properties, uri and magic_signature. Example: >> >> { >> =C2=A0"uri": "acct:dbounds@cliqset.com", >> =C2=A0"magic_signature": "asdlkklafsdjkldsfjlkj=3D" >> } >> >> > > What is the meaning of the assertion? Does the uri represent an end-user = or > the client? > How does the assertion represent an authorization, given that you try to > make end-user authorization via browser redirect an optional step. > > regards, > Torsten, > > --=20 darren bounds darren@cliqset.com From darren@cliqset.com Thu Jul 29 09:43: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 D244C28C12D for ; Thu, 29 Jul 2010 09:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=-1.206, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiU5p-fl1lmf for ; Thu, 29 Jul 2010 09:43:31 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 800EF28C218 for ; Thu, 29 Jul 2010 09:43:31 -0700 (PDT) Received: by gwaa18 with SMTP id a18so235912gwa.31 for ; Thu, 29 Jul 2010 09:43:55 -0700 (PDT) Received: by 10.101.183.16 with SMTP id k16mr431319anp.120.1280421835232; Thu, 29 Jul 2010 09:43:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.7.19 with HTTP; Thu, 29 Jul 2010 09:43:35 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> From: Darren Bounds Date: Thu, 29 Jul 2010 12:43:35 -0400 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 16:43:32 -0000 Thanks James. Comments are inline. > It sounds like you want to use OAuth2 to insert an human/HTML interaction= into a app/Atom exchange. The proposal was designed to provide a single flow that would accommodate 0 or more human interaction requirements. Additionally, the scope should not limited to access protected feed but rather any protected resource. While the example usecase illustrated access to a protected feed, you can imagine this being used in more traditional flow scenarios, such as that of the Web Server client profile. For example, if a user has already negotiated an access token in the proposed manner, additional access tokens *could* be granted on the user's behalf without the requirement of a redirect. > OAuth2 can do that. > > You also want to use a direct OAuth2 flow for access control to the feed. > > Your "precondition_uri" addition to the token response is an attempt to c= ombine the 2 OAuth2 flows. I'd say it's an attempt to create a new flow that's more flexible and suitable for the type of interactions DiSo requires. > An alternative would be to run the 2 OAuth2 flows sequentially. > 1. app use a direct OAuth2 flow (eg the assertion flow) to get a token; > 2. app tries to get feed with token, but server demands a user-delegation= OAuth2 flow; > 3. app redirects user to service; Terms of Service are shown; user redire= cted back; > 4. app tries to get feed again, which succeeds this time. > > This example illustrates that OAuth2 discovery needs to let a service > explicitly indicate whether a direct and/or user-delegation flow is requi= red. > For instance, a "WWW-Authenticate: OAuth2" response could define 2 parame= ters: > 'user-uri' and 'token-uri'. If only one is present, only the correspondin= g mode > is useful in this interaction. Interesting. > Another interesting facet of this example is what token the app uses > at step 4. Is it the token the app got in the first OAuth2 flow (step 1), > or the token from the second OAuth2 flow (step 3)? > > Presumably the second token overrides the first. > In this example, however, it may be sufficient to keep using the first to= ken. > OAuth2 doesn=E2=80=99t need to make returning a token mandatory -- it is = not > always required in a user-delegation flow. Also, when the user delegation flow is executed (step 3), how does the provider associate acknowledgement of the ToS with the assertion grant (step 1)? --=20 darren bounds darren@cliqset.com From torsten@lodderstedt.net Thu Jul 29 10:05:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101E128C0E4 for ; Thu, 29 Jul 2010 10:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.147, 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 CoPqp7P+58nO for ; Thu, 29 Jul 2010 10:05:10 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id CAD6F28C11D for ; Thu, 29 Jul 2010 10:05:09 -0700 (PDT) Received: from p4ffd0fa6.dip.t-dialin.net ([79.253.15.166] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OeWXw-00008h-1q; Thu, 29 Jul 2010 19:05:28 +0200 Message-ID: <4C51B4C9.3030304@lodderstedt.net> Date: Thu, 29 Jul 2010 19:05:13 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Darren Bounds References: <4C512248.1080707@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: pubsubhubbub@googlegroups.com, oauth@ietf.org, federated-social-web@googlegroups.com Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 17:05:12 -0000 So this assertion is conceptually equivalent to a case where the client would have sent username and password of dbounds at the authz server. Is this correct? Am 29.07.2010 17:32, schrieb Darren Bounds: > Torsten, > > The URI represents an end-user at a domain. Through this assertion the > provider is able to verify the magic signature and thus confirm user > dbounds at host cliqset.com has requested an access token. > > References: > http://code.google.com/p/webfinger/wiki/WebFingerProtocol > http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.html > http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html > > On Thu, Jul 29, 2010 at 2:40 AM, Torsten Lodderstedt > wrote: > >> Darren, >> >> I have got some questions regarding your posting, esp. the assertion. >> >>> 1) cliqset.com would like to request an access token from google.com. >>> Sends a request with grant_type=assertion. >>> >>> Request: >>> POST /token HTTP/1.1 >>> Host: google.com >>> Content-Type: application/x-www-form-urlencoded >>> >>> grant_type=assertion&assertion_type=http://webfinger.org/& >>> >>> assertion=eyJ1cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwibWFnaWNfc2lnbmF0dXJlIjogImFzZGxra2xhZnNkamtsZHNmamxraj0ifQ== >>> >>> The assertion value in the request is a Base64 encoded JSON string >>> with two properties, uri and magic_signature. Example: >>> >>> { >>> "uri": "acct:dbounds@cliqset.com", >>> "magic_signature": "asdlkklafsdjkldsfjlkj=" >>> } >>> >>> >>> >> What is the meaning of the assertion? Does the uri represent an end-user or >> the client? >> How does the assertion represent an authorization, given that you try to >> make end-user authorization via browser redirect an optional step. >> >> regards, >> Torsten, >> >> >> > > > From darren@cliqset.com Thu Jul 29 11:36: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 03A203A69C2 for ; Thu, 29 Jul 2010 11:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp1Byth9gwAh for ; Thu, 29 Jul 2010 11:36:28 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id A7EB33A698E for ; Thu, 29 Jul 2010 11:36:28 -0700 (PDT) Received: by gxk1 with SMTP id 1so279471gxk.31 for ; Thu, 29 Jul 2010 11:36:52 -0700 (PDT) Received: by 10.101.183.16 with SMTP id k16mr599148anp.120.1280428612255; Thu, 29 Jul 2010 11:36:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.7.19 with HTTP; Thu, 29 Jul 2010 11:36:32 -0700 (PDT) In-Reply-To: <4C51B4C9.3030304@lodderstedt.net> References: <4C512248.1080707@lodderstedt.net> <4C51B4C9.3030304@lodderstedt.net> From: Darren Bounds Date: Thu, 29 Jul 2010 14:36:32 -0400 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: pubsubhubbub@googlegroups.com, oauth@ietf.org, federated-social-web@googlegroups.com Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 18:36:30 -0000 Yes, but with no requirement that the user have an account on the provider. It is merely an assertion the UserA on HostX made the request. On Thu, Jul 29, 2010 at 1:05 PM, Torsten Lodderstedt wrote: > So this assertion is conceptually equivalent to a case where the client > would have sent username and password of dbounds at the authz server. Is > this correct? > > Am 29.07.2010 17:32, schrieb Darren Bounds: >> >> Torsten, >> >> The URI represents an end-user at a domain. Through this assertion the >> provider is able to verify the magic signature and thus confirm user >> dbounds at host cliqset.com has requested an access token. >> >> References: >> http://code.google.com/p/webfinger/wiki/WebFingerProtocol >> >> http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.h= tml >> >> http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00= .html >> >> On Thu, Jul 29, 2010 at 2:40 AM, Torsten Lodderstedt >> =C2=A0wrote: >> >>> >>> Darren, >>> >>> I have got some questions regarding your posting, esp. the assertion. >>> >>>> >>>> 1) cliqset.com would like to request an access token from google.com. >>>> Sends a request with grant_type=3Dassertion. >>>> >>>> Request: >>>> POST /token HTTP/1.1 >>>> Host: google.com >>>> Content-Type: application/x-www-form-urlencoded >>>> >>>> grant_type=3Dassertion&assertion_type=3Dhttp://webfinger.org/& >>>> >>>> >>>> assertion=3DeyJ1cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwibWFnaWNfc2= lnbmF0dXJlIjogImFzZGxra2xhZnNkamtsZHNmamxraj0ifQ=3D=3D >>>> >>>> The assertion value in the request is a Base64 encoded JSON string >>>> with two properties, uri and magic_signature. Example: >>>> >>>> { >>>> =C2=A0"uri": "acct:dbounds@cliqset.com", >>>> =C2=A0"magic_signature": "asdlkklafsdjkldsfjlkj=3D" >>>> } >>>> >>>> >>>> >>> >>> What is the meaning of the assertion? Does the uri represent an end-use= r >>> or >>> the client? >>> How does the assertion represent an authorization, given that you try t= o >>> make end-user authorization via browser redirect an optional step. >>> >>> regards, >>> Torsten, >>> >>> >>> >> >> >> > > --=20 darren bounds darren@cliqset.com From gffletch@aol.com Thu Jul 29 11:51:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510503A69A5 for ; Thu, 29 Jul 2010 11:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MP3+KPm5Jd72 for ; Thu, 29 Jul 2010 11:51:48 -0700 (PDT) Received: from imr-da05.mx.aol.com (imr-3.mx.aol.com [205.188.105.147]) by core3.amsl.com (Postfix) with ESMTP id 083363A689C for ; Thu, 29 Jul 2010 11:51:47 -0700 (PDT) Received: from mtaout-ma04.r1000.mx.aol.com (mtaout-ma04.r1000.mx.aol.com [172.29.41.4]) by imr-da05.mx.aol.com (8.14.1/8.14.1) with ESMTP id o6TIpmBO018179; Thu, 29 Jul 2010 14:51:50 -0400 Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma04.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2A5B6E000083; Thu, 29 Jul 2010 14:51:49 -0400 (EDT) Message-ID: <4C51CDC4.6060400@aol.com> Date: Thu, 29 Jul 2010 14:51:48 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Darren Bounds References: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000400020808050008020601" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:377572608:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29044c51cdc52aa4 X-AOL-IP: 10.181.183.108 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 18:51:50 -0000 This is a multi-part message in MIME format. --------------000400020808050008020601 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Question. In the proposal, how does google know that the request is being presented by "acct:dbounds@cliqset.com"? Is the secret used for the magic signature in the first request, the user's private key? So in this case cliqset.com would have dbounds' private key in order to generate the signature? (This seems to be implied from the oauth-push doc; at least from my reading). I love the idea of allowing access to protected resources by individuals that do not have an "account" at the provider. This is a critical next step in the set of capabilities supported by OAuth and other technologies. However, I'm not quite show how the provider verifies the presented user identifier. Meaning, how does the provider protect against me specifying someone else's identifier and getting access to the protected resource. Thanks, George On 7/29/10 12:43 PM, Darren Bounds wrote: > Thanks James. Comments are inline. > > >> It sounds like you want to use OAuth2 to insert an human/HTML interaction into a app/Atom exchange. >> > The proposal was designed to provide a single flow that would > accommodate 0 or more human interaction requirements. Additionally, > the scope should not limited to access protected feed but rather any > protected resource. > > While the example usecase illustrated access to a protected feed, you > can imagine this being used in more traditional flow scenarios, such > as that of the Web Server client profile. > > For example, if a user has already negotiated an access token in the > proposed manner, additional access tokens *could* be granted on the > user's behalf without the requirement of a redirect. > > > >> OAuth2 can do that. >> >> You also want to use a direct OAuth2 flow for access control to the feed. >> >> Your "precondition_uri" addition to the token response is an attempt to combine the 2 OAuth2 flows. >> > I'd say it's an attempt to create a new flow that's more flexible and > suitable for the type of interactions DiSo requires. > > > >> An alternative would be to run the 2 OAuth2 flows sequentially. >> 1. app use a direct OAuth2 flow (eg the assertion flow) to get a token; >> 2. app tries to get feed with token, but server demands a user-delegation OAuth2 flow; >> 3. app redirects user to service; Terms of Service are shown; user redirected back; >> 4. app tries to get feed again, which succeeds this time. >> >> This example illustrates that OAuth2 discovery needs to let a service >> explicitly indicate whether a direct and/or user-delegation flow is required. >> For instance, a "WWW-Authenticate: OAuth2" response could define 2 parameters: >> 'user-uri' and 'token-uri'. If only one is present, only the corresponding mode >> is useful in this interaction. >> > Interesting. > > > >> Another interesting facet of this example is what token the app uses >> at step 4. Is it the token the app got in the first OAuth2 flow (step 1), >> or the token from the second OAuth2 flow (step 3)? >> >> Presumably the second token overrides the first. >> In this example, however, it may be sufficient to keep using the first token. >> OAuth2 doesn’t need to make returning a token mandatory -- it is not >> always required in a user-delegation flow. >> > Also, when the user delegation flow is executed (step 3), how does the > provider associate acknowledgement of the ToS with the assertion grant > (step 1)? > > > --------------000400020808050008020601 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Question.  In the proposal, how does google know that the request is being presented by "acct:dbounds@cliqset.com"? Is the secret used for the magic signature in the first request, the user's private key? So in this case cliqset.com would have dbounds' private key in order to generate the signature? (This seems to be implied from the oauth-push doc; at least from my reading).

I love the idea of allowing access to protected resources by individuals that do not have an "account" at the provider. This is a critical next step in the set of capabilities supported by OAuth and other technologies. However, I'm not quite show how the provider verifies the presented user identifier. Meaning, how does the provider protect against me specifying someone else's identifier and getting access to the protected resource.

Thanks,
George

On 7/29/10 12:43 PM, Darren Bounds wrote: 
Thanks James. Comments are inline.

  
It sounds like you want to use OAuth2 to insert an human/HTML interaction into a app/Atom exchange.
    
The proposal was designed to provide a single flow that would
accommodate 0 or more human interaction requirements. Additionally,
the scope should not limited to access protected feed but rather any
protected resource.

While the example usecase illustrated access to a protected feed, you
can imagine this being used in more traditional flow scenarios, such
as that of the Web Server client profile.

For example, if a user has already negotiated an access token in the
proposed manner, additional access tokens *could* be granted on the
user's behalf without the requirement of a redirect.


  
OAuth2 can do that.

You also want to use a direct OAuth2 flow for access control to the feed.

Your "precondition_uri" addition to the token response is an attempt to combine the 2 OAuth2 flows.
    
I'd say it's an attempt to create a new flow that's more flexible and
suitable for the type of interactions DiSo requires.


  
An alternative would be to run the 2 OAuth2 flows sequentially.
1. app use a direct OAuth2 flow (eg the assertion flow) to get a token;
2. app tries to get feed with token, but server demands a user-delegation OAuth2 flow;
3. app redirects user to service; Terms of Service are shown; user redirected back;
4. app tries to get feed again, which succeeds this time.

This example illustrates that OAuth2 discovery needs to let a service
explicitly indicate whether a direct and/or user-delegation flow is required.
For instance, a "WWW-Authenticate: OAuth2" response could define 2 parameters:
'user-uri' and 'token-uri'. If only one is present, only the corresponding mode
is useful in this interaction.
    
Interesting.


  
Another interesting facet of this example is what token the app uses
at step 4. Is it the token the app got in the first OAuth2 flow (step 1),
or the token from the second OAuth2 flow (step 3)?

Presumably the second token overrides the first.
In this example, however, it may be sufficient to keep using the first token.
OAuth2 doesn’t need to make returning a token mandatory -- it is not
always required in a user-delegation flow.
    
Also, when the user delegation flow is executed (step 3), how does the
provider associate acknowledgement of the ToS with the assertion grant
(step 1)?
--------------000400020808050008020601-- From darren@cliqset.com Thu Jul 29 12:15: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 2EE233A6A14 for ; Thu, 29 Jul 2010 12:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCjgTRElsCdh for ; Thu, 29 Jul 2010 12:15:14 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 7CEA93A68B5 for ; Thu, 29 Jul 2010 12:14:57 -0700 (PDT) Received: by gyg8 with SMTP id 8so296109gyg.31 for ; Thu, 29 Jul 2010 12:15:21 -0700 (PDT) Received: by 10.101.139.6 with SMTP id r6mr687814ann.74.1280430921258; Thu, 29 Jul 2010 12:15:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.7.19 with HTTP; Thu, 29 Jul 2010 12:15:01 -0700 (PDT) In-Reply-To: <4C51CDC4.6060400@aol.com> References: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> <4C51CDC4.6060400@aol.com> From: Darren Bounds Date: Thu, 29 Jul 2010 15:15:01 -0400 Message-ID: To: George Fletcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 19:15:23 -0000 Thanks George. My response is inline. On Thu, Jul 29, 2010 at 2:51 PM, George Fletcher wrote: > Question.=C2=A0 In the proposal, how does google know that the request is= being > presented by "acct:dbounds@cliqset.com"? Is the secret used for the magic > signature in the first request, the user's private key? So in this case > cliqset.com would have dbounds' private key in order to generate the > signature? (This seems to be implied from the oauth-push doc; at least fr= om > my reading). Google would perform a WebFinger on the acct: URI, discovery XRD (http://cliqset.com/etc/webfinger/?q=3Dacct:dbounds@cliqset.com). The XRD would present my Magic Signature Key which would be used to verification the signature in the assertion. > I love the idea of allowing access to protected resources by individuals > that do not have an "account" at the provider. This is a critical next st= ep > in the set of capabilities supported by OAuth and other technologies. > However, I'm not quite show how the provider verifies the presented user > identifier. Meaning, how does the provider protect against me specifying > someone else's identifier and getting access to the protected resource. The actions mentioned above ensure the assertion was made by cliqset.com and not spoofed. References: http://code.google.com/p/webfinger/wiki/WebFingerProtocol http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.ht= ml --=20 darren bounds darren@cliqset.com From torsten@lodderstedt.net Thu Jul 29 13:47:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4CAC3A68E3 for ; Thu, 29 Jul 2010 13:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.142, 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 rE5OP24QULJZ for ; Thu, 29 Jul 2010 13:47:31 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by core3.amsl.com (Postfix) with ESMTP id CA73B3A68C5 for ; Thu, 29 Jul 2010 13:47:30 -0700 (PDT) Received: from p4ffd0fa6.dip.t-dialin.net ([79.253.15.166] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Oea19-0005co-CX; Thu, 29 Jul 2010 22:47:51 +0200 Message-ID: <4C51E8EC.7090705@lodderstedt.net> Date: Thu, 29 Jul 2010 22:47:40 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Darren Bounds References: <4C512248.1080707@lodderstedt.net> <4C51B4C9.3030304@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: pubsubhubbub@googlegroups.com, oauth@ietf.org, federated-social-web@googlegroups.com Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 20:47:33 -0000 So what the value of that assertion? The authz server cannot authenticate the user (probably not even identify). Or do you assume some kind of federation between the two domains? Am 29.07.2010 20:36, schrieb Darren Bounds: > Yes, but with no requirement that the user have an account on the > provider. It is merely an assertion the UserA on HostX made the > request. > > On Thu, Jul 29, 2010 at 1:05 PM, Torsten Lodderstedt > wrote: > >> So this assertion is conceptually equivalent to a case where the client >> would have sent username and password of dbounds at the authz server. Is >> this correct? >> >> Am 29.07.2010 17:32, schrieb Darren Bounds: >> >>> Torsten, >>> >>> The URI represents an end-user at a domain. Through this assertion the >>> provider is able to verify the magic signature and thus confirm user >>> dbounds at host cliqset.com has requested an access token. >>> >>> References: >>> http://code.google.com/p/webfinger/wiki/WebFingerProtocol >>> >>> http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.html >>> >>> http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html >>> >>> On Thu, Jul 29, 2010 at 2:40 AM, Torsten Lodderstedt >>> wrote: >>> >>> >>>> Darren, >>>> >>>> I have got some questions regarding your posting, esp. the assertion. >>>> >>>> >>>>> 1) cliqset.com would like to request an access token from google.com. >>>>> Sends a request with grant_type=assertion. >>>>> >>>>> Request: >>>>> POST /token HTTP/1.1 >>>>> Host: google.com >>>>> Content-Type: application/x-www-form-urlencoded >>>>> >>>>> grant_type=assertion&assertion_type=http://webfinger.org/& >>>>> >>>>> >>>>> assertion=eyJ1cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwibWFnaWNfc2lnbmF0dXJlIjogImFzZGxra2xhZnNkamtsZHNmamxraj0ifQ== >>>>> >>>>> The assertion value in the request is a Base64 encoded JSON string >>>>> with two properties, uri and magic_signature. Example: >>>>> >>>>> { >>>>> "uri": "acct:dbounds@cliqset.com", >>>>> "magic_signature": "asdlkklafsdjkldsfjlkj=" >>>>> } >>>>> >>>>> >>>>> >>>>> >>>> What is the meaning of the assertion? Does the uri represent an end-user >>>> or >>>> the client? >>>> How does the assertion represent an authorization, given that you try to >>>> make end-user authorization via browser redirect an optional step. >>>> >>>> regards, >>>> Torsten, >>>> >>>> >>>> >>>> >>> >>> >>> >> >> > > > From darren@cliqset.com Thu Jul 29 14:13:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337F13A691D for ; Thu, 29 Jul 2010 14:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dREKxun6PWvL for ; Thu, 29 Jul 2010 14:13:45 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 8C1643A6918 for ; Thu, 29 Jul 2010 14:13:45 -0700 (PDT) Received: by gxk1 with SMTP id 1so346384gxk.31 for ; Thu, 29 Jul 2010 14:14:09 -0700 (PDT) Received: by 10.101.139.6 with SMTP id r6mr878288ann.74.1280438049201; Thu, 29 Jul 2010 14:14:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.7.19 with HTTP; Thu, 29 Jul 2010 14:13:49 -0700 (PDT) In-Reply-To: <4C51E8EC.7090705@lodderstedt.net> References: <4C512248.1080707@lodderstedt.net> <4C51B4C9.3030304@lodderstedt.net> <4C51E8EC.7090705@lodderstedt.net> From: Darren Bounds Date: Thu, 29 Jul 2010 17:13:49 -0400 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: pubsubhubbub@googlegroups.com, oauth@ietf.org, federated-social-web@googlegroups.com Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2010 21:13:47 -0000 Torsten, Yes. Federation is the basis for proposal. Federated social interactions. The value is that the provider is able to verify the assertion that user dbounds on host cliqset.com has requested access token which it will use to access and/or request access to protected resources within the google.com realm, such as remote friending/following. The provider does not need to, or necessarily want to authenticate the remote user. It merely needs to verify the assertion in order to confirm the origin user/host. References: http://status.net/2010/07/13/what-is-the-federated-social-web http://status.net/2010/07/14/features-of-a-federated-social-web -- darren bounds darren@cliqset.com On Thu, Jul 29, 2010 at 4:47 PM, Torsten Lodderstedt wrote: > So what the value of that assertion? The authz server cannot authenticate > the user (probably not even identify). Or do you assume some kind of > federation between the two domains? > > Am 29.07.2010 20:36, schrieb Darren Bounds: >> >> Yes, but with no requirement that the user have an account on the >> provider. It is merely an assertion the UserA on HostX made the >> request. >> >> On Thu, Jul 29, 2010 at 1:05 PM, Torsten Lodderstedt >> =C2=A0wrote: >> >>> >>> So this assertion is conceptually equivalent to a case where the client >>> would have sent username and password of dbounds at the authz server. I= s >>> this correct? >>> >>> Am 29.07.2010 17:32, schrieb Darren Bounds: >>> >>>> >>>> Torsten, >>>> >>>> The URI represents an end-user at a domain. Through this assertion the >>>> provider is able to verify the magic signature and thus confirm user >>>> dbounds at host cliqset.com has requested an access token. >>>> >>>> References: >>>> http://code.google.com/p/webfinger/wiki/WebFingerProtocol >>>> >>>> >>>> http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00= .html >>>> >>>> >>>> http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-= 00.html >>>> >>>> On Thu, Jul 29, 2010 at 2:40 AM, Torsten Lodderstedt >>>> =C2=A0 =C2=A0wrote: >>>> >>>> >>>>> >>>>> Darren, >>>>> >>>>> I have got some questions regarding your posting, esp. the assertion. >>>>> >>>>> >>>>>> >>>>>> 1) cliqset.com would like to request an access token from google.com= . >>>>>> Sends a request with grant_type=3Dassertion. >>>>>> >>>>>> Request: >>>>>> POST /token HTTP/1.1 >>>>>> Host: google.com >>>>>> Content-Type: application/x-www-form-urlencoded >>>>>> >>>>>> grant_type=3Dassertion&assertion_type=3Dhttp://webfinger.org/& >>>>>> >>>>>> >>>>>> >>>>>> assertion=3DeyJ1cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwibWFnaWNf= c2lnbmF0dXJlIjogImFzZGxra2xhZnNkamtsZHNmamxraj0ifQ=3D=3D >>>>>> >>>>>> The assertion value in the request is a Base64 encoded JSON string >>>>>> with two properties, uri and magic_signature. Example: >>>>>> >>>>>> { >>>>>> =C2=A0"uri": "acct:dbounds@cliqset.com", >>>>>> =C2=A0"magic_signature": "asdlkklafsdjkldsfjlkj=3D" >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> What is the meaning of the assertion? Does the uri represent an >>>>> end-user >>>>> or >>>>> the client? >>>>> How does the assertion represent an authorization, given that you try >>>>> to >>>>> make end-user authorization via browser redirect an optional step. >>>>> >>>>> regards, >>>>> Torsten, >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > From stpeter@stpeter.im Fri Jul 30 00:14: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 B73BF3A6A8A for ; Fri, 30 Jul 2010 00:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 wCc6K3IFgacQ for ; Fri, 30 Jul 2010 00:14:06 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C73633A6899 for ; Fri, 30 Jul 2010 00:14:05 -0700 (PDT) Received: from dhcp-23fb.meeting.ietf.org (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A6EB4400EE for ; Fri, 30 Jul 2010 01:14:30 -0600 (MDT) Message-ID: <4C527BD4.4080104@stpeter.im> Date: Fri, 30 Jul 2010 09:14:28 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: oauth@ietf.org References: <3D3C75174CB95F42AD6BCC56E5555B45028698A0@FIESEXC015.nsn-intra.net> <4C5162C5.8030905@gmx.net> <4C516ADB.6010501@gmail.com> In-Reply-To: <4C516ADB.6010501@gmail.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] [saag] OAuth Tutorial on Friday, 9am X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 07:14:08 -0000 I see no recording equipment in the room. On 7/29/10 1:49 PM, Gregory Lebovitz wrote: > Hannes, > Will the session be recorded, i.e. audio archive and notes/minutes > created? I think this would be VERY useful. > > Gregory. > > On 7/29/10 4:15 AM, Hannes Tschofenig wrote: >> The meeting room is 2.14 Amazon >> >> On 23.07.2010 11:23, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>> >>> Hi all, >>> >>> As mentioned in the meeting agenda Blaine and myself thought it would >>> be useful to schedule a tutorial about OAuth during the IETF week. >>> >>> The morning slot (9am till max 11:30am) on Friday seems to be good. >>> >>> I will organize a meeting room. Details will be provided later. >>> >>> Ciao >>> Hannes & Blaine >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> From James.H.Manger@team.telstra.com Fri Jul 30 00:20:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C095D28C1FF for ; Fri, 30 Jul 2010 00:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.486 X-Spam-Level: X-Spam-Status: No, score=-0.486 tagged_above=-999 required=5 tests=[AWL=0.415, 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 Tc466RpURo7j for ; Fri, 30 Jul 2010 00:20:39 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 670883A6A91 for ; Fri, 30 Jul 2010 00:20:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,285,1278252000"; d="scan'208";a="7015846" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 30 Jul 2010 17:20:58 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6058"; a="5091739" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcdvi.tcif.telstra.com.au with ESMTP; 30 Jul 2010 17:21:00 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Fri, 30 Jul 2010 17:21:00 +1000 From: "Manger, James H" To: Darren Bounds , "oauth@ietf.org" Date: Fri, 30 Jul 2010 17:20:59 +1000 Thread-Topic: [OAUTH-WG] OAuth & Protected feeds Thread-Index: AcsvPT2yR/rNTtU+QeePqgKsds/24QAdNU3w Message-ID: <255B9BB34FB7D647A506DC292726F6E11267EC8194@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 07:20:40 -0000 RGFycmVuLA0KDQo+PiBZb3VyICJwcmVjb25kaXRpb25fdXJpIiBhZGRpdGlvbiB0byB0aGUgdG9r ZW4gcmVzcG9uc2UgaXMNCj4+IGFuIGF0dGVtcHQgdG8gY29tYmluZSB0aGUgMiBPQXV0aDIgZmxv d3MuDQoNCj4gSSdkIHNheSBpdCdzIGFuIGF0dGVtcHQgdG8gY3JlYXRlIGEgbmV3IGZsb3cgdGhh dCdzIG1vcmUgZmxleGlibGUgYW5kDQo+IHN1aXRhYmxlIGZvciB0aGUgdHlwZSBvZiBpbnRlcmFj dGlvbnMgRGlTbyByZXF1aXJlcy4NCg0KcHJlY29uZGl0aW9uX3VyaSBzZWVtcyB0byBhZGRyZXNz IGEgcmVxdWlyZW1lbnQgZm9yIG9wdGlvbmFsIGh1bWFuIGludGVyYWN0aW9uDQp3aGVuIGFuIGFw cCBzdGFydHMgYWNjZXNzaW5nIGEgcHJvdGVjdGVkIHJlc291cmNlLg0KQSBzb2x1dGlvbiB0aGF0 IGNoYW5nZXMgdGhlIHRva2VuIHJlc3BvbnNlIGNhbiBvbmx5IGFkZCB0aGUgaHVtYW4gaW50ZXJh Y3Rpb246DQphKSBpZiBPQXV0aCBpcyB1c2VkIGZvciBkaXJlY3QgYXV0aGVudGljYXRpb24vYXV0 aG9yaXphdGlvbiBvZiB0aGUgYXBwOyBhbmQNCmIpIGF0IHRoZSBpbnN0YW50IGluIHRpbWUgd2hl biB0aGUgYXBwIGRvZXMgaXRzIGRpcmVjdCBPQXV0aCBmbG93Lg0KSSdtIG5vdGUgc3VyZSBhIHJl cXVpcmVtZW50IGZvciBodW1hbiBpbnRlcmFjdGlvbiB3aWxsIG5lY2Vzc2FyaWx5IGJlIHRpZWQg dG8NCmVpdGhlciBvZiB0aG9zZSBjb25kaXRpb25zLCB3aGljaCBpcyB3aHkgYW4gaW5kZXBlbmRl bnQgT0F1dGgyIGZsb3cgZm9yDQp0aGUgaHVtYW4gaW50ZXJhY3Rpb24gaXMgYXBwZWFsaW5nLg0K DQoNCj4+IEFuIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvIHJ1biB0aGUgMiBPQXV0aDIgZmxvd3Mg c2VxdWVudGlhbGx5Lg0KPj4gMS4gYXBwIHVzZSBhIGRpcmVjdCBPQXV0aDIgZmxvdyAoZWcgdGhl IGFzc2VydGlvbiBmbG93KSB0byBnZXQgYSB0b2tlbjsNCj4+IDIuIGFwcCB0cmllcyB0byBnZXQg ZmVlZCB3aXRoIHRva2VuLCBidXQgc2VydmVyIGRlbWFuZHMgYSB1c2VyLWRlbGVnYXRpb24gT0F1 dGgyIGZsb3c7DQo+PiAzLiBhcHAgcmVkaXJlY3RzIHVzZXIgdG8gc2VydmljZTsgVGVybXMgb2Yg U2VydmljZSBhcmUgc2hvd247IHVzZXIgcmVkaXJlY3RlZCBiYWNrOw0KPj4gNC4gYXBwIHRyaWVz IHRvIGdldCBmZWVkIGFnYWluLCB3aGljaCBzdWNjZWVkcyB0aGlzIHRpbWUuDQo+Pg0KPj4gVGhp cyBleGFtcGxlIGlsbHVzdHJhdGVzIHRoYXQgT0F1dGgyIGRpc2NvdmVyeSBuZWVkcyB0byBsZXQg YSBzZXJ2aWNlDQo+PiBleHBsaWNpdGx5IGluZGljYXRlIHdoZXRoZXIgYSBkaXJlY3QgYW5kL29y IHVzZXItZGVsZWdhdGlvbiBmbG93IGlzIHJlcXVpcmVkLg0KPj4gRm9yIGluc3RhbmNlLCBhICJX V1ctQXV0aGVudGljYXRlOiBPQXV0aDIiIHJlc3BvbnNlIGNvdWxkIGRlZmluZSAyIHBhcmFtZXRl cnM6DQo+PiAndXNlci11cmknIGFuZCAndG9rZW4tdXJpJy4gSWYgb25seSBvbmUgaXMgcHJlc2Vu dCwgb25seSB0aGUgY29ycmVzcG9uZGluZyBtb2RlDQo+PiBpcyB1c2VmdWwgaW4gdGhpcyBpbnRl cmFjdGlvbi4NCg0KPiBJbnRlcmVzdGluZy4NCg0KDQo+PiBBbm90aGVyIGludGVyZXN0aW5nIGZh Y2V0IG9mIHRoaXMgZXhhbXBsZSBpcyB3aGF0IHRva2VuIHRoZSBhcHAgdXNlcw0KPj4gYXQgc3Rl cCA0LiBJcyBpdCB0aGUgdG9rZW4gdGhlIGFwcCBnb3QgaW4gdGhlIGZpcnN0IE9BdXRoMiBmbG93 IChzdGVwIDEpLA0KPj4gb3IgdGhlIHRva2VuIGZyb20gdGhlIHNlY29uZCBPQXV0aDIgZmxvdyAo c3RlcCAzKT8NCj4+DQo+PiBQcmVzdW1hYmx5IHRoZSBzZWNvbmQgdG9rZW4gb3ZlcnJpZGVzIHRo ZSBmaXJzdC4NCj4+IEluIHRoaXMgZXhhbXBsZSwgaG93ZXZlciwgaXQgbWF5IGJlIHN1ZmZpY2ll bnQgdG8ga2VlcCB1c2luZyB0aGUgZmlyc3QgdG9rZW4uDQo+PiBPQXV0aDIgZG9lc27igJl0IG5l ZWQgdG8gbWFrZSByZXR1cm5pbmcgYSB0b2tlbiBtYW5kYXRvcnkgLS0gaXQgaXMgbm90DQo+PiBh bHdheXMgcmVxdWlyZWQgaW4gYSB1c2VyLWRlbGVnYXRpb24gZmxvdy4NCg0KPiBBbHNvLCB3aGVu IHRoZSB1c2VyIGRlbGVnYXRpb24gZmxvdyBpcyBleGVjdXRlZCAoc3RlcCAzKSwgaG93IGRvZXMg dGhlDQo+IHByb3ZpZGVyIGFzc29jaWF0ZSBhY2tub3dsZWRnZW1lbnQgb2YgdGhlIFRvUyB3aXRo IHRoZSBhc3NlcnRpb24gZ3JhbnQNCj4gKHN0ZXAgMSk/DQoNClRoZSBzZXJ2ZXIgcHJvdmlkZXMg YSB1c2VyLWF1dGhvcml6YXRpb24gVVJJIGluIHN0ZXAgMiB3aGljaCBjYW4gZW5jb2RlIGRldGFp bHMNCmFib3V0IHRoZSBpbml0aWFsIHRva2VuLg0KQSBuZXcgdG9rZW4gaXNzdWVkIGluIHRoZSBz ZWNvbmQgT0F1dGgyIGZsb3cgY2FuIGVuY29kZSB0aGUgVG9TIGFja25vd2xlZGdlbWVudA0KYWxv bmcgd2l0aCBkZXRhaWxzIGZyb20gdGhlIGluaXRpYWwgdG9rZW4uDQoNCk9BdXRoMiBuZWVkcyBh IHdheSB0byBpZGVudGl0eSBhbiBleGlzdGluZyB0b2tlbiB3aGVuIG1ha2luZyBhIHN1YnNlcXVl bnQgT0F1dGgyDQpmbG93IC0tIG5vdCBqdXN0IGZvciB0aGlzIGV4YW1wbGUsIGJ1dCB3aGVuIGFu IGFwcCBhc2tzIGZvciBleHRyYSBwZXJtaXNzaW9ucy4NClRoZSBzcGVjIG1pZ2h0IG5vdCBuZWVk IHRvIGV4cGxpY2l0bHkgZGVmaW5lIHRoaXMgaWYsIGFzIGluIHRoaXMgZXhhbXBsZSwgdGhlDQpz ZXJ2ZXIgY2FuIGR5bmFtaWNhbGx5IHByb3ZpZGUgYSB1c2VyLWF1dGh6IFVSSS4gSXQgd291bGQg YmUgaGVscGZ1bCBpbiBvdGhlcg0KY2lyY3Vtc3RhbmNlcywgdGhvdWdoLg0KSXQgcHJvYmFibGUg cmVxdWlyZXMgYSB0b2tlbl9pZCB0aGF0IGlzIHNlcGFyYXRlIGZyb20gdGhlIHRva2VuLg0KDQot LQ0KSmFtZXMgTWFuZ2VyDQoNCg== From Jeff.Hodges@KingsMountain.com Fri Jul 30 00:25:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0103A6A61 for ; Fri, 30 Jul 2010 00:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr3qBH8lEVef for ; Fri, 30 Jul 2010 00:25:11 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 7FED83A6899 for ; Fri, 30 Jul 2010 00:25:11 -0700 (PDT) Received: (qmail 7467 invoked by uid 0); 30 Jul 2010 07:25:35 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 30 Jul 2010 07:25:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=r1vbJqfaFf/lg3lTeUKLrj+8O1Wwt30FcC/JpkH1iCKVRq7Y2u9K/OakWKYCz3ZjU7naiDaqhNSU1HcKHNsdzApP8ReFMmzBfTSZyjn1KZzx6IP8xdITYxSZCh08t+qc; Received: from dhcp-749c.meeting.ietf.org ([130.129.116.156]) by box514.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OejyJ-0007el-D9 for oauth@ietf.org; Fri, 30 Jul 2010 01:25:35 -0600 Message-ID: <4C527E43.1070708@KingsMountain.com> Date: Fri, 30 Jul 2010 00:24:51 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF oauth WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.116.156 authed with jeff.hodges+kingsmountain.com} Subject: [OAUTH-WG] OAuth v1 flow ladder/swimlane diagrams (ascii) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 07:25:12 -0000 fyi/fwiw I concocted ascii-art OAuth v1 flow ladder/swimlane diagrams a while back (not yet updated for v2). they are cached here.. OAuth Protocol Flow Diagrams http://identitymeme.org/archives/2008/10/22/oauth-protocol-flow-diagrams/ HTH, =JeffH From stpeter@stpeter.im Fri Jul 30 01:45:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB19D28C29C for ; Fri, 30 Jul 2010 01:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=-1.223, BAYES_00=-2.599, TVD_SPACED_SUBJECT_WORD3=2.412] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXPj3rcrqgMi for ; Fri, 30 Jul 2010 01:45:33 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 04E8228C291 for ; Fri, 30 Jul 2010 01:45:33 -0700 (PDT) Received: from dhcp-23fb.meeting.ietf.org (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 35CB3400EE for ; Fri, 30 Jul 2010 02:45:58 -0600 (MDT) Message-ID: <4C529144.9080801@stpeter.im> Date: Fri, 30 Jul 2010 10:45:56 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] PlantUML X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 08:45:34 -0000 As referred to in the tutorial just now: http://plantuml.sourceforge.net/ Peter -- Peter Saint-Andre https://stpeter.im/ From ynir@checkpoint.com Fri Jul 30 02:18: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 18C9928C2C5 for ; Fri, 30 Jul 2010 02:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 FiEODI5GJYzF for ; Fri, 30 Jul 2010 02:18:35 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id EEA4328C2A7 for ; Fri, 30 Jul 2010 02:18:34 -0700 (PDT) X-CheckPoint: {4C52A4A3-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o6U9IwDq014003; Fri, 30 Jul 2010 12:18:58 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 30 Jul 2010 12:19:28 +0300 From: Yoav Nir To: Peter Saint-Andre Date: Fri, 30 Jul 2010 12:18:56 +0300 Thread-Topic: [OAUTH-WG] PlantUML Thread-Index: AcsvyE8MLMLEgVDhRhmhy345sL4BdQ== Message-ID: References: <4C529144.9080801@stpeter.im> In-Reply-To: <4C529144.9080801@stpeter.im> 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] PlantUML X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 09:18:37 -0000 Any chance of postings the sources for today's diagrams=20 (now that we can render them ourselves) On Jul 30, 2010, at 10:45 AM, Peter Saint-Andre wrote: > As referred to in the tutorial just now: >=20 > http://plantuml.sourceforge.net/ >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > Scanned by Check Point Total Security Gateway. From stpeter@stpeter.im Fri Jul 30 02:33: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 AEFCB28C286 for ; Fri, 30 Jul 2010 02:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.012, 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 MS4t4RdJ9vm7 for ; Fri, 30 Jul 2010 02:33:28 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 380A628C24B for ; Fri, 30 Jul 2010 02:33:05 -0700 (PDT) Received: from dhcp-23fb.meeting.ietf.org (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D7BBC400EE; Fri, 30 Jul 2010 03:33:29 -0600 (MDT) Message-ID: <4C529C67.6040005@stpeter.im> Date: Fri, 30 Jul 2010 11:33:27 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Yoav Nir References: <4C529144.9080801@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] PlantUML X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 09:33:30 -0000 Blaine said he will post them, but I'm not sure when. On 7/30/10 11:18 AM, Yoav Nir wrote: > Any chance of postings the sources for today's diagrams > (now that we can render them ourselves) > > On Jul 30, 2010, at 10:45 AM, Peter Saint-Andre wrote: > >> As referred to in the tutorial just now: >> >> http://plantuml.sourceforge.net/ >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> Scanned by Check Point Total Security Gateway. From rbarnes@bbn.com Fri Jul 30 04:37:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AAED3A68E6 for ; Fri, 30 Jul 2010 04:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unGwC6GsjL4B for ; Fri, 30 Jul 2010 04:37:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A65DF3A6899 for ; Fri, 30 Jul 2010 04:37:36 -0700 (PDT) Received: from [128.89.253.157] (port=50452 helo=dhcp-22e1.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OenuY-000L6J-UA; Fri, 30 Jul 2010 07:37:59 -0400 Message-Id: <4E71E3BE-4C4F-4198-8B63-9BE54F034F9A@bbn.com> From: "Richard L. Barnes" To: Peter Saint-Andre In-Reply-To: <4C529144.9080801@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 30 Jul 2010 13:37:57 +0200 References: <4C529144.9080801@stpeter.im> X-Mailer: Apple Mail (2.936) Cc: OAuth WG Subject: Re: [OAUTH-WG] PlantUML X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 11:37:41 -0000 Gold star to the first person to add support for ASCII art output. On Jul 30, 2010, at 10:45 AM, Peter Saint-Andre wrote: > As referred to in the tutorial just now: > > http://plantuml.sourceforge.net/ > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From darren@cliqset.com Fri Jul 30 08:42: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 6E6533A69F2 for ; Fri, 30 Jul 2010 08:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNYe05hV3QB0 for ; Fri, 30 Jul 2010 08:42:24 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 678813A6A06 for ; Fri, 30 Jul 2010 08:42:24 -0700 (PDT) Received: by gxk1 with SMTP id 1so781488gxk.31 for ; Fri, 30 Jul 2010 08:42:48 -0700 (PDT) Received: by 10.100.198.20 with SMTP id v20mr2402619anf.144.1280504564423; Fri, 30 Jul 2010 08:42:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.7.19 with HTTP; Fri, 30 Jul 2010 08:42:24 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11267EC8194@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11267EC8194@WSMSG3153V.srv.dir.telstra.com> From: Darren Bounds Date: Fri, 30 Jul 2010 11:42:24 -0400 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 15:42:25 -0000 James, > precondition_uri seems to address a requirement for optional human intera= ction > when an app starts accessing a protected resource. > A solution that changes the token response can only add the human interac= tion: > a) if OAuth is used for direct authentication/authorization of the app; a= nd > b) at the instant in time when the app does its direct OAuth flow. > I'm note sure a requirement for human interaction will necessarily be tie= d to > either of those conditions, which is why an independent OAuth2 flow for > the human interaction is appealing. Technically what I've proposed reverses the order of operations. Doing so allows for redirect decisions to be made by the provider on a case-by-case basis. As a result, I would submit that with the changes I'm suggesting, OAuth direct flows are much more flexible and could even be used in place of a Web Server, Native and User-Agent client profiles. >>> An alternative would be to run the 2 OAuth2 flows sequentially. >>> 1. app use a direct OAuth2 flow (eg the assertion flow) to get a token; >>> 2. app tries to get feed with token, but server demands a user-delegati= on OAuth2 flow; >>> 3. app redirects user to service; Terms of Service are shown; user redi= rected back; >>> 4. app tries to get feed again, which succeeds this time. >>> >>> This example illustrates that OAuth2 discovery needs to let a service >>> explicitly indicate whether a direct and/or user-delegation flow is req= uired. >>> For instance, a "WWW-Authenticate: OAuth2" response could define 2 para= meters: >>> 'user-uri' and 'token-uri'. If only one is present, only the correspond= ing mode >>> is useful in this interaction. > >> Interesting. > > >>> Another interesting facet of this example is what token the app uses >>> at step 4. Is it the token the app got in the first OAuth2 flow (step 1= ), >>> or the token from the second OAuth2 flow (step 3)? >>> >>> Presumably the second token overrides the first. >>> In this example, however, it may be sufficient to keep using the first = token. >>> OAuth2 doesn=E2=80=99t need to make returning a token mandatory -- it i= s not >>> always required in a user-delegation flow. > >> Also, when the user delegation flow is executed (step 3), how does the >> provider associate acknowledgement of the ToS with the assertion grant >> (step 1)? > > The server provides a user-authorization URI in step 2 which can encode d= etails > about the initial token. > A new token issued in the second OAuth2 flow can encode the ToS acknowled= gement > along with details from the initial token. > > OAuth2 needs a way to identity an existing token when making a subsequent= OAuth2 > flow -- not just for this example, but when an app asks for extra permiss= ions. > The spec might not need to explicitly define this if, as in this example,= the > server can dynamically provide a user-authz URI. It would be helpful in o= ther > circumstances, though. > It probable requires a token_id that is separate from the token. > > -- > James Manger As an OAuth 2 provider and consumer as well as someone who's preparing to build the DiSo interactions my proposal was based on, I would prefer a single flow that addresses what I feel will be a increasingly common set of requirements rather than combining two flows designed for two distinct purposes. --=20 darren bounds darren@cliqset.com From aaron@parecki.com Fri Jul 30 10:51: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 DD6183A6A0F for ; Fri, 30 Jul 2010 10:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lan87zsUxWUm for ; Fri, 30 Jul 2010 10:51:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id BE6473A6ADE for ; Fri, 30 Jul 2010 10:51:11 -0700 (PDT) Received: by wyb40 with SMTP id 40so1489635wyb.31 for ; Fri, 30 Jul 2010 10:51:36 -0700 (PDT) Received: by 10.216.35.12 with SMTP id t12mr2038360wea.41.1280512295781; Fri, 30 Jul 2010 10:51:35 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id o84sm1349620wej.13.2010.07.30.10.51.33 (version=SSLv3 cipher=RC4-MD5); Fri, 30 Jul 2010 10:51:34 -0700 (PDT) Received: by pwj1 with SMTP id 1so727196pwj.31 for ; Fri, 30 Jul 2010 10:51:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.148.2 with SMTP id v2mr2072677wfd.114.1280512292454; Fri, 30 Jul 2010 10:51:32 -0700 (PDT) Received: by 10.142.234.18 with HTTP; Fri, 30 Jul 2010 10:51:32 -0700 (PDT) Date: Fri, 30 Jul 2010 10:51:32 -0700 Message-ID: From: Aaron Parecki To: oauth@ietf.org Content-Type: multipart/alternative; boundary=000e0cd3289c52850e048c9e800e Subject: [OAUTH-WG] Expiring refresh tokens after use X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 17:52:46 -0000 --000e0cd3289c52850e048c9e800e Content-Type: text/plain; charset=UTF-8 I have started implementing OAuth 2 on geoloqi.com's API. I have a question/suggestion regarding using refresh tokens. It is my understanding that access tokens are supposed to be short-lived, and clients should use the refresh token to request a new access token after it expires. When the client requests a new access token, it may also get a new refresh token back in the response. If this is the case, the client will probably use the new refresh token for future requests and discard the old refresh token. Does it make sense in this case that the authorization server should expire the old refresh token? Proposed text for the "refresh_token" section of 4.2 Access Token Response: If the access grant type is "refresh_token", the authorization server SHOULD > expire (revoke?) the refresh token that was used in this request when > providing a new refresh token. Does this make sense? --000e0cd3289c52850e048c9e800e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have started implementing OAuth 2 on geolo= qi.com's API. I have a question/suggestion regarding using refresh = tokens.

It is my understanding that access tokens are su= pposed to be short-lived, and clients should use the refresh token to reque= st a new access token after it expires. When the client requests a new acce= ss token, it may also get a new refresh token back in the response. If this= is the case, the client will probably use the new refresh token for future= requests and discard the old refresh token. Does it make sense in this cas= e that the authorization server should expire the old refresh token?

Proposed text for the "refresh_token" section= of 4.2 Access Token Response:

If=C2=A0the access grant type is "refresh_token",=C2=A0the author= ization server SHOULD expire (revoke?) the refresh token that was used in t= his request when providing a new refresh token.

=
Does this make sense?

--000e0cd3289c52850e048c9e800e-- From lshepard@facebook.com Fri Jul 30 15:39: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 0D1F73A684D for ; Fri, 30 Jul 2010 15:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMvGwLVg2+KZ for ; Fri, 30 Jul 2010 15:39:54 -0700 (PDT) Received: from mx-out.facebook.com (outmail003.snc1.tfbnw.net [69.63.178.162]) by core3.amsl.com (Postfix) with ESMTP id 9F78B3A6835 for ; Fri, 30 Jul 2010 15:39:54 -0700 (PDT) Received: from [10.18.255.128] ([10.18.255.128:14071] helo=mail.thefacebook.com) by mta027.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 09/BD-06248-0D4535C4; Fri, 30 Jul 2010 15:40:17 -0700 Received: from SC-MBX05.TheFacebook.com ([169.254.4.45]) by sc-hub03.TheFacebook.com ([fe80::1cfe:1f6b:8b35:cf7f%11]) with mapi; Fri, 30 Jul 2010 15:40:16 -0700 From: Luke Shepard To: Nat Sakimura Thread-Topic: [OAUTH-WG] Alternative ways to pass Authorization Request Parameters Thread-Index: AcsiNkVlDxcA0bzBQ2uVwaI5xr8XHwOPJd0A Date: Fri, 30 Jul 2010 22:40:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] Alternative ways to pass Authorization Request 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: Fri, 30 Jul 2010 22:39:56 -0000 That sounds reasonable to me. Makes sense that we'd want to make sure the s= pec doesn't preclude artifact binding, while still keeping it clear for the= main use case (which is just putting parameters in the URL). On Jul 12, 2010, at 7:51 PM, Nat Sakimura wrote: > As of -10, the Authorization Request Parameters are required to be > passed as part of the Authorization Request URI query component. >=20 > I would like to see it relaxed a bit so that they do not have to be a > part of the URL but can be passed by reference. >=20 > In the proposal that I have submit a while ago, I proposed to have >=20 > 1) The parameters to be captured in JSON that can be obtained through a U= RL > 2) Pass this URL to the end-user authorization endpoint through a > parameter 'request_url' >=20 > I have enumerated numerous merit of this approach and I believe we had > an agreement that this would be useful from both security and > usability perspective. >=20 > However, as the current text is written, the parameters have to be > sent as URI query component. >=20 > In -10, it is written as: >=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 > (parm defs) >=20 > The client directs the end-user to the constructed URI using an HTTP > redirection response, or by other means available to it via the end- > user's user-agent. The authorization server MUST support the use of > the HTTP "GET" method for the end-user authorization endpoint, and > MAY support the use of the "POST" method as well. >=20 > Instead I would propose something like: >=20 > In order to obtain the end-user's authorization, the client sends the > following parameters to the end-user authorization endpoint. >=20 > (param defs) >=20 > The client directs the end-user to the end-user authorization endpoint > URI using an HTTP redirection response, or by other means available to > it via the end-user's user-agent. The authorization server MUST > support the use of > the HTTP "GET" method for the end-user authorization endpoint, and > MAY support the use of the "POST" method as well. The authorization > server MUST support the parameters being passed as the query component > using the "application/x-www-form-urlencoded" format as defined by > [W3C.REC-html401-19991224]. >=20 >=20 > I also have a comment on the structure of the section 3. > I should have noticed this much earlier but currently the section 3 is > structured as: >=20 > 3. Obtaining End-User Authorization > 3.1. Authorization Response > 3.2. Error Response >=20 > Would it not be better to be something like below? >=20 > 3. Obtaining End-User Authorization > 3.1. Authorization Request > 3.2. Authorization Response > 3.3. Error Response >=20 > --=20 > Nat Sakimura (=3Dnat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth