Ariadne Identity Service Providers 1.0.0

Summary

This document describes the different service providers that are supported for identity claim verification. This document will also provide information on how to parse the identity claims and use that to fetch the proof, as well as tips on how to match the service provider to an identity claim.

Table of Contents

• Summary
• Table of Contents
• Related specifications
• Conventions
• ActivityPub
  • General information
  • Claim verification
    • Claim matching
    • Data fetching
    • Data processing
  • Examples
  • Considerations

Related specifications

This specification uses the context, definitions and information from the Ariadne Identity 1.0.0 specification.

Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC2119.

This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC2234.

ActivityPub

General information

This service's identifier is: activitypub.

This service is a protocol implemented by federated social networks. The protocol has a specification available on w3.org.

Claim verification

Claim matching

1. This service is not associated to a single domain name.
2. Regarding claim direct URIs:
   1. The claim direct URI MUST be a URL using the https scheme.
   2. The URL is not required to use a specific host or path.
3. Regarding claim data URIs:
   1. The data URI associated with this service is formatted as described in Ariadne Identity 1.0.0, with the MIME type parameter service=activitypub and the following properties for the data payload:
      1. url: the claim direct URI.
4. Servers implementing this service MAY respond to the nodeinfo API endpoint:

   /.well-known/nodeinfo
   

   More information on the nodeinfo API endpoint: nodeinfo protocol.

Data fetching

There are two methods of fetching the data used for claim verification: the unsigned request and the signed request. The difference is the some ActivityPub servers do not accept unsigned requests. Verification clients SHOULD use signed requests.

An unsigned request is made as follows:

1. Perform an HTTP GET request as follows:
   1. url: the claim direct URI.
   2. headers:
      1. Accept: application/activity+json
2. Parse the response as json.

A signed request is made as follows:

1. Perform an HTTP GET request as follows:
   1. url: the claim direct URI.
   2. headers:
      1. Accept: application/activity+json
      2. Signature: HTTP signature
2. Parse the response as json.

The Signature header contains an HTTP signature generated using the method described in draft-cavage-http-signatures. For more information on creating an HTTP signature for ActivityPub servers, see the Mastodon Security guide (web archive link).

Data processing

The json data fetched from the service could contain the proof in any of the following locations:

1. .summary
   1. This is usually the profile's biography, if the URL refers to a profile. It may also hold a post's content warning.
2. .content
   1. This is a post's content, if the URL refers to a post.
3. .attachment.[].value
   1. For Mastodon accounts, these are the metadata fields.

Verification clients SHOULD search all these locations in the response data.

Examples

Example 1 with a claim direct URI:

CLAIM URI   = https://domain.example/@username
REQUEST URL = https://domain.example/@username

Example 2 with a claim data URI:

CLAIM URI   = data:application/vnd.ariadne.claim+json;service=activitypub;base64,eyJ1cmwiOiJodHRwczovL2RvbWFpbi5leGFtcGxlL0B1c2VybmFtZSJ9
REQUEST URL = https://domain.example/@username

Considerations

1. Because of how difficult it is to assert whether a claim direct URI is associated with the ActivituPub service, this service SHOULD be tried as one of the last services for any claim direct URI.
2. Verification clients COULD use information from the nodeinfo API endpoint to help with the data processing, such as obtaining the name of the software running on the server. This is helpful for user interfaces, to display the actual name of the service instead of a generic activitypub name.