Two-Stage Message Authentication: Transport Continuity Screening Before Semantic Validation

Mechanism

The mechanism partitions authentication into two evaluations that operate on disjoint material and produce independent verdicts. Stage one evaluates the transport-layer identifier carried in the message envelope. The system maintains a continuity record for each previously seen identifier, including the dynamic hash-chain head, the last accepted slope value, and the timestamp of the last accepted message. When a new message arrives, the receiver advances the chain by one step using the inputs declared in the envelope, compares the resulting head against the value carried in the message, and confirms that the trust slope between successive observations falls within the configured envelope. The biological identity is not asserted by a static credential. It is asserted by the continuity of the chain itself: only the entity that observed the prior message can produce the next valid head, because the chain advancement requires possession of the prior state.

Stage two operates on the decrypted payload. After stage one has confirmed continuity and the receiver has decrypted the body using the negotiated transport key, a second authentication block is parsed from inside the payload. This block carries a capability claim — an assertion that the sender is authorized to invoke a specific operation, address a specific resource, or carry a specific role — and an attestation that binds the claim to the message contents. The capability claim is signed with material that is independent of the transport continuity. Stage two therefore answers a different question than stage one. Stage one answers "is this the same correspondent we have been talking to;" stage two answers "is this correspondent authorized to make this particular semantic request."

The two stages are evaluated in fixed order and produce three possible terminal outcomes. If both stages succeed, the receiver assigns the message its declared scope and dispatches it to the application. If stage one succeeds but stage two fails, the receiver assigns the message a bounded fallback scope: read-only operations on the correspondent's own resources, presence indications, and other actions that do not require capability beyond identity continuity. If stage one fails, the receiver discards the message before decryption is attempted, preventing payload-resident attacks from reaching the parser. The bounded-scope fallback is the structural primitive: identity without capability does not produce silence, and it does not produce escalation, but it produces a strictly limited set of permitted operations.

Each terminal outcome is committed to an append-only lineage record. The record captures the chain head observed, the slope evaluated, the capability claim presented, the attestation result, the scope assigned, and the timestamp. Because the record is cryptographically committed to the prior record, replay, omission, and retroactive alteration are detectable by any party with access to the chain. The lineage thus provides not only a per-message authentication outcome but a per-correspondent history that can be inspected to determine when scope has been bounded, when capability has been claimed, and when continuity has been broken.

Operating Parameters

Three parameter families govern the runtime behavior of the two-stage construction. The first family defines the trust-slope envelope used in stage one. The envelope specifies the maximum permitted change in chain advancement rate between successive observations, the maximum permitted clock skew between sender and receiver, and the maximum permitted gap between observations before the chain is treated as expired. Tight envelopes detect impersonation attempts that depart from the historical traffic pattern; loose envelopes accommodate legitimate variations such as device sleep, network outage, or load-induced jitter. Default envelopes are calibrated per correspondent class, with stricter envelopes for high-value correspondents and looser envelopes for intermittent edge devices.

The second family defines the capability ontology used in stage two. The ontology enumerates the capability claims that may be presented in the payload-embedded attestation, the operations each capability authorizes, and the bounded fallback scope that applies when the claim is absent or invalid. The ontology is governance-configurable rather than hardcoded: a deploying jurisdiction can extend it to cover domain-specific operations without modifying the authentication core. The ontology version is referenced explicitly in each attestation, so a receiver evaluating an older message uses the ontology that was current when the message was issued rather than the ontology current at evaluation time.

The third family defines the lineage commitment cadence. The cadence specifies how often the local lineage chain is committed to a peer or to a shared anchor, how many committed entries must be witnessed before a chain head is considered finalized, and how the chain is reconstructed after partition. Higher commitment cadences shorten the window during which a compromised endpoint could reconstruct a divergent history; lower cadences reduce per-message overhead. The cadence is independent of the message rate: a high-volume correspondent with a low commitment cadence still produces a strictly ordered chain, but the finality of any individual entry is delayed.

Together, these parameter families allow the construction to be tuned for traffic patterns ranging from continuous high-rate machine traffic to intermittent low-rate human correspondence without changing the structural guarantee. The guarantee is that two independent gates govern scope; the parameters govern the sensitivity, vocabulary, and finality of the gates.

Alternative Embodiments

