FHIR Chat · Backend Services · smart

Stream: smart

Topic: Backend Services

Grahame Grieve (Sep 20 2017 at 06:09):

@Josh Mandel some questions about the backend services spec

Grahame Grieve (Sep 20 2017 at 06:10):

doc says:

Grahame Grieve (Sep 20 2017 at 06:10):

• Register a fixed “issuer URL” with the EHR
• Register a public RSA key with the EHR (for RSA SHA-256 signatures)

Grahame Grieve (Sep 20 2017 at 06:10):

then the JWT says:

Grahame Grieve (Sep 20 2017 at 06:11):

{
 " iss": "https://{app url}",

Grahame Grieve (Sep 20 2017 at 06:11):

I think that the app url is meant to be the 'fixed "issue URL" with the EHR

Grahame Grieve (Sep 20 2017 at 06:12):

but I'm confused about whether it should or shouldn't have 'https://' when registered. this is unclear

Grahame Grieve (Sep 20 2017 at 06:13):

also the exp value in the sample JWT is... creative

Grahame Grieve (Sep 20 2017 at 06:13):

I have the same question about the token url with regard to prefix...

Josh Mandel (Sep 20 2017 at 12:32):

The fixed issuer url should be registered with the EHR (including "https"), and should be inserted wholesale as the jwt's iss property. Agree this should be clearer.

Josh Mandel (Sep 20 2017 at 12:33):

Ditto for the token url.

Josh Mandel (Sep 20 2017 at 12:38):

How is the exp creative? It's 1422568860, an integer number of seconds since epoch representing Thursday, January 29, 2015 10:01:00 PM, presumably when the example was written.

Josh Mandel (Sep 20 2017 at 12:41):

I don't think this specification has been implemented as written (though I'm not aware of places where it's broken... yet). I know @Isaac Vetter and @Jenni Syed have expressed interest.

Grahame Grieve (Sep 20 2017 at 12:57):

hmm. "exp" - I must have read the wrong piece of code. It thought it was relative

Isaac Vetter (Sep 20 2017 at 14:36):

Josh, we are actively developing support for Backend services as written.

Josh Mandel (Sep 20 2017 at 14:36):

@Grahame Grieve : expires_in on the token response is relative...

Jenni Syed (Sep 20 2017 at 14:57):

I think we'll be trying to do something for the connectathon and as this matures. Right now we use the OAuth 2 "client credentials" grant b/c it didn't seem like backend services had been ironed out yet. I reached out internally to see if there were any concerns with the draft as specified

Jenni Syed (Sep 20 2017 at 14:58):

I know we generally prefer not having the symmetric/shared secret :)

Jenni Syed (Sep 20 2017 at 14:59):

I'm curious how the certificate management part of this may work

Josh Mandel (Sep 20 2017 at 15:01):

No certificates! Just bare keys :-)

Jenni Syed (Sep 20 2017 at 15:02):

I guess I need to reread that draft :)

Jenni Syed (Sep 20 2017 at 15:03):

But either way, just public key, IIRC

Josh Mandel (Sep 20 2017 at 15:07):

Yes.

Grahame Grieve (Sep 20 2017 at 20:32):

another question about the JWT - it says

"sub" : "app_client_id"

Grahame Grieve (Sep 20 2017 at 20:32):

is this literal? if it's not, what is it ? (@Josh Mandel)

Josh Mandel (Sep 20 2017 at 20:32):

Not literal ;-) It's meant to express the OAuth client_id that the backend service received when registering with the EHR.

Grahame Grieve (Sep 20 2017 at 20:33):

the specification doesn't otherwise mention anything about a client_id from the backend service

Kevin Shekleton (Sep 20 2017 at 20:35):

It is the sub field in the JWT

Grahame Grieve (Sep 20 2017 at 20:35):

does the client_id bring any value over the issuer url?

Grahame Grieve (Sep 20 2017 at 20:36):

I think it does - but the spec should mention it explicitly in 'Registering a SMART Backend Service'

Josh Mandel (Sep 20 2017 at 20:38):

Yes! PRs or GH issue reports welcome on this stuff ;)

Josh Mandel (Sep 20 2017 at 20:39):

In theory, you could have a bunch of services all relying on the same issuer. When registering a service with the EHR, we'd say that the service supplies the issuer value, and the EHR assigns a client_id.

Grahame Grieve (Sep 20 2017 at 20:42):

