@oidfed implementation overview & feedback

@oidfed

A complete OpenID Federation 1.0 implementation for JavaScript.

oidfed entity statement anatomy — header, claims, signature

Justin Dah-Kenangnon
@oidfed · OIDF AB/Connect WG · 2026-05-21              talk.oidfed.com
@oidfed implementation overview & feedback

Justin Yamonwan Dah-kenangnon

  • Background — Engineering graduate in Mathematics & Modelingsoftware engineer with a focus on identity and integration work
  • OIDC — integrations mostly built on Filip Skokan's node-oidc-providerdeploying real OPs and consuming them as RPs
  • Federation — came in cold to the OpenID Federation specthis implementation is the way I learned it — the source of today's feedback
@oidfed · OIDF AB/Connect WG · 2026-05-21              talk.oidfed.com
@oidfed implementation overview & feedback

What @oidfed is

  • @oidfed/coreEntity Statements, trust chain resolution, metadata policy, crypto verification
  • @oidfed/authorityTrust Anchor & Intermediate — subordinate mgmt, issuance, endpoints, policy
  • @oidfed/leafLeaf Entity toolkit — EC serving, authority discovery, chain participation
  • @oidfed/oidcOIDC / OAuth 2.0 flows — automatic & explicit registration, Request Object
  • @oidfed/cliResolve, fetch, validate, decode, sign — debug deployments from the terminal

Apps & resources

fed.oidfed.com Demo · not production

Reference federation deployment — six topologies built on the @oidfed packages, exercised end-to-end to validate spec compliance.

explore.oidfed.com

Browser-based federation explorer — paste any entity URL, render its trust chain, statements, and resolved metadata inline.

resources

learn.oidfed.com  ·  oidfed.com
course material and project home.

@oidfed · OIDF AB/Connect WG · 2026-05-21              talk.oidfed.com
@oidfed implementation overview & feedback

The demo federation

