eCoC XML signing and XAdES: from candidate to verified artifact
An eCoC signing step connects an approved XML candidate with the party authorized to sign or seal it. XAdES is an XML signature format supported by the European Commission's Digital Signature Service. Choosing a format does not, by itself, establish the required trust level or acceptance by the destination. Agree the receiving profile and provider responsibilities before wiring an API.
What XML signature verification checks
W3C separates reference validation from signature validation. References identify the data covered by the signature; the declared transforms and digest are part of processing those references. Verification of the signature value is another step. Canonicalization belongs to this processing model, so changing XML serialization without understanding the signed references is a poor release procedure.
Freeze the candidate before signing
Give the reviewed XML candidate an immutable revision reference. Record who approved it and which organization is responsible for the sealing decision. Hand that exact candidate to the signing component. Retain the returned artifact separately and verify its signed content and expected vehicle identity before release. A successful API response alone is insufficient evidence of a valid signed file.
What an eCoC signing API contract should define
- Payload: whether the provider receives a full file or another agreed representation, plus how the response is bound to that file.
- Identity: legal entity, authorized caller and certificate/provider responsibility.
- Profile: agreed signature format, packaging, algorithms and any timestamp or validation-evidence requirements.
- Lifecycle: synchronous response or queued job, terminal outcomes and recovery after a timeout.
- Evidence: output reference, verification result, event time and a traceable operation identifier.
These are contract questions to resolve with the provider. They are not a published Digital CoC API specification. Credentials and private keys belong in the approved signing infrastructure, not in a browser form or an article's example request.
Test retries without losing the file relationship
In a synthetic scenario, operation S-001 times out after the provider receives candidate C-001. Before making a second request, reconcile the provider's recorded state using the agreed contract. A later source correction produces candidate C-002 and requires a new decision; it must not inherit C-001's signed status. Record these outcomes explicitly in the pilot acceptance sheet.
Separate signing from electronic sealing and delivery
Ask which identity the chosen certificate represents and which trust conditions the receiver requires. DSS can provide detailed signature validation reports, but its output must be interpreted under the agreed validation policy. Keep the verified artifact and subsequent submission acknowledgement as separate evidence. Digital CoC's manufacturer workflow is distinct from the trust-service provider and official receiving system.
What should a signing demonstration prove?
Use one approved candidate, one modified signed file and one interrupted operation. The demonstration should identify the artifact at every step, reject the integrity failure and resolve the interrupted operation without confusing the two candidate revisions.