Payload relay across multiple gateways

[krisaccessh]

A multi health claim exchange provider model (multiple HCX platform model) is recommended in NHA Joint Working Group 2019 report.
Multiple HCX provider model will facilitate the exchange of requests and responses across multiple HCX platforms similar to SMTP relay to reach the destination.
Each HCX will register their subscribed participants (provider and payers) in participant registry maintained by the HCX platform and assign unique participant registry codes (. The participant registry will contain the other details such as endpoint-url, blacklist flag, gateway-domain-code (HCX1, HCX2 etc) Each participant is identified by a unique registry code (e.g. PROVIDER01@HCX01 or PAYOR01@HCX01) These participant registry codes are sent as x-hcx-sender-code and x-hcx-recipient-codes header values in the ProtocolHeader object in hcx apis.
As defined in HCX technical specifications, all the participant systems will obtain an API Key from HCX Gateway with which it authenticates itself to the HCX gateway. The API_keys will be JWT compliant as per JSON web signature (RFC7515) specifications. The JWS payload will have claim sets as
• JWS Payload should be a claim set containing the mandatory claims jti, iss, sub, iat and exp.
o jti - unique identifier for the JWT
o iss - HCX instance identifier of token issuer HCX instance.
o sub - client_id of the participant
o iat - unix timestamp at which the JWT is issued
o exp - the expiration time after which the JWT must not be accepted for processing
Here iss = will be a unique HCX identifier who issued the token (each HCX will be identified by a unique HCX identifier (same will be used as suffix code in participant registry codes (e.g. participant-code@hcx-domain-code)
When a participant provider or payer submit the HCX request message in API call to the HCX gateway (to which the participant is subscribed), the HCX will authenticate the request API call using the issued JWS token . The ProtocolHeader object contain the custom header values such as participant registry code (participant-code@hcx-domain-code) of the sender and the recipient , x-hcx-api_call_id,x-hcx-correlation_id and x-hcx-timestamp Two more header values may be introduced in ProtocolHeader e.g. x-hcx-source-gateway-domain-code (source gateway domain code (e.g. HCX1,HCX2,….) and x-hcx-destination-gateway-domain-code(destination gateway domain code (e.g.(HCX1,HCX2….). The HCX gateways will dynamically update these header values before routing of messages from one gateway to another intermediary or final destination gateway. The x-hcx-source-gateway-domain-code will be the gateway domain code of the source HCX gateway which forwarded the request to another gateway during a relay and x-hcx-destination-gateway-domain-code will be the gateway domain code of the next gateway in the hop chain where message is forwarded by the source gateway during flow of message across multiple gateways to reach the final destination gateway. The HCX gateways will audit these header values in the database to learn the path of message relaying from one gateway to another gateway and submit callback responses back to the source gateway from which it received the message during relay.
When sender participant submits the message to the first connected gateway x-hcx-source-gateway-domain-code will be null and x-hcx-destination-gateway-domain-code will be populated with the gateway-domain-code of the connected HCX gateway. The HCX gateway interceptor will check the x-hcx-destination-gateway-domain-code value in ProtocolHeader .if the suffix in the participant recipient registry code i.e. x-hcx-recipient_code (e.g. PAYOR01@HCX1) is same as the gateway-domain-code of the HCX1 gateway (say HCX1), then it means the recipient participant is registered in the same network of the HCX1 gateway and HCX1 will forward the message request to the destination participant without using any relay service.
In case the suffix in the participant recipient registry code i.e. x-hcx-recipient_code (e.g. PAYOR01@HCX2)is not equal to the gateway-domain-code of the HCX1 gateway then the HCX1 gateway invokes the relay service to route message to next destination. The gateway relay service will look up the routing table maintained in the gateway (All gateways will maintain the routing table with details such as gateway-domain- code, gateway-identifier, gateway-endpoint_url, gateway credentials). This routing table will be used by HCX gateways as DNS lookup enteries. The gateway will look up the gateway domain code of the recipient participant in the routing table to find the endpoint url of next gateway which matches the gateway domain code retrieved from the suffix of x-hcx-recipient_code and the gateway relay service will hop the message payload to the next gateway in the hop chain . if the routing table lookup does not find the exact matching gateway, the gateway finds the next intermediary gateway in the chain based on the neighboring gateways connected to any gateway or any precomputed paths to reach the destination gateway stored in cachemappings. The precomputed path tables will be dynamically updated based on least distance algorithm between a source and destination gateway based on previous hop details and the details. If there is no match found for any destination gateway, the HCX gateway will return the Acknowledgement to the sender participant with a proper error message.
Before relaying the message payload to any intermediary or destination gateway, the inbound gateway (which received the message payload from the sender participant) will update the x-hcx-source-gateway with the domain code of the sender gateway (which is the inbound gateway domain code of same gateway which is forwarding message to next gateway) and x-hcx-destination-gateway header value with the domain code of the gateway of the next intermediary or destination HCX gateway in the hop chain. The x-hcx-source-gateway protocol header value will be used by any intermediary or destination gateway to return the callback response to the gateway from which it returned the request in the hop chain.

The HCX gateways may be designed to use Async message patterns and dedicated message queues (Kafka message queues dedicated to each subscriber (different HCX gateways) and separate message queues for consumers (providers and payers) for forwarding messages as Async APIs to next destination.
The HCX gateways should implement Oath 2.0 extension (RFC 8693 for token exchange protocol across multiple HCX gateways. The token exchange protocol uses grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer with requested_token_use=on_behalf_of; in the most recent spec drafts on_behalf_of” was changed to “subject_token”. this activity requires the intermediary HCX gateways to play an active role in making this specific request; the identity provider must grant explicit rights to the intermediary to be allowed to make this request.

This token exchange functionality essentially enables an actor to exchange a token (such JWT Token) with one audience (presumably its own) for a token that describes the same user, but with a different audience from an identity provider. This is done in a secure manner, meaning there are significant limits placed upon which audience the new token may reference.

Two common forms of this token exchange are delegation, where the protocol provides a concept of the intermediary that is making the call (such as the WS-Trust ActAs), and impersonation, where the protocol provides no concept of the intermediary (such as WS-Trust On-Behalf-Of). The OAuth2 Token Exchange spec defines similar concepts for OAuth2 and OpenID Connect (OIDC); however, it uses the terms to mean the opposite of how they are used here.

Securing each step of the request’s journey

The sender participant will make API calls to the HCX gateway; identity information will be passed from the sender participant to the API gateway layer as access token and refresh tokens. When the request arrives at the HCX gateway, the access token must be extracted from the request and validated. This validation step could be performed locally, if the token is a JWT, or could be done by querying the identity provider’s OAuth2 Introspection Endpoint or other identity provider-specific mechanism. If necessary, a call can be made to the OIDC UserInfo Endpoint.
Some type of coarse-grained authorization decision will likely be made at this point. Finally, the access token that was passed into the API gateway with the request needs to be replaced with an access token whose scope matches the downstream actor’s (intermediary or destination HCX gateway) scope.

This is accomplished with a Token Exchange Grant call defined by the OAuth2 Token Exchange spec. The new access token is placed into the API request (replacing the existing token) and that request is routed to the intermediary HCX gateways during relaying of messages.
When the request arrives at the final destination gateway, the access token is extracted and Likewise, the UserInfo endpoint can be queried for additional information, a fine-grained authorization decision can be enforced, and possibly a new downstream token obtained for the end mile participant layer.

We expect that participants in intermediary exchanges will also be participants in one or more trust networks (i.e., a collection of policies, technical specifications, and interoperability criteria). The trust network among multiple gateways can be maintained by a Regulatory Body such as IRDAI or NHA.
The Regulatory body should also set up a testing and certification framework for all intermediary HCX gateways and the information about the certification status of each intermediary should published as a directory service (one option may be to register each intermediary HCX gateway in HFR Registry publishing details such as the gateway_endpoint , certification status and trust credential details.

Please provide your suggestions and feedback.

Thanks
Krishan

[abhimail]

Hi @krisaccessh,

Many thanks for the detailed idea on the HCX relay/Multi HCX scenario. We can definitely detail the HCX relay use cases in much more detail using many of the elements in your post above including unbundling detailing the the techno-functional parts from the regulatory parts.

I think we need to take it up with working groups for further detailing at appropriate time. As indicated in response to #5, point 9, it was not considered an immediate priority give the other pressing needs on getting the protocol working on ground (we may be looking at only a couple of HCX instances in near future).

We think many aspects of the idea are present in some shape and form in the current version of protocol and may serve the purpose for initial scenarios. We can choose to priritise and extend these further at an opportune moment. Few of the elements available in the current version of the protocol are:

1. As indicated in the “HIE/HIO.HCX” role in the Access Control section, protocol envisions that other HCX’s can be participants on an HCX instance thereby allowing for any kind of relay network to exist as per future needs.
2. By virtue of being another participant role, these HCXs can leverage the JWT (RFC7159) based Authentication and Access control mechanisms described in API security section as other participants. So, any HCXs that want to link to each other may become participants on each other and with an agreement to honour recipient HCX’s signed JWT token. This is quite similar to auth needs described in your idea.
3. Depending on the state of the ecosystem (number of HCX), there can be multiple approaches for participant discovery ranging from simple to advanced approaches. E.g. in a simpler configuration, registry lookup of the HCX registries can be used for figuring out PATH to the final destination (as every HCX can be a participant on other HCXs). More advance ecosystem states may use IANA/ASN kind of mechanisms to perform such tasks.
4. As indicated in response to point 9, easy tracking of the relay may involve including new relay related headers (as also suggested by you) populated at each hop (similar to HTTP forwarded header in RFC7239).

I suggest that we bring it up for prioritisation in our working group discussions.

Best regards,
Abhishek