@dxos/protocols 0.1.0

package/src/proto/dxos/echo/snapshot.proto

@@ -0,0 +1,98 @@
+//
+// Copyright 2020 DXOS.org
+//
+
+syntax = "proto3";
+
+import "dxos/echo/timeframe.proto";
+import "dxos/halo/signed.proto";
+import "dxos/keys.proto";
+
+package dxos.echo.snapshot;
+
+//
+// Snapshots define full party state at a given point in time.
+// They must have enough information to be able to recover the party state without reading the feed messages.
+//
+// Each snapshot is identified by a party key and a timeframe.
+// The timeframe defines the set of feed messages that have already been processed.
+// When loading from the snapshot, application would skip all of the feed messages up to (and including) the provided timeframe.
+//
+
+message PartySnapshot {
+  bytes party_key = 1;
+  optional timeframe.TimeframeVector timeframe = 2;
+
+  // Unix timestamp of the snapshot creation time. For information purposes only.
+  // TODO(dmaretskyi): Convert to google.protobuf.Timestamp.
+  optional int32 timestamp = 3;
+
+  HaloStateSnapshot halo = 11;
+  // TODO(dmaretskyi): Rename to EchoSnapshot.
+  DatabaseSnapshot database = 12;
+}
+
+// TODO(dmaretskyi): Rename to HaloSnapshot.
+// For now we just store and replay a list of all halo messages as thier number is expected to be relatively low.
+message HaloStateSnapshot {
+  repeated dxos.halo.signed.Message messages = 1;
+}
+
+//
+// Database Snapshot
+//
+
+message DatabaseSnapshot {
+  repeated ItemSnapshot items = 1;
+  repeated LinkSnapshot links = 2;
+}
+
+message ItemSnapshot {
+  optional string item_id = 1;
+  optional string item_type = 2;
+  string model_type = 3;
+  optional string model_version = 4;
+  optional string parent_id = 5;
+  optional ModelSnapshot model = 6;
+}
+
+message LinkSnapshot {
+  optional string link_id = 1;
+  optional string link_type = 2;
+  string model_type = 3;
+  optional string model_version = 4;
+  string source = 5;
+  string target = 6;
+  optional ModelSnapshot model = 7;
+}
+
+/**
+ * Represents the reified state of a state machine.
+ * The snapshots make consist of a custom snapshot object and/or a list of mutations
+ * that are applied to the snapshot or the initial state.
+ */
+// TODO(burdon): Rename?
+message ModelSnapshot {
+  /**
+   * Encoded model snapshot (defined by the model's codec).
+   * If undefined the state machine will be initialized with it's default state.
+   */
+  optional bytes snapshot = 1;
+
+  /**
+   * Mutations to be applied on top of the snapshot, or on top of initial state if the snapshot is undefined.
+   */
+  repeated ModelMutation mutations = 2;
+}
+
+message ModelMutation {
+  // Encoded model mutation, format is defined by model's codec.
+  bytes mutation = 1;
+  ModelMutationMeta meta = 2;
+}
+
+message ModelMutationMeta {
+  dxos.keys.PublicKey feed_key = 1;
+  int32 seq = 2;
+  dxos.keys.PublicKey member_key = 3;
+}

package/src/proto/dxos/echo/timeframe.proto

@@ -0,0 +1,21 @@
+//
+// Copyright 2020 DXOS.org
+//
+
+syntax = "proto3";
+
+package dxos.echo.timeframe;
+
+/**
+ * Vector timestamp used to order messages.
+ */
+message TimeframeVector {
+  message Frame {
+    // TODO(dmaretskyi): Compress using numeric feed indexes.
+    // TODO(burdon): Determine if admit DAG can be ordered. Requires party messages to be ordered (by lexical feed key).
+    bytes feed_key = 1;
+    int32 seq = 3;
+  }
+
+  repeated Frame frames = 1;
+}

package/src/proto/dxos/google.proto

@@ -0,0 +1,7 @@
+//
+// Copyright 2020 DXOS.org
+//
+
+// Adds `BytesType` definition.
+
+import public "google/protobuf/wrappers.proto";

package/src/proto/dxos/halo/credentials/auth.proto

