The profile is its Ed25519 key pair (§1.1, §1.3). §1.3 requires clients to treat a key change under the same URI as a different profile and to warn the user. As specified, this means:
- Key compromise = permanent, irrecoverable profile takeover. There is no way to announce a successor key, so the legitimate owner cannot rotate away from an attacker who obtained the private key.
- Key loss = permanent identity death. All connections, reader-key relationships, and the web-of-trust position are gone.
- The asymmetry is notable: the spec provides a well-designed migration path for the URI (§16 Profile Relocation) but none for the key — yet over a profile lifetime of years, key compromise/loss is arguably the more likely event than provider death.
Additionally, Overview.md describes a "social fingerprint" disaster-recovery scheme (depositing data packets with connected profiles, threshold re-authentication with friends to regain control of the key pair). As far as I can tell, this mechanism is not specified in SPXP-Spec.md, SPXP-PME-Spec.md, or SPXP-SPE-Spec.md. The overview currently promises a security property the protocol doesn't define.
Suggested direction
- Specify a key rotation/succession statement: a document signed by the old profile key announcing a successor public key (with timestamp), published on the profile root. Clients migrate the pinned key when they see a valid succession signed by the key they currently trust. This handles proactive rotation and graceful response to suspected compromise.
- For actual compromise (attacker also holds the old key and can sign competing successions), a single self-signed statement can't resolve the race — this is where the web of trust could carry weight, e.g. connected profiles co-attesting the succession via their friends endpoints, giving clients a quorum signal.
- Either specify the social-fingerprint recovery scheme or remove/caveat its description in Overview.md until it exists.
I realize this is the hardest problem in the list and touches the protocol's core identity model; filing it primarily so the trade-off ("identity is sovereign" vs. "identity is one stolen laptop away from permanently gone") is explicitly on the record and discussable.
*Disclosure: this finding came out of an AI-assisted review of the spec; I have verified the cited sections against the current master text.*
The profile is its Ed25519 key pair (§1.1, §1.3). §1.3 requires clients to treat a key change under the same URI as a different profile and to warn the user. As specified, this means:
Additionally,
Overview.mddescribes a "social fingerprint" disaster-recovery scheme (depositing data packets with connected profiles, threshold re-authentication with friends to regain control of the key pair). As far as I can tell, this mechanism is not specified in SPXP-Spec.md, SPXP-PME-Spec.md, or SPXP-SPE-Spec.md. The overview currently promises a security property the protocol doesn't define.Suggested direction
I realize this is the hardest problem in the list and touches the protocol's core identity model; filing it primarily so the trade-off ("identity is sovereign" vs. "identity is one stolen laptop away from permanently gone") is explicitly on the record and discussable.
*Disclosure: this finding came out of an AI-assisted review of the spec; I have verified the cited sections against the current master text.*