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

Marius Scurtescu <mscurtescu@google.com> Tue, 04 October 2011 18:36 UTC

Return-Path: <mscurtescu@google.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 D44BB21F8E0B for <oauth@ietfa.amsl.com>; Tue, 4 Oct 2011 11:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.119
X-Spam-Level:
X-Spam-Status: No, score=-106.119 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 A1uExJmNYdRJ for <oauth@ietfa.amsl.com>; Tue, 4 Oct 2011 11:36:12 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 328C121F8E01 for <oauth@ietf.org>; Tue, 4 Oct 2011 11:36:11 -0700 (PDT)
Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p94IdGLc028250 for <oauth@ietf.org>; Tue, 4 Oct 2011 11:39:16 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317753556; bh=lY6kqql/34ixrQEE8DWQK0HyZbg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CdhCjTKrP4PxNBe0PFVLMewlQzGOzppQcgDfdclUTaVn15lDdf4R3LRkei/VrG33O 9MBa8WNUwR69b8T4opMrw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=cCU6zSveJvLAOUVH/QvDoHs4BhTJDVVJ8TtPF2G6fvEfhRRxSfeg6tpM0LJ2VCYAg ZL5g2F1aiJZgBeUGfMPKg==
Received: from yxt3 (yxt3.prod.google.com [10.190.5.195]) by hpaq7.eem.corp.google.com with ESMTP id p94IcMHr027388 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <oauth@ietf.org>; Tue, 4 Oct 2011 11:39:15 -0700
Received: by yxt3 with SMTP id 3so1513190yxt.30 for <oauth@ietf.org>; Tue, 04 Oct 2011 11:39:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A6AbeEGbMtZb47ZB72sUhOwHMa9bnxWYPPK0jnwqyEQ=; b=lAlv4c8kYhkFrBwF5iOPn2qzpC/sA4wytl6CtzdcUNTiBYY1OgE/LFziF01Gi3s7pA AYj899Rvvjh08UYun9lQ==
Received: by 10.100.233.33 with SMTP id f33mr1317666anh.123.1317753550410; Tue, 04 Oct 2011 11:39:10 -0700 (PDT)
Received: by 10.100.233.33 with SMTP id f33mr1317651anh.123.1317753549975; Tue, 04 Oct 2011 11:39:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.142.14 with HTTP; Tue, 4 Oct 2011 11:38:48 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.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>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Tue, 4 Oct 2011 11:38:48 -0700
Message-ID: <CAGdjJpLeGECqjGrMZyBAx+ewA3KcMazaZxJsKS7h1Atj5Tp=Pw@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=001636ed62ee3f739704ae7d68aa
X-System-Of-Record: true
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 18:36:13 -0000

On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones <Michael.Jones@microsoft.com>wrote:

>  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.
>

Aren't these simple strings URIs? I think they are parsed as a URI with no
scheme and authority only a path.

Marius


