Federating Trust Perimeters: Extending Industry IAM with DLT-Based Governance

5G and Beyond

• Mobile networks have grown more heterogeneous through outsourcing and cloud-based functions, while private-network SLA governance and future device relaying further blur stakeholder roles.A unified access-control model for network functions across core networks remains active work, and configuration sprawl raises security concerns, [6].Source: §I · p. 1

eHealth

• eHealth technology enables patients to participate more directly, but fragmented data, interoperability constraints, identity standardization gaps, and weak data-sharing incentives impede collaboration.AI is also accelerating medical applications, including diagnosis, drug discovery, administrative efficiency, and personalization,,.Source: §I · pp. 1–2

Agentic AI

• Agentic AI involves diverse stakeholders and agents with open-ended goals that may require unanticipated cross-organizational collaboration; A2A and ANP leave authorization or broader IAM gaps, [26],.A2A leaves federation and authorization to implementers, while ANP lacks a formal authorization model and relies on HTTPS-based discovery.Source: §I · p. 2

Shared challenges

• Across domains, heterogeneous stakeholders require explicit, verifiable trust; unplanned interactions increase security risks, while ephemeral network locations and massive entity scale challenge existing IAM.Layer-3 and layer-4 identifiers are undermined by unstable cloud network positions, and the relevant entities may number in the millions.Source: §I · p. 2

Contribution

• The paper analyzes established IAM as a basis for open, flexible cross-organizational trust, arguing DLT can provide trust anchoring and governance without centralized or out-of-band coordination.The paper identifies single points of compromise and the absence of a tamper-evident record of federation membership as gaps in existing approaches.Source: §I · p. 2

SPIFFE & SPIRE

• SPIRE is a vendor-neutral, cloud-native reference implementation of SPIFFE for provisioning credentials to ephemeral, dynamically scheduled workloads without secrets.This enables workload authentication.Source: SPIFFE & SPIRE · p. 2
• After initial setup, operators can manage thousands of certificates through a few configuration objects, reflecting SPIRE’s focus on operational automation.Source: SPIFFE & SPIRE · p. 2
• SPIRE supports flexible deployment topologies, including multiple servers, hierarchies, and federated deployments.Source: SPIFFE & SPIRE · p. 2
• Within a trust domain, the Server issues SVIDs, while Workloads manage their SVIDs through the Workload API exposed by an Agent.Source: SPIFFE & SPIRE · p. 2
• Agents manage co-located workloads because the Workload API is unauthenticated; servers trust agents through Agent Attestation, which proves host identity.Agent attestation may rely on deployment-time secrets, cloud-provider-issued documents, or trusted platform modules.Source: SPIFFE & SPIRE · pp. 2–3
• Agents establish workload trust through Workload Attestation, querying platform runtime information such as operating-system, Kubernetes, or container-runtime scheduling data.Source: SPIFFE & SPIRE · p. 3
• SPIFFE solves authentication only; authorization requires separate techniques, such as policy engines or permissions-carrying credentials.Source: SPIFFE & SPIRE · p. 3

OAuth

• OAuth 2.0 is a toolbox of endpoints, grant types, and token semantics rather than a single tightly defined IAM approach.RFC 6749 describes a framework for delegated authorization that supports human-facing and machine-to-machine scenarios.Source: OAuth · p. 3
• In OAuth’s machine-to-machine Client Credentials grant, the client authenticates to the authorization server with its own credentials and needs no user authorization grant.Source: OAuth · p. 3

Workload Identity Federation

• WIF uses token exchange: an external workload presents an issuer credential to an STS, which validates it and returns a token for accessing a protected resource.The STS may fetch the workload issuer’s public keys for validation, and the resource workload may fetch its local issuer’s keys to validate the returned token.Source: Workload Identity Federation · p. 3
• WIF is an emerging, cloud-vendor-driven practice introduced by Google Cloud in 2021 and adopted by other providers.Source: Workload Identity Federation · p. 3
• WIF has a bilateral trust model: each external issuer must be registered individually with the STS, a manual, per-issuer step.Source: Workload Identity Federation · p. 3
• WIF accepts flexible credential types: Google Cloud supports SAML signed assertions and X.509 client certificates, among others.Source: Workload Identity Federation · p. 3

OIDC and OpenID Federation 1.0