ok where exactly do you want change proposals?

Josh Mandel (Sep 20 2017 at 20:43):

For backend services: http://docs.smarthealthit.org/authorization/backend-services/ has an "edit this page" link

Grahame Grieve (Sep 20 2017 at 20:45):

hmm. so I have to propose specific changes? what about changes inside the diagrams?

Grahame Grieve (Sep 20 2017 at 21:50):

@Josh Mandel I think that this is a valid JWT according to the instructions:

eyJhbGciIDogIlJTMjU2IiwidHlwIiA6ICJKV1QifQ.eyJhdWQiIDogImh0dHBzOi8vbG9jYWwuZmhpci5vcmc6OTYxL2F1dGgvdG9rZW4iLCJleHAiIDogLTE5MDIzMjIwNDgsImlzcyIgOiAiaHR0cDovL2xvY2FsLmZoaXIub3JnIiwianRpIiA6ICIzYWVhZTcyNC0yNmQ2LTQ3MzctYTRkMS0xYzYzM2QxZmJiN2QiLCJzdWIiIDogbnVsbH0.V1m1BLojiA2RNUdalgWAwYyyFuzTVodFlz94wqn9oB4NBQ-QzCAcl6LqG-8sA0gsDhJSMcCxHjUKV2-qwWqAfFw827RmYYDqbvipFFA9OWxh9mJcalMq4QJGF9G0WzVE8y2_g7ZkVKkFtuLpnWy4Pr8CCY_LK4AjZb9kJMAST1sJWrLtloEvBIAxOUBn-DD0S6HtRgPjV4Y9hPf_WZRybXjMckxQYLcM8XZCE54AZpUyndBOn-gV2Wo4DMmoRyLyuZ0reWPzah9EgTmL9oHLw4_jGRBBmMltqs2ZlQaCeDUrSZJmc2jvpRxZUzXf-72T5vXZTRjzdAbJDvGCD0Sd7Q

Grahame Grieve (Sep 20 2017 at 21:51):

this is the public key:

Grahame Grieve (Sep 20 2017 at 21:51):

test.fhir.org.cer

Grahame Grieve (Sep 20 2017 at 21:52):

can you check for me please... given that there's no other implementations..

Kevin Shekleton (Sep 20 2017 at 21:54):

The sub is null in that JWT

Kevin Shekleton (Sep 20 2017 at 21:55):

And the exp is -1902322048 (Monday, September 20, 1909 9:12:32 AM GMT)

Kevin Shekleton (Sep 20 2017 at 21:56):

Technically, the JWT is correct (signature verified too). Functionally though, the values are odd (especially the sub).

Grahame Grieve (Sep 20 2017 at 22:43):

grr both of those programming mistakes. I was focused ont the hard stuff. at least those are easy to fix

Grahame Grieve (Sep 20 2017 at 22:43):

anyway thanks

Grahame Grieve (Sep 20 2017 at 22:49):

eyJhbGciIDogIlJTMjU2IiwidHlwIiA6ICJKV1QifQ.eyJhdWQiIDogImh0dHBzOi8vbG9jYWwuZmhpci5vcmc6OTYxL2F1dGgvdG9rZW4iLCJleHAiIDogMTUwNjA3MDExNiwiaXNzIiA6ICJodHRwOi8vbG9jYWwuZmhpci5vcmciLCJqdGkiIDogIjgwNTQzNmZhLWE4NjYtNDVlMy05MjUzLTJhY2VmZWRjNjk2ZiIsInN1YiIgOiAidGVzdF9jbGllbnRfaWQifQ.R2EPxixnZrqgvkPAbYdKgD7Coi4mf6o9G9-yIvQqKvrDCcXyODemGbGN_krhrsFa8wdhhBQTMkhbvn7-VOoSeQQFNujQfXn1gxTkk-vo5DD39EGmCQr-RxlgPaHzxys7JwPvqhKGHw2MBDhcrhaKBhU7KIBEfBkxm4gzBTJdh8L4248H2xShEGJV5Sg1BXgPWGpKB3BDhVt3_Gm29YmiXigSrDrwtHYezSSxpFPF42dSAtVhccKKKodnEM3hFK2FP8_T0kzNgV4uhX_inqcP7AFUH-I3iyzkfAtazs5hV-xaMy-aukdthL_S8lgBUWLGFGhvHqMVjjHhRz-aPyk6uw

Grahame Grieve (Sep 20 2017 at 22:49):

