Version 0

Ariadne Identity Core Specification

Version 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:

  • fetch a cryptographically secured document containing identity claims
  • parse the claims and deduce potential locations of identity proof
  • fetch public data from these locations and search for proofs of identity

1.1. Example

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

  • proof@ariadne.id=https://domain.tld

Our hypothetical OpenPGP key has the following fingerprint:

  • 21110C4A12F24046C460B2995241BA9B7233E2DD

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:

  • openpgp4fpr:FINGERPRINT

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

  • minisignpub:PUBLICKEY

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:

  • a domain name;
  • an account registered with a third party service provider.

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

Examples of Identity Claims are:

  • https://domain.tld
  • https://domain.tld/user
  • irc://domain.tld/nickname

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:

  • as notations in an OpenPGP cryptographic key
  • as a cryptographically signed document

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:

  • proof is the key, signifies what follows is an Identity Claim
  • @ariadne.id is the namespace
  • CLAIM is the actual Claim

Examples of Identity Claim notations are:

  • proof@ariadne.id=https://domain.tld
  • proof@ariadne.id=https://domain.tld/user
  • proof@ariadne.id=irc://domain.tld/nickname

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:

  • proof=https://domain.tld
  • proof=https://domain.tld/user
  • proof=irc://domain.tld/nickname

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:

  • key=minisignpub:RWQV3WT6S7EM63OEQfwnDBpj7QN/O3Ki05VHLpKwX9QFEejqD7Id09Vp

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 URI representation of a cryptographic key's identifier
  • a cryptographic hash of a URI representation of a cryptographic key's identifier
  • an URL pointing to a web representation of an Ariadne Identity Profile

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

  • URI: openpgp4fpr:ACB9C3FDB63C9DCAF14AD027811C5FDF6E20CC0E
  • argon2 hash: $argon2id$v=19$m=64,t=512,p=2$bgvN8ojYGE27FiHVSt12mA$Wi8M62eZeign70OwaDqrxQ
  • bcrypt hash: $2a$11$ZetL6mhWEC05DgFTQrz0k.8yWjYxYwI/ozEsr/C51B14URhdj2KIq
  • URL: https://keyoxide.org/ACB9C3FDB63C9DCAF14AD027811C5FDF6E20CC0E
  • Vanity URL: https://domain.tld/myid

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:

  • ariadne-identity-proof: KEY_IDENTIFIER

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:

  • parse the claim and deduce potential locations of identity proof
  • fetch public data from these locations and search for proofs of identity

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:

  • https://domain.tld/user
  • https://domain.tld/user.json
  • https://api.domain.tld/profile/user

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:

  • cross-origin resource sharing restrictions
  • access tokens that shouldn't appear in the web interface's source code
  • data locations not accessible through browsers-side code (for example, DNS records)

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