Two layers interoperate instead of competing
REPO-017 is the consolidated governing corpus. FederatedTrust owns a first-pilot product, but the target remains a designed deployment profile until its release and operating evidence exists.
Layer 1: Federated Trust
Federated Trust provides cloud authentication plus ReBAC-centered authorization and is the only writer of firm, membership, relationship, role, cross-party or coalition grant, and policy facts.
Layer 2: downstream app evaluation
Each application evaluates its resource-specific decision from live Layer 1 facts or a verified Layer 1 projection plus resource-local state. It may deny or narrow, but cannot invent a grant or run a competing relationship engine.
Cloud and offline paths
Cloud-first and offline-capable applications use the same decision logic. Offline evaluation consumes a signed, versioned, expiring Layer 1 projection, accepts no relationship or policy writes, and fails closed by default for sensitive operations when the projection is stale past its bound.
Pilot product boundary
FederatedTrust owns the product for the first pilot. Broader investment remains governed by BIZ-1/2/3 and is not implied by the authorization architecture.
Typed policy and relationship evaluation exists in code and tests. Independent Federated Trust deployment, operational evidence, and relying-party integration remain incomplete.
Managed, customer-controlled connected, and sovereign/offline profiles are designed target shapes, not generally available offerings. Each requires a validated package and explicit infrastructure, custody, update, recovery, observability, and support responsibilities.
Local audience, tenant, revision, revocation, and resource-policy enforcement is a required design contract; conformance must be proven for each relying service.
Three policy lenses answer different questions
RBAC: job-shaped access
Roles provide understandable bundles for recurring responsibilities, but should not become the only source of truth.
ReBAC: durable relationships
Relationship-based policy expresses who owns, belongs to, manages, sponsors, or is affiliated with a resource or organization.
ABAC: contextual narrowing
Attributes such as tenant, environment, assurance, purpose, device, time, or transaction risk can further constrain a request.
Typed policy and relationship evaluation exists in code and tests. Independent Federated Trust deployment, operational evidence, and relying-party integration remain incomplete.
Capability-based authorization is a delegation target
CapBAC is not a fourth competing policy engine. Size-limited signed-envelope verification, opaque verified artifacts, attenuation, and exact reference-service request binding exist in code; independent issuer-key resolution and relying-party rollout evidence remain gated.
Attenuation only
A delegated artifact can become narrower in resource, action, audience, purpose, or lifetime; it cannot create authority the delegator did not have.
Actor chain
Human, application, agent, and downstream workload identities remain distinguishable for policy and audit.
Short-lived and revocable
High-risk delegation should use bounded lifetimes, unique identifiers, current policy revision, and a revocation path.
Strict attenuation, a size-limited signed-envelope verifier, runtime-opaque verified artifacts, and exact reference-service request binding exist in code and tests. Independent issuer-key resolution and relying-party rollout evidence remain gated.
Roadmap reference for narrowing delegated authority across actors and workloads; it is not represented as a generally available issuance flow.
OAuth 2.0 Rich Authorization Requests (RFC 9396)Roadmap reference for structured authorization detail. Current integrations must not assume this request shape is accepted.
DPoP (RFC 9449)Roadmap reference for sender-constrained OAuth tokens. It is not a blanket statement that current clients are sender constrained.
Layer 2 retains per-app final deny
A Layer 1 decision or valid delegation is necessary but not sufficient to read or change a protected application resource.
Audience match
A service rejects authority issued for another relying service or environment.
Resource-local evaluation
The service evaluates the exact resource, current tenant state, Layer 1 revision and revocation state, and local deny conditions before acting.
Fail closed
Unknown subject mappings, ambiguous tenant context, unverifiable delegation, or an expired projection for a sensitive operation ends in denial.
Local audience, tenant, revision, revocation, and resource-policy enforcement is a required design contract; conformance must be proven for each relying service.