Stream: implementers
Topic: Apply Digital Signature
Marshall Weekley (Jan 25 2018 at 15:20):
I am needing to create a service that allows for the posting of a document and a passphrase, then applying the digital signature to that document. Is there a Fhir resoruces that would support this type of process? The Provenance allows for details about a signature but does not seem to allow for the validation of any type of key.
John Moehrke (Jan 25 2018 at 15:28):
Hi Marshall. I am the owner of the FHIR security stuff... so would like to understand a bit more about what you are trying to do. It sounds to me like you want a 'service' that you can send a FHIR object to, and get a Digital Signature out of it? I am not sure I understand fully what you are trying to do, or how you are trying to do it.
Marshall Weekley (Jan 25 2018 at 16:17):
We are embedding another app into our system. We are using a fhir implementation to pass data to the embedded app. The embedded application has documents that it will need to have signed. We have the signing logic in parent app. I am wanting to allow the emedded app to be able to pass me the document and a password that is used for signing and then we can perform the siganture for the embedded app.
John Moehrke (Jan 25 2018 at 17:38):
So the Provenance resource would be the output from this process. I would suggest that what you are asking for is to create a signing service that takes as arguments the Resouce(s) to be signed, and some other parameters. This would be a useful service. see http://build.fhir.org/services.html
John Moehrke (Jan 25 2018 at 17:41):
I think that @Grahame Grieve has implemented something like this, in his case I think it just applies a timestamp signature, so no need to pass in an identity/password. A timestamp service has its own identity that it uses. In the case of FHIR it is one that understands FHIR as input, and produces a FHIR based Provenance as output. As a timestamp service it could produce signatures across both json and xml encodings too.
John Moehrke (Jan 25 2018 at 17:42):
for general description of a timestamp signature service see https://en.wikipedia.org/wiki/Trusted_timestamping#Trusted_(digital)_timestamping
John Moehrke (Jan 25 2018 at 17:42):
I would be interested in seeing something like this further developed. Even if just informally, but would expect it to eventually be useful formally.
John Moehrke (Jan 25 2018 at 17:45):
There are known issues with digital signatures with FHIR. Issues that can be addressed, but only if we get a group of implementers and motivating use-cases. Digital signatures are too often hyped, and too few actually implemented. See my blog topics on this https://healthcaresecprivacy.blogspot.com/2014/12/digital-signatures-on-fhir.html
Marshall Weekley (Jan 25 2018 at 22:12):
Are there any examples of how a service is expected to added to the Fhir environment? Or is this pretty open to how they should be created.
John Moehrke (Jan 25 2018 at 22:47):
see http://build.fhir.org/services.html
Grahame Grieve (Jan 26 2018 at 00:44):
I did this in the client. (FHIR Toolbox). Here's how it works for me:
- composition is created on the server (not part of this workflow - has to already have happened)
- client asks the server to generate a document
- client prompts the user to pick a certificate and provide the passphrase
- client uses digsig or jose code to sign the document (producing a provenance resource and/or an embedded signature in the document)
- client posts the output resource(s) back to the server, or saves them to a file
Grahame Grieve (Jan 26 2018 at 00:45):
it's possible to put the signing code on the server, but that's messy - passing passphrases across the network etc...
Grahame Grieve (Jan 26 2018 at 00:46):
"Are there any examples of how a service is expected to added to the Fhir environment?" - this is a wrong question... FHIR is an API specification, and you're asking a deployment question that we have nothing to say about - so the answer will depend on the implementation
Last updated: Apr 12 2022 at 19:14 UTC
