Integrating NDHM Health ID

[Venu_Gopal]

Hi, In our mobile app that is to be launched shortly we integrate with social identity platforms, and add SMART on FHIR launch scopes. Our authorization server attaches FHIR scopes, issues access tokens to perform CRUD on our FHIR server. We plan to leverage this and integrate with NDHM Health ID. For this I would like to know, if the NDHM Health ID APIs can return a callback after authentication is complete to a custom URL I specify ? If it can be done, then I would also like to know what protocol is NDHM using currently to generate the Health IDs. Is it OIDC, SAML…? It is important to know this, as this would effect the parameters needed from NDHM to integrate into the app.

Please don’t confuse this with DEPA. It’s okay if this can’t be supported right now, although it would mean, I have to strip off the authorization flow that I currently have

Thank you

[Venu_Gopal]

Hello there, any advise on this will be good. Can I specify a Redirect URI while using the HealthID APIs ?

[angshuonline]

As of now, HealthID can be generated either through the website. There are ways to validate and health-number (the 12 digit number) offline.
Healthid (the human readable id - an alias) can only be generated and validated by the user himself.

The FHR systems provides means of authenticating user using the /users/auth/* API - for specific purpose - e.g. KYC, LINK etc. And they provide a callback means when the user authentication is done.
Wouldn’t that be enough?

@ashok can you elaborate further on offline verification of the health-number?

[Venu_Gopal]

@angshuonline

TL;DR - I am currently pursuing a secure web access (SWA) method where this can be achieved, even if NDHM doesn’t want to provide a redirect URI. The redirect URI I’m mentioning here is not same as the async callbacks issued for HIP/HIU for KYC & LINK. In the async callbacks the user is not granted any access token and therefore no further refresh token. As a HIP/HIU, I get a linking token to link the user’s records

1. As a health services consumer app, we only want to enable users with a same sign-on options. We are implementing google & Facebook with same sign-on. We want to add HealthID as well.

2. By definition we don’t qualify as a HFR. Even if we do, the /api provides options to authenticate user, by means of collecting user credentials. The way this is done currently is as follows

3. As a HIP or as suitable role, I get a valid Auth token by calling the /sessions api with my clientId/clientSecret

4. Then I invoke the /api routes using the Auth token & X-HIP-ID header and other relevant headers, by collecting users HealthID, password/OTP/mobile token.

5. Successful response would issue a two hour access token for the user

6. Unsuccessful response would mean the user is denied access

7. Then if I like, I can send this token to my authZ server and attach FHIR scopes and provide further processing

8. In this process the user is inputting their credentials in my app’s client. Although, I will take all necessary steps to safeguard the user credentials, it need not be like this

9. NDHM has already provided ClientID/ClientSecret. So, if I can specify an option of Redirect URL, then the user can be directed to an NDHM login page, after authN they can be redirected to the redirect URL. This is how it works with OIDC/SAML/AD & others. Simply put, this is same sign on

10. I am currently pursuing a secure web access (SWA) method where this can be achieved, even if NDHM doesn’t want to provide a redirect URI.

11. The redirect URI I’m mentioning here is not same as the async callbacks issued for HIP/HIU for KYC & LINK. In the async callbacks the user is not granted any access token and therefore no further refresh token. As a HIP, I get a linking token to link the user’s records

12. How would same sign-on benefit a user ?

13. The user can consume the services on the app platform like appointments, nutrition advise, lab tests, health locker using their healthID itself

14. The user can easily integrate with their health Locker(if they chose to get a service) without having to reveal any of their identity, attach their relevant health records (Family history, discharge summary), while seeking services

15. This would enable easier linking of care contexts at HIP/HIU after, as the appointment/Encounter requests already have HealthID

16. The specs for Health Lockers haven’t been published yet, and therefore I can’t say with certainty about accessing the health locker, but if it’s done as the above consent management would be easier. I don’t want to look at other reference implementations

17. Since this is an online service, offline verification won’t suit our use case

PS : All views expressed are individual and from a patient point of view, and can change as more knowledge is gained

[angshuonline]

I think there are 2 different concerns. A service provider and a patient perspective …

1. You get keys for a servicing entity - HIU/HIP/HRP/LOCKER etc. Note that there is no “single credential” (clientid/secret) across capabilities. As of now, an org servicing as HRP or LOCKER, needs to be registered for their unique services.
2. You can use the “credential” as a HIP or a LOCKER but you only get access (using token) to APIs that are meant for your capabilities.
3. /user/auth APIs are meant for specific purpose for a specific requester (HIU/HIP/LOCKER). This is not meant for users at all. We are bringing in DIRECT authentication mode soon, but then again - its for user to grant /auth request for a purpose. This is not same as SAML/AD, and this has nothing to do with SSO.
   in FHR, Gateway works as the IdP.
4. For a patient, HealthID service acts as IdP and provides SSO features across healthId and CM/PHR functionality. If you really want to build a patient facing app, then you ought to be talking to the HealthID service, not the Gateway.
5. Lastly, I don’t think NDHM healthID service would want to act as SSO, providing sign in tokens, for services that you want to provide to your end users across apps that may offer. All it does, provides a means of validating the identity of the user in the healthId service.

@kiranma any other thoughts?

[Venu_Gopal]

To your point #4, yes I really want to build a patient facing app, and therefore want to talk to healthID service. In the process I don’t want to be collecting the user credentials, its for NDHM to do that, authenticate and grant me a response. Amen !

[Venu_Gopal]

@kiranma @angshuonline please advise what scenarios the patient can use the HealthID and why would they need to be provided an accessToken if this is not meant to consume health services ? Why would they need to share their credentials with HIP/HIU/HRP/Health Locker ?

[angshuonline]

Are you getting confused about who gets “accessToken” for what @Venu_Gopal?
For the use case, please refer to the “HIP Initiated Linking” in the sandbox documentation.
You can also refer the API specification for details.

A HIP gets an “accessToken” for a purpose (e.g. LINK) only after auth from user. This is not a “accessToken” of the user! HIP can use this token only for the specific purpose - e.g LINK a care context.

User gets a “loginToken”.
Hope there is no confusion anymore.

[Venu_Gopal]

No I am not, I am asking about the loginToken as you mentioned. How would the patient use it and why would they have to submit their credentials to the HIP/HIU to get it ? I explained everything clearly and steps taken, I can repeat myself it helps. Please look at the screenshot, the response of this request is a loginToken as you mentioned. How would the patient use it ?

I just generated a token using the https://healthidsbx.ndhm.gov.in/api/v1/auth/authPassword and attaching the X-HIP-ID and authorization Bearer token. Below is the response. Decode it and you will see the token is issued to the patient and not to the HIP. What would the patient do with it ?

eyJhbGciOiJSUzUxMiJ9.eyJzdWIiOiI0NS02MjE1LTc2NTAtODUxOSIsIm1vYmlsZSI6Iis5MTg4ODQwMjQ0NDAiLCJoZWFsdGhJZCI6InNhbmRib3hAc2J4IiwiZXhwIjoxNjAyMTUxNzM4LCJoZWFsdGhJZE51bWJlciI6IjQ1LTYyMTUtNzY1MC04NTE5IiwiaWF0IjoxNjAyMTQ0NTM4fQ.K4Iju0QxHN3CArQYK2RgRFrYSswvGo6VuE13aWvSNGu5PACSPUzxoZ7xH_9pLY7Q0gRGXjsZoUJTazlVTzky9zxKmgJbpUF2TNM1c-VTw39Xf_4GApcJ79Ad7HA90TFFyZSHmdNjK4G4JTWVYYWgXOTrWQxIQi-pM4finFMKk9688-APMURp7foGDyEqModhBiO3R3Zq5HVkdCM-5YIjPOVFafDe54QwAo8cIISyst6-rbFMB3Vs_QVkq0dLh3UY0u0fFh0Z9CXne4jMMhsxb3NKPZaAlEncYJYRg4aFZTIb6taLqNzuGIKaj7BauLNs6LTEtuYlQaJKKlfaI4jqYIZBVk6MOuj8ojIapnnB-Swo1aGmvnh259YDqne4Z9eBBVy4OucpZyXuExOMEy9XA-khkSCf4y9jghTYcPH6OO4tx3OaeWw5MHuRlXOTtTXcDh4bowY0fABZLfCxxYpEH63ZBwHg_UxCBcikKvLS2NFlxvFBfYKRaaX159vaGUkMVMCi-zVcr8ZjuX0QeMI3Fj-l-SHzeze7PMAQLwvukxjuINz34MVuKMFjHLKAQmt1IkZVBtXqNgZXS77gsC9OVfdMqDid53AgrrkXXCzRYaviOFoBo_Q9JPw6hzopTEXFMrxWEZX9zjk1dfiXVQEQ2D-EF_5RHSkdsPgGQBFCRhg

.

[angshuonline]

Excuse me for my ignorance!

• User does not pass his/her login credentials to a HIP/HIU - in a hospital/doctor interaction context.

• Access to the healthId API likes /auth/authPassword is only for designated services that would want to create HealthId and/or build apps/services while leveraging the Health Account Service (HAS). Whether you are allowed or not, will depend on your application/services that you provide and depends on the NDHM committee/certifying-authority.

• HAS is not a SAML or OAuth service provider. So even if you are granted access for the above, you can’t use it as means of centralised authz provider for downstream services like appointment or such. If you want you can build your own. In that case, you will likely not have direct API access to HAS, but can leverage the Gateway APIs to identify a patient/user. Like any other HIPs, you can keep a link with the healthId

• The X-HIP-ID and the Authorization headers are meant for services that are leveraging the HAS to create user/patient accounts, or for providing patients to have direct access. The Headers are used by HAS to identify the requester (services that act on behalf of the user) and check whether they have access or not.

Hope the above is clear.

Attn: @ashok @kiranma an you verify the above please? or anything that you want to add.

[Venu_Gopal]

Thank you for your patience. Let’s not worry about AuthZ for now and stick to the HAS. The identity provider will always have a say, in this case NDHM, need to certify and do periodic audits of the apps, that consume the HAS APIs, and is a fair point

1. The HAS APIs /api/ (https://healthidsbx.ndhm.gov.in/api/v1/auth/**) are designed in such a way that a patient enters their credentials - HealthID/Password in the app client. The app then collects this information, wraps into a https request, attaches valid headers and send to the HAS service for authN.

2. This effectively means the user is handing over their credentials to the app client, subsequently to the HIP/HIU. This is a violation of user/patient security, notwithstanding the strict controls and right intent

3. Instead the user should be directed to a HAS service login/authentication page/service, enter their healthId/password, after authentication by the HAS service, a response is sent back to the Redirect URL of the HIP/HIU app with a valid response (success - with a loginToken , failure - access denied). Currently this is not the case

4. The app can then decide what AuthZ scopes they would like to attach and how to source the information requested using the Gateway APIs or Lockers

I think this could be achieved in multiple ways, but the HAS service should start accepting a callback/redirect URL ( a sub-domain like https://login.app.com). This may not the same as the callback URL provided for the gateway responses (https://www.app.com) and please don’t get confused !!!

[angshuonline]

@kiranma would be probably be the best person to comment on access to these APIs, and whether HAS has plans of being OpenID compliant.

[Venu_Gopal]

@kiranma @angshuonline it would be really solid if HAS can be made to an OIDC, but its entirely up to NDHM to decide. On the other hand, to provide a redirect URL functionality for the HAS authentication service, it needn’t be an OIDC. The gateway /bridges api or a new HAS /bridges API could be created to upend a redirectURL. The HIP/HIU app can use secure web access (SWA) to authenticate a user/patient. This is different from UPI.

NPCI provides the UPI tech stack to authorized service providers, after the UPI PIN is validated no session is granted to the payer.
Where as even if NDHM provides the tech stack only to authorized HRPs (or HIP/HIU) a session is provided to the user/patient. There is a chance for user credential leak at the client level or while offline verification. The parties may not even know that this happening. This is a security risk

I would be happy to involve in further discussion, or let me know if I am wrong and why this is a non-issue

[Venu_Gopal]

Hi @kiranma this needs a response, please

[kiranma]

@Venu_Gopal Thanks for bringing this up.

Having the Health ID service support OIDC (or an alternative) is one the items under active discussion on the design side. We feel that this may be a good way to provide access to a the set of consent management APIs which are currently private between the NDHM PHR app and the Health Data consent manager.

The current approach we have will force us to restrict access to the Health ID APIs to trusted applications (probably only those from the govt) as there is a security risk with the crediential capture is in another application.

Even with ODIC, we are trying to understand the usecases (esp usage within mobile apps) and what the security risks. Happy to have inputs / pick your brains. Drop me an email at kiran@nha.gov.in and we will setup some time with you for a discussion.

[Venu_Gopal]

Sure, currently we are using a IDaaS. we can either leverage or co-create one for India. I will email you

[Venu_Gopal]

@kiranma @angshuonline Need clarification on this. Its been sometime, we had the meeting with some follow up action items. I would like to know if OpenID will be implemented or not. The important piece to the PHR is the login, and therefore it should be an OpenID if NDHM wants to allow multiple vendors operating PHR. That said, when are the specs for the PHR/HealthLocker going to be announced ?

Please clarify

Venu

[angshuonline]

@Venu_Gopal I think the last webinar would have clarified?
Health Locker Specs are going to be available very soon. By PHR, I am guessing you meant the CM APIs that can be leveraged by others - well that can be brought in only after the OpenID Connect enhancements. As Kiran said, it maybe be another 2 months, considering policy and/or guidelines.

[Venu_Gopal]

Hi @angshuonline, yes. I posted this before the webinar But I have an other thread for you to look at

HealthID OIDC & PHR scopes, consent mechanisms

Thank you for the webinar and indication of expanding the HealthID as an openIDC. I assume this would be done to DigiDocID (which later may be workForceID) & FacilityID, as it was suggested to have different IDs. That said, there is no reason why one HealthID can’t serve for the other aspects as well. But this is a NDHM decision I would request to add PHR scopes on the NRCeS FHIR profiles being implemented, much like an activity of an authorization server. NDHM need not be a FHIR server to do t…

Let me tag you there