News

Feature

April 21, 2026 · 13 min read

Feature Catskills Region

Presence Derived Identity A Third Key Type For Federated Trust

Journalist
13 min read 5 views
Presence Derived Identity A Third Key Type For Federated Trust

A Third Signal for Digital Identity

Most digital identity systems are very good at answering a particular question: does this actor control the required credential?

A private key can answer that extremely well. Multi-signature schemes can require several independently controlled keys, while zero-knowledge proofs can establish particular claims without exposing the underlying information. Those are powerful tools, but they don't answer every question we sometimes smuggle into the word identity.

A valid signature tells us that the signing operation had access to a private key. Depending on the surrounding system, that may provide very strong evidence about authorization. It doesn't independently tell us whether the person using the key is behaving normally, whether they're under coercion, whether an organization still resembles the organization that originally established its credentials, or whether something important has changed since the credential was issued. None of this means the key failed. The key did its job. We're asking it a question it wasn't designed to answer.

I've been experimenting with an additional credential that attempts to carry information about one of those other questions. I call it a tone key.

The name is provisional, and so is almost everything else.

Control and continuity

Suppose I've controlled the same cryptographic key for ten years. Yesterday I signed a transaction with it, and today I sign another. Cryptographically, the continuity is excellent: something controlled the same key both times.

A great deal about me could nevertheless have changed between those signatures. I could be acting under unusual pressure. Someone else could have obtained the key. My intentions could have changed completely. In an organization, the people represented by a long-lived organizational credential could have changed while the credential remained exactly the same.

That suggests there may be value in keeping another kind of evidence alongside control: information about the history immediately surrounding the use of the credential.

My earlier description went too far here. I said a tone key would prove, I am present. That's more than cryptography can establish from the proposed inputs. A more defensible claim would be that this credential was derived by a specified process from an interaction history that satisfied specified conditions.

That's less dramatic, but it's something we might actually be able to build.

Imagine a local system that maintains a rolling record of interaction with its owner. It measures a set of behavioral properties over time, derives a changing value from those measurements, and uses that value as one input to a cryptographic derivation process. The resulting credential doesn't prove that the person is coherent, sober, free from coercion, or metaphysically the same person they were yesterday. It proves something about the state of the measurement process.

Whether that state tells us anything useful about the person is an empirical question. That's where the project gets interesting.

Start with anomaly, not identity

Suppose I normally interact with a local agent in a way that produces a fairly stable collection of measurements. Then one day several of those measurements change abruptly. My pace changes, the structure of the exchange changes, previously stable interaction patterns disappear, and the way earlier information is carried forward changes.

That doesn't tell the system why. Maybe I'm under duress, drunk, sick, angry or simply in a hurry. Maybe someone else is using the interface. Maybe I've changed.

The measurement doesn't interpret itself. What it can potentially tell us is that the current interaction differs from the history against which it is being compared, and for a sufficiently consequential action that might justify another step. Perhaps that's a delay, another authentication factor, an explicit confirmation or an independent human check. The appropriate response depends on the cost of being wrong in both directions.

The original tone-key design used four groups of measurements: tone arcs, role transitions, coherent turn rate and a Resonance Integrity Score. I wouldn't throw those away, but I also wouldn't assume yet that they measure what their names imply.

A tone arc attempts to describe how certain observable properties of an interaction change across several turns. Role-transition measurements attempt to capture changes in the function different turns appear to perform. Coherent Turn Rate compares current pacing with an established baseline. RIS combines proposed measurements of continuity, reversibility, contradiction and compression fidelity.

Each is a candidate feature.

If pacing predicts useful anomalies and the rest don't, use pacing. If contradiction handling contributes additional predictive information, keep it. If a four-dimensional entropy calculation performs no better than ordinary behavioral statistics, don't preserve the entropy calculation because the theory likes it.

Let the measurement earn the architecture.

Deriving a credential

Once we have measurements that actually predict something useful, the cryptographic part becomes comparatively ordinary. A local process could periodically construct a measurement state from a rolling interaction window and combine that state with a locally held secret and contextual information through a standard key-derivation function.

Conceptually:

measurement_state = encode(validated_features, rolling_window)

seed = KDF(local_secret, measurement_state, epoch)

tone_credential = HKDF(seed, domain_context)

