[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 (https://github.com/Tribler/tribler/issues/4481 and https://github.com/Tribler/tribler/issues/1)
  • Decentralized Finance (https://github.com/Tribler/tribler/issues/5988 and https://github.com/Tribler/tribler/issues/5996)
  • Decentralized value transfer (https://github.com/Tribler/tribler/issues/6029)
  • Decentralized music sharing (https://github.com/Tribler/trustchain-superapp/issues/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

[remyd95]

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

[remyd95]

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 11-05-2021:

• Please update your current paper just before the meeting.
• Not much progress regarding the engineering part. For next week, please upload a screenshot of your application interface.
• Midterm presentation (May 21), at most 5 minutes presentation + 5 minutes Q&A.

[prodrigovalero]

First screenshot of the application, he focus is not in style but in providing the basic functionality to test the NFT creation (bittorrent) and storage.

[ghost]

Introduction and Problem Description Towards_a_Disaster_Resilient_Self_Sovereign_Identity.pdf

[prodrigovalero]

Added abstract, refined introduction and problem description: Research_Project_NFTs (3).pdf

[devos50]

Feedback for Kalin:

• Use consistent language: data resilience instead of disaster resilience.
• Please mention earlier on what aspect of data resilience you focus, e.g., lost phone.
• It is uncommon to use the ‘I do …”, always use ‘we’
• We considered this and this approach, but we believe it is unfeasible because of Y. Therefore, we proceed with Z.
• The problem description should clearly explain the problem.
• Key problem: we have a single point of failure in SSI, the data is only on one phone and exclusively managed by the phone owner. So, if the phone gets lots, or data gets corrupted, the operating user has a problem.
• Possible solution 1: store data at Google or another TPP. Sounds like a good solution (these parties are usually good ), but there are privacy issues (e.g., the right to be forgotten), and synchronization issues.
• Possible solution 2: store your data at other peers. There is a trust problem here: other nodes might resell your data, or corrupt it. You could use something like tit-for-tat. Encrypt data?
• Possible solution 3: store the data on a server controlled by yourself. Solves privacy issue. The problem here is that you have to manage this infrastructure yourself.

[ghost]

@devos50 The meeting for next Wednesday is only for students. Each of us has to be present in a different breakout room and present his/her poster to peers from other groups.

[merelanne]

Current version of my paper

[ghost]

This version has the introduction, problem description and covers the first solution. Work has been started on the second and third solutions, but they can be expected later today or tomorrow. Towards_a_Disaster_Resilient_Self_Sovereign_Identity.pdf

[prodrigovalero]

Current version of my paper Research_Project_NFTs (4).pdf

[remyd95]

Research_Project_CSE3000_Intro+Problem.pdf

Intro + Problem description. I'm currently finishing up the text for the literature study part. I plan to upload this tonight or tomorrow.

[remyd95]

Midterm_Poster_Remy_CSE3000.pdf

Current version of the poster presentation (New images)

[xoriole]

The bintray dependencies should be resolved with https://github.com/Tribler/trustchain-superapp/pull/73 merged. Could any of you try and let me know if you still encounter issues?

[merelanne]

midterm_poster.pdf This is my poster for the midterm. It will probably be changed slightly as I expect some feedback tomorrow. I have some questions for Martijn for our Thursday personal meeting, so after that meeting it might change (expand) as well.

[prodrigovalero]

Midterm poster (not 100% finished) + needs feedback from today's session: Visual Content (3).pdf

[prodrigovalero]

@xoriole I can confirm that I have no issues with regards to bintray dependencies. Thank you for your help.

[remyd95]

Research_Project_Remy_CSE3000_Layout+1PageContent.pdf

Progress update: added overall layout and 1 page of content. Currently working on transforming more draft text to formal text for the paper

[ghost]

Towards Data Resilience for Fully Distributed Self-Sovereign Identity Managers​.pdf Towards_a_Data_Resilient_Self_Sovereign_Identity.pdf

These are my paper and my poster. The section with the three solutions will probably be edited later when I have an implementation. The poster is lacking some visuals, but those will come with the design of the solution.

[HarmenKroon]

Research_Paper_SSI.pdf

My current draft that requires a lot of refinement. Structure of sections has evolved to discuss lending platforms and their use of collateral and identity management.

[merelanne]

Current paper

[prodrigovalero]

Current paper : Research_Project_NFTs (5).pdf

[prodrigovalero]

Improved version of the current state of the application (still needs a lot of styling):

[devos50]

Meeting notes 25-05-2021:

• In two weeks, there is a readable draft deadline. I expect that in this draft, the most important sections are filled in. I do not impose requirements on number of pages but keep in mind that you should make progress on your paper.

Individual feedback (Kalin):

• “Our requirements are inspired by the ten principles…”.
• You are not using all principles of SSI - why not? What’s wrong with the requirements that you did not include? Answer: they are not applicable.
• Start working on a table which provides an overview of these solutions in the light of your requirements. Rows are the solutions, and the column are the requirements, and your cell element is a - -, -, o, +, ++ (nonexistent to very good).
• Defend your choice for some of these items.
• Your choice on what to implement should be well-defended.
• The most important part of the implementation work is a “transaction synchronisation algorithm”. Show how each of your implementation parts related to the requirements.
• Focus on “identity owners as storage provider”
• Keep the implementation as simple as possible.
• “Identity recovery” implemented using authenticated HTTP messages, a self-deloyed IPv8 instance and secret phrases.
• “Access revocation” partially implemented using aiohttp.
• Biggest concern now: recovering secret phases in Kotlin, has to be compatible with Python.
• First version of the two engineering components can be completed at the end of this week.
• For a later iteration, make a figure of your system architecture.
• For the group meeting, please make sure you completed the two parts of the implementation and have written about it in the paper.
• You are defining the word ‘legality’ within your own system as: “an identity/transaction having a backup”. This is dangerous since it’s very open to interpretation and you (and me) are not legal experts. I suggest to reword this requirement to something more technical.

[devos50]

Individual feedback (Harmen):

• Writing is a bit behind on schedule.
• Paper storyline: describe the two classes of existing solutions. After you’ve done so, highlight the positive and negative properties of each solution class and summarise this in a table using checkmarks/Red cross/neutral icons. Argue about this in the text.
  • Then propose your solution and elaborate how it overcomes the aforementioned deficiencies.
• No need to make your solution superior in all aspects - it’s a matter of selecting the right trade-offs and application domains.
• Insight: related work is too abstract. You can mention that existing work fails to grasp the complexities of real-world systems.
• Goal of research: leverage existing credit scores solutions to either reduce or remove collaterals.
• Existing solutions do not provide data autonomy to end users. Alternative angle: existing solutions are under the flagship of a centralised, capitalistic company.
• In addition, existing reputation scores are not re-usable across different applications, therefore increasing administrative overhead and reducing overall efficiency.
• Proposed solution: share KYC attributes with your lending protocol or credit score manager.

For next week:

• Write about your the existing solutions in the paper.
• Add a sketch of your solution to the paper.

[merelanne]

Current paper

[devos50]

Individual feedback (Merel):

• Please make the problem more prominent in the problem description. Try to have the first sentence indicate the problem you address in this work.
• “perfect decentralisation” -> suggestion to rename this to “limited autonomy” or something more accurate.
• There are not many solutions to reuse verifiable claims (intra-application).
• It would be preferred to keep the communication protocol generic and focus the implementation of your solution on the SuperApp.
• Assume the availability of a PKI
• SSI solutions assume that the user will only operate within their designated app. They do not evolve beyond a very small number of use cases.
  • In other words, in order to profit from data deduplication, we need to radically rethink the interoperability aspects of SSI. We do so by devising a universal interoperability framework for the sharing of verifiable claims.
• For the introduction, I suggest to build up your story towards SSI by introducing 1) centralised identity, 2) federated identity, 3) SSI. Also add a figure on page 2 with these architectures.
• Paper title suggestion: “A universal framework for claim portability of Self-Sovereign Identities”
• You could also add a figure with an application and a SSI solution, show where your solution hooks in.
• Section 4: “Our claim portability framework”
• Section 5: “Implementation details”, add a system architecture, GUI screenshot, interface methods in a table, etc.

For the next meeting:

• Extend your paper with a few pages.