fixed...

Pascal Pfiffner (Sep 20 2017 at 22:50):

One of you has figured out how to override my Zulip pref of not sending desktop notifications – I'm getting them for messages in this thread only!

Grahame Grieve (Sep 20 2017 at 22:50):

... you have been pwned

Pascal Pfiffner (Sep 20 2017 at 22:51):

UNPLUG UNPLUG

Grahame Grieve (Sep 20 2017 at 22:51):

more seriously you can set that in a per stream level yourself

Pascal Pfiffner (Sep 20 2017 at 22:52):

That's what I'm saying – I've never opted in to notifications (except PMs) but I'm getting them for this stream, without touching anything

Kevin Shekleton (Sep 20 2017 at 23:02):

@Grahame Grieve - The new JWT you posted looks much better. The expvalue though is set to Friday, September 22, 2017 8:48:36 AM GMT. Per the current draft, the exp "MUST be no more than five minutes in the future."

Kevin Shekleton (Sep 20 2017 at 23:03):

@Pascal Pfiffner - Maybe someone defaulted your notifications for the #smart stream back when you worked on the SMART team?

Pascal Pfiffner (Sep 20 2017 at 23:04):

Maybe. Bastards!!
It was indeed checked, no idea why, unchecked now. :)

Grahame Grieve (Sep 20 2017 at 23:10):

I missed that about exp. why does that rule exist?

Grahame Grieve (Sep 20 2017 at 23:13):

reading further into the spec:
required scope is "system/CommunicationRequest.write (which allows the app to generate alerts for clinical users)" - why must a backend services server - a spec useful for all sorts of reasons - have clinical users, let alone let any client communicate with them?

Kevin Shekleton (Sep 20 2017 at 23:50):

A short lived exp allows issuers to rotate their keys on a frequent basis. Given that our JWTs in this scenario are transient, making them short lived makes sense.

The exp is also useful for mitigating replay attacks. While the jti serves this purpose explicitly, it also requires clients to maintain a cache of known jti values it has encountered. While this is recommended, I'm sure many clients will not keep this type of state. In this case, the exp is an easy check to prevent any replays after the short lived window.

Grahame Grieve (Sep 20 2017 at 23:51):

I understand why it might be good to rotate keys. enforcing this by sealing the exp on JWT seems... very round about.

Grahame Grieve (Sep 20 2017 at 23:52):

your second paragraph... why do clients need to maintain a cache of their own jti values?

Kevin Shekleton (Sep 20 2017 at 23:54):

How else would clients know if they have seen a previous jti (nonce) value?

Kevin Shekleton (Sep 20 2017 at 23:54):

The purpose of the jti is so that a JWT can only be claimed once by the intended client

Kevin Shekleton (Sep 20 2017 at 23:56):

In order to enforce that, the client must record the jtiwhen it validates the JWT. If it sees another JWT with the same jti, then it should reject it since an attacker is attempting to replay the JWT

Grahame Grieve (Sep 20 2017 at 23:56):

but clients create the jti value... that's why I'm not sure what you mean

Kevin Shekleton (Sep 20 2017 at 23:56):

The issuer creates the JWT (and thus jti)

Kevin Shekleton (Sep 20 2017 at 23:57):

When I say "client" I'm referring to the entity receiving the JWT and the entity identified by the client_id (sub)

Grahame Grieve (Sep 20 2017 at 23:57):

doesn't the server receive the JWT?

Kevin Shekleton (Sep 20 2017 at 23:57):

In this diagram on the backend services draft page, it is the "App"

Grahame Grieve (Sep 20 2017 at 23:57):

and the App (the client) creates the JWT

Kevin Shekleton (Sep 20 2017 at 23:58):

Arg...wait...

Kevin Shekleton (Sep 20 2017 at 23:58):

My bad

Kevin Shekleton (Sep 20 2017 at 23:58):

I had this flipped (I was thinking CDS Hooks)

Kevin Shekleton (Sep 20 2017 at 23:58):

You are correct

Grahame Grieve (Sep 20 2017 at 23:59):

ok. so the server has to prevent replay attacks. that's obvious, but not stated. another pull request on the way...

Kevin Shekleton (Sep 20 2017 at 23:59):

So everything where I said the client needs to verify the JWT, replace that with the EHR :-)

Grahame Grieve (Sep 21 2017 at 00:03):

