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
- [OAUTH-WG] Next steps (draft timeline) Eran Hammer-Lahav
- [OAUTH-WG] specification of authorization code pr… PRATEEK MISHRA
- Re: [OAUTH-WG] specification of authorization cod… Torsten Lodderstedt
- Re: [OAUTH-WG] Next steps (draft timeline) Torsten Lodderstedt
- Re: [OAUTH-WG] Next steps (draft timeline) Eran Hammer-Lahav
- Re: [OAUTH-WG] specification of authorization cod… PRATEEK MISHRA
- Re: [OAUTH-WG] specification of authorization cod… Torsten Lodderstedt
- Re: [OAUTH-WG] specification of authorization cod… Brian Campbell