Should the resolve endpoint (alternatively) accept entity configuration as parameter?

[cicnavi]

In 9. Obtaining Federation Entity Configuration Information, it is said:

While Leaf Federation Entities SHOULD make an Entity Configuration document available at their configuration endpoints, an exception to this requirement is that clients that use a client registration method that results in the server having the client's Entity Configuration MAY omit doing so.

In 10.1. Fetching Entity Statements to Establish a Trust Chain, it is said:

Depending on the circumstances, Party A MAY be handed Party B's Entity Configuration, or it may have to fetch it by itself. If it needs to fetch it, it will use the process described in Section 9 based on the Entity Identifier of Party B.

However, in 8.3. Resolve Entity, it is said:

An Entity MAY use a resolve endpoint to fetch Resolved Metadata and Trust Marks for an Entity. The resolver fetches the subject's Entity Configuration, assembles a Trust Chain that starts with the subject's Entity Configuration and ends with the specified Trust Anchor's Entity Configuration, verifies the Trust Chain, and then applies all the policies present in the Trust Chain to the subject's metadata.

Currently, the resolve endpoint "only" accepts the Entity Identifier of the Entity whose resolved data is requested, so can't cover the scenario in which the entity does not make entity configuration available at the configuration endpoint.

Should the resolve endpoint (alternatively) also accept the entity configuration for which to do the resolve procedure? Or should there be a note that the resolver only handles entities which have configuration endpoint? Or should the resolver maybe do a (less efficient in this scenario) "top-down" resolving in this case and in the end ignore the fact that the entity has no configuration endpoint?

[zachmann]

Good catch, I think the resolve endpoint needs an optional parameter to submit an entity configuration that should be used when resolving.

[rohe]

@cicnavi as you say the scenario with the entity not being able to publish their own configuration is in fact supported but in a pretty inefficient way if you want to do top-down resolving.

I'm also not quite sure who would know the complete entity configuration of an entity and how it acquired it.

So at this point in time I would like to punt submitting an entity configuration as a resolve endpoint parameter value to a possible extension.

[selfissued]

This could be added as a non-breaking extension in any extension spec that defines a mechanism in which leaf entities do not publish their Entity Configurations but are still somehow usable. It does not need to be in the 1.0 specification.

[zachmann]

I would argue that this should be included in the 1.0 spec. While it might not be extremely common, an OP could rely on a resolver for resolving; and with the current text this will not be be possible for the case of explicit registration.

This is not only relevant for entities that do not publish an entity configuration at all, but for all explicit registration requests. For an explicit registration request the spec states:

The RP will then construct its Entity Configuration, where the metadata statement chosen is influenced by the OP's metadata and where the authority_hints included are picked by the process described above.

Therefore, we have to expect that the entity configurations submitted in the explicit registration request is different from the published one. Therefore, resolving the trust chain must consider the submitted entity configuration.

I believe we should enable the usage of a resolver also for this use-case in the core spec.

[cicnavi]

A few more things that cross my mind:

• An RP which doesn't expose entity configuration can't rely on resolver to resolve trust chains for himself
• (Gabriel also stressed this) - OP which "only" receives entity configuration of RP during explicit registration can't rely on resolver to resolve trust chain for RP
• since we mentioned possibility of "top-down" resolving, does this mean that the resolver can try to do "top-down" resolving if it ever receives any error from entity credential endpoint... That would also mean that when using "top-down" resolving, the final leaf entity configuration can (always) be ignored, and that chain still accepted, since there would always be a chance that the final entity doesn't expose entity configuration

I was just bringing this up for the sake of consistency across the spec. For me it is actually not a problem if this is added in a separate draft. I'll have to enable functionality of resolving trust chain with given entity configuration anyways because of the explicit registration. It's just that this functionality won't be utilized on the resolve endpoint since it can't accept entity configuration.

I can also imagine the new parameter for the resolve endpoint being introduced as optional and used instead (or together with entity ID), so no actual breaking change. Also, I actually hope so that the "top-down" resolving will not be recommended to do trust chain resolution, as I can imagine federations large enough that this won't be feasible to do on-the-fly.