• OIDC adds authentication to OAuth 2.0, while OpenID Federation 1.0 enables multilateral trust through signed entity statements and a pre-trusted Trust Anchor.Intermediates publish lists of subordinate entities they vouch for, enabling Automatic Registration; Trust Marks can attest conformance to a federation profile.Source: OIDC and OpenID Federation 1.0 · p. 3
• OpenID Federation is used in Italy’s Digital Identity Wallet ecosystem and in open banking, where providers resolve a party’s trust chain to a national or scheme Trust Anchor.In these examples, an RP obtains citizen attributes from a wallet provider, or a bank releases account data to a third-party provider.Source: OIDC and OpenID Federation 1.0 · p. 3

Organizational Culture

• The OpenID Foundation emphasizes identity and authentication and is funded by membership fees and certification, while OAuth focuses on authorization and APIs; SPIFFE/SPIRE grew from a cloud-native open-source project.OAuth is stewarded by the IETF, whose membership is free and whose funding relies on donations; SPIFFE and SPIRE evolved together as a specification and reference implementation.Source: Organizational Culture · pp. 3–4

Token Exchange

• OIDC standardized JWT tokens and metadata/key discovery, enabling direct peer-to-peer validation; OAuth adopted comparable standards later, and token interoperability across domains was not built in.OAuth left token formats open for nine years, RFC 9068 introduced a JWT profile in 2021, and RFC 8414 added a similar discovery mechanism in 2018.Source: Token Exchange · p. 4
• RFC 8693 token exchange lets a home domain issue tokens in its own format to foreign-domain entities, keeping interoperability within the STS rather than making it system-wide.The domain owner controls trust relations, and adding a trusted issuer does not require downstream changes; the tradeoff is managing the STS and potentially heterogeneous policies.Source: Token Exchange · p. 4
• Token exchange facilitates bilateral trust, whereas SAML-like many-to-many federations and OpenID Federation use direct tokens when members share an agreed IAM language.A shared technical minimum common denominator removes the need for a translation layer.Source: Token Exchange · p. 4

Remote Attestation

• SPIRE attestation assumes agent-workload colocation, while RATS assigns Evidence appraisal to a Verifier and resulting decisions to a Relying Party.Keylime attests remote-node boot and runtime integrity using TPM 2.0, and Veraison provides a scheme-agnostic Verifier.Source: Remote Attestation · p. 4
• SPIRE/Keylime integration and WIMSE drafts connect attestation to identity,,, but verifier trust remains bilateral and preconfigured, leaving multilateral acceptance unresolved,.RFC 9334 relies on a Verifier key in a trust-anchor store or the Verifier first acting as an Attester [39, §7.1]; a decentralized-registry draft sketches architecture but specifies neither protocol nor governance.Source: Remote Attestation · p. 4

SAML Federation

• SAML 2.0 exemplifies closed-world federation: IdPs and SPs exchange signed metadata ahead of time, with a central operator aggregating it in large inter-federations.An IdP signs an assertion vouching for a subject, and an SP consumes it to enable cross-organizational single sign-on; eduGAIN is an example of central aggregation and distribution.Source: SAML Federation · p. 4

III. REQUIREMENTS AND RESEARCH QUESTIONS

• The framework must support unplanned cross-domain interactions without prior pairwise configuration, non-human actors without interactive consent, ephemeral workloads independent of network locators, and heterogeneous IAM solutions.Source: §III · p. 4
• It must scale to millions of NHEs, propagate onboarding, offboarding, and key rotation within bounded time, scope access, enable auditable governance, and prevent unilateral censorship or partition.Source: §III · pp. 4–5
• Analytically, RQ1 eliminates SAML and OpenID Federation 1.0, leaving SPIRE and WIF; SPIRE offers workload-level attestation and specified internals, while WIF leaves provisioning and exchange-policy encoding provider-specific.The empirical evaluation does not decide RQ1; it validates the resulting design and measures WIF as an industry baseline.Source: §III · p. 5
• Because no considered IAM solution meets trust-anchoring and governance requirements R8 and R9, RQ2 asks how heterogeneous domains can coordinate trust anchoring and metadata sharing.Source: §III · p. 5

IV. IAM SOLUTIONS AND PROPOSED DESIGN

