Stream: implementers
Topic: publicKey in Endpoint
Luke Duncan (Mar 23 2017 at 13:58):
I see that publicKey was removed from endpoint and suggested to use an extension. Will there be a standard extension defined or should we just set up our own?
John Moehrke (Mar 23 2017 at 14:43):
Luke, can you explain your use-case? The only use-case we have where it would be helpful to publish the publicKey in the Endpoint is where that endpoint is an asynchronous communication type. So of the types of endpoints, this only applies to Direct. Isn't it more appropriate for Direct to publish those Certificates with the Provider? As the Certificate is not just an endpoint, but an identity, and signing. --- Note it isn't there either... so ultimately it should be somewhere, but where is the most appropriate?
Luke Duncan (Mar 23 2017 at 17:41):
I believe it was to allow organizations or practitioners to receive communication by being able to look up the certificate to encrypt the message before sending.
John Moehrke (Mar 23 2017 at 17:47):
Okay, so your usecase is an asynchronous messaging such as Direct. Understood. I just wanted to make sure there was no misunderstanding, or new use-case that was not understood.
John Moehrke (Mar 23 2017 at 17:47):
Is it then right to create an Endpoint for each Direct address? I am not against this, just wanting to understand the potential ramifications.
Carl Leitner (Mar 23 2017 at 18:08):
As an FYI, I looked back at my the argonauts did with the provider directory work:
http://argonautwiki.hl7.org/index.php?title=Provider_Registry_Implementation_Guide
The don't specify where the PKI certificate should go. They do put the DIRECT address in an extension.
John Moehrke (Mar 23 2017 at 19:04):
certainly needed to support Direct usecases. I could see why it might be a US extension.
Grahame Grieve (Mar 23 2017 at 19:37):
@Brett Marquard has this been discussed in Argonaut?
Brett Marquard (Mar 23 2017 at 19:44):
The Argonauts didn't discuss including a public Key in Endpoint. We did originally use an extension for the Direct address before updating to EndPoint
Brett Marquard (Mar 23 2017 at 19:45):
latest design here: http://build.fhir.org/ig/Healthedata1/Argo-PD/StructureDefinition-argo-endpoint.html
Brett Marquard (Mar 23 2017 at 19:45):
we added direct-project to this value set http://build.fhir.org/valueset-endpoint-connection-type.html
Brett Marquard (Mar 23 2017 at 19:46):
...will make it more clear that wiki is no longer place to reference for Argo PD
John Moehrke (Mar 23 2017 at 20:07):
Brett, that connection type is in STU3. But there is no element in Endpoint to hold the Certificate. I though it was being moved into an Extension, but seems not to have shown up there. I also don't see it in your Healthdata1 extension...So for Direct, it is needed somewhere
Brian Postlethwaite (Mar 23 2017 at 23:00):
Yes, after discussion we removed the public key to be put into extensions where its purpose will be very explicit as to why it is there.
Expected uses were for encrypting so only the recevier can get them (as you've noted above), checking the signature to ensure that the content wasn't tampered with, and others.
John Moehrke (Mar 24 2017 at 14:01):
Brian, is that still in an existing CR that we can track?
John Moehrke (Mar 24 2017 at 14:03):
In looking at Argonaut Directory, it seems they never had in-scope to publish the Certificate in the directory. Presumably the DNS CERT mechanism is sufficient? If so, then this need is indeed not core and might not even have any urgency. I would have expected USA interest.
Brian Postlethwaite (Mar 25 2017 at 23:00):
There is no current CR for that. We processed a CR to remove it, in preference to having extensions to determine usage.
Last updated: Apr 12 2022 at 19:14 UTC
