Use Case - Vaccination Cards

1

Hi,

I am new to Solid world and so I thought, it will be helpful to share my understanding as a layman. Just to make sure that I am not treading a wrong path from the beginning itself.

As per my understanding, Solid aims to be the single source of truth for data about user.

So a user’s Pod is the primary source of truth for any data that the user generates. It will only be a secondary source , if the data is generated by any other entity, be it Government , public or private institution or person.
The entity that creates the data, doesn’t have the store the only copy on user’s pod, and access it always from user’s Pod.

They can remove unwanted data and transfer the responsibility of the data to user.

Example :

Government needs to create an Identity ( Like License ) or certificate ( like a vaccine certificate) for a user.
The user shares his data from Pod to government to create the identity or certificate. The government creates the certificate, based on the data it owns and also the data the user shared .
Government posts the certificate back to users pod.

In the above scenario , government does not need to take the responsibility of the security of User’s Pod. If the data, that is being read from User’s Pod is injected or malicious, they only have to sanitise the data or reject the data.
Also , the Pod, that the user shares with the government is same as any mail id or number provided by the user right now. The government does not need to take responsibility of the mail server used by User.

Here the government can hold the data that was used to generate the certificate, and offload the responsibility of storing the certificate to User. In case, the user want’s to generate the certificate, government can use the same data to create the duplicate. Or the government can delete all the data, once the generation is completed ( this can’t be enforced ).

The above stands valid for any transaction between two entities. User and Hospital. User and User etc.

The hospitals and labs creates reports of the patient and shares it to their pod. Same as sending the reports to their mail. They can store a copy or delete it .
But it is the responsibility of the user to securely store it .

I haven’t used the BBC app. But , as a layman, If I have to visualise the app. I don’t see any need for them to be worried about the data, they read from User’s Pod, as they can sanitise it or reject it.

Please correct me.

2

I prefer this scenario - agency asks user for data, generates certificate and gives to user, destroys data, when it needs to verify, asks for certificate. That’s the user’s data, the agency has no business storing it.

Here’s an example where a city has a rule that no candidate can receive over Y amount and the city wants to preserve the citizen’s privacy but also ensure that the citizen lives in the city :
donor2

2 Likes
3

Thanks Jeffz for the scenario.

If I understand the scenario correctly.

  1. Susan’s privacy as a donor needs to be maintained.
  2. The city needs to regulate the amount that the candidate receives.

Susan applied for eligibility to an agency and the agency issues an eligibility certificate.
Susan presents this certificate to a matching app along with the amount and candidate.
The app checks the city database for the allowed amount and if the amount is within the limit, it gives the amount to the candidate.

Here the certificate is for one-time use and if Susan misses her certificate, she can supply the same data and generate another certificate.

But in some situations, specific certificates can’t be created with the data that the user has. Or the User can’t be the authority of the data that needs to generate the certificate.

Example: Consider Covid vaccine certificate.

The user can be the authority for the details related to a user.

But the Agency that took the vaccine is the authority for the details regarding

  1. Which vaccine was taken
  2. When it was taken.
  3. How many doses were taken.

Etc.

The agency shares this information with the city, which issues the certificate. The city needs to record this information if the user needs a duplicate certificate.
Also, the city is the authority regarding the validity of the data.

solid_vaccine
solid_vaccine701×741 77.3 KB

4

Well, the part you left out is the data that belongs to Susan. Does the city store herr name with her vaccination details? It shouldn’t in my opinion - aggregate data, yes, but not her name.

1 Like
5

Yes, I missed part where Susan’s data is needed to complete the certificate.
I was assuming that, the token that is submitted to the vaccine centre is the key that city can use to fetch the user data from city’s database.

By city’s database means, the data that city collected to issue an identity to Susan. Susan applied for token using this ID or number.

The vaccine centre submits the vaccination details along with token back to city. City can use the token to trace the user and complete the certificate.
I think, if city has issued the ID , then city is entitled to store this data, as city is the authority that validates this data.

What if the ID is issued by one agency and vaccination is conducted by another agency. Can any of these agency store data, that the other agency provides, to complete the certificate.
Well , in that case, the issue is no more related to Solid or RDF .

I think we are dealing with fragments to data, which needs to be encrypted , signed and passed from agency to agency , who fills their data , signs and encrypts it , which only the user can decrypt and combine into a single document.
The authenticity of the data in the final document can be verified using individual signatures. I am sort of bluffing here :slight_smile: .

6

If none of the user’s data is protected, what is the point of using Solid?

8

@Vincent
Sorry , I didn’t meant to deviate the topic from BBC app.

But on discussing the technical implementation of the app, I was confused on seeing a debate on the basic philosophy of Solid.
So just wanted to clarify.

9

@jeffz I think Solid proposes a storage solution, with access control to expose data.
But the nature of the data cannot be governed by Solid. Also, who holds what data.

But a storage solution with access control to data along with interoperable capability of RDF, itself is a great deal to tackle some data privacy issue. It is only that, we need to identify, who is the authority of what data.

Actually , that was what I was trying to put forward in the BBC app discussion.
From the ideas and concerns that is shared, I genuinely feel, there needs to be a discussion on the nature of data and its ownership.

10

is indeed a great combination in itself. But does not benefit from what makes Solid different from other approaches - the ability to allow each person control over their data. No one is, I think arguing that you shouldn’t build apps that omit this feature, just that you shouldn’t advertise those apps as showcasing Solid’s ability to protect user’s control over their data.

11

I totally agree. If you built apps claiming to be Solid compliant , then it should adhere to all the standards and specifications.
Especially, going a step forward to lock the pod, to protect user’s data doesnt sound “Solid”.

12

I’d encourage you to look up Verifiable Credentials and Verifiable Presentations, for the use cases you’re describing they’re generally more applicable.

User presents a verifiable credential or presentation of their identity to the vaccination center, vaccination center uses that to generate a verifiable credential of the vaccination certificate, that then gets stored in the users’ pod.

At each step, the data can be verified through digital signatures (cryptography) and you can transmit them between devices using QR codes (because contactless, yay)

For the lab work one, it’s much the same, user presents doctor with ID + Health Insurance verifiable credentials/presentations, doctor issues a verifiable credential requesting blood work, user stores that in their pod (or wallet app, separate topic). Then the user goes to the laboratory for blood work, shows the verifiable presentation of their ID or Health Insurance + the verifiable credential saying they need blood work; the lab can prove the doctor issued it, and it’s for you because you’ve your ID certificate; they send you an access request as a verifiable credential to write/append to a certain container, you approve, you get the blood taken, it’s labeled with the patient’s QR code, they leave, the lab does it’s thing, and generates a certificate for the results and uploads it to your pod using the access grant, and then you take that certificate to your doctor who can verify it came from that lab & hasn’t been tampered with.

That said, all this tech all kinda already exists to varying degrees, and it’s well worth reading the existing solutions before dreaming up new ones, just in case there’s something specific in that domain. (Edit: I’m also by no means an expert in VCs and VPs, this is just my rough late night explanation/understanding)

2 Likes
13

@ThisIsMissEm . Thanks for the explanation. When i was suggesting encryption and signature, I was talking about verifiable credentials. Since i haven’t researched about it in depth, I didn’t mention it.

Thanks for stating about verifiable presentation. Helped me read more about it and understand.

Yes, there is no need to dream about new tech. It is only that, we need to have clarity of what to use from existing tech stack. Also, understand the purpose and limitation of each one.