Re: [OAUTH-WG] Next steps (draft timeline)

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 30 September 2010 15:36 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5494B3A6D46 for <oauth@core3.amsl.com>; Thu, 30 Sep 2010 08:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.08
X-Spam-Level:
X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.168, 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 0g6tFZkRnIgZ for <oauth@core3.amsl.com>; Thu, 30 Sep 2010 08:36:13 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by core3.amsl.com (Postfix) with ESMTP id D16D63A6D10 for <oauth@ietf.org>; Thu, 30 Sep 2010 08:36:12 -0700 (PDT)
Received: from [79.253.32.128] (helo=[192.168.71.43]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1P1LBo-0002bv-Si; Thu, 30 Sep 2010 17:36:57 +0200
Message-ID: <4CA4AEAE.5080807@lodderstedt.net>
Date: Thu, 30 Sep 2010 17:37:18 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Eran Hammer-Lahav <eran@hueniverse.com>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB9A2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DB9A2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: multipart/alternative; boundary="------------050307050602060000020801"
X-Df-Sender: torsten@lodderstedt-online.de
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Next steps (draft timeline)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2010 15:36:21 -0000

  Bassically, your suggestion sounds reasonable to me.

The only thing I'm missing is discovery. As you pointed out in 
http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/ 
this is a major enabler for interoperable APIs and motivates the need 
for signatures. Shouldn't we consider discovery, too?

regards,
Torsten.

Am 29.09.2010 18:20, schrieb Eran Hammer-Lahav:
>
> (This is a draft overview of our next steps. Clearly, this can change 
> based on working group consensus.)
>
> Proposal discussion
>
> The working group is still discussing the compromise proposal for 
> moving section 5 out of the specification. So far there is general 
> support but some have raised concerns (I have not seen any strong 
> objections yet). I am going to ask the chairs for an official 
> consensus call on this on Friday. I will not publish another draft 
> until we close this matter properly. While a consensus call does not 
> end debate, it provides a useful tool to move forward and reduce the 
> likelihood of future arguments.
>
> Editorial work
>
> I have been working on -11 and have applied all the feedback received 
> so far. I am still working on the compromise structure of 
> reintroducing the separate profiles into the document, but that is 
> purely an editorial change. As soon as we resolve the issue around the 
> document structure, I will finish the work and publish it. All the 
> normative language changes are already "published" on my github 
> account [1].
>
> If the proposal is approved, I plan to remove my name from the bearer 
> token specification and hand over that section to someone else. 
> Selecting an editor is the sole discretion of the chairs, but if you 
> are interested in taking over that document (which will include all of 
> section 5 of the current draft, with a new introduction), please let 
> the chairs know soon. I will get you off to a good start by providing 
> the first draft with all the necessary parts ready for editing. I will 
> also help as much as needed (my dislike for this document will not 
> prevent me for offering as much support as requested).
>
> Signature work
>
> Mike and Dirk have been making good progress with their proposals, and 
> I hope that we will soon have a single unified draft to work on. Once 
> that is ready, the working group will need to decide if it wants to 
> promote the proposal to a working group item, and if adopted, the 
> chairs will need to pick an editor for that work (not me).
>
> Assuming the signature proposal is going to keep its duplication of 
> HTTP request elements, I plan to introduce an alternative proposal 
> based on the OAuth 1.0a HMAC-SHA-1 method, my earlier token scheme 
> proposal, and the recent proposal from draft -05. I do not plan to ask 
> for this draft to become a working group item (I do plan to use this 
> list for discussions though), but will have no objections if others 
> ask. I have absolutely no desire to engage in any more working group 
> debate around which of the two approaches is better. I will promote my 
> ideas elsewhere and will let the market decide.
>
> Additional documents
>
> We have a few proposed I-D dealing with artifact binding, SAML 
> assertions, token revocation, and others. These seems to be in good 
> enough state to consider making them a working group item (a process 
> started by the chairs but which seems stuck). I suggest that the 
> authors make an official request to the chairs and get it done. My 
> proposal is that any document that is ready for last call alongside 
> the main working group specifications will be directly referenced in them.
>
> Timeline
>
> If the proposal is approved, I believe we can move to working group 
> last call by the end of the year. To get there, we will need to 
> complete at least two more round of review (i.e. get to a -13). I am 
> not expecting any new normative changes (but don't have any control 
> over it either). This will require the completion and integration of 
> the security consideration section in -12.
>
> This means:
>
> -11 -- last round of normative changes, document split, reintroducing 
> profiles (mid October)
>
> -12 -- security consideration section (early November)
>
> -13 -- last call document (early December)
>
> To get the bearer token document ready for last call, someone will 
> need to take over as editor as well as get the security consideration 
> section done for that part. The two documents do not need to enter 
> last call together, but it will probably be a useful thing to do. I do 
> not see any other last call dependencies (such as a signature draft).
>
> If we remain focused and move forward with the proposed compromise, we 
> should be able to meet this timeline. Otherwise, I have seen nothing 
> to suggest reaching last call for any document this year (but am 
> always open to new proposals that have not been rejected or strongly 
> opposed before).
>
> Open Issues
>
> With the pending publication of draft -11 I would like to ask everyone 
> to treat it as a working group last call and raise any objections or 
> issues they have. If anything in the document will cause you to raise 
> objections to its publication, please share those as soon as possible. 
> I hope to have a quick and quite review for -13, followed quickly by a 
> working group last call.
>
> Keep in mind that missing the these goals will mean February as the 
> next likely timeline, given the historical lack of activity in 
> December and January.
>
> EHL
>
> [1] http://github.com/theRazorBlade/draft-ietf-oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth