Hippocrat Wallet SDK
Last updated
Last updated
The Hippocrat Wallet SDK is an open-source development kit that empowers data subjects to construct data wallets that govern their identity, data acquired from organizations, and rewards earned from data sharing. Keeping a person's data in a data wallet is akin to holding a key card or receipt that grants access to that data, rather than storing the original data itself. This is comparable to owning a wallet that contains not just cash or credit cards, but also IDs, membership cards, tickets, blood donation records, keys, receipts, and more, which can be accessed whenever needed. If you misplace your wallet, you lose everything in it, indicating you have complete control and, consequently, full responsibility. The same principle applies to data wallets.
In this section, we'll present the primary features we aim to incorporate in the Hippocrat Wallet SDK. The majority of these are grounded on open standards and open source, enabling us to add value centered on the problem Hippocrat is tackling, rather than reinventing the wheel, using already proven technology. This strategy minimizes potential intentional and unintentional bugs that might occur in new software while still enjoying the ongoing enhancements and innovations facilitated by open standards. Moreover, it allows the user's assets and data in a wallet developed with the Hippocrat Wallet SDK to be accessed through various applications, augmenting the user's utility.
The Hippocrat Wallet SDK's fundamental function is to securely generate and store the private keys required for accessing and managing your assets, data, and decentralized identity (DID). Owing to its compatibility with the BIP39 standard, it offers the same level of security as most Bitcoin wallets for private key generation and mnemonic code recovery. Hence, the Hippocrat Wallet SDK can also be utilized to implement basic Bitcoin wallet functionality. The device's trusted execution environment (TEE) can be deployed for added security in private key storage.
Once a DID is established, it facilitates peer-to-peer connections with the organization accessing your data without any intermediaries. All data and messages shared between the two parties are encrypted end-to-end, ensuring that only those involved can view the contents, thus minimizing the risk of privacy breaches during communication. The initial connection is usually initiated by scanning a QR code or clicking a button on the organization's app or website. Users then verify and approve information about their connection partner, including permissions and data requests. Once connected, the relationship is remembered as a trusted association unless terminated by either party.
In the healthcare context, hospitals often require patients to register as new patients during their first visit. This involves pressing a registration button and scanning a QR code with their data wallet, which requests them to share their legal identity: name, social security number, photo, gender, etc. If the patient consents, a hospital representative verifies the patient's identity from their data wallet, and the patient is registered.
This approach eliminates traditional logins and other authentication methods, eradicating the need for users to generate and remember usernames and passwords for every service they wish to connect to. It allows users to log in, authenticate, send and receive assets and data, and more, simply by recognizing a QR code. The data wallet application can also use additional security measures such as PINs and biometrics in tandem with the private key, providing effective multi-factor authentication (MFA) and a much higher level of security than typical login methods.
When linked to an entity, say a hospital, through a data wallet, original data or its certificates can be mutually exchanged as per your request or when the other party sees fit. Usually, when a hospital dispenses data like medical records, they undergo an authentication process to confirm the patient's identity before issuing it as a VC to the patient's data wallet. A notification and a message alerting of the new data issuance requiring authorization is then received by the data wallet. Upon authorization, the data becomes accessible. Unlike conventional cloud storage, the user's encryption key secures all data.
Such data can be showcased wherever required. For instance, a data-driven healthcare service might ask the patient to scan a QR code to obtain particular data necessary for service provision. On scanning the QR code, the patient views data usage details and the terms of use by the service provider. If approved, the data is shared with the service provider, who then verifies if the data hash matches the issuer's hash and if the issuer is trusted. Upon validation, the patient gets the necessary service. This process, though intricate, is handled by automated software at high speed, making it seem like a simple authentication process for the patient.
In certain situations, you can choose to share only some parts of your data, avoiding the need to disclose potentially personal information. Consider a case where you need to verify that you're the legal guardian of your child. Initially, you have information about your child and your relationship with them in your data wallet. A representative at the hospital will request you to scan a QR code to confirm your guardianship. After scanning and authorizing the QR code, the system only confirms your registration as the patient's guardian, without exposing any personal data. This approach, called zero-knowledge proof, is sufficient because the hospital staff only needs to verify the actual guardian and not their personal information.
Consent only requires the user to click the consent button. However, with a data wallet, you can easily view what you've consented to, and if you want to withdraw consent, you can do so at any point. Traditional methods often require cumbersome processes or even separate forms to withdraw consent. In contrast, a data wallet offers maximum control over your data even after you've given consent.
Furthermore, any data a user consents to share can be signed with the user's cryptographic key as a type of watermark. This ensures that any organization possessing data without this watermark will have to prove their legal acquisition of it. This strengthens the security of data circulation.
The inherent issue with traditional consent acquisition is that users are "forced" to accept terms and conditions to evidence consent, which primarily safeguards the service provider rather than the data subject. Lengthy and complex terms of service and privacy policies often discourage users from meticulously reading and assessing them, leading to 'insufficient consent'.
To tackle this, Hippocrat will introduce a standardized policy license that balances data subject protection and reasonable usage. If multiple services share identical privacy policies, users can be assured of uniformity without painstakingly reading each one. Once read properly, users can accept the same privacy policy license across different services, even setting it to auto-accept if desired. This enhances user convenience, protection, and companies' consent acquisition rates.
Any non-standard terms or previously unagreed terms in the policy will be isolated for separate consent. Users only need to review the changes or additions, fostering more confidence in their consent decision. These licenses will be overseen by a decentralized governance framework to guarantee trustworthiness, which will be elaborated on under Governance and DAOs.
Healthcare data, to reach its full potential, needs to be collected and utilized on a global scale. This can be accomplished by providing data subjects with value-added services that arise from the use of their information, or, where there is no immediate service to offer, by compensating them accordingly. In this regard, it's essential to support assets that enable quick and cost-effective data transfer on a global scale over the internet and to store and exchange it via data wallets.
Bitcoin and dollar-pegged stablecoins serve as the best assets for this purpose, particularly with the evolution of the Lightning network, which facilitates the transmission of small amounts of money worldwide at credit-card-payment speeds, with fees of less than 0.0x dollars. Moreover, advancements in technologies such as Taproot and Taro will facilitate the management and transfer of stablecoins and HPOs on the Bitcoin and Lightning networks. Consequently, Hippocrat and the Hippocrat Wallet SDK will be developed to align with these technologies, enabling global rewards through data collection and utilization in a form of assets preferred by users or businesses.
Since data wallets contain an individual's valuable assets and data, a secure method to back up and restore them is also crucial. By default, users can back up the mnemonic code displayed during the creation of a data wallet by BIP-39 by writing it down in a secure location. However, this method may be unfamiliar, and many individuals might be uncomfortable bearing full responsibility for it. To address this concern, we plan to support the encryption of your mnemonic code with a password of your choice and storing it in your preferred personal cloud storage, such as iCloud or Google Drive.
While this method is generally unsuitable for storing large sums of money, it may be an acceptable compromise for most data wallet users, as it reduces the risk of losing the mnemonic code. Of course, users can opt for a more secure method and avoid storing it in private cloud storage. As we adhere to Bitcoin wallet standards, methods to enhance the security of Bitcoin wallets, such as multi-sig wallets and adding passphrases, can be implemented in almost the same way.
On the other hand, maintaining assets in a customized Lightning wallet up to a certain limit and transferring them to a self-managed wallet beyond a certain amount is also a viable strategy. This helps strike a balance between user-friendliness and security.
Notifications are necessary to ensure that users see required notices or consent requests in a timely manner. To effectively get the user's attention, we will only utilize the device's system notification features when consent and signatures are required.
While wallet owners and data subjects are typically the same, many patients may find it difficult to manage their own data wallet for reasons such as health or technical literacy. In these cases, you can provide the ability to designate a proxy at the data wallet level to allow someone else to make decisions about consent and data sharing on behalf of the patient. In this case, the wallet user with the proxy status can have the ability to store and control the data subject's data in the wallet on their behalf.
These representatives can be individuals, such as guardians, as well as entities. Extending this functionality, it is also possible to implement a guardian to take over the patient's assets and data upon the patient's death. While further verification is required to ensure that this is permissible under national laws, identity authentication for representatives and guardians can be implemented electronically through the verifiable credentials (VCs) described earlier.
