Tribler: Universal wallet for identity, attestations, and money

[synctext]

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:

• [ ] Understand the #2943 IPv8 plug-in running code and existing (identity) wallet solutions.
• [ ] Explore attestation solutions and their (lack of) running code
  
  
  
  • Zero-Knowledge Proofs (ex. Ethereum’s zk-SNARKs [MSK16]
  
  
  • Stanford’s Bulletproofs [BBB18])
  
  
  • verifiable computation using blockchain (ex. MIT’s Enigma [ZNP15] and UCL’s ClaimChain [KIT17]).
  
  
• [ ] Create a Bitcoin wallet in pure Python using IPv8 plug-ins
• [ ] Create a zero-knowledge proof as a IPv8 plug-in for flexible attestations
• [ ] Define an API for a unified Ethereum, Ripple and Bitcoin wallet. Implement.
• [ ] Integrate IPv8 identity and Trustchain stack. Ability to send coins to an identity safe and securely.
• [ ] Integrate PSD2 IBAN accounts
• [ ] Brainstorm on an advanced "wow"-factor feature, such as:
  
  
  
  • [ ] legally valid signature with your identity, using notary integration #4458
  
  
  • [ ] attestations for legal entities, work with Dutch Chamber of Commerce
  
  
  • [ ] work with the Bitonic currency exchange and market maker; create an "Exchange DAO".
  
  

[TimSpeelman]

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]

Summary of work until now.

• Read up on Self-Sovereign Identity.
• Read Mitchell's ticket https://github.com/Tribler/tribler/issues/2943
• Took a look at https://github.com/Tribler/py-ipv8
• Summary of findings and thoughts available on https://ssi.timspeelman.nl/
• In particular trying to understand and generalize SSI, by analyzing/formalizing an interaction scheme
• In general, trying to understand the reasons behind decentralization (wider view)
• Formulated a simple example on University Admission
• Briefly looked at mortgage application. Although a wealthy launching customer, a lot of bootstrapping is perhaps needed to make this work. Discontinued
• Currently looking into Universal Access Management. Perhaps needs focus on concrete example. General case too hard to solve in one go.

What's next:

• MVP for UAM: what use case to automate first? Which stakeholders involved? How to discover their interests?
• Talk to ministry

[synctext]

Meeting minutes:

• check IPv8 / Docs directory with tutorials for omissions and errors (e.g. need maintenance PR)
• Universal Access Management picture is quite complex. Tough to flawless implement.
• simplify for 1 or multiple use-cases
• focus on single use-case at some point and push to high Technology Readiness Level?
• smart door use-case?
• Core of thesis?
  
  
  
  • who will use this universal wallet, launching customer..
  
  
  • universal access SDK with passport-grade wallet?
  
  
  • SSI ?
  
  
  • signature registry for legal entity representatives ?
  
  

[synctext]

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

[synctext]

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

Related work for digital ownership and self-sovereignty:

• Any decentralized system that is more efficient if centralized, eventually gets centralized by efficiencies of scale. From HN thread
• MIT: Defending Internet Freedom through Decentralization:
  Back to the Future?
• Upspin manifesto the ownership and sharing of data
  I want my home directory to be where all my data is. Not just my local files, not just my source code, not just my photos, not just my mail. All my data. My "phone" should be able to access the same data as my laptop, which should be able to access the same data as the servers.
• Plus: https://github.com/redecentralize/alternative-internet/blob/e6266bdc8aa20fa35d73e620bbe699751db17030/README_AGE.md

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:

• https://www.kvk.nl/advies-en-informatie/fraude/is-mijn-zakenpartner-tekenbevoegd/
• https://www.docusign.com/products-and-pricing

[devos50]

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]

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]

thesis direction and storyline meeting notes:

• For instance: "after 28 years since digital identity infrastructure was first proposed we aim to close the gap between theory and reality".
• propose a generic infrastructure and implementation framework
• document in IETF format (e.g. contribute to the co-author level?)?
• experimental validation of the digital identity architecture
  
  
  
  • two or more use-cases
  
  
  • re-usage of existing PY3 Android backend code
  
  
  • IEEE article writeup?
  
  
• example we did before: http://pure.tudelft.nl/ws/files/41225519/article.pdf

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

[TimSpeelman]

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]

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]

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]

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

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

