Summary and Goal(s)
Ability of users to authorize use of Status Identity in remote (d)apps:
- Sync with Status (profile, settings, message history)
- Execute (send) Messages in Status Network
- Execute (send) Ethereum Transactions (and sign ethereum contracts)
Users should be able to connect in Status Desktop, or any Dapp that integrates this api, to use Status Network and Ethereum with identity securely stored in Status Client, instead of needing to give their seed phrase.
Currently Status Desktop requires user to enter seed phrase to sync with mobile, this would make this not required anymore, unless user want to use Status Desktop as their authorization client.
- One time payments in stores could integrate Status to scan for buy of product/services or contract calls.
- Teller network would use Status Network to provide an embedded chat where users can talk about their trade, however users with Status would be able to sync and use their Status Client Identity instead of being forced to use mobile.
- Chat & Wallet Integration for 3rd Party Apps
Dapp creates a disposable keypair and presents publickey in a code together with authorization request to be scanned.
Dapp listens for a private message in Status Network for that key.
User authorize remote application request by entering the public key,
Status executes request and answers in private message to dapp public key.
Whisper should use local network if possible to exchange this messages, specially “Sync” answers. The handshake might happen in whisper, but it could try to connect through LAN and keep whisper only if not in same network.
All those interactions require Status Client connected, because the keys are not sent to browser/whatever, rather the Status Client signs them for the authorized dapps, automatically depending on authorization.
Account Contract Identity
The use of Identity Contracts can provide a “offline authorization” or 2FA, which would allow access to user funds and identity messaging without Status Client connected.
The difference is the use of an “account contract”, the authorization is “publicly” defined in blockchain, under Identity contract terms, therefore Identity support is required for type, and are not specifically the “remote control”.
- Single authorization - a one time only request would be displayed when user scans a “connect request”;
- Message: The message that will be sent + channel, would appear and allow user to confirm.
- Transactions and Signatures: The request data would be displayed and require user password.
- Sync: Would be able to query one time a specific data set from Status (profile, settings, specific group/contact history up to some date)
- Automatic request - allow the automatic requests to be displayed, after user scans “connect request” the dapp can make new requests without a new “contact code”
- Message: Every request would appear automatically, buy would need to be approved by user.
- Transactions and Signatures: Every request would appear automatically but need password to execute.
- Sync: Every request of new data needs to be authorized
- Automatic authorization - allow the automatic execution of requests (no re authorization required, still requires connected Status Client)
- Message: Messages are automatically sent on user request, after one time authorization.
- Transactions and Signatures: Should not be possible, because requires the user password to unlock key.
- Sync: Dapp can sync anything on demand from connected Status Client.
- Public authorization - allow the use of “account contract” as Identity to specify multiple keys with specific purposes.
- Message: Status derives a key for the requesting dapp, and is defined “encryption” purpose key in Identity.
- Transactions and Signatures: Status derives a key for the requesting dapp, and is defined as “action” purpose key in Identity.
- Sync: Not possible, still requires Status Client connected as data is stored within user device only. Use option 3.
When [2. Automatic Request] or [3. Automatic authorization], a TTL might be interesting (allowing 0 = never expires).
[4. Public authorization] might not be part of MVP, but is included in specification because its an alternative to remote control, where the authorization is committed to consensus, making the newly added key independent, but the initial authorization would use the same system.
Implement as extension
Could be one extension for all dapps, or one extension per dapp.
Extensions features needed:
- “1-1 back-end communication by whisper” (receive a message which is not displayed to user, but only processed by extension)
- send a message (chat.command/send-message ?)
- send transaction (ethereum/send-transaction ?)
Dapp integration UX
- A list of authorized apps appear and can have their settings changed
- Authorization requests appear like chat timeline - per dapp authorized
- Each dapp authorized is a extension with their own authorizations
- Dapp requests User to connect with status presented with a qr-code, requesting authorization of automatic authorization of messages, sync, and automatic request of transactions/signatures
- User unlock Status and add new authorized app by scanning the qr-code.
- Dapp can now be used as if in Status Browser, depending on authorization.
- Transactions need to be signed in Status Client (mobile)
- Dapp wants only to read message history and send new messages (ex.: status desktop), request automatic message sending.
- User authorizes dapp by scanning qr code.
- Dapp can now send messages and read messages sent to user, but the message sending/receiving happens only in Status Client (mobile), not in desktop.
- Desktop can cache the old messages in local db so it don’t needs to read again from remote.
Copyright and related rights waived via CC0.