setting key expiry to <5 minutes means the clocks have to be correct... I always prefer to be >1 hour, given timezone pecularities...

Grahame Grieve (Sep 21 2017 at 00:03):

why I defaulted to 24 hours, even though I would never actually reuse it

Kevin Shekleton (Sep 21 2017 at 00:08):

I agree that 5min is too short since the current proposal is requiring the server + ehr to have clock consistency

Grahame Grieve (Sep 21 2017 at 00:08):

so... 2 hours?

Kevin Shekleton (Sep 21 2017 at 00:10):

We need to add an iat claim to the JWT. This would prevent any clock skew

Kevin Shekleton (Sep 21 2017 at 00:10):

iat is issued at time (seconds since epoch). This is the time from the server and will be consistent with the exp. The EHR can then compare exp to iat. (We use this in CDS Hooks)

Kevin Shekleton (Sep 21 2017 at 00:11):

Wait, no.

Kevin Shekleton (Sep 21 2017 at 00:11):

I need more sleep :)

Kevin Shekleton (Sep 21 2017 at 00:12):

Yes, the exp value needs to be longer than 5min. 2 hours seems like too long still. 15 minutes?

Grahame Grieve (Sep 21 2017 at 00:16):

well, if we say that the servers have to do offset from iat, then it doesn't have to be long... but, really, doesn't that do away with the supposed security advantage of a short exp?

Kevin Shekleton (Sep 21 2017 at 00:22):

It doesnt..that's what my "wait, no" comment was referring to

Kevin Shekleton (Sep 21 2017 at 00:25):

The use of exp requires the clock of the server and EHR to be in sync. iat doesn't help prevent this

Grahame Grieve (Sep 21 2017 at 00:35):

so, where does this end up then? iat doesn't really help. exp is still too short to be robust against clock deviations. timezone associated deviations can be +/- 1 hour... so an exp window of +/- 1 hour + a few minutes, and servers mandated to track jti for 24 hours... no replay attacks, and robust against clock variations

Kevin Shekleton (Sep 21 2017 at 00:43):

Clock skew shouldn't be in hours, right? Timezone differences should affect any skew since both the server and EHR should be looking at the UTC time, right?

Grahame Grieve (Sep 21 2017 at 00:48):

hmm. yes lets assume that whether timezones changes are wrong or not, servers will correct to UTC internally consistently. (though my implementation may not in the microseconds around the change)

Grahame Grieve (Sep 21 2017 at 00:51):

perhaps 5min does it . https://serverfault.com/questions/394967/what-is-a-realistic-average-time-difference-between-servers-in-the-same-lan

Josh Mandel (Sep 21 2017 at 01:39):

I think 5min is a pretty reasonable recommendation. It requires that machines really do synchronize their clocks to a timeserver, but it doesn't require any heroics.

John Moehrke (Sep 21 2017 at 14:32):

Timeout should not be mandated in SMART.. guidelines as recommendations are useful for initial implementers. But actual timeouts used should be in the hands of the specific environment. This allows some systems that have high trust, to be less chatty... while others, in very unstable environments, to be more conservative. Thus risk drives actual. Yes, include useful guidance, but don't mandate it.

Grahame Grieve (Sep 21 2017 at 19:04):

the goal here is very specific: ensure that the tokens are single use

Grahame Grieve (Sep 22 2017 at 07:42):

Now that I've fully implemented the backend services spec, I don't really see that it has any value. Say we compare to it to a baseline which is a server that uses SSL+basic Authentication (username/password). What attack vectors does the backend services protocol close down that the simple baseline doesn't?

Grahame Grieve (Sep 22 2017 at 07:46):

and I can't see what it is. If someone can break into the client and get the username/password, they can break into the client and get the privatekey/issuer. then they can impersonate the client

Grahame Grieve (Sep 22 2017 at 07:46):

except that if they can MITM the SSL, they very likely to be able to keep doing that

Grahame Grieve (Sep 22 2017 at 07:46):

ok, true, if someone can MITM the SSL, then they can impersonate the baseline client indefinitely, where as with the backend services spec, they can only do so for the length of the session .. that is, 15 min

Grahame Grieve (Sep 22 2017 at 07:46):

because given the increased complexity, it better be something really good...

Grahame Grieve (Sep 22 2017 at 07:48):

somehow those are all out of order for me

Grahame Grieve (Sep 22 2017 at 11:55):

read them by the clock, not their literal order...

Josh Mandel (Sep 22 2017 at 13:44):

