Your understanding is correct. I just wanted to note the additional data
required at the authz server in order to implement the indirect case.
Regards,
Torsten.
Am 15.09.2010 um 00:32 schrieb Brian Campbell :
> So is my understanding of the kraft incorrect? I read it to say that
> direct acc
So is my understanding of the draft incorrect? I read it to say that
direct access token revocation is optional but, if supported, then all
associated assess tokens must also be revoked on a revocation of a
refresh token.
On Sun, Sep 12, 2010 at 4:13 AM, Torsten Lodderstedt
wrote:
> Stefanie,
>
Editorial note: shouldn't the "must" in that text be a "MUST"?
You are right. I changed that.
regards,
Torsten.
On Thu, Sep 9, 2010 at 11:52 AM, Stefanie Dronia wrote:
Hallo Torsten,
first of all thanks for providing this draft on the mailing list.
Except for the following words, the d
Stefanie,
thanks for your comments.
I think there is a subtle difference between revoking access tokens
directly and indirectly via refresh tokens. In the later case, the
authorization server needs to keep track of the relation between refresh
and access tokens (somewhere in a database), whe
Hi Brain,
yes, you are right. I just went over that condition.
On the other hand, this implies to me, that access token revocation is
not possible in a constellation as described before.
Regards,
Stefanie
Am 10.09.2010 00:38, schrieb Brian Campbell:
Isn't that kind of situation exactly the
Isn't that kind of situation exactly the reason that access token
revocation was made optional? Invalidation of access tokens on
revocation of a refresh token is only a MUST, if the deployment
already supports revocation of access tokens. And if revocation of
access tokens is supported, I'd assu
Hallo Torsten,
first of all thanks for providing this draft on the mailing list.
Except for the following words, the draft is consistent. It defines the
end of a token's life cycle, intended by the user.
While reading it, I think that the following part of chapter 2 (Token
Revocation) might
I just submited the first version of my I-D for token revocation.
Link: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/
The I-D proposes an additional endpoint, which can be used to revoke
both refresh and access tokens. The objective is to enhance OAuth
security by givin
