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 > >
- [OAUTH-WG] Publication requested for draft-ietf-o… Hannes Tschofenig
- Re: [OAUTH-WG] Publication requested for draft-ie… Stephen Farrell