Subject: [Txauth] Possible Use Case for GNAP

From: David Pyke <[email-masked]>
Date: Thu, 2 Jul 2020 11:29:11 -0400

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

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Logo <http://www.readycomputing.com/>

LinkedIn icon <https://www.linkedin.com/company/ready-computing> Twitter 
icon <https://twitter.com/ready_computing?lang=en> Youtbue icon 
<https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>

Office: +1 212 877 3307 x5001

[email-masked] <mailto:[email-masked]>_

_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.

---

From: Tom Jones <[email-masked]>
Date: Thu, 2 Jul 2020 09:26:54 -0700

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=
[email-masked]> wrote:

> 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.
>
>  <http://www.readycomputing.com/>
>
>  <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>
>
> * [email-masked] <[email-masked]>*
>
> * www.readycomputing.com <http://www.readycomputing.com/>*
>
> 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.
>
> destroy all copies of the original message. --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: David Pyke <[email-masked]>
Date: Thu, 2 Jul 2020 12:40:49 -0400

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=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     transmission of REST based (FHIR: fhir.hl7.org
>     <http://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.
>
>     LinkedIn icon <https://www.linkedin.com/company/ready-computing>
>     Twitter icon <https://twitter.com/ready_computing?lang=en> Youtbue
>     icon <https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>
>
>     	
>
>     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
>     [email-masked] <mailto:[email-masked]>
-- 

*David Pyke*

---

From: Tom Jones <[email-masked]>
Date: Thu, 2 Jul 2020 09:45:44 -0700

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=
[email-masked]> wrote:

> 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!
>> 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.
>>

---

From: David Pyke <[email-masked]>
Date: Thu, 2 Jul 2020 13:02:20 -0400

Each hop relays the information but may have to do a transform on the 
data on the way through.  So, the data shouldn't be archived as the 
network is designed purely to route request and responses from 
originator to  responder.  As such, there's no need for individual 
access notifications.  However, the data is not necessarily encrypted as 
this is designed as a trusted network. The FHIR query would be routed 
through to the responder, and the results routed back to the query 
originator.

Notifications to the user would be not needed as to the originator 
system the network is (should be) transparent. However, to maintain the 
trust of the authorization/authentication, each hop will have to 
capture, and forward to one or more responders in the network.

For example

 1. EHR A sends out a patient record discovery request to it's upstream
    actor, that is forwarded to it's upstream HIN.
 2. The HIN sends that request to all other HINs who forward it
    (depending on the capabilities of the HIN) to the various actors. 
    The originating user needs to be identified to the responders for
    audit and access consent. However, the cert that is used may (and
    likely will) change for each hop and be different the org that was
    the query source, which will still need to be identified to the
    responders
 3. Some of those actors' EHRs respond saying they have data on that
    patient.
 4. The responding HINs aggregates the responses and sends on bundle to
    the initiating HIN who forwards it via it's network to the query source
 5. That source sends out a requests to saying "Send me the data from
    all the sources", that goes out, and results are aggregated on the
    way back into one bundle.  Same requirements as 2

All of that needs to be managed from a 
trust/authentication/authorization point of view. Simple, right?

On 2020-07-02 12:45 p.m., Tom Jones wrote:
> 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 
>     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!
>
>>     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
>>
>>
>>         I am working on a Healthcare IT project that requires
>>         multi-hop transmission of REST based (FHIR: fhir.hl7.org
>>         <http://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*
>>
>>         LinkedIn icon
>>         <https://www.linkedin.com/company/ready-computing> Twitter
>>         icon <https://twitter.com/ready_computing?lang=en> Youtbue
>>         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
-- 

*David Pyke*

---

From: Tom Jones <[email-masked]>
Date: Thu, 2 Jul 2020 10:46:44 -0700

My guess is that txauth is only concerned with the link between the user
(indirectly to get consent) the destination EHR, which is perversely called
the client of the user, and the RS which is the combined HIE in its
entirety. The RCE should work out the hop x hop stuff. This link (which i
sent out previously) is intended to address the patient as the AS with a
self issued ID. The interesting problem from health care is that the AS
consent will need to be in terms that the user understands, which is not
defined, and not the FHIR claims detail. The HIAWG of Kantara has taken on
the challenge of healthcare identity assurance semantics. A different
Kantara WG is working on the syntax of these messages.
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
Peace ..tom

On Thu, Jul 2, 2020 at 10:02 AM David Pyke <[email-masked]>
wrote:

> Each hop relays the information but may have to do a transform on the data
> on the way through.  So, the data shouldn't be archived as the network is
> designed purely to route request and responses from originator to
> responder.  As such, there's no need for individual access notifications.
> However, the data is not necessarily encrypted as this is designed as a
> trusted network.  The FHIR query would be routed through to the responder,
> and the results routed back to the query originator.
>
> Notifications to the user would be not needed as to the originator system
> the network is (should be) transparent.  However, to maintain the trust of
> the authorization/authentication, each hop will have to capture, and
> forward to one or more responders in the network.
>
> For example
>
>    (depending on the capabilities of the HIN) to the various actors.  The
>    originating user needs to be identified to the responders for audit and
>    access consent. However, the cert that is used may (and likely will) change
>    for each hop and be different the org that was the query source, which will
>    still need to be identified to the responders
>    all the sources", that goes out, and results are aggregated on the way back
>    into one bundle.  Same requirements as 2
>
> All of that needs to be managed from a trust/authentication/authorization
> point of view. Simple, right?
>
>
>>> <https://www.linkedin.com/company/ready-computing> 
>>> <https://twitter.com/ready_computing?lang=en>

---

From: Justin Richer <[email-masked]>
Date: Thu, 2 Jul 2020 15:34:10 -0400

David, thanks for bringing this use case here. If I’m understanding this, the problem has more to do with the data as it traverses the API fulfillment than it does with the authorization request on the way in, right? I think that this has some potentially interesting implications on the way the client requests resources (using a rich descriptive structure) and the UX associated with that at the AS. Aaron Parecki’s had some thoughts on something similar within the OAuth WG, so maybe he can chime in on this here.

There are also some implications about the transitive trust through the network. If we look at each hop as a separately authorized request, could we define them in a way that they’re chained from each other down the line? Maybe it would be possible for the root HIN to get a new token for each of the downstream HINs, but this new token is in the context of the first one. OAuth token exchange lets you do something like this, but here we could have it be augmented and amended with the rights and requests of the root HIN as well. 

I think Tom is largely right, though, in that GNAP would be a :carrier: for that kind of request through the network, and the :details: of it would need to be worked out in a vertical-specific definition. But the infrastructure is important!

What are the aspects of OAuth 2 that make this kind of multi-hop deployment difficult to use with OAuth 2 today, though? In understanding the limitations, we can start to address them here in GNAP.

 — Justin

> On Jul 2, 2020, at 1:46 PM, Tom Jones <[email-masked]> wrote:
> 
> My guess is that txauth is only concerned with the link between the user (indirectly to get consent) the destination EHR, which is perversely called the client of the user, and the RS which is the combined HIE in its entirety. The RCE should work out the hop x hop stuff. This link (which i sent out previously) is intended to address the patient as the AS with a self issued ID. The interesting problem from health care is that the AS consent will need to be in terms that the user understands, which is not defined, and not the FHIR claims detail. The HIAWG of Kantara has taken on the challenge of healthcare identity assurance semantics. A different Kantara WG is working on the syntax of these messages.  
> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token <https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token>  
> Peace ..tom
> 
> 
> On Thu, Jul 2, 2020 at 10:02 AM David Pyke <[email-masked] <mailto:[email-masked]>> wrote:
> Each hop relays the information but may have to do a transform on the data on the way through.  So, the data shouldn't be archived as the network is designed purely to route request and responses from originator to  responder.  As such, there's no need for individual access notifications.  However, the data is not necessarily encrypted as this is designed as a trusted network.  The FHIR query would be routed through to the responder, and the results routed back to the query originator. 
> 
> Notifications to the user would be not needed as to the originator system the network is (should be) transparent.  However, to maintain the trust of the authorization/authentication, each hop will have to capture, and forward to one or more responders in the network.
> 
> For example
> 
> EHR A sends out a patient record discovery request to it's upstream actor, that is forwarded to it's upstream HIN.
> The HIN sends that request to all other HINs who forward it (depending on the capabilities of the HIN) to the various actors.  The originating user needs to be identified to the responders for audit and access consent. However, the cert that is used may (and likely will) change for each hop and be different the org that was the query source, which will still need to be identified to the responders
> Some of those actors' EHRs respond saying they have data on that patient.
> The responding HINs aggregates the responses and sends on bundle to the initiating HIN who forwards it via it's network to the query source
> That source sends out a requests to saying "Send me the data from all the sources", that goes out, and results are aggregated on the way back into one bundle.  Same requirements as 2 
> All of that needs to be managed from a trust/authentication/authorization point of view. Simple, right?
> 
> 
> 
>> 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=[email-masked] <mailto:[email-masked]>> 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!
>> 
>>> 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=[email-masked] <mailto:[email-masked]>> wrote:
>>> I am working on a Healthcare IT project that requires multi-hop transmission of REST based (FHIR: fhir.hl7.org <http://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
>>> 
>>>  <https://www.linkedin.com/company/ready-computing>  <https://twitter.com/ready_computing?lang=en>  <https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>	
>>> [email-masked] <mailto:[email-masked]>
>>> www.readycomputing.com <http://www.readycomputing.com/>
>>> 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
>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>>> 
>> -- 
>> David Pyke
>> 
>>  <https://www.linkedin.com/company/ready-computing>  <https://twitter.com/ready_computing?lang=en>  <https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>	
>> [email-masked] <mailto:[email-masked]>
>> www.readycomputing.com <http://www.readycomputing.com/>
>> 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
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> David Pyke
> 
>  <https://www.linkedin.com/company/ready-computing>  <https://twitter.com/ready_computing?lang=en>  <https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>	
> [email-masked] <mailto:[email-masked]>
> www.readycomputing.com <http://www.readycomputing.com/>
> 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
> [email-masked]

---

From: David Pyke <[email-masked]>
Date: Mon, 6 Jul 2020 10:34:13 -0400

Those are exactly the issues I was facing.  While I can make the hops 
independent, they need to be chained so that everything is traceable.   
It's possible but ugly with OAuth.

On 2020-07-02 3:34 p.m., Justin Richer wrote:
> If we look at each hop as a separately authorized request, could we 
> define them in a way that they’re chained from each other down the 
> line? Maybe it would be possible for the root HIN to get a new token 
> for each of the downstream HINs, but this new token is in the context 
> of the first one
-- 

*David Pyke*

---

From: Steinar Noem <[email-masked]>
Date: Mon, 6 Jul 2020 18:48:16 +0200

Hey, we have some (sort of) similar cases and requirements today which we
have solved by implementing the token-exchange spec.
It certainly doesn’t solve all the issues discussed here, but for
traceability it does the job for us. Being able to express an
“authorization stack-trace” and the original user identity is both useful
and required  in our case.

-Steinar

man. 6. jul. 2020 kl. 16:34 skrev David Pyke <david.pyke=
[email-masked]>:

> If we look at each hop as a separately authorized request, could we define
> them in a way that they’re chained from each other down the line? Maybe it
> would be possible for the root HIN to get a new token for each of the
> downstream HINs, but this new token is in the context of the first one
>
> --
>
> *David Pyke*
>
> <https://www.google.com/maps/search/150%0D%0A++++++++++++++++++++++++++++Beekman+Street,+Floor+3,+New+York,+NY+10038?entry=gmail&source=g>
>
-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| [email-masked] | [email-masked]  | +47 955 21 620 | www.udelt.no |

---

From: Justin Richer <[email-masked]>
Date: Mon, 6 Jul 2020 13:30:38 -0400

Something very much like this was the original driver to my now-defunct OAuth 2 token chaining draft:

https://tools.ietf.org/html/draft-richer-oauth-chain-00 <https://tools.ietf.org/html/draft-richer-oauth-chain-00>

Most of the concepts here were eventually subsumed by the token exchange specification, though with support for more complex use cases as well. 

In XYZ, one of the reasons that we have an explicit “transaction handle” to represent the grant request is that it allows us to build in this kind of multi-party chaining. A downstream party can refer to an ongoing request and start a new one in its context. This is also the idea behind how you’d do an RS-first flow: the RS would get a resource or transaction handle and give it back to the client, which would make a request for a new token based on that artifact. Note, for clarity, we didn’t implement it explicitly in our code base, but a number of thought experiments went into the design of the overall protocol and it’s noted on the website in a few places. It’s something that I think is worth exploring, and it’s well within our scope given it’s an area that OAuth 2 does address today. It’s my hope that by taking a step back from the OAuth 2 solution and understanding its problems, we can have a more consistent and robust solution in GNAP.

 — Justin

> On Jul 6, 2020, at 12:48 PM, Steinar Noem <[email-masked]> wrote:
> 
> Hey, we have some (sort of) similar cases and requirements today which we have solved by implementing the token-exchange spec. 
> It certainly doesn’t solve all the issues discussed here, but for traceability it does the job for us. Being able to express an “authorization stack-trace” and the original user identity is both useful and required  in our case.
> 
> -Steinar
> 
> man. 6. jul. 2020 kl. 16:34 skrev David Pyke <david.pyke=[email-masked] <mailto:[email-masked]>>:
> Those are exactly the issues I was facing.  While I can make the hops independent, they need to be chained so that everything is traceable.   It's possible but ugly with OAuth.
> 
>> If we look at each hop as a separately authorized request, could we define them in a way that they’re chained from each other down the line? Maybe it would be possible for the root HIN to get a new token for each of the downstream HINs, but this new token is in the context of the first one
> -- 
> David Pyke
> 
> 150 Beekman Street, Floor 3, New York, NY 10038 <https://www.google.com/maps/search/150%0D%0A++++++++++++++++++++++++++++Beekman+Street,+Floor+3,+New+York,+NY+10038?entry=gmail&source=g>
> 
> | [email-masked] <mailto:[email-masked]> | [email-masked] <mailto:[email-masked]>  | +47 955 21 620 <> | www.udelt.no <http://www.udelt.no/> |