[Trimming the CC to just the OAuth WG.]
On Wed, Jun 8, 2011 at 8:53 PM, Robert Sayre wrote:
> On Wed, Jun 8, 2011 at 10:32 AM, Eran Hammer-Lahav
> wrote:
>>> -Original Message-
>>> From: Tim [mailto:tim-proje...@sentinelchicken.org]
>>> Sent: Wednesday, June 08, 2011 8:32 AM
>>
>>> At r
Tim,
> Hi Paul,
>
> > That's the reason for the MAC. Once we can ensure the integrity of
> > the message exchange, then the existing cookie mechanism can provide
> > us with the secure state management capability we need.
>
> Maybe I'm missing something in the MAC authentication draft, but I do
What issues, specifically. (Messages are all over the place and I don’t know
exactly what issues you’re raising. Is it with the approach we’re proposing or
something else?)
Paul
From: Nico Williams [mailto:n...@cryptonector.com]
Sent: Wednesday, June 08, 2011 10:55 AM
To: Paul E. Jones
On Wed, Jun 8, 2011 at 10:32 AM, Eran Hammer-Lahav wrote:
>> -Original Message-
>> From: Tim [mailto:tim-proje...@sentinelchicken.org]
>> Sent: Wednesday, June 08, 2011 8:32 AM
>
>> At risk of repeating myself: Why not just adapt HTTP Digest for OAuth?
>> That is not just rhetorical, it is
On 6/8/11, Nico Williams wrote:
> Sweet! Thanks for confirming my intuition, and then some. I like the
> idea that using TLS actually reduces latency -- I'd not have imagined
> it.
>
Well, it's the enforcement of the end-to-end principle that reduces
latency, not the TLS protocol per se. You'd g
On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones wrote:
> If you can drive a consensus decision for the name "access_token", I'd be
> glad to change the name in the spec. I agree that the current names are
> confusing for developers.
At Google we are getting the same feedback, that it is confusing f
The last part, refresh token, is with the authorization server, not resource
server.
EHL
From: denadai2 [mailto:denad...@gmail.com]
Sent: Wednesday, June 08, 2011 1:27 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand
Perfect,
On Wed, Jun 8, 2011 at 5:26 PM, Breno de Medeiros wrote:
> On Tue, Jun 7, 2011 at 17:07, Nico Williams wrote:
>> Here's another issue: some of you are saying that an application using
>> this extension will be using TLS for some things but not others, which
>> presumes a TLS session. Does using
On Tue, Jun 7, 2011 at 17:07, Nico Williams wrote:
> On Tue, Jun 7, 2011 at 6:41 PM, Tim wrote:
>> I have to agree with Nico here. In almost all cases I assert that, on
>> typical modern networks:
>>
>> let P = difficulty of passive attack
>> let M = difficulty of active (man-in-the-middle) at
Perfect, thank you. I made a sequence diagram for Authorization code. I want
to explain the MINIMAL authorization requisites.
http://dl.dropbox.com/u/1118905/oauth2-authorization-code.png
I explained in red the REQUIRED TLS connections. Is that all right?
Thank you
2011/5/22 Eran Hammer-Lahav
> -Original Message-
> From: Tim [mailto:tim-proje...@sentinelchicken.org]
> Sent: Wednesday, June 08, 2011 8:32 AM
> At risk of repeating myself: Why not just adapt HTTP Digest for OAuth?
> That is not just rhetorical, it is a genuine question. What is HTTP Digest
> missing that you need
Hi Paul,
> That's the reason for the MAC. Once we can ensure the integrity of
> the message exchange, then the existing cookie mechanism can provide
> us with the secure state management capability we need.
Maybe I'm missing something in the MAC authentication draft, but I
don't see how it prov
On Jun 8, 2011 2:09 AM, "Paul E. Jones" wrote:
>
> Nico,
>
> Cookies would still be employed. A cookie would be used to identify the
particular user, for example. However, it's important to make sure that the
cookie provided by the client to the server is not stolen. It's important
to ensure th
Nico,
Cookies would still be employed. A cookie would be used to identify the
particular user, for example. However, it's important to make sure that the
cookie provided by the client to the server is not stolen. It's important to
ensure that the client provided by the server to the client i
On Tue, Jun 7, 2011 at 7:09 PM, Nico Williams wrote:
> Or am I missing something?
Well, last I tried it under apache, at least, there was a hard limit
on the length of
a TLS stream. Since I use HTTP for a storage system for multi-GB files, I'd
really love to see alternatives.
-Randy Fischer
15 matches
Mail list logo