• SAML and OpenID Federation 1.0 are excluded because their browser-centricity or pre-established membership, manual onboarding, and shared trust anchor conflict with R1 and R2; the paper proposes relocating OpenID's PKI onto a ledger.SPIRE and WIF are retained as options because they leave trust-root realization more flexible and bind identity to workloads rather than network locations, as R3 requires.Source: §IV · p. 5
• Federation domains may act concurrently as members, providers, or consumers, with providers required to be members; consumers can operate in Imperative or Inversion of Control mode.Imperative mode has the consumer invoke services in the trusted domain, whereas IoC has the trusted domain invoke services in the consumer.Source: §IV · p. 5
• A provider's public federation metadata declares access terms and, for IoC, is the consumer's sole configuration source.It also specifies support for imperative mode, consumer authorization conditions, exchange-request parameters, and any external coordination procedure.Source: §IV · p. 5
• The PAP lets principals configure their federation relationships, and workload configuration may target an indirection layer such as environment variables or a local discovery service.The PAP is a policy management interface defined by NIST SP 800-162.Source: §IV · p. 5

Interactions Common to Both

• Domain B enrolls in the federation and its metadata enters the Repository, where the PAP resolves it to configure Domain A and make B’s workloads authenticable and authorizable under IoC.Domain A’s workloads learn which foreign domains exist and what they offer.Source: Interactions Common to Both · p. 5
• Domain A manages known foreign-domain URLs through the Trust Configuration Interface for discovery and controls such as blacklisting; agentic workloads may instead configure trust bottom-up.This extreme realization establishes technical trust in a previously unknown federation, breaking with the closed-world model of static federation membership.Source: Interactions Common to Both · p. 5
• Workload A requests that Workload B operate under IoC, and Imperative-mode authorization is negotiated; the diagram marks these mode-specific interactions with dashed lines.The dashed interactions are required only for Imperative mode.Source: Interactions Common to Both · p. 5, Figure 1 · p. 6

• With https web, SPIRE can fetch foreign bundles using public web PKI without prior provider knowledge; https spiffe requires out-of-band bundles and mutual domain configuration.Under https spiffe, each domain must already hold the other’s bundle to validate the endpoint certificate.Source: SPIFFE & SPIRE · p. 6
• SPIRE servers fetch partner bundles, attest agents and workloads, then push local bundle updates to workloads before communication.Workload B initiates under IoC; Workload A acts as enforcement and decision point and initiates under Imperative mode.Source: SPIFFE & SPIRE · p. 6
• WIF’s STS evaluates token-exchange requests against issuer-specific policies and can release a Domain A-signed token, while policy encoding remains unspecified and Domain A retains sovereignty.The receiving workload validates the token against its local authorization-server keys.Source: SPIFFE & SPIRE · p. 6
• WIF relies on web PKI, avoids mutual consumer-provider configuration, and adds cross-domain steps: token exchange followed by a possible issuer JWKS key fetch.The STS and authorization server are logically separate, though deployments often combine them.Source: SPIFFE & SPIRE · pp. 6–7
• OAuth and OIDC flows assume workloads already have credentials recognized by the local issuer, often provisioned by infrastructure such as Kubernetes projected tokens or metadata endpoints.The paper calls this practice ambient provisioning.Source: SPIFFE & SPIRE · p. 7

Federation in SPIRE and WIF

• WIF exchanges a workload’s local credential for a target-domain credential, mapping the foreign principal to a local one through an STS broker.The trusting party configures accepted issuers, claims, and principal mappings; the trusted party configures a federation client carrying the requested audience.Source: Federation in SPIRE and WIF · p. 7
• SPIRE domains exchange trust bundles containing public keys to verify peer SVIDs over mTLS, with no token exchange or identity translation.A workload retains its SPIFFE ID across the boundary.Source: Federation in SPIRE and WIF · p. 7
• SPIRE’s configuration is symmetric and trusts an entire domain, whereas WIF’s issuer-and-claims policies enable fine-grained authorization but require asymmetric coordination.Both SPIRE servers publish bundle endpoints and configure the other domain’s endpoint; WIF requires configuration on both trusting and trusted sides.Source: Federation in SPIRE and WIF · p. 7

Proposed Design: Attested Cross-Domain Identity

