FHIR Chat · Bundle Signatures · implementers

Stream: implementers

Topic: Bundle Signatures

Grahame Grieve (Dec 28 2017 at 23:03):

The following signed document has a valid signature:

Grahame Grieve (Dec 28 2017 at 23:03):

signed.xml

Grahame Grieve (Dec 28 2017 at 23:04):

but it's not a valid FHIR instance:

Grahame Grieve (Dec 28 2017 at 23:04):

  <signature>
    <type>
      <system value="urn:iso-astm:E1762-95:2013"/>
      <code value="1.2.840.10065.1.12.1.1"/>
    </type>
    <when value="2017-12-28T23:02:41Z"/>
    <whoReference>
      <reference value="Practitioner/example"/>
    </whoReference>
    <targetFormat value="application/fhir+xml"/>
    <sigFormat value="application/signature+xml"/>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>hE70IWsShlfQtc+HaiWAsl+0fkI=</DigestValue></Reference></SignedInfo><SignatureValue>IQY6hk/xtFKokFfqIKHnZnliCE1FF1bVNKqWkSI3uTYh55AqhjMCkyxaOJBu4vVclemB5TRFUAyEnxrNTYdm7hR6o7PdIJ5EO9ZuO9RSzgNkDOIfMYdPQjnECTJcN7XIuZroeviFstzR/iIECVUmTLJw0m0ddXGey8/DSLIYjgzpcZqIcVlkOs+NjqbeXJWKC260sLPwXMOyiNvfMdhLl7P424P+KHPuVUUOXTJ5jjdummJqxBVMnS/g1R+8tG9KcPG78BTbFm3m3XxBsmzJuOEw8TMiefSDZktmeQkNTGGYiVqJPTWZAlPuJFG7WZkUfWFOx76Fn+tCr9qDtWq/OA==</SignatureValue><KeyInfo><KeyValue><RSAKeyValue><Modulus>m475SJi0ndOkUWBDK9HeUPJLo5ujSiTaO23N6DrNHMR0wGzbMNTaslVKUKKF+wR1JBwoGvGLwsol0vrctR+tz/z5JbetCjOwFqh1R6ElJL7/T2sPLo1gRxpXmTAJ+kWbenQX9Z8Mr8teijGPwQ0MvQWlesl0S0ZJm4W54XVwFPsvbUaohKyCx6yBT1SyTcMHnDJve9AT/k30Gu/euxMLMQE814rSWnoyVy8p5Dt4AgTWKEgU4y2Efr8yZRlx6Fhttbt6g/lGWretlKuA46MJv3HyssYw7daTHKoHCIcaU/bhJ237pFguQg6v/Zn6U7hTHwW3lWXVXyEZCsaZtflPGw==</Modulus><Exponent>AQAB</Exponent></RSAKeyValue></KeyValue></KeyInfo></Signature></signature>

Grahame Grieve (Dec 28 2017 at 23:04):

problem is that the signature needs to be put in a blob... but then it's not an enveloped signature... so I'm not sure what it should look like?

Grahame Grieve (Dec 28 2017 at 23:04):

@Rick Geimer @John Moehrke

John Moehrke (Dec 29 2017 at 00:30):

Grahame, what are you trying to show?

John Moehrke (Dec 29 2017 at 00:31):

The blob is the base64 of the xml signature. Not what you have.

Grahame Grieve (Dec 29 2017 at 00:31):

right. So what should the signature in the blob look like. is reference="" still valid?

John Moehrke (Dec 29 2017 at 00:32):

sorry. i don't understand your question.

Grahame Grieve (Dec 29 2017 at 00:33):

An enveloped signature is added to an XML document, like above. It has <Reference URI=""> - to indicate that what is signed is the XML document that contains the signature, and it is removed before verifying the signature.

Grahame Grieve (Dec 29 2017 at 00:33):

I do not see that it is possible to have an enveloped signature in a Bundle - yet it must be because it is inside the bundle

John Moehrke (Dec 29 2017 at 00:33):

An enveloped signature?

Grahame Grieve (Dec 29 2017 at 00:34):

yes. that's what we're talking about

John Moehrke (Dec 29 2017 at 00:34):

so Bundle.signature

Grahame Grieve (Dec 29 2017 at 00:34):

