Document SignaturesWith Document Signatures, we have a completely self-describing blob that we hash, and that hash is included in a Digital Signature block. This signature block can be managed in at least three distinct ways:
- Detached – Signature block is managed as an independent document from the document(s) it signs Possibly using a Document Sharing system like XDS which also has ‘association’ linkages that can identify the signature relationship between signed document and the signature document.
- Enveloping – Signature block is managed as a document that contains the document that it signs. The signed document is ‘enveloped’ inside of the signature block. This ‘new’ object can be managed and communicated in many ways. The signed document and the signature are bound together through this containment. However to access the signed document, one must be able to take the signature envelop off of the document.
- Enveloped – The Signature block is inserted inside of the signed document. This means the signed document must have a defined place to hold the signature block, and the signature must exclude this place. The signed document and signature are bound together through this form of containment. However to access the signature block, for validating the signature, one must have the ability to extract the signature prior to sending it to a standards based signature verification algorithm.
FHIR are ResourcesFHIR could use the above mechanisms, but the dynamic nature of FHIR causes many problems.
FHIR Resources can and will be made into Documents
Resource fixup breaks SignaturesBut most of the time with FHIR, the expectation is that the Document or any set of Resources will be decomposed and managed independently. Thus we don’t have a “Document” for long, we have a set of Resources that are ‘fixed up’ by the server. We have a set of Resources that are moved around, and thus more ‘fixup’ happens. The first problem that FHIR presents is this concept of ‘fixup’. What I mean by ‘fixup’ is this: Any FHIR Resource that contains pointers, either Reference or URI or Attachment or other; these pointers might need to be adjusted by any system that is going to persist or further process. An example is that sometimes a bundle will be created that contains all the necessary Reference resources, all pointed to through relative-URI. The recipient will break these resources out of the Bundle and as it stores them it will create a absolute-URI and thus adjust the uses of the previous relative-URI to the new absolute-URI. This is a specific example of ‘fixup’. There are others elements of a Resource that might need to be adjusted by a recipient. These ‘fixup’ are expected, and normal. They should not be changing the meaning originally intended. A digital-signature would see this as a change and thus flag the change as breaking the signature. If the change is expected and normal; then the signature needs to ignore these changes. However the signer does also need to make sure that the ‘fixup’ was done accurately.
An interesting, and simple, solution to one deployment scenario goes like this: For a client that wants to create a signature across a Resource that it is going to publish, it could manage the ‘fixup’ problem using the following method: From the perspective of a FHIR client
- The client creates a new instance of some resource(X)
- The client Posts X onto server Y
- The HTTP Response indicate successfully created, returning the URL to X’
- The client retrieves that instance X’ from the server Y resulting in a local copy of X’
- The client confirms that the essence of what is intended to be recorded has been recorded. Thus allowing the server to do things like fixing up references.
- The client then calculates the signature S across that X’
- The client then creates a Provenance resource P pointing at X’, with the signature calculated S.
- The client could then retrieve the Provenance instance P’ and validate X’ and included S’ with the current X”