> ****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Marius Scurtescu
> *Sent:* Tuesday, October 04, 2011 11:01 AM
> *To:* Phil Hunt
> *Cc:* oauth@ietf.org WG
>
> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26****
>
> ** **
>
> I just realized that scopes are defined as a space separated list of
> strings, for some reason I though they are a list of URIs.****
>
> ** **
>
> Mark Lentczner just clarified for me that URIs are supposed to be ASCII
> only. IRIs can have non-ASCII characters and can be canonically converted to
> URIs using percent encoding (back to square one).****
>
> ** **
>
> If the core spec defines scope as list of URIs then the whole issue goes
> away. Any reason not to do that?****
>
> ** **
>
> Marius
>
> ****
>
> On Tue, Oct 4, 2011 at 10:18 AM, Phil Hunt <phil.hunt@oracle.com> wrote:**
> **
>
> I very much agree with you there.  As I said, simple roles are best and are
> by far the primary case.****
>
> ** **
>
> I'm just not so sure we should close the door.****
>
> ** **
>
> Phil****
>
> ** **
>
> @independentid****
>
> www.independentid.com****
>
> phil.hunt@oracle.com****
>
> ** **
>
> ** **
>
> ** **
>
> On 2011-10-04, at 9:58 AM, William Mills wrote:****
>
>
>
> ****
>
> I don't believe that scope is the right place to carry a more complex
> grant, those would live in the token.  That would more logically go in the
> token.  XML gets weird when you get to the part about space separationoand
> order doesn't matter.  Scope's current definition makes it incompatible in
> sublte ways with using it for XML.****
>
> ** **
>    ------------------------------
>
> *From:* Phil Hunt <phil.hunt@oracle.com>
> *To:* "oauth@ietf.org WG" <oauth@ietf.org>
> *Sent:* Tuesday, October 4, 2011 9:47 AM
> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26
>
> In most cases, scope has just been a set of simple "roles" as in
> "readProfile", "updateStatus", etc.
>
> I tend to agree scope is an internal value that SHOULD never be seen by
> end-users (this should be made clear). The meaning of a scope must be
> conveyed in authorization dialog, the how of which is out of scope.  Since
> the resource server defines how it scopes information, it should be able to
> explain the meaning of a scope request in localized language.
>
> I'm not against encoding the value if necessary to handle non-printable
> characters. The issue I think comes back to complexity for the clients.
> Would such encoding be problematic for the clients envisioned?
>
> Some examples I can think of:
> * A URL to a specific resource
> * An XML or JSON structure representing a more complex "grant" or policy
> statement
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On 2011-10-04, at 9:01 AM, Michael Thomas wrote:
>
> > On 10/03/2011 09:58 PM, William Mills wrote:
> >> You forgot:
> >>
> >> 4.  Restrict the character set for scope to the point where these issues
> all go away.
> >
> > Assuming that this is *completely* internal, and no end users will ever
> > see either of these,  this seems like the most prudent if
> interoperability
> > is the primary goal. The principle of least surprise, and all.
> >
> > But completely internal is impossible to guarantee, so I guess the
> question
> > is whether an incomprehensible katakana-encoded message/token is any
> > worse than  an incomprehensible ascii-7 english one to the poor end user
> > who's trying to make sense of it. If it isn't then keeping things simple
> is
> > probably safer. I assume the reason that 5987 exists is because as a
> > whole, http shouldn't make any assumptions about whether users will
> > see header field data. But these are individual cases here, not a
> protocol-wide
> > mandate.
> >
> > Mike
> >
> >>
> >> ------------------------------------------------------------------------
> >> *From:* Mike Jones <Michael.Jones@microsoft.com>
> >> *To:* "oauth@ietf.org" <oauth@ietf.org>
> >> *Cc:* "Manger, James H" <James.H.Manger@team.telstra.com>; William
> Mills <wmills@yahoo-inc.com>
> >> *Sent:* Monday, October 3, 2011 6:55 PM
> >> *Subject:* RE: [OAUTH-WG] Possible alternative resolution to issue 26
> >>
> >> As editor, based upon James’ input, I’d like to expand the set of
> choices for the working group to consider by adding the possibility of using
> JSON string encodings for scope and error_description where the characters
> used for the encoding are restricted to the set of 7-bit ASCII characters
> compatible with the HTTPbis and RFC 2617 parameter syntaxes.
> >> 1.  Using RFC 5987 encoding for the scope parameter.
> >> 2.  Continuing to specify no non-ASCII encoding for scope parameter
> values.
> >> 3.  Using JSON string encoding for the scope parameter.
> >> A.  Using RFC 5987 encoding for the error_description parameter.
> >> B.  Continuing to specify UTF-8 encoding for the error_description
> parameter.
> >> C.  Using JSON string encoding for the error_description parameter.
> >> As an individual, I’m sympathetic to the argument that RFC 5987 (with
> “scope*” and language tags etc.) is overkill for OAuth implementations,
> where neither of the sets of strings is intended to be presented to
> end-users.  Hence, the possible attractiveness of options 3 and C.
> >> Thoughts from others?
> >>                                                                -- Mike
> >> *From:* William Mills [mailto:wmills@yahoo-inc.com]
> >> *Sent:* Sunday, October 02, 2011 11:01 PM
> >> *To:* Manger, James H; Mike Jones; oauth@ietf.org
> >> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26
> >> I don't like dropping scope from the WWW-Authenticate responses, because
> my current discovery usage requires scope to be returned so that it can be
> passed to the auth server if the user is forced to re-authenticate.
> >> +1 for "explicitly restrict scope values to some subset of printable
> ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol is
> slightly disappointing, but I can live with it."
> >>
> >> ------------------------------------------------------------------------
> >> *From:* "Manger, James H" <James.H.Manger@team.telstra.com <mailto:
> James.H.Manger@team.telstra.com>>
> >> *To:* Mike Jones <Michael.Jones@microsoft.com <mailto:
> Michael.Jones@microsoft.com>>; "oauth@ietf.org <mailto:oauth@ietf.org>" <
> oauth@ietf.org <mailto:oauth@ietf.org>>
> >> *Sent:* Sunday, October 2, 2011 5:50 AM
> >> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26
> >> The best solution is to drop the “scope” field from the
> “WWW-Authenticate: Bearer ...” response header. “scope” is relevant to an
> OAuth2-core flow, not to presenting a bearer token. “scope” could make sense
> in a “WWW-Authenticate: OAuth2 ...” response header as long as other
> necessary details such as an authorization URI were also provided. Dropping
> “scope” and “error_description” (as the error should be described in the
> response body) would eliminate these encoding problems.
> >> If the group really wants to keep “scope”, I don’t think RFC 5987 is a
> good solution. RFC 5987 might have been ok for adding internationalization
> support to long-standing ASCII-only fields in a world of multiple character
> sets – but none of that applies here. Having to change the field name from
> “scope” to “scope*” when you have a non-ASCII value is the biggest flaw.
> >> The simplest solution is to explicitly restrict scope values to some
> subset of printable ASCII in OAuth2 Core. Not being able to support Unicode
> in a new protocol is slightly disappointing, but I can live with it.
> >> My preferred escaping solution would be a JSON string, UTF-8 encoded:
> json.org <http://json.org>, RFC 4627; value in double-quotes; slash is the
> escape char; supports Unicode; eg scope="coll\u00E8gues". This is
> backward-compatible with HTTP’s quoted-string syntax. It is
> forward-compatible with UTF-8 HTTP headers (if that occurs). JSON is
> well-supported (and required for other OAuth2 exchanges). [I might suggest
> json-string to the httpbis group as a global replacement for quoted-string
> (or at least as a recommendation for new fields).]
> >> --
> >> James Manger
> >> *From:* oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org> [mailto:
> oauth-bounces@ietf.org] <mailto:[mailto:oauth-bounces@ietf.org]> *On
> Behalf Of *Mike Jones
> >> *Sent:* Friday, 30 September 2011 4:53 AM
> >> *To:* oauth@ietf.org <mailto:oauth@ietf.org>
> >> *Subject:* [OAUTH-WG] Possible alternative resolution to issue 26
> >> There seems to now be more working group interest in representing
> non-ASCII characters in scope strings than had previously been in evidence.
> If we decide to define a standard representation for doing so, using RFC
> 5987 <http://tools.ietf.org/html/rfc5987> (Character Set and Language
> Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters)
> seems to be the clear choice.  I’d be interested in knowing how many working
> group members are in favor of either:
> >> 1.  Using RFC 5987 encoding for the scope parameter.
> >> 2.  Continuing to specify no non-ASCII encoding for scope parameter
> values.
> >> As a related issue, some working group members have objected to
> specifying UTF-8 encoding of the error_description value, requesting the use
> of RFC 5987 encoding instead.  I’d also be interested in knowing how many
> working group members are in favor of either:
> >> A.  Using RFC 5987 encoding for the error_description parameter.
> >> B.  Continuing to specify UTF-8 encoding for the error_description
> parameter.
> >> (As editor, I would make the observation that if we choose RFC 5987
> encoding for either of these parameters, it would be logical to do so for
> the other one as well.)
> >> In the interest of finishing the specification in a way that meets
> everyone’s needs,
> >>                                                            -- Mike
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org <mailto:OAuth@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> ****
>
> ** **
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>