XML Signature and Canonicalization Prompt Template

This prompt is designed for the specific job of generating an XML Digital Signature (XMLDSig) element that a downstream system can verify cryptographically. The ideal user is a security engineer or integration developer who already possesses an unsigned XML payload and the necessary signing key material. The prompt's value is in navigating the strict rules of canonicalization (C14N), digest value computation, and KeyInfo construction, which are common points of failure in manual or ad-hoc signature generation. It is not a general-purpose XML generation tool; it assumes the input XML structure is already correct and the task is strictly to wrap or insert a valid signature.

Use this prompt when your workflow requires producing a signed XML document for standards-compliant exchange, such as in SAML assertions, SOAP web services, or enterprise document signing. The template is built to handle both Inclusive and Exclusive C14N transforms, which are critical for signatures that must survive common XML processing like namespace declaration changes or whitespace reformatting. You should have the unsigned XML, the private key (or a reference to it), and the certificate or public key information ready as inputs. The prompt's constraints are designed to prevent the model from hallucinating cryptographic values, instead guiding it to structure the SignedInfo and placeholder digest values correctly for your application code to finalize.

Do not use this prompt if you need to sign non-XML payloads, generate the private key material itself, or perform the actual cryptographic hashing and encryption within the model. The model's role is to generate the correct XML structure and canonicalization instructions, not to act as a cryptographic library. For high-risk deployments, always pair this prompt's output with a post-generation validation harness that independently verifies the digest and signature values using a trusted XML security library before transmitting the signed document. The next step after adapting this template is to wire it into an application harness that injects real key material and performs the cryptographic operations the prompt has structurally prepared for.

This prompt template generates a valid XML Digital Signature (<ds:Signature>) for a provided XML payload. It handles the full signing workflow: selecting the canonicalization method (Inclusive or Exclusive C14N), computing the digest of referenced resources, and constructing the SignedInfo, SignatureValue, and KeyInfo blocks. The prompt is designed for security engineers who need to integrate AI-assisted signature generation into document processing pipelines where the private key is managed externally by a hardware security module (HSM) or a secure application—the model orchestrates the XML structure and digest instructions, but the actual cryptographic signing operation must be performed in your application code.

textCopy
You are an XML Security specialist. Your task is to generate a valid XML Digital Signature element for the provided XML document.

