Thesis: self-sovereign identity (SSI)

[synctext]

Current status:

• Full-time for 11 November onwards (first courses)
• ToDo: formulate Cum Laude scientific idea
• Re-usage of Superapp infrastructure with IPv8
• cooperation with ministry
• tamper-proof hardware: https://www.bunniestudios.com/blog/?p=5921
• Ask Stephan Wong faculty member for his Computer Engineering expertise?
• Idea: Build and trail a secure identity wallet with Passport and Euro contents
• Idea: use OpenTitan silicon root-of-trust
• idea: import quantum randomness through the open GPIO pins, latest science (too immature tech)
• Too hardware focused (e.g. Firmware flashing and OS compile debugging?
• Also involve the TBM people for the legally valid signature on behalf of a legal entity?
• Deadline: 1 Dec 2020 have a Problem Description in 1 page
• Deadline graduation: current rules Tuesday 31 Aug 2021 graduation (this has not changed)
• ToDo: Sicco check of cybersecurity assignment

[synctext]

Open crypto hardware wallet Trezor
ColdCardWallet

[qstokkink]

If you're into crypto: another fun, open and very difficult problem in the space of Self-Sovereign Identities is that of credential revocation. You can get a taste of the problem space in these papers: paper1, paper2. You'll have to make sure revocation data propagates decentrally and that the revocation lists/sets are anonymized.

[synctext]

Are we interleaving requirement analysis and prototyping? Sounds like the good thing todo in this unexplored field. Hardware expertise level: no soldering iron, custom firmware-only.
Discussed "Member States"+EC co-author objective.

EU digital ID scheme for online transactions across Europe

An EU digital ID scheme (EUid) will:
  - make it safer and easier to use online services anywhere in Europe
    (e.g. enrolling in a foreign university, opening a bank account, accessing public services)
  - give people more control over their personal data and privacy while respecting user anonymity.
Type of act:    Proposal for a regulation

[InvictusRMC]

Sicco's assignment request:

• Short assignment description (1-2 A4), including:
  • Research area
  • Knowledge gap
  • Research questions

[synctext]

Today is the first thesis day!
Goal: determine direction in 3 weeks. Draft problem description.
Firmware project or algorithm work?
Related work on SSI: https://repository.tudelft.nl/islandora/object/uuid%3A200f1df0-adda-47a1-894c-baf54133035a
plus obviously prior thesis from our Lab: https://repository.tudelft.nl/islandora/object/uuid%3Aaab1f3ff-da54-47f7-8998-847cb78322c8

[InvictusRMC]

Initial thesis ideas:
Thesis_Ideas-2.pdf

WIP proposal:
Thesis_Proposal.pdf

[synctext]

Currently have a few possible directions:

• International Deployment, European-ID
  the Commission will soon propose a secure European e-identity., speech by Head of European Commission, Ursula Herself
• Identity Theft (private key compromise) {related idea: open API for biometrics}
• "industrial-strength SSI implementation". Native Kotlin of IPv8 zero-knowledge proof and from-scratch interaction model / GUI design. Go beyond prior trail with real users and high-end publication (IEEE Magazine level).
  
  Possible link to biometrics, like this work from Twente startup

Understand prior work

• self-sovereign identity system #2682 our SSI insight from 2016.
• Universal wallet for identity, attestations, and money #4461 (comment) Speelman thesis with BSN crypto idea
• Nijmegen

[qstokkink]

If you plan on investigating revocation, you may also want to take note of this recent MSc thesis (from the crypto group) regarding a credential revocation scheme: http:https://resolver.tudelft.nl/uuid:871e17aa-a023-461f-88b1-80d83c21de92

[InvictusRMC]

I have written the following Thesis proposal with the Industry-Strength SSI in mind. I plan to submit this to Sicco.

Thesis_Proposal_V2.pdf

[synctext]

Nice! Seems ready for submission to Sicco. Minor comments:

realised, there is still much to gain.

Still much left to investigate.

(4) interoperability is another key challenge. This needs to be an open standard and have an open reference implementation. But somehow the Spanish wallet provider needs to be able to talk fluently to Polish verifiable claim providers.
So, a German/Dutch international SSI trail would be a key milestone to achieve.

The main knowledge gap currently existing in the research area of SSI is the gap between the theoretical frameworks and the practicality of an implementation of these theoretical frameworks.

The main knowledge gap currently existing in the research area of SSI is the gap between the theoretical frameworks and the feasibility these theories. For instance, strict processing latency requirements on mobile devices. Governments would be reluctant to ask many of the European Union citizens to upgrade their phones. Governance requirements by nation-states, complexity, communication overhead, and fault-tolerance are other gaps.

we can derive the following sub-questions that can be used to substantiate an answer to this research question

Too generic. We know prior work, functional requirements and its limits. This deviates from what is really needed. As scientists we can ignore the eIDAS and GDPR legal constraints somewhat. The next stage in the maturing of the SSI theoretical concepts is to go beyond mock-up trails. We need to devise the most simple as possible SSI architecture which integrates the following required elements in a technology neutral manner:

• A wallet to store verifiable claims
• open API towards any commercial vendor of biometric authentication technology (DONE)
• open API towards any secure hardware token with challenge-response protocol to minimise side-channel leakage.
• Compatible with major deployed smartphone Operating Systems (Android,iPhone)
• No vendor lock-in, fully patent-free or from friendlies such as "Bundesdruckerei.
• Integrate a "trusted registry" of entities for which claims are accepted

[InvictusRMC]

Great feedback. I've updated the research questions and added a minor section on interoperability. The research questions could still use a little refinement, however, are sufficient for the assignment description submission in my opinion.

Thesis_Proposal.pdf

---

Update: Stjepan called it "more than enough".

[InvictusRMC]

Update:

• Got (almost) everything in order for BZK:
  • Will (most likely) be attending meeting next monday on their next plans for SSI.
  • Got access to their systems so I can freely communicate within BZK.
• Identified around 25 articles/whitepapers/theses to read:
  • Still have 19 to go through
• Finished Q1 courses (still had an oral & project to complete):
  • Still waiting on a single grade
  • However, Cum Laude average is secure

[synctext]

https://graz.pure.elsevier.com/en/publications/revocable-and-offline-verifiable-self-sovereign-identities

[InvictusRMC]

Had a great talk with @qstokkink. Got an introduction to the Python code and pointers to interesting authors and what literature to stay away from.

Also my literature list for now (will be growing after the pointers from Quinten):

CLICK ME

•  Stokkink, Q., Epema, D., & Pouwelse, J. (2020). A Truly Self-Sovereign Identity SystemarXiv preprint arXiv:2007.00415.

•  Dong, C., Wang, Z., Chen, S., & Xiang, Y. (2020). BBM: A Blockchain-Based Model for Open Banking via Self-sovereign Identity. In International Conference on Blockchain (pp. 61–75).

•  Stokkink, Q., & Pouwelse, J. (2018). Deployment of a blockchain-based self-sovereign identity. In 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData) (pp. 1336–1342).