.. yes, that's what I'm asking about.

John Moehrke (Dec 29 2017 at 00:34):

Yes you have indeed happened upon a problem that who ever added signature to Bundle didn't address. I was not aware

Grahame Grieve (Dec 29 2017 at 00:35):

not aware that Bundle contains a signature..?

John Moehrke (Dec 29 2017 at 00:35):

for encapsulated signatures, typically the xml-signature would have an xpath exception for the place where the signature is going to be stored.

Grahame Grieve (Dec 29 2017 at 00:36):

what does that look like?

John Moehrke (Dec 29 2017 at 00:36):

that is what CDA did with the encapsulated xml-signature

John Moehrke (Dec 29 2017 at 00:36):

encapsulated signatures are trouble... not just because of this. But because of this need to exclude from the signature a region where the signature will go.... bad-guys simply put what they want inside that exception area

Grahame Grieve (Dec 29 2017 at 00:40):

what's a good reference for the CDA encapsulated signature? I can't find good information about " the xml-signature would have an xpath exception"?

John Moehrke (Dec 29 2017 at 00:41):

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=375

John Moehrke (Dec 29 2017 at 00:46):

hmmm, I expected that was a bit more instructive

Grahame Grieve (Dec 29 2017 at 00:53):

it doesn't help. For a start, the example is not legal (not even any namespace)

John Moehrke (Dec 29 2017 at 00:54):

So, all of the actual uses that I have worked with are signatures by reference. Like what we did in Provenance, or IHE DSG. Where the signature is not contained within the hash space. I only know of the theory, don't have a good example. For an encapsulated signature you need to exclude from the hashed space the slot where you are putting the blob.

Grahame Grieve (Dec 29 2017 at 00:58):

now that I've read the text of that document, I'm getting more unhappy. The examples have "<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>" - but this is a lie, because:

A digest is the result of a mathematical algorithm that takes all of the bits of the thing to be signed (in this case, the CDA document excluding the legalAuthenticator and authenticator tags in the CDA header)

Grahame Grieve (Dec 29 2017 at 00:59):

It's also hard to believe that the signature ignores the authenticator information - that information that binds between the signature and the thing being signed.... surely that smells badly?

Grahame Grieve (Dec 29 2017 at 00:59):

how does IHE DSG work with CDA documents?

John Moehrke (Dec 29 2017 at 01:01):

yeah, I do remember I put in a bunch of negative comments... That is what resulted

John Moehrke (Dec 29 2017 at 01:02):

DSG just makes a XML-Signature blob (as a document) of a signed document (by reference)

John Moehrke (Dec 29 2017 at 01:02):

thus there is no need to exclude anything

John Moehrke (Dec 29 2017 at 01:02):

simple

John Moehrke (Dec 29 2017 at 01:02):

what you need for Bundle is https://www.w3.org/TR/xmldsig-core1/#sec-EnvelopedSignature

John Moehrke (Dec 29 2017 at 01:02):

where you exclude the Bundle.signature element during signing and validation

Grahame Grieve (Dec 29 2017 at 01:02):

but where does the signature go? It just moves the problems around

John Moehrke (Dec 29 2017 at 01:03):

in IHE-DSG? There are two options... ( a ) Two documents are in the Registry... one is XML-Signature, the other is the signed docment

John Moehrke (Dec 29 2017 at 01:03):

The other one ( b ) is enveloped... That is the signed document is base64 encoded INTO the XML-Signature.

John Moehrke (Dec 29 2017 at 01:03):

no,... not enveloped... enveloping.

John Moehrke (Dec 29 2017 at 01:04):

you want envelopedSignature

Grahame Grieve (Dec 29 2017 at 01:04):

so note that the actual transform for https://www.w3.org/TR/xmldsig-core1/#sec-EnvelopedSignature is pre-specified - to exclude the dsig:Signature. So we'd have to define our own canonicalization then

John Moehrke (Dec 29 2017 at 01:04):

that is where you put the signature into the signed-document, in an element excluded from the signature calculation

John Moehrke (Dec 29 2017 at 01:04):

yup

John Moehrke (Dec 29 2017 at 01:07):

so, I guess that should not be too hard to do for Bundle.signature... right? And we can likely use fhir path?

