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.
- 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.
- The website prepares the requested transaction and it's XDR representation in base64 format.
- The website initiates the intent (see intent list in the project description) using js module that provides an interface for all supported intents.
- 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
- Signer application reads parameters from the URL and asks the user for a confirmation.
- The user chooses a keypair from the list of stored accounts (or adds a new one) and confirms the action.
- The signer app signs the transaction the same way any other wallet do it.
- The signed transaction is serialized into XDR as TransactionEnvelope and transmitted back to the opener site in base64 encoding via the built-in browser
- 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:
- Request transaction signing. The calling app receives a signed transaction envelope in XDR format.
- 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).
- 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.
- 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.