•  Zwitter, A., Gstrein, O., & Yap, E. (2020). Digital Identity and the Blockchain: Universal Identity Management and the Concept of the “Self-Sovereign” Individual Frontiers in Blockchain, 3.

•  Van Bruggen, C.. (2020). Forward-looking consistency inAttribute-Based Credentials.

•  Ferdous, M., Chowdhury, F., & Alassafi, M. (2019). In search of self-sovereign identity leveraging blockchain technology IEEE Access, 7, 103059–103079.

•  Tobin, A., & Reed, D. (2016). The inevitable rise of self-sovereign identity The Sovrin Foundation, 29(2016).

•  Cameron, K. (2005). The laws of identity Microsoft Corp, 5, 8–11.

•  Allen, C.. (2016). The Path to Self-Sovereign Identity.

•  Mühle, A., Grüner, A., Gayvoronskaya, T., & Meinel, C.. (2018). A survey on essential components of a self-sovereign identity.

•  Zhou, T., Li, X., & Zhao, H. (2019). EverSSDI: Blockchain-based framework for verification, authorisation and recovery of self-sovereign identity using smart contractsInternational Journal of Computer Applications in Technology, 60(3), 281–295.

•  Coelho, P., Z'uquete, A., & Gomes, H. (2018). Federation of Attribute Providers for User Self-Sovereign Identity Journal of Information Systems Engineering & Management, 3(4).

•  Helmy, N.. (2020). Overview of Decentralized Identity Standards.

•  Der, U., Jähnichen, S., & Sürmeli, J. (2017). Self-sovereign identity - opportunities and challenges for the digital revolutionar Xiv preprint arXiv:1712.01767.

•  Wang, F., & De Filippi, P. (2020). Self-Sovereign Identity in a Globalized World: Credentials-Based Identity Systems as a Driver for Economic InclusionFrontiers in Blockchain, 2, 28.

•  Othman, A., & Callahan, J. (2018). The Horcrux Protocol: A Method for Decentralized Biometric-based Self-sovereign Identity. In Proceedings of the International Joint Conference on Neural Networks. Institute of Electrical and Electronics Engineers Inc..

