IETF Logo Mail Archive

Re: [OAUTH-WG] Possible alternative resolution to issue 26

Barry Leiba <barryleiba@computer.org> Tue, 04 October 2011 23:45 UTC

Return-Path: <barryleiba.mailing.lists@gmail.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 828F921F8BEC for <oauth@ietfa.amsl.com>; Tue, 4 Oct 2011 16:45:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.963
X-Spam-Level:
X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 aT4zuxIvV+PM for <oauth@ietfa.amsl.com>; Tue, 4 Oct 2011 16:45:07 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id EDF5321F8BE7 for <oauth@ietf.org>; Tue, 4 Oct 2011 16:45:06 -0700 (PDT)
Received: by yxt33 with SMTP id 33so1232518yxt.31 for <oauth@ietf.org>; Tue, 04 Oct 2011 16:48:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LHuPoFwXMC1Pb0rxwT41tYtoCuEsXr5prD0O8VV8eQo=; b=k7b+UgP8tu37jc0Y25rXUnoQ/d8vwfx6aBoqqceFfc8FPzAhzCstoNUwnzp0ukotzy JBwejYI+YxruvaFPfX2pGu4Bu2tOMl/EC0dJNmiWn2wiN5UlwvtBiuOWQAN9ACht6IpN hW9iIfirpLEFytz1BSNCVK1WjcfM/1PcouPyE=
MIME-Version: 1.0
Received: by 10.236.187.36 with SMTP id x24mr10150102yhm.74.1317772093199; Tue, 04 Oct 2011 16:48:13 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.146.83.8 with HTTP; Tue, 4 Oct 2011 16:48:12 -0700 (PDT)
In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CAAA@SISPE7MB1.commscope.com>
References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <C2C10679-2611-415B-80B7-8526937C1E82@oracle.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> <CAGdjJpJ+XkyPAJXEJa-3p3tNTxKzMpZXSHmH3H-m-7T9v=4x0Q@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CAAA@SISPE7MB1.commscope.com>
Date: Tue, 04 Oct 2011 19:48:12 -0400
X-Google-Sender-Auth: oPydjYtEhfDqGfPI_7rlmSHpWG0
Message-ID: <CAC4RtVBkhHNF7dtfwhVr9oNa2+y+JT-sTaYY1nm2=rWu2s2tQQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: "Thomson, Martin" <Martin.Thomson@commscope.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26
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: Tue, 04 Oct 2011 23:45:07 -0000

>> Existing practice is that simple ASCII strings like "email" "profile",
>> "openid", etc. are used as scope elements.  Requiring them to be URIs
>> would break most existing practice.
>
> Constraining syntax to an ascii token OR a URI (relative reference) might
> work.  Anything with a colon can be interpreted as a URI; anything without
> better use a constrained set of characters.

This sounds like a good compromise.  URI encoding is already specified
elsewhere, and then ASCII tokens can be limited as they already are,
with no encoding.

Are there any objections to this approach?

Barry

v2.23.0 | Report a Bug | By Email