Fraud Prevention - SSO Account Sharing Across Deployments

[carrollgt91]

If we allow for multiple, entirely decoupled deployments of the PIS system, we open up the following possibility:

Let's say we have an application that is attempting to use the PIS system to verify a positive COVID test result within the past two weeks in order to distribute aid to that person. They have a SSO with PIS feature that supports the OpenMined-hosted PIS and the Amazon-hosted PIS. User A has tested positive with COVID a few days ago.

He signs up for the OpenMined PIS and verifies his test results there. Then, he has his friend sign up for the Amazon-hosted PIS, but he then links his test results account to his friend's Amazon PIS account, and his friend signs up for receiving aid and gets it.

[H4LL]

With respect to counterfeit or cloned test results. With verifiable credentials, I'm pretty sure that there is a way for a way for a verifier to know if a proof came from the same master key as a previous one. Having said this, we want to ditribute the PIS service across multiple entities so I don't know how enforceable this will be. I'm sure @wip-abramson can provide more to the discussion there.

If we assume that we can't rely on the beign able to detect multiple uses of the same master key, we may still be able to solve this by appending additional attributes to test results credentials. We would Ideally have credential type issued by the diagnosing agent with the following attributes;

Name of Patient: (string)
... (whatever other identifiers are necessary/ useful)
Address of Patient: (string)
Patient Diagnosis: (result type)
Date of Diagnosis: (dd/mm/yy)

These attributes have been verified along with the results and can be queried individually or in aggregate (https://misterwip.uk/cl-signatures). Theoretically, the service who provides aid could request the following information (as testified to by the medical professional) before releasing aid;

• Proof of Qualifying Diagnosis
• Proof of Address of Patient
  -(Proof of multiple occupancy?)

Even in cases where users send share their master key, they can't spoof the proof of address issued by the diagnosing agent. Once that address has received aid, the service provider knows not to send it again. Additionally, I won't have a valid proof of address unless I am deemed eligible by the diagnosing agent. In cases where houses have multiple occupants, this can disclosed at the time of diagnosis and attested to by the diagnosing agent. We could work out logic to accomodate for that also!

[wip-abramson]

These two links may be useful

• https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.md
• https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/zkp-safety.md#technique-7-link-secret-bond

[carrollgt91]

@wip-abramson @H4LL beautiful, these address the cross-deployment account sharing issues quite nicely. @H4LL, your suggestion really fits in with the strategy described here, and I think we can make use of this strategy even before we've fully integrated with the DID systems.