Client (Identity)

Gateway Protocol’s architecture revolves around the Decentralized Identity (DID) standard, which defines all entities participating in the protocol and governs their interactions.

A DID in Gateway Protocol consists of three key elements:

1. Signing Key - An ECDSA secp256k1 or Ed25519 key pair, which includes a public and private key.

   • The private key must be kept secret as it grants permissions and consent to user data.

2. Encryption Key - An RSA-4096/OAEP (with BLAKE2b-384 digest) key pair, represented as $(PK_i, SK_i)$.

   • The user’s public key is shared publicly on-chain in the DID document, allowing third parties to encrypt data that can only be viewed by the user.
   • The private key must never be shared publicly, as it enables decryption of user-controlled data.

3. ID - The ID follows the W3C Decentralized Identity (DID) standard.

   • It is created by hashing (BLAKE2b-384) the public signing key of the user and a $salt$ value that can be changed for each user interaction with a given party.
   • The DID is constructed as follows: $DID_i = \text{"did:gatewayid:"} || BLAKE2b_{384}(VerifyK_i,salt)$

Key Management and Security

To ensure the highest level of security, the generation of DIDs and handling of public crypto artifacts should happen off-chain and be recorded on-chain. Generating private key pairs off-band prevents storage and transmission leaks of user private keys. Once generated, only the relevant public derivatives (e.g., public signing and encryption keys) are reported to the network.

The private signing key is used to authorize all on-chain activity, while the encryption keys are used for secure data transmission and storage. All on-chain actions require a signature with the secret private signing key, and sensitive data may be encrypted for the predetermined user using their public encryption key.

Identity management tasks, such as key generation, revocation, and rotation, can be managed by the client responsible for creating the keys, such as native mobile clients with access to secure enclave compute.

All private key pairs must be generated off-band. Only appropriate public derivatives will be reported to the network operating as a decentralized Certificate Authority.