Skip to main content

Blockchain Position

Review status: This foundation page requires specialist review before public approval. Its claims must remain within the scope stated here.

Blockchain is a structural trust component in the UbID identity model, providing a verifiable linkage between a holder's public cryptographic identity and a blockchain address. This linkage can support proof of control, public verification references, and continuity across compatible services without revealing the holder's private key.

The blockchain does not encrypt, store, or recover the private key. The private key remains under the holder's control in protected custody.

Public linkage, private custody​

UbID separates public verifiability from private identity material:

May be publicly verifiableMust remain off-chain
Public cryptographic identifiers and approved verification referencesPrivate keys and recovery secrets
Public keys or resolvable verification material where appropriateCredentials and undisclosed claims
Narrowly scoped integrity or status references where justifiedPersonal profiles and source documents
Institutional issuer referencesBiometric images, templates, and liveness data
Public policy or trust metadata intended for discoveryPresentation history and transaction behavior

No public blockchain should become a universal personal-data repository.

What a blockchain reference proves​

A ledger event or commitment can demonstrate that a specific public reference or cryptographic commitment existed in relation to the ledger at a given point. It does not, by itself, prove that:

  • the underlying identity evidence was accurate;
  • a source document was genuine or lawfully obtained;
  • the person was properly proofed;
  • the issuer was authorized to make the claim;
  • the credential remains current;
  • the presenter is the intended holder;
  • a verifier's policy was satisfied.

Those properties come from issuer governance, proofing, credential signatures, status, holder binding, and verification policy.

Not every interaction is an on-chain transaction​

The blockchain relationship is part of the UbID cryptographic identity profile, but ordinary credential issuance, custody, selective presentation, and verification should not require publishing personal transaction details to a public ledger.

A verifier can validate a credential through its signature, issuer material, status, presentation context, and policy without learning or publishing every use of the credential on-chain.

Privacy safeguards​

Where a ledger reference is used, it should avoid predictable personal-data hashes and long-lived correlation identifiers. A plain hash of a document containing predictable fields can sometimes be tested by an observer and should not be treated as anonymous.

Public ledger designs should therefore avoid:

  • raw personal data;
  • direct hashes of predictable identity fields;
  • biometric material;
  • recovery components;
  • revocation reasons;
  • wallet inventories;
  • credential presentation histories;
  • stable cross-context transaction identifiers.

The associated legal basis, purpose, retention, rights workflow, and dispute process remain off-chain under institutional governance.

Blockchain is not synonymous with cryptoassets​

Using cryptographic keys, decentralized identifiers, verifiable credentials, or a blockchain-linked address does not by itself create a token, payment instrument, security, exchange, custody service, or investment product.

Any future feature involving transferable value, asset custody, trading, payment, or regulated cryptoasset activity requires separate legal classification, keys, governance, risk controls, and incident procedures.

Identity recovery must never be presented as authority to recover or transfer a holder's financial assets.

Relationship with other controls​

Blockchain does not replace:

Public documentation boundary​

This page explains UbID's public architectural position. It does not publish addresses linked to real people, private network configuration, anchoring formats, transaction policies, customer ledgers, key derivation paths, or financial-service designs.