[CSE3000] Towards a Digital Foundational Identity

[devos50]

This ticket will host the meeting notes/progress updates for the CSE3000 BSc project.

For the next meeting (April 20, 10:00):

• Read the papers that we added to the projectforum description.
• Get the TrustChain super app up and running locally, see https://github.com/Tribler/trustchain-superapp.

[prodrigovalero]

Meeting notes 19/04/2021 Internal meeting to discuss research questions:

• Discuss initial ideas about each individual research questions
• Discuss potential overlaps and aspects to discuss in the meeting tomorrow at 10.00h with the professor + supervisor
• Reminder for Plan Week 1 deadline today!!

[devos50]

Thanks everyone for uploading the draft research plans to Brightspace! As you might have noticed, I rescheduled the meeting next week to Monday, 14:00. Rowdy will also join this meeting.

Best of luck on finishing the research plan! Below you can find some feedback for everyone, and feedback for each group member.

Generic feedback:

• Think about both your scientific and engineering contribution and state them in your research plan.
• As we discussed this morning, it is acceptable to keep generalisation in mind, at least for the first weeks, but please do not make it a main focus. It is better to deliver a finished product that does one thing well than something with many unfinished features.
• You might want to maintain a shared pool of interesting papers related to your research.
• Some of the research areas our lab is active (to determine a SSI application domain):
  • Decentralized file-sharing (https://github.com/Tribler/tribler)
  • Trust and reputation (Using proximity to mitigate the Sybil attack  #4481 and attack-resilient micro-economy for media #1)
  • Decentralized Finance (A Mobile and Generic Asset Exchange using Liquidity Pooling [group 1] #5988 and A Mobile and Generic Asset Exchange using Liquidity Pooling [group 2] #5996)
  • Decentralized value transfer (Generic value transfer primitive - master thesis #6029)
  • Decentralized music sharing (Fairness and freedom for artists: Towards a Robot Economy for the Music (Streaming) Industry trustchain-superapp#45)
  • Also see this overview of our lab efforts

Remy:

• Good motivation of the research!
• RQ is (too) broad - please narrow it down (I have to acknowledge that we proposed this RQ but it is a good starting point for research). For example, can you address one technical limitation/SSI aspect with a Proof-of-Concept implementation?

Kalin:

• I like the availability angle: "towards a disaster-proof SSI". How can we ensure that attributes/data is safe without relying on any centralised entity? Existing SSI solutions often cheat by integrating a centralised server.
• RQ and methodology is missing in the research plan.

Harmen:

• Please extend the background and position the research problem accordingly.
• RQ seems to align with the interoperability issues, from the perspective of use-cases. Suggestion: focus on a particular application domain. Decentralized finance maybe? "A Self-Sovereign Identity for Autonomous Financial Activity" or something like that. See https://www.sciencedirect.com/science/article/pii/S1062976920301162: "Finance cannot be viable without inalienable identity in case of default."
• Add references where applicable.

Pablo:

• Good research background and writing style!
• You have some ambitious ideas (particularly the working together with CINOA/Interpol/UNESCO members). I voiced my concern about the application domain. Please make the direction more concrete; I can discuss the viability of this direction with the responsible professor.

Merel:

• Please pick an application domain, e.g., the 18+ use-case that Rowdy made.
• How does the first sub-RQ relate to the overarching RQ?

[prodrigovalero]

For anyone looking into Blockchain enhanced SSI (I think at least @remyd95 you were looking into it), this paper describes a real proof-of-concept project in which they explain the basic concepts of blockchain and how it can help enhance SSI. It gave me a better understanding of each of the technologies and most importantly their interaction: http://essay.utwente.nl/71274/1/Baars_MA_BMS.pdf

[ghost]

This is my research plan.
Research_Plan.pdf

[remdui]

Here is my research plan as well.
Research_Plan_Remy_CSE3000.pdf

[devos50]

Here's a good source for articles on SSI (thanks @llegard) 👍

Another recommended paper

[devos50]

Feedback on uploaded research plans:

Remy:

• Overall good research angle.
• Bit of overlap in the planning (reading week 1 vs week 3).
• Please be more specific about your engineering contribution, e.g., is it a use case? How does the engineering contribute to answering the posed research question?

Kalin:

• Potential for an interesting storyline.
• Background and research question covers quite a lot of topics.
• I don't agree with the statement that a global blockchain is required to recover from identity loss. Blockchain is not always the appropriate solution for that.
• TrustChain is fundamentally different from a "regular" blockchain like Bitcoin. IPv8 focusses on selective data storage.
• There is probably a privacy trade-off if you have other users store your claims/attributes. This could be a sub-question.
• Also, you don't talk about the notion of decentralisation here.
• Suggestion to rephrase main RQ: "how can we build a disaster-resilient SSI solution?"
• "terminals" sound like a federated solution (e.g., look at chatting/email protocols).
• Why introduce two different solutions? Please focus on one solution, using IPv8.

Harmen:

• Title of research plan doesn't match main content.
• Interesting research domain. This will probably affect the literature you are going to read.
• Research plan generally is unconvincing and lacks in-depth analysis of the RQ.
• What sets a "DeFi SSI" apart from a generic SSI solution?
• Privacy is also an issue here - most people don't want to expose their financial position.
• The reputation angle sounds promising but lacks any description and clarity.
• Please expand your research plan and I can do another revision later this week.

Pablo:

• I suggest to look into the field of NFTs (current hype in the blockchain world).
• As I said last week, we are not familiar with the field of art work.
• Can you integrate this with our existing work (e.g., an "artist passport" for the MusicDAO)? You can split this as a use-case.

Merel:

• Working on the user interface of the MusicDAO applications sounds like a solid contribution. However, since it's a different application domain, I think it diverges too much from the SSI domain. I suggest to focus on the 18+ verification flow. One particular problem in that flow is that you want quick enrollment/verification to reduce queue times in physical stores.
• As an alternative, you could focus on inter-application workflow and integration of our existing SSI solution in other apps (e.g., something like OAuth).
• Please adjust your research plan/research questions based on the feedback above.

Suggestion for this week:

• Setup your development environment if you haven't done so. While reading literature, also look at the SSI part of the superapp. Rowdy will join the meeting today to tell you more about his efforts.

[devos50]

Some specific comments/ideas on Pablo's plan (we will further discuss these ideas today):

• Cum laude ambitions
• Use TrustChain records to store ownership of particular assets. Much more efficient than Ethereum.
• For your storyline, make sure to elaborate on the difference between fungible (often financial) instruments and NFTs. How does that affect your system design?
• Trace change of ownership and automatically pay royalties to previous owners
• Leverage EuroToken payouts in the superapp?
• Optional: integration with MusicDAO?
• Optional: can you enable joint ownership?

Possible NFT workflow:

1. create a torrent of your creative material (e.g., movie, art, music)
2. store the swarm hash of your material on TrustChain, create a signed record. Attach it to your SSI wallet.
3. optionally, you can have external parties audit/attest the material (e.g., certificate of authenticity).
4. a user is able to transfer ownership of their materials to others, in return for EuroTokens.

Fundamental problem: how can we guarantee unique ownership of NFTs using TrustChain accounting?

Potential storyline: Ethereum is not scalable enough, high fees -> insight: we need accountability, not full-fletched contractual logic -> we can use TrustChain -> TrustChain has the problem of double-spending.

Our recently published article on TrustChain.

[ghost]

Revised Project Plan
Research_Plan.pdf

[merelanne]

Revised Research Plan

[remdui]

Hereby the revised research plan.
Research_Plan_Remy_CSE3000_V2.pdf

[InvictusRMC]

Alright, as promised I would follow up in some more detail.

Self-Sovereign Identity in IPv8 is comprised of two main communities:

1. AttestationCommunity
2. IdentityCommunty

In this post I will only explain the AttestationCommunity, as this is the only one used in the SSI app in the super-app repo.

AttestationCommunity

The attestation community contains the low level logic for signing and verifying attestations. Two types of attestations exist, which are further subdivided in numerous key sizes and value ranges. Firstly, there is the Boneh et al.[1] algorithm. This is a public key encryption scheme, allowing for exact value verification with zero knowledge. The second algorithm by (Peng & Bao)[https://ieeexplore-ieee-org.tudelft.idm.oclc.org/stamp/stamp.jsp?tp=&arnumber=5591457][2], is another ZKP algorithm, however, this one is special as it allows for range proofs (i.e., you can verify that a certain value lies in a range).
The basic flow of attestation signing is as follows:

1. Peer A sends a RequestAttestationPayload, incorporating the type of proof used, the attribute name, a public key, and any further custom metadata (JSON format).
2. Peer B receives said request and creates an attestation using the provided public key. Peer B also assigns the value.
3. Peer B sends AttestationChunkPayloads, which is the serialized attestation. It is fragmented into several UDP packages.
4. Peer A receives the AttestationChunkPayloads, reconstructs the attestation and saves it to his wallet.

Important things to note here is that Peer A (favourably) generates a new key for each attestation requests. This is best for privacy reasons.

The attestation verification flow works as follows:

1. Peer B send a VerifyAttestationRequestPayload to peer A, containing the hash of the attestation he wants to verify.
2. Peer A sends back the attestation using AttestationChunkPayloads
3. Peer B sends ChallengePayloads to peer A.
4. Peer A sends ChallengeRespondPayloads to peer B.
5. Peer B can now verify that Peer A holds the private key of the attestation and using the responses he can verify that attestion holds the correct value. (The mathematical details can be found in the references of the two algorithms.)

It is important to note that the plaintext value is, thus, never sent through the network. Feel free to ask me any questions. (You can also e.g. e-mail me).

[1] Boneh, D., Goh, E.-J., and Nissim, K. (2005). Evaluating2-dnf formulas on ciphertexts. In Theory of Cryptography Conference, pages 325–341. Springer.
[2] Kun Peng and Feng Bao. An efficient range proof scheme. In Social Computing (SocialCom), 2010 IEEE Second International Conference on, pages 826–833. IEEE, 2010.

[devos50]

Feedback on the research presentations:

Remy:

• Privacy is an interesting (yet challenging!) research angle.
• Some gaps in your motivation (e.g., missing user authentication results in lack of privacy).
• Make sure to remain focus (seeing lots of other aspects). Focus on the technical aspects.
• Already try to separate the notion of privacy, elaborate on different aspects of privacy (metadata leakage, network fingerprinting etc).

Pablo:

• Suggestion to leave the ‘double spending’ problem for a later sprint in your research. It’s a challenging problem.
• Think about how SSI fits in your research.

Kalin:

• ‘if there is data availability, it is going to outweight other solutions.’ Your solution is likely going to have different trade-offs.
• Coming up with a full custom solution is going to be hard. Keep focus and narrow down your contributions.
• ‘master’ does not sound very decentralized.
• Please focus on improving the Kotlin superapp.

Merel:

• You are solving the data portability issue!
• How does the usability aspect fit in here?
• First deliverable? Cross-application 18+ verification check + workflow.

Harmen:

• Nice problem statement!
• Terminology can be confusing (liquidity pool vs lending pool), due to the field being new.
• How could the DeFi world benefit from a SSI? What are the additional possibilities?

[merelanne]

@devos50 I have a few questions regarding the specifics of my research. Do you have time tomorrow after our group meeting to discuss those?

[devos50]

@merelanne Unfortunately I have another meeting right after our group meeting tomorrow. Would 14:00 tomorrow work for you (same Jitsi URL as our group meeting)?

[InvictusRMC]

Hey guys and gal my apologies for missing the presentations last Friday. For some reason the event was not synced with my calendar and, as such, I believed them to be coming Friday.

@devos50 if you'd like my help with any other presentations or likewise, do let me know!

[merelanne]

My current version of the paper (first 400 words). The introduction is almost done, but I want to ask some questions before I write the detailed problem description. Note that this version has not received feedback from the Academic Communication Skills department yet. This will happen on Friday.

[ghost]

Towards_a_Disaster_Resilient_Self_Sovereign_Identity.pdf There are not that many changes from my project plan.

[devos50]

Meeting notes 04-05-2021:

• Did a tutorial of the Superapp code.
• For next week, please finish the problem description in the paper. Plus post a screenshot on Github showing your current progress on the superapp.
• Since the research is getting more concrete, it might be a good idea to start doing individual meetings where we can discuss specific research topic. Please send me an email if you are interested in such a meeting.
• Please use the two-column paper template.

[prodrigovalero]

My first 300 words of the research paper. It is the first draft, so it is subject to change before submission Thursday.
Research_Project_NFTs.pdf

[devos50]

Some quick feedback on the uploaded first 300 words:

General feedback:

• The flow of the papers that I usually write are as follows: 2 or 3 paragraphs general introduction, then a paragraph explaining in simple words the problem and the solution, then I list the contributions of the work and then I focus on the problem description. See, for example, this short paper.
• In the problem description, focus on the problem and not the solution. Always use citations to substantiate you argumentation and numbers (e.g., “as shown in prior work, SSI suffers from problem X and Y [33]).

Remy:

• Overall promising and structured storyline.
• ‘we try to answer the RQ’. This is somewhat weakly formulated, in a paper you either answer the research question or you don’t (and then the paper is not published :). Just say: “we answer the following research question”, or: “Our work focusses on the following overarching research question”.
• Reformulate the engineering contribution as required effort to answer your research question. Judging from your storyline, your storyline mostly consists of literature review. Instead of building a new privacy solution, you could alternatively focus on the performance/scalability/robustness of the current privacy approaches in the SSI implementation.

Harmen:

• Nice story flow in the introduction!
• Missing explicit RQs.
• I would suggest to split the introduction in two parts: introduction and problem description. In the problem description, you elaborate on the problem of overcollateralization. Be careful not to talk about your solution yet in the problem description! You can, however, hint at your solution at the end of the introduction, where you usually state your contributions.

Pablo:

• “Incremental digital content” nice term, but incremental is quite a technical term. I will think of a better alternative :)
• Talk about transaction fees instead of commissions in your problem description.
• The scalability argument can be made more explicit. E.g., how severe are these problems currently? What would happen if a fraction of the music industry decides to use Ethereum for the management of digital assets (hypothetical scenario)? Add some numbers!
• “Maintaining the ownership chain”: this is technically easy; it’s about incentivizing users to provide appropriate crepitations. You can add something like: “We approach this problem from a technical perspective and consider socio-economic issues beyond the scope of our work. We refer the interested reader to the work of X and Y to read more about such issues”.

Merel:

• Discussed some feedback in our meeting yesterday. Please update your introduction/problem description accordingly.
• Nice find, 191 accounts per employee! That’s quite a lot. Good motivation for SSI.
• I suggest to simply name Section 2 “Problem Description”.
• No need to add page number when adding citations.

Kalin:

• I suggest to make a separate problem description section where you explain the problem with achieving your goal. Is this goal making a disaster-resilient SSI or is it availability?
• Given the time schedule, I would focus on making a small improvement to the current SSI solution that improves availability.

[merelanne]

@prodrigovalero and I cannot run the latest version of the SuperApp. We get the following error when trying to run gradlew app:installDebug. We have tried multiple solutions found on StackOverflow already, but haven't found anything that works. Have any of you seen this error before?

> Could not resolve com.mattskala:itemadapter:0.4.
         > Could not get resource 'https://dl.bintray.com/terl/lazysodium-maven/com/mattskala/itemadapter/0.4/itemadapter-0.4.pom'.
            > Could not GET 'https://dl.bintray.com/terl/lazysodium-maven/com/mattskala/itemadapter/0.4/itemadapter-0.4.pom'. Received status code 403 from server: Forbidden

[xoriole]

Seems bintray.com software repository is not available anymore so the dependencies are not resolving. We'll have to move bintray dependencies to a different repository or setup a new one of our own.

For this particular dependency resolution, here is a cached file you can import locally
itemadapter.zip

[HarmenKroon]

Research_Paper_SSI_Harmen.pdf
First 400 words on an SSI based credit score claim that promises to reduce collatoral in DeFi similar to a traditional credit score.

[devos50]

Poster template:
match_poster.pptx

[devos50]

Meeting notes (Merel):

• Related work can be a separate section.
• Consider adding some more structure to Section 3, e.g., by introducing your three solutions with a \textbf{} at the start of each paragraph.
• If I only look at the figure, which conclusion should I draw?
• Try to have around one visual element per page.
• Make the storage models Section 3.1.
• Start with a figure showing that your framework is something between the application and the application holding the verified claim.
• Please explain Figure 3 step-wise (step 1: …, step 2: …)
• End the contributions in your introduction with “this work is a small but key step towards full data portability …”

[ghost]

Towards_a_Data_Resilient_Self_Sovereign_Identity.pdf

[merelanne]

Research_Paper_Merel_draft_v2.pdf
Unfortunately, I was not able to implement all the feedback yet, but I feel like I did make progress and will be able to finish before the final deadline.

[prodrigovalero]

Draft v2

[HarmenKroon]

Draft v2.pdf
Draft v3 is expected in the coming days

[remdui]

An_Evaluation_of_Privacy_Protection_In_Blockchain_Based_Self_Sovereign_Identity_DraftV2.pdf

[ghost]

Towards_a_Data_Resilient_Self_Sovereign_Identity.pdf
Draft v3 - It includes all sections and meets the page requirement.

[devos50]

Meeting notes 21-06-2021 (Kalin):

Abstract:

• The word ‘crisis’ is mentioned in the abstract but no in the introduction (inconsistency).
• Abstract can be a bit more convincing.
• Abstract should be written in the present tense.
• Inconsistency in the second paragraph where you suddenly start talking about your solution.
• What is Trustchain? You mention it in the abstract but you do not explain it.
• “Our solution consists of three main components:”.
• End abstract with: “We extend an existing SSI mechanism with a proof-of-concept implementation of our solution.”

Rest of the paper:

• Using self-sovereign identity and SSI interchangeably - please be consistent.
• Suggestion to rename the title of Section 3 to: “Achieving data-resilience in SSI”.
• Put figures at the top or at the bottom of the page. Use LaTeX float barriers.
• Figure 1:
  • Cloud is not annotated.
  • Remove the square around Figure 1.
  • Add a bit of colours? E.g., make the cloud blue, users red/green tec.
  • Please use vector graphics (PDF/SVG).
  • Explain what’s in the figure in the caption.
• “Bokkem et al.” instead of “Dirk van Bokken et al.”
• Don’t mention that the cited paper is a master thesis.
• Use the \enquote{…} in the csquotes package to put a word in quotation marks.
• Words are ‘big’, ‘many’ etc are sometimes considered informal. “Big problem” -> “major concern”.
• Make the font in the table a bit smaller.
• “The following three questions need to be answered” (in Section 3.4)
• Rename the title of Section 4 to: “Implementation Details”
• Caption of table 1: “A comparison of the three solutions for data-resilience in SSI, in the context of our eight requirements.”
• Captions of Figure 4 and 5, they should be a bit more descriptive.
• Figure 4 and 5 can be made smaller. Also, it’s not vector graphics.
• Try to place Figure 4 and 5 next to each other.
• Figure 6 is not a figure, it’s a table.
• Make subsections in 6: 6.1 conclusions, 6.2 future work. “We now end with conclusions and provide pointers for further work.”
• Don’t pose a formal research question in your conclusion. Try to make it in-line.
• You can sell your solution more in the introduction, “we are the first to …, whereas related work …”, sell it as research gap?
• “We make a first, but key step towards …”
• What’s the takeaway message of your work?

[prodrigovalero]

RP.pdf

[HarmenKroon]

Draft v3.pdf

[merelanne]

mockups.pdf
Mockups for the claim registry for the SuperApp.
Unfortunately, the program I used did not help much with alignment, so there are some misalignments, but the idea is there.

[HarmenKroon]

Draft v3.1.pdf

[devos50]

Meeting notes (Harmen):

• Figure 4, 5 and 6 are still not very readable.
• Figure 1 is not vector graphics yet.
• Move related work to the end of your paper.
• Abstract should be extended to explain your solution (2nd paragraph).
• Consider merging introduction and problem description.
• Section 3 does not have subsections.
• Section 3 = background and related work?
• You can make a bit more bold claims, e.g., at the beginning of each section.
• Paper requires more polish.
• Please add a short description of your solution at the end of the introduction.
• Section 6: our solution
• For the coming days, please focus on your solution. Describe in detail what happens and why.

[ghost]

Towards_a_Data_Resilient_Self_Sovereign_Identity.pdf
Final draft

[merelanne]

Pre-final draft
Tonight and tomorrow will be spent on polishing sections 6 and 7, doing a full-read and polish and finishing the conclusions.

[remdui]

An_Evaluation_of_Privacy_Protection_In_Blockchain_Based_Self_Sovereign_Identity_Final.pdf
Final delivery

[remdui]

Final Poster Draft.pdf
Final poster draft, still needs some work.

[HarmenKroon]

Introducing_Self_Sovereign_Identity_and_Identity_as_Collateral_in_Decentralized_Finance.pdf
Final report

[ghost]

Towards_a_Data_Resilient_Self_Sovereign_Identity.pdf
Final version

[merelanne]

A_Universal_Framework_for_Claim_Portability_in_Self_Sovereign_Identity_Applications.pdf
Final version. I forgot to upload it here, but this is the version also uploaded to BS and TUDelft repositories.

[ghost]

Poster_Presentation.pdf
Final Poster

[merelanne]

endterm_poster.pdf

[remdui]

Final Poster Remy Research Project.pdf

[synctext]

As the responsible professor for grading I've been going through all your articles, impressive writing. I'll be forwarding this material to the ministry responsible for digital identity and passports in our Kingdom. See you in an hour.

btw a single table here with "titles" and [click](TO DOWNLOAD) of your 5 papers and 5 posters would be great (replacing the above isolated posts).

[merelanne]

Final deliverables:

Student Name	Paper	Poster
Remy Duijsens	Paper	Poster
Kalin Kostadinov	Paper	Poster
Harmen Kroon	Paper	Poster
Pablo Rodrigo Valero	Paper	Poster
Merel Steenbergen	Paper	Poster

[devos50]

This course has been finished and as such, this issue can be closed. The final deliverables can be found in the previous post 🍾

(Grades will be sent to you by email)

[devos50]

@prodrigovalero as a first step towards publication, I would recommend reading through the accepted DICG papers last year, see here.

Next steps:

1. convert your paper to ACM template (see here, under submission guidelines).
2. hide the authors, change it to “Anonymous authors” (the ACM template allows you to do that).
3. compress your paper so the main content fits within six pages - leave references for now.