[Openid-specs-ab] Issue #1350: Support for ID tokens in introspection endpoint (openid/connect)

[Mitar]

New issue 1350: Support for ID tokens in introspection endpoint
https://bitbucket.org/openid/connect/issues/1350/support-for-id-tokens-in-introspection

Mitar:

Introspection endpoint is defined in the OAuth 2.0 spec, but not really covered in the OpenID Connect spec. Some time ago check ID endpoint was dropped. Currently strict reading of the OAuth 2.0 spec would be that introspection endpoint can be used only for access tokens by a protected resource and not also for ID tokens. But multiple implementations in fact support passing ID tokens to the introspection endpoint:

* Okta accepts ID token on introspection endpoint: [https://developer.okta.com/docs/reference/api/oidc/#introspect](https://developer.okta.com/docs/reference/api/oidc/#introspect)
* Ping Identity accepts ID token on introspection endpoint: [https://www.pingidentity.com/en/company/blog/posts/2020/token-introspection-pingone-for-customers.html](https://www.pingidentity.com/en/company/blog/posts/2020/token-introspection-pingone-for-customers.html)
* Google has [tokeninfo](https://developers.google.com/identity/sign-in/web/backend-auth#calling-the-tokeninfo-endpoint) endpoint which to me looks like introspection endpoint and it accepts ID token

I wonder, is there already somewhere specified/documented/hinted that ID tokens can be passed to the introspection endpoint and how to do so in a safe manner?

I think it would be useful for this to be allowed, but I think to be done safely \(for token substitution attack not to happen\), caller should pass an expected `audience` parameter to it and introspection endpoint should return active response only if the parameter matches any of the `aud` claims in the token itself.

Anyway, what are thoughts here. Should this already be supported by implementations? Or is this something which is not a good idea to do?