@oidfed/* — OpenID Federation 1.0

The complete OpenID Federation 1.0 implementation for JavaScript — runtime-agnostic, spec-compliant, built on Web API standards. Trust chain resolution and validation, metadata policy enforcement, trust marks, constraint checking, and automatic and explicit client registration — split across four focused packages built on Web API primitives (Request → Response), running anywhere JavaScript runs: Node.js, Deno, Bun, and beyond. All persistent state is behind pluggable storage interfaces, keeping database and HSM integrations entirely outside the core packages. The only runtime dependencies are jose and zod. Two operational utilities — a CLI and a browser-based explorer — complete the toolchain.

Explorer · Project Home · Learn OpenID Federation

Important

Spec: Full OpenID Federation 1.0 implementation ·

Crypto: All JOSE operations delegated to jose ·

Status: v0.2.0 pre-release — API may change before the first stable 1.0 release.

---

                    Trust Anchor                 ← @oidfed/authority
                   ╱             ╲
       Intermediate               Intermediate   ← @oidfed/authority
            │                          │
   OpenID Provider             OpenID Provider   ← @oidfed/authority + @oidfed/oidc
            │                          │
    Relying Party               Relying Party    ← @oidfed/leaf + @oidfed/oidc

    @oidfed/core underlies every node in the graph

---

Packages

Package	Role	Install when building a…	Docs
@oidfed/core	Federation primitives — entity statements, trust chain resolution, metadata policy, and cryptographic verification. The foundational layer of the complete OpenID Federation 1.0 implementation	Any federation participant	docs/packages/core.md
@oidfed/authority	Trust Anchor and Intermediate Authority operations — subordinate management, statement issuance, federation endpoint serving, and policy enforcement	Trust Anchor or Intermediate Authority	docs/packages/authority.md
@oidfed/leaf	Leaf Entity toolkit — Entity Configuration serving, authority discovery, and trust chain participation for any entity at the edge of an OpenID Federation	Relying Party	docs/packages/leaf.md
@oidfed/oidc	OpenID Connect and OAuth 2.0 federation flows — automatic and explicit client registration, Request Object validation, and RP/OP metadata processing as defined in OpenID Federation 1.0	OP or RP	docs/packages/oidc.md

For integration examples, see the Wiring Guide. For production storage backends (PostgreSQL, MongoDB, Redis) and HSM key stores, see the Storage Guide. To run a full multi-topology federation locally with wildcard DNS and TLS, see the Dev Guide and E2E Test infrastructure.

The repository also ships a CLI (@oidfed/cli), a live federation explorer at explore.oidfed.com, an interactive course at learn.oidfed.com, and a few internal packages that support the workspace — browse the source or the docs/ directory to learn more.

Related Specifications

OpenID Federation 1.0 has been factored into two final successor specifications that together cover exactly the same functionality — a protocol-independent layer and a protocol-specific layer. Because @oidfed is a complete OpenID Federation 1.0 implementation, it is simultaneously a complete implementation of both 1.1 final specifications:

Specification	Status	Scope
OpenID Federation 1.1	Final ✓	Protocol-independent layer — Entity Statements, Trust Chains, Metadata, Policies, Trust Marks, Federation Endpoints
OpenID Federation for OpenID Connect 1.1	Final ✓	Protocol-specific layer — OAuth 2.0 / OpenID Connect entity types, client registration flows
OpenID Federation Wallet Architectures 1.0	Draft	Trust establishment for Wallet ecosystems with OpenID Federation
OpenID Federation Extended Listing 1.0	Draft	Subordinate Listings Specification for large-scale federations

Note

OpenID Federation 1.1 + OpenID Federation for OpenID Connect 1.1 are a clean split of OpenID Federation 1.0 — no functionality was added or removed, only factored apart. A complete 1.0 implementation is therefore a complete 1.1 implementation by definition. The Wallet Architectures and Extended Listing specs are independent extensions (still in draft) for which support may be added in future releases.

For real-world integration examples see the Wiring Guide, the dev federation server, and the E2E test infrastructure.

Federation Operator Notes

Running a federation involves responsibilities beyond what this library enforces. Operators MUST read and address:

• §18 — Security Considerations: DoS prevention for the resolve, fetch, and registration endpoints; authority_hints depth limits; Trust Mark filtering; reverse-proxy end-to-end signing.
• §19 — Privacy Considerations: Entity Statements are org-level infrastructure — keep personal data minimal; mitigate Trust Mark Status and Fetch endpoint tracking via short-lived tokens and static Trust Chains.
• §17 — Implementation Considerations: Multi-path topology ambiguity; Trust Mark policy design; resolver and Trust Anchor co-location.

This library provides the protocol mechanisms; policy, rate limiting, key management, HSM integration, and operational hardening are the operator's responsibility.

Security

To report a vulnerability, email dah.kenangnon@gmail.com — see SECURITY.md for the full disclosure policy.

License

@oidfed is dual-licensed by component:

• Libraries — @oidfed/core, @oidfed/authority, @oidfed/leaf, @oidfed/oidc, @oidfed/cli — released under Apache License 2.0.
• Apps & internal UI — @oidfed/explorer, @oidfed/home, @oidfed/learn, @oidfed/ui — released under MIT. See each component's own LICENSE (e.g. apps/home/LICENSE).

The repository root is governed by the Apache 2.0 LICENSE file. Apps and internal packages override this with their own MIT LICENSE file. Refer to the LICENSE in the nearest parent directory of any file to determine its license.

Copyright © 2026-Present Justin Dah-kenangnon.