•  Speelman, T. (2020). Self-Sovereign Identity: Proving Power over Legal Entities. (Master Thesis, TU Delft).

•  Baars, D. (2016). Towards self-sovereign identity using blockchain technology. (Master Thesis, UTwente)

• Otte, P., de Vos, M., & Pouwelse, J. (2020). TrustChain: A Sybil-resistant scalable blockchain. Future Generation Computer Systems, 107, 770-780.

• Abraham, A., Hörandner, F., Omolola, O., & Ramacher, S. (2019, December). Privacy-Preserving eID Derivation for Self-Sovereign Identity Systems. In International Conference on Information and Communications Security (pp. 307-323). Springer, Cham.

[InvictusRMC]

Some updates:

• Proposal cleared by both Sicco and Stjepan.
• Cybsec has a requirement that I have to attend some presentations (will be taken care of by me).
• Currently still reading papers, hope to be done by end of week. Currently summarizing them for my own convenience and have used relevent literature to draft a properties/requirements and problem statement/background section.
• Have some nifty ideas we can discuss tomorrow (regarding a revocation method that can be performed relatively offline - atleast, requires less interactivity).
• Updated literature list.
• Next steps:
  • Want to start implementing some code end of month.

Here is my very (!) rough draft. Thought I'd include it for completeness sake.

[synctext]

Lots of lost or stolen ID documents: 900 documents per day
Note that we use Tor-like stack to offer proper privacy when using your digital identity at passport-grade level.
Now we could also utilise our distributed technology for secure dynamic data exchange. Multiple times per day the government could publish revoked (lost/stolen) passports in their channel. A channel is a collection of signed data blobs, each blob is a swarm (sort of P2P RSS feed which can scale without bounds) (DDos protected, like attack on mijnoverheid.nl).

Quinten advise: just start; translated? : dive into Superapp stack with Kotlin IPv8

[InvictusRMC]

I have made a design on how the Hybrid-Revocation Model could work:

Also a design how it can be integrated in the regular verification flow:

[InvictusRMC]

Update

• Designed diagrams for workflows
• Finished reading for now (related work section is still WIP)
• Started porting the current SSI code of py-ipv8 to Kotlin (nearing 1000 LoC)
  • Primary focus:
    • Wallet Community (Self-imposed deadline: this month)
  • Secondary focus:
    • Identity Community (Self-imposed deadline: this month)
  • Plans after above tasks are completed:
    • Formalize own additions
    • Implement

[synctext]

• what are the field trail key requirements?
• what is the core API of the ISSIF, the eID of Europe?
  • present claim
  • verify claim
  • store claim
• what is the feature outcome of January sprint?
• side-channel leakage, our Tor-like proxies are out of scope
• Current analysis: complexity of a 5-person field trail seem manageable
• Bachelor thesis by @kkostadinov99 student who did prior IPv8 Python on Android work
  • On 18 April when 4th quarter starts he will be provided an operational skeleton ID app
  • Ready for feature extension and testing on 25 people (possible bsc thesis focus)
• offline-first support as a key selling point of this msc thesis
  • makes the revocation framework shine
  • goes beyond all other related work (Microsoft,IBM, DID-fans in general)
• incremental: end of this month your first Superapp pull request and addition to the .APK
• Future superapp sprint ideas: existing code for wallet for Bitcoins, scan of QR code of friend in social network, and Digital Euro storage. Think about a generic API based on the offline-first verifiable claim paradigm.

[InvictusRMC]

Update:

• Continuing with engineering:
  • Attestation community almost done.
  • Wallet community should only be a few days work after that.
• Have everything running in an Android app in first week of February.
• Still need to have a meeting with André about ESSIF requirements.
• Within BZK: will be having communication with Tim, Pim, and Quinten for international SSI tracks from EU.

[synctext]

• Focus on must-have features of attestation and wallet. Integration is future sprints
  • Most work inside: https://github.com/Tribler/kotlin-ipv8 not superapp
  • Zero-knowledge proof in Kotlin, not a showstopper
• @Tim-W credentials for "Trustchain Superapp" currently on Android Play Store, obtain live crash reports.
  • Pull request and take over Superapp project / repo?
• Split the "Basic Digital Identity" from the SSI service that operate above it. DBI is the low-level key creation, life-long core attestations, and nothing else.
• Q4 (April) usability bsc thesis study will start. Requires 18-yo and 72-yo citizens to work with your app!
• In future we want to be able to add social-relevant attestations
  • from this Covid E-Nose machine or blood sampling {tests without 💀 scraping}
  • Around Delft or Den Haag with BIG
  • integrate with BIG certificate of medical doctor, electronic signature
• cardinal objective: end-to-end software test with QR-code as input

[InvictusRMC]

Progress Update

• AttestationCommunity functioning
  • Squished a ton of bugs (Tip to self: Kotlin docs are not always correct)
  • Did a huge number of tests:
    • Core crypto classes now have tests (which also pass)
    • Manual more e2e-like testing
  • Skipped the irmaexact attestation algorithm --> is also not fully implemented in Py-IPv8
  • Still have to implement pengbaorange (not much work, builds on Bonehexact which is 100% implemented)
• In order to prove that AttestationCommunity is functioning:
  • Built a concept GUI app on Android which shows the request of attestation signing and the storage of verifiable claims
  • Built a concept CLI app which shows the verify claim flow (this will also end up in the Android app, ofcourse)
  • Code base is now in Kotlin-IPv8 (as the Superapp is a bit bloated, this has faster development time)
    • Ensured that the code is functioning in the Superapp, so should be a matter of ctrl+c ctrl+v to get it up and running
      • Unfortunate side effect: dependency "hell" breaks Blockchain Engineering "Luxery Communism" project --> will fix this later on.
• Unfortunately, a lot of time went into seting up the Android app (tip to self: JDK8 source cannot be compiled with JDK11)
  • Ofcourse, this is a one time thing
• My next steps (this week):
  • Finish IdentityCommunity
  • This community adds identity management
  • Complexity-wise, this code will take far less time
  • Goal: up and running this week
  • Add pengboarange algorithm: tomorrow
• Next steps (sprint):
• Formalise offline-first design requirements
• Android engineering time:
  • Implement IdentityCommunity in Android
  • QR support
  • Keep everything quite simple, focus on functionality (in Android)
• EBSI/ESSIF link

[synctext]

• 2 March 2021: possible real trail with EuroTokens, Digital Basic Identity and 18+ attestations.
• Making solid progress, towards MvP: "18+ icon" in superapp (e.g. 'scan 18+ authority')
• please keep everything running, MusicDAO has real users
• international trail, live usage, and international co-authors becoming realistic (EBSI/ESSIF)
• Political developments: "visiebrief digitale identiteit" by our secretary of state.

[InvictusRMC]

Progress update:

• Implemented Peng & Bao ZKP:
  • Verification and attestation fully working
• Fixed active verification for Boneh algorithm
• Implemented Trusted Authority Manager for IPv8
  • Stores the hash of the public key of authorities
  • Saved to database
• Extended attestation flow to incorporate signature:
  • Performed over metadata and serialized attestation
  • Allows for verification with Trusted Authorities
• Working on Android demo.

[InvictusRMC]

Another paper by Sovrin on revocation: https://sovrin.org/wp-content/uploads/AnonCred-RWC.pdf

[InvictusRMC]

Just had an idea for the secondary issue of loss recovery:

• Main issue: private key recovery --> Use Shamir's Secret Sharing with trusted persons (e.g. x close friends or even your local government). Next, we can use this private key recovery mechanism in two ways:

1. First method:
   • (1) Periodically encrypt serialized wallet contents with private key as encryption key and (2) store on an external storage solution (e.g. some cloud storage provider).
   • Use recovered private key to decrypt and restore encrypted wallet backup.
   • (Wallet is stored encrypted as this gives some guarantees on confidentiality and integrity).
2. Second method:
   • (1) Use recovered private key in challenge mechanism to prove ownership over attestations and (2) make each authority resend the attestations (trivial solution).

[qstokkink]

You could check out the results of #3245 and #3246. Both groups used Shamir shares for recovery.

[synctext]

WEF authors to contact: https://www.weforum.org/agenda/2021/04/trust-is-fraying-how-trust-anchors-could-help-gtgs/

[InvictusRMC]

Update Progress

• Code base:

  • PRs open for 18 days
  • Extensive (manual) e2e testing for CommunicationManager:
    • Implements rendezvous logic:
      • Allows peers to create a subcommunity (second instance of a Community) on runtime
      • --> No more visibility issues
      • Works via a special code a client can generate themselves and distribute via other means.

• Revocation:

  • Not developed further since last meeting, but
  • Khovratovich & Jason (2017) state three methodologies for revocation specifically for SSI:
    1. Signature Lists (Nakanishi et al., 2009). Paper on revoking keys, where keys of non-revoked members are fetched.
    2. Cryptographic accumulators (Camenisch et al., 2009). Hashes all valid credentials to a single (accumulated) value. A client uses a witness to prove that the accumulator comprises their identity. Solution requires interactivity with issuer and witnesses.
    3. Forward revocation lists (Verheul, 2016). Issuer generates revocation entries, client present non-revocation proof. A verifier tests this proof against every entry.

