XID Registration Payload

Initial registration of an XID involves signing a payload which includes a nonce and a recovery address.

The XID is computed as sha256(CONCAT($myAccountAddress, $nonce)).

message AssociationSignature {
  oneof signature {
    RecoverableEcdsaSignature erc_191 = 1;
    Erc1271Signature erc_1271 = 2;
    RecoverableEd25519Signature installation_key = 3;
    RecoverableEcdsaSignature legacy_key = 4;
  }
  AssociationTextVersion association_text_version = 5;
}

message Association {
  AssociationSignature existing_member = 1;
  AssociationSignature new_member = 2;
}

message XidCreationLogEntry {
	string account_address = 1;
	uint32 nonce = 2;
	string recovery_address = 3;
	AssociationSignature signature = 4;
}

message XidAddLogEntry {
	uint32 nonce = 1;
	Association association = 2;
}

message XidRevokeLogEntry {
	AssociationSignature signature = 1;
	string xid = 2;
	// The nonce of the association being removed.
	// This nonce must never be used again for this XID
	uint32 nonce = 3;
	// Either an installation public key or a wallet address
	string revoked_entity_address = 4;
}

message LogEntry {
	oneof kind {
		XidCreationLogEntry create = 1;
		XidAddLogEntry add = 2;
		XidRevokeLogEntry revoke = 3;
	}
}

Credentials

Each installation’s credential would include a history of the XID up to the point that the installation was added.

message Credential {
	repeated LogEntry history = 1;
	// The entry that adds the current installation
	XidAddLogEntry add_entry = 2;
}

By verifying the log sequentially, any participant can check that the current installation key had permission to be a member of the XID. The credential, however, comes from the installation itself and it may have selectively excluded revocation events.

To limit the size of credentials, installations may be able to omit irrelevant events from the history presented. The only required events are the chain of adds that begins with the creation of the XID and ends with the addition of the existing_member referenced in the XidAddLogEntry.

Each XidAddLogEntry includes a nonce. That nonce must be unique per XID, and is included in the signature text.

Revocation

Revocations are submitted to the network as a XidRevokeLogEntry , which must be signed by the recovery address of the XID.

Clients are expected to periodically check with the network for new revocations of group members. If a revocation is found, and the entity revoked is currently a member of a group with the client, the client is expected to commit a RevocationProposal (a custom MLS proposal type) to the group.

RevocationProposal messages include an entity to be removed from the group. If the entity is a wallet address all installations signed by that wallet address will be automatically removed as part of commit processing.

As part of processing a RevocationProposal clients will append the revocation message to a list stored in a GroupContextExtension . After the processing of the proposal no new associations will be allowed for that XID using that nonce. The combination of removing the existing installations and banning the nonce should prevent the wallet/installation key from being re-added in the future without a brand new association being created (replay prevention).