Re: [OAUTH-WG] OK to post OAuth Bearer draft 15?
Mike Jones <Michael.Jones@microsoft.com> Fri, 16 December 2011 17:12 UTC
Return-Path: <Michael.Jones@microsoft.com>
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 7E7ED21F8B37 for <oauth@ietfa.amsl.com>; Fri, 16 Dec 2011 09:12:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.527
X-Spam-Level:
X-Spam-Status: No, score=-5.527 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 1lXa28p3oUdp for <oauth@ietfa.amsl.com>; Fri, 16 Dec 2011 09:12:05 -0800 (PST)
Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id E943421F8AD6 for <oauth@ietf.org>; Fri, 16 Dec 2011 09:12:04 -0800 (PST)
Received: from mail40-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 16 Dec 2011 17:12:03 +0000
Received: from mail40-tx2 (localhost [127.0.0.1]) by mail40-tx2-R.bigfish.com (Postfix) with ESMTP id 96C43801B5; Fri, 16 Dec 2011 17:12:01 +0000 (UTC)
X-SpamScore: -38
X-BigFish: VS-38(zzbb2dI9371Ic89bh1be0I1447M1b0bM542Mc857hzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail40-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail40-tx2 (localhost.localdomain [127.0.0.1]) by mail40-tx2 (MessageSwitch) id 132405552087472_18377; Fri, 16 Dec 2011 17:12:00 +0000 (UTC)
Received: from TX2EHSMHS017.bigfish.com (unknown [10.9.14.254]) by mail40-tx2.bigfish.com (Postfix) with ESMTP id 045005E0043; Fri, 16 Dec 2011 17:12:00 +0000 (UTC)
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS017.bigfish.com (10.9.99.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 16 Dec 2011 17:11:48 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.220]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0247.005; Fri, 16 Dec 2011 09:11:29 -0800
From: Mike Jones <Michael.Jones@microsoft.com>
To: Mark Nottingham <mnot@mnot.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, Barry Leiba <barryleiba@computer.org>
Thread-Topic: OK to post OAuth Bearer draft 15?
Thread-Index: Acy6zxL5vGVpwSHMTIKvMNNyq2nAEgBRnxgA
Date: Fri, 16 Dec 2011 17:11:29 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739435F7650C6@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.32]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435F7650C6TK5EX14MBXC283r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OK to post OAuth Bearer draft 15?
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: Fri, 16 Dec 2011 17:12:07 -0000
Unless I hear a “no” from Mark, the chairs, or Stephen I’ll plan to publish -15 over the weekend. (Or if I hear a “yes”, I’ll do so right away. ☺) -- Mike From: Mike Jones Sent: Wednesday, December 14, 2011 6:13 PM To: Mark Nottingham; 'Stephen Farrell'; Hannes Tschofenig; Barry Leiba Cc: oauth@ietf.org Subject: OK to post OAuth Bearer draft 15? Mark, Stephen, Hannes, and Barry, Any objections to posting the updated Bearer draft incorporating the results of the APPS Area review and the TLS requirements? -- Mike From: Mike Jones Sent: Monday, December 12, 2011 8:51 AM To: Mark Nottingham; 'Stephen Farrell'; oauth@ietf.org<mailto:oauth@ietf.org> Subject: RE: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14 Thanks for the detailed review, Mark. Preliminary draft 15 of the OAuth Bearer specification is attached. It resolves the form encoding issues raised by Julian Reschke in the manner discussed at the working group meeting in Taipei, incorporates the consensus text on TLS version requirements, and contains several improvements suggested by Mark Nottingham during APPS area review. Mark, comments on all your proposed changes follow below: * Section 2.3 URI Query Parameter This section effectively reserves a URI query parameter for the draft's use. This should not be done lightly, since this would be a precedent for the IETF encroaching upon a server's URIs (done previously in RFC5785, but in a much more limited fashion, as a tactic to prevent further, uncontrolled encroachment). Given that the draft already discourages the use of this mechanism, I'd recommend dropping it altogether. If the Working Group wishes it to remain, this issues should be vetted both through the APPS area and the W3C liaison. (The same criticism could be leveled at Section 2.2 Form-Encoded Body Parameter, but that at least isn't surfaced in an identifier) There are some contexts, especially limited browsers and/or development environments, where query parameters are usable but the other methods are not. Thus, the query parameter method must be retained. Also, Justin Richter’s comments describing the value to him of the query parameter method are pertinent: “A URL with all parameters including authorization is a powerful artifact which can be passed around between systems as a unit”. As to using a standard parameter name, this is essential for interoperability. It is not “reserved” in any contexts other than when the Bearer spec is employed, which is a voluntary act by both parties. Thus, this poses no undue burdens or namespace restrictions on implementations in practice. Finally, you’ll find that OAuth 1.0 [RFC 5849<http://tools.ietf.org/html/rfc5849>] similarly defined, not one, but two standard query parameter values: oauth_token and oauth_verifier. As this didn’t cause any problems in practice then, I’m sure that defining an access_token parameter within the Bearer spec for interoperability purposes won’t cause a problem either. * Section 3 The WWW-Authenticate Response Header Field The draft references the quoted-string ABNF from HTTP, but changes its processing in a later paragraph: """In all these cases, no character quoting will occur, as senders are prohibited from using the %5C ('\') character.""" This is at best surprising (as many readers will reasonably surmise that using the quoted-string ABNF implies that the same code can be used). Please either use quoted-string as defined (i.e., with escaping). This parameter definition was a result of significant working group discussion and reflects a solid consensus position. Using the quoted string BNF makes it clear, per Julian Reschke’s suggestions, that generic parameter parsing code can be safely used. Whereas prohibiting the use of backslash quoting by senders also makes it clear that custom implementations can directly utilize the parameter values as transmitted without performing any quote processing. In short, the spec doesn’t change the processing of quoted strings. It simply restricts the set of legal input characters within the quoted strings. * Section 1: Introduction The introduction explains oauth, but it doesn't fully explain the relationship of this specification to OAuth 2.0. E.g., can it be used independently from the rest of OAuth? Likewise, the overview (section 1.3) seems more specific to the OAuth specification than this document. As I read it, this mechanism could be used for ANY bearer token, not just one generated through OAuth flows. If it is indeed more general, I'd recommend minimising the discussion of OAuth, perhaps even removing it from the document title. Per your suggestion, I’ve made it clear in the introduction that bearer tokens from any source can be used to access associated protected resources. The new language in the introduction is: “This specification defines the use of bearer tokens over HTTP/1.1 [I‑D.ietf‑httpbis‑p1‑messaging] using TLS [RFC5246] to access protected resources. … While designed for use with access tokens resulting from OAuth 2.0 Authorization [I‑D.ietf‑oauth‑v2] flows to access OAuth protected resources, this specification actually defines a general HTTP authorization method that can be used with bearer tokens from any source to access any resources protected by those bearer tokens.” * Section 3 The WWW-Authenticate Response Header Field The difference between a realm and a scope is not explained. Are the functionally equivalent, just a single value vs. a list? Realm is as defined by HTTPbis. It says that “The realm value is a string, generally assigned by the origin server, which can have additional semantics specific to the authentication scheme.” The Bearer specification intentionally adds no extra semantics to the realm definition. Whereas the scope parameter is defined as an order-independent space-separated list of scope values. The contextual meaning of both the realm and scope parameters is deployment-dependent. Do you really intend to disallow *all* extension parameters on the challenge? Yes. There was an explicit working group consensus decision to do so. Also, the scope, error, error_description and error_uri parameters all specify only a quoted-string serialisation. HTTPbis strongly suggests that new schemes allow both forms, because implementation experience has shown that implementations will likely support both, no matter how defined; this improves interoperability (see p7 2.3.1). Once again, the current text reflects a consensus decision of the working group. It was viewed that requiring support for multiple ways of doing the same thing unnecessarily complicated implementations without any compensating benefit; better to support one syntax for each semantic operation and require all implementations to use it. Finally, the error_description parameter can carry only ASCII characters. While I understand a tradeoff has been made here (and, in my judgement, an appropriate one), it's appropriate to highlight this in review. Noted * General The draft currently doesn't mention whether Bearer is suitable for use as a proxy authentication scheme. I suspect it *may*; it would be worth discussing this with some proxy implementers to gauge their interest (e.g., Squid). Who would you recommend review the draft from this perspective? Finally, Mark, I applied all the editorial suggestions you made. Thanks for those. Mark, Stephen, and chairs, please let me know whether to now post this draft as an actual submission. Thanks all, -- Mike -----Original Message----- From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org]<mailto:[mailto:oauth-bounces@ietf.org]> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Wednesday, November 23, 2011 11:51 PM To: oauth@ietf.org<mailto:oauth@ietf.org> Subject: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14 FYI -----Original Message----- From: apps-discuss-bounces@ietf.org<mailto:apps-discuss-bounces@ietf.org> [mailto:apps-discuss-bounces@ietf.org]<mailto:[mailto:apps-discuss-bounces@ietf.org]> On Behalf Of ext Mark Nottingham Sent: Thursday, November 24, 2011 8:22 AM To: IETF Apps Discuss; draft-ietf-oauth-v2-bearer.all@ietf.org<mailto:draft-ietf-oauth-v2-bearer.all@ietf.org> Cc: The IESG Subject: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see <http://www.apps.ietf.org/content/applications-area-review-team>). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-oauth-v2-bearer-14 Title: OAuth 2.0 Bearer Tokens Reviewer: Mark Nottingham Review Date: 24/11/2011 Summary: This draft is almost ready for publication as a Proposed Standard, but has a few issues that should be fixed. Major Issues ------------ * Section 2.3 URI Query Parameter This section effectively reserves a URI query parameter for the draft's use. This should not be done lightly, since this would be a precedent for the IETF encroaching upon a server's URIs (done previously in RFC5785, but in a much more limited fashion, as a tactic to prevent further, uncontrolled encroachment). Given that the draft already discourages the use of this mechanism, I'd recommend dropping it altogether. If the Working Group wishes it to remain, this issues should be vetted both through the APPS area and the W3C liaison. (The same criticism could be leveled at Section 2.2 Form-Encoded Body Parameter, but that at least isn't surfaced in an identifier) * Section 3 The WWW-Authenticate Response Header Field The draft references the quoted-string ABNF from HTTP, but changes its processing in a later paragraph: """In all these cases, no character quoting will occur, as senders are prohibited from using the %5C ('\') character.""" This is at best surprising (as many readers will reasonably surmise that using the quoted-string ABNF implies that the same code can be used). Please either use quoted-string as defined (i.e., with escaping). Minor Issues ------------ * Section 1: Introduction The introduction explains oauth, but it doesn't fully explain the relationship of this specification to OAuth 2.0. E.g., can it be used independently from the rest of OAuth? Likewise, the overview (section 1.3) seems more specific to the OAuth specification than this document. As I read it, this mechanism could be used for ANY bearer token, not just one generated through OAuth flows. If it is indeed more general, I'd recommend minimising the discussion of OAuth, perhaps even removing it from the document title. * Section 3 The WWW-Authenticate Response Header Field The difference between a realm and a scope is not explained. Are the functionally equivalent, just a single value vs. a list? Do you really intend to disallow *all* extension parameters on the challenge? Also, the scope, error, error_description and error_uri parameters all specify only a quoted-string serialisation. HTTPbis strongly suggests that new schemes allow both forms, because implementation experience has shown that implementations will likely support both, no matter how defined; this improves interoperability (see p7 2.3.1). Finally, the error_description parameter can carry only ASCII characters. While I understand a tradeoff has been made here (and, in my judgement, an appropriate one), it's appropriate to highlight this in review. * General The draft currently doesn't mention whether Bearer is suitable for use as a proxy authentication scheme. I suspect it *may*; it would be worth discussing this with some proxy implementers to gauge their interest (e.g., Squid). Nits ---- * Section 2.1 Authorization Request Header Field "simplicity reasons" --> "simplicity" "If additional parameters are desired in the future, a different scheme could be defined." --> "If additional parameters are needed in the future, a different scheme would need to be defined." * Section 3 The WWW-Authenticate Response Header Field The requirement that a resource server MUST include the HTTP WWW-Authenticate response header field is odd; really this is at the discretion of the server. Is it really necessary to use a conformance requirement here? URI-reference --> URI-Reference * Section 3.1 Error Codes 405 belongs in the list of typically appropriate status codes as well. Kind regards, -- Mark Nottingham http://www.mnot.net/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org<mailto:apps-discuss@ietf.org> https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] OK to post OAuth Bearer draft 15? Mike Jones
- Re: [OAUTH-WG] OK to post OAuth Bearer draft 15? Mark Nottingham
- Re: [OAUTH-WG] OK to post OAuth Bearer draft 15? Mike Jones
- Re: [OAUTH-WG] OK to post OAuth Bearer draft 15? S Moonesamy
- Re: [OAUTH-WG] OK to post OAuth Bearer draft 15? Barry Leiba
- Re: [OAUTH-WG] OK to post OAuth Bearer draft 15? Mike Jones
- [OAUTH-WG] auth-param syntax, was: OK to post OAu… Julian Reschke
- Re: [OAUTH-WG] OK to post OAuth Bearer draft 15? Mark Nottingham
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… Mike Jones
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… Julian Reschke
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… Mike Jones
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… Julian Reschke
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… Mike Jones
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… Julian Reschke
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… Mike Jones
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… Julian Reschke
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… William Mills
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… William Mills
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… Mike Jones
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… William Mills
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… Mike Jones
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… William Mills
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… Mike Jones
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… William Mills
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… John Bradley
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… Julian Reschke
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… John Bradley
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… Mike Jones
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… Julian Reschke
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… William Mills
- Re: [OAUTH-WG] auth-param syntax, was: OK to post… William Mills