search

Tribler / tribler

Privacy enhanced BitTorrent client with P2P content discovery
https://www.tribler.org
GNU General Public License v3.0
4.86k stars 451 forks source link

Universal wallet for identity, attestations, and money #4461

Closed synctext closed 4 years ago

synctext commented 5 years ago

Several wallets exist, but they are rarely extendable and are never truly universal. Storing Bitcoins and Ethereum is always seen as different from storing self-sovereign identity attestations. With the European Union PSD2 legislations it is even possible to mix real IBAN Euros with Bitcoins. Unifying these 3 isolated wallet infrastructures has never been achieved.

This Master thesis project will put a unique wallet on the Google App store: a wallet that, in principle, can contain a wealth of digital identities, a life-time collection of attestations, and your (pension) savings plus other types of (cyber)money.

This project has a high ambition level. Hence it is split into concrete feasible steps. We start with cybercurrency and then merge identity into the running code. Concrete steps with increasing ambition level and complexity:

TimSpeelman commented 5 years ago

We achieve zero-knowledge proof agnosticity by using a plugin system.

The focus of this thesis need not be on (crypto)currencies, but a system that encompasses all-in-one (attestations, identity, currency) would be much more innovative.

TimSpeelman commented 5 years ago

Summary of work until now.

What's next:

UniversalAccessManagement01

synctext commented 5 years ago

Meeting minutes:

synctext commented 5 years ago

scientific objective: explore if Distributed Apps are a viable alternative to the uPort smart contract architecture.

synctext commented 5 years ago

As discussed, there seems to be a universal law for the push towards centralisation.

Related work for digital ownership and self-sovereignty:

A solution is that we generalise the viral nature of the GPL software license for data and that you are bound to preserve and honor self-sovereignty. A data GPL. Thus banishing centralisation by principle.

Possible use-case to focus thesis on:

devos50 commented 5 years ago

Define an API for a unified Ethereum, Ripple and Bitcoin wallet. Implement.

Our decentralized market already has primitives for a universal cryptocurrency wallet, see here. However, the interface declaration is most likely not complete and it requires more work. It could be a nice starting point for this project however.

TimSpeelman commented 5 years ago

Signing authorization Chamber of Commerce (CoC)

How does a person know that another person is authorized to sign on a companies' behalf?

  1. It defaults to what can reasonably be assumed, based on the amount and the employee's function.
  2. The Chamber of Commerce offers a service for companies to list their authorized personnel.

The latter is a centralized repository which needs to be maintained by companies themselves. The verifying party then needs to purchase one-time access to this repository. This provides a (rather small) revenue stream for the CoC. As the repository is not always used and may be out of date, the verification is not required by law. Hence, these "credentials" only work one way: if they are present, the person is certainly authorized. If not, the person may still be authorized. Especially in high value transactions, the verifier is inclined to ascertain that the signer is authorized.

Self-Sovereign Identity: the top-level employees receive a signature from the CoC, stating that those individuals are authorized on the company's behalf. These individuals can subsequently authorize other personnel, bypassing the CoC, by providing them with signed statements. This requires:

  1. Software at the CoC to create, share and revoke credentials
  2. Software at the signing company (Subject) to persist credentials and create signed statements for other personnel.
  3. Software at the verifying company (Verifier) to verify the credentials and maintain a copy for legal purposes.
  4. A standardized language for legal signing credentials, to increase transparency and trust between companies doing business.

Concerns:

  1. Bootstrapping: all parties must purchase software which is only valuable when all parties have compatible software and procedures in place.
  2. Revenue: the CoC will lose a (small) revenue stream. Alternatively they may sell the credentials, or sell or lease the software. Leasing the software is perhaps not self-sovereign.

Benefits:

  1. Sovereignty: companies can safely do business without the need for a third party.
  2. Security: overall security of transactions may increase by providing strong authentication and authorization, even online. Also for low value transactions, this becomes interesting. The default (reasonable assumption of authorization) could be reduced (to a certain amount) or even completely removed as a whole.
  3. Flexibility: more complex authorization conditions can be established (e.g. who is authorized to hire personnel, who is authorized to do certain purchases, etc.)
  4. Wider application: this system can be used not only for signature authorization but for any form of representation. The CoC can help in developing a standard language for these purposes.

