New Entity Statement for subject data publication

[Stefan Santesson]

I would like to propose a new claim for inclusion in Entity Statements that provide information about if, how and in what way the subject entity publishes Entity Configuration data.

I have outlined this new claim here: https://github.com/oidc-sweden/specifications/blob/main/swedish-oidc-fed-profile.md#subject-data-publication-claim

‌

The motivation behind this claim is to allow validation of leaf entities that do not have the capability to create and publish Entity Configuration. This claim then provides the necessary information to allow validation of entity data via the Entity Statement issued to this entity, even in the absence of an Entity Configuration.

It is fully understood that an entity that does not publish an Entity Configuration at a well-known location can’t be discovered using the regular mechanism in a bottom-up path building strategy. But it can still be validated and supported by a Resolver that traverse the federation entities top-down.

If this claim is supported, the Leaf Entity is given a choice:

• Choose the simplified alternative (not publish Entity Configuration) but accept that it will only be visible to entities that use a compatible Resolver, or;
• Choose the more advanced alternative (publish Entity Configuration) and be visible to all entities that do not use a Resolver.

As I believe that, at least in our case, all federation services will use Resolvers, the simplified approach will be a viable option. Especially for RP:s where they know that the few OP:s they use support interaction with them using a Resolver.

‌

This claim also has other advantages as it can provide information about the exact location of Entity Configuration data. This is helpful to avoid re-tries on multiple URL:s when publication does not strictly follow RFC8414. This is a great help for Resolvers doing top-down traversal of the federation infrastructure.

[Michael Jones]

This was discussed on the 5-Jan-24 federation editors' call. Data about a subject can be established by any party in its trust chain: itself, its immediate superior, a higher-level superior, etc. If the leaf is unable or unwilling to host metadata about itself, as has previously been discussed, another party that it trust can do so for it.

The names of such hosted entities might be 1.hosted.example.com, 2.hosted.example.com, etc., but that makes them no less legitimate or useful as Entity Configurations. And the ability to do so means that we don’t need a special case in the specification that will cause interoperability problems.

We propose to close this issue on this basis in a week unless a reason to keep it open is identified.

[Stefan Santesson]

Michael.

You are missing a vital point here!

‌

This is NOT about hosting. This is about:

1. The ability to sign the Entity Configuration. And
2. The ability to participate in multiple federations under the same Entity Identifier

‌

If an Intermediate hosts your EntityConfiguration. You still have to sign it with your federation key. This requires you to be able to extract your federation key from your OP software and to insert it into some JSON signing software that can sign your Entity Configuration.

To do this you have to get passed policy and security problems. The problem to actually sign this statement is a bigger problem than the hosting of the statement.

‌

If an Entity Statement makes a clear statement that there is not Entity Configuration (self-signed) to find, then it si quite easy to validate a chain that ends with the Entity Statement for that subject if that Entity Statement contains metadata and Trust Marks. It is quite trivial and should be possible, at least with support of the extended claim.

‌

I’m fully aware that an entity tat do not publish a self-signed Entity Configuration will not be discoverable by its peers unless they are using a Resolver that can do chain validation and discovery for them. In our federation this is not a problem. So it becomes a choice for the leaf entity. If they want to be discoverable outside of the resolver, they MUST publish Entity Configuration. If they are happy to be discoverable only via Resolvers, then they can participate without publishing Entity Configuration.

‌

[Michael Jones]

Hi Stefan. It was great to sit down with you in person last week at TIIME. I’m going through the open issues in light of our discussions there.

There wasn’t consensus to add this functionality during our discussions there. As noted then, it would introduce a significant special case that we don’t believe is necessary.

Are you OK with us closing this issue on that basis?

[Stefan Santesson]

Somehow I doubt that I will convince you to include this claim. However, I think we will add some version of this as a private statement to at least advertise the exact URL where the EntityConfiguration of this entity can be found.
This obviously does not help entities that validates chains bottom up (As described in section 10), but it would be very helpful for Resolvers that traverse the tree of services top-down.

The specification allows different alternative URL:s relative to the EntityIdentifier where the metadata can be published. Resolvers that periodically traverses the federation tree from a trust anchor to refresh and cache data will have to try a lot of non-working URL:s because of this.

This claim would prevent that and would even allow an entity to store EntityConfiguration using a completely different URL. Such entity will not be discoverable and verifiable using section 10 procedures, but could still be available via resolvers.

I think it would improve the standard to include this, bu if you disagree, then I suggest you close this.

[Michael Jones]

Closing on the basis of Stefan's comment.

The editors understand the idea. We're just not comfortable adding a second way of doing things when one should be sufficient and will therefore be more interoperable.