Presence, Claim and Identity #

The purpose of this essay is to provide a standardized model for managing decentralized online identities. Specifically, it deals with how numerous online presences are associated and belong to the same identity, and provides a way for managing claims and identities of one's counterparts.

Similar to Keyoxide, it ensures one is interacting with whom they intended to be by helping check the authenticity of the counterpart's claims. Different from Keyoxide, it doesn't base an identity on any single profile (ASP, OpenPGP, etc.); claims can be made by any presence on any presence. Additionally, it doesn't deal with the technical aspects of formatting claims and verifying proofs.

Table of Contents #

• Summary
• Presence
• Claim
• Identity
• Medium-specific Adoption Tips
• Implementations
• Glossary Translations
• Claim Boilerplate Translations

Summary #

The structure of a sample database adopting the proposed model is illustrated below.

The model is based on three core elements: presence, claim and identity, hence the abbreviation PCI.

An online account or a more fractional existence is recorded as a presence, represented by a smaller rectangle in the diagram above.

When a presence claims to be in control of another presence, a claim is recorded in the diagram as a one-directional arrow pointing to the claimed presence.

Presences that are inter-claimed are associated and belong to the same presence group, represented as a larger rectangle containing all these presences, the label of which being its identity. A presence being outside a group means it's not under common control with any presence in that group.

Presence #

A presence is a distinguishable existence on a medium of communication which can be interacted with. Examples of a presence are an OpenPGP key, an XMPP account (or an OMEMO device thereof), and a Matrix account.

In practice, each presence is distinguished by a unique name. The general principle of naming a presence is to include the name of the medium plus the amount of information enough for distinguishing the presence from other presences on the medium. Example formats for naming presences on various mediums are listed below.

A presence may be revoked, if the medium of that presence supports declaring that the presence issuing revocation shall not be used any more. Revoked presences cease to exist and are removed from the database.

Claim #

A presence may claim another presence. Through a claim, a presence unilaterally declares, in natural language, that the claimed presence is under common control with the presence making the claim.

An example claim on an XMPP account written in English would be (available translations attached):

I hereby confirm that the following XMPP account:
	alice@example.org
and the OMEMO devices connected to it with the following fingerprints:
	- 12345678 9ABCDEF0 12345678 9ABCDEF0 12345678 9ABCDEF0 12345678 9ABCDEF0
	- 9ABCDEF0 12345678 9ABCDEF0 12345678 9ABCDEF0 12345678 9ABCDEF0 12345678
are under my control.

A claim may be revoked through a similar declaration by the presence that made the claim, stating that the claimed presence is no longer under common control with the former presence. Revocation of a claim doesn't render a presence revoked; however, when a presence is revoked, all its claims are revoked as well.

When two presences claim each other, they are associated, meaning it's confirmed that both presences are under common control. When so, they belong to the same presence group.

Specifically, a single presence not associated with any other presence also forms a group.

An association between two presences from different presence groups combines the two groups into one.

Absence of an association (due to revocation of a claim) in a presence group may or may not dissolve the group into more than one independent groups, depending on how presences are associated within.

Identity #

A presence group is by default unidentified. To identify a presence group is to recognize the control of the group as a definite entity by giving it a unique name. In other words, to identify a presence group is to name it.

Identity is group-level. Therefore, identifying any presence in a presence group equals identifying that group; it makes all other presences in that group identified the same.

When an unidentified presence group combines with an identified group, the identified one infects the unidentified one with its identity. From another perspective, the unidentified group contracts the identity from the identified one.

When an identified presence group is dissolved into more than one groups, all resulting groups turn unidentified, since identity is unique and no more than one groups may be identified the same. Note that a single presence leaving an identified presence group also constitutes dissolution.

Presence groups dissolved into may be identified again. In this scenario, one may want to identify one of the resulting groups as its previous identity, or not identify any of them any more.

Due to various reasons, one physical individual may have multiple identities. In this case, their identities should be treated as separate ones, and no association should be assumed between any of their presences.

Medium-specific Adoption Tips #

XMPP #

In Gajim, consecutive messages from the same JID are merged into one block, even if they are from different OMEMO devices. To be able to see the OMEMO fingerprint of each message, go to Preferences → Advanced → Advanced Configuration Editor, and deactivate chat_merge_consecutive_nickname.

Implementations #

An example CLI program sam is created that adopts this model for managing decentralized online identities. The program is released here.

Glossary Translations #

Claim Boilerplate Translations #

Translations on the example claim on an XMPP account written in English.

Mandarin #

本人特此证实，如下 XMPP 账号：
	alice@example.org
及属于该账号且指纹如下的 OMEMO 设备：
	- 12345678 9ABCDEF0 12345678 9ABCDEF0 12345678 9ABCDEF0 12345678 9ABCDEF0
	- 9ABCDEF0 12345678 9ABCDEF0 12345678 9ABCDEF0 12345678 9ABCDEF0 12345678
均受本人控制。

This page is released into the public domain under CC0 1.0.