Personnel authorization becomes a "certificate hierarchy", whereby the company's root certificates are issued by the CoC.

synctext commented 5 years ago

thesis direction and storyline meeting notes:

This weeks sprint: create clickable demo GUI in @egbertbouman selected GUI framework

TimSpeelman commented 5 years ago

Focusing a lot on understanding IPv8 and getting TLSWitness to work, I failed to notice early on that the KvK APIs do not offer the information we need: who owns the company. Alternatively, we could fetch it by downloading an extract ("uittreksel") in PDF and scanning it, but that would be really weak. I have contacted them regarding this issue.

Furthermore, another interesting case popped up, inspecting the extract of an actual company: a company may be owned by another company. This requires a little propagation which should not be too hard to implement, but we'll leave that case for later.

TimSpeelman commented 5 years ago

A little breakthrough today! The TLSWitness adapter for KvK is working (mostly).

Hence, we can request a kvknumber credential by logging in with a KvK username/password combination:

This results in successful attestation and a credential in our wallet:

It took a little while, because the KvK login process is cluttered with a lot of redirects, cookies, SAML request/response and other tokens which need to be propagated througout the session. Hence the procedure currently counts 6 GET/POST calls, not counting the logout procedure.

I could not verify the resulting QR code with the android-app, but I don't think this is an issue with my code.

synctext commented 5 years ago

solid progress! Access to the HandelsRegister-data-services is key. Plus Docker image for official signatures by Chamber of Commerce would be another significant step forward.

TimSpeelman commented 5 years ago

Tuesday July 2nd, I have a few meetings at the KvK in Utrecht.

Furthermore, we discussed the next milestone, set for July 12:

Questions for later:

TimSpeelman commented 5 years ago

Made quite some progress these weeks.

OpenWallet app

Built an OpenWallet app based on the RegieOpGegevens app. The views are near finished, but it still needs some work:

Attestation Server

Got an attestation server and client working (see repo) with the following features:

I have currently programmed three procedures:

The implemented procedure is as follows:

  1. Client invokes api/init over HTTPS with its mid and procedure_id and optional credential data (sent over secure HTTP, never over IPv8)
  2. Server starts the procedure , (optionally) requesting verification of the credentials over IPv8.
  3. Client automatically accepts the IPv8 verification requests (if they match the conditions).
  4. Server fetches the attributes from some data source;
  5. Server "stages" the attestation of these attributes (they wait for incoming IPv8 attestation request).
  6. Client requests api/data which lists all staged attestations for that peer (the actual attribute values, again not sent over IPv8).
  7. Client sends an attestation request for each staged attribute over IPv8 (not in parallel, since IPv8 currently does not allow that).
  8. Server continuously monitors for attestation requests. Upon request it checks if the attestation has been staged and if so makes the attestation.
  9. Client verifies the incoming attestations.
  10. The procedure is complete.

Remaining

synctext commented 5 years ago

Scientific storyline buzz draft: universal attestation architecture. btw please check these regulations

('Starting peer', 1)
('port', 14411)
('mid_b64', '9zEYoM+84qa89iPfe5yEIZ6JhgY=')
('mid_hex', 'f73118a0cfbce2a6bcf623df7b9c84219e898606')
('Starting peer', 2)
('port', 14412)
('mid_b64', 'Y4OuY4JmnMKmNdkB5Wo2IyqTheE=')
('mid_hex', '6383ae6382669cc2a635d901e56a36232a9385e1')
TimSpeelman commented 5 years ago

Had my first meetings with the Kamer van Koophandel today. Two key points came out of this:

  1. The procedure as I proposed: (1) verify BSN, (2) attest to KVKnr puts the KvK at a certain risk because they have to acknowledge a digital identity and attest to the link Pubkey -> Kvknr while their "only" duty is to maintain the link BSN -> Kvknr. Hence the KvK is not as interested in the current offer. We need to find a way to remove this risk. I can think of two solutions:
    1. The attestation contains a reference to the Passport attestation, in effect saying: "we attest to this fact, assuming that this passport attestation is valid".
    2. Probably more interesting: "we attest to the fact BSN -> KVKnr" and the wallet offers a ZKP that combines the two credentials Pubkey -> BSN and BSN -> Kvknr into one proof: Pubkey -> KvKnr. This is probably very interesting to many organizations that root their facts on the BSN. I must check whether this is feasible within my thesis as it is not something IPv8 currently supports.
  2. KvK wants to put emphasis on actuality of data. Hence, before each verification they would like the credential to be refreshed. I argued that this may put the KvK at the center of digital economical traffic, becoming a single point of failure. An alternative would be to check a distributed ledger for revocations. Does IPv8 already offer revocation?