• [ ] Open Wallet app based on RegieOpGegevens
  
  
  
  • [ ] Preconfigured with KvK IP and PK
  
  
  • [ ] Allows user to request the KvK attributes
  
  
  • [ ] Stores the attributes
  
  
  • [ ] Contains a mocked ItsMe attestation (passport grade authentication of natural persons)
  
  
• [ ] Attestation server as Docker image
  
  
  
  • [ ] Contains mocked data
  
  
  • [ ] Requires ItsMe authentication
  
  
  • [ ] Signs all attributes that belong to the ItsMe identity
  
  
  • [ ] Shares all attributes with Wallet
  
  

Questions for later:

• What are the difference between Portal and Wallet approach?
• Extend to DNB: bevoegd & bekwaam bestuurdersverklaring
• https://scholar.google.nl/scholar?hl=nl&as_sdt=0%2C5&q=pki+failure&btnG=

[TimSpeelman]

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:

• [ ] Connect to the attestation procedure (see below).
• [ ] Store the received attributes locally.

Attestation Server

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

• The attestation server ..
  
  
  
  • can be configured with _Procedures_, which:
  
  
  • offer one or more attributes that can be attested in one go (e.g. kvk-nr, kvk-entry-date)
  
  
  • demand verification of zero or more attributes/credentials (e.g. bsn).
  
  
  • offers a REST API with two endpoints /init and /data
  
  
• The attestation client ..
  
  
  
  • can be configured with _Procedures_, just like the attestation server
  
  
  • invokes the REST API and makes the calls over IPv8 correspondingly.
  
  

I have currently programmed three procedures:

• Attestation of bsn (no credentials needed). The server gives out BSN numbers, so we can use these later for the KVK procedure.
• Attestation of kvknr based on bsn. The server has a lookup table from bsn to kvknr.
• Attestation of multiple attributes. Only to test that multiple attribute-attestation also works.

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

• [ ] Put this in a Docker image.

[synctext]

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

python run_ipv8.py ('Starting peer', 1) ('port', 14411) ('mid_b64', '9zEYoM+84qa89iPfe5yEIZ6JhgY=') ('mid_hex', 'f73118a0cfbce2a6bcf623df7b9c84219e898606') ('Starting peer', 2) ('port', 14412) ('mid_b64', 'Y4OuY4JmnMKmNdkB5Wo2IyqTheE=') ('mid_hex', '6383ae6382669cc2a635d901e56a36232a9385e1')

[TimSpeelman]

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]

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]

23 July 2019 meeting. Thesis core idea:

• real deployment trial of SSI
• liveness and accuracy of legally-binding registry is essential:
  
  
  
  • Trustchain ledger availability
  
  
  • revocation list dissemination (scientific problem)
  
  
• ongoing work: dynamic attribute loading
  
  
  
  • attribute neutral API, re-usable for other attribute issuers
  
  
  • find a solution for hard-coded well-known public keys (trustworthy serverless issuers discovery:-)
  
  
• for now focus on experimental part of thesis.

[TimSpeelman]

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]

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]

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.

• [ ] Upon attestation, the subject or preferably the issuer should verify that the hash is good.
• [ ] It would be nice to have some indication of the range of values id_metadata/big/huge can carry, other than 'bad luck'.

[synctext]

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):

• [ ] government official or notary inspects your passport
• [ ] they inspect you digital signature (e.g. public key) with successful challenge/response
• [ ] they check if you BSN has a reported stolen passport, you're declared unfit for legal capacity (_Handelingsbekwaamheid_) or other open issues
• [ ] an attestation is given for public key, BSN
• [ ] chamber of commerce can safely issue BSN, KvK number attestation

[TimSpeelman]

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:

• [ ] 'Check with legal' that this is indeed allowed (Joost will hook me up with the legal dept.)
• [ ] Check with the RvIG whether they are willing to attest to BSN'.

Both steps require that I first:

• [ ] Explain this problem and solution very clearly in a simple image.

I'm working on the latter now.

[synctext]

Check! GDPR compliance and personal data processing...

[qstokkink]

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:

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

[TimSpeelman]

Good news! Thanks for looking into that.

[TimSpeelman]

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:

• [ ] Evaluate why the peer-to-peer characteristic is valuable. Perhaps one of our demos/use-cases could demonstrate this value.

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]

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]

Discussion outcome:

• problem description {second priority for now}
  
  
  
  • Chamber of Commerce legal entities registry
  
  
  • passport-grade identities for organisations (wallet, signatures, attributes, verifiable claims, etc.)
  
  
  • requires well documented procedures and software
  
  
  • legal validity and legal certainty are essential for economic uptake
  
  
  • Thesis challenge: find fit between the software architecture and the legal framework
  
  