John Moehrke (Dec 29 2017 at 01:08):

I hadn't noticed that the xpath exclusion is baked into the canonicalization algorithm... and thus we need our own..

John Moehrke (Dec 29 2017 at 01:08):

so then why is that not in the CDA signature spec.. hmmmm.....

Grahame Grieve (Dec 29 2017 at 01:12):

yes CDA spec is broken. I think we don't want to follow.

Grahame Grieve (Dec 29 2017 at 01:13):

so I think we need a new method code here: http://build.fhir.org/xml.html#digsig

Grahame Grieve (Dec 29 2017 at 01:14):

http://hl7.org/fhir/canonicalization/xml#bundle - signs an entire document, with the exception of Bundle.signature.blob

John Moehrke (Dec 29 2017 at 01:22):

sounds like that is heading in the right direction.

John Moehrke (Dec 29 2017 at 01:23):

The way I defined the signature datatype, it is not intended to be part of the signature. All the elements in the signature datatype are intended to be just easy access for a FHIR app to stuff that formally is part of the xml-signature.

John Moehrke (Dec 29 2017 at 01:23):

so, exclude the whole signature, not just the signature.blob

John Moehrke (Dec 29 2017 at 01:23):

that is just my logic... it might not be useful logic

John Moehrke (Dec 29 2017 at 01:24):

that also makes it easier to fixup the elements i Signature without invalidating the digital-signature

Grahame Grieve (Dec 29 2017 at 01:30):

I don't follow why you'd exclude all the elements that are easy access from the signature - just seems like it creates an obvious attack point - sign, but hack all the easy statements about the signature...

John Moehrke (Dec 29 2017 at 01:49):

I put warnings in the Signature datatype about this

John Moehrke (Dec 29 2017 at 01:50):

most will use these elements to find things, but they know for legal reliance (like a legal audit) they need to look at the same elements as captured within the signature itself

Grahame Grieve (Dec 29 2017 at 01:56):

I don't see the language. I don't see why we shouldn't sign them.

John Moehrke (Dec 29 2017 at 01:57):

I didn't say I put that language in there... I never expected someone to try an enveloped signature

Grahame Grieve (Dec 29 2017 at 01:57):

"I put warnings in the Signature datatype about this"....?

Grahame Grieve (Dec 29 2017 at 01:58):

is there any reason it shouldn't be a detached signature in there?

John Moehrke (Dec 29 2017 at 01:58):

about the fact the elements in the Signature datatype are informative, not part of a signature

Grahame Grieve (Dec 29 2017 at 01:59):

I've read it several times and can't see it

John Moehrke (Dec 29 2017 at 02:02):

hmmm... It must be well written in my head

John Moehrke (Dec 29 2017 at 02:02):

write a CR?

John Moehrke (Dec 29 2017 at 02:02):

more evidence that this is a good candidate to stay STU

John Moehrke (Dec 29 2017 at 02:03):

I start here... but it also doesn't say what I think it shouldhttp://build.fhir.org/secpriv-module.html#signature

John Moehrke (Dec 29 2017 at 02:03):

http://build.fhir.org/secpriv-module.html#signature

Grahame Grieve (Dec 29 2017 at 02:03):

back to detached/enveloped - is there any reason we shouldn't use detached in Bundle.signature.blob?

John Moehrke (Dec 29 2017 at 02:05):

I am not clear what the use-case for Bundle.signature is

John Moehrke (Dec 29 2017 at 02:05):

I saw it appear there, but was not involved in it

Grahame Grieve (Dec 29 2017 at 02:06):

signing documents exactly similar to the CDA use case

John Moehrke (Dec 29 2017 at 02:12):

As I have indicated... most that go to the extent of actually trying to make this work in real life... use detached, and maintain the signatures independent of the signed object. It is just more robust

John Moehrke (Dec 29 2017 at 02:12):

Provenance can do this for the whole FHIR-Document

John Moehrke (Dec 29 2017 at 02:13):

Provenance.target points at the FHIR Document, Provenance.signature holds the signature of that FHIR Document

Grahame Grieve (Dec 29 2017 at 02:13):

I'm suspicious of this. It feels like it moves the deckchairs around - how do I know I have the right matching provenance?

