I'll make this more explicit in -16.
Thanks.
EHL
> -Original Message-
> From: Freeman, Tim [mailto:tim.free...@hp.com]
> Sent: Monday, April 18, 2011 4:51 PM
> To: Eran Hammer-Lahav; oauth@ietf.org
> Subject: RE: Can you use POST to access protected resources?
>
> >Accessing protected r
>Accessing protected resources is outside the scope of v2 but both Bearer and
>MAC clearly allow any HTTP method.
Thanks for pointing out that Bearer describes the entire request. From the
titles I had assumed that they just specified the format of the token.
On quickly reading http://tools.ie
I'm a bit surprised by this question...
Accessing protected resources is outside the scope of v2 but both Bearer and
MAC clearly allow any HTTP method.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Freeman, Tim
> Sent: Monday, A
I guess if making things complicated and dropping features and now having to go
through the process of creating yet another specification is progress than
maybe we are, but on the other hand looks like we are making reverse progress.
-Original Message-
From: Eran Hammer-Lahav [mailto:e..
Section 7 of http://tools.ietf.org/html/draft-ietf-oauth-v2-15 gives examples
of how to access protected resources. All of the examples use GET.
Our protected resources are identified by a query, which might be a few
kilobytes. I'm concerned that this may not fit inside the length limitation o
At least I finally got you to agree that this can be done in a separate
specification. That's progress.
EHL
> -Original Message-
> From: Anthony Nadalin [mailto:tony...@microsoft.com]
> Sent: Monday, April 18, 2011 4:22 PM
> To: Eran Hammer-Lahav; Manger, James H; oauth
> Subject: RE: Re
I'm certainly glad you gave us your definition of "breaking" but sadly your
definition is not in line with ours. When a developer sits down and codes to
the spec and then goes to rev the code with the latest spec and things are
removed the developer now either has to drop that feature or find an
I don't think you understand what 'breaking' means. Breaking would be if we
assigned a different meaning or syntax to the two parameters, or changed their
name. Breaking requires code changes. There is nothing to prevent you from
defining these parameters just like the SAML grant type did.
Was
> The claim that "removing is a breaking issue" is patently wrong. This claim
> was made many times before and is baseless. A breaking change would cause
> current implementations using these two parameters to break. This is clearly
> not the case here since >the v2 specification already provide
There are two separate issues here, procedural and technical. We need to
address both.
Procedural issue:
The issue is how should this use case be addressed by this working group. There
were always three options:
1. Not address by the WG - leaving it up to those interested to submit an
individ
>"3.3 Client Assertion Credentials". OAuth2 currently supports the concept of a
>client app swapping an assertion for an access token. Do people want the
>additional functionality of using assertions for generic client
>authentication? I assumed servers would >prefer that clients swap an asserti
Eran, that is my recollection as well.
Possibly there could be consensus to add text like this if list
discussion leads in that direction, but as I recall there was no such
consensus when you provisionally added the text in [[...]] to the base spec.
Peter
On 4/16/11 10:58 AM, Eran Hammer-Lahav w
Can't the mod_rewrite in Apache set an environment variable with the original
request? [E=ORIG_PATH:$1]
Or set a header if proxying the request after rewrite (similar to
X-Forwarded-For or X-Forwarded-Proto) to preserve the original request path?
-
Everyone's main interest, I'm guessing, i
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Monday, April 18, 2011 12:35 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] MAC request URI normalization (query
> parameters)
>
> Any instance of apache's mod_rewrite will bork up the requ
Any instance of apache's mod_rewrite will bork up the request URL for
anything behind the rewrite. The server or client code behind a rewrite
will only see the rewritten URL and not the original request URL.
Why not just pack the signed string in with the payload? You would then
have rules on veri
I would like to drop all the request URI parameters normalization logic and
just use the raw request URI instead. A year ago during the discussion on my
Token authentication scheme (which had that behavior specified), some people
raised the issue that access to the raw request URI isn't always p
16 matches
Mail list logo
