Participant identity
Development status: Being explored — The design is being explored; its public interface and support are not settled. The intended design keeps a person’s or organisation’s identity separate from the keys, wallets and readable names that act for it, so that keys could be rotated, or recovered through a path arranged in advance, without changing the identity; participant identity is not implemented in the experimental prototype. Nothing is publicly available for live use.
Before you read: Identity, keys and access: concepts.
What is a participant’s identity, and how would it stay stable when keys or names change? In the intended design, a participant identity is the stable identity of a person or an organisation. Keys, wallets and readable names act for it, but none of them is the identity — so keys and names could change while the identity, and what it is responsible for, stays the same. None of this is implemented today. This page explains the intended separation, how it would allow key rotation and pre-arranged recovery, what a readable name is and is not, and the situations the design is meant to handle.
What participant identity is intended to be
In this documentation, a participant identity always means the identity of a person or an organisation that uses the network. It is intended to be a stable identity that keeps its responsibilities over time.
Three points define the intended concept:
- What acts for an identity is not the identity. Keys, wallets and readable names act for an identity; none of them is the identity.
- The identity outlasts its keys. The identity is intended to stay the same when its keys change.
- Responsibilities stay with the identity. What an identity is responsible for is intended to stay with it, rather than with whichever key happens to be in use.
How identities would be created, identified or represented is not described.
What acts for an identity
Several things would act for an identity, each with a narrower role:
- Keys — cryptographic keys used to act for the identity, for example to sign. An identity could have different keys over time; how keys would be created, rotated and revoked is described on Key lifecycle: creation, rotation and revocation.
- Wallets — software that holds keys and uses them to sign. A wallet is not the identity, and replacing a wallet is intended not to change the identity; see Wallets and the experimental wallet prototype.
- Readable names — labels that point to an identity. A name would carry no funds or permissions, and changing it would not change the identity it points to.
- Approval authority — who may approve sensitive actions for an identity is separate from which key signs day to day; see Approving actions: authority and multi-party approval.
Keeping identity stable: rotation and recovery
Status of this section: Being explored — not implemented.
The separation between an identity and its keys is what would make two important operations possible.
Rotation means replacing keys — for example, when staff change or a device is retired — without changing the identity.
Recovery concerns losing keys. The design is being explored for pre-arranged recovery of an identity after key loss, so that the identity keeps its obligations. Its intended limits are as important as the capability itself:
- Recovery would only be possible through a path configured in advance. Where none is configured, recovery would not be possible.
- Recovery would restore the ability to act for the identity with new keys. It would not recover encrypted data.
- Recovery is not a rescue service: no one would be able to restore access on request without a path arranged beforehand.
- Recovery procedures are not described.
Situations this is intended to handle
Once this capability is implemented, enabled and publicly released, the separation between identity and keys is intended to handle situations such as these:
- A departing employee. An organisation replaces the keys held by an employee who is leaving. The organisation’s identity and responsibilities stay the same.
- A lost device. A person loses a device. With a recovery path arranged in advance, they could regain the ability to act for their identity; without one, they could not.
- A suspected compromise. A key suspected of being compromised would be withdrawn and replaced while the identity continues; see Key lifecycle: creation, rotation and revocation.
- A renamed label. A readable name is changed. Nothing it points to moves, and no funds or permissions change hands.
What exists today
- Participant identity, readable names and recovery are not implemented in the experimental prototype.
- Keys and addresses used in the experimental implementation are not identities in the sense described here.
- Account and address conventions are still being settled and are not yet documented.
- No naming service exists.
Assumptions, trust and limitations
- Names can mislead. Readable names can look alike, so a name alone should not be trusted to identify someone.
- Recovery depends on preparation. Recovery would depend on the arrangement chosen in advance. Without one, losing keys could mean losing the ability to act for the identity.
- Nothing is enforced today. None of the behaviour described here is enforced in the experimental implementation, and how it would be enforced is not described.
- Terminology may change. The identity terms used here may change as public terminology is settled.
Not yet available, and how this page will grow
Identifier formats, naming rules and recovery procedures are not yet available. Further technical reference is not yet available. Once implemented and released, this page would describe how identities are created and maintained, with versioned reference. Glossary definitions of the identity terms may change, and any change would be recorded in the Documentation change log.
What this page does not claim
This page does not describe any identifier format or naming service, it claims no recovery beyond a path configured in advance, and it does not claim that recovery would restore encrypted data. It does not claim that participant identity exists today. Anything not stated here as available should be treated as unavailable.
Related pages
- Identity, keys and access: concepts — the section overview separating identity, keys, wallets, names and authority.
- Wallets and the experimental wallet prototype — wallets hold keys; they are not the identity.
- Key lifecycle: creation, rotation and revocation — how keys would be rotated and revoked under policy.
- Approving actions: authority and multi-party approval — approval authority, separate from everyday signing.
- Participants and roles — users and organisations among the planned roles.
Glossary
References
No approved public references yet.
