Identity API

The BitClout Identity service provides a convenient and secure way for users to login to many different BitClout nodes and applications. When using BitClout Identity, users' private key material never leaves the browser. All signing happens in a secured iframe and transaction approvals occur in a pop-up window.
The developer community highly recommends node operators and app developers integrate with identity.bitclout.com to provide users with consistent log in, sign up, and account management experiences. Identity currently integrates most smoothly with web-based applications. The developer community is working on creating libraries for integrating with iOS and Android.
Message Protocol
Applications interact with Identity in two ways: embedding Identity in an iframe and opening Identity in a new window via window.open. The iframe context can handle transaction signing and message decryption. The window.open context can handle log in, sign up, log out, and account management. Both iframe and window.open contexts communicate with the parent via window.postMessage .
A few notes about message formats:
Messages with an id and method are requests that expect a response.
Messages with an id and no method are responses to requests.
Messages without an id do not expect a response.
UUID v4 is the recommended id format.
initialize
The first message Identity sends to the parent when it loads in is initialize. This message is sent in both iframe and window.open contexts. A response is required so Identity knows the hostname of the parent window.
Request
1
{
2
  id: '21e02080-0ef4-4056-a319-a66403f33768',
3
  service: 'identity',
4
  method: 'initialize',
5
}
Copied!
Response
1
{
2
  id: '21e02080-0ef4-4056-a319-a66403f33768',
3
  service: 'identity',
4
}
Copied!
window.open context
Opening Identity using window.open allows an application to send and receive messages to the newly opened tab or pop-up. A new Identity window can be opened at many paths:
1
const login   = window.open('https://identity.bitclout.com/log-in');
2
const signUp  = window.open('https://identity.bitclout.com/sign-up');
3
const logout  = window.open('https://identity.bitclout.com/logout?publicKey=BC123');
4
const approve = window.open('https://identity.bitclout.com/approve?tx=0abf35a');
5
​
6
// Can be added to any path for testnet bitclout and bitcoin addresses
7
const testnet = window.open('https://identity.bitclout.com/log-in?testnet=true');
Copied!
Only one Identity window should be opened at a time.
Access Levels
Users can control access level on a per-domain and per-account basis. The available access levels are:
1
enum AccessLevel {
2
  // User revoked permissions
3
  None = 0,
4
​
5
  // Approval required for all transactions
6
  ApproveAll = 2,
7
​
8
  // Approval required for buys, sends, and sells
9
  ApproveLarge = 3,
10
​
11
  // Node can sign all transactions without approval
12
  Full = 4,
13
}
Copied!
An application can specify which access level it would like to request by including accessLevelRequest as a query parameter when opening the Identity window. If no accessLevelRequest is specified then ApproveAll is used as the default.
login
When a user finishes any action in an Identity window a login message is sent. The login message does not expect a response and means the Identity window can be closed by calling window.close on the stored reference to the window.open.
For a log in or sign up action the selected publicKey will be included in publicKeyAdded. When a user approves a transaction the signed transaction will be included in signedTransactionHex.
An application should store the current publicKey and users objects in its local storage. When an application wants to sign or decrypt something the accessLevel, accessLevelHmac, and encryptedSeedHex values will be required.
Request
1
{
2
  users: {
3
    BC1YLfsWMfv8UdytwrWqWvqSP6M6eQJg7W5TWL1WNDYd7zxi6wEShQX: {
4
      accessLevel: 4,
5
      accessLevelHmac: "0d22e283751c904ab36dc3910afe1a981...",
6
      btcDepositAddress: "1PXhm3D6sgZtfGNe2mtP27NVBHEcNJX2AW",
7
      encryptedSeedHex: "bdad93a19eb3be8b4c2f63b5cefb82823...",
8
      hasExtraText: false,
9
      network: "mainnet",
10
    },
11
  },
12
  publicKeyAdded: '',
13
  signedUp: false,
14
  signedTransactionHex: '',
15
}
Copied!
iframe context
The iframe is responsible for signing and decryption. The iframe is usually entirely invisible to the user. However, the iframe does need to render when the user needs to grant storage access on Safari.
1
<iframe
2
  id="identity"
3
  frameborder="0"
4
  src="https://identity.bitclout.com/embed"
5
  style="height: 100vh; width: 100vw;"
6
  [style.display]="requestingStorageAccess ? 'block' : 'none'"
