How does establishing subordination work?

[tgeoghegan]

The draft describes at length how to represent an established subordination relationship: the subordinate lists its superior's identifier in its authority_hints, and the superior serves entity statements for its subordinates from its federation_fetch_endpoint, federation_list_endpoint, etc. However the draft doesn't really explain how two entities would go about establishing such a relationship. I think it's doable with the current text (draft 41), but it requires reading between the lines a bit, and careful interpretation of existing requirements.

Here's my guess at how we would go about getting entity A to subordinate entity B:

1. B publishes an entity configuration with an empty authority_hints, or no authority_hints at all (see Note 1 below)
2. Some entity (could be B, could be something else) makes a request to A asking it to subordinate B, providing B's entity identifier (see Note 2 below)
3. A fetches B's EC from /.well-known/openid-federation, relative to B's identifier
4. A evaluates some policy to decide whether or not it wants to subordinate B (see Note 3 below)
5. If yes, A begins acknowledging requests sent to its fetch, list, resolve endpoints pertaining to B (see Note 4 below)
6. B's EC is updated to include A's identifier in its authority_hints

Note 1: Step (1) would seem to violate the specification's requirements for an EC, but actually authority_hints is only required for "Entities that have at least one Superior above them". An entity that isn't yet subordinate to anything has no Superior, and so despite not being a trust anchor or an EC, it's permitted for it to have no authority_hints. Another option here would be for the EC to speculatively include its desired superior in authority_hints. The draft requires that superiors be listed in authority_hints, but it doesn't forbid listing other entities.

Note 2: OpenID Federation doesn't currently define an endpoint that works for this. I think that either federation_fetch_endpoint or federation_resolve_endpoint could be overloaded for this, though, if the semantic of either was implied to be "give me an ES for the named entity if you already know about it. If you don't know about it, then please subordinate it, and once that's done, give me an ES". I'm not sure that's a great idea, though.

Note 3: IMO this policy is outside the scope of the OpenID Federation draft.

Note 4: The delta of time between this step and the next is interesting. What does it mean if A publishes an ES about B, but B does not yet have A in its authority_hints? Should an RP consider B to be subordinate in this case?

So this is workable, and good enough for the OIDF prototype I'm working on right now. But I think it'd be nice to formalize some of this to make sure it remains workable, and make it more clear how it works. In particular:

a. authority_hints are more than hints. Since RPs will generally be starting from leaf entities and working their way up the trust chain, the whole thing falls apart without these hints. I think the name should be changed to make it more clear that authority_hints is nearly authoritative.
b. Define something like an Entity Configuration but with a distinct type (e.g., entity-subordination-request+jwt) and make it clear its purpose is requesting subordination to reduce the risk of misuse. This would be akin to a PKCS#10 CSR, or a Certificate Transparency precertificate.
c. Add endpoints alongside federation_fetch_endpoint that are explicitly for requesting subordination, and spell out what the requests and responses look like.
d. Clarify what happens when subordination is partially established, i.e. only one side of the relationship has been updated to reflect the subordination.

It's possible that the mechanics of subordination establishment are outside of the scope of this document, in which case I'd be grateful for a pointer to which draft I should be watching.

Thanks!

[zachmann]

I strongly believe that this is out of scope of the spec.
While I'm not at all an federation operator or expert, I have the understanding that joining a federation is a rather lengthy process that also requires a lot of legal and policy work (of course this might be depend on the type of federation). I also think that the exact procedure can greatly differ between federations.

Nevertheless, I agree that the process can be abstracted into a few steps:

• Enroll Request
• Checks
• Approval (or rejection)

Federations will have different requirements for the checks they perform, as a result they also need different information in the enrollment request.

Some checks could be easily checked in an automated way. But I also envision that there are thinks that must be checked more manual. However, it would be possible to issue trust marks for those things, therefore outlouding the manual checking to the trust mark issuance, while the enrollment could then be checked in an automated way.

In my go implementation I have implemented something very similar to what you describe:
I introduced two new endpoints for enroll requests: The request for both is the same and in line with what you described. An entity submits the entity id that should be enrolled. The authority then obtains the entity configuration.

One of the endpoints is for automated enrollments, it will perform certain checks on the EC and if they pass, enroll the entity, i.e. it is included in the list endpoint as well as an entity statement is issued on the fetch endpoint.

The other endpoint is only for requests. It will just store the request and a federation admin needs to approve it.

Note 2: OpenID Federation doesn't currently define an endpoint that works for this. I think that either federation_fetch_endpoint or federation_resolve_endpoint could be overloaded for this, though, if the semantic of either was implied to be "give me an ES for the named entity if you already know about it. If you don't know about it, then please subordinate it, and once that's done, give me an ES". I'm not sure that's a great idea, though.

I would strongly advice to use a new endpoint for this. Overloading other endpoints for this does not make sense.

Note 4: The delta of time between this step and the next is interesting. What does it mean if A publishes an ES about B, but B does not yet have A in its authority_hints? Should an RP consider B to be subordinate in this case?

I would say, yes A is a subordinate of B. It would be technically possible to build a trust chain for A using B if one traverses top-down (a resolver might do this).
However, as you know the usual approach is to go bottom-up, which would not work here.
Which leads us to the term authority_hints; after all it is still only a hint. The entity hints on what it thinks it's authorities are. This might not be correct for two reasons: (1) A listed authority does not issue statements, (2) A not-listed authority does.

If one has other means to establish trust chains that does not involve authority hints, those trust chains are still perfectly valid.

It's possible that the mechanics of subordination establishment are outside of the scope of this document, in which case I'd be grateful for a pointer to which draft I should be watching.

As already noted, I also think that this is out of scope. I know that when I read the spec for the first time this was the one thing I was curious about the most; and felt a bit let down that it is not in there. However, I think it is reasonable.
I also see the challenge that "joining a federation" is (at least in some federations) a complex procedure. I see the potential for a defined simple approach somewhat in the lines of what you described and I have implemented. But I'm sure that this would need to go into a separate draft; I believe that this does not yet exist.

[selfissued]

Establishing subordinate/superior relationships among Entities is an administrative action performed by the organization and not a protocol features. For instance, a university might establish its departments as subordinates.

We propose to close this issue in a week unless reasons to keep it open are stated.

[tgeoghegan]

Declaring this to be out of scope of this particular OpenID Federation draft seems reasonable. However I do think it should be a design goal of OIDF to not preclude automated mechanisms for establishing subordination. Nothing I see in the current draft makes this impossible, though, so I'd be OK with closing this issue.

[selfissued]

We discussed this on the 17-Feb-25 working group call. We agreed that doing an extension to establish these relationships procedurally would be fine but the current specification doesn't do it.

[TomCJones]

Such a API would be extremely complex in view of the complex structures that some (eg) universities have just within their email programs: students, professors that are students, labs, and associated independent bodies - csail at mit - clubs - mergers - divestitures, etc.
Probably more trouble than you can imagine.