[Openid-specs-heart] Notification in HEART and/or UMA

Sun Jul 31 22:46:29 UTC 2016

In-line after the purple...

On Sunday, July 31, 2016, Aaron Seib, NATE <aaron.seib at nate-trust.org>
wrote:

> Thanks for responding in line.  I have added some commentary with a
> purple font.
>
>
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> [image: cid:image001.jpg at 01D10761.5BE2FE00] <http://nate-trust.org>
>
>
>
> *From:* agropper at gmail.com
> <javascript:_e(%7B%7D,'cvml','agropper at gmail.com');> [mailto:
> agropper at gmail.com <javascript:_e(%7B%7D,'cvml','agropper at gmail.com');>] *On
> Behalf Of *Adrian Gropper
> *Sent:* Sunday, July 31, 2016 2:20 PM
> *To:* Aaron Seib, NATE
> *Cc:* openid-specs-heart at lists.openid.net
> <javascript:_e(%7B%7D,'cvml','openid-specs-heart at lists.openid.net');>;
> Dixie Baker
> *Subject:* Re: [Openid-specs-heart] Notification in HEART and/or UMA
>
>
>
> Thanks, Aaron - I think you get it just fine - how we explain it may still
> be a challenge - see inline
>
>
>
> On Sun, Jul 31, 2016 at 9:50 AM, Aaron Seib, NATE <
> aaron.seib at nate-trust.org
> <javascript:_e(%7B%7D,'cvml','aaron.seib at nate-trust.org');>> wrote:
>
> Adrian,
>
>
>
> This is a very useful description of the HEART work: “HEART is all about
> giving everyone a choice of authorization server in the FHIR context.”
>
>
>
> I think it would be a great way to start a presentation about HEART that
> would provide a better understanding of what the project is about.
>
>
>
> Before we move onto the rest of the thread here – which I think is just as
> important to understanding what is being proposed - can we deconstruct the
> meaning of two components of this sentence?
>
>
>
> ·         What does it mean to ‘give everyone a choice of authorization
> server’?
>
> It means that when I begin a relationship with a service provider they
> don't expect to tell me who my email provider should be. I get to choose
> Google or an email from my college or run my own mail server and the
> service provider just has to deal with that. By giving the person the
> choice of authorization server, the service provider has to make contact in
> the Inbox that's convenient to the person. Imagine if every merchant and
> service provider could tell you where to sign-in to check your messages
> from them. Oh, this is exactly how "secure messages" from our EHRs work
> today, never mind, you don't have to imagine.
>
>
>
> I am with you.  So that we are not deluding ourselves or anyone that is
> trying to understand what this is all about would you agree that it is fair
> to say that unlike the availability of email servers Authorization servers
> are not very common?  Or is that not accurate.  They are common and we just
> don’t know that they are on every web-server in the country?  This is a
> sincere question. I don’t think if someone held a gun to my head and told
> me they were going to pull the trigger if I couldn’t tell them where my
> Authorization Server is today.
>
>
>
> If I wanted to how would I go about setting up my own Authorization server
> and how would I point people to it?  How could we make it easy for all of
> my provider’s EMR’s to discover it and use it to disclose data to me?
>
> [AG] Where is your authorization server for financial transactions? Are
there any transactions that are not accountable to you? Are there any
financial authorization servers that don't offer you notification in your
chosen in-box? Are there any limits on how much of your financial
authorizations services you can centralize in one single bank and
associated credit card account? Are there limits to what financial
authorization transactions you can centralize and control as cash in your
own wallet (there are many cash economies still around the world)?

The HEART authorization server can be as centralized and regulated as my
big bank account or as personal and jurisdiction-free as my wallet. The
services I do business with don't get to tell me which bank I can use or
what kind of wallet. The banks compete with my wallet to be my
authorization service. HEART will not succeed if it doesn't support that
"build, run, or outsource" competition to keep the regulated vendors and
outsources honest.

·         What does it mean to do so ‘in the FHIR Context’?
>
> FHIR is a standard for EHR interoperability. When a standard is available
> a service provider has the choice of using it or not. Email for example is
> an available standard but hospitals don't choose to use it even though the
> Office for Civil Rights has said unequivocally that patients have a right
> to request contact by plain insecure email. (There's still some kind of
> legal or regulatory challenge to be mounted on that front - but I digress.)
> Direct email was another standard that hospitals have chosen not to
> implement in a consumer-friendly way. Now we have the FHIR standard. We
> need to learn from our experience and the JASONs and the API Task Force and
> make sure that the FHIR implementations _can't_ discriminate between HIPAA
> covered endpoints and patient-controlled endpoints. If we make HEART work
> for patient-directed exchange and the hospitals pull another Direct
> maneuver, it needs to be obvious to the regulators and politicians.
>
>
> I am following you here too.  In the FHIR context meaning that the
> Consumer App is using the FHIR standard to support interoperability the
> same way that the EHRs are.
>
> [AG] Exactly. HEART must make any discrimination so obvious that it
becomes politically and publicly untenable.