• get first prototype on Google Play store for demonstration at financial institutions.
• use-case "Form 13", authorised representative.

[TimSpeelman]

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]

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]

• introduction readable for social science people
• problem description
  
  
  
  • sharp and precise definitions which are only computer science understandable
  
  
  • historical evolution; PGP, OpenPGP, RFC 4880 (November 2007), itsme, Sovrin, etc. plus experimental deployments
  
  
  • requirements and how systems such as Sovrin partially meet them
  
  
  • deploy and incrementally grow paradox; technically it needs to expand; legally it needs to be perfect, water-tight, have full legal certainty from day zero.
  
  
  • bootstrap problem; who is going to provide the initial trust
  
  
  • movement gridlock; who will pay, build, and own the ecosystem: tech provider, platform owner, government, open source community
  
  
  • incentive misalignment; a fundamental problem exists for the incentive to issue identity credential. The potential providers have all the problems, no viable business model, and the benefit arises elsewhere.
  
  
  • lack of requirement readability. Legal texts are the key source for requirements. However, these legal texts have been written without any knowledge of technological capabilities and impossibilities. In direct conflict with the self-sovereign paradigm. We need to translate requirement by legal scholar and privacy advocates into technology. Technological viable mechanisms are difficult.
  
  
• design of TimChain: details of choices and improvements on Hyperledger, GPG, etc.
• implementation and discuss the Docker results
• field trial: here is why our stuff is so much more fit-to-requirements and thus viable, compared to uPort and Sovrin
  
  
  
  • KYC
  
  
  • "ondertekenen op afstand", Notary
  
  

_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]

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]

Draft Technical Context Model

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

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:

• As the Controller has full rights, anything can be programmed through this channel. This is especially useful for creating issuing/verification servers, etc. Any data source for issuing would be integrated with SSI via this channel.
• Second, I consider on-device 3rd party applications. These applications are considered untrusted by default, so permissions need to be set via control channels (b) or (c). Examples are custom biometric verification applications, airline company apps, or basically any app that wants access to identity information.

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]

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]

Meeting minutes:

• The last few weeks I have spent working on a theory of the _identity supply chain_ in order to motivate the SSI solution I wish to build on top of it. This effort has been futile. I have gained some nice insights in the matter, but the work is not directly usable for my thesis.
• The next few weeks I will move my focus back to the semantic layer I wish to build on top of IPv8.
• In Januari I plan to do a sprint, further developing the Wallet to support the case of authorizations rooted in the registry of legal entities (KVK/Handelsregister):
  
  
  
  • The KVK (or a notary as proxy) can issue a statement that a subject owns a company.
  
  
  • The owner of a company can issue a statement that a subject may represent that company.
  
  
  • A third party can verify that a subject is allowed to represent a company, and hence access some resource.
  
  

[synctext]

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

[synctext]

Schedule:

• April wrapping up aim
• Field trial 3 notary checks and accounts
• zekerezaken.nl as core of thesis practical work
• native wrapper for Android local execution; replace central website (React.js)
• possible extend https://github.com/Tribler/kotlin-ipv8 with webviewer

Thesis feedback:

• model of (Cameron) Allen is clarified, shapend, structured and made feasible + actionable
• New Dutch model of self-sovereignty

[TimSpeelman]

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]

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]

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

[synctext]

Comments on progress:

• very detailed top-down thesis ToC.
• good starting point, please write Chapter 9 in parallel with chapter 1..8
• still unclear to me what can be visualised in Chapter 10.
• field trial: notary is prime realistic option (check ID, legal representative, online check, legal opinion)

[synctext]

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."

[TimSpeelman]

To summarize our existential crisis meeting of today @synctext :

• My thesis focuses on "closing the reality gap", i.e. "Why Alice and Bob cannot solve this problem"
• Hence, to realize Digital Identity in practice, we must apply the theory (on the problems of Alice and Bob) to actual use cases.
• However, this creates a whole lot of many smaller problems (which until now have been swept under the rug of implementation details) which must be solved before we can actually realize it.
  
  
  
  • This has lead my problem description to be all over the place.
  
  
• So if I cannot clearly define one or two problems that I can address and possibly solve in my thesis, I must somehow address the complexity of all these details.
• Yet, it is also impossible for me to solve all that (i.e. close the gap on my own), so my contributions are
  
  
  
  • (1) exposing unsolved details and
  
  
  • (2) solving some of them.
  
  
