Continuing from Eve's last bullet: HEART's primary concern needs to be FHIR. Only the FHIR RS can have an Accounting of Disclosures and notify the Grantor that a resource has been accessed.<div><br></div><div>As Eve says, logs and notifications related to the AS - Grantor relationships are out of band and might as well be proprietary.</div><div><br></div><div>That leaves the logs and notifications related to the initiation of the RS - AS relationship. I call this the resource registration event. It is a Type 1 delegation of authorization. From the FHIR perspective, an AuditEvent of some sort should be logged by the RS and some notification should be sent for the AS registration transaction. </div><div><br></div><div>What shall we call the RS-AS resource registration transaction and is an event like this already in the FHIR standard?</div><div><br></div><div>Adrian<br><div></div><div><br>On Wednesday, May 18, 2016, Eve Maler <<a href="mailto:eve.maler@forgerock.com">eve.maler@forgerock.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Actually, I'm foolish, and my imagination did fail me. To answer Debbie's question about type 1, <i>of course</i> Alice may want to to know what authorization was actually made. This kind of notification could, I think, be in the form of a "receipt" (transaction receipt? consent receipt?) from the AS to Alice, letting her know that the instructions she gave it (an "authorization policy") were accurately recorded for execution. But note that UMA doesn't dictate this; it would be part of a different standard or proprietary flow.<div><br></div><div>Regarding Debbie's type-2 question: Yes, the picture I painted is of "normal", base-level functionality that depends entirely on the client app doing something, e.g. a push notification or whatever. If we focus entirely on AS-to-Alice notifications, we're in the realm of the "meta".</div><div><br></div><div>In this "meta" realm, we can observe that:</div><div><ul><li>There are things we might wish the AS to notify Alice about that aren't part of the UMA protocol at all.</li><ul><li>A subset of these might fall into a "readily standardizable or standardized" category, such as "consent receipts". For example, I'm not sure about this, but it might be the case that capturing Alice's instructions to the AS about how to protect her resource ("authorization policy") would be covered by the Consent Receipt spec.</li><li>The rest might fall into a "proprietary or handled by the implemented software stack" category, such as "software audit logs". For example, the ForgeRock UMA implementation keeps a log, and in fact exposes to the resource owner a History page that shows a chronological series of actions this user took.</li></ul><li>And then there are things that the official UMA protocol message flow encapsulates on the wire between entities, which can be conveyed to Alice.</li><ul><li>Some of these are required flows, such as a resource server having to register a permission ticket on behalf of the client and request a particular extent of access in the process.</li><li>By contrast, some are optional flows, leaving potential gaps in what can be captured. For example, the default token profile requires the resource server to introspect the tokens brought to it by the client at the AS, so this could be reported to Alice, but what the RS does subsequently -- let the client in, or not? -- can only be guessed at. Also, if an alternate token profile is used that uses local token validation, the AS wouldn't be able to notify Alice about this action at all.</li></ul></ul></div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Check out the <a href="https://summits.forgerock.com" target="_blank">2016 schedule</a> for <b>ForgeRock Summits and UnSummits</b>!</p></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, May 18, 2016 at 7:48 AM, Debbie Bucci <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','debbucci@gmail.com');" target="_blank">debbucci@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
I am asking these following questions from a systems perspective may not be relevant to the protocols</p><span>
<p dir="ltr">> Delegation type 1: Alice (RO) -> AS: Alice outsources the job of authorization to her always-on authorization server, an "agent" acting on her behalf. This is a "meta-level" function made possible by the UMA protocol, but gets into "inside-baseball" levels of discussion to talk</p>
</span><p dir="ltr">Although Alice has outsourced (asynchronously set up authorization?)<br>
Is there a chance Alice may want to know an authorization was actually made?</p><span>
<p dir="ltr">> Delegation type 2: RO Alice (RO) -> (RqP) Bob: Alice shares resource access with someone. This is a "base-level" function of UMA -- that is, it's basically the end-to-end sharing function UMA was designed to accomplish.<br>
> I'm sorry I didn't label this "type 1"! This seems to have a natural notification analogue in HL7/FHIR already, as well as in the NZ work etc. Lots of reasons why client app functionality might include notifying an RqP.</p>
</span><p dir="ltr">Isn't this Bob's client? The notification would go to RO again. Data to client Bob would see. A subtlety I must bemissing here</p><span>
<p dir="ltr">> Delegation type 3: Data subject Alice -> Grantor someone else: Alice doesn't directly control access to resources that are about her, but delegates that function to someone else who interacts with an AS on her behalf.</p>
</span><p dir="ltr">Alice may not get notified but I would think both the data accessed and delegation would be logged</p>
<p dir="ltr">>)</p><div><div><br>
> Eve Maler<br>
> ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>
> Cell<a href="tel:%2B1%20425.345.6756" target="_blank"> +1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>
> Check out the 2016 schedule for ForgeRock Summits and UnSummits!<br>
><br>
><br>
> On Wed, May 18, 2016 at 6:04 AM, Debbie Bucci <<a href="javascript:_e(%7B%7D,'cvml','debbucci@gmail.com');" target="_blank">debbucci@gmail.com</a>> wrote:<br>
>><br>
>> Please keep it simple and terminology constant across threads ! If you expand too far too you will loose me. When I see JASON I think additional metadata tagging of information. Please don't introduce<br>
>><br>
>> You asked about use of subscriptions to existing use cases.<br>
>> <br>
>><br>
>> I did not suggest anything would be exchanged beyond a notification but I do (strongly) believe all service will log/audit<br>
>><br>
>> At some point Alice (grantor?) may want need to know more. Doesn't grantor consent/authorize?<br>
>><br>
>> On May 18, 2016 8:28 AM, "Adrian Gropper" <<a href="javascript:_e(%7B%7D,'cvml','agropper@healthurl.com');" target="_blank">agropper@healthurl.com</a>> wrote:<br>
>>><br>
>>> Debbie, you are not following my model. My model has no prior consent, no consent policy representation in FHIR or any other way, and no consent receipts. My model is purely based on the JASON model where the resource, and therefore FHIR, are under separate jurisdiction from the authorization policies. In my model, the Grantor's policies are never communicated on the wire. <br>
>>><br>
>>> Think of this as analogous to never communicating a private key of the wire. My model has no shared secrets and policies are secret. The policies associated with the FHIR resource are locked up in the UMA Authorization Server and never leave. The only thing that leaves the AS is authorization tokens.<br>
>>><br>
>>> Therefore, in my model (an instance of the JASON model) there is no prior consent because Bob gets his authorization, regardless of whether it's one-time or reusable, when he presents to the Authorization Server. (I will not use Authorization for Disclosure ever any more. It's to close and confusing with Authorization of Disclosure in HIPAA.)<br>
>>><br>
>>> Therefore, as far as the FHIR resource server is concerned, it only needs to generate an empty notification each time Bob actually accesses a resource and store the AuditEvent in case the Grantor wants to use FHIR to get an Accounting of Disclosures at a later time.<br>
>>><br>
>>> Adrian<br>
>>><br>
>>> On Wednesday, May 18, 2016, Debbie Bucci <<a href="javascript:_e(%7B%7D,'cvml','debbucci@gmail.com');" target="_blank">debbucci@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Authorization for disclosure. Adrian if I follow you... Alice grants Dr Bob access her data (receipt generated here). Dr Bob later accesses data for the first time. Resource [authorization ??] server logs the disclosure event and optionally pushes a message via a subscription to alert Alice that her data was accessed. At some time later Alice could query for both her receipts and disclosures to verify she granted access and it was Bob who accessed her data. Seems to me these may be core to use case in a US context but peripheral to the profiles for its unclear if there would need to be any scopes or resources sets to define to support it. Defining the content of the subscription message,disclosure or receipt probably out of scope.<br>
>>>><br>
>>>> On May 17, 2016 10:55 PM, "Adrian Gropper" <<a href="javascript:_e(%7B%7D,'cvml','agropper@healthurl.com');" target="_blank">agropper@healthurl.com</a>> wrote:<br>
>>>>><br>
>>>>> I'm glad to hear they're in scope. <br>
>>>>><br>
>>>>> Thing is, that notifications have two components: the endpoint and the message format. As I recall, MVCR consent receipts are more about the message format than the endpoint. I much prefer the FHIR Subscriptions approach because it doesn't trigger a standards project related to the format and therefore makes implementation much faster.<br>
>>>>><br>
>>>>> All three notification types are perfectly compatible with a human-readable format. In some cases, as the FHIR Subscription standard points out, having a message content at all is an unacceptable and unnecessary privacy liability. This applies to type (1) notifications where any contact with the notification endpoint triggers a query to the FHIR endpoint.<br>
>>>>><br>
>>>>> Type (2) notifications need to be human-formatted by definition to meet the intent of HIPAA and today's API Task Force recommendation. Nothing would be served by trying to standardize the format as each FHIR endpoint has a right to issue whatever warning it feels is appropriate to the particular client and situation. Although there was interest in the API discussion today in evolving a Model Privacy Notice related to this Type (2) notification, that work, if and when it's available, is also meant for human-readable format and it was deemed unlikely to cover all of the warning situations. There are no privacy issues with Type (2) messages because they need not contain any PHI. This makes them much more user-friendly since they can be delivered via SMS and other insecure channels.<br>
>>>>><br>
>>>>> Type (3) notifications - A4D - are the only ones that might benefit from a standard format. Even so, standard formatting is not expected - we are perfectly happy to receive activity messages from banks and merchants even though their format is all over the place. In addition, type (3) messages do have privacy implications if they contain any PHI or even indication of the metadata. Therefore, it would be preferable to make these opaque or content-free and allow the recipient to query the FHIR server for A4D if they choose. <br>
>>>>><br>
>>>>> @Grahame: Does FHIR already specify an A4D resource?<br>
>>>>><br>
>>>>> Is the discussion above an appropriate addition to the current use-case?<br>
>>>>><br>
>>>>> Adrian<br>
>>>>><br>
>>>>> On Tuesday, May 17, 2016, Debbie Bucci <<a href="javascript:_e(%7B%7D,'cvml','debbucci@gmail.com');" target="_blank">debbucci@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Notifications were always in scope. One type of notification was in the form of a consent receipt. You may recall Sarah doing some research and comparing to ...was it HL7? The receipt could be use to acknowledge a number of state changes. <br>
>>>>>><br>
>>>>>> I am very familiar with topics/queues and pub/sub from my SOA infrastructure days. A brief glance at subscriptions seem to be a similar pattern.<br>
>>>>>><br>
>>>>>> Dont think its a scope issue. It could be a implementation choice in use cases to use a subscription to deliver a message that either acknowledges a receipt or triggers another process in the work flow<br>
>>>>>><br>
>>>>>> I think that would cover your 3 examples listed below.<br>
>>>>>><br>
>>>>>> On May 17, 2016 8:45 PM, "Adrian Gropper" <<a href="javascript:_e(%7B%7D,'cvml','agropper@healthurl.com');" target="_blank">agropper@healthurl.com</a>> wrote:<br>
>>>>>>><br>
>>>>>>> As mentioned in the other thread, there are three different kinds of notification under HIPAA (and probably in the general case):<br>
>>>>>>> (1) a resource has changed - this is p53 of the NZ doc<br>
>>>>>>> (2) a client is being registered that requires specific affirmation by the Grantor<br>
>>>>>>> (3) accounting for disclosures - the resource server has been accessed by a client<br>
>>>>>>><br>
>>>>>>> The FHIR spec lists 4 different standards for push notifications <a href="http://hl7.org/fhir/subscription.html" target="_blank">http://hl7.org/fhir/subscription.html</a> .<br>
>>>>>>><br>
>>>>>>> I believe all three of these kinds of notification are in-scope for HEART. The three endpoints do not all have to be the same, do not all have to be UMA, and we may want to restrict some of the 4 options offered in the FHIR spec.<br>
>>>>>>><br>
>>>>>>> Can we add these three kinds of notification to the current use case as proposed by Eve?<br>
>>>>>>><br>
>>>>>>> Adrian<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> On Tuesday, May 17, 2016, Eve Maler <<a href="javascript:_e(%7B%7D,'cvml','eve.maler@forgerock.com');" target="_blank">eve.maler@forgerock.com</a>> wrote:<br>
>>>>>>>><br>
>>>>>>>> Supplementing with the link I referred to during the call:<br>
>>>>>>>><br>
>>>>>>>> The UMA case study "Users Managing Delegated Access to Online Government Services" conducted by the New Zealand government available on the UMA wiki:<br>
>>>>>>>><br>
>>>>>>>><a href="http://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Users+Managing+Delegated+Access+to+Online+Government+Services" target="_blank"> http://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Users+Managing+Delegated+Access+to+Online+Government+Services</a><br>
>>>>>>>> (PDF report downloadable here)<br>
>>>>>>>><br>
>>>>>>>> ...documents in Sec 8.4.3.3.3 (p. 46) a desire for "notifications" that can be achieved by sending email or by other means, with a discussion in Sec 8.4.9 (p. 53) about sending push notifications to an UMA requesting party through a mobile app from a resource owner's smart device. The case study didn't, I believe, use FHIR.<br>
>>>>>>>><br>
>>>>>>>> Eve Maler<br>
>>>>>>>> ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>
>>>>>>>> Cell<a href="tel:%2B1%20425.345.6756" target="_blank"> +1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>
>>>>>>>> Check out the 2016 schedule for ForgeRock Summits and UnSummits!<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> On Tue, May 17, 2016 at 7:04 AM, Debbie Bucci <<a href="javascript:_e(%7B%7D,'cvml','debbucci@gmail.com');" target="_blank">debbucci@gmail.com</a>> wrote:<br>
>>>>>>>>><br>
>>>>>>>>> Adrian was given the floor to discuss his concerns that he has labeled for point of reference as “Independent Decision Support at the Point of Care for Physicians and Patients"<br>
>>>>>>>>><br>
>>>>>>>>> Adrian indicated there were 4 primary functions needed. Many in the group translated it in different ways but Debbie’s version was:<br>
>>>>>>>>><br>
>>>>>>>>> Release of Information<br>
>>>>>>>>><br>
>>>>>>>>> Notification of Disclosures<br>
>>>>>>>>><br>
>>>>>>>>> Subscribe to changes<br>
>>>>>>>>><br>
>>>>>>>>> Automated patient right of access.<br>
>>>>>>>>><br>
>>>>>>>>> Eve translated the bullets to both technical and policy work out of the UMA workgroup and pointed to relevant/related publication developed in close coordination with NZ.<br>
>>>>>>>>><br>
>>>>>>>>> Josh was concerned that Adrian perhaps was proposing an entirely new standard. John and others were trying to get clarification around what Adrian was referring to as Data Blocking.<br>
>>>>>>>>><br>
>>>>>>>>> After an hour long of healthy discussion – Josh asked if there were any procedure on how to document to handle such a discussion within the group Adrian was concerned about HEART’s functionality/relevance in relation to his concerns. Hope the following points brought up in the meeting addresses these concerns:<br>
>>>>>>>>><br>
>>>>>>>>> HEART’s function is not to create standards but to create profiles of existing recognized standards to encourage interoperable implementations of these standards. Please see :<a href="http://openid.net/wg/heart/charter/" target="_blank"> http://openid.net/wg/heart/charter/</a><br>
>>>>>>>>><br>
>>>>>>>>> All members are encouraged to bring use cases to the group to consider. The functional use case is broken down into technical functionalities that are flagged as core or peripheral to the standards being considered under HEART.<br>
>>>>>>>>><br>
>>>>>>>>> We acknowledge that with both the Standards and profiles, there may be implementation decisions made to bridge gaps where existing functionality does not exist. We strongly encourage those implementers to officially log the gaps and solutions they made back with the relevant Standards Bodies in order to give feedback to future iterations of the Standards. <br>
>>>>>>>>><br>
>>>>>>>>> Standards development is an iterative process and versioning control of standards and specs are an implementation reality we have to deal with. Changes are made incrementally <br>
>>>>>>>>><br>
>>>>>>>>> We concluded the discussion by asking Adrian to develop a functional use case to bring to the group for consideration. Subsequently there has been a recap discussion posted prior to the notes that we will append to these meeting notes to round out context to the discussion<br>
>>>>>>>>><br>
>>>>>>>>> Next week’s meeting (May 23rd) will focus on the comment submitted by Mike Jones re: suggested changes to the HEART profile. Additionally, if permissible, we will revisit and consider the Argonaut report and their recommendations as part of this review. All members interested that may have input to the impending updates, please make it a point to attend.<br>
>>>>>>>>><br>
>>>>>>>>> AI: Justin is developing a step by step analysis for us to consider.<br>
>>>>>>>>><br>
>>>>>>>>> Will cancel the next two meetings due to conflicts: May 30th (US holiday) and June 5th (Cloud Identity Summit )<br>
>>>>>>>>><br>
>>>>>>>>> On June 12th We should be prepared to go back to the current use case<a href="https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR" target="_blank"> https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR</a> and stay with that use case until we complete our final draft semantic profile.<br>
>>>>>>>>> Adrian's new use case is the next in the queue and welcome any others that folk may want to submit.<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> _______________________________________________<br>
>>>>>>>>> Openid-specs-heart mailing list<br>
>>>>>>>>><a href="javascript:_e(%7B%7D,'cvml','Openid-specs-heart@lists.openid.net');" target="_blank"> Openid-specs-heart@lists.openid.net</a><br>
>>>>>>>>><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank"> http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
>>>>>>>>><br>
>>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> -- <br>
>>>>>>><br>
>>>>>>> Adrian Gropper MD<br>
>>>>>>><br>
>>>>>>> PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>
>>>>>>> HELP us fight for the right to control personal health data.<br>
>>>>>>> DONATE:<a href="http://patientprivacyrights.org/donate-2/" target="_blank"> http://patientprivacyrights.org/donate-2/</a><br>
>>>>>>><br>
>>>>><br>
>>>>><br>
>>>>> -- <br>
>>>>><br>
>>>>> Adrian Gropper MD<br>
>>>>><br>
>>>>> PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>
>>>>> HELP us fight for the right to control personal health data.<br>
>>>>> DONATE:<a href="http://patientprivacyrights.org/donate-2/" target="_blank"> http://patientprivacyrights.org/donate-2/</a><br>
>>>>><br>
>>><br>
>>><br>
>>> -- <br>
>>><br>
>>> Adrian Gropper MD<br>
>>><br>
>>> PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>
>>> HELP us fight for the right to control personal health data.<br>
>>> DONATE:<a href="http://patientprivacyrights.org/donate-2/" target="_blank"> http://patientprivacyrights.org/donate-2/</a><br>
>>><br>
><br>
</div></div><p></p>
</blockquote></div><br></div>
</blockquote></div></div><br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div><br>