Skip to main content

Passport-derived profiles

Rarimo has developed a novel solution that turns a regular biometric passport into a flexible digital identity credential for Web3. Importantly, this is done without compromising the security of your sensitive data by using zero-knowledge proofs.

DApp developers can use the passport-derived profiles to:

  • Restrict access for risky countries
  • Set minimum age requirements
  • Create provable social graph attestations
  • Prevent Sybil attacks
  • Verify personhood
  • Any other use cases with selective disclosure of the passport data.

Biometric passports 101

Biometric passports are familiar to any traveler. Currently, 172 nations issue ID documents compatible with the ICAO Machine Readable Travel Documents standard, making them one of the most widely used identity credentials worldwide.

Each biometric passport contains a MRZ(Machine-Readable Zone). The MRZ includes an RFID chip that contains data for biometric verification, personal details, an expiration date, and the issuer's digital signature.

To check the validity of a passport, the verifier has to read the MRZ using an NFC scanner, verify the issuer's digital signature, and check the expiration date.

How it works

The passport-derived profiles solution consists of the following components:

  • RariMe mobile apps are available for Android and iOS. They scan passports, securely store the passport data, and generate ZK proofs.
  • A set of Circom circuits designed to generate and verify zero-knowledge proofs of identity.
  • A set of smart contracts for managing the identity profile states.
  • Rarimo's cross-chain messaging protocol propagates the identity states to other chains on demand.

Let's walk through the user flow and explore the inner workings of this solution.

Scanning the passport

To get started, the user must read the passport information using NFC. Under the hood, the reading process consists of the following steps:

  1. Receive the basic passport data from MRZ and generate authentication keys.
  2. Scan the data from the passport in encrypted form
  3. Decrypt and verify the data locally.
  4. Store the relevant passport data locally on the device.

After verifying the passport validity, the device securely stores the following data locally:

  • DG1 Personal Details. This section includes the passport holder's primary identity information, such as name, date of birth, nationality, and passport number. It reflects much of the information printed on the passport's data page.
  • DG2 Facial photograph. This section contains the passport holder's portrait. In the future, the protection method based on it will be possible to extend with face recognition and ZKML proofs.
  • DG15: Active Authentication Public Key. This includes the public key used for Active Authentication(AA), a security feature preventing unauthorized copying of passport data.
  • Hash values of other DGs.
  • Issuer's signature.
  • Document Signer Certificate (CDS).

Let's note that the list of biometric data groups can be extended in the future (or for some countries). DG2(Portrait) is currently the most widespread biometrics in passports.

All actions within this process are performed locally, without access to the Internet. The certificate path can also be verified on the device if the application stores a set of valid certificates for Trust Anchors. No personal data is shared anywhere or accessible to outside parties.

Creating a passport-derived profile

Next, we create a passport-derived profile by following this protocol:

  1. The user generates the keypair <sk, pk> for identity management and β = Hash(sk) to blind personal data.
  2. The user signs pk with the passport signature sig = sign(challenge, sk_pass) by using passport active authentication and providing Hash(pk)[:64] as a challenge.
  3. The user generates a ZK reg_proof that pk_pass is a public key belonging to the passport (signed by a key from the ICAO list, without revealing the exact passport's issuer).
  4. The circuit calculates a commitment DG_commit = Hash(DG1 || β).
  5. The user submits the registration data <pk, pk_pass, sig, reg_proof> to the registration relayer service, which then submits to the identity state contract on the Rarimo chain.
info

We use the registration relayer service instead of submitting the transaction directly to subsidize the gas fees for new users.

A link between the pk and pk_pass is saved in a leaf of a Sparse Merkle Tree in the identity state contract on the Rarimo chain. The leaf position and value are derived like this:

  • Leaf position: id_pos ← Hash(pk ∥ pk_pass)
  • Leaf value: v ← Hash(id_pos, DG_commit)

The user may try to create several profiles using different pk for the same passport, but the smart contract will reject these attempts.

Users may revoke or change the identity management keypair, but this operation requires a passport signature.

Additionally, the protocol allows the creation of periodic passport liveness commitments to prove passport ownership over a period of time. This is useful in use cases like voting, where a corrupt government may try to skew the results by issuing fake passports. The verifier application can set the time threshold to limit the impact of freshly printed documents on the final use case.

Generating zero-knowledge proofs of identity

The Passport Validity Circom circuit enables proving that the user owned a valid passport-derived profile at the specified time. Additionally, the circuit allows the user to prove that:

  • The citizenship matches the provided allowlist.
  • The expiration date of their passport is within some time bounds.
  • The date of their birth is within some time bounds.
  • Selectively disclose personal data from DG1 using a selector Sel.

When generating proof, the prover requests the historical state of the Identity Smart Contract.

Selector Sel is used to selectively disclose personal information from a passport. Each private data signal is multiplied by a corresponding Sel bit. If the bit is 0, the data is blinded by multiplying it with 0. If the bit is 1, data is sent to the output signal without modifications.

DApps can verify the proofs both on-chain and off-chain. Rarimo's on-demand identity state replication technology scales the usage of on-chain proofs to any EVM-compatible network.

Challenges and limitations

The first implementation of passport-derived profiles comes with some limitations:

  • No biometric checks are included, meaning someone may scan a stolen or borrowed passport. ZKML solutions may alleviate this in the future.
  • There's no way to prevent a holder of multiple passports from onboarding multiple times.
  • Only passports that support Active Authentication are supported now. We're working on an MPC-based solution to circumvent this limitation.