Summary

DRIVERS-2284 originally instructed for drivers to allow custom names for Queryable Encryption Metadata Collections via the eccCollection, ecocCollection, and escCollection fields within the encryptedFields option for the createCollection() helper.

SERVER-74069 has since added server-side validation for those fields and no longer allows names to deviate from the following:

• enxcol_.<collectionName>.esc
• enxcol_.<collectionName>.ecc
• enxcol_.<collectionName>.ecoc

These custom options within "encryptedFields" were never documented (see: create). The Queryable Encryption API is also documented as unstable so there should be no concern with changing this behavior.

Drivers should remove any modeling of these options for "encryptedFields". The createCollection() and dropCollection() helpers should ignore any user-supplied values within the encryptedFields option and use generated names with the proper format. Any values within encryptedFields can be left as-is and passed on to the server (if that leads to an error, so be it).

Additional Context

Quoting discussion from an internal Slack thread in #drivers-fle:

Looking at the create command docs, there's no mention of escCollection, eccCollection, or ecocCollection in the encryptedFields option docs. Were those fields always option and the server would just default to the generated names that are now enforced (as of DRIVERS-2565)?

Yes. Manually creating a collection with the following "encryptedFields" option will apply the default names for escCollection, eccCollection, ecocCollection:

db.runCommand({create: "foo", encryptedFields: {fields: []}})

Presumably there is no reason for a user to ever define these in encryptedFields. Does it make sense to still display these fields in the encryptedFields example within the spec (they were left in place in 8f6f4a3 for DRIVERS-2565)? If they do remain, should there be language talking about how the format is enforced? Perhaps a suggestion that if drivers haven't already modeled these options, they shouldn't even give users the choice to set them?

I am in favor of removing driver API and documentation of options for escCollection, eccCollection, and ecocCollection. I see no use case for a user to pass these options. Also, eccCollection is being removed with the new perf and on-disk format changes (DRIVERS-2524).

Motivation

Is this issue urgent?

No, but should be done while the Queryable Encryption API is still unstable.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No.