Welcome to Mooti’s public facing documentation. These pages include an overview of the technical capabilities of Mooti’s products, why and how you would implement them, and the technical details on how to do so.
These documents assume a basic familiarity with public/private encryption key pairs, programming, HTTP, and API consumption. These pages are tailored to clients integrating Mooti’s product into their existing architecture and applications.
Below is our current suite of products with details on the common client needs they serve and also how they compliment each other to offer a comprehensive solution. We also handle a good deal of custom work related to these products for various clients so please contact us if you have a specific requirement that isn’t outlined below.
Mooti Edge is our suite of libraries on both Android and iOS that are used to handle securely managing key pairs on mobile devices. Capabilities include:
- Generating public/private keypairs on device with a private key never leaving a user’s mobile device
- Protect a user’s private key via pin, password, fingerprint, and facial recognition
- Scan a public key via QR code
- Push a public key up to Mooti Server or other key stores
- Send messages to Mooti Server encrypted with a user’s private key and Mooti Server’s public key
- Receive requests from Mooti Server for a user to verify their identity on their mobile device
These features provided a critical first step for any organization that is looking to let their users manage their own self sovereign identity and is also critical for any infrastructure that relies on public/private key pairs such as writing transactions to a blockchain.
The following options are available for leveraging these libraries.
- They can be provided to your development team for integration into your existing mobile applications.
- We can assist with integrating the libraries into your mobile application
- Clients can white-label our existing Mooti mobile application with their own branding and we handle development.
Common Use Cases
The following are scenarios where Mooti Edge is commonly used by our clients.
- Allow your users to create a unique identifier specific to their mobile device that can be used to verify all future transactions and requests have been sent from that same device.
- Ensure that users can only use this unique identifier if they meet certain challenge criteria such as fingerprint recognition or facial recognition.
- This can be used in both user registration and login flows for a level of security above standard password based login.
- It can also be used to replace passwords altogether to create a better user experience when logging in or registering.
- Ensure all transactions from a user’s mobile device are encrypted before transmission with a composite key that only allows the designated receiver of those transactions to decrypt them.
Library Structure and Methods
The following classes and methods are available on both iOS and Android and are nearly identical except some small differences which are noted when necessary. In addition to the library classes, we also have boilerplate application files to standup a mobile app on iOS and Android. These are valuable for understanding the correct implementation of the library classes, testing functionality, and can also be repurposed to serve as the basis of a client specific white-labeled application.
Deals with storing, creating, and retrieving keys on device as well as protecting them via password, pin, fingerprint, or facial recognition. These protection methods are referred to as key protection factors.
- createKeyPair(Keypair, Pin, Password, Fingerprint, Facial Recognition) - Stores a new key pair in app isolated preferences and takes options related to key protection factors. These must be used when retrieving the private key
- deleteKeyPair(Pin, Password, Fingerprint, Facial Recognition) - Delete the key pair. Any key protect factors that were initially supplied when creating the key must be supplied to delete it.
- getPublicKey() - Get the public key
- getPrivateKey(Pin, Password, Fingerprint, Facial Recognition) - Get the private key and supply any key protection factors required.
Deals with encrypting and decrypting strings using a user’s keys.
- encryptMessage(PublicKey, Message) - Encrypts a message using a user’s private key and also the recipient’s public key
- decryptMessage(Public Key, Encrypted Message) - Decrypts a message using a user’s private key and the sender’s public key
- initialize() - Read config for Mooti Server and connects.
- retrievePublicKeyFromQRCode() - Scans a QR code to retrieve a public key. Can optionally also get a client specific user identifier (such as a unique database key) from the QR code in addition to a public key.
- receiveMessage(EncryptedMessage) - Receives encrypted message from Mooti Server and allows for other in app methods to be triggered.
- sendMessage(EncryptedMessage) - Sends an encrypted message up to Mooti Server and acknowledges receipt of message.
Ties directly into encryption methods, libraries, and algorithms. This class is used by MootiCrypto and varies somewhat depending on libraries available on each mobile platform. This is not designed to be used directly but is used by MootiCrypto.
Mooti Server is our hosted or deployable (in your infrastructure) solution that complements the functionality in Mooti Edge to enable a comprehensive infrastructure for interacting with users and their key pairs. It also provides functionality to keep a running internal chain of hashes for all user identity attestation records. These internal hashes can be written to a public blockchain at set intervals to create a fully auditable and tamper proof record of when users created their identity (public/private keypair) and verify themselves (verify ownership of a private key).
The following standard functionality is available in our core codebase and is customized as needed on specific projects.
- Provide a QR code for a user to scan which contains the Mooti Server public key and also a unique user identifier if required by an identity creation workflow
- Store public keys for users and any information needed to relate these public keys back to other internal systems
- Receive an encrypted message from the Mooti Edge mobile libraries and verify that the sender of this message is in possession of the related private key to verify their identity.
- Send a request to a specific user’s mobile device for them to verify their identity and/or approve a transaction.
- Trigger actions in other systems via HTTP or Web Socket requests when a user verifies their identity
- Receive requests from other systems which prompt a user to verify their identity
- Keep a running chain of hashes for ID creation and attestation records. A hash from this chain can occasionally be written to a public facing blockchain. This functionality is blockchain agnostic and we’ve integrated it previously with Ethereum and Hyperledger, but it can also be easily integrated with other blockchains by creating or leveraging an existing service to write transactions.
There are two standard hosting options for Mooti Server which can both be adjusted to meet specific requirements.
Hosted as a Service
Mooti can host the server in our infrastructure and will be responsible for all server maintenance, monitoring, and updates. This solution is good for projects where a client is looking to quickly test our solution without creating their own infrastructure and also works well in production for clients who would rather not have another server to manage.
Self Hosted Solution
Mooti can also deliver AWS AMIs, docker images, or compiled application files with instructions to deploy our solution in your own infrastructure. This option works well for clients who have internal compliance requirements to satisfy and want to maintain more control over pieces of their technical infrastructure.
Common Use Cases
The following are some common use cases where Mooti Server can be leveraged.
- Trigger an action in another system when a user creates their identity (public/private key pair)
- Store information (such as an existing internal user identifier) with a user’s public key
- Trigger actions in other systems when a user verifies their identity (ownership of their private key)
- Receive a request from another internal system which triggers a user to verify their identity, and then report back to that internal system when a user has successfully verified their identity
- Creating a fully verifiable and immutable record of identity transactions backed by writing hashes to a public blockchain