The backend services spec just provides whatever value you think there is in using asymmetric secrets (as opposed to symmetric secrets). No more or less IMO.

Josh Mandel (Sep 22 2017 at 13:45):

Say we compare to it to a baseline which is a server that uses SSL+basic Authentication (username/password).

@Grahame Grieve do you mean basic Auth on an OAuth "token" endpoint?

Josh Mandel (Sep 22 2017 at 13:59):

The general protections that asymmetric access provides: clients don't need to be worried about a hacked server leaking their credentials; clients don't need to be worried about getting "tricked" into revealing a secret to the wrong party (because they never reveal secrets and every authentication JWT has a built-in audience); clients can manage rotation of their own secrets as-needed; clients don't need to manage a store with multiple secrets (one per EHR)

John Moehrke (Sep 22 2017 at 14:31):

using SSL + Basic auth (username/password) is bad because of the password management. backend passwords then to be static, static passwords are bad. It is, a 'shared secret', not an asymmetric authentication. Using Mutual-Auth-TLS enables use of Public/Private key authentication, with opportunity for revocation management. These certificates can be issued for very long periods of time (2-10 years), thus limiting the management. Where a breach would update revocation (CRL or OCSP). Why not using mutal-auth-TLS?

Jenni Syed (Sep 22 2017 at 17:36):

@John Moehrke the existing spec is asymmetric, it's just not using certs. I don't think we want true mutual TLS for this (not that network layer). If you're saying you want more of a cert trust model, that's different. But still asymmetric auth.

John Moehrke (Sep 22 2017 at 17:48):

My basic first question is indeed, why not mutual-auth-TLS for backend-to-backend... Yes, not using OAuth at all... I am not against OAuth for this, but I first want to understand why TLS is not recommended. And I think that TLS has precedent and advantages. OAuth is indeed better in some cases, I am not against it. Just think that it is legitimate solution for backend-to-backend, especially for long-term relationships.

Jenni Syed (Sep 22 2017 at 18:35):

Mutual TLS isn't exactly easy to configure, first. (this isn't backend to backend - the fhir server is usually a "front end" thing). It's not 1:1, it's 1:many from FHIR's perspective

Jenni Syed (Sep 22 2017 at 18:35):

and not everything that connects to the fhir server will use this - SMART apps use the same endpoint

Jenni Syed (Sep 22 2017 at 18:38):

Also, it's nice to have something that can be passed throught the stack to prove original identity of caller, if needed (auditing/security logging/etc in non-FHIR based systems)

John Moehrke (Sep 22 2017 at 18:54):

I agree with those points.. and have pointed it out https://healthcaresecprivacy.blogspot.com/2016/11/is-iua-oauth-useful-in-service-to.html... They are good points, but not terminal points. Some backends are backend-to-backend and would be easier to configure TLS... Hence why I asked where the differentiation was.

Grahame Grieve (Sep 22 2017 at 21:02):

comments:

• ok I didn't consider the server being hacked.
• Mutual TLS might not be easy to configure but it's a walk in the park compared to implementing this
• I'm not sure this counts as truly asymmetric when the server doesn't have to provide cyrpto proof of identity to the client. Not that I really want to do that too
• I agree that this makes it easier for OAuth and services clients to use the same end-points than mutual TLS - though you could set up mutual TLS just for special token end-point

Grahame Grieve (Sep 22 2017 at 21:04):

I think the backend services spec should have a section that discusses 'why not mutual TLS'. And no, I'm not doing a PR for that because I don't know what it should say

Brian Postlethwaite (Sep 25 2017 at 04:15):

Debugging that JWT, you can use this great site https://jwt.io/
Does the extract and validate ;)

David Keith (Nov 15 2017 at 22:34):

Working in the EDIS space for decades, we're having a hard time understanding why backend services need this complex auth scheme for inter-HCF(Health Care Facility) communication?

Our system exchanges pt related data i.e. drugs, labs, prescriptions,allergies, many others with other vendor's systems within the same secure network within the hospital/UCF/FSED.

We pre-coordinate everything, including IP Addresses, protocols, message formats, any auth if necessary. This is important because when two backend systems communicate, it's an open pipe 24/7/365; continuous data interchange interfaces.

None of the recommendations here even make sense in a backend interface B2B inter-HCF environment.
The only relevant application for this that I can see is for net-to-net interchanges i.e. cloud etc.

