; To: Eran Hammer-Lahav
> Cc: Adam Barth; OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> > -Original Message-
> >> From: Skylar Woodward [mailto:sky...@kiva.org]
> >> Sent: Wednesday, June 01, 2011 12:16 AM
> &
> -Original Message-
>> From: Skylar Woodward [mailto:sky...@kiva.org]
>> Sent: Wednesday, June 01, 2011 12:16 AM
>> To: Eran Hammer-Lahav
>> Cc: Adam Barth; OAuth WG
>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
&g
Actually, monotonically increasing fails for this use case because even if
clocks are sync'd, device A and B can submit requests sequentially in UTC time
but could arrive in reverse order.
So monotonically increasing, with some tolerance or window of error would seem
to be sufficient for allowi
> -Original Message-
> From: Skylar Woodward [mailto:sky...@kiva.org]
> Sent: Wednesday, June 01, 2011 12:16 AM
> To: Eran Hammer-Lahav
> Cc: Adam Barth; OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> Provider: api.meg
Sounds like Eran's proposal will work fine for this scenario.
MegaWorld for iOS can just do what you suggest in the final paragraph,
which meets the new requirements for age. I'm glad we're able to
address you use case.
Thanks,
Adam
On Wed, Jun 1, 2011 at 12:15 AM, Skylar Woodward wrote:
> Pro
Provider: api.megaworld.com
Software Program: A universal binary iOS app called MegaWorld for iOS
Client ID: mega_app
User: Frankie in London
Username: frankie_uk
Device A: Frankie's iPhone
Device B: Frankie's iPad
Now imagine MegaWorld for iOS installed on device A & B. Client ID is the
> wrong - if you want to put the effort in to capture these, go ahead. I just
> think this isn't worth the effort in a formal document.
> >
> > EHL
> >
> >
> >> -Original Message-
> >> From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.
> -Original Message-
> From: Skylar Woodward [mailto:sky...@kiva.org]
> Sent: Tuesday, May 31, 2011 11:03 PM
> To: Eran Hammer-Lahav
> Cc: igor.faynb...@alcatel-lucent.com; OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> Eran,
> -Original Message-
> From: Skylar Woodward [mailto:sky...@kiva.org]
> Sent: Tuesday, May 31, 2011 10:54 PM
> Unfortunately though, this implementation doesn't help my use cases
> because such sequential requirement of a timestamp/age requires all
> devices with the token to be in sync
g]
>> Sent: Tuesday, May 31, 2011 10:14 PM
>> To: Eran Hammer-Lahav
>> Cc: igor.faynb...@alcatel-lucent.com; Phil Hunt; OAuth WG
>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>>
>> Yes, but I think my case is very important (eg, being a
EHL
-Original Message-
From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
Sent: Tuesday, May 31, 2011 6:15 PM
To: Eran Hammer-Lahav
Cc: Phil Hunt; OAuth WG
Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Maybe... But this information must be captured so
On Jun 1, 2011, at 7:58 AM, Eran Hammer-Lahav wrote:
> I don't think you have made the case why you age is any harder to implement
> than a timestamp. It is not that your email isn't clear, it's that we're not
> convinced that timestamp will produce any better result than age in practice.
> Thi
11 6:15 PM
>> To: Eran Hammer-Lahav
>> Cc: Phil Hunt; OAuth WG
>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>>
>> Maybe... But this information must be captured somewhere, right?
>>
>> At the moment, there seems to be no
; -Original Message-
> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
> >> Behalf Of Igor Faynberg
> >> Sent: Tuesday, May 31, 2011 3:50 PM
> >> To: Phil Hunt
> >> Cc: OAuth WG
> >> Subject: Re: [OAUTH-WG]
> > EHL
> >
> >
> >> -Original Message-
> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
> >> Behalf Of Igor Faynberg
> >> Sent: Tuesday, May 31, 2011 3:50 PM
> >> To: Phil Hunt
> >> Cc: OAuth WG
> &
On May 31, 2011, at 11:41 PM, Adam Barth wrote:
> You haven't described a problem.
Maybe so, but I guess you can't see yet where this is going, or you are
ignoring it intentionally. I did preface this letter that I wanted to
understand your perspective on this two points before attempting to co
use case discussed on this list recorded.
>
> EHL
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Igor Faynberg
>> Sent: Tuesday, May 31, 2011 3:50 PM
>> To: Phil Hunt
>> Cc: OAuth
: Tuesday, May 31, 2011 3:50 PM
To: Phil Hunt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
...Sorry to turn the question around so as to underline my pet peeve:
Have we *documented* all cases? (This is what the Use Cases document is
supposed to be all about
Of Phil Hunt
> Sent: Tuesday, May 31, 2011 3:35 PM
> To: Adam Barth
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> There seems to be a demonstrated need for both age and timestamp
> tokens.
>
> The list has 2 separate cases w
rg
> Sent: Tuesday, May 31, 2011 3:50 PM
> To: Phil Hunt
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> ...Sorry to turn the question around so as to underline my pet peeve:
> Have we *documented* all cases? (This is what the Use Cases do
gt;>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I can't speak for Mozilla, but I can tell you that many folks don't
>>>
clock provided by all modern operating systems.
>>>>>>>>>
>>>>>>>>> Adam
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward
>
o prevent replay. The whole point of this kind of
replay protection is when TLS is not available.
I think a better approach is to simply make checking the nonce optional when
TLS is used.
EHL
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
O
zing the use of MAC token even more -
>>>>>>>>> now it's becoming a service mainly for user-agents on home desktops?
>>>>>>>>> This is further for the original goal of making MAC as flexible is
>>>>>>>>> possible. In this
p is just as good as your
>>>>>>>> offset technique and is more: reliable, straightforward, flexible.
>>>>>>>>
>>>>>>>> User agents that care about creating robust behavior for home desktops
>>>>>>>>
nd trusting the
>>>>>>> device clock alone.
>>>>>>>
>>>>>>> Please change the spec back to using timestamp rather than age.
>>>>>>>
>>>>>>> I'd also like to hear a convincing ar
1, 2011 1:04 AM
> To: Adam Barth
> Cc: Eran Hammer-Lahav; OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> It seems we're failing to communicate. Or you're not understanding my use
> cases. Age doesn't "just" work. It
to do clock
>>>>>>> correction on their own (by pinging a time service) and trusting the
>>>>>>> device clock alone.
>>>>>>>
>>>>>>> Please change the spec back to using timestamp rather than age.
>>>
> unattractive or difficult to implement in a modern user-agent.
>>>>>>
>>>>>> Thanks,
>>>>>> skylar
>>>>>>
>>>>>> ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. — ... -.- -.--
>>>>
; skylar woodward
>>>>> Kiva Developer Program / build.kiva.org / @buildkiva
>>>>>
>>>>>
>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>>
>>>>>> Any kind of clock sync requirement
.org / @buildkiva
>>>>
>>>>
>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>
>>>>> Any kind of clock sync requirement for user-agents (basically, home
>>>>> desktops) it completely impractical. The added complex
nough as experience shows some users
>>>> have closes that are off by more than an hour and a half.
>>>>
>>>> The issue here is who is this being optimized for. Server-to-server
>>>> communication should simply use TLS for privacy and MITM protecti
ptimized for. Server-to-server
>>> communication should simply use TLS for privacy and MITM protection on top
>>> of MAC instead of using nonces to prevent replay. The whole point of this
>>> kind of replay protection is when TLS is not available.
>>>
&g
s to prevent replay. The whole point of this
>> kind of replay protection is when TLS is not available.
>>
>> I think a better approach is to simply make checking the nonce optional when
>> TLS is used.
>>
>> EHL
>>
>>> -Original Message-----
&
approach is to simply make checking the nonce optional when
> TLS is used.
>
> EHL
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Peter Wolanin
>> Sent: Sunday, May 29, 2011 6:53 PM
>> T
Skylar Woodward
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> I am also concerned by the fragility of using time-since-credentials-issued,
> and also the added complexity of specifying this construction.
>
> I think it would be pref
I am also concerned by the fragility of using
time-since-credentials-issued, and also the added complexity of
specifying this construction.
I think it would be preferable to always require a timestamp as part
of the authorization header, and maybe even include in the spec a
maximum time difference
Resending to the list from my subscribed account...
Begin forwarded message:
> From: Skylar Woodward
> Date: May 23, 2011 6:14:00 PM PDT
> To: Skylar Woodward
> Cc: Eran Hammer-Lahav , OAuth WG
> Subject: Re: [OAUTH-WG] issues with token age element - MAC token
>
> So after discussing this to
38 matches
Mail list logo
