> > In most instances outside of the Big Web Companies, OAuth is going to be
> > the new kid being grafted onto an existing framework or application. As
> > such, it really needs to play nice.
>
> Just a side note, with extensions also being simple names added to the
> protocol chances of a collis
On Thu, Jul 1, 2010 at 6:03 AM, Justin Richer wrote:
> #2 is the best route forward. If a particular extension requires its
> parameters to be present and handled, then it has a few different
> options. One is breaking at the server side, either with an explicit
> error or throwing away some other
Ignore as in, pretend it wasn't sent (from either the client or server).
EHL
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Thursday, July 01, 2010 6:03 AM
> To: Eran Hammer-Lahav
> Cc: Yaron Goland; OAuth WG
> Subject: Re: [OAUTH-
k of use cases.
>>
>>
>>
>> I think #2 offers a good enough balance here, but am happy to discuss
>> #3 if people have actual use cases where ignoring an extension will
>> cause security issues. Note that with the expectation of error codes,
>> my upcoming ext
w adding any new
> parameter values (only new parameters).
>
>
>
> EHL
>
>
>
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Yaron Goland
> Sent: Monday, June 28, 2010 3:02 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] How do we
On Mon, Jun 28, 2010 at 6:17 PM, Eran Hammer-Lahav wrote:
> There are times when the client wants the server to fail if it doesn’t
> support an extension.
Implementations that have such requirements also have the option of
making a new protocol that shares a lot of code with OAuth.
How much feat
ssing).
>
> EHL
>
> *From:* David Recordon [mailto:record...@gmail.com]
> *Sent:* Monday, June 28, 2010 6:11 PM
> *To:* Eran Hammer-Lahav
> *Cc:* Yaron Goland; OAuth WG (oauth@ietf.org)
> *Subject:* Re: [OAUTH-WG] How do we deal with unrecognized elements in
> requests and res
be missing).
EHL
From: David Recordon [mailto:record...@gmail.com]
Sent: Monday, June 28, 2010 6:11 PM
To: Eran Hammer-Lahav
Cc: Yaron Goland; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests
and responses?
For #2, if an extension defines r
:11 PM
*To:* Eran Hammer-Lahav
*Cc:* Yaron Goland; OAuth WG (oauth@ietf.org)
*Subject:* Re: [OAUTH-WG] How do we deal with unrecognized elements in
requests and responses?
For #2, if an extension defines required parameters then you're not
supporting the extension if you ignore them.
t: Monday, June 28, 2010 6:11 PM
To: Eran Hammer-Lahav
Cc: Yaron Goland; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests
and responses?
For #2, if an extension defines required parameters then you're not supporting
the extension if you
arameters).
>
>
>
> EHL
>
>
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
> Of *Yaron Goland
> *Sent:* Monday, June 28, 2010 3:02 PM
> *To:* oauth@ietf.org
> *Subject:* [OAUTH-WG] How do we deal with unrecognized elements in
>
HL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Yaron
Goland
Sent: Monday, June 28, 2010 3:02 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] How do we deal with unrecognized elements in requests and
responses?
In a private thread with Eran an issue came up regarding how to
If we define that unrecognized arguments / elements are ignored then
we can define extensions such that if their arguments / elements are
ignored they don't introduce insecurity.
Ian
On Tue, Jun 29, 2010 at 10:01 AM, Yaron Goland wrote:
> In a private thread with Eran an issue came up regarding
It also depends on how extensions will work, looking forward to read -09.
If extensions are namespaced somehow then you could ignore unknown
extension but be strict with core parameters (those would be
parameters with no namespace) and with known extensions.
Marius
On Mon, Jun 28, 2010 at 3:01
In a private thread with Eran an issue came up regarding how to handle
unrecognized arguments in OAuth requests and responses.
For example, if a token endpoint receives an access token request that contains
both a client_id and a client_foo_bar argument, what should it do? Should it
reject the
15 matches
Mail list logo
