Ariadne Identity Related Specifications
Ariadne Alias Specification v1
Ariadne Alias Specification
Author: Yarmo Mackenbach <firstname.lastname@example.org>
Last updated: 2022-11-16
This specification describes a service to provide alternate or alias URLs for Ariadne Identity profile pages and use those alias URLs as proof of identity to verify identity claims.
This version of the specification is active.
Copyright (c) 2022 Yarmo Mackenbach. All rights reserved.
This specification describes an HTTP server that will forward chosen paths to Ariadne Identity profile pages. It also describes the additional HTTP headers and responses required to make these URLs work as proofs to verify identity claims.
URLs for Ariadne Identity profile pages usually contain the fingerprint of the cryptographic key that secures them. This can make them quite lengthy, hard to remember and difficult to troubleshoot.
For example, here is the URL for the author's Keyoxide page:
An alias URL can be more meaningful and memorable. For example:
Furthermore, identity proofs require the presence of the fingerprint of the cryptographic key that secured the Ariadne Identity. Replacing the need for a fingerprint with a short URL therefore also simplifies the process of making identity proofs, and could prove useful when a service provider only provides limited space for proofs.
3. Protocol requirements
To comply with the decentralized nature of the Ariadne Identity specification, this protocol must avoid centralization and relying on known instances to properly function. Any implementation supporting this protocol must be able to reliably exchange aliases for fingerprints without having prior knowledge on the domain that hosts the alias.
This protocol must also be simple enough that it can be implemented by just configuring a reverse proxy. This allows both people with a domain and alias-providing services to enjoy the protocol.
4. Ariadne Alias protocol for servers
4.1. Alias URL
An alias URL must follow RFC2616 and be based on the HTTPS scheme. An alias URL may be the root of a domain or a path on that domain. It may be a subdomain of the base domain.
The alias URL must accept the GET, HEAD and OPTIONS methods.
The following are valid alias URLs:
The following are invalid alias URLs:
4.2. HTTP redirection
The alias URL must redirect directly to the location of an Ariadne Identity profile page. The redirect must use the 301 HTTP status code.
4.3. HTTP headers
The alias URL must support cross-origin resource sharing (CORS) and therefore return the following headers:
- Access-Control-Allow-Origin: *
- Access-Control-Allow-Methods: GET, HEAD, OPTIONS
The Access-Control-Allow-Methods header should at least contain the three methods described above, more may be added.
5. Ariadne Alias protocol for clients
5.1. Identity claim verification process
To support aliases as proofs, the client should proceed as follows:
- Request the proof data.
- Find the location inside the data where the proof should be located.
- Attempt to find a basic proof of identity.
- If not found, scan the data for HTTPS URLs.
- For each URL found:
- (optional) Perform an OPTIONS request, continue only if HEAD requests are allowed.
- Perform a HEAD request.
- If the response status is 301, follow the redirect and use that HTTP response in the next step.
- Scan the headers for the Ariadne-Identity-Proof header:
- If found, use that header's value as the proof.
- If not found, mark the claim as not verified.
This process only differs from the default process in step 5.3. where the URL was an alias URL because it redirects to the actual profile page.
The client must not follow consecutive redirects, since the alias URL should redirect directly to the profile page.