Delegated Entity Configuration signing

[Stefan Santesson]

It is very likely that not all leaf entities will have the combined capability to create and sign their own Entity Configuration. This may be caused by a number of reasons:

• The leaf entity is a public client with no static IP and no server capabilities
• RP or Client based on 3:rd party software without sufficient capabilities

We have discussed that a leaf entity could delegate this to its superior Intermediate so that this Intermediate

• Assigns the EntityID (under the Intermediates FQDN)
• Creates the Entity Configuration
• Publish the Entity Configuration under /.well-known location

The only problem with this is that the Entity Configuration must be signed by the leaf entity federation key. This may turn out to be a very tricky problem as this requires suitable software with access to the federation key of the leaf entity.

For these situations it would be very helpful if the leaf entity could also delegate the signing of the Entity Configuration to the Intermediate, making it the responsibility of that Intermediate to verify the key used by the leaf entity by some means outside of this specification.

I can think of some ways to solve this:

• Simply allow the Entity Configuration to be signed by an Intermediate entity key that also issues the Entity Statement for this leaf entity.
• Allow the EntityStatement for this leaf entity to be used and published as the EntityConfiguration of this leaf entity.

The latter seems more effective. It would still work the same way as it is found at the /.well-known location for the EntityID of the leaf entity. It will be treated as the EntityConfiguration of that Entity. The only thing that would differ is the path construction that will be one statement shorter.

‌

[Michael Jones]

Thanks for thinking through some of the possibilities, Stefan.

[Michael Jones]

Hi Stefan. I’ve thought about this some more. The problem with allowing the Entity Statement for a Leaf act as its Entity Configuration is that there wouldn’t be an Entity Configuration at the Entity Identifier URL from which to start building a trust chain. The party building the trust chain would have to somehow know who the Leaf’s superiors are and know to ask them for their Entity Statements about the Leaf.

There’s a simpler way to accomplish this and still have an Entity Configuration at the Entity Identifier. Have a third party, such as a department, organization, or Trust Anchor host the Entity Configuration for Leaf Entities that have trouble doing so themselves. The metadata in these Entity Configurations would still refer to the correct authorization_endpoint or whatever, depending upon the Entity Type.

For instance, a Trust Anchor could offer hosting services to Federation members. The Entity Identifiers could be from a set like:

• https://entity1.trust-anchor.example
• https://entity2.trust-anchor.example

The metadata at https://entity1.trust-anchor.example could still reference endpoints at places like:

• https://op.department.university.example/authorization_endpoint

That would enable Entities that can’t easily host and sign their own Entity Configurations to participate, while still enabling them to be included in Trust Chains.

(Credit to @Roland Hedberg for explaining this possibility to me.)

[Stefan Santesson]

Hi Michael.

I think you have misunderstood my proposal. 

We completely agree on everything you say. The superior entity can offer an Entity Identifier under the superiors URL where the Entity Configuration is made available. That part I have discussed with Roland and we totally agree with that.

But that does not solve the signing part, because if the Entity Configuration stored at the TA URL location must be signed by the target leaf entity, then the TA must send this unsigned Entity Configuration to the leaf for signing, and this creates a whole pile of challenges.

So given that we do all you say and publish the Entity Configuration of entity1 at https://entity1.trust-anchor.example, the question is what data we can make available here.

1. An Entity Configuration signed by entity1
2. En Entity Configuration signed by trust-anchor
3. The Entity Statement issued by trust-anchor for entity1

I would like to avoid having to send the Entity Configuration statement to entity1 for signing. So I would like to allow either 2 or 3.

I think 3 would work just fine. This is how I think the discovery and chain validation would be executed in such case:

1. op.department.university wants to find and validate the metadata of entity1
2. op.department.university gets the Entity Configuration of entity1 from https://entity1.trust-anchor.example/.well-known/openid-federation
3. What is returned to op.department.university is the Entity Statement issued by trust-anchor
4. op.department.university builds the path from trust-anchor to this Entity Statement and verifies its authenticity
5. op.department.university use the validated Entity Statement issued for entity1 to extract metadata for entity1 and process this metadata through the policies of the chain.

‌

Alternative 2 would also work. It would increase the complexity slightly, but the advantage may be that it retains more of the current logic. This would be executed in the following steps:

1. op.department.university wants to find and validate the metadata of entity1
2. op.department.university gets the Entity Configuration of entity1 from https://entity1.trust-anchor.example/.well-known/openid-federation
3. What is returned to op.department.university is the Entity Configuration for entity1 but signed by trust-anchor federation key
4. op.department.university builds the path from trust-anchor to this Entity Configuration and verifies its authenticity. In this step it must allow Entity Configuration to be signed by either the Entity Configuration federation key OR the superior entity federation key (This is the only modification in this case).
5. op.department.university use the validated Entity Configuration to extract metadata for entity1 and process this metadata through the policies of the chain.

‌

[Stefan Santesson]

Just as a side-note. I also would like to add that this way of hosting Entity Configuration (which I totally support) is linked to the discussion of the merge algorithm in the following way:

• This way to host Entity Configuration at the superior entity will require the Entity Identifier to be aligned with the superior entity URL
• This makes it harder for the hosted entity to re-enroll in other federations, as doing so will change its Entity Identifier
• This makes it even more important to be able to allow federations to be interconnected, allowing entities to participate in other federations without changing its superior entity
• This makes it even more important to allow definition of metadata_policy merge in a way where each TA stays in control of what is allowed in their context.

‌

[Stefan Santesson]

I would like to close this issue. I now think there are better ways to handle this problem than any change in the fact that Entity Configuration is always self-signed using the entity’s federation key. I will open a new issue instead proposing a new Entity Statement claim that I think is a better way forward.

[Michael Jones]

Closing, per Stefan's request