• The design extends SPIRE with RFC 8693 token exchange and remote workload attestation to combine scoped, audience-bound access with trust decisions about specific foreign workloads.Token exchange supports claim-based conditioning, mapping to a local principal, and audience scoping; attestation targets a workload rather than its whole domain.Source: Proposed Design: Attested Cross-Domain… · p. 7
• A ledger records shared keys and federation metadata, while governance controls member and Verifier admission or removal, avoiding a unilateral trust anchor and keeping the ledger off the runtime path.The governance layer can use an approach such as [53]; collectively accepted Verifiers let domains appraise foreign Evidence without bilateral out-of-band configuration.Source: Proposed Design: Attested Cross-Domain… · p. 7

V. EVALUATION DESIGN

• The evaluation validates the extended SPIRE design against R5 and R6, measures WIF as an industry baseline, and compares centralized and ledger-based FMRs for RQ2.It takes federation-member and external-consumer perspectives across three measurement categories; lifecycle events are assumed to arrive through Server-Sent Events or Solidity events, respectively.Source: §V · pp. 7–8
• Federation-operation measurements track creation, member addition, key rotation, and removal latency against federation size to compare candidates and expose scaling behavior.Removal is assessed through propagation latency and emptymesh latency, the time until the removed member’s workloads can no longer reach anyone.Source: §V · p. 8
• Key-rotation measurements cover internal and external propagation plus full-mesh latency, whose meaning differs between SPIRE receiver reconfiguration and WIF sender token re-exchange.The full-mesh measure captures re-establishing federation configuration after a sender-side SPIRE rotation, versus re-exchanging tokens after a receiver-side WIF rotation.Source: §V · p. 8
• Under load, sender-side latency with validation enabled is compared with a validation-disabled baseline to measure validation cost and determine whether it grows nonlinearly.Separate setups measure WIF with and without token introspection.Source: §V · p. 8
• The revocation experiment compares TTL-based passive revocation with per-request active introspection; their throughput-curve crossing identifies the tightest TTL matching active-mode throughput.This trade-off applies to WIF today and would apply to SPIRE if it adopted token exchange.Source: §V · p. 8

• SPIRE is the most promising foundation, but needs remote attestation, token exchange, and a distributed ledger for shared trust roots and governance without a single domain owning the reference.The ledger-backed governance admits and removes members.Source: §VI · p. 8
• The paper presents a design, not an implementation; end-to-end work remains across remote attestation, token exchange, ledger realization, and revocation.The paper identifies revocation as the most tractable of these issues.Source: §VI · p. 8
• Short SVID lifetimes let credentials lapse, while routing issuance through the STS enables direct token revocation instead of waiting for the TTL to expire.Source: §VI · p. 8
• Token exchange must add a WIF-like STS to mint scoped, audience-bound tokens from foreign SVIDs, while ledger selection, consensus, and access control remain open.Source: §VI · p. 8
• Remote attestation is perhaps the most arduous task: SPIRE's co-location assumption remains, and trust shifts from issuer assertions to workload evidence or a governed, ledger-trusted RATS Verifier.Practical directions include a hardware anchor such as a TPM; transitive trust is relocated, not eliminated.Source: §VI · p. 8

OpenID Federation 1.0

• Workload A authorizes B only after validating B’s credential and tracing its entity statements through an intermediate authority to a trusted Trust Anchor.The intermediate must list B’s OP among its valid subordinate entities, and its own entity statement must be signed by a trusted TA.Source: OpenID Federation 1.0 · p. 9
• A Trust Anchor publishes a self-signed Entity Configuration and Subordinate Statements that define its immediate subordinate intermediates.Source: OpenID Federation 1.0 · p. 9
• A prospective member requests listing through an out-of-band manual process, while the PAP bootstraps the OP with its domain name, keys, and immediate superiors.Source: OpenID Federation 1.0 · p. 9
• The PAP configures the workload with Trust Anchors, and the workload requests a federation-scoped token because ambient provisioning lacks the audience needed for federation members.Unlike WIF, an ambient-provisioned token cannot be sent directly to the other domain’s STS.Source: OpenID Federation 1.0 · p. 9
• Workload B initiates communication with A and includes its locally issued federation-scoped credential; endpoint discovery is out of scope.Source: OpenID Federation 1.0 · p. 9
• Workload A fetches Domain B’s Entity Statement to obtain credential-signing keys, either directly from the configuration or through a JWKS URI.Source: OpenID Federation 1.0 · p. 9