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

[Debbie Bucci]

Comments inline

On Fri, Jun 26, 2015 at 6:17 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> 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 enroll my 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.
>

Assumption:  Hospital will accept multiple external credentials including
the (assumed) token generated by fingerprint sensor.

>
> 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
>

Assumption: Backup procedures are set in place at time of the *binding
ceremony*

>
> A - Are there any other choices?
>

Dont think so -  I think backup credential/process covers it

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

Not sure this concept is quite right.  I think if Hospital had determined
they will federate and accept external credentials  Public API only needs
to know the client authenticated at some level of trust/assurance

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

Would the changes only occur when Public API is a client or does adding UMA
change all flows?


>
> 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")?
>

Not sure I understand this.  The only thing that matter is the binding
between the PHR and Hospital for client interactions.   If Hospital is the
client then PHR would determine authentication requirements if PHR is the
client is the token (fingerprint sensor authentication method) still in
play?

>
> 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
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150627/918f8c5c/attachment-0001.html>