Overview

An in-depth overview of the Self protocol.

Introduction

The Self protocol is an identity protocol designed to let people use their real-world attestation in a permissionless way, for Sybil resistance and selective disclosure. Our core thesis is that web-of-trust systems are hard to scale securely, and biometric verification à la Worldcoin has a long way to go, so bootstrapping from existing sources of trust like institutions is the most pragmatic way to verify identities securely today and in a privacy preserving way. We’re starting with passports, and plan on adding other attestations like ID cards and Aadhaar.

Self has three main components:

• A mobile app that lets users easily scan the NFC chip in their passport. The mobile app operates both on iOS and Android, and performs the authentication mechanisms required by the passport to read the content of its chip (BAC/PACE).

• Zero-knowledge circuits that can be used to verify the validity of certificates and passports, generate identity commitments and selectively disclose attributes.

Smart contracts that verify proofs, manage a merkle tree of identity commitments and allow for onchain disclosure of data while guaranteeing the permissionless aspect of the protocol

Background on Biometric Passports

Biometric passports were introduced in the 2000s as a way to streamline border control and reduce the risk of passport forgery. They are now issued in more than 170 countries, and their specifications are established by the ICAO (International Civil Aviation Organisation) and made available in Document 9303 on their website.

Each biometric passport contains an embedded microchip that can be read by any NFC reader. It stores multiple datagroups (up to 16) along with a SOD (Document Security Object) that can be used to verify the integrity of the passport. The SOD contains hashes of all datagroups, a signature attesting to the validity of the passport, and information on which hash functions and signature algorithms were used.

All possible datagroups and their content can be found in the image below. DG1 and DG2 are mandatory, the rest is optional.

In particular:

• DG1 has the same content as the machine readable zone, and is the source of all the information we care to verify.

• DG2 contains the person’s photo. Because it contains a lot of entropy, it makes sure that the final signature can’t be dictionary-attacked starting with some of the person’s information.

• DG15 (optional) is the public key corresponding to the passport’s Active Authentication private key. We plan to use it to improve security in the future.

The passport data groups are hashed according to a process detailed in Passport Circuits. The resulting final hash is signed by a Document Signing Certificate (DSC), which is itself signed by a Country Signing Certificate Authority (CSCA) as part of a certificate chain.

The eContent consists of the concatenation of all DG hashes, while the signedAttr is the final message signed by the issuing country.

Both objects can be accessed by scanning the passport chip with an NFC reader.

Though uncommon, different hashing algorithms may be used at each step.

The DSC that signed the passport can be found in the passport’s SOD, whereas CSCA certificates can be looked up on international registries such as the ICAO masterlist.

According to the specifications, each DSC should sign up to 100k passports, each CSCA should rotate every 3-5 years, and a country should always have at minimum 2 valid CSCA at the same time.