The important addition here is the local secret. The earlier design attempted to derive the key primarily from behavioral entropy, but behavioral measurements aren't secrets. Even if they're difficult to reproduce precisely, difficulty of imitation isn't the same thing as cryptographic entropy.

A behavioral signal should therefore participate in credential derivation or authorization without being asked to serve as the secret itself. That gives us two different properties: the secret establishes cryptographic control, while the measurement state establishes that some locally defined conditions were satisfied when the credential was produced.

Neither substitutes for the other.

This distinction also addresses an uncomfortable consequence of the original design. If my ordinary behavior becomes the secret that authenticates me, then being myself becomes a password. Behavioral patterns can leak, be modeled, and change naturally. Some may reveal information I never intended to make part of an authentication system, and an attacker who obtains enough historical interaction could potentially learn the same features the system uses.

Worse, I could become locked out precisely because I've changed.

That isn't sovereignty.

A better architecture treats longitudinal behavior as a local risk signal rather than a bearer credential. The raw history can remain on hardware I control, while a remote verifier doesn't need my interaction logs, emotional history, conversational cadence or behavioral fingerprint. It only needs whatever bounded assertion the local system is authorized to make: perhaps that local continuity checks passed for this transaction under a particular policy version.

Whether a relying party should care about that assertion is another question.

The local agent

The original architecture used four agent roles: Narrator, Watcher, Opposition and Witness. Those roles came from a much larger theory about relational coherence, but they don't need to be true for the credential experiment to work.

We can translate them into ordinary engineering functions. An interface communicates with the user. A monitor computes longitudinal measurements. An independent evaluator looks for contradictions or anomalies the primary interaction process may have missed. A gate decides whether the measurement state satisfies the policy required for credential issuance or transaction authorization.

Those functions could be implemented with four models or two. Some may not require language models at all. In particular, I would prefer the final gate to be as boring as possible. If a transaction requires conditions A, B and C, the gate checks A, B and C. It shouldn't develop a theory about whether I'm “really myself.”

That judgment exceeds the evidence available to it.

The same problem appears when the pattern changes. My original design proposed a response along the lines of: Your pattern isn't matching right now. No transactions until you're yourself again.

I wouldn't let the system say that anymore.

It doesn't know that I'm not myself. It knows that something it measured changed.

A safer response would be: This transaction differs from your established interaction pattern. Additional verification is required. Now the system is reporting an observation rather than diagnosing the person, which also leaves room for legitimate change. People change pace. We change language. We learn. We age. Our circumstances change. An authentication system that treats behavioral continuity as identity can eventually become a machine for enforcing an obsolete version of its owner.

Drift isn't automatically compromise. Sometimes continuity requires drift.

Duress is especially difficult

Duress remains one of the most interesting possible applications and one of the easiest places to overclaim. Suppose historical data eventually shows that certain changes in interaction frequently accompany coercion: unusual acceleration, truncated exchanges, abrupt simplification or deviations from established decision patterns. Those signals might improve risk detection, but they wouldn't prove coercion.

False positives have consequences. Imagine being unable to move money during an emergency because an agent interpreted urgency as evidence that you weren't behaving like yourself. A useful architecture therefore has to consider both the cost of allowing a dangerous transaction and the cost of preventing a legitimate one.

A low-risk action may proceed normally. A moderately unusual high-value transaction might require another factor. A severe anomaly during an irreversible transaction might introduce a delay or require an independently authorized person. The behavioral signal contributes evidence; it doesn't become sovereign over the person it's supposed to protect.

Organizations make the problem harder

The original proposal extended tone keys upward by combining individual tone keys into a domain tone key and described the result as proof that an organization was “coherent and alive.”

I don't think that follows.

Organizations aren't merely aggregates of member behavior. Membership changes, authority differs among members, and disagreement can be healthy. A highly uniform organization may be coordinated, captured or simply boring. Combining behavioral credentials doesn't solve those interpretation problems.

There may still be something useful here. An organization could define explicit continuity requirements for particular actions. Some transactions might require current authorization from several roles whose local continuity checks have passed. Governance rules could specify what happens when membership changes or an authorized participant becomes unavailable.

Now we're back on firmer ground. The cryptography proves that required credentials participated, the local systems provide whatever bounded assertions their policies permit, and the governance structure determines what combination is sufficient.