@@ -0,0 +1,31 @@
+//
+// Copyright 2020 DXOS.org
+//
+
+syntax = "proto3";
+
+import "google/protobuf/any.proto";
+
+import "dxos/keys.proto";
+
+package dxos.halo.credentials.auth;
+
+/**
+ * The payload for a SignedMessage sent during handshake for replication authentication.
+ */
+message Auth {
+  /// The publicKey of the target Party for these credentials.
+  dxos.keys.PublicKey party_key = 1;
+
+  /// The publicKey of the authenticating Device.
+  dxos.keys.PublicKey device_key = 2;
+
+  /// The publicKey of the authenticating Identity.
+  dxos.keys.PublicKey identity_key = 3;
+
+  /// The publicKey of the authenticating Identity.
+  optional dxos.keys.PublicKey feed_key = 4;
+
+  /// FeedAdmit message to the should be written to a control feed in case the `feed_key` is not admitted to the party.
+  optional google.protobuf.Any feed_admit = 5;
+}

package/src/proto/dxos/halo/credentials/greet.proto

@@ -0,0 +1,125 @@
+//
+// Copyright 2020 DXOS.org
+//
+
+syntax = "proto3";
+
+import "google/protobuf/any.proto";
+
+import "dxos/halo/keys.proto";
+import "dxos/keys.proto";
+
+package dxos.halo.credentials.greet;
+
+//
+// Greeting protocol:
+//
+//  Two nodes: Greeter which acts like a "server" and Invitee which acts like a "client".
+//  All interactions are request/response with the request always sent by the Invitee and the response always
+//  sent by the Invitee.
+//
+//  1) An invitation is generated for the Invitee with a unique ID, known to the Greeter.
+//  2) The Invitee connects to the Greeter over an *open* Topic, using the invitation ID as their peer ID.
+//     This is NOT the Topic of the Party they wish to join, it is one used for Greeting.
+//  3) The Invitee sends a Command message of type BEGIN. This signals the arrival of the invitee, and if necessary,
+//     triggers creation or retrieval of an auth secret for the rest of the process. This secret is normally
+//     communicated out-of-band (eg, voice, IM, etc.). The Greeter responds with a BeginResponse message, acknowledging
+//     the request and indicating the Invitee should proceed to the next step:
+//  4) The Invitee sends a Command message of type HANDSHAKE which includes their secret (eg, PIN, AuthMessage).
+//  5) The Greeter validates the contents (it's genuine, hasn't already been redeemed, the secret matches, etc.)
+//  6) The Greeter returns a HandshakeResponse message with the Party public key and challenge nonce.
+//  7) The Invitee generates one or more AdmitKey and AdmitFeed messages, including the nonce from step (5) then signs
+//     the contents in a SignedMessage.
+//  8) The Invitee sends the SignedMessages in a Command message of type NOTARIZE.
+//  9) The Greeter checks credentials presented and validates the SignedMessage signatures and nonce values.
+//     If all the checks pass then the Admit messages may be published on the Greeter's feed for the target Party,
+//     placed in Envelope messages signed by the Greeter.
+// 10) After writing the messages, the Greeter marks the invitation as having been redeemed, so that it cannot be
+//     used again.
+// 11) The Greeter sends copies of the Greeter-signed Envelope messages to the Invitee in a NotarizeResponse message,
+//     as well as a list of "hints" regarding keys and feeds which are enrolled in the Party. The Invitee uses thes
+//     "hints" to construct its initial view of Party membership, necessary to participate in mutual authentication
+//     for Party feed replication.
+// 12) The Invitee sends the Greeter a FINISH command to acknowledge receipt.
+
+/**
+ * A Greeter command.
+ */
+message Command {
+  enum Type {
+    BEGIN = 0;
+    HANDSHAKE = 1;
+    NOTARIZE = 2;
+    FINISH = 3;
+    CLAIM = 10;
+  }
+
+  Type command = 1;
+
+  // Auth secret (PIN, hash, AuthMessage, etc.).
+  optional bytes secret = 2;
+
+  // TODO(burdon): These seem to be signed messages? In which case we already know the type.
+  // TODO(dboreham): static typing of contained messages is not yet supported, change from any when it is.
+  // Parameters to the command.
+  repeated google.protobuf.Any params = 10;
+};
+
+//
+// Info is optional, and not needed for very simple schemes like using a PIN, but more complicated scenarios schemes
+// might need to communicate additional info in the response (eg, what key is expected for a signed AuthMessage).
+//
+message BeginResponse {
+  map<string, google.protobuf.Any> info = 1;
+}
+
+//
+// The next command is 'HANDSHAKE', the invitee sends the `secret` for authentication, and if successful, the
+// Greeter returns the `party_key` and a `nonce` which the invitee will need to use for the Party credential messages.
+//
+message HandshakeResponse {
+  // Random bytes which must be included in the signed portion of messages submitted in a 'NOTARIZE' command
+  // (proving ownership of the keys in question).
+  bytes nonce = 1;
+
+  // The public key of the party.
+  dxos.keys.PublicKey party_key = 2;
+};
+
+//
+// The 'NOTARIZE' command takes an array of SignedMessages which the invitee would like added to the Party. The
+// standard case would be a message admitting an Identity (or Device) key and a message admitting a feed.
+//
+message NotarizeResponse {
+  // A copy of each of the messages as written to the Party (now in an Envelope signed by the Greeter) and the Feed
+  // and key hints necessary to bootstrap the invitee into the Party.
+  repeated google.protobuf.Any copies = 1;
+
+  dxos.keys.PublicKey genesis_feed = 3;
+};
+
+// TODO(dmaretskyi): Verify if this is valid. Wouldn't the knowledge of the party's public key be enough to verify the rest of credential messages?
+//
+// Feed and key hints are by the invitee, because even though the Party members now trust it, it does not trust
+// them. Until it has a chance to replicate, it cannot construct its own understanding of the Party from party.*
+// messages, but neither can it replicate unless it trusts its peers. The Hints break this cycle by providing an
+// initial set of keys and Feeds to trust.
+//
+message KeyHint {
+  // TODO(telackey): These should be changed to be the full set of signed party messages, so the recipient can build
+  // and verify the party structure just as it would if it had obtained them from the feeds.
+  dxos.keys.PublicKey public_key = 1;
+  keys.KeyType type = 2;
+}
+
+//
+// The 'CLAIM' command is used to trigger the Greeting flow by "claiming" a PartyInvitation which was replicated
+// to the Party or presented as a "proof".
+//
+// The ClaimResponse provides the invitee with information about the interactive invitation triggered by the "claim",
+// such as the invitation ID and the swarm key to use to connect to the Greeter.
+//
+message ClaimResponse {
+  bytes id = 1;               // The ID of the invitation.
+  bytes rendezvous_key = 2;   // The swarm key to use to rendezvous with the Greeter.
+}

