Questions about CommonHealth client credentials

[minrk]

@surfdoc has provided me with credentials for Jupyter Health and Jupyter Health Testing.

I've placed the two sets of credentials as KV pairs in aws secretmanager in our aws project: ch-health-creds-[prod|testing].

My questions so far are about credentials and their lifetimes/lifecycles

• client id/secret are used to communicate with the CHCloud API. That means that anywhere we want to talk to this API, we must provide these values, i.e. to users of the Hub, so they can call ch_client.fetch_data(). Right?
• The private signing key (it's actually an encryption key, right, not just signing?). Is it one per application? What happens if a key is lost or re-issued? Can there be more than one?
• Deep links are specific to (patient, partner, key), right? Does it make sense for one part
• What exactly does the storage delegate store? So far, I've found the patient id:random id mapping and the private key(s), is that all?

What I'm trying to get at is what does "Jupyter Health" have access to, vs what does an individual Hub user have access to, and how can/should they differ (e.g. subsets of keys or shared keys, etc.). This will affect what credentials we load into the Hub user environment, and the presumably custom StorageDelegate class that we will use, because SQLite isn't going to work for shared state. For example, I see these broad categories:

1. single shared storage delegate for everyone on the Hub. Necessarily means everyone has access to all data associated with a given partner
2. each user has entirely their own storage delegate, not shared with anyone else - no users can access data created by another
3. 'project'-level, where there is more than one storage delegate, where each user has access to one or more storage delegates, and each delegate may be accessible to one or more users

Which of these best represents the credential/access patterns we expect here? In particular, does 3. make sense where a single 'partner' might have different users with different access scopes, or does this generally mean creating a new 'partner', and keys should be considered an implementation detail?

[surfdoc]

@minrk

• You are correct regarding the need to pass api client id and secret for any api request including fetch_data.
• The private signing key is also an encryption key. It is one per partner. If the private key is lost or re-issued, the associated public key can updated with a new public key in the CHCS service. However, any previous data encrypted with the old public key will not be able to be decrypted since the associated old private key is lost.
• Deep links are specific to patient, partner, key, and requested scope. The deep link is unique per patient since it includes the mapped patient_id that CHCS will utilize.
• The storage delegate is exactly what you identified, it stores the patient mapping so CHCS has no way to know patient id in the originating system and it houses the private/public encryption key info.
• Something to take into consideration is that this authentication architecture is intended only for the pre-MVP.
• You have pointed out all of the reasons why we want to stand up a SMART on FHIR authentication server post pre-MVP in front of the CHCS patient data store. This will enable leveraging OIDC and OAuth2 and provide granular access to the patient data down to the individual Hub user level and scope for that user. This would also remove the need for private/public encryption keys which leads to lost decryption if that private key is lost or reissued.

[minrk]

Got it, then I think I know what we need to do for pre-MVP on our side:

• make sure key pairs are issued for the two applications
• provide Hub users with client id/secret
• single storage delegate shared by all users (I have a very simple AWSSecretStorageDelegate working, but this isn't scalable to more than a few patients for demo purposes)
• single private key issued/managed by hub (me), provided to users, but not modifiable by users

[surfdoc]

Sounds great. Once we have the SoF auth server integrated with CHCS and in a testable state I will reach out and we can begin testing the better auth flow.