[Federation] Resolve endpoint: Note advantage of having the TA host the resolve endpoint

[Vladimir Dzhuvinov]

7.2.3. Considerations

https://openid.net/specs/openid-connect-federation-1_0.html#section-7.2.3

Having the Trust Anchor (TA) host the resolve endpoint makes it possible for entities to check the response signature with the TA’s key (no need to collect Trust Chain for the resolve endpoint itself). This is an important factor to consider when designing federations.

A closely related issue is that the current draft is not clear about the purpose of the resolve response signatures. If entities are going to check the response signature for every transaction and the resolve endpoint is not hosted at the TA, but at an Intermediate entity, we have a catch 22 situation (the Trust Chain for the resolver needs to be collected and verified first).

‌

[Vladimir Dzhuvinov]

Roland’s idea: note that an entity using the resolver can be (simply?) configured with its endpoint and public key

[Giuseppe De Marco]

we may suggest to include the trust chain related to the resolve response issuer in the form of JWS header parameter within the resolve endpoint signed response.
The Trust Anchor where the trust chain is resolved MUST be the same of the one submitted in the resolve request, using the required parameter anchor

in this way by just having the TA’s public keys a trust evaluator is able to verify both the trust chain related to the resolve issuer and the trust chain related to the subject of the request, when the trust chain is included in the response payload

I also assume that is it out of the scopes of a TA doing trust resolution for its indirect descendants, that are not in its proximity, while the resolve endpoint is very usefull in situation where an RP want to inspect its registration status and the final metadata regarding it to a specific OP and vice versa.

there are some implementations that requires the presence of a resolver service within a trusted domain (the same where they belongs to) by having an oidc federation micro service that does the trust evaluation within of an entire organization and all its oauth2/oidc implementation may uses it with small implementation efforts.

I suggest to have thin implementations of TAs since the TA may not correspond to an accreditation body and then it may not know nothing about the leafs that have been registered by its intermediates

[Vladimir Dzhuvinov]

Your comment states that being able to host resolvers at Intermediate entities can be crucial in federations.

Given that I believe we should at least specify that the resolve response may include a trust_anchor JWS header, to facilitate such scenarios.

[Giuseppe De Marco]

I can do a PR for this, good catch

[Michael Jones]

Discussed on the 6-Oct-23 editors' call.

[Giuseppe De Marco]

Resolved by https://bitbucket.org/openid/connect/pull-requests/642

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/642