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

From: Mike Jones <[email-masked]>
Date: Thu, 29 Sep 2011 18:52:36 +0000

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

---

From: Buhake Sindi <[email-masked]>
Date: Fri, 30 Sep 2011 14:03:30 +0200

Hi everyone,

As for encoding, my understanding is that the scope parameter were scope
fields provided by the service provider and that scope should match the
service provider scope. Fair enough, we could argue that non-UTF-8
characters can't be sent over HTTP response headers, so a better solution, I
would suggest is illustrated in section 4.2, Error Handling, of RFC 5987.

My solution: add an encoding as a value of the scope and error-desc,
followed by a colon (:) and then the percentage-encoded message.

So, the message, is first encoded to the encoding specified, and then
percentage-encoded:

Example:

error-descr="UTF-8: <percentage-encoded of an UTF-8 message>"

The client would then:

   1. Percentage decode the string and get the string based on the encoding.

Problem is though, the length of the string value.

Any thoughts?

On 29 September 2011 20:52, Mike Jones <[email-masked]> wrote:

>  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.****
>
> ****
> ** **
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
The Elite Gentleman

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Sep 2011 15:22:04 +0200

On 2011-09-30 14:03, Buhake Sindi wrote:
> characters can't be sent over HTTP response headers, so a better
> solution, I would suggest is illustrated in section 4.2, Error Handling,
> of RFC 5987.
>

Why invent yet another format that's close to RFC 5987 but not the same?

> Problem is though, the length of the string value.

How is that a problem?

 > ...

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Fri, 30 Sep 2011 15:20:06 +0000

Thus far, I've received no responses preferring 1 or 2 or preferring A or B.  Could people please weigh in so that the working group has data to base a decision on to close this issue?

                                                            Thanks,
                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Thursday, September 29, 2011 11:53 AM
To: [email-masked]
Subject: [OAUTH-WG] Possible alternative resolution to issue 26

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 30 Sep 2011 08:35:57 -0700

Two observations:

-          I doubt anyone is going to implement RFC 5987 in most OAuth 2.0 libraries, mostly because it offers little value and,

-          No one really needs scope values other than limited ASCII or URIs

There should not be any interoperability issues with the error_description value as long as it is valid for HTTP transport because it is for debugging only. If a provider returns some other character set than plain ASCII in there, it is safe to assume the developer will figure it out.

The fact that the v2 spec allows a wide range of characters in scope was unintentional. The design was limited to allow simple ASCII strings and URIs. Crossing the boundaries of v2 into the bearer spec is the first place where this flexibility has been tested.

Scope are machine-readable strings and URIs already provide a way to include internationalization. OAuth parameters are all in English and it is reasonable to expect most providers to craft their scope values within those undeclared boundaries.

I am not expressing a strong opinion because I don't think this is a real issue. Internationalization matters when it comes to end-user interaction, not developers. But the most consistent choice based on the past 2 years of use cases and examples is to simply limit the scope character-set in v2 and avoid all this.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, September 30, 2011 8:20 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26

                                                            Thanks,
                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones
Sent: Thursday, September 29, 2011 11:53 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] Possible alternative resolution to issue 26