Decentralized Identifiers
A Decentralized Identifier, or DID, is a URI associated with a subject and resolved through a DID method. The resolved DID document can publish verification methods, relationships between keys and purposes, and service information used for trusted interaction.
In UbID, a DID is an identifier and a source of public verification material. It is not a complete personal profile, a credential, an authenticated web session, or proof that every claim associated with the subject is true.
The problem DIDs solve
Traditional identifiers are frequently meaningful only inside the database of the organization that created them. A DID provides a common identifier model that can be resolved by compatible systems and can support proof of control through cryptographic verification methods.
This allows an issuer, holder service, verifier, or authorized agent to refer to an identity endpoint without requiring all participants to share one account directory.
DID, DID method, and DID document
These concepts are related but distinct:
| Concept | Meaning |
|---|---|
| DID | The identifier itself, expressed as a URI. |
| DID method | The rules for creating, resolving, updating, and deactivating identifiers of a particular type. |
| DID document | The resolved data associated with the DID, such as verification methods and service references. |
| DID URL | A reference to a particular resource, key, or service associated with a DID. |
| Controller | The entity able to make authorized changes or prove control according to the DID method. |
UbID uses did:web where web-domain governance and standard HTTPS discovery provide an appropriate institutional trust model. The method choice does not imply that personal data or private keys are published on the Web.
Verification methods and relationships
A DID document can identify public cryptographic material and state the purposes for which it may be used. Examples of verification relationships include authentication, assertion, key agreement, and capability-related purposes.
A verifier must not treat every key in a DID document as valid for every operation. The declared relationship, key status, algorithm policy, credential profile, and verification context all matter.
Resolution is not trust
Successful DID resolution proves only that a resolver obtained a document according to a method and resolution process. It does not automatically prove that:
- the subject was identity-proofed;
- the controller is authorized to issue a particular credential;
- the resolved domain is approved by the verifier;
- the key is allowed for the requested purpose;
- a credential is current or accepted by policy;
- the holder is entitled to the requested service.
Trust is established by combining resolution with issuer governance, cryptographic verification, status, context, assurance, and policy.
Rotation and continuity
Identifiers and keys have different lifecycles. A stable DID can reference new verification material after key rotation, while historical evidence may still need to be validated against the state and rules applicable when it was created.
A controlled implementation should define:
- authorized update procedures;
- key activation and retirement states;
- overlap during rotation;
- cache and refresh behavior;
- handling of deactivation or resolution failure;
- evidence required to investigate historical signatures.
The public documentation does not disclose UbID's operational rotation procedures or production key identifiers.
Privacy considerations
DIDs can improve portability, but a single long-lived identifier used across unrelated contexts can also create correlation risk. UbID therefore favors scoped identifiers and purpose-specific disclosure where the ecosystem permits them.
A DID document should not become a directory of personal attributes, credential inventories, biometric data, recovery participants, or transaction history.
Relationship with credentials and sessions
- A DID identifies and publishes controlled verification material.
- A verifiable credential contains claims made by an issuer.
- SD-JWT can support selective disclosure of credential claims.
- OpenID Connect establishes an authenticated application session.
- OAuth authorizes bounded API access.
- DIDComm protects identity-bound messages.
These layers complement one another; none should be substituted for the others without an explicit profile.
UbID position
DID Core and did:web are part of the implemented and reference baseline for UbID identity and issuer discovery. Exact methods, verification relationships, key types, and service entries are governed per product and environment.
This page is not a claim that every UbID participant exposes a DID or that every credential depends on the same DID method.
Source standards
See Verifiable Credentials and SD-JWT and DIDComm.