This is the way the major players in the industry have exchanged data since digital data exchange began.

I can understand perhaps securing the pipe; although it's redundant in a secure inter-facility network.

When we need to communicate outside the facility, we either send a DIRECT message, or establish a VPN connection prior to send.

John Moehrke (Nov 15 2017 at 23:05):

SMART is a security layer that is being developed in HL7, informed by Argonaut. It is NOT a mandate for FHIR. The Security WG has been very careful to support and encourage security/privacy layers, while not mandating any one specific. We ask only that the Risks to Privacy and Security are managed. You have described a way of doing this.

John Moehrke (Nov 15 2017 at 23:06):

That said, I do think that using SMART does make sense for backends... It is an alternative and you might find it is a harder alternative to using more blunt security solutions.

John Moehrke (Nov 15 2017 at 23:07):

I usually need to defend SMART in a different way... see https://healthcaresecprivacy.blogspot.com/2017/04/fhir-security-model-is-enterprise.html

John Moehrke (Nov 15 2017 at 23:08):

You might find the OAuth specification from IHE more helpful for organization-to-organization https://healthcaresecprivacy.blogspot.com/2016/11/is-iua-oauth-useful-in-service-to.html

John Moehrke (Nov 15 2017 at 23:10):

and there are possibility to just use a organization-to-organization tunnel (such as Mutually-Authenticated-TLS)

John Moehrke (Nov 15 2017 at 23:10):

I have more blog articles at https://healthcaresecprivacy.blogspot.com/p/fhir.html

David Keith (Nov 15 2017 at 23:50):

Your treatise on using SSH is interesting... although I make my living in the Windows world I prefer to work with Linux where possible. I have set up SSH tunnels using.... RSA, I think, for scripted transfer of files. It's a very viable option, even on windows with plink... it's just that too few windows techs are familiar with the tech or are willing to set something up.

In all fairness I must point out that establishing the comm link using cert exchange can often take a few seconds. In a high volume messaging environment you either have to batch your messages in a store-and-forward mechanism (which adds complexity to the coding process) or auth for each message, which has the potential to slow down message transfer. This can be a show stopper in a high volume environment.

Still, having worked with and programmed SSH systems in times past it seems like a quite logical choice if implemented properly. Very simple to implement, and completely secure...

Josh Mandel (Nov 15 2017 at 23:57):

I think the details of what guarantees we want/need in the SMART backend services API are still up for discussion -- that's why we're running a Connectathon track in January on Bulk Data, which will give implementers and opportunity to try out the specifications and share their experience.

Josh Mandel (Nov 16 2017 at 00:05):

@David Keith it sounds like your use case may not be a good fit for the SMART backend services specification (which is separate from the question I raised above about whether the SMART spec is more complex than it needs to be). From the perspective of security design, i would also love to get your take on on the principle that internal services should be secured as though they were public. For example https://research.google.com/pubs/pub43231.html is one example embodying this principle.

David Keith (Nov 16 2017 at 00:14):

It's really not. The problem is we as an EDIS are a 'little fish', swimming in a big HIS-centric pond for most of our installations are often subservient to the larger system vendors' approaches; if HIS says proprietary, it's proprietary. If HL7v2 with proprietary mods, so it is. Secure, we must use their designated security protocols.

That's why the smart solutions, which seem to make a lot of sense for individual pt's and clinicians, really don't work in the interface world. But if this is the only approach that an HIS vendor sees as valid due to it being pushed as the optimal or preferred 'standard', we may have to go through a clunky, man hour intensive process to implement this, only to later on down the road go through a remake when everyone figures out that this approach doesn't fit the requirement.

I've had to do this several times, very frustrating as it diverts programming man hours away from far more important tasks.

I'll take a look at your reference and respond.

John Moehrke (Nov 16 2017 at 15:01):

I feel I need to clarify my position. I am very much a supporter of SMART. I like it, I think it is a good-enough minimally-viable approach that hits a very large percentage of the need. I am however very much a supporter of other specific specifications. Specific as in as detailed as SMART will be. Specific in that they define their intended use-case and scope, as SMART will have. We should work toward a small set of reasonable security models. Each of these should be well defined and have clear identifier, so that they can be discovered. This pluggable security layers is the model that is in http, OAuth, and other security layers.

David Keith (Nov 16 2017 at 20:02):

