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

Mon Nov 9 18:40:03 UTC 2015

This follows aligns with ... W3C provenance work (?)
On Nov 9, 2015 1:00 PM, "Sarah Squire" <sarah at engageidentity.com> wrote:

> 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=>
>>
>
>
> _______________________________________________
> 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/20151109/a1c9fe79/attachment.html>