Re: [OAUTH-WG] What to do about 'realm'

Robert Sayre <sayrer@gmail.com> Sun, 11 July 2010 22:32 UTC

Return-Path: <sayrer@gmail.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E101A3A68B1 for <oauth@core3.amsl.com>; Sun, 11 Jul 2010 15:32:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDiuCztEaytG for <oauth@core3.amsl.com>; Sun, 11 Jul 2010 15:32:00 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id A417528C0CF for <oauth@ietf.org>; Sun, 11 Jul 2010 15:31:59 -0700 (PDT)
Received: by vws14 with SMTP id 14so3845199vws.31 for <oauth@ietf.org>; Sun, 11 Jul 2010 15:32:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8lTNRbDUWZJbtO89a/764xRmt+RPjfXz+O92NHg3CME=; b=lJMaw9RuV1Lpuj2azlw1wCsFqcz6QggrADg4byHnT5MR1E0vjccSwgMOU0QcI5Gatz QyBLmCUGRq+oc/maa/sH+F03YFKvPECssXv7ygHjIO15bgsRz/nIZWNzshJDF8s3/tLO NIKs2GNlwTVk8ckFPFHvgfY3/8lxzJi4IoWas=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TtI5Dh0tTWPxk2Wtn+KYuC2+VY700dwD6Z2S22BlMuMtmpZwFLGqKQtClXrVAcHrMF K9FpQ7qNH9+5HGdiMMsOQz8RPfWK7t8Nke6Aj4yKBxRQJDxDCFURugdErFd6VXLGJ7aY RoNbXXTnKE73oHqKYc8e5yZ9eIfosXWyzNdq0=
MIME-Version: 1.0
Received: by 10.229.38.68 with SMTP id a4mr7835746qce.112.1278887522074; Sun, 11 Jul 2010 15:32:02 -0700 (PDT)
Received: by 10.229.83.130 with HTTP; Sun, 11 Jul 2010 15:32:01 -0700 (PDT)
In-Reply-To: <C85F694F.36FF1%eran@hueniverse.com>
References: <AANLkTikLogvJAhE9LF60MDyEiqvpDM8WD8tSUr4fZLjP@mail.gmail.com> <C85F694F.36FF1%eran@hueniverse.com>
Date: Sun, 11 Jul 2010 15:32:01 -0700
Message-ID: <AANLkTil8wp2A6JN_td7hwSAttPH6dG_U6PPakb6-vlsb@mail.gmail.com>
From: Robert Sayre <sayrer@gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] What to do about 'realm'
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 11 Jul 2010 22:32:01 -0000

On Sun, Jul 11, 2010 at 12:27 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> [this has noting to do with realm]
>
> Any solution should be:
>
> - Extensible – we removed the few discovery parameters from the core spec
> due to lack of maturity and consensus. However, we clearly have enough
> strong interest in reintroducing them as extensions. The WWW-Authenticate
> header is the natural place to include them.

This is true. I thought it obvious that implementations would be
required to deal with text after the "OAuth2" string.

>
> - Human-friendly – I think being able to look at the header and immediately
> see what it means is useful.

I'm not sure this is valuable, but it is possible to accomodate the
concern anyway. I use a protocol analyzer, like WireShark.

> Is there a JSON profile suitable for inclusion
> in HTTP headers? I would like to avoid BASE64 when a person is likely to
> take a look at the header. Otherwise debugging and command line interaction
> become impractical.

The WG could specify that all control characters and non-ASCII text
within the JSON text be escaped. base64 adds overhead to the endeavor,
so it's probably best to avoid it, because most of the bits will be
ASCII anyway.

If browser clients need to set headers in the same manner, this could
be more inconvenient, because the JSON serializers shipping in
browsers today don't support requiring that the produced text be
escaped. This can be done as a follow-up pass, though. [0]

Using a JSON serialization neatly sidesteps several i18n issues. If
you go with traditional HTTP header syntax, you'll need to deal with
that some other way. btw, it just so happens that internationalization
of Realm values is a bug in most RFC2617 implemenations.


[0] (I happen to be on the ECMAScript committee, and I can be blamed
for Mozilla's native JSON object. It would be technically easy to add
a JSON.stringifyAsASCII() method, and I think the committee will go
for it.)



-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."