ected to be well-behaved and know about the
>> relationships between the master RS with the stricter RS1 & RS2
>parthers
>> ? Seems not easy to make it interoperable...
>>
>> Guess I'm missing the point still
>>
>> Thanks, Sergey
>>
>>> These
M
To: Richer, Justin P.
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] How the client can decide it is time to use
the refresh token
On 27/11/12 15:48, Richer, Justin P. wrote:
Yes, the client can keep two tokens and try using both of them if it
wants to. I think that you're conflating
h-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Sergey Beryozkin
Sent: Tuesday, November 27, 2012 10:26 AM
To: Richer, Justin P.
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh
token
On 27/11/12 15:48, Richer, Justin P. wrote:
mber 27, 2012 10:26 AM
To: Richer, Justin P.
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh
token
On 27/11/12 15:48, Richer, Justin P. wrote:
> Yes, the client can keep two tokens and try using both of them if it wants
> to. I think that y
nt:* Wednesday, November 21, 2012 6:11 AM
*Subject:* Re: [OAUTH-WG] How the client can decide it is time to use
the refresh token
There's no signaling regarding the validity of the refresh token from
the protected resource. In more distributed setups, the protected
resources know nothing about th
raft ?
>>>
>>> Cheers, Sergey
>>>
>>>>
>>>> Guangqing Deng
>>>>>
>>>>> *From:
Guangqing Deng
*From:* Justin Richer
*To:* Sergey Beryozkin
*Cc:* oauth@ietf.org
*Sent:* Wednesday, November 21, 2012 6:11 AM
*Subject:* Re: [OAUTH-WG] How the client can decide it is time to use
the refresh token
There's no signaling regarding the validity of the refresh token from
the pr
e ? If it does, can some relevant wording make it into the
> revocation token draft ?
>
> Cheers, Sergey
>
>>
>> Guangqing Deng
>> >
>> > *From:* Justin Richer
>> > *To:*
gqing Deng
>
> *From:* Justin Richer
> *To:* Sergey Beryozkin
> *Cc:* oauth@ietf.org
> *Sent:* Wednesday, November 21, 2012 6:11 AM
> *Subject:* Re: [OAUTH-WG] How the client can decide it is time
advance needed by Oauth?
Guangqing Deng
>
> *From:* Justin Richer
> *To:* Sergey Beryozkin
> *Cc:* oauth@ietf.org
> *Sent:* Wednesday, November 21, 2012 6:11 AM
> *Subject:* Re: [OAUTH-WG] How the clien
icher
*To:* Sergey Beryozkin
*Cc:* oauth@ietf.org
*Sent:* Wednesday, November 21, 2012 6:11 AM
*Subject:* Re: [OAUTH-WG] How the client can decide it is time to use
the refresh token
There's no signaling regarding the validity of the refresh token from
the protected resource. In more dis
:11 AM
*Subject:* Re: [OAUTH-WG] How the client can decide it is time to use
the refresh token
There's no signaling regarding the validity of the refresh token from
the protected resource. In more distributed setups, the protected
resources know nothing about the refresh tokens because the P
401 not 400
From: Justin Richer
To: Sergey Beryozkin
Cc: oauth@ietf.org
Sent: Wednesday, November 21, 2012 6:11 AM
Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh
token
There's no signaling regarding the validity o
different of
course.
From: Sergey Beryozkin
To: Justin Richer
Cc: oauth@ietf.org
Sent: Wednesday, November 21, 2012 6:18 AM
Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh
token
Hi
On 21/11/12 14:11, Justin Richer wrote:
> Ther
Hi
On 21/11/12 14:11, Justin Richer wrote:
There's no signaling regarding the validity of the refresh token from
the protected resource. In more distributed setups, the protected
resources know nothing about the refresh tokens because the PR never
sees them.
I was just asking how the client dec
There's no signaling regarding the validity of the refresh token from
the protected resource. In more distributed setups, the protected
resources know nothing about the refresh tokens because the PR never
sees them. In any case. the code path is fairly straightforward, even if
both tokens are e
Hi
I'm looking for some guidance on how the client which already owns an
access token can decide, after getting HTTP 400 back from the resource
server it tries to access on behalf of the end user/resource owner, can
decide that the refresh token it has can now be used to get a new access
toke
17 matches
Mail list logo
