The lifeID DID method specification conforms to the requirements specified in the DID specification currently published by the W3C Credentials Community Group. For more information about DIDs and DID method specifications, please see the DID Primer
lifeID is a decentralized, blockchain-based protocol that acts as an open identity provider. The protocol enables the creation and use of self-sovereign identities as well as the issuance of verifiable credentials to those identities. The blockchain-based components of the protocol include smart contracts for storage, revocation, and recovery of keys and credentials. These contracts may be run on any open, permissionless blockchain. The purpose of this protocol is to allow users to transact their identity in a way that minimizes data disclosure, is cryptographically secure, and enables censorship-resistant decentralized identity provisioning and recovery. The purpose of this specification is to describe how lifeID DIDs are created and the technical requirements to operate on the lifeID platform.
The lifeID DID method scheme follows the following conventions
An encoded lifeID DID contains three parts. A lifeID DID MUST contain the following prefix
did:life:
This indicates that you are presenting a standardized DID according to the specification outlined by the World Wide Web Consortium ("W3C"), belonging to the DID method name "life", and generated using the lifeID protocol (see "Creating, Reading and Updating lifeID DIDs" below). Per the DID specification, the string MUST be in lowercase.
The remainder of the did looks like this
7f8ca8982f6cc6e8ea087bd9457ab8024bd2...
For a DID created on the lifeID network to be considered valid, the decoded DID MUST include five parts, and the parts MUST be in the following order: a version number, network ID, type, public key, and checksum.
The version number: The version number is a single byte indicating which version of the lifeID DID method the DID is using. It will start at "1" to indicate version "1" and may be updated in the future as the DID method is revised.
The network ID: The network ID is a four-byte identifier that indicates where the DID is stored and publically accessible. lifeID will recommend a specific distributed ledger which lifeID holders SHOULD use. lifeID will implement a registry of network IDs, and the registry will be public and discoverable.
The type: The type is a single byte identifying the type of DID created. The current available values are "1" for an individual, "2" for any kind of organization (such as a corporation or non-profit), and "3" for any kind of physical device.
The public key: The public key is a cryptographic public key that can be used to prove ownership of the DID: the entity that controls the associated private key will be able to utilize that private key to authenticate as the DID's owner.
The checksum: The checksum is a SHA3-256 digest of the first four parts of the DID (i.e., version number, network ID, type, and public key). The checksum provides an easy way to check whether or not the DID has been modified.
These five parts together comprise the decoded specific-idstring. A decoded DID does not contain any more or less information than an encoded DID. Decoding a DID simply means converting its single encoded string format (the DID) into parsed JavaScript Object Notation, or JSON (the DID Document).
validDidData = {
key: "112341123dfdf9098098231233...",
version: "1",
network ID: "1234",
type: "1",
public key: "123dfdf909809823...",
method: "lifeID"
};
A decoded DID contains all of the information necessary to locate a DID's corresponding DID Document. Next we describe how DIDs are created, decoded, and updated, and then we describe lifeID DID Documents.
LifeID provides an open-source tool called the lifeid-did Library, for creating, decoding, and updating DIDs. It is available here.
We note that an encoded lifeID DID already contains all the data necessary to obtain the location of its corresponding DID Document, thus it is not necessary to perform a lookup to retrieve additional information. When using the did:life: method, the only difference between a DID and a DID Document is whether it is displayed as a hex-encoded string (DID) or a utf-8 encoded JSON (DID Document). The difference is relevant because normal Create, Read, Update and Delete (“CRUD”) operations do not strictly apply to the lifeID DID method. The process required to to delete a DID, for example, will depend on where the DID is stored. lifeID is implementing an API to store DIDs in a distributed ledger where public trust in a recovery mechanism is necessary; while lifeID DID holders SHOULD use the recommended ledger, they MAY store lifeID DIDs anywhere they choose.
All lifeID DIDs have a corresponding DID document.
{
"@context": "string",
"id": "string",
"name": "string",
"entityType": "string",
"created": "string",
"updated": "string",
"publicKey": [
{
"id": "string",
"type": "string",
"owner": "string",
"publicKey": "string",
"ethereumAddress": "string",
"publicKeyHex": "string"
}
],
"authentication": [
{
"type": "string",
"publicKey": "string"
}
],
"service": [
{
"type": "string",
"serviceEndpoint": "string"
}
]
}
lifeID DID holders MAY register their DIDs, and corresponding DID Documents, in the recommended official distributed ledger. If the owner chooses to register their DID in the recommended ledger, they will be able to recover their DID in the event that its private key is lost. If a DID is not registered in the recommended distributed ledger, its owner will be responsible for a recovery mechanism of their choice in the event of private key loss and is completely responsible for providing the DID Document anytime the owner wishes to prove ownership.
The distributed ledger that the lifeID api gateway connects to and stores DIDs
is currently Ethereum. However, we anticipate that the official storage method
and recovery smart contracts will exist on a different blockchain by the time
the network is live. The top candidate to replace Ethereum is currently RChain.
A lifeID DID holder MAY store their DID on a distributed ledger for ease of access and recovery.
It is RECOMMENDED that lifeID holders use the lifeID api-bridge to register their DIDs on the distributed ledger. It presents a restful interface with the methods below. Documentation is available here.
The API to Distributed Ledger Interface
The purpose of a distributed ledger for storing DIDs, DID Documents, and smart contracts is to enhance privacy, security and convenience for users. The API bridge enables access to a system of lifeID protocol smart contracts that can be run on any open, permissionless blockchain. The smart contracts that make up the lifeID protocol will include the following endpoints and methods:
Create, read, update and delete DIDs in the ledger. Once a DID is in the ledger, its owner can prove her identity at any time by showing that she has its corresponding private key.
Organization DID Registry Smart ContractCreate, read update and delete DIDs in the ledger as a trustee acting on the behalf of those DIDs.
LifeID Token Smart ContractsMint and transact lifeID Tokens which exist to provide an incentive to maintain the decentralized network that supports the ledger.
Verifiable Credential Revocation Smart ContractIssuers may revoke a previously issued verifiable credential. A credential can be made revocable by adding a method to check this list to the credential itself. If the issuer wishes to later revoke the credential, they may add it to the list and anyone examining the credential will be able to see that it has been revoked.
Governance Smart ContractsThe contracts that govern the updating of all of the other contracts on the platform. The governance contracts ensure that all of the above contracts are only modified under certain, publically available conditions.
lifeID's choice of official ledger and its smart contract implementation will always be made with self-sovereign identity as a top priority. A distributed ledger is only useful to us insofar as it achieves our goals of privacy, security and convenience for users.
lifeID DID encoding and decoding, as well as the lifeID API bridge, are carefully and securely constructed. This work-in-progress section will discuss, per the requirements listed in the DID Specification, the following areas pertaining to security.
Requirements listed in the Internet Engineering Task Force (IETF) RFC3552, "Guidelines for Writing RFC Text on Security Considerations", section 5 ("Security Considerations Guidelines"):
Requirements listed in the W3C DID Specification:
LifeID conducts all engineering considering AT LEAST the folloiwng security risks. They will be discussed more thoroughly in a future version.
The lifeID DID method is architected to ensure reduced correlation risk, increased anonymity, and improved selective sharing for users' self-sovereign identities. This work-in-progress section will discuss, per the requirements listed in the DID Method Specication, the following specific and general areas pertaining to privacy. Terms of use of verifiable credentials will also be discussed, and we will consider whether or not any of the following requirements listed in the Internet Engineering Task Force (IETF) RFC6973, "Privacy Considerations for Internet Protocols", section 5 ("Privacy Threats") apply in a lifeID method-specific way: