I made an encrypted submission from ODK Collect, and upon inspection, I noticed the root namespace is http://www.opendatakit.org/xforms/encrypted. However, in the ODK XForms Specification for encrypted XForms, it is stated that all attributes and elements should be in the http://opendatakit.org/submissions namespace.
Submissions from Enketo use the http://opendatakit.org/submissions namespace.
The discrepancy is a little inconvenience to our custom decryption library, but nonetheless we are able to handle support for both XML formats.
What is the correct spec? And why do forms from Enketo and ODK Collect have different formats?
2. What steps can we take to reproduce this issue?
Make a submission from an encrypted form on ODK Collect. Upon submission to the aggregate server, inspect the submission manifest XML. You'll notice that the XML format is different from the one defined in the ODK XForms Specification for encrypted XForms
3. What have you tried to fix the issue?
We've handled parsing of the different formats during decryption.
4. Upload any forms or screenshots you can share publicly below.
Hello @kmuchiri, when working with encrypted submissions from ODK Collect, I noticed that the XML root element uses the namespace http://www.opendatakit.org/xforms/encrypted, while the ODK XForms Specification indicates that the correct namespace should be http://opendatakit.org/submissions. Interestingly, encrypted submissions from Enketo do follow the specification and use the expected submissions namespace. This inconsistency caused a small inconvenience for our custom decryption tool, although we’ve added support to handle both formats.
From what I understand, this difference exists because ODK Collect uses a legacy namespace that predates the current spec, whereas Enketo was built later and adheres more closely to the standardized format. Functionally, both formats are nearly identical and do not impact the encryption or decryption process itself, the main issue is just the namespace. If you're building or maintaining custom tooling, it’s important to account for both variants to ensure compatibility across different submission sources.
In general, Collect is the reference implementation and what we tend to consider "correct." That said, unfortunately, a lot of Collect's original behavior wasn't formally documented so it had to be backfilled. In particular, Martijn, Enketo's original creator, wrote a lot of the spec from looking at Collect code. Sometimes things like this were missed.
Namespacing is not supported very consistently across the ecosystem. In practice, it's often acceptable for compatible tools to ignore namespaces entirely because there aren't many documented form spec additions in alternate namespaces so conflicts are very unlikely. In this specific case, ODK implementations that work with submissions strip the namespace from the submission block, for better or worse.
