On Tue, Jul 19, 2011 at 10:08 AM, Aiden Bell aiden...@gmail.com wrote:
This seems clearer Eran. I don't blame you for not liking collection, I
was searching for a term without
too much theoretical background; Your revision reads much better.
I'm happy with it. This seems like a good
On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eliot Lear
Sent: Sunday, July 17, 2011 2:49 AM
One other point: if the redirection_uri can have fragments
If you don't register the combination, how would anyone know (aside from
reading every service specific documentation) what the combination means. As
clearly stated in your own list, at a minimum, the location of the credentials
is not obvious and must be defined. We had a long discussion on
On Wed, Jul 20, 2011 at 8:42 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
If you don’t register the combination, how would anyone know (aside from
reading every service specific documentation) what the combination means. As
clearly stated in your own list, at a minimum, the location of the
I think somewhere in here my original comments got lost. The spec, as
written, provides no limitations on what can go in the state variable.
If we don't define those limitations in the spec implementors are
going to define their own limitations (I'm on the verge of doing it
myself).
I propose
Can you provide examples of bad values and how they make the implementation
less secure? What's the attack vector here?
EHL
-Original Message-
From: bigbadb...@gmail.com [mailto:bigbadb...@gmail.com] On Behalf Of
Bob Van Zant
Sent: Wednesday, July 20, 2011 9:10 AM
To: Breno; Eran
The problem lies in the inherent trust of the state parameter. The
naive client application developer assumes that state goes out to the
authorization server and comes back unchanged; because that's what the
spec says will happen.
As a malicious person I use the client application and steal the
Looks like we have consensus for the new text. I'd like to ask the chairs to
close issue 18 (or note it resolved until the I-D freeze is over and I can push
a revised draft).
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran
In short, over specification does not solve ignorance. We can and should
highlight the possible code injection attacks on both the client and
authorization server, as well as other security concerns around the state
parameter. But at the end, it is up to both the client and authorization
Take a look at how the other sections in the draft setup the premise first and
give a quick explanation of the attack...
EHL
From: Aiden Bell [mailto:aiden...@gmail.com]
Sent: Wednesday, July 20, 2011 11:38 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] OAuth v2-18 comment on state
See below for revision, tried to follow the introduction, recommendation,
example
structure in 10.12 Cross-site Request Forgery and shorten my text.
I'm strugging to make it clear that any internal modification to the 'state'
parameter
must not affect the re-transmitted value of 'state' in
So far response type values are just strings one need to compare
literally. What use case justifies the more complex proposal?
regards,
Torsten.
Am 15.07.2011 19:44, schrieb Eran Hammer-Lahav:
I was only arguing against the proposed text which doesn't accomplish
what you want from a
2.1 Client types
I'm struggeling with the new terminology of private and public
clients. In my perception, the text just distinguishes clients which can
be authenticated and such which cannot. This is fine but I consider the
wording misleading. I would suggest to change it to something like
2.1 Client types
I'm struggeling with the new terminology of private and public
clients. In my perception, the text just distinguishes clients which can
be authenticated and such which cannot. This is fine but I consider the
wording misleading. I would suggest to change it to something like
The authorization server redirects the user-agent to the
client's redirection URI previously established with the
authorization server during the client registration process.
Conflicts with section 3.1.2.3, which allows to pass a redirect_uri via
URI query parameter.
3.1.2.1 Endpoint
just a minor issue
In addition,
this specification does not provide a mechanism for refresh token
rotation.
The spec provides a mechanisms. It allows for the issuance of a new
refresh token with every request to referesh an access token.
regards,
Torsten.
section 1.5
(A) The client requests an access token by authenticating with the
authorization server, and presenting an authorization grant.
This statement does not reflect that client authentication is not always
required.
Proposal:
The client requests an access token by presenting
Key rotation I understand. Forcing expiry on every reissue seems extreme
though.
From: Brian Eaton bea...@google.com
To: William J. Mills wmi...@yahoo-inc.com
Cc: Torsten Lodderstedt tors...@lodderstedt.net; Eran Hammer-Lahav
e...@hueniverse.com; OAuth WG
Friends,
I have intentionally used this thread, on which 1001 messages ago I
mentioned the OMA and ITU-T work. Since then I got several private
queries, and I am happy to say that the liaison from OMA has arrived
(although it has a little glitch, which made me write this otherwise
redundant
19 matches
Mail list logo
