Skip to content

Conversation

@selfissued
Copy link
Member

Copy link
Member

@panva panva left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking for now. This is not right but I haven't had a chance to properly disect yet.

Copy link
Member

@panva panva left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See openid/federation#232 (comment) - a client has but one authentication method for the purposes of DCR (and intrinsically for other mechanisms supported by the data model introduced through DCR Metadata).

The inclusion of introspection_endpoint_auth_methods_supported and revocation_endpoint_auth_methods_supported client multi-valued metadata would serve no value since:

  • an AS is prohibited from responding with multi-valued metadata in a DCR response
  • there is no single-valued metadata for these
  • client implementations do in-fact use just one client authentication method for all the authenticated endpoints (token, introspection, revocation, ciba, device authorization, par)

@selfissued
Copy link
Member Author

FYI, should it be useful when reviewing, this is rendered at https://openid.github.io/rp-metadata-choices/mbj-introspection-revocation.html

@jricher
Copy link

jricher commented Jul 16, 2025

Token Introspection was primarily designed to be an RS-facing API, and therefore it's generally not clients that will be calling it. We co-opted client authentication methods because that's the only thing that OAuth defines -- OAuth doesn't really have a good story for RS registration, identification, or authentication. All that said, introspection does explicitly allow introspection of refresh tokens, which are client-held, and allows other types including ID Tokens. These imply that clients could do introspection if they wanted to in some circumstances.

Revocation is a little clearer, in that it's a client-facing API and I think it's reasonable to expect a client to use the same authentication methods for both the token endpoint as other endpoints, including registration.

I think the way we got here is that we built out each of these pieces one at a time and that incremental creep didn't seem bad at the time, but looking back a decade later it's a lot messier and more abstract than it needs to be.

@panva panva closed this Aug 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants