e defined by the Trust Frameworks) further
constrains the bindings.
4. Discovery
5. Dynamic Registration
6. Session Management
=nat
>
> Francisco
>
> --- On *Wed, 1/5/11, Mike Jones * wrote:
>
>
> From: Mike Jones
> Subject: RE: [OAUTH-WG] TLS is needed for redirecting
o be defined by the Trust Frameworks) further
constrains the bindings.
4. Discovery
5. Dynamic Registration
6. Session Management
=nat
>
> Francisco
>
> --- On *Wed, 1/5/11, Mike Jones * wrote:
>
>
> From: Mike Jones
> Subject: RE: [OAUTH-WG] TLS is needed for redirecti
ainst the realm. I don't
think that's sufficient, but it's better than nothing.
Francisco
--- On Wed, 1/5/11, Mike Jones wrote:
From: Mike Jones
Subject: RE: [OAUTH-WG] TLS is needed for redirecting back to the client
To: "fcore...@pomcor.com" , "Marius Scurt
-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Francisco Corella
Sent: Tuesday, January 04, 2011 5:04 PM
To: Marius Scurtescu; Justin Richer
Cc: oauth@ietf.org; Karen P. Lewison
Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client
--- On Tue, 1/4/11, Justin Richer
...@pomcor.com
Cc: ; Karen P. Lewison
Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client
--- On Tue, 1/4/11, Torsten Lodderstedt wrote:
> the attack you described sounds very similar to session
> fixation attacks. TLS (more specifically server
> authentication) is one way to
--- On Tue, 1/4/11, Torsten Lodderstedt wrote:
> the attack you described sounds very similar to session
> fixation attacks. TLS (more specifically server
> authentication) is one way to cope with spoofing in general
> (supposed the client has a reasonably CA policy). So it
> should do in this cas
--- On Tue, 1/4/11, Justin Richer wrote:
> > > We need a protocol that does both authentication and
> > > authorization. We can take OAuth and adapt it for
> > > authentication, or take OpenID and adapt it for
> > > authorization, or combine OpenID and OAuth (great
> > > solution
> > > for people
--- On Tue, 1/4/11, Marius Scurtescu wrote:
> > We need a protocol that does both authentication and
> > authorization. We can take OAuth and adapt it for
> > authentication, or take OpenID and adapt it for
> > authorization, or combine OpenID and OAuth (great solution
> > for people who love com
Francisco,
the attack you described sounds very similar to session fixation
attacks. TLS (more specifically server authentication) is one way to
cope with spoofing in general (supposed the client has a reasonably CA
policy). So it should do in this case, too.
Validation of the redirect_uri a
> > We need a protocol that does both authentication and
> > authorization. We can take OAuth and adapt it for
> > authentication, or take OpenID and adapt it for
> > authorization, or combine OpenID and OAuth (great solution
> > for people who love complexity) or... take the best ideas
> > from O
What is the status of openid connect and what organisation ist standardizing it?
Gesendet mit BlackBerry® Webmail von Telekom Deutschland
-Original Message-
From: Marius Scurtescu
Date: Tue, 4 Jan 2011 13:37:28
To:
Cc: ; ; Karen P.
Lewison
Subject: Re: [OAUTH-WG] TLS is needed for
On Tue, Jan 4, 2011 at 1:27 PM, Francisco Corella wrote:
>
> We need a protocol that does both authentication and
> authorization. We can take OAuth and adapt it for
> authentication, or take OpenID and adapt it for
> authorization, or combine OpenID and OAuth (great solution
> for people who lov
Torsten,
> you made a good point. However, the question is if this
> belongs into the OAuth scope since this a general attack on
> a web app's session management.
I gave two variants of the attack. I agree that the first
variant "looks like" an attack against session management,
but the second v
endet mit BlackBerry® Webmail von Telekom Deutschland
-Original Message-
From: Francisco Corella
Sender: oauth-boun...@ietf.org
Date: Mon, 3 Jan 2011 22:11:05
To:
Reply-To: fcore...@pomcor.com
Cc: Karen P. Lewison
Subject: [OAUTH-WG] TLS is needed for redirecting back to the c
Hi all,
The OAuth spec recommends the use of TLS when sending
requests to the end-user authorization endpoint and requires
it when sending requests to the token endpoint. It says
nothing about using TLS when redirecting the browser back to
the client, which implies that it is not needed for that
15 matches
Mail list logo