kxid.me

What is kxid.me?

kxid.me is a URL shortener created specifically for Keyoxide profiles.

Example

The maintainer's profile is located at https://keyoxide.org/9f0048ac0b23301e1f77e994909f6bd6f80f485d. Quite cumbersome to write!

Instead of using that, he could just use https://kxid.me/yarmo which simply brings you to the same profile page.

Respecting privacy

Projects like kxid.me that touch online identity need to be very mindful of the user's privacy and not leak sensitive information.

Ideas so far: making discovery opt-in (or not at all), rate limiting to counter scraping. By default, aliases and their linked keys are not publicly shared.

Feel free to share ideas on improving kxid.me:

Project status

kxid.me is currently in a Proof of Concept phase. This means anything about it can still drastically change. If you are invited to try it out, use at your own risk.

Roadmap

Move data from file to database
Add rate limiting
Add automated URL creation (needs investigation/feedback)
Use kxid.me URLs as proof (needs investigation/feedback)
Opt-in public index (needs investigation/feedback)

How to get your own shortened URL?

In this early development phase, everything is done manually and not all requests to join will be accepted. If you'd like to request to join, contact the maintainer directly:

Again, do realize that currently everything is subject to change, use at your own risk.

Ariadne Alias Protocol

Note: while waiting for the impending restructuring of the Ariadne Identity specification, this protocol will be hosted in the kxid-me repository.

Ariadne Alias Protocol

Author: Yarmo Mackenbach
Version: 0.1
Last updated: 2022-08-31

Abstract

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.

Status

This specification is a draft. Do not base implementations on this version of the specification.

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

1. Introduction

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.

2. Justification

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:

https://keyoxide.org/9f0048ac0b23301e1f77e994909f6bd6f80f485d

An alias URL can be more meaningful and memorable. For example:

https://domain.tld/yarmo

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:

  • https://domain.tld
  • https://domain.tld/id
  • https://domain.tld/name/id
  • https://sub.domain.tld
  • https://sub.domain.tld/id

The following are invalid alias URLs:

  • http://domain.tld
  • http://domain.tld/id

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:

  1. Request the proof data.
  2. Find the location inside the data where the proof should be located.
  3. Attempt to find the fingerprint.
  4. If not found, scan the data for HTTPS URLs.

  5. For each URL found:

    1. (optional) Perform an OPTIONS request, continue only if HEAD requests are allowed.
    2. Perform a HEAD request.
    3. If the response status is 301, follow the redirect and use that HTTP response in the next step.

    4. Scan the headers for the Ariadne-Identity-Proof header:

      1. If found, use that header’s value as the proof.
      2. 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.