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

[Adrian Gropper]

Please see one new comment inline as AG> toward the end.

On Saturday, June 27, 2015, Debbie Bucci <debbucci at gmail.com> wrote:

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

AG> Yes, the client changes within this use case and others. I don't think
that is relevant in the context of Question D. At any point in time, one
protected resource on the resource server, is concerned about only one
resource owner. That one resource owner is linked to the protected resource
in some way. For the purpose of this question D, let's focus on the
Hospital as the resource server. The Hospital has a protected resource that
is associated with one resource owner via a "link" of some sort. What is
this "link" to the patient? Is it a link to an AS? How was that link
established?


>> 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/f6cb5a1e/attachment.html>