agentleFS
Sign inStart free
ScaleDockHQScaleDockHQ/scaledock-skills/skills/openid-federation/SKILL.md

openid-federation

Skill1 starsChanged 31 days agoMITView on GitHub

OpenID Federation: build and validate trust chains, entity statements and metadata policy. Use when building or reviewing a Trust Anchor, Intermediate, Leaf, Trust Mark Issuer or resolver, or when an OpenID Connect RP or OP must trust a peer through a federation: entity configurations at /.well-known/openid-federation, subordinate statements, authority_hints, trust_anchor_hints, trust chain resolution and validation, metadata_policy operators (value, add, default, one_of, subset_of, superset_of, essential) and metadata_policy_crit, constraints (max_path_length, naming_constraints, allowed_entity_types), trust marks and delegation, fetch, list, resolve, trust mark status and historical keys endpoints, Automatic and Explicit Registration, the trust_chain header, and the Subordinate Events and Extended Subordinate Listing drafts. Pins OpenID Federation 1.0 Final and the Federation 1.1 split (Federation 1.1 and Federation for OpenID Connect 1.1, both Final).

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Follow the workflow below step by step: Every rule here comes from a source in Sources, cited inline as (Spec § section).

    line 15
  2. Very specific:

    Sources refresh: before relying on a pin, compare it with the OpenID Foundation specifications index.

    line 25
  3. Very specific:

    Every constraints claim in the chain is applied, and any failure makes the chain invalid (Federation § 6.2).

    line 34
  4. Distinctive:

    Register OpenID Connect or OAuth 2.0 clients: Use Automatic or Explicit Registration.

    line 57

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

OpenID Federation

OpenID Federation lets two entities with no prior relationship trust each other through a common Trust Anchor. Each entity publishes a signed Entity Configuration, and Superiors publish signed Subordinate Statements about their Immediate Subordinates. A verified chain of these, with its metadata policy applied, gives the peer's Resolved Metadata.

Follow the workflow below step by step. Every rule here comes from a source in Sources, cited inline as (Spec § section). If a rule is not in a source, it is not in this skill.

Federation 1.1 contains the protocol-independent parts of Federation 1.0, and Federation for OpenID Connect 1.1 contains the OpenID Connect and OAuth 2.0 parts. Neither adds functionality beyond 1.0 (Federation 1.1 § 1, Federation Connect 1.1 § 1). This skill cites the 1.1 documents as "Federation" and "Federation Connect". Federation 1.0 holds the same rules in one document.

Inputs (fill in, or ask before starting)

  • Role: Trust Anchor, Intermediate, Leaf (RP, OP, OAuth client, authorization server or protected resource), Trust Mark Issuer, or resolver. One entity can have several Entity Types.
  • Revision: Federation 1.1 and Federation Connect 1.1, or Federation 1.0 if the federation names it. Ask before using a draft.
  • Trust Anchors: the Entity Identifiers and public keys of the Trust Anchors this deployment trusts, obtained out of band (Federation § 4).
  • Federation policy: signing algorithms, required trust marks, client registration methods and any additional policy operators the federation defines.
  • Sources refresh: before relying on a pin, compare it with the OpenID Foundation specifications index. If a revision changed, re-read the source and update metadata.json and Sources.

Invariants

  1. An Entity Identifier is an https URL with a host and optional port and path, and no query or fragment (Federation § 1.2).
  2. Entity Statements have typ: entity-statement+jwt and are rejected otherwise. alg is never none, and kid exactly matches a key in the issuer's Entity Configuration jwks (Federation § 3, § 3.2).
  3. The Entity Configuration is served at the Entity Identifier, minus any trailing /, plus /.well-known/openid-federation, as application/entity-statement+jwt. Trust Anchors and Intermediates MUST publish it (Federation § 9, § 9.2).
  4. A chain is valid only if every statement is current, ES[j].iss == ES[j+1].sub, each statement is signed by a key in the next statement's jwks, and the last statement is the Trust Anchor's, verified with the Trust Anchor key held out of band (Federation § 10.2).
  5. Metadata policy resolves from the most Superior statement down. Any policy error, conflict, or unknown operator listed in metadata_policy_crit makes the chain invalid (Federation § 6.1.4).
  6. Every constraints claim in the chain is applied, and any failure makes the chain invalid (Federation § 6.2).
  7. A chain expires at the smallest exp in it. A registration based on a chain never outlives it (Federation § 10.4, Federation Connect § 12.3).
  8. A trust mark is trusted only after trust in its issuer is established through a chain. It has typ: trust-mark+jwt, and it needs a valid delegation when the Trust Anchor lists an owner for its type (Federation § 7, § 7.3).
  9. Entity Statements already fetched are never fetched again during one resolution, and an authority_hints entry that leads to a loop is dropped (Federation § 10.1). Implementations limit how many authority_hints they follow (Federation § 18.1).
  10. With Automatic Registration, the RP's Entity Identifier is its client_id, requests are authenticated with asymmetric keys, and the RP resolves the OP's chain before sending anything (Federation Connect § 12.1).

