I did not consider the user-agent flow. I guess the only truly accurate
response would provide both an expires_from and an expires_at?
On Dec 14, 2010, at 3:56 PM, Paul Lindner wrote:
> For User Agent flow you really really really want expires_in
>
> Do you know how many PCs and browsers have
Correct, I guess their respective calculations would be both off by the same
amount.
On Dec 14, 2010, at 4:34 PM, Marius Scurtescu wrote:
> On Tue, Dec 14, 2010 at 2:54 PM, Paul Walker wrote:
>> It seems to me that expires_in suffers from the same machine time
>> synchronization issue and addi
Prepare a new draft if needed and submit it with draft-ietf-oauth- prefix. One
of the chairs will need to approve it and it will be published. I think we have
wide consensus for this and this was already proposed a long time ago with no
objections.
EHL
> -Original Message-
> From: Bria
That is exactly the problem we're currently facing at Dailymotion with the
writing of our Javascript SDK. How do you handle this issue at Linkedin?
Facebook seems to use the expires_at pattern and just don't rely on expiration
time in their Javascript SDK but refresh the token 20 minutes (hard c
We at Linkedin use expires_in for the user-agent flow, just for the
reasons Paul mentioned.
The one issue is when developers pass the token to their backend.
Praveen
On Dec 14, 2010, at 3:56 PM, Paul Lindner wrote:
For User Agent flow you really really really want expires_in
Do you know ho
On Tue, Dec 14, 2010 at 2:54 PM, Paul Walker wrote:
> It seems to me that expires_in suffers from the same machine time
> synchronization issue and additionally throws in an indeterminable time
> amount, while expires_at would only suffer from the former.
I don't see how expires_in suffers from
It depends how the time is used. A machine hosting a client is more likely to
have the local clock off, so letting it calculate lifetime locally (say, this
token is good for 10 minutes) is better than having it interpret it locally
(say, this is good until 3:30 PM). One thing I've seen more than
For User Agent flow you really really really want expires_in
Do you know how many PCs and browsers have their clock set incorrectly?
On Tue, Dec 14, 2010 at 3:23 PM, Aaron Parecki wrote:
> Agreed. I like the idea of expires_at as well. One of the first things a
> client is going to do after rec
Agreed. I like the idea of expires_at as well. One of the first things a
client is going to do after receiving the expires_in is calculate the
current time plus the offset. Makes sense to eliminate one source of timing
errors.
On Dec 14, 2010 2:54 PM, "Paul Walker" wrote:
> It seems to me that exp
It seems to me that expires_in suffers from the same machine time
synchronization issue and additionally throws in an indeterminable time amount,
while expires_at would only suffer from the former.
~pj
On Dec 14, 2010, at 1:35 PM, Marius Scurtescu wrote:
> expires_at requires very good time s
Also look for the thread with subject "OAuth 2.0 Bearer Token
specification draft -01".
Marius
On Tue, Dec 14, 2010 at 2:11 PM, Jitesh Bhate wrote:
> Thanks for your Response
> I think I got one thread in archive
> http://www.ietf.org/mail-archive/web/oauth/current/msg04673.html
>
> -Origi
Thanks for your Response
I think I got one thread in archive
http://www.ietf.org/mail-archive/web/oauth/current/msg04673.html
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Tuesday, December 14, 2010 4:55 PM
To: Jitesh Bhate
Cc: OAuth@ietf.org
Subject: Re:
I tend to agree.
Check the archives, there are recent discussions on this subject. The
exact format of the Authorization header is still debated, including
the scheme.
Marius
On Tue, Dec 14, 2010 at 1:52 PM, Jitesh Bhate wrote:
> While Integrating our Apis WITH CoTweet library
>
> We found th
While Integrating our Apis WITH CoTweet library
We found that OAuth 2.0 has changed (from oauth 1.0) the way Oauth token is
passed in authorization header.
OAuth 2.0 does not
require the oauth_token= while passing in authorization header
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#sect
expires_at requires very good time synchronization for all machines involved.
expires_in, while not very exact, is more resilient.
Marius
On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate wrote:
> I have same question, Thanks Paul for Raising this
>
> Regards
> Jitesh
>
> -Original Message---
I have same question, Thanks Paul for Raising this
Regards
Jitesh
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Paul
Walker
Sent: Tuesday, December 14, 2010 4:14 PM
To: OAuth WG
Subject: [OAUTH-WG] expires_at vs expires_in
Has there been di
Has there been discussion of using expires_at as an exact epoch time in seconds
as opposed to expires_in which is, at best, an approximation "from the time the
response was generated by the authorization server?" I apologize if this has
been discussed previously.
~pj
__
I don't have any objection to it and think it's probably cleaner.
Previously I'd informally asked that the SAML profile be considered a
WG item and I don't think there was any objection. What needs to be
done to make that happen?
If you/we take this approach, what else will you need from me?
On
Torsten made a good argument that now that we combined assertions and
extensions into a single mechanism, it does not make sense to make the
'assertion' parameter required, and that some extensions will be confusing with
such a parameter name. In addition, the recent document split demoted this
Future revisions of this SAML draft will build off whatever
assertion/extension mechanism is provided by the core framework spec.
However, some compelling reasons were previously given for keeping the
'assertion' (one thread on the topic:
http://www.ietf.org/mail-archive/web/oauth/current/msg04401.
+1
Am 14.12.2010 um 04:19 schrieb Eran Hammer-Lahav :
> I think the 'assertion' parameter should be moved into this draft and defined
> there. This will also facilitate its proper definition and status (required,
> singular, etc.).
>
> EHL
>
>> -Original Message-
>> From: oauth-boun
21 matches
Mail list logo
