Arguably the client can't revoke the token. It can request to revoke the token and then the decision of whether it is revoked is only on the AS. A client considering a token revoked has no merit on the value of the *active *flag.
For full context, this is the section: https://datatracker.ietf.org/doc/html/rfc7662#section-2.2 And the relevant text: The server responds with a JSON object [RFC7159 <https://datatracker.ietf.org/doc/html/rfc7159>] in "application/ json" format with the following top-level members. active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The specifics of a token's "active" state will vary depending on the implementation of the authorization server and the information it keeps about its tokens, but a "true" value return for the "active" property will generally indicate that *a given token has been issued by this authorization server, has not been revoked by the resource owner, and is within its given time window of validity* (e.g., after its issuance time and before its expiration time). See Section 4 <https://datatracker.ietf.org/doc/html/rfc7662#section-4> for information on implementation of such checks. On Mon, Aug 21, 2023 at 12:31 PM Justin Richer <jric...@mit.edu> wrote: > I don’t think it’s necessary to enumerate all of the possible parties that > could have had a hand in revoking the token — it have also been revoked by > the AS through some backend process or through administrative action. If a > token is revoked, it’s revoked — and the RS doesn’t generally care why or > who did it, just that the token is no good. It doesn’t hurt to list the > client here, but it’s not necessary. As such, I still say the errata should > be rejected. > > — Justin > > On Aug 19, 2023, at 6:32 PM, Fulong Sun <sunful...@neusoft.edu.cn> wrote: > > Hi Justin, > > Yes, the resource owner can revoke, but the client also can revoke the > token, why do not write both of them? > > 孙福龙 > Fulong Sun > > 东软教育科技集团・IDC > IDC of Neusoft Education Technology Group > > Office: +86 (411) 82379410 -9 / 6602 > Mobile: +86 13478953390 > E-mail: sunful...@neusoft.edu.cn > Address: Room 305, Building A5, No. 8, Software Park Road, Dalian, > Liaoning, China > > *From:* Justin Richer <jric...@mit.edu> > *Sent:* 2023年8月18日 20:54 > *To:* RFC Errata System <rfc-edi...@rfc-editor.org>; > i...@justin.richer.org; r...@cert.org; paul.wout...@aiven.io; > hannes.tschofe...@arm.com; rifaat.s.i...@gmail.com > *Cc:* sunful...@neusoft.edu.cn; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] [Technical Errata Reported] RFC7662 (7607) > > The resource owner can revoke the token out of band, this errata should be > rejected. > > - Justin > ------------------------------ > *From:* OAuth <oauth-boun...@ietf.org> on behalf of RFC Errata System < > rfc-edi...@rfc-editor.org> > *Sent:* Thursday, August 17, 2023 2:42 PM > *To:* i...@justin.richer.org <i...@justin.richer.org>; r...@cert.org < > r...@cert.org>; paul.wout...@aiven.io<paul.wout...@aiven.io>; > hannes.tschofe...@arm.com <hannes.tschofe...@arm.com>; > rifaat.s.i...@gmail.com<rifaat.s.i...@gmail.com> > *Cc:* sunful...@neusoft.edu.cn <sunful...@neusoft.edu.cn>; oauth@ietf.org > <oauth@ietf.org>; rfc-edi...@rfc-editor.org<rfc-edi...@rfc-editor.org> > *Subject:* [OAUTH-WG] [Technical Errata Reported] RFC7662 (7607) > > The following errata report has been submitted for RFC7662, > "OAuth 2.0 Token Introspection". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7607 > > -------------------------------------- > Type: Technical > Reported by: Fulong Sun <sunful...@neusoft.edu.cn> > > Section: 2.2 > > Original Text > ------------- > a given token has been issued by this authorization server, has not been > revoked by the resource owner, and is within its given time window of > validity > > Corrected Text > -------------- > a given token has been issued by this authorization server, has not been > revoked by the resource owner or client, and is within its given time > window of validity > > Notes > ----- > RFC 7009 defined a given token can be revoke by client, so should write > client here. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7662 (draft-ietf-oauth-introspection-11) > -------------------------------------- > Title : OAuth 2.0 Token Introspection > Publication Date : October 2015 > Author(s) : J. Richer, Ed. > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
