<div dir="ltr">Below, with less pertinent stuff elided:<br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">







<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>New <a href="https://www.forgerock.com" target="_blank">ForgeRock Identity Platform</a> with <a href="https://www.forgerock.com/platform/user-managed-access/" target="_blank">UMA support</a> and an <a href="https://forgerock.org/openuma/" target="_blank">OpenUMA community</a>!</p></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Sat, Jan 30, 2016 at 3:01 PM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>You've lost me again. My 1 - 5 sequence had nothing to do with the strength of authentication for either the RO at the RS, the RO at the AS, or the RqP anywhere. LOA is important, and it comes into play in many places, but I don't understand how it impacts the chain between Resource Registration with an AS at one end and a successful FHIR transfer from the RS to the Client at the other.<br></div></div></div></blockquote><div><br></div><div>I didn't mention "Resource Registration"; I mentioned "onboarding/registering patients". I couldn't remember what words the WG agreed to use for when a patient first shows up at a practice vs. a service; in fact, now that I look at our <a href="https://docs.google.com/document/d/1IvbdWerdvMuA1dQ-KQvVKqIBrAas7FoenNVUtgpqYrw/edit?usp=sharing">first use case</a>, it seems we've taken out some explanatory terminology definition stuff that we used to have in there, and also mixed up our usage in a spot or two, but "registration" is supposed to be reserved for a practice and "onboarding" is supposed to for a service (such as an EHR portal). So: what I meant was "patient identity verification methods when onboarding patients to a service".</div><div><br></div><div>(In the case of actually providing many healthcare services, whether in person or something like telehealth, I wonder: is actual patient pseudonymity really practical? There's a physical body involved.)</div><div><br></div><div>Your #1-#5 process is interesting if you're considering treating biometrics as a body's "persistent username", but, at this point, fairly theoretical vs. how identity is verified today given that financial and governmental documentation is heavily relied on and biometric markers tend not to be, and your list speaks only of the "front-loaded" part, not the routine usage of any credentials. That latter part is where authentication comes in, and also where cross-service assurance leakage (e.g. UMA RS/AS, and client/RqP trust elevation) can potentially happen. LOA definitionally includes routine usage, not just credential creation.</div><div><br></div><div>Doctor IDs do matter too if they are in the position of accessing the patient's data as a requesting party.</div><div><br></div><div>(For those perhaps less technically inclined, here's a very old blog post of mine discussing <a href="http://www.xmlgrrl.com/blog/2009/12/31/how-to-rest-assured/">Levels of Assurance</a> that may be of interest. And heres the very latest version of the canonical <a href="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf">LOA specification</a>.)</div><div><br></div><div>Trying to net out some conclusions that are relentlessly practical for HEART purposes:</div><div><ul><li>Without further profiling, "raw" UMA doesn't require that Alice use the same identifier or the same authentication strength at both, say, a PHR resource server and an IRB authorization server.</li><li>The formal LOA standard defines an LOA 1-4 scale that is very rigid, and doesn't allow for pseudonymity once you enter into the levels with any good authentication strength.<br></li><li>If we wanted that for any use cases, we'd have to get creative (e.g., looking at Justin's "Vectors of Trust" standards work) to split the difference and get some of both.</li></ul></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><br></div>Please be more explicit. I know that the standards around authentication events is important and that federating IdPs and LOA may play a role for the doctors and nurses as RqPs but LOA is much less important for the patient authentication. Once again, this thread is about patient ID in the patient matching for FHIR sense. It is not directly about the doctor's ID, or is it?<span class=""><font color="#888888"><br><br></font></span></div><span class=""><font color="#888888">Adrian<br></font></span></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 30, 2016 at 4:59 PM, Eve Maler <span dir="ltr"><<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">(Removing wg-uma from this thread as not pertinent -- and anyway, I don't use my same email address/identifier for that list... :-)<div><br></div><div>Are biometrics going to become common as a standard as a patient identity verification method when onboarding/registering patients anytime soon and, further, for ongoing authentication once the patient is in the system? Both are needed for high assurance. Just yesterday, I happened to tweet this from a doctor's office...</div><div><br></div><div><a href="https://twitter.com/xmlgrrl/status/693220654611496960" target="_blank">https://twitter.com/xmlgrrl/status/693220654611496960</a><br></div><div>"OH at doctor’s office: Nurse to doctor: “Hey, I need your password again.” Why constrained delegated access needs to be easier than *that*."</div><div><br></div><div>(and actually, it was an MA, not a nurse)</div><div><br></div><div>And as I noted previously, biometrics are not the be-all/end-all of authentication, and while certain (not all) biometrics have interesting properties for uniquely <i>identifying</i> a person in the real world, many of them can also be faked by bad guys, and really should be paired with a second factor. It has been observed that "they make a better username than a password".</div><div><br></div><div>As long as various authentication methods are considered equivalently strong, this is where it could be useful to demand that "some individual" simply be able to prove they can log in to some client/RS at strength X and also to the authorization server at equivalent strength X, where it's only necessary for one side to have successfully patient-matched, and where there's a requirement for some magic patient ID to be correlatable/passed between systems if necessary to satisfy regulatory compliance issues.</div></div><div class="gmail_extra"><span><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">







<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>New <a href="https://www.forgerock.com" target="_blank">ForgeRock Identity Platform</a> with <a href="https://www.forgerock.com/platform/user-managed-access/" target="_blank">UMA support</a> and an <a href="https://forgerock.org/openuma/" target="_blank">OpenUMA community</a>!</p></div></div></div></div></div></div></div>
<br></span><div><div><div class="gmail_quote">On Sat, Jan 30, 2016 at 1:29 PM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We're back on track with "<font size="2"><span style="background-color:rgba(255,255,255,0)">Authentication strength/LOA and pairing mechanics could be a matter for HEART profiling."</span></font><div><br></div><div>The issue becomes, what is the chain of events that drives patient ID in the sense of enabling a patient-level FHIR client to access a patient-level FHIR resource?</div><div><br></div><div>1 - Although it's not the only way to build this chain, I start with "known to the practice" in the sense that a specific person's biometric can be associated with a specific primary key in either the FHIR client or FHIR resource server. There is no matching yet and the biometric, be it a photo or iris scan, is neither verified nor is it used for matching across the link.</div><div><br></div><div>2 - The patient provides an identifier to the Client FHIR endpoint that can eventually result in a match at the FHIR resource server. A persona. Depending on jurisdictional and business issues, this identifier may not be subject to any verification at all, verification to ensure correct spelling such as an email confirmation, or verification against a federated authority such as the state DMV. </div><div><br></div><div>3 - The persona identifier provided to the FHIR Client can be designed in all sorts of different ways. </div><div>     a - It could be globally unique and anonymous like a Bitcoin address. </div><div>     b - It could be globally unique and easily remembered like an email address or mobile number</div><div>     c - It could be globally unique and subject to a federation's jurisdiction like a driver's license number</div><div><br></div><div>4 - All of a, b, or c are then subject to discovery mechanics and standards such as blockchain, WebFinger or lookup in Surescripts or the state HIE. This eventually turns into an identifier that is unique to the FHIR resource server for that matching patient persona.</div><div><br></div><div>5 - The FHIR client presents to the FHIR resource server with a patient context and requests access. Hilarity and maybe more UMA ensues.</div><div><br></div><div>Somewhere between 1 and 5 we have patient and requesting party authentications, AS and client registrations, and these touch UMA and HEART more or less directly. I prefer to think of the patient's persona and her UMA AS URI being a unified and key link in his chain of events. </div><div><div><div><br></div><div>Adrian</div><div><br></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div>