b...@uninett.no]
> Sent: Monday, January 23, 2012 1:23 AM
> To: Eran Hammer
> Cc: William Mills; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
> Specification
>
> Den 20. jan. 2012 kl. 21:32 skrev Eran Hammer:
>
> > New text
Den 20. jan. 2012 kl. 21:32 skrev Eran Hammer:
> New text added to Access Token Scope section:
>
> If the client omits the scope parameter when requesting
> authorization, the authorization
> server MUST process the request using a pre-defined default value,
> or fail the r
Works for me.
From: Eran Hammer
To: William Mills ; "oauth@ietf.org"
Sent: Friday, January 20, 2012 12:32 PM
Subject: RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
Specification
New text added to Access Token Scope section:
:58 PM
*To:* Eran Hammer; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity
in Specification
"Null string", "empty string", or "server defined default value" all
work. Default scope doesn't do it for me.
--
gt;>;
"oauth@ietf.org<mailto:oauth@ietf.org>" mailto:oauth@ietf.org>>
Sent: Tuesday, January 10, 2012 5:24 PM
Subject: RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
Specification
I don’t like ‘empty scope’ as it is undefined. I prefer ‘default scope’.
EHL
From: Wil
Subject: RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
Specification
I don’t like ‘empty scope’ as it is undefined. I prefer ‘default scope’.
EHL
From:William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 10, 2012 4:02 PM
To: Eran Hammer; oauth@ietf.org
Subject: Re
I don't like 'empty scope' as it is undefined. I prefer 'default scope'.
EHL
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 10, 2012 4:02 PM
To: Eran Hammer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
Wups, there's a must in there that should be MUST.
From: agks mehx
To: William Mills ; Eran Hammer ;
"oauth@ietf.org"
Sent: Tuesday, January 10, 2012 4:18 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
Specification
mer
> *To:* "oauth@ietf.org"
> *Sent:* Tuesday, January 10, 2012 1:15 PM
>
> *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
> Specification
>
> I don't think the issue here is about the scope value, but who does the
> OPTIONAL desi
From: Eran Hammer
To: "oauth@ietf.org"
Sent: Tuesday, January 10, 2012 1:15 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
Specification
I don't think the issue here is about the scope value, but who does the
OPTIONAL designation applies
oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Phil Hunt
> Sent: Tuesday, January 10, 2012 11:33 AM
> To: SM
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
> Specification
>
> The underlying issue is that the
The underlying issue is that there was a decision not to in any way standardize
values for scope.
I agreed this was reasonable since the underlying resource APIs are likely to
be very specific requiring some degree of prior knowledge by the client app
developer. Thus the resource server OAuth i
At 09:19 10-01-2012, William Mills wrote:
That does clear it up! If the implementation returns a proper error
when the scope is omitted then it will be in conformance. Sending
an error result for the empty scope is valid.
Yes.
It is not possible to get a clear view of the specs if the discu
Sent: Monday, January 9, 2012 10:45 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
Specification
Please allow me to step-back and present the issue again in a different way:
I think of Section 4.1.1 as an API specification. In my entire career as a
programmer I
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
Mills ; oauth@ietf.org
Cc: SM ; Eran Hammer
Sent: Monday, January 9, 2012 5:57 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
Specification
That's fine and still consistent with the essence of (a), which is to require
implementations to accept requests with
ills ; oauth@ietf.org
> *Cc:* SM ; Eran Hammer
> *Sent:* Monday, January 9, 2012 5:44 PM
>
> *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
> Specification
>
> scope parameter in the HTTP requests.
>
> Two choices stand out to me: (a) keep t
t support it.
-bill
From: agks mehx
To: William Mills ; oauth@ietf.org
Cc: SM ; Eran Hammer
Sent: Monday, January 9, 2012 5:44 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
Specification
scope parameter in the HTTP requests.
Two choices stand out
h@ietf.org
> *Sent:* Monday, January 9, 2012 4:17 PM
> *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
> Specification
>
> Hi SM and Eran,
>
> I am confused again, after re-reading Eran's response, whether or not an
> implementation that rejects *mis
?
From: agks mehx
To: SM ; Eran Hammer ; oauth@ietf.org
Sent: Monday, January 9, 2012 4:17 PM
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
Specification
Hi SM and Eran,
I am confused again, after re-reading Eran's response, whether or not an
implementation
Hi SM and Eran,
I am confused again, after re-reading Eran's response, whether or not an
implementation that rejects *missing* (as opposed to empty) scope is
conformant or not. (Eran, your response was a bit ambiguous on whether an
implementation is free to error out on an missing scope parameter
rom: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of agks
mehx
Sent: Sunday, January 08, 2012 2:13 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
My client implementation per latest draft did not work against a major vendor
At 14:12 08-01-2012, agks mehx wrote:
I reported this to the vendor and the vendor claims that the IETF
draft specification says scope is OPTIONAL and that means the vendor
is free to make it required in a conforming implementation.
If a bit is said to be optional, it means that it will not ca
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
24 matches
Mail list logo