• My existential crisis is: will that be sufficient scientific contribution, and sufficient to graduate?

[devos50]

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 👍

[peppilittera]

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

[TimSpeelman]

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]

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

General:

• All of your claims and terminology must be backed up by either proof or a reference (or they need to be common knowledge) -- I'm going to be complaining a lot about this in the following points.

Chapter 2:

• (2.0) How do your two problems emerge? Not obvious how these emerge from the thesis goal of "verifications of practical qualifications".
• (2.0) "Alice and Bob engage in some transaction which involves risk to Bob." What is risk?/How is it risky for Bob?
• (2.1) What are IRMA, Sovrin, uPort and Trustchain?
• (2.1) What is cryptographic trust?
• (2.1) What are the different ways solutions provide a means for revocation?
• (2.2) Who is Cameron, what did he argue?
• (2.2.1) Who is Allen?
• (2.2.2) How can actors have different understandings?
• (2.2.2) What freedom of choice is there?
• (2.3) What is TOR?
• (2.3) When I search for Trustchain, it shows no mention of using TOR.
• (2.3) When I search for Trustchain, it shows no mention of being used in trials with the Dutch government.
• (2.4.1) Seems we have multiple types of risk. A table of types of risk would help here.
• (2.4.1) What is the W3C and what are Verifiable Credentials?
• (2.4.3) What is Cameron's seventh law? "the portal based approach is not the most efficient"?
• (2.4.4) "Issuing and Verifying organizations will likely want to manage their processed [...] on cloud infrastructure", do you have proof for this?

Chapter 3:

• (3.0) "For many day-to-day activities [...] such rigor is unnecessary [...]", why (do you perhaps have an example)?
• (3.2.1) Table 3.1, add column headers: what is in the left column and what is in the right column?

[synctext]

Overall the storyline is pretty good

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

• separate cryptographic integrity and business-level integrity. Interoperability does not seems like the optimal term to cover this (but that's merely thesis writing semantics). Accepting claims from a party means trusting them! Goes beyond parsing bits, checking signature, and protocol interoperability. By trusting somebodies verifiable claim you form more of a partnership. Even more dramatic, with large-scale attribute exchange you form a digital society with trust exchange.
• "2.3 Building on top of Trustchain" non-scientific formulation. "2.3 Identity, privacy and semantics". Selecting a technology to use is not something to discuss in the problem description chapter. Suggestion: the state-of-the-art in this field lacks proper Tor-level privacy etc etc. However, Trustchain is still immature and lacks semantics and revocation, etc etc. This thesis aims to offer both SSI, privacy and semantic-rich etc. etc.
• "If this process is somehow corrupted, the Verifier relying on that claim is at risk." This is more general. The value, integrity, believability, and trustworthiness of any claim depends on the quality of the issuer. please make it broader.
• "2.4.3 User Convenience" Only Github developers use sophisticated pub/priv key crypto. Normal people don't. SSI is like giving a live hand grenade to a monkey :hear_no_evil:
• more citations needed https://www.usenix.org/conference/8th-usenix-security-symposium/why-johnny-cant-encrypt-usability-evaluation-pgp-50
• "Example Problem: Extended Power of Attorney". title needs polishing. "authorisation by legal entities", "digital certificates with legal standing", "design of digital trust propagation"

[TimSpeelman]

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]

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?).

[qstokkink]

Actually, now that you're working on this anyway, I was considering the following approach:

