Stream: bulk data
Topic: secure: false ... ?
Isaac Vetter (Apr 12 2018 at 19:55):
The bulk data status response includes a boolean _secure_ element:
secure - boolean value indicating whether downloading the generated files will require an authentication token. Note: This may be false in the case of signed S3 urls or an internal file server within an organization's firewall.
This is the intentional support of bulk PHI exposed insecurely. Is this really a good idea? If so, how about additional information around when it's appropriate to use this?
Chris Grenz (Apr 12 2018 at 20:35):
From a secure communications standpoint, a signed URL contains a secret as much as URL+Bearer Token. It can be revoked. It expires. I'm not sure I agree that it's "exposed insecurely". It's probably not a great idea since URL are not usually treated as secrets in practice. But putting the secret in a separate header isn't technically more secure.
Chris Grenz (Apr 12 2018 at 20:35):
@John Moehrke ?
Josh Mandel (Apr 12 2018 at 21:43):
They use case for this field is to tell a client whether or not it needs to include the same authorization header that uses for EHR Communications when fetching this file
Josh Mandel (Apr 12 2018 at 21:44):
It might be better to call it useEhrAuthorization or needAuthorizationHeader or some such
Josh Mandel (Apr 12 2018 at 21:44):
For a self-contained signed URL, this would be set to false whatever we call it
Chris Grenz (Apr 12 2018 at 22:33):
@Josh Mandel - good point. It's not "not secure". It's about the authorization needed for the link vs. the original request.
Brian Postlethwaite (Apr 12 2018 at 22:51):
Agree that renaming the property to requiresAuthorizationToken or similar is a good idea, secure = false just seems wrong.
Internal file server (or internal web server) likely also has domain authentication, so is not insecure...
Josh Mandel (Apr 12 2018 at 23:41):
Yeah. The key consideration is that either the url should just work (like a signed URL) or require an EHR authorization token -- it shouldn't require out of band special knowledge to follow.
John Moehrke (Apr 12 2018 at 23:59):
I would echo the conclusions of the discussion.. although I would also indicate that if a server is willing to communication without security protocols, that is a policy decision that server should be allowed to do. I would not agree that this policy is good, but I will fight for their right to enforce any policy they want to enforce... Note one likely time this is valid is where there are other means securing the communication, such as a point-to-point mutually authenticated VPN.
Isaac Vetter (Apr 13 2018 at 06:05):
Hey Guys,
I just created issue #19 on the bulk data api spec to capture this feedback. Personally, I like @Brian Postlethwaite 's suggestion of requiresAuthorizationToken, despite its length. Are there existing examples of this type of field elsewhere in OAuth / security / the internet?
Josh Mandel (Apr 13 2018 at 11:04):
Thanks Isaac! I haven't seen this kind of thing at other places but it's worth keeping an eye out.
John Moehrke (Apr 13 2018 at 13:16):
In a very indirect way this specific solution is a concrete example of negotiation that is the abstract concept behind a work item that the security WG is doing around the abstract concept of negotiating a Trust Framework between two communicating partners that don't have a relationship to begin with. Very abstract work. See the current HL7 ballot -- HL7 Version 3 Standard: Privacy and Security Architecture Framework - Trust Framework for Federated Authorization, Release 1 (PI ID: 914)
Last updated: Apr 12 2022 at 19:14 UTC
