[Openid-specs-heart] Use Case A - Digital identity of the patient acceptable to the VA

Adrian Gropper agropper at healthurl.com
Tue Jan 13 17:13:11 UTC 2015


My question is not about weak authentication. It's about layering of
specifications, data minimization, and avoiding a compromise between
security and privacy.

To that end, the scope of Alice's sovereign technology can include:

   - a secure element (e.g. FIDO U2F) that can sign a challenge and carries
   an unserialized certificate describing its capabilities. An apple iPhone
   has the same capability but it is not exposed in a standard or open way yet.
   - an UMA Authorization server that Alice has built from open source

In healthcare, the base use-case does not require federation or identity
proofing. HIPAA allows a patient "known to the practice" to be treated and
connected without external identity verification. Alice can bring her U2F
and to practice A where they make a biometric record of her identity (take
a photo) and register her U2F token. Alice can bring that same U2F token to
practice B and they take her fingerprints to make a record of her identity.
Neither the photo or the fingerprints ever leave practice A or practice B
for any reason. Alice has the benefit of strong security without any
compromise of privacy. The VA can meet the presidential directive requiring
2FA.

Alice now wants to authorize practice B to access her FHIR endpoint at
practice A. Alice has her U2F secure element and her home built UMA AS.
This is what I would call a zero-federation use case. Can she do that under
the profiles proposed by MITRE last week?

Adrian

On Tue, Jan 13, 2015 at 10:17 AM, Eve Maler <eve.maler at forgerock.com> wrote:

> "Alice" would be traditional... I have no problem with that if others
> don't.
>
> As for the nature/strength of the digital identity, I think we're going to
> want to seek some variability in our use cases, most particularly around
> not assuming "VA" first and foremost, so that we're not too US- or
> VA-centric. But scenarios in which Alice is strongly authenticated to some
> standard seem like a reasonable option. And obviously the VA scenario is an
> important animating one.
>
> Are there scenarios in which it's useful to enable Alice to be more weakly
> authenticated on purpose, such as where leveraging existing social logins
> is a good idea? FWIW, every EHR system I've logged into so far requires
> passwords alone (with not a lot of evidence of contextual auth that I can
> see).
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!
>
> On Mon, Jan 12, 2015 at 2:09 PM, Adrian Gropper <agropper at healthurl.com>
> wrote:
>
>> Justin,
>>
>> First and most important: I suggest we call the patient (resource owner)
>> Alice consistently in all use cases.
>>
>> Then:
>>
>> I'm checking on the definition of the patient's digital identity at the
>> VA. Can we agree that the digital identity could be based on federation
>> with an IdP or simply Alice presenting to the VA a secure element
>> manufactured (but not serialized) to an acceptable specification (e.g.:
>> FIDO Alliance U2F).
>>
>> In other words, the basis of a VA-trusted digital identity does not have
>> to be an IdP as long as the technology is sourced from a trusted vendor.
>>
>> Adrian
>>
>>
>> --
>>
>>
>>
>> _______________________________________________
>> 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/20150113/dd711618/attachment.html>


More information about the Openid-specs-heart mailing list