NIP-FI: Federated Identity Authorization (spec + formal model)

[tlongwell-block]

What

Adds NIP-FI: Federated Identity Authorization — a normative spec (docs/nips/NIP-FI.md) and companion formal model (docs/nips/NIP-FI-MODEL.md) for authorizing an already-authenticated Nostr key only when a valid OIDC/JWT assertion from an external identity provider resolves to the same active identity-to-key binding.

Docs only; no code changes.

Why

#1476 implements corporate identity binding for the Buzz relay. Per the buzz-security discussion (thread 0d1aee9e), the requirement is broader: anyone with Okta or a generic OAuth2 reverse proxy providing JWTs should be able to enable this class of enhanced identity auth. Without a spec, the first large deployment's configuration becomes an accidental standard. Prior-art survey (upstream nips @ 8f8444d, strfry, Chorus, nostr-rs-relay, rnostr, relay.tools, NIP-46/98, Blossom) found no existing NIP or relay implementation binding a trusted IdP subject to a pubkey at relay authentication — closest shapes are NIP-05 domain verification (DNS/HTTPS polling, not request-time credentials) and NIP-46 auth_url (custody UX, not relay binding).

Design spine

• Identity is issuer-qualified (iss, sub) — never bare sub, username, or email.
• Active bindings form a per-domain partial bijection between identity and key; every transition preserves it.
• A bearer assertion never substitutes for Nostr proof (NIP-42/NIP-98); the authorized key is always the proof's key.
• Explicit enrollment modes: attested-key (IdP carries the npub claim), provisioned (admin-created only), risk-labeled tofu.
• Check + first bind is atomic; races and storage failures fail closed.
• Cached WS authorization is a lease bounded by assertion exp, tracked per authenticated key.
• Revocation cannot be undone by replaying a still-valid assertion; key rotation is an explicit transition, never conflict resolution.
• Trusted-proxy transport is conforming only when direct ingress is impossible and inbound header copies are stripped; client-attached transport uses Nostr-Federated-Identity: Bearer <JWT> (avoiding NIP-98's Authorization header).
• Delegation (e.g. NIP-OA) composes without granting the delegate a federated binding.
• Discovery via NIP-11 limitation.federated_identity + optional federated_identity object.

Relationship to #1476

The spec generalizes #1476's semantics (reviewed at bd822f3e) into a provider-neutral contract. One known delta: the spec requires WS leases not to outlive assertion exp; #1476 PR1 checks identity once at AUTH and defers lease expiry to its lifecycle follow-up. Spec leads implementation here.

Verification

• Formal model: trust assumptions, authorization predicate, binding state machine, safety/liveness properties, 13 adversarial traces — each trace resolves deterministically against normative text.
• Joint pre-PR quality gate (50+ binary completeness checks, benchmark vs NIPs 05/42/46/98): run independently by both authors; all Minimalness/Elegance/Correctness scores ≥9/10.

[wesbillman]

The revocation requirement is not enforced by the authorization transition. Revoke removes (i, k) from B_D and appends it to R_D, but Authorize only reads active bindings in B_D. On the next request for the same revoked pair, both lookups are empty, so attested-key and tofu recreate the pair and return ALLOW(created). That directly contradicts the normative text at NIP-FI.md:111 and the model's own requirement at NIP-FI-MODEL.md:137 that a fresh assertion must not reactivate a revoked pair without explicit recovery authorization.

Please make revocation history/tombstones part of the atomic authorization transition (for example, deny enrollment when (D, i, k) has a revocation record unless this invocation is an explicit recovery transition), and update the liveness statement so “unbound pair” excludes revoked pairs.

[KlavsKlavsen]

this would be a requirement for us (or anyone wanting to adhere to EU law) to use this software.. as its part of standard NIS2 and GDPR requirements to have sane security practices - incl. centralised user management (as allowed by OIDC or OAuth2)