@Josh Mandel
Google's security implementation is quite impressive. It represents the utilization of existing technologies, many of which have been around for decades, in a functional way to manage security risk.
Having served in IT Management, Network Engineering, Network Administration, Trading Floor Support, and for the last 15+ years as a business s/w developer - 9 years of which have been in support of Healthcare s/w in the hospital ED, and having worked in consulting and full time positions for over 25 businesses, I look at the Google infrastructure as it relates to security simply as '...the way it can be...'.
Meaning, NASA codes at CMM level 5, IBM consulting at CMM level 3, and the vast majority of the world at CMM level.... -1.

The vast majority of businesses - most certainly including the wild, wild west of HIT - may in some isolated instances hit the 'Google-level' of security in 20-30 years.

In the meantime, instead of following the current healthcare standards committee trend of capitalizing on LCD(least common denominator) tech with extremely complex system schemas like OAuth2, HIT needs to discover the capabilities of the OS'es, routers and layer 3 switches that already exist in their current infrastructure.

Likewise, instead of using s/w development tech like MUMPS, CCL, Java, various scripting languages and other inherently insecure tool chains, then trying to work around the insecurities by using Rube Goldberg contraptions like OAuth2, vendors need to get serious about development using tools that have consistently had access to industrial grade security for decades like C++ and Delphi.

The problems that well meaning folks are trying to solve in healthcare - like security, for ex. - were solved decades ago in some cases by tech like the multi-tier stacks available to developers today from companies like AstaTech, RemObjects, Components4Developers (kbmMW), and the various encryption stacks that have been available since the mid '90's in many cases.

Instead of continually seeking to reinvent the wheel, why not learn from Google and other's that are serious about tech security using known secure methods.

In other words instead of trying to make inherently insecure platforms secure - now that we've all been refocused on the need for securing PHI/PII as should have always been the focus, thanks to ransomware attacks on hospitals and other businesses - lets identify those s/w development approaches that are hard to secure and blacklist their use in areas where tight security is paramount.

The current trend seems to be headed in a direction that is bleeding edge for the sake of protecting bad approaches to the implementation of technology in healthcare, when we've had the tech available to us all along to avoid these pitfalls and secure our systems via the use of severely underused technologies that have existed for decades.

Kevin Mayfield (Dec 11 2017 at 10:07):

Am I correct in believing the Backend Services isn't one of the 5 Argonaut Use cases?

Grahame Grieve (Jun 12 2018 at 22:58):

@Josh Mandel @Dan Gottlieb can we please document in the back end services specification that if the client that is connecting to a server using back end services spec is acting on behalf of a human user, they should identify the user to the back end server with an openid token

Grahame Grieve (Jun 12 2018 at 22:58):

this is a question that has come up in multiple contexts for me

Grahame Grieve (Jun 12 2018 at 22:59):

and they should do that on each request.

Dan Gottlieb (Jun 13 2018 at 16:23):

I opened an issue here: https://github.com/smart-on-fhir/fhir-bulk-data-docs/issues/44

Debbie Bucci (Jun 29 2018 at 17:31):

Hi folks - I am not sure where to post but I am curious about the both the bulk upload and backend security pieces and wanted to dig deeper to better understand. I've been following the open API banking spec development very closely and they are suggesting the use of the bearer token in the browser (redirect) is unsafe. Instead of using additional client side certificate (which I think Graham was suggesting for bulk update) they are strongly suggesting MTLS bound with an access token so you can be certain of source address verification. MTLS for OAUTH is in draft - other parts of the spec are moving ahead at a quick pace. When listening to all of this it struck a chord and just wanted to put it out there for consideration.

Debbie Bucci (Jun 29 2018 at 17:35):

https://tools.ietf.org/id/draft-ietf-oauth-mtls-07.html Not sure this is most current but its close - and reading above - it seems MTLS is being consider ... do hope this is helpful

Josh Mandel (Jun 29 2018 at 17:44):

Thanks @Debbie Bucci . #bulk data is where that discussion is happening. (Briefly: For back-end services we use Bearer tokens that have short life times and are not exposed to end-users. Obtaining a bear token requires the client to demonstrate possession of a private key.)

Debbie Bucci (Jun 29 2018 at 18:27):

product key? the client ID given a registration?

Josh Mandel (Jun 29 2018 at 18:28):

Typo -- fixed ("private key")

Debbie Bucci (Jun 29 2018 at 18:28):

Ok thanks makes sense now

Last updated: Apr 12 2022 at 19:14 UTC