[Openid-specs-heart] Draft HEART Meeting Notes 2016-01-25
sarah at engageidentity.com
Mon Jan 25 22:15:46 UTC 2016
Danny van Leeuwen
Eve’s API Task Force Testimony
Eve will be testifying tomorrow:
Her written contribution is here:
There’s tension around accessibility vs. security. APIs are more properly
called communication protocols, and they require access control for many
different reasons. You can’t charge for an API if you can’t control access.
It might be interesting to talk about data tagging. You want to catch the
provenance of the data before it is created. One way to do that is to tag
the device that’s generating the data. It’s kind of like an identity
attribute for a device. tagging the data when it’s static is too late.
There are several motivations for standardizing API semantics: squeeze out
complexity, join data, get better vetting, give more buy vs build choice.
Adrian’s API Task Force Testimony
Adrian will be testifying on Thursday:
His written contribution was sent to the list.
BlueButton on FHIR is Medicare’s pilot with Mark Scrimshire at the helm.
It’s taking a copy of the medicare claims database. The issue of access
management has already been dealth with and in production. What is being
piloted is how to translate that into FHIR. It’s patient-level, read-only.
what do you mean by “encryption design of UMA, HEART, and FHIR”? What are
the security gaps you’re talking about?
I just mean the flows. We’re pretty clear on the scalability issues around
them. Going from that clarity to UMA in this API economy is not at all
clear. It’s all new. This is the same thing we’ve been talking about on the
list. So where does that leave us?
HEART isn’t an encryption solution, so let’s keep building it the way we’ve
been building it.
I agree with Justin. Encryption has a specific meaning technically.
Okay, I’m talking about protection, not encryption. So, what does this tell
us about FHIR?
Access and choice are fundamental tenants that need to be enabled, which is
the goal of the HEART working group?
Can we use the HIPAA definitions of choice for HEART?
I’ve been looking at the OCR guidance. I’m using it for the patient-choice
project. I think it’s valuable. It spells things out clearly.
There’s a specification for allowing third party access without the patient
having to see or decrypt the data going from the resource server to the
client. The piece of guidance that’s missing is an interpretation on the
part of OCR is that if the patient provides a public key in person to the
resource server whether that is considered to be equivalent to the patient
providing a USB fob or an email address.
Yeah, but FHA has a workgroup that has all the agencies involved in this
questions. Other agencies have higher requirements than are required in
HIPAA. They are working on the ability of the patient to wave
Yes, but that’s institution-to-institution access. Is that the same FHIR as
It’s the same FHIR, but it’s not the same part of FHIR, and it works
Wouldn’t the policies be different? In terms of certificates, and levels of
assurance and content?
Right, and once we have a consensus on that, HEART becomes an exercise in
protection design. I don’t know if UMA 1.0.1 has a gap with respect to this
or not. With respect to MITREid Connect, I’ve been lead to believe that the
AS cannot be decoupled from the resource server in the current version, so
the AS cannot be made independent.
That is incorrect. You can decouple the AS from the RS from the requesting
party from the IdP. All of those can be in separate security domains. What
doesn’t work is trying to do a webfinger lookup on a server that’s not
hosted on the same domain.
I think we can work through this. I’m not sure who else is using MITREid
Connect in healthcare.
Everyone who is using SMART.
Has anyone separated an RS from an AS?
We haven’t tried to do that. It hasn’t been a system requirement as yet.
SMART is only an OAuth/OIDC server. UMA was put in to support the Privacy
on FHIR work last year. It is still a very bare and focused implementation.
Can MITREid Connect support federated IdPs? Can you webfinger to the
It IS an IdP, and it’s meant to be a federated IdP. You can webfinger into
it if you set it up on the domain correctly. HealthAuth.org works for a
webfinger lookup of Alice at HealthAuth.org.
It sounds like my developer and I are the only people who are trying to do
a separated AS from IdP.
Are you trying to stand up an AS that accepts multiple IdPs?
Are you talking about logging in as the requesting party or the resource
The requesting party
These capabilities are in scope for the HEART specification. This might be
a more appropriate subject for the UMA list and UMA call.
Well, I’d like to do it in BlueButton on FHIR.
Well, you’re doing something no one has ever done before, so I’m not sure
anyone can help you. UMA is a technical specification for a communications
protocol. You can put whatever features you want into your software. The
standards community isn’t obliged to help you do that.
The CMS BlueButton on FHIR needs to outline what they’re doing and what
standards they’re supporting.
Take some time if you can to call into the API Task Force meeting tomorrow.
I’m on the committee for this hearing, so please send me any questions. The
hearing probably won’t take all five hours.
The security profiles are coming up for a vote very soon. Please read
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-heart