Re: [OAUTH-WG] Publication requested for draft-ietf-oauth-v2-bearer-12

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 30 October 2011 17:38 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FCA21F8A7D for <oauth@ietfa.amsl.com>; Sun, 30 Oct 2011 10:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.424
X-Spam-Level:
X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4vAvDeungjh for <oauth@ietfa.amsl.com>; Sun, 30 Oct 2011 10:37:59 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 05FC321F8A71 for <oauth@ietf.org>; Sun, 30 Oct 2011 10:37:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D0106157AAD; Sun, 30 Oct 2011 17:37:57 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1319996277; bh=+Bxz+XiLLIqg5v EvNohpPr3LDg7oDvv0AjcmfgVgqNk=; b=3WhDuV2rj/L1N1xjwZo89t3aLN9gO6 m/HhaBGVbpGg8atrvX5uw65EiaNxsFFGOvTYiF/q7cWt+Vdi+hUbJA/EkJgubkuz s0cJhweKq1lMVbdQXPVVwsDaduc/wkjSVRU1jRvobacgenxgIRgWmsjWhGxgJVAJ Pkm8pM3A1/VrhLa1RXa5FsWwPMOdm/XdhGU5KY7Mew+2nTJkGJokXKrBAmVdCDfS zrn+gI51FzIzgwgnnsqhnev81u7h9dcz9uVnprS/Yvygf6NvHzCCSrZo3TnBaM3j 7bezOTKHcy3Z2hMPbhpFpy77K/u49arOTpA1RAtH8skqtoeXWg4hbCTg==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id KcRKRJrfWVQY; Sun, 30 Oct 2011 17:37:57 +0000 (GMT)
Received: from [10.87.48.12] (unknown [86.41.5.169]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DCB31171C5A; Sun, 30 Oct 2011 17:37:56 +0000 (GMT)
Message-ID: <4EAD8B74.5010105@cs.tcd.ie>
Date: Sun, 30 Oct 2011 17:37:56 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
References: <03E302FD-3A01-4363-BF14-BBE6EB9B2AF1@gmx.net>
In-Reply-To: <03E302FD-3A01-4363-BF14-BBE6EB9B2AF1@gmx.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Publication requested for draft-ietf-oauth-v2-bearer-12
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 30 Oct 2011 17:38:00 -0000

Hi Hannes,

Just looking at this now. The tracker [1] WG state shows
revised ID needed - was that prior to the publication request
or as a result of the comments on the list since you sent me
this? If the former, I'll do my AD review now, if the latter
then I guess I should wait and review a -13.

Also - are you not able to enter the proto write up into
the WG chair/shepherd tool thing? If so could you do that?
(If you can't I can edit it in but would like to give the
tool a spin if we can.)

Ta,
S.

[1] https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/

On 10/28/2011 07:36 AM, Hannes Tschofenig wrote:
> Hi Stephen,
>
> the OAuth working group requests publication of draft-ietf-oauth-v2-bearer-12 as Proposed Standard.
>
> Here is the write-up for the document.
>
> -------------------------------------------
>
> Document Shepherd Write-Up for draft-ietf-oauth-v2-bearer-12
>
>    (1.a) Who is the Document Shepherd for this document? Has the
>          Document Shepherd personally reviewed this version of the
>          document and, in particular, does he or she believe this
>          version is ready for forwarding to the IESG for publication?
>
> The document shepherd is Hannes Tschofenig. I have personally reviewed the
> document and I think it is ready for going forward.
>
>    (1.b) Has the document had adequate review both from key WG members
>          and from key non-WG members? Does the Document Shepherd have
>          any concerns about the depth or breadth of the reviews that
>          have been performed?
>
> The document received a number of reviews from the working group but also
> from members outside the working group, including security reviews.
>
>    (1.c) Does the Document Shepherd have concerns that the document
>          needs more review from a particular or broader perspective,
>          e.g., security, operational complexity, someone familiar with
>          AAA, internationalization or XML?
>
> The document was reviewed by Julian Reschke for HTTP related content.
> Changes to the document have been made in response to his review.
>
> There is still disagreement between Julian and working
> group members regarding two issues concerning encoding. While the
> shepherd feels comfortable going forward with the specification to
> the IESG wider IETF review may provide additional feedback.
>
> One issue is related to the encoding of the scope attribute in context
> of HTTP authentication parameters:
>
> https://www.ietf.org/mail-archive/web/oauth/current/msg07733.html
> https://www.ietf.org/mail-archive/web/oauth/current/msg07734.html
> https://www.ietf.org/mail-archive/web/oauth/current/msg07739.html
>
> The other comment by Julian is related to the form encoding, as
> described here:
> https://www.ietf.org/mail-archive/web/oauth/current/msg07731.html
>
>
>    (1.d) Does the Document Shepherd have any specific concerns or
>          issues with this document that the Responsible Area Director
>          and/or the IESG should be aware of? For example, perhaps he
>          or she is uncomfortable with certain parts of the document, or
>          has concerns whether there really is a need for it. In any
>          event, if the WG has discussed those issues and has indicated
>          that it still wishes to advance the document, detail those
>          concerns here. Has an IPR disclosure related to this document
>          been filed? If so, please include a reference to the
>          disclosure and summarize the WG discussion and conclusion on
>          this issue.
>
> I have no concerns regarding this document but would like to appreciate
> feedback from the wider IETF community on the issues raised under
> item 1.c.
>
>    (1.e) How solid is the WG consensus behind this document? Does it
>          represent the strong concurrence of a few individuals, with
>          others being silent, or does the WG as a whole understand and
>          agree with it?
>
> There solid consensus behind this document from the working group.
>
>    (1.f) Has anyone threatened an appeal or otherwise indicated extreme
>          discontent? If so, please summarise the areas of conflict in
>          separate email messages to the Responsible Area Director. (It
>          should be in a separate email because this questionnaire is
>          entered into the ID Tracker.)
>
> Nobody had shown extreme discontent.
>
>    (1.g) Has the Document Shepherd personally verified that the
>          document satisfies all ID nits? (See the Internet-Drafts Checklist
>          and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
>          not enough; this check needs to be thorough. Has the document
>          met all formal review criteria it needs to, such as the MIB
>          Doctor, media type and URI type reviews?
>
> I have verified the document. The idnits tool gives a warning about
> the RFC 2119 boilerplate, and that warning is incorrect.
>
>    (1.h) Has the document split its references into normative and
>          informative? Are there normative references to documents that
>          are not ready for advancement or are otherwise in an unclear
>          state? If such normative references exist, what is the
>          strategy for their completion? Are there normative references
>          that are downward references, as described in [RFC3967]? If
>          so, list these downward references to support the Area
>          Director in the Last Call procedure for them [RFC3967].
>
> The references are split into normative and informative references.
>
> There is one downref to RFC 2818.
>
>    (1.i) Has the Document Shepherd verified that the document IANA
>          consideration section exists and is consistent with the body
>          of the document? If the document specifies protocol
>          extensions, are reservations requested in appropriate IANA
>          registries? Are the IANA registries clearly identified? If
>          the document creates a new registry, does it define the
>          proposed initial contents of the registry and an allocation
>          procedure for future registrations? Does it suggest a
>          reasonable name for the new registry? See [RFC5226]. If the
>          document describes an Expert Review process has Shepherd
>          conferred with the Responsible Area Director so that the IESG
>          can appoint the needed Expert during the IESG Evaluation?
>
> I have reviewed the IANA consideration section.
> The documents adds new values into an existing registry.
>
>    (1.j) Has the Document Shepherd verified that sections of the
>          document that are written in a formal language, such as XML
>          code, BNF rules, MIB definitions, etc., validate correctly in
>          an automated checker?
>
> The ABNF in the document was verified with
> http://trac.tools.ietf.org/wg/httpbis/trac/browser/abnfparser/bap
>
>    (1.k) The IESG approval announcement includes a Document
>          Announcement Write-Up. Please provide such a Document
>          Announcement Write-Up? Recent examples can be found in the
>          "Action" announcements for approved documents. The approval
>          announcement contains the following sections:
>
>       Technical Summary
>
>     This specification describes how to use bearer tokens in HTTP
>     requests to access OAuth 2.0 protected resources.  Any party in
>     possession of a bearer token (a "bearer") can use it to get access to
>     granted resources (without demonstrating possession of a
>     cryptographic key).  To prevent misuse, the bearer token MUST be
>     protected from disclosure in storage and in transport.
>
>       Working Group Summary
>
>     The working group decided to develop two types of mechanisms for
>     a client to access a protected resource. The second specification
>     is being worked on with draft-ietf-oauth-v2-http-mac-00. The
>     two specifications offer different security properties to allow
>     deployments to meet their specific needs.
>
>       Document Quality
>
>     This specification is implemented, deployed and used by Microsoft
>     Access Control Service (ACS), Google Apps, Facebook Connect and the
>     Graph API, Salesforce, Mitre, and many others.
>
>     Source code is available as well. For example
>     http://static.springsource.org/spring-security/oauth/
>     http://incubator.apache.org/projects/amber.html
>     https://github.com/nov/rack-oauth2
>     + many more, including those listed at
>     https://github.com/teohm/teohm.github.com/wiki/OAuth
>
>
> -------------------------------------------
>
> Ciao
> Hannes
>
>