Identity, policy and update authority evidence

SPIFFE token replay and uniqueness

Does a JWT-SVID jti claim make a SPIFFE workload token single-use?

The pinned JWT-SVID specification permits jti but does not require validators to track its uniqueness. JWT-SVIDs remain bearer tokens: audience and expiry constrain exposure without eliminating replay. A token with multiple audiences can be replayed by one recipient to another listed recipient. Single-use acceptance therefore needs separately evidenced controls.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

SPIFFE identity ambiguity in certificates

Can an X509-SVID with two URI SAN identities be accepted if its certificate chain verifies?

The pinned X509-SVID specification requires exactly one URI subject alternative name and one SPIFFE ID. Validators must reject more than one URI SAN, even when ordinary certificate-path validation succeeds. Other SAN types may be present. The identity selection rule prevents a verifier from arbitrarily choosing which workload identity to authorize.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

SPIFFE signing authority versus caller identity

Can a SPIFFE CA signing certificate authenticate as the workload it issues credentials for?

The pinned X509-SVID specification reserves caller authentication for leaf certificates and prohibits using signing certificates for authentication. A leaf must have cA false, lack keyCertSign and cRLSign, and carry a SPIFFE ID with a non-root path. Possessing valid signing material is not interchangeable with presenting a valid workload leaf.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

SPIFFE streamed identity withdrawal

Should a workload keep an old SPIFFE bundle when a later API response omits it?

SPIFFE Workload API stream responses are complete replacements, not incremental patches. Default or empty fields must replace previous values; omitted material should be treated as redacted. The X509 profile says clients should cease using redacted SVIDs or bundles, including withdrawal indicated by PermissionDenied. Retaining previously cached authority can contradict that update.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

SPIFFE federation endpoint binding

Does a downloaded SPIFFE trust bundle identify which trust domain it is authorized to represent?

The pinned federation specification says a bundle does not contain its trust-domain name. Clients must configure the endpoint URL, profile and associated trust domain before retrieval. Bundles from different domains must remain separate; merging them allows one domain to forge identities in another under the combined trust store. HTTPS success alone does not supply the missing domain binding.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

SPIFFE federation key rollout

Can a new SPIFFE signing key be used before foreign verifiers can fetch its bundle?

The pinned federation specification requires new externally used keys to appear at the bundle endpoint before issuing SVIDs with them. It recommends publication three to five refresh-hint intervals in advance and removing deprecated keys after no valid SVIDs remain. These are rollout conditions; a successful local issuance does not prove foreign verifiers have refreshed.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

SPIFFE filesystem key and certificate consistency

Can separate file reads load a mismatched SPIFFE private key and certificate despite atomic rotation?

The pinned, incubating filesystem delivery specification recommends loading the credential bundle in one open/read/close cycle. Separate cycles for key and certificate can straddle a rotation and produce a mismatched pair, even when the provisioning system writes atomically. Applications must reload updated bundles promptly and must not assume the new key type or chain matches the old one.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

SPIFFE filesystem withdrawal signals

Does an empty SPIFFE credential file mean the client should keep its last cached identity?

The pinned, incubating filesystem delivery specification defines an empty credential or trust-bundle file as deliberate redaction. Consumers should unload the withdrawn material, including individual anchors removed from a remaining bundle. An absent file can instead reflect remounting or repopulation; emptiness is the stronger intentional signal. Keeping cached identity indefinitely would erase that distinction.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

OpenFGA authorization model selection

Can an OpenFGA authorization check change when the request omits authorization_model_id?

OpenFGA models are immutable, but a write creates a new model version. The pinned documentation says requests without authorization_model_id use the store’s latest model. Passing the ID binds evaluation and validation to that version. Immutability therefore does not guarantee stable authorization when applications implicitly select whichever model was created last.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

OpenFGA model and tuple migration

Does publishing a renamed relation in OpenFGA migrate existing relationship tuples automatically?

