-
Type: Task
-
Resolution: Duplicate
-
Priority: Unknown
-
None
-
Component/s: Client Side Encryption
-
None
-
Needed
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.
- is related to
-
DRIVERS-2565 Update fle2-* tests to match name requirements in SERVER-74069
- Closed
-
SERVER-74069 Validate QE state collections match naming rules in validateEncryptedFieldConfig
- Closed
-
DRIVERS-2524 Drivers should not create the ECC collection in v2 of queryable encryption
- Closed
- split to
-
CDRIVER-4606 Create and drop collection helpers should ignore custom names for Queryable Encryption metadata collections
- Blocked
-
CSHARP-4602 Create and drop collection helpers should ignore custom names for Queryable Encryption metadata collections
- Blocked
-
CXX-2667 Create and drop collection helpers should ignore custom names for Queryable Encryption metadata collections
- Blocked
-
GODRIVER-2799 Create and drop collection helpers should ignore custom names for Queryable Encryption metadata collections
- Blocked
-
JAVA-4924 Create and drop collection helpers should ignore custom names for Queryable Encryption metadata collections
- Blocked
-
MOTOR-1111 Create and drop collection helpers should ignore custom names for Queryable Encryption metadata collections
- Blocked
-
NODE-5175 Create and drop collection helpers should ignore custom names for Queryable Encryption metadata collections
- Blocked
-
PYTHON-3655 Create and drop collection helpers should ignore custom names for Queryable Encryption metadata collections
- Blocked
-
RUBY-3234 Create and drop collection helpers should ignore custom names for Queryable Encryption metadata collections
- Blocked
-
RUST-1624 Create and drop collection helpers should ignore custom names for Queryable Encryption metadata collections
- Blocked
-
PHPLIB-1102 Create and drop collection helpers should ignore custom names for Queryable Encryption metadata collections
- Closed