Token Introspection

[jricher]

§10.1 Introspecting a Token: Editor's note:

This isn't super different from the token management URIs, but the RS has no way to get that URI, and it's bound to the RS's keys instead of the RC's or token's keys.

[Denisthemalice]

From a privacy point of view, token introspection allows an AS to know exactly when operation(s) are being performed by an end-user on a RS. This provides useful information for ASs that may be tempted to act as "Big Brother".

For that reason, the risks related to token introspection should be advertised in the Privacy Considerations section.

Its usage should be deprecated in the general case. If there exists specific cases where there is no such a risk, these cases should be advertised.

[adeinega]

The section doesn't provide any information on what happens when a client wants to introspect an inactive/invalid/revoked token.

[jricher]

Yes, this is pretty thin right now. It's the RS that introspects the token, and this section will be pulled out into a separate spec to make that more clear (#114). The response for both positive and negative situations is likely to be based on the OAuth introspection spec, RFC7662 https://tools.ietf.org/html/rfc7662