CHAPTER 142 · GOVERNANCE PROPOSAL · NOT A PRODUCTION CLAIM

FountainAuthKit: Fountain Coach Is Its Own Governed OAuth/OIDC Authority

This chapter proposes a reusable Swift-native FCIS-KIT authorization and identity boundary through which Fountain Coach may issue bounded authority to Reframe, FCIS-KIT instruments, MCP clients, native applications, remote services, and other admitted consumers.

Claim boundary: this chapter does not claim that a production authorization server is deployed, externally security-reviewed, accepted for public use, or that auth.fountain.coach is currently live.

Authentication, authorization, operation, and evidence remain separate authorities.

Purpose and the decision

Fountain Coach already governs capabilities, credentials, deployment, durable evidence, and instrument promotion as separate authorities. What remains missing is the authority that can say: this subject authenticated here, this client is known here, this capability was granted here, for this resource, for this duration, under this human decision—without handing that decision to Apple, Google, OpenAI, GitHub, a cloud provider, an MCP implementation, or an individual instrument.

The missing boundary is not another login screen. It is a Fountain.coach-owned authorization authority. The proposed reusable package is FountainAuthKit; a possible deployed authorization-server identity is https://auth.fountain.coach; the governed FCIS capability identity is fountain-coach.authorization.

FountainAuthKit SHALL be implemented as a Swift-owned, independently testable FCIS-KIT package. A deployed authorization service is one admitted use of that package. Reframe, FountainStore, EstatePublisher, remote MCP servers, native applications, and future instruments may consume that authority without becoming the issuer themselves.

The architectural distinction is:

authentication → authorization → capability execution → evidence

Authentication establishes who or what participated in an authentication ceremony. Authorization establishes what that authenticated principal has granted a particular client permission to do. The access token communicates that grant. The resource executes or refuses the requested capability. FountainStore records the governed lifecycle and durable evidence. None of those facts may be inferred from another.

Fountain.coach authority does not mean Fountain.coach passwords

FountainAuthKit MAY authenticate through platform passkeys, hardware-backed credentials, WebAuthn-compatible authenticators, device-bound keys, an external OpenID Connect identity provider, Apple or another admitted provider, an owner-controlled enrollment credential, or another separately governed mechanism.

An upstream provider MAY establish an authentication fact. It MUST NOT automatically become the authority over Fountain.coach capabilities. Authenticated principal ≠ authorized Fountain.coach capability. A successful provider login does not itself authorize estate.publish, fountainstore.write, instrument.release, deployment.apply, or organization.admin.

FCIS-KIT and protocol authority

FountainAuthKit SHALL obey the FCIS-KIT promotion model:

scenario → implementation → build → execution → evidence → admission → reuse

The Kit MUST declare package identity, semantic version, provenance, protocol profile, cryptographic algorithms, issuer, authorization operations, authentication adapters, client-registration model, token types and lifetimes, scopes and resource binding, revocation and expiry, key rotation and recovery, persistence, network and TLS assumptions, public metadata, refusal states, scenarios, evidence authorities, and release/admission state.

A Swift package that can mint a JWT is not an authorization server. A server that responds to /token is not an admitted Fountain.coach authority. A successful MCP connection is not authorization evidence.

FountainAuthKit SHALL implement published interoperable OAuth/OIDC contracts. The initial profile SHOULD include Authorization Code, PKCE, Authorization Server Metadata, Protected Resource Metadata, JWKS publication, and resource-bound access tokens with explicit expiry and revocation. OAuth Authorization Server Metadata is standardized by RFC 8414, Protected Resource Metadata by RFC 9728, and current OAuth security practice by RFC 9700.

protected resource
  → /.well-known/oauth-protected-resource
  → Fountain authorization issuer
  → /.well-known/oauth-authorization-server
  → authorization and token endpoints

MCP is a consumer of authority

MCP SHALL NOT become Fountain Coach’s identity database, authorization policy authority, SecretStore, or token issuer merely because a protected capability is exposed over MCP. MCP transports or exposes governed capability; it does not define who owns that capability.

One grant, one intended resource

An access token MUST be bounded to its intended resource. A credential issued for https://store.fountain.coach must not silently authorize https://estate.fountain.coach, https://git.fountain.coach, or an unrelated MCP service. The normal Fountain grant is:

subject + client + resource + capability + duration + authorization event

Scopes, human authority, and machine delegation

OAuth scopes SHALL correspond to governed capability boundaries wherever practical. Proposed vocabulary such as fountainstore.read, fountainstore.append, estate.inspect, estate.publish.preview, estate.publish.commit, instrument.discover, instrument.execute, instrument.admit, and release.inspect is not a declaration that those scopes currently exist. Each scope MUST resolve to an operation, owner, resource, meaning, mutation boundary, acceptance status, and evidence. Broad admin, all, or root grants SHOULD be rejected unless separately justified.

A valid token does not require every consequential operation to execute without further mediation. Reframe MAY require explicit human confirmation for publication, release, credential rotation, infrastructure mutation, destructive Store operations, authority delegation, or another high-consequence transition.

token permits ≠ host must execute

FountainAuthKit MAY issue authority to Reframe, an FCIS-KIT host, EstatePublisher, a build service, an MCP client, a deployment worker, an enrolled device, or another admitted agent. Machine identity MUST NOT be confused with human identity:

owner authorization → enrolled Reframe instance → bounded EstatePublisher execution

Delegation must remain visible as delegation. An agent may exercise granted authority; it does not become the originating authority merely because it possesses the credential.

Tokens, keys, and durable evidence

Tokens SHOULD contain only claims needed by the relying resource. They MUST NOT become portable copies of private profiles, manuscript material, prompts, provider credentials, organization internals, unnecessary personal information, Store records, or policy prose. Private signing keys MUST NOT appear in Git, releases, prompts, MCP, MIDI2, Store receipts, AX, screenshots, logs, public projections, or deployment arguments.

The key lifecycle MUST be defined as:

generate → activate → publish public key → sign → rotate → retire → revoke / compromise response → recover

FountainStore SHALL record safe authorization facts where durable evidence is required: issuer, authorization-event identity, subject pseudonym or governed identifier where needed, client, resource, requested and granted capability, authorization time, expiry, authentication mechanism class, policy/version identity, outcome, revocation state, relevant instrument/session correlation, and terminal receipt. It MUST NOT persist raw access tokens, refresh tokens, passwords, private keys, authorization codes, or equivalent bearer credentials merely for observability.

Client classes and native applications

FountainAuthKit SHALL distinguish public native clients, confidential server clients, first-party Fountain applications, MCP clients, enrolled devices, external third-party clients, and unrecognized clients. Registration or metadata verification does not grant capability. Reframe and other Apple-platform clients SHALL be public OAuth clients unless evidence establishes another class; they MUST NOT rely on embedded client secrets. Native flows SHOULD use system authorization context, authorization code, PKCE, exact redirect handling, and resource-bound grants.

HTTP, MCP, and MIDI2 remain separate

OAuth/OIDC defines the authorization and identity boundary. MIDI2 defines the typed operational command and lifecycle plane:

OAuth authorization → resource-bound credential
  → FCIS host accepts authorized session
  → typed MIDI2 operation
  → instrument lifecycle
  → FountainStore receipt

HTTP may transport protocol messages, MCP may expose a remote capability, MIDI2 may carry the Fountain operation, and FountainStore may persist evidence. These are composable boundaries, not competing vocabularies.

Existing governance and infrastructure boundaries

Chapter 89 governs external-provider authentication; Chapter 90 the independent-security-review boundary; Chapter 91 FCIS-KIT; Chapter 93 instrument promotion; Chapter 94 external credentials and infrastructure; Chapter 95 server-side Store authority; Chapter 97 trusted-host enrollment; and Chapter 118 the European cybersecurity profile. This chapter joins those authorities; it does not replace them.

FountainAuthKit does not supersede SecretStore, provider IAM, Hetzner authorization, AWS roles, deployment credentials, or equivalent authorities. A Fountain access token is not a Hetzner token, and a Hetzner token is not a Fountain authorization decision.

European regulatory applicability and compliance boundary

This chapter defines a technical authorization boundary; it does not certify Fountain.coach, FountainAuthKit, or a future protected resource as compliant with European Union or Member State law. The regulatory result depends on the deployed service, the data processed, the clients and resources admitted, the entity's role and size, and the jurisdictions reached.