• Pseudonym _P1_ (user) has attributes _A(P1, 1)_, _A(P1, 2)_ and _A(P1, 3)_ and metadata _M(P1, 1)_, _M(P1, 2)_ and _M(P1, 3)_. None of the attributes or metadata entries are visible to any other peer. Attributes are linked binary data (higher indices point to lower indices), indistinguishable from each other (only the semantics M provide insight into what these binary blobs may be). The semantics _M_ contain the attestations and descriptions of protocols and such (what is in there right now too), one-way links to a particular attribute.
• Pseudonym _P2_ (verifier) requires proof of two standardized metadata types _m1_ and _m2_ and will request proof of _[m1 -> m2]_ from _P1_.
• _P1_ receives the request of _P2_ and the user may select this pseudonym (_P1_) to prove the contained attributes to the verifier (_P2_) or reject this request (and this control flow will stop -- we'll assume the happy flow and continue).
• Suppose _m1_ is equivalent to _M(P1, 1)_ and _m2_ is equivalent to _M(P1, 3)_: _P1_ will send _P2_ the following: _{A(P1, 1), A(P1, 2), A(P1, 3), M(P1, 1), M(P1, 3)}_ . Note that _A(P1, 2)_ is required for pseudonym integrity.

This is a break with how Trustchain dictates functionality right now (and the reason we'll have to fork off an identity Trustchain derivative). If you want, you can flesh this out in your thesis.

[qstokkink]

Side note: I put the refactoring on the agenda for IPv8: https://github.com/Tribler/py-ipv8/issues/733

[TimSpeelman]

Thanks for the feedback. Before committing to any more work, I would like to understand why we need private attributes to be in a linked datastructure any way. Suppose we did not have that datastructure, which attacks are possible?

As far as I understand it puts three constraints on the pseudonym:

1. It prevents* reordering of attributes
2. It prevents* hiding/removing of attributes
3. It prevents* insertions (except appends)
   (* prevents or exposes)

Reordering
Suppose we relax the reordering constraint, what fraud becomes possible? When do we care about attribute order? For example two versions of the same attribute, say home address, we must know which is first and which is last. Or whether a revoke occured before or after a particular verification. Can we not solve this by simply including a co-signed timestamp?

A timestamp offers more information than simply ordering and is already included in the metadata right now. This is important for doing historical verifications: where did you live three years ago?

The only concern with a co-signed timestamp is it can relies on one party being honest. If this assumption cannot hold, maybe we should build a TimestampCommunity.

Am I missing any other attack that you can do when reordering is possible?

Hiding
First of all, subjects should have the right to hide and delete/forget. Furthermore, inability to hide data could enable other parties to coerce the subject into exposing the data.

If subject-repudation is a possible attack, this can be countered by the fact that verifiers or issuers can hold on to the metadata (as is already done) which includes the subject's signature.

The subject could hide revokes or updates. However, I think that if a Verifier does not accept a revocation being hidden, it should not be on the pseudonym anyway, because the authority still lies with the issuer. Can you even force a subject to sign a revocation? That is not control. So I think for revocation you either need a one-sided revoking mechanism or simply ask the subject for a live refresh (active model).

Inserting
Inserting could allow a subject to insert updates or revokes between issuing an attribute and verifying of that attribute. The subject could then later claim that at the time of verification, the attribute was already revoked. Can we not solve this by asking the subject to sign a receipt that states he presented the latest material? Again, I think revokes in this case should be one-sided, which also eliminates this problem.

Am I missing something?

[qstokkink]

At all times the subject can remove his/her own data. Pseudonyms only exist to both protect the verifier and add value/trust to attributes. I implore you to look at these issues from the angle of a verifier under the scrutiny of legal investigation.

Moving into your comments:

A timestamp offers more information than simply ordering and is already included in the metadata right now.

Timestamps are not reliable, clock times shift and in the worst case differ completely. Only (causal) ordering of attributes through signatures/hashes is a reliable way to ensure event order in an audit log. Plus, they are incredibly leaky: an expiration date is much more privacy preserving. I plan on removing the timestamp altogether.

When do we care about attribute order?
[...]
If subject-repudation is a possible attack, this can be countered by the fact that verifiers or issuers can hold on to the metadata (as is already done) which includes the subject's signature.
[...]
The subject could then later claim that at the time of verification, the attribute was already revoked. Can we not solve this by asking the subject to sign a receipt that states he presented the latest material?

For two legal reasons:

1. A verifier can show the pseudonym did not contain further attributes an attribute was linked to. A verifier can prove that facial recognition was not a valid authentication option for the home address for example. This prevents a "why didn't you use X" discussion in a court.
2. An auditing party can prove that a verifier should have known that another attribute was present, but was not properly checked. For instance, the "over 18" attribute was there but not verified. This makes the verifier liable.

The only concern with a co-signed timestamp is it can relies on one party being honest. If this assumption cannot hold, maybe we should build a TimestampCommunity.

I fail to see what this community would do.

First of all, subjects should have the right to hide and delete/forget.

Subjects have the abililty to have their attribute values evaluated through ZKPs. To this end they will have to share two things: a commitment and (partial) metadata. [Side note on the myth of ZKPs: given the set of challenges and responses to a ZKP everyone can verify that the proof holds - we can only hide the authenticity of the responses for third parties.] You can hide the attribute value and part of the metadata, but you depend on the honesty of the verifier to keep the commitment and metadata hidden (though you should assume a malicious verifier that leaks both in your attacker model).

Furthermore, inability to hide data could enable other parties to coerce the subject into exposing the data.
[...]
However, I think that if a Verifier does not accept a revocation being hidden, it should not be on the pseudonym anyway, because the authority still lies with the issuer.

The subject always has the ability to hide data, however --depending on the use case-- hiding intermediate attributes may not be legal. Pseudonyms should be minimized before use (one long pseudonym allows metadata correlation).

Can you even force a subject to sign a revocation? That is not control.

No and yes. No: it's self-sovereign so you can decide what you do and do not add to a pseudonym. Yes: you can offer convenience to users if they include this revocation. For instance: either you include the revoke of the old data before you get the new attribute on the same pseudonym OR you go back to the other third parties on this pseudonym and I will give you a completely fresh attestation.

Again, I think revokes in this case should be one-sided, which also eliminates this problem.

I'd like that, but we need to consider two-sided revokes for any realistic use case.

[TimSpeelman]

Thanks! A lot of food for thought. I'll get back to you on the information hiding topic.

Look at the issues from the angle of a verifier under scrutiny of legal investigation.

That's a good one, will do.

Timestamps are not reliable, clock times shift and in the worst case differ completely.

For many cases it might not matter that issuing/expiration times are a few seconds off right?

[…] they are incredibly leaky. […] I plan on removing the timestamp altogether.

I see the following use cases for timestamps:

• A) Prove that an attribute is still valid at verification time, i.e. the expiration date is in the future and has not been revoked.
• B) Prove that an attribute was valid at some time t < verification time.

