Subject: [OAUTH-WG] Process / timeline for OAuth 2.0

From: Evan Gilbert <[email-masked]>
Date: Thu, 15 Apr 2010 00:04:18 -0700

I've been participating in the OAuth 2.0 discussions, but realized I don't
know how the process is supposed to work for getting successive drafts and
getting to an agreed upon spec and if we have a rough timeline.

The "Informal Guide <http://www.ietf.org/about/process-docs.html>" didn't
help that much - wondering if someone could give a quick summary of how this
is supposed to work.

A few specific questions:
- What does it mean to have successive drafts? And if we move an issue to
the next draft, what does that practically mean?
- What is the expected timing of these drafts?
- How does the bill become a law?

Thanks,
Evan

---

From: SM <[email-masked]>
Date: Thu, 15 Apr 2010 01:38:00 -0700

At 00:04 15-04-10, Evan Gilbert wrote:
>I've been participating in the OAuth 2.0 discussions, but realized I 
>don't know how the process is supposed to work for getting 
>successive drafts and getting to an agreed upon spec and if we have 
>a rough timeline.
>
>The "Informal Guide" didn't help that much - wondering if someone 
>could give a quick summary of how this is supposed to work.
>
>- What does it mean to have successive drafts? And if we move an 
>issue to the next draft, what does that practically mean?

"During the development of a specification, draft versions of the 
document are made available for informal review and comment".  "At 
any time, an Internet-Draft may be replaced by a more recent version 
of the same specification".

If the current version of an Internet-Draft (I-D) does not address an 
issue and it is viewed as an issue by the Working Group (WG), the 
question might be deferred to a future version of the I-D.  There are 
no hard or fast rules.  It's a matter of style or approach.

>- What is the expected timing of these drafts?

There isn't a deadline for submitting these drafts.  It may be viewed 
as bad form to submit an updated version of the draft for each minor 
change.  The important point is to gauge whether there is consensus 
on what will become the final version of the specification.  That is 
first determined through a Working Group Last-Call.  It's a matter of 
using your judgement along the way to build consensus.  The WG Chairs 
can have consensus calls to resolve controversial issues.

>- How does the bill become a law?

Before the RFC can be published (I'm skipping some details here), it 
goes through a Working Group Last-Call and an IETF-wide Last-Call 
where the IESG asks the IETF community to comment on the 
document.  An IESG Evaluation is performed after that Last-Call to 
determine whether the document satisfies the criteria for 
publication.  A RFC is not a law.  The IETF does not enforce its 
specifications.  It's up to you to determine whether you want to 
implement what the RFC says and how you are going to do that.  It is 
better, for interoperability, if an implementation that claims 
conformance to a RFC adheres to it.

Regards,
-sm

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 05:12:38 -0700

On 4/15/10 12:04 AM, "Evan Gilbert" <[email-masked]> wrote:

> - What does it mean to have successive drafts? And if we move an issue to the
> next draft, what does that practically mean?

Drafts are numbered but not versioned and they are not reference-able. They
expire after 6 month of publication and cannot be used as normative
references from other specifications. So in practice the latest draft is
simply a representation of where the working group is in terms of progress.

When the WG is done, it issues a last call to see if anyone in the WG still
has open issues. You can have multiple last calls if a last calls demands
significant changes.

Once the working group is satisfied with its draft, it goes to an IETF last
call with the same process but with feedback coming from the entire
community and sent back to the WG to be worked out.

As any given time, the WG does not have to accommodate feedback but should
account for it (reply and explain why). The IETF last call includes official
review from other areas such as the security area. These reviews must be
addressed (in the same manner though).

When the document passed through both last calls, it goes to the IESG which
is the IETF governing body consisted of the area directors and the IESG
chair. The IESG votes on the draft to approve or discuss it. There is no
'No' vote in the IESG (you need 10 yes/abstain votes and no requests to
discuss the draft for approval).

IESG discussion can take a while until all the area directors are satisfied.
At that point the document is done and can be referenced, but can take
months to be published as an RFC. The process doesn't end there but the vast
majority of people treat the RFC as a standard (it is actually just a
proposed standard) and ignore the rest.

> - What is the expected timing of these drafts?

Like any standards process it takes as long as it takes. OAuth 1.0 took
about a year without becoming a standard. Once the WG is done, it should
take about 3-6 months for IESG approval and another 3-6 months for RFC
publication.

BUT - 

Companies can implement the drafts for beta or experimental purposes and
keep them up to date as much as possible. Once the WG draft is done,
companies can ship it with the expectation that it can still change but with
a general timeline of about 6 months to a year. The primary reason for
changes after WG LC are security requirements.

As for the WG timing, it is hard to say because we still have a long list of
open issues. The biggest reasons for WG slowness are busy editors and laid
back chairs. I don't think editorial work is going to slow the WG, but when
it comes to closing issues, we rely on the chairs to make consensus calls
and close open issues when the WG is stuck.

That said, I think the current draft is close to what OAuth 2.0 should look
like and the list of issues has remained about the same for the past month.

EHL

---

From: Evan Gilbert <[email-masked]>
Date: Thu, 15 Apr 2010 08:55:29 -0700

Thanks for the responses - they were very helpful.

On Thu, Apr 15, 2010 at 5:12 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> the