Policy-Governed Capability Binding for Biological Identity

Mechanism

The binding primitive operates on three persistent objects: a biological-identity thread, a capability-grant record, and a binding manifest that joins them. The biological-identity thread is a monotonic sequence of observation events produced by the identity subsystem. Each event carries a timestamp, a sensor-channel descriptor, a confidence value, and a continuity hash that chains the event to the immediately preceding event in the same thread. The chain is the load-bearing structure: a capability is bound to a particular thread-identifier and to a minimum continuity depth, and the binding is satisfied only while the chain remains unbroken at or above that depth.

A capability-grant record declares the scope of permitted operations, the resource set the capability authorizes, the issuing policy reference, and the binding manifest. The binding manifest carries the thread-identifier, the required continuity depth, the minimum acceptable observation confidence, the acquisition tier the thread must satisfy (sensor class, liveness class, custody class), and a lapse-action descriptor that specifies what the runtime must do if the binding fails.

Capability evaluation is a synchronous gate. When an actor presents a capability for use, the authorization service resolves the binding manifest, queries the identity subsystem for the current state of the referenced thread, and tests four predicates: thread-presence (the thread is currently being observed), continuity-depth (the most recent unbroken segment meets the required depth), confidence-floor (recent observations meet the manifest's minimum confidence), and tier-compliance (the active sensors satisfy the declared acquisition tier). All four predicates must hold. If any predicate fails, the capability is treated as lapsed for this evaluation and the lapse-action descriptor is executed.

Lapse is irreversible at the level of the bound grant. A new grant may be issued under a fresh binding once the identity subsystem has re-established a thread of sufficient depth, but the prior grant is not silently reattached to a re-acquired thread. This is the property that distinguishes the binding from a session token: a session token can be re-presented across an identity gap, while a bound capability cannot. The binding terminates with the thread.

Operating Parameters

Continuity depth is expressed as a count of consecutive observation events or, equivalently, as a wall-clock duration of unbroken observation. Typical bindings declare a minimum depth in the range of tens of seconds for low-sensitivity capabilities and tens of minutes of unbroken observation for capabilities authorizing irreversible operations. The depth is a policy parameter, not a hardware parameter; it is set by the issuing policy and recorded in the binding manifest.

Confidence floor is a scalar in the unit interval. Observations below the floor are admitted to the thread but do not contribute to satisfied-depth accounting. A binding may declare separate floors for the issuing event and for ongoing maintenance, permitting a high-confidence acquisition followed by tolerant maintenance, or vice versa where the operation requires sustained high confidence.

Acquisition tier enumerates the sensor classes, liveness checks, and custody attestations the thread must carry. A tier-1 binding may accept any single biometric channel with a passive liveness signal. A tier-3 binding may require a multi-modal channel set, an active liveness challenge within the last interval, and a hardware-attested custody chain from the sensor to the authorization service. Tier compliance is evaluated against the live thread, not against the thread at issuance, so a thread that drops a sensor mid-session loses tier compliance immediately.

Lapse-action descriptors enumerate the runtime responses to binding failure. The minimal action is denial of the current request. Stronger actions revoke the grant record, invalidate any cached authorization decisions derived from it, propagate revocation to downstream services that hold derivative grants, and emit a governance audit event. The strongest action additionally triggers compensating operations: rolling back partially completed transactions, releasing held resources, and notifying subscribers that the grant has lapsed.

Re-binding policy governs what happens when a thread is re-established after a lapse. The default is non-automatic: a new grant must be issued through the standard policy path. A binding may declare a re-bind window during which a re-acquired thread of equal or higher tier may be linked to a freshly issued grant without full policy re-evaluation, but the prior grant remains lapsed and the new grant carries a new identifier.

Alternative Embodiments

In a first embodiment, the binding manifest is stored alongside the grant record in a governance ledger, and capability evaluation is performed by a centralized authorization service that holds a live subscription to the identity subsystem. This embodiment minimizes evaluation latency at the cost of centralizing the identity-to-capability join.

In a second embodiment, the binding manifest is encoded into a signed capability artifact carried by the actor, and the relying service evaluates the binding against a local view of the identity thread obtained from a federated identity provider. This embodiment supports cross-domain capability use, with the trade-off that thread freshness depends on federation propagation.

In a third embodiment, the binding is hierarchical: a parent capability authorizes the issuance of child capabilities under more restrictive bindings. A parent lapse cascades to all children, but a child lapse does not affect the parent. This supports delegation patterns where a high-tier holder briefly authorizes a lower-tier operation without exposing the parent grant.

In a fourth embodiment, the binding is contextual: the manifest declares context predicates (location, time-of-day, co-presence with another bound identity) that must hold in addition to the thread predicates. Context failure is treated as a binding failure with the same lapse-action semantics, allowing the same grant to be active in some contexts and lapsed in others without requiring re-issuance.

In a fifth embodiment, the binding manifest declares a degradation schedule rather than a binary tier requirement. As thread quality decreases, capability scope contracts according to the schedule, so a fading thread loses high-risk operations first while retaining low-risk operations until full lapse.

In a sixth embodiment, the binding manifest declares a co-presence requirement that names a second thread-identifier whose continuity must be jointly maintained for the binding to remain satisfied. The authorization service evaluates both threads against the same four predicates, and a lapse on either thread is treated as a lapse on the binding. This embodiment supports operations that should require two persons to be simultaneously observed — an acquisition pattern previously approximated by procedural controls but now expressible as a single binding object.

In a seventh embodiment, the binding declares a quorum requirement over a set of thread-identifiers, satisfied when any k of n declared threads currently satisfy the per-thread predicates. Quorum bindings support continuity of authorization across roster changes, where the population of bound identities is allowed to drift but the count of currently-present, currently-observed identities must remain at or above the quorum floor.

Evaluation Flow and Failure Semantics

Each capability presentation traverses a deterministic evaluation flow. The authorization service first resolves the grant record by content address, then resolves the binding manifest carried in the grant, then issues a single query to the identity subsystem naming the manifest's thread-identifier and requesting the most recent continuity segment, observation confidences within the floor window, and live tier descriptor. The four predicates are evaluated against the returned state in fixed order: thread-presence, continuity-depth, confidence-floor, tier-compliance. The fixed order is load-bearing for diagnostics: a lapse record names the first failing predicate, which is the predicate the operator must address.

Failure produces a structured lapse record. The record names the grant identifier, the binding manifest content address, the failing predicate, the observed value, the threshold, and a timestamp. The record is signed by the authorization service and emitted to the audit channel before the lapse-action descriptor is executed, so the audit trail is not contingent on the success of the runtime response. If the lapse-action descriptor itself fails — for example, because a downstream revocation propagation times out — a follow-on lapse-action-failure record is emitted, but the original lapse remains in force and the grant remains lapsed.

Re-presentation of a lapsed grant is an idempotent failure: the authorization service returns the same lapse classification for every subsequent presentation of the same grant identifier without re-querying the identity subsystem, until the grant identifier is explicitly retired. This prevents probing a lapsed grant from generating sustained query load on the identity subsystem and ensures that the lapsed-state classification is stable across the cluster.

Composition

Capability binding composes with the broader cognition-patent architecture along three seams. First, the identity subsystem exposes the thread state through a stable interface that is consumed by the authorization service; the same interface is used by audit, telemetry, and consent subsystems, so binding decisions and the records they produce are observable through the existing governance plane. Second, the policy engine that issues grants writes binding manifests as part of the same transaction that emits the grant; there is no separate path for unbound issuance, which closes the class of failure where a grant escapes binding. Third, the lapse-action descriptor is executed by the same runtime that handles policy-driven revocation, so a thread-lapse and an explicit revocation are indistinguishable downstream — relying services do not need to discriminate between the two.

The binding primitive is also the load-bearing structure for several higher-level features described elsewhere in the patent family: graduated authorization (where capability scope expands with thread depth), temporal capability (where bindings declare maximum thread age), and co-presence capability (where a binding requires two threads to be simultaneously active). Each of these features is expressed as a binding manifest variant; no new evaluation primitive is required.

Prior-Art Distinction

Token-based access control binds capabilities to bearer artifacts. Possession of the artifact is sufficient for use; the artifact does not lapse on identity discontinuity because it is not bound to identity. Session-based systems bind capabilities to authentication events that occurred in the past; the binding is to the event, not to a continuing observation, so a session survives the actor's departure until an explicit timeout. Continuous-authentication systems re-evaluate authentication periodically but typically score risk and adjust friction rather than terminating capabilities. The disclosed primitive differs in that the binding is to a live, monotonically extended observation thread, lapse is automatic and synchronous with detection, and the manifest declares the lapse-action as part of the grant rather than leaving it to ad-hoc policy.

Disclosure Scope

This disclosure covers the binding manifest format, the four-predicate evaluation gate, the lapse-action descriptor and its execution semantics, the re-bind policy surface, and the five embodiment variants enumerated above. It also covers the composition seams with identity, policy, and revocation subsystems where those seams are load-bearing for the binding behavior. It does not cover the underlying biometric or behavioral signal acquisition, which is the subject of separate disclosures in the identity-subsystem family, nor the policy authoring interface used to declare manifests, which is governed by the policy-engine disclosures.