Token introspection, it seems to work incorrectly

[maennchen]

Discussed in #362

^{Originally posted by danj3 July 30, 2024}
There's a line in oidcc_token_introspection.erl:extract_response:

            IntrospectionClientId == ClientId; IntrospectionClientId == undefined

Which seems to mean that the function will only introspect a token that was issued by the client of the caller (i.e. one's own token) or a token issued elsewhere but only to a client_id of the same name.
Somehow this seems incorrect and not very useful, but maybe I misunderstand the intent of these words (from https://datatracker.ietf.org/doc/html/rfc7662):

   This specification defines a protocol that allows authorized
   protected resources to query the authorization server to determine
   the set of metadata for a given token that was presented to them by
   an OAuth 2.0 client.  This metadata includes whether or not the token
   is currently active (or if it has expired or otherwise been revoked),
   what rights of access the token carries (usually conveyed through
   OAuth 2.0 scopes), and the authorization context in which the token
   was granted (including who authorized the token and which client it
  was issued to).  Token introspection allows a protected resource to
   query this information regardless of whether or not it is carried in
   the token itself, allowing this method to be used along with or
   independently of structured token values.  Additionally, a protected
   resource can use the mechanism described in this specification to
   introspect the token in a particular authorization decision context
   and ascertain the relevant metadata about the token to make this
   authorization decision appropriately.

It would seem that this constraint would just need to be removed to fix the problem. Unless there is another mechanism for validating a token through the AS?