[Openid-specs-heart] {Openid-specs-heart] scope of work

[Tom Jones]

please send a point to the use cases
Peace ..tom


On Wed, Apr 29, 2020 at 11:55 AM Debbie Bucci <debbucci at gmail.com> wrote:

> Forwarding response to group
>
> ---------- Forwarded message ---------
> From: Debbie Bucci <debbucci at gmail.com>
> Date: Wed, Apr 29, 2020 at 2:53 PM
> Subject: Re: [Openid-specs-heart] scope of work
> To: Tom Jones <thomasclinganjones at gmail.com>
>
>
> Tom
>
> 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.
>
> 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.
>
>
>
> On Wed, Apr 29, 2020 at 2:47 PM Tom Jones <thomasclinganjones at gmail.com>
> wrote:
>
>> 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.
>> There are two way to approach this:
>> 1. find a business purpose
>> 2. find a set of appropriate use cases with problems that need to be
>> solved.
>> I would recommend #2 - lets build use cases based on needs.
>> I have started a potential list of use cases that could be a starting
>> point.
>> I am strongly opposed to the current approach of looking at
>> solutions (FAPI, UMA, whatever) before we understand what value we can
>> contribute.
>>
>> 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.
>>
>> Peace ..tom
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
> _______________________________________________
> 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/20200429/d6676f88/attachment.html>