Currently master and data key ids are bson binary uuids. These keys are generally needed to configure the driver, and being composed of binary data creates challenges for interoperability between drivers as well as developer experience.

For example, it is common to use environment variables to store configuration data. It is easy to store a string in an environment variable; it is not clear how to store a binary blob in an environment variable and be able to operate on it from a shell script.

An application may work around binary blobs by performing its own encoding and decoding, but doing so makes the configuration data potentially unportable across applications and environments.

Consider for example the following data flow:

• User generates a master key using a Python application;
• User writes this key to 0bin for transfer to another user;
• User loads this key into a Node application to generate data keys;
• User adds this key into a third-party configuration management system that uses json files for configuration (not extended json)
• Configuration management system uses AWS to provision a server with the master key added to the environment
• On the server a Mongoid application reads the key from the environment and passes it to the Ruby driver

If the key is a string, the above operations is straightforward. If the key is a binary blob, each step must be carefully evaluated for proper escaping (and could be unfeasible altogether).

The same issue applies to data key ids, since when they are used for explicit encryption they become part of driver configuration.

I asked kevin.albertson about why the key ids were not strings and from what I understand there is no specific reason why they can't be strings in principle.