[Openid-specs-heart] Identity Federation?

Mon Aug 17 22:00:05 UTC 2015

Hi,

I’m still a little confused on the identity federation being out of scope. A comment was made today on the call to what I understood that clinical organizations would not accept outside identity systems. But I would assume if Alice had a PHR that it would be unaffiliated with a particular health care organization and therefore have its own Identity Provider. To link up the PHR and the EHR you would have to establish trust. I would have thought that using OpenID Connect or just OAuth to solve this would have been a key part of HEART. Is it out of scope just for the use case we have been discussing recently? I can understand why the proofing part would be out of scope.

And also, hi everyone. I’ve been listening for a couple of weeks but haven’t been able to actively participate. I hope to be able to contribute more going forward.

Thanks

Chad

Chad Evans
Software Architect  HealthSuite DigitalPlatform
Philips Healthcare
+1770-731-0821 (office)
+1770-330-5228 (cell)

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Eve Maler
Sent: Friday, August 14, 2015 1:16 PM
To: Danny van Leeuwen
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Identity Federation?

Hi Danny-- Identity federation is the process of a service or application, such as a website (like an EHR portal) accepting the results of user authentication having been performed by a different service (like a government eID system or a bank or the AMA, or some other trustworthy party). It's federated, vs. local, because even though the EHR portal has an account for you, they don't have to perform the login duties for that account themselves -- it comes from afar (like a federation of states or planets :-) that work together).

When people say "an identity federation", they usually mean a group of organizations that have agreed to work together under a standard agreement that lays out the responsibilities and rights of the parties. Trusting someone else to do authentication for you is a big step. If the person's identity needs to have been proofed too (what we've been talking about lately -- the mapping of someone's identity credential to a real-world person), then the trustworthiness requirements on the "identity provider" go way up. Facebook, for example, simply won't do.

Eve Maler
ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Join our ForgeRock.org OpenUMA<http://forgerock.org/openuma/> community!

On Fri, Aug 14, 2015 at 9:07 AM, Danny van Leeuwen <danny at health-hats.com<mailto:danny at health-hats.com>> wrote:
What is Identity Federation?

On Tuesday, August 11, 2015, <openid-specs-heart-request at lists.openid.net<mailto:openid-specs-heart-request at lists.openid.net>> wrote:
Send Openid-specs-heart mailing list submissions to
        openid-specs-heart at lists.openid.net<mailto:openid-specs-heart at lists.openid.net>

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.openid.net/mailman/listinfo/openid-specs-heart
or, via email, send a message with subject or body 'help' to
        openid-specs-heart-request at lists.openid.net<mailto:openid-specs-heart-request at lists.openid.net>

You can reach the person managing the list at
        openid-specs-heart-owner at lists.openid.net<mailto:openid-specs-heart-owner at lists.openid.net>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Openid-specs-heart digest..."

Today's Topics:

   1. Re: Draft HEART Meeting Notes 2015-08-10 (Aaron Seib)
   2.  Draft HEART Meeting Notes 2015-08-10 (Adrian Gropper)
   3. Re: Draft HEART Meeting Notes 2015-08-10 (Aaron Seib)

----------------------------------------------------------------------

Message: 1
Date: Tue, 11 Aug 2015 09:34:58 -0400
From: "Aaron Seib" <aaron.seib at nate-trust.org<mailto:aaron.seib at nate-trust.org>>
To: "'Adrian Gropper'" <agropper at healthurl.com<mailto:agropper at healthurl.com>>, "'Kinsley, William'"
        <BKinsley at nextgen.com<mailto:BKinsley at nextgen.com>>
Cc: openid-specs-heart at lists.openid.net<mailto:openid-specs-heart at lists.openid.net>
Subject: Re: [Openid-specs-heart] Draft HEART Meeting Notes 2015-08-10
Message-ID: <05f601d0d43a$84d61a40$8e824ec0$@nate-trust.org<http://nate-trust.org>>
Content-Type: text/plain; charset="utf-8"

I am confused or might have a friendly amendment for what you are trying to communicate.

Are you positing to the group that item (3) is out of scope because it is an Identity Federation feature and by definition not part of the charter of the HEART project?

If that is what you are saying could you please tell me who is working on enabling the inclusion of the PCP?s Identity Proofing of Alice in determining the level of assurance associated with her accounts (in any system ? PHR, EMR or the portals thereof)?

This is what I am trying to discover.  When the PCP has a patient-provider relationship established with Alice and he is provide with Alice?s URL to her AS I am very interested in how we can reuse this ID proofing event to increase the level of assurance associated with Alice?s AS.  There are many ways to remote Identity proof Alice that have cost associated with them.  If we can capture the ID Proofing event (I assume that a URL and some unique Identifier related to Alice is required in the HEART transactions when Alice has her privacy preferences configured in an AS that has multiple users) from when the PCP trust the URL/GUID associated with Alice for an AS it would create value too.

In other words ? how do we make it possible for relying parties other than Alice?s PCP to discover that her PCP has come to trust the binding of Alice?s Identity to a specific URL/ID for her AS?

Is that being discussed anywhere other than the HEART project?

Aaron Seib, CEO

@CaptBlueButton

 (o) 301-540-2311<tel:301-540-2311>

(m) 301-326-6843<tel:301-326-6843>

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150817/1888fc9f/attachment-0001.html>