Skip to content

Latest commit

 

History

History
149 lines (95 loc) · 6.63 KB

did-mailto.md

File metadata and controls

149 lines (95 loc) · 6.63 KB

did-mailto

Editors

Authors

Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Abstract

This specification describes "mailto" DID Method that conforms to the core DID-CORE specification. The method can be used independent of any central source of truth, and is intended for bootstrapping secure interaction between two parties that can span across arbitrary number of devices. It is suitable for long sessions that need to operating under network partitions.

Status of This Document

This document is draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organization.

Introduction

Overview

This section is non-normative.

Most documentation about decentralized identifiers (DIDs) describes them as identifiers that are rooted in a public source of truth like a blockchain, a database, or similar. This publicness lets arbitrary parties resolve the DIDs to an endpoint and keys. It is an important feature for many use cases.

However, the vast majority of interactions between people, organizations, and things have simpler requirements. When Alice(Corp|Device) and Bob want to interact, there are exactly and only 2 parties in the world who should care: Alice and Bob. Instead of arbitrary parties needing to resolve their DIDs, only Alice and Bob do.

One to one interactions are excellent fit for did:key identifiers, however they suffer from key discovery problem and introduce additional challenges when interaction sessions span across more than two devices.

Mailto DIDs are designed to be used in conjunction with did:key and facilitate bootstrapping sessions between two parties that span across multiple devices.

Mailto DIDs are more accessible alternative to did:web and did:dns because a lot more people have an email address than there are people with did:web or did:dns identifier or skills to acquire one.

Mailto did documents are also verifiable offline, when domain key of the email address is known, implying significantly less network requests than with most other DIDs.

The did:mailto Format

The format for the did:key method conforms to the DID-CORE specification and is encoding of the email address. It consists of the did:mailto: prefix, followed by the domain part of an email address, : character and percent encoded local-part of the email address.

The ABNF definition can be found below. The formal rules describing valid domain-name syntax are described in RFC1035, RFC1123, RFC2181. The domain-name and user-name corresponds to domain and local-part respectively of the email address described in RFC2822. All "mailto" DIDs MUST conform to the DID Syntax ABNF Rules.

did       = "did:mailto:" domain-name ":" user-name
user-name = 1*idchar
idchar    = ALPHA / DIGIT / "." / "-" / "_" / pct_enc
pct_enc   = "%" HEXDIG HEXDIG

EXAMPLE 1. [email protected]

did:mailto:example.com:jsmith

EXAMPLE 2. [email protected]

did:mailto:web.mail:tag%2Balice

Operations

The following section outlines the DID operations for the did:mailto method.

Create (Register)

There is intentionally no specification for publishing did:mailto documents as single source of truth are not implied. Same did:mailto identifier MAY (intentionally) correspond to different DID document in different sessions.

Creating a did:mailto document is done by:

  1. Creating a did:key identifier.
  2. Sending an email from DID Subject email address with a key authentication message in the subject.

Key Authentication

Key authentication message must conform to the following ABNF definition, which refers to did-key-format defined in did:key specification

auth = "I am also known as " did-key-format
EXAMPLE 3
I am also known as did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

Read (Resolve)

Specification intentionally does not specify how to resolve DKIM-Signature for the given did:mailto identifier as those could be arranged out of bound between participants. Optional programmatic resolution over SMTP could be defined in the future iterations.

The following steps MUST be executed to resolve the DID document from the DKIM-Signature:

  1. Extract key authentication from the subject header.
  2. Extract did:key from the extracted key authentication.
  3. Extract sender email address from the from header.
  4. Resolve DID document from extracted did:key.
  5. Set id of the DID document to the did:mailto identifier of the sender email address.
  6. Set alsoKnownAs of the document to extracted did:key.

Deactivate (Revoke)

Specification intentionally does not specify how to communicate DKIM-Signature for deactivating the DID Document.

DID Subject may deactivate specific DID document by:

  1. Sending an email from DID Subject email address with a key revocation message in the subject.

Key Revocation

Key revocation message must conform to the following ABNF definition, which refers to did-key-format defined in did:key specification

auth = "I revoke " did-key-format
EXAMPLE 3
I revoke did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

Update

This DID Method does not support updating the DID Document.