[Openid-specs-heart] AS authentication

Glen Marshall [SRS] gfm at securityrs.com
Wed May 4 14:17:26 UTC 2016


In this time of mandated e-prescribing, I expect that any caregiver with the ability to order/prescribe would already have an electronic identity credential with metadata that states his prescribing authorities.  I’m thinking of something analogous to X.509-2000 attribute certificates, where the granting authorities can be authenticated in order to prevent fraud.  Such identity credentials should also be available for non-physician licensed practitioners, e.g., dentists, NPs, chiropractors, clinical psychologists, first responders, etc.   I’d prefer that sort of identity plus professional credentials to the more general OpenID credential like one gets from having a Google account, especially if I’m granting permission to a person to create, view, or share my clinical data.

From a personal perspective, I want my clinical data arising from my PCP, dentists, drugstore-based clinics, and massage therapy to be shared among all care-providers.  And, if needed, I want first responders to be included in that group.  Maybe that’s utopian today, but it is not unreasonable.

However, a more robust federated professional identity infrastructure is an obviously large and expensive operational burden.  I am keenly interested in best practices as well as viable economic models for it.


Glen F. Marshall
Consultant
Security Risk Solutions, Inc.
698 Fishermans Bend
Mount Pleasant, SC 29464
Tel: (610) 644-2452
Mobile: (610) 613-3084
gfm at securityrs.com
www.SecurityRiskSolutions.com<http://www.securityrisksolutions.com/>

From: Debbie Bucci [mailto:debbucci at gmail.com]
Sent: Wednesday, May 4, 2016 05:40
To: Adrian Gropper <agropper at healthurl.com>
Cc: openid-specs-heart at lists.openid.net; Glen Marshall [SRS] <gfm at securityrs.com>
Subject: Re: [Openid-specs-heart] AS authentication


Open service(s)  available that contains the information and metadata that would enable a service to whitelist and/or methods to  dynamically add new oidc provider information on the fly  is exactly what is needed imo.

If I grant access to Dr Bob's office to access my PHR it seems quite ok to me to accept a credential that Bob is already using for his everyday activities.

It wasn't obvious to me while glancing through the dynamic registration spec (s) ,in which folks  on this list were actively engaged/credited in developing , cover these issue.  We learned early on that many the specs assume some info is already in hand.

Lessons learned -  running a federation definately (!) ;  eased the burden on the researcher or consumer for easy access  but put a huge burden on operations.

If there are already best practices and techniques in place to handle Metadata and key management  then we should point to it.  If not I think it's in scope to address some of these painpoints.

I glanced at the spec but it's not obvious to me if any of that is there.
On May 4, 2016 12:05 AM, "Adrian Gropper" <agropper at healthurl.com<mailto:agropper at healthurl.com>> wrote:
I don't see any problem here.

The use of OpenID Connect as a recommended standard for provider authentication at the AS seems obvious and uncontroversial.
Every AS (be it institutional or patient-owned) can choose which ID providers to white-list as an OIDC IdP..
Every RS can choose to provide OIDC IdP services to the ASs that patients introduce.
A state medical society or HIE can choose to operate an OIDC IdP for their members. In MA, we actually have funding for such a project at the medical society waiting for HEART and related standards to make that practical.
Dynamic OIDC Client registration should be required by HEART to make it easy for all AS to participate.

Adrian

On Tue, May 3, 2016 at 10:05 AM, Debbie Bucci <debbucci at gmail.com<mailto:debbucci at gmail.com>> wrote:
I was actually focused on the authentication burden by the providers that will want/need to support their patient/consumers.

We had discussed a webfinger like flow to enable discover consumer resources as part of the introduction piece ...which in turn may indeed be an OIDC provider-AS for the consumer.




On Tue, May 3, 2016 at 9:49 AM, Glen Marshall [SRS] <gfm at securityrs.com<mailto:gfm at securityrs.com>> wrote:
Debbie,

I share your concern.  A secure AS registry infrastructure is needed for multiple AS instances, especially at scale.

  I am very leery of the business case for them.  In particular, what financial burden should the patients/subjects take-on for the AS(s) they choose, and how does the consumer evaluate AS product offerings?  Also, since the chosen AS URIs can be used to help re-identify patients, we probably need a scheme to pseudonymize them in shared patient EHR & PHR data.

Glen

Glen F. Marshall
Consultant
Security Risk Solutions, Inc.
698 Fishermans Bend
Mount Pleasant, SC 29464
Tel: (610) 644-2452<tel:%28610%29%20644-2452>
Mobile: (610) 613-3084<tel:%28610%29%20613-3084>
gfm at securityrs.com<mailto:gfm at securityrs.com>
www.SecurityRiskSolutions.com<http://www.securityrisksolutions.com/>

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net<mailto:openid-specs-heart-bounces at lists.openid.net>] On Behalf Of Debbie Bucci
Sent: Tuesday, May 3, 2016 09:37
To: openid-specs-heart at lists.openid.net<mailto:openid-specs-heart at lists.openid.net>
Subject: [Openid-specs-heart] AS authentication


Are there a methods to register additional OIDC Providers as part of the dynamic client registration "dance" or open multiprotocol (sambits ?) registries  in place today  where OIDC providers can register in advance to aide these type of interactions?

The thought of a provider (or researcher) having to authenticate to potentially hundreds of [UMA] AS  is worrisome and seems unmanageable at scale.

Perhaps I'm missing something ...




_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net<mailto:Openid-specs-heart at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-heart



--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160504/79b1befd/attachment.html>


More information about the Openid-specs-heart mailing list