The pinned immutable-model guide describes relation renaming as a coordinated migration: create the new model, update application relation names, copy existing tuples to the new relation and deploy against the new model ID. Creating an immutable model version alone is not the tuple or application migration. Rollout evidence must connect all three states.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

OpenFGA authorization cache freshness

Can a successful OpenFGA tuple update be followed by a stale Check response?

The pinned consistency guide says MINIMIZE_LATENCY can use cached results, so an immediate check may omit a recent tuple change when caching is enabled. HIGHER_CONSISTENCY bypasses the cache and queries the database. Caching is documented as disabled by default. The actual configuration and request mode matter; a write receipt alone does not establish a fresh authorization decision.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

OpenFGA request-local relationship overrides

Can a contextual tuple override the same stored relationship in an OpenFGA request?

The pinned contextual-tuples guide says request-local tuples participate in evaluation as stored tuples would, but are not persisted and affect only that request. When user, relation and object match a stored tuple, the contextual tuple takes precedence. Reviewing the database alone therefore does not reconstruct the relationships used by that specific decision.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

OpenFGA token-derived residual membership

Does removing a directory group immediately remove OpenFGA access based on an unexpired token claim?

The pinned OpenFGA token-claims guide warns that relationships supplied from token claims can continue granting access until the token expires even if the underlying directory relationship changes. Contextual tuples avoid persistent synchronization but do not make the token’s claim live directory evidence. Offboarding must account for that residual acceptance window and the deployed token-handling policy.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

OpenFGA change log and decision reconstruction

Can OpenFGA Read Changes alone reconstruct decisions that used contextual tuples?

OpenFGA contextual tuples exist only for a request and are not stored. Read Changes reports stored tuple writes and deletes, and the token-claims guide warns that permission-aware indexes built from it may not account for contextual tuples. A complete reconstruction needs the request-local inputs as well as the stored changes; the change stream is not an execution trace.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

OpenFGA temporal condition inputs

Does an OpenFGA temporal grant independently establish the current time used for authorization?

The pinned conditions guide models access using current_time, grant_time and grant_duration, and its query examples supply current_time in request context. The documented expression evaluates those inputs; it is not evidence of how the caller obtained or protected the clock value. A buyer must establish the provenance and freshness of time supplied for the decision.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

OpenFGA condition context merge

Can request context replace a condition parameter already stored in an OpenFGA relationship tuple?

The pinned conditions guide specifies a merge of persisted tuple context and request context for condition evaluation. Persisted values take precedence when both provide the same parameter. A request that sends a different grant duration does not, by that act alone, replace the stored duration. Reconstruction requires both inputs and their documented precedence.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

OpenFGA change-stream resumption

Does reaching the current end of OpenFGA Read Changes make its continuation token disposable?

The pinned Read Changes guide says to persist continuation tokens across errors and restarts. At the current end, the API returns the same token, which should be saved for later polling. A token produced by an object-type filter must be reused with that type. Losing the cursor or its filter context can undermine a claimed continuous audit export.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

OpenFGA contextual Expand documentation conflict

Do the pinned OpenFGA guides agree that Expand accepts contextual tuples?

At the pinned documentation revision, the contextual-tuples guide lists Expand among supported query methods, while the token-claims guide says contextual tuples are not supported on Expand. These statements conflict. The reviewed documentation alone cannot settle support for a buyer version; inspect that version’s API contract and validate the intended request before relying on an Expand result.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

TUF initial trust bootstrap

Can an agent trust a new tool repository by downloading its own TUF root metadata from that repository?

The pinned TUF client workflow begins with a trusted root copy supplied through an out-of-band process. Repository-supplied metadata cannot independently establish that initial trust. Later root updates must continue from the accepted root. A buyer must identify who approved the starting root and how its bytes and keys reached the updater.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

Required source attribution and distribution notice

TUF root-rotation continuity

Is a new TUF root trusted when only the new root keys signed it?

