Identity

The Morel Protocol adopts a privacy-first approach to identity while maintaining flexibility and security in a decentralized network. Below are the key requirements for identity in the Morel Protocol:

  1. Privacy-First Policy, User identifiers must prioritize privacy by default, avoiding the unnecessary surfacing of personally identifiable information (PII) or metadata that can link actions to specific users.
  2. Stable Identification Across Services, Users should be able to maintain consistent identities across multiple services within the network, enabling seamless interaction and recognition while preserving privacy.
  3. Minimized Trackability of Identifiers, The design should limit the ability to track users or correlate their activities across different connections or services unless explicitly authorized by the user.
  4. Rotatable Identifiers, Users must have the ability to rotate their identifiers, with options to rotate on a per-connection basis to enhance security and privacy.
  5. Service Discovery, Applications and services must be able to discover the services a user interacts with while respecting privacy controls and permissions.
  6. Portability, Users should be able to port their identity across nodes within the network, ensuring seamless access to services and data.
  7. Stable Public Identifiers for Public-Facing Entities, Public entities such as organizations, projects, and services should have stable public identifiers to facilitate discovery and interaction.
  8. User-Friendly Management, Identity creation, rotation, and management must be simple and intuitive for users, ensuring accessibility without sacrificing security.

Identifiers

We use two interrelated forms of identifiers: the handle and the DID. Handles are 3words seperated by a dot or DNS names while DIDs are an emerging W3C standard which act as secure & stable IDs.

The following are all valid indentifiers:


roblox.com
quite.three.path
hcn://quite.three.path
hcn://did:hcn:bh8hhgg5fth7f3fgfgh9hnwd

The relationship between them can be visualized as:


┌──────────────────┐                 ┌───────────────┐
│3words | DNS name ├──resolves to──→ │ DID           │
│(quite.three.path)│                 │ (did:hcn:...) │
└──────────────────┘                 └─────┬─────────┘
    ↑                                      │
    │                                  resolves to
    │                                      │
    │                                      ↓
    │                               ┌───────────────┐
    └───────────references──────────┤ DID Document  │
                                    │ {"id":"..."}  │
                                    └───────────────┘

The handle is a user-facing identifier — it should be shown in UIs and promoted as a way to identify users. Applications resolve handles to DIDs and then use the DID as the stable canonical identifier. The DID can then be securely resolved to a DID document which includes public keys and user services.

Handles

Handles are 3words or DNS names. They are resolved using the ac.hcn.identity.resolveHandle method and should be confirmed by a matching entry in the DID document. Dtails in the (Handle specs)[/morel-protocol/handle].

DIDs

DIDs are an emerging W3C standard for providing stable & secure IDs. They are used as stable, canonical IDs of users. Details of how they are used in the Morel Protocol can be found in the DID specification.

DID Documents

DID Documents are standardized objects which are hosted by DID registries. They include the following information:

  • The handle associated with the DID.
  • The signing key.
  • The URL of the user’s service-agent.
  • The URL of the user’s didcomm-agent.

DID Methods

The DID standard supports custom “methods” of publishing and resolving DIDs to the DID Document. A variety of existing methods have been published so we must establish criteria for inclusion in this proposal:

  • Strong consistency. For a given DID, a resolution query should produce only one valid document at any time. (In some networks, this may be subject to probabilistic transaction finality.)
  • High availability. Resolution queries must succeed reliably.
  • Online API. Clients must be able to publish new DID documents through a standard API.
  • Secure. The network must protect against attacks from its operators, a MITM, and other users.
  • Low cost. Creating and updating DID documents must be affordable to services and users.
  • Key rotation. Users must be able to rotate keypairs without losing their identity.
  • Decentralized governance. The network should not be governed by a single stakeholder; it must be an open network or a consortium of providers.

When we started the project, none of the DID methods met our standards fully. Therefore, we chose to support did-web, and introduced a novel method called DID:HCN, which we aim to implement using the KERI framework for enhanced security.

Handle Resolution

Handles in the Morel protocol are 3words and domain names which resolve to a DID, which in turn resolves to a DID Document containing the user’s signing pubkey and agent services.

Handle resolution uses the ac.hcn.identity.resolveHandle method. The method call should be sent to the server identified by the handle, and the handle should be passed as a parameter.

Here is the algorithm in pseudo-JS:

async function resolveHandle(handle) {
    const origin = `hcn://${handle}`;
    const res = await xrpc(origin, 'ac.hcn.identity.resolveHandle', { handle });
    return res.did;
} /* => did:hcn:bh8hhgg5fth7f3fgfgh9hnwd*/

Then we resolve the DID to a DID Document:

async function resolveDID(did) {
    const origin = `hcn://${did}`;
    const res = await xrpc(origin, 'ac.hcn.identity.resolveDID', { did });
    return res.doc;
} /* => {
    alsoKnownAs: `hcn://quite.three.path`,
    verificationMethod: [...],
    service: [
        {
            id: did:hcn:bh8hhgg5fth7f3fgfgh9hnwd#didcomm,
            serviceEndpoint: 'https://e1.hcn.didcomm.network',
            type: 'DIDCommMessaging',
        },
        {
            id: did:hcn:bh8hhgg5fth7f3fgfgh9hnwd#hcn_service,
            serviceEndpoint: 'https://service.e1.humancloud.network',
            type: 'ServiceEndpoint',
        },
    ]
    ...
}*/

And finally we can use the DID document to interact with a user.

/* Create credential from template*/
/* Sign credential*/
/* send credential */
async function sendCredential(did, credential) {
    const doc = await resolveDID(did);
    const res = await xrpc.agent(doc).ac.hcn.didcomm.send({ credential });
    return res;
}

Transition to Industry Standards

As we envision the evolution of decentralized identity systems, we foresee a gradual transition where identities will increasingly be managed by external identity vaults beyond the Morel Protocol. This shift aligns with the maturation of industry standards for self-sovereign identity (SSI), which are expected to provide robust frameworks for privacy, interoperability, and user control.

We will continuously review this section to ensure alignment with these emerging standards and will initiate a transition to adopt industry standards for SSI as soon as they mature and fulfill the stringent privacy, security, and usability requirements of the Morel Protocol. This approach ensures that Morel remains at the forefront of identity innovation while adapting to the broader ecosystem.

Overview