John Moehrke (Dec 29 2017 at 02:13):

enveloped signatures looks cool, and seems like what one would want... but it is a bitch to get right, and cracks easy

John Moehrke (Dec 29 2017 at 02:14):

why would you not find the right one?

Grahame Grieve (Dec 29 2017 at 02:14):

see http://wiki.hl7.org/index.php?title=201801_FHIR_Documents - what would you propose? @Sarah Gaunt @Sean McIlvenna @Rick Geimer

John Moehrke (Dec 29 2017 at 02:16):

should be fun

John Moehrke (Dec 29 2017 at 02:17):

doesn't a FHIR Document exist as a FHIR Resource? Thus a Provenance.target can point at that FHIR Document?

Grahame Grieve (Dec 29 2017 at 02:19):

it can. But the implication of what you are saying is that we might as well remove Bundle.signature

John Moehrke (Dec 29 2017 at 02:21):

so if someone just added signature to Bundle expecting magjic would happen... then, yes, we should remove it until we can make it work

John Moehrke (Dec 29 2017 at 02:21):

sure sounds well outside the 80%

Grahame Grieve (Dec 29 2017 at 02:41):

it's been there a long time. Since the beginning, in fact, since it cam out of Atom

Grahame Grieve (Dec 29 2017 at 07:25):

ok, an update, then. Here's a revised signed document, for comment

Grahame Grieve (Dec 29 2017 at 07:26):

signed.xml

Grahame Grieve (Dec 29 2017 at 07:26):

for reader convenience, here's the signature directly:

Grahame Grieve (Dec 29 2017 at 07:26):

<?xml version="1.0" encoding="UTF-8"?>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
    <Reference>
      <Transforms>
        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
      <DigestValue>Vyn0Z139dlswfTg1Ivx/DNlVJAJoRC+ros1dtAKKHGo=</DigestValue>
    </Reference>
  </SignedInfo>
  <SignatureValue>RU2N7C/WdTuuk5PCbdBL6/Qk6Tx46qEN1K4t6FbdZJmnDmYmlEn6WA+D1AnfQcfkDGlsSS2oyr/vZNRGyVSiVZkQAcHs2ExUo8YuwyI/SU40Mc9uqpWb18LNVu3+DRBaowUTzcDoafIBVkEe+Qv5B2kgByiqe2MN1V/a/dwjiMdb+SMXah60yHaq0o5vOYerAx/NYt4cpruvLcHUD6zRu+9f3h+Ptj+6hjhaK2P+WpNjANm3QokzZnqhAKqEwlNd1yFPBcL6zMhQKSvijkyNQDnjPGNfDyJDjc4LaZZ6SXu6TCiZICiYemlfypsZ7FiGYqc9OTAbWUqr/hqQQEw+qA==</SignatureValue>
  <KeyInfo>
    <KeyValue>
      <RSAKeyValue>
        <Modulus>m475SJi0ndOkUWBDK9HeUPJLo5ujSiTaO23N6DrNHMR0wGzbMNTaslVKUKKF+wR1JBwoGvGLwsol0vrctR+tz/z5JbetCjOwFqh1R6ElJL7/T2sPLo1gRxpXmTAJ+kWbenQX9Z8Mr8teijGPwQ0MvQWlesl0S0ZJm4W54XVwFPsvbUaohKyCx6yBT1SyTcMHnDJve9AT/k30Gu/euxMLMQE814rSWnoyVy8p5Dt4AgTWKEgU4y2Efr8yZRlx6Fhttbt6g/lGWretlKuA46MJv3HyssYw7daTHKoHCIcaU/bhJ237pFguQg6v/Zn6U7hTHwW3lWXVXyEZCsaZtflPGw==</Modulus>
        <Exponent>AQAB</Exponent>
      </RSAKeyValue>
    </KeyValue>
  </KeyInfo>
</Signature>

Grahame Grieve (Dec 29 2017 at 07:27):

oh. oops. missed something. I'll try again shorlty

Grahame Grieve (Dec 29 2017 at 07:52):

ok, this pair:

Grahame Grieve (Dec 29 2017 at 07:53):

signed.xml

Grahame Grieve (Dec 29 2017 at 07:53):

