<div><div dir="auto">Forwarding response to group</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <strong class="gmail_sendername" dir="auto">Debbie Bucci</strong> <span dir="auto"><<a href="mailto:debbucci@gmail.com">debbucci@gmail.com</a>></span><br>Date: Wed, Apr 29, 2020 at 2:53 PM<br>Subject: Re: [Openid-specs-heart] scope of work<br>To: Tom Jones <<a href="mailto:thomasclinganjones@gmail.com">thomasclinganjones@gmail.com</a>><br></div><br><br><div><div dir="auto">Tom</div></div><div dir="auto"><br></div><div dir="auto">Have you spent time on the HEART WG website?  We have listed a number of use cases that have yet to be resolved.  Hesitant to start from scratch.   I am personally interested in FAPI because of its much more secure , has production traction for read and write transactions.    HEART was criticized for being too tough to implement yet the open banking regulations helped move the FAPI work along.    </div><div dir="auto"><br></div><div dir="auto">A request for data has an associated token from the user in advance - existing implementation have defaulted to a broad yes/no because of the work to permit such fine grain access.</div><div dir="auto"><br></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 29, 2020 at 2:47 PM Tom Jones <<a href="mailto:thomasclinganjones@gmail.com" target="_blank">thomasclinganjones@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">First - i fundamentally agree with Justin's request that HEART needs to find a purpose that aligns with the needs of the market - His assertion was more of the type that HEART got no tracktion the last time around.<div>There are two way to approach this:</div><div>1. find a business purpose</div><div>2. find a set of appropriate use cases with problems that need to be solved.</div><div>I would recommend #2 - lets build use cases based on needs.</div><div>I have started a potential list of use cases that could be a starting point.</div><div>I am strongly opposed to the current approach of looking at solutions (FAPI, UMA, whatever) before we understand what value we can contribute.</div><div><br></div><div>wrt Justin's proposal on TXAUTH to HEART - i note one missing element - specifically  how does the requesting site tell the sending site what data they want in a manner that permits the user to accept or request the request. I do not believe that a list of FHIR data elements is something that the user could evaluate. If we want to put the user in control, we must provide the user a choice that they can understand. I can share the Kantara doc on patient choice if that is desired. TXAuth does not currently do that, but could be adapted to do it.</div><div><br></div><div><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div></div></div>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto: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" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
</blockquote></div></div>
</div></div>