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

Eran Hammer-Lahav <> Thu, 30 September 2010 15:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB6C33A6C29 for <>; Thu, 30 Sep 2010 08:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YYnrtwIjQgW6 for <>; Thu, 30 Sep 2010 08:56:08 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 6AD853A6BB1 for <>; Thu, 30 Sep 2010 08:56:08 -0700 (PDT)
Received: (qmail 29935 invoked from network); 30 Sep 2010 15:56:53 -0000
Received: from unknown (HELO ( by with SMTP; 30 Sep 2010 15:56:53 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([]) with mapi; Thu, 30 Sep 2010 08:56:46 -0700
From: Eran Hammer-Lahav <>
To: Torsten Lodderstedt <>
Date: Thu, 30 Sep 2010 08:56:10 -0700
Thread-Topic: [OAUTH-WG] Next steps (draft timeline)
Thread-Index: ActguBVqCe/AIaSeRyS4Zjf3dv+SnA==
Message-ID: <>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB9A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5B997D64AA0C43798EC051A032E081F8hueniversecom_"
MIME-Version: 1.0
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:56:10 -0000

The chairs sent a longer list of new items to consider. This does not replace that list but only focuses on the immediate next steps.


On Sep 30, 2010, at 8:38, "Torsten Lodderstedt" <<>> wrote:

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.


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