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

Torsten Lodderstedt <> Thu, 30 September 2010 15:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5494B3A6D46 for <>; Thu, 30 Sep 2010 08:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.08
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0g6tFZkRnIgZ for <>; Thu, 30 Sep 2010 08:36:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D16D63A6D10 for <>; Thu, 30 Sep 2010 08:36:12 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <>) id 1P1LBo-0002bv-Si; Thu, 30 Sep 2010 17:36:57 +0200
Message-ID: <>
Date: Thu, 30 Sep 2010 17:37:18 +0200
From: Torsten Lodderstedt <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv: Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Eran Hammer-Lahav <>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB9A2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DB9A2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: multipart/alternative; boundary="------------050307050602060000020801"
Cc: "OAuth WG (" <>
Subject: Re: [OAUTH-WG] Next steps (draft timeline)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 
this is a major enabler for interoperable APIs and motivates the need 
for signatures. Shouldn't we consider discovery, too?


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.
> [1]
> _______________________________________________
> OAuth mailing list