Do the security considerations of Token Introspection apply to IndieAuth Token Verification?

[Zegnat]

In IndieAuth, Access Token Verification is the alternative to Token Introspection. Both are meant as ways for resource servers that are not integrated with the token endpoint to be able to check tokens they recieve for validity.

OAuth 2.0 Simplified has a section on Security Considerations for Token Introspection, and the Token Introspection spec itself (RFC 7662) has Security Considerations and Privacy Considerations sections.

One of my main take aways is the fact that the endpoint for verification reasons might have to share more data than it would be willing to share with the public at large. I am not sure we are hitting this point just yet, but with discussions surrounding expiry times for refresh, as well as subject and resources data for TicketAuth, I wonder if this might be an example of a footgun.

If the same security considerations do apply, would there be reasons to pull them inline with eachother? If yes, is there any reason IndieAuth cannot do the same as for revocation and point at the existing Introspection spec?

I would also be interested in hearing:

• What software we know depends on the IndieAuth type verifications?
• Is it clear from the spec that verification is something for resource servers only to use?

[jamietanna]

I believe this has been highlighted by @aaronpk in #94 - with the move to replace the IndieAuth Token Verification flow with RFC 7662, this should be resolved?

[dshanske]

I think it's resolved when we merge #94

[dshanske]

We merged introspection.. does that resolve this?

[Zegnat]

Closing this, as all verification is now following RFC 7662.