<?xml version="1.0" encoding="UTF-8"?>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://hl7.org/fhir/canonicalization/xml#bundle"/>
    <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
    <Reference>
      <Transforms>
        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
      <DigestValue>H/lLrIGPTNlpf1Xr78AmZ2VVCDeO4XzYZalqxCgJmVQ=</DigestValue>
    </Reference>
  </SignedInfo>
  <SignatureValue>kwm6FNATYxp4sdHf0noK8Z1JBCyw+XisaRvhjsiIuL6emO7Yityq3CIRWm2WS8aAeq/bzcRrqRQB+TJKuwDGOXqJarkH7VuBreAMMNDotctMPSnb7BInzSpg+ytus1fz7MvtlQBpfyuEwNA4RNJcOLK8BgQe1pWwckNaNt5hN2Rn71E+doGr3g7FeX7kQZ3yWJTV7XWExVZdmDaDRI77N+AsNIPNP4Nc/OiAJJP+DAeHW15AJssQUIykr0ZKTaPLVPdk7N2QwBpkYsbkHh1646ys5MKDYu9+fRb8il5x8Ao1Dxgbeoow8VXDW1RI1cCbT7T5V+cm+T15LCTB9iCRRw==</SignatureValue>
  <KeyInfo>
    <KeyValue>
      <RSAKeyValue>
        <Modulus>m475SJi0ndOkUWBDK9HeUPJLo5ujSiTaO23N6DrNHMR0wGzbMNTaslVKUKKF+wR1JBwoGvGLwsol0vrctR+tz/z5JbetCjOwFqh1R6ElJL7/T2sPLo1gRxpXmTAJ+kWbenQX9Z8Mr8teijGPwQ0MvQWlesl0S0ZJm4W54XVwFPsvbUaohKyCx6yBT1SyTcMHnDJve9AT/k30Gu/euxMLMQE814rSWnoyVy8p5Dt4AgTWKEgU4y2Efr8yZRlx6Fhttbt6g/lGWretlKuA46MJv3HyssYw7daTHKoHCIcaU/bhJ237pFguQg6v/Zn6U7hTHwW3lWXVXyEZCsaZtflPGw==</Modulus>
        <Exponent>AQAB</Exponent>
      </RSAKeyValue>
    </KeyValue>
  </KeyInfo>
</Signature>

Grahame Grieve (Dec 29 2017 at 08:52):

@John Moehrke turning my attention to a json equivalent now.... we (you!) specify the mime type for json as application/jose. Is the specifically not application/jose+json? I would have thought that application/jose+json was actually the right thing to use in a Signature?

John Moehrke (Dec 29 2017 at 13:03):

that is what the RFC said to use...

Grahame Grieve (Dec 29 2017 at 18:52):

• application/jose = the compact form (URL safe encoding)
• application/jose+json = the full form (json encoding)

You've specified the URL safe encoding.....

Brian Postlethwaite (Dec 30 2017 at 23:09):

Will this also work for the bulk data transfer json format?
I expect this could be a useful place for it.

Grahame Grieve (Dec 31 2017 at 10:03):

I don't think signatures apply there - tough situation for signatures

John Moehrke (Dec 31 2017 at 20:36):

Bulk data transfer, is likely well enough covered by the communications security mechanism (e.g. mutually-authenticated TLS, https+OAuth, https+SMIME, S/MIME). So there is not really a need for a signature in the bundle.

John Moehrke (Dec 31 2017 at 20:40):

end-to-end security (made up of multiple point-to-point communications), is more the space where a signature is needed. Biggest use-case is where an object sits-at-rest for a period of time, and one needs an integrity check that the object has not changed while it was resting. Which is why the topic is natural to come up with a FHIR Document, or any FHIR Resource. the use-case for any FHIR Resource is well covered by Provenance.signature. I would argue that this same solution should be considered for FHIR Document, until someone identifies a specific use-case. We can then assess that specific use-case for best solution. This said, there is clearly more "Trial" (STU) experience we need with this solution.

Rick Geimer (Jan 03 2018 at 00:40):

Just coming up to speed on this after the holidays. @Sarah Gaunt please read the whole thread.

On the FHIR Documents track, we added the digital signature scenario specifically because it needs testing. We actually added it several connectathons ago, but no one did it yet (most people who sign up for the documents track are newbies to docs).

