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

Mon Nov 9 16:59:03 UTC 2015

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  <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=> consent receipts (or auditable transaction receipts) and FHIR  <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=> Resource AuditEvents and  <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=> Resource Provenance. 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  <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=> facilitated workshop 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

 <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=> http://engageidentity.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151109/22a5c96e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6966 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151109/22a5c96e/attachment.p7s>