[Openid-specs-heart] Draft HEART Meeting Notes 2015-11-02

[Sarah Squire]

Attending:

Debbie Bucci

Danny van Leeuwen

Sarah Squire

Adrian Gropper

William Kinsley

Glen Marshall

Justin Richer

Jeremy Maxwell

Eve Maler

Dale Moberg

Alex Mushkin

John Moehrke

Gunther Meyer

Edmund Jay

Abbie Barbir

Thompson Boyd

IIW and OIDF Meeting Updates

Debbie:

A new group is forming called iGov that uses OpenID Connect and OAuth 2 to
use a common profile between multiple governments. Justin would like them
to leverage the work we’ve done in HEART since we are ahead of the curve
and have three profiles that are generically applicable. We originally
planned to shut down the HEART working group in June 2016, but the OpenID
Foundation management committee suggested that we roll out an implementers’
draft in January (which would help the iGov workgroup and lessen some IPR
issues) and keep the group active to work out bugs.

Auditable Transaction Receipts in UMA

Sarah:

We talked about putting consent receipts in UMA, and found that we actually
need Auditable Consent Receipts to record each transaction so that an
auditable trail can exist for all information sharing transactions

Eve:

UMA has an open issue to support audit logs. CRs and ATRs are human
readable with machine capability mixed. So it

Glen:

I would caution against using the term audit logs since security auditing
is a whole different thing. I wrote a security audit log standard for
healthcare for HL7 which I will send to the list.

Eve:

Consent receipts could be worked into a blockchain structure

William:

Are you saying that we’re talking about Alice being able to look at an
access record?

Eve:

Yes, UMA out of the box does not let you see out of the box whether and
when things have been accessed. It’s recording a state-change.

Adrian:

It would be helpful to think of these as “accounting for disclosures.” It’s
a legal requirement that’s not well defined yet. What would that look like?

William:

Accounting of disclosures is something Alice is entitled to ask of any data
consumer like an EHR.

John:

Within FHIR, there are two mechanisms to cover - 1. provenance - where did
this data come from? how did it get transformed? 2. a recording that some
interesting event has occurred. HL7 is concerned with both security and
privacy and data provenance. There is a way already to record those types
of things. Also, I’ve driven a couple of use cases through FHIR
specifically on accounting of disclosures. If OAuth and UMA can come up
with a non-healthcare specific way to record this, that would be helpful.

Sarah:

Is that recording of an event human-readable?

John:

The recording is a FHIR resource, so it’s available in the XML and JSON
forms. So they are human readable within a JSON blob.

Adrian:

We should provide a notice endpoint in the authorization server to receive
transaction receipts regardless of how they’re formatted.

Debbie:

It would be interesting to know if there’s overlap between consent receipts
and audit event resource in FHIR

Sarah:

We can certainly look at both and see how much overlap there is.

John:

We are still working on both, so they may change.

Sarah:

I will find both schemas and send them to the group.

William:

Would these tickets originate from the authorization server or the resource
server?

Eve:

Any entities that have a trust relationship and a state change happens
between them, then one would generate a receipt and send it to the other.
For example, if you make a hotel reservation, you don’t really trust it
until you get a confirmation number. If you order a coffee, but don’t get a
receipt, you have no way to prove that it happened. The receipt proves that
you both experienced the state change.

Debbie:

Is this a way of logging transitive trust? Where Alice trusts Bob, and then
Bob shares with someone else?

Eve:

Alice and Bob are key contenders for parties interested in these receipts.
It may be that Bob could agree to something that gives him power of
attorney - there may be a relationship reflected in the artifact. We need
to think about where that artifact is stored and how it’s secured. Do we
want an extension endpoint? Andrew Hughes says we should call it “the
shoebox endpoint,” i.e. where you store all your receipts.

Adrian:

Rather than continuing this discussion, I will take an action item for the
next meeting to present at least three design patterns in the simplest
sequence diagram. These are things we talked about during our use cases.
Why don’t we do that instead? I’d like to create a variant of the swimlane
I made. My swimlane has a couple of miracles - how did Bob discover the
resource? What credentials did the authorization server get? There are
three consent receipts currently. What I’d like to do is present what’s
going on here as a couple of design patterns for us to talk about. It
brings together what’s going on in Argonaut and SMART on FHIR.

Debbie:

If we do this in a way that is not healthcare specific, what classes of
information would we audit?

John:

There’s a commonality between all of those - who, what, when, where, why.
As long as we have those characteristics, we have a consent receipt. I
would like to see it in a generic form. That’s actually a pretty low bar
because accounting of disclosures in the US is not very detailed.

Eve:

Influenced by Adrian in our patch release of the UMA spec, even after
getting a token saying Bob is authorized, the resource server can do more
or still refuse to let him in. Also, there are other reasons to release
information, such as a subpoena, and you would want to record that that was
done.

Debbie:

It’s sort of like “track my package” for your data.

Eve:

The loose coupling of UMA means that Alice can choose her AS, it means that
the AS has less and less effect over the RS to tell it what to do.

Debbie:

