+1 to "I think James made it pretty clear that we have a problem and that we have to solve it."
On Wed, Sep 28, 2011 at 10:36 AM, Marius Scurtescu <mscurte...@google.com> wrote: > On Wed, Sep 28, 2011 at 6:40 AM, Barry Leiba <barryle...@computer.org> > wrote: >> >> I'd like to see more participation in this thread, besides just from >> Mike and James. What do others think? > > I think James made it pretty clear that we have a problem and that we have > to solve it. > One solution would be for the core spec to limit the characters that can be > used in a scope, such that scopes are HTTP header safe. I think this would > be pretty limiting and fragile. > Another solution would be for the bearer spec to specify what escaping > should be used. RFC 5987 seems like the only good choice. > Marius >> >> Barry, as chair >> >> On Mon, Sep 26, 2011 at 3:05 PM, Mike Jones <michael.jo...@microsoft.com> >> wrote: >> > While you take the viewpoint that the bearer spec is restricting scope >> > values, in fact, the spec intentionally allows all characters that can >> > be >> > safely communicated in an HTTP response header parameter to be >> > used. About whether those characters employ an encoding >> > methodology to sometimes represent other characters or abstractions, >> > I believe that Barry's proposed wording hits the nail on the head: >> > >> > Interpretation of scope strings requires semantic agreement on the >> > meaning of the scope strings between the parties participating the >> > OAuth flow. Should an encoding be used for scope strings in a >> > particular deployment context, participants have to have agreed >> > upon that encoding, just as they agree on other OAuth configuration >> > parameters. >> > >> > Best wishes, >> > -- Mike >> >> >> On Mon, Sep 26, 2011 at 8:20 PM, Manger, James H >> <james.h.man...@team.telstra.com> wrote: >> >> While you take the viewpoint that the bearer spec is restricting scope >> >> values, in fact, >> >> the spec intentionally allows all characters that can be safely >> >> communicated in an HTTP >> >> response header parameter to be used. >> > >> > But "all characters that can be safely communicated in an HTTP response >> > header parameter" is only a subset of the characters that OAuth Core >> > allows in a scope value (any Unicode string excluding space). I don't >> > understand how this isn't the Bearer spec restricting scope values. >> > >> > >> > P.S. You recognize here that non-ASCII chars cannot be safely >> > communicated in an HTTP response header parameter. This is why >> > Julian was concerned about the spec saying the error_description holds >> > raw UTF-8. >> > [Actually the ABNF for error_description restricts it to 93 ASCII chars >> > so >> > when the text says it is UTF-8 encoded it is raising the potential >> > problem >> > of arbitrary UTF-8 in HTTP headers unnecessarily.] >> > >> > -- >> > James Manger >> >> >> On Tue, Sep 27, 2011 at 11:50 PM, Manger, James H >> <james.h.man...@team.telstra.com> wrote: >> > I'll have another go trying to explain the problem I see with the scope >> > parameter in the Bearer spec. >> > >> > Consider a French social network that decides to offer an API using >> > OAuth2. >> > It chooses 3 scope values for parts of the API related to family, >> > friends, and >> > business colleagues: >> > * "famille" >> > * "ami" >> > * "collègues" >> > Let's focus on the last scope. >> > >> > The site describes the scope and its semantics in HTML developer docs. >> > That works. >> > <dt>collègues</dt><dd>...</dd> >> > >> > Client apps construct authorization URIs to which users are sent. >> > That works. >> > https://example.fr/authz?scope=coll%C3%A8gues... >> > >> > The authorization server issues credentials in a JSON token response. >> > That works. >> > { "access_token":"SlAV32hkKG", "scope":"coll\u00E8gues", ...} >> > >> > The authorization server also supports implicit grants. That works. >> > Location: https://app.client.org/callback#scope=coll%C3%A8gues... >> > >> > Client apps request protected resources (without needing to mention >> > scope). >> > That works. >> > Authorization: Bearer vF9dft4qmT >> > >> > A protected resource server responds with a 401 error when a bearer >> > token >> > is wrong. They don't know what to put in the HTTP response header scope >> > parameter: "collègues" does not fit. >> > >> > One server knows HTTP headers have historically used ISO-8859-1. >> > WWW-Authenticate: Bearer scope="coll<E8>gues", >> > error_description="opps"... >> > >> > Another server sees that error_description is specified as UTF-8 so uses >> > that. >> > WWW-Authenticate: Bearer scope="coll<C3><A8>gues", >> > error_description="opps"... >> > >> > A third server reasons that the value will be copied to an authz URI so >> > uses >> > URI-escaping. >> > WWW-Authenticate: Bearer scope="coll%C3%A8gues", >> > error_description="opps"... >> > >> > A fourth server thinks JSON-escaping looks most like HTTP's >> > quoted-string >> > quoting (both use '\'). >> > WWW-Authenticate: Bearer scope="coll\u00E8gues", >> > error_description="opps"... >> > >> > A fifth uses RFC 5987 "Character Set and Language Encoding for HTTP >> > Header >> > Field Parameters": >> > WWW-Authenticate: Bearer scope*=UTF-8''coll%C3%A8gues, >> > error_description="opps"... >> > >> > It is a total interoperability failure for the client apps. The >> > paragraph in the Bearer >> > spec saying the encoding of the scope values is up to each "particular >> > deployment context" looks like a cruel joke to the app and library >> > developers. >> > >> > -- >> > James Manger >> _______________________________________________ >> 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