> Next, I thought that this statement was very useful:  ‘When she (*Alice*)
> engages with a FHIR service provider as a patient Alice provides three
> pieces of information:
>
> ·         an identity
>
> ·         a notification address
>
> ·         a resource registration address
>
> I want to make sure I understand what you mean when you later describe a
> potentially ideal solution as ‘Alice to provide an identity that
> automagically links to her Notification and Authorization addresses.”
>
> If I am reading it correctly – I think you are asking if an email address
> supplied by Alice would be sufficient for the identity – I just want to
> make sure I understand the question.  If I am keeping up there would be
> some way that Alice associates this email address with her choice of
> Authorization server (that a FHIR based resource server could use to
> resolve her privacy preferences) and incidentally be where the FHIR based
> Resource Server would send notifications about the disclosures it made
> based on her privacy preferences found in the Authorization Server of her
> choice in association with the email address she chooses.
>
> Yes. It's a standard called WebFinger that is already in OpenID Connect.
> HEART can build on WebFinger. There are other identity-related standards we
> can consider if necessary.
>
>
>
> Ok – you this is another component I think – can we start from the
> position that no one outside of our tribe really understands how you could
> relate an email address to an OpenID Connect (what instance, server?).
> Somehow I give you the email address as a parameter and using WebFinger I
> can discover the other parameters I need to know about you to enable
> consumer directed exchange is all I would need.  Is WebFinger just an API –
> how does it know all this stuff?  Doesn’t there need to be a registration
> step somewhere along the line for WebFinger to discover the rest given my
> email address?
>
> [AG] Yes. You register lots of stuff like this. The US Postal Service does
this kind of stuff for you as does Google and your domain services
provider. The domain services provider is probably the best example of a
registrar that we all can use. I use Namecheap
https://www.namecheap.com/domains/registration.aspx to register personal
.xyz domains for about $1 / year and Let's Encrypt
https://letsencrypt.org/ security
certificates are free. We're spending an average of $10,000 / person / year
on healthcare in the US. If people paid 1% of that to treat their personal
information with the respect we treat our financial information, that would
be $100 / year and a $30 Billion / year US business.

> Thank you – this would be the kind of detail that I think we could share
> with a folks like NATE’s members et al.
>
> I think HEART's patient-directed exchange is a huge opportunity for may of
> NATE's members. Somebody will need to make and sell those authorization
> servers :-)
>
> There is no reason to think that some of them wouldn’t if it would help
> their users get their data in a secure privacy preserving way.  That is all
> they have ever wanted to do.
>
> [AG] Most of NATE's members seem to think that Direct rent-seeking is
where they can add value and they're poisoning the interoperability commons
for everyone. It's very sad. I still chuckle at the head privacy lawyer at
ONC, telling one of the NATE's members to give up on Direct in front of a
huge public audience in DC.

Adrian

> Adrian
>
>
>
> Aaron
>
>
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> [image: cid:image001.jpg at 01D10761.5BE2FE00] <http://nate-trust.org>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net
> <javascript:_e(%7B%7D,'cvml','openid-specs-heart-bounces at lists.openid.net');>]
> *On Behalf Of *Adrian Gropper
> *Sent:* Saturday, July 30, 2016 1:47 PM
> *To:* openid-specs-heart at lists.openid.net
> <javascript:_e(%7B%7D,'cvml','openid-specs-heart at lists.openid.net');>
> *Cc:* Dixie Baker
> *Subject:* [Openid-specs-heart] Notification in HEART and/or UMA
>
>
>
> A new thread to consider Danny's very important reminder of how HEART will
> deal with Notification.
>
> From Alice's perspective, when she engages with a FHIR service provider as
> a patient Alice provides three pieces of information:
>
> - an identity
>
> - a notification address
>
> - a resource registration address
>
> That's a lot to ask. We're all used to providing an email address as an
> identity and a notification endpoint. We're also used to the typical OAuth
> authorization screen that sometimes appears after we use a federated
> identity such as Gmail. What we're not used-to, yet, is being given a
> choice of OAuth authorization server the same way we have a choice of
> notification address. HEART is all about giving everyone a choice of
> authorization server in the FHIR context. It's the essence of being
> patient-centered and why the HEART charter says: "build, buy, or outsource"
> the AS.
>
> The ideal situation IMHO would be for Alice to provide an identity that
> automagically links to her Notification and Authorization addresses. If
> that identity is an email address, then we have a simple, voluntary, and
> well-established way to explain HEART and to bootstrap the rest of the
> patient registration or consent to health information exchange process. Is
> there any realistic alternative to email?
>
> It's not clear at this time whether UMA will add a Notification endpoint
> to the UMA spec. If it does, then HEART can just use that. If it doesn't
> then HEART will need to deal with Notification some other way. Either way,
> HEART will need to explain to FHIR resource servers how they are expected
> to bootstrap discovery of Alice's authorization server and, incidentally,
> her Notification address.
>
> Adrian
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160731/b0d64698/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160731/b0d64698/attachment.jpg>