<div dir="ltr">Please see one new comment inline as AG> toward the end.<br><div><br>On Saturday, June 27, 2015, Debbie Bucci <<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Comments inline<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 6:17 PM, Adrian Gropper <span dir="ltr"><<a>agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div>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."<br><br></div>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:<br><br></div>1 - Apple and the Hospital must be federated so that the EHR accepts my Apple credential on the Public API. <br></div></div></div></div></div></div></div></blockquote><div><br></div><div>Assumption: Hospital will accept multiple external credentials including the (assumed) token generated by fingerprint sensor.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><br></div>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. <br> <br></div><div style="margin-left:40px">2a - I have a backup credential like a password or a FIDO token that also provides access to the Hospital Public API.<br><br></div><div style="margin-left:40px">2b - I have an in-person relationship with the Hospital and they have a photo or fingerprints on file when I show up.<br><br></div><div style="margin-left:40px">2c - Both 2a and 2b<br></div></div></div></div></div></div></blockquote><div><br></div><div>Assumption: Backup procedures are set in place at time of the *binding ceremony* <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div style="margin-left:40px"></div><br></div>A - Are there any other choices? <br></div></div></div></div></blockquote><div><br></div><div>Dont think so - I think backup credential/process covers it <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br>B - Does it matter to the Public API if Apple is the PHR and Verizon is the IDP that accepts the Apple credential?<br></div></div></div></div></blockquote><div><br></div><div>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 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br></div>C - What changes in the Public API if Apple offers me an UMA Authorization Server as a HealthKit app?</div></div></div></blockquote><div><br></div><div>Would the changes only occur when Public API is a client or does adding UMA change all flows? <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br></div>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")?<br></div></div></blockquote><div><br></div><div>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? <br></div></div></div></div></div></blockquote><div><br></div><div>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?<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.<br></div><div><br></div>Adrian<br><div><div><div><br><div><div><div style="margin-left:40px"><br></div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 18, 2015 at 2:50 PM, Kinsley, William <span dir="ltr"><<a>BKinsley@nextgen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="white" link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a">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. </span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a"> </span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a">Specifically I wanted to address three points:</span></p>
<p style="margin-left:.75in">
<span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a"><span>1)<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a">There are two different RP where one is designated by Alice as her single point of truth for her medical record.</span></p>
<p style="margin-left:.75in">
<span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a"><span>2)<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a">Each system has implemented different levels of:</span></p>
<p style="margin-left:1.25in">
<span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a"><span>a.<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a">Identity Proofing.</span></p>
<p style="margin-left:1.25in">
<span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a"><span>b.<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a">Identity Verification.</span></p>
<p style="margin-left:1.25in">
<span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a"><span>c.<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a">Credentialing and Authentication.</span></p>
<p style="margin-left:.75in">
<span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a"><span>3)<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a">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).</span></p>
<p style="margin-left:1.25in">
<span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a"><span>a.<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a">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).</span></p>
<p style="margin-left:1.25in">
<span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a"><span>b.<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a">Allow the PCP’s system to authenticate Alice using her stronger two factor credential and authentication process provided by her PHR system.</span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a"> </span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:14.0pt;font-family:"Cambria",serif;color:#44546a">Bill</span></p><div><div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><div><div><div><div>
</div><br></div></div></div></div></blockquote></blockquote></div></div></div></div><br></blockquote></div></div></div></div></div></div></div></div></div></div></div></div></blockquote></div><br></div></div></div>
</blockquote>
</div></div>