Status Remote (Identity, Authorization)

Status Mobile
1

Summary and Goal(s)

Ability of users to authorize use of Status Identity in remote (d)apps:

  1. Sync with Status (profile, settings, message history)
  2. Execute (send) Messages in Status Network
  3. 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.

Research

Use cases

  • 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

Technical architecture

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”.

Authorization types

  1. Single authorization - a one time only request would be displayed when user scans a “connect request”;
    1. Message: The message that will be sent + channel, would appear and allow user to confirm.
    2. Transactions and Signatures: The request data would be displayed and require user password.
    3. Sync: Would be able to query one time a specific data set from Status (profile, settings, specific group/contact history up to some date)
  2. 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”
    1. Message: Every request would appear automatically, buy would need to be approved by user.
    2. Transactions and Signatures: Every request would appear automatically but need password to execute.
    3. Sync: Every request of new data needs to be authorized
  3. Automatic authorization - allow the automatic execution of requests (no re authorization required, still requires connected Status Client)
    1. Message: Messages are automatically sent on user request, after one time authorization.
    2. Transactions and Signatures: Should not be possible, because requires the user password to unlock key.
    3. Sync: Dapp can sync anything on demand from connected Status Client.
  4. Public authorization - allow the use of “account contract” as Identity to specify multiple keys with specific purposes.
    1. Message: Status derives a key for the requesting dapp, and is defined “encryption” purpose key in Identity.
    2. Transactions and Signatures: Status derives a key for the requesting dapp, and is defined as “action” purpose key in Identity.
    3. 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

Full integration

  1. 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
  2. User unlock Status and add new authorized app by scanning the qr-code.
  3. Dapp can now be used as if in Status Browser, depending on authorization.
  4. Transactions need to be signed in Status Client (mobile)

1920×1080 206 KB

Partial integration

  1. Dapp wants only to read message history and send new messages (ex.: status desktop), request automatic message sending.
  2. User authorizes dapp by scanning qr code.
  3. 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.
  4. Desktop can cache the old messages in local db so it don’t needs to read again from remote.

Copyright

Copyright and related rights waived via CC0.

1 Like
2

Sounds pretty convenient! A lot to unpack so please bear with me while a work through my misunderstandings.

Do you see a ‘DApp connect request’ also work for a unique connect request by users, rather than sharing a generic contact code?

We discussed something along these lines in the scope of Tribute to Talk. Trying to understand and verify if the mechanism you describe above can apply or if future contacts are better of with a ‘appended’ key instead of a disposable key because of the durability of the exchange. Would this fall under the ‘Automatic request’ authorization?

A recurring concern I have in connecting more utility to a Whisper ID, or Wallet address for that matter, is the increased reliance on a ‘identity’ with associated exposure and recoverability risks. Not sure how relevant that is in this case, but it feels like ‘Automatic requests/authorization’ beyond chat with future contacts would need work on things like:

  • porting to a new key; breaking ties
  • managing automatic requests/authorization
  • saving request/authorization settings premeditatively so they can be reinitiated after access to a private key is lost.
3

Looks related to https://walletconnect.org/ ?

1 Like
4

No, this is only for the owner of wallet connecting to a Dapp in an external device/dapp.
It bridges the signing user user keys through network, so user can use their Status wallet/identity without entering their key in other device.

Disposable keys are used for one time requests and maybe some other use cases, usually this protocol would request a new derived key to use in the dapp, which if you have any token in that key and lost it, you can always recreate it.

This proposal don’t changes user address, the use of a “Contract Acount Identity” in the flow, is to explain how it will be for users using this advanced capabilities accounts, which can be the default for onboarding uses by the use of CREATE2 opcode.
The porting should be related to the swarm which includes this feature, and is indeed an important concern, however we can allow user to hold multiple Identity and the migration could happen on user demand - not great but might be the best we can get.
Imagine users with thousands of NFTs = thousands of transactions, however ERC721 contains a “allowAll(otherAddress)” for one address be able to control all NFTs of caller, which could be used by this users meanwhile. Identity.sol now is extendable, which mean an extension could be built to facilitate porting, in a limited way.

The loss of a disposable private key should not be a problem, because this key is never used in public network, only by user itself between its devices.

In case of public authorizations, it should be not a problem as this keys would be “action keys” and status wallet a “manager key”, which could replace the old key to a new one. - But this keys should always remain literally private, as they would be to call in chain actions.
2FA would be the use of “multiple manager keys” and requiring multiple keys (as multisig) for changing the allowed keys.

Yes, we could integrate this or fork it for our needs, as we also need the “chat feature” + “data sync” to be available through this remote connection. And also we might want to support the Identity Contract features.

Technically it shouldn’t be challenging, as is like a remote connection controlling the Status application.

1 Like