Proposal to add new Entity Statement claim - subject_entity_configuration_location

[Razumain]

We have in our profile added this custom critical claim that I would like to put forward for consideration:

It's syntax and use is described here: https://github.com/oidc-sweden/specifications/blob/main/swedish-oidc-fed-profile.md#subject-entity-configuration-location-claim

This claim is essential/useful for us for mainly 2 reasons:

1. It allows us to build a federation that includes current unaltered services. In particular current unaltered RP services
2. It saves resources for the resolver when traversing the federation structure top-down to build, and re-build its database.

The most important 1) this allows us to take an exiting RP without any capabilities what so ever to produce, sign and publish an Entity Configuration, to have this handled by a superior Intermediate Entity. That Intermediate Entity can make this Entity Configuration available without changing the current EntityIdentifier of the RP at any location.

Advantage 2) is relevant for the resolver. Today, there exist 2 alternative locations for Entity Configuration even if you follow the standard. By having the exact location in the Entity Configuration, you can optimize the top-down traversal of a federation to build all available paths. When this information is available, there is no need for trial and error when getting the leaf Entity Configuration.

Considerations
RP:s choosing this option are opting-out from being discoverable the traditional way. Their Entity Configuration can no longer be found using the /.well-known. location. However, they can still be found using a resolver that supports this claim. This choice to opt-out from being discoverable through traditional means must be a conscious choice of each RP and balanced between the advantage and disadvantage of this choice. For an RP that has no capacity to publish their own Entity Configuration, but all OP:s they communicate with use either a compatible resolver, or make their own top-down traversal of the federation, it could be a very good choice, at least in the short term.

this creates a much lower threshold of entry into the federation. The end goal is for every entity to publish their own Entity Configuration as prescribed by the standard, but this allows us to build a federation with existing services without modifications. This avoids the powerful hen and the egg problem when transitioning services to OpenID federation.

In our test federation: https://sandbox.swedenconnect.se/oidfed/home the two current services has been included this way. They can be resolved through:

curl --location 'https://sandbox.swedenconnect.se/oidfed/trust-anchor/resolve?anchor=https%3A%2F%2Fsandbox.swedenconnect.se%2Foidfed%2Ftrust-anchor&sub=https%3A%2F%2Foidc.test.bankid.com' \
--header 'Accept: application/resolve-response+jwt'

And:

curl --location 'https://sandbox.swedenconnect.se/oidfed/trust-anchor/resolve?anchor=https%3A%2F%2Fsandbox.swedenconnect.se%2Foidfed%2Ftrust-anchor&sub=https%3A%2F%2Fps.sandbox.swedenconnect.se%2Feidas-ps%2Foidc' \
--header 'Accept: application/resolve-response+jwt'

[Razumain]

Just wanted to add here, after re-reading section 10 and 12, that this solution would actually work for RP:s if they use explicit registration. They can do that even if their Entity Configuration is not published correctly. They could just send over their EntityConfiguration that was created by their superior entity regardless of where it is published and it would work.