[Openid-specs-heart] Notification in HEART and/or UMA

[Adrian Gropper]

A new thread to consider Danny's very important reminder of how HEART will
deal with Notification.

>From Alice's perspective, when she engages with a FHIR service provider as
a patient Alice provides three pieces of information:
- an identity
- a notification address
- a resource registration address

That's a lot to ask. We're all used to providing an email address as an
identity and a notification endpoint. We're also used to the typical OAuth
authorization screen that sometimes appears after we use a federated
identity such as Gmail. What we're not used-to, yet, is being given a
choice of OAuth authorization server the same way we have a choice of
notification address. HEART is all about giving everyone a choice of
authorization server in the FHIR context. It's the essence of being
patient-centered and why the HEART charter says: "build, buy, or outsource"
the AS.

The ideal situation IMHO would be for Alice to provide an identity that
automagically links to her Notification and Authorization addresses. If
that identity is an email address, then we have a simple, voluntary, and
well-established way to explain HEART and to bootstrap the rest of the
patient registration or consent to health information exchange process. Is
there any realistic alternative to email?

It's not clear at this time whether UMA will add a Notification endpoint to
the UMA spec. If it does, then HEART can just use that. If it doesn't then
HEART will need to deal with Notification some other way. Either way, HEART
will need to explain to FHIR resource servers how they are expected to
bootstrap discovery of Alice's authorization server and, incidentally, her
Notification address.

Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160730/558ee9cd/attachment.html>