Re: [OAUTH-WG] [Technical Errata Reported] RFC7662 (7607)

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 <jricher@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 <sunfulong@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: sunfulong@neusoft.edu.cn
> Address: Room 305, Building A5, No. 8, Software Park Road, Dalian,
> Liaoning, China
>
> *From:* Justin Richer <jricher@mit.edu>
> *Sent:* 2023年8月18日 20:54
> *To:* RFC Errata System <rfc-editor@rfc-editor.org>;
> ietf@justin.richer.org; rdd@cert.org; paul.wouters@aiven.io;
> hannes.tschofenig@arm.com; rifaat.s.ietf@gmail.com
> *Cc:* sunfulong@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-bounces@ietf.org> on behalf of RFC Errata System <
> rfc-editor@rfc-editor.org>
> *Sent:* Thursday, August 17, 2023 2:42 PM
> *To:* ietf@justin.richer.org <ietf@justin.richer.org>; rdd@cert.org <
> rdd@cert.org>; paul.wouters@aiven.io<paul.wouters@aiven.io>;
> hannes.tschofenig@arm.com <hannes.tschofenig@arm.com>;
> rifaat.s.ietf@gmail.com<rifaat.s.ietf@gmail.com>
> *Cc:* sunfulong@neusoft.edu.cn <sunfulong@neusoft.edu.cn>; oauth@ietf.org
> <oauth@ietf.org>; rfc-editor@rfc-editor.org<rfc-editor@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 <sunfulong@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
>