Demo · validates spec compliance · not real-world adoption

  • Six topologies live — single-anchor · hierarchical · multi-anchor · cross-federation · constrained · policy-operatorseach one exercises a different corner of the spec on shared @oidfed/* code
  • One Node process — vhost-dispatched · Hono for federation-only entities · Express + node-oidc-provider for OPssame source tree mirrors the upstream e2e bed at oidfed/tests/e2e/
Browser Sign in at rp1.single.fed.oidfed.com or rp2.single.fed.oidfed.com CLI oidfed resolve https://single.fed.oidfed.com  ·  oidfed chain <leaf> --ta <ta> Explorer Paste any entity URL into explore.oidfed.com — chain & metadata rendered live
@oidfed · OIDF AB/Connect WG · 2026-05-21              talk.oidfed.com
@oidfed implementation overview & feedback

Live demo

≈ 90 seconds

Demo federation · not production

  1. rp1.single.fed.oidfed.com — automatic client registration
  2. rp2.single.fed.oidfed.com — explicit client registration
  3. explore.oidfed.com — the same federation, visualised
@oidfed · OIDF AB/Connect WG · 2026-05-21              talk.oidfed.com
@oidfed implementation overview & feedback

Three pieces of feedback

From running the implementation

Item 1 §12.1.1.1.1 ·
request delivery

Embedded trust_chain overflows the query carrier — propose a conditional SHOULD NOT.

Item 2 §6.2 ·
constraints_crit

No fail-closed escape hatch for custom constraints — add a mirror of metadata_policy_crit.

Item 3 Runtime policy ·
future-work signal

Decisions whose inputs change between requests — candidate for a separate I-D, not a §6 amendment.

@oidfed · OIDF AB/Connect WG · 2026-05-21              talk.oidfed.com
@oidfed implementation overview & feedback

Feedback 1  ·  §12.1.1.1.1

Request delivery  ·  Issue & Description

Issue

Embedded trust_chain in the Request Object's JWS header overflows the ?request=<JWT> query carrier.

Description

A three-statement chain (Leaf + Intermediate + TA) is already 8–12 KB — past nginx's default proxy_buffer_size of 8 KB. The 502 fires on the smallest interoperable topology, not on a deep edge case.

The spec already acknowledges the size pressure in §12.1.1.1.1 — "it may be necessary to use the HTTP POST method, a request_uri, or PAR for the request" — but reads as a footnote rather than guidance for the production path.
@oidfed · OIDF AB/Connect WG · 2026-05-21              talk.oidfed.com
@oidfed implementation overview & feedback

Feedback 1  ·  §12.1.1.1.1

Request delivery  ·  Proposal & Example

Proposal

Add a conditional SHOULD NOT to §12.1.1.1.1 when trust_chain is embedded. POST form_post, request_uri, or PAR SHOULD be used instead.

No default change to OIDC Core's request-parameter shape — only conditional, only when the chain is in the header.

Example

// Failing path
GET /authorize?request=<9KB JWT with trust_chain>
→ HTTP/1.1 502 Bad Gateway   (nginx proxy_buffer_size)
 
// Working path (form_post default in @oidfed/oidc@0.4.0)
POST /authorize  Content-Type: application/x-www-form-urlencoded
request=<same JWT>
@oidfed · OIDF AB/Connect WG · 2026-05-21              talk.oidfed.com
@oidfed implementation overview & feedback

Feedback 2  ·  §6.2

Add constraints_crit  ·  Issue & Description

Issue

§6.2 lets federations define custom constraint parameters but mandates silent-ignore for unrecognised ones. No fail-closed escape hatch on the constraint side.

Description

The metadata side already has metadata_policy_crit (§6.1.3.2) — a federation can mark a custom operator as required-to-understand, with chain invalidity as the failure mode.

The constraint side has nothing equivalent. A verifier that hasn't implemented a custom constraint silently admits the chain, breaking the federation's stated guarantee.
@oidfed · OIDF AB/Connect WG · 2026-05-21              talk.oidfed.com
@oidfed implementation overview & feedback

Feedback 2  ·  §6.2

Add constraints_crit  ·  Proposal & Example

Proposal

Add a constraints_crit claim to §3.1.3 — exact mirror of metadata_policy_crit semantics. One new claim name, backwards-compatible, low review burden.

Example

// Subordinate Statement
{
  "iss": "https://ta.regulated-fed.example",
  "sub": "https://intermediate.bank.example",
  "constraints": {
    "max_path_length": 2,
    "required_trust_marks_in_chain": ["https://.../audit-2026"]
  },
  "constraints_crit": ["required_trust_marks_in_chain"]
}
@oidfed · OIDF AB/Connect WG · 2026-05-21              talk.oidfed.com
@oidfed implementation overview & feedback

Feedback 3  ·  runtime policy

Future-work signal  ·  Issue & Description

Issue

§6's extension points (operators, constraints) are code-distributable and static. They cannot encode decisions whose inputs change between requests — entity-graph state, federation-operational mode, dynamic naming.

Description

Concrete drivers: delegation budgets that narrow during operational incidents, federation-wide capacity envelopes, entity-reliability metrics over sliding windows.

§6.1.1 Determinism correctly rules these out of static metadata-policy — so the layer cannot live inside metadata_policy. Federations today are forced to fork the operator set or build the policy layer out-of-band, losing federation's signature guarantees.
@oidfed · OIDF AB/Connect WG · 2026-05-21              talk.oidfed.com
@oidfed implementation overview & feedback

Feedback 3  ·  runtime policy

Future-work signal  ·  Proposal

Proposal

Not a §6 amendment. Candidate for a separate I-D — working title oidf-runtime-policy-1_0 — defining an opt-in federation_policy_evaluation_endpoint alongside the static layer.

Signed verdict carries iat/exp, so cached decisions remain deterministic inside the window. The runtime layer MAY further restrict; it MUST NOT loosen the static one — §6.1.1 Hierarchy preserved.

Ask

Just one: "Is the underlying need real enough to merit a draft I-D, and would the WG entertain it as separate work in the post-1.1 follow-up cycle?"
@oidfed · OIDF AB/Connect WG · 2026-05-21              talk.oidfed.com
@oidfed implementation overview & feedback

Feedback 3  ·  runtime policy

Future-work signal  ·  Example

TA declares the endpoint

"metadata": {
  "federation_entity": {
    "federation_policy_evaluation_endpoint":
      "https://policy.ai-fed.example/evaluate",
    "federation_policy_evaluation_fallback": "use_cached"
  }
}

Signed verdict

// policy-decision+jwt — narrows a static budget federation-wide
{ "iss": "https://policy.ai-fed.example",
  "sub": "https://advisor-platform.example",
  "iat": 1779373800,  "exp": 1779373860,
  "decision": "modified",
  "effective_metadata": { "default_delegation_budget": 50 } }
@oidfed · OIDF AB/Connect WG · 2026-05-21              talk.oidfed.com
@oidfed implementation overview & feedback

Thank you.

Open to any suggestion, question, or further involvement — on the spec, on the implementation, or on the demo.

Justin Dah-Kenangnon dah.kenangnon@gmail.com · github.com/Dahkenangnon · https://www.linkedin.com/in/dahkenangnon/
After WG Call
talk.oidfed.com/openid-working-group-call-2026-05-21 · fed.oidfed.com · explore.oidfed.com · learn.oidfed.com · github.com/Dahkenangnon/oidfed
@oidfed · OIDF AB/Connect WG · 2026-05-21              talk.oidfed.com