Authentication
Documented architectureEstablishes which subject or agent is presenting itself. It answers who, and nothing more. Holding a key proves control of that key, not entitlement.
Operations
Security & Threat Model
Documented architecture
The security structure as designed: objectives, boundaries, invariants, threat categories and the questions still open. No component has been audited, penetration-tested, formally verified or certified, and no security guarantee is offered.
- Source / verification
- Internal design notes, not yet supplied for verification
- Document version
- Not yet assigned
- Last reviewed
- 19 September 2026
Explicitly not done
- External security audit
- Not performed
- Penetration test
- Not performed
- Formal verification
- Not performed
- Certification
- None held
- Bug bounty
- Not operating
- Incident history
- No systems to have incidents
Security objectives
- Integrity of history — an accepted record cannot be silently altered or removed.
- Attributable authority — every consequential action traces to an authority that was valid at the time.
- Minimal disclosure — verification should not require exposing unrelated source data.
- Reconstructability — an independent party can rebuild the outcome from retained evidence.
- Containment — compromise of one component must not confer authority elsewhere.
Trust boundaries
| Boundary | Crossing data | Assumption |
|---|---|---|
| Subject → identity layer | Credential presentation and proofs. | Issuer and revocation status are independently checkable. |
| Identity → authorization | Eligibility and mandate proofs. | A proof grants only the scope it names. |
| Governance → protocol | Authorized rules and role grants. | Authority records are current and verifiable. |
| Protocol → storage | Anchors and evidence references. | Anchors commit to evidence without disclosing it. |
| Protocol → interfaces | Read responses and submissions. | Interfaces are replaceable and hold no authority. |
| Protocol → external chains | Bridge references, where ever adopted. | External finality and custody are weaker assumptions than internal ones. |
Authentication versus authorization
Authorization
Documented architectureEstablishes whether that subject may perform this action, under this rule version, within this scope and period. It is granted explicitly and never inferred from authentication.
Identity-bound permissions
Documented architecturePermissions attach to a verified identity and an authorized mandate together. Transfer of a key does not transfer a mandate.
Account and key distinction
Documented architectureAn account is the accounting subject; a key is a control mechanism over it. Key rotation must be possible without a change of subject.
Key and account security
- Key custody model, rotation procedure and recovery path are not decided.
- No hardware, wallet, signature scheme or curve is specified or endorsed here.
- Loss and compromise handling is a requirement without a written procedure.
- Administrative keys, if any exist in an implementation, must be enumerated and their powers bounded and logged.
Protocol and administrative authority assumptions
Any implementation will start with more administrative power than the end-state model intends. That gap must be stated, not hidden: which powers exist, who holds them, how their use is recorded, and how they are reduced over time. No such power is currently held, because nothing is deployed.
Threat categories
| Category | Intended mitigation | Open question |
|---|---|---|
| Unauthorized state change | Explicit authority checks against authorized rule versions. | Enforcement mechanism not implemented. |
| History rewriting | Append-only entries with linked compensating corrections and epoch anchors. | Anchor cadence and snapshot format to be specified. |
| Credential forgery or replay | Scoped, verifiable proofs with issuer and status checks. | Credential and revocation formats undecided. |
| Key compromise | Bounded scope, revocation, and rotation independent of subject identity. | Custody and recovery model undecided. |
| Operator collusion | Named accountability, independent observers, reconstructable evidence. | Operator set and removal path undecided. |
| Evidence loss or unavailability | Replicated retention with content-addressed references. | Retention obligations and durability rail not fixed. |
| Bridge and cross-chain downgrade | Treat external references as weaker evidence; no reliance on them for internal integrity. | No bridge exists; conditions for adopting one unwritten. |
| Interface substitution or spoofing | Interfaces hold no authority; verification is possible without them. | Independent verification tooling not built. |
| Privacy overreach | Minimal disclosure and selective presentation. | Data classification not completed. |
Security invariants
- No accepted entry is mutated; correction happens through a linked entry.
- No action is authorized without a rule version and an authority reference.
- No interface is ever the source of truth.
- No proof grants scope beyond the one it names.
- No administrative power exists without being enumerated and recorded.
- No verification step requires disclosure of unrelated source data.
These are stated constraints for an implementation, not properties of a running system.
Data and storage considerations
Anchors are public and compact; durable evidence stays under explicit custody and retention control. Classification of which material may be anchored, which may be referenced and which may never leave custody is an open item, and is a prerequisite for any storage rail decision.
Scope of this platform
This site is documentation. It holds no accounts, no payment data and no member records; those belong to ByteShares.dk and are outside the scope of these pages.
Reporting a problem
A coordinated disclosure process will be published together with the first release of running software, including a contact route and a response commitment. No contact address is listed yet, because publishing one before anyone is on the other end would be misleading.
Evidence register
Each statement on this page is tracked against a source. A claim without a verified source is never presented as fact.
| Claim | Source type | Verification | Note |
|---|---|---|---|
| Security objectives, boundaries and invariants | Internal design notes | Source claimed, not yet verified | Notes to be supplied for verification; structure drafted from owner instruction. |
| Threat categories and mitigations | Threat model document | No source on file | No completed threat model exists; the table is a structure to be filled, not findings. |
| Any audit, test, certification or clean bill of health | Audit report | No source on file | No report exists; no assurance is given. |