package/src/proto/dxos/halo/credentials/identity.proto

@@ -0,0 +1,21 @@
+//
+// Copyright 2020 DXOS.org
+//
+
+syntax = "proto3";
+
+import "dxos/keys.proto";
+
+package dxos.halo.credentials.identity;
+
+// Additional, descriptive information about an Identity. Must be signed by the Identity's key.
+message IdentityInfo {
+  dxos.keys.PublicKey public_key = 1;     // The publicKey of the Identity (must be signed by this key).
+  string display_name = 2;                // The display name to use for this key.
+}
+
+// Additional, descriptive information about a Device. Must be signed by the Device's key.
+message DeviceInfo {
+  dxos.keys.PublicKey public_key = 1;     // The publicKey of the Device (must be signed by this key).
+  string display_name = 2;                // The display name to use for this key.
+}

package/src/proto/dxos/halo/credentials/party.proto

@@ -0,0 +1,127 @@
+//
+// Copyright 2020 DXOS.org
+//
+
+syntax = "proto3";
+
+import "dxos/halo/keys.proto";
+import "dxos/halo/signed.proto";
+import "dxos/keys.proto";
+
+package dxos.halo.credentials.party;
+
+//
+// Party Credentials are messages that, by virtue of their being signed by a key that is a
+// recognized authority, convey to the recipient that something should be allowed or done.
+// They are therefore similar in structure and purpose to X.509 certificates and to W3C
+// Verifiable Credentials. The "subject" for a Party Credential (who or what can do the thing allowed),
+// along with the kind of action permitted is specified in one of the four contained message
+// types: PartyGenesis, FeedGenesis, KeyAdmit, FeedAdmit. One such subject message is
+// present in the contents field of each PartyCredential message.
+// PartyMessage carries common metadata (created, nonce) and the type of the subject message (type).
+// Note that the subject message type is explicitly present in the type field even though
+// its type will be discoverable via the relevant codec at runtime. This arrangement allows
+// for signing to be done over the relevant fields (fields for which signature inclusion is
+// necessary to ensure the security of the system), without needing to make assumptions about
+// the presence and specific form of the codec-supplied message type identification.
+// The complete credential comprises the PartyCredential message contents, signed by the
+// relevant authority key(s), encoded as a SignedMessage (see ../signed.proto).
+//
+message PartyCredential {
+  enum Type {
+    ENVELOPE = 0;
+    PARTY_GENESIS = 1;
+    FEED_GENESIS = 2;
+    KEY_ADMIT = 3;
+    FEED_ADMIT = 4;
+  }
+
+  Type type = 1;
+
+  oneof contents {
+    Envelope envelope = 10;
+    PartyGenesis party_genesis = 11;
+    KeyAdmit key_admit = 12;
+    FeedAdmit feed_admit = 13;
+    FeedGenesis feed_genesis = 14;
+  }
+}
+
+//
+// The start-of-authority record for the Party, admitting a single key (usually a pseudonym) and a single feed.
+// It must be signed by all three keys (party, key, feed). The Party private key should be destroyed after
+// signing this message. This pattern is sometimes called an Inception Key.
+//
+message PartyGenesis {
+  dxos.keys.PublicKey party_key = 1;          // The party public key.
+  dxos.keys.PublicKey feed_key = 2;           // The initial feed to admit.
+  dxos.keys.PublicKey admit_key = 3;          // The key to admit (usually a pseudonym key).
+  keys.KeyType admit_key_type = 4;            // The KeyType of the admitKey.
+}
+
+//
+// Admit a single public key to the Party. This message must be signed by the key to be admitted, to prevent
+// impersonation attacks, and unless the contents of an Envelope, also by a key which has already been admitted.
+// Admitted keys represent entities in the Party Authority trust tree, for example: an identity pseudonym key
+// representing "Alice in this party", or a device pseudonym key representing "Alice's Laptop in this Party".
+//
+message KeyAdmit {
+  dxos.keys.PublicKey party_key = 1;
+  dxos.keys.PublicKey admit_key = 2;          // The public key to admit.
+  keys.KeyType admit_key_type = 3;            // The KeyType of the admitKey.
+}
+
+//
+// Admit a single feed to the Party. This message must be signed by the feed key to be admitted, also by some other
+// key which has already been admitted (usually by a device pseudonym key).
+// FeedAdmit messages constitute the leaf nodes in the Party Authority trust tree in that Party data is transmitted
+// via feeds and therefore to write to a Party a node must have at least one feed admitted.
+//
+message FeedAdmit {
+  dxos.keys.PublicKey party_key = 1;          // The Party public key.
+  dxos.keys.PublicKey feed_key = 2;           // The Feed public key.
+}
+
+//
+// The start-of-authority record for the Feed, signed by the owner of the feed and the feed.
+// The owner must be a key previously admitted to the Party.
+//
+message FeedGenesis {
+  dxos.keys.PublicKey feed_key  = 1;          // The feed public key.
+  dxos.keys.PublicKey owner_key = 2;          // The public key of the owner of this feed.
+}
+
+//
+// TODO(burdon): Needs discussion.
+// A signed message containing a signed message. The nested signed structure allows a signed message
+// received from another node that is not yet a party member (invitee), to be published on the party on behalf
+// of that node by another node (greeter). It thereby provides a kind of delegated authority mechanism used to
+// link signatures across the two nodes in a replay and impersonation resistant manner.
+// Envelope is used by a Greeter to write, and countersign using
+// its key, a message provided to it, signed by the Invitee, to the Party, via the greeting node's feed.
+// The signature on the Envelope is that of the Greeter, while the signature(s) on the interior message are
+// those of the Invitee, demonstrating ownership by the Invitee of the keys or feeds to be admitted.
+// Envelope exists solely to include the party key under the countersignature, otherwise two nested SignedMessages
+// could be used. The party key is included to prevent replay attacks where a valid credential from one
+// party is used to gain access to a different party.
+// The interior message can only be of types:
+//   KEY_ADMIT
+//   FEED_ADMIT
+//
+message Envelope {
+  dxos.keys.PublicKey party_key = 1;          // The Party public key.
+  dxos.halo.signed.Message message = 2;       // The original Message.
+}
+
+//
+// A PartyInvitation message that can be written to the Party so that any Party member can authenticate
+// the invitee and perform greeting. This message must be written within a SignedMessage signed by the key (or KeyChain)
+// of listed as the `issuer`. The invitee must authenticate themselves to the Greeter with Auth messages signed by
+// the key (or KeyChain) of listed in the `invitee` field.
+//
+message PartyInvitation {
+  bytes id = 1;                               // A unique ID for this Invitation.
+  dxos.keys.PublicKey party_key = 2;          // The public key of the Party for which this Invitation is valid.
+  dxos.keys.PublicKey issuer_key = 3;         // The public key of the Party member issuing this invitation.
+  dxos.keys.PublicKey invitee_key = 4;        // The public key of the non-member that is being invited to join the Party.
+}

