thanks a lot
Am 12.06.2012 01:03, schrieb Phil Hunt:
Thanks. That makes sense.
Phil
On 2012-06-11, at 15:39, Amos Jeffries wrote:
On 12.06.2012 07:23, Phil Hunt wrote:
Private also seems inappropriate since no operation should be cached
for oauth as even when the same requestor.
Phil
Th
Hi Paul and George,
Even though the Access Token is short lived, I would still like to revoke
it immediately if the user chooses to revoke the Refresh Token. And I
would love for the client application to only have to make one web service
call to accomplish that and not one for the Refresh Token
Thanks. That makes sense.
Phil
On 2012-06-11, at 15:39, Amos Jeffries wrote:
> On 12.06.2012 07:23, Phil Hunt wrote:
>> Private also seems inappropriate since no operation should be cached
>> for oauth as even when the same requestor.
>>
>> Phil
>>
>
> There is a difference in HTTP use-case
Hi George, perhaps it depends on the reason for the refresh token being
revoked. If because the user removed their consent then yes I agree that *all*
tokens should be revoked
Sent from my iPhone
On 2012-06-11, at 5:10 PM, George Fletcher wrote:
> Paul,
>
> I think I came to a different con
On 12.06.2012 07:23, Phil Hunt wrote:
Private also seems inappropriate since no operation should be cached
for oauth as even when the same requestor.
Phil
There is a difference in HTTP use-case between what the Bearer and core
specs are covering.
The core spec appears to be covering the re
Reviewing the feedback from Julian, John, and James, I'm coming to the
conclusion that client_id and client_secret, being for machines and not humans,
should be ASCII, whereas username and password should be Unicode, since they
are for humans. Per John's feedback, client_id can not contain a co
Paul,
I think I came to a different conclusion...
If I use the Resource Owner Password Credential flow and get back both
an access_token and a refresh_token then I would assume that the issued
access_token is tied in some way to the refresh_token. If the
refresh_token is revoked, then my expe
Hi Doug, my interpretation is that 'for that refresh token' means those
access tokens issued in exchange for that refresh token.
Consequently, for the cases you cite below, the access tokens at the
same time as a given refresh token need not be invalidated when that
refresh token is 'processed
Hi all,
I was hoping to get some clarity on a statement in section 2.0 of
draft-ietf-oauth-revocation-00.
If the processed token is a refresh token and the authorization
server supports the revocation of access tokens, then the
authorization server SHOULD also invalidate all access tokens issued
Private also seems inappropriate since no operation should be cached for oauth
as even when the same requestor.
Phil
On 2012-06-11, at 12:17, Torsten Lodderstedt wrote:
> Hi all,
>
> I noticed a difference in usage of cache control headers between bearer and
> core spec.
>
> core -27 stat
Hi all,
I noticed a difference in usage of cache control headers between bearer
and core spec.
core -27 states:
" The authorization server MUST include the HTTP "Cache-Control"
response header field [RFC2616] with a value of "no-store" in any
response containing tokens, credentials, o
Are we so sure the non-english "half" of the world only use ASCII characters in
passwords? Sounds highly unlikely to me.
> Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest"...
It can work. It is just underspecified. So things can get messy.
draft-reschke-basicauth-enc-05 i
12 matches
Mail list logo
