My client implementation per latest draft did not work against a major
vendor's server implementation.
This was because the vendor REQUIRES the scope parameter in the initial
request. If I do not supply the scope parameter, it calls back the URL
with an error response stating that the request is
t. I hope the essential concept made it through my writing!
A.
On Mon, Jan 9, 2012 at 3:47 PM, SM wrote:
> Hello,
>
> At 15:14 09-01-2012, agks mehx wrote:
>
>> Thank you for the response. If I understand correctly, the vendor is
>> correctly that their implementation
ions I have seen implement as an empty scope. Are you worried
> specifically about the scope parameter in the HTTP requests, or as
> represented in the credential used to access the PR?
>
> ------
> *From:* agks mehx
> *To:* SM ; Eran Hammer ;
> oaut
empty scopes, and it would be completely valid
> for the auth server to reject a request for an unknown scope, which could
> include the empty scope if the auth server doesn't support it.
>
> -bill
>
> --
> *From:* agks mehx
> *To:* William M
t. Do we need that here too? Would that make
> it clearer?
>
> --
> *From:* agks mehx
> *To:* William Mills ; oauth@ietf.org
> *Cc:* SM ; Eran Hammer
> *Sent:* Monday, January 9, 2012 5:57 PM
>
> *Subject:* Re: [OAUTH-WG] Seeking Clarifi
Sounds very good: "... MAY include or omit the scope parameter. If omitted,
the server must process the request using an empty scope as the default."
On Tue, Jan 10, 2012 at 4:02 PM, William Mills wrote:
> On your #1, I don't agree that an empty scope is useless. There are
> comparable implemen
I would be unhappy if things were sugarcoated any further. This is
definitely a rare specification where OPTIONAL parameters in the API can be
REQUIRED by a conforming implmentation (as I discussed in my note on the
scope parameter for which the proposed modification does not really change
much)
