Suggestion to add a global "g2p" prefix for the G2P protocol in URL segments and JWT scopes #17
Replies: 3 comments 3 replies
-
:-) Indeed @vvujjini did suggest this earlier. I was thinking that this can be left to implementation (maybe as a recommendation) instead of "mandating it as a standard". What do you think? |
Beta Was this translation helpful? Give feedback.
-
My concern is if it was not there, would we have to provision a subdomain to handle G2P routes? If we already had in use a single API gateway for other external integrations, then having a subdomain that is bespoke for G2P could become an overhead? I think that it wouldn't do any harm, and it would allow implementers to be flexible in their infrastructure approach. The JWT problem would be quite a challenge to get around without a prefix, as the JWT header would get past through to downstream services where conflicts could occur. |
Beta Was this translation helpful? Give feedback.
-
@euanmillar added {namespace} to the API specs URI and to JWT token payload as well. I hope this will address this issue you called! (fyi) URI namespace will be visible in try payload section on the right. |
Beta Was this translation helpful? Give feedback.
-
Hi,
We are very excited to be part of discussions regarding the G2PConnect protocol and look forward to getting involved with the Civil Registry related specifications.
I have a general suggestion that I think would help DPGs incorporate the G2P protocol into their existing architectures.
For example:
would become:
If we adopted this, then we could use regexp to redirect g2p requests to compliant middleware that has been coded to handle them. My reasoning is that DPGs are often required to conform to multiple standards and additionally custom implementation needs driven by countries.
At OpenCRVS, our interoperability layer is by default designed for the FHIR standard and the FHIR API to support birth and death notifications from a hospital setting. We are currently developing OSIA compliant middleware that can mediate between FHIR and OSIA. Over the years, we have added additional GraphQL endpoints and sometimes some custom end points for implementation specific integrations.
We would love to develop G2P compliant middleware. A segment like this would help us route requests to the right place and allow us to conform to multiple standards.
For example:
would become:
This is because we already use a variety of JWT scopes in OpenCRVS. This prefix would make it easier for us to filter and avoid any conflicts in our existing JWT usage.
What do you think?
Beta Was this translation helpful? Give feedback.
All reactions