A technical breakdown of the guiding principles and underlying technology behind the StellarAuth service.
StellarAuth is a service which employs a new security model for creating and storing account keypairs. It allows Applications to generate dedicated accounts for their Users in a provably secure way. The goal is to achieve a user-friendly experience which doesn't compromise on the best cryptography practices.
StellarAuth can be broken down into 4 active entities. They all interact and as we will see the lines between these divisions can get blurry, but seeing StellarAuth broken down in this way will help us to understand the greater goals and uses for the service.
App
This is your application. The service into which you're considering implementing StellarAuth. This is the most respected entity of the stack. It may not be the most important, as that will depend on what aspect of StellarAuth we're considering, but when it comes to the final say, the client if you will that StellarAuth is trying to please, impress and improve the life of, is your application.
Users
Right behind your app, are your users. While we ultimately turn to your app for the answer of how to treat your users, ultimately we will let your app decide their fate, with important caveats, as we will see. StellarAuth's primary relationship with your users is ease of use, letting them accomplish your Application's asks with as little friction as possible. StellarAuth is aiming to fade into the background of your Application's conversation with your Users. We are the invisible arbitrator, escrow and separator of interests. We are not a service in of ourselves, we are an extension of your App's service to your Users.
Keys
Circling around this conversation of App to User are Keys. Keys are the phone number, the PO box, the email address, the 2FA code, giving you access into your User's lives, allowing you to request actions of them. This by itself is not something new or the reason why you'd use StellarAuth as an alternative to SMS, (e)mail or traditional 2FA, the reason this is powerful is that it is both incredibly secure and frictionless. To date, especially when it comes to crypto, one or the other has been sacrificed at some level, either security or usability. By taking a firm stance on defining the differences between Apps, Users and Keys, and specifically how Keys should be stored, who should ultimately "own" the Keys and how and to whom usage of those Keys can be granted, we believe we've arrived at a truly groundbreaking service in the fight for crypto adoption.
StellarAuth
Tying these three entities together is the StellarAuth Server and App. An App API backend and a User facing native application. StellarAuth acts as a sort of protocol or translator informing and defining the conversation between App and User so security and usability can both be upheld together rather than one or the other teetering on the scale.
Server
The StellarAuth Server consists of a basic collection of AWS serverless lambda endpoints and a simple PostgreSQL database. It provides a standard communication syntax for Apps to communicate with their Users and for Users to securely and easily respond to those Applications with which they have accounts. We accomplish this through an opinionated distribution of permissions. This is where you'll want to start paying attention as StellarAuth at this point will begin to look and feel quite different than what you may be used to.
Within StellarAuth:
- Users own their keys transparently. They have no right or ability to request their secret seed in raw form. Keys in StellarAuth are a utility not an asset, they facilitate conversation but are not the focus of it. As such Users will not be granted the ability to take their private key or merge their account away without the Application's consent. It's worth noting that neither the Application nor StellarAuth have this privilege either. Ultimately the Keys are encrypted with a User secret and signed on device, so functionally the User owns the key, but transparently. Keys are conversations, and no one entity will be encouraged or allowed to dominate the conversation.
- What this means is that StellarAuth is not a wallet in the current sense of the word. Your App would be the wallet and should you choose to grant a User the ability to merge their account away and take their business elsewhere that's up to you to decide, not StellarAuth. If you believe the User should own everything and you desire to build that logic into your App that's up to you, StellarAuth should not and must not require that.
- This also means you cannot bring your own pre-existing keys to StellarAuth. The arbitration that StellarAuth is setting up between your App and your User is unique and opinionated and it's imperative that it works both predictably and securely. We've chosen to take a firm stance here as we simply don't believe a one for many use of keys is secure. If you choose to allow your Users to see and share their public key that's up to you, but we won't natively allow or enforce this practice.
- Neither Applications nor the StellarAuth Server see secret keys, ever, under any circumstances
- It might be painful at first as you'll need to handle rejection, time delays, or general failures but in the long run this is the better way.
- Applications can only send requests to those keys which they initiated the creation of
- This will limit the usability of cross application requests but agreeable applications could easily create a simple protocol for allowing or screening requests from one app to another.
- Key creation, encryption and decryption only ever happens locally on the User's StellarAuth app
App
The StellarAuth App is a simple, secure, User facing native application for the creation and securing of Keys and the signing of transactions as they are sent by Applications to those Keys. We will attempt to maintain usable versions for at least Mac, iOS, Windows and Android. We achieve this currently by utilizing VueJS and Capacitor to maintain a single code base for deploying to all these platforms. I'm currently unsure if I will support a public network web version as that would more easily expose passcodes and Key files to attack and compromise. For now we have a web version for the testnet but have no plans to support the public network.
If you have any questions, suggestions or would like greater detail or clarity on anything please don't hesitate to ask. A primary purpose in publishing this post is to expose the details of our thinking within StellarAuth and to allow for collaboration and improvements. Thanks for your time and interest in what I consider to be a most important service which could greatly improve both crypto application development and just secure app development in general.
Many thanks to @MikeFair, @JordanDWhalen, @MisterTicot, @StellarGuard and @dzham for their help and input at different stages along the journey to get to where we are today.