package/src/proto/dxos/halo/credentials.proto

@@ -0,0 +1,232 @@
+//
+// Copyright 2022 DXOS.org
+//
+
+syntax = "proto3";
+
+package dxos.halo.credentials;
+
+import "google/protobuf/any.proto";
+import "google/protobuf/timestamp.proto";
+
+import "dxos/keys.proto";
+
+//
+// TODO(burdon): Move these notes to the design doc commentary.
+// Peers maintain Feeds that are admitted to HALO and ECHO Parties.
+// Peers act as Verifiers for Credentials that may be Presented from other Peers.
+// Since Feeds implement a signed hash-linked data structure, they constitute a chain-of-authority for chained Credentials.
+// Credentials written to HALO Feeds may be Presented to Peers Verifying ECHO Parties.
+//
+
+//
+// **PartyGenesis** -
+//  First message written to initial Feed in a new Party.
+//
+
+message PartyGenesis {
+  dxos.keys.PublicKey party_key = 1; // Feeds belong to Parties.
+}
+
+//
+// **Claim** -
+//  Statement about a subject.
+//  Claims can be written directly to a feed or used within Credentials.
+//
+
+// Agent is authorized to access Party.
+message PartyMember {
+  // TODO(burdon): Consider permissions (e.g., for Bots).
+  enum Role {
+    INVALID = 0;
+    /// Manage members.
+    ADMIN = 1;
+    /// Read and write.
+    MEMBER = 2;
+    /// Read-only.
+    READER = 3;
+  }
+
+  dxos.keys.PublicKey party_key = 1;
+  Role role = 2;
+}
+
+// Device is authorized to sign messages for a given Agent (Identity).
+// NOTE: Devices are Admitted to Identities.
+message AuthorizedDevice {
+  dxos.keys.PublicKey identity_key = 1;
+  dxos.keys.PublicKey device_key = 2; // Existing authorized device.
+}
+
+// Feed is admitted to the Party for replication.
+// NOTE: Feeds are Admitted to Parties.
+message AdmittedFeed {
+  enum Designation {
+    /// Classic general purpose feeds for both HALO and ECHO messages together. To be deprecated.
+    GENERAL = 0;
+    /// Contain system-level messages messages, such as credentials and epochs.
+    CONTROL = 1;
+    /// Database mutations.
+    DATA = 2;
+  }
+
+  dxos.keys.PublicKey party_key = 1;
+
+  /// Owning identity.
+  dxos.keys.PublicKey identity_key = 2; // Could be derived.
+  /// Owning device.
+  dxos.keys.PublicKey device_key = 3;
+
+  /// Controls sets the feed designation. Feeds with different designations are consumed by separate pipelines.
+  Designation designation = 4;
+}
+
+/// Associtaes a space that will implement Agent's HALO with an Identity.
+message HaloSpace {
+  dxos.keys.PublicKey identity_key = 1;
+  /// Space key.
+  dxos.keys.PublicKey halo_key = 2;
+}
+
+/// Grants recovery permissions to a recovery key.
+message IdentityRecovery {
+  dxos.keys.PublicKey identity_key = 1;
+  /// Public key derrived from the recovery seedphrase.
+  dxos.keys.PublicKey recovery_key = 2;
+}
+
+/// Sets profile information.
+message IdentityProfile {
+  message ProfileDocument {
+    optional string display_name = 1;
+    optional string avatar_cid = 2;
+  }
+
+  // TODO(dmaretskyi): This could also be a DXNS link or stored in user's public HALO (we could also index the public HALO in the DMG).
+  ProfileDocument profile = 1;
+}
+
+/// Metadata associated with a key.
+/// Subject must be a key being referenced.
+message KeyInfo {
+  optional string name = 1;
+}
+
+/// Assertion for agents authenticating in the space swarm.
+message Auth {
+}
+
+//
+// **Claim** -
+//  Statement about a subject.
+//  Claims can be written directly to a feed or used within Credentials.
+//
+
+message Claim {
+  dxos.keys.PublicKey id = 1;                     // Subject of claim (e.g., Agent, Device, Feed).
+  google.protobuf.Any assertion = 2;
+}
+
+//
+// **Proof** -
+//  Signature that makes Credential tamper-evident.
+//  The proof is signed by the issuer of the Credential.
+//  Ref: https://www.w3.org/TR/vc-data-model/#proofs-signatures
+//
+
+message Proof {
+  string type = 1;                                // Type of proof (e.g., "Ed25519Signature2020").
+  google.protobuf.Timestamp creation_date = 2;
+  dxos.keys.PublicKey signer = 3;                 // Entity that created the proof (e.g., Agent, Device, Party).
+  optional bytes nonce = 4;                       // Used in Presentations to protect against replay attacks.
+
+  /// Signature (excluded from signed data).
+  bytes value = 5;
+
+  /**
+   * Must be present if signer is not credential issuer.
+   * Establishes the authority of the signer. Proves that the signer can issue such credentials.
+   * Excluded from signed data.
+   */
+  optional Chain chain = 6;
+}
+
+/**
+ * A chain of credentials that establishes the delegated authority to issue new credentials.
+ * Each key in the chain has an assotiated credential that establishes the authrity of that specific key.
+ *
+ * Example:
+ *   Alice/Device-2 => Alice/Device-1 => Alice
+ *
+ * This chain would include 2 credentials:
+ *   1. Giving Alice/Device-2 the authority to issue credentials on behalf of Alice, signed by Alice/Device-1.
+ *   2. Giving Alice/Device-1 the authority to issue credentials on behalf of Alice, signed by Alice.
+ */
+message Chain {
+  /// Credential that authorizes the subject to issue new credentials (can be recursive).
+  Credential credential = 1;
+}
+
+//
+// **Credential** -
+//  Set of claims containing a proof signed by the issuer.
+//  Credentials may be stored in a Credential Repository (e.g., digital wallet.)
+//  Credentials may also be store within feeds (e.g., an agent's HALO).
+//
+
+message Credential {
+  optional dxos.keys.PublicKey id = 1;                      // Credential identifier (e.g., for storage indexing).
+  dxos.keys.PublicKey issuer = 2;                           // key = { Party (genesis) | Identity (genesis) | (authorized) Device }
+  google.protobuf.Timestamp issuance_date = 3;
+  optional google.protobuf.Timestamp expiration_date = 4;
+  optional bytes expiration_ref = 5;                        // Could reference blockchain or epoch number.
+  Claim subject = 10;
+  Proof proof = 11;
+}
+
+//
+// **Presentation** -
+//  Signed Credential(s) sent to a Verifier.
+//  Presentations are typically NOT stored any may include a challenge (e.g., nonce).
+//  Presentations may contain multiple Credentials (and require multiple proofs).
+//
+
+message Presentation {
+  repeated Credential credentials = 1;
+  repeated Proof proofs = 2;
+}
+
+//
+// **Metadata** -
+//   Persistant metadata stored outside of used to bootsrapt the stack.
+//
+
+/// Information needed to bootstrap a Space.
+message SpaceRecord {
+  dxos.keys.PublicKey space_key = 1;
+
+  /// All feeds in the space must form a DAG (or a tree?). This is the root feed of that structure.
+  dxos.keys.PublicKey genesis_feed_key = 2;
+
+  /// Key of the writable feed for control messages. Keyring must have the asscoiated private key.
+  dxos.keys.PublicKey write_control_feed_key = 3;
+
+  /// Key of the writable feed for data messages. Keyring must have the asscoiated private key.
+  dxos.keys.PublicKey write_data_feed_key = 4;
+}
+
+/// Information needed to bootstrap an Identity.
+message IdentityRecord {
+  dxos.keys.PublicKey identity_key = 1;
+  dxos.keys.PublicKey device_key = 2;
+
+  SpaceRecord halo_space = 3;
+
+  /// Public profile information.
+  /// Not yet implemented. Must be null.
+  optional SpaceRecord profile_space = 4;
+
+  /// Cached profile.
+  optional IdentityProfile.ProfileDocument profile = 5;
+}
+