7
></iframe>
Copied!
info
The iframe responds to info messages which helps Identity support Safari and Chrome on iOS. Apple's Intelligent Tracking Prevention (ITP) places strict limitations on cross-domain data storage and access. This means the Identity iframe must request storage access every time the page reloads. When a user visits a BitClout application in Safari they will see a "Tap anywhere to unlock your wallet" prompt which is a giant button in the iframe. When the info message returns hasStorageAccess: false, an application should make the iframe take over the entire page. Above, this means setting requestingStorageAccess = true.
The info message also detects if a user has disabled third party cookies. Third party cookies are required for Identity to securely sign transactions. If info returns browserSupported: false an application should inform the user they will not be able to use Identity to sign or decrypt anything.
Request
1
{
2
  id: '21e02080-0ef4-4056-a319-a66403f33768',
3
  service: 'identity',
4
  method: 'info',
5
}
Copied!
Response
1
{
2
  id: '21e02080-0ef4-4056-a319-a66403f33768',
3
  service: 'identity',
4
  payload: {
5
    hasStorageAccess: true,
6
    browserSupported: true,
7
  },
8
}
Copied!
storageGranted
The iframe sends a storageGranted message when a user clicks "Tap anywhere to unlock your wallet." It does not expect a response. When an application receives this message it can hide the iframe from view and the iframe is now ready to receive sign and decrypt messages.
Request
1
{
2
  service: 'identity',
3
  method: 'storageGranted',
4
}
Copied!
sign
The sign message is responsible for signing transaction hexes. If approval is required an application must call window.open to acquire a signedTransactionHex.
Request
1
{
2
  id: '21e02080-0ef4-4056-a319-a66403f33768',
3
  service: 'identity',
4
  method: 'sign',
5
  payload: {
6
    accessLevel: 3,
7
    accessLevelHmac: "0fab13f4...",
8
    encryptedSeedHex: "0fab13f4...",
9
    transactionHex: "0fab13f4...",
10
  },
11
}
Copied!
Response (Success)
1
{
2
  id: '21e02080-0ef4-4056-a319-a66403f33768',
3
  service: 'identity',
4
  payload: {
5
    signedTransactionHex: "0fab13f4...",
6
  },
7
}
Copied!
Response (Approval Required)
1
{
2
  id: '21e02080-0ef4-4056-a319-a66403f33768',
3
  service: 'identity',
4
  payload: {
5
    approvalRequired: true,
6
  },
7
}
Copied!
decrypt
The decrypt message is responsible for decrypting messages.
Request
1
{
2
  id: '21e02080-0ef4-4056-a319-a66403f33768',
3
  service: 'identity',
4
  method: 'decrypt',
5
  payload: {
6
    accessLevel: 3,
7
    accessLevelHmac: "0fab13f4...",
8
    encryptedSeedHex: "0fab13f4...",
9
    encryptedHexes: [
10
      "0fab13f4...",
11
      "0fab13f4...",
12
    ]
13
  },
14
}
Copied!
Response
1
{
2
  id: '21e02080-0ef4-4056-a319-a66403f33768',
3
  service: 'identity',
4
  payload: {
5
    decryptedHexes: {
6
      "0fab13f4...": "hello world"
7
      "0fab13f4...": "in retrospect it was inevitable",
8
    }
9
  },
10
}
Copied!
jwt
The jwt message creates signed JWT tokens that can be used to verify a user's ownership of a specific public key.
Request
1
{
2
  id: '21e02080-0ef4-4056-a319-a66403f33768',
3
  service: 'identity',
4
  method: 'jwt',
5
  payload: {
6
    accessLevel: 3,
7
    accessLevelHmac: "0fab13f4...",
8
    encryptedSeedHex: "0fab13f4...",
9
  },
10
}
Copied!
Response
1
{
2
  id: '21e02080-0ef4-4056-a319-a66403f33768',
3
  service: 'identity',
4
  payload: {
5
    jwt: "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE2MTk2NDk4MDcsImV4cCI6MTYxOTY0OTg2N30.FKZF8DSwwlnUaW_eRa7Wr1v2QcG7_iDN-NjdqXUcgrSAPg1EdSfpWsLL4GeUiD9zdLUgrNoKU7EsKkE-ZKMaVQ",
6
  },
7
}
Copied!
Validation in Go
1
func ValidateJWT(publicKey string, jwtToken string) (bool, error) {
2
    pubKeyBytes, _, err := Base58CheckDecode(publicKey)
3
    if err != nil {
4
        return false, err
5
    }
6
​
7
    pubKey, err := btcec.ParsePubKey(pubKeyBytes, btcec.S256())
8
    if err != nil {
9
        return false, err
10
    }
11
​
12
    token, err := jwt.Parse(jwtToken, func(token *jwt.Token) (interface{}, error) {
13
        return pubKey.ToECDSA(), nil
14
    })
15
​
16
    return token.Valid, err
17
}
Copied!
Mobile / Webview support
Identity current offers support for mobile projects as well, but there are some differences needed in order to fully integrate.
Major differences:
1.There is no need to run an iframe context. You will send all messages to one context running in a webview.
2.Your webview context will need have an additional parameter ?webview=true
3.Depending on your mobile development framework, you need to make sure messages to and from the webview are being registered appropriately. Currently iOS, Android, and React Native webviews are supported.