## INPUT
- XML Document to sign:
```xml
[INPUT_XML]

• Reference URI to sign (e.g., "", "#elementId"): [REFERENCE_URI]
• Canonicalization Method: [CANON_METHOD] (Allowed: "http://www.w3.org/TR/2001/REC-xml-c14n-20010315", "http://www.w3.org/2001/10/xml-exc-c14n#")
• Signature Method: [SIGNATURE_METHOD] (Allowed: "http://www.w3.org/2000/09/xmldsig#rsa-sha256", "http://www.w3.org/2001/04/xmldsig-more#rsa-sha512")
• Digest Method: [DIGEST_METHOD] (Allowed: "http://www.w3.org/2001/04/xmlenc#sha256", "http://www.w3.org/2001/04/xmlenc#sha512")
• Key Info (optional): [KEY_INFO_XML] (Provide an X509Data, KeyName, or KeyValue XML fragment, or leave empty for a placeholder.)
• InclusiveNamespaces PrefixList (only for Exclusive C14N): [INCLUSIVE_PREFIXES] (Comma-separated list of namespace prefixes to include, e.g., "soapenv,wsse")

CONSTRAINTS

1. Output ONLY the complete <ds:Signature> element. Do not wrap it in a modified version of the input document.
2. Use the ds prefix bound to http://www.w3.org/2000/09/xmldsig#.
3. The <ds:DigestValue> and <ds:SignatureValue> elements must contain the placeholder text [PLACEHOLDER_DIGEST] and [PLACEHOLDER_SIGNATURE] respectively. Do not generate fake hash or signature values.
4. If the Canonicalization Method is Exclusive C14N, you MUST include a <ec:InclusiveNamespaces> element inside the <ds:CanonicalizationMethod> element, using the prefix list provided in [INCLUSIVE_PREFIXES]. Bind the ec prefix to http://www.w3.org/2001/10/xml-exc-c14n#.
5. The <ds:Reference> URI must exactly match [REFERENCE_URI].
6. Include exactly one <ds:Transform> element for the canonicalization method inside each <ds:Reference>, in addition to any enveloped signature transform if [REFERENCE_URI] is "".
7. If [REFERENCE_URI] is "", add an Enveloped Signature transform (<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>) as the first transform.
8. The output must be well-formed XML and valid against the xmldsig-core-schema.xsd.

OUTPUT FORMAT

Return only the raw XML Signature element, starting with <ds:Signature> and ending with </ds:Signature>.

Adaptation Notes: Before using this prompt, replace the square-bracket placeholders with your actual values. The critical design choice is the canonicalization method: use Inclusive C14N when you need to preserve the full XML context including all namespace declarations, and Exclusive C14N when the signed fragment will be extracted and embedded in different XML contexts. The [INCLUSIVE_PREFIXES] parameter is mandatory for Exclusive C14N—omitting it will cause signature verification failures when namespaces from ancestor elements are required. After the model returns the <ds:Signature> element, your application must: (1) parse the SignedInfo block, (2) apply the specified canonicalization and transforms to compute the correct digest values, (3) replace [PLACEHOLDER_DIGEST] with the actual base64-encoded digest, (4) canonicalize the SignedInfo element, (5) sign it with the private key, and (6) replace [PLACEHOLDER_SIGNATURE] with the base64-encoded signature value. Never send a private key to the model.

Integrating an XML Signature generation prompt into a production system requires treating the model output as a draft cryptographic component, not a finished signature. The prompt is designed to produce the structural XML for a <ds:Signature> element, including the SignedInfo, CanonicalizationMethod, SignatureMethod, Reference digests, and KeyInfo blocks. However, the actual cryptographic operations—digest computation and private key signing—must be performed by a trusted application library, never by the model. The harness should parse the model's XML output, extract the SignedInfo block, canonicalize it using the specified algorithm (e.g., Exclusive XML Canonicalization 1.0), compute the SignatureValue with a hardware-secured key, and inject the result back into the XML structure. This separation ensures that private key material never appears in a prompt or model response, maintaining a critical security boundary.

The implementation flow should follow a strict validate-compute-verify loop. First, validate the model-generated XML against the xmldsig-core-schema.xsd to catch structural errors before any cryptographic work begins. Next, extract each <ds:Reference> URI and compute the referenced element's digest using the stated digest method (e.g., SHA-256). Compare this computed digest against the model-provided <ds:DigestValue>; a mismatch here indicates either a hallucinated digest or a canonicalization error in the prompt output. If the digests match, proceed to canonicalize the <ds:SignedInfo> element and compute the final signature value using the application's private key. Finally, verify the complete signature with the corresponding public key before returning it to the calling system. Log every step—model output, validation errors, digest comparisons, and signing success/failure—for auditability. For high-assurance environments, route any digest mismatch or schema validation failure to a human reviewer rather than silently retrying.

When choosing a model for this workflow, prefer one with strong XML structural generation and strict adherence to namespace declarations. The prompt template includes placeholders for [CANONICALIZATION_METHOD], [SIGNATURE_METHOD], [DIGEST_METHOD], and [REFERENCE_URIS], which should be populated from your application's cryptographic policy configuration. Do not allow the model to select these algorithms autonomously; they must be injected as constraints. For retry logic, implement a maximum of two retries on schema validation failure, feeding the XSD validation error message back into the prompt's [PREVIOUS_ERROR] placeholder. If digest mismatches persist, escalate immediately—this indicates the model is fabricating digest values rather than computing them, and no amount of retrying will produce a valid signature. The next step is to integrate this harness with your key management system and add the verification step as a release gate before any signed document reaches a downstream system.