ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Signature — Resource electronic signature

Signature is a data type (not a standalone resource) that encodes a resource cryptographic signature. Used in Provenance, Bundle, Contract.

Purpose

Signature carries the electronic signature of a resource or Bundle. Supported formats: JWS (JSON Web Signature, RFC 7515, FHIR profile), XMLDSig (XML Signature), XAdES (XML Advanced Electronic Signatures, eIDAS).

The data field carries the binary base64 signature. targetFormat specifies what was signed (JSON vs XML). sigFormat specifies the signature format.

Key fields

FieldTypeCardinalityRole
typeCoding[]1..*Signature type (ISO 1.2.840.10065.1.12.1.* table).
wheninstant1..1Signature timestamp.
whoReference(Practitioner | PractitionerRole | RelatedPerson | Patient | Device | Organization)1..1Signer.
onBehalfOfReference(...)0..1On-behalf-of party.
targetFormatcode (MIME)0..1Signed format.
sigFormatcode (MIME)0..1Signature format (application/jose, application/signature+xml).
database64Binary0..1Base64 signature payload.

JSON example

JWS signature of a clinical Bundle:

json signature-example.json 
{
  "type": [{
    "system": "urn:iso-astm:E1762-95:2013",
    "code": "1.2.840.10065.1.12.1.1",
    "display": "Author's Signature"
  }],
  "when": "2026-05-16T14:30:00Z",
  "who": { "reference": "Practitioner/dr-smith" },
  "targetFormat": "application/fhir+json",
  "sigFormat": "application/jose",
  "data": "eyJhbGciOiJSUzI1NiIsImtpZCI6ImRyLXNtaXRoLWNlcnQifQ.eyJpYXQiOjE3NDc0...SIGNATURE-PAYLOAD"
}

Common pitfalls

  • targetFormat missing: JSON vs XML ambiguity — signature can be invalid for the reconstructed format.
  • who without published certificate: cannot verify the signature on the receiving side.
  • Re-serialisation breaking: in FHIR JSON, key order can break the signature. Always use canonicalisation (JCS, RFC 8785).
  • Provenance — Carries Signatures to trace authenticity.
  • Bundle — Bundle.signature signs the whole bundle.
  • Contract — Contractual signature.
  • Verifiable Credentials — Compatible signature pattern (W3C VC + FHIR).