exercise-2-solution.ipynb

{
 "cells": [
  {
   "cell_type": "markdown",
   "id": "2ff09d13-7d4e-412a-9902-9381b6c079db",
   "metadata": {},
   "source": [
    "# Solutions for Exercise 2 - Unlinkable proofs using BBS+\n",
    "\n",
    "This only holds the answer to the questions, and the solution to the last coding exercise."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "68984925-7842-47b0-aab2-990d409b1f21",
   "metadata": {},
   "source": [
    "---\n",
    "## 1 - Questions for Setting up a corresponding JSON Schema\n",
    "\n",
    "1. What is the format for `timeOfBirth`? And what is the limitations using that format? What else could the format be?\n",
    "\n",
    "> The javascript class `Date` returns the milliseconds since the Unix Epoch\n",
    "> (midnight of 1970-1-1) with the method `getTime()`.\n",
    "\n",
    "> This means that times before the Unix Epoch will be negative, which can pose problems\n",
    "> later on with Zero Knowledge Proofs.\n",
    "> Depending on the precision of the number, this might also overflow, as the number of\n",
    "> milliseconds since the Unix Epoch is already well over 32 bits.\n",
    "\n",
    "> One could imagine taking seconds since the beginning of the era (0000-1-1), or since\n",
    "> the beginning of the universe.\n",
    "> For the latter, we would be in the year 13_700_002_024.\n",
    "\n",
    "2. What other fields could be in the credential?\n",
    "\n",
    "- Place of birth\n",
    "- Place of origin\n",
    "- AVS-number\n",
    "\n",
    "Fields like `address`, `employer` will most probably be in separate credentials given out\n",
    "by the commune or the employer themselves."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "b28ded2e-8a26-43e3-b80b-1b21b2b3b56d",
   "metadata": {},
   "source": [
    "---\n",
    "## 2 - Questions for Issuer - Setting up and creating a BBS+ signature\n",
    "\n",
    "1. What information do you find in the credential which is sent to the holder? What keywords / algorithms do you recognize?\n",
    "\n",
    "> Looking at the credential sent to the holder, one can think of the\n",
    "> [W3C VC Data Model v1.1](https://www.w3.org/TR/vc-data-model/)\n",
    ">\n",
    "> ```\n",
    "> // the credentialSchema is encoded using utf-8, so it can accomodate\n",
    "> // all types of values.\n",
    "> id: 'data:application/json;charset=utf-8,',\n",
    "> // This is defined in the above document from W3C\n",
    "> type: 'JsonSchemaValidator2018',\n",
    "> // The proof (signature in this case) uses Bls12-381 and a BBS signature.\n",
    "> type: 'Bls12381BBSSignatureDock2023',\n",
    "> ```\n",
    ">\n",
    "> More information on BLS-12-381 can be found here, for example:\n",
    "> [Bls12-381](https://hackmd.io/@benjaminion/bls12-381#Security-level)\n",
    "\n",
    "2. How many bytes is the proof sent to the holder?\n",
    "\n",
    "> As the proof seems to be encoded in base64, which only represents 6 bits per character,\n",
    "> the number of characters needs to be multiplied by 6 and divided by 8.\n",
    "> Or multiplied by 3/4 = 0.75:\n",
    "> \n",
    "> 110 * 0.75 = 82.5\n",
    "> \n",
    "> So probably the docknetwork/crypto library concatenates multiple base64 strings."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "af7906c2-e3a8-4218-8da2-392811219a1b",
   "metadata": {},
   "source": [
    "---\n",
    "## 3 - Questions for Holder - Creating a proof\n",
    "\n",
    "1. Explore the bbsProofVerifier to see what information is sent to the verifier\n",
    "\n",
    "> If you print the object with\n",
    "> console.dir(bbsProofForVerifier, {depth: null})\n",
    "> javascript will not stop at a given depth, but print everything.\n",
    "> One of the interesting parts is this:\n",
    ">\n",
    ">     revealedAttributes: {\n",
    ">       credentialSubject: { name: 'Jack Sparrow', profession: 'IT Manager' }\n",
    ">     },\n",
    ">     sigType: 'Bls12381BBSSignatureDock2023'\n",
    ">\n",
    "> Which shows the revealed attributes sent to the verifier, as well as the signature\n",
    "> type which we encountered before.\n",
    "\n",
    "2. Is there information which could be used to de-anonymize the holder?\n",
    "\n",
    "> As far as we can interpret the structure by visual inspection, there doesn't\n",
    "> seem to be a specific value which allows the verifier to identify a specific\n",
    "> holder.\n",
    "> However, the revealed attributes can of course be used to de-identify a holder.\n",
    "\n",
    "3. How long is the proof now? Why is it bigger than the proof sent by the issuer?\n",
    "\n",
    "> The proof is now longer, 582 characters, which corresponds to 436.5 bytes.\n",
    "> This is due to the fact that the BBS proof sent by the holder needs to include\n",
    "> the blinding factors.\n",
    "> During our hands-on workshop we saw that the size of the proof is reduced if\n",
    "> more fields are revealed.\n",
    "> An intuitive explanation is that BBS only blinds the fields which are NOT revealed.\n",
    "> So the more fields are hidden, the longer the proof.\n",
    "> And the more fields are revealed, the shorter the proof."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "9477b67f-2427-47f2-92cb-096ba1886af5",
   "metadata": {},
   "source": [
    "---\n",
    "## 4 - Questions for Verifier - Verifying the proof is valid\n",
    "\n",
    "1. Can you create a proof which cannot be validated? What did you change?\n",
    "\n",
    "> One can think of creating another keypair for the issuer, and then using\n",
    "> this new keypair to verify the BBS proof generated with the old keypair.\n",
    "\n",
    "2. Reveal another element of the credential - what did you need to change?\n",
    "\n",
    "> The arguments to the method `presentationBuilder.markAttributesRevealed`\n",
    "> allow the holder easily to choose which fields to reveal.\n",
    "> The library will include the name of the fields directly in the object\n",
    "> sent to the verifier.\n",
    "\n",
    "3. How does the verifier know the credentials to reveal?\n",
    "\n",
    "> This can be found in the structure created by the crypto library with the\n",
    "> `presentationBuilder.finalize()` call."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "6fb5113c-f18f-4416-9038-020438076e17",
   "metadata": {},
   "source": [
    "## 5 - Discussion - Unlinkability achieved?\n",
    "\n",
    "1. Is there a signature or a cryptopgraphic data that is shared and could used to identify the credential holder?\n",
    "\n",
    "> Visually inspecting the structure sent from the holder to the verifier indicates that\n",
    "> there is no directly linkable value sent along.\n",
    "> As written in the exercise, this is of course no mathematically sound proof,\n",
    "> but from an intuition point of view it is nice to see the values changing for\n",
    "> every proof.\n",
    "\n",
    "2. Is there a part of data hashed or not that was included in the presented data that could be used to identify the credential holder?\n",
    "\n",
    "> As in exercise 1, if the data revealed to the verifier allow to single out\n",
    "> a specific holder, then they will be identified."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "900c23d6-c5ce-4042-a9cc-a121792f67b3",
   "metadata": {},
   "source": [
    "---\n",
    "\n",
    "## 6 - Coding exercise - Simulate an issuer-holder-verifier setup\n",
    "\n",
    "> Here is a list of objects to be transmitted for this exercise:\n",
    ">\n",
    "> - Issuer\n",
    ">   - to Verifier: the public key of the newly created keypair\n",
    ">   - to Holder: the result of the call to `BBSCredentialBuilder.sign().toJSON()`\n",
    ">     over a secure connection\n",
    "> - Holder\n",
    ">   - from Issuer: can recreate the credential using `BBSCredential.fromJSON()`\n",
    ">   - to Verifier: the result of the call to `PresentationBuilder.finalize().toJSON()`\n",
    "> - Verifier\n",
    ">   - from Holder: can recreate the proof using `Presentation.fromJSON()`\n",
    ">\n",
    "> It is interesting also for the issuer to create more than one credential,\n",
    "> so that the verifier can try to distinguish between the different credentials.\n",
    "\n",
    "### Questions\n",
    "\n",
    "1. What are the conditions that revealing a field doesn't lead to linkability?\n",
    "\n",
    "> If many holders share the same value of the field, the verifier will not be able\n",
    "> to link the proofs to a specific holder.\n",
    "> One can think of it like \"k-anonymity\", where \"k\" is the number of holders with the\n",
    "> identical value for the field.\n",
    "> Once the holder reveals more than one field, the \"k\" drops very rapidly to 1,\n",
    "> which means that the holder can be linked.\n",
    "\n",
    "2. How can the verifier be sure that the proof is not stale, meaning that it is not a replayed proof?\n",
    "\n",
    "> For this to work, one can do either of:\n",
    ">\n",
    "> 1. Define the protocol to include a timestamp of the proof\n",
    "> 2. Have the verifier send a random challenge to the holder, and then\n",
    ">    verify whether the challenge has been incorporated in the proof\n",
    ">\n",
    "> For both possibilities, the\n",
    "> [IETF-draft on BBS+](https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html#name-header-and-presentation-hea)\n",
    "> proposes for the holder to use the attribute `presentation_header` to\n",
    "> attach a proof of freshness to the proof sent to the verifier.\n",
    "> \n",
    "\n",
    "3. Can you easily implement this? Unfortunately the docknetwork/crypto-library doesn't have a good API documentation.\n",
    "   Look at the [PresentationBuilder](https://github.com/docknetwork/crypto-wasm-ts/blob/c32072b85150b6c1febadb29d2b8b7f4dbe7e40b/src/anonymous-credentials/presentation-builder.ts#L120). Which field looks like the best to use for the purpose of avoiding replays?\n",
    "\n",
    "> Unfortunately the library doesn't follow the namings of the IETF draft standard.\n",
    "> But looking at the fields, two stand out:\n",
    ">\n",
    "> ```\n",
    "> // This can specify the reason why the proof was created, or date of the proof, or self-attested attributes (as JSON string), etc\n",
    ">  _context?: string;\n",
    ">  // To prevent replay attack\n",
    ">  _nonce?: Uint8Array;\n",
    "> ```\n",
    ">\n",
    "> So the `context` must correspond to the `header` in the IETF-draft, and as such\n",
    "> should be set by the issuer.\n",
    "> The `nonce` must then be the `presentation_header`, which can be used for a challenge\n",
    "> or a timestamp.\n"
   ]
  }
 ],
 "metadata": {
  "kernelspec": {
   "display_name": "TypeScript",
   "language": "typescript",
   "name": "tslab"
  },
  "language_info": {
   "codemirror_mode": {
    "mode": "typescript",
    "name": "javascript",
    "typescript": true
   },
   "file_extension": ".ts",
   "mimetype": "text/typescript",
   "name": "typescript",
   "version": "3.7.2"
  }
 },
 "nbformat": 4,
 "nbformat_minor": 5
}