The pinned TUF root-update procedure requires the next root to satisfy signature thresholds from both the previously trusted root and the new root itself. A self-signed replacement alone does not establish continuity. Failed verification must abort that update cycle and retain the previous starting point for the next attempt.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

Required source attribution and distribution notice

TUF signature threshold identity

Can repeated signatures from one TUF key satisfy a multi-key approval threshold?

The pinned TUF verification rules count each key only once toward a role’s signature threshold. Repeating a KEYID in the signatures list does not add another verified signer. A threshold review must therefore count distinct authorized key identifiers after signature verification, rather than count signature entries or signature blobs.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

Required source attribution and distribution notice

TUF skipped root versions

Can a TUF client skip unavailable intermediate root versions and trust the latest signed root?

The pinned root-update workflow fetches the next numbered root and requires its version to be exactly one greater than the trusted version. Intermediate roots establish the chain across key changes. A higher version number or a latest-root URL alone does not establish that chain; missing continuity requires investigation rather than bypassing the required verification.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

Required source attribution and distribution notice

TUF root expiry during recovery

Does an expired intermediate TUF root necessarily prevent reaching a valid current root?

The pinned TUF workflow allows trusted starting and intermediate root expiry to remain unchecked while following verified root updates. It checks expiry after reaching the final trusted root, against the fixed update start time. This recovery rule does not allow an expired final root or relax the intervening version and signature checks.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

Required source attribution and distribution notice

TUF signed metadata freshness

Does a valid TUF timestamp signature prove that the update metadata is fresh enough to use?

TUF timestamp verification includes distinct signature, version and expiry checks. The pinned workflow rejects rollback and an expiry no later than the fixed update start time, even if the signature is valid. Signing authenticity therefore does not replace freshness evidence; the buyer also needs a defensible client clock and retained version state.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

Required source attribution and distribution notice

TUF unchanged timestamp handling

Does a repeated TUF timestamp version mean a tool update failed or an attack was proven?

The pinned timestamp workflow distinguishes lower versions from equal versions. A lower version is a rollback failure; an equal version is discarded and the update cycle ends normally without an error, because metadata should not have changed under that version. A no-change stop is not evidence of installation or independently proven malicious activity.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

Required source attribution and distribution notice

TUF cross-file metadata consistency

Can separately valid TUF signatures establish that timestamp, snapshot and targets metadata belong together?

The pinned client workflow also binds metadata versions and any listed hashes across roles: snapshot must match the trusted timestamp, and targets must match the trusted snapshot. These checks address mixed metadata sets. Valid signatures on independently selected files are not a substitute for verifying the required cross-file relationships.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

Required source attribution and distribution notice

TUF delegated target authority

Can a delegated TUF signer authorize a tool path allowed by its own metadata but excluded by an ancestor?

The pinned TUF delegation rules require the target path to satisfy trusted paths at every role in the delegation chain. Matching only the leaf role’s path is insufficient. A descendant cannot enlarge authority beyond an ancestor’s delegated path scope merely by signing metadata that names additional targets.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

Required source attribution and distribution notice

TUF terminating delegation boundary

Can a TUF updater fall back to another signer after a terminating delegation has no matching tool target?

TUF terminating delegations stop consideration of later matching trust statements after that role and its descendants have been processed. The pinned workflow does not treat a missing target as permission to seek a more permissive later signer. This restriction preserves the authority boundary deliberately assigned to the terminating delegation.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

Required source attribution and distribution notice

TUF delegation without relinquishment

Does delegating a TUF target role remove the parent publisher’s authority over those targets?

The pinned TUF roles description says a delegating role remains trusted after it delegates full or partial target scope. Delegation is therefore not evidence that the parent has surrendered publishing authority. A buyer seeking exclusive control by a subsidiary signer must inspect the entire trust arrangement rather than infer exclusivity from a delegation entry.

Documentation reviewed 2026-10-24. Primary source.

Complete record JSON · Exact free preview JSON · Source review

Required source attribution and distribution notice