This page explains how to authenticate with the Solaris Digital Assets (SDA) API.
Solaris Digital Assets requires partners to generate a pair of private & public keys. You must register the public key with the platform and sign every request to the API using your private key.
Each HTTP request to the SDA API must include the following headers in addition to standard ones:
These headers are described in detail below.
Digest header ensures the integrity of the HTTP request body. You must
construct it using the SHA-256 algorithm in accordance with the guidelines of
the Instance Digests in HTTP RFC.
Even for GET requests, assuming the request body is an empty string, you must
still construct the
Example digest header:
X-Nonce header uniquely identifies the HTTP request and serves to protect
against replay/playback attacks. The
X-Nonce header value must be a string of
up to 32 characters, which must be unique to each request generated using a
single API key.
As an example, the
X-Nonce header value may be generated as a 16-byte random
integer in hexadecimal representation.
Example X-Nonce header:
Signature header provides authentication and integrity assurances without
the need for shared secrets. It also does not require an additional round-trip
in order to authenticate the client and allows the integrity of a message to be
verified independently of the transport.
You must include the following parameters in the
A unique ID that is assigned to your API key.
The value must be
The value must be a UTC timestamp from the time at which the HTTP request was constructed.
Identifies how the canonical Signature String is constructed. Its value consists of a list of actual and pseudo-HTTP headers that will form the Signature String (according to the HTTP Signatures draft v11).
headers parameter must include the following headers:
Solaris recommends using the following value for this parameter:
(request-target) (created) digest x-nonce
Example Signature String:
(request-target): get /foo?bar=123\n
In the above example,
\n indicates the ASCII newline character. Note that it
is not included on the last line.
The digital signature of the HTTP request produced by your private key.
In order to create the
- Construct the canonical Signature String according to the value of the
- Using the private key that corresponds to the provided
keyId, generate an Ed25519 signature of the Signature String constructed in the previous step.
- Base64-encode the Ed25519 signature generated in the previous step.