The minimum applicability review is:

GDPR: identify controller and processor roles, lawful bases, purpose limitation, data minimization, retention, data-subject rights, transfers, security, breach response, and a data-protection impact assessment where the processing risk requires one.
ePrivacy Directive: assess cookies, device storage, session identifiers, tracking, and electronic communications separately from GDPR.
NIS2 and its German implementation: determine whether Fountain.coach or a service operator is an essential or important entity, a relevant digital-infrastructure or provider category, or outside scope; do not infer this from OAuth alone.
eIDAS: assess separately if the service uses a notified electronic-identification scheme or provides regulated trust services. Ordinary OAuth/OIDC issuance is not by itself an eIDAS trust service.
AI Act, DSA, and EAA: assess only against the deployed functions and service category, including whether AI makes or supports decisions about people, whether the service is an intermediary or hosting service, and whether a listed accessible product or service is offered.
German and other Member State law: record the applicable national implementation, supervisory authority, contractual terms, and consumer or e-commerce obligations for each target market.

Before any claim of public or security-reviewed production, the compliance evidence must include a dated applicability register with official sources and an owner, controller/processor and subprocessor map, privacy notice and retention/rights design, transfer assessment, incident and breach process, DPIA decision where applicable, accessibility evidence, security review, and qualified legal review. requires_review is a publication blocker; “not applicable” requires a written rationale.

Regulatory status: regulatory applicability is not yet established. These acceptance predicates are engineering evidence, not a legal certification, and the absence of a production issuer means no current Fountain.coach authentication service is being represented as compliant.

Golden Key Vault — canonical implementation prompt

This prompt is the implementation contract for the Fountain-owned custody and one-unlock broker boundary. It extends this chapter’s separation of identity, authorization, credential custody, operation, and durable evidence.

Implement the Fountain Coach Golden Key Vault as a native Swift custody and broker capability under the existing MaintenanceKit and EstatePublisher authority boundaries.
First reconstruct the existing path from AGENTS.md, scoped governance, repository history, current working-tree diff, existing SecretStore and SecretBroker contracts, and the EstatePublisher publication procedure. Do not create a parallel secret system until that reconstruction proves the existing seam cannot satisfy the capability.
The required boundary is identity/authentication → FountainAuthKit authorization grant → typed secret-free broker manifest → one owner-authorized Golden Key Vault session → short-lived leases → native EstatePublisher → FountainStore receipt, remote read-back, and HTTPS proof.
FountainAuthKit remains identity and authorization authority. The Golden Key Vault remains custody authority. EstatePublisher remains operation authority. FountainStore remains publication authority.
Implement a versioned Fountain-owned vault with authenticated envelope encryption, per-record references and purposes, key rotation, revocation, tamper detection, and fail-closed decoding. The Golden Key/root unlock material must never appear in CLI arguments, environment variables, JSON requests, MIDI2 payloads, receipts, logs, or public projections.
Implement one manifest-bound broker session. It must authorize the owner once, load each admitted record once, cache leases only in memory, bind leases to operation/scope/digest/expiry, reject missing or mismatched records, and emit only redacted evidence.
EstatePublisher must derive references from the typed publication request and registry. It must not contain hard-coded services, accounts, hosts, domains, credentials, vault records, or backend-specific custody calls. The one-click command must execute one native estate.publication.sync operation and require the terminal Store receipt, remote read-back, matching digest, and public HTTPS proof.
Extend the established native test procedures. Do not invent a password transport. Do not fall back to direct Keychain access, a stale external broker, generic HTTP, static copying, shell deployment, guessed paths, or a second publication authority.

Required proof before implementation is complete

Contract, schema, cryptographic, and tamper tests pass.
Broker tests prove exactly one owner authorization, one backend read per admitted reference, in-memory lease reuse, expiry, revocation, scope binding, and redacted receipts.
EstatePublisher tests prove dynamic manifest resolution, no direct Keychain or stale-broker fallback, exact target/scope/revision/correlation binding, idempotency, and secret exclusion from output.
Native semantic, Store, template, AX, VRT, and route-integrity gates pass through the established FountainStoreHTTPServer and EstatePublisher procedures.
Live acceptance proves one owner unlock, one native publication process, one terminal receipt, remote read-back, matching digest, public HTTPS, and no second prompt. If any predicate fails, the result is BLOCKED, not COMPLETE.

