Identity Hub

The foundational identifier for an Identity Hub. A Decentralized Identifier (DID) is a globally unique, cryptographically verifiable identifier that is not issued by a central authority. It is the root key for all user data and interactions within the hub.

• Example: did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
• Key Property: Enables self-sovereign identity, where the user has ultimate control.

The primary data format stored and managed by the hub. Verifiable Credentials are tamper-evident digital claims (like a driver's license or university degree) issued by trusted entities. The hub acts as a personal wallet for these credentials.

• Structure: Contains claims, metadata, and a cryptographic proof from the issuer.
• Use Case: A user can store a KYC credential from one service and present it to another without revealing unnecessary personal data.

Identity Hubs use a decentralized storage layer, often based on InterPlanetary File System (IPFS) or personal cloud servers, to host user data. Data is encrypted and replicated across multiple nodes for availability and censorship resistance.

• User Control: The user holds the encryption keys, not the storage provider.
• Synchronization: Hubs can sync data across a user's devices, ensuring a consistent identity state.

A core architectural component that handles secure communication and access control. This layer manages permissions (who can read/write data) and facilitates encrypted messages between DApps and the hub.

• Protocols: Often implements standards like DIDComm for secure messaging.
• Consent: Users grant and revoke fine-grained permissions (e.g., "App X can read my email credential for 30 days").

To ensure interoperability, data within the hub conforms to publicly defined schemas. These schemas standardize the structure of Verifiable Credentials and other data objects, allowing different applications to understand the data's meaning.

• Example: A UniversityDegreeCredential schema defines fields for degreeType, awardingInstitution, and awardDate.
• Registry: Schemas are often published on a verifiable data registry, like a blockchain.

Applications interact with a user's Identity Hub through a standardized Software Development Kit (SDK) or a user's agent (a background service). This abstracts the complexity of decentralized storage and cryptography for developers.

• Function: The agent handles key management, signing, encryption, and network communication on behalf of the user.
• Example: A wallet app often contains the user's primary agent software.

Securely stores and presents Verifiable Credentials (VCs)—tamper-proof digital attestations like diplomas, licenses, or KYC proofs. Key functions include:

• Selective disclosure: Prove specific claims (e.g., age > 18) without revealing the entire credential.
• Credential issuance & revocation: Receive VCs from issuers and manage their validity status.
• Interoperability: Exchange credentials using standards like W3C Verifiable Credentials.

Replaces traditional usernames/passwords with cryptographic proofs. The hub enables:

• Passwordless login: Sign into dApps and services using a cryptographic signature.
• Role-based access: Present credentials to prove membership, qualifications, or access rights.
• Session management: Control which applications have access to specific identity data and for how long.

Aggregates on-chain and off-chain activity to build a portable reputation profile. This supports use cases like:

• Under-collateralized lending: Prove creditworthiness via transaction history or income streams.
• Governance: Demonstrate contribution history for weighted voting rights.
• Sybil resistance: Uniquely identify users to prevent spam and airdrop farming in communities.

Gives users agency over their personal data, allowing them to grant or revoke access. This enables:

• Monetized data sharing: Users can sell or license specific data streams to researchers or advertisers.
• Auditable consent logs: Transparent, immutable records of who accessed what data and when.
• Compliance: Facilitates adherence to regulations like GDPR through user-centric data control.

A Decentralized Identifier (DID) is a globally unique, cryptographically verifiable identifier that is controlled by its subject (e.g., a person, organization, or device) without reliance on a central registry. It is the foundational address for an Identity Hub. DIDs are typically stored on a blockchain or other decentralized network, enabling self-sovereign identity.

• Structure: did:method:method-specific-identifier (e.g., did:ethr:0x...).
• Control: Proved via cryptographic private keys.
• Purpose: Serves as a persistent, non-revocable root for a user's identity data.

A Verifiable Credential (VC) is a tamper-evident digital credential whose authorship and integrity can be cryptographically verified. It is the primary data object stored and managed by an Identity Hub. A VC is issued by an issuer (e.g., a university) to a holder (the user) and can be presented to a verifier (e.g., an employer).

• Key Components: Metadata, claims about the subject, and cryptographic proofs.
• Standard: Based on the W3C Verifiable Credentials Data Model.
• Example: A digital driver's license or university degree certificate.

A Verifiable Presentation (VP) is a package of one or more Verifiable Credentials that a holder (user) presents to a verifier. The Identity Hub facilitates the creation and secure transmission of VPs. It allows for selective disclosure, where the holder can reveal only specific attributes from a credential without exposing the entire document.

• Function: Proves control over credentials and satisfies a verifier's request.
• Privacy: Can use zero-knowledge proofs (ZKPs) to prove statements (e.g., 'I am over 21') without revealing the underlying data.

Self-Sovereign Identity (SSI) is a model for digital identity where individuals or entities have sole ownership and control over their identity data, without relying on central authorities. An Identity Hub is the user-agent component that operationalizes SSI principles.

• Core Principles: User control, portability, interoperability, and consent.
• Architecture: Built on DIDs, VCs, and decentralized data storage.
• Contrast: Differs from federated (e.g., 'Login with Google') and centralized identity models.

Decentralized Data Storage refers to the method of storing the actual data referenced by an Identity Hub, such as credential metadata or personal profiles, on peer-to-peer networks rather than centralized servers. This ensures data availability, portability, and resilience.

• Common Protocols: InterPlanetary File System (IPFS), Ceramic Network, or personal cloud servers.
• Mechanism: The Identity Hub stores only encrypted data or data hashes, with DIDs providing the access control layer.
• Benefit: Prevents vendor lock-in and single points of failure.

DIDComm is a secure, peer-to-peer messaging protocol built on DIDs and public key cryptography. It is a key transport layer for Identity Hubs, enabling private communication between identity agents (e.g., between a user's wallet and a verifier's service).

• Function: Used for issuing VCs, requesting VPs, and general secure messaging.
• Security: Provides end-to-end encryption, authentication, and replay protection.
• Standard: Developed under the Decentralized Identity Foundation (DIF).