Another way to think about it is that the current text reserves the space
character to mean something specific but doesn't prevent service providers from
using any other delimiter as they see fit.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
First, there is nothing preventing the server from using:
scope=photos:read profile:read friends:read
or:
scope=photos:read profile:readwrite friends:write
---
I think the current language strikes the right balance between interop and
scopes definitions. While a generic client will not unders
The current spec defines scope (when the scope variable is introduced) as:
scope
OPTIONAL. The scope of the access request expressed as a list
of space-delimited strings. The value of the "scope" parameter
is defined by the authorization server. If the value contai
I vote for (3) unless a good (4) is suggested.
On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote:
> Over the past year many people expressed concerns about the use of the
> ‘realm’ WWW-Authenticate header parameter. The parameter is defined in RFC
> 2617 as required, and is allowed to have sch
Over the past year many people expressed concerns about the use of the 'realm'
WWW-Authenticate header parameter. The parameter is defined in RFC 2617 as
required, and is allowed to have scheme-specific structure.
We have a few options:
1. Leave it as required under the definition of RFC 2617 (
Hi everybody,
We're looking to adopt OAuth 2.0 here at Open Dining, and we couldn't find a
suitable PHP server implementation. With the draft status of the spec in
mind, we took a crack at an implementation anyway.
Documentation is very sparse still, but we commented the heck out of the
source.
On Sun, Jun 13, 2010 at 11:20 AM, Evan Gilbert wrote:
>
>>
>> Can you explain the XSS hole from parsing a random JSON string?
>
> Naive processor calls:
> var href = document.location.href;
> var jsonBlob = href.substring(href.indexOf('#'), href.length)
> var userData = eval(jsonBlob);
> This cod
