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

Debbie said: Sarah

Awesome notes as usual!

In addition to the links to the consent receipt ... to round out this week's discussion...Thomas H. if you are following along, perhaps we can persuade you to join us and talk about related work.

I do like the idea of tagging this on to both Glens (donation ) and Adrian (delegation) use case to see where this may lead. In the donation use case not only could you revoke the permissions...there would (in theory) be bread crumbs to follow in the clean-up - even if info is minimal.

Adding to both UMA/FHIR and OAUTH2/FHIR profiles make sense but if there is a generic extension or stub that both could leverage ... does that become it's own extension?