Both cases could benefit from range proofs: is the issuing date before time t and the expiration date after time t? In case of (A) we cannot ensure that a subject accepts a revoke before using the attribute (e.g. using an authorization when you've just been fired), hence the need for one-sided authority.

an expiration date is much more privacy preserving.

Attestation lifetime will likely be part of some non-secret policy (transparency). Expiration date minus lifetime is issuing date right?

I fail to see what this community would do.

Attesting to the correctness of a timestamp on a block. This would prevent an issuer and subject to collude into lying about the issuing timestamp.

hiding intermediate attributes may not be legal.

Do you have any sources or examples? This is really a valuable addition to my thesis.

An auditing party can prove that a verifier should have known that another attribute was present, but was not properly checked. For instance, the "over 18" attribute was there but not verified. This makes the verifier liable.

The Verifier should be liable for not verifying the "over 18" attribute, regardless of whether it was there or not. Not having an id-card does not make me eligible for buying alcohol. So I am wondering when proving attribute absence has any meaningful use case.

you depend on the honesty of the verifier to keep the commitment and metadata hidden

Yes, I discussed this in my chapter as well. We can never prevent a Verifier from claiming knowledge about a subject, but we may be able to prevent him proving it to anyone else, unless he needs to prove it to an auditor. Can we not just leave authenciation out? Why does the Verifier need to authenticate the responses? If the challenges are succesfully answered, that's enough right?

[qstokkink]

For many cases it might not matter that issuing/expiration times are a few seconds off right?

Probably not, but timestamps are still malleable. If properly gamed, this can become an attack vector on the integrity of the audit log for the few cases is does matter.

Both cases could benefit from range proofs: is the issuing date before time t and the expiration date after time t?

That's a fun and interesting one. We can make a (second) preceding attribute for each other attribute that has a ZKRP for the expiration date of the following attribute. But still, I see no reason why the timestamp should be plaintext in the metadata.

Attesting to the correctness of a timestamp on a block.

You would need some global clock authority. I prefer the ZKRP timestamp approach: no third parties.

Do you have any sources or examples? This is really a valuable addition to my thesis.

You can make conditional identities. To keep it short: basically role based activation constraints in Role-Based Access Control systems. Sometimes reality dicatates exceptions instead of permissions. For example in a system with 50 permissions it is easier to capture "All permissions - permission 43" than listing all other 49 permissions. Something like "[1] May not work with the elderly. [2] Has a chamber of commerce number.".

That said, you could technically turn any exception-based system into a permission-based system. It's just unpractical (especially when the permissions change for the default).

Not having an id-card does not make me eligible for buying alcohol. So I am wondering when proving attribute absence has any meaningful use case.

You have (1) not checking an attribute (negligence by verifier) and (2) not owning an attribute (attempted cheating by the subject). A subject may not be cheating, but a verifier may still be negligent. In case of (1) the verifier is at fault, but the subject may not be. In the case of (1) and (2) together, both the subject and verifier can be persecuted by the auditing authority.

Can we not just leave authenciation out? Why does the Verifier need to authenticate the responses? If the challenges are succesfully answered, that's enough right?

Read my previous post's side note. Everybody can make valid challenge and response pairs to a ZKP that is not bound to an identity, once they know the value committed to. Only if challenges and responses are both valid and authentic does it mean that a verifier can see that the correct party is answering the challenges at the time of proving and retroactively an auditor can audit correct verification. Note that establishing a covert channel with an identity is enough to provide this authenticity and as such individual responses are not digitally signed (which would potentially allow for a rainbow table type of attack if the data is not sufficiently unique). Basically, this is the way we disallow verifiers from proving this data to anyone else, as you mentioned.

[TimSpeelman]

Meeting minutes:

• @synctext will read chapter 5 draft as uploaded to this ticket
• I will include a comment on why SSI e-IDAS Bridge solution does not meet SSI constraints.
• I will explicitly explain protocol messages used in my design

[TimSpeelman]

The long awaited chapter 9, Implementation, is complete. It describes a prototype for a semantic layer on top of IPv8 (latest release, 2.1), and includes:

1. an android-based Wallet application,
2. a verification protocol,
3. an attestation protocol,
4. an authentication service and
5. an attestation service that enables subjects to collect attestations without leaving their wallet.

I intend to run the authentication and attestation service inside Docker containers, but I have run into IPv8 networking problems, so this does not yet work. The docker files and README are available here.

Note that chapter 9 does NOT include the ZekereZaken app developed for the KVK. This is described separately in chapter 10 as it intends to run on top of the protocols, and using the services of the Wallet. Chapter 10 is not yet done.

Thesis20200515a.pdf

Feedback is very welcome.

[qstokkink]

You seem to have substantial material for your thesis. Don't forget to contextualize it with existing research though. Even in the field of usability there is a lot of work (useful example for your usability claims: https://www.usenix.org/conference/soups2019/presentation/wu).

[synctext]

Solid progress! You have lots of thesis material. 1 week test with small amount of subjects would make it perfect. Please finish the thesis first.

[synctext]

Wanted to get the latest version now. Can you please push your thesis.pdf and .tex to an open repo regularly?

Chapter 5 analyzed the peer-to-peer identity layer upon which this thesis
builds. In chapter 6, we presented the design of a semantic layer as another
step towards a Self-Sovereign Identity infrastructure. This chapter presents
a proof of concept implementation of this design, called Open Wallet (OW).
The major paradigm shift that self-sovereign identity brings is the
central role of the subject, Alice. It is therefore only natural to start our
prototype from her perspective. Hence, we first present an Android-based
Wallet application in section 9.1, that shows how Alice collects identity
information from one party and shares it with another.

This can also be shortened to: "Open Wallet (OW) is our SSI Android implementation."

please merge chapter 7 and 8 in others. try to do single design chapter (5,6)

Please do a "minimal rewrite version week". So no new content, only allowed to repair storyline with 5 additional sentences max, and make it Thesis Committee Email Ready (TCER).

[TimSpeelman]

I made progress, but unfortunately the TCER version turned out to be too ambitious. The past few days did stirr things up and made me reconsider my path. Luckily, I regained confidence in the project yesterday.

Thesis20200604a_compressed.pdf

[synctext]

Thesis progress feedback:

• starting to come together, 21 July as a tentative defense date. Final thesis version deadline probably 14 July.
• in general your writing style is very elaborate, detailed, repeating and meticulous. It could fit into 50 pages, but now is 88. Dense wording is often perceived as being more "profound" and scientifically abstract. No need to change, but just be aware of this.
• Chapter 1: introduction should tell the story of consistent failure to create a PKI system with broad societal uptake and usage by legal entities. Tried since Phil PGP web-of-trust. intro is now an abstract
• Chapter 2: focus on a problem you will solve. SSI is a lot of lofty philosophical principles. Translation into technical requirement is still missing. SSI is still an academic ideas with few viable prototypes. The open problem within this vast unexplored area of science we focus on within this thesis is using SSI by natural persons for representation of an legal entity. something something...
• Chapter 3: rewrite first 5 sentences with more intro&content. Then: Thesis Committee Email Ready
• Chapter 4: Thesis Committee Email Ready. However, how this proposed model relates to the state-of-the-art is missing. It makes three general very nice points beyond the state-of-the-art, but not cites any concrete work at all in the entire chapter. What better beyond which papers?
• Chapter 5: Thesis Committee Email Ready. Very well written chapter actually.
• Chapter 6: Thesis Committee Email Ready. You are often very modest in your claims. "We review multi-party access control against our SSI theoretical model presented in chapter 4." ("TODO:" remarks left in chapter text). "6.7 Reviewing SSI satisfaction", more scientific: "6.7 evaluation of the self-sovereign requirements"
• Chapter 7: Thesis Committee Email Ready. The core of the thesis work turned out to be very nice. The 8 screenshots, 7 data type tables, 5 flow figures, and 5 detailed code listings need to be cut by 30%, this makes it a bachlor engineering thesis versus academic work.
• Chapter 8: Thesis Committee Email Ready. What is the scientific contribution and lessons learned from working on this specific use-case? Abstract away details.
• Chapter 9: is optional, would add great scientific value to the thesis. May take 1 week only. Nobody confronts SSI work with the real world. Or make it a non-sovereign central Hyperledger server (plus because smart contract conformations time of 10minutes make whole classes of approaches a dead-end road)

[synctext]

• Section 1.6 The ongoing 146 year search
• 1.1.3 Zero-Knowledge Proofs, 1.1.4 Distributed Ledgers, etc. : [prior work 12,13,14,15,etc]
• getting ready for thesis defence soon, polishing is nearing completion

[TimSpeelman]

Fully revised problem description (ch 2):
Thesis20200614_compressed.pdf

• States more clearly what the semantic layer is and why it is needed.
• Explains the focus on applications involving legal entity authorisations.

[TimSpeelman]

Improved and finished theoretical SSI model (now ch 3):
Thesis20200617_compressed.pdf

• Incorporates related work
• States explicitly how it improves the state of the art
• Made some changes to the model itself to make it more comprehensive
• Elaborated on the dimensions of the problem space as this helps consolidate our work with similar SSI efforts.

[TimSpeelman]

I present the first non-draft version of my thesis:
Thesis20200623c_compressed.pdf

[qstokkink]

The cryptographic layer was first studied in general which revealed a
privacy issue: attestation metadata was unfairly considered public and
it was argued that this should instead be considered as confidential in
the relation between subject and verifier.

This was also summarily changed and now selective disclosure of metadata has been merged into IPv8: https://github.com/Tribler/py-ipv8/pull/759

[TimSpeelman]

I have added the construction site case study. No other feedback was processed yet.
Thesis20200713_compressed.pdf

[TimSpeelman]

I have added an abstract and processed most of the feedback.
Thesis20200715d_compressed.pdf

[TimSpeelman]

The final version of my thesis has arrived.
Tim-Speelman-Thesis-2020-FINAL-compressed.pdf

[TimSpeelman]

First rough outline of presentation for quick discussion
Defense1.pdf

[qstokkink]

[presentation] You're a bit light in the math department. Could you add a bit more depth to appease the professor-level audience?

[synctext]

• "Evaluation: Nijmegen Construction Site", identity is an unsolved problem. Move from page 24, towards page 2!
• Scientific Challenge: universal model with validity across all identity problems for natural persons and legal identities
• skipped over foundations: your cellphone number, your DNS entry, your passport it not really yours. 1 slide
• "Figure 6.2. Integration between Wallets and Authentication Apps." central to your storyline: your solution
• This thesis scientific contribution: understand the various self-sovereign identity models made by philosophers in the past decades, create the first viable model, and experimentally validated the resulting technology
  
• implemented connection of natural persons ID, legal entity ID, and person-to-person delegation chain: power of representation
• not a single state-of-the-art citation :smile: Logo of the dozens companies in this field? Or more academics?
• a formal slide? please don't force it to look good&fancy.
• Too many details, no clarity. SSI strength: passport-grade ID everywhere, start a company from the couch, notary signature from the beach.

[TimSpeelman]

New version. Finished with content and ordering. Dropped Theoretical Framework. Still working on some of the images/animations and sharpening up some slides that have too much text. Conversion to PDF makes it look a bit weird in some places, but pptx file is too large.
Defense3.pdf

@qstokkink More depth needed still?

[qstokkink]

@TimSpeelman Looks good 👍. Good luck tomorrow!

[synctext]

:partying_face: :balloon: :partying_face: Final official thesis .PDF is here :partying_face: :balloon: :partying_face:
That closes this chapter/issue, a fresh issue will build upon this work soon.