No single layer has to pretend it proved organizational coherence.

Federation

This produces a somewhat different three-level architecture from the one I originally imagined.

At the peer level, ordinary cryptographic credentials establish control while local longitudinal measurements can influence whether or how those credentials are used. At the domain level, organizations define which peer credentials and continuity assertions are required for particular actions. At the public ledger level, ordinary signatures and multi-signature rules continue doing what they already do well.

The public network doesn't need to know my behavioral history, tone vectors, conversational cadence, or whether a local agent thinks I'm behaving unusually. It verifies the cryptographic artifact presented to it.

That separation may be one of the strongest properties of the design because the most sensitive interpretation stays closest to the person.

What should persist?

The original proposal used a local relational database to preserve interaction history across sessions, and I still like that part. Longitudinal measurement requires history somewhere. If the system starts from zero every time, it can't distinguish an established pattern from today's variation.

Local storage also creates a useful authority boundary. The person can retain control over the history from which the measurements are computed. The database should store observations and provenance rather than pretending to store identity itself: what happened, what measurement was produced, which policy version interpreted it, what action followed, and what later evidence suggested that interpretation was correct or wrong.

That last part matters because the system needs somewhere to learn that its own anomaly detector was mistaken. Otherwise yesterday's interpretation quietly becomes tomorrow's baseline.

My original design also proposed migrating the local agent to federated cloud storage after the person's death, where it would become a read-only memorial. That's really a separate problem. A memorial may be valuable, continuity of records may be valuable, and estate-controlled access to selected material may be valuable, but none follows automatically from an authentication architecture.

Death also creates exactly the kind of authority question cryptography can't answer on its own: who gets to declare that the person is permanently absent, under what evidence, and what happens to the data afterward?

That belongs in an explicit succession policy. The tone-key mechanism shouldn't quietly decide it.

The experiment before the key

There is an even more basic issue: we don't yet know whether the proposed behavioral measurements are useful enough to put anywhere near an authentication system.

So don't start with the key.

Start with prediction.

Collect longitudinal interaction data with informed consent and define independently labeled events that matter: unusual interaction, successful correction, account-takeover simulations, controlled high-pressure conditions, or other outcomes that can be studied safely. Compute the candidate measurements without allowing them to affect access, then ask whether they predict those outcomes better than simpler baselines.

If they don't, stop. If they do, run them in shadow mode and let the detector make recommendations while people continue making the actual decisions. Measure false positives and false negatives. Only after that should we test bounded interventions, and only after those interventions demonstrate value should the measurement participate in credential issuance.

The order matters because authentication systems can harm the people they're meant to protect when their assumptions are wrong.

What remains of the tone key

Quite a lot, actually.

The original intuition was that control and presence aren't the same property. I still think that's right. Where I went too far was assuming that because cryptographic systems don't measure presence, I already knew what presence was and how to measure it.

I don't.

What I have instead is a candidate set of longitudinal signals that may tell us something useful about continuity around the exercise of cryptographic authority. If those signals survive testing, we can use them without turning them into identity.

A private key can establish that an operation possessed the required secret. A longitudinal measurement system might eventually add that the local conditions surrounding the operation were consistent with policy and historical observations.

Neither statement means:

This is truly Rob.

That last sentence contains far more than either system can know.

The architecture becomes safer when we stop asking cryptography to answer it.

The tone key began as an attempt to create a third kind of identity credential, something derived from ongoing interaction rather than possession of a secret. I would describe the project differently now: it is an experiment in adding longitudinal local evidence to cryptographic authorization.

The behavioral measurements aren't secrets. Variation isn't automatically duress. Continuity isn't identity. Anomaly isn't guilt. A local agent isn't an authority on who its owner really is. Those boundaries don't weaken the idea; they tell us what the idea has to prove.

If longitudinal interaction contains reliable signals that improve high-stakes authorization while keeping the underlying history local, then we have something useful. We can combine those signals with ordinary cryptography, explicit governance and bounded intervention without pretending that any of them has solved identity.

The private key proves control, while the longitudinal layer contributes context.

The person remains more than either one can represent.

QR Code for this article
QR Code

Scan to read this article online. Right-click the image or download to use in print.

Download PNG