StellarExpert ID – Single-Sign-On App and Tx Signer for Stellar Network

mazieres The documentation is not ready yet. Hopefully, I will publish all source codes and docs in a week or so.

The flow is quite simple.

1. A user invokes some action on the third-party website (a wallet, DEX interface, inflation pool etc). Let's say, he wants to create an offer.
2. The website prepares the requested transaction and it's XDR representation in base64 format.
3. The website initiates the intent (see intent list in the project description) using js module that provides an interface for all supported intents.
4. The interface module opens a new pop-up window pointing to id.stellar.expert. All intent parameters are serialized and transmitted in a form of GET parameters. So the full URL will look like https://id.stellar.expert/confirm?intent=sign_tx&network=testnet&txXdr=AAAAALPZeTF82....
5. Signer application reads parameters from the URL and asks the user for a confirmation.
6. The user chooses a keypair from the list of stored accounts (or adds a new one) and confirms the action.
7. The signer app signs the transaction the same way any other wallet do it.
8. The signed transaction is serialized into XDR as TransactionEnvelope and transmitted back to the opener site in base64 encoding via the built-in browser postMessage mechanism.
9. The third-party website receives a signed transaction envelope and may choose either to submit it to the network or store somewhere in case if the tx needs more signatures or if it has time bounds set.

Intent confirmation dialog always contains extended request information, including intent description (like "Sign transaction"), initiator website ("origin: example.com"), risk level ("high", "medium", or "low"), information about personal data disclosure (only for personal_info intent), and safety status ("safe" or "potentially unsafe"). Intent-specific details allow a user to review the request before confirmation. For instance, a dialog with sing_tx intent displays full transaction information including all meaningful properties and the list of operations in a human-friendly format adapted for the ordinary users.

There are 4 main groups of intents:

1. Request transaction signing. The calling app receives a signed transaction envelope in XDR format.
2. Request information. The app may request a user's personal info (email, avatar), Stellar account public key, or Stellar account secret key (required only in rare cases, maybe we should disable this intent at all).
3. Request specific action. Currently two actions available: "vote for inflation pool" and "establish trustline". The signer app prepares and submits the transaction to the network without returning transaction envelope XDR to the initiator website. It is done to simplify such standard actions; the initiator website does not need JS SDK or any other custom logic.
4. Request cryptographic signature of the arbitrary data. The website may request a crypto signature to verify a keypair ownership (authentication, secure messages exchange etc).

If SDF adopted this, we would probably a SEP that is specific enough to allow independent implementations.

Absolutely agree, I'll prepare detailed documentation.

It seems you are relying on informal domain separation for signed messages--basically only sign authentication messages that don't look like transactions. This is not robust to upgrades. Hence, as a first step to integrating with the Stellar ecosystem, you should request a dedicated value of EnvelopeType as a pull request on Stellar-ledger-entries.x

I'm afraid, here you lost me... StellarExpertID is built on top of the existing SDK and it utilizes only the existing standard data formats. It's just a key storage with a simplistic interface allowing other web apps to request predefined actions. I can't see a need for the underlying XDR formats modifications. Everything is already working, we just need a trusted hosting and controlled source codes modification via pool requests. It won't require any code changes for existing SDF-maintained projects.

MisterTicot It's my implementation, I designed it 7 months ago, when CosmicLink was not announced yet, and SEP-0007 was not defined. As I mentioned earlier, the application will support CosmicLink format. I spent last month fixing StellarExpert, so I had no time to properly clean up the code and implement the latest specs. If you are going to create your own implementation based on my open-source project and it will be better in terms of usability, I will gradually switch to your project, ditching my codebase.

I'm going to update GET params mapping to match your notation (for example, xdr instead of txXdr). I do like the format you proposed, the only thing which seems completely wrong to me is a callback logic. If the browser follows redirects, the initiator application will lose its current state. For example, you prepared a transaction on, say, super-cool-trading-bot.io, then you are redirecting the user to cosmic.link?xdr=...&url=super-cool-trading-bot.io. In this case, a developer of super-cool-trading-bot.io has to save current application state either in URL or in localStorage in order to restore it once the transaction is signed.

My implementation works transparently. You just invoke the intent which returns a standard promise. Once the promise is resolved, the application receives the result, and it does not lose the current state.

MisterTicot You are absolutely right,

sign(...keypairs) {
    let txHash = this.hash();
    let newSigs = each(keypairs, kp => {
      let sig = kp.signDecorated(txHash);
      this.signatures.push(sig);
    });
  }

In this situation keypair.sign(keypair.publicKey() + input_message) looks like a better alternative to double-hashing to me.

Once again, when it is about login/authentication (automatic signing) I would prevent any kind of text input as it may have legal value in the future.

Legal implications definitely should be considered. The signing itself is very simple and robust way to confirm the identity or secret key ownership, so I don't want to give up on it so easily.

Update 2018-08-31

• Publicly released stable development version. Check the repository here.
• Improved security: secret (request secret key) intent removed.
• New pay intent added.
• SEP-0007 support added.
• Fixed potential vulnerability with transaction hash signing via sign_msg intent.

I faced some problems implementing SEP-0007 standard. Maybe someone knows other SEP-0007 signer open-source implementations?

MisterTicot Sure, feel free to fork. The more developers adopt the same signing schema, the better. It will be a giant step toward more secure key management.

MisterTicot Yes, I see a few new bugs on Android. Thanks for the bug report!