As we move toward the UMA semantic profile and nail down the three or four
patterns, is ATR a pattern that we include in that profile?

John:

In the security realm around healthcare, we have always provided a way to
record when access is recorded. So that a patient can request an “access
report.” We want to have good enough logs to be able to generate that, and
we want to be able to determine which events would go into that report.

Adrian:

I’m concerned that you’re still expecting patients to ask for an access
report. Consent receipts as developed in Kantara are not asked for, they
are delivered as a side-effect of a consent or agreement.

John:

I’m just trying to support the law that says we have to report everything.
I’m not trying to describe an output.

Adrian:

There is no reason to wait for a request.

John:

There’s nothing that forbids that from happening. The problem is that there
are so many exceptions that making the decision that the patient /must/ be
informed. If you absolutely know that, then do it. There have been many
medical and legal professionals who indicate that there have been concerns.
In this case, we’re dealing with a competent patient who is in control, so
we should have a good reason /not/ to inform the patient.

Debbie:

It sounds like there’s a starting place there, and that’s good. Adrian will
be up first next week.

Adrian:

Also on the agenda next week, I would like to announce a project I started
at iiw that will be a hackathon at MIT - future commerce - November 20-22.
It’s a personal authorization server.

Chat log

Justin Richer (to All):

I'm having network difficulties so my audio's going to be cutting in and
out today. I'll follow as much as I can.

Justin Richer (to All):

A big difference is also the fact that the receipts themselves are sent to
and/or made available to the end users.

Justin Richer (to All):

These aren't just objects that sit in a log on the server.

debbie bucci (to All):

Get that but what is the class of objects being logged?

Justin Richer (to All):

Notions of transactions, not security events.

Justin Richer (to All):

These are not system events.

Justin Richer (to All):

I think Glen's got the wrong idea of it from what I've hearing.

Justin Richer (to All):

*I'm

Eve Maler (to All):

Provenance was the third of four use cases we thought of for blockchain/UMA
synergies; session notes are here (but IIW wiki seems to be down at the
moment)... http://iiw.idcommons.net/BlockChain_%26_UMA
26_UMA_–_Two_Great_Tastes…_Do_They_Go_Together%3F

Justin Richer (to All):

the whole notion of the ATR and consent reciept is to make it generally
applicable and not specific to any vertical

Justin Richer (to All):

they're protected with the issuer's signature and can be processed offline
after transmission

Justin Richer (to All):

this is very important for a receipt-type object

Eve Maler (to All):

I think it's important that the data structure could be extended with
vertical-specific structures

John Moehrke (to All):

http://hl7.org/implement/standards/fhir/provenance.html

John Moehrke (to All):

http://hl7.org/implement/standards/fhir/auditevent.html

Justin Richer (to All):

Certainly but that remains in the realm of extension, where the ATR is a
core capture mechanism.

Eve Maler (to All):

yes, agreed

John Moehrke (to All):

http://hl7.org/implement/standards/fhir/auditevent-example-disclosure.json.html

John Moehrke (to All):

Note in FHIR any resource can have a digital signature for non-repudiation.

Eve Maler (to All):

thanks, John - great example

Justin Richer (to All):

Notification and transit is somewhat orthogonal but it's all got to fit
together in the end

Eve Maler (to All):

The reason why I say actual confirmation of access (A4D, sort of) is not in
out-of-the-box UMA is that the AS can't be perfectly sure based simply on
the RS's token introspection that access was given - it would be just a
guess

Eve Maler (to All):

But the AS and RS have a nice, secure comms channel over which to build
such notification as a simple extension (A4D endpoint?)

Justin Richer (to All):

not necessarily to the end user, depending on how the primary account
credentials are set up

Justin Richer (to All):

But I think a "if you want the notice sent to you you need to tell me how"
kind of thing makes sense

debbie bucci (to All):

So ATR is a simple extension to ....? UMA?

Justin Richer (to All):

We can do things beyond what's required by the law.

Justin Richer (to All):

ATR is something that can be applied to UMA and perhaps other things.

Justin Richer (to All):

There seems to be general applicability for recording an event between
parties like this. There's been some talk here at IETF this week already
about pulling together the receipts work, RISC, SCIM, and a few other
projects that are doing similar things.

debbie bucci (to All):

Just to be clear ... ATR is not another standard is it?

Justin Richer (to All):

I would like to see the ATR included in our semantic profiles for both
OAuth/FHIR and UMA/FHIR

debbie bucci (to All):

both makes sense to me

Justin Richer (to All):

ATR is an abstration of consent receipts

Justin Richer (to All):

it's a term I coined last week to capture this notion, probably not the
final name or form

Justin Richer (to All):

It started as consent receipts but the who/what/when type of questions are
common to a number of different things, beyond consent.

debbie bucci (to All):

I know that ... just consent receipts is a scoped layer of info/profile of
info that can be gathered during transactions

Eve Maler (to All):

here were all the notes: http://iiw.idcommons.net/IIW_21_Notes


Sarah Squire
Engage Identity
http://engageidentity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151102/73d7e64b/attachment.html>