Assuming someone does try it this time around, I think we should test both the detached (using Provenance) and enveloped (using Grahame's sample as an example) methods.

Also, maybe this is a dumb question, but why not follow https://www.w3.org/TR/xmldsig-core1/#sec-EnvelopedSignature exactly and use dsig:Signature? Yes it's in another namespace, but is there a reason why we can't do that for XML?

Grahame Grieve (Jan 03 2018 at 00:45):

we could but it's a lot of work for everyone

Grahame Grieve (Jan 03 2018 at 00:45):

what would it look lke for json?

Grahame Grieve (Jan 03 2018 at 00:46):

a for provenance, what workflow do you want for the connectathon?

Rick Geimer (Jan 03 2018 at 00:46):

I'm not much of a JSON guy, better to ask someone who is. I assume there is a preferred method of signing JSON files, yes?

Grahame Grieve (Jan 03 2018 at 00:47):

I expected to add a sign parameter to the $document operation, but I fall over on passwords/access (personal or system cert?). What would the flow be for a provenance?

Grahame Grieve (Jan 03 2018 at 00:48):

well, there's a way to, yes, though I haven't got the bottom of jose yet. I haven't found enveloped signatures there yet. @John Moehrke?

Rick Geimer (Jan 03 2018 at 00:50):

The flow from the Connectathon perspective? I assume it would be pretty simple:
a) Create a document
b) Calculate the signature for the document
c) Create the Provenance resource and stuff the sig in there.
d) Post both to your favorite FHIR server

Grahame Grieve (Jan 03 2018 at 00:55):

so the client does the signing? ok

Grahame Grieve (Jan 03 2018 at 00:56):

can you update the wiki page?

Rick Geimer (Jan 03 2018 at 04:41):

Sure

John Moehrke (Jan 03 2018 at 16:56):

This will be enlightening. The main problems with the client doing the signatures is all of the expected reference fixup that the server will do will cause that signaure to break. This is the main problem we have identified as a problem for all digital signatures http://wiki.hl7.org/index.php?title=FHIR_Digital_Signature_Working_Page

John Moehrke (Jan 03 2018 at 16:57):

The text I put in for json signatures was purely done by theory... no actual trial feedback has been received.

Grahame Grieve (Jan 03 2018 at 21:19):

this is why an encapsulated signature on a bundle is so much simpler - because there's no external dependencies to intrude on the content. The idea that encapsulated signatures are harder is because of externalised complexity

Grahame Grieve (Jan 03 2018 at 21:33):

I will implement a client that uses $document on the server, signs the response, and posts it back to the server as a binary, with either an encapsulated signature or a detached provenance

John Moehrke (Jan 03 2018 at 22:00):

If you have already fixedup the references, then that problem goes away. Not sure how encapsulated signature magjically solves the fixup problem.

Grahame Grieve (Jan 04 2018 at 01:28):

No need to fiddle with references afterwards. Unlike in other contexts.

Grahame Grieve (Jan 04 2018 at 01:31):

On this subject, take this workflow: generate a document, sign it, post it to the server as a binary. @Ewout Kramer @James Agnew @Josh Mandel - the content type will be none other than.. application/fhir+[fmt]... which is ambiguous... isn’t it?

Grahame Grieve (Jan 04 2018 at 07:10):

@Rick Geimer @Sarah Gaunt is there a specified version of FHIR for the document track?

Grahame Grieve (Jan 06 2018 at 02:51):

ok. so I have released a new version of the FHIRToolkit that supports the following workflow:
- connect to a server
- find a patient, double click
- see the patient's compositions, double click one
- toolkit fetches a document using $document
- allows the user to see the document
- prompts for user to provide certificate details to sign the document
- allows user to choose an embedded signature (Bundle.signature) or a detached signature (Provenance.signature)
- allows the user to save Document/DocumentReference(/Provenance) back to the server, or to a local file

@Rick Geimer @Sarah Gaunt @Sean McIlvenna

Grahame Grieve (Jan 06 2018 at 02:52):

xml signatures a supported (completely, so far as I can tell). JSON signatures is a work in progress

Last updated: Apr 12 2022 at 19:14 UTC