Implementer feedback from @oidfed: JavaScript OpenID Federation 1.0 implementation overview and observations

[Dahkenangnon]

Context

Following the OpenID Foundation AB/Connect Working Group call where I presented my @oidfed implementation overview, I was encouraged to capture the implementation feedback in a GitHub issue so it can be recorded and discussed in the right place.

Presentation reference:

• Slides: https://talk.oidfed.com/openid-working-group-call-2026-05-21/

Implementation and demo references:

• Project home: https://oidfed.com/
• Live reference federation: https://fed.oidfed.com/
• Federation explorer: https://explore.oidfed.com/
• GitHub repository: https://github.com/Dahkenangnon/Oidfed

Implementation overview

@oidfed is a JavaScript / TypeScript implementation of OpenID Federation 1.0.

The goal of the project is to provide a complete implementation of the main OpenID Federation roles and flows, with a runtime-agnostic design based on Web API primitives. The same core implementation is intended to be usable across environments such as Node.js, Deno, Bun, workerd, Electron, and browsers.

The implementation is split into focused packages:

• @oidfed/core
  Core federation primitives, including entity statements, entity configurations, trust-chain resolution, metadata policy processing, cryptographic verification, schemas, and constants.

• @oidfed/authority
  Trust anchor and intermediate authority functionality, including subordinate management, federation endpoints, entity statement issuance, metadata policy, constraints, trust marks, key lifecycle, and authority operations.

• @oidfed/leaf
  Leaf entity functionality for OPs, RPs, resource servers, and other federation participants, including entity configuration serving, authority discovery, and trust-chain participation.

• @oidfed/oidc
  OpenID Connect / OAuth 2.0 integration layer, including federation-aware client registration flows, request validation, and OIDC/OAuth-related federation behavior.

• @oidfed/cli
  Command-line tooling for implementers to fetch, resolve, decode, validate, sign, and debug OpenID Federation deployments.

NB: The project is implementing other profile like the Extended List Endpoint, Entity Collection, etc

Demo federation and testing approach

The project includes a live reference federation at:

https://fed.oidfed.com/

The demo federation currently exercises several federation topologies:

• single-anchor federation;
• hierarchical federation;
• multi-anchor federation;
• cross-federation;
• constrained federation;
• policy-operators federation.

The intention is to test the implementation against more than one happy-path topology and to make different federation structures observable and debuggable.

The explorer at:

https://explore.oidfed.com/

provides a browser-based way to inspect:

• entity configurations;
• entity statements;
• trust chains;
• resolved metadata;
• metadata policy behavior;
• federation relationships.

The CLI provides a terminal-based equivalent for implementers who prefer debugging directly from the command line.

Implementer observations

The following points are implementation observations only. I am recording them as feedback that may be useful for future discussions, deployment guidance, profiles, test suites, or future evolution of the work.

1. Request size when trust_chain is embedded in the Request Object

When the trust_chain is embedded in the Authorization Request Object, the resulting request can become large quickly.

In implementation testing, even a relatively small trust chain can produce a large Request Object once the signed entity statements, metadata, keys, policies, and JWS serialization are included.

This made front-channel delivery with ?request=<JWT> feel operationally fragile in some deployments, especially when the request passes through browsers, reverse proxies, gateways, load balancers, or web servers with request-line or header-size limits.

The existing specification already acknowledges that POST, request_uri, or PAR may be necessary because a Trust Chain can be large. My implementation experience confirmed that this is not only theoretical; it appears quickly in practical testing.

Observation for future deployment guidance or profiling:

• deployments embedding trust_chain directly in the Request Object should carefully consider request-size limits;
• request_uri, PAR, or POST-based delivery may be more robust in real deployments;
• implementers should test with realistic trust-chain sizes rather than only minimal examples.

2. Constraints and required-to-understand behavior

While implementing metadata policy and constraints, I noticed a practical difference between the extensibility model for metadata policy and the extensibility model for constraints.

For metadata policy, metadata_policy_crit gives a way to mark custom policy operators as required-to-understand.

For constraints, I did not find an equivalent required-to-understand mechanism for custom constraint parameters.

From an implementer perspective, this means that custom constraints need careful handling in deployments and profiles. If a federation relies on a custom constraint as part of its governance or validation model, implementations need a clear deployment-level agreement on how that constraint is interpreted and whether unknown constraints should fail validation or be ignored.

Observation for future profiles or operational guidance:

• deployments using custom constraints should define explicit processing expectations;
• profiles may need to say whether unknown constraints are ignored or treated as validation failures;
• implementers should avoid assuming that custom constraints are understood unless the federation profile or deployment contract makes this explicit.

3. Static policy and runtime operational decisions

The deterministic nature of entity statements, trust-chain validation, metadata policy, and constraints is a strength of the specification.

During implementation and testing, I also encountered scenarios where deployments might want additional runtime operational decisions outside the static trust-chain and metadata-policy model.

Examples include:

• temporary incident-mode restrictions;
• short-lived suspension or narrowing decisions;
• operational capacity limits;
• emergency governance actions;
• reliability or risk signals that change more frequently than published entity statements.

I do not present this as a missing feature in the final specification. The static model is clear and valuable. The observation is only that some deployments may eventually define additional operational layers around the federation model.

Observation for future discussion or deployment guidance:

• runtime operational policy should not weaken static federation validation;
• if used by a deployment, it should only narrow what static validation already allows;
• such decisions should be auditable, time-bound, and clearly separated from the base federation validation model;
• this may be better handled by deployment profiles or operational guidance rather than the base specification.

The observations above are shared humbly as implementer feedback after building and testing the model in practice. I may guess something in the bad way, I will appreciate any of your clarification, resources which may solve or guide on solving these 3 points above.

Thank you to the Working Group members for the discussion and for encouraging this feedback to be captured here.

I am available and open for any discussion concerned

[fkj]

Thanks for the feedback!

Regarding point 1, I think that could be useful implementation guidance.

Regarding point 2, right now the spec says for custom constraints: "If they are not understood, they MUST be ignored."
I think it might get pretty complicated to encode custom constraint definitions, so it might not make sense to try to define them "programmatically". However, it is probably worth it to add some guidance explaining this in more detail.

Point 3 is a good point. I don't have a solution in mind, but maybe some of this should be handled using e.g. the shared signals framework?

[Dahkenangnon]

Hi @fkj

Share Signal Frameworks can be used, in fact to expire a subordinate statement (per entity statement validation section: https://openid.net/specs/openid-federation-1_0.html#section-3.2 ) when the receiver (a trust anchor or intermediate authority) receive an event which instruct it to not longer vouch for the concerned entity in the federation. That can also be by not recognizing anymore the entity from the fetch endpoint ?

Some trust verifier may also cache the trust chain construction & validation, so, they will need also to participate to that SSF dance in order to invalidate their cache, right ?

Do you have any specific way, SSF can be coupled to resolve the point 3 ?

[fkj]

Yeah, coordinating the signal across all of the participants in the federation could be difficult. I agree that everyone would need to participate in and understand the signals to use SSF for this. I don't have a particular solution in mind, I was just suggesting a potential direction to look into. Some of it also becomes specific to the use case, e.g. if you want to mark authentications during a specific time period for review. So I think a solution might belong more in guidance/a white paper than in the Federation spec itself.