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

[Debbie Bucci]

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?
On Nov 2, 2015 5:40 PM, "Sarah Squire" <sarah at engageidentity.com> wrote:

> 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
>
> _______________________________________________
> 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/20151102/c1558cf3/attachment-0001.html>