qstokkink commented 5 years ago
  1. The public key serves as the link between the secret kvknr and the secret bsn. You can see this as the SSI substitute for the public key in an HTTPS session, there is no way around it. 1.i. That's intrinsic to the attribute order in TrustChain. 1.ii. Just XOR the kvknr and the bsn together and put that in the attribute?
  2. Seems like they want to control a webportal, like DigiD and not enable an SSI solution.
synctext commented 5 years ago

23 July 2019 meeting. Thesis core idea:

TimSpeelman commented 5 years ago

I have written a small piece that presents an alternative protocol that allows the KVK to commit to a mathematical equivalent of the BSN -> KVKNR relation since they may not be legally allowed to attest to PK -> KVKNR. The idea in short:

  1. The BRP attests to BLINDED_BSN (ElGamal commitm.)
  2. The KVK attests to a blinded function f: BLINDED_BSN -> KVKNR. (ElGamal commitm.)
  3. The subject shares f, KVKNR and BLINDED_BSN with the verifier.
  4. The verifier checks that f(BLINDED_BSN) ?= KVKNR

It uses an ElGamal based commitment scheme which is information-theoretically binding, however slighly adapted. I am aware that this may screw up the entire security, so I still need to prove that the properties hold. This scheme should be computationally-hiding, which I believe is sufficient protection for the BSN.

DRAFT: Attesting-To-BSN-Using-ElGamal-Commitment-Schemes-DRAFT.pdf

TimSpeelman commented 5 years ago

