Differential D7003 Diff 23699 shared/protos/identity_client.proto

Changeset View

Standalone View

shared/protos/identity_client.proto

This file was added.

				syntax = "proto3";

				package identity.client;

				// RPCs from a client (iOS, Android, or web) to identity service
				service IdentityClientService {

				// Account actions

				// Called by user to register with the Identity Service (PAKE only)
				rpc RegisterPasswordUser(stream RegistrationRequest) returns (stream
				RegistrationResponse) {}
				// Called by user to update password and receive new access token
				rpc UpdateUserPassword(stream UpdateUserPasswordRequest) returns
				(stream UpdateUserPasswordResponse) {}
				// Called by user to register device and get an access token
				rpc LoginPasswordUser(stream OpaqueLoginRequest) returns
				(stream OpaqueLoginResponse) {}
				rpc LoginWalletUser(WalletLoginRequest) returns (WalletLoginResponse) {}
				// Called by a user to delete their own account
				rpc DeleteUser(DeleteUserRequest) returns (Empty) {}

				// Sign-In with Ethereum actions

				// Called by clients to get a nonce for a Sign-In with Ethereum message
				rpc GenerateNonce(Empty) returns (GenerateNonceResponse) {}
				}

				// Helper types

				message Empty {}

				// Key information needed for starting a X3DH session
				message IdentityKeyInfo {
				// JSON payload containing Olm Identity keys
				// Sessions for users will contain both IdentityKeys and NotifKeys
				// For keyservers, this will only contain IdentityKeys
				string payload = 1;
				// Payload signed with the signing ed25519 key
				string payloadSignature = 2;
				// Signed message used for SIWE (optional)
				// This correlates a given wallet with the identity of a device
				optional string socialProof = 3;
				}

				// Ephemeral information provided to create initial message
				// Prekeys are generally rotated periodically
				// One-time Prekeys are "consumed" after first use
				message PreKeyResponse {
				// Rotating preKey, validated to be associatd with IdentityKeys
				// through signature
				string preKey = 4;
				string preKeySignature = 5;
				ashoatUnsubmitted Done Inline Actions We might consider "combining" these in some way as a single value called `signedPreKey` (eg. it could be a JSON blob containing these two values). I don't feel strongly, but worth noting that these two should always be sent / uploaded together in all APIs ashoat: We might consider "combining" these in some way as a single value called `signedPreKey` (eg. it…
				jonAuthorUnsubmitted Done Inline Actions I separated them out to avoid having to deserialize and serialize the information often. I was optimizing for the "how much do I need to do in code" rather than "how is this thought of conceptually in crypto". Personally, I would like to just have a comment saying that the signature is also required. But wondering what @varun thinks. jon: I separated them out to avoid having to deserialize and serialize the information often. I was…
				jonAuthorUnsubmitted Done Inline Actions Talked to varun offline, and we came to agree that we should have separate fields to avoid serializing/deserializing the values. jon: Talked to varun offline, and we came to agree that we should have separate fields to avoid…
				// One time key, removed from available list of one time keys after requested
				// Client is also intended to remove OPKs after initial message
				optional string onetimePrekey = 6;
				}

				// Information needed when establishing communication to someone else's device
				message RemoteDeviceInfo {
				IdentityKeyInfo identityInfo = 1;
				PreKeyResponse identityPrekeys = 2;
				PreKeyResponse notifPrekeys = 3;
				}

				// Information needed when establishing communication to a keyserver
				message KeyserverSessionInfo {
				IdentityKeyInfo identityInfo = 1;
				PreKeyResponse identityPrekeys = 2;
				}

				// RegisterUser

				// Ephemeral information provided so others can create initial message
				// to this device
				//
				// Prekeys are generally rotated periodically
				// One-time Prekeys are "consumed" after first use, so many need to
				// be provide to avoid exhausting them.
				message PreKeyRegistrationUpload {
				// Rotating preKey, validated to be associatd with IdentityKeys
				// through signature
				string preKey = 1;
				string preKeySignature = 2;
				// One time keys
				// Removed from available list after requested by another client
				repeated string onetimePrekeys = 3;
				}

				// Bundle of information needed for creating an initial message using X3DH
				message DeviceKeyUpload {
				IdentityKeyInfo deviceKeyInfo = 1;
				PreKeyRegistrationUpload identityUpload = 2;
				PreKeyRegistrationUpload notifUpload = 3;
				}

				// Request for registering a new user
				message ClientRegistrationRequest {
				// ed25519 key for the given user's device
				string deviceEd25519PublicKey = 1;
				ashoatUnsubmitted Done Inline Actions We name this `signingPublicKey` elsewhere. Should we be consistent? Do we even need to provide this separately given it's already provided via the `DeviceKeyUpload`? ashoat: 1. We name this `signingPublicKey` elsewhere. Should we be consistent? 2. Do we even need to…
				// Message sent to initiate PAKE registration (step 1)
				bytes opaqueRegistrationRequest = 2;
				string username = 3;
				// Information needed to open a new channel to current user's device
				DeviceKeyUpload deviceKeyUpload = 4;
				}

				// Messages sent from a client to Identity Service
				message RegistrationRequest {
				oneof data {
				// First message in PAKE registration + user information
				ClientRegistrationRequest registrationRequest = 1;
				// Final message in PAKE registration
				bytes opaqueRegistrationUpload = 2;
				}
				}

				// Messages sent from Identity Service to client
				message RegistrationResponse {
				oneof data {
				// sent to the user upon reception of the PAKE registration attempt
				// (step 2)
				bytes opaqueRegistrationResponse = 1;
				// After successful unpacking of user credentials, return token
				string accessToken = 2;
				}
				}

				// UpdateUserPassword

				// Request for updating a user, similar to registration but need a
				// access token to validate user before updating password
				message InitialUpdateUserPasswordRequest {
				// Message sent to initiate PAKE registration (step 1)
				bytes opaqueRegistrationRequest = 1;
				// Used to validate user, before attempting to update password
				string accessToken = 3;
				}

				// Do a user registration, but overwrite the existing credentials
				// after validation of user
				message UpdateUserPasswordRequest {
				oneof data {
				InitialUpdateUserPasswordRequest updateRequest = 1;
				bytes opaqueRegistrationUpload = 2;
				}
				}

				message UpdateUserPasswordResponse {
				oneof data {
				bytes opaqueRegistrationResponse = 1;
				// After validating client reponse, mint a new token
				string accessToken = 2;
				}
				}

				// LoginUser

				message InitialOpaqueLoginRequest {
				string username = 1;
				// ed25519 key for the given user's device
				string signingPublicKey = 2;
				ashoatUnsubmitted Done Inline Actions We name this `deviceEd25519PublicKey` elsewhere. Should we be consistent? Do we even need to provide this separately given it's already provided via the `DeviceKeyUpload`? ashoat: 1. We name this `deviceEd25519PublicKey` elsewhere. Should we be consistent? 2. Do we even need…
				jonAuthorUnsubmitted Done Inline Actions my `arc diff` update landed right before you submitted your review, I'm not sure which line this is referring to. jon: my `arc diff` update landed right before you submitted your review, I'm not sure which line…
				ashoatUnsubmitted Done Inline Actions You can click the link to figure it out? ashoat: You can click the link to figure it out?
				jonAuthorUnsubmitted Done Inline Actions I see now, the JSON encoded payload will contain the same key. I'll defer to @varun since this was carried over from the previous RPC. My personal inclination is to remove the duplication, and just parse of the keys, as we should be validating the IdentityKey payload anyway. jon: I see now, the JSON encoded payload will contain the same key. I'll defer to @varun since…
				// Message sent to initiate PAKE login (step 1)
				bytes opaqueLoginRequest = 3;
				// Information specific to a user's device needed to open a new channel of
				// communication with this user
				DeviceKeyUpload deviceKeyUpload = 4;
				}

				message OpaqueLoginRequest {
				oneof data {
				InitialOpaqueLoginRequest loginRequest = 1;
				// Message containing client's reponse to server challenge.
				// Used to verify that client holds password secret (Step 3)
				bytes opaqueLoginUpload = 2;
				}
				}

				message OpaqueLoginResponse {
				oneof data {
				// Opaque challenge sent from server to client attempting to login (Step 2)
				bytes opaqueServerResponse = 1;
				// Mint and return a new key upon successful login
				string accessToken = 2;
				}
				}

				message WalletLoginRequest {
				// ed25519 key for the given user's device
				string signingPublicKey = 1;
				ashoatUnsubmitted Done Inline Actions We name this `deviceEd25519PublicKey` elsewhere. Should we be consistent? Do we even need to provide this separately given it's already provided via the `DeviceKeyUpload`? ashoat: 1. We name this `deviceEd25519PublicKey` elsewhere. Should we be consistent? 2. Do we even need…
				string siweMessage = 2;
				string siweSignature = 3;
				// Information specific to a user's device needed to open a new channel of
				// communication with this user
				DeviceKeyUpload deviceKeyUpload = 4;
				}

				message WalletLoginResponse {
				string accessToken = 1;
				}

				// DeleteUser

				message DeleteUserRequest {
				string accessToken = 1;
				}

				// GenerateNonce

				message GenerateNonceResponse{
				string nonce = 1;
				}