Workflow

  1. Publish the Entity Configuration. Set iss equal to sub, plus jwks, metadata per Entity Type, and authority_hints for non-Trust-Anchors. -> references/entity-statements.md ✓ /.well-known/openid-federation returns a signed, typed JWT that passes (Federation § 3.2).
  2. Issue Subordinate Statements and endpoints (Trust Anchors and Intermediates). Expose fetch and list, and add metadata_policy and constraints where needed. -> references/endpoints.md, references/metadata-policy.md ✓ The fetch endpoint returns application/entity-statement+jwt, and errors use (Federation § 8.9).
  3. Resolve a peer's trust chain. Collect statements bottom-up from authority_hints, or use a resolver. -> references/trust-chains.md ✓ Loops and unknown Trust Anchors are skipped, and the number of hints followed is bounded.
  4. Validate the chain, then apply policy and constraints. -> references/trust-chains.md, references/metadata-policy.md ✓ Tests cover a broken signature link, an expired statement, a policy conflict and a constraint failure, and each one invalidates the chain.
  5. Evaluate trust marks when the federation uses them. -> references/trust-marks.md ✓ The trust mark issuer's chain is validated before the trust mark itself.
  6. Register OpenID Connect or OAuth 2.0 clients. Use Automatic or Explicit Registration. -> references/registration.md ✓ The Request Object or registration JWT aud is only the OP's Entity Identifier, and the registration lifetime is at most the chain lifetime.
  7. Refresh and roll keys. Re-resolve when chains expire, and roll Federation Entity Keys with overlap. -> references/trust-chains.md ✓ An expired chain is never used, and old keys stay published until Subordinates have the new ones.
  8. Add draft endpoints only when asked. -> references/endpoints.md ✓ Each draft in use is pinned to the revision in Sources, with its posture recorded.

Verify before done

  • Every Entity Statement, trust mark, resolve response and historical keys JWT checks its typ and rejects a missing or wrong value.
  • Chain validation enforces iss/sub linkage, signature linkage, iat, exp, and the out-of-band Trust Anchor key (Federation § 10.2).
  • Policy resolution starts at the Trust Anchor's statement, merges operators per their rules, and fails closed (Federation § 6.1.4).
  • Operators are applied in order: value, add, default, one_of, subset_of, superset_of, then essential (Federation § 6.1.3.1).
  • Subordinate metadata is applied before the resolved policy (Federation § 6.1.4.2).
  • max_path_length, naming_constraints and allowed_entity_types are enforced (Federation § 6.2).
  • Endpoint URLs are published in the Entity Configuration, not in Subordinate Statements (Federation § 8.1, § 8.2).
  • Chain and registration lifetimes use the minimum exp (Federation § 10.4, Federation Connect § 12.3).
  • Every draft in use carries its pinned revision and posture.

Reference index

FileCovers
references/entity-statements.mdEntity Statement claims, validation, the well-known URL, federation_entity metadata, Entity Types, media types
references/trust-chains.mdChain structure, collection, validation, selection, expiry, constraints, key rollover, DoS limits
references/metadata-policy.mdPolicy structure, the seven standard operators, combination and merge rules, resolution and application
references/trust-marks.mdTrust mark claims, issuers and owners, delegation, validation, status
references/endpoints.mdFetch, list, resolve, trust mark status, listing and issuance, historical keys, client authentication, errors, draft endpoints
references/registration.mdAutomatic and Explicit Registration for OpenID Connect and OAuth 2.0

Related skills

  • openid-connect: the OpenID Connect protocol that Federation Connect registers clients for. npx skills add ScaleDockHQ/scaledock-skills --skill openid-connect
  • openid: the umbrella skill that routes between the OpenID Foundation specifications. npx skills add ScaleDockHQ/scaledock-skills --skill openid
  • jwt: JWS and JWT processing that every Entity Statement relies on. npx skills add ScaleDockHQ/scaledock-skills --skill jwt
  • oauth: OAuth 2.0 clients, authorization servers and protected resources in a federation. npx skills add ScaleDockHQ/scaledock-skills --skill oauth

Sources

Status uses the publishing body's own maturity term. Checked is the date the source was last read.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free