I realised that I only needed one commitment (on BSN), so I could simplify the protocol. Now the math no longer needs proving as it is a straightforward ElGamal commitment. The new idea in short:

  1. The BRP attests to BSN' (Blinded BSN, ElGamal commitm.)
  2. The subject shares BSN', BSN and blinding value r with the KVK
  3. The KVK verifies BSN'
  4. The KVK attests to a tuple (BSN', KVKNR) if a relation BSN -> KVKNR exists
  5. The subject shares (BSN', KVKNR) with the verifier.
  6. The verifier verifies the BSN' attestation and the (BSN', KVKNR) attestation.

I have updated my draft accordingly.

Attesting-To-BSN-Using-ElGamal-Commitment-Schemes-DRAFT-V2.pdf

TimSpeelman commented 5 years ago

After quite a bit of searching, I found the cause for the flaky behaviour of the Attestation flow. The dummy flow I wrote tossed a coin and shared either '2168897456' or '3598846111' with type: id_metadata. It turns out that the attestation for '2168897456' resulted in a "bad hash" according to Quinten which led to a verification probability of 0.666656494140625, insufficient. The other value results in a 0.9999847412109375 probability, thus verification succeeds. After changing the type to id_metadata_big the issue for these values was resolved.

synctext commented 5 years ago

Read you document, nice and fancy crypto! "Given a finite abelian group G of prime order q which is generated by g and h (h 6= g) where discrete logarithm of h to the base of g is unknown by any user in the system." However, please consider the following reliable and simple approach (government OKed):

TimSpeelman commented 5 years ago

The issue with your approach is that a proof of KVK number is required in the private sector which, in most cases, is not allowed to process BSN. Hence, a private company cannot request the attribute BSN, KvK number.

In contrast, my solution allows a private company to request the attributes BSN' issued by government and BSN', KvK number issued by KVK and compare the values of BSN'. I believe it more likely that the private sector would be allowed to use a pseudo-BSN because it is a non-deterministic encryption. Therefore, many can be derived of the original BSN, reducing linkability. Next steps would be:

Both steps require that I first:

I'm working on the latter now.

synctext commented 5 years ago

Check! GDPR compliance and personal data processing...

qstokkink commented 5 years ago

Figured out the .66 matching issue. Turns out that the (3 dimensional) hash vector describing your specific attribute value has a 0 component. This is throwing off the matching calculation.

For no good reason, here is a moving image of the resulting vectors of several values:

anim_hvectors

This will be fixed in https://github.com/Tribler/py-ipv8/pull/543

TimSpeelman commented 5 years ago

Good news! Thanks for looking into that.

TimSpeelman commented 5 years ago

Real BSN pilot unlikely Joost unfortunately does not think it likely that the KVK will run a pilot with real data using BSN. We may however run a pilot based on first and last name, either signed by TU Delft or KVK. We could run a test with BSN but only on fake data.

Validate legal possibilities for Pseudo BSN As mentioned before, I would like to evaluate the legal implications of using a Pseudo BSN. In a few weeks, I will speak to the KVK legal department about this issue. However, it may also be interesting to ask the AP (Autoriteit Persoonsgegevens). We may also be able to consult with an expert in this field, initiated either by the KVK or the TU Delft.

Preliminary Scope (I'm not sure if "preliminary" is correct, four months in.) Build a Self-Sovereign Identity solution that:

  1. provides a user with a Wallet from which a variety of attributes can be retrieved and shared,
  2. allows any party to become an attestation provider, plugging in their systems with minimal coding effort (configurable Docker image, Open Wallet Protocol),
  3. allows the user to add any party's server as a trusted contact to their Wallet (relying on real world trust, no hardcoding of IP addresses/public keys),
  4. allows the attestation provider to configure a list of offered attributes (Open Wallet Protocol),
  5. allows any user to manually verify someone's attributes with their own Wallet app,
  6. allows any party to automatically verify someone's attributes reusing the Docker image,
  7. allows the attestation provider to revoke their data in a privacy preserving manner (liveness, accuracy, availability)
  8. allows public Registrars like KVK to share data linked to a pseudo-BSN (crypto) which a private organization is allowed to verify,
  9. is connected to a mocked (or real) BSN/Pseudo-BSN attestation, and;
  10. is proven to work in practice with one or more pilots including the KVK and other interested parties.

Also:

Possible extension: inter- and intraorganizational authorization management The prelim scope already sounds like quite a bit, and hopefully enough for a decent Masters' Thesis. If time permits, I could take a look at the authorizations ("machtigingen") domain. An SSI solution may help resolve some of the problems in the authorizations domain, such as eased interoperability, low maintenance systems, strong digital identity, preserving organizational sovereignty, etc. However, this is quite a big case. I don't believe that I have sufficient time to put the core focus on this application, but I might be able to create a start and pitch the rest of the idea in the "future work" section.

I do believe that such an extension could really show some of the strengths that an SSI solution such as this one can provide.

synctext commented 5 years ago

authorised representative as key use-case. Simply bypass BSN issue for now with last-name. Demonstrate the verifiable claim principle and authorized representative. Avoid ontology complexity matters at all cost! Focus on the linkage and portable digital claims: natural person plus legal entity.

synctext commented 5 years ago

Discussion outcome:

TimSpeelman commented 5 years ago

A short explanation of one use case, foreign authorization certificates (volmachten), that is of special interest to ING which our technology may contribute to:

Scenario: signing deals in other countries

ING authorizes employees or third parties such as notaries to close deals in their name. In the Netherlands, these authorization certificates (volmacht) are issued at and signed by the Chamber of Commerce. When deals occur in other countries, such authorization certificate needs to be "legalised", as is the case with many public documents that (must) have legal consequences.

Note that this process is two-fold:

  1. First issue, legalise and verify the authorization certificate, then;
  2. use this certificate to sign any contract.

Subproblem: Legalisation and Apostille

Legalisation agreements differ per country, but usually involve the following:

  1. A document travelling from a source country A to a destination country B (1) first passes the Ministry of Foreign Affairs (or court room) of country A which checks: a. the validity of the signature (possibly using a signature registry) and; b. verifies that the document is genuine and correct.
  2. Then the stamped document goes to the Embassy of country B which also checks the validity and the stamp of A. Finally, the document has legal effects in country B.

To speed up this process, 108 countries including the Netherlands have signed the Apostille Convention, stating that the second check is no longer necessary as they trust the first stamp is sufficiently qualified. Within the EU, this Apostille is not even necessary anymore for certain documents as of 2016.

The eletronic Apostille Program (e-APP) is an attempt improve and secure this process even further. It involves two stages: (1) the source country issues an e-Apostille (PDF with optional XML layer) and (2) it operates an e-Register, a simple database allowing lookup of e-Apostilles issued by that country given a number and date. This is an important step in combating fraud which is much easier with paper-based procedures. Over 25 countries work with e-APP like the UK, US, Belgium. Remarkably, although Apostille is founded in The Hague, the Netherlands does not yet provide it.

Main issues:

  1. paper document travel is slow,
  2. paper stamps and signatures are vulnerable to fraud,
  3. manual verification of the document is required by an authority in country A (and optionally an embassy of country B).

Authorization Certificates

When a representative from country A signs a deal in country B, a legalised authorization certificate is required. The notary must hence receive the legalised document, either on paper or digitally, verify the stamp(s) on it by the proper authorities (or check the e-Register), make sure that the represented party is correct and authenticate the representing party. Only then can they sign the deal.

TimSpeelman commented 5 years ago

Draft of Problem Context Description

In business, and society, one party's success often relies on the honesty and competence of another. Those who are able to distinguish the good from the bad apples have the best chance of survival. To tell the difference, the relying party needs to gather the relevant knowledge about the subject, i.e. the apple. Depending on the kind of business, it may be relevant whether the subject meets a minimum age, knows a certain language, or is experienced as a programmer. The relying party may acquire confidence in these traits before business proceeds. However, if it is the benevolence or honesty of the subject that matters, the parties will first have to establish trust.

In general, the subject cannot be trusted to deliver the relevant facts that enable the business, i.e. do not trust the teenager to honestly tell her age when buying a drink. This example clearly shows the problem: the subject is at a conflict of interest. One solution is for the relying party to assess certain traits by itself. For an employer, questioning an applicant about the work specific knowledge, may be a reasonably cheap and effective way of doing so. In contrast, a home owner is likely unqualified to quiz a contractor about bolts and screws. The irony is that trust and confidence are usually products from a history of (risky) transactions, while they are also supposed to be a precondition. Again, the employer can risk a trial period with the employee, but for the home owner this is not feasible. As risk comes with failure and failure comes with cost, building trust or confidence first hand may be expensive.

When one recommends a restaurant to a friend, we see the transfer of trust. For the friend, the risk (and cost) of visiting that restaurant is now lower. It follows that trust has value, both for the friend as well as the restaurant. Reputation, an age-old mechanism for sharing of trust, is still considered the one of the most prized posessions of people and organisations. Friends are inclined not to lie about restaurants and restaurants are inclined to keep up their quality. This illustrates that reputation has a self-preserving effect; it keep one on the straight-and-narrow.

Reputation, and trust, are not generic qualities. We trust the friend to be honest about this restaurant, assuming there is no conflict of interest, and we deem him capable of making such assessment. But for a hygiene-check we'd rather trust the health inspection. The attestation from a friend is valuable because the source is trusted regarding that attestation. The same mechanisms work a macroscopic scale: modern-day society is built of all sorts of institutions that have their own expertise and aim to preserve a good reputation specific to that expertise. Hence, we trust the bank with our money but not with our darkest secrets. We trust consumers to review shops, taxi drivers and service providers and the products and services they offer. We trust schools to assess knowledge and skill of individuals, but only trust doctors to assess their health.

Zooming out reveals a complex network of entities, each contributing their honorable word to make the next transaction a little safer. Identity information about individuals and organisations is exchanged through all sorts of networks, channels and media. It is at this complex infrastructure, the storage and exchange of possibly vulnerable information, where issues arise. These issues, regarding the privacy and autonomy of individuals and the risks of identity fraud or theft, have led to numerous laws and security measures which increase complexity and cost of the identity exchange. One prominent example is the amount of effort and money banks currently put into Know You Customer (KYC) and Anti Money-Laundering (AML) procedures. The current infrastructure does not suffice, but if these issues were to be relieved, we can tap into a wealth of potential.

The latest development in this area is coined Self-Sovereign Identity and it is looking very promising. By a series of technologies involving smart phones, cryptography and distributed ledgers this new concept proposes to put the control of identity information back into the hands of the individual, the subject, whom the information concerns. By putting a secure and persistent digital identity in the hands of the individual, the rightful owner can make a strong claim on that identity at all times. Providing such a very secure and universal means of authentication combats identity fraud. Moreover, as this technology resides at the subject, it is available to all trusted sources and relying parties, which saves even more cost.

Self-Sovereign Identity could be the new infrastructure that carries the identity exchange. By sharing the infrastructure, these solutions could become very cheap and accessible. By providing all sources and all relying parties with the tools to issue and verify a subject's credentials using strong identities and signatures, the limiting issues could be relieved and the promised potential unlocked. But while this technology is next to ready, it is not yet adopted at large scale. One open challenge is how to coordinate the exchange of information, now that the source no longer controls the medium of disclosure, nor who receives the information.

What is required is a standardized communication of identity information that meets the needs of all parties involved. This standardization must occur at the right level of abstraction, so it does not limit the possibilities, yet enables parties to quickly and affordably reap the benefits of this new channel. It must facilitate sources and relying parties to establish a mutual understanding of the meaning and (legal) implications of the identity information being shared. But also, as the main intent of SSI, the subject must be involved in this play as well. It must unequivocally understand the value of the information it receives and is being asked for, in order to be fully autonomous. However, this infrastructure concerns all levels of society, even those without an affinity to technology or elevated conscience about identity information and its implications. As it requires the individual to play along, the technology must also be really accessible.

This thesis will focus on a Semantic Layer, making the interplay between source, subject and relying party accessible and meaningful in a way that suits the multi-stakeholder requirements of the real world and preserves the qualities that Self-Sovereign Identity promises.

synctext commented 5 years ago

wild idea: write thesis in DID W3C specification style and submit proposal with implementation experience

This thesis is focused on a problem at the intersection of computer science, business, legal, and social science. identity is a broad topics with political sensitivity. Proving your identity goes beyond traditional computer science. Every day citizens authenticate themselves to government officials. Creating less friction, cheaper, and more secure alternative has high impact on society. The Internet lacks an identity and authentication framework. This thesis takes a practical approach and small step to filling this void. Our ambition level is creating a primitive prototype which could form the foundation for a Internet-wide identity framework.

Numerous identity frameworks have been created in the past 28 years since the invention of PGP. No of these frameworks have proved to be viable. Most effort in this this has been spend to understand the requirements, expectations, and business opportunities to make the first identity framework which is both viable and self-sovereign.

Effort has been focused on real-world deployment and legal grounding.

synctext commented 5 years ago

Great insight of yours: remove party with any stake. Net neutrality defines the freedom of communication, "identity&trust technology neutrality" is a novel concept we define here. In a more general scientific formulation: an identity and trust system MUST be neutral and self-governing. It is REQUIRED to be stripped of all conflicts of interest from stakeholders, return-on-investment influence, veto power of technology providers, ownership of source code. It also SHALL be self-sustainable with self-goverance, similar to Bitcoin, DAO, and Bittorrent ecosystems. ToDo: create "Tim Triples", which are the running code equivalance of the philosophical commandments of Allan. ToDo: landscaped information-overloaded architecture PNG of your thesis prototype (PUSH,Revoke,semantic module,..).

TimSpeelman commented 5 years ago

Draft Technical Context Model

I have drafted a picture illustrating the relevant technical components that shape the context.

ContextTechnical

SSI Core is not the appropriate term I think. It may be the core of my thesis, but not the core of SSI, which should include IPv8.

Note that I aim to design a uniform Peer that is capable of playing all roles (issuer, holder, verifier). That's why it is both controllable from a GUI (Wallet-application on end-user device) via (b) or from a programmed "Controller" via (c). Both (b) and (c) have administrative/ownership rights.

The stack uses IPv8 obviously to connect with other peers via (g). The core may also communicate directly to the core of another peer via (h). Keys and encrypted credentials may be stored in an on-device Vault (e). A camera and other peripherals may also be used to communicate.

Integration with custom logic is appropriate via two channels:

Note that I have left out a direct connection from the core to external systems. This means all third party systems have to integrate with this SSI solution, instead of being compatible out of the box. One nice feature would be if the wallet could connect via OAuth, because existing systems would not need to be adapted. As far as I know, OAuth requires an authorization server, so that does not seem a viable option.

qstokkink commented 5 years ago

https://pages.nist.gov/800-63-3/sp800-63-3.html https://www.forumstandaardisatie.nl/sites/bfs/files/atoms/files/HR-Betrouwbaarheidsniveaus-v3-2014.pdf

TimSpeelman commented 4 years ago

Meeting minutes:

synctext commented 4 years ago

perfect, Jan sprint on attestation for representing a company, Feb possible field trail with a few test subjects.

synctext commented 4 years ago

Schedule:

Thesis feedback:

TimSpeelman commented 4 years ago

I propose to phrase the main research question of my thesis as follows:

How can one practically verify an actor's qualifications using a scalable Self-Sovereign Identity infrastructure?

I will elaborate using the following subquestions:

  1. What mininum-viable constraints are imposed by the Self-Sovereign Identity paradigm?
  2. How can a user have smart phone based control over his identities, their data and signatures.
  3. How can a Self-Sovereign Identity infrastructure interoperate with as many use cases as possible?
  4. How can we minimize the impact of such verifications on the privacy of the parties involved?
  5. How can we prevent identity fraud when verifying one's qualitifications?
  6. How can a verifier rely upon information provided by a subject, even when he does not know or trust the issuer of that information directly?

I will use the case of Authorizations/Machtigingen as formulated together with the KVK as the running example througout my thesis. At the end of my thesis, I describe the app I built (ZekereZaken) which is the embodiment of this example, and how this performed in a field test.

Note that the overarching goal is to create a shared Self-Sovereign Identity infrastructure that supports many more identity use cases than the one covered by my app. However, as I will argue in my introduction, it is infeasable to create this from scratch. Therefore, the approach is to take a (still quite generic) function of digital identity and design a system for it from theory to practice and then present the findings of this design exercise in such a way that it could be extended to other applications.

TimSpeelman commented 4 years ago

At the last meeting, we discussed the outline of my thesis needed some more work. I propose the following rearrangement. Note that the fundamental problem is explained in (2) Problem Description, and its practical manifestation in (3) Example Problem: Extended Power of Attorney. Then chapter 4 thoroughly explores the concept of Self-Sovereignty (which is still poorly covered in academic literature) and proposes a model for framing it. Chapters 5 through 7 describe my contributions, the solutions to the problems mentioned in (2). We then implement in chapter 8, test that in the field in chapter 9 and finally conclude and propose directions for future work.

I have added estimated page count per chapter, and the Research Questions that sections address.

  1. Chapter 1 - Introduction (6p)
    • Identity is Everywhere
    • The Evolution of Digital Identity Systems
    • The Need for a Shared Infrastructure
    • Self-Sovereign Identity, a new paradigm
    • Research Questions
    • Document Structure
  2. Chapter 2 - Problem Description (6p)
    • Verifying an actor's qualifications (RQ5)
    • A distributed identity infrastructure (RQ1, RQ3)
    • An untrusted subject presenting evidence (RQ2)
    • An untrusted source issuing evidence (RQ6)
    • Minimizing privacy leakage (RQ4)
  3. Chapter 3 - Example Problem: Extended Power of Attorney (6p)
    • Usage Scenarios
    • Executive Power over Legal Entities
    • Extending Power over Legal Entities
    • Actions versus Jurisdiction
    • Logic to Qualify
  4. Chapter 4 - A Theoretical Framework for Self-Sovereignty (RQ1, RQ3, 8p)
    • Dimensions
    • Principles for Individual Sovereignty
    • Principles for a Self-Sovereign Identity Infrastructure (RQ3)
  5. Chapter 5 - A Universal Agent: Representation and Control (RQ2, RQ3, 8p)
    • ..
  6. Chapter 6 - Untrusted Sources: Propagating Trust (RQ5, RQ6, 6p)
    • ..
  7. Chapter 7 - Data Minimization and Anti-Correlation (RQ4, 6p)
    • ..
  8. Chapter 8 - A First Application: Representing Legal Entities
  9. Chapter 9 - Implementation (8p)
    • IPv8
    • Agent
    • Wallet
    • Zekere Zaken App
  10. Chapter 10 - Field Trials (4p)
  11. Chapter 11 - Conclusions & Discussion (3p)
  12. Chapter 12 - Future Work (2p)
synctext commented 4 years ago

very good. Last 2 points are security. Can these specific partial issues be captured into 1 end-to-end "guaranteed integrity" research question?

synctext commented 4 years ago

Comments on progress:

synctext commented 4 years ago

Conclusion from our discussion: Irreducible complexity and messiness of reality which can't be captured in beautiful simplistic Alice and Bob models. Who owns it? Expand the Internet ownership model: owned by both nobody and everybody. Attempts to address the last remaining open problem of the governance risk: "An efficient distributed PKI for structured P2P networks", also "Chord-PKI: A distributed trust infrastructure based on P2P networks", etc. plus loss recovery and theft locking. One paper quote "The proposed solution does not handle certificate revocation and expiration since the employed trust model does not deal with these aspects." IMG_20200312_113044

TimSpeelman commented 4 years ago

To summarize our existential crisis meeting of today @synctext :

devos50 commented 4 years ago

closing the reality gap

will that be sufficient scientific contribution, and sufficient to graduate?

I think exploring (and closing) the gap between theory and practice is a strong (and unique) scientific contribution 👍

dusterbloom commented 4 years ago

Go ahead with your work. Definitely needed as banking is imploding and new trust paradigm will need to emerge in the emergency

TimSpeelman commented 4 years ago

The past two weeks have not been as productive as I had hoped, primarily due to the Corona virus. Also, I have had difficulties with balancing the ambition of closing the reality gap, with the reality of closing my thesis project.

The result is the following problem description, which is still a bit rough, but should completely describe the problem and scope of my project. Note that chapter 2 is the generic problem description (mostly theory) and chapter 3 is an in depth description of the practical problem I will be solving (with KVK): representing (or acting on behalf of) legal entities. Feedback is very welcome.

Thesis0327-Ch2-Ch3.pdf

qstokkink commented 4 years ago

Did a quick review. Overall the storyline is pretty good. In detail:

General:

Chapter 2:

Chapter 3:

synctext commented 4 years ago

Overall the storyline is pretty good

Good stuff indeed! Solid progress for your thesis, no need to deviate from this path anymore. Sprint remarks:

TimSpeelman commented 4 years ago

I have drafted most of chapter 5, the analysis of the TrustChain/IPv8 stack upon which I build the semantic layer. There is one more small section left to write, but I would already like to share this work for feedback. Specifically:

  1. I am slightly confused by the naming of technologies and protocols, IPv8 and Trustchain, the naming and scope seem different in the papers, documentation and IETF draft. Can you help me clarify this?
  2. I would like to know what you think of the Identity Fraud analysis.
  3. I discuss the privacy implications of the fact that attestations are being treated as public. @qstokkink we have discussed this a while ago. I would specifically like your feedback on this.

Note that solving metadata leakage is out of scope for my thesis.

Thesis20200418b.pdf

qstokkink commented 4 years ago

Looking good. I liked the remark about the DHT anonymization: @egbertbouman do you want to combine both of your babies into one?

Regarding the metadata: metadata visibility is one of three things that critically need to be changed before we can deploy for real (though metadata should not include private values -- metadata leakage is indeed a thing), but I have left these out for ease of use. We spend/spent most of our time testing anyway. However, given the fact that other people are starting to use our implementation, we should probably make these changes on the main branch soon.

Given the direction Trustchain is heading in (with the noodle protocol), I may have to do a hard protocol break soon anyway. Trustchain will then turn into something different: a DAG with no consensus, bilateral agreements and selective visibility of attributes (@synctext we need a new name 😃). At that point, it may also be wise to move the identity part of IPv8 to its own repository (possibly the noodle Trustchain would also move -- into AnyDex or the Tribler repo?).