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

[Eve Maler]

"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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150113/28b9ac90/attachment.html>