• Possible novelty in revocation:

  • Distributed: most (all?) of the solutions do not use other clients as relay stations for revoked signatures. Gossip can be a novelty.
  • Usage of bloom filters for speed optimization. My current solution uses a revocation list of the hashes of revoked signatures. Bloom filters are extremely efficient datastructures which help us say with certainty that a signature is not revoked. In case the bloom filter reports that there might be a match, then we can perform the O(n) search. This O(n) search can also be optimized by using a smart search algorithm (e.g Heapsort worst case O(n log n).
  • There are some papers on bloom filters and revocation. (Did not yet dive in):
    • (https://ieeexplore.ieee.org/abstract/document/7192615)
    • (https://ieeexplore.ieee.org/abstract/document/5719271)
    • (https://ieeexplore.ieee.org/abstract/document/8288287)

• Article:

  • Started working on article. ~(4-5 pages now, possibly too in-depth, but fragments can be used for the thesis itself)
  • What results to discuss in article?
  • Article_Draft_19-04-21.pdf

• For bonus, I've written the first version of the SSI blog:

  • DRAFT_SSI_Blog_10_4_2021.pdf

[synctext]

• Science in thesis? ?Distributed and practical revocation systems for passport-grade identity.. (non-interactive, QR-code only, bulk-broadcast, offline relay gossip, challenged network, IoT low-bandwidth, etc.)
• revoked passport ID, side-channel leakage of sensitive information? Full public info?
• Practical:
  • runtime beyond Big O notation
  • speed improvement with and without Bloom filters
  • storage requirements in real MBytes for realistic country-wide deployment scenarios
  • performance evaluation on numerous real Android devices?
• Related work - credentials and web-of-trust: Trust over IP foundation
  • All related work is central, see Idemix, Sovrin, etc.
• ToDo: write design?
• Thesis what makes it more then "YARC: Yet-Another-Revocation Scheme"?
  • Realistic trail and use-case - the real 18+ trail and photo
  • Realistic Von Der Leyen trail: QR-code to login to platform, without revealing anything

[InvictusRMC]

Progress update:

• App (new logic implemented):
  • Ability to set special rendezvous token
  • Ability to request attestation whilst locating the other peer through rendezvous token
  • Requests screen in order answer to attestation and verification requests
  • Ability to sign and verify small (!) images --> can be used for ID pictures, idea to write something about this in thesis/article
  • UI component to see verification output
  • UI component to revoke signatures
• Writing:
  • Started writing on design of revocation, becoming more clear that fully distributed (offline usable) revocation has not been done yet
• SSI design:
  • Working on attestation presentation logic for "Von Der Leyen" trail
  • Significantly improved signature scheme for offline validation:
    • Value is only sent once on AttestationCommunity-level (sent back through the attestation chunk payloads)
      • Incorporated into raw byte stream which is encrypted --> confidentiality should be enforced
    • Value is no longer present in AttestationCommunity-level metadata, only in IdentityCommunity-level, meaning that the value cannot be read out on verification-time, and, thus, does not necessarily has to be disclosed when sending the raw attestation (i.e., the AttestationCommunity attestation).
    • Both parties reconstruct the metadata containing the value, as the value itself is stored in the wallet
    • Signatures are validated (offline) using the chain of signatures on IdentityCommunity level, hence, we reuse IdentityCommunity-level signatures, as opposed to creating new ones.
  • Significantly improved QR code presentation (for offline attestation verification):
    • Less vulnerable to replay attack --> timestamped challenge is used which is only valid for an amount decided upon by the requested peer.
    • Ability to split large attestation into two QR codes
    • QR generation way quicker
• BZK:
  • Next week presentation on SSI & my thesis
  • SSI blog almost finished
• TU:
  • Helped Martijn with BSc students

Self reflection:

• Not too happy with progress over past two weeks
• App development can be sluggish and feels not too relevant for endgoal at times
• Need to focus more on writing ~10 pages thesis, ~4 pages article. Feel I need to work a lot more on this.

Proposed roadmap (next two weeks):

• Be done with app this week (including "Von Der Leyen" presentation logic)
• Revocation mechanism "beyond state of art" analysis/comparison
  • Have this written down in both article and thesis

[synctext]

• Why is your thesis work novel? Design of revocation algorithm. Unique approach: as decentral as possible.
• more scientific terms, not secondary something. Secure communication primitive
• How different is your unique code from standard TLS?
• A nounce is not a token
• The Big Picture: decentral economy with master students
• Can your work be presented at upcoming European Cybersecurity Agency event?
  • https://www.enisa.europa.eu/events#b_start=0
  • scan QR code that does something. However: it always needs to work. Paper passport robustness.
• ToDo: start your scientific article. Starting point: design
• determine upper bound of tps, single gateway. no maximum tps determined yet of gateway (no block validation, just 1 transaction block transfer)

[InvictusRMC]

"Von Der Leyen"-Trial (Although name is revealed, 18 plus also works)

20210508_211733.mp4

[InvictusRMC]

Progress

• Finished app:
  • Revocation logic implemented and functional
  • Presentation logic & answers to request for specific attributes ("Von Der Leyen"-Trial, see video in previous comment)
• Revocation functional:
  • Did analysis on convergence time (written down in Thesis)
  • Did analysis on impact of Bloom filters (written down in Article, should probably be moved to Thesis as a whole)
  • Working on runtime analysis graphs (bottleneck: only max ~10 clients before CPU is capped)
• Writing:
  • Have written more in-depth about design:
    • Explained protocol in terms of attestation signing and verification
    • Explained revocation
    • Extensive convergence time analysis
• Next steps:
  • Finish article this week/begin next week
  • Continue writing thesis
  • Investigate usage of accumulators versus hashes for Revocation
• General remarks:
  • Presentation on my Thesis at BZK on the 7th
  • Two PRs open
  • More happy with progress, but still require a lot of work on writing.
  • Need to plan in Thesis defence.

DRAFT_Thesis_27-05-2021.pdf
DRAFT_Article_27-05-2021.pdf

[synctext]

• How does your identity framework differ from FIDO2, OpenID, SAML? Demo?
• mental note: always keep private keys external from untrusted phones from untrusted supply chain and untrusted OS. 1st-phase as external crypto key storage using microSDcard; easy interface into unsecure Android devices. Air-gapped challenge response via MicroSD. See supplier and here
  
• 2005 was the year that SSI was defined, possibly this gets too little credit for the depth it has.
• Hype your novelty: Zero-interaction, zero-centrality, failure-proof revocation architecture (+ requirements from tamper-proof storage layer & gossip relays; censorship-free message forwarding; single honest node eventual discovery?)
• Theoretical performance bound for revocations?
• Table of known revocation algorithms with [REF], YEAR, SSI-compatible? plus 1-line description.
• Cross-border revocation trail? (Student writes testing plan :-) {invites, task description, revoke, measure, graph, storyline} {revoking test floods, 4 test scenario buttons}

[InvictusRMC]

With thanks to Andre:

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM%3A2021%3A281%3AFIN&qid=1622704576563

[synctext]

Please study this master thesis format for Cum Laude: #5221 (comment)

[InvictusRMC]

Progress:

Article:

• Created table comparing other revocation algorithms
• Improved structure of article
• TODO:
  • Remove some less relevant information
  • Add section on scalability (still in progress of creating graphs)

Thesis:

• Finished piece on Identity and SSI:
  • Philosophical nature of identity
  • Digital identity (introduced a small model describing the current ecosystem)
  • Evolution of digital identity
  • Problems in digital identity
  • Recorded the history of SSI for the first time (?) in academia
  • Discussed shortcoming of the term and proposed a new one
  • Discussed what SSI is through properties and proposed a new framework (needs perhaps another revision) aiding a definition of SSI.
• TODO:
  • Write design piece on SSI (can be copied from article and then extended upon)
  • Write about ethics
  • Write about the lifecycle
  • Write about benefits for users
  • Write evaluation

Test plan:

• Need another day or two to finish test plan. Have drafted scenario's, but still need to strengthen them and define metrics.

DRAFT_Article_13-06-2021.pdf
DRAFT_Thesis_13-06-2021.pdf
DRAFT_Test_Plan_14-06-2021.pdf

Published Dutch SSI blogpost:
https://digicampus.tech/hoe-creeer-je-online-vertrouwen/

Thesis structure guidelines:
https://www.tudelft.nl/studenten/ewi-studentenportal/onderwijs/afstuderen-msc/thesis-report

[synctext]

Great article first draft! Please put the table first, as hook for your storyline that after 48 years since invention of public key crypto its not ready yet. Mark red (smaller) and green checks (bigger) plus clearly: this work. Turn table, more citations? Add Problem Description?
5 people trail for system validation? Or "cross-border-scan" German Government official scans a QR code generated by Dutch citizens and signed by Dutch Kingdom official?

btw Gemeente Hoorn crypto deployment for citizens: https://github.com/discipl/waardepapieren/projects/2

[InvictusRMC]

Progress Update

• Spent mostly writing Thesis:
  • Have come a long way with main body. Document nearly 80 pages
• Article fixed table, still requires some removal of irrelevant/too detailed information.
  • Need to add results showcasing propagation time.
  • Finish this week
  • Look for conference (?)
• Testing plan is now a single scenario showcasing both credentials and revocation.
• Have presentation about thesis this afternoon for Cybsec.
• Had a talk with Prof Epema.

Thesis-Draft-30-60-21.pdf
Article-Draft-30-60-21.pdf
Testing-Plan-30-60-21.pdf

[synctext]

• consider switching thesis format radically and use article as first chapter. Then move to supplementary material. 14 page Delft msc thesis
• Experimental setup "Firstly, a storage for 300.000 hashes of 32 bytes each, results in a space usage of at least 9.2 megabytes" 👍
• Screenshot in article 📱 ???
• Propose:
  • work until 16 Juli on experimental results (maximum 3-4 amazing graphs)
  • Finish scientific article: 30 July
  • Then thesis supplementary material till 16 Aug.
• First is emulation graphs, secondary perhaps a Jupyter Notebook for theoretical performance bounds?
• thesis storyline is too broad. Offline support as a first-class requirement. That's the innovation. Lack clarity.
• You turned sovereign fantasies into Kotlin reality. Where is that represented in thesis?

This chapter describes the overall outline of the thesis. Firstly, the research area is introduced, providing brief insights into the
topic of Self-Sovereign Identity. Next, the motivation for this research is discussed, touching upon current shortcomings and
 opportunities for SSI. Then, the research questions are discussed. Finally, the contributions of this work
are highlighted and the outline of the remainder of the document is given.

• My preference is less boilerplate in a thesis and more condense formatting:
  We introduce the topic of Self-Sovereign Identity, discuss the motivation for this research, and outline the research questions of this thesis.
• Switch to master thesis format, not phd thesis. Too Soon 🏅 Page 3 and 5 has lots of empty space.
• Background chapter, make an explicit "Problem Description". Probably existing content can fit into intro and problem chapter.
• 2.6.4. THE PYRAMID OF SOVEREIGNTY, "Figure 2.4: The Pyramid of Sovereignty", make explicit this is your model, give it a name. If existence and control are the two pillar on which everything else is build 🌉. You get a hanging bridge type of mental model.
• 2.5.1. HISTORY; merge with related work.
• Inside "2.5.2": SSI gives absolute control over identity. "This misconceptualisation is most likely caused due to the ambiguous nature of the term Self-Sovereignty. As we established that self-sovereignty does not lead to self-attested, the dependency on attestation directly deteriorates the level of control one has over claims." You're putting a lengthy tutorial in there. Information density is too low in many parts of thesis. chapter 2 ends on page 34. Make that page 13 or so!
• "Figure 3.1: The relationship between credentials and (verifiable) claims" size of fonts mismatch with thesis text
• "In a centralised fashion, SSL-certificates are achieved through Public Key Infrastructure (PKI)." No tutorials, especially not on page 37 (beyond intro chapter)
• 3.2. ARCHITECTURE; move into related work.
• 3.2.1. REQUIRED FUNCTIONALITIES; part of the problem description chapter
• "Figure 3.6: Interactive Verification" move this to introduction chapter and give it depth.
• "As yearly up to 340.000 identity documents are stolen in a country as The Netherlands, the same amount of revocations must be possible on a year basis"; deeply burried text, promote into problem description.
• no implementation and performance analysis chapter
• Nieuwsuur; embarrassing ref: https://scholar.google.com/scholar?q=identity+documents+loss+and+theft

[InvictusRMC]

Progress Update:

• Focused on results and article in general
• Restructure in thesis

Thesis-Draft-13-07-21.pdf

[synctext]

• Green light 🎊 🎊 🎊
• Needs more science-focus
  • theoretical performance bound!
  • Math approach, like Stannat did: http:https://www.ifaamas.org/Proceedings/aamas2021/pdfs/p1263.pdf
  • the missing revocation layer in "Problem Description".
  • 'Reliable revocation using unreliable communication links'; that what you did?
  • Page 11 table: it was unsolved, but we have solved it!! Move to 2nd page on top. (alter, make each published paper a row)
  • first 8 figures are not 100% scientific, lots of engineering
  • No opening architecture figure
  • Title of "industry-grade" is not scientific (but excellent thesis direction 😄)
  • Math and pseudo code come too late
  • "The Hybrid-Revocation Model (HRM)" anything less boring tbh?
  • Internet lacks identity layer. Key problem to address is revocation. Existing attempts critically rely on communication with central authorities and introduce inequality into the architecture. For the first time we address these problems. We claim our architecture is a viable candidate for the upcoming European-wide identity standard. Our small-scale trail shows that this is a promising direction to further explore.
  • remove subtitle: "On the Realisation of a Fully Distributed Self-Sovereign Identity Framework"
  • Sovrin cryptographic accumulators are complex and too costly. Proof?
• lots of boilerplate pages (65 pages total, not close to the record 14 :-) Bundle appendix into 1 supplementary material section
• You did a live trail! Is that not a "key scientific contribution" to mention? (Creative Commons, CC0)

[InvictusRMC]

Thesis-Draft-23-07-21.pdf

[synctext]

• Page 14: start of the real content, remove even more bloilerplate and clutter. No part " I. " page or "preface" please.
• Opening table: "state of the art in revocation".
• Claim to novelty? first 'fully distributed revocation'. We relax the requirements which are critical in prior works, such as a reliable central server and reliable Internet.
• Our work stretches the spectrum of theoretical analysis, simulation, and real-world deployment.
• nice theory section now! Read and mention more related work: Kwiatkowska. Plus also obviously: 1987 "Epidemic algorithms for replicated database maintenance".
• Lemma 2.1 "spontaneously go offline" why not use a more exciting "sporadically are online"?
• Messy structure: explains with 1) wordy Trusted Authority Storage, 2) Algorithm 3: Revocation Gossip and finally 3) An edge (i, j) ∈ E represents a throughput link of information from node i to j.
• Need better structure: (Section II now has the theory, but is called Revocation Design)
  • Section 2: "Problem Description"
  • Section 3: "Related work" with table
  • Section 4: "Architecture and analysis" or something
  • Section 5: "Algorithms and simulation"
  • Section 6: "Implementation and field trail"
  • Section 7: "Performance analysis"
• Messy figure: "Fig. 12: Simulated propagation time (all gossip intervals)" 3D is unreadable.
• "Deteriorating the assumption", "to the remainder of the group of uninformed to the nodes"
• Simplified storyline:
  • no "Industry-Grade", simply the first solution believe to be usable for mass usage because meets both primary and secondary requirements.
  • no "Hybrid Revocation Model", simply the first fully distributed

[InvictusRMC]

Article revision: Article30.pdf
(Thesis draft too messy)

[synctext]

Offline usage is important: flooding of cities results in Alipay going offline. Digital identities should be disaster-proof.

Or the de-platforming storyline, revocations are a collaborative alternative to Big Tech dictatorships of identity layer. Deplatforming: Your identity gets canceled by a profit-driven entity.
https://journals.sagepub.com/doi/full/10.1177/0267323120922066

Extreme, anti-establishment actors are being characterized increasingly as ‘dangerous individuals’ by the social media
platforms that once aided in making them into ‘Internet celebrities’. These individuals (and sometimes groups) are
being ‘deplatformed’ by the leading social media companies such as Facebook, Instagram, Twitter and YouTube for
such offences as ‘organised hate’. Deplatforming has prompted debate about ‘liberal big tech’ silencing free speech
and taking on the role of editors, but also about the questions of whether it is effective and for whom.

Revocations intro line; because of theft, loss, and big data breaches: https://www.csoonline.com/article/2130877/the-biggest-data-breaches-of-the-21st-century.html

Problem: we need revocations for mass-deployment. Cardinal requirement is that its need to be authority-free. Violating this requirement violates the principles of self-sovereignty itself.

Table I shows no fully distributed SSI revocation mechanism has been proposed yet. First sentence of related work

[InvictusRMC]

Rowdy_Chotkan_MSc_Thesis_IG-SSI.pdf
Rowdy_Chotkan_MSc_Thesis_IG-SSI.pdf

URL: http:https://resolver.tudelft.nl/uuid:32711378-2f6f-452e-b65c-1866c471e934

As also submitted via mail.

[InvictusRMC]

Slides WIP.pptx

[synctext]

Remarks: Example claim/verifier within your fully operational prototype using real Corona example JSON
Where is your contribution to European Commission roadmap

[InvictusRMC]

Defence-Slides-draft.zip
Defence-Slides.pptx
Defence-Slides-Final.zip

[synctext]

Msc Thesis DONE