Ariadne Identity Claim Containers 1.0.0

Summary

This document describes the different methods to create valid claim containers for Ariadne Identities and how to identify, distribute and parse them for the purposes of identity claim verification.

Table of Contents

• Summary
• Table of Contents
• Related specifications
• Conventions
• OpenPGP
  • Security considerations
• Ariadne Signature Profile (ASP)

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.

OpenPGP

1. An OpenPGP claim container uses a cryptographic keypair generated using the OpenPGP standard (RFC4880) as the document to hold identity claims.
2. An OpenPGP claim container is identified by an openpgp4fpr: URI (openpgp4fpr URI scheme), which is formatted as follows:

   openpgp4fpr-uri = "openpgp4fpr:" fingerprint
   fingerprint     = 40*40HEXDIG
   

   Where fingerprint is the fingerprint of the OpenPGP keypair.
3. An OpenPGP claim container MUST store identity claims as notations, formatted as follows:

   claim-notation = "proof@ariadne.id=" claim-uri
   

   Where claim-uri is the identity claim in URI format.
4. An OpenPGP keypair MAY contain multiple subkeys and user IDs. Identity claims from all user IDs SHOULD be used and parsed by verification clients.
5. Identity claims from revoked or expired keys, subkeys or user IDs MUST be ignored by verification clients.
6. Verification clients SHOULD support fetching OpenPGP public keys using the OpenPGP HTTP Keyserver Protocol (HKP) and the Web Key Directory protocol (WKD), and MAY support parsing OpenPGP public keys exported as armored text or to binary.
7. For backwards compatibility, verification clients SHOULD support parsing identity claim notations formatted as follows:

   legacy-claim-notation = "proof@metacode.biz=" claim-uri
   

Security considerations

The HKP protocol supports querying public keys by fingerprint but also by the email addresses that have been entered in the key's user IDs. However, it is not common practice by HKP servers to verify that the uploader of the key does indeed have access to the email addresses they claim to have. This is why this specification does not allow email addresses as valid identity proofs, and why verification clients MUST NOT treat the presence of an email address in a public key as a trustworthy or verified indicator of hold over said email address.

Verification clients MAY however accept email addresses as identifier of OpenPGP claim containers, but only to the extent that the email address is used to initiate the verification process of an online identity profile. As described above, that same email address MUST NOT be used in the verification process of identity claims.

As an exception to the rule, hkps://keys.openpgp.org is known to perform email verification for uploaded keys, and does not expose user IDs for which the email address has not been verified. For this reason, verification clients are RECOMMENDED to use hkps://keys.openpgp.org as primary or fallback server for HKP requests.

When using the WKD protocol, public keys can only be queried by an email address, not a fingerprint. Publishing a public key using the WKD protocol does not actually require access to the email account used as the identifier of said public key. However, the WKD protocol specifies that a public key published using WKD is associated to the email address used as identifier. Therefore, verification clients MAY consider the email address as an implicitly verified account of the identity profile. Similarly as with the HKP protocol, the email address MAY be used for discovery of online identities, but MUST NOT be used as identity proof.

Ariadne Signature Profile (ASP)

1. An ASP claim container uses a JSON Web Token (RFC7519) as described in the Ariadne Signature Profile v0 specification as the document to hold identity claims.
2. An ASP claim container is identified by an aspe: URI (Ariadne Signature Profile v0), which is formatted as follows:

   aspe-uri = "aspe:" aspe-domain ":" fingerprint
   

   Where aspe-domain is the domain of the ASPE server hosting the JWT and fingerprint is the fingerprint of the cryptographic keypair.
3. An ASP claim container MUST store identity claims in the JSON payload.
4. Verification clients SHOULD support fetching ASP profiles using the ASPE protocol (Ariadne Signature Profile v0) and MAY support parsing JWTs provided directly.