FHIR Digital Signature Working Page
This page documents a series of proposals arising out of the digital signature implementation project
This topic is formally around coming to a resolution for Change Proposal tracker 3746
Many of the problems identified are exactly the kind of 'problem' that a Digital Signature is intended to protect against. That is, the purpose of a Digital Signature is to verify that the content has not changed. Determining which kinds of changes are allowed is 'policy', meaning a decision that element XYZ is allowed to change and not break the signature is declaring a policy that XYZ element is not important. However to enable broad interoperability some decisions need to be made.
- Advice is needed for how to create a Provenance.signature and how to validate one so that the signature survives various movements. Or do we just indicate that signatures are not intended to survive movements?
- How are signatures to be handled by a receiving system that imports the resource for use? That is it incorporates the resource content, and likely fixes up the References to local copies of the resource?
- Should a counter-signature be used? That is the importing system will validate the incoming signature, and then counter sign the fixed-up resource, which should be a new version with a new Provenance.
- How to handle when References are included in the resource being signed?
- Do they get turned into relative URLs?
- If a system imports the resource and 'fixes up' the References to point at local copies of the referenced resource, then the signatures will fail to validate
- Do they get turned into just the unique part, without the URL root?
- Do they get turned into _id?
- Do they get nulled?
- How are versioned Referenced resources identified?
- Do you serialize the Referenced resource along with the resource? If so how deep?
- Do they get turned into relative URLs?
- How to handle metadata?
- Which metadata is included in the signature? Which is not?
- How are signatures to be handled when the resource server gets re-located, changing the URL root?
The discussions to date in Security, CBCC, FM etc. can be boiled down to the need for 2 types of signatures:
integrity Signatures: Purpose to determine if content altered through a defined period (e.g. in transit). This signature is allowed to break if the resource is moved, or updated. Operation sign over all content in the resource. Should be able to apply to a bundle.
documentation Signature: Purpose to determine if content altered over time regardless of movement, should not break if moved. Operation: sign over immutable portions of current resource, and follow references in the order encountered and include either: if the referred to resource has a documentation signature include the documentation signature string if any (more efficient than harvesting the Signed-hash from the string) and do not follow references for this resource; if the referred to resource does not then include the immutable elements from the referred to resource and follow the references for this resource applying this same logic as you go. This means there needs to be a specific signature transform canonicalization that isolates the portions needing signature while allowing others to change.
Document Signature: This is not 'needed' as it is already available and not a FHIR specific capability, let me explain. This is a signature across a whole Document that is managed as a whole document. This may be a FHIR document or other. Given that this document is managed as a whole document, then Document centric signatures already can be applied. See IHE-Document Digital Signature (DSG) profile for a profile of XAdES-X-L. The resulting signature is either Encapsulating the signed document, or is another document that must be managed in relationship (See DocumentReference).
Provenance Signature - clarification
The current text was carefully crafted, but clearly we need to clean up the signature definition in Provenance. This signature was only intended to bind the specific versioned content to the provenance that describes the 'provenance' of that versioned content. Therefore it should be a more simple flavor of a digital signature. However it does still suffer from many of the issues.
Proposal 1 : A page for digital signature implementation notes
We should add a digital signature page that:
- describes the use cases that we support
- details general implementation considerations & where to look for support
- describes a profile on xml digital signatures
- describes some FHIR specific transforms that when used with FHIR resources confer robustness against format changes, and meet the use cases
- deals with xml vs json
We should add a note to both the xml and json pages describing signature ready xml and json. Implementers are recommended to conform to this
XML ready for Digital Signature
- default namespaces - only use default namespaces for fhir and xhtml namespaces
- outside the xhtml, no whitespace except in attributes
- no processing instructions, no xml comment
JSON ready for digital Signature
- all unimportant whitespace removed from the JSON representation
XML/JSON that conforms to this profile can be reproduced exactly from the data in the resource, without needing to store the actual XML (or can be recreated correctly from the JSON)
That we define a standard transform
Signature Verifying Service
To address the problems that arise when the actor using a FHIR resource may be low-tech, or be bound to only one transform (XML, JSON, etc).
A signature creation must happen at a place where the private key of the signer is present. Thus the signature operation can't be easily encapsulated into a service.
- Note there are Timestamp Digital Signature services, that will apply a signature. This signature is by the service, and with the purpose only of binding an authoritative timestamp with the content. Although this is a type of signature it is not seen as the primary use-case.
A signature verifying service could be created. It would contain all the complexity necessary to verify any signature types defined. The additional benefit is that the client that needs proof of signature can call this service and not be bound to any specific policy, technology, encoding, etc.
The drawback is that the signature verifying service must be trusted completely, but this true of any software doing signature verifying.