I'm refering to a siuation where a single authorization server manages
access to multiple resource serveres and a client seeks authorization
for some of this resource servers. I assume this would also happen in
your scenario once the OP discovers that access to calendar and address
book are
Hi all,
I'm arriving pretty late to the OAuth party, so please bear with me.
I just finished my first end-to-end read of the v2 spec and noticed
some minor issues. I wish I had some profound contribution to make
but initially it's a lot easier to notice the trivial details :) And
sometimes such
OAuth 2.0 authors or anyone with authority on the draft, would appreciate
some response to the below items.
3.5. User-Agent Flow
1. It is not clear from the draft how a user agent flow would refresh
an access token. As per section 4, client does a HTTP(S) POST to
authorization server which
On Thu, May 27, 2010 at 10:51 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
Cool. Glad we can put Roy's security concern to rest, at least.
I disagree. Your signature proposal makes matching worse, but moves the
canonicalization problem to the server side. You just flipped the problem.
On May 28, 2010, at 9:21 AM, William Mills wrote:
I thought one of the fundamental ugly problems is that the client
doesn't actually know the full URL authoritatively in all frameworks,
because variables get appended to the query string in an unknown order
in some cases?
If the client
Can't you always have the front end web server preserve the original URI in a
header or something before the rewrite engine or application framework mangle
it, right?
For example, this Nginx conf that preserves original parts of the request that
get changed when the request is proxied to the
That's the same thing (in a header or in the attached signed blob).
EHL
From: Kris Selden [mailto:kris.sel...@gmail.com]
Sent: Friday, May 28, 2010 3:21 PM
To: Brian Eaton
Cc: Eran Hammer-Lahav; field...@gbiv.com; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] FW: Duplicating request
Except you are in control of your web server so you know you put it there and
where it came from right?
On May 28, 2010, at 3:35 PM, Eran Hammer-Lahav wrote:
That’s the same thing (in a header or in the attached signed blob).
EHL
From: Kris Selden [mailto:kris.sel...@gmail.com]
Sent:
So we can define something much simpler than Oauth 1.0, where the
complexity was around normalizing the parameters, and if you want to
implement signing you have to be able to know what you are actually
sending, yes?
I'm OK with having some frameworks not capable of signing without being
fixed.
Because the authorization header is from the client which isn't
trusted like your web front end server.
All I was trying to say is the duplication is not necessary because
you can workaround it on the server side before it gets mangled by
rewrite rules or the app framework. You only need
The OAuth 2.0 draft 5
spechttp://tools.ietf.org/id/draft-ietf-oauth-v2-05.html#authz_headertells
about how the Authorization header can contain a Token as well as an
optional set of parameters for tokens that have associated secrets. But the
query string and POST methods for including the access
The type and immediate were the two parameters that I had
feedbacks that they want it in the URL. type being in the URL is
that implementations are using it as a switch. immediate was to
avoid creating two Request File in the case immediate did not
succeed. In my original manuscript, neither of
http://tools.ietf.org/id/draft-ietf-oauth-v2-05.html#authz_header
It seems that the spec for the Authorization header requires quotes around
the values of everything *except* the algorithm. Look closely at how the
substring is absent from the third line.
timestamp= timestamp =
13 matches
Mail list logo
