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 m
Key rotation I understand. Forcing expiry on every reissue seems extreme
though.
From: Brian Eaton
To: William J. Mills
Cc: Torsten Lodderstedt ; Eran Hammer-Lahav
; OAuth WG
Sent: Tuesday, July 12, 2011 9:32 AM
Subject: Re: [OAUTH-WG] Refresh token securit
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 presenti
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.
___
"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 C
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 lik
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 lik
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 normativ
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 Aut
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"
Been following this discussion
I'll propose some text, though it seems to me it is getting into the realm
of "Don't trust inputs"
It is also worth noting that signing the request using something like the
HMAC extension elevates any
problems where you DO need to evaluate the state parameter in som
> 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
I think most of your description isn't very relevant to this particular attack.
I'll skip to the part where the legitimate client gets a maliciously modified
state parameter value.
Your concern seems to be a simple code injection attack (e.g. that some clients
will not properly protect their co
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 Hamm
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
cl
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; Er
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 that
On Wed, Jul 20, 2011 at 8:42 AM, Eran Hammer-Lahav wrote:
> 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
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 thi
On Thu, Jul 7, 2011 at 11:35 PM, Eran Hammer-Lahav wrote:
> Can this be reworked to discuss the authorization endpoint specifically?
> The use of 'target' site is confusing. This section needs to be much more
> specific to the authorization process.
>
Just chiming in to say that I am happy this l
On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav wrote:
>
>
> > -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 and can
On Tue, Jul 19, 2011 at 10:08 AM, Aiden Bell 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 alternative now if p
Sorry, I meant response_type 'none' and _not_ 'node'
On Wed, Jul 20, 2011 at 7:51 AM, Breno wrote:
>
>
> Comments inline.
>
> On Tue, Jul 12, 2011 at 8:23 PM, Paul Tarjan wrote:
>
>> I like splitting on space like scopes. But I'm fine with registering all
>> possible compositions that make sens
Comments inline.
On Tue, Jul 12, 2011 at 8:23 PM, Paul Tarjan wrote:
> I like splitting on space like scopes. But I'm fine with registering all
> possible compositions that make sense, if you prefer.
>
I agree with Marius that registering the combinations are not useful,
however also agree with
24 matches
Mail list logo
