Identity, keys and access: concepts
Development status: Overview — Each concept in this section carries its own label: an experimental wallet prototype exists for local and internal testing only; participant identity, readable names, custody choices and multi-party approval are being explored; and a policy-governed key lifecycle is planned. Apart from the wallet prototype, none of these exists in the experimental implementation, account and address conventions are still being settled, and nothing is publicly available for live use.
Before you read: System model: how Cubane is intended to work for its users.
How are identities, keys, wallets and approvals intended to relate to each other? These ideas are easy to run together — an identity treated as its key, a user treated as their wallet. Cubane’s intended design keeps them apart. This page separates the concepts, gives each its status and primary page, and corrects the most common conflations before you read further.
Why these concepts are kept separate
When an identity is defined by a single key, replacing or losing that key changes or loses the identity. Everything attached to it — responsibilities, obligations, relationships with others — is then tied to one secret that may one day need replacing.
The intended design avoids this by keeping a person’s or organisation’s identity separate from the keys, wallets and readable names that act for it. Keys could then be rotated, or recovered through a path arranged in advance, without changing the identity.
Two further concepts are kept separate as well:
- Approval authority. Being able to sign is not the same as being authorised to approve. The authority to approve a sensitive action is intended to be separate from the key used for day-to-day signing.
- Visibility. Who may see data is intended to be controlled separately from who may act on it; see Visibility controls and selective disclosure.
The concepts at a glance
Table: identity and access concepts, their intended meaning, status and primary page.
| Concept | Intended meaning | Status today | Primary page |
|---|---|---|---|
| Participant identity | The stable identity of a person or organisation, separate from the keys, wallets and readable names that act for it | Being explored — not implemented | Participant identity |
| Keys | Cryptographic keys that act for an identity, created, rotated and revoked under policy | Planned — not implemented | Key lifecycle: creation, rotation and revocation |
| Wallet | Software that holds keys and uses them to sign for an identity | Experimental implementation exists — a prototype for local and internal testing; not released or supported | Wallets and the experimental wallet prototype |
| Readable name | A label that points to an identity and carries no funds or permissions | Being explored — not implemented | Participant identity |
| Custody | How the signing keys behind an organisation’s funds are held, for example by one party or by a group of parties | Being explored — not implemented; no custody service is described | Custody options for organisations |
| Approval authority | Who may approve sensitive actions, possibly requiring several authorised approvers, separate from everyday signing | Being explored — nothing enforces it | Approving actions: authority and multi-party approval |
How the concepts relate
Read together, the concepts fit as follows:
- An identity could have different keys over time.
- A wallet holds keys and uses them to sign for an identity.
- Readable names point to identities.
- Custody decides who holds the keys behind an organisation’s funds; approval authority decides whose agreement a sensitive action needs.
- Changing a key or a name is intended not to change the identity, or what it is responsible for.
- Holding a key does not by itself give authority to approve every action.
What exists today
Status of this section: Experimental implementation exists for the wallet prototype only; everything else in this section is planned or being explored.
- An experimental wallet prototype exists for local and internal testing. It is not released and is not a supported product.
- Participant identity, readable names, a managed key lifecycle, custody choices and multi-party approval do not exist in the experimental implementation.
- Account and address conventions are still being settled and are not yet documented.
- Nothing in the experimental implementation should be read as an identity in the sense described here, and key handling there must not be relied on for security.
Common misunderstandings to avoid
- “An address is an identity.” In the intended design, neither an address nor a key is an identity.
- “A wallet is who I am.” A wallet holds keys; it does not define who someone is.
- “A readable name owns something.” A readable name does not own funds or grant permissions.
- “If I can sign, I can approve.” Being able to sign is not the same as being authorised to approve.
- “If I can see it, I can act on it.” Being allowed to see data is not the same as being allowed to act on it.
Assumptions, trust and limitations
- These are intended concepts, and apart from the wallet prototype none is implemented. Names and definitions may change, and several of their glossary definitions are marked for review.
- How identities, keys and approvals would be enforced is not described.
- The experimental implementation is an early prototype and must not be relied on for security or production use.
Not yet available, and how this section will grow
Formats, interfaces, key types and procedures would be documented with a supported release; account and address conventions are still being settled. Further technical reference is not yet available. Each concept page would gain reference material and an updated status label once its capability is implemented and released. Glossary definitions for these concepts may change as public terminology is settled, and any change would be recorded in the Documentation change log.
What this page does not claim
This page does not describe any identifier, account or address format, any key type, or any recovery or custody service, and it claims no compatibility with other platforms’ accounts or wallets. Anything not stated here as available should be treated as unavailable.
Related pages
- Participant identity — the identity concept, readable names, rotation and recovery.
- Wallets and the experimental wallet prototype — what a wallet is for and the status of the prototype.
- Custody options for organisations — how the keys behind an organisation’s funds could be held.
- Key lifecycle: creation, rotation and revocation — how keys would be managed over time.
- Approving actions: authority and multi-party approval — authority to approve, separate from everyday signing.
- System model: how Cubane is intended to work for its users — the prerequisite overview of roles and stages.
- Participants and roles — users and organisations among the planned roles.
Glossary
References
No approved public references yet.