Implementation status: this is a published implementation contract. It is not a claim that the Golden Key Vault or a one-unlock production publication path is already implemented or accepted.

Scenario-first acceptance

The first implementation SHALL be driven by bounded executable scenarios. Acceptance must establish:

Authorization-server metadata resolves from the declared issuer.
The published issuer exactly matches the authority used during token validation.
A native public client completes authorization using PKCE.
An incorrect redirect URI fails closed.
An authorization code cannot be replayed.
An expired token is refused.
A token issued for Resource A is refused by Resource B.
A token missing the required capability is refused.
An unrecognized or invalid client follows its declared refusal path.
Key rotation preserves explicitly permitted in-flight validity and refuses signatures outside the admitted key history.
Revocation or invalidation produces the declared result.
Protected-resource metadata identifies the intended authorization authority.
An admitted MCP protected resource discovers or validates Fountain.coach authority according to the supported MCP profile.
FountainStore contains the safe authorization/effect lineage without containing bearer credentials.
Logs, AX, screenshots, MIDI2 events, Store records, and public evidence contain no secrets.
Network loss, Store loss, clock skew, malformed metadata, invalid signatures, and issuer mismatch fail closed.
Replaying an execution request cannot silently recreate human authorization.
A successful authentication without sufficient Fountain.coach authorization is refused.
A valid Fountain.coach token without separately required high-consequence human confirmation does not bypass host policy.
The exact release under test is identifiable by source revision, SemVer, dependency resolution, artifact digest, and signing evidence.

The scenario runner establishes its declared predicates. It does not grant production status.

Security acceptance, adversarial review, and recovery

The states remain distinct:

implemented → locally tested → integration accepted
  → owner-controlled operational production
  → independently security-reviewed → public/reusable release

Independent review SHOULD examine redirect handling, PKCE, code binding, issuer and resource confusion, client impersonation, replay, refresh tokens if supported, key generation and rotation, algorithm confusion, JWKS, clocks, metadata poisoning, scope escalation, MCP boundaries, session fixation, CSRF, open redirects, token leakage, signing-key compromise recovery, and administrative escalation. RFC 9700 remains the OAuth Security BCP.

Recovery MUST distinguish restoring service from restoring trust when keys, databases, Store, hosts, DNS, TLS, issuer identity, client credentials, enrolled devices, or outstanding authority are compromised or unavailable.

Public projection, topology, and stop conditions

The public estate MAY publish issuer identity, protocol profile, public metadata/JWKS, documentation, client classes, sanitized capability vocabulary, release identity, admission state, security-review status, interoperability evidence, and governance links. It MUST NOT publish tokens, codes, private keys, client credentials, personal authorization histories, private subject identifiers, SecretStore contents, private Store records, or unsupported live-acceptance claims.

auth.fountain.coach       FountainAuthKit issuer
store.fountain.coach      independent protected resource
estate.fountain.coach     independent protected resource
instruments.fountain.coach independent protected resource

The first implementation SHOULD remain small: issuer, metadata, key custody, Authorization Code + PKCE, resource-bound access tokens, protected-resource validation, revocation/expiry, Store evidence, and one real FCIS/MCP protected resource. Stop rather than issue, accept, promote, or publish when issuer/TLS identity or key custody is ambiguous, authentication and authorization are collapsed, validation is permissive, PKCE is missing, credentials appear in evidence, an agent can grant itself authority, recovery is undefined, the build cannot be identified, live behavior is claimed from fixtures, independent review is claimed from internal tests, or public material would expose private authorization data.

Current state: governance proposal and local projection only. No production issuer, live token, security review, operational acceptance, or public authorization service is claimed.

Governing sentence

Fountain Coach may issue its own authority without inventing its own authentication protocol: FountainAuthKit is the Swift-native FCIS-KIT authorization boundary, OAuth/OIDC provides interoperable discovery and grants, MCP and other protected resources consume narrowly resource-bound capability, Reframe preserves human mediation, FountainStore proves the durable authorization and effect lineage, and neither an authenticated identity, a valid token, an agent, nor a protocol connection may silently become the authority it was never granted.