Authenticated Transfer Scheme for cross-server Space Station 14 data transfer

A Collection of Interesting Ideas, 12 September 2025

Not Ready For Implementation

This spec is not yet ready for implementation. It exists in this repository to record the ideas and promote discussion.

Before attempting to implement this spec, please contact the editors.

To the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 12 September 2025, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, which is available at https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0. Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

1. Introduction

Sometimes, it would be useful to share certain information between SS14 servers, such as playtime data for playtime transfers. This spec defines a simple but (hopefully) flexible protocol for doing so.

2. Protocol Endpoints

2.1. Instance Information Endpoint

The Instance Information Endpoint is used to retrieve information for an ATS instance. A GET request to an Instance Information Endpoint MUST be responded to with a [JSON] document, following InstanceInfo. The document MAY have additional attributes not described in this specification.

interface InstanceInfo {
    attribute USVString name; // The display name for the instance
    attribute USVString? desc;
    attribute sequence<InstanceInfoLinks>? links;
    attribute InstanceInfoAts ats;
};

interface InstanceInfoAts {
    attribute object signingKey; // Signing Key in JWK format
    attribute USVString? pullUrl;
    attribute USVString? pushUrl;
    attribute boolean relayed; // Whether this instance exports data at least partly from another ATS instance.
};

interface InstanceInfoLinks {
    attribute USVString url;
    attribute USVString icon;
    attribute USVString name;
};

2.2. Pull Endpoint

The Pull Endpoint is used to request a specific piece of information from an ATS instance. If an ATS instance supports the Pull action, the pullUrl attribute MUST point to the Pull Endpoint.

Clients MUST first send an OPTIONS request with the intended request body.

The server MUST respond with one the following:

a 204 No Content response, alongside the Accept-Signature field as defined in HTTP Message Signatures § section-5.1 if the requesting ATS instance may access the information.
a 403 Forbidden response if the requesting ATS instance is not allowed access to the requested information.
a 404 Not Found response if the server cannot provide the requested information.

Instances MAY also respond with 204 No Content instead of 403 Forbidden to prevent public knowledge of which servers are allowed to access what information.

If an 204 No Content response is received, the client can now proceed by sending a POST request with:

The same request body as in OPTIONS.
A valid HTTP Message Signature defined in [rfc9421], signed using the signing key of the ATS instance.

The request body MUST be a [JSON] document following PullRequest:

interface PullRequest {
    attribute USVString requester; // The Instance Information Endpoint for the requesting instance.
    attribute USVString category; // The category of information requested.
    attribute object? specifier; // More details on the information requested, defined by the category.
};

The response body format is a [JSON] document with format defined by the category.

2.3. Push Endpoint

The Push Endpoint is used to notify that a specific piece of information has been updated to an ATS instance. If an ATS instance supports the Push action, the pushUrl attribute MUST point to the Push Endpoint.

Clients notify the server of an update by sending a POST request with a valid HTTP Message Signature, covering at least the request body, and a body including a [JSON] document following PushRequest:

interface PushRequest {
    attribute USVString requester; // The Instance Information Endpoint for the requesting instance.
    attribute USVString category; // The category of information requested.
    attribute object? specifier; // More details on the information requested, defined by the category.
    attribute object data;
};

3. Standard Categories

Implementations MAY implement none, some or all of the categories listed in this specification. However, implementations MUST NOT use a category name in the specification in a way incompatible with the specification.

3.1. `playtime` Category

The playtime category represents the recorded per-role playtime of a player.

Its specifier type is PlaytimeSpecifier and its data type is PlaytimeData.

interface PlaytimeSpecifier {
    attribute USVString authServer; // Authentication server of the user.
    attribute USVString user; // UUID of the user.
};

interface PlaytimeData {
    attribute sequence<PlaytimeEntry> jobs;
};

interface PlaytimeEntry {
    attribute USVString tracker; // ID of the PlayTimeTrackerPrototype, if using wizden system.
    attribute double minutes;
};

4. Signing Requirements

4.1. Algorithm Requirements

All implementations MUST support the ed25519 algorithm as defined in HTTP Message Signatures § section-5.1. All implementations MUST understand the [rfc8037] format for Ed25519 JWKs.

4.2. Signature Requirements

Implementations MAY reject any signatures or signature requests including any of the following:

HTTP Message Components other than @signature-params, @method, @target-uri, content-digest, content-length, and content-type.
The expires signature parameter.
A Content-Digest header without a sha-256 entry.
A Content-Digest header with an entry that is not sha-256.

Implementations SHOULD reject any signature requests including any of the following:

More than one signatures.
The alg, keyid, or tag signature parameters.

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Index

Terms defined by this specification