[Openid-specs-heart] Vectors of Trust for the Public API - Was: HEART Use Case: Alice Enrolls with PCP

Fri Jun 26 22:17:18 UTC 2015

Let's assume that central intent of Bill's use case seems is to leverage
the quality of the PHR credential and the in-person identity proofing of
the EHR. For example, imagine that Apple offers me a secure PHR in
HealthKit linked to the fingerprint sensor and remote wipe feature. Apple
may or may not do identity proofing. If I lose my iPhone, I need to restore
the PHR from backup. "Apple does not see your HealthKit data."

Now that I have a PHR that I trust and a secure credential, I go to my
Hospital and say that I want to enrollmy iPhone into their Public API. The
issues are:

1 - Apple and the Hospital must be federated so that the EHR accepts my
Apple credential on the Public API.

2 - If I lose my phone or Apple forsakes me, I need to be able to access
the hospital's Public API through some other path.

2a - I have a backup credential like a password or a FIDO token that also
provides access to the Hospital Public API.

2b - I have an in-person relationship with the Hospital and they have a
photo or fingerprints on file when I show up.

2c - Both 2a and 2b

A - Are there any other choices?

B - Does it matter to the Public API if Apple is the PHR and Verizon is the
IDP that accepts the Apple credential?

C - What changes in the Public API if Apple offers me an UMA Authorization
Server as a HealthKit app?

D - What changes in the Public API if Verizon and the Hospital are part of
a trust federation and my Apple Authorization Server is completely under my
control ("Apple will not see my Authorization Server or my HealthKit data")?

Note that I've avoided use of "known to the practice" or "identity
proofing" and that I've not named any particular standards other than FIDO
which is here only as a placeholder for any cryptographically strong
pseudonym.

Adrian

On Thu, Jun 18, 2015 at 2:50 PM, Kinsley, William <BKinsley at nextgen.com>
wrote:

>  This use case specifically includes the smart phone to introduce a
> common two-factor authentication process. As Justin said earlier, this and
> all the other use cases can be used to branch off into modified versions.
>
>
>
> Specifically I wanted to address three points:
>
> 1)   There are two different RP where one is designated by Alice as her
> single point of truth for her medical record.
>
> 2)   Each system has implemented different levels of:
>
> a.      Identity Proofing.
>
> b.     Identity Verification.
>
> c.      Credentialing and Authentication.
>
> 3)   Which lead to the discussion of how the two systems (AS and RP)
> manage the trust relationship to support Alice’s ability to use single sign
> on (SSO).
>
> a.      Upgrading Alice’s weaker Identity Proofing and verification trust
> level from her PHR based on the PCP registration process (In person and
> government issued photo ID vs. simple email).
>
> b.     Allow the PCP’s system to authenticate Alice using her stronger
> two factor credential and authentication process provided by her PHR system.
>
>
>
> Bill
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Justin Richer
> *Sent:* Wednesday, June 17, 2015 8:36 AM
> *To:* Maxwell, Jeremy (OS/OCPO); Debbie Bucci
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] HEART Use Case: Alice Enrolls with PCP
>
>
>
> I think you guys are putting too much stock in this use case. Keep in mind
> that the textual description in this specific use case isn't the only way
> any of this can transpire. If the patient doesn't have a smart phone with
> them they can use the kiosk like in the original description. My workflow
> description was specifically to address the concern Sarah brought up of
> people not wanting to log in through the kiosk. Logging in to a remote IdP
> through a kiosk is already worlds better than creating a local password
> (which would be just as susceptible to shoulder surfing security cameras
> and keylogging, and likely more dangerous). But if the RP is written
> correctly, we could support this case *also*.
>
>
> Each use case is but a tiny branch of the tree of possibilities. We're
> still deciding which branches we care about and which branches we prune in
> this group.
>
>  -- Justin
>
>  On 6/17/2015 8:06 AM, Maxwell, Jeremy (OS/OCPO) wrote:
>
>  But that means 30 million Americans don't have a cell phones. What does
> the workflow look like for them?
>
> Sent from my iPhone
>
>
> On Jun 17, 2015, at 7:17 AM, Debbie Bucci <debbucci at gmail.com> wrote:
>
>
>
>
>
> On Tue, Jun 16, 2015 at 4:00 PM, Maxwell, Jeremy (OS/OCPO) <
> Jeremy.Maxwell at hhs.gov> wrote:
>
>
>
> Is a smart phone necessary for the use case work flow?  What about folks
> that don’t have smart phones?  What about folks that don’t have a cell
> phone?
>
>
>
>
>  <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
>
>  According to PEW report in 2014 90% of adults have cell phones today
> 75% of them are smartphones.  I'd say for this use case - its pretty close
> to the 80/20 rule
>
> http://www.pewinternet.org/data-trend/mobile/cell-phone-and-smartphone-ownership-demographics/
>
>
>
>
> Certainly there are issues to deal with using cell (lost, stolen,
> replaced) an even short term alternatives must be available.  What about
> use of tablets and other *mobile devices?*.   I'd dare to say that a
> significant number of those unable to use a cell phone - will have a
> delegate to stand in their stead.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>

-- 
Adrian Gropper MD
Ensure Health Information Privacy. Support Patient Privacy Rights.
*http://patientprivacyrights.org/donate-2/*
<http://patientprivacyrights.org/donate-2/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150626/322bdc0a/attachment.html>