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

[Sarah Squire]

On the call this week, we discussed the overlap between consent receipts
<http://api.consentreceipt.org/doc/> (or auditable transaction receipts)
and FHIR Resource AuditEvents
<http://hl7.org/implement/standards/fhir/auditevent.html> and Resource
Provenance <http://hl7.org/implement/standards/fhir/provenance.html>. 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
<http://iiw.idcommons.net/Consent_Receipts_in_UMA> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151107/a757ddcb/attachment.html>