The construction admits several embodiments that preserve the two-stage structure while varying the underlying primitives. In the canonical embodiment, stage one uses a dynamic hash chain with slope validation and stage two uses a signature over a capability claim. In an alternate embodiment suited to constrained devices, stage one is implemented as a stateful counter with HMAC continuity and stage two is implemented as a short-form attestation derived from a per-session capability seed. The two-stage property is preserved because the two evaluations remain disjoint and independently failable, even though the underlying cryptography is lighter.

A second alternate embodiment binds stage one to a hardware-rooted attestation rather than a software-resident chain. In this form, the transport identifier is signed by a TPM, secure enclave, or platform attestation key, and the continuity is established through the platform's monotonic counter rather than a software hash chain. This embodiment is appropriate where the deploying environment already provisions hardware roots of trust and where the operator wishes to bind biological identity to a specific physical device rather than to a software-resident state. The bounded-scope fallback behavior is unchanged.

A third alternate embodiment supports federation across authentication domains. In federated form, stage one is evaluated by a domain-local resolver that attests continuity to a downstream verifier, while stage two is evaluated end-to-end by the receiving application. The federated form allows a domain operator to absorb the continuity-tracking cost on behalf of its correspondents while preserving the application's ability to evaluate capability claims independently. The bounded-scope fallback applies at the application boundary rather than at the transport boundary.

A fourth alternate embodiment supports asynchronous and store-and-forward channels. In asynchronous form, stage one continuity is evaluated against the chain head as of the message origination time, with a tolerance window that accommodates message reordering. Stage two remains a strict evaluation against the capability claim. This embodiment supports messaging substrates where delivery latency exceeds the freshness window of a synchronous chain, including disconnected operation, mesh routing, and intermittent satellite links.

Composition With Adjacent Primitives

Two-stage authentication composes with the broader keyless-identity architecture in three load-bearing ways. It composes with the lineage substrate by writing both stage outcomes into the same append-only record that carries object provenance, policy evaluations, and substrate transitions. A downstream auditor reading the lineage sees authentication outcomes interleaved with the operations they authorized, so the chain of custody for any decision can be reconstructed without consulting separate logs.

It composes with the capability-claim ontology by treating the ontology version as a first-class field in the attestation. When the governance authority publishes a revised ontology, in-flight messages continue to be evaluated against the ontology referenced in their attestations, while new messages adopt the revised version on their own cadence. The two-stage construction is therefore stable under governance changes that would destabilize a single-stage scheme tied to a fixed credential format.

It composes with the bounded-scope policy engine by providing a deterministic mapping from authentication outcome to authorized scope. The policy engine does not need to interpret authentication outcomes; it consumes the scope assignment produced by the two-stage evaluation and applies it as the upper bound on what the message can request. The composition produces a clean separation between authentication concerns (who, what capability) and authorization concerns (under what policy).

Distinction From Prior Art

Conventional two-factor and multi-factor authentication schemes combine multiple credential types at session establishment but evaluate them as a single composite verdict. Once the session is established, every message inherits the composite outcome, and the authentication does not distinguish between identity continuity and capability assertion. The construction disclosed here evaluates both concerns on every message and produces independent verdicts, so a correspondent whose capability has been revoked retains continuity scope without needing to re-establish the session.

Mutual TLS and similar transport-layer schemes provide identity continuity through certificate validation but do not embed capability assertion in the payload. Capability is delegated to an application-layer authorization step that is not bound to the transport authentication outcome, so a compromised application credential can be replayed across sessions even when the transport credential has rotated. The construction binds capability into the payload-embedded attestation and chains it to the transport continuity, eliminating the cross-layer replay surface.

Capability-based security systems such as macaroons and biscuits provide payload-embedded capability assertions but do not address transport-layer identity continuity, leaving the authentication-of-the-bearer concern to a separate mechanism. The two-stage construction integrates both concerns and adds the bounded-scope fallback, which neither family provides.

Disclosure Scope

The disclosure under Provisional 64/050,895 covers the two-stage construction in which biological identity is bound through transport continuity and capability claim is validated through payload-embedded attestation, with both required for full scope and a bounded fallback scope when only continuity succeeds. Coverage extends to the dynamic hash-chain continuity primitive, the trust-slope envelope, the capability ontology versioning, the lineage commitment of both stage outcomes, and the alternate embodiments described above including hardware-rooted attestation, federated continuity, and asynchronous channel support. Embodiments that depart from the two-stage structure — single-stage authentication, post-decryption-only authentication, or schemes without a bounded-scope fallback — fall outside the claimed scope. The disclosure is intended to support a non-provisional filing that elaborates the parameter families, the lineage commitment protocol, and the cross-domain federation behavior.