Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-22.txt

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 17 July 2012 17:57 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022DF21F86B2; Tue, 17 Jul 2012 10:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.957
X-Spam-Level:
X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=-0.358, 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 NHzt2Scnck+4; Tue, 17 Jul 2012 10:57:07 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 2772521F863E; Tue, 17 Jul 2012 10:57:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342547874; d=isode.com; s=selector; i=@isode.com; bh=5P83iUVCAG+WnWmVsN04N0M/8nuqyPQ2/O4HMC7Mdtk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=tojbabbdowUbiyx5maojwX4xRGxME+sOJvcEKL7DhfaA5MzcL8aHowzSvXcnngIiuluvx6 CgZ0mgYBhpYzo4F/s/LWbx7kt6kiXtsAcQenL3Z2cYs5yGh+J/PJuGbwgG5XbfIDo+ukEI B4KXUjko3x90FuXlSbpfq+sz0mMTtoE=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <UAWnmwAdirP-@statler.isode.com>; Tue, 17 Jul 2012 18:57:53 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <5005A79A.6010504@isode.com>
Date: Tue, 17 Jul 2012 18:57:46 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: Mike Jones <Michael.Jones@microsoft.com>
References: <4F2575CE.9040001@isode.com> <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F27C37C.1090008@isode.com> <4F843A22.4020908@isode.com> <4F843DA1.8080703@isode.com> <500546C5.6080102@isode.com>, <50054897.3070108@cs.tcd.ie> <4E1F6AAD24975D4BA5B1680429673943667370D7@TK5EX14MBXC285.redmond.corp.microsoft.com> <50059598.3030304@gmx.de> <50059A95.7050904@isode.com> <4E1F6AAD24975D4BA5B16804296739436673743F@TK5EX14MBXC285.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436673743F@TK5EX14MBXC285.redmond.corp.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" <draft-ietf-oauth-v2-bearer.all@tools.ietf.org>, Julian Reschke <julian.reschke@gmx.de>, General Area Review Team <gen-art@ietf.org>, The IESG <iesg@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-22.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jul 2012 17:57:08 -0000

On 17/07/2012 18:15, Mike Jones wrote:
> For clarity of discussion, the definition in question is:
>       b64token    = 1*( ALPHA / DIGIT /
>                         "-" / "." / "_" / "~" / "+" / "/" ) *"="
>
> Note that b64token is a liberal syntax intended to permit base64 encoded content (hence the inclusion of the "+" and "/" characters and the optional trailing "=" characters), base64url encoded content (hence the inclusion of the "-" and "_" characters) and other URL-safe productions (hence the inclusion of the "." and "~" characters).
>
> Its use is definitely not intended to be restricted to base64 encoded content, per RFC 4648. If it were so restricted (by not allowing ".", for instance), this would exclude the use of JWTs as bearer tokens, for instance, which is something we *definitely* want to allow.
>
> As a result, I don't think adding a reference to RFC 4648 is either necessary or appropriate.

In this case, can you please rename the production to something which is 
clearly not a base64 string.

> Julian may be able to provide more background.
>
> 				Best wishes,
> 				-- Mike
>
> -----Original Message-----
> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]
> Sent: Tuesday, July 17, 2012 10:02 AM
> To: Julian Reschke; Mike Jones
> Cc: The IESG; General Area Review Team; oauth@ietf.org; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Stephen Farrell
> Subject: Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-22.txt
>
> On 17/07/2012 17:40, Julian Reschke wrote:
>> On 2012-07-17 18:10, Mike Jones wrote:
>>> FYI, the b64 token definition is identical to the one in
>>> draft-ietf-httpbis-p7-auth-20.  If it works there, it should work for
>>> OAuth Bearer.
>>> ...
>> +1; not every constraint needs to be expressed in the ABNF. "b64token"
>> is here so recipients can parse the header field; it's up to the auth
>> scheme to state what the addition constraints are; and that can happen
>> in prose.
> I didn't say that it has to be expressed in ABNF (although I obviously wouldn't mind). I would like an ABNF comment pointing to the document which defines base64.
>
>
>