I think the limit makes sense, but then are tokens limited by the same rules?
They need to live in all the same places (query parameters, headers, forms)
that scopes do and would be subject to the same kinds of encoding woes that
scopes will. Or am I missing something obvious as to why this isn'
Restricting it now in the core spec is going to save a lot of headaches later.
John B.
On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote:
> It's an open question for the list.
>
> EHL
>
>> -Original Message-
>> From: Julian Reschke [mailto:julian.resc...@gmx.de]
>> Sent: Sunday, Octobe
It's an open question for the list.
EHL
> -Original Message-
> From: Julian Reschke [mailto:julian.resc...@gmx.de]
> Sent: Sunday, October 16, 2011 11:00 AM
> To: Mike Jones
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth WG;
> Eran Hammer-Lahav
> Subject: Re: [OAUTH-W
On 2011-10-16 18:44, Mike Jones wrote:
As Eran wrote on 9/30, "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."
...
I see. Thanks.
Is this going to be clarified in -23?
Best regards, Julia
As Eran wrote on 9/30, "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."
-- Mike
-Original Message-
From: Julian Reschke [mailto:julian.resc...@gmx.de]
On 2011-10-16 07:12, Mike Jones wrote:
In your note yesterday summarizing our proposed issue resolutions, you wrote "The
scope field is yet another item that will not be shown to the user and it serves the
purpose of an identifier for authorization comparison. So, we don't need to have any
int
