Trust Chain Resolution for calls to Introspection Endpoint by a Federated Protected Resource

[eduperottoni]

Hello,

I'm seeking clarification on the intended interaction between the OpenID Federation trust model and the OAuth 2.0 Token Introspection endpoint. The specification is clear about trust establishment during the authorization flow, but less explicit about subsequent interactions.

Scenario:

1. A Client is registered with an OpenID Provider (OP).
2. A Protected Resource (PR) exists, which is not pre-registered with the OP, but shares a common Trust Anchor with it.
3. The Client obtains an access token from the OP and presents it to the PR.
4. The PR now needs to validate this access token by calling the OP's introspection endpoint.

According to RFC 7662, to prevent token scanning attacks, the introspection endpoint should be protected and require the client (in this case, the PR) to authenticate itself. Since the PR is not registered, it cannot use a pre-configured client_id or client_secret.

When the OP receives this authenticated call from an unknown entity (the PR), is the following interpretation correct?

1. The OP must first perform Trust Chain Resolution on the identity of the calling PR.
2. If a valid trust chain can be built to a shared Trust Anchor, the OP can consider the PR authenticated and trusted. It can then proceed to introspect the access token and return a response.
3. If no valid trust chain can be established, the OP should reject the request with an authentication error, even if the presented access token itself might have been valid.

This contrasts with a call to the Userinfo endpoint, where the authorization is based on the bearer token itself, and no separate trust establishment for the calling PR seems necessary.

Could you confirm if this interpretation is correct? If so, would you consider adding a note or an example to the specification clarifying this? It would provide valuable guidance for implementers on how to correctly secure endpoints in a federated environment.

[peppelinux]

Since the PR is not registered, it cannot use a pre-configured client_id or client_secret

it can use a private key jwt client authentication (private_key_jwt), using the cryptographic material evaluated by the OP within the trust chain about the PR (or Resource Server, RS)

[rohe]

There are many ways by which the PR can register with the OP if OIDC and OpenID Federation is used :

1. static registration
2. OIDC dynamic registration
3. OpenID Federation explicit registration
4. OpenID Federation automatic registration

If we use the restriction that you have specified (the PR is not pre-registered) that would leave out 1-3.
In which case the remaining method is automatic registration.

In the token introspection endpoint case one would expect the private_key_jwt client authentication method to be used because in that case the PR metadata (RFC9728) returned during the automatic registration could be used to verify the
key material used for the private_key_jwt.

OpenID Federation is about trust establishment which is, as far as possible, application protocol independent.

[eduperottoni]

@rohe @peppelinux Thank you so much for your answers! I got it!

But don't you think this case deserves a note in the Implementation Considerations section to clarify that automatic registration can be executed at moments other than in the authorization flow?

[eduperottoni]

Oh, I closed it by accident, still want your point of view about this:

But don't you think this case deserves a note in the Implementation Considerations section to clarify that automatic registration can be executed at moments other than in the authorization flow?

Another idea is to have an example of the automatic registration on a different flow (like the one I presented).

Anyway, the idea is to make it clear that trust resolution must occur in every interaction in which the OP must trust the entity communicating with him, not only in the authorization cases, which is the only one present in the spec. Does it make sense?

[selfissued]

A description of this could possibility be added to 12.1.4. Possible Other Uses of Automatic Registration. @rohe and I discussed this on today's editors' call. How about this possible wording?

Also note that Client ID values that are Entity Identifiers could be used to identify clients using Automatic Registration at endpoints other than the Authorization Endpoint in OAuth 2.0 deployments. Describing particular such scenarios is beyond the scope of this specification.

[eduperottoni]

That`s good, but I think it would be better to be more explicit about the importance of the trust evaluation. Maybe something like the below?

In order to evaluate the trust in the entity making the request, note that Automatic Registration can be used at endpoints other than the Authorization Endpoint in OAuth 2.0 deployments, like the Token Introspection Endpoint. In that case, Client ID values that are Entity Identifiers could be used to identify those clients. Describing particular such scenarios is beyond the scope of this specification.

[selfissued]

Introspection is not used with either Federation or OpenID Connect, so I'm quite reluctant to add an oblique reference to it in the spec. It would be more likely to confuse people than clarify anything.

I'll create a PR with my proposed text above and ask for reviews of it.

[eduperottoni]

Ok, agreed!