Re: [Txauth] Possible Use Case for GNAP

without a better understanding of the "hop" it is hard to say. Does each
"hop" archive the PHI in FHIR format? if so each would need to notify the
user of access, as i see the problem. That sounds like something that would
scare the patient. If the "hop" just handled (for example) an encrypted
packet, that would not be a problem. OTOH if a federation were involved,
the federation could notify the user. Less scary perhaps.
Peace ..tom

On Thu, Jul 2, 2020 at 9:41 AM David Pyke <david.pyke=
40readycomputing.com@dmarc.ietf.org> wrote:

> Great to hear!
>
> My main concern is that the cert use may be an issue as it's passed
> through the hops.  A hop may want to have their predecessor  use the
> predecessor's cert coming in but may swap out their own cert for the next
> connection (and the same happening on the way back).  So, the ability to
> trace certs through the relaying would be an issue so that trust is
> maintained even when those certs aren't chained together.  It would be good
> if there was one cert or a set of chained certs used for the two traversal
> but that's not likely to be the case.
>
> Thanks!
> On 2020-07-02 12:26 p.m., Tom Jones wrote:
>
> We discussed that use case this morning in OIDC. A proposal has been made
> for a new endpoint that I would like to see working from the EHR endpoints.
> Did you have other concerns besides the source and destination endpoints
> for the data?
> Peace ..tom
>
>
> On Thu, Jul 2, 2020 at 8:30 AM David Pyke <david.pyke=
> 40readycomputing.com@dmarc.ietf.org> wrote:
>
>> I am working on a Healthcare IT project that requires multi-hop
>> transmission of REST based (FHIR: fhir.hl7.org) resources.  The
>> established protocol uses OAuth2 which doens't lend itself to multi-hop
>> relay.
>>
>> I saw a presentation on XYZ/GNAP and thought it might be early enough to
>> get on the train to consider how it might address that structure.  The
>> system I'm working on is from the US Office of the National Coordinator for
>> Healthcare IT (ONC) called TEFCA.  At minimum there would be 4 hops, at
>> maximum, could be 8-10 and no bypassing of the network can be done.  As I
>> said, OAuth2 doesn't handle that without significant issues.
>>
>> If this is not a use case that can be considered, please accept my
>> apologies.
>>
>> Thanks
>>
>> Dave Pyke
>> --
>>
>> *David Pyke*
>>
>> Manager, Strategic Consulting
>>
>>
>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> [image: Logo] <http://www.readycomputing.com/>
>>
>> [image: LinkedIn icon] <https://www.linkedin.com/company/ready-computing> [image:
>> Twitter icon] <https://twitter.com/ready_computing?lang=en> [image:
>> Youtbue icon] <https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>
>>
>> Office: +1 212 877 3307 x5001
>>
>> * david.pyke@readycomputing.com <david.pyke@readycomputing.com>*
>>
>> * www.readycomputing.com <http://www.readycomputing.com/>*
>>
>> 150 Beekman Street, Floor 3, New York, NY 10038
>>
>> The information in this e-mail communication together with any
>> attachments is intended only for the person or entity to which it is
>> addressed and may contain confidential and/or privileged material. If you
>> are not the intended recipient of this communication, please notify us
>> immediately. Any views expressed in this communication are those of the
>> sender, unless otherwise specifically stated. Ready Computing does not
>> represent, warrant or guarantee that the integrity of this communication
>> has been maintained or the communication is free of errors, virus or
>> interference.
>>
>> This is not a secure transmission. The information contained in this
>> transmission is highly prohibited from containing privileged and
>> confidential information, including patient information protected by
>> federal and state privacy laws. It is intended only for the use of the
>> person(s) named above. If you are not the intended recipient, you are
>> hereby notified that any review, dissemination, distribution, or
>> duplication of this communication is strictly prohibited. If you are not
>> the intended recipient, please contact the sender by reply email and
>> destroy all copies of the original message. --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
> --
>
> *David Pyke*
>
> Manager, Strategic Consulting
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> [image: Logo] <http://www.readycomputing.com/>
>
> [image: LinkedIn icon] <https://www.linkedin.com/company/ready-computing> [image:
> Twitter icon] <https://twitter.com/ready_computing?lang=en> [image:
> Youtbue icon] <https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>
>
> Office: +1 212 877 3307 x5001
>
> * david.pyke@readycomputing.com <david.pyke@readycomputing.com>*
>
> * www.readycomputing.com <http://www.readycomputing.com/>*
>
> 150 Beekman Street, Floor 3, New York, NY 10038
>
> The information in this e-mail communication together with any attachments
> is intended only for the person or entity to which it is addressed and may
> contain confidential and/or privileged material. If you are not the
> intended recipient of this communication, please notify us immediately. Any
> views expressed in this communication are those of the sender, unless
> otherwise specifically stated. Ready Computing does not represent, warrant
> or guarantee that the integrity of this communication has been maintained
> or the communication is free of errors, virus or interference.
>
> This is not a secure transmission. The information contained in this
> transmission is highly prohibited from containing privileged and
> confidential information, including patient information protected by
> federal and state privacy laws. It is intended only for the use of the
> person(s) named above. If you are not the intended recipient, you are
> hereby notified that any review, dissemination, distribution, or
> duplication of this communication is strictly prohibited. If you are not
> the intended recipient, please contact the sender by reply email and
> destroy all copies of the original message. --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>