Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Julian Reschke <julian.reschke@gmx.de> Sat, 15 October 2011 12:20 UTC

Return-Path: <julian.reschke@gmx.de>
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 F115521F8B5D for <oauth@ietfa.amsl.com>; Sat, 15 Oct 2011 05:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.488
X-Spam-Level:
X-Spam-Status: No, score=-104.488 tagged_above=-999 required=5 tests=[AWL=-1.889, 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 o8KbEp-rWU+j for <oauth@ietfa.amsl.com>; Sat, 15 Oct 2011 05:20:22 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 08AB221F8B5B for <oauth@ietf.org>; Sat, 15 Oct 2011 05:20:21 -0700 (PDT)
Received: (qmail invoked by alias); 15 Oct 2011 12:20:20 -0000
Received: from p5DCCB50E.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.181.14] by mail.gmx.net (mp015) with SMTP; 15 Oct 2011 14:20:20 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/0KVAMM7f0wTpH+A732MpZfmtQieI3J9m2MsqALG Yc7SQOPQ6cUPr6
Message-ID: <4E997A80.3000202@gmx.de>
Date: Sat, 15 Oct 2011 14:20:16 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net>
In-Reply-To: <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions
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: Sat, 15 Oct 2011 12:20:23 -0000

On 2011-10-15 14:16, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> Hi Mike,
>
> this is not specific enough. A string could be defined as
> "
> A string is a sequence of zero or more Unicode characters [UNICODE].
> "
> (as in RFC 4627), or as
> "
> 8-bit binary data without a NUL (hex 00) termination
> "
> (as in RADIUS, RFC 2865).
>
> In any case, we have to consider the constraints from the usage of
> "application/x-www-form-urlencoded". In our specific case this means
> that we have to get from the scope string to an octet sequence, which is
> allowed by application/x-www-form-urlencoded.
>
> Julian had pointed to this issue already (see mail from October 7th).
>
> If you want any string (with the exception of SP, which is the
> delimiter) then you have to choose an encoding that is able to represent
> Unicode in ASCII. There are a few choices and according to Julian the
> following options exist:
>
> a) RFC 5987
> b) URI encoding to UTF-8 encoding
> (which is essentially like RFC 5987 but to omit the language part of the
> triple)

Actually, omitting both the charset and the language part, and 
hardwiring the encoding to UTF-8.

> c) JSON (with the problem that the "\" notation in the quoted-string)
>
> If you want to go along this route then I would suggest to go for (a)
> and to include a couple of examples (see Section 3.2.2 of RFC 5987 for
> examples). This is clearly better than inventing a new mechanism
> ourselves. The language tag is optional and RFC 5987 only requires
> parser support for UTF-8 and ISO-8859-1.

...and for RFC5987bis we are discussing to restrict this to UTF-8 only...

Best regards, Julian