Merge pull request #67 from privacybydesign/yivi-updates

Yivi updates
privacybydesign · Dec 2, 2024 · 0cc1831 · 0cc1831
2 parents 639d379 + 88eac61
commit 0cc1831
Show file tree

Hide file tree

Showing 32 changed files with 465 additions and 366 deletions.
diff --git a/README.md b/README.md
@@ -1,3 +1,25 @@
 # Yivi technical documentation
 
-This is the source of the Yivi technical documentation website. [Build and edit instructions](website).
+This is the source of the Yivi technical documentation website.
+
+## Local development
+To start a local docusaurus server simply run the following commands.
+```bash
+cd yivi-docs
+```
+```bash
+npm i
+```
+```bash
+npm run start
+```
+
+To start a local docker container with the right settings simply run:
+
+```bash
+docker compose up
+```
+
+## Release
+To release a new version run the Github action located [here](https://github.com/privacybydesign/irma-documentation/actions/workflows/delivery.yml). This will push a new Docker build to Github packages:
+https://github.com/privacybydesign/irma-documentation/pkgs/container/irma-documentation
diff --git a/yivi-docs/blog/2024-11-29-nov-update/index.md b/yivi-docs/blog/2024-11-29-nov-update/index.md
@@ -0,0 +1,54 @@
+---
+slug: vision, roadmap, progress
+title: November update
+authors: [dibranmulder]
+tags: [yivi, roadmap]
+---
+
+He all, I thought it would be nice to update you on our progress. Our dedicated team started the development and operations of Yivi effectively on the 1st of November. The existing code base (70+ repositories) is quite large, and the learning curve is rather steep, however I think we are making great progress. We touched a lot of components already and are making great progress.
+
+As told during the Yivi meetup we have a roadmap ahead of us containing 3 epics, namely: Cloud Migration, Development and eIDAS2.0. I will update our progress on each of them.
+
+<!-- truncate -->
+
+## Cloud Migration
+As said our priority is taking care of all infrastructure and tooling required to serve the Yivi ecosystem. We are aiming for a seamless migration of multiple core components such as several issuers (mobile, email,saml, idin), yiviconnect.nl, the key share server and my yivi. Most of these components are hosted by SIDN on VM’s managed by them. Our plan is to host it all on Scaleway, a European cloud provider, offering locations in Amsterdam, Paris and Warsaw. Our tech of choice is Kubernetes. Choosing Kubernetes benefits the broader ecosystem, because containerized hosting will be our default going forward. You might have seen that several demos and issuers are now containerized.
+
+To highlight our progress, here is a list of services running on our staging environment—a newly established platform where we test our services.
+- https://schemes.staging.yivi.app
+- https://is.staging.yivi.app
+- https://my.staging.yivi.app/
+- https://keyshare.staging.yivi.app
+- https://emailissuer.staging.yivi.app/
+- https://sms-issuer.staging.yivi.app/en/
+- https://docs.staging.yivi.app
+- https://connect.staging.yivi.app/saml-bridge
+- https://demos.staging.yivi.app
+- https://angrygames.staging.yivi.app
+- https://atumd.staging.yivi.app
+- https://docs.staging.yivi.app
+
+For security reasons, we do not open-source the code used to create the infrastructure.
+
+## Development
+The next priority is to take care of the user experience of Yivi. We think having the best UX is one of the ways in which Yivi distinguishes itself from other ID-wallets. Our mobile engineer Wouter took some time to eliminate technical debt, including upgrading to the latest Xcode and Flutter versions and upgrading several dependencies. Also, the integration tests broke with the upgrade, so we had to fix them.
+
+The first UI improvements are already merged, we will stack them up and aim to release them before Christmas. We already took ownership of the App and Play Store accounts, but the release process and any particularities have not been discussed yet. We will update you when there’s a new App to test. Make sure to open an issue on the irmamobile repository when you experience bugs in the mobile app.
+
+Next to the mobile development we started fixing some bugs in the irmago library. Getting familiar with this rather complex piece of code is quite challenging but progress is made. Luckily, we have the extensive knowledge of Ivar and Sietse available so that helps a lot!
+
+## eIDAS 2.0
+We acknowledge that Yivi should be part of the European Digital Identity Framework. Becoming an EUDI-wallet is one of our long-term goals, however, how to become one is very much still a moving target. Fortunately, we have several connections and advisors keeping us up to date in that field.
+
+We have begun examining the technical implications of adopting cryptography and protocols other than Idemix and IRMA. While it's too early to share specific details, rest assured that it's on our radar.
+
+## Community
+We started reaching out to the existing contacts of Yivi, you might have noticed it. We had dozens of talks and introductions, and we valued them very much. It’s very nice to see the enthusiasm about Yivi in the ecosystem. Also, we have several commercial parties showing interest in Yivi, we can’t share anything yet, but we will when the time is ready.
+
+Several parties contacted us regarding the Development, Consultancy and Support for an Age Verification Solution – European Tender. We evaluated the tender but sadly participating in the tender on such a short term was rather impossible. In the future we will need a consortium of organizations to participate in such a tender. We already had quite a lot of expertise available via several organizations, but we clearly missed BID management capacity and law and regulations expertise. If your organization has these expertise’s we would like to connect so that we can explore a collaboration in the future.
+
+Thank you all for being a part of the Yivi community. Feel free to contact us with any questions or remarks. This concludes the November update, I will try to update you every month, and for now happy holidays!
+
+Kind regards, also on behalf of the yivi team
+
+Dibran, Sara, Wouter, Martijn, Jasper, Leon, Ivar, Sietse. 
diff --git a/yivi-docs/docs/api-irma-server.md b/yivi-docs/docs/api-irma-server.md
@@ -130,7 +130,7 @@ Get the [session result](https://godoc.org/github.com/privacybydesign/irmago/ser
 The response may contain the following fields:
 * `token`: Requestor token
 * `status`: Current [session status](#get-session-requestortoken-status)
-* `type`: [Session type](what-is-irma.md#session-types): one of `"disclosing"`, `"signing"`, or `"issuing"`
+* `type`: [Session type](what-is-yivi.md#session-types): one of `"disclosing"`, `"signing"`, or `"issuing"`
 * `proofStatus`: One of the package level [irma.ProofStatus](https://godoc.org/github.com/privacybydesign/irmago#pkg-constants) constants, indicating the cryptographic validity of the attributes and proofs of knowledge:
    * `"VALID"`: proofs are valid
    * `"INVALID"`: proofs are invalid

diff --git a/yivi-docs/docs/chained-sessions.md b/yivi-docs/docs/chained-sessions.md
@@ -1,13 +1,13 @@
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
 ---
 title: Chained sessions
 ---
 
-Since version 6.1.0 of the [Yivi app](yivi-app.md) and 0.8.0 of the [IRMA server](irma-server.md), multiple [IRMA sessions](what-is-irma.md#session-types) may be chained together by the requestor into a single flow. After the Yivi app user has started the first session (for example, by scanning a QR code), she then passes through multiple session screens, as shown here. In this example, the requestor uses a disclosure session to retrieve the user's name and then immediately afterwards issues that into a new credential.
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+Since version 6.1.0 of the [Yivi app](yivi-app.md) and 0.8.0 of the [IRMA server](irma-server.md), multiple [IRMA sessions](what-is-yivi.md#session-types) may be chained together by the requestor into a single flow. After the Yivi app user has started the first session (for example, by scanning a QR code), she then passes through multiple session screens, as shown here. In this example, the requestor uses a disclosure session to retrieve the user's name and then immediately afterwards issues that into a new credential.
 
-<div className="center" style={{ marginBottom: "1em" }}>
+<div className="center" style={{ textAlign: "center", marginBottom: "1em" }}>
   <img
     src="/img/chain-disclosure.png"
     style={{ width: "35%" }}

diff --git a/yivi-docs/docs/condiscon.md b/yivi-docs/docs/condiscon.md
@@ -2,48 +2,51 @@
 title: "\"Condiscon\" session requests"
 ---
 
-This page introduces *condiscon*: a new IRMA feature allowing IRMA [verifiers and signature requestors](overview.md#participants) to express the attributes they need with much more flexibility, using a new format for the [session request](session-requests.md) with which sessions are started at the IRMA server. This affects:
-- [Requestors](overview.md#participants) using an [`irma server`](irma-server.md) or the [`irmaserver` library](irma-server-lib.md), as they need to convert their session request to the new condiscon format.
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+This page introduces *condiscon*: a new IRMA feature allowing IRMA [verifiers and signature requestors](technical-overview.md#participants) to express the attributes they need with much more flexibility, using a new format for the [session request](session-requests.md) with which sessions are started at the IRMA server. This affects:
+- [Requestors](technical-overview.md#participants) using an [`irma server`](irma-server.md) or the [`irmaserver` library](irma-server-lib.md), as they need to convert their session request to the new condiscon format.
 - The [`irma` command](irma-cli.md) including [`irma server`](irma-server.md) (`0.3.0` and up supports condiscon).
 - The [Yivi app](yivi-app.md) (a condiscon-compatible version will soon be released in the beta channel).
 
 Below we describe the new session format, explaining the new features that it brings, and highlighting differences with the old session format. The documentation of the updated session request format can be on the [session requests](session-requests.md) page.
 
 ## New session request format
 
-An [IRMA disclosure session](what-is-irma.md#session-types) is started by a verifier submitting a [*session request*](session-requests.md) to an IRMA server, listing the attributes that it requires, offering the user a choice between multiple options for some or all of these attributes. That is, IRMA supports requesting the user for a [*conjunction*](https://en.wikipedia.org/wiki/Logical_conjunction) of [*disjunctions*](https://en.wikipedia.org/wiki/Logical_disjunction) of attributes. In the (new) Yivi app, this looks as follows.
+An [IRMA disclosure session](what-is-yivi.md#session-types) is started by a verifier submitting a [*session request*](session-requests.md) to an IRMA server, listing the attributes that it requires, offering the user a choice between multiple options for some or all of these attributes. That is, IRMA supports requesting the user for a [*conjunction*](https://en.wikipedia.org/wiki/Logical_conjunction) of [*disjunctions*](https://en.wikipedia.org/wiki/Logical_disjunction) of attributes. In the (new) Yivi app, this looks as follows.
 
-<!--DOCUSAURUS_CODE_TABS-->
-<!--Yivi app-->
-<img src="/img/pre-condiscon.png" class="ss" alt="pre-condiscon" />
-<!--Session request (old format, JSON)-->
-```json
-{
-  "type": "disclosing",
-  "content": [{
-    "label": "Address",
-    "attributes": [
-      "irma-demo.nijmegen.address.street",
-      "irma-demo.idin.idin.address"
-    ]
-  },
+<Tabs>
+  <TabItem value="yivi" label="Yivi App">
+  <img src="/img/pre-condiscon.png" class="ss" alt="pre-condiscon" />
+  </TabItem>
+  <TabItem value="json" label="Session request (old format, JSON)">
+  ```json
   {
-    "label": "City",
-    "attributes": [
-      "irma-demo.nijmegen.address.city",
-      "irma-demo.idin.idin.city"
-    ]
-  }]
-}
-```
-<!--END_DOCUSAURUS_CODE_TABS-->
+    "type": "disclosing",
+    "content": [{
+      "label": "Address",
+      "attributes": [
+        "irma-demo.nijmegen.address.street",
+        "irma-demo.idin.idin.address"
+      ]
+    },
+    {
+      "label": "City",
+      "attributes": [
+        "irma-demo.nijmegen.address.city",
+        "irma-demo.idin.idin.city"
+      ]
+    }]
+  }
+  ```
+  </TabItem>
+</Tabs>
 
 "Condiscon", standing for conjunction of disjunctions *of conjunctions* of attributes adds one extra level to this in the session request format: now verifiers can request multiple attribute *sets* from the user, offering the user multiple choices for some or all of the sets:
 
-<!--DOCUSAURUS_CODE_TABS-->
-<!--Yivi app-->
-<img src="/img/condiscon.png" class="ss" alt="condiscon" />
-<!--Session request (condiscon, JSON)-->
+<Tabs>
+  <TabItem value="json" label="Session request (condiscon, JSON)" default>
 ```json
 {
   "@context": "https://irma.app/ld/request/disclosure/v2",
@@ -65,7 +68,8 @@ An [IRMA disclosure session](what-is-irma.md#session-types) is started by a veri
   ]
 }
 ```
-<!--Session request (condiscon, Go)-->
+  </TabItem>
+  <TabItem value="go" label="Session request (condiscon, Go)">
 ```golang
 request := irma.NewDisclosureRequest()
 request.Disclose = irma.AttributeConDisCon{
@@ -85,18 +89,23 @@ request.Disclose = irma.AttributeConDisCon{
 	},
 }
 ```
-<!--END_DOCUSAURUS_CODE_TABS-->
+  </TabItem>
+  <TabItem value="app" label="Yivi App">
+    <img src="/img/condiscon.png" class="ss" alt="condiscon" />
+  </TabItem>
+</Tabs>
 
 In this disclosure request, the user is asked for her (demo) BSN, and for her `street`, `houseNumber` and `city` attribute from the `irma-demo.nijmegen.address` credential type. For the latter three the user has one other option which is not currently shown in the screenshot (but it is present in the session request).
 
 In the session request above (see the second tab) we call the three JSON lists that contain strings *inner conjunctions* (distinguishing them from the *outer conjunctions*, that contain not attribute but disjunctions). Asking for multiple attributes within such an inner conjunctions of a session request is subject to the following rules:
 
-- When attributes coming from multiple credential types occur in an inner conjunction, at most one of them may be a non-[singleton](overview.md#singletons).
+- When attributes coming from multiple credential types occur in an inner conjunction, at most one of them may be a non-[singleton](technical-overview.md#singletons).
 - If some of the attributes occuring in the inner conjunction come from the same credential type, then the attributes that the user sends must come from the same credential instance: it is not allowed to mix attributes coming from distinct instances of that credential type. (The Yivi app automatically only offers candidate sets as choices to the user that satisfy this property.)
 
 For example, consider the following condiscon session request:
-<!--DOCUSAURUS_CODE_TABS-->
-<!--Session request (JSON)-->
+
+<Tabs>
+  <TabItem value="json" label="Session request (JSON)" default>
 ```json
 {
   "@context": "https://irma.app/ld/request/disclosure/v2",
@@ -110,7 +119,8 @@ For example, consider the following condiscon session request:
   ]
 }
 ```
-<!--Session request (Go)-->
+  </TabItem>
+  <TabItem value="go" label="Session request (Go)">
 ```golang
 request := irma.NewDisclosureRequest()
 request.Disclose = irma.AttributeConDisCon{
@@ -122,7 +132,8 @@ request.Disclose = irma.AttributeConDisCon{
 	},
 }
 ```
-<!--END_DOCUSAURUS_CODE_TABS-->
+  </TabItem>
+</Tabs>
 
 Supposing that the user has two instances of `pbdf.pbdf.diploma` whose `degree` and `institute` attributes are `(degree 1, institute 1)` and `(degree 2, institute 2)`, this means that the user can choose only either `(degree 1, institute 1)` or `(degree 2, institute 2)`, and not `(degree 1, institute 2)` or `(degree 2, institute 1)`. (If desired it would be possible to give the user those options by asking for the two attributes in two *outer* conjunctions instead of within an *inner* conjunction.)
 
@@ -133,9 +144,10 @@ When combining multiple credential types within a disjunction these restrictions
 As before, the verifier can indicate in the session request that it requires specific values for one or more of the requested attributes. In addition, the new condiscon versions of the Yivi app and server include the following new features.
 
 - **Optional disjunctions**: Now that inner conjunctions can be of any length (instead of just 1 as it previously was), verifiers can mark a disjunction as *optional* by specifying an empty inner conjunction `[]` as one of its candidates, indicating that by disclosing nothing this disjunction is satisfied:
-  <!--DOCUSAURUS_CODE_TABS-->
-  <!--Session request (JSON)-->
-  ```json
+
+<Tabs>
+  <TabItem value="json" label="Session request (JSON)" default>
+```json
   {
     "@context": "https://irma.app/ld/request/disclosure/v2",
     "disclose": [
@@ -146,18 +158,21 @@ As before, the verifier can indicate in the session request that it requires spe
     ]
   }
   ```
-  <!--Session request (Go)-->
-  ```golang
-  request := irma.NewDisclosureRequest()
-  request.Disclose = irma.AttributeConDisCon{
-    irma.AttributeDisCon{
-      irma.AttributeCon{},
-      irma.AttributeCon{irma.NewAttributeRequest("pbdf.pbdf.diploma.degree")},
-    },
-  }
-  ```
-<!--END_DOCUSAURUS_CODE_TABS-->
-  This can be useful when certain attributes would be useful but not required, so that their absence does not abort the IRMA session.
+  </TabItem>
+  <TabItem value="go" label="Session request (Go)">
+```golang
+request := irma.NewDisclosureRequest()
+request.Disclose = irma.AttributeConDisCon{
+  irma.AttributeDisCon{
+    irma.AttributeCon{},
+    irma.AttributeCon{irma.NewAttributeRequest("pbdf.pbdf.diploma.degree")},
+  },
+}
+```
+  </TabItem>
+</Tabs>
+
+This can be useful when certain attributes would be useful but not required, so that their absence does not abort the IRMA session.
 
 - **Null attributes**: Attributes that were skipped by the issuer during issuance, assigning them the `null` value, can now be requested and disclosed normally. The verifier receives the JSON value `null` instead of a (string) attribute value. (Previously such null attributes would have caused the Yivi app to abort the session, considering them "absent" and thus the request unsatisfiable. This made it impractical to request an optional attribute along with other attributes.)
 - **Disjunction labels** are now optional. They often only repeated the requested credential or attribute names (mainly because they were required); this is now discouraged. Instead, labels should only be used to explain something to the user that would otherwise not be obvious (e.g, to request the user to send a work email address instead of a personal one).
@@ -181,4 +196,3 @@ For attribute-based signatures, the condiscon version of the IRMA software bring
 This is fixed in the condiscon versions of IRMA by committing to the attribute structure (i.e. disclosed vs. non-disclosed attributes) during generation and verification of the attribute-based signature in a new way, that is automatically compatible with future attribute additions to the credential type.
 
 Previously generated IRMA attribute-based signatures remain valid (as long as no new attributes are added to their credential types). However, the new Yivi app always uses the fixed signature generation algorithm which the pre-condiscon version of the IRMA server does not support. For that reasons, if you use attribute-based signatures your IRMA server(s) will need to be updated before the new Yivi app is released (probably some weeks from now).
-