Ariadne Identity

Status archived
Created 2022-11-16
Last updated 2022-11-16
Superseded by Ariadne Identity 1.0.0

Ariadne Identity Core Specification

Author: Yarmo Mackenbach <yarmo@keyoxide.org>
Version: 0
Published: 2022-11-16
Last updated: 2022-11-22

Status

This version of the specification is a draft. It is not recommended to base implementations on this version.

Copyright (c) 2022 Yarmo Mackenbach. All rights reserved.

1. Introduction

The Ariadne Identity Specification (AIS) describes a protocol to prove online identity in a decentralized manner using bidirectional linking and secured by cryptography.

The protocol roughly works as follows:

1.1. Example

Let's take a hypothetical OpenPGP key containing a single notation:

Our hypothetical OpenPGP key has the following fingerprint:

We fetch the OpenPGP key from a keyserver and read the notations it contains. We find a single one. Since it has the proof key and the ariadne.id namespace, we interpret the notation's value as an identity claim. We parse the value https://domain.tld and assume it attempts to claim a website. We fetch the website and parse the HTML data looking for specific meta tags. If we find a correct meta tag of which the value contains the OpenPGP key's fingerprint, we have established bidirectional linking and can mark the identity claim as verified.

1.2. Supported cryptographic standards and tools

The AIS currently supports OpenPGP cryptographic keys and minisign cryptographic keys.

The identifier of an OpenPGP cryptographic key is its fingerprint. It's URI representation is:

The identifier of a minisign cryptographic key is its public key. It's URI representation is:

2. Identity Claims

Identity Claims are links stored inside cryptographically secured documents that point to digital assets that one can uniquely hold.

An Identity Claim is always an URI and may be an URL.

The non-exhaustive list of digital assets an Identity Claim may point to are:

Identity Claims must contain all the necessary information to deduce potential locations of public data containing proofs of identity.

Examples of Identity Claims are:

3. Identity Profiles

A collection of identity claims constitute an Identity Profile. To ensure the integrity of a Profile, Identity Claims must always be stored together in a single documment and that document must be cryptographically signed for authenticity and uniqueness.

Ariadne Identity Profiles can be stored in one of two ways:

3.1. OpenPGP profiles

OpenPGP cryptographic public keys can be exported and propagated containing arbitrary bits of information known as notations. A notation is a key-value pair with an optional namespace for the key.

Ariadne Identity Claims stored as notations must be as follows:

proof@ariadne.id=CLAIM

where:

Examples of Identity Claim notations are:

3.2. Signature profiles

Plaintext documents can be cryptographically signed by a variety of cryptographic standards and tools. These plaintext documents can contain lines with specific keywords that when parsed, form an Ariadne Identity Profile.

The public keys of the cryptographic keys that signed the profile must either be publicly available through keyserver or other key diffusion protocols, or embedded in the document if they are small enough.

Lines starting with proof= must be treated as Identity Claims. Examples are:

Lines starting with key= must be treated as public cryptographic keys. Keys should start with the protocol or tool they, followed by a pipe symbol and then the public key itself. Examples are:

Other lines will be ignored and may be used to clarify the intent of the signature profile.

4. Identity Proofs

Identity Proofs are links that point to a cryptographic key. Presence of an identity proof inside data fetched from a location deduced from an identity claim verifies said claim.

An identity proof may be:

An example set of Identity Proofs for an OpenPGP key with fingerprint ACB9C3FDB63C9DCAF14AD027811C5FDF6E20CC0E could be:

Identity proofs may be stored inside plaintext data or JSON data, depending on the service provider.

4.1. Cryptographic hash

To prevent Identity Proofs from tracing back to their Identity Profile, the URI representation of the key's identifier can be hashed.

Cryptographic hashing must be performed using either the argon2 [RFC9106] or the bcrypt method.

4.2. Ariadne Identity Profile URL

Ariadne Identity Profile URL should be fetched through a HEAD HTTP request and the response headers scanned for the following header:

where KEY_IDENTIFIER is the URI representation of an OpenPGP key's fingerprint, or the URI representation of a public key for other standards and tools.

4.3. Vanity URL

An Ariadne Identity Profile URL may be a vanity URL that redirects to the actual Ariadne Identity Profile URL. A vanity URL may not take more than a single redirect to arrive at the Ariadne Identity Profile URL.

5. Identity verification process

The verification process for an Identity Claim roughly works as follows:

To parse an Identity Claim, it is matched against a set of known service providers definitions and tested against each match until one verifies the claim.

For each matched service provider, the identity claim will be converted into a set of instructions to fetch the potential proof of identity. As an example, take the claim https://domain.tld/user. For different service providers, this could be converted into the potential locations to fetch:

Each of these locations should be fetched with appropriate HTTP headers and methods as specified in the service provider definition. The data returned for each location will be parsed and analyzed as specified in the service provider definition.

If the returned data is plaintext, search the entire document for proofs of identity. If the returned data is JSON, the service provider definition will specify the path to the desired key or keys.

If the returned data contains a proof of identity in any of the forms described in section 4, the Identity Claim is marked as verified.

5.1. Proxy servers

Not all identity claims are verifiable through web interfaces due to a variety of reasons:

In these cases, an AIS program may fetch the necessary data through a proxy server. It is recommended to prefer direct requests over proxied requests. Interfaces should inform the user when a proxy server was solicited.

6. Service provider definitions

Since there is no universal way to verify an Identity Claim, the AIS is based on a predefined list of supported service providers. This list is publicly available on https://ariadne.id/arc

7. References

[RFC9106] https://www.rfc-editor.org/rfc/rfc9106