[Openid-specs-heart] Events in UMA, FHIR, and HEART

[Sarah Squire]

Ah! That's an interesting model. Thank you for clarifying. I hadn't
considered the possibility of combining different resources to achieve
specific security goals. That might be a useful architecture to have in a
HEART context.

Sarah Squire
Engage Identity
http://engageidentity.com

On Mon, Nov 9, 2015 at 8:59 AM, Moehrke, John (GE Healthcare) <
John.Moehrke at med.ge.com> wrote:

> Hi Sarah,
>
>
>
> Fantastic review. As the co-chair in Security that covers the FHIR
> specification, I want to point out a fact that you might have missed. The
> Provenance resource can cover any other resource, and thus can cover an
> AuditEvent. You pointed out that the AuditEvent doesn’t include a
> signature, well none of the other FHIR resources include a signature. When
> a signature is needed across a resource a Provenance resource is used for
> that purpose. There are many use-cases that call upon signatures for
> non-repudiation or source validation; rather than duplicate this all over
> the place HL7 FHIR has one special resource, the Provenance, for this
> purpose. Such as prescribing narcotics, authoring an observation, etc. So,
> when an AuditEvent needs a signature a Provenance resource would be
> included with a signature.  In this way FHIR is intended to be
> compose-able. So, an AuditEvent can be signed just like anything else.
>
>
>
> John
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Sarah Squire
> *Sent:* Saturday, November 07, 2015 10:59 AM
> *To:* openid-specs-heart at lists.openid.net
> *Subject:* [Openid-specs-heart] Events in UMA, FHIR, and HEART
>
>
>
> On the call this week, we discussed the overlap between consent receipts
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__api.consentreceipt.org_doc_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=pkx9qbM2emEy0TZIkp8_xBFSCyR9dAwSbfmxQdohRog&s=5GdWN0sr0deuzEbkTba0Xw5x-XC8JFg1Q5VZS_95lwg&e=>
> (or auditable transaction receipts) and FHIR Resource AuditEvents
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__hl7.org_implement_standards_fhir_auditevent.html&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=pkx9qbM2emEy0TZIkp8_xBFSCyR9dAwSbfmxQdohRog&s=5Pfw5Fjk1zDwzlCWNzKmLBq_Vci7tIRkTlOVDE3REIo&e=>
> and Resource Provenance
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__hl7.org_implement_standards_fhir_provenance.html&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=pkx9qbM2emEy0TZIkp8_xBFSCyR9dAwSbfmxQdohRog&s=uBkaR28kpcrFpwNWDtOI4hhUbF4RRCyR-R2vwpbRC00&e=>.
> I took an action item to compare the three, and here’s what I found. Please
> keep in mind throughout that FHIR is an established standard, while consent
> receipt is not yet. Both projects are subject to change.
>
>
>
> In the context of a facilitated workshop
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__iiw.idcommons.net_Consent-5FReceipts-5Fin-5FUMA&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=pkx9qbM2emEy0TZIkp8_xBFSCyR9dAwSbfmxQdohRog&s=VxgoRcPZ9EsVZXH3w4MqIIQR6aWWv7_rIVq45fZoQfk&e=>
> at IIW last week, we came to the conclusion that there were many events in
> a generic UMA workflow where data was exchanged, but only two - 1. Alice
> configures her AS, and  2. Bob presents claims - where actual “consent” was
> taking place. We discussed the possibility of having two different kinds of
> receipts - a consent receipt for when a person is consenting, and an
> auditable transaction receipt for when data is being exchanged between
> security boundaries so that both sides of that exchange have signed record
> of the transaction.
>
>
>
> This is interesting because the FHIR project broke out their events in a
> similar fashion. Rather than talking about data exchange and consent, they
> talk about data usage and generation. Data generation is handled by
> Resource Provenance while data usage is handled by Resource AuditEvent.
>
>
>
> If you’ll come with me down into the weeds, these are the fields that are
> common to all three:
>
>
>
> subject/actor/participant
>
> purpose of use
>
> policy URL
>
> timestamp
>
>
>
> Of the fields that are not common, I would like to point out some
> interesting differences:
>
>
>
> *signature*
>
> Provenance and consent receipts are both signed, while AuditEvents are
> not. This is interesting because our group conceived of an auditable event
> receipt that would be signed by one party and “given” to another.
> AuditEvents have a record of both parties, but no cryptographic proof.
>
>
>
> *subject/object*
>
> AuditEvents have a concept of a “subject” and an “object” that might be
> very useful in a HEART context. Consent receipts have similar “subject” and
> “issuer” fields.
>
>
>
> *period/lifecycle*
>
> Both FHIR specifications define some kind of bounded time period. This is
> very interesting because it’s a concept we don’t have in HEART or consent
> receipts. HEART doesn't yet have any use cases that involve information
> lifecycle, expiration, or permission revocation. That’s probably something
> we should look at as a group.
>
>
>
> *location/jurisdiction*
>
> Consent receipts have a jurisdiction field, but not location. Both FHIR
> specs have location, but not jurisdiction. Do the lawyers in the room have
> an opinion on whether these are relevant in a HEART context? One? Both?
> Neither?
>
>
> I would love to hear some feedback from the group on what events and/or
> receipts in HEART would look like.
>
>
> Sarah Squire
>
> Engage Identity
>
> http://engageidentity.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__engageidentity.com_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=pkx9qbM2emEy0TZIkp8_xBFSCyR9dAwSbfmxQdohRog&s=mlyIZoTbn_wDu6prERBFoN36Cpw1Xcp0kwqsiMfy9jk&e=>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151109/dc1e5b30/attachment.html>