[OAUTH-WG] return to draft 6 spec org?

Brian Eaton <beaton@google.com> Sun, 11 July 2010 04:15 UTC

Return-Path: <beaton@google.com>
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 0122F3A696B for <oauth@core3.amsl.com>; Sat, 10 Jul 2010 21:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.819
X-Spam-Level:
X-Spam-Status: No, score=-104.819 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 3ethCr-lhW7h for <oauth@core3.amsl.com>; Sat, 10 Jul 2010 21:15:16 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E59893A6948 for <oauth@ietf.org>; Sat, 10 Jul 2010 21:15:15 -0700 (PDT)
Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o6B4FLDo015963 for <oauth@ietf.org>; Sat, 10 Jul 2010 21:15:21 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278821721; bh=HlFqMouerQVYSDev37ob5femRZk=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=Hhpi/S2+NFQZUkVt1FeaoEvTzEzRXuo8jhVngu60FoHIFcCIZuyCa7476Wnalm6aE mTbCyb7AVaaS8SjKjrMZQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=VlZjrIDQkEFfy1Zr5Oy0gblE7umnQFUlDLMOhXGIkqsgg/jErqS92TtgI3/wtt3Ng 1A+y82JAu8SWkEj+yW79g==
Received: from pwi1 (pwi1.prod.google.com [10.241.219.1]) by wpaz17.hot.corp.google.com with ESMTP id o6B4FKCE004738 for <oauth@ietf.org>; Sat, 10 Jul 2010 21:15:21 -0700
Received: by pwi1 with SMTP id 1so1484132pwi.1 for <oauth@ietf.org>; Sat, 10 Jul 2010 21:15:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.215.6 with SMTP id n6mr15306207wfg.7.1278821720442; Sat, 10 Jul 2010 21:15:20 -0700 (PDT)
Received: by 10.142.193.19 with HTTP; Sat, 10 Jul 2010 21:15:20 -0700 (PDT)
Date: Sat, 10 Jul 2010 21:15:20 -0700
Message-ID: <AANLkTiknyfz3PMoP1l2wLIMB3Qptq34xMYUfyHNuhGLL@mail.gmail.com>
From: Brian Eaton <beaton@google.com>
To: oauth@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
Subject: [OAUTH-WG] return to draft 6 spec org?
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: Sun, 11 Jul 2010 04:15:17 -0000

I think it would be a good idea to return to the draft 6 organization.

Draft 6: normative language for each flow was called out separately,
and was described from start to finish, in chronological order, with
no interruption.  Each step showed what a client should send, and what
an authorization server should return.

Draft 7 and further: flows are merged to reuse spec language.  Steps
for any given use case are now interrupted with steps for other use
cases.

For example, consider a client developer who wants to implement the
web server flow.

First they have to read section 3.1, to describe the redirect they
need to send to the authorization server.

Then they read section 3.2, to see the redirect back.

Then they read section 4.1.1, to see the request they send to the
authorization server.

Then they skip a few pages, because they don't care about assertions
or passwords or refresh tokens.

They they read section 4.2, to see the response from the authorization server.

Then they skip several more pages to get to section 5, so they can access data.

Then they skip back to section 4.1.4, because they need to refresh their token.


Compare this to draft 6:
- read section 2.5
   this is everything you need to get a token, with no intervening
cruft about credentials you don't have.

- read section 4
   this is everything you need to use a token.

- read section 3
   this is everything you need to refresh a token.

Cheers,
Brian