Federated Computing as Code (FCaC): Sovereignty-aware Systems by Design

F E D E R A T E D C O M P U T I N G A S C O D E ( F C A C ) S OV E R E I G N T Y - A W A R E S Y S T E M S B Y D E S I G N Enzo Fenoglio ∗ , Philip T relea ven Dept. Computer Science Univ ersity College London 66-72 Gower Street, London WC1E 5EA, UK {e.fenoglio, p.treleaven}@ucl.ac.uk A B S T R AC T Federated computing (FC) enables collaborativ e computation—such as machine learning, analytics, or data processing—across distributed organizations while keeping raw data local. Built on four architectural pillars: (a) distributed data assets (local control), (b) federated services (in-place computation), (c) standardized APIs (interoperability), and (d) decentralized services (multi-party control), FC is designed to support so vereignty-preserving collaboration. Ho wever , federated systems spanning or ganizational and jurisdictional boundaries lack a portable mechanism for enforcing sov ereignty-critical constraints. They depend on runtime polic y e valuation, shared trust infrastructure, or institutional agreements that introduce coordination overhead and offer limited cryptographic assurance. F ederated Computing as Code (FCaC) is a declarativ e architecture that addresses this gap by compiling authority and dele gation into cryptographically v eriﬁable artifacts rather than relying on online policy interpretation. Boundary admission becomes a local veriﬁcation step rather than a polic y decision service. FCaC separates what we term constitutional gov ernance (permission to ex ecute and delegate across so vereignty boundaries) from procedural gov ernance (context-dependent procedures during e xecution). Admission is validated locally and statelessly with respect to online policy services at ex ecution boundaries using proof-carrying capabilities, while stateful services may still implement post-admission controls such as Attrib ute-Based Access Control (AB AC), risk scoring, quotas, and workﬂow state. FCaC introduces V irtual Federated Platforms (VFPs), which combine Core, Business, and Governance contracts through a cryptographic trust chain: Ke y Y our Organization (KY O), Env elope Capability T okens (ECTs), and proof of possession (PoP). W e sho w the approach in a proof-of-concept setting on a cross-silo federated learning workﬂo w using MNIST as a surrogate workload to v alidate the admission mechanisms and release an open-source proof of con- cept sho wing en velope issuance, cryptographic boundary v eriﬁcation, and en velope-triggered training. Code and artifacts: https://github.com/onzelf/FCaC- MNIST . K eywords Federated Computing as Code · Data Sovereignty · Boundary Admission · Capability-Based Security · Cryptographic Gov ernance 1 Introduction Scientiﬁc research, healthcare inno vation, and industrial optimization increasingly depend on collaborati ve analysis of data distributed across organizational and jurisdictional boundaries. Researchers need to train machine learning models on patient records held by multiple hospitals. Supply chains require analytics across suppliers without exposing proprietary information. Financial services face similar pressures since institutions must detect fraud patterns and perform risk and compliance analytics while preserving customer priv acy and satisfying strict regulatory and audit obligations. These scenarios share a common requirement. They need to enable computation over distributed data ∗ Corresponding author . Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven while respecting sov ereignty , priv acy , and regulatory constraints. Three established architectures are commonly used to support multi-partner collaboration and data-intensiv e analytics: • Shared Database Platforms (Data Lakes): Centralized repositories that aggregate data to enable broad exploration and integration. They are effecti ve for internal analytics, but pri vac y regulations and sov ereignty constraints often preclude their use for sensitiv e datasets, particularly in healthcare and cross-border scenarios [1]. • T rusted Research En vironments (TREs): Secure, controlled digital en vironments where authorized researchers can access and analyze sensitiv e datasets under strict governance. TREs are widely deployed in healthcare but typically operate within a single organizational boundary , limiting their ability to integrate datasets across multiple institutions [2]. • Federated Computing (FC): A decentralized paradigm that enables collaborati ve computation across distrib uted organizations while k eeping raw data local. FC provides orchestration infrastructure connecting data holders and analytics services (and, where applicable, controlled ex ecution environments such as TREs), f acilitating access to data and algorithms without centralization. FC supports multi-partner , multi-discipline, and multi-dataset analytics for preserving data sov ereignty [3]. Federated Computing (FC) has been discussed in the literature primarily as a collection of distributed computing mechanisms enabling collaboration across organizational boundaries, often in the context of federated learning [ 4 ] or decentralized system architectures. The survey by Schwermer et al. [ 5 ] provides a comprehensiv e taxonomy of technical components, extensions, and deployment models in this space. In contrast, the notion of Federated Computing adopted in this work originates from a dif ferent perspectiv e. W e introduced Federated Computing (FC) as a b usiness infrastructure [ 3 ] and later reﬁned it for sovereignty constraints [ 6 ], where the original pillars had been recast as architectural principles. This view deﬁnes a framew ork for composing interoperable federated platforms aligned with organizational constraints, regulatory requirements, and collaboration agreements. The present paper b uilds on that perspectiv e and introduces Federated Computing as Code (FCaC), which operationalizes the four principles by transforming sov ereignty-critical constraints into locally veriﬁable conditions enforced at ex ecution boundaries. FCaC follows the later principle-based reﬁnement of FC [ 6 ], under which the original pillars are treated as architectural principles: 1. Distributed Data Assets: Data remains distributed under the ownership of the originating entity (user , or ganization, or jurisdiction), to preserve pri vac y , enable regulatory compliance, and remo ve central points of failure. 2. Federated Ser vices: Computation moves to data and not the opposite. By bringing algorithms to distributed data sources, federated services enable collaborativ e analytics and model training while maintaining data locality . 3. Standardized APIs: Secure, standardized communication protocols between distrib uted components facilitate interoperability across heterogeneous en vironments, abstracting underlying infrastructure complexities. 4. Decentralized Gov ernance: Multi-party go vernance without a central authority enables veriﬁable interactions through implementation-agnostic mechanisms. It expresses the architectural requirement to distribute policy control and enforcement across independently gov erned participants, and not simply to decentralized infrastructure services. These principles address the technical challenges of distributed computation. Cross-domain deployments, ho wever , introduce a different problem: no central authority can enforce delegation constraints across independent organizations. Participants retain autonomy , and trust cannot be assumed across boundaries. T raditional mechanisms—access control lists, policy engines, and identity providers—were designed for single administrati ve domains and depend on shared trust infrastructure or centralized coordination. Those assumptions break down when parties operate under dif ferent legal re gimes and jurisdictional constraints. This paper outlines the architectural scope of F ederated Computing as Code (FCaC) , a declarati ve modeling frame work for expressing deployment, operation, and coordination of federated infrastructures through composable contracts. The as-code paradigm automates processes that would otherwise be performed manually , improving consistency , repeatability , and version control. The notable examples include Infrastructur e as Code (IaC) [ 7 ], which codiﬁes infrastructure resources, and Policy as Code [ 8 ], which encodes security and compliance rules for automated enforcement. FCaC extends this logic to federated admission and delegation by encoding authority , rights, and delegations as v eriﬁable artifacts instead of procedural agreements. Moreover , FCaC is built around a strict separation between admission (permission to execute and delegate) and post-admission operational control (context-dependent procedures during ex ecution). It integrates deplo yment, execution, and boundary veriﬁcation through Cor e, Business , and Governance contracts (Section 3.2.1), linking how systems are b uilt, operated, and checked across or ganizational boundaries. 2 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven 1.1 Motivation: Governance Bey ond Policy Engines Modern DevSecOps pipelines ha ve achiev ed a high degree of automation in deployment, conﬁguration, and monitoring. Infrastructure as Code, continuous deli very , and automated compliance checks hav e signiﬁcantly reduced operational friction within organizational boundaries. Gov ernance, ho wever , remains largely procedural, mediated through access lists, policy engines, identity brokers, contracts, and audit processes that require continuous interpretation and coordination at runtime [ 9 ]. These mechanisms are effecti ve within a single administrativ e domain, but they do not provide portable, auditable admission across independent authorities. Once data or computation crosses an organizational boundary , admission semantics depend on shared trust assumptions, synchronized policy state, or centralized intermediaries. As a result, enforcement becomes opaque, brittle, and dif ﬁcult to verify after the fact. Policy engines, RB AC matrices, and platform-speciﬁc onboarding workﬂo ws remain v aluable operational tools, but they do not solve the cross-silo problem. In federated settings, authorization semantics must survive heterogeneity in stacks, vendors, and jurisdictions, and must remain explainable under e xternal scrutiny . The issue is therefore not whether a local platform can ev aluate policy correctly , but whether cross-boundary admission can remain portable, veriﬁable, and go vernance-preserving when no shared runtime authority can be assumed. The following failure modes motiv ate FCaC’ s design: • A udit Reconstruction: A regulator , auditor , or internal risk function asks: Why was this operation allowed, under which rule, at that moment, and who had stop authority? If the answer is “check the platform conﬁguration and logs, ” then the decision must be reconstructed after the fact rather than veriﬁed directly . In practice, such reconstruction is brittle: policies ev olve, logs may be incomplete or siloed, and the linkage between a request, the ev aluated rule set, and the resulting boundary decision is often implicit [ 10 ]. FCaC addresses this by turning ex ecution into a proof-carrying act in which the requester presents signed artif acts encoding the admissible operation, scope, and v alidity windo w , and the veriﬁer records a deterministic decision trace bound to those artifacts. The result is an auditable object—what was checked, against which signed constraints, under which trust anchors—rather than an inference from mutable platform state. • Federation Drift: Partners, vendors, and toolchains change. RB A C settings, policies, and onboarding workﬂo ws do not compose across stacks, so admission semantics are reinterpreted at e very boundary [ 11 ]. The result is gradual drift tow ard bilateral exceptions, local translations, and operator-dependent trust. What begins as a federation degrades into a collection of ad hoc integrations. FCaC treats admission semantics as portable by construction: each participant establishes authority locally and issues signed capabilities whose constraints can be veriﬁed else where without reinterpretation. Admission therefore becomes independent of any single vendor policy engine or centralized coordinator, because the enforcement surface consumes standardized, signed artifacts rather than platform-speciﬁc policy state. • Derived Outputs: Training is not the only gov erned act. Metrics, embeddings, predictions, and other derived outputs are also governed assets, each with its own distrib ution risk and regulatory proﬁle. If participation in a consortium is treated as implicitly authorizing access to such outputs, sensiti ve or v aluable information may leak e ven when raw data ne ver mo ves [ 12 , 13 ]. FCaC makes these outputs explicit in the contract model by binding capability constraints to both operations and outputs (e.g., export, query , predict), together with time bounds and delegation limits. Access to deriv ed artifacts must therefore be explicitly minted, presented, and veriﬁed, rather than inherited implicitly from participation in training. These failure modes are structural rather than symptoms of immature tooling or incomplete standardization. T raditional control mechanisms often rely on runtime interpretation of context, intent, and mutable state to decide whether an action should be permitted. In cross-domain settings, that dependence makes admission fragile and difﬁcult to audit. Org anizations therefore resort to auxiliary mechanisms such as manual agreements, audits, legal contracts, and centralized coordinators to bridge the gap. These mechanisms scale poorly , offer limited cryptographic guarantees, and cannot reliably pre vent unauthorized downstream use once data or computation lea ves the originating domain. FCaC starts from the observation that some constraints are mechanically enforceable, while others remain inherently conte xtual. It isolates the subset that can be enforced deterministically and compiles authority , delegation, and capability scope into cryptographically veriﬁable artif acts that accompany each request. Cross-boundary enforcement is therefore carried by the request itself rather than reconstructed from mutable platform state. In this sense, FCaC shifts cross-domain gov ernance from runtime policy interpretation to veriﬁcation of signed constraints ﬁx ed at design time. The rest of the paper is or ganized as follo ws. Section 2 revie ws related work and positions FCaC relati ve to existing access-control and gov ernance technologies. Section 3 describes FCaC’ s architectural foundations. Section 4 presents FCaC’ s central claim through the separation between constitutional and procedural gov ernance. Section 5 introduces the cryptographic trust chain. Section 6 describes FCaC guarantees at the boundary and its threat model. Section 7 3 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven presents typical use cases. Section 8 discusses an illustrativ e example and the accompan ying proof of concept. Section 9 discusses FCaC deployment models. Section 10 concludes. 2 Related W ork and FCaC Positioning FCaC relates to several established bodies of work in authorization, distributed gov ernance, and security architecture. It does not compete with these approaches. It introduces an architectural boundary that constrains and composes them in federated, cross-organizational settings. This section situates FCaC within existing technologies and clariﬁes the assumptions under which they operate. Identity and Policy-Centric A uthorization Systems: A large class of authorization systems relies on identity and policy-centric decision making. Role-Based Access Control (RB A C) [ 14 ]) and Attrib ute-Based Access Control (AB A C) [ 15 , 9 ] formalize authorization as policy ev aluation over identities and attrib utes [ 16 ]. Contemporary implementations often employ centralized, or logically centralized, authorization services that ev aluate policies at runtime. Examples include O Auth 2.0 and OpenID Connect authorization servers [ 17 ], policy engines such as XA CML [ 18 ], or large-scale authorization systems like Google’ s Zanzibar [ 19 ], which provides global consistency by maintaining a shared authorization graph. More recently , Polic y as Code approaches [ 8 ] brought declarativ e speciﬁcation to policy management. Systems such as Open Policy Agent (OP A) [ 20 ] and A WS Cedar [ 21 ] enable policies to be deﬁned as v ersioned code, ev aluated consistently across infrastructure, and inte grated into CI/CD pipelines. These systems advance auditability , testing, and reproducibility within organizational boundaries. FCaC shares the declarativ e intent and targets cross-or ganizational scenarios in which authorization cannot depend on a shared control plane. Identity and access management systems (IAM) [ 22 ] address authorization as a runtime decision problem. Requests are ev aluated against mutable policy state and conte xtual attributes, typically through a logically centralized decision service or a shared authorization substrate. FCaC dif fers in tar geting cross-domain settings where shared policy state or centralized decision services cannot be assumed, shifting boundary admission from online ev aluation to local cryptographic veriﬁcation. Zero T rust Architecture: Zero T rust Architecture (ZT A) [23] is a security architecture that emphasizes continuous veriﬁcation and e xplicit access decisions based on identity , device posture, and contextual signals. In practice, ZT A combines strong enforcement at the access point with a decision and telemetry ecosystem that depends on continuously updated context. FCaC is compatible with ZT A and addresses a different failure mode. ZT A strengthens enterprise enforcement, whereas FCaC makes cross-domain authority and delegation portable through veriﬁable artif acts checked locally at the boundary . ZT A mechanisms remain v aluable inside each domain for operational controls, monitoring, and response. Capability-Based and Proof-Carrying A uthorization: Capability-based security has a long history , from early operating systems to language-based security models [ 24 , 25 ]. Subsequent work explored proof-carrying authorization and delegation using signed statements and tokens [ 26 , 27 ]. Modern token-based mechanisms, including JSON W eb T okens (JWT) [ 28 ] and proof-of-possession extensions such as DPoP [ 29 ], provide practical realizations of these ideas. FCaC adopts this lineage and specializes it for sov ereignty constraints by treating capabilities as derived artif acts from declarati ve gov ernance contracts. It uses proof-carrying requests to support boundary decisions, while reserving context-dependent enforcement for post-admission control within each domain. Gover nance Frameworks and Procedural A pproaches: Distrib uted systems often rely on contractual agreements, audits, compliance workﬂo ws, and or ganizational trust arrangements to manage obligations that cannot be enforced mechanically . In data go vernance and federated learning, many requirements are handled through institutional arrangements, policy-compliance checks, and post-hoc accountability mechanisms [ 30 , 31 ]. These approaches are appropriate when obligations depend on context, interpretation, or organizational judgment. FCaC separates boundary veriﬁcation from the conte xtual controls that remain inside backend systems and or ganizational processes. Existing framew orks therefore remain applicable under FCaC, but they apply after the request has crossed the boundary . Federated and Decentralized A uthorization Systems: Several systems address authorization across or ganizational boundaries through federation or decentralization. SAML [32] and federated identity protocols enable single sign-on across domains but require participants to trust designated identity pro viders. Decentralized identiﬁer (DID) [ 33 ] and veriﬁable credentials pro vide cryptographically veriﬁable identity and claim mechanisms without centralized authorities. Systems such as UCAN [ 34 ] extend this space to ward decentralized authorization through delegable capability chains. FCaC shares the reliance on cryptographic proofs and local v eriﬁcation, but tar gets the broader problem of governed admission of cross-domain computation at ex ecution boundaries rather than authorization alone. 4 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven Blockchain and Distributed Ledger Systems: Blockchain-based systems and smart contracts [ 35 ] provide decen- tralized coordination through consensus and cryptographically v eriﬁed state transitions. These systems reduce single points of failure and enable coordination among mutually distrustful parties through shared ledger state. FCaC does not require participants to maintain consensus ov er a shared global state. Boundary decisions are checked locally from presented artifacts. Blockchain-based systems can still be used within FCaC Core and Business contracts as mechanisms for state management, coordination, and procedural governance [ 36 ]. For e xample, a federated platform can use smart contracts for resource allocation, payment settlement, or audit trails. FCaC’ s constitutional layer constrains who may in voke such mechanisms and under which deleg ations. Architecturally , FCaC uses local proof validation for boundary admission across federated domains, whereas blockchain provides consensus-based state management within execution domains. Dataspace Protocols and Eur opean Standardization: Emerging dataspace initiativ es provide an important adjacent point of comparison. In particular , the Eclipse Dataspace Protocol (DSP) deﬁnes schemas and protocols for interop- erable data sharing, agreement negotiation, and data access across participants in a dataspace [ 37 ]. FCaC focuses on cryptographically veriﬁable boundary control, where DSP focuses on exchange workﬂows and usage-governed interoperability . In fact, authority , dele gation, and possession are compiled into locally checkable artifacts that determine whether ex ecution may proceed. This distinction may become increasingly relev ant as European standardization around data spaces matures, including the work of CEN/CENELEC JTC 25 on data management, data spaces, cloud, and edge [38]. 2.1 Positioning FCaC Relati ve to Existing Access-Control and Gov ernance T echnologies T o clarify where FCaC sits relative to existing approaches, Figure 1 organizes the landscape around three questions that are often conﬂated in practice: (1) Who ar e you? (2) What ar e you allowed to do? and (3) Under which authority ar e you allowed to do it? The ﬁrst concerns identity and claims; the second concerns permissions under an adopted policy or relationship model; the third concerns the prov enance and cross-domain validity of an operation. 1. Identity technologies such as passwords, PKI/mTLS, SAML/OIDC, and veriﬁable-credential schemes establish control of an identiﬁer and, in some cases, presentable attrib utes. They answer who the requester is, but do not by themselves determine which computations or data uses are admissible under a sov ereignty-aware go vernance model. Their trust anchors remain institutional or registry-based, and the meaning of claims is external to the credential format. 2. Mainstream access-control mechanisms—RB AC/AB A C, IAM policies, OAuth scopes, and policy agents such as OP A—address the second question by enumerating permitted actions under a current policy . Relationship- based authorization systems inspired by Zanzibar (e.g., SpiceDB [ 39 ], Keto [ 40 ]) generalize this approach via authorization graphs. These systems are ef fective within a managed ecosystem, b ut their semantics are typically platform-bound since authorization depends on shared policy or relationship state and trusted runtime infrastructure, and audit often reduces to log inspection and reconstruction while we need a portable, cryptographically veriﬁable boundary record. 3. FCaC addresses the third question: under which authority a gi ven operation is permitted across domain boundaries. It does so by expressing authority , delegation, and capability scope through portable cryptographic artif acts that can be veriﬁed locally at the boundary . Figure 1: FCaC Admission: identity establishes who , authorization deﬁnes what , and FCaC binds under which authority via locally veriﬁable artifacts. 3 Architectural F oundation of FCaC 3.1 The Four Ar chitectural Principles FCaC builds on the four architectural principles of Federated Computing as formulated in its sovereignty-oriented reﬁnement [ 6 ]. These principles—distributed data assets, federated services, standardized APIs, and decentralized 5 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven services—deﬁne the conditions under which distributed computation can remain sov ereignty-preserving across organi- zational boundaries. Principles Implication FCaC realization Distributed data assets (local control) Data remains in-domain; only bounded com- putation is permitted to reach it Boundary veriﬁcation enforces capability scope so only permitted computations can ex- ecute against in-domain assets Federated services (compute-to-data) ex ecution occurs inside domains; requests must be safely admitted without central co- ordination The VFP veriﬁer checks requests through lo- cally veriﬁable proof-carrying artifacts; exe- cution then proceeds within Core. Standardized APIs (interoperability) Cross-domain requests must be interpretable uniformly across heterogeneous stacks Gov ernance contracts compile to veriﬁable artifacts (ECTs with proof of possession real- ized through DPoP) whose semantics remain stable across local policy en vironments. Decentralized gov ernance (multi-party enforcement) No single party is trusted to enforce federation-wide constraints; dele gation must be veriﬁable The trust chain KY O → ECT → PoP provides portable delegation evidence; in the present implementation, PoP is realized through DPoP , and the same inputs yield the same de- cision at each site. T able 1: From FC principles to FCaC mechanisms. Each principle becomes an implementation constraint under sov ereignty . FCaC realizes these constraints through boundary veriﬁcation, proof-carrying artifacts, and the VFP trust chain. VFP is V irtual Federated Platform; KYO is K ey Y our Organization; ECT is En velope Capability T oken; DPoP is Demonstrating Proof-of-Possession (Section 5) The pillars were introduced to describe a meta-frame work for e xecutiv e decision-making [ 3 ], whereas the principles recast that frame work as implementation-oriented requirements for practitioners [ 6 ]. T aken together , these principles deﬁne the conditions under which distributed computation can remain so vereignty-preserving across org anizational boundaries. FCaC builds on this principle-based formulation by sho wing how the orchestration layer required by federation can be speciﬁed and implemented in line with Infrastructure as Code (IaC) principles. In this way , FCaC turns architectural principles into deployable mechanisms. It speciﬁes how control and enforcement are distributed across independently gov erned participants, not merely how infrastructure is distrib uted. Cross-boundary constraints are then realized as veriﬁable conditions enforced at e xecution boundaries. 3.2 V irtual Federated Platf orms (VFPs) Federated Computing as Code organizes federated systems through V irtual Federated Platforms (VFPs). A VFP deﬁnes the federated boundary within which infrastructure, services, b usiness relationships, and cross-boundary constraints are speciﬁed declarati vely while remaining operationally independent. It provides a common structure for federation without imposing centralized control or shared runtime state. A VFP spans multiple administrativ e domains and execution en vironments. Its role is to deﬁne where cross-boundary interactions occur and where requests must be checked. It is not a centralized runtime or a shared service. Rather , it links independently operated systems through common contract conditions and locally veriﬁable control at the points where domains interact. The FCaC system architecture (Figure 2) speciﬁes each VFP through three declarative contract classes: Cor e , Business , and Governance . Respectively , these capture local execution, cross-party interaction, and the conditions under which cross-boundary operations may occur . F ederated Services continue to run inside their respecti ve Core en vironments under local operational control. Core and Business components in vok e veriﬁcation against presented artifacts to determine whether a requested operation may proceed. Once that check succeeds, ex ecution continues locally , including any application-speciﬁc controls, compliance checks, or workﬂo w logic required by the participating system. 3.2.1 Core, Business, and Go vernance Contracts The three contract classes introduced above specify complementary aspects of a VFP . T ogether , the y deﬁne how federated infrastructures are instantiated, operated, and constrained across organizational boundaries. 6 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven • Core Contracts deﬁne the operational substrate of the VFP , specifying how services are deployed, conﬁgured, and ex ecuted within local infrastructure en vironments. They include infrastructure deﬁnitions, service topology , ex ecution constraints, and operational integrations. • Business Contracts capture domain-speciﬁc intent and interaction semantics across parties. They encode terms of service, economic exchange, and application-le vel constraints rele vant to cross-or ganizational workﬂows. • Gover nance Contracts specify allo wed cross-boundary operations, authorities, and delegation structure. They compile into veriﬁable cryptographic artifacts used for local veriﬁcation independent of deployment conte xt. T rust anchors are distributed out of band and cached locally . At a high lev el, a VFP can be read as extending a T erraform-style IaC module with business and cross-boundary control semantics. In this way , FCaC links infrastructure automation, service interaction, and cryptographic veriﬁcation within a single federated structure (Section 4). Figure 2: FCaC architecture across Core, Governance, and Business contracts. FCaC binds Core services and Business interactions through proof-carrying artifacts deri ved from declarati ve contracts. At runtime, the boundary check is a veriﬁcation step (artifact validity , possession binding, and capability match), not an online polic y ev aluation service. This yields a shared declarativ e model for infrastructure and policy automation, while keeping w orkﬂow and domain logic inside Core and Business components. 4 Constitutional and Procedural Go vernance A central claim of FCaC is that not all governance constraints belong to the same enforcement layer . Some can be decided mechanically at the point where a request crosses an organizational boundary; others depend on local records, workﬂo w state, temporal context, or institutional judgment and therefore remain inside the executing system. This section makes that distinction explicit. It introduces the separation between constitutional governance , which determines whether cross-boundary ex ecution may begin at all, and pr ocedural governance , which determines ho w an admitted operation is handled thereafter inside local en vironments. This distinction is the basis for the trust-chain mechanisms introduced in Section 5. FCaC is built on a strict separation between two go vernance layers. The ﬁrst is constitutional governance , which deﬁnes the conditions under which an operation may enter the execution domain. The second is procedur al governance , which deﬁnes how an admitted operation is processed within local systems, workﬂo ws, and organizational processes. The terminology is borrowed from institutional la w , but here it is giv en the following computational meaning: 7 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven • Constitutional gover nance encodes rights and delegations as veriﬁable artifacts: who may be admitted, which capabilities exist, and under what authority and dele gation chain they ar e valid . It is enforced at the boundary and is designed to be stateless, deterministic, portable, and independent of local implementation details. • Procedural go vernance cov ers the stateful and context-dependent controls that apply after admission, including workﬂo w execution, rate limiting, scheduling, temporal conditions, compliance checks, and other domain-speciﬁc decisions. It remains local to the executing en vironment and depends on system state, operational context, and organizational process. In operational terms, FCaC conﬁnes deterministic enforcement to the boundary . At the point where a request crosses into a ne w administrativ e domain, the veriﬁer checks the presented artifacts for authority , dele gation, and possession without relying on online policy e valuation or cross-party coordination. Once that check succeeds, execution proceeds inside Core services, where additional controls may still be applied according to local workﬂo w state, compliance obligations, and application-speciﬁc logic. Therefore, the architectural point is not to replace procedural gov ernance, but to separate it cleanly from boundary veriﬁcation that remains portable and mechanically veriﬁable across independently gov erned domains. About the terminology , admission denotes the boundary decision to permit ex ecution on the basis of proof-carrying artifacts, whereas authorization refers to local access-control decisions inside the executing en vironment when describing related work in its o wn terminology . 4.1 Constitutional Gover nance: V eriﬁable Commitments The constitutional layer cov ers the go vernance constraints that can be enforced deterministically at execution boundaries through cryptographically veriﬁable artifacts. It deﬁnes who may act, under which authority , and which operations may occur within a V irtual Federated Platform. Its role is to establish the boundary conditions under which execution may begin. T wo properties follo w from this design. First, admission is deterministic, i.e., the same request, presented with the same artifacts and ev aluated against the same trust anchors, yields the same outcome. Second, admission is portable, i.e., veriﬁcation depends only on material carried with the request and locally a vailable trust anchors, so enforcement can occur at any e xecution site without reliance on shared policy engines or centralized intermediaries. The constitutional layer is intentionally narro w . It covers only those constraints that can be checked deterministically from the request and the presented artifacts. Questions that depend on workﬂow state, application conte xt, or business semantics remain within Core services and are outside the boundary veriﬁer’ s authority . The result is a constituti ve layer: it determines whether execution may proceed, but it does not coordinate workﬂo ws or prescribe how admitted operations must be carried out. Core and Business contracts govern what happens after admission within the bounds already deﬁned and validated. FCaC turns sovereignty-critical enforcement into a boundary property by grounding admission in veriﬁable com- mitments instead of retrospecti ve inferences from logs or audits. Each admitted operation carries a cryptographic justiﬁcation traceable to an issuing authority and an explicit delegation chain. This enables reproducible decisions across independently gov erned domains while preserving local autonomy after admission. 4.2 Procedural Go vernance in Core Boundary enforcement in FCaC is limited to the decision to permit execution. Once a request has been admitted, ex ecution proceeds inside Core services, where controls such as workﬂo ws, scheduling, rate limiting, monitoring, consent handling, lifecycle management, and compliance interpretation remain under local authority . These controls are not secondary to the architecture; they are essential to the correct operation of the participating system. They go vern how an admitted request is actually handled in practice, which internal workﬂow is triggered, which local records are consulted, which compliance obligations must still be checked, and which operational conditions may still cause the request to be rejected or deferred. Their ev aluation may depend on mutable state, temporal conditions, external signals, local policy , or application semantics, and therefore cannot, in general, be reduced to deterministic veriﬁcation based solely on proof-carrying artifacts. For this reason, FCaC does not attempt to standardize or externalize these controls. Its role is narrower , limited to ensuring that sovereignty-critical constraints are enforced ﬁrst at the boundary before execution enters the local en vironment. Procedural gov ernance then determines how an admitted operation is processed inside the system. A Core service (e.g., Federated Learning) may still reject the request on local grounds, apply additional restrictions, or enforce duties that arise only during ex ecution. 8 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven The architectural point is therefore not to replace procedural go vernance, b ut to separate from boundary veriﬁcation cleanly . The constitutional governance determines whether e xecution may begin across org anizational boundaries; the procedural gov ernance determines how e xecution unfolds thereafter within the participating domain. This separation preserves local autonomy , ensuring that cross-domain constraints are enforced through portable, cryptographically veriﬁable artifacts. It also determines what is compiled into capability artifacts and what remains inside backend logic as described in the next section. 4.2.1 Policy tuples FCaC compiles only the subset of declarativ e clauses that can be enforced deterministically at the boundary into a ﬁnite set of capability tuples , i.e., structured predicates over a small, ﬁxed v ocabulary (e.g., resource, action, and scope qualiﬁers) deriv ed from the system policy . An example of the corresponding policy .json artifact is giv en in Section 8.1, Figure 4. Compilation is deterministic and performed at design time; it introduces no new semantics and does not consult runtime conte xt. The tuple compiler e xtracts only the constitutional subset of the policy model; procedural rules, if present, remain with VFP:Core bac kend logic and are not compiled into tuples. The resulting tuples are embedded in the ECT as signed claims that deﬁne what a request may do under which constraints. At veriﬁcation time, the v eriﬁer checks artifact integrity and holder binding, then matches the request ag ainst the signed tuples. Capability tuples. A capability tuple is a structured predicate representing one admissible class of requests under the constitutional subset of the polic y model. In schematic form, we write τ = ( r, a, s, c ) , where r denotes the protected resource, a the admissible action, s the relev ant scope qualiﬁers, and c a ﬁnite set of signed caveats or restrictions (e.g., output class, audience, validity bounds, or deleg ation limits). Intuitively , a tuple states that a holder may request action a ov er resource r within scope s , subject to the additional signed constraints collected in c . ECT minting compiles declarativ e clauses into a ﬁnite set of such tuples, which are then embedded as signed claims and later matched against incoming requests during veriﬁcation. 4.3 Stateless Admission and Deterministic Boundary Decisions This subsection illustrates the distinction introduced abov e through two examples. In FCaC, the boundary veriﬁer decides whether a request may proceed by checking the presented artifacts and locally cached trust anchors. Once that check succeeds, ex ecution continues inside Core services, where local controls, workﬂo w state, and domain-speciﬁc logic still apply . The contrast is therefore not between security and no security , but between what can be decided deterministically at the boundary and what must remain inside the ex ecuting system. Example 1 – Cross-jurisdiction healthcare federation. Consider a setting in which Hospital A permits a clinic to run a federated training job on dataset D under study identiﬁer S . A request may proceed only if it presents a capability artifact that names the dataset and study scope, constrains the permitted operation to training, sets a v alidity window , and is linked through a v eriﬁable delegation chain to a trusted issuer . These checks are decidable at the boundary . By contrast, controls such as consent v alidation for the rele vant cohort, AB AC on internal attrib utes, rate limits, monitoring, and incident response remain inside Core services and are ev aluated using local records and processes. In a V irtual Federated Platform (VFP), this decision is made from veriﬁable artifacts e xpressing authority , delegation [ 41 , 42 ], and proof of possession realized in the present implementation through DPoP [ 29 ]. The veriﬁer checks signature chains, possession bindings, scope constraints, and freshness conditions using only the presented artifacts and local trust anchors. Given the same request and the same inputs, independent veriﬁers reach the same result. Missing or in valid proofs are rejected unconditionally , with no discretionary fallback path. Example 2 – T emporal constraints. The same distinction applies to time. Some temporal rules can be enforced directly from the current request, the current time, and the validity conditions carried by the presented artifacts. Examples include not-before times, expiry times, study windows, and approv ed hours of operation. An issuer may therefore mint a capability that permits training on dataset D for study S only between dates T0 and T1 , and only during approved hours in the issuer’ s jurisdiction. Requests outside that window are rejected deterministically at the boundary . Other temporal rules cannot be decided in this w ay because they depend on e vent history or sequencing. Obligations such as “ after X, Y must occur within 24 hours ” depend on prior events, w orkﬂow progression, and local records. They therefore remain inside Core services, where monitoring, audit, and workﬂo w state are av ailable. 5 The FCaC Cryptographic T rust Chain This section introduces the cryptographic trust chain that makes cross-domain boundary decisions portable across independently gov erned domains. The core idea is to represent sovereignty-critical governance as proof-carrying 9 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven Figure 3: FCaC cryptographic trust chain: K ey Y our Organization (KYO), Env elope Capability T okens (ECTs), and Proof-of- Possession (PoP) artifacts that can be v alidated mechanically at the e xecution boundary . The remainder of the section speciﬁes ho w FCaC carries veriﬁable e vidence of authority , delegation, and possession, and ho w these artifacts compose into a deterministic boundary decision. The trust chain is composed of three elements: (i) Key Y our Organization (KY O) , based on RFC 8705 [ 43 ], to anchor authority to a veriﬁable source; (ii) En velope Capability T okens (ECTs) , based on RFC 7519, RFC 7800, and RFC 7638 [ 28 , 44 , 45 ], to e xpress admissible actions and deleg ation constraints; and (iii) proof of possession (P oP) , realized in the present implementation through DPoP based on RFC 9449 [ 29 ], to bind capability exercise to a concrete act of execution. Individually , these elements are insufﬁcient. T aken together , they form a minimal basis for enforcing boundary veriﬁcation at e xecution time (Figure 3). For completeness in Appendix A we brieﬂy recall the main RFCs employed in the FCaC trust chain. 5.1 Proof of A uthority (KY O – Key Y our Organization) W e use the acronym K e y Y our Or ganization (KYO) 2 to bind the sov ereign cryptographic identity of each participating organization within a V irtual Federated Platform. It answers the question "Who are you?" at the organizational lev el. KY O is grounded in direct cryptographic proof of k ey ownership rather than in institutional identity pro viders or external trust authorities. In the intended deployment model, organizational credentials and authority-sensitiv e signing operations are anchored in a trusted execution en vironment (TEE), creating a protected enclave for ke y material and related operations [ 46 ]. Organizations authenticate through mutual TLS (mTLS) handshakes [ 43 ] that demonstrate control ov er their pri vate keys and associated digital credentials. This process establishes the or ganizational cryptographic root from which subsequent capability artifacts deri ve. In KYO, le gitimacy is not inferred from naming, registration, or institutional endorsement alone, but from the ability to produce veriﬁable cryptographic e vidence. Authority is therefore treated as a property of ke y control since what matters is not only who claims authority , b ut who can prov e control of the corresponding cryptographic material. Once v alidated, the org anization’ s public key , together with minimal non-authoritati ve metadata, is recorded in the federation’ s trust registry . The registry serves only as a veriﬁcation reference, allo wing participants to check the prov enance of issued capabilities against re gistered public keys without further coordination or runtime trust negotiation. V eriﬁers rely on locally cached trust anchors on the request path and therefore do not depend on the registry’ s av ailability at runtime. KY O does not itself grant permissions or authorize ex ecution. Its role is to establish the organizational cryptographic root from which issuer authority for ECT signing and holder-ke y veriﬁcation for request execution are deri ved. Permissions, scopes, and delegation constraints are e xpressed through Env elope Capability T okens (Section 5.2), while request-time ex ercise is later bound through proof of possession (Section 5.3). This keeps the principal purely cryptographic across domain boundaries, i.e., requests are decided on the basis of signed artifacts and registered k eys, not on UI-provided 2 not to be confused with “Know Y our Owner/Ownership” used in ﬁnancial compliance 10 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven usernames or local application identiﬁers. KY O therefore separates the establishment of authority from its later delegation and exercise, providing an auditable organizational root of trust across jurisdictions without requiring a shared identity infrastructure. 5.2 Proof of Capability (ECT – En velope Capability T oken) The En velope Capability T oken (ECT) is the mechanism by which a participating organization e xpresses delegated capability in a portable, v eriﬁable form. It answers the question "What ar e you allowed to do?" . Whereas KYO establishes the or ganizational cryptographic root, the ECT carries the speciﬁc permissions, scopes, and deleg ation limits that may be exercised under that authority . The issuing authority examines an org anization’ s declarative contracts, deriv es a minimal set of capability tuples, and encodes them as cryptographically signed artifacts. Each ECT therefore carries a scoped subset of the issuer’ s rules, expressing what may be done, under which constraints, and on whose delegated authority , without exposing the full speciﬁcation or requiring it at runtime. ECT minting is a deterministic tuple compiler executed at design or issuance time. Declarativ e contracts are mapped to a ﬁnite set of capability tuples that capture admissible operations and constraints, including resource, action, scope, output restrictions (such as aggregation, PII, or contact), and non-functional cav eats such as audience. These tuples are then embedded as signed claims in an En velope Capability T oken. Each ECT is bound to a speciﬁc holder and materialized as a JSON W eb T oken (JWT , RFC 7519 [ 28 ]) carrying signed capability clauses and linked to a holder key via the JWT conﬁrmation ( cnf ) claim (RFC 7800 [ 44 ]), using a JWK thumbprint ( jkt , RFC 7638 [ 45 ]) to support proof of possession. The compilation step introduces no new semantics. It does not interpret intent, resolve context, or consult runtime state. Its role is to freeze capability constraints into a veriﬁable artif act suitable for local veriﬁcation. An ECT deﬁnes the capability boundary within which e xecution may proceed. Once minted, its scope and limits are ﬁxed. They cannot be expanded by the holder , altered by backend services, or reinterpreted at runtime. In this sense, the ECT makes capability scope an in variant of ex ecution rather than a policy decision deferred to the en vironment in which it is presented. At runtime, the veriﬁer is intentionally minimal. It v alidates the ECT signature and claims under the issuer’ s KYO ke y , checks the holder binding, and veriﬁes that the resulting capability covers the requested operation. No policy parsing or external consultation is required; requests that fail these checks are rejected unconditionally . ECTs therefore express scoped permission to attempt ex ecution under explicitly deﬁned constraints. They make cross-domain requests portable and locally veriﬁable without relying on shared policy engines or centralized trust infrastructure. Passing this check, ho wev er, does not guarantee successful e xecution. Once a request has entered Core services, it may still be rejected on the basis of workﬂow conditions, compliance obligations, local state, or other domain-speciﬁc controls. The ECT thus deﬁnes the outer limit of what may be attempted, while leaving the subsequent handling of the request to local systems. Because each ECT is traceable to an issuing authority and a speciﬁc contract version, it provides the basis for reproducible decisions across federated domains and prepares the ground for the ﬁnal element of the trust chain: proof of possession, which binds capability ex ercise to a concrete act of execution. 5.3 PoP – Pr oof of Possession The ﬁnal element of the FCaC trust chain is proof of possession (PoP), which binds an issued capability to a concrete act of ex ecution. It answers the question "Who is using it now?" . KYO establishes the origin of authority . ECTs express admissible actions. PoP demonstrates that the entity presenting the capability for the current request controls the cryptographic key to which that capability is bound, so capability use cannot be detached from e xecution. In the present implementation, this PoP layer is realized using DPoP [ 29 ]. For each request, the presenter constructs a DPoP proof by signing selected elements of the HTTP request with a priv ate key under its control. This proof accompanies the request together with the rele vant En velope Capability T oken. The veriﬁer then v alidates the DPoP proof against the corresponding public key bound to the ECT , conﬁrming that the request is being made by an entity in control of the key associated with that capability in that e xecution context. DPoP establishes cryptographic possession, i.e., proof that the requester controls the key bound to the presented capability at the moment of use. By incorporating request-speciﬁc elements and freshness controls such as nonces, it provides replay resistance and helps pre vent capability reuse outside the intended execution conte xt. It therefore binds capability ex ercise to the concrete request without relying on bearer-token semantics alone. This binding is essential to prevent capabilities from degenerating into transferable bearer tokens. An ECT alone expresses permission to attempt an operation, but without PoP , it could be replayed, proxied, or misused by unauthorized 11 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven parties. PoP closes this gap by transforming capability use from a static claim into a live cryptographic act inseparable from ex ecution. T ogether , ECT and PoP enforce non-transferability by construction. Capabilities may still be deleg ated explicitly through the trust chain, b ut they cannot be ex ercised implicitly by intermediaries or copied across ex ecution contexts without demonstrating control of the bound ke y . Each permitted operation is therefore accompanied by veriﬁable evidence that the requester controls the k ey bound to the capability at the time of ex ecution. 6 Cryptographic Accountability and T rust Containment This section describes what FCaC guarantees at the boundary , how those guarantees are maintained ov er time, and what remains outside its scope. W e characterize the threat model for proof-carrying boundary veriﬁcation, discuss trust continuity through key rotation and re vocation, and summarize the failure modes that remain local or organizational by nature. 6.1 Admission Control Semantics Admission control is implemented as a proof-carrying check o ver two artif acts: (i) an En velope Capability T oken (ECT) and (ii) a request-bound proof of possession, realized in the present implementation through DPoP . The ECT is a signed JWT (RFC 7519) carrying a ﬁnite set of capability tuples and bound to a speciﬁc holder key via the conﬁrmation claim cnf.jkt (RFC 7800, RFC 7638). DPoP binds that same holder ke y to a concrete execution ev ent by signing request-speciﬁc parameters. A request is accepted only if the ECT veriﬁes under the issuer’ s trust anchors, the proof of possession veriﬁes ag ainst the holder binding, and at least one signed capability tuple co vers the requested ex ecution tuple. The result is a deterministic decision procedure whose inputs are e xplicit and whose outcome can be recorded as an auditable decision record. This composition deﬁnes the scope of FCaC guarantees at the boundary . It provides authenticity , possession, and capability coverage without requiring online policy e valuation or centralized enforcement. It does not resolve intent beyond what is encoded in the capability tuples, nor does it capture obligations that depend on off-chain process state. The rest of this section characterizes the threat model for this veriﬁcation rule and the residual failure modes that remain local or or ganizational by nature. 6.2 Cryptographic Accountability Across Domains FCaC makes accountability more directly tied to ex ecution rather than relying solely on retrospecti ve inference from logs, audits, or institutional trust. Every operation that crosses a federated boundary carries veriﬁable evidence, so attribution is established at the moment of execution. This property follows from the FCaC trust chain. Key Y our Organization (KY O) anchors capabilities to a so vereign authority . En velope Capability T okens (ECTs) express delegated capability and scope constraints. Proof of possession binds capability use to a concrete ex ecution event. T ogether , these elements allo w an accepted operation to be attrib uted cryptographically to an issuing authority , a speciﬁc capability , and the party exercising it at execution time. Because this evidence trav els with the request and is veriﬁed locally using cached trust anchors, accountability remains portable across or ganizational and jurisdictional boundaries. Each ex ecution en vironment can also verify under which contract version and delegation chain the request was accepted. Accountability does not imply that backend services are correct or benign. Core services may be buggy , misconﬁgured, or ev en adversarial, but within FCaC successful execution cannot exceed the authority established at the boundary . Operations lacking cryptographic justiﬁcation are rejected regardless of backend intent. This differs from con ventional approaches, in which attribution is inferred indirectly from access logs, identity assertions, or contractual arrangements, and often requires interpretation or institutional arbitration. By grounding accountability in veriﬁable artifacts, FCaC decouples assurance at the boundary from trust in internal operations. Participants need not trust each other’ s internal controls or operational discipline; the y need only trust local veriﬁcation of the presented artifacts, thereby clarifying cross-domain attribution and k eeping delegated authority bounded. 6.3 Threat Model The threat model of FCaC focuses on unauthorized cross-boundary execution rather than on the correctness or availability of backend systems. FCaC does not attempt to prev ent all classes of attacks in distributed systems; instead, it constrains a speciﬁc failure mode: the execution of operations that violate sov ereignty or delegation constraints without valid cryptographic veriﬁcation at the boundary . Under this model, an attack succeeds only if an operation that exceeds the declared capability constraints is executed without presenting valid cryptographic e vidence at the boundary . By construction, FCaC aims to prevent the class of failures in which a sov ereignty-violating operation may cross the boundary unless it has been cryptographically validated under the declared authority and delegation structure. This 12 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven guarantee is independent of backend implementation choices, organizational trust assumptions, or deployment topology . It holds where ver local veriﬁcation is performed ag ainst the same presented artif acts and trust anchors. Therefore, FCaC remains composable with con ventional security controls and operational practices while enforcing a clear structural in variant at the federation boundary . It explicitly excludes several other threat classes from its scope. It does not address unauthorized disclosure or misuse of data after access has been granted, correctness of application logic, denial-of-service attacks, model integrity , or compliance obligations that require conte xtual or temporal interpretation. Such concerns remain the responsibility of backend systems and or ganizational processes. 6.4 Key Rotation, Re vocation, and T rust Continuity FCaC treats lifecycle control as part of trust continuity rather than as part of the core trust-chain construction. In the base design, cryptographic artifacts remain bounded by their declared v alidity windows and by the continued v alidity of the issuer key . A veriﬁer therefore rejects expired artifacts deterministically , while key rotation pre vents ne w capability artifacts from being minted under compromised or superseded ke ys. More immediate withdrawal introduces a different class of mechanism. If a still-valid capability artifact must be in validated before e xpiry , veriﬁers need additional re vocation evidence distrib uted out of band and cached locally . The same applies to delegation links whose v alidity must be withdrawn before their natural expiration. These mechanisms improv e responsiveness, b ut they also introduce operational state into the trust-distribution channel and therefore mov e beyond the minimal stateless design. Three lifecycle cases are rele vant in practice: • Issuer key rotation or r evocation: withdraws the ability to mint new capability artifacts under a compromised or superseded key and changes which trust anchors are accepted during v eriﬁcation. • Capability re vocation: withdraws a speciﬁc artifact before e xpiry , requiring revocation e vidence or , alternativ ely , sufﬁciently short-li ved artif acts. • Delegation r evocation: withdraws a delegation link on which later artifacts depend, again requiring either rev ocation evidence or short-li ved dele gated artifacts. The proof of concept implements bounded validity and key rotation. Immediate artifact revocation and delegation- speciﬁc rev ocation remain future work. 7 Practical Implications and Use Cases FCaC provides a unifying framework for trustworthy collaboration across domains where coordination is typically difﬁcult. It enables rights and obligations to trav el with the computation rather than with the location of the data. 7.1 Federated Resear ch and Healthcare In federated healthcare research, hospitals must collaborate on shared analytics or machine-learning models without violating patient pri v acy or jurisdictional data la ws [ 47 ]. T raditional approaches depend on access lists, VPNs, federated learning coordinators, and other intermediary control mechanisms [ 48 ], all of which require trust in shared operators or infrastructure. In this context, each hospital performs KY O to establish its authority , then authorized issuers mint ECTs that constrain permissible datasets, time ranges, and analytical purposes. Clinicians present proof of possession (e.g., DPoP) for the capabilities assigned to them, and each training or inference request is v eriﬁed locally at the boundary . No raw data lea ves institutional boundaries; only permitted updates (e.g., encrypted gradients) trav erse the network. 7.2 Industrial and Supply-Chain Data Exchange Modern manufacturing and logistics ecosystems require continuous data exchange among suppliers, integrators, and auditors while preserving commercial and regulatory boundaries. FCaC replaces brokered trust with cryptographically enforced sov ereignty . Each participant establishes its authority through KY O, then compiles declarati ve gov ernance rules into ECTs that specify which analytics or data views are permitted. An integrator , for instance, may receiv e an ECT allo wing performance aggregation but not access to ra w telemetry . Every analytic request includes proof of possession (DPoP), sho wing that the requester controls the key bound to that capability for the current request. The boundary veriﬁer at e ach site veriﬁes signatures locally . Admission succeeds only if the proofs align with the trusted keys and declared constraints. The result is a veriﬁable supply-chain fabric where data, computation, and policy coexist under the same cryptographic guarantees. 13 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven 7.3 Financial Services and Regulatory Analytics Financial institutions must collaborate on fraud detection, anti-mone y laundering (AML) monitoring, and risk ana- lytics across subsidiaries and counterparties to preserv e customer conﬁdentiality and meet strict re gulatory and audit obligations. FCaC makes admission portable and locally veriﬁable across independently go verned participants. Each institution establishes its authority through KY O, then mints ECTs that constrain admissible computations, data views, delegation scope, and validity windo ws. A bank, for example, may issue an ECT that allows the computation of aggregated risk indicators or alerts for a deﬁned segment without exposing raw transaction records. Each request includes a DPoP proof-binding capability e xercise for the concrete request. Boundary veriﬁers validate the presented artifacts locally . Admission succeeds only if signatures, bindings, and declared constraints hold. This yields cross- institution analytics with reproducible decisions and clear accountability , without shared policy engines or centralized intermediaries. High-Frequency T rading (HFT): A more latency-critical, yet equally regulation-dri ven, v ariant arises in electronic trading and High-F requency T rading (HFT) [ 49 ]. In this setting, the key question is not only whether a strategy may run, but which v ersion may execute, where it may be deployed, under which hard risk limits, and with what audit e vidence. FCaC separates the ultra-low-latenc y execution path from the boundary-v eriﬁcation path. A strategy can be packaged as a sealed en velope whose identity is ﬁx ed by a hash over code, conﬁguration, and optional model weights. An ECT then binds that identity to an approv ed execution scope, enforceable trading limits, and the evidence streams required for later re view . At each ex ecution site, the veriﬁer checks the sov ereignty en velope and the ECT for user requests. If the request is allowed, it releases short-li ved runtime credentials. This mechanism yields a portable, cryptographically auditable boundary layer for multi-party trading arrangements inv olving buy-side strategies, broker mark et access, and venue connecti vity . The resulting decision record — what ran, wher e, under which limits, and with what e vidence — remains reproducible across parties and defensible in post-incident revie w without requiring a shared policy engine. 8 An Illustrative Case Study This section grounds FCaC in an illustrative cross-sil o deployment that ex ercises the full trust-chain pipeline end to end. For reproducibility and ease of experimentation, we use MNIST as a surrogate workload. Concretely , we treat MNIST images as stand-ins for regulated clinical imaging assets (e.g., PET -CT slices) and use digit classes to emulate gov ernance-relev ant cohorts. Cohort labels ( EVEN_ONLY , ODD_ONLY , ODD_PLUS ) deﬁne surrogate scope partitions in the PoC. They stand in for patient strata, study arms, or jurisdiction-speciﬁc cohorts in a simpliﬁed MNIST -based setting. These labels are encoded in the policy artif act through scope.cohort , propagated into the ECT at minting time, and checked again by the veriﬁer when a request is presented. This setup allows us to demonstrate three properties: (i) cryptographically enforced request validation through ECTs and proof of possession, (ii) rejection of scope escalation when a request is tampered with to target a broader or different cohort than the one authorized, and (iii) separation between request veriﬁcation and additional controls enforced later inside the federated service. W e deliberately keep the ML task simple while preserving the same trust-chain surface that would appear in a production clinical FL deployment: capability issuance, scope binding, boundary veriﬁcation, and guarded service inv ocation. In the prototype, a training request is admitted only if it presents (i) a signed capability artifact that constrains scope, actions, and delegation limits, and (ii) proof of possession bound to the request. Requests that omit these artifacts, present in valid signatures, or exceed declared bounds are rejected deterministically at the boundary . Raw data ne ver leav es its originating organization; only permitted outputs of admitted execution, such as model updates, are exchanged. Detailed implementation and deployment material is a vailable in the FCaC repository on GitHub 3 , including contract examples, the deterministic tuple-to-token compilation pipeline, and deplo yment scripts for the complete end-to-end demonstration. W e provide a description of the PoC interface and observ ed outcomes. W e start from the two critical artif acts that are tested: (i) the sover eignty envelope that is created via multi-party quorum (Bind → approv als → Activ e en velope), and (ii) the capability admission decisions that is created with the Env elope Capability T oken (ECT) bound to a DPoP proof (holder ke y binding) and ev aluated against a policy .json artifact. The PoC objective is to demonstrate v eriﬁable compilation targets (polic y artifacts, en velopes, attestable decisions) rather than optimize performance or implement a full production grade substrate. 3 https://github.com/onzelf/FCaC- MNIST 14 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven 8.1 PoC endpoints and trust boundaries This section describes the e xternal endpoints exposed by the PoC and the points where trust is enforced. W e identify where TLS is terminated, which identities are permitted on each route (hub versus or ganization administrators), and which attributes are treated as authoritative by the application (e.g., the forwarded mTLS subject DN). W e then enumerate the minimal endpoint surface required to realize the two FCaC primitiv es used in this case study: (i) sov ereignty env elope formation under quorum approv als, and (ii) proof-carrying requests veriﬁed locally . The goal is not to catalogue implementation details, b ut to mak e the enforcement perimeter explicit and reproducible for independent re-ex ecution. mTLS edge (nginx) and identity forwarding. The PoC places nginx at the trust boundary and terminates TLS there. Mutual TLS (mTLS) is used to authenticate calling parties before any request reaches the application. The veriﬁer endpoint is authenticated with a PKIX X.509 v3 certiﬁcate whose service identity is carried in the subjectAltName (SAN) extension (e.g., dNSName=verifier.local ), so hostname veriﬁcation follo ws current PKI practice and not legac y CN-only matching [ 50 , 51 ]. Once the client certiﬁcate has been validated, nginx applies route-lev el identity constraints (for example, distinguishing Hub from Hospital-admin certiﬁcates) and forw ards only the already veriﬁed identity attributes to the application. In this way , the application relies on identity facts established at the mTLS edge. En velope f ormation endpoints. The env elope creation ﬂow uses the follo wing endpoints behind nginx: • POST /beta/bind/init (hub-only) • GET /verify-start (admin-only: Hospital A + Hospital B) • GET /session/claim?code= (hub-only) • POST /beta/bind/approve (hub-only; second appro val reaches quorum) Operational policy artifact: The PoC exposes admission constraints into a versioned policy artif act ( policy .json , v1.1) that provides the shared reference v ocabulary for both capability issuance and boundary veriﬁcation (Figure 4). In practice, policy .json deﬁnes the admissible operations, proﬁles, caveats, and other go vernance-relev ant ﬁelds from which ECT claims are deriv ed at minting time. The same artifact is then reused by the veriﬁer at runtime to project an incoming request to a canonical tuple and to check whether that tuple falls within the signed bounds carried by the presented ECT and proof of possession. This arrangement keeps the semantics stable across issuance and veriﬁcation, because issuer and veriﬁer rely on the same declarative vocab ulary . The artifact enumerates admissible operations (ops) (e.g., train_petct_A, pr edict_petct_even_only , export_model_par ams ) and deﬁnes named capability proﬁles ( cap_pr oﬁles ) that constrain which operations and scopes may be requested under a token (e.g., capset:trainer_A, capset:pr edictor_even , capset:e gr ess_safe ). A default proﬁle set ( cap_pr oﬁles_default ) speciﬁes the baseline granted proﬁles for a role when minting is not parameterized. The cav eats block binds tokens to an intended service boundary (e.g., "audience": "svc:ﬂ-gateway:eu" ) and may include explicit prohibitions. Finally , meta provides traceability ( policy_id , manifest_id ) and documentary notes on constraints handled outside the ECT (e.g., deplo yment routing or upstream quality gates). In T est#2 and T est#3 , the veriﬁer uses policy.json as the reference v ocabulary (ops, proﬁles, cav eats) to project each incoming request to a canonical tuple, and then decides ALLOW/DENY by checking that tuple against the signed bounds carried in (ECT + DPoP). Figure 4: Minimal illustrativ e fragment of a policy .json ﬁle. The example sho ws the main policy elements used by FCaC—operation set, capability proﬁles, default capability assignment, cav eats, and policy metadata—while omitting the additional ﬁelds and detail present in the full policy used in the proof of concept. 15 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven 8.2 Evidence: acceptance tests W e present the PoC through three acceptance tests: T est#1 shows ho w an en velope becomes activ e after the multi-party quorum is satisﬁed under mTLS-constrained identities; T est#2 shows deterministic ALLOW/DENY decisions using signed artifacts (ECT + DPoP) together with the referenced policy artif act; T est#3 is for verify the gov erned MNIST prediction. For each test, we summarize the required inputs, the observable outputs, and the expected failure modes so that the reader can validate the trust chain without follo wing implementation details line by line. T est#1 — Env elope creation (quorum): Run T est1A_createEn velope.sh, which: 1. Initializes a bind with two participants and quorum k=2 , n=2 . 2. Prompts the operator to enter the two 6-digit codes displayed by two admin devices, posting /v erify-start. 3. Claims sessions via the hub credential (/session/claim) and submits approv als; quorum completion yields an en velope_id. Successful completion prints: Env elope created: and suggests a post-env elope integration test hook ( ./Test1B_postEnvelope.sh $ENVELOPE_ID ). T est#2 — T rust chain admission: ECT + DP oP ( /mint_ect , /admission/check ). Run the trust-chain script harness ( Test2A_run_probe_eddsa_nginx.sh ), which: 1. Generates a holder key pair (member ke y material). 2. Mints an ECT via /mint_ect under organization-admin mTLS, granting selected capability pro- ﬁles (by reference to cap_profiles in policy.json ; in the script: capset:trainer_A and capset:data_scientist ). 3. Generates a DPoP proof (EdDSA) bound to the holder key and request parameters (method, HTU, nonce, JTI). 4. Executes admission probes against /admission/check that must ALLOW and DENY deterministically . The ALLOW probe uses a clinical-style tuple v ocabulary (e.g., resource=TUMOR_MEASUREMENTS , action=read , agg=aggregated , pii=false , contact=false ). The DENY probes cov er (i) wrong purpose (e.g., resource=PET-CT , action=train , purpose=model_prediction ), (ii) wrong cohort (e.g., cohort=B when only A is permitted), and (iii) holder -binding mismatch by presenting the ECT with a DPoP generated under a different k eypair (intruder). The test is considered successful only if the veriﬁer beha ves deterministically under repeated e valuation of the same inputs. Concretely , when presented with the same request tuple and the same signed artifacts, it must always return the same ALLOW or DENY outcome. It must also fail closed, i.e., if a required artifact is missing, if a signature is inv alid, or if proof of possession is inconsistent with the holder binding encoded in the ECT , the result must be DENY without fallback or discretionary interpretation. This test is limited to the minting and veriﬁcation path. The clinical attributes included in the request are not used to drive a real prediction workload; they are treated only as tuple ﬁelds against which the veriﬁer matches the signed capability constraints. The purpose of the test is therefore not to measure model behavior , but to sho w that capability issuance and local veriﬁcation produce stable, reproducible decisions from the same declared inputs. T est#3 — Governed MNIST prediction (clinical surrogate). The prediction test demonstrates the operational path Hub → /admission/check → flower-server:/predict_image . MNIST digits serve as a stand-in for clinical imaging resources (e.g., PET -CT), and cohorts ( EVEN_ONLY , ODD_ONLY , ODD_PLUS ) act as regulated “patient groups/study strata” to demonstrate scope enforcement. An issuer mints an ECT for a member with a declared cohort, and the user submits a prediction request ( Test3A_run_probe_mnist.sh ). If admission is denied (e.g., due to a cohort mismatch or a capability violation), no prediction ex ecutes. If admitted, the prediction service additionally enforces cohort-scoped label disclosure by masking disallowed classes at inference time ( Test3B_run_predict_via.sh ). An E2E CLI regression check ( Test3C_e2e.sh ) completes the demonstration. E2E UI demonstrator (admin mint → user gover ned predict). In addition to the CLI tests, the PoC provides a minimal web UI at http://127.0.0.1:8082/ that follows the same governed ex ecution path end-to-end. The UI follo ws the two-step protocol: (i) Select the Admin Tab to let an or ganization-scoped issuer (e.g., issuer-hospitala / issuer-hospitalb ) mint an ECT for the selected member and cohort. In turn, it will call the veriﬁer /mint_ect ; (ii) Select the User tab to let the user submit { who , envelope_id , cohort , digit } along with the minted ECT (and DPoP) to the boundary . The hub then performs /admission/check and, only on ALLOW=true , forwards internally 16 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven to flower-server:/predict_image ; denials return a structured reason (e.g., capability/cohort violation) and no ex ecution is performed. The UI also makes operational readiness explicit if the referenced envelope_id has no persisted model under /vault//model.pth , prediction returns model_not_ready . This UI layer is intentionally thin. It demonstrates that FCaC’ s boundary guarantees remain unchanged when driven by a human-facing interface, preserving separation of duties (issuers mint, hub admits/dispatches, backend stays internal-only). Current P oC limitations • L1. En velope identiﬁer not token-bound: The envelope_id is used by the service as a routing selector to load persisted en velope or model state, b ut it is not currently part of the minting or veriﬁcation tuple. • L2. Set-scoped capabilities: In the current implementation, capabilities are set-scoped : an issued ECT grants the right to in voke a class of operations over an y env elope that is Active at veriﬁcation time, where Active is deﬁned by an administrator-controlled v alidity window [nbf, exp] . • L3. Activity check rather than exact en velope match: V eriﬁcation enforces proof v alidity (ECT chain and DPoP binding) and checks that the requested envelope_id is activ e at the current time, instead of requiring an exact identiﬁer match embedded in the token. • L4. En velope-speciﬁc capabilities not yet e valuated: Binding envelope_id into the minting and v eriﬁcation tuple is straightforward and would yield en velope-speciﬁc capabilities, authorizing exactly one env elope or a bounded set. Howe ver , we ha ve not yet ev aluated issuance policies, lifecycle semantics, or benchmarks under this more granular model. This reﬁnement would also simplify administrati ve reallocation: relocating a member would become a token-issuance update (minting a new en velope-scoped ECT and letting the old one expire or be rev oked), rather than managing implicit access over the entire activ e set. This would reduce cross-env elope privile ge and accidental operator drift. • L5. Cryptographic r oles only partially separated in the PoC: The conceptual split between org anization root (KY O), issuer authority for ECT signing, and holder keys for proof of possession is clearer in the architecture than in the present prototype. The PoC exercises the trust chain end to end, b ut it does not yet fully model richer issuer and holder role separation as required in more mature multi-party deployments. • L6. K ey management is simulated rather than hard ware-backed: The prototype simulates vault-backed storage for signing material on disk. Production deployments would use organization-controlled hardware-backed key management or enclav e-backed signing services to protect issuer keys and holder credentials more strongly . • L7. Immediate revocation is not implemented: The PoC supports bounded validity and ke y rotation, but not immediate re vocation of a still-v alid ECT or delegation link through out-of-band re vocation e vidence cached by veriﬁers. • L8. Scope of evidence is demonstrativ e rather than production-complete: The PoC demonstrates deterministic veriﬁcation, capability scoping, and end-to-end trust-chain behavior , b ut it does not yet ev aluate larger-scale operational concerns such as concurrent multi-env elope issuance, richer delegation topologies, or production-grade performance under sustained multi-party load. 9 Deployment Models FCaC can be deployed in three principal regimes presented in Figure 5 that summarize under which conditions they are instantiated. In a single cohesi ve federation, shared control planes, aligned policy state, and institutional coordination may be sufﬁcient t o govern ex ecution. FCaC is well suited when the cohesion assumptions fail. T ypical trigger points include cross-jurisdiction participation, rotating partners, asymmetric trust, or the inability to rely on shared policy state and intermediaries. In such settings, local control alone does not yield portable admission semantics. • Level 0 : con ventional FC deplo yments implement FC principles through shared control planes. Identity systems and policy e valuation decide whether requests may proceed, and enforcement depends on shared operational state and intermediaries. This regime supports rapid deplo yment in a single cohesiv e federation but does not provide portable semantics across jurisdictions. • Lev el 1 : hybrid federations introduce proof-carrying artif acts but still couple lifecycle decisions, such as re vocation and delegation updates, to shared services. This improves portability but retains dependence on those services for lifecycle changes. • Level 2 : FCaC validates presented proof-carrying artifacts at execution boundaries using cached trust anchors. Control after boundary veriﬁcation remains local and is administered independently within each domain. 17 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven Figure 5: Deployment mode of federated gov ernance regimes (FC → Hybrid → FCaC). Stateful-only federations form a limiting case (a degenerate FCaC) in which admission is mediated by stateful control planes. FCaC targets re gimes where admission must remain portable across domains through locally veriﬁable artifacts. FCaC complements e xisting identity systems, policy engines, and established control frame works. In cohesi ve federations with a strong coordinating operator , FC principles can be realized through shared control planes, identity infrastructure, and local workﬂo w enforcement. FCaC targets the stricter re gime in which such shared policy state or intermediaries cannot be assumed. In that setting, cross-domain execution must be determined through portable, locally veriﬁable artifacts rather than through runtime dependence on a common control plane. 10 Conclusion and Future W ork This paper introduced Federated Computing as Code (FCaC), a declarative architectural discipline for enforcing sov ereignty-critical constraints in federated systems through cryptographically veriﬁable artifacts. By structuring a federation as a V irtual Federated Platform (VFP) composed of Core, Business, and Governance contracts, FCaC makes permission to ex ecute and delegate locally checkable at organizational boundaries, while preserving operational autonomy inside each participating domain. Boundary decisions are enforced through v alidation of veriﬁable artifacts rather than through online policy interpretation or centralized trust infrastructure. A central contribution is the precise localization of enforcement. FCaC enforces sovereignty-critical constraints deterministically at ex ecution boundaries through veriﬁcation of proof-carrying artifacts. Controls that depend on context, local state, or workﬂow progression—such as AB A C, quotas, monitoring, and incident response—remain inside Core en vironments after the boundary check. This separation yields reproducible decisions at organizational and jurisdictional boundaries without requiring shared policy engines or institutional intermediaries. FCaC does not attempt to mechanize obligations that depend on mutable global state, discretionary interpretation, or ex post judgment. It constrains ex ecution only where requirements can be reduced to mechanically veriﬁable conditions 18 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven enforced at the boundary; everything else remains with backend systems and or ganizational processes. This separation distinguishes FCaC from policy-centric and identity-centric approaches that attempt to subsume boundary decisions and operational control into a single enforcement plane. Sev eral directions for future work follow naturally . First, extending en velope creation to quorum-based or multi- authority regimes w ould support federations in which authority is jointly deﬁned and not unilaterally issued. Second, richer dele gation structures and lifecycle semantics should be explored to formalize and e valuate rev ocation mechanisms beyond the base lifecycle support already described (Section 6.4), and to explore temporal attenuation and bounded delegation. Third, a formal account of the compilation process from declarative contracts to v eriﬁable artifacts would strengthen the architecture’ s theoretical grounding. Finally , broader empirical v alidation through additional proof-of- concept deployments, including large-scale federated learning and cross-sector data exchange, is needed to assess applicability and operational trade-offs. FCaC delineates an architectural space in which sov ereignty-critical boundary decisions become a veriﬁable property of ex ecution. It provides a design discipline for federated systems that require portable, locally veriﬁable artifacts across independently gov erned domains. References [1] Rihan Hai, Christos K outras, Christoph Quix, and Matthias Jarke. Data Lakes: A Surve y of Functions and System. IEEE T ransactions on Knowledge and Data Engineering , 35(12):12571–12590, 2023. doi:10.1109/TKDE. 2023.3270101 . [2] Sanaz Kavianpour , James Sutherland, Esma Mansouri-Benssassi, Natalie Coull, and Emily Jefferson. Next- Generation Capabilities in T rusted Research En vironments: Intervie w Study. Journal of Medical Internet Resear ch , 24(9):e33720, September 2022. doi:10.2196/33720 . [3] Enzo Fenoglio and Philip T releav en. Federated computing: A data-dri ven b usiness infrastructure. SSRN Electr onic Journal , May 2025. doi:10.2139/ssrn.5218039 . [4] Qiang Y ang, Y ang Liu, T ianjian Chen, and Y ongxin T ong. Federated machine learning: Concept and applications. A CM T rans. Intell. Syst. T echnol. , 10(2), January 2019. doi:10.1145/3298981 . [5] Robert Schwermer , Rudolf Mayer , and Hans-Arno Jacobsen. Federated computing – surv ey on building blocks, extensions and systems. arXiv pr eprint arXiv:2404.02779 , 2024. [6] Enzo Fenoglio and Philip Trelea ven. Federated computing: information integration under sovereignty constraints. Royal Society Open Science , 13(2), February 2026. doi:10.1098/rsos.251318 . [7] HashiCorp Dev eloper . T erraform Infrastructure as Code. HashiCorp, San F rancisco, CA, USA , 2023. URL: https://developer.hashicorp.com/terraform . [8] Pa vel Chupriko v , Patrick Eugster , and Shamiek Mangipudi. Security Policy as Code . IEEE Security & Privacy , 23(02):23–31, March 2025. doi:10.1109/MSEC.2025.3535803 . [9] V incent Hu, David Ferraiolo, D. Kuhn, A. Schnitzer , Knox Sandlin, R. Miller, and Karen Scarfone. Guide to attribute based access control (ABA C) deﬁnition and considerations. National Institute of Standards and T echnology Special Publication , pages 162–800, 01 2014. [10] Carlos Cotrini, Thilo W eghorn, and David Basin. Mining abac rules from sparse logs. In 2018 IEEE Eur opean Symposium on Security and Privacy (Eur oS&P) , pages 31–46, 2018. doi:10.1109/EuroSP.2018.00011 . [11] Nirojan Selvanathan, Dileepa Jayak ody , and V ioleta Damjanovic-Behrendt. Federated identity management and interoperability for heterogeneous cloud platform ecosystems. In Pr oceedings of the 14th International Confer ence on A vailability , Reliability and Security (ARES 2019) , 2019. doi:10.1145/3339252.3341492 . [12] Reza Shokri, Marco Stronati, Congzheng Song, and V italy Shmatikov . Membership inference attacks against machine learning models. In 2017 IEEE Symposium on Security and Privacy (SP) , pages 3–18, 2017. doi: 10.1109/SP.2017.41 . [13] Matt Fredrikson, Somesh Jha, and Thomas Ristenpart. Model in version attacks that exploit conﬁdence infor- mation and basic countermeasures. In Pr oceedings of the 22nd ACM SIGSA C Confer ence on Computer and Communications Security (CCS 2015) , pages 1322–1333, 2015. doi:10.1145/2810103.2813677 . [14] Ravi S. Sandhu, Edward J. Coyne, Hal L. Feinstein, and Charles E. Y ouman. Role-Based Access Control Models. Computer , 29(2):38–47, February 1996. doi:10.1109/2.485845 . 19 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven [15] Dilawar Singh, Shweta Sinha, and V ikas Thada. Re view of Attrib ute Based Access Control (ABA C) Models for Cloud Computing. In 2021 International Confer ence on Computational P erformance Evaluation (ComPE) , pages 710–715, 2021. doi:10.1109/ComPE53109.2021.9752139 . [16] P . M Jyosthna, Anirudh V arma Mandapati, Matam Surya T eja, Sachin Kumar Ray , and B.Y ashwanth Sai Kumar . Enhancing Security and Flexibility with Combined RB A C and AB A C Access Control Models. In 2024 10th International Confer ence on Communication and Signal Pr ocessing (ICCSP) , pages 576–581, 2024. doi: 10.1109/ICCSP60870.2024.10543482 . [17] Dick Hardt. The O Auth 2.0 Authorization Framew ork. RFC 6749, October 2012. doi:10.17487/RFC6749 . [18] O ASIS. eXtensible Access Control Markup Language (XA CML) V ersion 3.0. T echnical report, OASIS Stan- dard, 2013. O ASIS Standard, January 2013. URL: http://docs.oasis- open.org/xacml/3.0/xacml- 3. 0- core- spec- os- en.html . [19] Ruoming Pang, Ramón Cáceres, Mike Burro ws, Zhifeng Chen, Pratik Dav e, Nathan Germer , Alexander Golynski, Ke vin Graney , Nina Kang, Lea Kissner , Jef frey L. K orn, Abhishek Parmar , Christina D. Richards, and Mengzhi W ang. Zanzibar: Google’ s consistent, global authorization system. In Pr oceedings of the 2019 USENIX Confer ence on Usenix Annual T echnical Confer ence , USENIX A TC ’19, page 33–46, USA, 2019. USENIX Association. [20] Open Policy Agent (OP A) Community. Open Policy Agent Documentation. https://openpolicyagent.org/ docs , 2025. Accessed 2025-12-26. [21] Joseph W . Cutler , Craig Disselkoen, Aaron Eline, Shaobo He, Kyle Headley , Michael Hicks, Kesha Hietala, Eleftherios Ioannidis, John Kastner, Anwar Mamat, Darin McAdams, Matt McCutchen, Neha Rungta, Emina T orlak, and Andrew M. W ells. Cedar: A Ne w Language for Expressive, F ast, Safe, and Analyzable Authorization (Extended V ersion). arXiv , 2024. URL: , . [22] Anuja Sharma, Sarita Sharma, and Meenu Dav e. Identity and Access Management- a comprehensi ve study. In 2015 International Confer ence on Gr een Computing and Internet of Things (ICGCIoT) , pages 1481–1485, 2015. doi:10.1109/ICGCIoT.2015.7380701 . [23] Scott Rose, Oliv er Borchert, Stu Mitchell, and Sean Connelly . Zero T rust Architecture. NIST Special Publication 800-207, National Institute of Standards and T echnology , August 2020. doi:10.6028/NIST.SP.800- 207 . [24] Jack B. Dennis and Earl C. V an Horn. Programming semantics for multiprogrammed computations. Commun. A CM , 9(3):143–155, March 1966. doi:10.1145/365230.365252 . [25] Mark S Miller , Ka-Ping Y ee, and Jonathan Shapiro. Capability myths demolished. T echnical Report SRL2003- 02, Johns Hopkins University Systems Resear ch Laboratory , 2003. URL: http://www.erights.org/elib/ capability/duals/myths.html . [26] Andrew W . Appel and Edward W . Felten. Proof-carrying authentication. In Pr oceedings of the 6th ACM Confer ence on Computer and Communications Security , CCS ’99, page 52–62, New Y ork, NY , USA, 1999. Association for Computing Machinery . doi:10.1145/319709.319718 . [27] Butler Lampson, Martín Abadi, Michael Burro ws, and Edward W obber . Authentication in distributed systems: theory and practice. ACM T rans. Comput. Syst. , 10(4):265–310, November 1992. doi:10.1145/138873. 138874 . [28] Michael B. Jones, John Bradley , and Nat Sakimura. JSON W eb T oken (JWT). RFC 7519, May 2015. doi: 10.17487/RFC7519 . [29] Daniel Fett, Brian Campbell, John Bradley , T orsten Lodderstedt, Michael B. Jones, and Da vid W aite. O Auth 2.0 Demonstrating Proof of Possession (DPoP). RFC 9449, September 2023. doi:10.17487/RFC9449 . [30] Nicola Rieke, Jonny Hancox, W enqi Li, Fausto Milletà, Holger R Roth, Shadi Albarqouni, Spyridon Bakas, Mathieu N Galtier, Bennett A Landman, Klaus Maier-Hein, et al. The future of digital health with federated learning. NPJ digital medicine , 3(1):119, 2020. [31] Peter Kairouz, H Brendan McMahan, Brendan A vent, Aurélien Bellet, Mehdi Bennis, Arjun Nitin Bhagoji, Kallista Bonawitz, Zachary Charles, Graham Cormode, Rachel Cummings, et al. Advances and open problems in federated learning. F oundations and T rends in Mac hine Learning , 14(1–2):1–210, 2021. [32] Scott Cantor , John Kemp, Rob Philpott, and Eve Maler . Assertions and protocols for the OASIS security assertion markup language (SAML) V2.0. T echnical report, O ASIS Standard, 2005. O ASIS Standard, March 2005. URL: https://docs.oasis- open.org/security/saml/Post2.0/sstc- saml- tech- overview- 2.0.html . [33] Manu Sporny , Dav e Longley , Markus Sabadello, Drummond Reed, Orie Steele, and Christopher Allen. Decentral- ized Identiﬁers (DIDs) v1.0. W3C Recommendation , Jul 2022. URL: https://www.w3.org/TR/did- core/ . 20 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven [34] Brooklyn Zelenka, Blaine Brock, Irakli Kurniaw an, Sergey Krych, Quinn Shea, and Hugo Long. User Controlled Authorization Network (UCAN) Speciﬁcation v0.10.0. https://github.com/ucan- wg/spec , 2022. Accessed: 2024. [35] V italik Buterin. A next-generation smart contract and decentralized application platform. Ether eum whitepaper , 2014. URL: https://ethereum.org/en/whitepaper/ . [36] Reza Soltani, Marzia Zaman, Rohit Joshi, and Sriniv as Sampalli. Distributed Ledger T echnologies and Their Applications: A Re view. Applied Sciences , 12(15), 2022. doi:10.3390/app12157898 . [37] Eclipse Foundation. Eclipse Dataspace Protocol. https://projects.eclipse.org/projects/technology. dataspace- protocol- base , 2025. Project page, latest release 1.0.0; accessed 2026-03-11. [38] International Data Spaces Association. European standardization request for data spaces is no w ofﬁcial. https://internationaldataspaces.org/ european- standardization- request- for- data- spaces- is- now- official/ , August 2025. Ac- cessed 2026-03-11. [39] SpiceDB: Open Source Authorization Database. https://authzed.com/ , 2023. [40] Ory Keto Authorization Server. https://www.ory.sh/keto/ , 2023. [41] T atu Ylonen, Brian Thomas, Butler Lampson, Carl Ellison, Ronald L. Rivest, and W illiam S. Frantz. SPKI Certiﬁcate Theory. RFC 2693, September 1999. doi:10.17487/RFC2693 . [42] Carl Ellison. SPKI Requirements. RFC 2692, September 1999. doi:10.17487/RFC2692 . [43] Brian Campbell, John Bradley , Nat Sakimura, and T orsten Lodderstedt. O Auth 2.0 Mutual-TLS Client Authenti- cation and Certiﬁcate-Bound Access T okens. RFC 8705, February 2020. doi:10.17487/RFC8705 . [44] Michael B. Jones, John Bradley , and Hannes Tschofenig. Proof-of-Possession Ke y Semantics for JSON W eb T okens (JWTs). RFC 7800, April 2016. doi:10.17487/RFC7800 . [45] Michael B. Jones and Nat Sakimura. JSON W eb Key (JWK) Thumbprint. RFC 7638, September 2015. doi: 10.17487/RFC7638 . [46] Osama Hosam and F an BinY uan. A Comprehensi ve Analysis of T rusted Execution En vironments. In 2022 8th International Confer ence on Information T echnolo gy T rends (ITT) , pages 61–66, 2022. doi:10.1109/ITT56123. 2022.9863962 . [47] Farah Elkourdi, Chenhao W ei, LU Xiao, Zhongyuan YU, and Onur Asan. Exploring Current Practices and Challenges of HIP AA Compliance in Software Engineering: Scoping Revie w. IEEE Open Journal of Systems Engineering , 2:94–104, 2024. doi:10.1109/OJSE.2024.3392691 . [48] T ian Li, Anit Kumar Sahu, Ameet T alwalkar , and V irginia Smith. Federated Learning: Challenges, Methods, and Future Directions. IEEE Signal Pr ocessing Magazine , 37(3):50–60, 2020. doi:10.1109/MSP.2020.2975749 . [49] Johannes Breck enfelder . Competition among high-frequency traders, and mark et quality . SSRN Electr onic Journal , 2019. doi:10.2139/ssrn.3402867 . [50] Peter Saint-Andre and Rich Salz. Service Identity in TLS. RFC 9525, November 2023. doi:10.17487/RFC9525 . [51] Sharon Boeyen, Stef an Santesson, Tim Polk, Russ Housley , Stephen Farrell, and David Cooper . Internet X.509 Public Ke y Infrastructure Certiﬁcate and Certiﬁcate Re vocation List (CRL) Proﬁle. RFC 5280, May 2008. doi:10.17487/RFC5280 . 21 Federated Computing as Code (FCaC) E. Fenoglio and P . T releaven A RFCs used with FCaC RFC 8705 (O A uth 2.0 Mutual-TLS Client A uthentication and Certiﬁcate-Bound Access T okens) [ 43 ]: Estab- lishes org anizational root of trust through X.509 certiﬁcates; binds access tokens to client TLS certiﬁcates, creating a veriﬁable chain back to a certiﬁcate authority; anchors identity to org anizationally veriﬁable credentials; enables K ey Y our Organization (KY O) pattern for cross-jurisdictional trust. RFC 7519 (JSON W eb T oken – JWT) [ 28 ]: Deﬁnes a compact, URL-safe token format for representing claims as a signed or encrypted JSON object. A JWT consists of three parts: a header, a payload of claims, and a signature or integrity protection. In FCaC, JWT provides the basic container format used to carry capability claims. Howe ver , JWT does not guarantee proof of possession. If used as a bearer token, authorization depends only on presentation of the token instead of on cryptographic demonstration of ke y ownership. RFC 7800 (Proof-of-P ossession K ey Semantics f or JWTs)1[ 44 ]: Transforms bearer tokens into proof-of-possession tokens via the cnf (conﬁrmation) claim. Binds JWTs to cryptographic keys held by the presenter . Enables veriﬁcation that the token presenter controls the associated priv ate key . Critical for prev enting token theft and replay attacks in capability-based systems. RFC 7638 (JSON W eb K ey Thumbprint) [ 45 ]: Pro vides a deterministic, canonical method for generating stable cryptographic key identiﬁers. Deﬁnes hash-based thumbprints of JWKs for compact key references in cnf.jkt ﬁelds. Ensures interoperability through standardized computation. Essential for delegation chains and key references in distributed systems where embedding full k eys is impractical. RFC 9449 (OA uth 2.0 Demonstrating Proof of Possession - DP oP) [ 29 ]: Binds token usage to speciﬁc HTTP requests at ex ecution time. Requires fresh, request-speciﬁc JWT proofs signed with the bound pri vate k ey . Includes HTTP method, URL, and timestamp to prev ent replay attacks. Provides moment-of-ex ecution veriﬁcation that bridges abstract capabilities (what you can do) to concrete actions (what you’ re doing no w). 22

Federated Computing as Code (FCaC): Sovereignty-aware Systems by Design

Original Paper

Comments & Academic Discussion

Leave a Comment

Original Paper

Related Papers

Comments & Academic Discussion

Leave a Comment