diff --git a/Dockerfile b/Dockerfile
index 16f0a9c..7a10626 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -2,10 +2,10 @@ FROM node:21 as build
WORKDIR /app/website
-COPY ./docs /app/docs
-COPY ./website /app/website
-RUN yarn install --immutable --immutable-cache --check-cache
-RUN yarn build
+# COPY ./docs /app/docs
+COPY ./yivi-docs /app/website
+RUN npm install
+RUN npm run build
FROM joseluisq/static-web-server:latest
-COPY --from=build /app/website/build/irma-documentation /public
+COPY --from=build /app/website/build /public
diff --git a/README.md b/README.md
index 649225b..fea0aa6 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,3 @@
-# IRMA technical documentation
+# Yivi technical documentation
-This is the source of the IRMA technical documentation website. [Build and edit instructions](website).
\ No newline at end of file
+This is the source of the Yivi technical documentation website. [Build and edit instructions](website).
\ No newline at end of file
diff --git a/docs/what-is-irma.md b/docs/what-is-irma.md
deleted file mode 100644
index aee372d..0000000
--- a/docs/what-is-irma.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: What is IRMA?
----
-
-IRMA is a set of free and open source software projects implementing the Idemix attribute-based credential scheme, allowing users to safely and securely authenticate themselves as privacy-preserving as the situation permits. Users receive digitally signed attributes from trusted issuer, storing them in their Yivi app, after which the user can selectively disclose attributes to others. Schematically:
-
-
-
-
-
-
-Using the issuer's digital signature over the attributes the verifier can verify that the attributes were given to the user in the past, and that they have not been modified since.
-
-## IRMA session flow
-
-A typical IRMA session is depicted schematically below.
-
-![IRMA session flow](assets/irmaflow.png)
-
-Software components:
-* *Requestor backend and frontend*: Generally the requestor runs a website with a (JavaScript) frontend in the user's browser, and a backend server. During an IRMA session the frontend displays the IRMA QR that the [Yivi app](yivi-app.md) scans. All frontend tasks depicted in the diagram are supported by [`yivi-frontend`](yivi-frontend.md).
-* [*IRMA server*](#irma-servers): Handles [IRMA protocol](irma-protocol.md) with the Yivi app for the requestor.
-* [*Yivi mobile app*](yivi-app.md): [Android](https://play.google.com/store/apps/details?id=org.irmacard.cardemu), [iOS](https://itunes.apple.com/nl/app/irma-authentication/id1294092994).
-
-Explanation of the steps:
-
-1. Usually the session starts by the user performing some action on the website (e.g. clicking on "Log in with IRMA").
-1. The requestor sends its [session request](session-requests.md) (containing the attributes to be disclosed or issued, or message to be signed) to the [IRMA server](#irma-servers). Depending on its configuration, the IRMA server accepts the session request only if the session request is authentic (e.g. a validly signed [session request JWT](session-requests.md#jwts-signed-session-requests)) from an authorized requestor.
-1. The IRMA server accepts the request and assigns a session token (a random string) to it. It returns the contents of the QR code that the frontend must display: the URL to itself and the session token.
-1. The frontend ([`yivi-frontend`](yivi-frontend.md)) receives and displays the QR code, which is scanned by the Yivi app.
-1. The Yivi app requests the session request from step 1, receiving the attributes to be disclosed or issued, or message to be signed.
-1. The IRMA server returns the session request.
-1. The Yivi app displays the attributes to be disclosed or issued, or message to be signed, and asks the user if she wants to proceed.
-1. The user accepts.
-1. The IRMA server performs the IRMA protocol with the Yivi app, issuing new attributes to the user, or receiving and verifying attributes from the user's Yivi app, or receiving and verifying an attribute-based signature made by the user's app.
-1. The session status (`DONE`, `CANCELLED`, `TIMEOUT`), along with disclosed and verified attributes or signature depending on the session type, are returned to the requestor.
-
-Additional notes:
-
-* Which of these tasks are performed by the requestor's backend and which by its frontend differs case by case:
- - Often the session request is sent to the IRMA server by the requestor's backend, after which the IRMA server's reply in step 2 is forwarded to the frontend which renders it as a QR code. Step 1 can however also be done by `yivi-frontend`, in which case `yivi-frontend` automatically picks up the IRMA server's reply in step 2 and renders the QR code.
- - Similarly, `yivi-frontend` can be instructed to fetch the session result in step 10, but this can also be done in the backend. In the latter, `yivi-frontend` can fetch a custom result at your backend, if desired.
-* The IRMA server could be deployed on the same machine as the requestor's backend, but it need not be; possibly it is not even controlled by the requestor. Generally, steps 2/3 and 10 are done with REST HTTP calls to the IRMA server, but in case the [`irmaserver`](irma-server-lib.md) library is used, these steps are function calls. Alternatively, you could use one of the packages in [`irma-backend-packages`](irma-backend.md) to do these steps with function calls in other programming languages.
-
-## Session types
-
-In an IRMA session, the [Yivi mobile app](yivi-app.md) performs one of the following three *session types* with an [*IRMA server*](#irma-servers):
-
-* *Disclosure sessions*: Upon receiving a list of requested attributes from the IRMA server, the app discloses the required attributes to the IRMA server if the app user agrees, after which they are verified by the IRMA server.
-* *Attribute-based signature sessions*: Similar to disclosure sessions, but the attributes are attached to a message digitally signed into an [*attribute-based signature*](overview.md#attribute-based-signatures). The attribute-based signature can be verified at any later time, ensuring that the signed message is intact, and that the IRMA attributes attached to it were valid at the time of creation of the attribute-based signature.
-* *Issuance sessions*: the Yivi app receives a new set of IRMA attributes including valid issuer signatures from the IRMA server, to use in later disclosure or attribute-based signature sessions. (Possibly the user is asked to disclose some attributes as well, within the same IRMA session, before receiving the new attributes. This is called a *combined issuance-disclosure session*.)
-
-This process is depicted schematically and explained in more detail in the [IRMA session flow](what-is-irma.md#irma-session-flow) chapter. For the user, after scanning the QR in his/her Yivi app a disclosure session generally looks like the following. (Attribute-based signature sessions and issuance sessions are identical in terms of their flow (scan qr, provide permission, success screen); only the graphical interface is different.)
-
-
-
-
-
-
-## IRMA servers
-
-Various existing software components documented on this website can perform the role of the IRMA server.
-Apart from exposing an API that is used by the [Yivi app](yivi-app.md) during IRMA sessions, each of these components also offer an API with which IRMA sessions can be started and monitored, for use by the [*requestor*](overview.md#participants): the party wishing to issue attributes to or verify attributes from an Yivi app. The IRMA server handles the IRMA session with the Yivi app for the requestor.
-
-Currently the following IRMA servers exist:
-
-* The `irma server` command of the [`irma`](irma-cli.md) binary: a standalone daemon exposing its requestor API as HTTP endpoints. [Documentation](irma-server.md); [API reference](api-irma-server.md).
-* The `irmaserver` Go library, exposing a HTTP server that handles IRMA sessions with the Yivi app, and Go functions for starting and managing IRMA sessions. [Documentation](irma-server-lib.mdrary); [API reference](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver).
-* The now deprecated [`irma_api_server`](https://github.com/privacybydesign/irma_api_server).
-
-## About this documentation
-
-IRMA uses JSON to pass messages within IRMA sessions. The majority of IRMA is [written in Go](https://github.com/privacybydesign/irmago), and the JSON messages generally correspond to specific Go structs. For example, the [`GET /session/{token}/result`](api-irma-server.md#get-session-token-result) endpoint of the [`irma server`](irma-server.md) outputs instances of the [`server.SessionResult`](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult). In such cases, a link to the corresponding Go struct will be included. This can tell you what fields you can use or expect. (Note that some structs have custom (un)marshalers. See also the [Go documentation](https://blog.golang.org/json-and-go) on JSON and Go.)
diff --git a/website/README.md b/website/README.md
deleted file mode 100644
index 745669b..0000000
--- a/website/README.md
+++ /dev/null
@@ -1,201 +0,0 @@
-This website was created with [Docusaurus](https://docusaurus.io/).
-
-# What's In This Document
-
-* [Get Started in 5 Minutes](#get-started-in-5-minutes)
-* [Directory Structure](#directory-structure)
-* [Editing Content](#editing-content)
-* [Adding Content](#adding-content)
-* [Full Documentation](#full-documentation)
-
-# Get Started in 5 Minutes
-
-### Using Docker
-To build the website and run it inside a Docker container, use the following command:
-```sh
-$ docker-compose up
-```
-Afterwards the website is accessible via http://localhost:3000 in your browser.
-
-### For development
-1. Make sure all the dependencies for the website are installed:
-
-```sh
-# Install dependencies
-$ yarn
-```
-2. Run your dev server:
-
-```sh
-# Start the site
-$ yarn start
-```
-
-## Directory Structure
-
-Your project file structure should look something like this
-
-```
-my-docusaurus/
- docs/
- doc-1.md
- doc-2.md
- doc-3.md
- website/
- blog/
- 2016-3-11-oldest-post.md
- 2017-10-24-newest-post.md
- core/
- node_modules/
- pages/
- static/
- css/
- img/
- package.json
- sidebar.json
- siteConfig.js
-```
-
-# Editing Content
-
-## Editing an existing docs page
-
-Edit docs by navigating to `docs/` and editing the corresponding document:
-
-`docs/doc-to-be-edited.md`
-
-```markdown
----
-id: page-needs-edit
-title: This Doc Needs To Be Edited
----
-
-Edit me...
-```
-
-For more information about docs, click [here](https://docusaurus.io/docs/en/navigation)
-
-## Editing an existing blog post
-
-Edit blog posts by navigating to `website/blog` and editing the corresponding post:
-
-`website/blog/post-to-be-edited.md`
-```markdown
----
-id: post-needs-edit
-title: This Blog Post Needs To Be Edited
----
-
-Edit me...
-```
-
-For more information about blog posts, click [here](https://docusaurus.io/docs/en/adding-blog)
-
-# Adding Content
-
-## Adding a new docs page to an existing sidebar
-
-1. Create the doc as a new markdown file in `/docs`, example `docs/newly-created-doc.md`:
-
-```md
----
-id: newly-created-doc
-title: This Doc Needs To Be Edited
----
-
-My new content here..
-```
-
-1. Refer to that doc's ID in an existing sidebar in `website/sidebar.json`:
-
-```javascript
-// Add newly-created-doc to the Getting Started category of docs
-{
- "docs": {
- "Getting Started": [
- "quick-start",
- "newly-created-doc" // new doc here
- ],
- ...
- },
- ...
-}
-```
-
-For more information about adding new docs, click [here](https://docusaurus.io/docs/en/navigation)
-
-## Adding a new blog post
-
-1. Make sure there is a header link to your blog in `website/siteConfig.js`:
-
-`website/siteConfig.js`
-```javascript
-headerLinks: [
- ...
- { blog: true, label: 'Blog' },
- ...
-]
-```
-
-2. Create the blog post with the format `YYYY-MM-DD-My-Blog-Post-Title.md` in `website/blog`:
-
-`website/blog/2018-05-21-New-Blog-Post.md`
-
-```markdown
----
-author: Frank Li
-authorURL: https://twitter.com/foobarbaz
-authorFBID: 503283835
-title: New Blog Post
----
-
-Lorem Ipsum...
-```
-
-For more information about blog posts, click [here](https://docusaurus.io/docs/en/adding-blog)
-
-## Adding items to your site's top navigation bar
-
-1. Add links to docs, custom pages or external links by editing the headerLinks field of `website/siteConfig.js`:
-
-`website/siteConfig.js`
-```javascript
-{
- headerLinks: [
- ...
- /* you can add docs */
- { doc: 'my-examples', label: 'Examples' },
- /* you can add custom pages */
- { page: 'help', label: 'Help' },
- /* you can add external links */
- { href: 'https://github.com/facebook/Docusaurus', label: 'GitHub' },
- ...
- ],
- ...
-}
-```
-
-For more information about the navigation bar, click [here](https://docusaurus.io/docs/en/navigation)
-
-## Adding custom pages
-
-1. Docusaurus uses React components to build pages. The components are saved as .js files in `website/pages/en`:
-1. If you want your page to show up in your navigation header, you will need to update `website/siteConfig.js` to add to the `headerLinks` element:
-
-`website/siteConfig.js`
-```javascript
-{
- headerLinks: [
- ...
- { page: 'my-new-custom-page', label: 'My New Custom Page' },
- ...
- ],
- ...
-}
-```
-
-For more information about custom pages, click [here](https://docusaurus.io/docs/en/custom-pages).
-
-# Full Documentation
-
-Full documentation can be found on the [website](https://docusaurus.io/).
diff --git a/website/core/Footer.js b/website/core/Footer.js
deleted file mode 100644
index 6cb2301..0000000
--- a/website/core/Footer.js
+++ /dev/null
@@ -1,67 +0,0 @@
-/**
- * Copyright (c) 2017-present, Facebook, Inc.
- *
- * This source code is licensed under the MIT license found in the
- * LICENSE file in the root directory of this source tree.
- */
-
-const React = require('react');
-
-class Footer extends React.Component {
- docUrl(doc, language) {
- const baseUrl = this.props.config.baseUrl;
- const docsUrl = this.props.config.docsUrl;
- const docsPart = `${docsUrl ? `${docsUrl}/` : ''}`;
- const langPart = `${language ? `${language}/` : ''}`;
- return `${baseUrl}${docsPart}${langPart}${doc}`;
- }
-
- baseUrl(page) {
- const baseUrl = this.props.config.baseUrl;
- return `${baseUrl}${page}`;
- }
-
- pageUrl(doc, language) {
- const baseUrl = this.props.config.baseUrl;
- return baseUrl + (language ? `${language}/` : '') + doc;
- }
-
- render() {
- return (
-
- );
- }
-}
-
-module.exports = Footer;
diff --git a/website/package.json b/website/package.json
deleted file mode 100644
index b5caaf9..0000000
--- a/website/package.json
+++ /dev/null
@@ -1,15 +0,0 @@
-{
- "scripts": {
- "examples": "docusaurus-examples",
- "start": "docusaurus-start",
- "build": "docusaurus-build",
- "publish-gh-pages": "docusaurus-publish",
- "write-translations": "docusaurus-write-translations",
- "version": "docusaurus-version",
- "rename-version": "docusaurus-rename-version"
- },
- "devDependencies": {
- "docusaurus": "sietseringers/docusaurus#860be33493f95239c3cbc0e75a009064fc2052a1"
- },
- "license": "MIT"
-}
diff --git a/website/pages/en/about.js b/website/pages/en/about.js
deleted file mode 100755
index 5cdb557..0000000
--- a/website/pages/en/about.js
+++ /dev/null
@@ -1,63 +0,0 @@
-/**
- * Copyright (c) 2017-present, Facebook, Inc.
- *
- * This source code is licensed under the MIT license found in the
- * LICENSE file in the root directory of this source tree.
- */
-
-const React = require('react');
-
-const CompLibrary = require('../../core/CompLibrary.js');
-
-const Container = CompLibrary.Container;
-const GridBlock = CompLibrary.GridBlock;
-
-function Help(props) {
- const {config: siteConfig, language = ''} = props;
- const {baseUrl, docsUrl} = siteConfig;
- const docsPart = `${docsUrl ? `${docsUrl}/` : ''}`;
- const langPart = `${language ? `${language}/` : ''}`;
- const docUrl = doc => `${baseUrl}${docsPart}${langPart}${doc}`;
-
- const supportLinks = [
- {
- title: 'Browse Docs',
- content: `Learn more about IRMA using the [documentation on this site.](${docUrl(
- 'what-is-irma',
- )})`,
- },
- {
- title: 'Slack',
- content: 'In our Slack channel we discuss all IRMA matters, technical and otherwise. Ask for an invite.',
- },
- {
- title: 'Twitter',
- content: 'You can follow and contact us on Twitter.',
- },
- {
- title: 'GitHub',
- content: 'Read and contribute to the IRMA source code on GitHub.',
- }
- ];
-
- return (
-
-
-
-
-
About IRMA
-
-
IRMA is developed and maintained by the Privacy by Design Foundation and SIDN, and is free and open source. See the Foundation's website for news about IRMA; how you can support IRMA; statistics on the Foundation's IRMA infrastructure; scientific publications related to IRMA; and more.
-
To contact us, join us on Slack (see below) or send an e-mail to info at privacybydesign dot foundation.
-
-The IRMA server enables this by sending the session results of the intermediate sessions in the chain to a server chosen by the requestor, which can process the session results and respond with a session request for the next session in the chain.
-
-Attributes disclosed in earlier sessions in a session chain can also be used to lookup data to be issued in a new credential, later in the session chain. More generally, within a session chain later sessions may depend on the results of the earlier sessions. With ordinary (that is, non-chained) IRMA sessions, the only possible way to achieve this is to send the user to a webpage between each session to start the next session.
-
-This page documents how this feature works.
-
-## The `nextSession` URL
-
-An [extended session request](session-requests.md#extra-parameters) may now contain a `nextSession` object which must contain a `url` field. If so, then at the end of the session (i.e., after the user has agreed to perform the session in the session screen of the Yivi app), the IRMA server will POST the [session result](https://pkg.go.dev/github.com/privacybydesign/irmago/server#SessionResult) in JSON (as returned by the [`/result` endpoint](api-irma-server#get-session-requestortoken-result)) to that `url`. The server at that `url` must then respond with one of the following:
-
-* a new (extended) session request in JSON, which may depend on the received session result;
-* HTTP 204, signifying that there is no next session to be performed. In this case, no further sessions take place and the flow stops normally.
-
-In the first case, the IRMA server will then start a new session using that session request and pass it to the Yivi app, which will show the corresponding session screen. Thus, the app user moves from the first session screen immediately to the next one.
-
-The session request returned by the server at the `nextSession` URL may itself contain a `nextSession` object (possibly but not necessarily referring to the same server). If so, then yet another session will be started using the same mechanism, after the one specified by the current session request. In this fashion, a session chain can consist of any number of sessions (although ideally it is kept as short as possible for optimal UX; in most cases two sessions will suffice).
-
-## Signing POSTed session results
-
-If a [JWT private key is installed in the IRMA server](irma-server.md#signed-jwt-session-results), then instead of POSTing plain JSON session results (as returned by the [`/result` endpoint](api-irma-server#get-session-requestortoken-result)) to the `nextSession` URL, the server will POST a session result JWT signed with the private key (as returned by the [`/result-jwt` endpoint](api-irma-server.md#get-session-requestortoken-result-jwt)) to the `nextSession` URL. The server at that URL can verify the JWT using the corresponding public key to authenticate the request as coming from the expected IRMA server.
-
-If a JWT private key is not installed, then the boolean `--allow-unsigned-callbacks` option must be passed to the IRMA server before chained sessions may be used, to explicitly enable POSTing unsigned session results. Otherwise, the server will reject session requests containing a `nextSession` object.
-
-> If no JWT private key is installed, then the `nextSession` URL should either not be publically reachable, or it should include a secret token (e.g. `https://example.com/cX5aTins5kEZpjDpfYcN`) and have TLS enabled (which it should anyway as personal data will be POSTed to it). Otherwise there is no way for the server at the `nextSession` URL to distinguish POSTs from your IRMA server from POSTs made by anyone else.
-
-## Use cases
-
-* Retrieving an attribute and then issuing it into a new credential.
-* Retrieving an attribute; use that to lookup related data; and issue that data into new credentials.
-* Refreshing a nearly expired credential, by retrieving an identifying attribute from it; use that to lookup fresh values for the other attributes, and issue a fresh credential.
-
-## Example
-
-In this example, we use an IRMA disclosure request to retrieve the user's name, and then issue that into a new credential, as shown in the two screenshots on top of this page. A live demo very similar to this may be found [here](https://privacybydesign.foundation/demo/irmaTubePremium).
-
-First, we deploy the following Go program at `https://example.com`. This program unmarshals the request body into a session result, takes the discloed attribute from it, and returns an issuance request containing that attribute.
-
-Note that this program assumes that no JWT private key is installed; see the remark in the previous paragraph.
-
-```go
-package main
-
-import (
- "encoding/json"
- "fmt"
- "io/ioutil"
- "log"
- "net/http"
-
- irma "github.com/privacybydesign/irmago"
- "github.com/privacybydesign/irmago/server"
-)
-
-func main() {
- log.Fatal(http.ListenAndServe(":80", http.HandlerFunc(handler)))
-}
-
-func handler(w http.ResponseWriter, r *http.Request) {
- // Read and unmarshal the POSTed session result
- bts, err := ioutil.ReadAll(r.Body)
- if err != nil {
- writeError(w, err.Error())
- return
- }
- var result server.SessionResult
- if err := json.Unmarshal(bts, &result); err != nil {
- writeError(w, err.Error())
- return
- }
-
- // Perform sanity checks on the session result.
- // NB: this endpoint is called by the IRMA server just before it ends the
- // session, so the session status is expected to be server.StatusConnected
- // (or the JSON string "CONNECTED").
- if result.Status != server.StatusConnected ||
- result.ProofStatus != irma.ProofStatusValid ||
- len(result.Disclosed) == 0 || len(result.Disclosed[0]) == 0 ||
- result.Disclosed[0][0].Identifier.String() != "irma-demo.gemeente.personalData.fullname" ||
- result.Disclosed[0][0].RawValue == nil {
- writeError(w, "received invalid session result")
- return
- }
-
- // Construct issuance request to respond with,
- // containing the attribute from the session result
- issuanceRequest := irma.NewIssuanceRequest([]*irma.CredentialRequest{{
- CredentialTypeID: irma.NewCredentialTypeIdentifier("irma-demo.IRMATube.member"),
- Attributes: map[string]string{
- "fullname": *result.Disclosed[0][0].RawValue,
- "type": "premium",
- "id": "123456",
- }}},
- )
-
- // Marshal and write our issuance request
- bts, err = json.Marshal(issuanceRequest)
- if err != nil {
- writeError(w, err.Error())
- return
- }
- w.Header().Set("Content-Type", "application/json")
- if _, err = w.Write(bts); err != nil {
- fmt.Println(err.Error())
- }
-}
-
-func writeError(w http.ResponseWriter, msg string) {
- w.WriteHeader(500)
- w.Write([]byte(msg))
-}
-```
-
-The session chain can then be started by sending the following session request to our IRMA server.
-
-
-
-```jsonc
-{
- "nextSession": {
- "url": "https://example.com"
- },
- "request": {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "irma-demo.gemeente.personalData.fullname" ]]]
- }
-}
-```
-
-```go
-irma.ServiceProviderRequest{
- RequestorBaseRequest: irma.RequestorBaseRequest{
- NextSession: &irma.NextSessionData{
- URL: "https://example.com",
- },
- },
- Request: irma.NewDisclosureRequest(
- irma.NewAttributeTypeIdentifier("irma-demo.gemeente.personalData.fullname"),
- ),
-}
-```
-
-
-After the user discloses the `irma-demo.gemeente.personalData.fullname` attribute, the IRMA server POSTs it to `https://example.com`. Our Go server responds to the IRMA server with the `issuanceRequest` found near the end of the program. Next, the IRMA server immediately starts this issuance session with the user's Yivi app, resulting in the screenshots shown on top of this page.
-
-## Differences with combined issuance-disclosure requests
-
-[Combined issuance-disclosure requests](session-requests.md#issuance-requests), i.e. issuance requests with a nonempty `disclose` field requesting attributes to be disclosed, is another way of first requesting and then issuing attributes from/to an Yivi app user within a single flow. Thus, this is very similar to a session chain consisting of first a disclosure request and then an issuance request. However, contrary to session chains, this flow is started using a single session request. Thus, when using combined issuance-disclosure requests it is impossible for the issued attributes to depend on the disclosed attributes, because at the time the session request is composed the value of the disclosed attributes are not yet known.
-
-Comparing the two, chained sessions are more powerful in the following ways:
-
-* As mentioned, sessions later in the chain may depend on the session results of earlier sessions in the chain;
-* Session chains can consist of more than two sessions (although this may lead to bad UX);
-* The sessions occuring in a session chain may be of any type (although first disclosure and then issuance is probably the most common scenario).
diff --git a/website/versioned_docs/version-v0.13.0/condiscon.md b/website/versioned_docs/version-v0.13.0/condiscon.md
deleted file mode 100644
index 84fba0e..0000000
--- a/website/versioned_docs/version-v0.13.0/condiscon.md
+++ /dev/null
@@ -1,195 +0,0 @@
----
-title: "\"Condiscon\" session requests"
-id: version-v0.13.0-condiscon
-original_id: condiscon
----
-
-
-
-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.
-- 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.
-
-
-
-
-
-```json
-{
- "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"
- ]
- }]
-}
-```
-
-
-"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:
-
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.MijnOverheid.root.BSN" ]
- ],
- [
- [
- "irma-demo.nijmegen.address.street",
- "irma-demo.nijmegen.address.houseNumber",
- "irma-demo.nijmegen.address.city"
- ],
- [
- "irma-demo.idin.idin.address",
- "irma-demo.idin.idin.city"
- ]
- ]
- ]
-}
-```
-
-```golang
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.root.BSN")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.nijmegen.address.street"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.houseNumber"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.city"),
- },
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.idin.idin.address"),
- irma.NewAttributeRequest("irma-demo.idin.idin.city"),
- },
- },
-}
-```
-
-
-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).
-- 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:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- "pbdf.pbdf.diploma.degree",
- "pbdf.pbdf.diploma.institute"
- ]
- ]
- ]
-}
-```
-
-```golang
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("pbdf.pbdf.diploma.degree"),
- irma.NewAttributeRequest("pbdf.pbdf.diploma.institute"),
- },
- },
-}
-```
-
-
-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.)
-
-When combining multiple credential types within a disjunction these restrictions ensure that when the Yivi app computes candidate attribute sets for the user to choose from, the amount of resulting options stays manageable. In adddition, the second restriction is a new feature on its own, allowing verifiers to request multiple attributes coming from one credential instance.
-
-## Other features
-
-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:
-
-
- ```json
- {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [],
- [ "pbdf.pbdf.diploma.degree" ]
- ]
- ]
- }
- ```
-
- ```golang
- request := irma.NewDisclosureRequest()
- request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{},
- irma.AttributeCon{irma.NewAttributeRequest("pbdf.pbdf.diploma.degree")},
- },
- }
- ```
-
- 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).
-
-For full details, see the documentation of the [session request format](session-requests.md).
-
-## Compatibility
-
-The `irma server` of version `0.3.0` and up is:
-- Backwards compatible with the old session request format, i.e. with old IRMA requestor applications. New session request JSON objects are recognized as such by the presence of their `@context` property; if this is absent the request is interpreted as a pre-condiscon IRMA session request.
-- Backwards compatible with old Yivi apps, as long as the condiscon feature is not used in the session (i.e., all inner conjunctions contain exactly 1 attribute).
-- [This `irmago` unit test](https://github.com/privacybydesign/irmago/blob/condiscon/irmago_test.go#L259) shows how pre-condiscon session requests are converted, by asserting equality of pre- and post-condiscon session requests, for all three session types.
-- The documentation of the pre-condiscon session format can be found on the [session requests](/v0.2.0/session-requests) page.
-
-The new Yivi app is backwards compatible with the old session request format, i.e. with old `irma server`s, *except* in case of signature sessions (see below).
-
-## Signature sessions
-
-For attribute-based signatures, the condiscon version of the IRMA software brings another update that fixes the [following issue](https://github.com/privacybydesign/irmago/issues/35): if the scheme manager adds a new attribute to an existing credential type, then attribute-based signatures using attributes from that credential type that were created before the attribute was added would fail to verify by the IRMA server, due to the signature not incorporating the new attribute. In effect, adding a new attribute to an existing credential type would invalidate all attribute-based signatures previously made that contain attributes from that credential.
-
-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).
-
diff --git a/website/versioned_docs/version-v0.13.0/email.md b/website/versioned_docs/version-v0.13.0/email.md
deleted file mode 100644
index ec2b3b4..0000000
--- a/website/versioned_docs/version-v0.13.0/email.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Email address
-id: version-v0.13.0-email
-original_id: email
----
-
-IRMA has a decentral architecture: anyone can start an [`irma server`](irma-server.md) and verify attributes, communicating directly with Yivi apps. This is an important and distinguishing feature contributing to IRMA's privacy features and trustworthiness, but also means that we as authors of the software have no natural update channel with which we can update all IRMA servers running within the ecosystem. We have to prevent that this leads to a fractured IRMA ecosystem with incompatible apps and servers, which would lead to bad user experience and hurt adoption.
-
-Inspired by the approach of Let's Encrypt, each of the [IRMA server](what-is-irma.md#irma-servers) software components can be configured with an email address. If specified, the email address is uploaded to the [Privacy by Design Foundation](https://privacybydesign.foundation/) and subscribed to receive updates about changes in the IRMA software or ecosystem. You will be notified of changes such as major updates of the IRMA server, and breaking changes in any part of the IRMA infrastructure that would require you to update your IRMA server or otherwise take action in order to stay compatible with the rest of the IRMA ecosystem.
-
-***We strongly recommend anyone running any IRMA server in production to specify an email address.***
-
- * If you provide your email address it will exclusively be used by the Foundation for the above purpose.
- * It will be very low volume (on average perhaps one email per several months).
- * If you have provided your email address in the past and wish to be unsubscribed, please email [the Foundation](https://privacybydesign.foundation/contact-en/).
- * See also the Foundation's [privacy policy](https://privacybydesign.foundation/privacy-policy-en/).
diff --git a/website/versioned_docs/version-v0.13.0/getting-started.md b/website/versioned_docs/version-v0.13.0/getting-started.md
deleted file mode 100644
index 5a38c95..0000000
--- a/website/versioned_docs/version-v0.13.0/getting-started.md
+++ /dev/null
@@ -1,180 +0,0 @@
----
-title: Getting started
-id: version-v0.13.0-getting-started
-original_id: getting-started
----
-
-This page shows how to get started with verifying or issuing IRMA attributes, using the following components:
-
- * [`irma server`](irma-server.md), a server that verifies or issues IRMA attributes to [Yivi apps](yivi-app.md),
- * [`irma-frontend`](irma-frontend.md), a JavaScript library for drawing the IRMA QR in your website, and handling IRMA session with the `irma server`.
-
-You should have the [Yivi app](yivi-app.md) installed ([Android](https://play.google.com/store/apps/details?id=org.irmacard.cardemu), [iOS](https://itunes.apple.com/nl/app/irma-authentication/id1294092994)). If you want to compile from source instead of using prebuilt binaries, you should additionally have [Git](https://git-scm.com/), [Go](https://golang.org/doc/install), and [npm](https://docs.npmjs.com/cli/npm) installed.
-
-
-## Installing and running `irma server`
-You can install the `irma` command line tool in the following two ways.
-
-* **Download prebuilt binary**: From [GitHub](https://github.com/privacybydesign/irmago/releases/latest). Choose the binary for your OS and architecture (most likely amd64). Rename the file to `/usr/local/bin/irma` to have it available in your PATH.
-* **Compile and install from source** as follows:
- ```shell
- go install github.com/privacybydesign/irmago/irma@latest
- ```
-* **Using Docker**:
- ```shell
- docker pull ghcr.io/privacybydesign/irma:latest
- ```
-
-After installing the `irma` binary, start the server (with increased verbosity but otherwise default configuration):
-* Using a prebuilt binary or compiled from source:
- ```shell
- irma server -v
- ```
-* Using Docker:
- ```shell
- IP=192.168.1.2 # Replace with your local IP address.
- docker run -p 8088:8088 ghcr.io/privacybydesign/irma:latest server -v --url "http://$IP:port"
- ```
-
-Run `irma server -h` to see configuration options. In order to verify your configuration, run `irma server check -v`. General documentation can be found on the [irma server](irma-server.md) page, API documentation of HTTP endpoints can be found on the [api irma server](api-irma-server.md) page.
-
-## Perform a command line IRMA session
-Given a running IRMA server (see above), you can perform a first IRMA session using your server on the command line as follows:
-* Using a prebuilt binary or compiled from source:
- ```shell
- irma session --server http://localhost:8088 --disclose pbdf.pbdf.irmatube.type
- ```
-* Using Docker
- ```shell
- IP=192.168.1.2 # Replace with your local IP address.
- docker run ghcr.io/privacybydesign/irma:latest session --server "http://$IP:8088" --disclose pbdf.pbdf.irmatube.type
- ```
-[IRMATube attributes](https://privacybydesign.foundation/attribute-index/en/pbdf.pbdf.irmatube.html) are available on the [IRMATube demo](https://privacybydesign.foundation/demo/irmaTube/) page. This will print a QR that you can scan with your Yivi app, and the attribute contents after they have been received and verified by the server. `irma session` can also perform issuance sessions and attribute-based signature sessions. If you pass `-v` it logs the session request JSON that it sends to your `irma server`.
-
-
-## Installing an example webpage for `yivi-frontend`
-Download the `yivi-frontend-packages` source code, as [zip](https://github.com/privacybydesign/yivi-frontend-packages/archive/master.zip) from GitHub, or using git:
-```shell
-git clone https://github.com/privacybydesign/yivi-frontend-packages && cd yivi-frontend-packages
-```
-
-Examples for the browser and for nodejs are included in the `examples` folder. In this guide we will use the `yivi-frontend` example for browsers to realize the example webpage. This example has to be installed first.
-```shell
-cd examples/browser/yivi-frontend/
-npm install
-npm run build
-```
-
-## Perform browser IRMA session
-
-(Re)start your `irma server`, configuring it such that it statically hosts the `irma-frontend` example webpage we just built:
-* Using a prebuilt binary or compiled from source:
- ```shell
- irma server -v --static-path ~/yivi-frontend-packages/examples/browser/yivi-frontend
- ```
-* Using Docker:
- ```shell
- IP=192.168.1.2 # Replace with your local IP address.
- docker run -v ~/yivi-frontend-packages:/yivi-frontend-packages -p 8088:8088 ghcr.io/privacybydesign/irma:latest server -v --url "http://$IP:port" --static-path /yivi-frontend-packages/examples/browser/yivi-frontend
- ```
-A webpage demoing IRMA attribute issuance verification should now be available at http://localhost:8088.
-
-> Open the browser console and the console running `irma server` to see various log messages and possibly error messages as the IRMA session proceeds.
-
-## Example configuration and IRMA session
-
-Generally, your IRMA server runs in your backend alongside a server application serving your frontend (website), with which the Yivi app user is interacting. Your server application starts and manages sessions at your IRMA server to verify or issue attributes (for example, when the user wants to log in). This can be setup as follows.
-
-### Configure `irma server`
-
-In production it is generally best to [authenticate incoming session requests](irma-server.md#requestor-authentication) from your application. The following is an example production configuration file ([in YAML](irma-server.md#configuring)) for the `irma server` (start with `irma server -c /path/to/config.yml`) that will accept [session requests](session-requests.md) if they include a `Authorization: mysecrettoken` HTTP header.
-
-```yaml
-production: true
-email: "example@example.com" # see https://irma.app/docs/email
-
-port: 443
-url: "https://example.com/irma/"
-tls_cert: "/etc/letsencrypt/live/example.com/fullchain.pem"
-tls_privkey: "/etc/letsencrypt/live/example.com/privkey.pem"
-
-no_auth: false
-requestors:
- myapp:
- auth_method: "token"
- key: "mysecrettoken"
-```
-
-* You may want to [restrict permissions](irma-server.md/#permissions) to verify or issue specific attributes, globally or per requestor.
-* The server can be made into a daemon on most Linux systems [using a systemd unit file](irma-server.md#running-as-daemon).
-* Another common setup is to have a reverse proxy between the IRMA server and the internet, which handles TLS instead and forwards traffic on `https://example.com/irma/` to the IRMA server.
-
-### Perform a session
-
-Assuming your application runs on the same server as the IRMA server, your application can now start a session at your IRMA server as follows (using `curl` as example):
-
-```bash
-curl https://example.com/session \
- -X POST \
- -H "Content-Type: application/json" \
- -H "Authorization: mysecrettoken" \
- -d '{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[["irma-demo.MijnOverheid.ageLower.over18"]]]
- }'
-```
-
-This will output something like the following:
-
-```json
-{
- "token": "X7LU5Q8Jhig0330gjYUO",
- "sessionPtr": {"u": "https://example.com/irma/t1nXs4ZduyhvAeAAlB77","irmaqr": "disclosing"},
- "frontendRequest":{"authorization":"X9XeI0gJG2HZv4hZ1WkP","minProtocolVersion":"1.0","maxProtocolVersion":"1.1"}
-}
-```
-
-* Use the `token` to [track the session status](api-irma-server.md#get-session-token-status), and to [get the session result](api-irma-server.md#get-session-token-result) after the session has finished.
-* The `sessionPtr` and `frontendRequest` are used by [`irma-frontend`](api-irma-frontend.md) to show an IRMA QR code or toggle to the Yivi app. Generally you [configure `irma-frontend`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client#usage) with an URL that returns the `sessionPtr` and `frontendRequest`; it will then start the session automatically.
-
-Instead of managing sessions with HTTP requests as shown here, [for certain languages](irma-backend.md) (currently Go and JavaScript) it is also possible to include an IRMA library and manage sessions using function invocations.
-
-## Issuing IRMA attributes
-
-This page mostly focuses on verifying, i.e. receiving IRMA attributes from Yivi apps and establishing their authenticity. Issuing attributes to Yivi apps can be done with the same software and with largely similar flows, but is more involved, because the identity of prospective issuers need to be verified and the contents and structure of the credentials to be issued needs to be established. This process is documented (among other things) in the [issuer guide](issuer.md).
-
-For experimenting and demoing, however, it is possible to issue [any of the existing credentials](https://privacybydesign.foundation/attribute-index/en/irma-demo.html) within the [`irma-demo` scheme](schemes.md). For example, if the `requestors` block in the [YAML example configuration](#configure-irma-server) of the IRMA server above would include permission to issue `irma-demo` attrbutes, as follows:
-
-```yaml
-requestors:
- myapp:
- auth_method: "token"
- key: "mysecrettoken"
- issue_perms:
- - "irma-demo.*"
-```
-
-Then an issuance session for the credential used in the [example disclosure session](#perform-a-session) above can be started at the IRMA server as follows:
-
-```bash
-curl https://example.com/session \
- -X POST \
- -H "Content-Type: application/json" \
- -H "Authorization: mysecrettoken" \
- -d '{
- "@context": "https://irma.app/ld/request/issuance/v2",
- "credentials": [
- {
- "credential": "irma-demo.MijnOverheid.ageLower",
- "attributes": {
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no"
- }
- }
- ]
- }'
-```
-
-To issue a demo credential of your own not already present in the `irma-demo` scheme, see the [issuer guide](issuer.md).
diff --git a/website/versioned_docs/version-v0.13.0/irma-app.md b/website/versioned_docs/version-v0.13.0/irma-app.md
deleted file mode 100644
index 3e14f67..0000000
--- a/website/versioned_docs/version-v0.13.0/irma-app.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: IRMA app
-id: version-v0.13.0-irma-app
-original_id: irma-app
----
-
-The IRMA app has been renamed to [Yivi](yivi-app.md).
diff --git a/website/versioned_docs/version-v0.13.0/irma-backend.md b/website/versioned_docs/version-v0.13.0/irma-backend.md
deleted file mode 100644
index e262e14..0000000
--- a/website/versioned_docs/version-v0.13.0/irma-backend.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: IRMA backend packages
-id: version-v0.13.0-irma-backend
-original_id: irma-backend
----
-
-[`irma-backend-packages`](https://github.com/privacybydesign/irma-backend-packages/)
-is a collection of libraries in multiple programming languages assuming the role
-of the [IRMA server](what-is-irma.md#irma-servers) in the IRMA protocol, allowing you to integrate IRMA in the backend
-of your application. In particular, these libraries allow you to do the following:
-
- * Starting IRMA sessions using a session request or a JWT at the IRMA server
- * Retrieving the current status of IRMA sessions (only once or by receiving events on status updates)
- * Retrieving session result or session result JWT when a session succeeded
- * Cancelling IRMA sessions
- * Retrieving the JWT public key of the IRMA server
- * Generating a JWT of a session request
- * Verifying a JWT of a session request or a session result
-
-Additionally, they will handle all communication with the [Yivi app](yivi-app.md).
-
-Depending on the programming language, the libraries achieve this by either directly including
-the IRMA server functionality, or by consuming the [REST API](api-irma-server.md) exposed
-by the [`irma server`](irma-server.md).
-
-The library will slightly differ per language, since each programming language has its own conventions.
-
-## Available languages
-For the list of currently available programming languages, check the [GitHub README](https://github.com/privacybydesign/irma-backend-packages/). (Note that for the Go programming language, there is
-a separate [`irmaserver`](irma-server-lib.md) Go package.)
-
-If the programming language of your choice is not available yet, you can
-always directly invoke the `irma server` [REST API](api-irma-server.md).
-If you think the programming language of your choice would benefit being part of
-`irma-backend-packages`, you can always contact us or make an issue on [GitHub](https://github.com/privacybydesign/irma-backend-packages/issues).
-
-If you made a library for a programming language yourself that we do not support yet,
-or if you added features to existing libraries, please send us a pull request.
-We are always interested in extending the IRMA ecosystem with support for additional
-programming languages.
diff --git a/website/versioned_docs/version-v0.13.0/irma-cli.md b/website/versioned_docs/version-v0.13.0/irma-cli.md
deleted file mode 100644
index 1f3bdab..0000000
--- a/website/versioned_docs/version-v0.13.0/irma-cli.md
+++ /dev/null
@@ -1,85 +0,0 @@
----
-title: irma command line tool
-id: version-v0.13.0-irma-cli
-original_id: irma-cli
----
-
-`irma` is an IRMA Swiss knife in the form of a command line executable, supporting the following subcommands:
-
-* [`irma server`](irma-server.md): an IRMA server daemon allowing you to perform IRMA sessions with [Yivi apps](yivi-app.md).
-* `irma session`: Perform an IRMA disclosure, issuance or signature session, using the [builtin](irma-server-lib.md) IRMA server or a remote [`irma server`](irma-server.md)
-* [`irma scheme`](schemes.md#updating-and-signing-schemes-with-irma): Manage IRMA schemes, supporting downloading, updating, verifying, and signing schemes, and IRMA key generation
-* `irma request`: compose an IRMA session request
-* `irma meta`: Parse an IRMA metadata attribute and print its contents
-
-Pass `-h` or `--help` to any of these subcommands to see usage details and examples.
-
-## Installation
-
-Preferably, you should build `irma` from source, but we also provided binary releases built by GitHub Actions.
-
-### Compiling from source
-
-```shell
-go install github.com/privacybydesign/irmago/irma@latest
-```
-
-### Using the binary release
-
-You can download the precompiled `irmago` binaries from [GitHub](https://github.com/privacybydesign/irmago/releases/latest). Choose the binary for your OS and architecture (most likely amd64). Rename the file to `/usr/local/bin/irma` to have it available in your PATH.
-
-### Using Docker
-
-```shell
-docker pull ghcr.io/privacybydesign/irma:latest
-```
-
-## Examples
-
-Perform IRMA sessions on the command line. By default, this starts a IRMA server specfically for one session on port 48680, prints the QR, and prints session results when the session is done:
-```shell
-$ irma session --disclose pbdf.nijmegen.personalData.fullname
-$ irma session --issue irma-demo.MijnOverheid.ageLower=yes,yes,yes,no
-$ irma session --noqr --request '{"type":"disclosing","content":[{"label":"BSN","attributes":["irma-demo.MijnOverheid.ageLower.over18"]}]}'
-$ irma session --server http://localhost:8088 --authmethod token --key mytoken --disclose irma-demo.MijnOverheid.ageLower.over18
-```
-
-> If you run using Docker, then the commands look a bit different.
-> ```shell
-> docker run -p 48680:48680 ghcr.io/privacybydesign/irma:latest session --url "http://$IP:48680" --disclose pbdf.nijmegen.personalData.fullname
-> docker run -p 48680:48680 ghcr.io/privacybydesign/irma:latest session --url "http://$IP:48680" --issue irma-demo.MijnOverheid.ageLower=yes,yes,yes,no
-> docker run -p 48680:48680 ghcr.io/privacybydesign/irma:latest session --url "http://$IP:48680" --noqr --request '{"type":"disclosing","content":[{"label":"BSN","attributes":["irma-demo.MijnOverheid.ageLower.over18"]}]}'
-> docker run ghcr.io/privacybydesign/irma:latest session --server "http://$IP:8088" --authmethod token --key mytoken --disclose irma-demo.MijnOverheid.ageLower.over18
-> ```
-
-Download an IRMA scheme and then verify its authenticity:
-```shell
-$ irma scheme download . https://privacybydesign.foundation/schememanager/irma-demo
-$ irma scheme verify irma-demo
-Verifying scheme irma-demo
-
-Verification was successful.
-```
-
-Generate an IRMA issuer private-public keypair (of 2048 bits and supporting a maximum of 10 attributes):
-```shell
-$ cd irma-demo/MijnIssuer
-$ irma scheme issuer keygen # takes a while
-$ ls PublicKeys PrivateKeys
-PrivateKeys:
-0.xml
-
-PublicKeys:
-0.xml
-```
-
-Sign an IRMA scheme after having made modifications:
-```shell
-$ cd irma-demo
-# Make modifications (e.g. add a public key to an issuer with irma scheme issuer keygen)
-$ irma scheme sign
-$ irma scheme verify
-Verifying scheme irma-demo
-
-Verification was successful.
-```
diff --git a/website/versioned_docs/version-v0.13.0/irma-protocol.md b/website/versioned_docs/version-v0.13.0/irma-protocol.md
deleted file mode 100644
index 315e6ef..0000000
--- a/website/versioned_docs/version-v0.13.0/irma-protocol.md
+++ /dev/null
@@ -1,378 +0,0 @@
----
-title: IRMA protocol
-id: version-v0.13.0-irma-protocol
-original_id: irma-protocol
----
-
-During an IRMA session, the IRMA protocol is used by the [IRMA server](irma-server.md) and [Yivi app](yivi-app.md) to issue or verify attributes. The Yivi app sends and receives various data by invoking a number of HTTP endpoints of the IRMA server, making the session progress through a number of stages. This page documents those endpoints, the data being handled, and the states the session goes through.
-
-## Introduction
-
-The IRMA protocol consists of a set of messages that are exchanged between the IRMA server and an Yivi app during a session. Each message being sent or received is a JSON serialization of a particular Go struct defined within the [`irmago`](https://github.com/privacybydesign/irmago) source code repository. Thus, whenever we say below that an instance of a particular struct is sent or received, we refer to its JSON serialization. For most of the messages being sent and received, the default Go (un)marshaler is used. Whenever we say that a particular Go struct is sent or received, we will link to its [API documentation](https://pkg.go.dev/github.com/privacybydesign/irmago), from which its JSON structure may be inferred.
-
-We assume here that the Yivi app and server both support the latest IRMA protocol version. Some of the messages have custom unmarshalers, which if an older protocol version is used transform the message to comply with the older protocol version.
-
-The HTTP endpoints of the IRMA server documented here are invoked exclusively by the Yivi app, in particular by the [`irmaclient` Go library](https://pkg.go.dev/github.com/privacybydesign/irmago/irmaclient) used by the Yivi app. These endpoints are not meant for direct use by any other party or software. The endpoints of the IRMA server used by requestors and/or by frontends are documented in the [API reference of the IRMA server](api-irma-server.md).
-
-In order to protect the attributes as they travel over the internet from being read or modified by anyone else than the Yivi app and server to which they are sent, it is important that they are encrypted. The IRMA protocol does not deal with encryption by itself; instead it relies on TLS for this, as well as for authenticating the requestor. Thus, the messages being sent in the protocol as shown below are normally TLS encrypted. The Yivi app will refuse to connect to IRMA servers over plain HTTP without TLS, unless [developer mode](yivi-app.md#developer-mode) is enabled.
-
-The IRMA protocol as outlined below can be seen in action by performing an IRMA session with an IRMA server configured with [maximum verbosity](irma-server.md#logging-and-verbosity), as then it will log all HTTP traffic that it sends and receives.
-
-### The session state
-
-At any time after its creation an IRMA session is in a particular [session state](https://pkg.go.dev/github.com/privacybydesign/irmago#ServerStatus), and with respect to this state the IRMA server acts as a state machine. Each of the endpoints below may be invoked only when the session is in a particular state, and most of them cause the session to progress to a next state. The requestor, the frontend and the Yivi app may keep track of the session state through server-sent events or through polling. An IRMA session progresses through the following states, in the order as they appear here:
-
-* `INITIALIZED`: after the session [is created](#session-creation).
-* `PAIRING`: only if device pairing is enabled, after the Yivi app [first connects to the IRMA server](#retrieving-the-session-request).
-* `CONNECTED`: either when device pairing is disabled and the Yivi app [first connects to the IRMA server](#retrieving-the-session-request), or after the frontend indicates to the IRMA server that pairing has been completed successfully.
-* `DONE`: after the HTTP request has finished processing in which Yivi app has sent its [session response](#sending-the-session-response). In this state, any attributes that were disclosed by the Yivi app to the server are ready to be retrieved by the requestor.
-
-At any time, the session may move from one of the first three states to any of the following states:
-
-* `TIMEOUT`: the session has been in one of the first three states longer than a timeout (configurable in the IRMA server, by default 5 minutes).
-* `CANCELLED`: the session was cancelled [by the Yivi app](#cancelling-delete-irma-session-clienttoken), [the requestor or by the frontend](api-irma-server.md#delete-session-requestortoken); or an error occurred.
-
-Of these states, `DONE`, `TIMEOUT` and `CANCELLED` are final states: no valid state transition exists from these to any other state.
-
-### Sequence diagram
-
-The following sequence diagrams showing an IRMA session in the happy flow, without and with device pairing, summarize the above. Note that these diagrams show a complete session for completeness, including the actions of the frontend, while the remainder of this document focuses on the actions of the Yivi app.
-
-
-
-
-
-
-
-
-
-
-### Further reading
-
-This page is concerned only with the IRMA protocol. For more technical information on IRMA in general, as well as explanations and definitions of some of the terms mentioned in this page, see the [technical overview](overview.md).
-
-This page does not deal with the cryptographic contents of the messages being passed nor how they achieve [IRMA's security properties](overview.md#irma-security-properties), only with how and when they are passed. IRMA being an implementation of the Idemix attribute-based credential scheme, details on the cryptographic contents and mechanisms of the messages may be found in the [Idemix specification](https://dominoweb.draco.res.ibm.com/reports/rz3730_revised.pdf) and in the [paper introducing Idemix](https://cs.brown.edu/people/alysyans/papers/camlys02b.pdf) by Camenisch and Lysyanskaya.
-
-## Session creation
-
-The [requestor](overview.md#participants) creates a session by sending a [session request](session-requests.md) for one of the three supported [session types](what-is-irma.md#session-types) to the [`POST /session`](api-irma-server.md#post-session) endpoint of the `irma server`, or by invoking the [`StartSession()`](https://pkg.go.dev/github.com/privacybydesign/irmago/server/irmaserver#Server.StartSession) function of the `irmaserver` Go library. If the IRMA server accepts the session (i.e., the session request is valid and the requestor is authorized to start sessions), the session is created and its state is set to [`INITIALIZED`](https://pkg.go.dev/github.com/privacybydesign/irmago#ServerStatusInitialized). This means that the IRMA server is waiting for the first HTTP request of the Yivi app, documented below.
-
-When the requestor creates the session, the IRMA server responds with a [session package](api-irma-server.md#post-session). For example:
-
-```json
-{
- "sessionPtr": {
- "u": "https://example.com/irma/session/6xyh0D2CdLsloWljYFH1",
- "irmaqr": "disclosing"
- },
- "token": "NsuDGnWtfpLX7nv4Gn1M",
- "frontendRequest": {
- "authorization": "MfEl17feZHbfOfPQtiJe",
- "minProtocolVersion": "1.0",
- "maxProtocolVersion": "1.1"
- }
-}
-```
-
-The requestor takes the `sessionPtr` and `frontendRequest` from the session package and sends those to its [frontend](irma-frontend.md), which uses them to create a QR code or a universal link. The Yivi app then picks that up by either scanning the QR code (desktop flow) or clicking on the universal link (mobile flow).
-
-Next, there are two possibilities: the frontend either enables device pairing, or not. Pairing is only used in the desktop flow, i.e. when the frontend displays a QR code for the Yivi app to scan (and even then not necessarily in all cases; it can be disabled by the frontend). If device pairing is enabled, then after the Yivi app connects to the server (using the information in the QR code or the universal link) but before the Yivi app receives the session request, the user must enter a random 4-digit pairing code in the frontend, as protection against shoulder surfing (QR code stealing).
-
-## Retrieving the session request
-
-### `GET /irma/session/{clientToken}`
-
-After the Yivi app scans the QR code or the user taps on the universal link displayed by the frontend, containing a token identifying the session that we will denote with `clientToken`, the app performs a GET request to `/irma/session/{clientToken}`. It sends along the minimum and maximum versions of the IRMA protocol that it supports. For example:
-
-```
-GET /irma/session/6xyh0D2CdLsloWljYFH1/ HTTP/1.1
-X-Irma-Minprotocolversion: 2.4
-X-Irma-Maxprotocolversion: 2.8
-```
-
-The server responds with an [`irma.ClientSessionRequest` instance](https://pkg.go.dev/github.com/privacybydesign/irmago#ClientSessionRequest), containing the protocol version that it chooses (the highest protocol version supported by both itself and by the app), the pairing code if device pairing is enabled, or the session request if not. For example:
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/client/v1",
- "protocolVersion": "2.8",
- "options": {
- "@context": "https://irma.app/ld/options/v1",
- "pairingMethod": "pin",
- "pairingCode": "1761"
- }
-}
-```
-
-```json
-{
- "@context": "https://irma.app/ld/request/client/v1",
- "protocolVersion": "2.8",
- "options": {
- "@context": "https://irma.app/ld/options/v1",
- "pairingMethod": "none"
- },
- "request": {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "context": "AQ==",
- "nonce": "Il2FiK8uCIApjzkWeRouSQ==",
- "protocolVersion": "2.8",
- "devMode": true,
- "disclose": [
- [
- [
- "pbdf.pbdf.irmatube.type"
- ]
- ]
- ]
- }
-}
-```
-
-
-If device pairing is disabled, then the session state is set to [`CONNECTED`](https://pkg.go.dev/github.com/privacybydesign/irmago#ServerStatusConnected). Otherwise the session state is set to [`PAIRING`](https://pkg.go.dev/github.com/privacybydesign/irmago#ServerStatusPairing). In that case the Yivi app shows the `pairingCode` in the response above in its GUI, and instructs the user to type that into the frontend. It uses [`/irma/session/{clientToken}/statusevents`](api-irma-server.md#get-irma-session-clienttoken-statusevents) or polls to [`/irma/session/{clientToken}/status`](api-irma-server.md#get-irma-session-clienttoken-status) to keep track of the session status. After the user enters the pairing code into the frontend, the frontend invokes the [`POST /irma/session/{clientToken}/frontend/pairingcompleted` endpoint](api-irma-server.md#post-irma-session-clienttoken-frontend-pairingcompleted), triggering the IRMA server to switch the session status to `CONNECTED`. When that happens the Yivi app notices through a server-sent event or through its polling, after which it invokes the below endpoint to retrieve the session request.
-
-### `GET /irma/session/{clientToken}/request`
-
-This endpoint is only used to retrieve the session request when device pairing is enabled (if not, this endpoint is not invoked since the session request is included in the response to the previous HTTP request, see above). The server responds with the session request, for example:
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "nonce": "Il2FiK8uCIApjzkWeRouSQ==",
- "context": "AQ==",
- "protocolVersion": "2.8",
- "devMode": true,
- "disclose": [
- [
- [
- "pbdf.pbdf.irmatube.type"
- ]
- ]
- ]
-}
-```
-
-This is the session request that was passed by the requestor to the IRMA server [when the session was started](#session-creation), with the following additions:
-
-* `nonce` (standing for a *n*umber that is used *once*): this base64-encoded number serves as the challenge in the IRMA protocol, which is a challenge-response protocol: the Yivi app's [response](#sending-the-session-response) must take this number into account in a specific way. That is, this number guarantees liveness of the prover (the app) and prevents against replay attacks. It is randomly chosen by the IRMA server and unique per session.
-* `context`: always contains a base64 encoding of the number 1; this is not currently used in IRMA.
-* `protocolVersion`: the protocol version chosen by the IRMA server (see above).
-* `devMode`: `true` when [production mode](irma-server.md#production-mode) is *not* enabled in the IRMA server, false otherwise. (If this is `true`, then the Yivi app will accept the session request only if [developer mode](yivi-app.md#developer-mode) is enabled in it).
-
-## Sending the session response
-
-After receiving the session request, the following happens.
-
-* The Yivi app compares the requested attributes (if any) in the session request against its store to decide if it currently has them in possession, and computes a list of options containing attributes for the user to choose from that will satisfy the requestor, according to the session request.
-* The app presents those options as well as information about the requestor to the user, asking her to either choose from the options and proceed with the session, or to abort.
-* If the user decides to proceed with the session, then based on the user's choices of attributes to be disclosed the Yivi app computes the appropriate response to the IRMA server, in conjunction with the keyshare server using the [keyshare protocol](keyshare-protocol.md). If instead the user decides to abort, or if any error occurs, then the Yivi app cancels the session (see [below](#cancelling-delete-irma-session-clienttoken)).
-
-In the remainder of this section, we assume that so far no error occurred and the user chooses to proceed. In that case, after constructing the response to the IRMA server as mentioned above one of the following three endpoints is invoked, depending on the session type.
-
-### Disclosure: `POST /irma/session/{clientToken}/proofs`
-
-The app POSTs an [`irma.Disclosure` instance](https://pkg.go.dev/github.com/privacybydesign/irmago#Disclosure), for example:
-
-```json
-{
- "proofs": [
- {
- "c": "Hg+cpDeB85nH0hZFmQ2AzLIv+CxVi6mPR2LeDZ+7XVU=",
- "A": "1Uf2V5PRILh6cjo64wWcwIDm39SqnXAXu+tOwq90GmceiahyG5h1zH5/HMA4vwxZfF+9pkqIX1/7twRU6dI5ct2hqAq6qWWcYrwqFV2PsMLVzIyrdU1xVeo4YOIajJ4DMX5rxrCJjjLb28VNWxWUqieXs/iz8Dn67+nYTxxdv4tQw7B3i45PtrD+sKbZPGjTQP0iBHOp5OOvlWNKDYZhKAYgkx+upjcDMHUSCDZPLUCzVBK7LZRqzsh02QrBRyFmeWKxqHpOKzyN9V1GHnUpXWPehenwGFD+N9/TB7rDfMciAV/BaC6pbPbjYCT0bWaBxe07kKT0O4PSsOHBf643jA==",
- "e_response": "oB02Vcm+NekUq4qA92p45jWj4L/QAIJW2SxnMOSyX6GmhV62KeU5+hQUvAv6hK/Jkw+NqdX0kiwV8DUQFc4d",
- "v_response": "C8NbtoNAwYX/OiYMbVBHcDExpIId2a6k5e/JC2rAbp7qATkHTfOjhvjjdSQNy6CYguW67Zn26lp817EWRNxia6ScAuQjkT+8nxBfFIOG5+qFANiRp2MhNCcbyFFPjQGL9m5fPHAoRkyvAPydwvOwomXuj2zX0LbReuYxlBviwLjikNHeWrPAxzk11NCnSxQd3jo+cHzKmJd24RbeOWoyuBRtoXBEV/cKcFbfAd0vamr9n5LYNDK7BXqazBzkP6VeTyzvKFgalW/7mzilYgLAe5htSsHnAQCe7gOP//12iPxQe7NX1aGUmOmTZfQmNv4AxU9tCb3ylPTXPPImYaUiVt8k91+ADvgF/uwf2gLPs3QtsvYqi6njozrRt1ZyIL9dHxf9AQMQiWDBGXkw2rbywx/UmfZV/TqZmU7j/NFLqlDC7u1UYfzMQFSvy/pamImQ20njTG9bZY8geAGc0mMLhwtSY8GIHaCG7Qmgz/cNWuAszX2w4bG9hZaznBCbOOA/q2UH962Majum4DbJo+12/jY=",
- "a_responses": {
- "0": "X1DnHADwaDTOQGb2SS+bJCebTCRbZserzi5wqu0K8SQI7729hH39YC2y9PK4x6m+6Ep1MTqRDF7ZT8ThSV6Fg2ngqTytVJv9t7mobp3fTnY=",
- "3": "vrmbFFjN2NepjEiDXSwhnb5AC7Y2ZWAluAu2gUUmLD4Re3BG/Jia9WGFWU6SEifmT269BHE8LmsT0/UkGFr+CRPddXPDJUFWaEsoQ2NtNz0=",
- "4": "E4BMmNXOAHNCMEVGLiA9WZ8GkqLRPlWs+3H3uEZ8G/I/6ct1O98OJI0+C7hD3zP6yD1M1qXbWE7DTWo4tt/rXDju6Zdhq+olST8OzLxwU5Q="
- },
- "a_disclosed": {
- "1": "AwAKhwAaAAXZZxdMn4TvQ6F/mVxWb6a7",
- "2": "5MrO6tjC5Q=="
- }
- }
- ],
- "indices": [
- [
- {
- "cred": 0,
- "attr": 2
- }
- ]
- ]
-}
-```
-
-The `proofs` array contains a list of disclosure proofs, i.e. [`gabi.ProofD`](https://pkg.go.dev/github.com/privacybydesign/gabi#ProofD) instances, for each credential out of which attributes are being disclosed (present in the `a_disclosed` map, see below). The remainder of the fields within the `gabi.ProofD` are [zero-knowledge proofs](zkp.md) of the hidden attributes (`a_responses`) and of the issuer signature over the attributes of this credential.
-
-The `indices` double array informs the IRMA server where it can find the attributes that it requested in the session request within the `proofs` array, schematically as follows: if `indices[i][j]` contains `{"cred": k, "attr": l}`, then the attribute requested in the [inner conjunction](session-requests.md#multiple-credential-types-within-inner-conjunctions) `j` in the outer conjunction `i` can be found in `proofs[k].a_disclosed[l]`.
-
-#### The attributes in `a_disclosed`
-
-The IRMA protocol uses Base64 to encode large integers, as can be seen in the strings in the message above. The disclosed attributes additionally contain an extra bit in the least significant position encoding their presence, which is used to distinguish [absent attributes](session-requests.md#issuance-requests) from attributes containing the empty string as values. Thus, a (non-empty) string found within `a_disclosed` containing a disclosed attribute can be converted to its string value as follows:
-
-* Base64-decode the string,
-* Bit-shift the resulting bytes one position to the right,
-* Parse the resulting bytes as a UTF-8 string.
-
-For example, taking attribute `2` from `a_disclosed` in the message above, the following [Go snippet](https://play.golang.org/p/GTWeM_uHr98) outputs `regular`.
-
-```go
-bts, _ := base64.StdEncoding.DecodeString("5MrO6tjC5Q==")
-i := new(big.Int).SetBytes(bts)
-i.Rsh(i, 1)
-fmt.Println(string(i.Bytes()))
-```
-
-Note that attribute `1` is the [metadata attribute](overview.md#the-metadata-attribute), containing among others the credential type and the expiry date of the credential in a custom encoding. This attribute is always disclosed. The above snippet will not output anything sensible for metadata attributes, but instead the [`irma` command line tool](irma-cli.md) can be used as follows.
-
-```text
-$ irma meta "AwAKhwAaAAXZZxdMn4TvQ6F/mVxWb6a7"
-Identifier : pbdf.pbdf.irmatube
-Signed : 2021-08-26 02:00:00 +0200 CEST
-Expires : 2022-02-24 01:00:00 +0100 CET
-IsValid : true
-Version : 3
-KeyCounter : 5
-KeyExpires : 2021-09-23 11:43:09 +0200 CEST
-KeyModulusBitlen: 2048
-```
-
-### Attribute-based signatures: `POST /irma/session/{clientToken}/proofs`
-
-The app POSTs an [`irma.SignedMessage` instance](https://pkg.go.dev/github.com/privacybydesign/irmago#SignedMessage), for example:
-
-```json
-{
- "@context": "https://irma.app/ld/signature/v2",
- "signature": [
- {
- "c": "fxMY3mOBnyuh+snmkvpza7R8yoNhXk5WWWDAddxpmwM=",
- "A": "pU8O3BUrdgAZ5+Xekea+++MJSsZKkqdHRJOv11Nog5BmKnFpbV388ZMaSFOj1BsFT6vA3O7sWNMfxgWrgWYDONdIrd9zLt+GbT4kcqDvp/ual2u9JqAOkt6xHoG2kDX9VLLBRxsPzgeyic/NReqXotQ7qcSppf/9NGe6u+BJnmEWPALIdSfv+dwycfrWf3qAblMmwwYKodUBLwRd0nvR1NXsq5omieM9QRf12rXyZHJ4/jxDL7YKXk3CbKQxqZP84Q8MWoL3BnaVvL+XcAdZcxh4ayZSNBfOF2ovZQhNtWmIueLMf2MrVVF6V8Z4j+WBHEE0bTJLXfSsWzi1ex89Ww==",
- "e_response": "CtS3r/LSInVqRzb7fbF9g/TozXmPHzoPbR2O/Hap2sWJlIC2qxaDwGkiJuCxw/nhLrV7u9Qy8b4jpd70xwno",
- "v_response": "AUMG/sw2Dx34g2eYrm15+/lgubKoQR0tHctZIfOHs2IT+9n7lmXW/kA57f5O43LxG14yo6G7vSdqwW5QRsCfix/nbl2El0C31sFb5ZyKVcHsFDB4derCQYaAqr6lbSUS6mjHSl5p8JMMoGErF/B0f+9dNrbZlWXbdzckdZUruWEbnoSvXvt8v6oXmHCE7ngHrxa+0ft/Fs6phvgYbAA/ABXwxuSjsm2U0FUMdfpKwhwClOFWZzgX5HLV4rNq/Z6j9DYd6NEKnwSavLB0h8F1gibV2IyxdTFWM7B62Izq8W2NvJkvNE7Z+CaeAFyyHGmA12rSfPfPqspEGd87UJo2ByfZ8DZZsWoe0EYM/LYPnK4BDsaKNiNXc1+42QkZkeL7ZL2p+er7F6CfuhpebEt7gaANiBUJfR0XFMC1IH/eLvx6Y9Sa7h9NvcHFGC1/cHgEOk9SZi4AXpg7W05Tv01IYQg6o+hgjwAI23dEm2TM4CMDyFXsi0XSa/m9DcnZXWrRrz8DLz3XDLO6SlBkKDzOfyw=",
- "a_responses": {
- "0": "09um7BUT1sfj4G8NJfNTxVrxQR5Fxyjb88EWOtICeQAcwMJPeL7HjfjkVuDSsnUbO/a95PMwWo2QOjz3pYx5TwfxksfODhov1SdGQublems=",
- "3": "wXFVVu64epTtUeuwYhkTsStWRoKJKjgo69Y2YBFdWJY2D4oIH3ut0Fprs/p2Mhm+g180Gc0JuiFqVJfMnTUhBbs26ENDGbAZZRVdobu7520=",
- "4": "A8rAICtm6tykmm21SBkOFrjZQt7K2xukuPaoXhYJOtX180p29tzueTipAp/nfDyRwLkWox26QBj0s8AXmOvzU0S4vq5oHSxsHVWvKosMHLM="
- },
- "a_disclosed": {
- "1": "AwAKhwAaAAXZZxdMn4TvQ6F/mVxWb6a7",
- "2": "5MrO6tjC5Q=="
- }
- }
- ],
- "indices": [
- [
- {
- "cred": 0,
- "attr": 2
- }
- ]
- ],
- "nonce": "u9llQevSkYoDEiz/qAtJDQ==",
- "context": "AQ==",
- "message": "The message signed by this signature",
- "timestamp": {
- "Time": 1630063199,
- "ServerUrl": "https://irma.sidn.nl/atumd",
- "Sig": {
- "Alg": "ed25519",
- "Data": "iAyQutB26ZaVLgfXvMa+sjAeXOYclpInq+xIaROdoWG/WqIg6xWQuFwaPvZQ0PQk5C3e0EYNDGsjNTpQejWBCw==",
- "PublicKey": "MKdXxJxEWPRIwNP7SuvP0J/M/NV51VZvqCyO+7eDwJ8="
- }
- }
-}
-```
-
-Here, the fields are as follows:
-
-* `@context` identifies this as an IRMA attribute-based signature.
-* `signature` is the same as [`proofs` in disclosure sessions](#disclosure-post-irma-session-clienttoken-proofs).
-* `indices` is the same as in [disclosure sessions](#disclosure-post-irma-session-clienttoken-proofs).
-* `nonce` and `context` have the same values as in the [session request](#get-irma-session-clienttoken-request). Contrary to the response of disclosure sessions they are included here, so that the signature is completely self-contained: it contains all information necessary to verify its validity.
-* `message` is the message signed by this signature.
-* `timestamp` contains a signed timestamp, which is used during verification of the attribute-based signature to establish that the attributes within it were valid at creation time of the signature.
-
-### Issuance: `POST /irma/session/{clientToken}/commitments`
-
-The app POSTs an [`irma.IssueCommitmentMessage` instance](https://pkg.go.dev/github.com/privacybydesign/irmago#IssueCommitmentMessage), for example:
-
-```json
-{
- "combinedProofs": [
- {
- "U": "LcIn9Bbp2HN0gLPU11fFSWbLlGcUz1SzmsSk0yxY7Qou3RlucUErR/xvBuhUG3kCOhVVuZm2tw/W0OAWc/ivsYZ+XxV/bJURcFjaDt7cyKN7hIG1LYTtUHy343eSSCUBTKshO4cNy+QdL7jwzh5+wXdGUuUvJ4FEg1ktjOt2zaA=",
- "c": "FTgz4JDU+B5C21ieVZ7b+d8DDohXSRDRm311Kv8T9/o=",
- "v_prime_response": "f6kkO0Z85+gjE3av3bEyr7EJgh7yjW39aKtt/oI4m6QyGu95CqLMbHLObz3cPAnGsm/GhL2KnGZiyF89KnHBrSaiCyAjzpaqTK17/SisNdqSI0gTtqMnQLdVlHGQLeBiS00iHRbG943p6kXXiBCNz7RUxDU3uDgVMq58YaragkYHwudd2YANUFe0XuTbkQ0HEdIOyhJA5PRfxcpsXPg2P9MlL1oppqM69PL/Sy3v9mgdc8G/",
- "s_response": "R71lJ6mVIeLb6g2sabiShN2hOHoSirE2b0/DoESEEDntHlOyaLrPIxjuH2DNV8PTYa/NonBvF9Wfpn9zRNnIyrr6C5+0XRjpYPM="
- }
- ],
- "n_2": "kRNuTr7JcrhXvwIfR+EUKQ=="
-}
-```
-
-The `combinedProofs` array contains, for each credential being issued within the session (one in this example), a [zero-knowledge proof](zkp.md) of the Yivi app's secret key (which will become [the first attribute](overview.md#the-secret-key-attribute) of the credential(s) being issued). In addition, in case of [combined disclosure-issuance sessions](session-requests.md#issuance-requests) this array will also contain [`gabi.ProofD`](https://pkg.go.dev/github.com/privacybydesign/gabi#ProofD) instances, like the `proofs` array in [disclosure sessions](irma-protocol.md#disclosure-post-irma-session-clienttoken-proofs).
-
-When responding to this HTTP request (see below) with its signature(s) over the attributes, the IRMA server includes a zero-knowledge proof of its own, proving that it correctly constructed its signatures. The `n_2` field contains the nonce over which the issuer is to construct that zero-knowledge proof (c.f. the `nonce` in the session request, see [above](irma-protocol.md#get-irma-session-clienttoken-request)).
-
-### The IRMA server's response
-
-When receiving data from the Yivi app on any of the above three endpoints, the IRMA server first verifies the proofs contained in them (note that the app sends zero-knowledge proofs for each session type). The Yivi app is a challenge-response protocol, so referring back to the `nonce` in the session request (as [mentioned earlier](irma-protocol.md#get-irma-session-clienttoken-request)) which acts as the challenge, the data that the Yivi app sends to these endpoints must be a valid response to that particular challenge.
-
-The server responds with an [`irma.ServerSessionResponse`](https://pkg.go.dev/github.com/privacybydesign/irmago#ServerSessionResponse) for each of the three above endpoints. For example:
-
-```json
-{
- "proofStatus": "VALID",
- "nextSession": {
- "u": "https://example.com/irma/session/QBeuXS3iWcYY76rdHfP6",
- "irmaqr": "disclosing"
- },
- "sigs": [
- {
- "signature": {
- "A": "QyeTB0DyqPV9563K0bANaQqQ+zshEUfjcc/fB0pGgc4TXVtu+0mTvohePatBNt3G7GJeJEjnjJHW5AvmhpN74PWJiqXxjlrlkAIJ3oKW0BDIT4t1eaicpXeICq2MU441YWR5dxNX5oYB3fNqjGPnXNJA5XuIBnME3hPl1M4EgTc=",
- "e": "EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACBXzy0nbspQi7Bn5leUl",
- "v": "D3D/nmdPqJ0s3f936ZQ6mKm73J/nA2Aoc0whTGXnYLfr1PwpuHCeI5uSZ5P2TI92h6GSKbiWdmRSjYZPq9K4uqITaJp+ojKwNEomgcUrEKb+VK+dPjEzwvSwC5MoyfPhoEjxSsRiOgCX4rqAheAdFYQru481hZz7ljmNrp0NgYb8vjxLE3YGshamhRYBe03aO1ZSuS8I54qrRQqqOsoL5+D/olZYlv9K5RV8ndz2Q8Kp/0GpB3rTo8okohP5Sx1uAKKJg10bv+Z0OolGli3o76bbc5I6",
- "KeyshareP": null
- },
- "proof": {
- "c": "39uLUi9wzUQMFes7y5l7Es/Xm2LBRJdfI0cFz1AdtmA=",
- "e_response": "FmokcMY3fjT7G4qGMZAnkfgofCm/xmnzNLxxulxsOALtTWCePNi9W5yBe7y83DT6KBBaOmvf29OunzjorK9DOnXaSt64DX8hLw8J/pqn+1RfpvKpBwXfILS26FP7iZVGuUmozp26sai0iuL7qiV1QL/eXD0C+6bgUtcWUusBbR0="
- }
- }
- ]
-}
-```
-
-Here the fields are as follows:
-
-* `proofStatus`: an [`irma.ProofStatus`](https://pkg.go.dev/github.com/privacybydesign/irmago#ProofStatus) constant containing whether or not the server successfully validated the proofs that it received from the app. Anything else than `VALID` is considered an error by the app. (The same status is reported to the requestor in the session result, see below.)
-* `nextSession` optionally contains the [session pointer](https://pkg.go.dev/github.com/privacybydesign/irmago#Qr) to the next session in the [session chain](chained-sessions.md). If this field is present, then after processing the current response the app will immediately start the next session using this session pointer.
-* In case of issuance sessions, the `sigs` array contains the issuer's signatures over each of the credentials being issued (if `proofStatus` is `VALID`). For each object within this array, the `signature` object contains the signature itself, and the `proof` is the issuer's proof of correctness of the signature, over the nonce `n_2` mentioned [above](#issuance-post-irma-session-clienttoken-commitments).
-
-After this, the session state is set to [`DONE`](https://pkg.go.dev/github.com/privacybydesign/irmago#ServerStatusDone), and the requestor can retrieve the [session result](https://pkg.go.dev/github.com/privacybydesign/irmago/server#SessionResult) at the [`GET /session/{requestorToken}/result`](api-irma-server.md#get-session-requestortoken-result) or [`GET /session/{requestorToken}/result-jwt`](api-irma-server.md#get-session-requestortoken-result-jwt) endpoints, or using the [`GetSessionResult()` function](https://pkg.go.dev/github.com/privacybydesign/irmago/server/irmaserver#Server.GetSessionResult).
-
-## Cancelling: `DELETE /irma/session/{clientToken}`
-
-If the user decides to cancel the session, or if the Yivi app finds that it does not possess the attributes being requested, or if the app encounters any error during any part of the session, then the the app cancels the session by invoking `DELETE /irma/session/{clientToken}`. The server responds with HTTP status 200 and no response body. The session state is set to [`CANCELLED`](https://pkg.go.dev/github.com/privacybydesign/irmago#ServerStatusCancelled).
-
-## Errors
-
-If the server encounters any error when handling invocations of any of the endpoints documented here, it will set the session state to `CANCELLED`, and instead of responding to the Yivi app with the objects documented above it responds with an [`irma.RemoteError`](https://pkg.go.dev/github.com/privacybydesign/irmago#RemoteError), containing details about the error. For example, when invoking any of the above four endpoints using a `clientToken` that does not refer to an existing session in the `CONNECTED` state, the server responds with the following:
-
-```json
-{
- "status": 400,
- "error": "SESSION_UNKNOWN",
- "description": "Unknown or expired session"
-}
-```
-
-The Yivi app will then inform the user that an error occurred, and in some cases allow the user to report the error to the IRMA team.
diff --git a/website/versioned_docs/version-v0.13.0/irma-server-lib.md b/website/versioned_docs/version-v0.13.0/irma-server-lib.md
deleted file mode 100644
index 2c04423..0000000
--- a/website/versioned_docs/version-v0.13.0/irma-server-lib.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: irma server library
-id: version-v0.13.0-irma-server-lib
-original_id: irma-server-lib
----
-
-
-
-`irmaserver` is a Go library providing a HTTP server that handles IRMA session with the Yivi app, and functions for starting and managing IRMA sessions.
-
-## Installing
-
-```shell
-go get github.com/privacybydesign/irmago
-```
-
-## Configuring
-The server is configured by passing a `server.Configuration` instance to `irmaserver.New()`. For the options and their meaning, see [Godoc](https://godoc.org/github.com/privacybydesign/irmago/server/#Configuration).
-
-## Email
-
-Users are encouraged to provide an email address with the `Email` option in the `server.Configuration` struct, subscribing for notifications about changes in the IRMA software or ecosystem. [More information](email.md).
-
-## Example
-
-```go
-package main
-
-import (
- "github.com/privacybydesign/irmago/server"
- "github.com/privacybydesign/irmago/server/irmaserver"
- "net/http"
- "fmt"
- "encoding/json"
-)
-
-func main() {
- configuration := &server.Configuration{
- // Replace with address that Yivi apps can reach
- URL: "http://localhost:1234/irma",
- }
-
- err := irmaserver.Initialize(configuration)
- if err != nil {
- // ...
- }
-
- http.Handle("/irma/", irmaserver.HandlerFunc())
- http.HandleFunc("/createrequest", createFullnameRequest)
-
- // Start the server
- fmt.Println("Going to listen on :1234")
- err = http.ListenAndServe(":1234", nil)
- if err != nil {
- fmt.Println("Failed to listen on :1234")
- }
-}
-
-func createFullnameRequest(w http.ResponseWriter, r *http.Request) {
- request := `{
- "type": "disclosing",
- "content": [{ "label": "Full name", "attributes": [ "pbdf.nijmegen.personalData.fullname" ]}]
- }`
-
- sessionPointer, token, err := irmaserver.StartSession(request, func (r *server.SessionResult) {
- fmt.Println("Session done, result: ", server.ToJson(r))
- })
- if err != nil {
- // ...
- }
-
- fmt.Println("Created session with token ", token)
-
- // Send session pointer to frontend, which can render it as a QR
- w.Header().Add("Content-Type", "text/json")
-
- jsonSessionPointer, _ := json.Marshal(sessionPointer)
- w.Write(jsonSessionPointer)
-}
-```
-
-## See also
-
-* The Go library [`requestorserver`](https://godoc.org/github.com/privacybydesign/irmago/server/requestorserver) wraps the functions that this library exposes for starting and managing IRMA sessions into HTTP endpoints.
-* The [`irma server`](irma-server.md) command wraps `requestorserver` into an executable.
-* The [client](https://godoc.org/github.com/privacybydesign/irmago/irmaclient) corresponding to this server is implemented by the [IRMA mobile app](yivi-app.md).
diff --git a/website/versioned_docs/version-v0.13.0/irma-server.md b/website/versioned_docs/version-v0.13.0/irma-server.md
deleted file mode 100644
index 950c98e..0000000
--- a/website/versioned_docs/version-v0.13.0/irma-server.md
+++ /dev/null
@@ -1,312 +0,0 @@
----
-title: irma server
-id: version-v0.13.0-irma-server
-original_id: irma-server
----
-
-
-`irma server` is an IRMA server executable (daemon) allowing you to perform IRMA sessions with
-[Yivi apps](yivi-app.md). It handles all IRMA-specific cryptographic details of issuing or verifying IRMA attributes with an Yivi app on behalf of a [requestor](overview.md#participants) (the application wishing to verify or issue attributes). It exposes the following:
- * HTTP endpoints under `/irma`, used by the Yivi app during IRMA sessions
- * a JSON API under `/sessions` for requestors, allowing them to request the server to verify or issue attributes.
-
-`irma server` is a subcommand of the [`irma`](irma-cli.md) command line tool, which additionally contains subcommands to start or perform IRMA sessions, handle [IRMA schemes](schemes.md), and more.
-
-For installation instructions, see [`irma`](irma-cli.md).
-
-## Running the server
-
-Simply run `irma server` to run the server with the default configuration in development mode. Use `irma server -v` for more verbose logging, for example to see the current configuration. Use `irma server -vv` to also log session contents.
-
-Run `irma server --help` to see configuration options. In order to verify your configuration, run `irma server check -v`.
-
-## Starting a session
-Assuming the server runs in the [default configuration](#default-configuration) (in particular [requestor authentication](#requestor-authentication) is disabled (`no_auth` is `true`) and the `irma-demo` [scheme](schemes.md) is installed), issue `irma-demo.MijnOverheid.ageLower` attributes using the [`session`](irma-cli.md) subcommand of the `irma` tool:
-```shell
-irma session --server http://localhost:8088 --issue irma-demo.MijnOverheid.ageLower=yes,yes,yes,no
-```
-Verify the `irma-demo.MijnOverheid.ageLower.over18` attribute:
-```shell
-irma session --server http://localhost:8088 --disclose irma-demo.MijnOverheid.ageLower.over18
-```
-These print QRs in your terminal that you can scan with your [Yivi app](yivi-app.md) to perform the session. For more extensive examples, see [irmajs](irmajs.md).
-
-## Configuring
-Run `irma server -h` to see all configuration options. Each option may be passed as:
- 1. a command line flags (e.g. [`--listen-addr`](#http-server-endpoints))
- 2. a environmental variable (e.g. `IRMASERVER_LISTEN_ADDR`)
- 3. an item in a configuration file (e.g. `"listen_addr"`) (which may be in JSON, TOML or YAML)
-
- with the following rules:
- * Flags supersede environmental variables which supersede configuration file entries.
- * Dashes are used in flags, but underscores are used in environmental variables and configuration file entries.
- * Environmental variables are uppercased and prefixed with `IRMASERVER_`.
- * The [`requestors`](#requestor-authentication) and [`static_sessions`](#static-irma-qrs) options are special: when passed as a flag or environmental variable, they must be passed as a JSON object (for example: `--requestors '{"myapp":{"auth_method":"token","key":"12345"}}'`).
- * When passing a boolean flag [use an `=`](https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax), for example [`--no-auth=false`](#requestor-authentication).
-
-In order to see the configuration that the server uses after having gathered input from these sources, specify `-v` or `-vv` or use the `verbose` option. Use `irma server check -v` (with the same flags, env vars and config files as `irma server`) to check your configuration for correctness before running the server.
-
-For a full configuation example, see [Getting started](getting-started.md#example-configuration-and-irma-session).
-
-In the remainder of this document, when referring to options we write them as configuration file entries, with underscores and without prefix.
-
-### Default configuration
-In the default configuration (run `irma server check -v` to see it) the server is immediately usable. In particular, it
-* uses the [default IRMA schemes](schemes.md#default-schemes-pbdf-and-irma-demo) ([`pbdf`](https://github.com/credentials/pbdf-schememanager) and [`irma-demo`](https://github.com/credentials/irma-demo-schememanager)), downloading them if necessary
-* allows anyone to use the server [without authentication](#requestor-authentication) (the `no_auth` setting is `true`)
-* saves the session state in memory.
-
-If the server is reachable from the internet, you should consider enabling authentication of session requests.
-
-### Configuration files
-A configuration file can be provided using the `config` option (for example: `irma server --config ./irmaserver.json`). When not specified, the server looks for a configuration file called `irmaserver.json` or `irmaserver.toml` or `irmaserver.yaml` in (1) the current path; (2) `/etc/irmaserver/`; (3) `$HOME/irmaserver`, in that order. A configuration file is not required; if none is found at any of these locations the server takes its configuration from just command line flags and environmental variables.
-
-### Production mode
-When running the server in production, you should enable the `production` option. This enables stricter defaults on the configuration options for safety and prints warnings on possibly unsafe configurations. In particular, when `production` is enabled, the default values of some options change as follows (cf. `diff <(irma server -h) <(irma server -h --production)`):
-
-* `url` from `"http://$YOUR_LOCAL_IP:port"` to `""`: in development mode the `url` to which Yivi apps will connect is set by default to your current local IP address; in `production` mode you must configure it yourself.
-* [`no_auth`](#requestor-authentication) from `true` to `false`: you should consider enabling requestor authentication, or explicitly disable this by setting this flag to `true`.
-* [`issue_perms`](#global-permissions) from `[*]` (everything) to `[]` (none).
-* [`no_email`](email.md) from `true` to `false`: in `production` mode, opting out of providing an email address can be done by explicitly setting this flag to `true`.
-
-In addition, when [developer mode is not enabled in the Yivi app](yivi-app.md#developer-mode) (the default setting), the Yivi app wil refuse to perform sessions with IRMA servers not running in `production` mode. Since the majority of the Yivi app users will not have developer mode enabled, this requires IRMA servers facing those users to enable `production` mode.
-
-### Stateless mode
-By default session states are kept in memory. If you want to run several IRMA servers in parallel or if you wish data persistence for sessions, you can use [stateless mode](stateless.md) which is implemented in the IRMA server via a Redis data store.
-
-You can enable the Redis data store in the `irma server` by setting the `store_type` option to `redis` and specifying the `redis_addr` and `redis_pw` options.
-
-### Keys and certificates
-For each configuration option that refers to some kind of key or certificate (for example `jwt_privkey`), there is a corresponding option with the `_file` suffix (for example `jwt_privkey_file`). Keys can be specified either by setting former to a (PEM) string, or setting the the latter to a file containing the (PEM) string.
-
-### HTTP server endpoints
-The HTTP endpoints that this server offers is split into two parts:
-* `/session`: used by the requestor to start sessions, check session status, or get session results.
-* `/irma`: used by the Yivi app during IRMA sessions.
-
-In the default mode, the server starts one HTTP server that offers both, configured with `listen_addr` and `port`. If however the `client_port` and `client_listen_addr` options are provided, then the server starts two separate HTTP servers:
-* `/session` attaches to the address and port provided with `port` and `listen_addr`.
-* `/irma` attaches to the address and port provided with `client_port` and `client_listen_addr`.
-
-The `/irma` endpoints must always be reachable for the Yivi app. Using this double server mode you can restrict access to the `/session` endpoints by e.g. setting `listen_addr` to `127.0.0.1` or to an interface only reachable from an internal network. Restricting access to the `/session` endpoints in this way may make requestor authentication unnecessary.
-
-### Requestor authentication
-The server runs in one of two modes: it either accepts all session requests from anyone that can reach the server, or it accepts only authenticated session requests from authorized requestors. This can be toggled with the `no_auth` boolean option. If the `/session` creation endpoint of your `irma server` is publicly accessible from the internet (i.e. the `client_port` option is used, see [above](#http-server-endpoints)), then you should consider enabling requestor authentication (i.e. turn `no_auth` off), otherwise anyone can use your `irma server`.
-
-The default is `true` (requests are not authenticated) when `production` is disabled and `false` otherwise.
-
-When authentication is enabled (`no_auth` is `false`), requestors that are authorized to use the server must be configured in the `requestor` option in the form of a map, for example:
-
-```json
-{
- "requestors": {
- "myapp": {
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-
-The server supports several authentication methods, one of which must be specified in the `auth_method` field for each requestor. The snippet above demonstrates the recommended and easiest to use authentication method, called `token`. When using this method the requestor must include the `key` as an API token in a HTTP header (for more details see the [API reference](api-irma-server.md#post-session)).
-
-In addition the server supports the following authentication methods:
-* `hmac`: the requestor symmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/), with HMAC-SHA256 (`HS256`) using `key`. The `key` provided should be the Base64 encoding of the actual secret.
-* `publickey`: the requestor asymmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/) with RSA (`RS256`), in this case `key` should be the PEM public key of the requestor.
-
-For each of these modes it is also possible to specify `key_file` instead `key`; in that case the file at `key_file` will be read and used as `key`.
-
-### Static IRMA QRs
-Unlike normal QRs which differ per session (as they contain the session token), the server also supports static QRs which, when scanned by the Yivi app, start preconfigured IRMA sessions. This makes it possible to for example print such a static QR. These preconfigured sessions are configured with the `static_sessions` options, for example:
-```json
-{
- "static_sessions": {
- "mystaticsession": {
- "callbackUrl": "https://example.com/callbackUrl",
- "request": {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "irma-demo.MijnOverheid.ageLower.over18" ]]]
- }
- }
- }
-}
-```
-Thus `static_sessions` must contain a map of which each item must be an [extended session request](session-requests.md#extra-parameters). Including a `callbackUrl` to which the [session result](api-irma-server.md#get-session-token-result) is sent after the session is required (since for these sessions there is no requestor waiting to receive the attributes after the session has finished). If a JWT private key is installed, then the session result is sent as a [JWT](api-irma-server.md#get-session-token-result-jwt).
-
-> If no JWT private key is installed, then the `callbackUrl` should either not be publically reachable, or it should include a secret token (e.g. https://example.com/cX5aTins5kEZpjDpfYcN) and have TLS enabled (which it should anyway as personal data will be POSTed to it). Otherwise there is no way of distinguishing POSTs from your `irma server` from POSTs made by someone else.
-
-Assuming the URL of the `irma server` is `http://example.com`, the session configured above is started when the Yivi app scans a QR with the following contents:
-```json
-{
- "irmaqr": "redirect",
- "u": "http://example.com/irma/session/mystaticsession"
-}
-```
-
-Only static [disclosure or attribute-based signature sessions](what-is-irma.md#session-types) are supported.
-
-### Permissions
-For each of the [three IRMA session types](what-is-irma.md#session-types) (attribute verification; attribute-based signature sessions; and attribute issuance), permission to use specific attributes/credentials can be granted to requestors in the configuration. For example, including permissions in the `myapp` requestor from above:
-```json
-{
- "requestors": {
- "myapp": {
- "disclose_perms": [ "irma-demo.MijnOverheid.ageLower.over18" ],
- "sign_perms": [ "irma-demo.MijnOverheid.ageLower.*" ],
- "issue_perms": [ "irma-demo.MijnOverheid.ageLower" ],
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-This means that `myapp` is authorized to request `irma-demo.MijnOverheid.ageLower.over18` in disclosure session, and any attribute from `irma-demo.MijnOverheid.ageLower` in attribute-based signature sessions. Additionally `myapp` can issue `irma-demo.MijnOverheid.ageLower` instances. In each level wildcards are permitted (`irma-demo.MijnOverheid.ageLower.*`, `irma-demo.MijnOverheid.*`, `irma-demo.*`, `*`). Thus `"disclose_perms": [ "*" ]` allows the requestor to verify any attribute.
-
-### Global permissions
-
-Global permissions can be applied to all requestors by using the global `disclose_perms`, `sign_perms` and `issue_perms` options. For each requestor, the effective set of permissions is the union of the permissions specified in its `requestors` map and the global permission set.
-
-The global options also work when `no_auth` is enabled. Thus in this case a session type can be disabled by granting no one the permission, e.g., `issue_perms: []` would disable issuance.
-
-In development mode, when `production` is `false`, the defaults for `disclose_perms`, `sign_perms` and `issue_perms` are `["*"]`. In order to protect any IRMA private keys that the server has access to from unintended use by others, when `production` is true the default of `issue_perms` is `[]`: no one can issue unless the global `issue_perms` is modified or unless specific requestors receive nonempty `issue_perms`.
-
-### Client return urls
-
-In session requests, the server can be asked to pass a [client return url](session-requests.md#client-return-url) to the Yivi app, which the app will open after completing the session for sessions that involve only one device. This feature is always enabled.
-
-### Session lifetime
-
-When a session is [started by the requestor](#starting-a-session), users have a limited amount of time to perform the session in their Yivi app. These lifetime constraints can be configured.
-
-By default, users have the maximum session lifetime to start the session in their Yivi app after it is started on the server. By default, this is set to 15 minutes. This global setting holds for all sessions on this server and can be changed in the configuration (see below). Per session, a custom timeout value can be chosen using the `timeout` option in the [extended session request](session-requests.md#extra-parameters).
-
-After a session is started by the user in the Yivi app, it has another full period of the maximum session lifetime to complete the session in their app. As mentioned above, this is 15 minutes by default. This part of the session lifetime is not affected by the `timeout` setting of the extended session request. The maximum session lifetime can be configured using the global `max_session_lifetime` option in the server configuration.
-
-When the user completes the session, the requestor has a limited amount of time to retrieve the session result from the server. By default, the lifetime of the session result on the server is 5 minutes. The session result lifetime can be configured using the global `session_result_lifetime` option in the server configuration.
-
-More information on how to configure global options for your server can be found [above](#configuring).
-
-### Augmented client return urls
-
-The server can be configured to [augment the client return url](session-requests.md#augmenting-the-client-return-url) when requested. In order to enable this feature, the `augment_client_return_url` setting needs to be set to `true`.
-
-### Static file hosting
-
-Apart from hosting endpoints under [`/session` and `/irma`](irma-server.md#http-server-endpoints), the server also supports statically hosting all files from a certain directory. This can be useful [for experimenting](getting-started.md#perform-browser-irma-session). It can be configured with the following options:
-
-* `static_path`: Host files under this path as static files. Leave empty to disable static file hosting.
-* `static_prefix`: Host static files under this URL prefix (default: no prefix)
-
-### IRMA schemes
-
-The server uses [IRMA schemes](schemes.md) to retrieve issuer, credential and attribute names, as well as public and private keys with which attributes can be verified an issued, respectively. By default the server uses the [`pbdf` and `irma-demo` schemes](schemes.md#default-schemes-pbdf-and-irma-demo). This can be configured with the following options:
-
-* `schemes_path`: path containing IRMA schemes (often called `irma_configuration`). Default: `C:\Users\Username\AppData\Local\irma\irma_configuration` on Windows, `$HOME/.local/share/irma/irma_configuration` otherwise. Created if it does not exist. If empty, the default schemes [`pbdf` and `irma-demo`](schemes.md#default-schemes-pbdf-and-irma-demo) are downloaded into it.
-* `schemes_assets_path`: path containing initial, read-only IRMA schemes. If specified, the schemes found here are copied into the path specified by `schemes_path`. Can be used to avoid downloading default schemes on first run.
-* `schemes_update`: update IRMA schemes from their scheme URL every this many minutes. Default is `60`. Set to `0` to disable automatic scheme updating (not recommended).
-
-### IRMA issuer private keys
-
-If IRMA issuer private keys are included in the server configuration, then the server can issue all credential types of all issuers for which private keys are installed. IRMA issuer private keys can be configured in the following two ways:
-
-* Include the private keys within the [IRMA scheme](schemes.md) in the issuer's `PrivateKeys` folder, with filenames `0.xml`, `1.xml`, etc ([example](https://github.com/privacybydesign/irma-demo-schememanager/tree/master/MijnOverheid/PrivateKeys)).
-* Set the `privkeys` option to a folder containing IRMA issuer private keys called `scheme.issuer.xml` or `scheme.issuer.counter.xml` (for example, `irma-demo.MijnOverheid.xml` or `irma-demo.MijnOverheid.2.xml`).
-
-If issuance is enabled in production and private keys are configured, then you should ensure that only authenticated requestors can start issuance requests (otherwise if anyone can use your server to issue attributes then those attributes cannot be trusted or used). You should either:
-
-* disable `no_auth` and [send authenticated session requests](irma-server.md#requestor-authentication),
-* Restrict the [`/session` HTTP endpoints](#http-server-endpoints) to a internal network interface only accessible by your applications and not from outside.
-
-Taking neither approach is an unsafe configuration as in that case anyone can create issuance sessions. In this case, if `production` mode is enabled then the server will refuse to run.
-
-### Signed JWT session results
-
-If a `jwt_privkey` (or `jwt_privkey_file`) is given, then the following endpoints are enabled:
-
-* `GET /session/{sessiontoken}/result-jwt`: returns the session result signed by the `irma server` into a JWT.
-* `GET /session/{sessiontoken}/getproof`: returns a JWT similar to the one from `result-jwt`, but with the same structure as the IRMA API server session result JWTs.
-* `GET /publickey`: returns the public key with which the JWTs output by this server can be verified.
-
-This can be useful if the session result travels along an unsafe or untrusted route from the IRMA server to the requestor. As long as the `irma server` is trusted and its public key is known, the JWT can be verified to ensure that the session result was untampered with since it left the `irma server`.
-
-### TLS
-
-The [IRMA protocol](irma-protocol.md) relies on TLS for encryption of the attributes as they travel along the internet. If your server is connected to the internet and it handles actual attributes (personal data from people), then you ***must*** ensure that the attributes are protected in transit with TLS. In its default configuration (i.e. with [developer mode](yivi-app.md#developer-mode) disabled), the Yivi app will refuse to connect to servers not using TLS.
-
-You can enable TLS in the `irma server` with the `tls_cert` and `tls_privkey` options (or the `_file` equivalents), specifying a PEM certificate (chain) and PEM private key. If you use [separate requestor and app endpoints](#http-server-endpoints), additionally use `client_tls_cert` and `client_tls_privkey`.
-
-Alternatively, if your IRMA server is connected to the internet through a reverse proxy then your reverse proxy probably handles TLS for you.
-
-### Email
-
-Users of the server are encouraged to provide an email address with the `email` option, subscribing for notifications about changes in the IRMA software or ecosystem. [More information](email.md). In `production` mode, it is required to either provide an email address or to explicitly out with the `no_email` option.
-
-### Logging and verbosity
-
-The server's verbosity can be increased by two degrees:
-* `-v` flag is given, or `verbosity` option set to `1`: includes `DEBUG` messages. Logs server configuration when starting the server, stack traces of errors, and more.
-* `-vv` flag is given, or `verbosity` option set to `2`: includes `TRACE` messages. Additionally includes dumps of all HTTP traffic from and to the server.
-
-> in its default mode, the server will not log untrusted user input and attribute values (personal data). If the verbosity is increased, sensitive or dangerous content may be logged. You should avoid doing this in production.
-
-The output is [structured](https://github.com/sirupsen/logrus#fields), putting certain recurring values in fields:
-```text
-[2019-02-28T20:51:09+01:00] INFO Session started action=disclosing session=WdypvSs97JTotpfl1Dtd
-```
-Outputting JSON is enabled with the `log-json` option:
-```json
-{"action":"disclosing","level":"info","msg":"Session started","session":"WdypvSs97JTotpfl1Dtd","time":"2019-02-28T20:51:09+01:00"}
-```
-
-## Running as daemon
-
-On most Linux systems, the `irma server` can be made into an automatically started daemon as follows:
-
-1. Write a new systemd unit file to `/etc/systemd/system/irmaserver.service`:
- ```ini
- [Unit]
- Description=IRMA server
- Documentation=https://irma.app/docs/irma-server
- Requires=network.target
-
- [Service]
- Type=simple
- ExecStart=/usr/local/bin/irma server --config=/etc/irmaserver/config.json
- TimeoutStopSec=60
- Restart=always
- RestartSec=1
- StandardOutput=syslog
- StandardError=syslog
- SyslogIdentifier=irma
- User=irmaserver
- Group=irmaserver
-
- [Install]
- WantedBy=multi-user.target
- ```
- Modify the path to `irma` and [your configuration file (or flags or environmental variables)](#configuring) in `ExecStart` as needed, as well as `User` and `Group`.
-2. Start the daemon and schedule it for automatic start on boot by running `systemctl start irmaserver.service && systemctl enable irmaserver.service`.
-
-See `systemctl status irmaserver.service` for the status of the daemon, and `journalctl -u irmaserver.service` for the console output of the IRMA server.
-
-## Design goals
-
-The server was designed with the following goals in mind.
-- Developer and user friendliness
- - Each of the [configuration options](#configuring) can be specified in a configuration file, command line flag, or environmental vars (see `-h`)
- - Default configuration (demo mode) is immediately useful
- - Thorough and configurable logging (`-v`, `-vv`; by default logs exclude attribute values)
- - Partial backwards compatibility with predecessor [`irma_api_server`](https://github.com/privacybydesign/irma_api_server)
- - Small startup time
-- Also available as [Go library](irma-server-lib.md) instead of standalone server
- - Bindings to other programming languages (Python, Ruby) are expected
-
-Being written in [Go](https://golang.org/), this server (in fact, the containing [`irma` binary](irma-cli.md)) additionally automatically has the following properties.
-- Simple to install (one binary, no dependencies, cross platform) and/or compile
-- [Reproducible builds](https://www.gnu.org/software/mes/manual/html_node/Reproducible-Builds.html)
-- [API documentation](https://godoc.org/github.com/privacybydesign/irmago) (generated automatically from `master` branch)
-
-Referring to Go packages (i.e. folders) under [`irmago`](https://github.com/privacybydesign/irmago), the server is structured as follows.
-* [`server/irmaserver`](irma-server-lib.md): Go library implementing the HTTP endpoints for the [IRMA protocol](irma-protocol.md) (in which the Yivi app is the client), and a Go API for requestors to manage sessons. ([Godoc API documentation](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver))
-* `server/requestorserver`: Go library wrapping `server/irmaserver`, exposing the requestor API as a second HTTP endpoint set under `/session` URLs instead of as Go functions (next to `/irma` for the Yivi app endpoints). ([Godoc API documentation](https://godoc.org/github.com/privacybydesign/irmago/server/requestorserver))
-* `irma`: executuable whose `server` commands wraps `server/requestorserver`.
diff --git a/website/versioned_docs/version-v0.13.0/irmajs.md b/website/versioned_docs/version-v0.13.0/irmajs.md
deleted file mode 100644
index 7115197..0000000
--- a/website/versioned_docs/version-v0.13.0/irmajs.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-title: irmajs JavaScript library
-id: version-v0.13.0-irmajs
-original_id: irmajs
----
-
-> This concerns documentation of a deprecated library. Please use [`irma-frontend`](irma-frontend.md) instead. If you are looking for a library to manage your `irma server` using Node.js, you can use the JavaScript packages from [`irma-backend`](irma-backend.md).
-
-`irmajs` is a Javascript client of the RESTful JSON API offered by the [`irma server`](https://github.com/privacybydesign/irmago/tree/master/irma). It allows you to use the `irma server` to:
-
- * Verify IRMA attributes. You specify which attributes, the library handles the user interaction and the communication with the `irma server` and the [Yivi app](yivi-app.md)).
- * Issue IRMA attributes.
- * Perform IRMA attribute-based signature sessions, resulting in a signature on a string to which IRMA attributes are verifiably attached.
-
-`irmajs` supports all major browsers (Firefox, Chrome, Safari, Edge, Internet Explorer 11).
-
-## Installation
-
-### Compiling from source
-Compile the library:
-
- git clone https://github.com/privacybydesign/irmajs.git
- cd irmajs
- npm install
- npm run build
-
-This writes `irma.js` to the `dist` folder, which you can include in your website in a ``) you can start an IRMA disclosure session as follows:
-
-```js
-const request = {
- '@context': 'https://irma.app/ld/request/disclosure/v2',
- 'disclose': [[[ 'irma-demo.MijnOverheid.ageLower.over18' ]]]
-};
-
-irma.startSession(server, request)
- .then(({ sessionPtr, token }) => irma.handleSession(sessionPtr, {server, token}))
- .then(result => console.log('Done', result));
-```
-
-This assumes you have an [`irma server`](irma-server.md) that is configured to [accept unauthenticated session requests](irma-server.md#requestor-authentication) listening at the URL indicated by `server`.
-
-For complete examples, see the `examples` folder. You can host these examples using the IRMA server, with:
-
- irma server -v --static-path examples/browser
-
-> If your `irma server` is publically reachable, having a setup like the one above allows anyone on the internet to start IRMA sessions at your `irma server`. Additionally, starting IRMA sessions from the browser is generally an antipattern. You should enable either [requestor authentication](irma-server.md#requestor-authentication) or [restrict access to the IRMA session creation endpoints](irma-server.md#http-server-endpoints).
-
-A more realistic configuration for this case may be found in the [Getting started](getting-started.md#example-configuration-and-irma-session) page.
diff --git a/website/versioned_docs/version-v0.13.0/issuer.md b/website/versioned_docs/version-v0.13.0/issuer.md
deleted file mode 100644
index 57e3cdd..0000000
--- a/website/versioned_docs/version-v0.13.0/issuer.md
+++ /dev/null
@@ -1,111 +0,0 @@
----
-title: Issuer guide
-id: version-v0.13.0-issuer
-original_id: issuer
----
-
-Being an IRMA issuer allows you to issue credentials containing attributes to Yivi app users, which they can then disclose to yourself or to others. Contrary to verifying IRMA attributes from the [Yivi app](yivi-app.md) which can be done by anyone running an [IRMA server](irma-server.md), issuing to Yivi apps cannot be done without involvement the developers of IRMA ([the Privacy by Design Foundation](https://privacybydesign.foundation) and [SIDN](https://sidn.nl/irma)): registering your organization and the credentials you will be issuing is required. As part of this registration process the identity of your organization is verified, and the contents and structure of the credentials that you will be issuing is finetuned for correctness and consistency with the rest of the IRMA ecosystem. This process includes signing a contract that among others requires you to properly protect your IRMA private key, as well as paying a yearly fee.
-
-This page documents some of the processes involved.
-
-## Becoming an issuer
-
-In IRMA, information on all issuers, their credentials and the contained attributes is stored in datastructures called [IRMA schemes](schemes.md). The two standard IRMA schemes, `irma-demo` and `pbdf`, meant for demo and production respectively, are maintained by [the Privacy by Design Foundation](https://privacybydesign.foundation) and [SIDN](https://sidn.nl/irma). All Yivi apps and servers contain a copy of these two schemes, which they automatically periodically update. A party wishing to become an issuer must therefore be included in these schemes.
-
-Generally, the process of becoming an IRMA issuer looks as follows. These steps are documented in detail in the sections below.
-
-1. Collect all relevant information on your issuer, its credentials and the contained attributes, and submit that as a pull request (PR) to the [`irma-demo` scheme](https://github.com/privacybydesign/irma-demo-schememanager). (We can help creating the PR based on the relevant information, if required.) Once that is merged, it becomes automatically available for your IRMA server and for Yivi apps. Then you can start issuing the new credentials in your application during development and in demos, using the [IRMA server](irma-server.md). In this phase, you can finetune your credential structure and your issuance application.
-2. When your credential structure has become finalized and you are ready to move to production, [contact us](/about). Once you are verified as the valid issuer of the credentials and the issuer contract has been signed, your issuer information from the `irma-demo` scheme can be copied over to the production scheme, `pbdf` using another PR. At this point you will need to generate your IRMA issuer private/public keypair (more on that [below](#generating-irma-issuer-keys)), and include the public key in the PR. Once your issuer information is included in the `pbdf` scheme, you can start issuing credentials.
-
-> Credentials within the `irma-demo` scheme are not meant for production application and actual personal data, since attributes within this scheme cannot be trusted: all private keys of all issuers under the `irma-demo` scheme are included in it, so that anyone can issue any `irma-demo` credential containing any attribute values.
-
-### Creating an `irma-demo` issuer and credentials
-
-Within the scheme, all issuer and credential information is contained in a folder that schematically looks like the following.
-
-```text
-issuer-id
-├── Issues
-│ └── credentialtype-id
-│ ├── description.xml
-│ └── logo.png
-├── PublicKeys
-│ ├── 0.xml
-| └── 1.xml
-├── PrivateKeys
-│ ├── 0.xml
-│ └── 1.xml
-├── description.xml
-└── logo.png
-```
-
-To get started, it is easiest to use an existing folder of another issuer in `irma-demo` as base by duplicating it, and modifying its contents. In order to check correctness of your modifications, you can try to sign the scheme by running `irma scheme sign` in your `irma-demo` checkout, which will point out common mistakes. For more details about the contents of schemes, see the [IRMA schemes](schemes.md) page.
-
-Some notes about the `irma-demo` scheme:
-
-* The contents of the `` tags in the `description.xml` of both the issuer and all of its credential types must start with `Demo ` for all translations, to distinguish them from production (`pbdf`) credentials in the Yivi app.
-* Using the IRMA logo as `logo.png` for the issuer and credential type is fine.
-* For the private and public keypair, since no trust is associated to anything within `irma-demo`, using those of another issuer in `irma-demo` is fine (but generating a new keypair is fine too; see [below](#generating-irma-issuer-keys)).
-
-Once your modifcations are complete, ensure the scheme is validly signed by running `irma scheme sign` in your irma-demo checkout, and submit your changes as a [PR](https://github.com/privacybydesign/irma-demo-schememanager/compare). Once the PR is merged, your demo issuer and its credentials become available for issuance to your IRMA server when it updates its copy of the scheme: periodically (hourly by default), or when you restart your server.
-
-You can then use your IRMA server to issue the new credentials to your Yivi app. Alternatively, after the `irma-demo` PR is merged, the new credentials can also be issued from their corresponding pages in the [attribute index](https://privacybydesign.foundation/attribute-index/en/) (only in the case of `irma-demo` credentials).
-
-#### Using a locally modified `irma-demo` scheme
-
-Instead of submitting a PR to the `irma-demo` scheme to us, it is also possible to modify a local copy of the `irma-demo` scheme, and embed that local copy in the IRMA server and a manually compiled Yivi app, as follows.
-
-1. Create your modifications in `irma-demo`.
-2. Ensure the scheme is validly signed by running `irma scheme sign` in your `irma-demo` checkout.
-3. When starting your [IRMA server](irma-server.md#irma-schemes), point it to the folder containing your `irma-demo` checkout and disable scheme updating:
- ```sh
- irma server --schemes-path ... --schemes-update 0
- ```
-4. Create a checkout of [`irmamobile`](https://github.com/privacybydesign/irmamobile/), the Yivi app source code; replace the `irma-demo` copy in `irmamobile/irma_configuration/irma-demo` with your modified copy; and compile the Yivi app using the instructions in its README.
-
-If you use the IRMA server from step 3 to issue your credentials, then the Yivi app from step 4 will accept them. Note, however, that the standard App/Play Store versions of the Yivi app will not.
-
-### Creating a `pbdf` issuer and credentials
-
-After the development phase of your issuance application is finished and the issuer contract has been signed, your issuer and credentials can be moved to production as follows.
-
-1. Copy your issuer and its credentials from `irma-demo` to a local checkout of the production scheme, [`pbdf`](https://github.com/privacybydesign/pbdf-schememanager).
-2. Change all occurences of `irma-demo` within your issuer and credentials to `pbdf`; ensure the `Demo ` prefix is everywhere removed; and use actual logos for your issuer and credentials.
-3. [Generate](#generating-irma-issuer-keys) a new 2048 bit IRMA issuer private/public keypair; put the public key within your issuer folder in `PublicKeys/0.xml`; and keep your private key private.
-4. Submit your changes to `pbdf` as a PR.
-
-Your PR will then be signed by us, and merged. As with `irma-demo`, your issuer and its credentials then become available for issuance to your IRMA server when it updates its copy of the scheme: periodically (hourly by default), or when you restart your server. Your credentials will also automatically appear in the [attribute index](https://privacybydesign.foundation/attribute-index/en/), but in contrast with `irma-demo` credentials, they cannot be issued from there.
-
-### Generating IRMA issuer keys
-
-Generating a new IRMA issuer private/public keypair is done with the [`irma`](irma-cli.md) command line tool:
-
-```sh
-irma issuer keygen
-```
-
-See `irma issuer keygen -h` for the flags that this command accepts. By default, it will emit the private and public keys in directories called `PrivateKeys` and `PublicKeys` under your current directory, creating them if they don't exist.
-
-Some notes:
-
-* When generating a new keypair for the `irma-demo` scheme, the private key is expected to be included in the PR to the `irma-demo` repository, within the `PrivateKeys` folder under your issuer folder. However, when generating a new keypair for the production `pbdf` scheme, you *must* keep your private key private.
-* Your past and current public keys are stored within your issuer folder in the `pbdf` scheme in the `PublicKeys` folder with increasing filenames: `0.xml`, `1.xml`, et cetera. The number in the filename is the counter of your public key. When generating a new public key, you can ensure it gets the correct counter in one of the following ways:
- - By specifying it explicitly using the `-c` or `--counter` flag.
- - By running `irma issuer keygen` within your issuer folder in the scheme; it will then infer the appropriate counter using the public keys already present in the `PublicKeys` folder.
- - Alternatively, after generating the keypair you can open the private and public keys in a text editor and set the `` tag to the appropriate number.
-* If one of your credentials contains more than 10 attributes, then that amount of attributes *increased by 2* (to account for [the secret key and metadata attributes](overview.md#special-attributes)) must be passed to the `-a` or `--numattributes` flag, to ensure that the new public key supports the required amount of attributes.
-
-## Issuer maintenance
-
-Production IRMA issuer keypairs are valid for a year. Once a keypair expires it cannot be used anymore for issuance, so it is important that it is replaced by a fresh keypair before that time. Once a new public key has been included in the `pbdf` scheme, the corresponding private key can be included in your IRMA server configuration. After a restart it will use to the new private key.
-
-Please note that although the old private key cannot be used for new credentials, you MUST still keep this private key private. Someone with access to the private key could otherwise forge credentials with a creation date set to a date in the past when the key was not yet expired.
-
-### Submitting a new production public key
-
-The process for getting a new issuer public key included in the production `pbdf` scheme is as follows.
-
-1. Generate a new keypair as documented above.
-2. Send the public key to the `pbdf` scheme manager, using a [PR](https://github.com/privacybydesign/pbdf-schememanager/compare), email or Slack.
-3. The scheme manager will contact you out-of-band to verify that the public key arrived intactly, by checking its SHA256 hash.
-4. If this check succeeds, your new key will be included in the scheme. You can then install the corresponding private key in your issuing IRMA server.
diff --git a/website/versioned_docs/version-v0.13.0/keyshare-protocol.md b/website/versioned_docs/version-v0.13.0/keyshare-protocol.md
deleted file mode 100644
index 388ba7e..0000000
--- a/website/versioned_docs/version-v0.13.0/keyshare-protocol.md
+++ /dev/null
@@ -1,193 +0,0 @@
----
-title: Keyshare protocol
-id: version-v0.13.0-keyshare-protocol
-original_id: keyshare-protocol
----
-
-
-
-
-This document describes the goals and details of the IRMA keyshare protocol.
-
-## Introduction
-
-The [IRMA mobile app](yivi-app.md) allows users to obtain and disclose [IRMA attributes](overview.md#cryptographic-entities), as well as attach them to signed statements. Before such an IRMA session proceeds, the Yivi app may ask the user to enter her IRMA PIN code so that the [requestor](overview.md#participants) can be sure that it is indeed the attribute owner initiating the session (as opposed to, e.g., a thief of the user's phone). The verification of the correctness of the IRMA PIN code, and preventing the session from happening when it is not, is the responsibility of the [IRMA keyshare server](https://github.com/privacybydesign/irma_keyshare_server). In order to do this, it interacts with the Yivi app and possibly the IRMA server in a protocol that we call the *keyshare protocol*. This protocol is documented here.
-
-Each [IRMA scheme](schemes.md) decides whether or not it employs an IRMA keyshare server. If it does, then this keyshare server is involved in any IRMA session that involves attributes that fall under the scheme manager's responsibility.
-
-Upon app installation, the IRMA user *registers* to the keyshare servers of the installed scheme managers. At this point the user chooses her IRMA PIN code. The app additionally generates an ECDSA keypair, of which the public key is sent to the keyshare server, and the corresponding private key is stored exclusively in the phone's Secure Enclave (SE) or Trusted Execution Environment (TEE). Afterwards, whenever the user performs an IRMA session, the user must first enter her IRMA PIN code, after which her Yivi app signs a challenge provided by the keyshare server using its ECDSA private key. Only if the PIN is correct and the challenge is correctly signed will the keyshare server allow the session to proceed.
-
-### Goals
-
-The keyshare server must:
-- Authenticate a user as being the same person that registered to the keyshare server in the past, just before an IRMA session occurs, using (1) a secret from the phone's SE/TEE and (2) the user's IRMA PIN;
-- Block the IRMA session from happening when this authentication fails,
-- Allow users to remotely block their Yivi app from performing future IRMA session in case of loss or theft of their phone. That is, the user can *revoke* her own attributes.
-- The keyshare server must not learn the values of any of the attributes of any user, and also not to whom the user discloses attributes.
-
-Consequentially, it is insufficient to verify the user's IRMA PIN code locally in the Yivi app, because otherwise a malicious actor could try to bruteforce the PIN of a user and thus gain access to her attributes. Instead we have chosen to modify the cryptography that is used in IRMA sessions in such a way that the keyshare server's contribution to it is necessary for the session to complete, so that the keyshare server can reliably block sessions from happening by refusing to cooperate, if the correct PIN is not entered. Additionally the keyshare server prevents bruteforce attempts on the user's PIN, by rejecting further PIN attempts if the user's PIN is entered incorrectly too many times.
-
-### IRMA secret keys and keyshares
-
-IRMA is an implementation of the Idemix attribute-based credential (ABC) scheme. In such schemes a *credential* is a set of numbers $(k_0, ..., k_n)$ along with a digital signature over this set of numbers, created by the [issuer](https://credentials.github.io/docs/irma.html#participants) using the [issuer's private key](https://credentials.github.io/docs/irma.html#cryptographic-entities). The ABC scheme provides an *attribute disclosure protocol* in which the user can selectively disclose any subset of the attributes $(k_0, ..., k_n)$ to another party (called the *verifier* or *service provider*), in such a way that the verifier is assured of the validity of the issuer's signature over all attributes (including the ones that were not shown).
-
-In IRMA, the first attribute $k_0$ of a credential is always the user's *secret key*. When the user discloses attributes, this secret key is always kept hidden. The *issuance protocol* in which an issuer grants an IRMA credential to a user is such that whenever the user receives a second or third or $n$-th credential, the value of this secret key $k_0$ of the new credential is the same as that of the user's first credential. Consequentially, the first attributes $k_0$ of all credentials of the user have the same value. Then, when the user discloses two attributes that come from two distinct credentials, the user not only proves to the verifier that she owns two valid signatures over the two credentials, but also that the values of the first attributes (i.e. the secret keys) of the two credential coincides. To the verifier, this proves that even though the two attributes come from distinct credentials, they still come from the same Yivi app, and therefore the same user.
-
-Thus each user has her own secret key, namely the integer that serves as the first attribute in each of her credentials. We shall drop the index and call this integer $m$. Recalling that the signed tuple of attributes of a credential is then $(m, k_1, ..., k_n)$, the purpose of the keyshare protocol is to enforce that the tuple of integers that is effectively signed in the issuance protocol is $(m_u + m_k, k_1, ..., k_n)$, where $m_u$ is known to the user and hidden from the keyshare server (along with all other attributes), and $m_k$ is known to the keyshare server and hidden from the user. That is, the user's secret key is *split* into two halves, one of which resides at the keyshare server (hence its name). Consequentially, the cooperation of the keyshare server in IRMA sessions, which necessarily always involve the secret key $m = m_u + m_k$, has become necessary.
-
-### Splitting the secret key across the user and keyshare server
-
-As mentioned, in IRMA the secret key $m$ is always kept hidden from the verifier using [a zero-knowledge proof](zkp.md). Now let $m = m_u + m_k$ with $m_u$ only known to the user, $m_k$ only known to the keyshare server, and $m$ known to neither. We now describe how we can modify the zero-knowledge proof of the secret key in such a way that the user and keyshare server *jointly* prove knowledge of the number $m$, as follows. We refer to the diagram and use the notation of the [page on zero-knowledge proofs](zkp.md).
-
-* After step 2.2, the user asks the keyshare server to generate its own random $w_k$ and compute $W_k = R^{w_k}$. The keyshare server keeps $w_k$ hidden but sends $W_k$ to the user.
-* The user computes the challenge as $c = H(P, WW_k, \eta)$, and then sends $c$ to the keyshare server.
-* The keyshare server computes $s_k = cm_k + w_k$ and sends this number to the user.
-* Instead of sending $(c,s)$ to the verifier in step 2.5, the user sends $(c, s + s_k)$.
-
-The verifier then uses this tuple to verify the proof of knowledge as it normally would. If both the user and the keyshare server follow the protocol, then the verification equation $c = c'$ will hold, so that the verifier will accept. This is effectively a proof of knowledge of the sum $m = m_u + m_k$, in the sense that the messages going back and forth between the user and verifier have exactly the same structure as they would have if they were a proof of knowledge of $m$ - in fact, to the verifier an execution of this modified protocol is completely indistinguishable from a normal one without a keyshare server. Additionally, the protocol has the following properties:
-
-* The keyshare server essentially proves a normal (i.e., non-Fiat-Shamir heuristic) zero-knowledge proof of $m_k$ to the user. Consequentially, the user learns nothing about the number $m_k$.
-* As the user does not know the number $m_k$ and gains no knowledge of it even through multiple session with the keyshare server, she can impossibly prove knowledge of the sum $m = m_u + m_k$ if the keyshare server refuses to cooperate.
-
-For these reasons this protocol is very well suited for our aims of making the keyshare server's contributions necessary in IRMA sessions, while simultaneously keeping the amount of information that the keyshare server learns about the user, her activities and her attributes as little as possible.
-
-## The protocol
-
-We now describe the IRMA keyshare protocol. The version of the keyshare protocol documented here is supported by the keyshare server since `v0.11.0` of `irmago`. The previous version of the protocol, which was largely the same but did not use ECDSA for device binding, is documented [here](/v0.9.0/keyshare-protocol). The [Yivi app](yivi-app.md) always uses the latest keyshare protocol version that it knows of, but the keyshare server is backwards compatible: it understands both protocols.
-
-### Overview
-
-When the Yivi app runs for the first time, it first registers to the keyshare server as follows. It asks the user for the IRMA PIN that she wishes to use in future sessions, and optionally for her email address. Next, it computes the following cryptographic material:
-* An ECDSA keypair inside the phone's SE/TEE, which is later used for challenge-response authentication to the keyshare server.
-* A salt: 32 random bytes. Similar to password authentication, this is later used to send a *hashed salted* PIN, that is `SHA256(salt, PIN)`, to the keyshare server, instead of the PIN directly.
-
-Using its ECDSA private key, it then signs the user's email address (if specified), the ECDSA public key, and the user's hashed salted PIN into a JWT, and sends this JWT to the keyshare server. The keyshare server then generates a random username for the user, which is automatically issued to the user as her first attribute. At this point registration is complete in the sense that the user can now receive and disclose attributes. If the user entered her email address a confirmation link is sent to it, which the user must click on to finalize the registration.
-
-When performing an IRMA session, the user and keyshare server use the protocol described above to compute a proof of knowledge of the sum $m = m_u + m_k$, with an important addition: when sending the response $s_k$, the keyshare server always includes a digital signature over this number. The keyshare server's public key with which these signatures can be verified is known to all IRMA participants through the [IRMA scheme](schemes.md).
-
-Now the IRMA protocol is modified as follows.
-
-* The user authenticates to the keyshare server as follows: (1) the app retrieves a challenge from the keyshare server; (2) the user enters her PIN in the Yivi app; (3) using its ECDSA private key from the SE/TEE, the app signs the challenge, hashed salted PIN, and the user's username into a JWT; (4) it sends this JWT to the keyshere server. The keyshare server checks if the user is known, if the JWT validates against the public key with which she registered, and if the PIN is correct; and aborts if not.
-* When performing a disclosure or attribute-based signing session, the user engages in the protocol described above with the keyshare server to produce a proof of knowledge of the sum $m = m_u + m_k$, and sends this proof to the verifier.
-* When issuing the user does the same, except for computing and sending the sum $s + s_k$ in the final step of the protocol described above. Instead, the user sends $s$ and $s_k$, along with the keyshare server's signature over $s_k$, separately to the issuer. The issuer then checks the signature over $s_k$, and computes the sum $s + s_k$ which it uses for checking the proof of knowledge.
-
-In this way, the issuer enforces that the user uses the help of the keyshare server in the issuance protocol, and that the resulting credential indeed has $m = m_u + m_k$ as its first attribute. Consequentially, the modified disclosure protocol as described in the second item will succeed, and as the keyshare server's contributions are not directly communicated from the keyshare server to the verifier but only to the user, the keyshare server never learns to whom the user is disclosing attributes.
-
-
-### Registration
-
-When registering, the Yivi app signs the following message into a JWT with its ECDSA private key, and sends that to `/client/register` at the keyshare server:
-
-```json
-{
- "email": "example@example.com",
- "language": "en",
- "pin": "0kO3xbCrWMK1336eKzI3KOKWWogGb/oW4xErUd5rwFI=\n",
- "publickey": "User's ECDSA public key, base64-encoded"
-}
-```
-
-The email address is optional and may be absent. The `language` indicates the user's preferred language, used for a confirmation mail if the email address is present. Lastly, the `pin` field is computed as `Base64(SHA256(salt, pin))\n` (the trailing newline is there for legacy purposes and will be removed in the future). Note that since the user is not yet known to the keyshare server, this message is self-signed; to validate it the public key will first need to be extracted from the JWT and parsed.
-
-### Authentication
-
-During an IRMA session, authenticating to the keyshare server during the protocol between the IRMA client and keyshare server is done as follows. First, the app retrieves a challenge from the keyshare server at `POST /users/verify_start`. Next it computes the PIN as `Base64(SHA256(salt, pin))\n`, and using its ECDSA private key it signs the following message into a JWT, and sends that to the keyshare server at `POST /user/verify/pin_challengeresponse`:
-
-a message like the following
-
-```json
-{
- "id": "FVP1kMRcF2s",
- "pin": "0kO3xbCrWMK1336eKzI3KOKWWogGb/oW4xErUd5rwFI=\n",
- "challenge": "the challenge retrieved earlier"
-}
-```
-If the JWT validates against the user's public key and the PIN is correct, then the user has successfully authenticated. The keyshare server then returns an object like the following:
-```json
-{
- "status": "succes",
- "message": ""
-}
-```
-
-Here, `success` indicates to the user that authentication was succesful. The `message` field contains a signed JWT that is used as authentication in the rest of the protocol. This JWT has an expiry of 15 minutes. The contents of this JWT is like the following:
-
-```json
-{
- "iss": "name_of_keyshare_server",
- "sub": "auth_tok",
- "exp": 1523914956,
- "token_id": "a token identifying the user",
- "iat": 1523914056
-}
-```
-
-### The keyshare protocol
-
-At the start of the keyshare protocol, the client needs to inform the keyshare server which IRMA public keys are involved, in the sense that they are necessary to verify the attributes that are being disclosed. An issuer may have multiple public keys, indexed by integers starting at 0, so the string `"irma-demo.IRMATube-1"` refers to the second public key of the `IRMATube` issuer.
-
-The keyshare server's API endpoints are the following.
-
-* `POST /prove/getCommitments`: The client sends a list of public key identifiers (e.g. `["irma-demo.IRMATube-1"]`) to the keyshare server (along with the authentication JWT described above in a HTTP header). If the user is authenticated and the public keys are known to the keyshare server, the keyshare server reacts with a commitment to its part of the secret key, for each of the specified public keys:
-
- ```json
- {
- "c": {
- "irma-demo.IRMATube-1": {
- "P": 121212,
- "Pcommit": 909090,
- }
- }
- }
- ```
- Here `P ` $ = R^{m_k}\mod n$ and `Pcommit ` $=W_k$ is the commitment mentioned above, `Pcommit ` $= W_k = R^{w_k} \mod n$, with $R$ and $n$ coming from the second public key of the `irma-demo.IRMATube` issuer.
-* `POST /prove/getResponse`: after calculating the challenge, the client posts it to the keyshare server, who replies with a signed JWT with the following as content:
-
- ```json
- {
- "iss": "name_of_keyshare_server",
- "sub": "ProofP",
- "ProofP": {
- "P": 121212,
- "c": 343434,
- "s_response": 565656
- },
- "iat": 1523914056
- }
- ```
- `s_response` is the response integer $s_k$ in the Schnorr zero-knowledge proof.
-
-This ends the involvement of the keyshare server in the IRMA session. In case of attribute disclosures or attribute-based signatures, the client next merges the keyshare server's contributions `Pcommit` and `s_response` into its proof of knowledge of the secret key. In case of issuance this is skipped; instead the entire JWT from the final endpoint is sent to the issuer alongside the client's own proof of knowledge of its part of the secret key.
-
-The structure of the message in which the client sends the keyshare server's signed response to the issuance session currently unfortunately supports at most one keyshare server simultaneously. This means that it is impossible for two (or more) issuers falling under two distinct scheme managers that use distinct keyshare servers to both issue credential simultaneously to a client (i.e., within one IRMA session). Although this is an unlikely scenario, this will still be fixed in a future version of the protocol. Although all other issuance or disclosure sessions involving multiple keyshare server simultaneously are theoretically already possible, currently no IRMA client yet supports being registered to more than one keyshare server at once.
-
-### Changing the PIN
-
-When the user wants to change her IRMA PIN, using her ECDSA private key she signs the following message into a JWT, and sends that to `POST /user/change/pin`:
-
-```json
-{
- "id": "FVP1kMRcF2s",
- "oldpin": "0kO3xbCrWMK1336eKzI3KOKWWogGb/oW4xErUd5rwFI=\n",
- "newpin": "IjBrTzN4YkNyV01LMTMzNmVLekkzS09LV1dvZ0diL29=\n"
-}
-```
-
-The keyshare server then looks up the user given the specified `id`, and checks if the `oldpin` is correct. If so it changes the user's PIN to the `newpin`, and responds with the following:
-```json
-{"status": "success"}
-```
-(That is, the same JSON message as `POST /user/verify/pin` but without an authentication JWT).
-
-In addition to these API endpoints, the keyshare server exposes a number of other endpoints that are used by the [MyIRMA webclient](https://github.com/privacybydesign/irma_keyshare_webclient), which allows the IRMA user to manage her registration at the keyshare server. These endpoints are not documented here.
diff --git a/website/versioned_docs/version-v0.13.0/overview.md b/website/versioned_docs/version-v0.13.0/overview.md
deleted file mode 100644
index 49e4857..0000000
--- a/website/versioned_docs/version-v0.13.0/overview.md
+++ /dev/null
@@ -1,184 +0,0 @@
----
-title: Technical overview
-id: version-v0.13.0-overview
-original_id: overview
----
-
-This document presents a technical overview of the IRMA project.
-
-## IRMA terminology
-
-### Participants
-
-* *Yivi app*: (mobile) application that receives attributes, and can disclose them. Also called *client* as it acts as the client in the [IRMA protocol](irma-protocol.md).
-* *Verifier* or *service provider*: a party wanting to verify someone's attributes (in order to provide some service).
-* *Issuer* or *Identity provider*: a party wanting to issue attributes to someone.
-* *Issuer*: uses an Idemix private key in order to issue credentials to a client, when instructed to by an identity provider
-* *Requestor*: the service or identity provider that wants to, respectively, verify someone's attributes or issue attributes to them.
-* *Scheme manager*: distributes Idemix public keys, credential types and issuer information to clients and requestors; also decides which issuers may join its domain and what credential types they may issue.
-
-### Cryptographic entities
-
-* *Attribute*: a small piece of data, generally containing a statement about the attribute owner (e.g., '> 18 years old').
-* *Credential*: a group of attributes, jointly signed by the issuer using an Idemix private key, in an interactive protocol (called the *issuance protocol*) between the issuer and client.
-* *Credential type*: each IRMA credential is an instance of a credential type, which determines the names of the contained attributes, its validity period, and by which issuer the credential is issued.
- * *Singleton credential type*: users can store at most one instance of such credential types in their Yivi app.
-* *Idemix private-public keypair*: a pair of related keys:
- * *Idemix private key*: used by the issuer to sign a credential in the issuance protocol.
- * *Idemix public key*: used by a verifier when attributes are disclosed to it, in order to establish that the disclosed attributes have been signed using the corresponding Idemix private key.
-* *Disclosure proof*: a set of disclosed attributes, along with a proof of knowledge showing that these disclosed attributes originated from a credential that was validly signed by the issuer.
-* [*Attribute-based signature*](#attribute-based-signatures): a digital signature, with IRMA attributes cryptographically attached to it, on some document or message.
-
-### Core software projects
-
-* [IRMA mobile app](yivi-app.md): (mobile) application that receives attributes, and can disclose them.
-* [`irma` command](irma-cli.md): contains an IRMA attribute verification and issuance server, scheme management, and more.
-* [irmajs](irmajs.md): javascript library acting as glue between an IRMA server and the requestor's website, allowing the requestor to instruct an API server to issue or verify attributes.
-
-## Overview
-
-IRMA is at its core a set of software projects implementing the Idemix attribute-based credential scheme. An *attribute* is a statement or property about a person, such as "I am over 18 years old" or "my name is John Doe".
-
-These attributes are grouped together in a *credential*. In attribute-based credential schemes such as Idemix, such a credential can be issued to a user by a trusted party called the *issuer*. This issuer creates a digital signature over the credential and its containing attributes using its *private key*. The user receives the credential as well as the issuer's signature in her [IRMA mobile app](yivi-app.md).
-
-After that, the user can disclose these attributes to other parties, who are called *verifiers*, selectively showing some and hiding the other attributes from the credential. The verifier then receives the disclosed attributes, as well as a *proof of knowledge* which proves to the verifier that the user
-
-* knows the attributes from the credential which are not being disclosed
-* owns a valid issuer signature over the disclosed attributes and hidden attributes.
-
-The verifier can check the validity of this proof of knowledge using the issuer's *public key* that corresponds with the private key with which the issuer signed the attributes (thus, the verifier must know this public key). The verifier can tell from this that the user has at some point received the disclosed attributes from the trusted issuer. Therefore, it can trust the authenticity of the attributes. (This proof of knowledge does *not* include a full copy of the signature over the attributes, so that even if all attributes of the credential were disclosed simultaneously, the verifier can impossibly use the received attributes and proof of knowledge to disclose these attributes itself to others.)
-
-In addition to attribute disclosure, users can also attach their attributes to messages in an *IRMA attribute-based signature*. This is explained in more detail [below](#attribute-based-signatures).
-
-## Credential types
-
-In IRMA, each credential is an instance of a *credential type*. A credential type specifies (among other things) how many attributes its instances have, what their names are, and by which issuer instances of this credential type are issued. Credential types are not shared between issuers: even if two issuers would issue two credential types with the same name and with the same amount of attributes having the same names, they still are distinct credential types. On [Github](https://github.com/privacybydesign/pbdf-schememanager/blob/master/pbdf/Issues/irmatube/description.xml) an example of such a credential type is available, defining the "IRMATube" credential type which is issued and verified in [this IRMA demo](https://privacybydesign.foundation/demo/irmaTube/). Schematically, an instance of such a credential type would look as follows.
-
-| Attribute name | Attribute value |
-| -------------- | --------------- |
-| **type** | member |
-| **id** | 123456 |
-
-In this table, the right column are the attribute values which are stored and signed in the credential. The left column contains the attribute names from the credential type.
-
-### Singletons
-
-A credential type can be marked as a *singleton* by the scheme manager. If so the Yivi app will store at most one instance of this credential type simultaneously, and receiving a new one would overwrite any older instance. (Example: [`pbdf.nijmegen.bsn`](https://privacybydesign.foundation/attribute-index/en/pbdf.nijmegen.bsn.html)) If a credential type is not a singleton (example: [`pbdf.pbdf.diploma`](https://privacybydesign.foundation/attribute-index/en/pbdf.pbdf.diploma.html)), then the user can have any number of instances of that credential type in her Yivi app.
-
-### Special attributes
-
-#### The metadata attribute
-
-In IRMA, each credential always contains a special attribute called the *metadata attribute*, which must always be disclosed whenever other attributes are disclosed from this credential. This metadata attribute contains:
-
-* which credential type this credential is an instance of (from which it follows by which issuer this credential was issued),
-* the date at which this credential was issued,
-* the expiry date of this credential.
-
-In order to lessen linkability issues (see the [security properties](#irma-security-properties) section below), the issuance and expiry dates are always chosen to fall on the boundary of an *epoch*, which is one week.
-
-#### The secret key attribute
-
-The first attribute of any IRMA credential is always a 256-bit integer which is called the user's *secret key*. The user's Yivi app randomly chooses and stores this integer when it is run for the first time. Whenever it receives a new credential, the app ensures that this number is used as the first attribute, so that all credentials that the app manages share this integer as their first attribute. Contrary to the metadata attribute this attribute is never disclosed; it is even kept hidden from the issuer during issuance. When the user discloses attributes that come from multiple credentials, the proof of knowledge that the Yivi app calculates and sends to the verifier proves multiple facts:
-
-* The app knows a valid issuer signature over each credential from which attributes are currently being disclosed,
-* The first attribute from all of these credentials coincide.
-
-From this the verifier can conclude that the credentials from which attributes are being disclosed belong to one and the same person; that is, it defends against users pooling their credentials.
-
-## Schemes
-
-IRMA schemes are documented on the [Schemes](schemes.md) page.
-
-## Issuers
-
-Each IRMA issuer has an Idemix private key, which it must keep secret as it is used when issuing credentials, and a corresponding public key which is distributed to attribute verifiers and Yivi apps in the IRMA scheme. An issuer may issue multiple credential types (and a scheme may contain many issuers).
-
-Issuers cannot independently create credential types and start issuing them to Yivi app users: the credential type must first be included in an [IRMA scheme](schemes.md) by the scheme manager. In case of the default scheme `pbdf` of the Yivi app, this is the [Privacy by Design Foundation](https://privacybydesign.foundation/issuance/).
-
-When verifying IRMA attributes, out of all possible attributes the verifier could ask for, it must decide which attributes suite its purposes best. In order to be able to make this decision, it is important that for each credential type it is clearly documented how the attributes are obtained, and how it is ensured that they indeed belong to the person that receives them. For each credential type in the `pbdf` scheme, this is documented on the [Privacy by Design Foundation website](https://privacybydesign.foundation/issuance/).
-
-## IRMA PIN codes using the keyshare server
-
-When a user's device containing her Yivi app along with her attributes is lost or stolen, the finder of the phone can potentially abuse the owner's attributes. In order to protect against this, scheme managers may decide to employ an *IRMA keyshare server*. In this case, whenever a credential type that falls under the scheme is used, the user must enter her PIN code before the IRMA session can proceed. The correctness of this PIN code is verified by the keyshare server. When an incorrect PIN code is entered three times in a row, the keyshare server blocks IRMA sessions by refusing to cooperate, for an amount of time that exponentially increases with the amount of consecutive incorrect PIN codes entered. Additionally, users can remotely block their own Yivi app from performing future IRMA sessions on the keyshare server's website, in case their phone is lost or stolen.
-
-The keyshare server's most important function is twofold. It provides a stronger binding of the attributes to their owner, by forcing the correctness of the IRMA PIN code: as long as the user can be trusted to not reveal her PIN code to anyone, the party that receives the attributes can be sure that the person who is disclosing them right now is the same person as the one to which they were issued in the past. Additionally, it provides a way of blocking future IRMA sessions; currently, this feature is only exposed to the users themselves. The price of these advantages is that there is now a single entity that has to cooperate in each IRMA session. This means that whenever the keyshare server is not online, no user can issue or disclose any of the attributes falling under the authority of the relevant scheme. It is thus very important that this component is carefully protected and monitored. Additionally, the keyshare server learns and records a limited amount of data whenever the user performs an IRMA session (how limited this data is is discussed below).
-
-At the Privacy by Design Foundation we believe that the advantages of using a keyshare server far outweigh the disadvantages, so the Foundation's scheme uses a keyshare server. Like all other software, this server is open source.
-
-At a high level keyshare servers work as follows. The user's secret key is split across the user's Yivi app and the keyshare server: both of them hold a part of the secret key. The actual secret key that is effectively used in each credential from this scheme is the sum of these two secret keys. When the user does not enter the correct PIN code the keyshare server will refuse to use its part of the secret key in the IRMA protocol, making it impossible for the session to complete.
-
-In more detail: whenever a scheme is installed in the Yivi app that uses a keyshare server (or when the Yivi app starts for the first time and encounters a hardcoded scheme manager that uses a keyshare server), the user *registers* at the keyshare server, by entering her email address and choosing a PIN code. The Yivi app chooses and stores a random salt of 8 bytes, calculates `SHA256(salt || PIN)`, and sends this along with the user's email address to the keyshare server.
-
-At that moment, the keyshare server chooses and stores a *keyshare* for this user: a 32-bit integer just like the user's secret key. Whenever the users performs an IRMA session using attributes from this scheme, the following happens:
-
-* The Yivi app sends the email address along with `SHA256(salt || PIN)` to the keyshare server. If this hash is not equal to the hash with which the user registered, the keyshare server aborts the session.
-* Assuming the user entered the correct PIN code, the keyshare server generates a proof of knowledge for its part of the user's secret key and sends this to the Yivi app.
-
-What happens next depends on the type of the IRMA session:
-
-* When receiving newly issued attributes, the Yivi app sends the keyshare's proof of knowledge to the issuance server, who first verifies its correctness and authenticity. If correct and authentic, it completes the issuance session in such a way that the actual secret key used in the resulting credential is the sum of both secret keys: that of the user and that of the keyshare server.
-* When disclosing attributes, the Yivi app merges this proof of knowledge with its own proof of knowledge of its own part of the secret key (and the other hidden attributes) in a certain fashion. The result of this is a valid proof of knowledge of the sum of the two secret keys.
-
-Consequentially, it is cryptographically enforced during issuance that the user will need the keyshare server's cooperation whenever she later wants to disclose attributes from the resulting credential. By refusing to cooperate, the keyshare can completely block the user from using her attributes, which is what happens when the user enters an incorrect PIN code too often.
-
-Additionally, the keyshare server comes with a small website on which users can, after logging in with their email address attribute (which they received upon registering at the keyshare server):
-
-* Instruct the keyshare server to block future IRMA sessions, remotely blocking their own Yivi app;
-* Delete their account at the keyshare server (which also blocks future IRMA sessions),
-* View a log of earlier IRMA transactions and PIN code entry attempts.
-
-As the keyshare server's contribution to the proof of knowledge of the secret key is passed to the verifier through the Yivi app instead of directly from the keyshare server to the verifier, the keyshare server does not know to whom attributes are being disclosed. In fact, the only thing it learns is which issuer (and which Idemix public keys) are involved; it does not get to see which attributes are being disclosed nor their values, nor which attributes are kept hidden, nor how many attributes from how many credentials. The transaction log that the user sees in the keyshare server's website is correspondingly bare.
-
-Summarizing, the keyshare server increases the binding between the attributes and the user through the PIN code and through the option of revocation in case of loss or theft, at the cost of a decrease in the decentral nature of IRMA and in some of the privacy guarantees. In order to keep the privacy cost as low as possible, using various cryptographic means we have tried to keep the amount of information that the keyshare server learns about the participants as small as possible. Although we are still looking at ways to make the keyshare server still more privacy-friendly, at the Privacy by Design Foundation we believe that this tradeoff is already worth it. Thus, the `pbdf` scheme indeed uses a keyshare server (towards users we call it ["MyIRMA"](https://privacybydesign.foundation/myirma/)).
-
-Each scheme manager can decide for itself whether or not to use a keyshare server in its scheme. Currently, however, due to a limitation in the IRMA protocol only one keyshare server can be involved simultaneously in IRMA sessions. This will be solved in future new versions of the Yivi app and the IRMA API server.
-
-Full details on the protocol spoken between the IRMA client and an [IRMA keyshare server](https://github.com/privacybydesign/irma_keyshare_server) is documented on the [Keyshare protocol](keyshare-protocol.md) page.
-
-## Attribute-based signatures
-
-Apart from attribute disclosure, IRMA also supports *attribute-based signatures*: a digital signature with IRMA attributes attached to it, on some document or string (more accurately this can generally be any set of bytes, though currently IRMA only support strings). The Yivi app can create such signatures with any of the attributes that it contains. The validity of such a signature can be verified using the Idemix public keys of the issuers of the used attributes, and valid attribute-based signatures can only be created using valid credentials. Contrary to [disclosure proofs](#cryptographic-entities) which are tied to an authentication session, and thus of no more use afterwards, attribute-based signatures are attached to the document that they sign, so their validity is useful as long as the signed document exist. IRMA attribute-based signatures have the same properties as conventional (non-attribute-based) [digital signatures](https://en.wikipedia.org/wiki/Digital_signature) such as non-repudiation, integrity of the signed message, and unforgeability with respect to the issuer private key. In addition, the attributes are cryptographically verifiably attached to the signature and message.
-
-IRMA attribute-based signatures can be used in any case where conventional (digital or conventional "wet") signatures are used and in which it is necessary to know something about the signature creator. For example:
-
-* A doctor could attach his name and "I am a doctor"-attribute to a medical prescription.
-* Teachers could sign student grades with their "I am a teacher"-attribute.
-* If a bank were to issue bank account numbers as an attribute to bank account owners, then a bank account owner could attach her account number attribute to a statement like "I transfer $10 to account 424242", effectively creating a cheque.
-
-Technically, IRMA attribute-based signatures are very similar to disclosure proofs. As mentioned earlier IRMA disclosures use a challenge-response protocol: the verifier generates a random number called the nonce and sends it to the Yivi app, whose response has to take this nonce into account in a precise fashion (this is achieved using the [Fiat-Shamir heuristic](https://en.wikipedia.org/wiki/Fiat%E2%80%93Shamir_heuristic)). More precisely, the disclosure proof is a digital signature on the nonce that was used; if the nonce was freshly generated then the verifier can be sure that the attribute owner is actually present instead of replaying an earlier or eavesdropped disclosure proof. An IRMA attribute-based signature is the same except that not a nonce but an actual message is signed (or rather its SHA256 hash).
-
-Currently IRMA only supports creating attribute-based signatures on strings, although we plan to support other types of documents as well. They can be created using [irmajs](https://github.com/privacybydesign/irmajs) and verified using [IRMA servers](what-is-irma.md#irma-servers) almost the same as disclosure proofs. An online demo is available on the [website of the Foundation](https://privacybydesign.foundation/demo/ondertekenen/).
-
-## IRMA security properties
-
-* **Credential unforgeability:**
- Only the issuer (that is, the holder of the Idemix private key) can issue credentials that will verify under the Idemix public key. Thus when a verifier receives valid attributes, it can safely assume they were issued by the issuer.
-
-* **Multi-show unlinkability:**
- When a verifier performs two IRMA sessions in which the attributes that it receives are identical, then it cannot tell whether the two IRMA sessions were performed with one user who disclosed the same attributes twice, or with two distinct users. In other words, such sessions are not linkable as coming from the same user. (It is important to note that this property holds only at the cryptographic level; using identifying data from the transport layer such as the user's IP or MAC address verifiers can potentially still link sessions.)
-
-* **Grouping credentials using the private key:**
- When attributes are disclosed coming from multiple credentials, the Yivi app additionally proves that the credentials share the same secret key, and thus that the attributes come from the same user.
-
-* **Eavesdroppers cannot perform replay attacks:**
- When verifying attributes, the verifier first sends a number of random bits called the nonce to the Yivi app, and the Yivi app's reply containing the disclosed attributes and the proofs of knowledge has to fit on this nonce in a precise fashion. Assuming that the verifier never reuses nonces, this means that an eavesdropper cannot replay an IRMA disclosure.
-
-* **Verifiers cannot perform replay attacks:**
- Even if all attributes were disclosed (and the secret key is in fact never disclosed), the Yivi app does not send a complete copy of the credential's signature to the verifier; instead parts of it are hidden using proofs of knowledge. This means that verifiers cannot use what they learn in IRMA disclosures to disclose the received attributes to other verifiers, acting as an Yivi app possessing the attributes that were disclosed to it.
-
-* **No impersonation attacks:**
- The credentials and attributes reside in the Yivi app installation of the users. This is contrary to other identity management systems such as for example "Log in with Facebook": when someone presses such a Facebook login button on some website, it is really Facebook who authenticates on that website on behalf of the user. Consequentially, Facebook can potentially authenticate itself as any of its users to such websites. This is not possible in IRMA.
-
-* **No privacy hotspots:**
- When a user discloses IRMA attributes to a verifier, the attributes are sent directly from the user to the verifier without passing through any central party.
-
-It must be mentioned that these properties only hold assuming that our software contains no bugs that break these properties. For this reason all of the IRMA software is open source so that anyone can verify its correctness. We encourage anyone to inspect the IRMA source code, and inform us of any errors that might lessen security or other aspects of the functionality.
-
-## Other resources
-
-* Website of the [Privacy by Design Foundation](http://privacybydesign.foundation/), the creators and maintainers of IRMA
- * An [introduction to IRMA](https://privacybydesign.foundation/irma-start/) for Yivi app users
- * A general and more complete [introduction to IRMA](https://privacybydesign.foundation/irma-explanation/)
- * [Live IRMA demos](https://privacybydesign.foundation/demo-en/)
-* The Android and iOS [Yivi apps](https://privacybydesign.foundation/download-en/)
diff --git a/website/versioned_docs/version-v0.13.0/randomblind.md b/website/versioned_docs/version-v0.13.0/randomblind.md
deleted file mode 100644
index da0e0a4..0000000
--- a/website/versioned_docs/version-v0.13.0/randomblind.md
+++ /dev/null
@@ -1,195 +0,0 @@
----
-title: Randomblind issuance
-id: version-v0.13.0-randomblind
-original_id: randomblind
----
-
-
-
-
-*Randomblind* attributes are a new IRMA feature introduced in
-[`irmago` v0.6.0](https://github.com/privacybydesign/irmago/releases/tag/v0.6.0)
-that can give the user extra privacy
-guarantees during issuance. Specifically, if this mode of issuance is enabled
-for an attribute within a credential type, this attribute is guaranteed to
- 1) be random, i.e., unequal to all previously issued instances of this attribute and
- 2) remain unknown to the issuer, while it still signs the attribute as part of the credential.
-
-Note that the latter property holds up until a user decides to disclose the
-attribute. In this sense, the attribute can be seen as a one-time attribute.
-
-This page explains how to enable this feature and later how this guarantee is
-upheld cryptographically. The primary use case of this feature is online
-voting, where voting secrecy plays a vital role. In the last section,
-we will explain how randomblind attributes can be used in digital elections.
-
-
-## API
-
-Randomblind issuance is enabled in the scheme by adding the `randomblind` XML
-attribute to an `Attribute` tag within the issue specification of a given
-credential. For more information about schemes, see [this
-page](/schemes/). In the example below we enable this for
-the second attribute in the credential. Any or all atributes in a credential
-type can be randomblind.
-
-``` xml
-
- ...
-
-
- ...
-
-
- ...
-
- ...
-
-...
-
-```
-
-When issuing a credential specified by the above, the
-issuing party, i.e., the requestor that submits the issuance request to the
-IRMA server, must *not* pass attribute values for attributes that are tagged as
-randomblind. Instead, the issuer and user jointly decide on the value of these
-attributes (in this case the `votingnumber` attribute) during the session.
-We explain in detail how this comes to pass in the next section.
-
-
-As a concrete example we use the
-"Demo Voting Card" credential type, see [this page in the attribute
-index](https://privacybydesign.foundation/attribute-index/en/irma-demo.stemmen.stempas.html#irma-demo.stemmen.stempas.election).
-Even though the credential contains five attributes, the issuer must only give
-four concrete values to construct the credential. For example, a requestor can
-start an issuance session to issue such a credential using the following
-command:
-
-```
-irma session --issue irma-demo.stemmen.stempas=test,test.com,14-12-2020,15-12-2020
-```
-
-Upon scanning the QR code, the Yivi app user is asked permission to perform the
-session and obtain this credential. At this point, the value of `votingnumber`
-has not been decided yet. After the issuance, a fifth attribute,
-`votingnumber`, which is at most 256 bits, shows up in the credential. The app
-displays this attribute in a [base62
-representation](https://en.wikipedia.org/wiki/Base62).
-
-
-Before issuance | After issuance
-:----------------------------:|:----------------------------:
-![Permission](assets/rb_permission.jpg) | ![Card](assets/rb_card.jpg)
-
-## Cryptography
-In this section we will explain in detail how the issuer and the user are able
-to perform such an issuance session. Randomblindness of attributes only concerns
-the issuance protocol. The disclosure and signature protocols involving randomblind attributes
-are in every aspect identical to disclosing or signing using a normal attribute.
-
-We can assume that the schemes of both parties agree on the indices of the
-randomblind attributes. If this is not the case, either party cancels the
-session. In the following example, we only have one randomblind attribute, but
-the protocol can be extended straightforwardly to issue multiple randomblind
-attributes.
-
-The following requires a bit of background regarding Camenisch-Lysyanskaya (CL)
-signatures. A short summary can be found
-[here](https://privacybydesign.foundation/pdf/Idemix_overview.pdf). A more
-extensive description of the Idemix specification can be found
-[here](https://dominoweb.draco.res.ibm.com/reports/rz3730_revised.pdf).
-
-In the following, the variables $R, S$ and $Z$ are public parameters defined by the
-Idemix public key of the issuer. The issuance goes as follows:
-- The user starts by sampling a random $v'$ and a random 255-bit integer $m_{r}'$ at
- the index $r$ of the randomblind attribute.
- This so-called *share* of the attribute remains secret, similar to
- how the user's secret key remains secret during issuance.
- The user computes the commitment $U = S^{v'} R_0^{m_0} R_r^{m_{r}'} \mod n$.
- Note that $m_0$ is always the user's secret key. This commitment is sent to
- the issuer along with a [zero-knowledge proof](/zkp/)
- of $v', m_0$ and $m_{r}'$.
-
-- The issuer samples a random prime $e$.
- The issuer also samples $v''$ and $m_{r}''$ (also 255 bits) at random.
- Next, the issuer computes
-
- $$
- A = \Bigg(\frac{Z}{U S^{v''} R_{1}^{m_1} \dots \ R_{r}^{m_r''} \dots \ R_{n}^{m_n}}\Bigg)^{1/e}
- $$
-
- For every attribute that is tagged randomblind, the issuer includes its share
- of the attribute in the exponent (in this case, only for index $r$). For
- regular attributes, the exponent is simply the attribute value that the
- issuer wants to pass. The issuer sends $(A, e, v'', m_{r}'')$ back to the
- user.
-
-- Finally, the user is able to reconstruct any attributes that are the sum of two shares:
- $$
- m_r = m_r' + m_r''
- $$
-
- The CL signature becomes $(A, e, v)$ with $v = v' + v''$. It follows that $Z
- = A^e S^v \prod_{i=0}^{l} R_{i}^{m_i}$ holds for the attributes $m$ in the
- resulting credential, meaning that the signature (and thereby the credential) is
- valid. We also note that the issuer does not have enough information to
- fully uncover $m_r$, which ends up as the attribute value in the resulting
- credential. The user is now free to use this attribute, knowing the issuer
- cannot trace it back to her. Note that after revealing this attribute
- once, this guarantee no longer holds.
-
-## Use case: Digital elections
-
-Two important requirements in digital elections in not just an online setting,
-but rather in general, are *secrecy* and *verifiability*. Secrecy means that
-nobody else is able to figure whom someone voted for. Verifiability means that
-any user of the system is able to verify that her vote is included in the
-final tally. In this section we explain how IRMA's randomblind attributes can
-help realize these requirements.
-
-A key observation to preserve secrecy is that there has to be a split between
-authenticating the user and registering the votes. In physically held
-elections this is realized by handing out an anonymized ballot after the user
-has proven eligibility. For this purpose, two parties are required; one that
-the user authenticates to after which this party determines if the user is
-eligible (party A); and one that registers votes (party B). It is crucial
-that these parties are strictly separate and do not conspire together.
-
-In digital elections, the same principle applies. Using IRMA randomblind
-attributes the following system can be realized:
-
-1. (Eligibility check \& voting pass retrieval). The user authenticates to
- party A (perhaps using IRMA), which then decides whether or not
- this user is eligible as per the system's criteria. In this process,
- party A learns (part of) the identity of the user. If the user is
- eligible, the party issues a voting card, which includes a randomblind
- attribute. Since party A does not learn the value of the
- attribute, this party can also not learn whom or what a user decides to vote
- for in the upcoming steps. Note that in order to prevent a user from
- fetching more than one voting card (and thus being able to cast multiple
- votes), the user must be uniquely identified in this stage.
-
-2. (Casting the vote). To vote, a user creates an [attribute-based
- signature](/overview/#attribute-based-signatures) on a
- "ballot" string, i.e., the user's choice using the randomblind attribute
- acquired in the previous step. This signature, the choice and the attribute
- are then registered in a database at party B. The signature ensures
- authentication, integrity and non-repudiation. Note that party B only
- learns what somebody voted for, but not the actual identity of the voter.
-
-3. (Verification).
- After the election ends, the database is published. To verify whether her
- vote has been correctly cast, the user can simply check if the
- attribute-based signature created in the previous step containing her
- randomblind attribute is among the registered vote entries.
diff --git a/website/versioned_docs/version-v0.13.0/revocation.md b/website/versioned_docs/version-v0.13.0/revocation.md
deleted file mode 100644
index 352569f..0000000
--- a/website/versioned_docs/version-v0.13.0/revocation.md
+++ /dev/null
@@ -1,352 +0,0 @@
----
-title: Revocation
-id: version-v0.13.0-revocation
-original_id: revocation
----
-
-
-
-
-Revocation adds to IRMA issuers the ability to revoke a credential that it previously issued to an [Yivi app](yivi-app.md), when the contained attributes are no longer accurate. This allows IRMA attribute verifiers to establish that the attributes it received are still factual, as otherwise the credential would have been revoked by the issuer.
-
-This page explains in detail how revocation is implemented in IRMA and what it means to requestors and app users, on three levels:
-* In the first part of the section below, we give a summarizing overview fitting in one page.
-* In the [API section](#api) we give a much more expansive explanation, including the new revocation API for issuers and verifiers.
-* In the [cryptography section](#cryptography) we explain the cryptographic mechanism enabling revocation.
-
-## Overview
-
-Revocation in IRMA is an implementation of the RSA-B scheme from ["Accumulators with applications to anonymity-preserving revocation"](https://eprint.iacr.org/2017/043.pdf) by Baldimtsi et al, which in turn is based on ["Dynamic accumulators and application to efficient revocation of anonymous credentials"](http://static.cs.brown.edu/people/alysyans/papers/camlys02.pdf) by Camenisch et al. Using this scheme the app can prove nonrevocation of its credential in zero-knowledge, preserving [unlinkability of multiple disclosures](overview.md#irma-security-properties) of the attributes within the credential.
-
-In IRMA, revocation is enabled per credential type in the IRMA scheme. If so, when properly configured (more on that [below](#revocation-settings)) the issuer's IRMA server will issue revocation-enabled credentials of that type. During disclosures the Yivi app can then prove nonrevocation (but it will only do so if explicitly asked for by the requestor).
-
-In short, revocation works as follows.
-
-* **Key generation**: The issuer generates an **accumulator** and makes it available to all IRMA participants (i.e. requestors and apps; more on how this is done later). This accumulator changes value whenever the issuer revokes a credential.
-* **Issuance**: If the issuer issues a credential for which revocation is enabled in the scheme, then along with the credential the issuer computes a **nonrevocation witness**, consisting of two large integers. This witness is valid against the issuer's current accumulator (like a signature over a message can be valid against a public key). One of these integers is also included in the credential as a new **revocation attribute** (hidden in de Yivi app GUI), binding the witness to the credential. During issuance, the issuer stores the revocation attribute for this credential in a database for later revocation. The Yivi app stores the witness alongside the credential.
-* **Disclosure**: If the requestor asks for a nonrevocation proof for a given credential type and the app has a revocation-enabled credential instance of that type, then along with the disclosed attributes the client sends to the requestor a **nonrevocation proof**, which proves in zero knowledge to the requestor that the witness of the credential is valid against the issuer's current accumulator. From this the requestor infers that the credential is not revoked.
-* **Revocation**: When the issuer wants to revoke a credential, it first looks up in its database the revocation attribute for that credential that it stored after issuance. Using this, it (1) updates its accumulator to a new value, and (2) makes available to all IRMA participants a **revocation update message**, consisting of the new accumulator and the revocation attribute of the revoked credential. Yivi apps containing (non-revoked) credentials use these update messages to update their witness, so that it becomes valid to the new accumulator. This update algorithm is such that it always fails for the witness of the revoked credential, so that the containing app can no longer prove nonrevocation.
-
-Computing a nonrevocation proof for a credential is much more expensive than just computing a disclosure proof out of that credential. If the user has a revocation-enabled credential then proving nonrevocation is not required; instead she can also just normally disclose attributes from the credential, without using the witness, which is much cheaper. For this reason the app will only prove nonrevocation for a credential type if the requestor explicitly requests it. Requestors should only request nonrevocation proofs when it is really necessary for them to establish that they received nonrevoked attributes.
-
-In the papers linked to above (and generally in the scientific literature on revocation), the party that is able to revoke credentials is called the **revocation authority**, which is not necessarily the same as the party that issues credentials. Within IRMA we have decided to endow the issuer with this responsibility, i.e. the issuer is also the revocation authority for revocation-enabled credential types, because conceptually and technically this simplifies many details.
-
-> In the remainder of this post when we refer to the requestor, issuer, or verifier, we generally refer to the IRMA server software implementing APIs for those parties. The term "IRMA server" itself refers to the following variants of the IRMA server:
-> * The [`irma server`](irma-server.md) daemon.
-> * The [`irmaserver` Go library](irma-server-lib.md).
->
-> Support for revocation will be added to the [bindings of the above library](https://github.com/privacybydesign/irmago/tree/master/server/irmac) to other programming languages soon.
-
-### Revocation updates
-
-Whenever the issuer revokes a credential, updating its accumulator, it publishes a revocation update message as explained above, which apps require to update their witness so that it is valid against the new accumulator. Accumulators are labeled with an index which is increased whenever the issuer makes a new accumulator by revoking. Apps use the index to keep track of against which accumulator their witness is valid in the chain of all past accumulators, and thus how many update messages it needs to obtain and apply. The app requires all of the update messages that it has not already received and applied; if it misses one or more of them it cannot update its witness and it is no longer able to compute nonrevocation proofs for the witness's credential. If that happens but the verifier requires a nonrevocation proof, then the user is unable to disclose attributes from the credential.
-
-It is thus crucial that the set of update messages is always available to each Yivi app. In IRMA, the issuer is responsible for ensuring that all update messages and the latest accumulator are available. To that end, the IRMA server exposes these messages through new HTTP endpoints, if so configured. For each revocation-enabled credential type, at least one URL to such an IRMA server instance must be included within the credential type in the scheme.
-
-If within an IRMA session a requestor requests revocation for a given credential type but the app's witness is out of date (i.e. credentials have been revoked and the accumulator changed value since the app last updated), then before the app can prove nonrevocation it needs to update its witness so that it becomes valid against the latest accumulator. If the app would have to contact the issuer's IRMA server to download updates whenever that happens, then the issuer could infer from its logs that the user is updating probably because she now wants to disclose attributes, harming the user's privacy towards the issuer. In order to prevent this, whenever a requestor requests a nonrevocation proof for a given credential type in a session request, it is required to include the last few revocation update messages for that credential type with the session request. The app uses those to update its witness, if it is not too far behind. The IRMA server will automatically include the required amount of update messages when it sends the session request to the app during the IRMA protocol. (If the app is too far behind then it will need to contact the issuer to download the updates that it did not receive from the requestor in the session request. The Yivi app will do this periodically, i.e. outside of IRMA sessions, for all of its witnesses.)
-
-#### Revocation update chain
-
-Whenever a credential is revoked and the accumulator changes value, the accumulator's index is incremented. If an app has a witness at index $i$ but the current accumulator $\nu_j$ has index $j$, then the app requires $(e_i,\dots,e_j,\nu_j)$ to update its witness to the latest index $j$, where the $e$'s are the revocation attributes of the revoked credentials. As soon as another credential is revoked and the current accumulator becomes $\nu_{j+1}$, the old accumulator $\nu_j$ is no longer needed. Thus the revocation attributes $e_i$ naturally form a chain, always headed with the latest accumulator $\nu_j$.
-
-Each element of this chain (including the head element $\nu_j$) contains the cryptographic hash of its predecessor, and $\nu_j$ is signed by the issuer using ECDSA. Thus this one ECDSA signature signs the entire partial chain $(e_i,\dots,e_j,\nu_j)$: apps and IRMA servers can check its authenticity regardless of its length. This makes it safe for the Yivi app to receive revocation update messages through the requestor in the session request.
-
-Each accumulator $\nu_j$ contains the time of its creation, and every minute this timestamp is refreshed: the accumulator is replaced with a new (signed) accumulator $\nu'_j$ with the same value and index but newer timestamp. To others receiving the updated accumulator, this proves that the issuer's revocation setup is still live. In addition, when verifying an attribute-based signature this makes it possible to establish that the attributes in it were not revoked at creation time of the signature.
-
-A requestor by itself only needs the accumulator $\nu_j$ against which the app has proved nonrevocation in order to verify the proof, and not necessarily the revocation attributes $e_j$ of the revoked credentials. However, they will still fetch a number of these attributes from the issuer's revocation IRMA server in order to pass them on to apps during IRMA sessions.
-
-### Issuer responsibilities
-
-The issuer of a revocation-enabled credential type must:
-
-* Store all revocation update messages in order to be able to offer these to other IRMA participants needing them;
-* Offer the revocation update messages to other IRMA participants through an HTTP API;
-* Store the revocation attribute of each revocation-enabled credential during issuance, as the revocation attribute is necessary during revocation;
-* Revoke a credential when necessary by updating the accumulator and adding a revocation update message.
-
-The IRMA server can handle any or all of the above responsibilies if so configured (see [below](#revocation-settings)).
-
-If the server hosting the revocation update messages is unreachable, then the requestor and app cannot update their accumulator and witness to the latest version. In that case nonrevocation can only be proved against the last known accumulator, from before the issuer's server became unreachable.
-
-> In the event that the issuer's server is unreachable and the requestor's IRMA server cannot update its accumulator to the latest version, then the requestor's IRMA server will accept nonrevocation proofs from the app against its last known accumulator. This results in a time window in which nonrevocation is not guaranteed. If that time window is longer than a configurable maximum the server will report the length of the nonrevocation window to the requestor, but still accept the attributes.
-
-The only possible alternative behaviour would be for the requestor to not accept the attributes, but we want to avoid burdening the user with the consequences of the problem; she would then no longer be able to do whatever she wanted to do with her attributes. Therefore we leave this decision to the requestor. Instead it is the issuer's responsibility to always keep its server online so that this does not happen; and when it does go offline, to restore it as soon as possible. The shorter it is offline, the smaller the "nonrevocation window" and the smaller the problem.
-
-Before revocation is enabled for a given credential type, revocation-specific public and private key material has to be included in the IRMA public and private key of the issuer of the credential type. The [`irma` binary](irma-cli.md) will do so automatically for new keypairs and it can also augment existing keypairs.
-
-#### Scalability
-
-The issuer of a revocation-enabled credential type must always have at least one publically reachable IRMA server running, which is contacted in the following cases.
-* Requestor IRMA servers verifying instances of this credential type will periodically fetch revocation updates (by default every 5 minutes), in order to pass them along to Yivi apps during sessions.
-* Yivi apps also periodically fetch revocation updates to ensure their witness does not become too far outdated (with random time intervals, around 1 day). The average amount of time between two such updates can be configured in the scheme.
-* During a session, if the Yivi app's witness is so far outdated that the update messages provided by the requestor are not sufficient.
-
-The load on this server will increase with the amount of (1) requestors, (2) Yivi apps posessing revocation-enabled credentials, and (3) revocations performed by the issuer. If the load becomes too heavy for one IRMA server, the issuer can do the following:
-* Deploy multiple revocation IRMA servers, with for example a DNS load balancer in front of them, or putting multiple `RevocationServer` URLs in the scheme (see below).
-* Deploying HTTP caching servers in front of the revocation IRMA servers, as it outputs `Cache-Control` HTTP headers on revocation HTTP endpoints that output stable information.
-
-All revocation update messages and accumulators are always digitally signed by the issuer using ECDSA before they are published, and in particular, the entire revocation update chain is signed. This means that other parties than the issuer itself can also run IRMA servers running in revocation server mode for the issuer's credential type. Apart from sharing the load this can also increase uptime.
-
-## API
-
-The addition of revocation to IRMA is designed to be backwards compatible: when revocation is not enabled for a credential type or when a nonrevocation proof is not requested, everything works as it used to; and all of the API changes documented below are additions, adopting the style and conventions of the existing API wherever applicable.
-
-### Scheme
-
-Revocation for a credential type is enabled in the scheme by including at least one `RevocationServer` XML tag and a separate `Attribute` XML tag with a `revocation="true"` attribute inside `description.xml`:
-```xml
-
-
- http://example.com/
-
-
-
-
-
-
-
-
-
-
-```
-See for example [this demo credential type](https://github.com/privacybydesign/irmago/blob/master/testdata/irma_configuration/irma-demo/MijnOverheid/Issues/root/description.xml#L19). Specifying more than one URL allows IRMA requestors and apps to fallback to other URLs when one of them is offline. Once revocation is enabled in the scheme, issuing IRMA servers will automatically issue revocation-enabled credentials. (From this moment the issuing requestor [needs to include](#issuance) `revocationKey`s in its issuance requests, and the issuing IRMA server(s) need to be correctly [configured](#revocation-settings) for revocation.)
-
-Existing credential types can gain support for revocation by adding a `RevocationServer` and adding an attribute with `revocation` enabled.
-
-The IRMA issuer private and public keys used for revocation-enabled credentials must contain revocation-specific key material. When generating new keypairs, `irma issuer keygen` now always includes this. Existing keypairs may be augmented using the new `irma issuer revocation keypair` subcommand.
-
-### Revocation settings
-
-The primary new responsibility for an issuer of a revocation-enabled credential type is to maintain the [revocation update chain](#revocation-update-chain) $(...,e_{i-1},e_i,\nu_i)$. The IRMA server supports a new *revocation mode* for this which can be enabled per credential type by the issuer. At minimum, for each credential type supporting revocation one IRMA server must run in revocation mode for that credential type (publically reachable via its URL in a `RevocationServer` tag in the credential type).
-
-Revocation can be configured in the IRMA server configuration using a new `revocation_settings` map, containing options per credential type. Below is a full example of an IRMA server running in revocation mode for `irma-demo.MijnOverheid.root`.
-
-```json
-{
- "revocation_db": "host=127.0.0.1 port=5432 user=testuser dbname=test password='testpassword'",
- "revocation_db_type": "postgres",
- "no_auth": false,
- "revocation_settings": {
- "irma-demo.MijnOverheid.root": {
- "authority": true
- }
- },
- "requestors": {
- "myapp": {
- "authmethod": "token",
- "key": "mypresharedtoken",
- "issue_perms": [ "irma-demo.MijnOverheid.root" ],
- "revoke_perms": [ "irma-demo.MijnOverheid.root" ]
- }
- }
-}
-```
-
-Note the following:
-* A server running in revocation mode for any credential type requires a SQL database to be configured. In this database all revocation state will be stored.
- Current supported SQL databases:
- * Postgres
- ```json
- {
- "revocation_db": "host=127.0.0.1 port=5432 user=testuser dbname=test password='testpassword'",
- "revocation_db_type": "postgres"
- }
- ```
- * MySQL:
- ```json
- {
- "revocation_db": "testuser:testpassword@tcp(127.0.0.1)/test",
- "revocation_db_type": "mysql"
- }
- ```
- * Microsoft SQL Server
- ```json
- {
- "revocation_db": "sqlserver://testuser:test-Password@127.0.0.1:1433?database=test",
- "revocation_db_type": "sqlserver"
- }
- ```
-* This configuration also grants permission to a requestor called `myapp` to issue and revoke `irma-demo.MijnOverheid.root` instances. Alternatively, if `no_auth` would be `true` then any requestor capable of reaching the server could issue and revoke instances (in production settings, such a server should not be publically reachable).
-
-For each credential type revocation settings may be specified in the `revocation_settings` block as above. The following specifies all possible options and their defaults.
-```json
-{
- "server": false,
- "authority": false,
- "revocation_server_url": "",
- "tolerance": 600,
- "sse": false
-}
-```
-The options are as follows.
-* `server` enables endpoints used by Yivi apps and other IRMA servers to fetch part of the revocation update chain.
-* `authority` implies `server` and additionally enables (1) an endpoint required by issuing IRMA servers to send **issuance records** to for each issued credential, required for later revocation of the credentials; and (2) an endpoint accepting revocation requests (subject to the server's requestor authentication configuration).
-* `revocation_server_url`, if present, overrides the `RevocationServer` URL from the credential type in the scheme. In the following cases, this must point to an `authority` IRMA server:
- - If `server` is true but `authority` is false (in this case, revocation updates are fetched from here);
- - If this server will issue instances of the current credential type, and `authority` is false (otherwise it just stores the records locally).
-* `tolerance`: at the latest, the nonrevocation guarantee provided by the Yivi app lasts until the moment that it first connected to the IRMA server in the current session (see [below](#disclosure)). If during an IRMA session this time window is more than `tolerance` seconds, then it will be reported back to the requestor (who may then decide to accept the attributes or abort).
-* `sse`: if `true` then the IRMA server will attempt to open a [Server Sent Events](https://en.wikipedia.org/wiki/Server-sent_events) channel to the revocation server (as specified by either the scheme or `revocation_server_url`). If successful, the revocation server will push new revocation updates to the IRMA server as it creates them (instead of the IRMA server having to periodically fetch then). Note that the revocation server may have disabled SSE support, and (forward) proxies sitting between the current server and the revocation server may break SSE channels. If enabled, it should always be tested that it works.
-
-Note that the `RevocationServer` URL from the credential type must point to a publically reachable IRMA server with `server` enabled for the credential type. This IRMA server must be online at all times. It does not need to have `authority` enabled (if not, the issuer will need at least one other server for which `authority` is enabled, as only those servers can write to the revocation chain).
-
-The example IRMA server configuration above is the minumum setup enabling revocation for `irma-demo.MijnOverheid.root`, with one server handling everything. A more elaborate setup could be as follows (using schematic example URLs without `https://`).
-
-| URL | Public | Configuration |
-|----------|--------|------------------------------------------------------------------|
-| `issuer` | yes | `{"revocation_server_url": "auth"}` |
-| `rs` | yes | `{"server": true, "revocation_server_url": "auth", "sse": true}` |
-| `auth` | no | `{"authority": true}` |
-
-The middle column indicates whether or not the server needs to be publically reachable. This setup assumes that `rs` and `auth` use distinct SQL databases. The URL of `rs` must be included as the `RevocationServer` in the scheme. Enabling `sse` in `rs` ensures its revocation state remains up to date with the authority `auth`. This setup avoids that the issuance record endpoint and revocation endpoint are exposed to the internet, and also allows scaling `rs` to multiple instances to share the load if required.
-
-### Issuance
-
-When issuing a revocation-enabled credential to a user, the issuer includes a `revocationKey` for each credential in the session request. For example:
-```json
-{
- "@context": "https://irma.app/ld/request/issuance/v2",
- "credentials": [{
- "credential": "irma-demo.MijnOverheid.root",
- "attributes": { "BSN": "12345" },
- "revocationKey": "bsn-12345"
- }],
-}
-```
-
-The state that would be needed during revocation (in particular, the revocation attribute of this credential) is stored in the database with the `revocationKey` acting as primary key: when later this credential needs to be revoked the issuer can refer to it out of all issued credentials using its `revocationKey`.
-
-Note that the issuance IRMA server must be [configured](#revocation-settings) with the URL to the authoritative revocation server.
-
-### Disclosure
-
-Requestors can request nonrevocation proof for a given credential type by including it in the new `revocation` array in the session request:
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "irma-demo.MijnOverheid.root.BSN" ]]],
- "revocation": [ "irma-demo.MijnOverheid.root" ]
-}
-```
-This instructs the IRMA server to only accept the attributes if the app includes a valid nonrevocation proof for all instances of `irma-demo.MijnOverheid.root` out of which it discloses attributes. If a credential type is not listed there and the app has a revocation-enabled credential of that type, then it will not include a nonrevocation proof.
-
-Since attribute disclosures can occur during [any of the three session types](session-requests.md#disclosure-requests) (disclosure, attribute-based signatures, issuance), the `revocation` key can be included in the session requests of any type.
-
-The IRMA server of the requestor obtains new revocation update messages from the `RevocationServer` specified in the credential type in the scheme in one of two possible ways: either through a Server Sent Events channel so that the server is always up to date, or by periodically fetching. Either way, when the Yivi app connects to the IRMA server (e.g. after scanning the QR code), for each credential type of which nonrevocation proofs are requested in the session request, the server looks up in its own memory or database (1) the last accumulator that it knows and (2) a certain amount of the most recent update messages, and it includes these in the session request that it sends to the Yivi app.
-
-The server will accept the nonrevocation proof of the app if the proof is valid against either the accumulator that it included in the session request, or a newer one. The app always includes the accumulator against which it proved nonrevocation with the nonrevocation proof, so that during verification it is never necessary to retrieve accumulators from the issuer; by including the accumulator the response of the app contains all information required to verify it.
-
-When reporting verified attributes for which the app proved nonrevocation to the requestor at the end of the session, the corresponding entry in the [`SessionResult`](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult) might look as follows.
-
-```json
-{
- "disclosed": [
- [
- {
- "rawvalue": "299792458",
- "id": "irma-demo.MijnOverheid.root.BSN",
- "status": "PRESENT",
- "issuancetime": 1583366400,
- "notrevoked": true
- }
- ]
- ]
-}
-```
-The `notrevoked` boolean indicates that the app proved nonrevocation of this attribute.
-
-The Yivi app proves nonrevocation against a certain accumulator which it includes in its response to the IRMA server. The verifying IRMA server determines which accumulator this must be when the app first connects to it, by choosing the latest one that it knows of and sending it to the app in the session request.
-
->The nonrevocation guarantee inferrable from an Yivi app's nonrevocation proof lasts only until the creation time of the accumulator used by the app.
-
-If the age of the accumulator is greater than a configurable value called `tolerance` (see [above](#revocation-settings)), then this age will be reported alongside `notrevoked` (which remains `true`). This can happen in the following cases:
-* The Yivi app user took longer over deciding whether or not to perform the session than the `tolerance`;
-* The issuer's revocation IRMA server is offline and no updates can be retrieved.
-
-When signing the newest accumulator the issuer always includes the current time, and as mentioned earlier, when disclosing attributes (or when constructing an attribute-based signature), the Yivi app includes the accumulator against which it proves nonrevocation in its disclosure (or attribute-based signature). In case of signatures, this means that by checking that the accumulator time is sufficiently close to the time in the timestamp of the signature, it can be established that the attributes were not revoked at the moment the attribute-based signature was created. The attribute-based signature by itself is sufficient to establish this; i.e., it is not necessary to contact either the issuer or timestamp server during verification.
-
-If during disclosure the requestor asks for a nonrevocation proof of a given credential type, but the app only posesses credentials of that type that do not support revocation (i.e., no witnesses were included with them during issuance), then the app will abort as it is not able to fulfill the requestor's request.
-
-Yivi apps can disclose attributes out of revocation-aware credentials even to non-revocation aware IRMA servers. In this case only knowledge of the revocation attribute $e$ is proved.
-
-### Revocation
-
-The API that the IRMA server exposes for revoking previously issued credentials is similar to the API for starting and managing IRMA sessions:
-* A new revocation endpoint is available as a function on the [`irmaserver` Go library](irma-server-lib.md), and as a corresponding HTTP endpoint in the `irma server`.
-* Similar to session request data structures, (e.g. [`DisclosureRequest`](https://godoc.org/github.com/privacybydesign/irmago#DisclosureRequest)), revocation is initiated at the `irma server` by a [`RevocationRequest`](https://godoc.org/github.com/privacybydesign/irmago#RevocationRequest) data structure identified as such by a [JSON-LD](https://json-ld.org/) `@context` tag (having constant value `https://irma.app/ld/request/revocation/v1`).
-* As with ordinary session requests, when the `no-auth` setting is disabled in the `irma server` configuration this request has to be authenticated using one of the [existing authentication methods](irma-server.md#requestor-authentication) (i.e., by including a preshared `token` in an HTTP header or by signing the request into a JWT using `hmac` or `publickey`).
-* Each requestor configured in the `irma server` can be endowed with permission to revoke specific credential types (possibly in addition to [permissions to issue or verify attributes](irma-server#permissions)). If `no-auth` is disabled, and the revocation request can be succesfully authenticated as originating from a requestor present in the `irma server` configuration, and that requestor is authorized to revoke the credential type mentioned in the request, then the revocation command is executed and the credential is revoked.
-
-For example, the following `RevocationRequest` instructs the server to revoke the `irma-demo.MijnOverheid.root` instance to which it previously assigned `bsn-12345` as `revocationKey` during issuance, and which was issued at Unix nano timestamp `1583765731750425000`. If `issued` is not specified, all previously issued credentials with matching `revocationKey` are revoked.
-
-```json
-{
- "@context": "https://irma.app/ld/request/revocation/v1",
- "type": "irma-demo.MijnOverheid.root",
- "revocationKey": "bsn-12345",
- "issued": 1583765731750425000
-}
-```
-
-## Cryptography
-
-The IRMA issuer private key is $(p', q')$ where $p', q'$ are both [safe primes](https://en.wikipedia.org/wiki/Safe_prime): if written as $p' = 2p+1$ and $q' = 2q+1$, then $p$ and $q$ are also prime. The issuer uses this private key for issuing attributes as well as for revoking. The corresponding IRMA issuer public key contains the modulus $n = p'q'$. This modulus defines the group $QR_n = ((\mathbb{Z}/n\mathbb{Z})^*)^2$ of quadratic residues within the multiplicative integers modulo $n$, in which both the Idemix and the revocation cryptography takes place. For signing various revocation related messages the issuer additionally generates an ECDSA private/public keypair. These are included in the existing IRMA private/public keys.
-
-### Issuance
-The current accumulator is a number $\nu \in QR_n$. The first accumulator is randomly chosen by the issuer from $QR_n$. During issuance, the issuer
- 1. generates a prime $e$,
- 2. embeds the prime $e$ as an attribute within the credential being issued,
- 3. uses its private key to compute $u = \nu^{1/e\bmod pq}$, and sends the tuple $(u,e)$ to the app along with the credential,
- 4. stores the number $e$ in a database for later revocation.
-
-### Disclosure
-The revocation witness is the tuple $(u, e)$. By definition it is valid only if $u^e = \nu \bmod n$. When using revocation, the app now proves the following to the verifier:
-* "I possess a valid credential containing the disclosed attributes as well as an undisclosed attribute $e$."
-* "I know a number $u$ which is such that $u^e = \nu \bmod n$."
-
-The app proves this in zero-knowledge, meaning that the verifier can infer nothing from this proof except the above two facts. In particular, the proof hides the undisclosed attributes as well as $u$ and $e$. This provides unlinkability, as it ensures that a later session using the same credential and same witness cannot be linked to earlier ones (before or after the credential has been revoked). From the fact that the witness is valid, the verifier infers that the witness's credential is not revoked.
-
-The app includes the accumulator $\nu$ signed by the issuer against which it proved nonrevocation with its nonrevocation proof. The verifier accepts if this included accumulator is validly signed by the issuer; if the nonrevocation proof is valid against that accumulator; and if the accumulator is the same or newer than its own copy.
-
-### Revocation
-Henceforth, we label the current accumulator and witnesses with an index $i$, so the current accumulator value is $\nu_i$. If the issuer wants to revoke a credential it first looks up in its database the revocation attribute $\tilde{e}$ that it used for that credential (we use a tilde to distinguish this $\tilde{e}$ from the revocation attributes $e$ of other apps wanting to update their own (nonrevoked) witness, see below). Then it uses its private key to compute the new accumulator value as follows:
-
- $\displaystyle \nu_{i+1} = \nu_{i}^{1/\tilde{e}\bmod pq}$
-
-The update message consists of $(\nu_{i+1}, \tilde{e})$; the issuer signs this using its ECDSA private key and then offers it to others using an HTTP API. Apps and requestors only use update messages if it is validly signed, confirmed using the ECDSA public key of the issuer of the credential type.
-
-Apps having a (nonrevoked) credential with witness $(u_i, e)$ (satisfying $u_i^{e} = \nu_i$) first compute the numbers $a, b$ which are such that $ae + b\tilde{e} = 1$, using the [Extended Euclidean algorithm](https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm), and then they update their witness as follows:
-
- $\displaystyle u_{i+1} = u_i^b\nu_{i+1}^a$
-
-This is valid against the new accumulator $\nu_{i+1}$:
-
-
-$
- \begin{eqnarray*}
- u_{i+1}^{e}
- &=& (u_i^b\nu_{i+1}^a)^{e}
- = u_i^{be}\nu_{i+1}^{ae} \\
- &=& \nu_i^{b}\nu_{i}^{ae/\tilde{e}}
- = (\nu_i^{b\tilde{e}}\nu_{i}^{ae})^{1/\tilde{e}}
- = (\nu_i^{b\tilde{e}+ae})^{1/\tilde{e}} \\
- &=& \nu_i^{1/\tilde{e}}
- = \nu_{i+1}
- \end{eqnarray*}
-$
-
-
-(The $\bmod n$ after each equality sign is implied.) The revoked credential having revocation attribute $\tilde{e}$ cannot use this algorithm and update message $(\nu_{i+1}, \tilde{e})$ to compute a new witness, as in this case there exist no integers $a, b$ such that $a\tilde{e} + b\tilde{e} = 1$. In fact, [one can prove that](http://static.cs.brown.edu/people/alysyans/papers/camlys02.pdf) knowing only $\nu_i$, $\nu_{i+1} = \nu_{i}^{1/\tilde{e}}$ and $\tilde{e}$, by the [Strong RSA assumption](https://en.wikipedia.org/wiki/Strong_RSA_assumption) which is used by both Idemix and the RSA-B accumulator scheme, *no* efficient algorithm can compute the correct witness $u_{i+1} = \nu_{i+1}^{1/\tilde{e}} = \nu_{i}^{1/\tilde{e}^2}$.
-
-Thus the app owning the revoked credential has no way to compute a new witness on its own without the issuer private key. Since the app no longer posesses a valid witness, it can no longer prove that it does, i.e., construct a nonrevocation proof: the credential is revoked.
diff --git a/website/versioned_docs/version-v0.13.0/schemes.md b/website/versioned_docs/version-v0.13.0/schemes.md
deleted file mode 100644
index 13635fb..0000000
--- a/website/versioned_docs/version-v0.13.0/schemes.md
+++ /dev/null
@@ -1,249 +0,0 @@
----
-title: IRMA schemes
-id: version-v0.13.0-schemes
-original_id: schemes
----
-
-In IRMA, every party ([Yivi apps](yivi-app.md), [IRMA servers](what-is-irma.md#irma-servers), [requestors](overview.md#participants)) must be aware of existing [credential types](overview.md#credential-types), attribute names, and the [issuers](overview.md#issuers) and their public keys. All such information is contained in IRMA *schemes*. It is the task of the *scheme manager* to determine and distribute this information to all parties, in the form of a directory structure [such as this one](https://github.com/privacybydesign/pbdf-schememanager), which contains:
-
-* All information about all issuers that fall under this scheme including their logos,
-* The IRMA public keys of said issuers,
-* All credential types that these issuers may issue, including their logos.
-
-This entire directory structure is signed using an (ECDSA) private-public keypair that the scheme manager has for this purpose.
-
-Each scheme has a *scheme URL*, defined by the `` tag in the root `description.xml`. At that location the scheme manager must host the current version of the scheme. IRMA components that have the scheme installed will periodically update their local version of the scheme using this remote copy.
-
-All of the information contained in the scheme is thus signed by as well as distributed by the scheme manager. This means that the scheme manager has exclusive and total control over which issuers may join his domain, and what credential types and attributes this issuer may issue.
-
-## Scheme contents
-
-Schematically the directory structure of a scheme looks as follows:
-
-```text
-scheme-id
-├── issuer-id
-│ ├── Issues
-│ │ └── credentialtype-id
-│ │ ├── description.xml
-│ │ └── logo.png
-│ ├── PublicKeys
-│ │ ├── 0.xml
-│ │ └── 1.xml
-│ ├── PrivateKeys (need not be present)
-│ │ ├── 0.xml
-│ │ └── 1.xml
-│ ├── description.xml
-│ └── logo.png
-├── description.xml
-├── index
-├── index.sig
-├── timestamp
-├── pk.pem
-└── kss-0.pem
-```
-
-Multiple issuers are grouped under the scheme, and each issuer may issue multiple credential types.
-
-Description of the files:
-* A scheme, issuer, or credential type (call it an *entity*) is always stored in `description.xml`, contained in a folder whose name *must* be that of the entity as specified by the xml file.
-* Each issuer and each credential type should include a `logo.png` for in the Yivi app.
-* `index` contains of each file in the tree its SHA256 hash, as well as its path and filename.
-* `index.sig` is an ECDSA signature over the `index`, thus effectively signing each file listed in the `index`.
-* `timestamp` contains the Unix timestamp of the last time the scheme was modified.
-* `pk.pem` is the scheme's public key against which `index.sig` should verify.
-* `kss-0.pem` (optional): if the scheme uses a [keyshare server](keyshare-protocol.md), then this contains the keyshare server's public key.
-
-IRMA schemes have the following nested structure: a scheme contains (multiple) issuers, which contain (multiple) credentials, which contain (multiple) attributes. Each of these are identified and referred to using a string that we call the *identifier*. In the case of schemes, issuers and credentials, these can be seen in the directory structure. In the directory tree above:
-
-* The identifier of the scheme is `scheme-id`,
-* This scheme contains an issuer whose identifier is `issuer-id`,
-* This issuer contains a credential type whose identifier is `credentialtype-id`.
-
-The `description.xml` of a credential type contains the definitions, including their identifiers, of the attributes contained within that credential type.
-
-These identifiers are used to refer to these entities within [IRMA session requests](session-requests.md), joined together using a dot `.` as separator. For example, the `description.xml` [below](#credential-types) shows the definition of the credential type `credentialtype-id` included in the directory tree above. This file contains an attribute whose identifier, as defined by the `id` XML attribute, is `boolean-attr`. Then the following would be a valid IRMA disclosure request that requests an Yivi app user to disclose this attribute:
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "scheme-id.issuer-id.credentialtype-id.boolean-attr" ]]]
-}
-```
-
-```golang
-irma.NewDisclosureRequest(irma.NewAttributeTypeIdentifier(
- "scheme-id.issuer-id.credentialtype-id.boolean-attr",
-))
-```
-
-
-IRMA identifiers may not themselves contain dots. Generally, only alphanumeric characters and the dash `-`are used.
-
-## File contents
-
-### Scheme
-
-The `description.xml` of a scheme looks like the following.
-
-```xml
-
- scheme-id
- https://example.com/scheme
- true
-
- English human-readable name
- Nederlandse human-readable naam
-
-
- A description of this scheme
- Een beschrijving van dit scheme
-
- https://example.com/atumd
- https://example.com/keyshareserver
- https://example.com/myirma
- scheme-id.issuer-id.credential-id.keyshare-attr
- https://example.com
-
-```
-
-* The `version` XML attribute of the `` tag is a constant, versioning the XML structure in the file.
-* The identifier of the issuer is specified by the `` tag (`scheme-id` in this example).
-* The `` tag points to the location where an online copy of this scheme is hosted, from which Yivi apps and servers update their local copies.
-* The `` tag, containing `true` or `false`, defines whether this is a demo or a production scheme. When `true`, the human-readable names (i.e., the contents of the `` tags) of all issuers and credential types within the scheme are required to start with the prefix `Demo `, and some requirements checked by `irma scheme verify` and `irma scheme sign` are slightly relaxed.
-* The `` defines which timestamp server is used for [attribute-based signatures](session-requests.md#attribute-based-signature-requests) that contain attributes from this scheme.
-* The ``, ``, and `` tags, when present, enable the use of a [keyshare server](keyshare-protocol.md) for this scheme, and define the URL of the keyshare server; the URL of the MyIRMA webinterface for it; and which attribute is used by the keyshare server, respectively.
-
-### Issuers
-
-The `description.xml` of an issuer looks like the following.
-
-```xml
-
- issuer-id
-
- English human-readable name
- Nederlandse human-readable naam
-
-
- English name
- Nederlandse naam
-
- scheme-id
- https://example.org
- example@example.org
-
-```
-
-* The `version` XML attribute of the `` tag is a constant, versioning the XML structure in the file.
-* The identifier of the issuer, specified by the `` tag (`issuer-id` in this example), must equal the folder name in which the file is stored.
-* The `` tag must contain the identifier of the containing scheme.
-* The `` tag should be present but is not currently shown in the Yivi app GUI or elsewhere.
-
-### Credential types
-
-The `description.xml` of a credential type looks like the following.
-
-```xml
-
-
- English human-readable name
- Nederlandse human-readable naam
-
-
- English name
- Nederlandse naam
-
- scheme-id
- issuer-id
- credential-id
-
- A description of this credential type
- Een beschrijving van dit credentialtype
-
-
- https://example.com/issue-url/en
- https://example.com/issue-url/nl
-
- true
-
-
-
-
- Boolean attribute
- Boolean attribuut
-
-
- A description of this boolean attribute
- Een beschrijving van dit boolean attribuut
-
-
-
-
- Optional attribute
- Optioneel attribuut
-
-
- A description of this optional attribute
- Een beschrijving van dit optionele attribuut
-
-
-
-
-```
-
-* The `version` XML attribute of the `` tag is a constant, versioning the XML structure in the file.
-* The identifier of the credential type, specified by the `` tag (`credential-id` in this example), must equal the folder name in which the file is stored.
-* The `` tag must contain the identifier of the containing issuer.
-* The `` tag must contain the identifier of the containing scheme.
-* The `` and `` tags should be present but are not currently shown in the Yivi app GUI or elsewhere.
-* The `` tag should contain translated URLs referring to where the user can obtain this credential. If the user refreshes an instance of the credential type, or tries to obtain it during a session, this URL is used.
-* The `` tag should contain either `true` or `false`, and determines if the user is allowed to possess more than one instance of the credential type simultaneously in her Yivi app. Default is `false`.
-
-An attribute is defined by an `` XML tag, which must at minimum contain an identifier in the `id` XML attribute, and `` and `` XML subtags. Additionally, the following XML attributes are supported:
-
-* `displayIndex`: Once an `` has been added to the credential type, its position relative to the other `` XML tags cannot be changed. However, its position as shown in the Yivi app may be set using the `displayIndex` XML attribute. In the example above, the Yivi app will first show the `optional-attr` and then the `boolean-attr`. If not present, the value of `displayIndex` is inferred from its position within the `` XML tag.
-* `optional`: if `true`, the issuer [may skip this attribute during issuance](session-requests.md#null-attributes), for example when the value of the corresponding attribute is unknown or not applicable.
-* `displayHint="yesno"`: used to indicate that the attribute will contain boolean values such as `yes`, `no`, `ja` or `nee` (case insensitive). When present, the Yivi app will translate the boolean to the user's language.
-
-New attributes can be added to existing credential types at any point in time. Existing attributes within a credential type may not be removed once they exist, but they may be marked `optional` so that the issuer can skip them during issuance.
-
-## Default schemes: `pbdf` and `irma-demo`
-
-Most IRMA software components automatically use the following two schemes:
-
-* [`pbdf`](https://github.com/privacybydesign/pbdf-schememanager): the production scheme of the [Privacy by Design Foundation](https://privacybydesign.foundation/).
-* [`irma-demo`](https://github.com/privacybydesign/irma-demo-schememanager): exclusively for development, demoing and experimenting, as the scheme private key and all issuer private keys are included.
-
-The [Privacy by Design Foundation](https://privacybydesign.foundation/), which develops IRMA and issues a basic set of attributes, is the scheme manager of these two schemes. New issuers wishing to issue attributes under the `pbdf` scheme, or existing issuers wishing to issue new credential types, can [ask](https://privacybydesign.foundation/people#developers) the Foundation to be included in these schemes.
-For more information on this process, see the [issuer documentation page](issuer.md).
-
-These two schemes are hardcoded into the [Yivi app](yivi-app.md), and if an [`irma`](irma-cli.md) subcommand that requires schemes is run for the first time, these two schemes are downloaded to a default location on disk (`~/.local/share/irma/irma_configuration` on Linux/macOS). It is always possible to use other schemes in conjunction with these two, or without them, either by making a custom build of the Yivi app, or by passing the appropriate options to the `irma` subcommands (see the `--help` messages).
-
-
-## Updating and signing schemes with `irma`
-
-The following `irma scheme` subcommands from the [`irma`](irma-cli.md) command line tool act on IRMA schemes:
-
-* `download`: Download a scheme from its remote URL
-* `issuer`: Manage IRMA issuers within an IRMA scheme
- * `keygen`: Generate a new IRMA issuer private/public keypair
-* `keygen`: Generate ECDSA private/public keypair for scheme signing
-* `sign`: Sign a scheme directory after update its contents
-* `update`: Download scheme updates from its remote URL
-* `verify`: Verify scheme signature and check directory structure
-
-Check `-h` or `--help` of these for usage details.
-
-## Other schemes
-
-Anyone can create their own IRMA scheme. At minimum the following must be done:
-
-* Create a directory structure like the one above (you can use the `scheme` subcommand of the [`irma`](irma-cli.md) command line tool to generate an ECDSA public-private keypair and sign the directory tree);
-* Define at least one issuer and generate its Idemix public-private keypair (again using `irma`), putting the public key in the directory structure;
-* Define at least one credential type that this issuer will issue;
-* Compile a version of the Yivi app with this directory tree hardcoded in it;
-* Host an [`irma server`](irma-server.md) that will issue and verify your credential type (as this server will issue credentials it must have a copy of the scheme directory tree, and the Idemix private key);
-* Create a website using [`irma-frontend`](irma-frontend.md) that will issue and verify instances of your credential type.
diff --git a/website/versioned_docs/version-v0.13.0/session-requests.md b/website/versioned_docs/version-v0.13.0/session-requests.md
deleted file mode 100644
index 41143dd..0000000
--- a/website/versioned_docs/version-v0.13.0/session-requests.md
+++ /dev/null
@@ -1,493 +0,0 @@
----
-title: Session requests
-id: version-v0.13.0-session-requests
-original_id: session-requests
----
-
-
-
-Each [IRMA server](what-is-irma.md#irma-servers) exposes APIs for creating IRMA sessions with a session request. An *IRMA session request* contains all information required for the IRMA server and [Yivi app](yivi-app.md) to perform an IRMA session with, such as the attributes to be issued or verified. This page documents IRMA session requests. It applies to:
-
-* The [`POST /session`](api-irma-server.md#post-session) endpoint from [`irma server`](irma-server.md).
-* The [`StartSession()` function](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver#StartSession) in the `irmaserver` Go library.
-* The [`startSession()` function](api-irmajs.md#startsession) of `irmajs`.
-
-For the precise role of session requests in an IRMA session, see this [diagram of an IRMA session](what-is-irma.md#irma-session-flow).
-
-## Session request data types
-
-For each of the [three IRMA session types](what-is-irma.md#session-types), we define a *session request* data type: an object whose JSON representation contains at least a [JSON-LD `@context`](https://w3c.github.io/json-ld-syntax/#the-context) key identifying which message type it is, and extra keys specific to the session type. The following three `@context` values identify disclosure, attribute-based signature, and issuance session requests respectively:
-
-* `"@context": "https://irma.app/ld/request/disclosure/v2"`
-* `"@context": "https://irma.app/ld/request/signature/v2"`
-* `"@context": "https://irma.app/ld/request/issuance/v2"`
-
-(For now these URIs do not resolve to anything; they just distinguish the message type.)
-
-## Disclosure requests
-Disclosure sessions are started with an [`irma.DisclosureRequest`](https://godoc.org/github.com/privacybydesign/irmago#DisclosureRequest). Example:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.MijnOverheid.root.BSN" ]
- ],
- [
- [
- "irma-demo.nijmegen.address.street",
- "irma-demo.nijmegen.address.houseNumber",
- "irma-demo.nijmegen.address.city"
- ],
- [
- "irma-demo.idin.idin.address",
- "irma-demo.idin.idin.city"
- ]
- ]
- ]
-}
-```
-
-```golang
-// Create a new empty request
-request := irma.NewDisclosureRequest()
-
-// Request specific attributes
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.root.BSN")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.nijmegen.address.street"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.houseNumber"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.city"),
- },
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.idin.idin.address"),
- irma.NewAttributeRequest("irma-demo.idin.idin.city"),
- },
- },
-}
-```
-
-
-
-
-This asks for a (demo) `BSN` attribute, as well as either `street`, `houseNumber` and `city` from `irma-demo.nijmegen.address`, or `address` and `city` from `irma-demo.idin.idin`. The three levels correspond to a *conjunction* of *disjunctions* of *conjunctions* of requested attributes, allowing verifiers to request multiple attribute sets from the user, offering choices for some or all of these sets.
-
-All of the attribute types (i.e., the string values) contained in the request must exist in their scheme ([`irma-demo`](https://github.com/privacybydesign/irma-demo-schememanager) in the example above). For the `irma-demo` and `pbdf` schemes, an index of existing attribute types that can be requested can be found [here](https://privacybydesign.foundation/attribute-index/en/).
-
-> Attributes can be disclosed to the requestor in any of the three session types: in issuance sessions issuance proceeds only if the user discloses the required attributes just before issuance, and in attribute-based signature sessions the requested attributes are attached to the resulting attribute-based signature. Thus the `disclose` and `labels` fields introduced above can also occur in issuance or attribute-based signature session requests (see below).
-
-### Multiple credential types within inner conjunctions
-In the request above 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).
-- 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 session request:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- "pbdf.pbdf.diploma.degree",
- "pbdf.pbdf.diploma.institute"
- ]
- ]
- ]
-}
-```
-
-```golang
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("pbdf.pbdf.diploma.degree"),
- irma.NewAttributeRequest("pbdf.pbdf.diploma.institute"),
- },
- },
-}
-```
-
-
-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.)
-
-When combining multiple credential types within a disjunction these restrictions ensure that when the Yivi app computes candidate attribute sets for the user to choose from, the amount of resulting options stays manageable. In adddition, the second restriction is a feature on its own, allowing verifiers to request multiple attributes coming from one credential instance.
-
-### Requesting specific attribute values
-Within inner conjunctions, specific attribute values can be requested by replacing the string with an object like the following:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "pbdf.pbdf.diploma.degree", "value": "PhD" },
- { "type": "pbdf.pbdf.diploma.institute", "value": null }
- ]
- ]
- ]
-}
-```
-
-```go
-phd := "PhD"
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.degree"),
- Value: &phd,
- }, {
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.institute"),
- Value: nil,
- }},
- },
-}
-```
-
-
-This would only be satisfied by a `degree` attribute whose value is `PhD`, together with any `institute` attribute. (Note that the object and string syntaxes can be mixed within an inner conjunction, i.e. it would be permissible in the JSON example above to replace the second object with just `"pbdf.pbdf.diploma.institute"`.)
-
-### Null attributes
-
-Whenever an attribute is marked with `optional` in the scheme ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)), the issuer may skip it when it issues an instance of the containing credential type, assigning a `null` value to it (which is distinct from the empty string `""`). When disclosing the attribute, the verifier receives `null` instead of a string containing the attribute value.
-
-If a non-null attribute is required this can be requested using `notNull` as follows:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "irma-demo.MijnOverheid.fullName.prefix", "notNull": true }
- ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("irma-demo.MijnOverheid.fullName.prefix"),
- NotNull: true,
- }},
- },
-}
-```
-
-
-The default value of `notNull` is `false`.
-
-### Optional disjunctions
-
-A disjunction within a session request can be marked as *optional*, by including an empty inner conjunction in it:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.nijmegen.address.city" ]
- ],
- [
- [],
- [ "irma-demo.MijnOverheid.fullName.firstname" ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.nijmegen.address.city")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{},
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.fullName.firstname")},
- },
-}
-```
-
-
-
-
-This can be useful when certain attributes are not required, so that if the user does not have them the session does not need to be aborted.
-
-### Disjunction labels
-
-Per disjunction a *label* can be specified, which is shown in the Yivi app when the user is asked for permission to disclose attributes. For example, the session request from [above](#disclosure-requests) could be augmented with a label for the second disjunction as follows:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [ ... ],
- [ ... ]
- ],
- "labels": {
- "1": { "en": "Work address", "nl": "Werk adres" }
- }
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Labels = map[int]irma.TranslatedString{
- 1: {"en": "Work address", "nl": "Werk adres"},
-}
-```
-
-
-
-
-In this way each disjunction can be given a optional label explaining to the user the purpose of the disjunction. It is recommended to only provide a label to explain something to the user that would otherwise not be obvious; for example, to request the user to send a work email address instead of a personal one. Repeating the credential or attribute name or description in labels is an antipattern.
-
-## Attribute-based signature requests
-Attribute-based signature sessions are started with an [`irma.SignatureRequest`](https://godoc.org/github.com/privacybydesign/irmago#SignatureRequest), which are similar to disclosure requests:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/signature/v2",
- "message": "Message to be signed by user",
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-request := irma.NewSignatureRequest("Message to be signed by user")
-request.Disclose = irma.AttributeConDisCon{ /* request attributes to attach to ABS */ }
-request.Labels = map[int]irma.TranslatedString{}
-```
-
-
-The `message` field is required. The attributes to be attached to the attribute-based signature are requested with the `disclose` field, which along with the `labels` field work exactly like in disclosure sessions.
-
-## Issuance requests
-Issuance sessions are started with an [`irma.IssuanceRequest`](https://godoc.org/github.com/privacybydesign/irmago#IssuanceRequest). Example:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/issuance/v2",
- "credentials": [{
- "credential": "irma-demo.MijnOverheid.ageLower",
- "validity": 1592438400,
- "attributes": {
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no"
- }
- }],
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-validity := irma.Timestamp(time.Unix(1592438400, 0))
-request := irma.NewIssuanceRequest([]*irma.CredentialRequest{
- {
- CredentialTypeID: irma.NewCredentialTypeIdentifier("irma-demo.MijnOverheid.ageLower"),
- Validity: &validity, // optional
- Attributes: map[string]string{
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no",
- },
- },
-})
-request.Disclose = irma.AttributeConDisCon{} // optional
-request.Labels = map[int]irma.TranslatedString{} // optional
-```
-
-
-Per credential in the `credentials` array the `validity` is optional; if skipped it is assigned the default value of 6 months. If present, the validity is always rounded down to the [nearest epoch boundary](overview.md#special-attributes), which is one week (60 * 60 * 24 * 7 = 604800 seconds).
-
-Attributes marked as `optional` in the containing credential type ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)) may be skipped in the `attributes` map. This issues [the `null` value](#null-attributes) to these attributes.
-
-`disclose` and `labels` are optional, allowing for *combined disclosure-issuance sessions*, in which the user is required to disclose attributes before the IRMA server will issue the credentials.
-
-The `clientReturnUrl` option can also be used, both for issuance only and combined disclosure-issuance sessions. Usage is similar as in [disclosure sessions](#client-return-url).
-
-## Client return URL
-If the user performs a mobile session, i.e. on the same device as where the Yivi app is installed on, then after the session has completed the user will be redirect to the `clientReturnUrl` specified in the session request, if present.
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- ...
- ],
- "clientReturnUrl": "https://example.com"
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.ClientReturnURL = "https://example.com"
-```
-
-
-The example shows a disclosure request but `clientReturnUrl` can be set on session requests of any type. If set, when the user finishes a session (either successfully or unsuccessfully), she is redirected to the location specified by `clientReturnUrl`.
-
-If *not* set:
-* On Android the Yivi app automatically toggles back to the previous app;
-* On iOS it is not possible to toggle back to the previous app due to restrictions by Apple, so the Yivi app stays open. In the top left corner of the screen, however, a button appears that leads back to the previous app.
-
-This URL does not necessarily have to be a web URL; it can also be a universal link to another app. Universal links work both on Android and iOS. It is also possible to use iOS or Android scheme URLs. (Note however that iOS and Android scheme URLs differ from one another, so when starting a session with a scheme URL as return URL you should therefore determine on which platform the user's app is running.)
-
-On iOS, toggling back to the calling app or website after the session can be simulated by navigating towards the calling app using a `clientReturnUrl`, either a normal URL or universal link. This works on Android as well, so currently this is the only platform-independent way of ensuring that the used ends up at a specified place after the session. If the URL opens a website, however, then the user is navigated towards a new browser tab instead of back to an existing browser tab, so in website-IRMA-website flows you will need to reload your webapp and state in the newly opened tab.
-
-### Augmenting the client return URL
-
-It is possible to have the IRMA server augment the `clientReturnUrl` with the server token of a session (i.e., the `token` in the [response of the `/session` endpoint](api-irma-server.md#post-session)). This token is then appended as a query parameter with name `token` to the `clientReturnUrl`. Using this token, one can the retrieve the [session result](api-irma-server.md#get-session-token-result).
-
-To enable this, both the server configuration flag `augment-client-return-url` needs to be enabled, as well as the `augmentReturnUrl` session request parameter needs to be true.
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- ...
- ],
- "augmentReturnUrl": true,
- "clientReturnUrl": "https://example.com"
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.ClientReturnURL = "https://example.com"
-request.AugmentReturnURL = true
-```
-
-
-In this example, the client return url would be augmented to become `https://example.com?token=0123456789abcdef`, where `0123456789abcdef` would be the server token of the session.
-
-## Extra parameters
-For each API that accepts one of the above session request data types, the requestor can provide additional parameters to configure the session at the IRMA server, by providing an *extended session request* instead, as follows:
-
-
-```json
-{
- "validity": 120,
- "timeout": 120,
- "callbackUrl": "https://example.com",
- "nextSession": {
- "url": "https://example.com/nextsession"
- },
- "request": ...
-}
-```
-
-```go
-// See also corresponding types irma.SignatureRequestorRequest
-// and irma.IdentityProviderRequest
-irma.ServiceProviderRequest{
- irma.RequestorBaseRequest{
- ResultJwtValidity: 120,
- ClientTimeout: 120,
- CallbackUrl: "https://example.com",
- NextSession: &irma.NextSessionData{URL: "https://example.com/nextsession"},
- },
- irma.NewDisclosureRequest(),
-}
-```
-
-
-Below you can find an overview of all extra parameters and their default value.
-
-| Option (JSON) | Option (Go) | Meaning | Default value |
-| ------------- | ----------- | ------- | ------------- |
-| `"validity"` | `ResultJwtValidity` | Validity of session result JWT in seconds (to determine JWT expiration time `exp`) | 120 seconds |
-| `"timeout"` | `ClientTimeout` | Wait this many seconds for the Yivi app to connect before the session times out | 300 seconds (5 minutes) |
-| `"callbackUrl"` | `CallbackUrl` | URL to post session result to | `""` (no callback is performed) |
-| `"nextSession"` | `NextSession` | Continue with a follow-up IRMA session when this session succeeds. The session result is posted to `URL`, and as response on the `POST` a new session request should be returned for the IRMA server to start. More documentation [here](chained-sessions.md). | `nil` (there is no next session) |
-
-More information about session lifetimes and timeouts can be found in the [IRMA server documentation](irma-server.md#session-lifetime).
-
-## JWTs: signed session requests
-The IRMA API server or [`irma server`](irma-server.md) can be configured such that it only accepts session requests that have been digitally signed in the form of a [JWT](https://jwt.io). The form of the JWT depends on the [session type](what-is-irma.md#session-types). An example requesting [IRMATube](https://privacybydesign.foundation/demo/irmaTube) attributes::
-```
-eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImlybWF0dWJlIn0.eyJpYXQiOjE1NjQ2NTczNzUsInN1YiI6InZlcmlmaWNhdGlvbl9yZXF1ZXN0Iiwic3ByZXF1ZXN0Ijp7InJlcXVlc3QiOnsiQGNvbnRleHQiOiJodHRwczovL2lybWEuYXBwL2xkL3JlcXVlc3QvZGlzY2xvc3VyZS92MiIsImRpc2Nsb3NlIjpbW1sicGJkZi5wYmRmLmlybWF0dWJlLnR5cGUiXV0sW1sicGJkZi5wYmRmLmFnZUxpbWl0cy5vdmVyMTIiXSxbInBiZGYuZ2VtZWVudGUucGVyc29uYWxEYXRhLm92ZXIxMiJdXV19fX0.lW9mqjrLkoahDP6Fcw_9mH5hlfl1tq5qp3W3ga0Nrd_j0NXFj-6ngqHVXEV1zhC_OkVH4LN8fMBAgN8nqaFWgEdQvrCuB7-ynuBVjLR-QU272Ym86zLEWYggAkbZ5KY40MpTxU1dgFMucG7fyAESic04OribWOCVxstAMsM28yCxvzkBMCOSjFEe3abcg_N6VvQnLn3LgZP_UrxQmQsh4DK7mBjW04LesLG1vjcliyhDGUb52FHOP_NAsG7G2FvIgojPzALlPrpTMu5p8a95wc5CGR791wybmh0F8kDdwZWAU0W2FjlX5bNPsyXN8AxRVWaRmWoGrGsQhy_sKEf8lg
-```
-In case of disclosure sessions, the body of the JWT (the part in between the two dots) contains a Base64-encoding of the following:
-
-
-```json
-{
- "iat": 1550424847,
- "sub": "verification_request",
- "sprequest": ...
-}
-```
-
-```go
-// Sets iat, iss, and sub fields.
-// See also corresponding functions irma.NewSignatureRequestorJwt()
-// and irma.NewIdentityProviderJwt().
-// Obtain signed JWT string to POST to an irma server using Sign() method.
-irma.NewServiceProviderJwt("IRMATube", irma.NewDisclosureRequest())
-```
-
-
-The fields are as follows:
-* `iat`: Unix timestamp of the creation date of the JWT. IRMA servers may reject JWTs beyond a certain age.
-* `iss`: contains the requestor name, and is used by the IRMA server to lookup the appropriate key with which to verify the JWT.
-* `sub`: JWT subject, in case of disclosure sessions this must always be `"verification_request"`.
-* `sprequest`: contains an extended disclosure session request as defined above.
-
-For each possible session type, the contents of the `sub` field and the name of the field containing the session request must be as follows.
-
-| Session type | `sub` contents | Session request field name | Go function |
-| ------------ | -------------- | -------------------------- | ----------- |
-| Disclosure | `verification_request` | `sprequest` | `irma.NewServiceProviderJwt()` |
-| Attribute-based signature | `signature_request` | `absrequest` | `irma.NewSignatureRequestorJwt()` |
-| Issuance | `issue_request` | `iprequest` | `irma.NewIdentityProviderJwt()` |
-
-Currently the following libraries can produce JWTs of this form:
-* The [`irmago`](https://godoc.org/github.com/privacybydesign/irmago) library, using the mentioned functions
-* The [`irmajs`](irmajs.md) Javascript library
-* The [`irma-requestor`](https://github.com/privacybydesign/irma-requestor) PHP library
-* The [`irma_api_common`](https://github.com/privacybydesign/irma_api_common) Java library
-* The [`irma-diva-js`](https://github.com/Alliander/diva-irma-js) Javascript library
-
-`irma server` currently supports JWTs signed (asymmetrically with RSA) with the `RS256` algorithm, and (symmetrically signed with HMAC-SHA256) `RS256`. The IRMA API server only supports `RS256`.
diff --git a/website/versioned_docs/version-v0.13.0/what-is-irma.md b/website/versioned_docs/version-v0.13.0/what-is-irma.md
deleted file mode 100644
index 3af7b4c..0000000
--- a/website/versioned_docs/version-v0.13.0/what-is-irma.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: What is IRMA?
-id: version-v0.13.0-what-is-irma
-original_id: what-is-irma
----
-
-IRMA is a set of free and open source software projects implementing the Idemix attribute-based credential scheme, allowing users to safely and securely authenticate themselves as privacy-preserving as the situation permits. Users receive digitally signed attributes from trusted issuer, storing them in their Yivi app, after which the user can selectively disclose attributes to others. Schematically:
-
-
-
-
-
-
-Using the issuer's digital signature over the attributes the verifier can verify that the attributes were given to the user in the past, and that they have not been modified since.
-
-## IRMA session flow
-
-A typical IRMA session is depicted schematically below.
-
-![IRMA session flow](assets/irmaflow.png)
-
-Software components:
-* *Requestor backend and frontend*: Generally the requestor runs a website with a (JavaScript) frontend in the user's browser, and a backend server. During an IRMA session the frontend displays the IRMA QR that the [Yivi app](yivi-app.md) scans. All frontend tasks depicted in the diagram are supported by [`irma-frontend`](irma-frontend.md).
-* [*IRMA server*](#irma-servers): Handles [IRMA protocol](irma-protocol.md) with the Yivi app for the requestor.
-* [*IRMA mobile app*](yivi-app.md): [Android](https://play.google.com/store/apps/details?id=org.irmacard.cardemu), [iOS](https://itunes.apple.com/nl/app/irma-authentication/id1294092994).
-
-Explanation of the steps:
-
-1. Usually the session starts by the user performing some action on the website (e.g. clicking on "Log in with IRMA").
-1. The requestor sends its [session request](session-requests.md) (containing the attributes to be disclosed or issued, or message to be signed) to the [IRMA server](#irma-servers). Depending on its configuration, the IRMA server accepts the session request only if the session request is authentic (e.g. a validly signed [session request JWT](session-requests.md#jwts-signed-session-requests)) from an authorized requestor.
-1. The IRMA server accepts the request and assigns a session token (a random string) to it. It returns the contents of the QR code that the frontend must display: the URL to itself and the session token.
-1. The frontend ([`irma-frontend`](irma-frontend.md)) receives and displays the QR code, which is scanned by the Yivi app.
-1. The Yivi app requests the session request from step 1, receiving the attributes to be disclosed or issued, or message to be signed.
-1. The IRMA server returns the session request.
-1. The Yivi app displays the attributes to be disclosed or issued, or message to be signed, and asks the user if she wants to proceed.
-1. The user accepts.
-1. The IRMA server performs the IRMA protocol with the Yivi app, issuing new attributes to the user, or receiving and verifying attributes from the user's Yivi app, or receiving and verifying an attribute-based signature made by the user's app.
-1. The session status (`DONE`, `CANCELLED`, `TIMEOUT`), along with disclosed and verified attributes or signature depending on the session type, are returned to the requestor.
-
-Additional notes:
-
-* Which of these tasks are performed by the requestor's backend and which by its frontend differs case by case:
- - Often the session request is sent to the IRMA server by the requestor's backend, after which the IRMA server's reply in step 2 is forwarded to the frontend which renders it as a QR code. Step 1 can however also be done by `irma-frontend`, in which case `irma-frontend` automatically picks up the IRMA server's reply in step 2 and renders the QR code.
- - Similarly, `irma-frontend` can be instructed to fetch the session result in step 10, but this can also be done in the backend. In the latter, `irma-frontend` can fetch a custom result at your backend, if desired.
-* The IRMA server could be deployed on the same machine as the requestor's backend, but it need not be; possibly it is not even controlled by the requestor. Generally, steps 2/3 and 10 are done with REST HTTP calls to the IRMA server, but in case the [`irmaserver`](irma-server-lib.md) library is used, these steps are function calls. Alternatively, you could use one of the packages in [`irma-backend-packages`](irma-backend.md) to do these steps with function calls in other programming languages.
-
-## Session types
-
-In an IRMA session, the [IRMA mobile app](yivi-app.md) performs one of the following three *session types* with an [*IRMA server*](#irma-servers):
-
-* *Disclosure sessions*: Upon receiving a list of requested attributes from the IRMA server, the app discloses the required attributes to the IRMA server if the app user agrees, after which they are verified by the IRMA server.
-* *Attribute-based signature sessions*: Similar to disclosure sessions, but the attributes are attached to a message digitally signed into an [*attribute-based signature*](overview.md#attribute-based-signatures). The attribute-based signature can be verified at any later time, ensuring that the signed message is intact, and that the IRMA attributes attached to it were valid at the time of creation of the attribute-based signature.
-* *Issuance sessions*: the Yivi app receives a new set of IRMA attributes including valid issuer signatures from the IRMA server, to use in later disclosure or attribute-based signature sessions. (Possibly the user is asked to disclose some attributes as well, within the same IRMA session, before receiving the new attributes. This is called a *combined issuance-disclosure session*.)
-
-This process is depicted schematically and explained in more detail in the [IRMA session flow](what-is-irma.md#irma-session-flow) chapter. For the user, after scanning the QR in his/her Yivi app a disclosure session generally looks like the following. (Attribute-based signature sessions and issuance sessions are identical in terms of their flow (scan qr, provide permission, success screen); only the graphical interface is different.)
-
-
-
-
-
-
-## IRMA servers
-
-Various existing software components documented on this website can perform the role of the IRMA server.
-Apart from exposing an API that is used by the [Yivi app](yivi-app.md) during IRMA sessions, each of these components also offer an API with which IRMA sessions can be started and monitored, for use by the [*requestor*](overview.md#participants): the party wishing to issue attributes to or verify attributes from an Yivi app. The IRMA server handles the IRMA session with the Yivi app for the requestor.
-
-Currently the following IRMA servers exist:
-
-* The `irma server` command of the [`irma`](irma-cli.md) binary: a standalone daemon exposing its requestor API as HTTP endpoints. [Documentation](irma-server.md); [API reference](api-irma-server.md).
-* The `irmaserver` Go library, exposing a HTTP server that handles IRMA sessions with the Yivi app, and Go functions for starting and managing IRMA sessions. [Documentation](irma-server-lib.mdrary); [API reference](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver).
-* The now deprecated [`irma_api_server`](https://github.com/privacybydesign/irma_api_server).
-
-## About this documentation
-
-IRMA uses JSON to pass messages within IRMA sessions. The majority of IRMA is [written in Go](https://github.com/privacybydesign/irmago), and the JSON messages generally correspond to specific Go structs. For example, the [`GET /session/{token}/result`](api-irma-server.md#get-session-token-result) endpoint of the [`irma server`](irma-server.md) outputs instances of the [`server.SessionResult`](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult). In such cases, a link to the corresponding Go struct will be included. This can tell you what fields you can use or expect. (Note that some structs have custom (un)marshalers. See also the [Go documentation](https://blog.golang.org/json-and-go) on JSON and Go.)
diff --git a/website/versioned_docs/version-v0.13.0/workshop.md b/website/versioned_docs/version-v0.13.0/workshop.md
deleted file mode 100644
index db8c160..0000000
--- a/website/versioned_docs/version-v0.13.0/workshop.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: May 22 IRMA Workshop
-id: version-v0.13.0-workshop
-original_id: workshop
----
-
-## Resources
-
-- Technical documentation: https://irma.app/docs
-- IRMA source code: https://github.com/privacybydesign/
-- Attribute index: https://privacybydesign.foundation/attribute-index/en/
-- Slack: ask for invite
-
-Other resources:
-- Privacy by Design Foundation website: https://privacybydesign.foundation/
-- Privacy by Design Foundation twitter: https://twitter.com/IRMA_privacy/
-- Attribute issuance: https://privacybydesign.foundation/issuance
-
-## Prerequisites
-
-Make sure you have installed the Yivi app on your [Android](https://play.google.com/store/apps/details?id=org.irmacard.cardemu) or [iOS](https://itunes.apple.com/nl/app/irma-authentication/id1294092994) device.
-
-If you haven't before, try one of the demos on our [demo page](https://privacybydesign.foundation/demo/). For many demos you need for example an [email or age limit attribute](https://privacybydesign.foundation/issuance/). [IRMATube](https://privacybydesign.foundation/demo/irmaTube) is an entirely self-contained demo.
-
-## Part 1
-
-For this part, follow the instructions in the [Getting Started](getting-started.md) page of the technical documentation. You will download or compile from source the IRMA command line tool, which includes the IRMA server. You then download or compile the `irmajs` JavaScript library and let the IRMA server host the static pages.
-
-This IRMA server automatically detects your LAN IP address, and adjusts the URL in the QR to match that address. This is necessary because the Yivi app on your phone somehow needs to connect to your server. However, not all network allow direct LAN access, especially not corporate wifi. Mobile hotspots often work well.
-
-#### Using a workshop server
-
-To bypass any compilation and network issues, you can also use one of our workshop Debian Linux servers over an SSH connection. Please reserve one by grabbing a token at the front of the room. Then edit and execute the following:
-
-```
-PASSWORD=...
-SERVER_NUMBER=01
-
-wget -O irma_workshop_id_rsa "https://irma.app/irma_workshop_id_rsa_${PASSWORD}"
-chmod 600 irma_workshop_id_rsa
-ssh -i irma_workshop_id_rsa "debian@irma${SERVER_NUMBER}.irma.app"
-```
-
-Add the `PASSWORD` you received during the workshop (as a super basic precaution). The private key gives access to all workshop servers. Enter the two-digit server number that's on your token as `SERVER_NUMBER`.
-
-You can then run the example with `./run_example.sh` and browse to the address listed in the output. The server is completely yours to use for purposes of the workshop, and can also be easily reset on request.
-
-
-## Part 2
-Integrate IRMA attribute verification in your own website or application, for example with one of the following use cases:
-
-* Use case 1: Instead of logging in with username/passwords, users can register and then login at your website by showing their IRMA email address attribute ([index](https://privacybydesign.foundation/attribute-index/en/pbdf.pbdf.email.html), [issuance](https://privacybydesign.foundation/issuance/email/), [info](https://privacybydesign.foundation/issuance-email/)).
-* Use case 2: Auto-fill an HTML form in your website by asking the user to disclose IRMA attributes, as in [this demo](https://privacybydesign.foundation/demo/adres/).
-* Use case 3: Ask your users to provide, for example, consent to receive ads per email, with an [attribute-based signature](what-is-irma.md#session-types).
-* Use case 4 (experimental): if you develop an iOS or Android app, start an IRMA session from within your app using these libraries: [iOS](https://github.com/privacybydesign/irmaios), [Android](https://github.com/privacybydesign/irmaandroid).
-
-## Advanced/take home exercises
-
-1. In production scenarios, you should switch to the [`pbdf`](https://github.com/credentials/pbdf-schememanager) [scheme](schemes.md), which contrary to the [`irma-demo`](https://github.com/credentials/irma-demo-schememanager) scheme contains actual personal data.
-2. Start issuing your own attributes, as follows:
- 1. Create a new credential type within the `irma-demo` scheme, and re-sign the scheme (`irma scheme sign`)
- 2. Create a custom build of the Yivi app [`irma_mobile`](yivi-app.md) with your modified `irma-demo` scheme in its `irma_configuration` folder
- 3. Start an `irma server` and point it to your modified `irma-demo` scheme, e.g. with the `--schemes-path` flag
- 4. Start an issuance session of your new credential type, e.g. by modifying the [`irmajs` browser demo](https://github.com/privacybydesign/irmajs)
-3. The HTTP endpoints exposed by the `irma server` are also available as Go functions in the [`irmaserver`](irma-server-lib.md) Go library, and as C functions [here](https://github.com/privacybydesign/irmago/tree/master/server/irmac). Enable IRMA attribute verification and issuance from your own favorite programming language by binding to these C functions.
\ No newline at end of file
diff --git a/website/versioned_docs/version-v0.13.0/yivi-app.md b/website/versioned_docs/version-v0.13.0/yivi-app.md
deleted file mode 100644
index 7143e78..0000000
--- a/website/versioned_docs/version-v0.13.0/yivi-app.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: Yivi app
-id: version-v0.13.0-yivi-app
-original_id: yivi-app
----
-
-
-
-
-
-
-
-
-The Yivi app allows users to receive and store digitally signed attributes from trusted issuers, after which they can be selectively disclosed to others. The app is essentially a GUI for the [`irmaclient`](https://github.com/privacybydesign/irmago/tree/master/irmaclient) Go package, which implements the client relative to the [IRMA server](irma-server.md). It is available in the iOS and Android app stores and may also be compiled from source.
-
-
-
-
-## Source code
-
-The source code of the Yivi app is published [on GitHub](https://github.com/privacybydesign/irmamobile/) under the [GPLv3 license](https://www.gnu.org/licenses/gpl-3.0.en.html).
-
-## Developer mode
-
-The Yivi app has a developer mode, which is disabled by default. It can be enabled by tapping 7 times on the version number at the bottom of the "More" tab on the home screen.
-
-While developer mode is disabled (default), the Yivi app will:
-- Block all HTTP connections that don't use TLS (i.e. the URL of the server must start with `https`), in order to prevent attributes from being sent unencrypted over the internet.
-- Block all HTTP connections to IRMA servers *not* running in [`production` mode](irma-server.md#production-mode). Since the majority of the Yivi app users will not have developer mode enabled, this requires IRMA servers facing those users to enable `production` mode (which makes the IRMA server switch to safer default values for some of its configuration options).
-
-Developer mode thus enables performing IRMA sessions with locally running IRMA servers, during development of an application using IRMA. After it has been enabled, a toggle will appear in the "Settings" screen with which it can be disabled again.
-
-For normal users this feature is made difficult to discover by design, for their protection. On the other hand, developers will notice its existence as soon as they try to do an IRMA session with a locally running IRMA server, by the error message displayed by the app.
-
-> Use developer mode with care: when enabled, the Yivi app will not protect you from accidentally sending your attributes unencrypted over the internet.
-> Furthermore, it enables access to debugging features that may make your Yivi app unstable.
diff --git a/website/versioned_docs/version-v0.14.0/irma-server.md b/website/versioned_docs/version-v0.14.0/irma-server.md
deleted file mode 100644
index 6d57d78..0000000
--- a/website/versioned_docs/version-v0.14.0/irma-server.md
+++ /dev/null
@@ -1,325 +0,0 @@
----
-title: irma server
-id: version-v0.14.0-irma-server
-original_id: irma-server
----
-
-
-`irma server` is an IRMA server executable (daemon) allowing you to perform IRMA sessions with
-[Yivi apps](yivi-app.md). It handles all IRMA-specific cryptographic details of issuing or verifying IRMA attributes with an Yivi app on behalf of a [requestor](overview.md#participants) (the application wishing to verify or issue attributes). It exposes the following:
- * HTTP endpoints under `/irma`, used by the Yivi app during IRMA sessions
- * a JSON API under `/sessions` for requestors, allowing them to request the server to verify or issue attributes.
-
-`irma server` is a subcommand of the [`irma`](irma-cli.md) command line tool, which additionally contains subcommands to start or perform IRMA sessions, handle [IRMA schemes](schemes.md), and more.
-
-For installation instructions, see [`irma`](irma-cli.md).
-
-## Running the server
-
-Simply run `irma server` to run the server with the default configuration in development mode. Use `irma server -v` for more verbose logging, for example to see the current configuration. Use `irma server -vv` to also log session contents.
-
-Run `irma server --help` to see configuration options. In order to verify your configuration, run `irma server check -v`.
-
-## Starting a session
-Assuming the server runs in the [default configuration](#default-configuration) (in particular [requestor authentication](#requestor-authentication) is disabled (`no_auth` is `true`) and the `irma-demo` [scheme](schemes.md) is installed), issue `irma-demo.MijnOverheid.ageLower` attributes using the [`session`](irma-cli.md) subcommand of the `irma` tool:
-```shell
-irma session --server http://localhost:8088 --issue irma-demo.MijnOverheid.ageLower=yes,yes,yes,no
-```
-Verify the `irma-demo.MijnOverheid.ageLower.over18` attribute:
-```shell
-irma session --server http://localhost:8088 --disclose irma-demo.MijnOverheid.ageLower.over18
-```
-These print QRs in your terminal that you can scan with your [Yivi app](yivi-app.md) to perform the session. For more extensive examples, see [irmajs](irmajs.md).
-
-## Configuring
-Run `irma server -h` to see all configuration options. Each option may be passed as:
- 1. a command line flags (e.g. [`--listen-addr`](#http-server-endpoints))
- 2. a environmental variable (e.g. `IRMASERVER_LISTEN_ADDR`)
- 3. an item in a configuration file (e.g. `"listen_addr"`) (which may be in JSON, TOML or YAML)
-
- with the following rules:
- * Flags supersede environmental variables which supersede configuration file entries.
- * Dashes are used in flags, but underscores are used in environmental variables and configuration file entries.
- * Environmental variables are uppercased and prefixed with `IRMASERVER_`.
- * The [`requestors`](#requestor-authentication) and [`static_sessions`](#static-irma-qrs) options are special: when passed as a flag or environmental variable, they must be passed as a JSON object (for example: `--requestors '{"myapp":{"auth_method":"token","key":"12345"}}'`).
- * When passing a boolean flag [use an `=`](https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax), for example [`--no-auth=false`](#requestor-authentication).
-
-In order to see the configuration that the server uses after having gathered input from these sources, specify `-v` or `-vv` or use the `verbose` option. Use `irma server check -v` (with the same flags, env vars and config files as `irma server`) to check your configuration for correctness before running the server.
-
-For a full configuation example, see [Getting started](getting-started.md#example-configuration-and-irma-session).
-
-In the remainder of this document, when referring to options we write them as configuration file entries, with underscores and without prefix.
-
-### Default configuration
-In the default configuration (run `irma server check -v` to see it) the server is immediately usable. In particular, it
-* uses the [default IRMA schemes](schemes.md#default-schemes-pbdf-and-irma-demo) ([`pbdf`](https://github.com/credentials/pbdf-schememanager) and [`irma-demo`](https://github.com/credentials/irma-demo-schememanager)), downloading them if necessary
-* allows anyone to use the server [without authentication](#requestor-authentication) (the `no_auth` setting is `true`)
-* saves the session state in memory.
-
-If the server is reachable from the internet, you should consider enabling authentication of session requests.
-
-### Configuration files
-A configuration file can be provided using the `config` option (for example: `irma server --config ./irmaserver.json`). When not specified, the server looks for a configuration file called `irmaserver.json` or `irmaserver.toml` or `irmaserver.yaml` in (1) the current path; (2) `/etc/irmaserver/`; (3) `$HOME/irmaserver`, in that order. A configuration file is not required; if none is found at any of these locations the server takes its configuration from just command line flags and environmental variables.
-
-### Production mode
-When running the server in production, you should enable the `production` option. This enables stricter defaults on the configuration options for safety and prints warnings on possibly unsafe configurations. In particular, when `production` is enabled, the default values of some options change as follows (cf. `diff <(irma server -h) <(irma server -h --production)`):
-
-* `url` from `"http://$YOUR_LOCAL_IP:port"` to `""`: in development mode the `url` to which Yivi apps will connect is set by default to your current local IP address; in `production` mode you must configure it yourself.
-* [`no_auth`](#requestor-authentication) from `true` to `false`: you should consider enabling requestor authentication, or explicitly disable this by setting this flag to `true`.
-* [`issue_perms`](#global-permissions) from `[*]` (everything) to `[]` (none).
-* [`no_email`](email.md) from `true` to `false`: in `production` mode, opting out of providing an email address can be done by explicitly setting this flag to `true`.
-
-In addition, when [developer mode is not enabled in the Yivi app](yivi-app.md#developer-mode) (the default setting), the Yivi app wil refuse to perform sessions with IRMA servers not running in `production` mode. Since the majority of the Yivi app users will not have developer mode enabled, this requires IRMA servers facing those users to enable `production` mode.
-
-### Stateless mode
-By default session states are kept in memory. If you want to run several IRMA servers in parallel or if you wish data persistence for sessions, you can use [stateless mode](stateless.md) which is implemented in the IRMA server via a Redis data store.
-
-You can enable the Redis data store in the `irma server` by setting the `store_type` option to `redis` and specifying the `redis_addr` and `redis_pw` options.
-
-### Keys and certificates
-For each configuration option that refers to some kind of key or certificate (for example `jwt_privkey`), there is a corresponding option with the `_file` suffix (for example `jwt_privkey_file`). Keys can be specified either by setting former to a (PEM) string, or setting the the latter to a file containing the (PEM) string.
-
-### HTTP server endpoints
-The HTTP endpoints that this server offers is split into two parts:
-* `/session`: used by the requestor to start sessions, check session status, or get session results.
-* `/irma`: used by the Yivi app during IRMA sessions.
-
-In the default mode, the server starts one HTTP server that offers both, configured with `listen_addr` and `port`. If however the `client_port` and `client_listen_addr` options are provided, then the server starts two separate HTTP servers:
-* `/session` attaches to the address and port provided with `port` and `listen_addr`.
-* `/irma` attaches to the address and port provided with `client_port` and `client_listen_addr`.
-
-The `/irma` endpoints must always be reachable for the Yivi app. Using this double server mode you can restrict access to the `/session` endpoints by e.g. setting `listen_addr` to `127.0.0.1` or to an interface only reachable from an internal network. Restricting access to the `/session` endpoints in this way may make requestor authentication unnecessary.
-
-### Requestor authentication
-The server runs in one of two modes: it either accepts all session requests from anyone that can reach the server, or it accepts only authenticated session requests from authorized requestors. This can be toggled with the `no_auth` boolean option. If the `/session` creation endpoint of your `irma server` is publicly accessible from the internet (i.e. the `client_port` option is used, see [above](#http-server-endpoints)), then you should consider enabling requestor authentication (i.e. turn `no_auth` off), otherwise anyone can use your `irma server`.
-
-The default is `true` (requests are not authenticated) when `production` is disabled and `false` otherwise.
-
-When authentication is enabled (`no_auth` is `false`), requestors that are authorized to use the server must be configured in the `requestor` option in the form of a map, for example:
-
-```json
-{
- "requestors": {
- "myapp": {
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-
-The server supports several authentication methods, one of which must be specified in the `auth_method` field for each requestor. The snippet above demonstrates the recommended and easiest to use authentication method, called `token`. When using this method the requestor must include the `key` as an API token in a HTTP header (for more details see the [API reference](api-irma-server.md#post-session)).
-
-In addition the server supports the following authentication methods:
-* `hmac`: the requestor symmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/), with HMAC-SHA256 (`HS256`) using `key`. The `key` provided should be the Base64 encoding of the actual secret.
-* `publickey`: the requestor asymmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/) with RSA (`RS256`), in this case `key` should be the PEM public key of the requestor.
-
-For each of these modes it is also possible to specify `key_file` instead `key`; in that case the file at `key_file` will be read and used as `key`.
-
-### Static IRMA QRs
-Unlike normal QRs which differ per session (as they contain the session token), the server also supports static QRs which, when scanned by the Yivi app, start preconfigured IRMA sessions. This makes it possible to for example print such a static QR. These preconfigured sessions are configured with the `static_sessions` options, for example:
-```json
-{
- "static_sessions": {
- "mystaticsession": {
- "callbackUrl": "https://example.com/callbackUrl",
- "request": {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "irma-demo.MijnOverheid.ageLower.over18" ]]]
- }
- }
- }
-}
-```
-Thus `static_sessions` must contain a map of which each item must be an [extended session request](session-requests.md#extra-parameters). Including a `callbackUrl` to which the [session result](api-irma-server.md#get-session-token-result) is sent after the session is required (since for these sessions there is no requestor waiting to receive the attributes after the session has finished). If a JWT private key is installed, then the session result is sent as a [JWT](api-irma-server.md#get-session-token-result-jwt).
-
-> If no JWT private key is installed, then the `callbackUrl` should either not be publically reachable, or it should include a secret token (e.g. https://example.com/cX5aTins5kEZpjDpfYcN) and have TLS enabled (which it should anyway as personal data will be POSTed to it). Otherwise there is no way of distinguishing POSTs from your `irma server` from POSTs made by someone else.
-
-Assuming the URL of the `irma server` is `http://example.com`, the session configured above is started when the Yivi app scans a QR with the following contents:
-```json
-{
- "irmaqr": "redirect",
- "u": "http://example.com/irma/session/mystaticsession"
-}
-```
-
-Only static [disclosure or attribute-based signature sessions](what-is-irma.md#session-types) are supported.
-
-### Permissions
-For each of the [three IRMA session types](what-is-irma.md#session-types) (attribute verification; attribute-based signature sessions; and attribute issuance), permission to use specific attributes/credentials can be granted to requestors in the configuration. For example, including permissions in the `myapp` requestor from above:
-```json
-{
- "requestors": {
- "myapp": {
- "disclose_perms": [ "irma-demo.MijnOverheid.ageLower.over18" ],
- "sign_perms": [ "irma-demo.MijnOverheid.ageLower.*" ],
- "issue_perms": [ "irma-demo.MijnOverheid.ageLower" ],
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-This means that `myapp` is authorized to request `irma-demo.MijnOverheid.ageLower.over18` in disclosure session, and any attribute from `irma-demo.MijnOverheid.ageLower` in attribute-based signature sessions. Additionally `myapp` can issue `irma-demo.MijnOverheid.ageLower` instances. In each level wildcards are permitted (`irma-demo.MijnOverheid.ageLower.*`, `irma-demo.MijnOverheid.*`, `irma-demo.*`, `*`). Thus `"disclose_perms": [ "*" ]` allows the requestor to verify any attribute.
-
-To use the [`host` option](session-requests.md#session-host) in session requests, you need to specify which hosts the requestor may use. You can do this by specifying `host_perms`. You can use glob patterns to grant permissions for a range of hosts.
-
-```json
- {
- "requestors": {
- "myapp": {
- ...
- "host_perms": ["*.example.com"]
- }
- }
- }
-```
-
-### Global permissions
-
-Global permissions can be applied to all requestors by using the global `disclose_perms`, `sign_perms` and `issue_perms` options. For each requestor, the effective set of permissions is the union of the permissions specified in its `requestors` map and the global permission set.
-
-The global options also work when `no_auth` is enabled. Thus in this case a session type can be disabled by granting no one the permission, e.g., `issue_perms: []` would disable issuance.
-
-In development mode, when `production` is `false`, the defaults for `disclose_perms`, `sign_perms` and `issue_perms` are `["*"]`. In order to protect any IRMA private keys that the server has access to from unintended use by others, when `production` is true the default of `issue_perms` is `[]`: no one can issue unless the global `issue_perms` is modified or unless specific requestors receive nonempty `issue_perms`.
-
-### Client return urls
-
-In session requests, the server can be asked to pass a [client return url](session-requests.md#client-return-url) to the Yivi app, which the app will open after completing the session for sessions that involve only one device. This feature is always enabled.
-
-### Session lifetime
-
-When a session is [started by the requestor](#starting-a-session), users have a limited amount of time to perform the session in their Yivi app. These lifetime constraints can be configured.
-
-By default, users have the maximum session lifetime to start the session in their Yivi app after it is started on the server. By default, this is set to 15 minutes. This global setting holds for all sessions on this server and can be changed in the configuration (see below). Per session, a custom timeout value can be chosen using the `timeout` option in the [extended session request](session-requests.md#extra-parameters).
-
-After a session is started by the user in the Yivi app, it has another full period of the maximum session lifetime to complete the session in their app. As mentioned above, this is 15 minutes by default. This part of the session lifetime is not affected by the `timeout` setting of the extended session request. The maximum session lifetime can be configured using the global `max_session_lifetime` option in the server configuration.
-
-When the user completes the session, the requestor has a limited amount of time to retrieve the session result from the server. By default, the lifetime of the session result on the server is 5 minutes. The session result lifetime can be configured using the global `session_result_lifetime` option in the server configuration.
-
-More information on how to configure global options for your server can be found [above](#configuring).
-
-### Augmented client return urls
-
-The server can be configured to [augment the client return url](session-requests.md#augmenting-the-client-return-url) when requested. In order to enable this feature, the `augment_client_return_url` setting needs to be set to `true`.
-
-### Static file hosting
-
-Apart from hosting endpoints under [`/session` and `/irma`](irma-server.md#http-server-endpoints), the server also supports statically hosting all files from a certain directory. This can be useful [for experimenting](getting-started.md#perform-browser-irma-session). It can be configured with the following options:
-
-* `static_path`: Host files under this path as static files. Leave empty to disable static file hosting.
-* `static_prefix`: Host static files under this URL prefix (default: no prefix)
-
-### IRMA schemes
-
-The server uses [IRMA schemes](schemes.md) to retrieve issuer, credential and attribute names, as well as public and private keys with which attributes can be verified an issued, respectively. By default the server uses the [`pbdf` and `irma-demo` schemes](schemes.md#default-schemes-pbdf-and-irma-demo). This can be configured with the following options:
-
-* `schemes_path`: path containing IRMA schemes (often called `irma_configuration`). Default: `C:\Users\Username\AppData\Local\irma\irma_configuration` on Windows, `$HOME/.local/share/irma/irma_configuration` otherwise. Created if it does not exist. If empty, the default schemes [`pbdf` and `irma-demo`](schemes.md#default-schemes-pbdf-and-irma-demo) are downloaded into it.
-* `schemes_assets_path`: path containing initial, read-only IRMA schemes. If specified, the schemes found here are copied into the path specified by `schemes_path`. Can be used to avoid downloading default schemes on first run.
-* `schemes_update`: update IRMA schemes from their scheme URL every this many minutes. Default is `60`. Set to `0` to disable automatic scheme updating (not recommended).
-
-### IRMA issuer private keys
-
-If IRMA issuer private keys are included in the server configuration, then the server can issue all credential types of all issuers for which private keys are installed. IRMA issuer private keys can be configured in the following two ways:
-
-* Include the private keys within the [IRMA scheme](schemes.md) in the issuer's `PrivateKeys` folder, with filenames `0.xml`, `1.xml`, etc ([example](https://github.com/privacybydesign/irma-demo-schememanager/tree/master/MijnOverheid/PrivateKeys)).
-* Set the `privkeys` option to a folder containing IRMA issuer private keys called `scheme.issuer.xml` or `scheme.issuer.counter.xml` (for example, `irma-demo.MijnOverheid.xml` or `irma-demo.MijnOverheid.2.xml`).
-
-If issuance is enabled in production and private keys are configured, then you should ensure that only authenticated requestors can start issuance requests (otherwise if anyone can use your server to issue attributes then those attributes cannot be trusted or used). You should either:
-
-* disable `no_auth` and [send authenticated session requests](irma-server.md#requestor-authentication),
-* Restrict the [`/session` HTTP endpoints](#http-server-endpoints) to a internal network interface only accessible by your applications and not from outside.
-
-Taking neither approach is an unsafe configuration as in that case anyone can create issuance sessions. In this case, if `production` mode is enabled then the server will refuse to run.
-
-### Signed JWT session results
-
-If a `jwt_privkey` (or `jwt_privkey_file`) is given, then the following endpoints are enabled:
-
-* `GET /session/{sessiontoken}/result-jwt`: returns the session result signed by the `irma server` into a JWT.
-* `GET /session/{sessiontoken}/getproof`: returns a JWT similar to the one from `result-jwt`, but with the same structure as the IRMA API server session result JWTs.
-* `GET /publickey`: returns the public key with which the JWTs output by this server can be verified.
-
-This can be useful if the session result travels along an unsafe or untrusted route from the IRMA server to the requestor. As long as the `irma server` is trusted and its public key is known, the JWT can be verified to ensure that the session result was untampered with since it left the `irma server`.
-
-### TLS
-
-The [IRMA protocol](irma-protocol.md) relies on TLS for encryption of the attributes as they travel along the internet. If your server is connected to the internet and it handles actual attributes (personal data from people), then you ***must*** ensure that the attributes are protected in transit with TLS. In its default configuration (i.e. with [developer mode](yivi-app.md#developer-mode) disabled), the Yivi app will refuse to connect to servers not using TLS.
-
-You can enable TLS in the `irma server` with the `tls_cert` and `tls_privkey` options (or the `_file` equivalents), specifying a PEM certificate (chain) and PEM private key. If you use [separate requestor and app endpoints](#http-server-endpoints), additionally use `client_tls_cert` and `client_tls_privkey`.
-
-Alternatively, if your IRMA server is connected to the internet through a reverse proxy then your reverse proxy probably handles TLS for you.
-
-### Email
-
-Users of the server are encouraged to provide an email address with the `email` option, subscribing for notifications about changes in the IRMA software or ecosystem. [More information](email.md). In `production` mode, it is required to either provide an email address or to explicitly out with the `no_email` option.
-
-### Logging and verbosity
-
-The server's verbosity can be increased by two degrees:
-* `-v` flag is given, or `verbosity` option set to `1`: includes `DEBUG` messages. Logs server configuration when starting the server, stack traces of errors, and more.
-* `-vv` flag is given, or `verbosity` option set to `2`: includes `TRACE` messages. Additionally includes dumps of all HTTP traffic from and to the server.
-
-> in its default mode, the server will not log untrusted user input and attribute values (personal data). If the verbosity is increased, sensitive or dangerous content may be logged. You should avoid doing this in production.
-
-The output is [structured](https://github.com/sirupsen/logrus#fields), putting certain recurring values in fields:
-```text
-[2019-02-28T20:51:09+01:00] INFO Session started action=disclosing session=WdypvSs97JTotpfl1Dtd
-```
-Outputting JSON is enabled with the `log-json` option:
-```json
-{"action":"disclosing","level":"info","msg":"Session started","session":"WdypvSs97JTotpfl1Dtd","time":"2019-02-28T20:51:09+01:00"}
-```
-
-## Running as daemon
-
-On most Linux systems, the `irma server` can be made into an automatically started daemon as follows:
-
-1. Write a new systemd unit file to `/etc/systemd/system/irmaserver.service`:
- ```ini
- [Unit]
- Description=IRMA server
- Documentation=https://irma.app/docs/irma-server
- Requires=network.target
-
- [Service]
- Type=simple
- ExecStart=/usr/local/bin/irma server --config=/etc/irmaserver/config.json
- TimeoutStopSec=60
- Restart=always
- RestartSec=1
- StandardOutput=syslog
- StandardError=syslog
- SyslogIdentifier=irma
- User=irmaserver
- Group=irmaserver
-
- [Install]
- WantedBy=multi-user.target
- ```
- Modify the path to `irma` and [your configuration file (or flags or environmental variables)](#configuring) in `ExecStart` as needed, as well as `User` and `Group`.
-2. Start the daemon and schedule it for automatic start on boot by running `systemctl start irmaserver.service && systemctl enable irmaserver.service`.
-
-See `systemctl status irmaserver.service` for the status of the daemon, and `journalctl -u irmaserver.service` for the console output of the IRMA server.
-
-## Design goals
-
-The server was designed with the following goals in mind.
-- Developer and user friendliness
- - Each of the [configuration options](#configuring) can be specified in a configuration file, command line flag, or environmental vars (see `-h`)
- - Default configuration (demo mode) is immediately useful
- - Thorough and configurable logging (`-v`, `-vv`; by default logs exclude attribute values)
- - Partial backwards compatibility with predecessor [`irma_api_server`](https://github.com/privacybydesign/irma_api_server)
- - Small startup time
-- Also available as [Go library](irma-server-lib.md) instead of standalone server
- - Bindings to other programming languages (Python, Ruby) are expected
-
-Being written in [Go](https://golang.org/), this server (in fact, the containing [`irma` binary](irma-cli.md)) additionally automatically has the following properties.
-- Simple to install (one binary, no dependencies, cross platform) and/or compile
-- [Reproducible builds](https://www.gnu.org/software/mes/manual/html_node/Reproducible-Builds.html)
-- [API documentation](https://godoc.org/github.com/privacybydesign/irmago) (generated automatically from `master` branch)
-
-Referring to Go packages (i.e. folders) under [`irmago`](https://github.com/privacybydesign/irmago), the server is structured as follows.
-* [`server/irmaserver`](irma-server-lib.md): Go library implementing the HTTP endpoints for the [IRMA protocol](irma-protocol.md) (in which the Yivi app is the client), and a Go API for requestors to manage sessons. ([Godoc API documentation](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver))
-* `server/requestorserver`: Go library wrapping `server/irmaserver`, exposing the requestor API as a second HTTP endpoint set under `/session` URLs instead of as Go functions (next to `/irma` for the Yivi app endpoints). ([Godoc API documentation](https://godoc.org/github.com/privacybydesign/irmago/server/requestorserver))
-* `irma`: executuable whose `server` commands wraps `server/requestorserver`.
diff --git a/website/versioned_docs/version-v0.14.0/session-requests.md b/website/versioned_docs/version-v0.14.0/session-requests.md
deleted file mode 100644
index 615b4cb..0000000
--- a/website/versioned_docs/version-v0.14.0/session-requests.md
+++ /dev/null
@@ -1,537 +0,0 @@
----
-title: Session requests
-id: version-v0.14.0-session-requests
-original_id: session-requests
----
-
-
-
-Each [IRMA server](what-is-irma.md#irma-servers) exposes APIs for creating IRMA sessions with a session request. An *IRMA session request* contains all information required for the IRMA server and [Yivi app](yivi-app.md) to perform an IRMA session with, such as the attributes to be issued or verified. This page documents IRMA session requests. It applies to:
-
-* The [`POST /session`](api-irma-server.md#post-session) endpoint from [`irma server`](irma-server.md).
-* The [`StartSession()` function](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver#StartSession) in the `irmaserver` Go library.
-* The [`startSession()` function](api-irmajs.md#startsession) of `irmajs`.
-
-For the precise role of session requests in an IRMA session, see this [diagram of an IRMA session](what-is-irma.md#irma-session-flow).
-
-## Session request data types
-
-For each of the [three IRMA session types](what-is-irma.md#session-types), we define a *session request* data type: an object whose JSON representation contains at least a [JSON-LD `@context`](https://w3c.github.io/json-ld-syntax/#the-context) key identifying which message type it is, and extra keys specific to the session type. The following three `@context` values identify disclosure, attribute-based signature, and issuance session requests respectively:
-
-* `"@context": "https://irma.app/ld/request/disclosure/v2"`
-* `"@context": "https://irma.app/ld/request/signature/v2"`
-* `"@context": "https://irma.app/ld/request/issuance/v2"`
-
-(For now these URIs do not resolve to anything; they just distinguish the message type.)
-
-## Disclosure requests
-Disclosure sessions are started with an [`irma.DisclosureRequest`](https://godoc.org/github.com/privacybydesign/irmago#DisclosureRequest). Example:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.MijnOverheid.root.BSN" ]
- ],
- [
- [
- "irma-demo.nijmegen.address.street",
- "irma-demo.nijmegen.address.houseNumber",
- "irma-demo.nijmegen.address.city"
- ],
- [
- "irma-demo.idin.idin.address",
- "irma-demo.idin.idin.city"
- ]
- ]
- ]
-}
-```
-
-```golang
-// Create a new empty request
-request := irma.NewDisclosureRequest()
-
-// Request specific attributes
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.root.BSN")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.nijmegen.address.street"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.houseNumber"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.city"),
- },
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.idin.idin.address"),
- irma.NewAttributeRequest("irma-demo.idin.idin.city"),
- },
- },
-}
-```
-
-
-
-
-This asks for a (demo) `BSN` attribute, as well as either `street`, `houseNumber` and `city` from `irma-demo.nijmegen.address`, or `address` and `city` from `irma-demo.idin.idin`. The three levels correspond to a *conjunction* of *disjunctions* of *conjunctions* of requested attributes, allowing verifiers to request multiple attribute sets from the user, offering choices for some or all of these sets.
-
-All of the attribute types (i.e., the string values) contained in the request must exist in their scheme ([`irma-demo`](https://github.com/privacybydesign/irma-demo-schememanager) in the example above). For the `irma-demo` and `pbdf` schemes, an index of existing attribute types that can be requested can be found [here](https://privacybydesign.foundation/attribute-index/en/).
-
-> Attributes can be disclosed to the requestor in any of the three session types: in issuance sessions issuance proceeds only if the user discloses the required attributes just before issuance, and in attribute-based signature sessions the requested attributes are attached to the resulting attribute-based signature. Thus the `disclose` and `labels` fields introduced above can also occur in issuance or attribute-based signature session requests (see below).
-
-### Multiple credential types within inner conjunctions
-In the request above 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).
-- 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 session request:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- "pbdf.pbdf.diploma.degree",
- "pbdf.pbdf.diploma.institute"
- ]
- ]
- ]
-}
-```
-
-```golang
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("pbdf.pbdf.diploma.degree"),
- irma.NewAttributeRequest("pbdf.pbdf.diploma.institute"),
- },
- },
-}
-```
-
-
-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.)
-
-When combining multiple credential types within a disjunction these restrictions ensure that when the Yivi app computes candidate attribute sets for the user to choose from, the amount of resulting options stays manageable. In adddition, the second restriction is a feature on its own, allowing verifiers to request multiple attributes coming from one credential instance.
-
-### Requesting specific attribute values
-Within inner conjunctions, specific attribute values can be requested by replacing the string with an object like the following:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "pbdf.pbdf.diploma.degree", "value": "PhD" },
- { "type": "pbdf.pbdf.diploma.institute", "value": null }
- ]
- ]
- ]
-}
-```
-
-```go
-phd := "PhD"
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.degree"),
- Value: &phd,
- }, {
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.institute"),
- Value: nil,
- }},
- },
-}
-```
-
-
-This would only be satisfied by a `degree` attribute whose value is `PhD`, together with any `institute` attribute. (Note that the object and string syntaxes can be mixed within an inner conjunction, i.e. it would be permissible in the JSON example above to replace the second object with just `"pbdf.pbdf.diploma.institute"`.)
-
-### Null attributes
-
-Whenever an attribute is marked with `optional` in the scheme ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)), the issuer may skip it when it issues an instance of the containing credential type, assigning a `null` value to it (which is distinct from the empty string `""`). When disclosing the attribute, the verifier receives `null` instead of a string containing the attribute value.
-
-If a non-null attribute is required this can be requested using `notNull` as follows:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "irma-demo.MijnOverheid.fullName.prefix", "notNull": true }
- ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("irma-demo.MijnOverheid.fullName.prefix"),
- NotNull: true,
- }},
- },
-}
-```
-
-
-The default value of `notNull` is `false`.
-
-### Optional disjunctions
-
-A disjunction within a session request can be marked as *optional*, by including an empty inner conjunction in it:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.nijmegen.address.city" ]
- ],
- [
- [],
- [ "irma-demo.MijnOverheid.fullName.firstname" ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.nijmegen.address.city")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{},
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.fullName.firstname")},
- },
-}
-```
-
-
-
-
-This can be useful when certain attributes are not required, so that if the user does not have them the session does not need to be aborted.
-
-### Disjunction labels
-
-Per disjunction a *label* can be specified, which is shown in the Yivi app when the user is asked for permission to disclose attributes. For example, the session request from [above](#disclosure-requests) could be augmented with a label for the second disjunction as follows:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [ ... ],
- [ ... ]
- ],
- "labels": {
- "1": { "en": "Work address", "nl": "Werk adres" }
- }
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Labels = map[int]irma.TranslatedString{
- 1: {"en": "Work address", "nl": "Werk adres"},
-}
-```
-
-
-
-
-In this way each disjunction can be given a optional label explaining to the user the purpose of the disjunction. It is recommended to only provide a label to explain something to the user that would otherwise not be obvious; for example, to request the user to send a work email address instead of a personal one. Repeating the credential or attribute name or description in labels is an antipattern.
-
-### Skip expiry check
-You can allow users to disclose expired instances of credentials. This is useful for [combined issuance-disclosure sessions](session-requests.md#issuance-requests) and [chained sessions](chained-sessions.md) if you only want to ensure that the user is still using the same device, and therefore the same [secret key](zkp.md), as during a previous issuance session.
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "irma-demo.MijnOverheid.root.BSN", "value": "12345" }
- ]
- ]
- ],
- "skipExpiryCheck": [ "irma-demo.MijnOverheid.root" ]
-}
-```
-
-## Attribute-based signature requests
-Attribute-based signature sessions are started with an [`irma.SignatureRequest`](https://godoc.org/github.com/privacybydesign/irmago#SignatureRequest), which are similar to disclosure requests:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/signature/v2",
- "message": "Message to be signed by user",
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-request := irma.NewSignatureRequest("Message to be signed by user")
-request.Disclose = irma.AttributeConDisCon{ /* request attributes to attach to ABS */ }
-request.Labels = map[int]irma.TranslatedString{}
-```
-
-
-The `message` field is required. The attributes to be attached to the attribute-based signature are requested with the `disclose` field, which along with the `labels` field work exactly like in disclosure sessions.
-
-## Issuance requests
-Issuance sessions are started with an [`irma.IssuanceRequest`](https://godoc.org/github.com/privacybydesign/irmago#IssuanceRequest). Example:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/issuance/v2",
- "credentials": [{
- "credential": "irma-demo.MijnOverheid.ageLower",
- "validity": 1592438400,
- "attributes": {
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no"
- }
- }],
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-validity := irma.Timestamp(time.Unix(1592438400, 0))
-request := irma.NewIssuanceRequest([]*irma.CredentialRequest{
- {
- CredentialTypeID: irma.NewCredentialTypeIdentifier("irma-demo.MijnOverheid.ageLower"),
- Validity: &validity, // optional
- Attributes: map[string]string{
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no",
- },
- },
-})
-request.Disclose = irma.AttributeConDisCon{} // optional
-request.Labels = map[int]irma.TranslatedString{} // optional
-```
-
-
-Per credential in the `credentials` array the `validity` is optional; if skipped it is assigned the default value of 6 months. If present, the validity is always rounded down to the [nearest epoch boundary](overview.md#special-attributes), which is one week (60 * 60 * 24 * 7 = 604800 seconds).
-
-Attributes marked as `optional` in the containing credential type ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)) may be skipped in the `attributes` map. This issues [the `null` value](#null-attributes) to these attributes.
-
-`disclose` and `labels` are optional, allowing for *combined disclosure-issuance sessions*, in which the user is required to disclose attributes before the IRMA server will issue the credentials.
-
-The `clientReturnUrl` option can also be used, both for issuance only and combined disclosure-issuance sessions. Usage is similar as in [disclosure sessions](#client-return-url).
-
-## Client return URL
-If the user performs a mobile session, i.e. on the same device as where the Yivi app is installed on, then after the session has completed the user will be redirect to the `clientReturnUrl` specified in the session request, if present.
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- ...
- ],
- "clientReturnUrl": "https://example.com"
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.ClientReturnURL = "https://example.com"
-```
-
-
-The example shows a disclosure request but `clientReturnUrl` can be set on session requests of any type. If set, when the user finishes a session (either successfully or unsuccessfully), she is redirected to the location specified by `clientReturnUrl`.
-
-If *not* set:
-* On Android the Yivi app automatically toggles back to the previous app;
-* On iOS it is not possible to toggle back to the previous app due to restrictions by Apple, so the Yivi app stays open. In the top left corner of the screen, however, a button appears that leads back to the previous app.
-
-This URL does not necessarily have to be a web URL; it can also be a universal link to another app. Universal links work both on Android and iOS. It is also possible to use iOS or Android scheme URLs. (Note however that iOS and Android scheme URLs differ from one another, so when starting a session with a scheme URL as return URL you should therefore determine on which platform the user's app is running.)
-
-On iOS, toggling back to the calling app or website after the session can be simulated by navigating towards the calling app using a `clientReturnUrl`, either a normal URL or universal link. This works on Android as well, so currently this is the only platform-independent way of ensuring that the used ends up at a specified place after the session. If the URL opens a website, however, then the user is navigated towards a new browser tab instead of back to an existing browser tab, so in website-IRMA-website flows you will need to reload your webapp and state in the newly opened tab.
-
-### Augmenting the client return URL
-
-It is possible to have the IRMA server augment the `clientReturnUrl` with the server token of a session (i.e., the `token` in the [response of the `/session` endpoint](api-irma-server.md#post-session)). This token is then appended as a query parameter with name `token` to the `clientReturnUrl`. Using this token, one can the retrieve the [session result](api-irma-server.md#get-session-token-result).
-
-To enable this, both the server configuration flag `augment-client-return-url` needs to be enabled, as well as the `augmentReturnUrl` session request parameter needs to be true.
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- ...
- ],
- "augmentReturnUrl": true,
- "clientReturnUrl": "https://example.com"
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.ClientReturnURL = "https://example.com"
-request.AugmentReturnURL = true
-```
-
-
-In this example, the client return url would be augmented to become `https://example.com?token=0123456789abcdef`, where `0123456789abcdef` would be the server token of the session.
-
-## Session host
-The host in the `sessionPtr` field of the [session package](api-irma-server.md#post-session) can be configured using the `host` option in the session request. This is useful when the IRMA server can be reached through multiple URLs. In this way, a single IRMA server can be used to serve multiple requestors, each with their own hostname. The hostname is being shown to the user in the Yivi app. The IRMA server will verify that the hostname the Yivi app connects to matches the hostname in the session request.
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "host": "irma.example.com",
- "disclose": ...
-}
-```
-This leads to the following session package:
-```json
-{
- "token":"KzxuWKwL5KGLKr4uerws",
- "sessionPtr": {"u":"https://irma.example.com/irma/session/ysDohpoySavbHAUDjmpz","irmaqr":"disclosing"},
- "frontendRequest": {
- "authorization":"qGrMmL8UZwZ88Sq8gobV",
- "minProtocolVersion": "1.0",
- "maxProtocolVersion": "1.1"
- }
-}
-```
-
-The `host` field is optional. If not set, the `url` from the server's [configuration](irma-server.md#configuring) will be used as-is. In this case, the IRMA server will not check which host the Yivi app connects to. The Yivi app on the other hand will check that the TLS certificate being used is correct.
-
-When you use `irma server`, you should explicitly specify [requestor permissions](irma-server.md#permissions) for this. Otherwise, only the hostname from the `url` in the server's [configuration](irma-server.md#configuring) will be allowed. When you use the [IRMA server library](irma-server-lib.md), no permission restrictions are imposed. If you need restrictions, then you have to implement this yourself.
-
-## Extra parameters
-For each API that accepts one of the above session request data types, the requestor can provide additional parameters to configure the session at the IRMA server, by providing an *extended session request* instead, as follows:
-
-
-```json
-{
- "validity": 120,
- "timeout": 120,
- "callbackUrl": "https://example.com",
- "nextSession": {
- "url": "https://example.com/nextsession"
- },
- "request": ...
-}
-```
-
-```go
-// See also corresponding types irma.SignatureRequestorRequest
-// and irma.IdentityProviderRequest
-irma.ServiceProviderRequest{
- irma.RequestorBaseRequest{
- ResultJwtValidity: 120,
- ClientTimeout: 120,
- CallbackUrl: "https://example.com",
- NextSession: &irma.NextSessionData{URL: "https://example.com/nextsession"},
- },
- irma.NewDisclosureRequest(),
-}
-```
-
-
-Below you can find an overview of all extra parameters and their default value.
-
-| Option (JSON) | Option (Go) | Meaning | Default value |
-| ------------- | ----------- | ------- | ------------- |
-| `"validity"` | `ResultJwtValidity` | Validity of session result JWT in seconds (to determine JWT expiration time `exp`) | 120 seconds |
-| `"timeout"` | `ClientTimeout` | Wait this many seconds for the Yivi app to connect before the session times out | 300 seconds (5 minutes) |
-| `"callbackUrl"` | `CallbackUrl` | URL to post session result to | `""` (no callback is performed) |
-| `"nextSession"` | `NextSession` | Continue with a follow-up IRMA session when this session succeeds. The session result is posted to `URL`, and as response on the `POST` a new session request should be returned for the IRMA server to start. More documentation [here](chained-sessions.md). | `nil` (there is no next session) |
-
-More information about session lifetimes and timeouts can be found in the [IRMA server documentation](irma-server.md#session-lifetime).
-
-## JWTs: signed session requests
-The IRMA API server or [`irma server`](irma-server.md) can be configured such that it only accepts session requests that have been digitally signed in the form of a [JWT](https://jwt.io). The form of the JWT depends on the [session type](what-is-irma.md#session-types). An example requesting [IRMATube](https://privacybydesign.foundation/demo/irmaTube) attributes::
-```
-eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImlybWF0dWJlIn0.eyJpYXQiOjE1NjQ2NTczNzUsInN1YiI6InZlcmlmaWNhdGlvbl9yZXF1ZXN0Iiwic3ByZXF1ZXN0Ijp7InJlcXVlc3QiOnsiQGNvbnRleHQiOiJodHRwczovL2lybWEuYXBwL2xkL3JlcXVlc3QvZGlzY2xvc3VyZS92MiIsImRpc2Nsb3NlIjpbW1sicGJkZi5wYmRmLmlybWF0dWJlLnR5cGUiXV0sW1sicGJkZi5wYmRmLmFnZUxpbWl0cy5vdmVyMTIiXSxbInBiZGYuZ2VtZWVudGUucGVyc29uYWxEYXRhLm92ZXIxMiJdXV19fX0.lW9mqjrLkoahDP6Fcw_9mH5hlfl1tq5qp3W3ga0Nrd_j0NXFj-6ngqHVXEV1zhC_OkVH4LN8fMBAgN8nqaFWgEdQvrCuB7-ynuBVjLR-QU272Ym86zLEWYggAkbZ5KY40MpTxU1dgFMucG7fyAESic04OribWOCVxstAMsM28yCxvzkBMCOSjFEe3abcg_N6VvQnLn3LgZP_UrxQmQsh4DK7mBjW04LesLG1vjcliyhDGUb52FHOP_NAsG7G2FvIgojPzALlPrpTMu5p8a95wc5CGR791wybmh0F8kDdwZWAU0W2FjlX5bNPsyXN8AxRVWaRmWoGrGsQhy_sKEf8lg
-```
-In case of disclosure sessions, the body of the JWT (the part in between the two dots) contains a Base64-encoding of the following:
-
-
-```json
-{
- "iat": 1550424847,
- "sub": "verification_request",
- "sprequest": ...
-}
-```
-
-```go
-// Sets iat, iss, and sub fields.
-// See also corresponding functions irma.NewSignatureRequestorJwt()
-// and irma.NewIdentityProviderJwt().
-// Obtain signed JWT string to POST to an irma server using Sign() method.
-irma.NewServiceProviderJwt("IRMATube", irma.NewDisclosureRequest())
-```
-
-
-The fields are as follows:
-* `iat`: Unix timestamp of the creation date of the JWT. IRMA servers may reject JWTs beyond a certain age.
-* `iss`: contains the requestor name, and is used by the IRMA server to lookup the appropriate key with which to verify the JWT.
-* `sub`: JWT subject, in case of disclosure sessions this must always be `"verification_request"`.
-* `sprequest`: contains an extended disclosure session request as defined above.
-
-For each possible session type, the contents of the `sub` field and the name of the field containing the session request must be as follows.
-
-| Session type | `sub` contents | Session request field name | Go function |
-| ------------ | -------------- | -------------------------- | ----------- |
-| Disclosure | `verification_request` | `sprequest` | `irma.NewServiceProviderJwt()` |
-| Attribute-based signature | `signature_request` | `absrequest` | `irma.NewSignatureRequestorJwt()` |
-| Issuance | `issue_request` | `iprequest` | `irma.NewIdentityProviderJwt()` |
-
-Currently the following libraries can produce JWTs of this form:
-* The [`irmago`](https://godoc.org/github.com/privacybydesign/irmago) library, using the mentioned functions
-* The [`irmajs`](irmajs.md) Javascript library
-* The [`irma-requestor`](https://github.com/privacybydesign/irma-requestor) PHP library
-* The [`irma_api_common`](https://github.com/privacybydesign/irma_api_common) Java library
-* The [`irma-diva-js`](https://github.com/Alliander/diva-irma-js) Javascript library
-
-`irma server` currently supports JWTs signed (asymmetrically with RSA) with the `RS256` algorithm, and (symmetrically signed with HMAC-SHA256) `RS256`. The IRMA API server only supports `RS256`.
diff --git a/website/versioned_docs/version-v0.14.2/api-irma-frontend.md b/website/versioned_docs/version-v0.14.2/api-irma-frontend.md
deleted file mode 100644
index 03c22ca..0000000
--- a/website/versioned_docs/version-v0.14.2/api-irma-frontend.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: IRMA frontend packages
-id: version-v0.14.2-api-irma-frontend
-original_id: api-irma-frontend
----
-
-The IRMA frontend packages have been renamed to [Yivi frontend packages](api-yivi-frontend.md).
diff --git a/website/versioned_docs/version-v0.14.2/api-irma-server.md b/website/versioned_docs/version-v0.14.2/api-irma-server.md
deleted file mode 100644
index 58e16f1..0000000
--- a/website/versioned_docs/version-v0.14.2/api-irma-server.md
+++ /dev/null
@@ -1,294 +0,0 @@
----
-title: irma server
-id: version-v0.14.2-api-irma-server
-original_id: api-irma-server
----
-
-```shell
-irma server [options...]
-```
-
-The API that this server offers consists of two parts:
-
-* [Endpoints under `/session`](#api-reference-requestor-endpoints) with which IRMA session requestors can start IRMA sessions, monitor their status and retrieve their result afterwards.
-* [Endpoints under `/irma`](#api-reference-irma-endpoints) for [frontend libraries](yivi-frontend.md) and the [irmaclient](https://github.com/privacybydesign/irmago/tree/master/irmaclient)/[Yivi app](yivi-app.md).
- * [Frontend endpoints under `/irma`](#api-reference-irma-frontend-endpoints) exclusively for [frontend libraries](yivi-frontend.md).
-
----
-## API overview
-
-
-
----
-
-For each of these endpoints, if the HTTP status code indicates that the request was not successful (i.e. not in the 2xx range), then the server returns an [`irma.RemoteError`](https://godoc.org/github.com/privacybydesign/irmago#RemoteError) instance. For example, attempting to [retrieve the session result](#get-session-requestortoken-result) of an unknown session returns:
-```json
-{"status": 400, "error": "SESSION_UNKNOWN", "description": "Unknown or expired session"}
-```
-The following fields may occur in this message:
-* `status`: HTTP error code associated to this error
-* `error`: an error `Type` from the list of possible errors in the [server API documentation](https://godoc.org/github.com/privacybydesign/irmago/server#Error)
-* `description`: English human-readable description of this error
-* `message`: May contain additional information
-* `stacktrace`: Stack trace of the error, only if verbose mode is enabled
-
-## API reference requestor endpoints
-
----
-
-### `POST /session`
-
-Start an IRMA session. What to POST to this endpoint depends on the server configuration:
-
-* If `no_auth` is true, an [(extended) JSON session request](session-requests.md)
-* If `no_auth` is false:
- * [(extended) JSON session request](session-requests.md) with an API token in the `Authorization` HTTP header
- * [JWT session request](session-requests.md#jwts-signed-session-requests) signed with RS256 or HS256
-
-If `no_auth` is false, then which of these options should be taken depends on the [`requestors`](irma-server.md#requestor-authentication) option passed to the `irma server`.
-
-In each case an appropriate `Content-Type` with `text/plain` or `application/json` must be included.
-
-If the request was successfully parsed, and authenticated if applicable, then the server returns a *session package*:
-```json
-{
- "token":"KzxuWKwL5KGLKr4uerws",
- "sessionPtr": {"u":"https://example.com/irma/session/ysDohpoySavbHAUDjmpz","irmaqr":"disclosing"},
- "frontendRequest": {
- "authorization":"qGrMmL8UZwZ88Sq8gobV",
- "minProtocolVersion": "1.0",
- "maxProtocolVersion": "1.1"
- }
-}
-```
-In the endpoints below, the `{requestorToken}` placeholder must be replaced with the above session `token`. The `sessionPtr` points to the IRMA session for the Yivi app user, and should be displayed as a QR for the user to scan, or encoded in a universal link for a mobile session, e.g. using [`yivi-frontend`](api-yivi-frontend.md).
-The final part of the `u` field in the `sessionPtr` is called the `clientToken`. The `clientToken` can be used to access the [public `/irma` endpoints](#api-reference-irma-endpoints) of the irma server.
-For accessing and using the [`/irma` frontend endpoints](#api-reference-irma-frontend-endpoints), you need the `frontendRequest`.
-
-Each session starts in the `"INITIALIZED"` [session status](#get-session-requestortoken-status). Regardless of how it reaches its ending status (`"DONE"`, `"CANCELLED"`, `"TIMEOUT"`), it is kept in memory for 5 minutes after reaching its ending status. After that all endpoints below requiring the requestor `token` return error `"SESSION_UNKNOWN"`.
-
----
-
-### `DELETE /session/{requestorToken}`
-
-Cancel the session: set the [session status](#get-session-requestortoken-status) to `"CANCELLED"`.
-
-> There is also a [variant of this endpoint](#delete-irma-session-clienttoken) for frontends (and Yivi apps) using client tokens (the final part of the `u` field in a `sessionPtr`).
-
----
-
-### `GET /session/{requestorToken}/status`
-
-Retrieve the [session status](https://godoc.org/github.com/privacybydesign/irmago/server#Status) as a JSON string. Returns one of:
-* `"INITIALIZED"`: the session has been started and is waiting for the client
-* `"PAIRING"`: the client is waiting for the frontend to [give permission to connect](#post-irma-session-clienttoken-frontend-pairingcompleted)
-* `"CONNECTED"`: the client has retrieved the session request, we wait for its response
-* `"CANCELLED"`: the session is cancelled: the user refused, or the user did not have the requested attributes, or an error occurred during the session
-* `"DONE"`: the session has completed successfully
-* `"TIMEOUT"`: session timed out
-
-Of these the latter three are *ending statuses*; once the session reaches such a status, it will not switch status again. A session starts as `"INITIALIZED"`. When being in a non-ending status (one of the first three), all statuses below that status in the list are possible next statuses.
-
-> The session is cancelled and receives status `"CANCELLED"` not only when the Yivi app user refuses, but also when the session is aborted due to an error.
-
-> If the session is cancelled due to the user aborting, it is (by design) not possible using this or the other endpoints of the `irma server` to distinguish between (1) the user had the requested attributes but refused to disclose them, and (2) the session was aborted by the user's Yivi app because (s)he did not have the required attributes.
-
-> There is also a [variant of this endpoint](#get-irma-session-clienttoken-status) for frontends (and Yivi apps) using client tokens (the final part of the `u` field in a `sessionPtr`).
-
----
-
-### `GET /session/{requestorToken}/statusevents`
-
-Subscribe to a [server-sent event](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events) stream of status updates. Whenever the session status changes, an event is sent with the new session status as a JSON string. If you need to monitor the status of a session, this is preferred over polling to `GET /session/{requestorToken}/status`.
-
-> There is also a [variant of this endpoint](#get-irma-session-clienttoken-statusevents) for frontends (and Yivi apps) using client tokens (the final part of the `u` field in a `sessionPtr`)
-
----
-
-### `GET /session/{requestorToken}/result`
-
-Get the [session result](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult). Example output:
-```json
-{
- "type" : "disclosing",
- "status" : "DONE",
- "disclosed" : [
- [{
- "status" : "PRESENT",
- "rawvalue" : "yes",
- "id" : "irma-demo.MijnOverheid.ageLower.over18",
- "value" : {
- "en" : "yes",
- "nl" : "yes",
- "" : "yes"
- }
- }]
- ],
- "proofStatus" : "VALID",
- "token" : "ELMExi5iauWYHzbH7gwU"
-}
-```
-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"`
-* `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
- * `"INVALID_TIMESTAMP"`: Attribute-based signature has invalid timestamp
- * `"UNMATCHED_REQUEST"`: proofs do not correspond to a specified request
- * `"MISSING_ATTRIBUTES"`: proofs do not contain all requested attributes
- * `"EXPIRED"`: Attributes were expired at creation time
-* `disclosed`: List of [attributes disclosed](https://godoc.org/github.com/privacybydesign/irmago#DisclosedAttribute) by the user. The array structure mirrors that of the [session request](session-requests#disclosure-requests) that started the session: the i-th item of the outer array is a conjunction of attributes satisfying the i-th outer conjunction of the session request. (*Note*: if the session was started with a legacy, pre-[condiscon](condiscon.md) session request, then this array structure has a different legacy structure; see the [legacy documentation](/v0.2.0/api-irma-server#get-session-requestortoken-result))
-* `signature`: The full attribute-based signature in case of `"signing"` sessions
-* `error`: Error message in case of failure
-
-If the session is not yet finished (that is, the session status is `INITIALIZED` or `CONNECTED`), then only the first three fields are populated. (For getting just the current session status, using [`GET /session/{requestorToken}/statusevents`](#get-session-requestortoken-statusevents) or [`GET /session/{requestorToken}/status`](#get-session-requestortoken-status) is preferred.)
-
-This endpoint just fetches the session result, and works normally even if the session failed. If so, the `status`, `proofStatus` or `error` fields will indicate what happened. Be sure to check these fields when retrieving and handling the session result.
-
----
-
-### `GET /session/{requestorToken}/result-jwt`
-
-If a JWT private key was [provided in the configuration of the `irma server`](irma-server.md#signed-jwt-session-results), then this returns a [JWT](https://jwt.io) signed by the `irma server` with the message from [`GET /session/{requestorToken}/result`](#get-session-requestortoken-result) above as JWT body, along with the following standard JWT fields:
-* `iss`: name of the current `irma server` as defined in its configuration
-* `iat`: Unix timestamp indicating when this JWT was created
-* `sub`: `verification_result` or `signing_result` or `issuing_result`
-
-This way, even if the session result from the `irma server` travels along an untrusted route (for example the user's browser), the session result can still be validated and trusted.
-
----
-
-### `GET /session/{requestorToken}/getproof`
-
-Also returns a session result JWT, but one whose structure is the same as the session JWTs returned by the [`irma_api_server`](https://github.com/privacybydesign/irma_api_server). Only works if a JWT private key was [provided in the configuration of the `irma server`](irma-server.md#signed-jwt-session-results).
-
----
-
-### `GET /publickey`
-
-If a JWT private key was [provided in the configuration of the `irma server`](irma-server.md#signed-jwt-session-results), then this returns the corresponding public key in PEM with which the server's session result JWTs returned by [`GET /session/{requestorToken}/result-jwt`](#get-session-requestortoken-result-jwt) and [`GET /session/{requestorToken}/getproof`](#get-session-requestortoken-getproof) can be verified.
-
----
-
-## API reference `/irma` endpoints
-The `/irma` endpoints of your IRMA server have to be publicly reachable from the internet. Most of the endpoints
-behind the `/irma` prefix are exclusively used by the
-[irmaclient](https://github.com/privacybydesign/irmago/tree/master/irmaclient)/[Yivi app](yivi-app.md).
-These endpoints are documented in full in the page on the [IRMA protocol](irma-protocol.md).
-The endpoints used by both the Yivi app and the [frontend libraries](yivi-frontend.md) are documented below.
-The endpoints exclusively meant for frontend libraries can be found below [in a separate section](#api-reference-irma-frontend-endpoints).
-
----
-
-### `DELETE /irma/session/{clientToken}`
-Behaves exactly the same as the [delete endpoint for requestors](#delete-session-requestortoken), but uses the
-[client token from the `sessionPtr`](#post-session) instead of the requestor token.
-
----
-
-### `GET /irma/session/{clientToken}/status`
-Behaves exactly the same as the [status endpoint for requestors](#get-session-requestortoken-status), but uses the [client token
-from the `sessionPtr`](#post-session) instead of the requestor token. For frontend libraries, this endpoint is deprecated.
-Please use the [frontend status endpoint](#get-irma-session-clienttoken-frontend-status) instead.
-
----
-
-### `GET /irma/session/{clientToken}/statusevents`
-Behaves exactly the same as the [statusevents endpoint for requestors](#get-session-requestortoken-statusevents), but uses the
-[client token from the `sessionPtr`](#post-session) instead of the requestor token. For frontend libraries this endpoint is deprecated.
-Please use the [frontend statusevents endpoint](#get-irma-session-clienttoken-frontend-statusevents) instead.
-
----
-
-## API reference `/irma` frontend endpoints
-The frontend endpoints are exclusively meant for [frontend libraries](yivi-frontend.md) to communicate with the IRMA server.
-Frontends need the information from the `frontendRequest` in order to use these endpoints. The `frontendRequest` is received
-along with the `sessionPtr` from the [`POST /session`](#post-session) requestor endpoint.
-Just like the [other `/irma` endpoints](#api-reference-irma-endpoints), the frontend endpoints of your IRMA server
-have to be publicly reachable from the internet.
-
-To make sure these endpoints can only be accessed by frontends, requests should be done with an
-additional `Authorization` HTTP request header. The expected value for this request header is the `authorization`
-token in the `frontendRequest`.
-
-The frontend endpoints in this version of the IRMA server implement frontend protocol version 1.1.
-
-### `GET /irma/session/{clientToken}/frontend/status`
-Retrieve the current [session status](https://godoc.org/github.com/privacybydesign/irmago/server#Status), and additional information
-being relevant for that session status, as a JSON object.
-
-The JSON object always contains a `status` field, containing the session status as being described in [status endpoint for requestors](#get-session-requestortoken-status).
-Additionally, when the session status is `DONE`, the `nextSession` field might be included.
-It contains the `sessionPtr` of the IRMA session following up the current session (a chained session).
-This happens when the `nextSession` option is used as [extra parameter in the session request](session-requests.md#extra-parameters).
-
-
-Below you can find an example response:
-```json
-{
- "status" : "DONE",
- "nextSession": {"u":"https://example.com/irma/ysDohpoySavbHAUDjmpz","irmaqr":"disclosing"}
-}
-```
-
-### `GET /irma/session/{clientToken}/frontend/statusevents`
-Subscribe to a [server-sent event](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events) stream of status updates.
-Whenever the session status changes, an event is sent as a JSON object. This JSON object follows the exact same format as the
-output of the [frontend status endpoint](#get-irma-session-clienttoken-frontend-status).
-If you need to monitor the status of a session, this is preferred over polling the frontend status endpoint.
-
-### `POST /irma/session/{clientToken}/frontend/options`
-This endpoint can be used to set pairing options for an IRMA session. Specific options can be sent to this endpoint and
-in the response an overview of the current pairing options is sent. If an options request holds an invalid combination
-of options, an error is returned.
-
-Session options can be changed multiple times. However, as soon as an
-[irmaclient](https://github.com/privacybydesign/irmago/tree/master/irmaclient)/[Yivi app](yivi-app.md)
-has connected to the session, it is not possible to change the options anymore. In other words, this
-endpoint can only be used when the [session status](#get-irma-session-clienttoken-frontend-status) is `"INITIALIZED"`.
-
-The body of an options request should have the following structure:
-```json
-{
- "@context": "https://irma.app/ld/request/frontendoptions/v1",
- "pairingMethod": "..."
-}
-```
-
-Currently we only have one option, the option `pairingMethod`. It can have two values:
- * `"pairingMethod": "none"` **(default value)**
- No device pairing is used. This is the normal, already known behaviour.
- * `"pairingMethod": "pin"`
- When an [irmaclient](https://github.com/privacybydesign/irmago/tree/master/irmaclient)/[Yivi app](yivi-app.md)
- connects to a session in which pairing is enabled, the [session status](#get-irma-session-clienttoken-frontend-status)
- becomes `PAIRING`. The irmaclient shows a 4 digit pairing code and only after the user correctly enters this code
- in the frontend the session continues, and the status becomes `CONNECTED`. This method can be
- used when a user is expected to scan an IRMA QR code using his/her phone and there is a risk on shoulder surfing
- (i.e. someone in close physical proximity to the user scans the QR code that was meant for the user).
-
- Pairing confirmation can be communicated by the frontend using the [`pairingcompleted` endpoint](#post-irma-session-clienttoken-frontend-pairingcompleted).
-
- When this option is requested, the session options response on this request will contain an extra field
- `pairingCode` containing the expected 4 digit code.
-
-A response of this endpoint has the following structure:
-```json
-{
- "@context": "https://irma.app/ld/options/v1",
- "pairingMethod": "pin",
- "pairingCode": "1234"
-}
-```
-
-If the `pairingMethod` field has the value `none`, the `pairingCode` field is omitted.
-
----
-
-### `POST /irma/session/{clientToken}/frontend/pairingcompleted`
-This endpoint can be used by the frontend to confirm the pairing of the frontend
-and the [irmaclient](https://github.com/privacybydesign/irmago/tree/master/irmaclient)/[Yivi app](yivi-app.md).
-The endpoint can only be used while the [session status](#get-session-requestortoken-status) is set to `PAIRING`.
-A valid request to this endpoint will cause the session status to change from `PAIRING` to `CONNECTED`.
-When the request succeeds, a `204 No Content` response is returned.
diff --git a/website/versioned_docs/version-v0.14.2/api-irmajs.md b/website/versioned_docs/version-v0.14.2/api-irmajs.md
deleted file mode 100644
index e00f12a..0000000
--- a/website/versioned_docs/version-v0.14.2/api-irmajs.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: irmajs
-id: version-v0.14.2-api-irmajs
-original_id: api-irmajs
----
-
-The irmajs JavaScript library is deprecated. Please use the [Yivi frontend packages](api-yivi-frontend.md).
diff --git a/website/versioned_docs/version-v0.14.2/api-yivi-frontend.md b/website/versioned_docs/version-v0.14.2/api-yivi-frontend.md
deleted file mode 100644
index 99fb260..0000000
--- a/website/versioned_docs/version-v0.14.2/api-yivi-frontend.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: Yivi frontend packages
-id: version-v0.14.2-api-yivi-frontend
-original_id: api-yivi-frontend
----
-
-The Yivi frontend packages consist of multiple packages. Therefore we describe the API per package.
-The API description of the Yivi frontend plugins is combined into one section.
-
-## Yivi core
-The [Yivi core](yivi-frontend.md#yivi-core) package only exports the `YiviCore` class. To handle an IRMA session,
-an instance of this class can be made with the relevant options for your session. The options object is shared
-between all plugins that are registered at the `YiviCore` instance. The plugins don't need to be configured
-individually. The options that can be specified depend on the specific plugins you are using. You can find all
-possible options in the READMEs of the plugins. You can find an overview of all available Yivi core plugins
-[here](#plugins).
-
-The Yivi core class has one constructor:
-```javascript
-const YiviCore = require('@privacybydesign/yivi-core');
-const yivi = new YiviCore({/* Options */});
-```
-
-Below you can find an overview of all methods an Yivi core instance offers you.
-
-| Method | Functionality |
-|---|---|
-| `use(/* Plugin*/)` | With this method plugins can be added to the Yivi core instance. This method takes care of instantiating the plugin. You simply pass the plugin class as an argument to this function; you must not instantiate the plugin yourself.|
-| `start()` | The start method activates the state machine. From then the Yivi core instance is ready to be used and no plugins can be added to the instance anymore. It returns a promise that resolves when a session is finished successfully and rejects when a unrecoverable error occurs. By calling Yivi core's `start` method, the plugins will be started too.|
-| `abort()` | The abort method forces an `yivi-core` instance to abort the session and all associated plugins should stop making changes. In this way you can stop the instance from being active when it is not relevant anymore. If a promise returned by the `start` method is still active, the promise will be rejected with error message `Aborted`.|
-
-For an example of how the Yivi core API can be used, you can also check the [usage guide](yivi-frontend.md#usage-guide).
-
-## Yivi frontend
-[Yivi frontend](yivi-frontend.md#yivi-frontend) is a wrapper
-package around Yivi core combined with several of its plugins and the default [`yivi-css`](yivi-frontend.md#yivi-css)
-styling. The package can only be used in web browser environments.
-
-It exports two functions:
-
-| Function | Functionality |
-|---|---|
-| `newWeb({/* Options */})` | With this method an `YiviCore` instance is initialized, using the given options, configured to control an embedded web element. The options that can be used are all options from [`yivi-client`](https://github.com/privacybydesign/yivi-frontend-packages/tree/master/plugins/yivi-client) and [`yivi-web`](https://github.com/privacybydesign/yivi-frontend-packages/tree/master/plugins/yivi-web).
-| `newPopup({/* Options */})` | With this method an `YiviCore` instance is initialized, using the given options, configured to start a popup overlay. The options that can be used are all options from [`yivi-client`](https://github.com/privacybydesign/yivi-frontend-packages/tree/master/plugins/yivi-client) and [`yivi-popup`](https://github.com/privacybydesign/yivi-frontend-packages/tree/master/plugins/yivi-popup).
-
-Both functions return an interface with the following methods:
-
-| Method | Functionality |
-|---|---|
-| `start()` | Calls the `start` method of the initialized `YiviCore` instance and returns the promise it gets as result.
-| `abort()` | Calls the `abort` method of the initialized `YiviCore` instance.
-
-When importing this library via a `
-```
-
-You can then instantiate `yivi-frontend` and start a session like this when using an embedded web element:
-```javascript
-const exampleWeb = yivi.newWeb({
- debugging: false, // Enable to get helpful output in the browser console
- element: '#yivi-web-form', // Which DOM element to render to
-
- // Back-end options
- session: {
- // Configure your flow here, see usage guide of yivi-core
- },
-
- ...
-});
-
-exampleWeb.start()
-.then(result => console.log("Successful disclosure! 🎉", result))
-.catch(error => console.error("Couldn't do what you asked 😢", error));
-```
-
-When you want a popup overlay to be used to, you can do the following:
-```javascript
-const examplePopup = yivi.newPopup({
- debugging: false, // Enable to get helpful output in the browser console
-
- // Back-end options
- session: {
- // Configure your flow here, see usage guide of yivi-core
- },
-
- ...
-});
-
-examplePopup.start()
-.then(result => console.log("Successful disclosure! 🎉", result))
-.catch(error => console.error("Couldn't do what you asked 😢", error));
-```
-
-Be aware that you can start an instance of `yivi-frontend` only once.
-When you want to call `start()` again, you have to create a new instance.
-When a promise of an earlier `start()` call is not completed yet, promise rejection
-can be forced by calling the `abort()` method. In this way a new `yivi-frontend`
-instance can be created without any risk on interference with other running instances.
-When a promise is rejected because of an `abort()` call, the promise will return the
-error message `Aborted`.
-
-```javascript
-exampleWeb.abort();
-examplePopup.abort();
-```
-
-More information about the methods the Yivi frontend package offers to you can be found
-in the [API overview](api-yivi-frontend.md#yivi-frontend).
-
-## Yivi css
-For the Yivi core plugins `yivi-web` and `yivi-popup` we made it possible to manually include the style
-that it will use. We provide to you a [normal version](https://github.com/privacybydesign/yivi-frontend-packages/releases/latest/download/yivi.css)
-and a [minified version](https://github.com/privacybydesign/yivi-frontend-packages/releases/latest/download/yivi.min.css)
-of the default styles. The CSS can be linked into your website the regular way:
-
-```html
-
-```
-
-When you want to adapt the design to suit for your own use case, you can take a look in the [styleguide](https://privacybydesign.github.io/yivi-frontend-packages/styleguide/).
-Based on this you can adapt the CSS and then import the modified version into your project.
-Customized versions of `yivi-css` can be used in combination with the `yivi-web` and
-`yivi-popup` plugins for `yivi-core`.
-
-### Customizing the design
-Customizing the design is especially useful for developers that want to use an embedded
-web element to initiate the Yivi flow and see that the default design does not fit
-into the design of their website. We provide you a convenient way to alter the
-design and build a new, customized style. This can be done in the following way:
-
-1. Clone the [`yivi-frontend-packages` repository](https://github.com/privacybydesign/yivi-frontend-packages).
-2. Use our [guide](https://github.com/privacybydesign/yivi-frontend-packages/tree/master/yivi-css#compiling-locally)
- to compile the CSS styleguide locally.
-3. Make the desired changes in the source files. These files can be found in the
- `yivi-css/src` directory.
-4. Check **all pages** of the locally built styleguide to check whether your local
- changes work for all flows.
-5. Build a release version for your customized CSS by running `npm run release` in the
- `yivi-css` directory. The built CSS files can be found in the `yivi-css/dist` directory.
-6. Include the new style in your website and use [Yivi core](#yivi-core) in combination
- with the `yivi-web` plugin (for embedded web elements) or the `yivi-popup` plugin (for
- a popup overlay). The plugins will use the custom CSS that you have embedded. For
- managing the session state we recommend you to use the `yivi-client` plugin.
-
-```javascript
-require('assets/my-custom-yivi-css-design.min.css');
-
-const YiviCore = require('@privacybydesign/yivi-core');
-const YiviWeb = require('@privacybydesign/yivi-web');
-const YiviClient = require('@privacybydesign/yivi-client');
-
-const yivi = new YiviCore({
- debugging: true,
- element: '#yivi-web-form',
- language: 'en',
- // Check the yivi-web README on how to customize the default texts.
- session: {
- // Check the yivi-client README for all options.
- },
-});
-
-yivi.use(YiviWeb);
-yivi.use(YiviClient);
-
-yivi.start()
-.then(result => console.log("Successful disclosure! 🎉", result))
-.catch(error => {
- if (error === 'Aborted') {
- console.log('We closed it ourselves, so no problem 😅');
- return;
- }
- console.error("Couldn't do what you asked 😢", error);
-});
-```
-
-## Make your own Yivi core plugin
-If you need functionality that is not covered by one of the existing Yivi core plugins, you can also define
-one yourself. In the constructor the `stateMachine` and the `options` from `YiviCore` can be accessed.
-The constructor can be omitted if you do not need it.
-Furthermore, a plugin can have a `start` method that is
-called when the `start` method of the associated `YiviCore` instance is called, a `stateChange` method
-that is called when the state of the state machine changes, and a `close` method (check the explanation below for details).
-
-```javascript
-class YiviPlugin {
- // Optional
- constructor({stateMachine, options}) {
- ...
- }
-
- // Optional method
- start() {
- ...
- }
-
- // Optional method
- stateChange({newState, oldState, transition, isFinal, payload}) {
- ...
- }
-
- // Optional method
- close() {
- // May return a Promise when the closing operation is async;
- // yivi-core will then wait for the Promise to be completed.
- ...
- }
-}
-```
-
-A plugin can request the state machine to make changes. This can be done using the `transition` and
-`finalTransition` methods of the `stateMachine`. The first parameter of these functions is the requested
-transition. The possible transitions can be found in the [state machine](https://github.com/privacybydesign/yivi-frontend-packages/blob/master/yivi-core/state-transitions.js).
-As second parameter `payload` can be added to the transition. The payload can then be accessed by all other plugins
-as it is one of the parameters of the `stateChange` method. When requesting a `finalTransition`, the state
-machine will be locked in the new state. From then no transitions can be made anymore. For a `finalTransition`
-the potential `newState` must be in the list of possible end states. Otherwise, an error is returned. After
-a `finalTransition` the `close` method of the plugin is called to close the plugin's state. This method should
-return a Promise which resolves when the plugin finishes closing. When the `close` Promises of all plugins are
-resolved, the promise returned by the `start` method of `YiviCore` will resolve or reject (depending on the
-transaction). In this way we can guarantee that plugins are not active anymore when the promise returned by the
-`start` method of `YiviCore` is finished. Besides when calling `finalTransition`, the closing procedure can also
-be activated when the `transition` method is used and the state machine gets in a state from which no
-transitions are possible anymore.
-
-For example, in the `YiviPopup` plugin the user can press on the close button in the UI to abort the session.
-When this happens the `YiviPopup` plugin must request a state change at the Yivi core state machine to
-notify all other plugins that the new state becomes `Aborted`. This is done in the following way:
-```javascript
-stateMachine.transition('abort', 'Popup closed');
-```
-
-There are no transitions possible anymore from the state `Aborted`. This means that unless the transition
-is not explicitly marked as final, the `stateChange` method of your plugin will be called with `isFinal` set
-to true.
diff --git a/website/versioned_docs/version-v0.15.0/irma-server.md b/website/versioned_docs/version-v0.15.0/irma-server.md
deleted file mode 100644
index 5432751..0000000
--- a/website/versioned_docs/version-v0.15.0/irma-server.md
+++ /dev/null
@@ -1,331 +0,0 @@
----
-title: irma server
-id: version-v0.15.0-irma-server
-original_id: irma-server
----
-
-
-`irma server` is an IRMA server executable (daemon) allowing you to perform IRMA sessions with
-[Yivi apps](yivi-app.md). It handles all IRMA-specific cryptographic details of issuing or verifying IRMA attributes with an Yivi app on behalf of a [requestor](overview.md#participants) (the application wishing to verify or issue attributes). It exposes the following:
- * HTTP endpoints under `/irma`, used by the Yivi app during IRMA sessions
- * a JSON API under `/sessions` for requestors, allowing them to request the server to verify or issue attributes.
-
-`irma server` is a subcommand of the [`irma`](irma-cli.md) command line tool, which additionally contains subcommands to start or perform IRMA sessions, handle [IRMA schemes](schemes.md), and more.
-
-For installation instructions, see [`irma`](irma-cli.md).
-
-## Running the server
-
-Simply run `irma server` to run the server with the default configuration in development mode. Use `irma server -v` for more verbose logging, for example to see the current configuration. Use `irma server -vv` to also log session contents.
-
-Run `irma server --help` to see configuration options. In order to verify your configuration, run `irma server check -v`.
-
-## Starting a session
-Assuming the server runs in the [default configuration](#default-configuration) (in particular [requestor authentication](#requestor-authentication) is disabled (`no_auth` is `true`) and the `irma-demo` [scheme](schemes.md) is installed), issue `irma-demo.MijnOverheid.ageLower` attributes using the [`session`](irma-cli.md) subcommand of the `irma` tool:
-```shell
-irma session --server http://localhost:8088 --issue irma-demo.MijnOverheid.ageLower=yes,yes,yes,no
-```
-Verify the `irma-demo.MijnOverheid.ageLower.over18` attribute:
-```shell
-irma session --server http://localhost:8088 --disclose irma-demo.MijnOverheid.ageLower.over18
-```
-These print QRs in your terminal that you can scan with your [Yivi app](yivi-app.md) to perform the session. For more extensive examples, see [irmajs](irmajs.md).
-
-## Configuring
-Run `irma server -h` to see all configuration options. Each option may be passed as:
- 1. a command line flags (e.g. [`--listen-addr`](#http-server-endpoints))
- 2. a environmental variable (e.g. `IRMASERVER_LISTEN_ADDR`)
- 3. an item in a configuration file (e.g. `"listen_addr"`) (which may be in JSON, TOML or YAML)
-
- with the following rules:
- * Flags supersede environmental variables which supersede configuration file entries.
- * Dashes are used in flags, but underscores are used in environmental variables and configuration file entries.
- * Environmental variables are uppercased and prefixed with `IRMASERVER_`.
- * The [`requestors`](#requestor-authentication) and [`static_sessions`](#static-irma-qrs) options are special: when passed as a flag or environmental variable, they must be passed as a JSON object (for example: `--requestors '{"myapp":{"auth_method":"token","key":"12345"}}'`).
- * When passing a boolean flag [use an `=`](https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax), for example [`--no-auth=false`](#requestor-authentication).
-
-In order to see the configuration that the server uses after having gathered input from these sources, specify `-v` or `-vv` or use the `verbose` option. Use `irma server check -v` (with the same flags, env vars and config files as `irma server`) to check your configuration for correctness before running the server.
-
-For a full configuation example, see [Getting started](getting-started.md#example-configuration-and-irma-session).
-
-In the remainder of this document, when referring to options we write them as configuration file entries, with underscores and without prefix.
-
-### Default configuration
-In the default configuration (run `irma server check -v` to see it) the server is immediately usable. In particular, it
-* uses the [default IRMA schemes](schemes.md#default-schemes-pbdf-and-irma-demo) ([`pbdf`](https://github.com/credentials/pbdf-schememanager) and [`irma-demo`](https://github.com/credentials/irma-demo-schememanager)), downloading them if necessary
-* allows anyone to use the server [without authentication](#requestor-authentication) (the `no_auth` setting is `true`)
-* saves the session state in memory.
-
-If the server is reachable from the internet, you should consider enabling authentication of session requests.
-
-### Configuration files
-A configuration file can be provided using the `config` option (for example: `irma server --config ./irmaserver.json`). When not specified, the server looks for a configuration file called `irmaserver.json` or `irmaserver.toml` or `irmaserver.yaml` in (1) the current path; (2) `/etc/irmaserver/`; (3) `$HOME/irmaserver`, in that order. A configuration file is not required; if none is found at any of these locations the server takes its configuration from just command line flags and environmental variables.
-
-### Production mode
-When running the server in production, you should enable the `production` option. This enables stricter defaults on the configuration options for safety and prints warnings on possibly unsafe configurations. In particular, when `production` is enabled, the default values of some options change as follows (cf. `diff <(irma server -h) <(irma server -h --production)`):
-
-* `url` from `"http://$YOUR_LOCAL_IP:port"` to `""`: in development mode the `url` to which Yivi apps will connect is set by default to your current local IP address; in `production` mode you must configure it yourself.
-* [`no_auth`](#requestor-authentication) from `true` to `false`: you should consider enabling requestor authentication, or explicitly disable this by setting this flag to `true`.
-* [`issue_perms`](#global-permissions) from `[*]` (everything) to `[]` (none).
-* [`no_email`](email.md) from `true` to `false`: in `production` mode, opting out of providing an email address can be done by explicitly setting this flag to `true`.
-
-In addition, when [developer mode is not enabled in the Yivi app](yivi-app.md#developer-mode) (the default setting), the Yivi app wil refuse to perform sessions with IRMA servers not running in `production` mode. Since the majority of the Yivi app users will not have developer mode enabled, this requires IRMA servers facing those users to enable `production` mode.
-
-### Stateless mode
-By default session states are kept in memory. If you want to run several IRMA servers in parallel or if you wish data persistence for sessions, you can use [stateless mode](stateless.md) which is implemented in the IRMA server via a Redis data store.
-
-You can enable the Redis data store in the `irma server` by setting the `store_type` option to `redis`. For stand-alone mode, you should specify the `redis_addr` and `redis_pw` options. If you use ACLs in Redis, you should also specify the `redis_username` option. If you share the Redis instance with other applications and you want your Redis keys to be scoped, you can enable the `redis_acl_use_key_prefixes` option. All keys are prefixed with the Redis username (`:`) then.
-
-The IRMA server also supports Redis in Sentinel mode for high availability. Instead of `redis_addr` you should then specify `redis_sentinel_addrs` (list of strings) and `redis_sentinel_master_name`.
-
-Please note that if you use Redis in Sentinel mode, you need to consider whether you accept the risk of losing session state in case of a failover. Redis does not guarantee strong consistency in these setups. We mitigated this by waiting for a write to have reached the master node and at least one replica. This means that at least two replicas should be configured for every master node to achieve high availability. Even then, there is a small chance of losing session state when a replica fails at the same time as the master node. For example, this might be problematic if you want to guarantee that a credential is not issued twice or if you need a session QR to have a long lifetime but you do want the session to be finished soon after the QR is scanned. If you require IRMA sessions to be highly consistent, you should use the default in-memory store or Redis in standalone mode. If you accept this risk, then you can enable Sentinel mode support by setting the `redis_accept_inconsistency_risk` to true.
-
-For all configuration options, check the help output of the `irma server` command (`irma server --help`).
-
-### Keys and certificates
-For each configuration option that refers to some kind of key or certificate (for example `jwt_privkey`), there is a corresponding option with the `_file` suffix (for example `jwt_privkey_file`). Keys can be specified either by setting former to a (PEM) string, or setting the the latter to a file containing the (PEM) string.
-
-### HTTP server endpoints
-The HTTP endpoints that this server offers is split into two parts:
-* `/session`: used by the requestor to start sessions, check session status, or get session results.
-* `/irma`: used by the Yivi app during IRMA sessions.
-
-In the default mode, the server starts one HTTP server that offers both, configured with `listen_addr` and `port`. If however the `client_port` and `client_listen_addr` options are provided, then the server starts two separate HTTP servers:
-* `/session` attaches to the address and port provided with `port` and `listen_addr`.
-* `/irma` attaches to the address and port provided with `client_port` and `client_listen_addr`.
-
-The `/irma` endpoints must always be reachable for the Yivi app. Using this double server mode you can restrict access to the `/session` endpoints by e.g. setting `listen_addr` to `127.0.0.1` or to an interface only reachable from an internal network. Restricting access to the `/session` endpoints in this way may make requestor authentication unnecessary.
-
-### Requestor authentication
-The server runs in one of two modes: it either accepts all session requests from anyone that can reach the server, or it accepts only authenticated session requests from authorized requestors. This can be toggled with the `no_auth` boolean option. If the `/session` creation endpoint of your `irma server` is publicly accessible from the internet (i.e. the `client_port` option is used, see [above](#http-server-endpoints)), then you should consider enabling requestor authentication (i.e. turn `no_auth` off), otherwise anyone can use your `irma server`.
-
-The default is `true` (requests are not authenticated) when `production` is disabled and `false` otherwise.
-
-When authentication is enabled (`no_auth` is `false`), requestors that are authorized to use the server must be configured in the `requestor` option in the form of a map, for example:
-
-```json
-{
- "requestors": {
- "myapp": {
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-
-The server supports several authentication methods, one of which must be specified in the `auth_method` field for each requestor. The snippet above demonstrates the recommended and easiest to use authentication method, called `token`. When using this method the requestor must include the `key` as an API token in a HTTP header (for more details see the [API reference](api-irma-server.md#post-session)).
-
-In addition the server supports the following authentication methods:
-* `hmac`: the requestor symmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/), with HMAC-SHA256 (`HS256`) using `key`. The `key` provided should be the Base64 encoding of the actual secret.
-* `publickey`: the requestor asymmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/) with RSA (`RS256`), in this case `key` should be the PEM public key of the requestor.
-
-For each of these modes it is also possible to specify `key_file` instead `key`; in that case the file at `key_file` will be read and used as `key`.
-
-### Static IRMA QRs
-Unlike normal QRs which differ per session (as they contain the session token), the server also supports static QRs which, when scanned by the Yivi app, start preconfigured IRMA sessions. This makes it possible to for example print such a static QR. These preconfigured sessions are configured with the `static_sessions` options, for example:
-```json
-{
- "static_sessions": {
- "mystaticsession": {
- "callbackUrl": "https://example.com/callbackUrl",
- "request": {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "irma-demo.MijnOverheid.ageLower.over18" ]]]
- }
- }
- }
-}
-```
-Thus `static_sessions` must contain a map of which each item must be an [extended session request](session-requests.md#extra-parameters). Including a `callbackUrl` to which the [session result](api-irma-server.md#get-session-token-result) is sent after the session is required (since for these sessions there is no requestor waiting to receive the attributes after the session has finished). If a JWT private key is installed, then the session result is sent as a [JWT](api-irma-server.md#get-session-token-result-jwt).
-
-> If no JWT private key is installed, then the `callbackUrl` should either not be publically reachable, or it should include a secret token (e.g. https://example.com/cX5aTins5kEZpjDpfYcN) and have TLS enabled (which it should anyway as personal data will be POSTed to it). Otherwise there is no way of distinguishing POSTs from your `irma server` from POSTs made by someone else.
-
-Assuming the URL of the `irma server` is `http://example.com`, the session configured above is started when the Yivi app scans a QR with the following contents:
-```json
-{
- "irmaqr": "redirect",
- "u": "http://example.com/irma/session/mystaticsession"
-}
-```
-
-Only static [disclosure or attribute-based signature sessions](what-is-irma.md#session-types) are supported.
-
-### Permissions
-For each of the [three IRMA session types](what-is-irma.md#session-types) (attribute verification; attribute-based signature sessions; and attribute issuance), permission to use specific attributes/credentials can be granted to requestors in the configuration. For example, including permissions in the `myapp` requestor from above:
-```json
-{
- "requestors": {
- "myapp": {
- "disclose_perms": [ "irma-demo.MijnOverheid.ageLower.over18" ],
- "sign_perms": [ "irma-demo.MijnOverheid.ageLower.*" ],
- "issue_perms": [ "irma-demo.MijnOverheid.ageLower" ],
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-This means that `myapp` is authorized to request `irma-demo.MijnOverheid.ageLower.over18` in disclosure session, and any attribute from `irma-demo.MijnOverheid.ageLower` in attribute-based signature sessions. Additionally `myapp` can issue `irma-demo.MijnOverheid.ageLower` instances. In each level wildcards are permitted (`irma-demo.MijnOverheid.ageLower.*`, `irma-demo.MijnOverheid.*`, `irma-demo.*`, `*`). Thus `"disclose_perms": [ "*" ]` allows the requestor to verify any attribute.
-
-To use the [`host` option](session-requests.md#session-host) in session requests, you need to specify which hosts the requestor may use. You can do this by specifying `host_perms`. You can use glob patterns to grant permissions for a range of hosts.
-
-```json
- {
- "requestors": {
- "myapp": {
- ...
- "host_perms": ["*.example.com"]
- }
- }
- }
-```
-
-### Global permissions
-
-Global permissions can be applied to all requestors by using the global `disclose_perms`, `sign_perms` and `issue_perms` options. For each requestor, the effective set of permissions is the union of the permissions specified in its `requestors` map and the global permission set.
-
-The global options also work when `no_auth` is enabled. Thus in this case a session type can be disabled by granting no one the permission, e.g., `issue_perms: []` would disable issuance.
-
-In development mode, when `production` is `false`, the defaults for `disclose_perms`, `sign_perms` and `issue_perms` are `["*"]`. In order to protect any IRMA private keys that the server has access to from unintended use by others, when `production` is true the default of `issue_perms` is `[]`: no one can issue unless the global `issue_perms` is modified or unless specific requestors receive nonempty `issue_perms`.
-
-### Client return urls
-
-In session requests, the server can be asked to pass a [client return url](session-requests.md#client-return-url) to the Yivi app, which the app will open after completing the session for sessions that involve only one device. This feature is always enabled.
-
-### Session lifetime
-
-When a session is [started by the requestor](#starting-a-session), users have a limited amount of time to perform the session in their Yivi app. These lifetime constraints can be configured.
-
-By default, users have the maximum session lifetime to start the session in their Yivi app after it is started on the server. By default, this is set to 15 minutes. This global setting holds for all sessions on this server and can be changed in the configuration (see below). Per session, a custom timeout value can be chosen using the `timeout` option in the [extended session request](session-requests.md#extra-parameters).
-
-After a session is started by the user in the Yivi app, it has another full period of the maximum session lifetime to complete the session in their app. As mentioned above, this is 15 minutes by default. This part of the session lifetime is not affected by the `timeout` setting of the extended session request. The maximum session lifetime can be configured using the global `max_session_lifetime` option in the server configuration.
-
-When the user completes the session, the requestor has a limited amount of time to retrieve the session result from the server. By default, the lifetime of the session result on the server is 5 minutes. The session result lifetime can be configured using the global `session_result_lifetime` option in the server configuration.
-
-More information on how to configure global options for your server can be found [above](#configuring).
-
-### Augmented client return urls
-
-The server can be configured to [augment the client return url](session-requests.md#augmenting-the-client-return-url) when requested. In order to enable this feature, the `augment_client_return_url` setting needs to be set to `true`.
-
-### Static file hosting
-
-Apart from hosting endpoints under [`/session` and `/irma`](irma-server.md#http-server-endpoints), the server also supports statically hosting all files from a certain directory. This can be useful [for experimenting](getting-started.md#perform-browser-irma-session). It can be configured with the following options:
-
-* `static_path`: Host files under this path as static files. Leave empty to disable static file hosting.
-* `static_prefix`: Host static files under this URL prefix (default: no prefix)
-
-### IRMA schemes
-
-The server uses [IRMA schemes](schemes.md) to retrieve issuer, credential and attribute names, as well as public and private keys with which attributes can be verified an issued, respectively. By default the server uses the [`pbdf` and `irma-demo` schemes](schemes.md#default-schemes-pbdf-and-irma-demo). This can be configured with the following options:
-
-* `schemes_path`: path containing IRMA schemes (often called `irma_configuration`). Default: `C:\Users\Username\AppData\Local\irma\irma_configuration` on Windows, `$HOME/.local/share/irma/irma_configuration` otherwise. Created if it does not exist. If empty, the default schemes [`pbdf` and `irma-demo`](schemes.md#default-schemes-pbdf-and-irma-demo) are downloaded into it.
-* `schemes_assets_path`: path containing initial, read-only IRMA schemes. If specified, the schemes found here are copied into the path specified by `schemes_path`. Can be used to avoid downloading default schemes on first run.
-* `schemes_update`: update IRMA schemes from their scheme URL every this many minutes. Default is `60`. Set to `0` to disable automatic scheme updating (not recommended).
-
-### IRMA issuer private keys
-
-If IRMA issuer private keys are included in the server configuration, then the server can issue all credential types of all issuers for which private keys are installed. IRMA issuer private keys can be configured in the following two ways:
-
-* Include the private keys within the [IRMA scheme](schemes.md) in the issuer's `PrivateKeys` folder, with filenames `0.xml`, `1.xml`, etc ([example](https://github.com/privacybydesign/irma-demo-schememanager/tree/master/MijnOverheid/PrivateKeys)).
-* Set the `privkeys` option to a folder containing IRMA issuer private keys called `scheme.issuer.xml` or `scheme.issuer.counter.xml` (for example, `irma-demo.MijnOverheid.xml` or `irma-demo.MijnOverheid.2.xml`).
-
-If issuance is enabled in production and private keys are configured, then you should ensure that only authenticated requestors can start issuance requests (otherwise if anyone can use your server to issue attributes then those attributes cannot be trusted or used). You should either:
-
-* disable `no_auth` and [send authenticated session requests](irma-server.md#requestor-authentication),
-* Restrict the [`/session` HTTP endpoints](#http-server-endpoints) to a internal network interface only accessible by your applications and not from outside.
-
-Taking neither approach is an unsafe configuration as in that case anyone can create issuance sessions. In this case, if `production` mode is enabled then the server will refuse to run.
-
-### Signed JWT session results
-
-If a `jwt_privkey` (or `jwt_privkey_file`) is given, then the following endpoints are enabled:
-
-* `GET /session/{sessiontoken}/result-jwt`: returns the session result signed by the `irma server` into a JWT.
-* `GET /session/{sessiontoken}/getproof`: returns a JWT similar to the one from `result-jwt`, but with the same structure as the IRMA API server session result JWTs.
-* `GET /publickey`: returns the public key with which the JWTs output by this server can be verified.
-
-This can be useful if the session result travels along an unsafe or untrusted route from the IRMA server to the requestor. As long as the `irma server` is trusted and its public key is known, the JWT can be verified to ensure that the session result was untampered with since it left the `irma server`.
-
-### TLS
-
-The [IRMA protocol](irma-protocol.md) relies on TLS for encryption of the attributes as they travel along the internet. If your server is connected to the internet and it handles actual attributes (personal data from people), then you ***must*** ensure that the attributes are protected in transit with TLS. In its default configuration (i.e. with [developer mode](yivi-app.md#developer-mode) disabled), the Yivi app will refuse to connect to servers not using TLS.
-
-You can enable TLS in the `irma server` with the `tls_cert` and `tls_privkey` options (or the `_file` equivalents), specifying a PEM certificate (chain) and PEM private key. If you use [separate requestor and app endpoints](#http-server-endpoints), additionally use `client_tls_cert` and `client_tls_privkey`.
-
-Alternatively, if your IRMA server is connected to the internet through a reverse proxy then your reverse proxy probably handles TLS for you.
-
-### Email
-
-Users of the server are encouraged to provide an email address with the `email` option, subscribing for notifications about changes in the IRMA software or ecosystem. [More information](email.md). In `production` mode, it is required to either provide an email address or to explicitly out with the `no_email` option.
-
-### Logging and verbosity
-
-The server's verbosity can be increased by two degrees:
-* `-v` flag is given, or `verbosity` option set to `1`: includes `DEBUG` messages. Logs server configuration when starting the server, stack traces of errors, and more.
-* `-vv` flag is given, or `verbosity` option set to `2`: includes `TRACE` messages. Additionally includes dumps of all HTTP traffic from and to the server.
-
-> in its default mode, the server will not log untrusted user input and attribute values (personal data). If the verbosity is increased, sensitive or dangerous content may be logged. You should avoid doing this in production.
-
-The output is [structured](https://github.com/sirupsen/logrus#fields), putting certain recurring values in fields:
-```text
-[2019-02-28T20:51:09+01:00] INFO Session started action=disclosing session=WdypvSs97JTotpfl1Dtd
-```
-Outputting JSON is enabled with the `log-json` option:
-```json
-{"action":"disclosing","level":"info","msg":"Session started","session":"WdypvSs97JTotpfl1Dtd","time":"2019-02-28T20:51:09+01:00"}
-```
-
-## Running as daemon
-
-On most Linux systems, the `irma server` can be made into an automatically started daemon as follows:
-
-1. Write a new systemd unit file to `/etc/systemd/system/irmaserver.service`:
- ```ini
- [Unit]
- Description=IRMA server
- Documentation=https://irma.app/docs/irma-server
- Requires=network.target
-
- [Service]
- Type=simple
- ExecStart=/usr/local/bin/irma server --config=/etc/irmaserver/config.json
- TimeoutStopSec=60
- Restart=always
- RestartSec=1
- StandardOutput=syslog
- StandardError=syslog
- SyslogIdentifier=irma
- User=irmaserver
- Group=irmaserver
-
- [Install]
- WantedBy=multi-user.target
- ```
- Modify the path to `irma` and [your configuration file (or flags or environmental variables)](#configuring) in `ExecStart` as needed, as well as `User` and `Group`.
-2. Start the daemon and schedule it for automatic start on boot by running `systemctl start irmaserver.service && systemctl enable irmaserver.service`.
-
-See `systemctl status irmaserver.service` for the status of the daemon, and `journalctl -u irmaserver.service` for the console output of the IRMA server.
-
-## Design goals
-
-The server was designed with the following goals in mind.
-- Developer and user friendliness
- - Each of the [configuration options](#configuring) can be specified in a configuration file, command line flag, or environmental vars (see `-h`)
- - Default configuration (demo mode) is immediately useful
- - Thorough and configurable logging (`-v`, `-vv`; by default logs exclude attribute values)
- - Partial backwards compatibility with predecessor [`irma_api_server`](https://github.com/privacybydesign/irma_api_server)
- - Small startup time
-- Also available as [Go library](irma-server-lib.md) instead of standalone server
- - Bindings to other programming languages (Python, Ruby) are expected
-
-Being written in [Go](https://golang.org/), this server (in fact, the containing [`irma` binary](irma-cli.md)) additionally automatically has the following properties.
-- Simple to install (one binary, no dependencies, cross platform) and/or compile
-- [Reproducible builds](https://www.gnu.org/software/mes/manual/html_node/Reproducible-Builds.html)
-- [API documentation](https://godoc.org/github.com/privacybydesign/irmago) (generated automatically from `master` branch)
-
-Referring to Go packages (i.e. folders) under [`irmago`](https://github.com/privacybydesign/irmago), the server is structured as follows.
-* [`server/irmaserver`](irma-server-lib.md): Go library implementing the HTTP endpoints for the [IRMA protocol](irma-protocol.md) (in which the Yivi app is the client), and a Go API for requestors to manage sessons. ([Godoc API documentation](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver))
-* `server/requestorserver`: Go library wrapping `server/irmaserver`, exposing the requestor API as a second HTTP endpoint set under `/session` URLs instead of as Go functions (next to `/irma` for the Yivi app endpoints). ([Godoc API documentation](https://godoc.org/github.com/privacybydesign/irmago/server/requestorserver))
-* `irma`: executuable whose `server` commands wraps `server/requestorserver`.
diff --git a/website/versioned_docs/version-v0.15.0/stateless.md b/website/versioned_docs/version-v0.15.0/stateless.md
deleted file mode 100644
index 737aed8..0000000
--- a/website/versioned_docs/version-v0.15.0/stateless.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: Stateless IRMA server
-id: version-v0.15.0-stateless
-original_id: stateless
----
-
-For each IRMA session the [IRMA server](irma-server.md) needs to keep track of the [session state](irma-protocol.md#the-session-state).
-By default the session state is kept in memory. With version 0.9.0 of the IRMA server it is possible to run the IRMA server in a stateless mode. The session data will then be stored in a Redis datastore. This page explains how the stateless IRMA server works and how to run the IRMA server in stateless mode.
-
-## Overview
-During an IRMA session, the IRMA server acts as a state machine which is described in detail on the [IRMA protocol page](irma-protocol.md). The IRMA session progresses through various states such as `INITIALIZED`, `CONNECTED` and `DONE`. The IRMA server contains logic when to switch from one state into the other. The state itself can be kept in memory or, alternatively, in a Redis data store. Saving the session state in memory requires no extra setup and is currently the default behaviour of the IRMA server. However, the data in memory cannot be shared between several IRMA servers. This means that you cannot scale the IRMA server horizontally when using this in-memory solution. Next to poor scalability, the in-memory solution is problematic when the IRMA server needs to be restarted or - even worse - when the server crashes. In such cases, the in-memory information of all sessions gets irreversibly lost.
-
-With the new feature of running the IRMA server in stateless mode, the session data gets decoupled from the IRMA server, making the server itself stateless. The IRMA server still contains the logic when to switch between states but will retrieve and update the session data from and to a dedicated store. Hence, several IRMA servers can be run in parallel and connect to the same data store. Also, no data is lost when the IRMA server restarts or crashes.
-
-### Use cases
-* Scaling the IRMA server horizontally, i.e. running several IRMA severs in parallel.
-* Preventing data loss when restarting an IRMA server.
-* Preventing data loss in case of IRMA server crashes.
-
-## Running the IRMA server in stateless mode
-### Example
-You can start the IRMA server in stateless mode by setting the `store-type` option to `redis`. Additionally you need to provide a Redis server address and password. For test purposes you can override the need for a password by setting the `redis-allow-empty-password` option to `true`. However, make sure to use a secure Redis password in production. Your Redis data store will contain sensitive data and must be password-protected.
-
-```
-irma server -vv --store-type redis --redis-addr "localhost:6379" --redis-pw "placeholderPassword"
-```
-
-If you want to run several IRMA servers, you can now run them behind a load balancer and connect them to the same Redis instance.
-
-By default the IRMA server connects to Redis with TLS, using the system store of certificate authorities. Alternatively, you can specify the certificate that Redis uses, or the certificate authority with which that certificate is signed, using the `redis-tls-cert` or `redis-tls-cert-file` options. A certificate may be configured in Redis as follows:
-
-```
-requirepass placeholderPassword
-
-# Disable the non-TLS port completely
-port 0
-# Enable TLS on the default Redis port
-tls-port 6379
-
-# X.509 certificate and a private key
-tls-cert-file /path/to/cert.pem
-tls-key-file /path/to/privkey.pem
-
-# Disable TLS client authentication
-tls-auth-clients no
-```
-
-It is also possible to disable TLS altogether for connections to Redis, using the `redis-no-tls` option.
-
-> In production, always using TLS for Redis is recommended. If you disable TLS, be sure to run your Redis server in an internal network protected against unauthorized access.
-
-### Using multiple Redis instances
-The IRMA server supports Redis in Sentinel mode, which allows you to use multiple Redis instances in a failover configuration. For data consistency, we currently require at least 1 replica to be present. This means that you need a minimum of 2 replicas for high availability. Please check the [configuration options](irma-server.md#stateless-mode) for more information about this mode.
-
-We currently do not support Redis in cluster mode. If you need support for Redis Cluster, please contact us.
-
-### Server-sent events
-Currently the IRMA server does not support a stateless mode in combination with server-sent events. Please contact us, should you be in need of this combination.
diff --git a/website/versioned_docs/version-v0.2.0/api-go.md b/website/versioned_docs/version-v0.2.0/api-go.md
deleted file mode 100644
index d22d39b..0000000
--- a/website/versioned_docs/version-v0.2.0/api-go.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Go libraries
-id: version-v0.2.0-api-go
-original_id: api-go
----
-
-Most of the core IRMA software is written in the [Go](https://golang.org/) programming language. For Go projects, API documentation is generated automatically from the source code by [GoDoc](http://godoc.org/):
-
-* [`irmaserver`](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver)
-* [`irma`](https://godoc.org/github.com/privacybydesign/irmago)
-* [`irmaclient`](https://godoc.org/github.com/privacybydesign/irmago/irmaclient)
-
-When describing a JSON message on any of the other pages of this website, we will sometimes link to the corresponding Go struct on GoDoc.
diff --git a/website/versioned_docs/version-v0.2.0/api-irma-server.md b/website/versioned_docs/version-v0.2.0/api-irma-server.md
deleted file mode 100644
index ca913f0..0000000
--- a/website/versioned_docs/version-v0.2.0/api-irma-server.md
+++ /dev/null
@@ -1,149 +0,0 @@
----
-title: irma server
-id: version-v0.2.0-api-irma-server
-original_id: api-irma-server
----
-
-```shell
-irma server [options...]
-```
-
-The API that this server offers consists of two parts:
-
-* Endpoints under `/irma`. This is used exclusively by the [irmaclient](https://github.com/privacybydesign/irmago/tree/master/irmaclient)/[IRMA app](https://github.com/privacybydesign/irma_mobile), and is not documented here.
-* Endpoints under `/session` with which IRMA session requestors can start IRMA sessions, monitor their status and retrieve their result afterwards.
-
-## API reference
-
-
-
-For each of these endpoints, if the HTTP status code indicates that the request was not successful (i.e. not in the 2xx range), then the server returns an [`irma.RemoteError`](https://godoc.org/github.com/privacybydesign/irmago#RemoteError) instance. For example, attempting to [retrieve the session result](#get-session-token-result) of an unknown session returns
-```json
-{"status": 400, "error": "SESSION_UNKNOWN", "description": "Unknown or expired session"}
-```
-The following fields may occur in this message:
-* `status`: HTTP error code associated to this error
-* `error`: an error `Type` from the list of possible errors in the [server API documentation](https://godoc.org/github.com/privacybydesign/irmago/server#Error)
-* `description`: English human-readable description of this error
-* `message`: May contain additional information
-* `stacktrace`: Stack trace of the error, only if verbose mode is enabled
-
----
-
-### `POST /session`
-
-Start an IRMA session. What to POST to this endpoint depends on the server configuration:
-
-* If `no_auth` is true, an [(extended) JSON session request](session-requests.md)
-* If `no_auth` is false:
- * [(extended) JSON session request](session-requests.md) with an API token in the `Authorization` HTTP header
- * [JWT session request](session-requests.md#jwts-signed-session-requests) signed with RS256 or HS256
-
-If `no_auth` is false, then which of these options should be taken depends on the [`requestors`](irma-server.md#requestor-authentication) option passed to the `irma server`.
-
-In each case an appropriate `Content-Type` with `text/plain` or `application/json` must be included.
-
-If the request was successfully parsed, and authenticated if applicable, then the server returns a *session package*:
-```json
-{
- "token":"KzxuWKwL5KGLKr4uerws",
- "sessionPtr": {"u":"https://example.com/irma/ysDohpoySavbHAUDjmpz","irmaqr":"disclosing"}
-}
-```
-In the endpoints below, the `{token}` placeholder must be replaced with the above session `token`. The `sessionPtr` points to the IRMA session for the IRMA app user, and should be displayed as a QR for the user to scan, or encoded in a universal link for a mobile session, e.g. using [`handleSesion()`](api-irmajs.md#handlesession) from `irmajs`.
-
-Each session starts in the `"INITIALIZED"` [session status](#get-session-token-status). Regardless of how it reaches its ending status (`"DONE"`, `"CANCELLED"`, `"TIMEOUT"`), it is kept in memory for 5 minutes after reaching its ending status. After that all endpoints below requiring the session `token` return error `"SESSION_UNKNOWN"`.
-
----
-
-### `DELETE /session/{token}`
-
-Cancel the session: set the [session status](#get-session-token-status) to `"CANCELLED"`.
-
----
-
-### `GET /session/{token}/status`
-
-Retrieve the [session status](https://godoc.org/github.com/privacybydesign/irmago/server#Status) as a JSON string. Returns one of:
-* `"INITIALIZED"`: the session has been started and is waiting for the client
-* `"CONNECTED"`: the client has retrieved the session request, we wait for its response
-* `"CANCELLED"`: the session is cancelled: the user refused, or the user did not have the requested attributes, or an error occurred during the session
-* `"DONE"`: the session has completed successfully
-* `"TIMEOUT"`: session timed out
-
-Of these the latter three are *ending statuses*; once the session reaches such a status, it will not switch status again. A session starts as `"INITIALIZED"` and reaches one of the ending statuses either directly or after becoming `"CONNECTED"`.
-
-> The session is cancelled and receives status `"CANCELLED"` not only when the IRMA app user refuses, but also when the session is aborted due to an error.
-
-> If the session is cancelled due to the user aborting, it is (by design) not possible using this or the other endpoints of the `irma server` to distinguish between (1) the user had the requested attributes but refused to disclose them, and (2) the session was aborted by the user's IRMA app because (s)he did not have the required attributes.
-
----
-
-### `GET /session/{token}/statusevents`
-
-Subscribe to a [server-sent event](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events) stream of status updates. Whenever the session status changes, an event is sent with the new session status as a JSON string. If you need to monitor the status of a session, this is preferred over polling to `GET /session/{token}/status`.
-
----
-
-### `GET /session/{token}/result`
-
-Get the [session result](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult). Example output:
-```json
-{
- "type" : "disclosing",
- "status" : "DONE",
- "disclosed" : [{
- "status" : "PRESENT",
- "rawvalue" : "yes",
- "id" : "irma-demo.MijnOverheid.ageLower.over18",
- "value" : {
- "en" : "yes",
- "nl" : "yes",
- "" : "yes"
- }
- }],
- "proofStatus" : "VALID",
- "token" : "ELMExi5iauWYHzbH7gwU"
-}
-```
-The response may contain the following fields:
-* `token`: Session token
-* `status`: Current [session status](#get-session-token-status)
-* `type`: [Session type](what-is-irma.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
- * `"INVALID_TIMESTAMP"`: Attribute-based signature has invalid timestamp
- * `"UNMATCHED_REQUEST"`: proofs do not correspond to a specified request
- * `"MISSING_ATTRIBUTES"`: proofs do not contain all requested attributes
- * `"EXPIRED"`: Attributes were expired at creation time
-* `disclosed`: List of [attributes disclosed](https://godoc.org/github.com/privacybydesign/irmago#DisclosedAttribute) by the user
-* `signature`: The full attribute-based signature in case of `"signing"` sessions
-* `error`: Error message in case of failure
-
-If the session is not yet finished (that is, the session status is `INITIALIZED` or `CONNECTED`), then only the first three fields are populated. (For getting just the current session status, using [`GET /session/{token}/statusevents`](api-irma-server#get-session-token-statusevents) or [`GET /session/{token}/status`](api-irma-server#get-session-token-status) is preferred.)
-
-This endpoint just fetches the session result, and works normally even if the session failed. If so, the `status`, `proofStatus` or `error` fields will indicate what happened. Be sure to check these fields when retrieving and handling the session result.
-
----
-
-### `GET /session/{token}/result-jwt`
-
-If a JWT private key was [provided in the configuration of the `irma server`](irma-server.md#signed-jwt-session-results), then this returns a [JWT](https://jwt.io) signed by the `irma server` with the message from [`GET /session/{token}/result`](#get-session-token-result) above as JWT body, along with the following standard JWT fields:
-* `iss`: name of the current `irma server` as defined in its configuration
-* `iat`: Unix timestamp indicating when this JWT was created
-* `sub`: `verification_result` or `signing_result` or `issuing_result`
-
-This way, even if the session result from the `irma server` travels along an untrusted route (for example the user's browser), the session result can still be validated and trusted.
-
----
-
-### `GET /session/{token}/getproof`
-
-Also returns a session result JWT, but one whose structure is the same as the session JWTs returned by the [`irma_api_server`](https://github.com/privacybydesign/irma_api_server). Only works if a JWT private key was [provided in the configuration of the `irma server`](irma-server.md#signed-jwt-session-results).
-
----
-
-### `GET /publickey`
-
-If a JWT private key was [provided in the configuration of the `irma server`](irma-server.md#signed-jwt-session-results), then this returns the corresponding public key in PEM with which the server's session result JWTs returned by [`GET /session/{token}/result-jwt`](#get-session-token-result-jwt) and [`GET /session/{token}/getproof`](#get-session-token-getproof) can be verified.
diff --git a/website/versioned_docs/version-v0.2.0/api-irmajs.md b/website/versioned_docs/version-v0.2.0/api-irmajs.md
deleted file mode 100644
index 54f0337..0000000
--- a/website/versioned_docs/version-v0.2.0/api-irmajs.md
+++ /dev/null
@@ -1,130 +0,0 @@
----
-title: irmajs
-id: version-v0.2.0-api-irmajs
-original_id: api-irmajs
----
-
-`irmajs` can be used in the browser:
-```html
-
-```
-as well as in Node or Webpack:
-```js
-// ES modules
-import * as irma from '@privacybydesign/irmajs';
-// CommonJS
-const irma = require('@privacybydesign/irmajs');
-```
-
-Its primary functions are [`startSession()`](#startsession), which can start an IRMA session by sending a (unsigned or JWT) [session request](session-requests.md) to an IRMA server, and [`handleSession()`](#handlesession), which given the output of `startSession()` handles the remainder of an IRMA session.
-
-## API reference
-
-
-
----
-
-### `SessionStatus`
-A enum containing possible IRMA [session statuses](https://godoc.org/github.com/privacybydesign/irmago/server#Status), defined as follows:
-
-```js
-const SessionStatus = {
- Initialized: 'INITIALIZED', // The session has been started and is waiting for the client to connect (scan the QR)
- Connected : 'CONNECTED', // The client has retrieved the session request, we wait for its response
- Cancelled : 'CANCELLED', // The session is cancelled, possibly due to an error
- Done : 'DONE', // The session has completed successfully
- Timeout : 'TIMEOUT', // Session timed out
-};
-```
-
----
-
-### `handleSession()`
-
-```js
-irma.handleSession(qr, [options])
-```
-Handle an IRMA session after it has been created at an IRMA server, given the QR contents obtained from the IRMA server (e.g. using [`startSession()`](#startsession)) to be sent to the IRMA app. This function can
-1. draw an IRMA QR,
-2. wait for the phone to connect,
-3. wait for the session to complete,
-4. retrieve the session result afterwards from the irma server.
-
-Returns a promise that can resolve at any of these phases, depending on the options:
-
-| Option | Default | Effect |
-|---|---|---|
-| `method` | `'popup'` | Supported methods: `'popup'`, `'canvas'`, `'mobile'` (only browser), `'console'` (only node), `'url'` (both) |
-| `element` | `'irmaqr'` | HTML `id` of the canvas to draw to if `method === 'canvas'` |
-| `language` | `'en'` | Popup language when `method === 'popup'` |
-| `showConnectedIcon` | `true` | When method is `'popup'` or `'canvas'`, replace QR with a phone icon when phone connects |
-| `returnStatus` | `SessionStatus.Done` | When the session reaches this status control is returned to the caller |
-| `server` | `''` | Server URL to fetch the session result when session is done. Implies `returnStatus === SessionStatus.Done` |
-| `token` | `''` | Session token required to fetch the session result when session is done |
-| `resultJwt` | `false` | Retrieve signed session result from the irma server |
-| `disableMobile` | `false` | Disable automatic navigation to IRMA app on mobile |
-
-The following `method`s are supported:
-* `popup`: Draw a popup overlay with the QR and a cancel button in it.
-* `canvas`: Draw the QR into the HTML `canvas` specified by the `element` option.
-* `mobile`: For mobile browsers, open the IRMA app directly instead of drawing a QR. Note that this mode is default when running `irmajs` in a mobile browser, even if you specify another method. You can disable this behavior and use your own `method` by setting `disableMobile` to true.
-* `console`: Draw the QR into the console.
-* `url`: Return the QR as a data URL (for in an `img` HTML tag). Implies `returnStatus = SessionStatus.Initialized`.
-
-What the promise returned by this function receives depends on the options as follows:
-* If the `server` and `token` options are not provided then the session status is returned.
-* If the `server` and `token` parameters are given, containing a URL to an IRMA server and the session token at the IRMA server, respectively, then the session result is retrieved from the IRMA server. In that case, the promise returned by this function receives one of the following:
- * If `resultJwt` is `false` (default), a [`SessionResult` message](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult) as returned by the [`GET /session/{token}/result`](api-irma-server.md#get-session-token-result) endpoint of the `irma server`.
- * Otherwise, a session result JWT as returned by the [`GET /session/{token}/result-jwt`](api-irma-server.md#get-session-token-result-jwt) endpoint of the `irma server`.
-
-If the session is not successful, an exception is thrown. If the session is cancelled or times out, the message will be `SessionStatus.Cancelled` or `SessionStatus.Timeout`.
-
-> The session is cancelled and receives status `SessionStatus.Cancelled` not only when the IRMA app user refuses, but also when the session is aborted due to an error. In each of these cases an exception is thrown. Check its error argument.
-
-> If the session is cancelled due to the user aborting, it is (by design) not possible to distinguish between (1) the user had the requested attributes but refused to disclose them, and (2) the session was aborted by the user's IRMA app because (s)he did not have the required attributes.
-
----
-
-### `startSession()`
-
-```js
-irma.startSession(server, request[, method, key[, name]])
-```
-
-Start an IRMA session at an IRMA server. This function supports all authentication methods of the `POST /session` endpoint of the `irma server`. It returns a promise with the response (the session QR contents) from the IRMA server (which can be handled by [`handleSession()`](#handlesession)).
-
- Parameters:
- * `server`: URL to IRMA server at which to start the session.
- * `request`: Session request, either a JWT or an [(extended) session request](session-requests.md) (see below).
- * `method`: authentication method (supported: `none`, `token`, `hmac`, `publickey`; default is `none`).
- * `key`: API token or JWT key.
- * `name`: name of the requestor (only for `hmac` and `publickey` mode).
-
-The authentication method is determined by the `request` and `method` parameters as follows.
-* If `request` is a `string` then it is posted as a [session request JWT](session-requests.md#jwts-signed-session-requests) to the IRMA server.
-* Otherwise it should be an `object` containing an [(extended) session request](session-requests.md). How it is handled depends on `method`:
- * `none`: it is POSTed as JSON to the IRMA server (which must be configured to accept unauthorized session requests).
- * `token`: it is POSTed as JSON to the IRMA server along with the `key` parameter as an API token in a HTTP header.
- * `publickey`: it is first signed into a JWT with the specified RSA private `key` in PEM, using `name` as the requestor name, and then POSTed to the IRMA server.
- * `hmac`: it is first signed into a JWT with the specified symmetric HMAC `key`, using `name` as the requestor name, and then POSTed to the IRMA server.
-
----
-
-### `signSessionRequest()`
-```js
-signSessionRequest(request, method, key, name)
-```
-
----
-
-### `waitConnected()`
-```js
-waitConnected(url)
-```
-
----
-
-### `waitDone()`
-```js
-waitDone(url)
-```
diff --git a/website/versioned_docs/version-v0.2.0/email.md b/website/versioned_docs/version-v0.2.0/email.md
deleted file mode 100644
index daf08e6..0000000
--- a/website/versioned_docs/version-v0.2.0/email.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Email address
-id: version-v0.2.0-email
-original_id: email
----
-
-IRMA has a decentral architecture: anyone can start an [`irma server`](irma-server.md) and verify attributes, communicating directly with IRMA apps. This is an important and distinguishing feature contributing to IRMA's privacy features and trustworthiness, but also means that we as authors of the software have no natural update channel with which we can update all IRMA servers running within the ecosystem. We have to prevent that this leads to a fractured IRMA ecosystem with incompatible apps and servers, which would lead to bad user experience and hurt adoption.
-
-Inspired by the approach of Let's Encrypt, each of the [IRMA server](what-is-irma.md#irma-servers) software components can be configured with an email address. If specified, the email address is uploaded to the [Privacy by Design Foundation](https://privacybydesign.foundation/) and subscribed to receive updates about changes in the IRMA software or ecosystem. You will be notified of changes such as major updates of the IRMA server, and breaking changes in any part of the IRMA infrastructure that would require you to update your IRMA server or otherwise take action in order to stay compatible with the rest of the IRMA ecosystem.
-
-***We strongly recommend anyone running any IRMA server in production to specify an email address.***
-
- * If you provide your email address it will exclusively be used by the Foundation for the above purpose.
- * It will be very low volume (on average perhaps one email per several months).
- * If you have provided your email address in the past and wish to be unsubscribed, please email [the Foundation](https://privacybydesign.foundation/contact-en/).
- * See also the Foundation's [privacy policy](https://privacybydesign.foundation/privacy-policy-en/).
diff --git a/website/versioned_docs/version-v0.2.0/getting-started.md b/website/versioned_docs/version-v0.2.0/getting-started.md
deleted file mode 100644
index 56576af..0000000
--- a/website/versioned_docs/version-v0.2.0/getting-started.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: Getting started
-id: version-v0.2.0-getting-started
-original_id: getting-started
----
-
-This page shows how to get started with verifying or issuing IRMA attributes, using the following components:
-
- * [`irma server`](irma-server.md), a server that verifies or issues IRMA attributes to [IRMA apps](https://github.com/privacybydesign/irma_mobile),
- * [`irmajs`](irmajs.md), a JavaScript library for drawing the IRMA QR in your website, and handling IRMA session with the `irma server`.
-
-You should have the IRMA app installed ([Android](https://play.google.com/store/apps/details?id=org.irmacard.cardemu), [iOS](https://itunes.apple.com/nl/app/irma-authentication/id1294092994)). If you want to compile from source instead of using prebuilt binaries, you should additionally have [Git](https://git-scm.com/), [Go](https://golang.org/doc/install), [dep](https://golang.github.io/dep/docs/installation.html), and [npm](https://docs.npmjs.com/cli/npm) installed.
-
-
-## Installing and running `irma server`
-You can install the `irma` command line tool in the following two ways.
-
-* **Download prebuilt binary**: From our [CI build server](https://gitlab.science.ru.nl/irma/github-mirrors/irmago/-/jobs/artifacts/master/download?job=binaries). Extract the zip file, and use the binary for your OS and architecture (most likely amd64). Rename the file to `/usr/local/bin/irma` to have it available in your PATH.
-* **Compile and install from source** with `go` and `dep`, as follows:
- ```shell
- go get -d github.com/privacybydesign/irmago
- cd $GOPATH/src/github.com/privacybydesign/irmago
- dep ensure
- go install ./irma
- ```
-
-After installing the `irma` binary, start the server (with increased verbosity but otherwise default configuration):
-```shell
-irma server -v
-```
-Run `irma server -h` to see configuration options. In order to verify your configuration, run `irma server check -v`. General documentation can be found on the [irma server](irma-server.md) page, API documentation of HTTP endpoints can be found on the [api irma server](api-irma-server.md) page.
-
-## Perform a command line IRMA session
-You can perform a first IRMA session using your server on the command line as follows:
-```shell
-irma session --server http://localhost:8088 --disclose pbdf.pbdf.irmatube.type
-```
-([IRMATube attributes](https://privacybydesign.foundation/attribute-index/en/pbdf.pbdf.irmatube.html) are available on the [IRMATube demo](https://privacybydesign.foundation/demo/irmaTube/)) page. This will print a QR that you can scan with your IRMA app, and the attribute contents after they have been received and verified by the server. `irma session` can also perform issuance sessions and attribute-based signature sessions. If you pass `-v` it logs the session request JSON that it sends to your `irma server`.
-
-
-## Installing `irmajs` and an example webpage
-Download the `irmajs` source code, as [zip](https://github.com/privacybydesign/irmajs/archive/master.zip) from GitHub, or using git:
-```shell
-git clone https://github.com/privacybydesign/irmajs && cd irmajs
-```
-
-Like the `irma` command line tool, `irmajs` needs to be compiled before it can be used in the browser. This bundles all dependencies, images and CSS into one JavaScript file. You can obtain a compiled version of `irmajs` in one of the following two ways:
-
-* **Download prebuilt binary**: From our [CI build server](https://gitlab.science.ru.nl/irma/github-mirrors/irmajs/-/jobs/artifacts/master/download?job=bundle). Extract the files into the `dist` folder of `irmajs.`
-* **Compile from source**, as follows:
- ```shell
- git clone https://github.com/privacybydesign/irmajs && cd irmajs
- npm i
- npm run build
- ```
-
-The `irma.js` JavaScript file in the `dist` folder (or from the zip file) can now be included in a ``) you can start an IRMA disclosure session as follows:
-
-```js
-const request = {
- 'type': 'disclosing',
- 'content': [{
- 'label': 'Over 18',
- 'attributes': [ 'irma-demo.MijnOverheid.ageLower.over18' ]
- }]
-};
-
-irma.startSession(server, request)
- .then(({ sessionPtr, token }) => irma.handleSession(sessionPtr, {server, token}))
- .then(result => console.log('Done', result));
-```
-
-This assumes you have an [`irma server`](irma-server.md) that is configured to [accept unauthenticated session requests](irma-server.md#requestor-authentication) listening at the URL indicated by `server`.
-
-For complete examples, see the `examples` folder. You can host these examples using the IRMA server, with:
-
- irma server -v --static-path examples/browser
diff --git a/website/versioned_docs/version-v0.2.0/keyshare-protocol.md b/website/versioned_docs/version-v0.2.0/keyshare-protocol.md
deleted file mode 100644
index 5a66fb3..0000000
--- a/website/versioned_docs/version-v0.2.0/keyshare-protocol.md
+++ /dev/null
@@ -1,171 +0,0 @@
----
-title: Keyshare protocol
-id: version-v0.2.0-keyshare-protocol
-original_id: keyshare-protocol
----
-
-
-
-
-This document describes the goals and details of the IRMA keyshare protocol.
-
-## Introduction
-
-The [IRMA mobile app](https://github.com/privacybydesign/irma_mobile) allows users to obtain and disclose [IRMA attributes](overview.md#cryptographic-entities), as well as attach them to signed statements. Before such an IRMA session proceeds, the IRMA app may ask the user to enter her IRMA PIN code so that the [requestor](overview.md#participants) can be sure that it is indeed the attribute owner initiating the session (as opposed to, e.g., a thief of the user's phone). The verification of the correctness of the IRMA PIN code, and preventing the session from happening when it is not, is the responsibility of the [IRMA keyshare server](https://github.com/privacybydesign/irma_keyshare_server). In order to do this, it interacts with the IRMA app and possibly the IRMA API server in a protocol that we call the *keyshare protocol*. This protocol is documented here.
-
-Each [IRMA scheme](schemes.md) decides whether or not it employs an IRMA keyshare server. If it does, then this keyshare server is involved in any IRMA session that involves attributes that fall under the scheme manager's responsibility.
-
-Upon app installation, the IRMA user *registers* to the keyshare servers of the installed scheme managers. At this point the user chooses her IRMA PIN code. Afterwards, whenever the user performs an IRMA session, the user must first enter her IRMA PIN code. Only if the PIN is correct will the keyshare server allow the session to proceed.
-
-### Goals
-
-The keyshare server must:
-- Authenticate a user as being the same person that registered to the keyshare server in the past, just before an IRMA session occurs,
-- Block the IRMA session from happening when this authentication fails,
-- Allow users to remotely block their IRMA app from performing future IRMA session in case of loss or theft of their phone. That is, the user can *revoke* her own attributes.
-- The keyshare server must not learn the values of any of the attributes of any user, and also not to whom the user discloses attributes.
-
-The latter two points imply that it is insufficient to verify the user's IRMA PIN code locally in the IRMA app, because the IRMA app should not be trusted: the user could create a malicious version that does not check the IRMA PIN. Instead we have chosen to modify the cryptography that is used in IRMA sessions in such a way that the keyshare server's contribution to it is necessary for the session to complete, so that the keyshare server can reliably block sessions from happening by refusing to cooperate.
-
-### IRMA secret keys and keyshares
-
-IRMA is an implementation of the Idemix attribute-based credential (ABC) scheme. In such schemes a *credential* is a set of numbers $(k_0, ..., k_n)$ along with a digital signature over this set of numbers, created by the [issuer](https://credentials.github.io/docs/irma.html#participants) using the [issuer's private key](https://credentials.github.io/docs/irma.html#cryptographic-entities). The ABC scheme provides an *attribute disclosure protocol* in which the user can selectively disclose any subset of the attributes $(k_0, ..., k_n)$ to another party (called the *verifier* or *service provider*), in such a way that the verifier is assured of the validity of the issuer's signature over all attributes (including the ones that were not shown).
-
-In IRMA, the first attribute $k_0$ of a credential is always the user's *secret key*. When the user discloses attributes, this secret key is always kept hidden. The *issuance protocol* in which an issuer grants an IRMA credential to a user is such that whenever the user receives a second or third or $n$-th credential, the value of this secret key $k_0$ of the new credential is the same as that of the user's first credential. Consequentially, the first attributes $k_0$ of all credentials of the user have the same value. Then, when the user discloses two attributes that come from two distinct credentials, the user not only proves to the verifier that she owns two valid signatures over the two credentials, but also that the values of the first attributes (i.e. the secret keys) of the two credential coincides. To the verifier, this proves that even though the two attributes come from distinct credentials, they still come from the same IRMA app, and therefore the same user.
-
-Thus each user has her own secret key, namely the integer that serves as the first attribute in each of her credentials. We shall drop the index and call this integer $m$. Recalling that the signed tuple of attributes of a credential is then $(m, k_1, ..., k_n)$, the purpose of the keyshare protocol is to enforce that the tuple of integers that is effectively signed in the issuance protocol is $(m_u + m_k, k_1, ..., k_n)$, where $m_u$ is known to the user and hidden from the keyshare server (along with all other attributes), and $m_k$ is known to the keyshare server and hidden from the user. That is, the user's secret key is *split* into two halves, one of which resides at the keyshare server (hence its name). Consequentially, the cooperation of the keyshare server in IRMA sessions, which necessarily always involve the secret key $m = m_u + m_k$, has become necessary.
-
-### Splitting the secret key across the user and keyshare server
-
-As mentioned, in IRMA the secret key $m$ is always kept hidden from the verifier using [a zero-knowledge proof](zkp.md). Now let $m = m_u + m_k$ with $m_u$ only known to the user, $m_k$ only known to the keyshare server, and $m$ known to neither. We now describe how we can modify the zero-knowledge proof of the secret key in such a way that the user and keyshare server *jointly* prove knowledge of the number $m$, as follows. We refer to the diagram and use the notation of the [page on zero-knowledge proofs](zkp.md).
-
-* After step 2.2, the user asks the keyshare server to generate its own random $w_k$ and compute $W_k = R^{w_k}$. The keyshare server keeps $w_k$ hidden but sends $W_k$ to the user.
-* The user computes the challenge as $c = H(P, WW_k, \eta)$, and then sends $c$ to the keyshare server.
-* The keyshare server computes $s_k = cm_k + w_k$ and sends this number to the user.
-* Instead of sending $(c,s)$ to the verifier in step 2.5, the user sends $(c, s + s_k)$.
-
-The verifier then uses this tuple to verify the proof of knowledge as it normally would. If both the user and the keyshare server follow the protocol, then the verification equation $c = c'$ will hold, so that the verifier will accept. This is effectively a proof of knowledge of the sum $m = m_u + m_k$, in the sense that the messages going back and forth between the user and verifier have exactly the same structure as they would have if they were a proof of knowledge of $m$ - in fact, to the verifier an execution of this modified protocol is completely indistinguishable from a normal one without a keyshare server. Additionally, the protocol has the following properties:
-
-* The keyshare server essentially proves a normal (i.e., non-Fiat-Shamir heuristic) zero-knowledge proof of $m_k$ to the user. Consequentially, the user learns nothing about the number $m_k$.
-* As the user does not know the number $m_k$ and gains no knowledge of it even through multiple session with the keyshare server, she can impossibly prove knowledge of the sum $m = m_u + m_k$ if the keyshare server refuses to cooperate.
-
-For these reasons this protocol is very well suited for our aims of making the keyshare server's contributions necessary in IRMA sessions, while simultaneously keeping the amount of information that the keyshare server learns about the user, her activities and her attributes as little as possible.
-
-## The protocol
-
-### Overview
-
-We now describe the IRMA keyshare protocol at a high level. When the IRMA app runs for the first time, it registers to the keyshare server, by asking the user for the IRMA PIN that she wishes to use in future sessions, and optionally for her email address. It sends these to the keyshare server. The keyshare server then generates a random username for the user, which is automatically issued to the user as her first attribute. At this point registration is complete in the sense that the user can now receive and disclose attributes. If she entered her email address on registration a confirmation link is sent to it, and if the user clicks on it then the keyshare server issues an email address attribute to the user, and stores the email address.
-
-When performing an IRMA session, the user and keyshare server use the protocol described above to compute a proof of knowledge of the sum $m = m_u + m_k$, with an important addition: when sending the response $s_k$, the keyshare server always includes a digital signature over this number. The keyshare server's public key with which these signatures can be verified is known to all IRMA participants.
-
-Now the IRMA protocol is modified as follows.
-
-* The user authenticates to the keyshare server, by entering her PIN in the IRMA app, which sends it along with the user's username at the keyshare server to the keyshare server. The keyshare server checks if the user is known and if the PIN is correct, and aborts if not.
-* When performing a disclosure or attribute-based signing session, the user engages in the protocol described above with the keyshare server to produce a proof of knowledge of the sum $m = m_u + m_k$, and sends this proof to the verifier.
-* When issuing the user does the same, except for computing and sending the sum $s + s_k$ in the final step of the protocol described above. Instead, the user sends $s$ and $s_k$, along with the keyshare server's signature over $s_k$, separately to the issuer. The issuer then checks the signature over $s_k$, and computes the sum $s + s_k$ which it uses for checking the proof of knowledge.
-
-In this way, the issuer enforces that the user uses the help of the keyshare server in the issuance protocol, and that the resulting credential indeed has $m = m_u + m_k$ as its first attribute. Consequentially, the modified disclosure protocol as described in the second item will succeed, and as the keyshare server's contributions are not directly communicated from the keyshare server to the verifier but only to the user, the keyshare server never learns to whom the user is disclosing attributes.
-
-
-### Registration
-
-When registering, the IRMA app POSTs a message like the one below to the to `/api/v1/client/register` at the keyshare server:
-
-```json
-{
- "email": "example@example.com",
- "language": "en",
- "pin": "0kO3xbCrWMK1336eKzI3KOKWWogGb/oW4xErUd5rwFI=\n",
-}
-```
-
-The email address is optional and may be absent. The `language` indicates the user's preferred language, used for a confirmation mail if the email address is present. Lastly, the `pin` field is computed as `Base64(SHA256(salt, pin))\n` (the trailing newline is there for legacy purposes and will be removed in the future).
-
-### Authentication
-
-During an IRMA session, authenticating to the keyshare server during the protocol between the IRMA client and keyshare server is done by sending the same hashed PIN `Base64(SHA256(salt, pin))\n` as during registration. If the PIN is valid, then the keyshare server returns a signed JWT containing the user's username, having an expiry date of 15 minutes. This JWT later serves as authentication token in the keyshare protocol, described below.
-
-Below, the API endpoints of the keyshare server are described in the order they are called during the IRMA protocol.
-
-* `POST /api/v1/user/isAuthorized`: The client posts the keyshare server's JWT from a previous IRMA session, who responds with
-
- ```json
- {
- "status": status,
- "candidates": [ "pin" ]
- }
- ```
- where status is either `"authorized"` or `"expired"`. (The `candidates` array lists the supported methods for authentication, which is currently only using PIN codes.) If the status is "authorized" then the keyshare protocol itself starts using `/api/v1/prove/getCommitments` described below. Else the user must enter her PIN, after which
-
-* `POST /api/v1/user/verify/pin`: After computing the PIN again as `Base64(SHA256(salt, pin))\n`, a message like the following is sent to the keyshare server:
-
- ```json
- {
- "id": "FVP1kMRcF2s",
- "pin": "0kO3xbCrWMK1336eKzI3KOKWWogGb/oW4xErUd5rwFI=\n"
- }
- ```
- If the PIN is correct for the specified user, then the user has successfully authenticated. The keyshare server then returns the signed JWT that is used as authentication in the rest of the protocol. The signed message of this JWT is like the following:
-
- ```json
- {
- "iss": "name_of_keyshare_server",
- "sub": "auth_tok",
- "exp": 1523914956,
- "user_id": "FVP1kMRcF2s",
- "iat": 1523914056
- }
- ```
-
-### The keyshare protocol
-
-At the start of the keyshare protocol, the client needs to inform the keyshare server which IRMA public keys are involved, in the sense that they are necessary to verify the attributes that are being disclosed. An issuer may have multiple public keys, indexed by integers starting at 0, so the string `"irma-demo.IRMATube-1"` refers to the second public key of the `IRMATube` issuer.
-
-The keyshare server's API endpoints are the following.
-
-* `POST /api/v1/prove/getCommitments`: The client sends a list of public key identifiers (e.g. `["irma-demo.IRMATube-1"]`) to the keyshare server (along with the authentication JWT described above in a HTTP header). If the user is authenticated and the public keys are known to the keyshare server, the keyshare server reacts with a commitment to its part of the secret key, for each of the specified public keys:
-
- ```json
- {
- "c": {
- "irma-demo.IRMATube-1": {
- "P": 121212,
- "Pcommit": 909090,
- }
- }
- }
- ```
- Here `P ` $ = R^{m_k}\mod n$ and `Pcommit ` $=W_k$ is the commitment mentioned above, `Pcommit ` $= W_k = R^{w_k} \mod n$, with $R$ and $n$ coming from the second public key of the `irma-demo.IRMATube` issuer.
-* `POST /api/v1/prove/getResponse`: after calculating the challenge, the client posts it to the keyshare server, who replies with a signed JWT with the following as content:
-
- ```json
- {
- "iss": "name_of_keyshare_server",
- "sub": "ProofP",
- "ProofP": {
- "P": 121212,
- "c": 343434,
- "s_response": 565656
- },
- "iat": 1523914056
- }
- ```
- `s_response` is the response integer $s_k$ in the Schnorr zero-knowledge proof.
-
-This ends the involvement of the keyshare server in the IRMA session. In case of attribute disclosures or attribute-based signatures, the client next merges the keyshare server's contributions `Pcommit` and `s_response` into its proof of knowledge of the secret key. In case of issuance this is skipped; instead the entire JWT from the final endpoint is sent to the issuer alongside the client's own proof of knowledge of its part of the secret key.
-
-The structure of the message in which the client sends the keyshare server's signed response to the issuance session currently unfortunately supports at most one keyshare server simultaneously. This means that it is impossible for two (or more) issuers falling under two distinct scheme managers that use distinct keyshare servers to both issue credential simultaneously to a client (i.e., within one IRMA session). Although this is an unlikely scenario, this will still be fixed in a future version of the protocol. Although all other issuance or disclosure sessions involving multiple keyshare server simultaneously are theoretically already possible, currently no IRMA client yet supports being registered to more than one keyshare server at once.
-
-In addition to these API endpoints, the keyshare server exposes a number of other endpoints that are used by the [MyIRMA webclient](https://github.com/privacybydesign/irma_keyshare_webclient), which allows the IRMA user to manage her registration at the keyshare server. These endpoints are not documented here.
diff --git a/website/versioned_docs/version-v0.2.0/overview.md b/website/versioned_docs/version-v0.2.0/overview.md
deleted file mode 100644
index 9f31085..0000000
--- a/website/versioned_docs/version-v0.2.0/overview.md
+++ /dev/null
@@ -1,184 +0,0 @@
----
-title: Technical overview
-id: version-v0.2.0-overview
-original_id: overview
----
-
-This document presents a technical overview of the IRMA project.
-
-## IRMA terminology
-
-### Participants
-
-* *IRMA app*: (mobile) application that receives attributes, and can disclose them. Also called *client* as it acts as the client in the IRMA protocol.
-* *Verifier* or *service provider*: a party wanting to verify someone's attributes (in order to provide some service).
-* *Issuer* or *Identity provider*: a party wanting to issue attributes to someone.
-* *Issuer*: uses an Idemix private key in order to issue credentials to a client, when instructed to by an identity provider
-* *Requestor*: the service or identity provider that wants to, respectively, verify someone's attributes or issue attributes to them.
-* *Scheme manager*: distributes Idemix public keys, credential types and issuer information to clients and requestors; also decides which issuers may join its domain and what credential types they may issue.
-
-### Cryptographic entities
-
-* *Attribute*: a small piece of data, generally containing a statement about the attribute owner (e.g., '> 18 years old').
-* *Credential*: a group of attributes, jointly signed by the issuer using an Idemix private key, in an interactive protocol (called the *issuance protocol*) between the issuer and client.
-* *Credential type*: each IRMA credential is an instance of a credential type, which determines the names of the contained attributes, its validity period, and by which issuer the credential is issued.
- * *Singleton credential type*: users can store at most one instance of such credential types in her IRMA app.
-* *Idemix private-public keypair*: a pair of related keys:
- * *Idemix private key*: used by the issuer to sign a credential in the issuance protocol.
- * *Idemix public key*: used by a verifier when attributes are disclosed to it, in order to establish that the disclosed attributes have been signed using the corresponding Idemix private key.
-* *Disclosure proof*: a set of disclosed attributes, along with a proof of knowledge showing that these disclosed attributes originated from a credential that was validly signed by the issuer.
-* [*Attribute-based signature*](#attribute-based-signatures): a digital signature, with IRMA attributes cryptographically attached to it, on some document or message.
-
-### Core software projects
-
-* [IRMA mobile app](https://github.com/privacybydesign/irma_mobile): (mobile) application that receives attributes, and can disclose them.
-* [`irma` command](irma-cli.md): contains an IRMA attribute verification and issuance server, scheme management, and more.
-* [irmajs](irmajs.md): javascript library acting as glue between an IRMA server and the requestor's website, allowing the requestor to instruct an API server to issue or verify attributes.
-
-## Overview
-
-IRMA is at its core a set of software projects implementing the Idemix attribute-based credential scheme. An *attribute* is a statement or property about a person, such as "I am over 18 years old" or "my name is John Doe".
-
-These attributes are grouped together in a *credential*. In attribute-based credential schemes such as Idemix, such a credential can be issued to a user by a trusted party called the *issuer*. This issuer creates a digital signature over the credential and its containing attributes using its *private key*. The user receives the credential as well as the issuer's signature in her [IRMA mobile app](https://github.com/privacybydesign/irma_mobile).
-
-After that, the user can disclose these attributes to other parties, who are called *verifiers*, selectively showing some and hiding the other attributes from the credential. The verifier then receives the disclosed attributes, as well as a *proof of knowledge* which proves to the verifier that the user
-
-* knows the attributes from the credential which are not being disclosed
-* owns a valid issuer signature over the disclosed attributes and hidden attributes.
-
-The verifier can check the validity of this proof of knowledge using the issuer's *public key* that corresponds with the private key with which the issuer signed the attributes (thus, the verifier must know this public key). The verifier can tell from this that the user has at some point received the disclosed attributes from the trusted issuer. Therefore, it can trust the authenticity of the attributes. (This proof of knowledge does *not* include a full copy of the signature over the attributes, so that even if all attributes of the credential were disclosed simultaneously, the verifier can impossibly use the received attributes and proof of knowledge to disclose these attributes itself to others.)
-
-In addition to attribute disclosure, users can also attach their attributes to messages in an *IRMA attribute-based signature*. This is explained in more detail [below](#attribute-based-signatures).
-
-## Credential types
-
-In IRMA, each credential is an instance of a *credential type*. A credential type specifies (among other things) how many attributes its instances have, what their names are, and by which issuer instances of this credential type are issued. Credential types are not shared between issuers: even if two issuers would issue two credential types with the same name and with the same amount of attributes having the same names, they still are distinct credential types. On [Github](https://github.com/privacybydesign/pbdf-schememanager/blob/master/pbdf/Issues/irmatube/description.xml) an example of such a credential type is available, defining the "IRMATube" credential type which is issued and verified in [this IRMA demo](https://privacybydesign.foundation/demo/irmaTube/). Schematically, an instance of such a credential type would look as follows.
-
-| Attribute name | Attribute value |
-| -------------- | --------------- |
-| **type** | member |
-| **id** | 123456 |
-
-In this table, the right column are the attribute values which are stored and signed in the credential. The left column contains the attribute names from the credential type.
-
-### Singletons
-
-A credential type can be marked as a *singleton* by the scheme manager. If so the IRMA app will store at most one instance of this credential type simultaneously, and receiving a new one would overwrite any older instance. (Example: [`pbdf.nijmegen.bsn`](https://privacybydesign.foundation/attribute-index/en/pbdf.nijmegen.bsn.html)) If a credential type is not a singleton (example: [`pbdf.pbdf.diploma`](https://privacybydesign.foundation/attribute-index/en/pbdf.pbdf.diploma.html)), then the user can have any number of instances of that credential type in her IRMA app.
-
-### Special attributes
-
-#### The metadata attribute
-
-In IRMA, each credential always contains a special attribute called the *metadata attribute*, which must always be disclosed whenever other attributes are disclosed from this credential. This metadata attribute contains:
-
-* which credential type this credential is an instance of (from which it follows by which issuer this credential was issued),
-* the date at which this credential was issued,
-* the expiry date of this credential.
-
-In order to lessen linkability issues (see the [security properties](#irma-security-properties) section below), the issuance and expiry dates are always chosen to fall on the boundary of an *epoch*, which is one week.
-
-#### The secret key attribute
-
-The first attribute of any IRMA credential is always a 256-bit integer which is called the user's *secret key*. The user's IRMA app randomly chooses and stores this integer when it is run for the first time. Whenever it receives a new credential, the app ensures that this number is used as the first attribute, so that all credentials that the app manages share this integer as their first attribute. Contrary to the metadata attribute this attribute is never disclosed; it is even kept hidden from the issuer during issuance. When the user discloses attributes that come from multiple credentials, the proof of knowledge that the IRMA app calculates and sends to the verifier proves multiple facts:
-
-* The app knows a valid issuer signature over each credential from which attributes are currently being disclosed,
-* The first attribute from all of these credentials coincide.
-
-From this the verifier can conclude that the credentials from which attributes are being disclosed belong to one and the same person; that is, it defends against users pooling their credentials.
-
-## Schemes
-
-IRMA schemes are documented on the [Schemes](schemes.md) page.
-
-## Issuers
-
-Each IRMA issuer has an Idemix private key, which it must keep secret as it is used when issuing credentials, and a corresponding public key which is distributed to attribute verifiers and IRMA apps in the IRMA scheme. An issuer may issue multiple credential types (and a scheme may contain many issuers).
-
-Issuers cannot independently create credential types and start issuing them to IRMA app users: the credential type must first be included in an [IRMA scheme](schemes.md) by the scheme manager. In case of the default scheme `pbdf` of the IRMA app, this is the [Privacy by Design Foundation](https://privacybydesign.foundation/issuance/).
-
-When verifying IRMA attributes, out of all possible attributes the verifier could ask for, it must decide which attributes suite its purposes best. In order to be able to make this decision, it is important that for each credential type it is clearly documented how the attributes are obtained, and how it is ensured that they indeed belong to the person that receives them. For each credential type in the `pbdf` scheme, this is documented on the [Privacy by Design Foundation website](https://privacybydesign.foundation/issuance/).
-
-## IRMA PIN codes using the keyshare server
-
-When a user's device containing her IRMA app along with her attributes is lost or stolen, the finder of the phone can potentially abuse the owner's attributes. In order to protect against this, scheme managers may decide to employ an *IRMA keyshare server*. In this case, whenever a credential type that falls under the scheme is used, the user must enter her PIN code before the IRMA session can proceed. The correctness of this PIN code is verified by the keyshare server. When an incorrect PIN code is entered three times in a row, the keyshare server blocks IRMA sessions by refusing to cooperate, for an amount of time that exponentially increases with the amount of consecutive incorrect PIN codes entered. Additionally, users can remotely block their own IRMA app from performing future IRMA sessions on the keyshare server's website, in case their phone is lost or stolen.
-
-The keyshare server's most important function is twofold. It provides a stronger binding of the attributes to their owner, by forcing the correctness of the IRMA PIN code: as long as the user can be trusted to not reveal her PIN code to anyone, the party that receives the attributes can be sure that the person who is disclosing them right now is the same person as the one to which they were issued in the past. Additionally, it provides a way of blocking future IRMA sessions; currently, this feature is only exposed to the users themselves. The price of these advantages is that there is now a single entity that has to cooperate in each IRMA session. This means that whenever the keyshare server is not online, no user can issue or disclose any of the attributes falling under the authority of the relevant scheme. It is thus very important that this component is carefully protected and monitored. Additionally, the keyshare server learns and records a limited amount of data whenever the user performs an IRMA session (how limited this data is is discussed below).
-
-At the Privacy by Design Foundation we believe that the advantages of using a keyshare server far outweigh the disadvantages, so the Foundation's scheme uses a keyshare server. Like all other software, this server is open source.
-
-At a high level keyshare servers work as follows. The user's secret key is split across the user's IRMA app and the keyshare server: both of them hold a part of the secret key. The actual secret key that is effectively used in each credential from this scheme is the sum of these two secret keys. When the user does not enter the correct PIN code the keyshare server will refuse to use its part of the secret key in the IRMA protocol, making it impossible for the session to complete.
-
-In more detail: whenever a scheme is installed in the IRMA app that uses a keyshare server (or when the IRMA app starts for the first time and encounters a hardcoded scheme manager that uses a keyshare server), the user *registers* at the keyshare server, by entering her email address and choosing a PIN code. The IRMA app chooses and stores a random salt of 8 bytes, calculates `SHA256(salt || PIN)`, and sends this along with the user's email address to the keyshare server.
-
-At that moment, the keyshare server chooses and stores a *keyshare* for this user: a 32-bit integer just like the user's secret key. Whenever the users performs an IRMA session using attributes from this scheme, the following happens:
-
-* The IRMA app sends the email address along with `SHA256(salt || PIN)` to the keyshare server. If this hash is not equal to the hash with which the user registered, the keyshare server aborts the session.
-* Assuming the user entered the correct PIN code, the keyshare server generates a proof of knowledge for its part of the user's secret key and sends this to the IRMA app.
-
-What happens next depends on the type of the IRMA session:
-
-* When receiving newly issued attributes, the IRMA app sends the keyshare's proof of knowledge to the issuance server, who first verifies its correctness and authenticity. If correct and authentic, it completes the issuance session in such a way that the actual secret key used in the resulting credential is the sum of both secret keys: that of the user and that of the keyshare server.
-* When disclosing attributes, the IRMA app merges this proof of knowledge with its own proof of knowledge of its own part of the secret key (and the other hidden attributes) in a certain fashion. The result of this is a valid proof of knowledge of the sum of the two secret keys.
-
-Consequentially, it is cryptographically enforced during issuance that the user will need the keyshare server's cooperation whenever she later wants to disclose attributes from the resulting credential. By refusing to cooperate, the keyshare can completely block the user from using her attributes, which is what happens when the user enters an incorrect PIN code too often.
-
-Additionally, the keyshare server comes with a small website on which users can, after logging in with their email address attribute (which they received upon registering at the keyshare server):
-
-* Instruct the keyshare server to block future IRMA sessions, remotely blocking their own IRMA app;
-* Delete their account at the keyshare server (which also blocks future IRMA sessions),
-* View a log of earlier IRMA transactions and PIN code entry attempts.
-
-As the keyshare server's contribution to the proof of knowledge of the secret key is passed to the verifier through the IRMA app instead of directly from the keyshare server to the verifier, the keyshare server does not know to whom attributes are being disclosed. In fact, the only thing it learns is which issuer (and which Idemix public keys) are involved; it does not get to see which attributes are being disclosed nor their values, nor which attributes are kept hidden, nor how many attributes from how many credentials. The transaction log that the user sees in the keyshare server's website is correspondingly bare.
-
-Summarizing, the keyshare server increases the binding between the attributes and the user through the PIN code and through the option of revocation in case of loss or theft, at the cost of a decrease in the decentral nature of IRMA and in some of the privacy guarantees. In order to keep the privacy cost as low as possible, using various cryptographic means we have tried to keep the amount of information that the keyshare server learns about the participants as small as possible. Although we are still looking at ways to make the keyshare server still more privacy-friendly, at the Privacy by Design Foundation we believe that this tradeoff is already worth it. Thus, the `pbdf` scheme indeed uses a keyshare server (towards users we call it ["MyIRMA"](https://privacybydesign.foundation/myirma/)).
-
-Each scheme manager can decide for itself whether or not to use a keyshare server in its scheme. Currently, however, due to a limitation in the IRMA protocol only one keyshare server can be involved simultaneously in IRMA sessions. This will be solved in future new versions of the IRMA app and the IRMA API server.
-
-Full details on the protocol spoken between the IRMA client and an [IRMA keyshare server](https://github.com/privacybydesign/irma_keyshare_server) is documented on the [Keyshare protocol](keyshare-protocol.md) page.
-
-## Attribute-based signatures
-
-Apart from attribute disclosure, IRMA also supports *attribute-based signatures*: a digital signature with IRMA attributes attached to it, on some document or string (more accurately this can generally be any set of bytes, though currently IRMA only support strings). The IRMA app can create such signatures with any of the attributes that it contains. The validity of such a signature can be verified using the Idemix public keys of the issuers of the used attributes, and valid attribute-based signatures can only be created using valid credentials. Contrary to [disclosure proofs](#cryptographic-entities) which are tied to an authentication session, and thus of no more use afterwards, attribute-based signatures are attached to the document that they sign, so their validity is useful as long as the signed document exist. IRMA attribute-based signatures have the same properties as conventional (non-attribute-based) [digital signatures](https://en.wikipedia.org/wiki/Digital_signature) such as non-repudiation, integrity of the signed message, and unforgeability with respect to the issuer private key. In addition, the attributes are cryptographically verifiably attached to the signature and message.
-
-IRMA attribute-based signatures can be used in any case where conventional (digital or conventional "wet") signatures are used and in which it is necessary to know something about the signature creator. For example:
-
-* A doctor could attach his name and "I am a doctor"-attribute to a medical prescription.
-* Teachers could sign student grades with their "I am a teacher"-attribute.
-* If a bank were to issue bank account numbers as an attribute to bank account owners, then a bank account owner could attach her account number attribute to a statement like "I transfer $10 to account 424242", effectively creating a cheque.
-
-Technically, IRMA attribute-based signatures are very similar to disclosure proofs. As mentioned earlier IRMA disclosures use a challenge-response protocol: the verifier generates a random number called the nonce and sends it to the IRMA app, whose response has to take this nonce into account in a precise fashion (this is achieved using the [Fiat-Shamir heuristic](https://en.wikipedia.org/wiki/Fiat%E2%80%93Shamir_heuristic)). More precisely, the disclosure proof is a digital signature on the nonce that was used; if the nonce was freshly generated then the verifier can be sure that the attribute owner is actually present instead of replaying an earlier or eavesdropped disclosure proof. An IRMA attribute-based signature is the same except that not a nonce but an actual message is signed (or rather its SHA256 hash).
-
-Currently IRMA only supports creating attribute-based signatures on strings, although we plan to support other types of documents as well. They can be created using [irmajs](https://github.com/privacybydesign/irmajs) and verified using [IRMA servers](what-is-irma.md#irma-servers) almost the same as disclosure proofs. An online demo is available on the [website of the Foundation](https://privacybydesign.foundation/demo/ondertekenen/).
-
-## IRMA security properties
-
-* **Credential unforgeability:**
- Only the issuer (that is, the holder of the Idemix private key) can issue credentials that will verify under the Idemix public key. Thus when a verifier receives valid attributes, it can safely assume they were issued by the issuer.
-
-* **Multi-show unlinkability:**
- When a verifier performs two IRMA sessions in which the attributes that it receives are identical, then it cannot tell whether the two IRMA sessions were performed with one user who disclosed the same attributes twice, or with two distinct users. In other words, such sessions are not linkable as coming from the same user. (It is important to note that this property holds only at the cryptographic level; using identifying data from the transport layer such as the user's IP or MAC address verifiers can potentially still link sessions.)
-
-* **Grouping credentials using the private key:**
- When attributes are disclosed coming from multiple credentials, the IRMA app additionally proves that the credentials share the same secret key, and thus that the attributes come from the same user.
-
-* **Eavesdroppers cannot perform replay attacks:**
- When verifying attributes, the verifier first sends a number of random bits called the nonce to the IRMA app, and the IRMA app's reply containing the disclosed attributes and the proofs of knowledge has to fit on this nonce in a precise fashion. Assuming that the verifier never reuses nonces, this means that an eavesdropper cannot replay an IRMA disclosure.
-
-* **Verifiers cannot perform replay attacks:**
- Even if all attributes were disclosed (and the secret key is in fact never disclosed), the IRMA app does not send a complete copy of the credential's signature to the verifier; instead parts of it are hidden using proofs of knowledge. This means that verifiers cannot use what they learn in IRMA disclosures to disclose the received attributes to other verifiers, acting as an IRMA app possessing the attributes that were disclosed to it.
-
-* **No impersonation attacks:**
- The credentials and attributes reside in the IRMA app installation of the users. This is contrary to other identity management systems such as for example "Log in with Facebook": when someone presses such a Facebook login button on some website, it is really Facebook who authenticates on that website on behalf of the user. Consequentially, Facebook can potentially authenticate itself as any of its users to such websites. This is not possible in IRMA.
-
-* **No privacy hotspots:**
- When a user discloses IRMA attributes to a verifier, the attributes are sent directly from the user to the verifier without passing through any central party.
-
-It must be mentioned that these properties only hold assuming that our software contains no bugs that break these properties. For this reason all of the IRMA software is open source so that anyone can verify its correctness. We encourage anyone to inspect the IRMA source code, and inform us of any errors that might lessen security or other aspects of the functionality.
-
-## Other resources
-
-* Website of the [Privacy by Design Foundation](http://privacybydesign.foundation/), the creators and maintainers of IRMA
- * An [introduction to IRMA](https://privacybydesign.foundation/irma-start/) for IRMA app users
- * A general and more complete [introduction to IRMA](https://privacybydesign.foundation/irma-explanation/)
- * [Live IRMA demos](https://privacybydesign.foundation/demo-en/)
-* The Android and iOS [IRMA apps](https://privacybydesign.foundation/download-en/)
diff --git a/website/versioned_docs/version-v0.2.0/schemes.md b/website/versioned_docs/version-v0.2.0/schemes.md
deleted file mode 100644
index d242738..0000000
--- a/website/versioned_docs/version-v0.2.0/schemes.md
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: IRMA schemes
-id: version-v0.2.0-schemes
-original_id: schemes
----
-
-In IRMA, every party ([IRMA apps](https://github.com/privacybydesign/irma_mobile), [IRMA servers](what-is-irma.md#irma-servers), [requestors](overview.md#participants)) must be aware of existing [credential types](overview.md#credential-types), attribute names, and the [issuers](overview.md#issuers) and their public keys. All such information is contained in IRMA *schemes*. It is the task of the *scheme manager* to determine and distribute this information to all parties, in the form of a directory structure [such as this one](https://github.com/privacybydesign/pbdf-schememanager), which contains:
-
-* All information about all issuers that fall under this scheme including their logos,
-* The Idemix public keys of said issuers,
-* All credential types that these issuers may issue, including their logos.
-
-This entire directory structure is signed using an (ECDSA) private-public keypair that the scheme manager has for this purpose.
-
-Each scheme has a *scheme URL*, defined by the `` tag in the root `description.xml`. At that location the scheme manager must host the current version of the scheme. IRMA components that have the scheme installed will periodically update their local version of the scheme using this remote copy.
-
-All of the information contained in the scheme is thus signed by as well as distributed by the scheme manager. This means that the scheme manager has exclusive and total control over which issuers may join his domain, and what credential types and attributes this issuer may issue.
-
-## Scheme directory structure
-
-Schematically the directory structure of a scheme looks as follows:
-
-```text
-SchemeName
-+-- IssuerName
-| +-- Issues
-| | +-- CredentialTypeName
-| | +--- description.xml
-| | +--- logo.png
-| +-- PublicKeys
-| | +-- 0.xml
-| | +-- 1.xml
-| +-- PrivateKeys (need not be present)
-| | +-- 0.xml
-| | +-- 1.xml
-| +-- description.xml
-| +-- logo.png
-+-- description.xml
-+-- index
-+-- index.sig
-+-- timestamp
-+-- pk.pem
-+-- kss-0.pem
-```
-
-Multiple issuers are grouped under the scheme, and each issuer may issue multiple credential types.
-
-Description of the files:
-* A scheme, issuer, or credential type (call it an *entity*) is always stored in `description.xml`, contained in a folder whose name *must* be that of the entity as specified by the xml file.
-* Each issuer and each credential type should include a `logo.png` for in the IRMA app.
-* `index` contains of each file in the tree its SHA256 hash, as well as its path and filename.
-* `index.sig` is an ECDSA signature over the `index`, thus effectively signing each file listed in the `index`.
-* `timestamp` contains the Unix timestamp of the last time the scheme was modified.
-* `pk.pem` is the scheme's public key against which `index.sig` should verify.
-* `kss-0.pem` (optional): if the scheme uses a [keyshare server](keyshare-protocol.md), then this contains the keyshare server's public key.
-
-## Default schemes: `pbdf` and `irma-demo`
-
-Most IRMA software components automatically use the following two schemes:
-
-* [`pbdf`](https://github.com/privacybydesign/pbdf-schememanager): the production scheme of the [Privacy by Design Foundation](https://privacybydesign.foundation/).
-* [`irma-demo`](https://github.com/privacybydesign/irma-demo-schememanager): exclusively for development, demoing and experimenting, as the scheme private key and all issuer private keys are included.
-
-The [Privacy by Design Foundation](https://privacybydesign.foundation/), which develops IRMA and issues a basic set of attributes, is the scheme manager of these two schemes. New issuers wishing to issue attributes under the `pbdf` scheme, or existing issuers wishing to issue new credential types, can [ask](https://privacybydesign.foundation/people#developers) the Foundation to be included in these schemes.
-
-These two schemes are hardcoded into the [IRMA app](https://github.com/privacybydesign/irma_mobile), and if an [`irma`](irma-cli.md) subcommand that requires schemes is run for the first time, these two schemes are downloaded to a default location on disk (`~/.local/share/irma/irma_configuration` on Linux/macOS). It is always possible to use other schemes in conjunction with these two, or without them, either by making a custom build of the IRMA app, or by passing the appropriate options to the `irma` subcommands (see the `--help` messages).
-
-
-## Updating and signing schemes with `irma`
-
-The following `irma scheme` subcommands from the [`irma`](irma-cli.md) command line tool act on IRMA schemes:
-
-* `download`: Download a scheme from its remote URL
-* `issuer`: Manage IRMA issuers within an IRMA scheme
- * `keygen`: Generate a new IRMA issuer private/public keypair
-* `keygen`: Generate ECDSA private/public keypair for scheme signing
-* `sign`: Sign a scheme directory after update its contents
-* `update`: Download scheme updates from its remote URL
-* `verify`: Verify scheme signature and check directory structure
-
-Check `-h` or `--help` of these for usage details.
-
-## Other schemes
-
-Anyone can create their own IRMA scheme. At minimum the following must be done:
-
-* Create a directory structure like the one above (you can use the `scheme` subcommand of the [`irma`](irma-cli.md) command line tool to generate an ECDSA public-private keypair and sign the directory tree);
-* Define at least one issuer and generate its Idemix public-private keypair (again using `irma`), putting the public key in the directory structure;
-* Define at least one credential type that this issuer will issue;
-* Compile a version of the IRMA app with this directory tree hardcoded in it;
-* Host an [`irma server`](irma-server.md) that will issue and verify your credential type (as this server will issue credentials it must have a copy of the scheme directory tree, and the Idemix private key);
-* Create a website using [irmajs](irmajs.md) that will issue and verify instances of your credential type.
diff --git a/website/versioned_docs/version-v0.2.0/session-requests.md b/website/versioned_docs/version-v0.2.0/session-requests.md
deleted file mode 100644
index 77b539f..0000000
--- a/website/versioned_docs/version-v0.2.0/session-requests.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-title: Session requests
-id: version-v0.2.0-session-requests
-original_id: session-requests
----
-
-> In an upcoming update of the IRMA software the session request format has changed, with new features for the requestor. [More details](/condiscon).
-
-Each [IRMA server](what-is-irma.md#irma-servers) exposes APIs for creating IRMA sessions with a session request. An *IRMA session request* contains all information required for the IRMA server and [IRMA app](https://github.com/privacybydesign/irma_mobile) to perform an IRMA session with, such as the attributes to be issued or verified. This page documents IRMA session requests. It applies to:
-
-* The [`POST /session`](api-irma-server.md#post-session) endpoint from [`irma server`](irma-server.md).
-* The [`StartSession()` function](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver#StartSession) in the `irmaserver` Go library.
-* The [`startSession()` function](api-irmajs.md#startsession) of `irmajs`.
-
-## Session request data types
-
-For each of the [three IRMA session types](what-is-irma.md#session-types), we define a *session request* data type. Each request contain a `type` field whose value is `"disclosing"`, `"signing"` or `"issuing"`. For the precise role of session requests in an IRMA session, see this [diagram of an IRMA session](what-is-irma.md#irma-session-flow).
-
-### Disclosure requests
-Disclosure requests are started with an [`irma.DisclosureRequest`](https://godoc.org/github.com/privacybydesign/irmago#DisclosureRequest). Example:
-```json
-{
- "type": "disclosing",
- "content": [{
- "label": "Age limit",
- "attributes": [
- "irma-demo.MijnOverheid.ageLimits.over18",
- "irma-demo.MijnOverheid.ageLimits.over21"
- ]
- },
- {
- "label": "First name",
- "attributes": [
- "irma-demo.MijnOverheid.fullName.firstname"
- ]
- }]
-}
-```
-This asks the user for either an `over18` attribute or an `over21` attribute, *and* a `firstname` attribute. The `"Age limit"` and `"First name"` labels are shown in the IRMA app when the user is asked for permission to disclose these attributes, next to the candidate attributes.
-
-Each element of `content` in this example is called an *attribute disjunction*, as it asks for any one of the attributes listed in `attributes`. Specific attribute values can be requested by setting `attributes` to a map instead of a list. For example, setting `attributes` to
-```json
-{ "irma-demo.MijnOverheid.ageLimits.over18": "yes" }
-```
-would only be satisfied by an `over18` attribute whose value is `yes`.
-
-The `content` array may contain multiple such attribute disjunctions, each of which the user must satisfy with an attribute (they are `AND`ed together). Thus `content` contains a *conjunction of disjunctions* of IRMA attributes.
-
-### Attribute-based signature requests
-Attribute-based signature sessions are started with an [`irma.SignatureRequest`](https://godoc.org/github.com/privacybydesign/irmago#SignatureRequest), which are similar to disclosure requests:
-```json
-{
- "type": "signing",
- "message": "Message to be signed by user",
- "content": ...
-}
-```
-`content` is an array of attribute disjunctions just as in disclosure requests.
-
-### Issuance requests
-Issuance sessions are started with an [`irma.IssuanceRequest`](https://godoc.org/github.com/privacybydesign/irmago#IssuanceRequest). Example:
-```json
-{
- "type": "issuing",
- "credentials": [{
- "credential": "irma-demo.MijnOverheid.ageLower",
- "attributes": {
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no"
- }
- }],
- "disclose": ...
-}
-```
-`disclose` is an optional array of attribute disjunctions just as in disclosure requests. If this is provided then a *combined disclosure-issuance* session is performed: the user needs to disclose the attributes from `disclose` first before receiving the new attributes.
-
-### Extra parameters
-For each API that accepts one of the above session request data types, the requestor can provide additional parameters to configure the session at the IRMA server, by providing an *extended session request* instead, as follows:
-```json
-{
- "validity": 120,
- "timeout": 120,
- "callbackUrl": "https://example.com",
- "request": ...
-}
-```
-
-## JWTs: signed session requests
-The IRMA API server or [`irma server`](irma-server.md) can be configured such that it only accepts session requests that have been digitally signed in the form of a [JWT](https://jwt.io). The form of the JWT depends on the [session type](what-is-irma.md#session-types). For example, here is a JWT produced by the [IRMATube demo](https://privacybydesign.foundation/demo/irmaTube):
-```
-eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImlybWF0dWJlIn0.eyJpYXQiOjE1NTA0MjQ4NDcsImlzcyI6IklSTUFUdWJlIiwic3ViIjoidmVyaWZpY2F0aW9uX3JlcXVlc3QiLCJzcHJlcXVlc3QiOnsidmFsaWRpdHkiOjYwLCJyZXF1ZXN0Ijp7ImNvbnRlbnQiOlt7ImxhYmVsIjoiTWVtYmVyc2hpcCIsImF0dHJpYnV0ZXMiOlsicGJkZi5wYmRmLmlybWF0dWJlLnR5cGUiXX0seyJsYWJlbCI6IkFnZSBvdmVyIDEyIiwiYXR0cmlidXRlcyI6WyJwYmRmLnBiZGYuYWdlTGltaXRzLm92ZXIxMiIsInBiZGYubmlqbWVnZW4uYWdlTGltaXRzLm92ZXIxMiJdfV19fX0.4_b12I4fwXVE5QRf7ll1K-FhjeDYQk3a4XTiykIuWW61gY9VwzJrazWDWU7PRJfb0BgLU36cyw9K5FeQPpsIRxXhFxde4ueAjAixNWtn1JG1Nt_L-7LEOV3cl6G7TAGdVx_-WrLctBQ99NMHWL4_xJ8pY253vI6oQjqp0TTwMPkOAp-taZiRY5AEW0Itj1dbX09WWbxIegL7-SIhi-kjrz-ia6h-l2udAVaeCzpQX_-1Sqm1z8-Fi4lhcRNVituCGMgsWAPUNNPExlOY1YJmuLUogvSIClW6hqTUafVxWqQ-DLJFNBWLzlOoiSj6WqtkEX5r5AsFHKpI5383umcJqA
-```
-In case of disclosure sessions, the body of the JWT (the part in between the two dots) contains a Base64-encoding of the following:
-```json
-{
- "iat": 1550424847,
- "iss": "IRMATube",
- "sub": "verification_request",
- "sprequest": ...
-}
-```
-The fields are as follows:
-* `iat`: Unix timestamp of the creation date of the JWT. IRMA servers may reject JWTs beyond a certain age.
-* `iss`: contains the requestor name, and is used by the IRMA server to lookup the appropriate key with which to verify the JWT.
-* `sub`: JWT subject, in case of disclosure sessions this must always be `"verification_request"`.
-* `sprequest`: contains an extended disclosure session request as defined above.
-
-For each possible session type, the contents of the `sub` field and the name of the field containing the session request must be as follows.
-
-| Session type | `sub` contents | Session request field name |
-| ------------ | -------------- | -------------------------- |
-| Disclosure | `verification_request` | `sprequest` |
-| Attribute-based signature | `signature_request` | `absrequest` |
-| Issuance | `issue_request` | `iprequest` |
-
-Currently the following libraries can produce JWTs of this form:
-* The [`irma`](https://godoc.org/github.com/privacybydesign/irmago) Go library
-* The [`irmajs`](irmajs.md) Javascript library
-* The [`irma-requestor`](https://github.com/privacybydesign/irma-requestor) PHP library
-* The [`irma_api_common`](https://github.com/privacybydesign/irma_api_common) Java library
-* The [`irma-diva-js`](https://github.com/Alliander/diva-irma-js) Javascript library
-
-`irma server` currently supports JWTs signed (asymmetrically with RSA) with the `RS256` algorithm, and (symmetrically signed with HMAC-SHA256) `RS256`. The IRMA API server only supports `RS256`.
diff --git a/website/versioned_docs/version-v0.2.0/what-is-irma.md b/website/versioned_docs/version-v0.2.0/what-is-irma.md
deleted file mode 100644
index 3b8f4b3..0000000
--- a/website/versioned_docs/version-v0.2.0/what-is-irma.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: What is IRMA?
-id: version-v0.2.0-what-is-irma
-original_id: what-is-irma
----
-
-IRMA is a set of software projects implementing the Idemix attribute-based credential scheme, allowing users to safely and securely authenticate themselves as privacy-preserving as the situation permits. Users receive digitally signed attributes from trusted issuer, storing them in their IRMA app, after which the user can selectively disclose attributes to others. Schematically:
-
-
-
-
-
-
-Using the issuer's digital signature over the attributes the verifier can verify that the attributes were given to the user in the past, and that they have not been modified since.
-
-## IRMA session flow
-
-A typical IRMA session is depicted schematically below.
-
-![IRMA session flow](assets/irmaflow.png)
-
-Software components:
-* *Requestor backend and frontend*: Generally the requestor runs a website with a (JavaScript) frontend in the user's browser, and a backend server. During an IRMA session the frontend displays the IRMA QR that the IRMA app scans. All frontend tasks depicted in the diagram are supported by [`irmajs`](irmajs.md).
-* [*IRMA server*](#irma-servers): Handles IRMA protocol with the IRMA app for the requestor.
-* [*IRMA mobile app*](https://github.com/privacybydesign/irma_mobile): [Android](https://play.google.com/store/apps/details?id=org.irmacard.cardemu), [iOS](https://itunes.apple.com/nl/app/irma-authentication/id1294092994).
-
-Explanation of the steps:
-
-1. Usually the session starts by the user performing some action on the website (e.g. clicking on "Log in with IRMA").
-1. The requestor sends its [session request](session-requests.md) (containing the attributes to be disclosed or issued, or message to be signed) to the [IRMA server](#irma-servers). Depending on its configuration, the IRMA server accepts the session request only if the session request is authentic (e.g. a validly signed [session request JWT](session-requests.md#jwts-signed-session-requests)) from an authorized requestor.
-1. The IRMA server accepts the request and assigns a session token (a random string) to it. It returns the contents of the QR code that the frontend must display: the URL to itself and the session token.
-1. The frontend ([`irmajs`](irmajs.md)) receives and displays the QR code, which is scanned by the IRMA app.
-1. The IRMA app requests the session request from step 1, receiving the attributes to be disclosed or issued, or message to be signed.
-1. The IRMA server returns the session request.
-1. The IRMA app displays the attributes to be disclosed or issued, or message to be signed, and asks the user if she wants to proceed.
-1. The user accepts.
-1. The IRMA server performs the IRMA protocol with the IRMA app, issuing new attributes to the user, or receiving and verifying attributes from the user's IRMA app, or receiving and verifying an attribute-based signature made by the user's app.
-1. The session status (`DONE`, `CANCELLED`, `TIMEOUT`), along with disclosed and verified attributes or signature depending on the session type, are returned to the requestor.
-
-Additional notes:
-
-* Which of these tasks are performed by the requestor's backend and which by its frontend differs case by case:
- - Often the session request is sent to the IRMA server by the requestor's backend, after which the IRMA server's reply in step 2 is forwarded to the frontend which renders it as a QR code. Step 1 can however also be done by `irmajs`, in which case `irmajs` automatically picks up the IRMA server's reply in step 2 and renders the QR code.
- - Similarly, `irmajs` can be instructed to fetch the session result in step 10, but this can also be done in the backend.
-* The IRMA server could be deployed on the same machine as the requestor's backend, but it need not be; possibly it is not even controlled by the requestor. In case the [`irmaserver`](irma-server-lib.md) library is used, steps 2/3 and 10 are function calls.
-
-## Session types
-
-In an IRMA session, the [IRMA mobile app](https://github.com/privacybydesign/irma_mobile) performs one of the following three *session types* with an [*IRMA server*](#irma-servers):
-
-* *Disclosure sessions*: Upon receiving a list of requested attributes from the IRMA server, the app discloses the required attributes to the IRMA server if the app user agrees, after which they are verified by the IRMA server.
-* *Attribute-based signature sessions*: Similar to disclosure sessions, but the attributes are attached to a message digitally signed into an [*attribute-based signature*](overview.md#attribute-based-signatures). The attribute-based signature can be verified at any later time, ensuring that the signed message is intact, and that the IRMA attributes attached to it were valid at the time of creation of the attribute-based signature.
-* *Issuance sessions*: the IRMA app receives a new set of IRMA attributes including valid issuer signatures from the IRMA server, to use in later disclosure or attribute-based signature sessions. (Possibly the user is asked to disclose some attributes as well, within the same IRMA session, before receiving the new attributes. This is called a *combined issuance-disclosure session*.)
-
-This process is depicted schematically and explained in more detail [here](what-is-irma.md#irma-session-flow). For the user, after scanning the QR in his/her IRMA app a disclosure session generally looks like the following. (Attribute-based signature sessions and issuance sessions are identical in terms of their flow (scan qr, provide permission, success screen); only the graphical interface is different.)
-
-
-
-
-
-
-## IRMA servers
-
-Various existing software components documented on this website can perform the role of the IRMA server.
-Apart from exposing an API that is used by the IRMA app during IRMA sessions, each of these components also offer an API with which IRMA sessions can be started and monitored, for use by the [*requestor*](overview.md#participants): the party wishing to issue attributes to or verify attributes from an IRMA app. The IRMA server handles the IRMA session with the IRMA app for the requestor.
-
-Currently the following IRMA servers exist:
-
-* The `irma server` command of the [`irma`](irma-cli.md) binary: a standalone daemon exposing its requestor API as HTTP endpoints. [Documentation](irma-server.md); [API reference](api-irma-server.md).
-* The `irmaserver` Go library, exposing a HTTP server that handles IRMA sessions with the IRMA app, and Go functions for starting and managing IRMA sessions. [Documentation](irma-server-lib.mdrary); [API reference](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver).
-* The now deprecated [`irma_api_server`](https://github.com/privacybydesign/irma_api_server).
-
-## About this documentation
-
-IRMA uses JSON to pass messages within IRMA sessions. The majority of IRMA is [written in Go](https://github.com/privacybydesign/irmago), and the JSON messages generally correspond to specific Go structs. For example, the [`GET /session/{token}/result`](api-irma-server.md#get-session-token-result) endpoint of the [`irma server`](irma-server.md) outputs instances of the [`server.SessionResult`](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult). In such cases, a link to the corresponding Go struct will be included. This can tell you what fields you can use or expect. (Note that some structs have custom (un)marshalers. See also the [Go documentation](https://blog.golang.org/json-and-go) on JSON and Go.)
diff --git a/website/versioned_docs/version-v0.2.0/workshop.md b/website/versioned_docs/version-v0.2.0/workshop.md
deleted file mode 100644
index 0edd663..0000000
--- a/website/versioned_docs/version-v0.2.0/workshop.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: May 22 IRMA Workshop
-id: version-v0.2.0-workshop
-original_id: workshop
----
-
-## Resources
-
-- Technical documentation: https://irma.app/docs
-- IRMA source code: https://github.com/privacybydesign/
-- Attribute index: https://privacybydesign.foundation/attribute-index/en/
-- Slack: ask for invite
-
-Other resources:
-- Privacy by Design Foundation website: https://privacybydesign.foundation/
-- Privacy by Design Foundation twitter: https://twitter.com/IRMA_privacy/
-- Attribute issuance: https://privacybydesign.foundation/issuance
-
-## Prerequisites
-
-Make sure you have installed the IRMA app on your [Android](https://play.google.com/store/apps/details?id=org.irmacard.cardemu) or [iOS](https://itunes.apple.com/nl/app/irma-authentication/id1294092994) device.
-
-If you haven't before, try one of the demos on our [demo page](https://privacybydesign.foundation/demo/). For many demos you need for example an [email or age limit attribute](https://privacybydesign.foundation/issuance/). [IRMATube](https://privacybydesign.foundation/demo/irmaTube) is an entirely self-contained demo.
-
-## Part 1
-
-For this part, follow the instructions in the [Getting Started](getting-started.md) page of the technical documentation. You will download or compile from source the IRMA command line tool, which includes the IRMA server. You then download or compile the `irmajs` JavaScript library and let the IRMA server host the static pages.
-
-This IRMA server automatically detects your LAN IP address, and adjusts the URL in the QR to match that address. This is necessary because the IRMA app on your phone somehow needs to connect to your server. However, not all network allow direct LAN access, especially not corporate wifi. Mobile hotspots often work well.
-
-#### Using a workshop server
-
-To bypass any compilation and network issues, you can also use one of our workshop Debian Linux servers over an SSH connection. Please reserve one by grabbing a token at the front of the room. Then edit and execute the following:
-
-```
-PASSWORD=...
-SERVER_NUMBER=01
-
-wget -O irma_workshop_id_rsa "https://irma.app/irma_workshop_id_rsa_${PASSWORD}"
-chmod 600 irma_workshop_id_rsa
-ssh -i irma_workshop_id_rsa "debian@irma${SERVER_NUMBER}.irma.app"
-```
-
-Add the `PASSWORD` you received during the workshop (as a super basic precaution). The private key gives access to all workshop servers. Enter the two-digit server number that's on your token as `SERVER_NUMBER`.
-
-You can then run the example with `./run_example.sh` and browse to the address listed in the output. The server is completely yours to use for purposes of the workshop, and can also be easily reset on request.
-
-
-## Part 2
-Integrate IRMA attribute verification in your own website or application, for example with one of the following use cases:
-
-* Use case 1: Instead of logging in with username/passwords, users can register and then login at your website by showing their IRMA email address attribute ([index](https://privacybydesign.foundation/attribute-index/en/pbdf.pbdf.email.html), [issuance](https://privacybydesign.foundation/issuance/email/), [info](https://privacybydesign.foundation/issuance-email/)).
-* Use case 2: Auto-fill an HTML form in your website by asking the user to disclose IRMA attributes, as in [this demo](https://privacybydesign.foundation/demo/adres/).
-* Use case 3: Ask your users to provide, for example, consent to receive ads per email, with an [attribute-based signature](what-is-irma.md#session-types).
-* Use case 4 (experimental): if you develop an iOS or Android app, start an IRMA session from within your app using these libraries: [iOS](https://github.com/privacybydesign/irmaios), [Android](https://github.com/privacybydesign/irmaandroid).
-
-## Advanced/take home exercises
-
-1. In production scenarios, you should switch to the [`pbdf`](https://github.com/credentials/pbdf-schememanager) [scheme](schemes.md), which contrary to the [`irma-demo`](https://github.com/credentials/irma-demo-schememanager) scheme contains actual personal data.
-2. Start issuing your own attributes, as follows:
- 1. Create a new credential type within the `irma-demo` scheme, and re-sign the scheme (`irma scheme sign`)
- 2. Create a custom build of the IRMA app [`irma_mobile`](https://github.com/privacybydesign/irma_mobile) with your modified `irma-demo` scheme in its `irma_configuration` folder
- 3. Start an `irma server` and point it to your modified `irma-demo` scheme, e.g. with the `--schemes-path` flag
- 4. Start an issuance session of your new credential type, e.g. by modifying the [`irmajs` browser demo](https://github.com/privacybydesign/irmajs)
-3. The HTTP endpoints exposed by the `irma server` are also available as Go functions in the [`irmaserver`](irma-server-lib.md) Go library, and as C functions [here](https://github.com/privacybydesign/irmago/tree/master/server/irmac). Enable IRMA attribute verification and issuance from your own favorite programming language by binding to these C functions.
\ No newline at end of file
diff --git a/website/versioned_docs/version-v0.2.0/zkp.md b/website/versioned_docs/version-v0.2.0/zkp.md
deleted file mode 100644
index 7b4c447..0000000
--- a/website/versioned_docs/version-v0.2.0/zkp.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Zero-knowledge proofs
-id: version-v0.2.0-zkp
-original_id: zkp
----
-
-
-
-
-IRMA uses zero-knowledge proofs to prove that a number satisfies a certain property, without disclosing the number itself, in various situations. In particular:
-
-* When a user discloses part of the attributes of a credential, she hides the others using a zero-knowledge proof, with which she convinces the verifier that she possesses a valid issuer signature over all attributes from the credential, including the hidden ones.
-* The user always uses the same number - her *secret key* - as the first attribute of each credential she receives, by proving to the issuer that she knows the number, without disclosing it to the issuer. This way the issuer can safely sign this attribute (together with the other ones) without knowing it.
-
-Here we briefly review how zero-knowledge proofs are used in IRMA. We take the following:
-
-* Let $G$ be a (multiplicatively written) [cyclic group](https://en.wikipedia.org/wiki/Cyclic_group). In Idemix which IRMA implements, this is $G = QR(n)$, the subgroup of [quadratic residues](https://en.wikipedia.org/wiki/Quadratic_residue) in the integers modulo $n$, with $n = p q$ a product of [safe primes](https://en.wikipedia.org/wiki/Safe_prime).
-* Let $R$ be a generator of $G$ - that is, any element $P$ from $G$ can be written as $P = R^m$ for some integer (attribute) $m$. (Such a generator always exists because $G$ is cyclic.)
-
-Now suppose that $R$ and $P$ are known, and the (IRMA) user wishes to convince someone (the *verifier*) that she knows the number $m$ which is such that $P = R^m$. IRMA uses *zero-knowledge proofs in the Fiat-Shamir heuristic* for this. Skipping many details, the following happens:
-
-1. The verifier sends a random number $\eta$ called the *nonce* to the user.
-1. The user:
- 1. generates a random number $w$
- 1. computes the *commitment* $W = R^w$,
- 1. computes the *challenge* $c = H(P, W, \eta)$, where $H$ is a hash function (e.g., SHA256)
- 1. computes the *response* $s = cm + w$,
- 1. sends the tuple $(c, s)$ to the verifier.
-1. The verifier computes $W' = R^sP^{-c}$ and $c' = H(P, W', \eta)$, and then verifies that $c = c'$.
-
-If $c$ and $s$ are correctly computed, then $W' = R^sP^{-c} = R^{cm+w}R^{-mc} = R^w = W$, so that the verification equation $c' = H(P, W', \eta) = H(P, W, \eta) = c$ indeed holds. Additionally, when correctly implemented this protocol guarantees the following:
-* The user indeed knows $m$ (more precisely: if the user does not know the number $m$ then it cannot make the verifier accept),
-* The verifier learns nothing about the value or properties of $m$ that it did not already know, except that it is known to the user.
-
-The actual zero-knowledge proof protocol implemented in IRMA allows for simultaneous proving knowledge of *multiple* hidden numbers, instead of just the one $m$ like the protocol above. This extension is essentially straightforward and not relevant here.
-
-Due to the fact that the order of the group $QR(n)$ in which the proofs take place is not known to all participants (in fact, this group order is the IRMA issuer's secret key), the proofs of knowledge in IRMA are slightly more complicated than they would be if the group order were known (such as for example in elliptic curves). For example, if the group order were known then the response $s = cm + w$ from step 2.4 above would be reduced modulo the group order. Instead in IRMA we have to choose $w$ to be very large so that even without this modular reduction it still completely hides $m$. For full details about proofs of knowledge in this situation, we refer to Appendix C of the [Identity Mixer specification](https://dominoweb.draco.res.ibm.com/reports/rz3730_revised.pdf).
diff --git a/website/versioned_docs/version-v0.3.0/api-irma-server.md b/website/versioned_docs/version-v0.3.0/api-irma-server.md
deleted file mode 100644
index 984e1b2..0000000
--- a/website/versioned_docs/version-v0.3.0/api-irma-server.md
+++ /dev/null
@@ -1,151 +0,0 @@
----
-title: irma server
-id: version-v0.3.0-api-irma-server
-original_id: api-irma-server
----
-
-```shell
-irma server [options...]
-```
-
-The API that this server offers consists of two parts:
-
-* Endpoints under `/irma`. This is used exclusively by the [irmaclient](https://github.com/privacybydesign/irmago/tree/master/irmaclient)/[IRMA app](https://github.com/privacybydesign/irma_mobile), and is not documented here.
-* Endpoints under `/session` with which IRMA session requestors can start IRMA sessions, monitor their status and retrieve their result afterwards.
-
-## API reference
-
-
-
-For each of these endpoints, if the HTTP status code indicates that the request was not successful (i.e. not in the 2xx range), then the server returns an [`irma.RemoteError`](https://godoc.org/github.com/privacybydesign/irmago#RemoteError) instance. For example, attempting to [retrieve the session result](#get-session-token-result) of an unknown session returns
-```json
-{"status": 400, "error": "SESSION_UNKNOWN", "description": "Unknown or expired session"}
-```
-The following fields may occur in this message:
-* `status`: HTTP error code associated to this error
-* `error`: an error `Type` from the list of possible errors in the [server API documentation](https://godoc.org/github.com/privacybydesign/irmago/server#Error)
-* `description`: English human-readable description of this error
-* `message`: May contain additional information
-* `stacktrace`: Stack trace of the error, only if verbose mode is enabled
-
----
-
-### `POST /session`
-
-Start an IRMA session. What to POST to this endpoint depends on the server configuration:
-
-* If `no_auth` is true, an [(extended) JSON session request](session-requests.md)
-* If `no_auth` is false:
- * [(extended) JSON session request](session-requests.md) with an API token in the `Authorization` HTTP header
- * [JWT session request](session-requests.md#jwts-signed-session-requests) signed with RS256 or HS256
-
-If `no_auth` is false, then which of these options should be taken depends on the [`requestors`](irma-server.md#requestor-authentication) option passed to the `irma server`.
-
-In each case an appropriate `Content-Type` with `text/plain` or `application/json` must be included.
-
-If the request was successfully parsed, and authenticated if applicable, then the server returns a *session package*:
-```json
-{
- "token":"KzxuWKwL5KGLKr4uerws",
- "sessionPtr": {"u":"https://example.com/irma/ysDohpoySavbHAUDjmpz","irmaqr":"disclosing"}
-}
-```
-In the endpoints below, the `{token}` placeholder must be replaced with the above session `token`. The `sessionPtr` points to the IRMA session for the IRMA app user, and should be displayed as a QR for the user to scan, or encoded in a universal link for a mobile session, e.g. using [`handleSesion()`](api-irmajs.md#handlesession) from `irmajs`.
-
-Each session starts in the `"INITIALIZED"` [session status](#get-session-token-status). Regardless of how it reaches its ending status (`"DONE"`, `"CANCELLED"`, `"TIMEOUT"`), it is kept in memory for 5 minutes after reaching its ending status. After that all endpoints below requiring the session `token` return error `"SESSION_UNKNOWN"`.
-
----
-
-### `DELETE /session/{token}`
-
-Cancel the session: set the [session status](#get-session-token-status) to `"CANCELLED"`.
-
----
-
-### `GET /session/{token}/status`
-
-Retrieve the [session status](https://godoc.org/github.com/privacybydesign/irmago/server#Status) as a JSON string. Returns one of:
-* `"INITIALIZED"`: the session has been started and is waiting for the client
-* `"CONNECTED"`: the client has retrieved the session request, we wait for its response
-* `"CANCELLED"`: the session is cancelled: the user refused, or the user did not have the requested attributes, or an error occurred during the session
-* `"DONE"`: the session has completed successfully
-* `"TIMEOUT"`: session timed out
-
-Of these the latter three are *ending statuses*; once the session reaches such a status, it will not switch status again. A session starts as `"INITIALIZED"` and reaches one of the ending statuses either directly or after becoming `"CONNECTED"`.
-
-> The session is cancelled and receives status `"CANCELLED"` not only when the IRMA app user refuses, but also when the session is aborted due to an error.
-
-> If the session is cancelled due to the user aborting, it is (by design) not possible using this or the other endpoints of the `irma server` to distinguish between (1) the user had the requested attributes but refused to disclose them, and (2) the session was aborted by the user's IRMA app because (s)he did not have the required attributes.
-
----
-
-### `GET /session/{token}/statusevents`
-
-Subscribe to a [server-sent event](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events) stream of status updates. Whenever the session status changes, an event is sent with the new session status as a JSON string. If you need to monitor the status of a session, this is preferred over polling to `GET /session/{token}/status`.
-
----
-
-### `GET /session/{token}/result`
-
-Get the [session result](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult). Example output:
-```json
-{
- "type" : "disclosing",
- "status" : "DONE",
- "disclosed" : [
- [{
- "status" : "PRESENT",
- "rawvalue" : "yes",
- "id" : "irma-demo.MijnOverheid.ageLower.over18",
- "value" : {
- "en" : "yes",
- "nl" : "yes",
- "" : "yes"
- }
- }]
- ],
- "proofStatus" : "VALID",
- "token" : "ELMExi5iauWYHzbH7gwU"
-}
-```
-The response may contain the following fields:
-* `token`: Session token
-* `status`: Current [session status](#get-session-token-status)
-* `type`: [Session type](what-is-irma.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
- * `"INVALID_TIMESTAMP"`: Attribute-based signature has invalid timestamp
- * `"UNMATCHED_REQUEST"`: proofs do not correspond to a specified request
- * `"MISSING_ATTRIBUTES"`: proofs do not contain all requested attributes
- * `"EXPIRED"`: Attributes were expired at creation time
-* `disclosed`: List of [attributes disclosed](https://godoc.org/github.com/privacybydesign/irmago#DisclosedAttribute) by the user. The array structure mirrors that of the [session request](session-requests#disclosure-requests) that started the session: the i-th item of the outer array is a conjunction of attributes satisfying the i-th outer conjunction of the session request. (*Note*: if the session was started with a legacy, pre-[condiscon](condiscon.md) session request, then this array structure has a different legacy structure; see the [legacy documentation](/v0.2.0/api-irma-server#get-session-token-result))
-* `signature`: The full attribute-based signature in case of `"signing"` sessions
-* `error`: Error message in case of failure
-
-If the session is not yet finished (that is, the session status is `INITIALIZED` or `CONNECTED`), then only the first three fields are populated. (For getting just the current session status, using [`GET /session/{token}/statusevents`](#get-session-token-statusevents) or [`GET /session/{token}/status`](#get-session-token-status) is preferred.)
-
-This endpoint just fetches the session result, and works normally even if the session failed. If so, the `status`, `proofStatus` or `error` fields will indicate what happened. Be sure to check these fields when retrieving and handling the session result.
-
----
-
-### `GET /session/{token}/result-jwt`
-
-If a JWT private key was [provided in the configuration of the `irma server`](irma-server.md#signed-jwt-session-results), then this returns a [JWT](https://jwt.io) signed by the `irma server` with the message from [`GET /session/{token}/result`](#get-session-token-result) above as JWT body, along with the following standard JWT fields:
-* `iss`: name of the current `irma server` as defined in its configuration
-* `iat`: Unix timestamp indicating when this JWT was created
-* `sub`: `verification_result` or `signing_result` or `issuing_result`
-
-This way, even if the session result from the `irma server` travels along an untrusted route (for example the user's browser), the session result can still be validated and trusted.
-
----
-
-### `GET /session/{token}/getproof`
-
-Also returns a session result JWT, but one whose structure is the same as the session JWTs returned by the [`irma_api_server`](https://github.com/privacybydesign/irma_api_server). Only works if a JWT private key was [provided in the configuration of the `irma server`](irma-server.md#signed-jwt-session-results).
-
----
-
-### `GET /publickey`
-
-If a JWT private key was [provided in the configuration of the `irma server`](irma-server.md#signed-jwt-session-results), then this returns the corresponding public key in PEM with which the server's session result JWTs returned by [`GET /session/{token}/result-jwt`](#get-session-token-result-jwt) and [`GET /session/{token}/getproof`](#get-session-token-getproof) can be verified.
diff --git a/website/versioned_docs/version-v0.3.0/condiscon.md b/website/versioned_docs/version-v0.3.0/condiscon.md
deleted file mode 100644
index badac39..0000000
--- a/website/versioned_docs/version-v0.3.0/condiscon.md
+++ /dev/null
@@ -1,195 +0,0 @@
----
-title: "Condiscon" session requests
-id: version-v0.3.0-condiscon
-original_id: condiscon
----
-
-
-
-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.
-- The [`irma` command](irma-cli.md) including [`irma server`](irma-server.md) (`0.3.0` and up supports condiscon).
-- The [IRMA app](https://github.com/privacybydesign/irma_mobile) (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) IRMA app, this looks as follows.
-
-
-
-
-
-```json
-{
- "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"
- ]
- }]
-}
-```
-
-
-"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:
-
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.MijnOverheid.root.BSN" ]
- ],
- [
- [
- "irma-demo.nijmegen.address.street",
- "irma-demo.nijmegen.address.houseNumber",
- "irma-demo.nijmegen.address.city"
- ],
- [
- "irma-demo.idin.idin.address",
- "irma-demo.idin.idin.city"
- ]
- ]
- ]
-}
-```
-
-```golang
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.root.BSN")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.nijmegen.address.street"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.houseNumber"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.city"),
- },
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.idin.idin.address"),
- irma.NewAttributeRequest("irma-demo.idin.idin.city"),
- },
- },
-}
-```
-
-
-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).
-- 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 IRMA app automatically only offers candidate sets as choices to the user that satisfy this property.)
-
-For example, consider the following condiscon session request:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- "pbdf.pbdf.diploma.degree",
- "pbdf.pbdf.diploma.institute"
- ]
- ]
- ]
-}
-```
-
-```golang
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("pbdf.pbdf.diploma.degree"),
- irma.NewAttributeRequest("pbdf.pbdf.diploma.institute"),
- },
- },
-}
-```
-
-
-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.)
-
-When combining multiple credential types within a disjunction these restrictions ensure that when the IRMA app computes candidate attribute sets for the user to choose from, the amount of resulting options stays manageable. In adddition, the second restriction is a new feature on its own, allowing verifiers to request multiple attributes coming from one credential instance.
-
-## Other features
-
-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 IRMA 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:
-
-
- ```json
- {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [],
- [ "pbdf.pbdf.diploma.degree" ]
- ]
- ]
- }
- ```
-
- ```golang
- request := irma.NewDisclosureRequest()
- request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{},
- irma.AttributeCon{irma.NewAttributeRequest("pbdf.pbdf.diploma.degree")},
- },
- }
- ```
-
- 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 IRMA 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).
-
-For full details, see the documentation of the [session request format](session-requests.md).
-
-## Compatibility
-
-The `irma server` of version `0.3.0` and up is:
-- Backwards compatible with the old session request format, i.e. with old IRMA requestor applications. New session request JSON objects are recognized as such by the presence of their `@context` property; if this is absent the request is interpreted as a pre-condiscon IRMA session request.
-- Backwards compatible with old IRMA apps, as long as the condiscon feature is not used in the session (i.e., all inner conjunctions contain exactly 1 attribute).
-- [This `irmago` unit test](https://github.com/privacybydesign/irmago/blob/condiscon/irmago_test.go#L259) shows how pre-condiscon session requests are converted, by asserting equality of pre- and post-condiscon session requests, for all three session types.
-- The documentation of the pre-condiscon session format can be found on the [session requests](/v0.2.0/session-requests).
-
-The new IRMA app is backwards compatible with the old session request format, i.e. with old `irma server`s, *except* in case of signature sessions (see below).
-
-## Signature sessions
-
-For attribute-based signatures, the condiscon version of the IRMA software brings another update that fixes the [following issue](https://github.com/privacybydesign/irmago/issues/35): if the scheme manager adds a new attribute to an existing credential type, then attribute-based signatures using attributes from that credential type that were created before the attribute was added would fail to verify by the IRMA server, due to the signature not incorporating the new attribute. In effect, adding a new attribute to an existing credential type would invalidate all attribute-based signatures previously made that contain attributes from that credential.
-
-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 IRMA 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 IRMA app is released (probably some weeks from now).
-
diff --git a/website/versioned_docs/version-v0.3.0/irma-server.md b/website/versioned_docs/version-v0.3.0/irma-server.md
deleted file mode 100644
index 55341ff..0000000
--- a/website/versioned_docs/version-v0.3.0/irma-server.md
+++ /dev/null
@@ -1,223 +0,0 @@
----
-title: irma server
-id: version-v0.3.0-irma-server
-original_id: irma-server
----
-
-
-`irma server` is an IRMA server executable (daemon) allowing you to perform IRMA sessions with
-[IRMA apps](https://github.com/privacybydesign/irma_mobile). It handles all IRMA-specific cryptographic details of issuing or verifying IRMA attributes with an IRMA app on behalf of a [requestor](overview.md#participants) (the application wishing to verify or issue attributes). It exposes the following:
- * HTTP endpoints under `/irma`, used by the IRMA app during IRMA sessions
- * a JSON API under `/sessions` for requestors, allowing them to request the server to verify or issue attributes.
-
-`irma server` is a subcommand of the [`irma`](irma-cli.md) command line tool, which additionally contains subcommands to start or perform IRMA sessions, handle [IRMA schemes](schemes.md), and more.
-
-For installation instructions, see [`irma`](irma-cli.md).
-
-## Running the server
-
-Simply run `irma server` to run the server with the default configuration in development mode. Use `irma server -v` for more verbose logging, for example to see the current configuration. Use `irma server -vv` to also log session contents.
-
-Run `irma server --help` to see configuration options. In order to verify your configuration, run `irma server check -v`.
-
-## Starting a session
-Assuming the server runs in the [default configuration](#default-configuration) (in particular [requestor authentication](#requestor-authentication) is disabled (`no_auth` is `true`) and the `irma-demo` [scheme](schemes.md) is installed), issue `irma-demo.MijnOverheid.ageLower` attributes using the [`session`](irma-cli.md) subcommand of the `irma` tool:
-```shell
-irma session --server http://localhost:8088 --issue irma-demo.MijnOverheid.ageLower=yes,yes,yes,no
-```
-Verify the `irma-demo.MijnOverheid.ageLower.over18` attribute:
-```shell
-irma session --server http://localhost:8088 --disclose irma-demo.MijnOverheid.ageLower.over18
-```
-These print QRs in your terminal that you can scan with your IRMA app to perform the session. For more extensive examples, see [irmajs](irmajs.md).
-
-## Configuring
-Run `irma server -h` to see all configuration options. Each option may be passed as:
- 1. a command line flags (e.g. [`--listen-addr`](#http-server-endpoints))
- 2. a environmental variable (e.g. `IRMASERVER_LISTEN_ADDR`)
- 3. an item in a configuration file (e.g. `"listen_addr"`) (which may be in JSON, TOML or YAML)
-
- with the following rules:
- * Flags supersede environmental variables which supersede configuration file entries.
- * Dashes are used in flags, but underscores are used in environmental variables and configuration file entries.
- * Environmental variables are uppercased and prefixed with `IRMASERVER_`.
- * The [`requestors`](#requestor-authentication) option is special: when passed as a flag or environmental variable, it must be passed as a JSON object (for example: `--requestors '{"myapp":{"auth_method":"token","key":"12345"}}'`).
- * When passing a boolean flag [use an `=`](https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax), for example [`--no-auth=false`](#requestor-authentication).
-
-In order to see the configuration that the server uses after having gathered input from these sources, specify `-v` or `-vv` or use the `verbose` option. Use `irma server check -v` (with the same flags, env vars and config files as `irma server`) to check your configuration for correctness before running the server.
-
-In the remainder of this document, when referring to options we write them as configuration file entries, with underscores and without prefix.
-
-### Default configuration
-In the default configuration (run `irma server check -v` to see it) the server is immediately usable. In particular, it
-* uses the [default IRMA schemes](schemes.md#default-schemes-pbdf-and-irma-demo) ([`pbdf`](https://github.com/credentials/pbdf-schememanager) and [`irma-demo`](https://github.com/credentials/irma-demo-schememanager)), downloading them if necessary
-* allows anyone to use the server [without authentication](#requestor-authentication) (the `no_auth` setting is `true`).
-
-If the server is reachable from the internet, you should consider enabling authentication of session requests.
-
-### Configuration files
-A configuration file can be provided using the `config` option (for example: `irma server --config ./irmaserver.json`). When not specified, the server looks for a configuration file called `irmaserver.json` or `irmaserver.toml` or `irmaserver.yaml` in (1) the current path; (2) `/etc/irmaserver/`; (3) `$HOME/irmaserver`, in that order. A configuration file is not required; if none is found at any of these locations the server takes its configuration from just command line flags and environmental variables.
-
-### Production mode
-When running the server in production, you should enable the `production` option. This enables stricter defaults on the configuration options for safety and prints warnings on possibly unsafe configurations. In particular, when `production` is enabled, the default values of some options change as follows (cf. `diff <(irma server -h) <(irma server -h --production)`):
-
-* `url` from `"http://$YOUR_LOCAL_IP:port"` to `""`: in development mode the `url` to which IRMA apps will connect is set by default to your current local IP address; in `production` mode you must configure it yourself.
-* [`no_auth`](#requestor-authentication) from `true` to `false`: you should consider enabling requestor authentication, or explicitly disable this by setting this flag to `true`.
-* [`issue_perms`](#global-permissions) from `[*]` (everything) to `[]` (none).
-* [`no_email`](email.md) from `true` to `false`: in `production` mode, opting out of providing an email address can be done by explicitly setting this flag to `true`.
-
-### Keys and certificates
-For each configuration option that refers to some kind of key or certificate (for example `jwt_privkey`), there is a corresponding option with the `_file` suffix (for example `jwt_privkey_file`). Keys can be specified either by setting former to a (PEM) string, or setting the the latter to a file containing the (PEM) string.
-
-### HTTP server endpoints
-The HTTP endpoints that this server offers is split into two parts:
-* `/session`: used by the requestor to start sessions, check session status, or get session results.
-* `/irma`: used by the IRMA app during IRMA sessions.
-
-In the default mode, the server starts one HTTP server that offers both, configured with `listen_addr` and `port`. If however the `client_port` and `client_listen_addr` options are provided, then the server starts two separate HTTP servers:
-* `/session` attaches to the address and port provided with `port` and `listen_addr`.
-* `/irma` attaches to the address and port provided with `client_port` and `client_listen_addr`.
-
-The `/irma` endpoints must always be reachable for the IRMA app. Using this double server mode you can restrict access to the `/session` endpoints by e.g. setting `listen_addr` to `127.0.0.1` or to an interface only reachable from an internal network. Restricting access to the `/session` endpoints in this way may make requestor authentication unnecessary.
-
-### Requestor authentication
-The server runs in one of two modes: it either accepts all session requests from anyone that can reach the server, or it accepts only authenticated session requests from authorized requestors. This can be toggled with the `no_auth` boolean option. If the `/session` creation endpoint of your `irma server` is publicly accessible from the internet (i.e. the `client_port` option is used, see [above](#http-server-endpoints)), then you should consider enabling requestor authentication (i.e. turn `no_auth` off), otherwise anyone can use your `irma server`.
-
-The default is `true` (requests are not authenticated) when `production` is disabled and `false` otherwise.
-
-When authentication is enabled (`no_auth` is `false`), requestors that are authorized to use the server must be configured in the `requestor` option in the form of a map, for example:
-
-```json
-{
- "requestors": {
- "myapp": {
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-
-The server supports several authentication methods, one of which must be specified in the `auth_method` field for each requestor. The snippet above demonstrates the recommended and easiest to use authentication method, called `token`. When using this method the requestor must include the `key` as an API token in a HTTP header (for more details see the [API reference](api-irma-server.md#post-session)).
-
-In addition the server supports the following authentication methods:
-* `hmac`: the requestor symmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/), with HMAC-SHA256 (`HS256`) using `key`. The `key` provided should be the Base64 encoding of the actual secret.
-* `publickey`: the requestor asymmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/) with RSA (`RS256`), in this case `key` should be the PEM public key of the requestor.
-
-For each of these modes it is also possible to specify `key_file` instead `key`; in that case the file at `key_file` will be read and used as `key`.
-
-### Permissions
-For each of the [three IRMA session types](what-is-irma.md#session-types) (attribute verification; attribute-based signature sessions; and attribute issuance), permission to use specific attributes/credentials can be granted to requestors in the configuration. For example, including permissions in the `myapp` requestor from above:
-```json
-{
- "requestors": {
- "myapp": {
- "disclose_perms": [ "irma-demo.MijnOverheid.ageLower.over18" ],
- "sign_perms": [ "irma-demo.MijnOverheid.ageLower.*" ],
- "issue_perms": [ "irma-demo.MijnOverheid.ageLower" ],
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-This means that `myapp` is authorized to request `irma-demo.MijnOverheid.ageLower.over18` in disclosure session, and any attribute from `irma-demo.MijnOverheid.ageLower` in attribute-based signature sessions. Additionally `myapp` can issue `irma-demo.MijnOverheid.ageLower` instances. In each level wildcards are permitted (`irma-demo.MijnOverheid.ageLower.*`, `irma-demo.MijnOverheid.*`, `irma-demo.*`, `*`). Thus `"disclose_perms": [ "*" ]` allows the requestor to verify any attribute.
-
-### Global permissions
-
-Global permissions can be applied to all requestors by using the global `disclose_perms`, `sign_perms` and `issue_perms` options. For each requestor, the effective set of permissions is the union of the permissions specified in its `requestors` map and the global permission set.
-
-The global options also work when `no_auth` is enabled. Thus in this case a session type can be disabled by granting no one the permission, e.g., `issue_perms: []` would disable issuance.
-
-In development mode, when `production` is `false`, the defaults for `disclose_perms`, `sign_perms` and `issue_perms` are `["*"]`. In order to protect any IRMA private keys that the server has access to from unintended use by others, when `production` is true the default of `issue_perms` is `[]`: no one can issue unless the global `issue_perms` is modified or unless specific requestors receive nonempty `issue_perms`.
-
-### Static file hosting
-
-Apart from hosting endpoints under [`/session` and `/irma`](irma-server.md#http-server-endpoints), the server also supports statically hosting all files from a certain directory. This can be useful [for experimenting](getting-started.md#perform-browser-irma-session). It can be configured with the following options:
-
-* `static_path`: Host files under this path as static files. Leave empty to disable static file hosting.
-* `static_prefix`: Host static files under this URL prefix (default: no prefix)
-
-### IRMA schemes
-
-The server uses [IRMA schemes](schemes.md) to retrieve issuer, credential and attribute names, as well as public and private keys with which attributes can be verified an issued, respectively. By default the server uses the [`pbdf` and `irma-demo` schemes](schemes.md#default-schemes-pbdf-and-irma-demo). This can be configured with the following options:
-
-* `schemes_path`: path containing IRMA schemes (often called `irma_configuration`). Default: `C:\Users\Username\AppData\Local\irma\irma_configuration` on Windows, `$HOME/.local/share/irma/irma_configuration` otherwise. Created if it does not exist. If empty, the default schemes [`pbdf` and `irma-demo`](schemes.md#default-schemes-pbdf-and-irma-demo) are downloaded into it.
-* `schemes_assets_path`: path containing initial, read-only IRMA schemes. If specified, the schemes found here are copied into the path specified by `schemes_path`. Can be used to avoid downloading default schemes on first run.
-* `schemes_update`: update IRMA schemes from their scheme URL every this many minutes. Default is `60`. Set to `0` to disable automatic scheme updating (not recommended).
-
-### IRMA issuer private keys
-
-If IRMA issuer private keys are included in the server configuration, then the server can issue all credential types of all issuers for which private keys are installed. IRMA issuer private keys can be configured in the following two ways:
-
-* Include the private keys within the [IRMA scheme](schemes.md) in the issuer's `PrivateKeys` folder, with filenames `0.xml`, `1.xml`, etc ([example](https://github.com/privacybydesign/irma-demo-schememanager/tree/master/MijnOverheid/PrivateKeys)).
-* Set the `privkeys` option to a folder containing IRMA issuer private keys called `scheme.issuer.xml` (for example, `irma-demo.MijnOverheid.xml`).
-
-If issuance is enabled in production and private keys are configured, then you should ensure that only authenticated requestors can start issuance requests (otherwise if anyone can use your server to issue attributes then those attributes cannot be trusted or used). You should either:
-
-* disable `no_auth` and [send authenticated session requests](irma-server.md#requestor-authentication),
-* Restrict the [`/session` HTTP endpoints](#http-server-endpoints) to a internal network interface only accessible by your applications and not from outside.
-
-Taking neither approach is an unsafe configuration as in that case anyone can create issuance sessions. In this case, if `production` mode is enabled then the server will refuse to run.
-
-### Signed JWT session results
-
-If a `jwt_privkey` (or `jwt_privkey_file`) is given, then the following endpoints are enabled:
-
-* `GET /session/{sessiontoken}/result-jwt`: returns the session result signed by the `irma server` into a JWT.
-* `GET /session/{sessiontoken}/getproof`: returns a JWT similar to the one from `result-jwt`, but with the same structure as the IRMA API server session result JWTs.
-* `GET /publickey`: returns the public key with which the JWTs output by this server can be verified.
-
-This can be useful if the session result travels along an unsafe or untrusted route from the IRMA server to the requestor. As long as the `irma server` is trusted and its public key is known, the JWT can be verified to ensure that the session result was untampered with since it left the `irma server`.
-
-### TLS
-
-The IRMA protocol relies on TLS for encryption of the attributes as they travel along the internet. If your server is connected to the internet and it handles actual attributes (personal data from people), then you ***must*** ensure that the attributes are protected in transit with TLS.
-
-You can enable TLS in the `irma server` with the `tls_cert` and `tls_privkey` options (or the `_file` equivalents), specifying a PEM certificate (chain) and PEM private key. If you use [separate requestor and app endpoints](#http-server-endpoints), additionally use `client_tls_cert` and `client_tls_privkey`.
-
-Alternatively, if your IRMA server is connected to the internet through a reverse proxy then your reverse proxy probably handles TLS for you.
-
-### Email
-
-Users of the server are encouraged to provide an email address with the `email` option, subscribing for notifications about changes in the IRMA software or ecosystem. [More information](email.md). In `production` mode, it is required to either provide an email address or to explicitly out with the `no_email` option.
-
-### Logging and verbosity
-
-The server's verbosity can be increased by two degrees:
-* `-v` flag is given, or `verbosity` option set to `1`: includes `DEBUG` messages. Logs server configuration when starting the server, stack traces of errors, and more.
-* `-vv` flag is given, or `verbosity` option set to `2`: includes `TRACE` messages. Additionally includes dumps of all HTTP traffic from and to the server.
-
-> in its default mode, the server will not log attribute values (personal data). If the verbosity is increased, then attribute values may be logged. You should avoid doing this in production.
-
-The output is [structured](https://github.com/sirupsen/logrus#fields), putting certain recurring values in fields:
-```text
-[2019-02-28T20:51:09+01:00] INFO Session started action=disclosing session=WdypvSs97JTotpfl1Dtd
-```
-Outputting JSON is enabled with the `log-json` option:
-```json
-{"action":"disclosing","level":"info","msg":"Session started","session":"WdypvSs97JTotpfl1Dtd","time":"2019-02-28T20:51:09+01:00"}
-```
-
-## Design goals
-
-The server was designed with the following goals in mind.
-- Developer and user friendliness
- - Completely [configurable](#configuring) with configuration file, flags, or environmental vars (see `-h`)
- - Default configuration (demo mode) is immediately useful
- - Thorough and configurable logging (`-v`, `-vv`; by default logs exclude attribute values)
- - Partial backwards compatibility with predecessor [`irma_api_server`](https://github.com/privacybydesign/irma_api_server)
- - Small startup time
-- Also available as [Go library](irma-server-lib.md) instead of standalone server
- - Bindings to other programming languages (Python, Ruby) are expected
-
-Being written in [Go](https://golang.org/) this server (in fact, the containing [`irma` binary](irma-cli.md)) additionally automatically has the following properties.
-- Simple to install (one binary, no dependencies, cross platform) and/or compile
-- [Reproducible builds](https://www.gnu.org/software/mes/manual/html_node/Reproducible-Builds.html)
-- [API documentation](https://godoc.org/github.com/privacybydesign/irmago) (generated automatically from `master` branch)
-
-## See also
-
-* This executable wraps the Go library [`requestorserver`](https://godoc.org/github.com/privacybydesign/irmago/server/requestorserver) which wraps the Go library [`irmaserver`](irma-server-lib.md).
-* The [client](https://godoc.org/github.com/privacybydesign/irmago/irmaclient) corresponding to this server is implemented by the [IRMA mobile app](https://github.com/privacybydesign/irma_mobile).
-* This server is has replaced the deprecated Java [`irma_api_server`](https://github.com/privacybydesign/irma_api_server).
diff --git a/website/versioned_docs/version-v0.3.0/irmajs.md b/website/versioned_docs/version-v0.3.0/irmajs.md
deleted file mode 100644
index 7e2d3d9..0000000
--- a/website/versioned_docs/version-v0.3.0/irmajs.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: irmajs JavaScript library
-id: version-v0.3.0-irmajs
-original_id: irmajs
----
-
-`irmajs` is a Javascript client of the RESTful JSON API offered by the [`irma server`](https://github.com/privacybydesign/irmago/tree/master/irma). It allows you to use the `irma server` to:
-
- * Verify IRMA attributes. You specify which attributes, the library handles the user interaction and the communication with the `irma server` and the [IRMA app](https://github.com/privacybydesign/irma_mobile)).
- * Issue IRMA attributes.
- * Perform IRMA attribute-based signature sessions, resulting in a signature on a string to which IRMA attributes are verifiably attached.
-
-`irmajs` supports all major browsers (Firefox, Chrome, Safari, Edge, Internet Explorer 11).
-
-## Installation
-
-### Compiling from source
-Compile the library:
-
- git clone https://github.com/privacybydesign/irmajs.git
- cd irmajs
- npm install
- npm run build
-
-This writes `irma.js` to the `dist` folder, which you can include in your website in a ``) you can start an IRMA disclosure session as follows:
-
-```js
-const request = {
- '@context': 'https://irma.app/ld/request/disclosure/v2',
- 'disclose': [[[ 'irma-demo.MijnOverheid.ageLower.over18' ]]]
-};
-
-irma.startSession(server, request)
- .then(({ sessionPtr, token }) => irma.handleSession(sessionPtr, {server, token}))
- .then(result => console.log('Done', result));
-```
-
-This assumes you have an [`irma server`](irma-server.md) that is configured to [accept unauthenticated session requests](irma-server.md#requestor-authentication) listening at the URL indicated by `server`.
-
-For complete examples, see the `examples` folder. You can host these examples using the IRMA server, with:
-
- irma server -v --static-path examples/browser
diff --git a/website/versioned_docs/version-v0.3.0/overview.md b/website/versioned_docs/version-v0.3.0/overview.md
deleted file mode 100644
index 899d135..0000000
--- a/website/versioned_docs/version-v0.3.0/overview.md
+++ /dev/null
@@ -1,184 +0,0 @@
----
-title: Technical overview
-id: version-v0.3.0-overview
-original_id: overview
----
-
-This document presents a technical overview of the IRMA project.
-
-## IRMA terminology
-
-### Participants
-
-* *IRMA app*: (mobile) application that receives attributes, and can disclose them. Also called *client* as it acts as the client in the IRMA protocol.
-* *Verifier* or *service provider*: a party wanting to verify someone's attributes (in order to provide some service).
-* *Issuer* or *Identity provider*: a party wanting to issue attributes to someone.
-* *Issuer*: uses an Idemix private key in order to issue credentials to a client, when instructed to by an identity provider
-* *Requestor*: the service or identity provider that wants to, respectively, verify someone's attributes or issue attributes to them.
-* *Scheme manager*: distributes Idemix public keys, credential types and issuer information to clients and requestors; also decides which issuers may join its domain and what credential types they may issue.
-
-### Cryptographic entities
-
-* *Attribute*: a small piece of data, generally containing a statement about the attribute owner (e.g., '> 18 years old').
-* *Credential*: a group of attributes, jointly signed by the issuer using an Idemix private key, in an interactive protocol (called the *issuance protocol*) between the issuer and client.
-* *Credential type*: each IRMA credential is an instance of a credential type, which determines the names of the contained attributes, its validity period, and by which issuer the credential is issued.
- * *Singleton credential type*: users can store at most one instance of such credential types in their IRMA app.
-* *Idemix private-public keypair*: a pair of related keys:
- * *Idemix private key*: used by the issuer to sign a credential in the issuance protocol.
- * *Idemix public key*: used by a verifier when attributes are disclosed to it, in order to establish that the disclosed attributes have been signed using the corresponding Idemix private key.
-* *Disclosure proof*: a set of disclosed attributes, along with a proof of knowledge showing that these disclosed attributes originated from a credential that was validly signed by the issuer.
-* [*Attribute-based signature*](#attribute-based-signatures): a digital signature, with IRMA attributes cryptographically attached to it, on some document or message.
-
-### Core software projects
-
-* [IRMA mobile app](https://github.com/privacybydesign/irma_mobile): (mobile) application that receives attributes, and can disclose them.
-* [`irma` command](irma-cli.md): contains an IRMA attribute verification and issuance server, scheme management, and more.
-* [irmajs](irmajs.md): javascript library acting as glue between an IRMA server and the requestor's website, allowing the requestor to instruct an API server to issue or verify attributes.
-
-## Overview
-
-IRMA is at its core a set of software projects implementing the Idemix attribute-based credential scheme. An *attribute* is a statement or property about a person, such as "I am over 18 years old" or "my name is John Doe".
-
-These attributes are grouped together in a *credential*. In attribute-based credential schemes such as Idemix, such a credential can be issued to a user by a trusted party called the *issuer*. This issuer creates a digital signature over the credential and its containing attributes using its *private key*. The user receives the credential as well as the issuer's signature in her [IRMA mobile app](https://github.com/privacybydesign/irma_mobile).
-
-After that, the user can disclose these attributes to other parties, who are called *verifiers*, selectively showing some and hiding the other attributes from the credential. The verifier then receives the disclosed attributes, as well as a *proof of knowledge* which proves to the verifier that the user
-
-* knows the attributes from the credential which are not being disclosed
-* owns a valid issuer signature over the disclosed attributes and hidden attributes.
-
-The verifier can check the validity of this proof of knowledge using the issuer's *public key* that corresponds with the private key with which the issuer signed the attributes (thus, the verifier must know this public key). The verifier can tell from this that the user has at some point received the disclosed attributes from the trusted issuer. Therefore, it can trust the authenticity of the attributes. (This proof of knowledge does *not* include a full copy of the signature over the attributes, so that even if all attributes of the credential were disclosed simultaneously, the verifier can impossibly use the received attributes and proof of knowledge to disclose these attributes itself to others.)
-
-In addition to attribute disclosure, users can also attach their attributes to messages in an *IRMA attribute-based signature*. This is explained in more detail [below](#attribute-based-signatures).
-
-## Credential types
-
-In IRMA, each credential is an instance of a *credential type*. A credential type specifies (among other things) how many attributes its instances have, what their names are, and by which issuer instances of this credential type are issued. Credential types are not shared between issuers: even if two issuers would issue two credential types with the same name and with the same amount of attributes having the same names, they still are distinct credential types. On [Github](https://github.com/privacybydesign/pbdf-schememanager/blob/master/pbdf/Issues/irmatube/description.xml) an example of such a credential type is available, defining the "IRMATube" credential type which is issued and verified in [this IRMA demo](https://privacybydesign.foundation/demo/irmaTube/). Schematically, an instance of such a credential type would look as follows.
-
-| Attribute name | Attribute value |
-| -------------- | --------------- |
-| **type** | member |
-| **id** | 123456 |
-
-In this table, the right column are the attribute values which are stored and signed in the credential. The left column contains the attribute names from the credential type.
-
-### Singletons
-
-A credential type can be marked as a *singleton* by the scheme manager. If so the IRMA app will store at most one instance of this credential type simultaneously, and receiving a new one would overwrite any older instance. (Example: [`pbdf.nijmegen.bsn`](https://privacybydesign.foundation/attribute-index/en/pbdf.nijmegen.bsn.html)) If a credential type is not a singleton (example: [`pbdf.pbdf.diploma`](https://privacybydesign.foundation/attribute-index/en/pbdf.pbdf.diploma.html)), then the user can have any number of instances of that credential type in her IRMA app.
-
-### Special attributes
-
-#### The metadata attribute
-
-In IRMA, each credential always contains a special attribute called the *metadata attribute*, which must always be disclosed whenever other attributes are disclosed from this credential. This metadata attribute contains:
-
-* which credential type this credential is an instance of (from which it follows by which issuer this credential was issued),
-* the date at which this credential was issued,
-* the expiry date of this credential.
-
-In order to lessen linkability issues (see the [security properties](#irma-security-properties) section below), the issuance and expiry dates are always chosen to fall on the boundary of an *epoch*, which is one week.
-
-#### The secret key attribute
-
-The first attribute of any IRMA credential is always a 256-bit integer which is called the user's *secret key*. The user's IRMA app randomly chooses and stores this integer when it is run for the first time. Whenever it receives a new credential, the app ensures that this number is used as the first attribute, so that all credentials that the app manages share this integer as their first attribute. Contrary to the metadata attribute this attribute is never disclosed; it is even kept hidden from the issuer during issuance. When the user discloses attributes that come from multiple credentials, the proof of knowledge that the IRMA app calculates and sends to the verifier proves multiple facts:
-
-* The app knows a valid issuer signature over each credential from which attributes are currently being disclosed,
-* The first attribute from all of these credentials coincide.
-
-From this the verifier can conclude that the credentials from which attributes are being disclosed belong to one and the same person; that is, it defends against users pooling their credentials.
-
-## Schemes
-
-IRMA schemes are documented on the [Schemes](schemes.md) page.
-
-## Issuers
-
-Each IRMA issuer has an Idemix private key, which it must keep secret as it is used when issuing credentials, and a corresponding public key which is distributed to attribute verifiers and IRMA apps in the IRMA scheme. An issuer may issue multiple credential types (and a scheme may contain many issuers).
-
-Issuers cannot independently create credential types and start issuing them to IRMA app users: the credential type must first be included in an [IRMA scheme](schemes.md) by the scheme manager. In case of the default scheme `pbdf` of the IRMA app, this is the [Privacy by Design Foundation](https://privacybydesign.foundation/issuance/).
-
-When verifying IRMA attributes, out of all possible attributes the verifier could ask for, it must decide which attributes suite its purposes best. In order to be able to make this decision, it is important that for each credential type it is clearly documented how the attributes are obtained, and how it is ensured that they indeed belong to the person that receives them. For each credential type in the `pbdf` scheme, this is documented on the [Privacy by Design Foundation website](https://privacybydesign.foundation/issuance/).
-
-## IRMA PIN codes using the keyshare server
-
-When a user's device containing her IRMA app along with her attributes is lost or stolen, the finder of the phone can potentially abuse the owner's attributes. In order to protect against this, scheme managers may decide to employ an *IRMA keyshare server*. In this case, whenever a credential type that falls under the scheme is used, the user must enter her PIN code before the IRMA session can proceed. The correctness of this PIN code is verified by the keyshare server. When an incorrect PIN code is entered three times in a row, the keyshare server blocks IRMA sessions by refusing to cooperate, for an amount of time that exponentially increases with the amount of consecutive incorrect PIN codes entered. Additionally, users can remotely block their own IRMA app from performing future IRMA sessions on the keyshare server's website, in case their phone is lost or stolen.
-
-The keyshare server's most important function is twofold. It provides a stronger binding of the attributes to their owner, by forcing the correctness of the IRMA PIN code: as long as the user can be trusted to not reveal her PIN code to anyone, the party that receives the attributes can be sure that the person who is disclosing them right now is the same person as the one to which they were issued in the past. Additionally, it provides a way of blocking future IRMA sessions; currently, this feature is only exposed to the users themselves. The price of these advantages is that there is now a single entity that has to cooperate in each IRMA session. This means that whenever the keyshare server is not online, no user can issue or disclose any of the attributes falling under the authority of the relevant scheme. It is thus very important that this component is carefully protected and monitored. Additionally, the keyshare server learns and records a limited amount of data whenever the user performs an IRMA session (how limited this data is is discussed below).
-
-At the Privacy by Design Foundation we believe that the advantages of using a keyshare server far outweigh the disadvantages, so the Foundation's scheme uses a keyshare server. Like all other software, this server is open source.
-
-At a high level keyshare servers work as follows. The user's secret key is split across the user's IRMA app and the keyshare server: both of them hold a part of the secret key. The actual secret key that is effectively used in each credential from this scheme is the sum of these two secret keys. When the user does not enter the correct PIN code the keyshare server will refuse to use its part of the secret key in the IRMA protocol, making it impossible for the session to complete.
-
-In more detail: whenever a scheme is installed in the IRMA app that uses a keyshare server (or when the IRMA app starts for the first time and encounters a hardcoded scheme manager that uses a keyshare server), the user *registers* at the keyshare server, by entering her email address and choosing a PIN code. The IRMA app chooses and stores a random salt of 8 bytes, calculates `SHA256(salt || PIN)`, and sends this along with the user's email address to the keyshare server.
-
-At that moment, the keyshare server chooses and stores a *keyshare* for this user: a 32-bit integer just like the user's secret key. Whenever the users performs an IRMA session using attributes from this scheme, the following happens:
-
-* The IRMA app sends the email address along with `SHA256(salt || PIN)` to the keyshare server. If this hash is not equal to the hash with which the user registered, the keyshare server aborts the session.
-* Assuming the user entered the correct PIN code, the keyshare server generates a proof of knowledge for its part of the user's secret key and sends this to the IRMA app.
-
-What happens next depends on the type of the IRMA session:
-
-* When receiving newly issued attributes, the IRMA app sends the keyshare's proof of knowledge to the issuance server, who first verifies its correctness and authenticity. If correct and authentic, it completes the issuance session in such a way that the actual secret key used in the resulting credential is the sum of both secret keys: that of the user and that of the keyshare server.
-* When disclosing attributes, the IRMA app merges this proof of knowledge with its own proof of knowledge of its own part of the secret key (and the other hidden attributes) in a certain fashion. The result of this is a valid proof of knowledge of the sum of the two secret keys.
-
-Consequentially, it is cryptographically enforced during issuance that the user will need the keyshare server's cooperation whenever she later wants to disclose attributes from the resulting credential. By refusing to cooperate, the keyshare can completely block the user from using her attributes, which is what happens when the user enters an incorrect PIN code too often.
-
-Additionally, the keyshare server comes with a small website on which users can, after logging in with their email address attribute (which they received upon registering at the keyshare server):
-
-* Instruct the keyshare server to block future IRMA sessions, remotely blocking their own IRMA app;
-* Delete their account at the keyshare server (which also blocks future IRMA sessions),
-* View a log of earlier IRMA transactions and PIN code entry attempts.
-
-As the keyshare server's contribution to the proof of knowledge of the secret key is passed to the verifier through the IRMA app instead of directly from the keyshare server to the verifier, the keyshare server does not know to whom attributes are being disclosed. In fact, the only thing it learns is which issuer (and which Idemix public keys) are involved; it does not get to see which attributes are being disclosed nor their values, nor which attributes are kept hidden, nor how many attributes from how many credentials. The transaction log that the user sees in the keyshare server's website is correspondingly bare.
-
-Summarizing, the keyshare server increases the binding between the attributes and the user through the PIN code and through the option of revocation in case of loss or theft, at the cost of a decrease in the decentral nature of IRMA and in some of the privacy guarantees. In order to keep the privacy cost as low as possible, using various cryptographic means we have tried to keep the amount of information that the keyshare server learns about the participants as small as possible. Although we are still looking at ways to make the keyshare server still more privacy-friendly, at the Privacy by Design Foundation we believe that this tradeoff is already worth it. Thus, the `pbdf` scheme indeed uses a keyshare server (towards users we call it ["MyIRMA"](https://privacybydesign.foundation/myirma/)).
-
-Each scheme manager can decide for itself whether or not to use a keyshare server in its scheme. Currently, however, due to a limitation in the IRMA protocol only one keyshare server can be involved simultaneously in IRMA sessions. This will be solved in future new versions of the IRMA app and the IRMA API server.
-
-Full details on the protocol spoken between the IRMA client and an [IRMA keyshare server](https://github.com/privacybydesign/irma_keyshare_server) is documented on the [Keyshare protocol](keyshare-protocol.md) page.
-
-## Attribute-based signatures
-
-Apart from attribute disclosure, IRMA also supports *attribute-based signatures*: a digital signature with IRMA attributes attached to it, on some document or string (more accurately this can generally be any set of bytes, though currently IRMA only support strings). The IRMA app can create such signatures with any of the attributes that it contains. The validity of such a signature can be verified using the Idemix public keys of the issuers of the used attributes, and valid attribute-based signatures can only be created using valid credentials. Contrary to [disclosure proofs](#cryptographic-entities) which are tied to an authentication session, and thus of no more use afterwards, attribute-based signatures are attached to the document that they sign, so their validity is useful as long as the signed document exist. IRMA attribute-based signatures have the same properties as conventional (non-attribute-based) [digital signatures](https://en.wikipedia.org/wiki/Digital_signature) such as non-repudiation, integrity of the signed message, and unforgeability with respect to the issuer private key. In addition, the attributes are cryptographically verifiably attached to the signature and message.
-
-IRMA attribute-based signatures can be used in any case where conventional (digital or conventional "wet") signatures are used and in which it is necessary to know something about the signature creator. For example:
-
-* A doctor could attach his name and "I am a doctor"-attribute to a medical prescription.
-* Teachers could sign student grades with their "I am a teacher"-attribute.
-* If a bank were to issue bank account numbers as an attribute to bank account owners, then a bank account owner could attach her account number attribute to a statement like "I transfer $10 to account 424242", effectively creating a cheque.
-
-Technically, IRMA attribute-based signatures are very similar to disclosure proofs. As mentioned earlier IRMA disclosures use a challenge-response protocol: the verifier generates a random number called the nonce and sends it to the IRMA app, whose response has to take this nonce into account in a precise fashion (this is achieved using the [Fiat-Shamir heuristic](https://en.wikipedia.org/wiki/Fiat%E2%80%93Shamir_heuristic)). More precisely, the disclosure proof is a digital signature on the nonce that was used; if the nonce was freshly generated then the verifier can be sure that the attribute owner is actually present instead of replaying an earlier or eavesdropped disclosure proof. An IRMA attribute-based signature is the same except that not a nonce but an actual message is signed (or rather its SHA256 hash).
-
-Currently IRMA only supports creating attribute-based signatures on strings, although we plan to support other types of documents as well. They can be created using [irmajs](https://github.com/privacybydesign/irmajs) and verified using [IRMA servers](what-is-irma.md#irma-servers) almost the same as disclosure proofs. An online demo is available on the [website of the Foundation](https://privacybydesign.foundation/demo/ondertekenen/).
-
-## IRMA security properties
-
-* **Credential unforgeability:**
- Only the issuer (that is, the holder of the Idemix private key) can issue credentials that will verify under the Idemix public key. Thus when a verifier receives valid attributes, it can safely assume they were issued by the issuer.
-
-* **Multi-show unlinkability:**
- When a verifier performs two IRMA sessions in which the attributes that it receives are identical, then it cannot tell whether the two IRMA sessions were performed with one user who disclosed the same attributes twice, or with two distinct users. In other words, such sessions are not linkable as coming from the same user. (It is important to note that this property holds only at the cryptographic level; using identifying data from the transport layer such as the user's IP or MAC address verifiers can potentially still link sessions.)
-
-* **Grouping credentials using the private key:**
- When attributes are disclosed coming from multiple credentials, the IRMA app additionally proves that the credentials share the same secret key, and thus that the attributes come from the same user.
-
-* **Eavesdroppers cannot perform replay attacks:**
- When verifying attributes, the verifier first sends a number of random bits called the nonce to the IRMA app, and the IRMA app's reply containing the disclosed attributes and the proofs of knowledge has to fit on this nonce in a precise fashion. Assuming that the verifier never reuses nonces, this means that an eavesdropper cannot replay an IRMA disclosure.
-
-* **Verifiers cannot perform replay attacks:**
- Even if all attributes were disclosed (and the secret key is in fact never disclosed), the IRMA app does not send a complete copy of the credential's signature to the verifier; instead parts of it are hidden using proofs of knowledge. This means that verifiers cannot use what they learn in IRMA disclosures to disclose the received attributes to other verifiers, acting as an IRMA app possessing the attributes that were disclosed to it.
-
-* **No impersonation attacks:**
- The credentials and attributes reside in the IRMA app installation of the users. This is contrary to other identity management systems such as for example "Log in with Facebook": when someone presses such a Facebook login button on some website, it is really Facebook who authenticates on that website on behalf of the user. Consequentially, Facebook can potentially authenticate itself as any of its users to such websites. This is not possible in IRMA.
-
-* **No privacy hotspots:**
- When a user discloses IRMA attributes to a verifier, the attributes are sent directly from the user to the verifier without passing through any central party.
-
-It must be mentioned that these properties only hold assuming that our software contains no bugs that break these properties. For this reason all of the IRMA software is open source so that anyone can verify its correctness. We encourage anyone to inspect the IRMA source code, and inform us of any errors that might lessen security or other aspects of the functionality.
-
-## Other resources
-
-* Website of the [Privacy by Design Foundation](http://privacybydesign.foundation/), the creators and maintainers of IRMA
- * An [introduction to IRMA](https://privacybydesign.foundation/irma-start/) for IRMA app users
- * A general and more complete [introduction to IRMA](https://privacybydesign.foundation/irma-explanation/)
- * [Live IRMA demos](https://privacybydesign.foundation/demo-en/)
-* The Android and iOS [IRMA apps](https://privacybydesign.foundation/download-en/)
diff --git a/website/versioned_docs/version-v0.3.0/session-requests.md b/website/versioned_docs/version-v0.3.0/session-requests.md
deleted file mode 100644
index b3c7f8f..0000000
--- a/website/versioned_docs/version-v0.3.0/session-requests.md
+++ /dev/null
@@ -1,418 +0,0 @@
----
-title: Session requests
-id: version-v0.3.0-session-requests
-original_id: session-requests
----
-
-
-
-Each [IRMA server](what-is-irma.md#irma-servers) exposes APIs for creating IRMA sessions with a session request. An *IRMA session request* contains all information required for the IRMA server and [IRMA app](https://github.com/privacybydesign/irma_mobile) to perform an IRMA session with, such as the attributes to be issued or verified. This page documents IRMA session requests. It applies to:
-
-* The [`POST /session`](api-irma-server.md#post-session) endpoint from [`irma server`](irma-server.md).
-* The [`StartSession()` function](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver#StartSession) in the `irmaserver` Go library.
-* The [`startSession()` function](api-irmajs.md#startsession) of `irmajs`.
-
-For the precise role of session requests in an IRMA session, see this [diagram of an IRMA session](what-is-irma.md#irma-session-flow).
-
-## Session request data types
-
-For each of the [three IRMA session types](what-is-irma.md#session-types), we define a *session request* data type: an object whose JSON representation contains at least a [JSON-LD `@context`](https://w3c.github.io/json-ld-syntax/#the-context) key identifying which message type it is, and extra keys specific to the session type. The following three `@context` values identify disclosure, attribute-based signature, and issuance session requests respectively:
-
-* `"@context": "https://irma.app/ld/request/disclosure/v2"`
-* `"@context": "https://irma.app/ld/request/signature/v2"`
-* `"@context": "https://irma.app/ld/request/issuance/v2"`
-
-(For now these URIs do not resolve to anything; they just distinguish the message type.)
-
-## Disclosure requests
-Disclosure sessions are started with an [`irma.DisclosureRequest`](https://godoc.org/github.com/privacybydesign/irmago#DisclosureRequest). Example:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.MijnOverheid.root.BSN" ]
- ],
- [
- [
- "irma-demo.nijmegen.address.street",
- "irma-demo.nijmegen.address.houseNumber",
- "irma-demo.nijmegen.address.city"
- ],
- [
- "irma-demo.idin.idin.address",
- "irma-demo.idin.idin.city"
- ]
- ]
- ]
-}
-```
-
-```golang
-// Create a new empty request
-request := irma.NewDisclosureRequest()
-
-// Request specific attributes
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.root.BSN")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.nijmegen.address.street"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.houseNumber"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.city"),
- },
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.idin.idin.address"),
- irma.NewAttributeRequest("irma-demo.idin.idin.city"),
- },
- },
-}
-```
-
-
-
-
-This asks for a (demo) `BSN` attribute, as well as either `street`, `houseNumber` and `city` from `irma-demo.nijmegen.address`, or `address` and `city` from `irma-demo.idin.idin`. The three levels correspond to a *conjunction* of *disjunctions* of *conjunctions* of requested attributes, allowing verifiers to request multiple attribute sets from the user, offering choices for some or all of these sets.
-
-All of the attribute types (i.e., the string values) contained in the request must exist in their scheme ([`irma-demo`](https://github.com/privacybydesign/irma-demo-schememanager) in the example above). For the `irma-demo` and `pbdf` schemes, an index of existing attribute types that can be requested can be found [here](https://privacybydesign.foundation/attribute-index/en/).
-
-> Attributes can be disclosed to the requestor in any of the three session types: in issuance sessions issuance proceeds only if the user discloses the required attributes just before issuance, and in attribute-based signature sessions the requested attributes are attached to the resulting attribute-based signature. Thus the `disclose` and `labels` fields introduced above can also occur in issuance or attribute-based signature session requests (see below).
-
-### Multiple credential types within inner conjunctions
-In the request above 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).
-- 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 IRMA app automatically only offers candidate sets as choices to the user that satisfy this property.)
-
-For example, consider the following session request:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- "pbdf.pbdf.diploma.degree",
- "pbdf.pbdf.diploma.institute"
- ]
- ]
- ]
-}
-```
-
-```golang
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("pbdf.pbdf.diploma.degree"),
- irma.NewAttributeRequest("pbdf.pbdf.diploma.institute"),
- },
- },
-}
-```
-
-
-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.)
-
-When combining multiple credential types within a disjunction these restrictions ensure that when the IRMA app computes candidate attribute sets for the user to choose from, the amount of resulting options stays manageable. In adddition, the second restriction is a feature on its own, allowing verifiers to request multiple attributes coming from one credential instance.
-
-### Requesting specific attribute values
-Within inner conjunctions, specific attribute values can be requested by replacing the string with an object like the following:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "pbdf.pbdf.diploma.degree", "value": "PhD" },
- { "type": "pbdf.pbdf.diploma.institute", "value": null }
- ]
- ]
- ]
-}
-```
-
-```go
-phd := "PhD"
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.degree"),
- Value: &phd,
- }, {
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.institute"),
- Value: nil,
- }},
- },
-}
-```
-
-
-This would only be satisfied by a `degree` attribute whose value is `PhD`, together with any `institute` attribute. (Note that the object and string syntaxes can be mixed within an inner conjunction, i.e. it would be permissible in the JSON example above to replace the second object with just `"pbdf.pbdf.diploma.institute"`.)
-
-### Null attributes
-
-Whenever an attribute is marked with `optional` in the scheme ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)), the issuer may skip it when it issues an instance of the containing credential type, assigning a `null` value to it (which is distinct from the empty string `""`). When disclosing the attribute, the verifier receives `null` instead of a string containing the attribute value.
-
-If a non-null attribute is required this can be requested using `notNull` as follows:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "irma-demo.MijnOverheid.fullName.prefix", "notNull": true }
- ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("irma-demo.MijnOverheid.fullName.prefix"),
- NotNull: true,
- }},
- },
-}
-```
-
-
-The default value of `notNull` is `false`.
-
-### Optional disjunctions
-
-A disjunction within a session request can be marked as *optional*, by including an empty inner conjunction in it:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.nijmegen.address.city" ]
- ],
- [
- [],
- [ "irma-demo.MijnOverheid.fullName.firstname" ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.nijmegen.address.city")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{},
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.fullName.firstname")},
- },
-}
-```
-
-
-
-
-This can be useful when certain attributes are not required, so that if the user does not have them the session does not need to be aborted.
-
-### Disjunction labels
-
-Per disjunction a *label* can be specified, which is shown in the IRMA app when the user is asked for permission to disclose attributes. For example, the session request from [above](#disclosure-requests) could be augmented with a label for the second disjunction as follows:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [ ... ],
- [ ... ]
- ],
- "labels": {
- "1": { "en": "Work address", "nl": "Werk adres" }
- }
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Labels = map[int]irma.TranslatedString{
- 1: {"en": "Work address", "nl": "Werk adres"},
-}
-```
-
-
-
-
-In this way each disjunction can be given a optional label explaining to the user the purpose of the disjunction. It is recommended to only provide a label to explain something to the user that would otherwise not be obvious; for example, to request the user to send a work email address instead of a personal one. Repeating the credential or attribute name or description in labels is an antipattern.
-
-## Attribute-based signature requests
-Attribute-based signature sessions are started with an [`irma.SignatureRequest`](https://godoc.org/github.com/privacybydesign/irmago#SignatureRequest), which are similar to disclosure requests:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/signature/v2",
- "message": "Message to be signed by user",
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-request := irma.NewSignatureRequest("Message to be signed by user")
-request.Disclose = irma.AttributeConDisCon{ /* request attributes to attach to ABS */ }
-request.Labels = map[int]irma.TranslatedString{}
-```
-
-
-The `message` field is required. The attributes to be attached to the attribute-based signature are requested with the `disclose` field, which along with the `labels` field work exactly like in disclosure sessions.
-
-## Issuance requests
-Issuance sessions are started with an [`irma.IssuanceRequest`](https://godoc.org/github.com/privacybydesign/irmago#IssuanceRequest). Example:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/issuance/v2",
- "credentials": [{
- "credential": "irma-demo.MijnOverheid.ageLower",
- "validity": 1592438400,
- "attributes": {
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no"
- }
- }],
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-validity := irma.Timestamp(time.Unix(1592438400, 0))
-request := irma.NewIssuanceRequest([]*irma.CredentialRequest{
- {
- CredentialTypeID: irma.NewCredentialTypeIdentifier("irma-demo.MijnOverheid.ageLower"),
- Validity: &validity, // optional
- Attributes: map[string]string{
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no",
- },
- },
-})
-request.Disclose = irma.AttributeConDisCon{} // optional
-request.Labels = map[int]irma.TranslatedString{} // optional
-```
-
-
-Per credential in the `credentials` array the `validity` is optional; if skipped it is assigned the default value of 6 months. If present, the validity is always rounded down to the [nearest epoch boundary](overview.md#special-attributes), which is one week (60 * 60 * 24 * 7 = 604800 seconds).
-
-Attributes marked as `optional` in the containing credential type ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)) may be skipped in the `attributes` map. This issues [the `null` value](#null-attributes) to these attributes.
-
-`disclose` and `labels` are optional, allowing for *combined disclosure-issuance sessions*, in which the user is required to disclose attributes before the IRMA server will issue the credentials.
-
-## Extra parameters
-For each API that accepts one of the above session request data types, the requestor can provide additional parameters to configure the session at the IRMA server, by providing an *extended session request* instead, as follows:
-
-
-```json
-{
- "validity": 120,
- "timeout": 120,
- "callbackUrl": "https://example.com",
- "request": ...
-}
-```
-
-```go
-// See also corresponding types irma.SignatureRequestorRequest
-// and irma.IdentityProviderRequest
-irma.ServiceProviderRequest{
- irma.RequestorBaseRequest{
- ResultJwtValidity: 120,
- ClientTimeout: 120,
- CallbackUrl: "https://example.com",
- },
- irma.NewDisclosureRequest(),
-}
-```
-
-
-## JWTs: signed session requests
-The IRMA API server or [`irma server`](irma-server.md) can be configured such that it only accepts session requests that have been digitally signed in the form of a [JWT](https://jwt.io). The form of the JWT depends on the [session type](what-is-irma.md#session-types). An example requesting [IRMATube](https://privacybydesign.foundation/demo/irmaTube) attributes:
-```
-eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImlybWF0dWJlIn0.eyJpYXQiOjE1NjQ2NTczNzUsInN1YiI6InZlcmlmaWNhdGlvbl9yZXF1ZXN0Iiwic3ByZXF1ZXN0Ijp7InJlcXVlc3QiOnsiQGNvbnRleHQiOiJodHRwczovL2lybWEuYXBwL2xkL3JlcXVlc3QvZGlzY2xvc3VyZS92MiIsImRpc2Nsb3NlIjpbW1sicGJkZi5wYmRmLmlybWF0dWJlLnR5cGUiXV0sW1sicGJkZi5wYmRmLmFnZUxpbWl0cy5vdmVyMTIiXSxbInBiZGYuZ2VtZWVudGUucGVyc29uYWxEYXRhLm92ZXIxMiJdXV19fX0.lW9mqjrLkoahDP6Fcw_9mH5hlfl1tq5qp3W3ga0Nrd_j0NXFj-6ngqHVXEV1zhC_OkVH4LN8fMBAgN8nqaFWgEdQvrCuB7-ynuBVjLR-QU272Ym86zLEWYggAkbZ5KY40MpTxU1dgFMucG7fyAESic04OribWOCVxstAMsM28yCxvzkBMCOSjFEe3abcg_N6VvQnLn3LgZP_UrxQmQsh4DK7mBjW04LesLG1vjcliyhDGUb52FHOP_NAsG7G2FvIgojPzALlPrpTMu5p8a95wc5CGR791wybmh0F8kDdwZWAU0W2FjlX5bNPsyXN8AxRVWaRmWoGrGsQhy_sKEf8lg
-```
-In case of disclosure sessions, the body of the JWT (the part in between the two dots) contains a Base64-encoding of the following:
-
-
-```json
-{
- "iat": 1550424847,
- "sub": "verification_request",
- "sprequest": ...
-}
-```
-
-```go
-// Sets iat, iss, and sub fields.
-// See also corresponding functions irma.NewSignatureRequestorJwt()
-// and irma.NewIdentityProviderJwt().
-// Obtain signed JWT string to POST to an irma server using Sign() method.
-irma.NewServiceProviderJwt("IRMATube", irma.NewDisclosureRequest())
-```
-
-
-The fields are as follows:
-* `iat`: Unix timestamp of the creation date of the JWT. IRMA servers may reject JWTs beyond a certain age.
-* `iss`: contains the requestor name, and is used by the IRMA server to lookup the appropriate key with which to verify the JWT.
-* `sub`: JWT subject, in case of disclosure sessions this must always be `"verification_request"`.
-* `sprequest`: contains an extended disclosure session request as defined above.
-
-For each possible session type, the contents of the `sub` field and the name of the field containing the session request must be as follows.
-
-| Session type | `sub` contents | Session request field name | Go function |
-| ------------ | -------------- | -------------------------- | ----------- |
-| Disclosure | `verification_request` | `sprequest` | `irma.NewServiceProviderJwt()` |
-| Attribute-based signature | `signature_request` | `absrequest` | `irma.NewSignatureRequestorJwt()` |
-| Issuance | `issue_request` | `iprequest` | `irma.NewIdentityProviderJwt()` |
-
-Currently the following libraries can produce JWTs of this form:
-* The [`irmago`](https://godoc.org/github.com/privacybydesign/irmago) library, using the mentioned functions
-* The [`irmajs`](irmajs.md) Javascript library
-* The [`irma-requestor`](https://github.com/privacybydesign/irma-requestor) PHP library
-* The [`irma_api_common`](https://github.com/privacybydesign/irma_api_common) Java library
-* The [`irma-diva-js`](https://github.com/Alliander/diva-irma-js) Javascript library
-
-`irma server` currently supports JWTs signed (asymmetrically with RSA) with the `RS256` algorithm, and (symmetrically signed with HMAC-SHA256) `RS256`. The IRMA API server only supports `RS256`.
diff --git a/website/versioned_docs/version-v0.3.1/session-requests.md b/website/versioned_docs/version-v0.3.1/session-requests.md
deleted file mode 100644
index 2fba613..0000000
--- a/website/versioned_docs/version-v0.3.1/session-requests.md
+++ /dev/null
@@ -1,418 +0,0 @@
----
-title: Session requests
-id: version-v0.3.1-session-requests
-original_id: session-requests
----
-
-
-
-Each [IRMA server](what-is-irma.md#irma-servers) exposes APIs for creating IRMA sessions with a session request. An *IRMA session request* contains all information required for the IRMA server and [IRMA app](https://github.com/privacybydesign/irma_mobile) to perform an IRMA session with, such as the attributes to be issued or verified. This page documents IRMA session requests. It applies to:
-
-* The [`POST /session`](api-irma-server.md#post-session) endpoint from [`irma server`](irma-server.md).
-* The [`StartSession()` function](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver#StartSession) in the `irmaserver` Go library.
-* The [`startSession()` function](api-irmajs.md#startsession) of `irmajs`.
-
-For the precise role of session requests in an IRMA session, see this [diagram of an IRMA session](what-is-irma.md#irma-session-flow).
-
-## Session request data types
-
-For each of the [three IRMA session types](what-is-irma.md#session-types), we define a *session request* data type: an object whose JSON representation contains at least a [JSON-LD `@context`](https://w3c.github.io/json-ld-syntax/#the-context) key identifying which message type it is, and extra keys specific to the session type. The following three `@context` values identify disclosure, attribute-based signature, and issuance session requests respectively:
-
-* `"@context": "https://irma.app/ld/request/disclosure/v2"`
-* `"@context": "https://irma.app/ld/request/signature/v2"`
-* `"@context": "https://irma.app/ld/request/issuance/v2"`
-
-(For now these URIs do not resolve to anything; they just distinguish the message type.)
-
-## Disclosure requests
-Disclosure sessions are started with an [`irma.DisclosureRequest`](https://godoc.org/github.com/privacybydesign/irmago#DisclosureRequest). Example:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.MijnOverheid.root.BSN" ]
- ],
- [
- [
- "irma-demo.nijmegen.address.street",
- "irma-demo.nijmegen.address.houseNumber",
- "irma-demo.nijmegen.address.city"
- ],
- [
- "irma-demo.idin.idin.address",
- "irma-demo.idin.idin.city"
- ]
- ]
- ]
-}
-```
-
-```golang
-// Create a new empty request
-request := irma.NewDisclosureRequest()
-
-// Request specific attributes
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.root.BSN")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.nijmegen.address.street"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.houseNumber"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.city"),
- },
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.idin.idin.address"),
- irma.NewAttributeRequest("irma-demo.idin.idin.city"),
- },
- },
-}
-```
-
-
-
-
-This asks for a (demo) `BSN` attribute, as well as either `street`, `houseNumber` and `city` from `irma-demo.nijmegen.address`, or `address` and `city` from `irma-demo.idin.idin`. The three levels correspond to a *conjunction* of *disjunctions* of *conjunctions* of requested attributes, allowing verifiers to request multiple attribute sets from the user, offering choices for some or all of these sets.
-
-All of the attribute types (i.e., the string values) contained in the request must exist in their scheme ([`irma-demo`](https://github.com/privacybydesign/irma-demo-schememanager) in the example above). For the `irma-demo` and `pbdf` schemes, an index of existing attribute types that can be requested can be found [here](https://privacybydesign.foundation/attribute-index/en/).
-
-> Attributes can be disclosed to the requestor in any of the three session types: in issuance sessions issuance proceeds only if the user discloses the required attributes just before issuance, and in attribute-based signature sessions the requested attributes are attached to the resulting attribute-based signature. Thus the `disclose` and `labels` fields introduced above can also occur in issuance or attribute-based signature session requests (see below).
-
-### Multiple credential types within inner conjunctions
-In the request above 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).
-- 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 IRMA app automatically only offers candidate sets as choices to the user that satisfy this property.)
-
-For example, consider the following session request:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- "pbdf.pbdf.diploma.degree",
- "pbdf.pbdf.diploma.institute"
- ]
- ]
- ]
-}
-```
-
-```golang
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("pbdf.pbdf.diploma.degree"),
- irma.NewAttributeRequest("pbdf.pbdf.diploma.institute"),
- },
- },
-}
-```
-
-
-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.)
-
-When combining multiple credential types within a disjunction these restrictions ensure that when the IRMA app computes candidate attribute sets for the user to choose from, the amount of resulting options stays manageable. In adddition, the second restriction is a feature on its own, allowing verifiers to request multiple attributes coming from one credential instance.
-
-### Requesting specific attribute values
-Within inner conjunctions, specific attribute values can be requested by replacing the string with an object like the following:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "pbdf.pbdf.diploma.degree", "value": "PhD" },
- { "type": "pbdf.pbdf.diploma.institute", "value": null }
- ]
- ]
- ]
-}
-```
-
-```go
-phd := "PhD"
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.degree"),
- Value: &phd,
- }, {
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.institute"),
- Value: nil,
- }},
- },
-}
-```
-
-
-This would only be satisfied by a `degree` attribute whose value is `PhD`, together with any `institute` attribute. (Note that the object and string syntaxes can be mixed within an inner conjunction, i.e. it would be permissible in the JSON example above to replace the second object with just `"pbdf.pbdf.diploma.institute"`.)
-
-### Null attributes
-
-Whenever an attribute is marked with `optional` in the scheme ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)), the issuer may skip it when it issues an instance of the containing credential type, assigning a `null` value to it (which is distinct from the empty string `""`). When disclosing the attribute, the verifier receives `null` instead of a string containing the attribute value.
-
-If a non-null attribute is required this can be requested using `notNull` as follows:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "irma-demo.MijnOverheid.fullName.prefix", "notNull": true }
- ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("irma-demo.MijnOverheid.fullName.prefix"),
- NotNull: true,
- }},
- },
-}
-```
-
-
-The default value of `notNull` is `false`.
-
-### Optional disjunctions
-
-A disjunction within a session request can be marked as *optional*, by including an empty inner conjunction in it:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.nijmegen.address.city" ]
- ],
- [
- [],
- [ "irma-demo.MijnOverheid.fullName.firstname" ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.nijmegen.address.city")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{},
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.fullName.firstname")},
- },
-}
-```
-
-
-
-
-This can be useful when certain attributes are not required, so that if the user does not have them the session does not need to be aborted.
-
-### Disjunction labels
-
-Per disjunction a *label* can be specified, which is shown in the IRMA app when the user is asked for permission to disclose attributes. For example, the session request from [above](#disclosure-requests) could be augmented with a label for the second disjunction as follows:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [ ... ],
- [ ... ]
- ],
- "labels": {
- "1": { "en": "Work address", "nl": "Werk adres" }
- }
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Labels = map[int]irma.TranslatedString{
- 1: {"en": "Work address", "nl": "Werk adres"},
-}
-```
-
-
-
-
-In this way each disjunction can be given a optional label explaining to the user the purpose of the disjunction. It is recommended to only provide a label to explain something to the user that would otherwise not be obvious; for example, to request the user to send a work email address instead of a personal one. Repeating the credential or attribute name or description in labels is an antipattern.
-
-## Attribute-based signature requests
-Attribute-based signature sessions are started with an [`irma.SignatureRequest`](https://godoc.org/github.com/privacybydesign/irmago#SignatureRequest), which are similar to disclosure requests:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/signature/v2",
- "message": "Message to be signed by user",
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-request := irma.NewSignatureRequest("Message to be signed by user")
-request.Disclose = irma.AttributeConDisCon{ /* request attributes to attach to ABS */ }
-request.Labels = map[int]irma.TranslatedString{}
-```
-
-
-The `message` field is required. The attributes to be attached to the attribute-based signature are requested with the `disclose` field, which along with the `labels` field work exactly like in disclosure sessions.
-
-## Issuance requests
-Issuance sessions are started with an [`irma.IssuanceRequest`](https://godoc.org/github.com/privacybydesign/irmago#IssuanceRequest). Example:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/issuance/v2",
- "credentials": [{
- "credential": "irma-demo.MijnOverheid.ageLower",
- "validity": 1592438400,
- "attributes": {
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no"
- }
- }],
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-validity := irma.Timestamp(time.Unix(1592438400, 0))
-request := irma.NewIssuanceRequest([]*irma.CredentialRequest{
- {
- CredentialTypeID: irma.NewCredentialTypeIdentifier("irma-demo.MijnOverheid.ageLower"),
- Validity: &validity, // optional
- Attributes: map[string]string{
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no",
- },
- },
-})
-request.Disclose = irma.AttributeConDisCon{} // optional
-request.Labels = map[int]irma.TranslatedString{} // optional
-```
-
-
-Per credential in the `credentials` array the `validity` is optional; if skipped it is assigned the default value of 6 months. If present, the validity is always rounded down to the [nearest epoch boundary](overview.md#special-attributes), which is one week (60 * 60 * 24 * 7 = 604800 seconds).
-
-Attributes marked as `optional` in the containing credential type ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)) may be skipped in the `attributes` map. This issues [the `null` value](#null-attributes) to these attributes.
-
-`disclose` and `labels` are optional, allowing for *combined disclosure-issuance sessions*, in which the user is required to disclose attributes before the IRMA server will issue the credentials.
-
-## Extra parameters
-For each API that accepts one of the above session request data types, the requestor can provide additional parameters to configure the session at the IRMA server, by providing an *extended session request* instead, as follows:
-
-
-```json
-{
- "validity": 120,
- "timeout": 120,
- "callbackUrl": "https://example.com",
- "request": ...
-}
-```
-
-```go
-// See also corresponding types irma.SignatureRequestorRequest
-// and irma.IdentityProviderRequest
-irma.ServiceProviderRequest{
- irma.RequestorBaseRequest{
- ResultJwtValidity: 120,
- ClientTimeout: 120,
- CallbackUrl: "https://example.com",
- },
- irma.NewDisclosureRequest(),
-}
-```
-
-
-## JWTs: signed session requests
-The IRMA API server or [`irma server`](irma-server.md) can be configured such that it only accepts session requests that have been digitally signed in the form of a [JWT](https://jwt.io). The form of the JWT depends on the [session type](what-is-irma.md#session-types). An example requesting [IRMATube](https://privacybydesign.foundation/demo/irmaTube) attributes::
-```
-eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImlybWF0dWJlIn0.eyJpYXQiOjE1NjQ2NTczNzUsInN1YiI6InZlcmlmaWNhdGlvbl9yZXF1ZXN0Iiwic3ByZXF1ZXN0Ijp7InJlcXVlc3QiOnsiQGNvbnRleHQiOiJodHRwczovL2lybWEuYXBwL2xkL3JlcXVlc3QvZGlzY2xvc3VyZS92MiIsImRpc2Nsb3NlIjpbW1sicGJkZi5wYmRmLmlybWF0dWJlLnR5cGUiXV0sW1sicGJkZi5wYmRmLmFnZUxpbWl0cy5vdmVyMTIiXSxbInBiZGYuZ2VtZWVudGUucGVyc29uYWxEYXRhLm92ZXIxMiJdXV19fX0.lW9mqjrLkoahDP6Fcw_9mH5hlfl1tq5qp3W3ga0Nrd_j0NXFj-6ngqHVXEV1zhC_OkVH4LN8fMBAgN8nqaFWgEdQvrCuB7-ynuBVjLR-QU272Ym86zLEWYggAkbZ5KY40MpTxU1dgFMucG7fyAESic04OribWOCVxstAMsM28yCxvzkBMCOSjFEe3abcg_N6VvQnLn3LgZP_UrxQmQsh4DK7mBjW04LesLG1vjcliyhDGUb52FHOP_NAsG7G2FvIgojPzALlPrpTMu5p8a95wc5CGR791wybmh0F8kDdwZWAU0W2FjlX5bNPsyXN8AxRVWaRmWoGrGsQhy_sKEf8lg
-```
-In case of disclosure sessions, the body of the JWT (the part in between the two dots) contains a Base64-encoding of the following:
-
-
-```json
-{
- "iat": 1550424847,
- "sub": "verification_request",
- "sprequest": ...
-}
-```
-
-```go
-// Sets iat, iss, and sub fields.
-// See also corresponding functions irma.NewSignatureRequestorJwt()
-// and irma.NewIdentityProviderJwt().
-// Obtain signed JWT string to POST to an irma server using Sign() method.
-irma.NewServiceProviderJwt("IRMATube", irma.NewDisclosureRequest())
-```
-
-
-The fields are as follows:
-* `iat`: Unix timestamp of the creation date of the JWT. IRMA servers may reject JWTs beyond a certain age.
-* `iss`: contains the requestor name, and is used by the IRMA server to lookup the appropriate key with which to verify the JWT.
-* `sub`: JWT subject, in case of disclosure sessions this must always be `"verification_request"`.
-* `sprequest`: contains an extended disclosure session request as defined above.
-
-For each possible session type, the contents of the `sub` field and the name of the field containing the session request must be as follows.
-
-| Session type | `sub` contents | Session request field name | Go function |
-| ------------ | -------------- | -------------------------- | ----------- |
-| Disclosure | `verification_request` | `sprequest` | `irma.NewServiceProviderJwt()` |
-| Attribute-based signature | `signature_request` | `absrequest` | `irma.NewSignatureRequestorJwt()` |
-| Issuance | `issue_request` | `iprequest` | `irma.NewIdentityProviderJwt()` |
-
-Currently the following libraries can produce JWTs of this form:
-* The [`irmago`](https://godoc.org/github.com/privacybydesign/irmago) library, using the mentioned functions
-* The [`irmajs`](irmajs.md) Javascript library
-* The [`irma-requestor`](https://github.com/privacybydesign/irma-requestor) PHP library
-* The [`irma_api_common`](https://github.com/privacybydesign/irma_api_common) Java library
-* The [`irma-diva-js`](https://github.com/Alliander/diva-irma-js) Javascript library
-
-`irma server` currently supports JWTs signed (asymmetrically with RSA) with the `RS256` algorithm, and (symmetrically signed with HMAC-SHA256) `RS256`. The IRMA API server only supports `RS256`.
diff --git a/website/versioned_docs/version-v0.4.1/api-irma-frontend.md b/website/versioned_docs/version-v0.4.1/api-irma-frontend.md
deleted file mode 100644
index da61591..0000000
--- a/website/versioned_docs/version-v0.4.1/api-irma-frontend.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: IRMA frontend packages
-id: version-v0.4.1-api-irma-frontend
-original_id: api-irma-frontend
----
-
-The IRMA frontend packages consist of multiple packages. Therefore we describe the API per package.
-The API description of the IRMA frontend plugins is combined into one section.
-
-## IRMA core
-The [IRMA core](irma-frontend.md#irma-core) package only exports the `IrmaCore` class. To handle an IRMA session,
-an instance of this class can be made with the relevant options for your session. The options object is shared
-between all plugins that are registered at the `IrmaCore` instance. The plugins don't need to be configured
-individually. The options that can be specified depend on the specific plugins you are using. You can find all
-possible options in the READMEs of the plugins. You can find an overview of all available IRMA core plugins
-[here](#plugins).
-
-The IRMA core class has one constructor:
-```javascript
-const IrmaCore = require('@privacybydesign/irma-core');
-const irma = new IrmaCore({/* Options */});
-```
-
-Below you can find an overview of all methods an IRMA core instance offers you.
-
-| Method | Functionality |
-|---|---|
-| `use(/* Plugin*/)` | With this method plugins can be added to the IRMA core instance. This method takes care of instantiating the plugin. You simply pass the plugin class as an argument to this function; you must not instantiate the plugin yourself.
-| `start()` | The start method activates the state machine. From then the IRMA core instance is ready to be used and no plugins can be added to the instance anymore. It returns a promise that resolves when a session is finished successfully and rejects when a unrecoverable error occurs. By calling IRMA core's `start` method, the plugins will be started too.
-
-For an example of how the IRMA core API can be used, you can also check the [usage guide](irma-frontend.md#usage-guide).
-
-## IRMA frontend
-[IRMA frontend](irma-frontend.md#irma-frontend) does not export any explicit class or function. It is a wrapper
-package around IRMA core combined with several of its plugins and the default [`irma-css`](irma-frontend.md#irma-css)
-styling. The package can only be used in web browser environments and it adds an `IrmaCore` instance
-directly to the JavaScript DOM, named `irma`.
-
-This `irma` instance has two methods:
-
-| Method | Functionality |
-|---|---|
-| `new({/* Options*/})` | With this method an `IrmaCore` instance is initialized (using its constructor) using the given options. The options that can be used are all options from [`irma-client`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client) and [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web).
-| `start()` | Calls the `start` method of `IrmaCore` internally and behaves exactly like this method.
-
-## Plugins
-The [plugins](irma-frontend.md#available-plugins-for-irma-core) do not export any class or method. They only add extra
-possible options to IRMA core. An overview of the options that can be used per plugin can be found in the READMEs.
-
-| Plugin |
-|---|
-| [`irma-client`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client) |
-| [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web) |
-| [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-popup) |
-| [`irma-console`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-console) |
-| [`irma-dummy`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-dummy) |
-
-## IRMA legacy
-This package uses the exact API from [irmajs](api-irmajs.md). However, due to technical changes in IRMA,
-we were not able to realize full backwards compatibility with `irmajs`.
-All changes are related to the function call `handleSession`.
-* Method `canvas` is not supported anymore. Please use the module `irma-frontend` instead or make
- your own composition of plugins and layouts using `irma-core`.
- This also means the canvas related options `element` and `showConnectedIcon` are deprecated.
-* Method `mobile` has the same behaviour as method `popup` now. On mobile devices, the popup
- mode automatically detects whether a mobile device is used and then shows the user the option to open
- the IRMA app installed on the mobile device itself. It is now an explicit choice, so users can also get
- a QR on mobile devices instead (useful for tablets).
-* The option `disableMobile` is not useful anymore. This module does not have
- automatic redirects to other apps anymore without explicit user interaction.
- The option is therefore deprecated.
-* The option `returnStatus` is deprecated. Instead you can use the functions `waitConnected` and `waitDone`
- to detect yourself whether the session reached a certain status.
diff --git a/website/versioned_docs/version-v0.4.1/irma-backend.md b/website/versioned_docs/version-v0.4.1/irma-backend.md
deleted file mode 100644
index f60c40e..0000000
--- a/website/versioned_docs/version-v0.4.1/irma-backend.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: IRMA backend packages
-id: version-v0.4.1-irma-backend
-original_id: irma-backend
----
-
-[`irma-backend-packages`](https://github.com/privacybydesign/irma-backend-packages/)
-is a collection of libraries in multiple programming languages assuming the role
-of the [IRMA server](what-is-irma.md#irma-servers) in the IRMA protocol, allowing you to integrate IRMA in the backend
-of your application. In particular, these libraries allow you to do the following:
-
- * Starting IRMA sessions using a session request or a JWT at the IRMA server
- * Retrieving the current status of IRMA sessions (only once or by receiving events on status updates)
- * Retrieving session result or session result JWT when a session succeeded
- * Cancelling IRMA sessions
- * Retrieving the JWT public key of the IRMA server
- * Generating a JWT of a session request
- * Verifying a JWT of a session request or a session result
-
-Additionally, they will handle all communication with the IRMA app.
-
-Depending on the programming language, the libraries achieve this by either directly including
-the IRMA server functionality, or by consuming the [REST API](api-irma-server.md) exposed
-by the [`irma server`](irma-server.md).
-
-The library will slightly differ per language, since each programming language has its own conventions.
-
-## Available languages
-For the list of currently available programming languages, check the [GitHub README](https://github.com/privacybydesign/irma-backend-packages/). (Note that for the Go programming language, there is
-a separate [`irmaserver`](irma-server-lib.md) Go package.)
-
-If the programming language of your choice is not available yet, you can
-always directly invoke the `irma server` [REST API](api-irma-server.md).
-If you think the programming language of your choice would benefit being part of
-`irma-backend-packages`, you can always contact us or make an issue on [GitHub](https://github.com/privacybydesign/irma-backend-packages/issues).
-
-If you made a library for a programming language yourself that we do not support yet,
-or if you added features to existing libraries, please send us a pull request.
-We are always interested in extending the IRMA ecosystem with support for additional
-programming languages.
diff --git a/website/versioned_docs/version-v0.4.1/irma-frontend.md b/website/versioned_docs/version-v0.4.1/irma-frontend.md
deleted file mode 100644
index 0bdb20c..0000000
--- a/website/versioned_docs/version-v0.4.1/irma-frontend.md
+++ /dev/null
@@ -1,271 +0,0 @@
----
-title: IRMA frontend JavaScript packages
-id: version-v0.4.1-irma-frontend
-original_id: irma-frontend
----
-
-The [`irma-frontend-packages`](https://github.com/privacybydesign/irma-frontend-packages) repository is a set of
-related JavaScript packages that together form a Javascript frontend client to the
-[`irma server`](https://github.com/privacybydesign/irmago/tree/master/irma). The packages contain a state
-machine package [`irma-core`](#irma-core) to which several plugin packages can be added to achieve IRMA support
-for your application. We also provide a wrapper package [`irma-frontend`](#irma-frontend) that combines `irma-core` with some of the
-plugins in a bundle to have an easy starting point for handling sessions using an embedded web element in the browser.
-
-Using the default styling, the browser version will look like this:
-
-![IRMA frontend web element](assets/irma-frontend-web.gif)
-
-All packages are published on [npm](https://www.npmjs.com/) in `@privacybydesign` scoped packages.
-
-## IRMA core
-
-This package contains the [state machine](https://github.com/privacybydesign/irma-frontend-packages/blob/master/irma-core/state-transitions.js)
-for implementing IRMA flows. `irma-core` itself does not provide any real functionality. Plugins can be registered at the
-state machine and the plugins then provide the functionality depending on the state the state machine is in.
-The plugins can also request state modifications to the state machine.
-
-IRMA core can be initialized in the following way:
-```javascript
-const IrmaCore = require('@privacybydesign/irma-core');
-const irma = new IrmaCore(/* options */);
-
-irma.use(/* Plugin A */);
-irma.use(/* Plugin B */);
-
-irma.start();
-```
-
-More information about the methods IRMA core offers to you can be found
-in the [API overview](api-irma-frontend.md#irma-core).
-
-### Available plugins for IRMA core
-Below is a list of the plugins we provide. Detailed explanations of the plugins can be found in the READMEs
-on GitHub (linked to in the left column).
-
-| Plugin | Functionality |
-|---|---|
-| [`irma-client`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client) | Plugin to fetch a [session package](api-irma-server.md#post-session), to check the `irma server` for the current session status and optionally to fetch the result. The plugin is widely configurable, so you can also fetch a session package or a session result at custom endpoints. |
-| [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web) | Plugin to handle user interaction via a web element that developers can embed within the contents of their webpages. It is designed to be used with [`irma-css`](#irma-css). `irma-css` is not embedded in this package, so you have to manually include this. You are also free to use your own styling. |
-| [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-popup) | `irma-web` element embedded in a popup overlay. The popup is displayed on top of your content and is hidden again when a session is completed, when a fatal error occurs or when the user closes the popup. It is designed to be used with [`irma-css`](#irma-css). `irma-css` is not embedded in this package, so you have to manually include this. You are also free to use your own styling. |
-| [`irma-console`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-console) | Plugin to handle user interaction via the console (either the browser console or the command line console) using node.js. |
-| [`irma-dummy`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-dummy) | Plugin that provides a dummy implementation of the `irma-client` plugin. This can be used to test the user interaction without actually having to do a session at an IRMA server. Instead, the state machine will be instructed to continue after fixed timeouts. |
-
-If a plugin for your use case is not available, we offer you the option to [construct one yourself](#make-your-own-irma-core-plugin).
-
-### Usage guide
-Here we explain the scenario in which the web element is embedded within the contents of our website.
-This web element will be controlled by the `irma-web` plugin. We use `irma-client` for the communication
-with the IRMA server and our backend.
-
-In the body of our HTML page we need to have an HTML element where `irma-web` can render its user interface.
-We also import the [`irma-css`](#irma-css) styling to nicely style our `irma-web-form` element.
-```html
-
-
- ...
-
- ...
-
-
- ...
-
- ...
-
-
-```
-
-In our JavaScript we import `irma-core` and the relevant plugins first.
-```javascript
-const IrmaCore = require('@privacybydesign/irma-core');
-const IrmaWeb = require('@privacybydesign/irma-web');
-const IrmaClient = require('@privacybydesign/irma-client');
-```
-
-Then we can instantiate IRMA core. Let's assume we already have an endpoint `/get-irma-session`
-in our backend that starts a relevant IRMA session at the [`irma server`](irma-server.md). Let's say the endpoint
-returns a single session package (in JSON) without any backend token.
-```javascript
-const irma = new IrmaCore({
- // Enable to get helpful output in the browser console.
- debugging: false,
-
- // The option 'element' is used by irma-web to find its HTML element in the DOM.
- element: '#irma-web-form',
-
- // The 'session' option struct is used by irma-client to find the session informnation.
- session: {
- // The base url of our website
- url: 'http://example.com',
-
- // The 'start' option struct specifies where irma-client can fetch a new session package.
- start: {
- // Specifies how the endpoint url can be derived from the base url (see above).
- url: o => `${o.url}/get-irma-session`,
- // A GET request is used.
- method: 'GET',
- // No additional HTTP headers are needed.
- headers: {},
- // For all other options the default value is sufficient in our example.
- },
-
- // The 'mapping' option specifies how the data can be derived from a 'start' response.
- mapping: {
- // The only thing included in the request is the session pointer, so no additional parsing is needed.
- sessionPtr: r => r,
- },
-
- // Since we did not receive a backend token, we cannot retrieve any session result here.
- result: false,
- },
-});
-```
-
-Now we can add the plugins to our IRMA core instance and start running it.
-```javascript
-irma.use(IrmaWeb);
-irma.use(IrmaClient);
-
-const promise = irma.start();
-```
-
-IRMA core is now started and the IRMA web element should be visible.
-By looking at the state of the promise, you can detect whether the user has finished.
-```javascript
-promise.then(() => {
- // The user has completed the session.
-})
-.catch((err) => {
- // Some fatal error has occurred.
-});
-```
-
-For detailed information about all available options, you can check the README of the
-particular plugin on GitHub. There are links in the plugin overview [above](#available-plugins-for-IRMA-core).
-
-## IRMA frontend
-For convenience we already bundled `irma-core`, `irma-web` and `irma-client` together with the default styling
-from `irma-css`. This bundled package can be downloaded [here](https://gitlab.science.ru.nl/irma/github-mirrors/irma-frontend-packages/-/jobs/artifacts/master/raw/irma-frontend/dist/irma.js?job=irma-frontend).
-Please host this file as asset yourself.
-
-The bundle can be imported in your JavaScript file by doing `require('@privacybydesign/irma-frontend')` or it can
-be included directly in the HTML.
-
-```html
-
-```
-
-You can then instantiate `irma-core` and start a session like this:
-```javascript
-irma.new({
- debugging: false, // Enable to get helpful output in the browser console
- element: '#irma-web-form', // Which DOM element to render to
-
- // Back-end options
- session: {
- // Configure your flow here, see usage guide of irma-core
- },
-
- ...
-});
-
-irma.start()
-.then(result => console.log("Successful disclosure! 🎉", result))
-.catch(error => console.error("Couldn't do what you asked 😢", error));
-```
-
-More information about the methods the IRMA frontend package offers to you can be found
-in the [API overview](api-irma-frontend.md#irma-frontend).
-
-## IRMA css
-For the IRMA core plugins `irma-web` and `irma-popup` we made it possible to manually include the style
-that it will use. We provide to you a [normal version and a minified version](https://gitlab.science.ru.nl/irma/github-mirrors/irma-frontend-packages/-/jobs/artifacts/master/browse/irma-css/dist?job=irma-css)
-of the default styles. The CSS can be linked into your website the regular way:
-
-```html
-
-```
-
-When you want to adapt the design to suit for your own use case, you can take a look in the [styleguide](https://privacybydesign.github.io/irma-frontend-packages/styleguide/).
-Based on this you can adapt the CSS and then import the modified version into your project.
-
-## Make your own IRMA core plugin
-If you need functionality that is not covered by one of the existing IRMA core plugins, you can also define
-one yourself. The defined class must at least have a constructor. In the constructor the `stateMachine` and
-the `options` from `IrmaCore` can be accessed. Furthermore a plugin can have a `start` method that is
-called when the `start` method of the associated `IrmaCore` instance is called, and a `stateChange` method
-that is called when the state of the state machine changes:
-
-```javascript
-class IrmaPlugin {
-
- constructor({stateMachine, options}) {
- ...
- }
-
- // Optional method
- start() {
- ...
- }
-
- // Optional method
- stateChange({newState, oldState, transition, isFinal, payload}) {
- ...
- }
-}
-```
-
-A plugin can request the state machine to make changes. This can be done using the `transition` and
-`finalTransition` methods of the `stateMachine`. The first parameter of these functions is the requested
-transition. The possible transitions can be found in the [state machine](https://github.com/privacybydesign/irma-frontend-packages/blob/master/irma-core/state-transitions.js).
-As second parameter `payload` can be added to the transition. The payload can then be accessed by all other plugins
-as it is one of the parameters of the `stateChange` method. When requesting a `finalTransition`, the state
-machine will be locked in the new state. From then no transitions can be made anymore. For a `finalTransition`
-the potential `newState` must be in the list of possible end states. Otherwise an error is returned. After
-a `finalTransition` the promise returned by the `start` method of `IrmaCore` will resolve or reject
-(depending on the transaction). The promise also resolves or rejects when the `transition` method is used
-and the state machine gets in a state from which no transitions are possible anymore.
-
-For example, in the `IrmaPopup` plugin the user can press on the close button in the UI to abort the session.
-When this happens the `IrmaPopup` plugin must request a state change at the IRMA core state machine to
-notify all other plugins that the new state becomes `Aborted`. This is done in the following way:
-```javascript
-stateMachine.transition('abort', 'Popup closed');
-```
-
-There are no transitions possible anymore from the state `Aborted`. This means that unless the transition
-is not explicitly marked as final, the `stateChange` method of your plugin will be called with `isFinal` set
-to true.
-
-## Differences with [irmajs](irmajs.md)
-The previous JavaScript library `irmajs` combined frontend and backend functionality. The `startSession` related
-functions could be used to start sessions, and `handleSession` could be used for actually being the
-frontend to the user.
-
-In the new library we have split these functionalities into two libraries. The session management functionality
-for node.js server applications now belongs to the [`irma-backend-packages`](https://github.com/privacybydesign/irma-backend-packages).
-The `irma-frontend-packages` only deals with session handling for the (web)client, starting
-with fetching a session package from a remote server, then communicating with the `irma server` what the current status
-of the session is, and finally fetching the result if the client needs it.
-It also handles the user interaction related to all of these actions.
-
-As a rule of thumb, `irma-frontend-packages` is meant to handle the `/irma/...` endpoints, and
-`irma-backend-packages` is meant to handle the `/session/...` endpoints of the `irma server`. Theoretically,
-`irma-frontend-packages` is able to fetch a session package directly at the `irma server` and therefore also
-use the `/session` endpoint of the `irma server`. This flow is however not recommended. A better
-practice is to put a backend layer in between that starts the session at the `irma server`.
-
-For user interaction, we currently have support for a web element embedded in the content, a web browser
-popup overlay and console user interaction using node.js. Below you can find an overview of the plugins for
-`irma-core` and how they map to the methods known from `irmajs`. In all cases the [`irma-client`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client)
-plugin is needed for server communication.
-
-| irmajs method | irma-frontend plugin | Differences |
-|---|---|---|
-| `'popup'` | [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-popup) | Does not always reject on cancellation or timeout. When a `start` endpoint is specified at `irma-client` to fetch a new session package, the user gets the opportunity to try again. Also, support for tablets has been added. The default [`irma-css`](#irma-css) style can be used or a custom CSS template can be defined to give it your own look and feel. |
-| `'canvas'` | [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web) | Has been upgraded to a full web element to also be able to handle tablets. Auto-refreshment of the QR on session timeout is now supported. Furthermore, the differences mentioned at the method `popup` also apply here. |
-| `'mobile'` | [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web) or [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-popup) | The mobile flow is fully integrated into the web and popup interfaces. Please check those options to see the differences. |
-| `'console'` | [`irma-console`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-console) | No major differences. |
-| `'url'` | _No support_ | The url can simply be constructed according to the format `https://irma.app/-/session#` where `` has to be replaced with the session package JSON object (converted to a string using url encoding). A session package can be retrieved using the [`irma-backend-packages`](https://github.com/privacybydesign/irma-backend-packages). |
-
-For users that have difficulties integrating a new library, but do want to upgrade, we also provide a [`irma-legacy`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/irma-legacy)
-wrapper that maps the legacy `irmajs` calls onto the new `irma-frontend-packages`. More information about this will follow.
diff --git a/website/versioned_docs/version-v0.4.1/irma-server.md b/website/versioned_docs/version-v0.4.1/irma-server.md
deleted file mode 100644
index 7bba1e8..0000000
--- a/website/versioned_docs/version-v0.4.1/irma-server.md
+++ /dev/null
@@ -1,252 +0,0 @@
----
-title: irma server
-id: version-v0.4.1-irma-server
-original_id: irma-server
----
-
-
-`irma server` is an IRMA server executable (daemon) allowing you to perform IRMA sessions with
-[IRMA apps](https://github.com/privacybydesign/irma_mobile). It handles all IRMA-specific cryptographic details of issuing or verifying IRMA attributes with an IRMA app on behalf of a [requestor](overview.md#participants) (the application wishing to verify or issue attributes). It exposes the following:
- * HTTP endpoints under `/irma`, used by the IRMA app during IRMA sessions
- * a JSON API under `/sessions` for requestors, allowing them to request the server to verify or issue attributes.
-
-`irma server` is a subcommand of the [`irma`](irma-cli.md) command line tool, which additionally contains subcommands to start or perform IRMA sessions, handle [IRMA schemes](schemes.md), and more.
-
-For installation instructions, see [`irma`](irma-cli.md).
-
-## Running the server
-
-Simply run `irma server` to run the server with the default configuration in development mode. Use `irma server -v` for more verbose logging, for example to see the current configuration. Use `irma server -vv` to also log session contents.
-
-Run `irma server --help` to see configuration options. In order to verify your configuration, run `irma server check -v`.
-
-## Starting a session
-Assuming the server runs in the [default configuration](#default-configuration) (in particular [requestor authentication](#requestor-authentication) is disabled (`no_auth` is `true`) and the `irma-demo` [scheme](schemes.md) is installed), issue `irma-demo.MijnOverheid.ageLower` attributes using the [`session`](irma-cli.md) subcommand of the `irma` tool:
-```shell
-irma session --server http://localhost:8088 --issue irma-demo.MijnOverheid.ageLower=yes,yes,yes,no
-```
-Verify the `irma-demo.MijnOverheid.ageLower.over18` attribute:
-```shell
-irma session --server http://localhost:8088 --disclose irma-demo.MijnOverheid.ageLower.over18
-```
-These print QRs in your terminal that you can scan with your IRMA app to perform the session. For more extensive examples, see [irmajs](irmajs.md).
-
-## Configuring
-Run `irma server -h` to see all configuration options. Each option may be passed as:
- 1. a command line flags (e.g. [`--listen-addr`](#http-server-endpoints))
- 2. a environmental variable (e.g. `IRMASERVER_LISTEN_ADDR`)
- 3. an item in a configuration file (e.g. `"listen_addr"`) (which may be in JSON, TOML or YAML)
-
- with the following rules:
- * Flags supersede environmental variables which supersede configuration file entries.
- * Dashes are used in flags, but underscores are used in environmental variables and configuration file entries.
- * Environmental variables are uppercased and prefixed with `IRMASERVER_`.
- * The [`requestors`](#requestor-authentication) and [`static_sessions`](#static-irma-qrs) options are special: when passed as a flag or environmental variable, they must be passed as a JSON object (for example: `--requestors '{"myapp":{"auth_method":"token","key":"12345"}}'`).
- * When passing a boolean flag [use an `=`](https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax), for example [`--no-auth=false`](#requestor-authentication).
-
-In order to see the configuration that the server uses after having gathered input from these sources, specify `-v` or `-vv` or use the `verbose` option. Use `irma server check -v` (with the same flags, env vars and config files as `irma server`) to check your configuration for correctness before running the server.
-
-In the remainder of this document, when referring to options we write them as configuration file entries, with underscores and without prefix.
-
-### Default configuration
-In the default configuration (run `irma server check -v` to see it) the server is immediately usable. In particular, it
-* uses the [default IRMA schemes](schemes.md#default-schemes-pbdf-and-irma-demo) ([`pbdf`](https://github.com/credentials/pbdf-schememanager) and [`irma-demo`](https://github.com/credentials/irma-demo-schememanager)), downloading them if necessary
-* allows anyone to use the server [without authentication](#requestor-authentication) (the `no_auth` setting is `true`).
-
-If the server is reachable from the internet, you should consider enabling authentication of session requests.
-
-### Configuration files
-A configuration file can be provided using the `config` option (for example: `irma server --config ./irmaserver.json`). When not specified, the server looks for a configuration file called `irmaserver.json` or `irmaserver.toml` or `irmaserver.yaml` in (1) the current path; (2) `/etc/irmaserver/`; (3) `$HOME/irmaserver`, in that order. A configuration file is not required; if none is found at any of these locations the server takes its configuration from just command line flags and environmental variables.
-
-### Production mode
-When running the server in production, you should enable the `production` option. This enables stricter defaults on the configuration options for safety and prints warnings on possibly unsafe configurations. In particular, when `production` is enabled, the default values of some options change as follows (cf. `diff <(irma server -h) <(irma server -h --production)`):
-
-* `url` from `"http://$YOUR_LOCAL_IP:port"` to `""`: in development mode the `url` to which IRMA apps will connect is set by default to your current local IP address; in `production` mode you must configure it yourself.
-* [`no_auth`](#requestor-authentication) from `true` to `false`: you should consider enabling requestor authentication, or explicitly disable this by setting this flag to `true`.
-* [`issue_perms`](#global-permissions) from `[*]` (everything) to `[]` (none).
-* [`no_email`](email.md) from `true` to `false`: in `production` mode, opting out of providing an email address can be done by explicitly setting this flag to `true`.
-
-### Keys and certificates
-For each configuration option that refers to some kind of key or certificate (for example `jwt_privkey`), there is a corresponding option with the `_file` suffix (for example `jwt_privkey_file`). Keys can be specified either by setting former to a (PEM) string, or setting the the latter to a file containing the (PEM) string.
-
-### HTTP server endpoints
-The HTTP endpoints that this server offers is split into two parts:
-* `/session`: used by the requestor to start sessions, check session status, or get session results.
-* `/irma`: used by the IRMA app during IRMA sessions.
-
-In the default mode, the server starts one HTTP server that offers both, configured with `listen_addr` and `port`. If however the `client_port` and `client_listen_addr` options are provided, then the server starts two separate HTTP servers:
-* `/session` attaches to the address and port provided with `port` and `listen_addr`.
-* `/irma` attaches to the address and port provided with `client_port` and `client_listen_addr`.
-
-The `/irma` endpoints must always be reachable for the IRMA app. Using this double server mode you can restrict access to the `/session` endpoints by e.g. setting `listen_addr` to `127.0.0.1` or to an interface only reachable from an internal network. Restricting access to the `/session` endpoints in this way may make requestor authentication unnecessary.
-
-### Requestor authentication
-The server runs in one of two modes: it either accepts all session requests from anyone that can reach the server, or it accepts only authenticated session requests from authorized requestors. This can be toggled with the `no_auth` boolean option. If the `/session` creation endpoint of your `irma server` is publicly accessible from the internet (i.e. the `client_port` option is used, see [above](#http-server-endpoints)), then you should consider enabling requestor authentication (i.e. turn `no_auth` off), otherwise anyone can use your `irma server`.
-
-The default is `true` (requests are not authenticated) when `production` is disabled and `false` otherwise.
-
-When authentication is enabled (`no_auth` is `false`), requestors that are authorized to use the server must be configured in the `requestor` option in the form of a map, for example:
-
-```json
-{
- "requestors": {
- "myapp": {
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-
-The server supports several authentication methods, one of which must be specified in the `auth_method` field for each requestor. The snippet above demonstrates the recommended and easiest to use authentication method, called `token`. When using this method the requestor must include the `key` as an API token in a HTTP header (for more details see the [API reference](api-irma-server.md#post-session)).
-
-In addition the server supports the following authentication methods:
-* `hmac`: the requestor symmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/), with HMAC-SHA256 (`HS256`) using `key`. The `key` provided should be the Base64 encoding of the actual secret.
-* `publickey`: the requestor asymmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/) with RSA (`RS256`), in this case `key` should be the PEM public key of the requestor.
-
-For each of these modes it is also possible to specify `key_file` instead `key`; in that case the file at `key_file` will be read and used as `key`.
-
-### Static IRMA QRs
-Unlike normal QRs which differ per session (as they contain the session token), the server also supports static QRs which, when scanned by the IRMA app, start preconfigured IRMA sessions. This makes it possible to for example print such a static QR. These preconfigured sessions are configured with the `static_sessions` options, for example:
-```json
-{
- "static_sessions": {
- "mystaticsession": {
- "callbackUrl": "https://example.com/callbackUrl",
- "request": {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "irma-demo.MijnOverheid.ageLower" ]]]
- }
- }
- }
-}
-```
-Thus `static_sessions` must contain a map of which each item must be an [extended session request](session-requests.md#extra-parameters). Including a `callbackUrl` to which the [session result](api-irma-server.md#get-session-token-result) is sent after the session is required (since for these sessions there is no requestor waiting to receive the attributes after the session has finished). If a JWT private key is installed, then the session result is sent as a [JWT](api-irma-server.md#get-session-token-result-jwt).
-
-> If no JWT private key is installed, then the `callbackUrl` should either not be publically reachable, or it should include a secret token (e.g. https://example.com/cX5aTins5kEZpjDpfYcN) and have TLS enabled (which it should anyway as personal data will be POSTed to it). Otherwise there is no way of distinguishing POSTs from your `irma server` from POSTs made by someone else.
-
-Assuming the URL of the `irma server` is `http://example.com`, the session configured above is started when the IRMA app scans a QR with the following contents:
-```json
-{
- "irmaqr": "redirect",
- "u":" http://example.com/irma/session/mystaticsession"
-}
-```
-
-Only static [disclosure or attribute-based signature sessions](what-is-irma.md#session-types) are supported.
-
-### Permissions
-For each of the [three IRMA session types](what-is-irma.md#session-types) (attribute verification; attribute-based signature sessions; and attribute issuance), permission to use specific attributes/credentials can be granted to requestors in the configuration. For example, including permissions in the `myapp` requestor from above:
-```json
-{
- "requestors": {
- "myapp": {
- "disclose_perms": [ "irma-demo.MijnOverheid.ageLower.over18" ],
- "sign_perms": [ "irma-demo.MijnOverheid.ageLower.*" ],
- "issue_perms": [ "irma-demo.MijnOverheid.ageLower" ],
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-This means that `myapp` is authorized to request `irma-demo.MijnOverheid.ageLower.over18` in disclosure session, and any attribute from `irma-demo.MijnOverheid.ageLower` in attribute-based signature sessions. Additionally `myapp` can issue `irma-demo.MijnOverheid.ageLower` instances. In each level wildcards are permitted (`irma-demo.MijnOverheid.ageLower.*`, `irma-demo.MijnOverheid.*`, `irma-demo.*`, `*`). Thus `"disclose_perms": [ "*" ]` allows the requestor to verify any attribute.
-
-### Global permissions
-
-Global permissions can be applied to all requestors by using the global `disclose_perms`, `sign_perms` and `issue_perms` options. For each requestor, the effective set of permissions is the union of the permissions specified in its `requestors` map and the global permission set.
-
-The global options also work when `no_auth` is enabled. Thus in this case a session type can be disabled by granting no one the permission, e.g., `issue_perms: []` would disable issuance.
-
-In development mode, when `production` is `false`, the defaults for `disclose_perms`, `sign_perms` and `issue_perms` are `["*"]`. In order to protect any IRMA private keys that the server has access to from unintended use by others, when `production` is true the default of `issue_perms` is `[]`: no one can issue unless the global `issue_perms` is modified or unless specific requestors receive nonempty `issue_perms`.
-
-### Static file hosting
-
-Apart from hosting endpoints under [`/session` and `/irma`](irma-server.md#http-server-endpoints), the server also supports statically hosting all files from a certain directory. This can be useful [for experimenting](getting-started.md#perform-browser-irma-session). It can be configured with the following options:
-
-* `static_path`: Host files under this path as static files. Leave empty to disable static file hosting.
-* `static_prefix`: Host static files under this URL prefix (default: no prefix)
-
-### IRMA schemes
-
-The server uses [IRMA schemes](schemes.md) to retrieve issuer, credential and attribute names, as well as public and private keys with which attributes can be verified an issued, respectively. By default the server uses the [`pbdf` and `irma-demo` schemes](schemes.md#default-schemes-pbdf-and-irma-demo). This can be configured with the following options:
-
-* `schemes_path`: path containing IRMA schemes (often called `irma_configuration`). Default: `C:\Users\Username\AppData\Local\irma\irma_configuration` on Windows, `$HOME/.local/share/irma/irma_configuration` otherwise. Created if it does not exist. If empty, the default schemes [`pbdf` and `irma-demo`](schemes.md#default-schemes-pbdf-and-irma-demo) are downloaded into it.
-* `schemes_assets_path`: path containing initial, read-only IRMA schemes. If specified, the schemes found here are copied into the path specified by `schemes_path`. Can be used to avoid downloading default schemes on first run.
-* `schemes_update`: update IRMA schemes from their scheme URL every this many minutes. Default is `60`. Set to `0` to disable automatic scheme updating (not recommended).
-
-### IRMA issuer private keys
-
-If IRMA issuer private keys are included in the server configuration, then the server can issue all credential types of all issuers for which private keys are installed. IRMA issuer private keys can be configured in the following two ways:
-
-* Include the private keys within the [IRMA scheme](schemes.md) in the issuer's `PrivateKeys` folder, with filenames `0.xml`, `1.xml`, etc ([example](https://github.com/privacybydesign/irma-demo-schememanager/tree/master/MijnOverheid/PrivateKeys)).
-* Set the `privkeys` option to a folder containing IRMA issuer private keys called `scheme.issuer.xml` (for example, `irma-demo.MijnOverheid.xml`).
-
-If issuance is enabled in production and private keys are configured, then you should ensure that only authenticated requestors can start issuance requests (otherwise if anyone can use your server to issue attributes then those attributes cannot be trusted or used). You should either:
-
-* disable `no_auth` and [send authenticated session requests](irma-server.md#requestor-authentication),
-* Restrict the [`/session` HTTP endpoints](#http-server-endpoints) to a internal network interface only accessible by your applications and not from outside.
-
-Taking neither approach is an unsafe configuration as in that case anyone can create issuance sessions. In this case, if `production` mode is enabled then the server will refuse to run.
-
-### Signed JWT session results
-
-If a `jwt_privkey` (or `jwt_privkey_file`) is given, then the following endpoints are enabled:
-
-* `GET /session/{sessiontoken}/result-jwt`: returns the session result signed by the `irma server` into a JWT.
-* `GET /session/{sessiontoken}/getproof`: returns a JWT similar to the one from `result-jwt`, but with the same structure as the IRMA API server session result JWTs.
-* `GET /publickey`: returns the public key with which the JWTs output by this server can be verified.
-
-This can be useful if the session result travels along an unsafe or untrusted route from the IRMA server to the requestor. As long as the `irma server` is trusted and its public key is known, the JWT can be verified to ensure that the session result was untampered with since it left the `irma server`.
-
-### TLS
-
-The IRMA protocol relies on TLS for encryption of the attributes as they travel along the internet. If your server is connected to the internet and it handles actual attributes (personal data from people), then you ***must*** ensure that the attributes are protected in transit with TLS.
-
-You can enable TLS in the `irma server` with the `tls_cert` and `tls_privkey` options (or the `_file` equivalents), specifying a PEM certificate (chain) and PEM private key. If you use [separate requestor and app endpoints](#http-server-endpoints), additionally use `client_tls_cert` and `client_tls_privkey`.
-
-Alternatively, if your IRMA server is connected to the internet through a reverse proxy then your reverse proxy probably handles TLS for you.
-
-### Email
-
-Users of the server are encouraged to provide an email address with the `email` option, subscribing for notifications about changes in the IRMA software or ecosystem. [More information](email.md). In `production` mode, it is required to either provide an email address or to explicitly out with the `no_email` option.
-
-### Logging and verbosity
-
-The server's verbosity can be increased by two degrees:
-* `-v` flag is given, or `verbosity` option set to `1`: includes `DEBUG` messages. Logs server configuration when starting the server, stack traces of errors, and more.
-* `-vv` flag is given, or `verbosity` option set to `2`: includes `TRACE` messages. Additionally includes dumps of all HTTP traffic from and to the server.
-
-> in its default mode, the server will not log attribute values (personal data). If the verbosity is increased, then attribute values may be logged. You should avoid doing this in production.
-
-The output is [structured](https://github.com/sirupsen/logrus#fields), putting certain recurring values in fields:
-```text
-[2019-02-28T20:51:09+01:00] INFO Session started action=disclosing session=WdypvSs97JTotpfl1Dtd
-```
-Outputting JSON is enabled with the `log-json` option:
-```json
-{"action":"disclosing","level":"info","msg":"Session started","session":"WdypvSs97JTotpfl1Dtd","time":"2019-02-28T20:51:09+01:00"}
-```
-
-## Design goals
-
-The server was designed with the following goals in mind.
-- Developer and user friendliness
- - Completely [configurable](#configuring) with configuration file, flags, or environmental vars (see `-h`)
- - Default configuration (demo mode) is immediately useful
- - Thorough and configurable logging (`-v`, `-vv`; by default logs exclude attribute values)
- - Partial backwards compatibility with predecessor [`irma_api_server`](https://github.com/privacybydesign/irma_api_server)
- - Small startup time
-- Also available as [Go library](irma-server-lib.md) instead of standalone server
- - Bindings to other programming languages (Python, Ruby) are expected
-
-Being written in [Go](https://golang.org/) this server (in fact, the containing [`irma` binary](irma-cli.md)) additionally automatically has the following properties.
-- Simple to install (one binary, no dependencies, cross platform) and/or compile
-- [Reproducible builds](https://www.gnu.org/software/mes/manual/html_node/Reproducible-Builds.html)
-- [API documentation](https://godoc.org/github.com/privacybydesign/irmago) (generated automatically from `master` branch)
-
-Referring to Go packages (i.e. folders) under [`irmago`](https://github.com/privacybydesign/irmago), the server is structured as follows.
-* `internal/servercore`: Go library implementing the HTTP endpoints for the IRMA protocol (in which the IRMA app is the client), and a Go API for requestors to manage sessons. Not meant for direct use, can instead be compiled to a C-compatible library (at `server/irmac`) for binding to other languages (Ruby, Python, Swift).
-* [`server/irmaserver`](irma-server-lib.md): Go library wrapping the server and API implemented by `internal/servercore`. ([Godoc API documentation](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver))
-* `server/requestorserver`: Go library wrapping `server/irmaserver`, exposing the requestor API as a second HTTP endpoint set under `/session` URLs instead of as Go functions (next to `/irma` for the IRMA app endpoints). ([Godoc API documentation](https://godoc.org/github.com/privacybydesign/irmago/server/requestorserver))
-* `irma`: executuable whose `server` commands wraps `server/requestorserver`.
diff --git a/website/versioned_docs/version-v0.4.1/revocation.md b/website/versioned_docs/version-v0.4.1/revocation.md
deleted file mode 100644
index 813d2ff..0000000
--- a/website/versioned_docs/version-v0.4.1/revocation.md
+++ /dev/null
@@ -1,328 +0,0 @@
----
-title: Coming: revocation
-id: version-v0.4.1-revocation
-original_id: revocation
----
-
-
-
-
-Revocation will add to IRMA issuers the ability to revoke a credential that it previously issued to an IRMA app, when the contained attributes are no longer accurate. This allows IRMA attribute verifiers to establish that the attributes it received are still factual, as otherwise the credential would have been revoked by the issuer.
-
-This page explains in detail how revocation is implemented in IRMA and what it means to requestors and app users, on three levels:
-* In the first part of the section below, we give a summarizing overview fitting in one page.
-* In the [API section](#api) we give a much more expansive explanation, including the new revocation API for issuers and verifiers.
-* In the [cryptography section](#cryptography) we explain the cryptographic mechanism enabling revocation.
-
-## Overview
-
-Revocation in IRMA is an implementation of the RSA-B scheme from ["Accumulators with applications to anonymity-preserving revocation"](https://eprint.iacr.org/2017/043.pdf) by Baldimtsi et al, which in turn is based on ["Dynamic accumulators and application to efficient revocation of anonymous credentials"](http://static.cs.brown.edu/people/alysyans/papers/camlys02.pdf) by Camenisch et al. Using this scheme the app can prove nonrevocation of its credential in zero-knowledge, preserving [unlinkability of multiple disclosures](overview.md#irma-security-properties) of the attributes within the credential.
-
-In IRMA, revocation is enabled per credential type in the IRMA scheme. If so, when properly configured (more on that [below](#revocation-settings)) the issuer's IRMA server will issue revocation-enabled credentials of that type. During disclosures the IRMA app can then prove nonrevocation (but it will only do so if explicitly asked for by the requestor).
-
-In short, revocation works as follows.
-
-* **Key generation**: The issuer generates an **accumulator** and makes it available to all IRMA participants (i.e. requestors and apps; more on how this is done later). This accumulator changes value whenever the issuer revokes a credential.
-* **Issuance**: If the issuer issues a credential for which revocation is enabled in the scheme, then along with the credential the issuer computes a **nonrevocation witness**, consisting of two large integers. This witness is valid against the issuer's current accumulator (like a signature over a message can be valid against a public key). One of these integers is also included in the credential as a new **revocation attribute** (hidden in de IRMA app GUI), binding the witness to the credential. During issuance, the issuer stores the revocation attribute for this credential in a database for later revocation. The IRMA app stores the witness alongside the credential.
-* **Disclosure**: If the requestor asks for a nonrevocation proof for a given credential type and the app has a revocation-enabled credential instance of that type, then along with the disclosed attributes the client sends to the requestor a **nonrevocation proof**, which proves in zero knowledge to the requestor that the witness of the credential is valid against the issuer's current accumulator. From this the requestor infers that the credential is not revoked.
-* **Revocation**: When the issuer wants to revoke a credential, it first looks up in its database the revocation attribute for that credential that it stored after issuance. Using this, it (1) updates its accumulator to a new value, and (2) makes available to all IRMA participants a **revocation update message**, consisting of the new accumulator and the revocation attribute of the revoked credential. IRMA apps containing (non-revoked) credentials use these update messages to update their witness, so that it becomes valid to the new accumulator. This update algorithm is such that it always fails for the witness of the revoked credential, so that the containing app can no longer prove nonrevocation.
-
-Computing a nonrevocation proof for a credential is much more expensive than just computing a disclosure proof out of that credential. If the user has a revocation-enabled credential then proving nonrevocation is not required; instead she can also just normally disclose attributes from the credential, without using the witness, which is much cheaper. For this reason the app will only prove nonrevocation for a credential type if the requestor explicitly requests it. Requestors should only request nonrevocation proofs when it is really necessary for them to establish that they received nonrevoked attributes.
-
-In the papers linked to above (and generally in the scientific literature on revocation), the party that is able to revoke credentials is called the **revocation authority**, which is not necessarily the same as the party that issues credentials. Within IRMA we have decided to endow the issuer with this responsibility, i.e. the issuer is also the revocation authority for revocation-enabled credential types, because conceptually and technically this simplifies many details.
-
-> In the remainder of this post when we refer to the requestor, issuer, or verifier, we generally refer to the IRMA server software implementing APIs for those parties. The term "IRMA server" itself refers to the following variants of the IRMA server:
-> * The [`irma server`](irma-server.md) daemon.
-> * The [`irmaserver` Go library](irma-server-lib.md).
->
-> Support for revocation will be added to the [bindings of the above library](https://github.com/privacybydesign/irmago/tree/master/server/irmac) to other programming languages soon.
-
-### Revocation updates
-
-Whenever the issuer revokes a credential, updating its accumulator, it publishes a revocation update message as explained above, which apps require to update their witness so that it is valid against the new accumulator. Accumulators are labeled with an index which is increased whenever the issuer makes a new accumulator by revoking. Apps use the index to keep track of against which accumulator their witness is valid in the chain of all past accumulators, and thus how many update messages it needs to obtain and apply. The app requires all of the update messages that it has not already received and applied; if it misses one or more of them it cannot update its witness and it is no longer able to compute nonrevocation proofs for the witness's credential. If that happens but the verifier requires a nonrevocation proof, then the user is unable to disclose attributes from the credential.
-
-It is thus crucial that the set of update messages is always available to each IRMA app. In IRMA, the issuer is responsible for ensuring that all update messages and the latest accumulator are available. To that end, the IRMA server exposes these messages through new HTTP endpoints, if so configured. For each revocation-enabled credential type, at least one URL to such an IRMA server instance must be included within the credential type in the scheme.
-
-If within an IRMA session a requestor requests revocation for a given credential type but the app's witness is out of date (i.e. credentials have been revoked and the accumulator changed value since the app last updated), then before the app can prove nonrevocation it needs to update its witness so that it becomes valid against the latest accumulator. If the app would have to contact the issuer's IRMA server to download updates whenever that happens, then the issuer could infer from its logs that the user is updating probably because she now wants to disclose attributes, harming the user's privacy towards the issuer. In order to prevent this, whenever a requestor requests a nonrevocation proof for a given credential type in a session request, it is required to include the last few revocation update messages for that credential type with the session request. The app uses those to update its witness, if it is not too far behind. The IRMA server will automatically include the required amount of update messages when it sends the session request to the app during the IRMA protocol. (If the app is too far behind then it will need to contact the issuer to download the updates that it did not receive from the requestor in the session request. The IRMA app will do this periodically, i.e. outside of IRMA sessions, for all of its witnesses.)
-
-#### Revocation update chain
-
-Whenever a credential is revoked and the accumulator changes value, the accumulator's index is incremented. If an app has a witness at index $i$ but the current accumulator $\nu_j$ has index $j$, then the app requires $(e_i,\dots,e_j,\nu_j)$ to update its witness to the latest index $j$, where the $e$'s are the revocation attributes of the revoked credentials. As soon as another credential is revoked and the current accumulator becomes $\nu_{j+1}$, the old accumulator $\nu_j$ is no longer needed. Thus the revocation attributes $e_i$ naturally form a chain, always headed with the latest accumulator $\nu_j$.
-
-Each element of this chain (including the head element $\nu_j$) contains the cryptographic hash of its predecessor, and $\nu_j$ is signed by the issuer using ECDSA. Thus this one ECDSA signature signs the entire partial chain $(e_i,\dots,e_j,\nu_j)$: apps and IRMA servers can check its authenticity regardless of its length. This makes it safe for the IRMA app to receive revocation update messages through the requestor in the session request.
-
-Each accumulator $\nu_j$ contains the time of its creation, and every minute this timestamp is refreshed: the accumulator is replaced with a new (signed) accumulator $\nu'_j$ with the same value and index but newer timestamp. To others receiving the updated accumulator, this proves that the issuer's revocation setup is still live. In addition, when verifying an attribute-based signature this makes it possible to establish that the attributes in it were not revoked at creation time of the signature.
-
-A requestor by itself only needs the accumulator $\nu_j$ against which the app has proved nonrevocation in order to verify the proof, and not necessarily the revocation attributes $e_j$ of the revoked credentials. However, they will still fetch a number of these attributes from the issuer's revocation IRMA server in order to pass them on to apps during IRMA sessions.
-
-### Issuer responsibilities
-
-The issuer of a revocation-enabled credential type must:
-
-* Store all revocation update messages in order to be able to offer these to other IRMA participants needing them;
-* Offer the revocation update messages to other IRMA participants through an HTTP API;
-* Store the revocation attribute of each revocation-enabled credential during issuance, as the revocation attribute is necessary during revocation;
-* Revoke a credential when necessary by updating the accumulator and adding a revocation update message.
-
-The IRMA server can handle any or all of the above responsibilies if so configured (see [below](#revocation-settings)).
-
-If the server hosting the revocation update messages is unreachable, then the requestor and app cannot update their accumulator and witness to the latest version. In that case nonrevocation can only be proved against the last known accumulator, from before the issuer's server became unreachable.
-
-> In the event that the issuer's server is unreachable and the requestor's IRMA server cannot update its accumulator to the latest version, then the requestor's IRMA server will accept nonrevocation proofs from the app against its last known accumulator. This results in a time window in which nonrevocation is not guaranteed. If that time window is longer than a configurable maximum the server will report the length of the nonrevocation window to the requestor, but still accept the attributes.
-
-The only possible alternative behaviour would be for the requestor to not accept the attributes, but we want to avoid burdening the user with the consequences of the problem; she would then no longer be able to do whatever she wanted to do with her attributes. Therefore we leave this decision to the requestor. Instead it is the issuer's responsibility to always keep its server online so that this does not happen; and when it does go offline, to restore it as soon as possible. The shorter it is offline, the smaller the "nonrevocation window" and the smaller the problem.
-
-Before revocation is enabled for a given credential type, revocation-specific public and private key material has to be included in the IRMA public and private key of the issuer of the credential type. The [`irma` binary](irma-cli.md) will do so automatically for new keypairs and it can also augment existing keypairs.
-
-#### Scalability
-
-The issuer of a revocation-enabled credential type must always have at least one publically reachable IRMA server running, which is contacted in the following cases.
-* Requestor IRMA servers verifying instances of this credential type will periodically fetch revocation updates (by default every 5 minutes), in order to pass them along to IRMA apps during sessions.
-* IRMA apps also periodically fetch revocation updates to ensure their witness does not become too far outdated (with random time intervals, around 1 day). The average amount of time between two such updates can be configured in the scheme.
-* During a session, if the IRMA app's witness is so far outdated that the update messages provided by the requestor are not sufficient.
-
-The load on this server will increase with the amount of (1) requestors, (2) IRMA apps posessing revocation-enabled credentials, and (3) revocations performed by the issuer. If the load becomes too heavy for one IRMA server, the issuer can do the following:
-* Deploy multiple revocation IRMA servers, with for example a DNS load balancer in front of them, or putting multiple `RevocationServer` URLs in the scheme (see below).
-* Deploying HTTP caching servers in front of the revocation IRMA servers, as it outputs `Cache-Control` HTTP headers on revocation HTTP endpoints that output stable information.
-
-All revocation update messages and accumulators are always digitally signed by the issuer using ECDSA before they are published, and in particular, the entire revocation update chain is signed. This means that other parties than the issuer itself can also run IRMA servers running in revocation server mode for the issuer's credential type. Apart from sharing the load this can also increase uptime.
-
-## API
-
-The addition of revocation to IRMA is designed to be backwards compatible: when revocation is not enabled for a credential type or when a nonrevocation proof is not requested, everything works as it used to; and all of the API changes documented below are additions, adopting the style and conventions of the existing API wherever applicable.
-
-### Scheme
-
-Revocation for a credential type is enabled in the scheme by (1) including at least one `RevocationServer` XML tag in its `description.xml`, and (2) including a *revocation attribute*:
-```xml
-
-
- http://example.com/
-
-
-
-
-
-
-
-
-```
-See for example [this demo credential type](https://github.com/privacybydesign/irmago/blob/master/testdata/irma_configuration/irma-demo/MijnOverheid/Issues/root/description.xml#L19). Specifying more than one URL allows IRMA requestors and apps to fallback to other URLs when one of them is offline. Once revocation is enabled in the scheme, issuing IRMA servers will automatically issue revocation-enabled credentials. (From this moment the issuing requestor [needs to include](#issuance) `revocationKey`s in its issuance requests, and the issuing IRMA server(s) need to be correctly [configured](#revocation-settings) for revocation.)
-
-Existing credential types can gain support for revocation by adding a `RevocationServer` and adding an attribute with `revocation` enabled.
-
-The IRMA issuer private and public keys used for revocation-enabled credentials must contain revocation-specific key material. When generating new keypairs, `irma issuer keygen` now always includes this. Existing keypairs may be augmented using the new `irma issuer revocation keypair` subcommand.
-
-### Revocation settings
-
-The primary new responsibility for an issuer of a revocation-enabled credential type is to maintain the [revocation update chain](#revocation-update-chain) $(...,e_{i-1},e_i,\nu_i)$. The IRMA server supports a new *revocation mode* for this which can be enabled per credential type by the issuer. At minimum, for each credential type supporting revocation one IRMA server must run in revocation mode for that credential type (publically reachable via its URL in a `RevocationServer` tag in the credential type).
-
-Revocation can be configured in the IRMA server configuration using a new `revocation_settings` map, containing options per credential type. Below is a full example of an IRMA server running in revocation mode for `irma-demo.MijnOverheid.root`.
-
-```json
-{
- "revocation_db": "host=127.0.0.1 port=5432 user=testuser dbname=test password='testpassword'",
- "revocation_db_type": "mysql",
- "no_auth": false,
- "revocation_settings": {
- "irma-demo.MijnOverheid.root": {
- "authority": true
- }
- },
- "requestors": {
- "myapp": {
- "authmethod": "token",
- "key": "mypresharedtoken",
- "issue_perms": [ "irma-demo.MijnOverheid.root" ],
- "revoke_perms": [ "irma-demo.MijnOverheid.root" ]
- }
- }
-}
-```
-
-Note the following:
-* A server running in revocation mode for any credential type requires a SQL database to be configured. In this database all revocation state will be stored. Currently MySQL and Postgres are supported.
-* This configuration also grants permission to a requestor called `myapp` to issue and revoke `irma-demo.MijnOverheid.root` instances. Alternatively, if `no_auth` would be `true` then any requestor capable of reaching the server could issue and revoke instances (in production settings, such a server should not be publically reachable).
-
-For each credential type revocation settings may be specified in the `revocation_settings` block as above. The following specifies all possible options and their defaults.
-```json
-{
- "server": false,
- "authority": false,
- "revocation_server_url": "",
- "tolerance": 600,
- "sse": false
-}
-```
-The options are as follows.
-* `server` enables endpoints used by IRMA apps and other IRMA servers to fetch part of the revocation update chain.
-* `authority` implies `server` and additionally enables (1) an endpoint required by issuing IRMA servers to send **issuance records** to for each issued credential, required for later revocation of the credentials; and (2) an endpoint accepting revocation requests (subject to the server's requestor authentication configuration).
-* `revocation_server_url`, if present, overrides the `RevocationServer` URL from the credential type in the scheme. In the following cases, this must point to an `authority` IRMA server:
- - If `server` is true but `authority` is false (in this case, revocation updates are fetched from here);
- - If this server will issue instances of the current credential type, and `authority` is false (otherwise it just stores the records locally).
-* `tolerance`: at the latest, the nonrevocation guarantee provided by the IRMA app lasts until the moment that it first connected to the IRMA server in the current session (see [below](#disclosure)). If during an IRMA session this time window is more than `tolerance` seconds, then it will be reported back to the requestor (who may then decide to accept the attributes or abort).
-* `sse`: if `true` then the IRMA server will attempt to open a [Server Sent Events](https://en.wikipedia.org/wiki/Server-sent_events) channel to the revocation server (as specified by either the scheme or `revocation_server_url`). If successful, the revocation server will push new revocation updates to the IRMA server as it creates them (instead of the IRMA server having to periodically fetch then). Note that the revocation server may have disabled SSE support, and (forward) proxies sitting between the current server and the revocation server may break SSE channels. If enabled, it should always be tested that it works.
-
-Note that the `RevocationServer` URL from the credential type must point to a publically reachable IRMA server with `server` enabled for the credential type. This IRMA server must be online at all times. It does not need to have `authority` enabled (if not, the issuer will need at least one other server for which `authority` is enabled, as only those servers can write to the revocation chain).
-
-The example IRMA server configuration above is the minumum setup enabling revocation for `irma-demo.MijnOverheid.root`, with one server handling everything. A more elaborate setup could be as follows (using schematic example URLs without `https://`).
-
-| URL | Public | Configuration |
-|----------|--------|------------------------------------------------------------------|
-| `issuer` | yes | `{"revocation_server_url": "auth"}` |
-| `rs` | yes | `{"server": true, "revocation_server_url": "auth", "sse": true}` |
-| `auth` | no | `{"authority": true}` |
-
-The middle column indicates whether or not the server needs to be publically reachable. This setup assumes that `rs` and `auth` use distinct SQL databases. The URL of `rs` must be included as the `RevocationServer` in the scheme. Enabling `sse` in `rs` ensures its revocation state remains up to date with the authority `auth`. This setup avoids that the issuance record endpoint and revocation endpoint are exposed to the internet, and also allows scaling `rs` to multiple instances to share the load if required.
-
-### Issuance
-
-When issuing a revocation-enabled credential to a user, the issuer includes a `revocationKey` for each credential in the session request. For example:
-```json
-{
- "@context": "https://irma.app/ld/request/issuance/v2",
- "credentials": [{
- "credential": "irma-demo.MijnOverheid.root",
- "attributes": { "BSN": "12345" },
- "revocationKey": "bsn-12345"
- }],
-}
-```
-
-The state that would be needed during revocation (in particular, the revocation attribute of this credential) is stored in the database with the `revocationKey` acting as primary key: when later this credential needs to be revoked the issuer can refer to it out of all issued credentials using its `revocationKey`.
-
-Note that the issuance IRMA server must be [configured](#revocation-settings) with the URL to the authoritative revocation server.
-
-### Disclosure
-
-Requestors can request nonrevocation proof for a given credential type by including it in the new `revocation` array in the session request:
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "irma-demo.MijnOverheid.root.BSN" ]]],
- "revocation": [ "irma-demo.MijnOverheid.root" ]
-}
-```
-This instructs the IRMA server to only accept the attributes if the app includes a valid nonrevocation proof for all instances of `irma-demo.MijnOverheid.root` out of which it discloses attributes. If a credential type is not listed there and the app has a revocation-enabled credential of that type, then it will not include a nonrevocation proof.
-
-Since attribute disclosures can occur during [any of the three session types](session-requests.md#disclosure-requests) (disclosure, attribute-based signatures, issuance), the `revocation` key can be included in the session requests of any type.
-
-The IRMA server of the requestor obtains new revocation update messages from the `RevocationServer` specified in the credential type in the scheme in one of two possible ways: either through a Server Sent Events channel so that the server is always up to date, or by periodically fetching. Either way, when the IRMA app connects to the IRMA server (e.g. after scanning the QR code), for each credential type of which nonrevocation proofs are requested in the session request, the server looks up in its own memory or database (1) the last accumulator that it knows and (2) a certain amount of the most recent update messages, and it includes these in the session request that it sends to the IRMA app.
-
-The server will accept the nonrevocation proof of the app if the proof is valid against either the accumulator that it included in the session request, or a newer one. The app always includes the accumulator against which it proved nonrevocation with the nonrevocation proof, so that during verification it is never necessary to retrieve accumulators from the issuer; by including the accumulator the response of the app contains all information required to verify it.
-
-When reporting verified attributes for which the app proved nonrevocation to the requestor at the end of the session, the corresponding entry in the [`SessionResult`](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult) might look as follows.
-
-```json
-{
- "disclosed": [
- [
- {
- "rawvalue": "299792458",
- "id": "irma-demo.MijnOverheid.root.BSN",
- "status": "PRESENT",
- "issuancetime": 1583366400,
- "notrevoked": true
- }
- ]
- ]
-}
-```
-The `notrevoked` boolean indicates that the app proved nonrevocation of this attribute.
-
-The IRMA app proves nonrevocation against a certain accumulator which it includes in its response to the IRMA server. The verifying IRMA server determines which accumulator this must be when the app first connects to it, by choosing the latest one that it knows of and sending it to the app in the session request.
-
->The nonrevocation guarantee inferrable from an IRMA app's nonrevocation proof lasts only until the creation time of the accumulator used by the app.
-
-If the age of the accumulator is greater than a configurable value called `tolerance` (see [above](#revocation-settings)), then this age will be reported alongside `notrevoked` (which remains `true`). This can happen in the following cases:
-* The IRMA app user took longer over deciding whether or not to perform the session than the `tolerance`;
-* The issuer's revocation IRMA server is offline and no updates can be retrieved.
-
-When signing the newest accumulator the issuer always includes the current time, and as mentioned earlier, when disclosing attributes (or when constructing an attribute-based signature), the IRMA app includes the accumulator against which it proves nonrevocation in its disclosure (or attribute-based signature). In case of signatures, this means that by checking that the accumulator time is sufficiently close to the time in the timestamp of the signature, it can be established that the attributes were not revoked at the moment the attribute-based signature was created. The attribute-based signature by itself is sufficient to establish this; i.e., it is not necessary to contact either the issuer or timestamp server during verification.
-
-If during disclosure the requestor asks for a nonrevocation proof of a given credential type, but the app only posesses credentials of that type that do not support revocation (i.e., no witnesses were included with them during issuance), then the app will abort as it is not able to fulfill the requestor's request.
-
-IRMA apps can disclose attributes out of revocation-aware credentials even to non-revocation aware IRMA servers. In this case only knowledge of the revocation attribute $e$ is proved.
-
-### Revocation
-
-The API that the IRMA server exposes for revoking previously issued credentials is similar to the API for starting and managing IRMA sessions:
-* A new revocation endpoint is available as a function on the [`irmaserver` Go library](irma-server-lib.md), and as a corresponding HTTP endpoint in the `irma server`.
-* Similar to session request data structures, (e.g. [`DisclosureRequest`](https://godoc.org/github.com/privacybydesign/irmago#DisclosureRequest)), revocation is initiated at the `irma server` by a [`RevocationRequest`](https://godoc.org/github.com/privacybydesign/irmago#RevocationRequest) data structure identified as such by a [JSON-LD](https://json-ld.org/) `@context` tag (having constant value `https://irma.app/ld/request/revocation/v1`).
-* As with ordinary session requests, when the `no-auth` setting is disabled in the `irma server` configuration this request has to be authenticated using one of the [existing authentication methods](irma-server.md#requestor-authentication) (i.e., by including a preshared `token` in an HTTP header or by signing the request into a JWT using `hmac` or `publickey`).
-* Each requestor configured in the `irma server` can be endowed with permission to revoke specific credential types (possibly in addition to [permissions to issue or verify attributes](irma-server#permissions)). If `no-auth` is disabled, and the revocation request can be succesfully authenticated as originating from a requestor present in the `irma server` configuration, and that requestor is authorized to revoke the credential type mentioned in the request, then the revocation command is executed and the credential is revoked.
-
-For example, the following `RevocationRequest` instructs the server to revoke the `irma-demo.MijnOverheid.root` instance to which it previously assigned `bsn-12345` as `revocationKey` during issuance, and which was issued at Unix nano timestamp `1583765731750425000`. If `issued` is not specified, all previously issued credentials with matching `revocationKey` are revoked.
-
-```json
-{
- "@context": "https://irma.app/ld/request/revocation/v1",
- "type": "irma-demo.MijnOverheid.root",
- "revocationKey": "bsn-12345",
- "issued": 1583765731750425000
-}
-```
-
-## Cryptography
-
-The IRMA issuer private key is $(p', q')$ where $p', q'$ are both [safe primes](https://en.wikipedia.org/wiki/Safe_prime): if written as $p' = 2p+1$ and $q' = 2q+1$, then $p$ and $q$ are also prime. The issuer uses this private key for issuing attributes as well as for revoking. The corresponding IRMA issuer public key contains the modulus $n = p'q'$. This modulus defines the group $QR_n = ((\mathbb{Z}/n\mathbb{Z})^*)^2$ of quadratic residues within the multiplicative integers modulo $n$, in which both the Idemix and the revocation cryptography takes place. For signing various revocation related messages the issuer additionally generates an ECDSA private/public keypair. These are included in the existing IRMA private/public keys.
-
-### Issuance
-The current accumulator is a number $\nu \in QR_n$. The first accumulator is randomly chosen by the issuer from $QR_n$. During issuance, the issuer
- 1. generates a prime $e$,
- 2. embeds the prime $e$ as an attribute within the credential being issued,
- 3. uses its private key to compute $u = \nu^{1/e\bmod pq}$, and sends the tuple $(u,e)$ to the app along with the credential,
- 4. stores the number $e$ in a database for later revocation.
-
-### Disclosure
-The revocation witness is the tuple $(u, e)$. By definition it is valid only if $u^e = \nu \bmod n$. When using revocation, the app now proves the following to the verifier:
-* "I possess a valid credential containing the disclosed attributes as well as an undisclosed attribute $e$."
-* "I know a number $u$ which is such that $u^e = \nu \bmod n$."
-
-The app proves this in zero-knowledge, meaning that the verifier can infer nothing from this proof except the above two facts. In particular, the proof hides the undisclosed attributes as well as $u$ and $e$. This provides unlinkability, as it ensures that a later session using the same credential and same witness cannot be linked to earlier ones (before or after the credential has been revoked). From the fact that the witness is valid, the verifier infers that the witness's credential is not revoked.
-
-The app includes the accumulator $\nu$ signed by the issuer against which it proved nonrevocation with its nonrevocation proof. The verifier accepts if this included accumulator is validly signed by the issuer; if the nonrevocation proof is valid against that accumulator; and if the accumulator is the same or newer than its own copy.
-
-### Revocation
-Henceforth, we label the current accumulator and witnesses with an index $i$, so the current accumulator value is $\nu_i$. If the issuer wants to revoke a credential it first looks up in its database the revocation attribute $\tilde{e}$ that it used for that credential (we use a tilde to distinguish this $\tilde{e}$ from the revocation attributes $e$ of other apps wanting to update their own (nonrevoked) witness, see below). Then it uses its private key to compute the new accumulator value as follows:
-
- $\displaystyle \nu_{i+1} = \nu_{i}^{1/\tilde{e}\bmod pq}$
-
-The update message consists of $(\nu_{i+1}, \tilde{e})$; the issuer signs this using its ECDSA private key and then offers it to others using an HTTP API. Apps and requestors only use update messages if it is validly signed, confirmed using the ECDSA public key of the issuer of the credential type.
-
-Apps having a (nonrevoked) credential with witness $(u_i, e)$ (satisfying $u_i^{e} = \nu_i$) first compute the numbers $a, b$ which are such that $ae + b\tilde{e} = 1$, using the [Extended Euclidean algorithm](https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm), and then they update their witness as follows:
-
- $\displaystyle u_{i+1} = u_i^b\nu_{i+1}^a$
-
-This is valid against the new accumulator $\nu_{i+1}$:
-
-
-$
- \begin{eqnarray*}
- u_{i+1}^{e}
- &=& (u_i^b\nu_{i+1}^a)^{e}
- = u_i^{be}\nu_{i+1}^{ae} \\
- &=& \nu_i^{b}\nu_{i}^{ae/\tilde{e}}
- = (\nu_i^{b\tilde{e}}\nu_{i}^{ae})^{1/\tilde{e}}
- = (\nu_i^{b\tilde{e}+ae})^{1/\tilde{e}} \\
- &=& \nu_i^{1/\tilde{e}}
- = \nu_{i+1}
- \end{eqnarray*}
-$
-
-
-(The $\bmod n$ after each equality sign is implied.) The revoked credential having revocation attribute $\tilde{e}$ cannot use this algorithm and update message $(\nu_{i+1}, \tilde{e})$ to compute a new witness, as in this case there exist no integers $a, b$ such that $a\tilde{e} + b\tilde{e} = 1$. In fact, [one can prove that](http://static.cs.brown.edu/people/alysyans/papers/camlys02.pdf) knowing only $\nu_i$, $\nu_{i+1} = \nu_{i}^{1/\tilde{e}}$ and $\tilde{e}$, by the [Strong RSA assumption](https://en.wikipedia.org/wiki/Strong_RSA_assumption) which is used by both Idemix and the RSA-B accumulator scheme, *no* efficient algorithm can compute the correct witness $u_{i+1} = \nu_{i+1}^{1/\tilde{e}} = \nu_{i}^{1/\tilde{e}^2}$.
-
-Thus the app owning the revoked credential has no way to compute a new witness on its own without the issuer private key. Since the app no longer posesses a valid witness, it can no longer prove that it does, i.e., construct a nonrevocation proof: the credential is revoked.
diff --git a/website/versioned_docs/version-v0.4.1/session-requests.md b/website/versioned_docs/version-v0.4.1/session-requests.md
deleted file mode 100644
index a46e620..0000000
--- a/website/versioned_docs/version-v0.4.1/session-requests.md
+++ /dev/null
@@ -1,451 +0,0 @@
----
-title: Session requests
-id: version-v0.4.1-session-requests
-original_id: session-requests
----
-
-
-
-Each [IRMA server](what-is-irma.md#irma-servers) exposes APIs for creating IRMA sessions with a session request. An *IRMA session request* contains all information required for the IRMA server and [IRMA app](https://github.com/privacybydesign/irma_mobile) to perform an IRMA session with, such as the attributes to be issued or verified. This page documents IRMA session requests. It applies to:
-
-* The [`POST /session`](api-irma-server.md#post-session) endpoint from [`irma server`](irma-server.md).
-* The [`StartSession()` function](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver#StartSession) in the `irmaserver` Go library.
-* The [`startSession()` function](api-irmajs.md#startsession) of `irmajs`.
-
-For the precise role of session requests in an IRMA session, see this [diagram of an IRMA session](what-is-irma.md#irma-session-flow).
-
-## Session request data types
-
-For each of the [three IRMA session types](what-is-irma.md#session-types), we define a *session request* data type: an object whose JSON representation contains at least a [JSON-LD `@context`](https://w3c.github.io/json-ld-syntax/#the-context) key identifying which message type it is, and extra keys specific to the session type. The following three `@context` values identify disclosure, attribute-based signature, and issuance session requests respectively:
-
-* `"@context": "https://irma.app/ld/request/disclosure/v2"`
-* `"@context": "https://irma.app/ld/request/signature/v2"`
-* `"@context": "https://irma.app/ld/request/issuance/v2"`
-
-(For now these URIs do not resolve to anything; they just distinguish the message type.)
-
-## Disclosure requests
-Disclosure sessions are started with an [`irma.DisclosureRequest`](https://godoc.org/github.com/privacybydesign/irmago#DisclosureRequest). Example:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.MijnOverheid.root.BSN" ]
- ],
- [
- [
- "irma-demo.nijmegen.address.street",
- "irma-demo.nijmegen.address.houseNumber",
- "irma-demo.nijmegen.address.city"
- ],
- [
- "irma-demo.idin.idin.address",
- "irma-demo.idin.idin.city"
- ]
- ]
- ]
-}
-```
-
-```golang
-// Create a new empty request
-request := irma.NewDisclosureRequest()
-
-// Request specific attributes
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.root.BSN")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.nijmegen.address.street"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.houseNumber"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.city"),
- },
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.idin.idin.address"),
- irma.NewAttributeRequest("irma-demo.idin.idin.city"),
- },
- },
-}
-```
-
-
-
-
-This asks for a (demo) `BSN` attribute, as well as either `street`, `houseNumber` and `city` from `irma-demo.nijmegen.address`, or `address` and `city` from `irma-demo.idin.idin`. The three levels correspond to a *conjunction* of *disjunctions* of *conjunctions* of requested attributes, allowing verifiers to request multiple attribute sets from the user, offering choices for some or all of these sets.
-
-All of the attribute types (i.e., the string values) contained in the request must exist in their scheme ([`irma-demo`](https://github.com/privacybydesign/irma-demo-schememanager) in the example above). For the `irma-demo` and `pbdf` schemes, an index of existing attribute types that can be requested can be found [here](https://privacybydesign.foundation/attribute-index/en/).
-
-> Attributes can be disclosed to the requestor in any of the three session types: in issuance sessions issuance proceeds only if the user discloses the required attributes just before issuance, and in attribute-based signature sessions the requested attributes are attached to the resulting attribute-based signature. Thus the `disclose` and `labels` fields introduced above can also occur in issuance or attribute-based signature session requests (see below).
-
-### Multiple credential types within inner conjunctions
-In the request above 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).
-- 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 IRMA app automatically only offers candidate sets as choices to the user that satisfy this property.)
-
-For example, consider the following session request:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- "pbdf.pbdf.diploma.degree",
- "pbdf.pbdf.diploma.institute"
- ]
- ]
- ]
-}
-```
-
-```golang
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("pbdf.pbdf.diploma.degree"),
- irma.NewAttributeRequest("pbdf.pbdf.diploma.institute"),
- },
- },
-}
-```
-
-
-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.)
-
-When combining multiple credential types within a disjunction these restrictions ensure that when the IRMA app computes candidate attribute sets for the user to choose from, the amount of resulting options stays manageable. In adddition, the second restriction is a feature on its own, allowing verifiers to request multiple attributes coming from one credential instance.
-
-### Requesting specific attribute values
-Within inner conjunctions, specific attribute values can be requested by replacing the string with an object like the following:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "pbdf.pbdf.diploma.degree", "value": "PhD" },
- { "type": "pbdf.pbdf.diploma.institute", "value": null }
- ]
- ]
- ]
-}
-```
-
-```go
-phd := "PhD"
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.degree"),
- Value: &phd,
- }, {
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.institute"),
- Value: nil,
- }},
- },
-}
-```
-
-
-This would only be satisfied by a `degree` attribute whose value is `PhD`, together with any `institute` attribute. (Note that the object and string syntaxes can be mixed within an inner conjunction, i.e. it would be permissible in the JSON example above to replace the second object with just `"pbdf.pbdf.diploma.institute"`.)
-
-### Null attributes
-
-Whenever an attribute is marked with `optional` in the scheme ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)), the issuer may skip it when it issues an instance of the containing credential type, assigning a `null` value to it (which is distinct from the empty string `""`). When disclosing the attribute, the verifier receives `null` instead of a string containing the attribute value.
-
-If a non-null attribute is required this can be requested using `notNull` as follows:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "irma-demo.MijnOverheid.fullName.prefix", "notNull": true }
- ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("irma-demo.MijnOverheid.fullName.prefix"),
- NotNull: true,
- }},
- },
-}
-```
-
-
-The default value of `notNull` is `false`.
-
-### Optional disjunctions
-
-A disjunction within a session request can be marked as *optional*, by including an empty inner conjunction in it:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.nijmegen.address.city" ]
- ],
- [
- [],
- [ "irma-demo.MijnOverheid.fullName.firstname" ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.nijmegen.address.city")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{},
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.fullName.firstname")},
- },
-}
-```
-
-
-
-
-This can be useful when certain attributes are not required, so that if the user does not have them the session does not need to be aborted.
-
-### Disjunction labels
-
-Per disjunction a *label* can be specified, which is shown in the IRMA app when the user is asked for permission to disclose attributes. For example, the session request from [above](#disclosure-requests) could be augmented with a label for the second disjunction as follows:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [ ... ],
- [ ... ]
- ],
- "labels": {
- "1": { "en": "Work address", "nl": "Werk adres" }
- }
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Labels = map[int]irma.TranslatedString{
- 1: {"en": "Work address", "nl": "Werk adres"},
-}
-```
-
-
-
-
-In this way each disjunction can be given a optional label explaining to the user the purpose of the disjunction. It is recommended to only provide a label to explain something to the user that would otherwise not be obvious; for example, to request the user to send a work email address instead of a personal one. Repeating the credential or attribute name or description in labels is an antipattern.
-
-## Attribute-based signature requests
-Attribute-based signature sessions are started with an [`irma.SignatureRequest`](https://godoc.org/github.com/privacybydesign/irmago#SignatureRequest), which are similar to disclosure requests:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/signature/v2",
- "message": "Message to be signed by user",
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-request := irma.NewSignatureRequest("Message to be signed by user")
-request.Disclose = irma.AttributeConDisCon{ /* request attributes to attach to ABS */ }
-request.Labels = map[int]irma.TranslatedString{}
-```
-
-
-The `message` field is required. The attributes to be attached to the attribute-based signature are requested with the `disclose` field, which along with the `labels` field work exactly like in disclosure sessions.
-
-## Issuance requests
-Issuance sessions are started with an [`irma.IssuanceRequest`](https://godoc.org/github.com/privacybydesign/irmago#IssuanceRequest). Example:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/issuance/v2",
- "credentials": [{
- "credential": "irma-demo.MijnOverheid.ageLower",
- "validity": 1592438400,
- "attributes": {
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no"
- }
- }],
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-validity := irma.Timestamp(time.Unix(1592438400, 0))
-request := irma.NewIssuanceRequest([]*irma.CredentialRequest{
- {
- CredentialTypeID: irma.NewCredentialTypeIdentifier("irma-demo.MijnOverheid.ageLower"),
- Validity: &validity, // optional
- Attributes: map[string]string{
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no",
- },
- },
-})
-request.Disclose = irma.AttributeConDisCon{} // optional
-request.Labels = map[int]irma.TranslatedString{} // optional
-```
-
-
-Per credential in the `credentials` array the `validity` is optional; if skipped it is assigned the default value of 6 months. If present, the validity is always rounded down to the [nearest epoch boundary](overview.md#special-attributes), which is one week (60 * 60 * 24 * 7 = 604800 seconds).
-
-Attributes marked as `optional` in the containing credential type ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)) may be skipped in the `attributes` map. This issues [the `null` value](#null-attributes) to these attributes.
-
-`disclose` and `labels` are optional, allowing for *combined disclosure-issuance sessions*, in which the user is required to disclose attributes before the IRMA server will issue the credentials.
-
-The `clientReturnUrl` option can also be used, both for issuance only and combined disclosure-issuance sessions. Usage is similar as in [disclosure sessions](#client-return-url).
-
-## Client return URL
-If the user performs a mobile session, i.e. on the same device as where the IRMA app is installed on, then after the session has completed the user will be redirect to the `clientReturnUrl` specified in the session request, if present.
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- ...
- ],
- "clientReturnUrl": "https://privacybydesign.foundation"
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.ClientReturnURL = "https://privacybydesign.foundation"
-```
-
-
-The example shows a disclosure request but `clientReturnUrl` can be set on session requests of any type. If set, when the user finishes a session (either successfully or unsuccessfully), she is redirected to the location specified by `clientReturnUrl`.
-
-If *not* set:
-* On Android the IRMA app automatically toggles back to the previous app;
-* On iOS it is not possible to toggle back to the previous app due to restrictions by Apple, so the IRMA app stays open. In the top left corner of the screen, however, a button appears that leads back to the previous app.
-
-This URL does not necessarily have to be a web URL; it can also be a universal link to another app. Universal links work both on Android and iOS. It is also possible to use iOS or Android scheme URLs. (Note however that iOS and Android scheme URLs differ from one another, so when starting a session with a scheme URL as return URL you should therefore determine on which platform the user's app is running.)
-
-On iOS, toggling back to the calling app or website after the session can be simulated by navigating towards the calling app using a `clientReturnUrl`, either a normal URL or universal link. This works on Android as well, so currently this is the only platform-independent way of ensuring that the used ends up at a specified place after the session. If the URL opens a website, however, then the user is navigated towards a new browser tab instead of back to an existing browser tab, so in website-IRMA-website flows you will need to reload your webapp and state in the newly opened tab.
-
-## Extra parameters
-For each API that accepts one of the above session request data types, the requestor can provide additional parameters to configure the session at the IRMA server, by providing an *extended session request* instead, as follows:
-
-
-```json
-{
- "validity": 120,
- "timeout": 120,
- "callbackUrl": "https://example.com",
- "request": ...
-}
-```
-
-```go
-// See also corresponding types irma.SignatureRequestorRequest
-// and irma.IdentityProviderRequest
-irma.ServiceProviderRequest{
- irma.RequestorBaseRequest{
- ResultJwtValidity: 120,
- ClientTimeout: 120,
- CallbackUrl: "https://example.com",
- },
- irma.NewDisclosureRequest(),
-}
-```
-
-
-## JWTs: signed session requests
-The IRMA API server or [`irma server`](irma-server.md) can be configured such that it only accepts session requests that have been digitally signed in the form of a [JWT](https://jwt.io). The form of the JWT depends on the [session type](what-is-irma.md#session-types). An example requesting [IRMATube](https://privacybydesign.foundation/demo/irmaTube) attributes::
-```
-eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImlybWF0dWJlIn0.eyJpYXQiOjE1NjQ2NTczNzUsInN1YiI6InZlcmlmaWNhdGlvbl9yZXF1ZXN0Iiwic3ByZXF1ZXN0Ijp7InJlcXVlc3QiOnsiQGNvbnRleHQiOiJodHRwczovL2lybWEuYXBwL2xkL3JlcXVlc3QvZGlzY2xvc3VyZS92MiIsImRpc2Nsb3NlIjpbW1sicGJkZi5wYmRmLmlybWF0dWJlLnR5cGUiXV0sW1sicGJkZi5wYmRmLmFnZUxpbWl0cy5vdmVyMTIiXSxbInBiZGYuZ2VtZWVudGUucGVyc29uYWxEYXRhLm92ZXIxMiJdXV19fX0.lW9mqjrLkoahDP6Fcw_9mH5hlfl1tq5qp3W3ga0Nrd_j0NXFj-6ngqHVXEV1zhC_OkVH4LN8fMBAgN8nqaFWgEdQvrCuB7-ynuBVjLR-QU272Ym86zLEWYggAkbZ5KY40MpTxU1dgFMucG7fyAESic04OribWOCVxstAMsM28yCxvzkBMCOSjFEe3abcg_N6VvQnLn3LgZP_UrxQmQsh4DK7mBjW04LesLG1vjcliyhDGUb52FHOP_NAsG7G2FvIgojPzALlPrpTMu5p8a95wc5CGR791wybmh0F8kDdwZWAU0W2FjlX5bNPsyXN8AxRVWaRmWoGrGsQhy_sKEf8lg
-```
-In case of disclosure sessions, the body of the JWT (the part in between the two dots) contains a Base64-encoding of the following:
-
-
-```json
-{
- "iat": 1550424847,
- "sub": "verification_request",
- "sprequest": ...
-}
-```
-
-```go
-// Sets iat, iss, and sub fields.
-// See also corresponding functions irma.NewSignatureRequestorJwt()
-// and irma.NewIdentityProviderJwt().
-// Obtain signed JWT string to POST to an irma server using Sign() method.
-irma.NewServiceProviderJwt("IRMATube", irma.NewDisclosureRequest())
-```
-
-
-The fields are as follows:
-* `iat`: Unix timestamp of the creation date of the JWT. IRMA servers may reject JWTs beyond a certain age.
-* `iss`: contains the requestor name, and is used by the IRMA server to lookup the appropriate key with which to verify the JWT.
-* `sub`: JWT subject, in case of disclosure sessions this must always be `"verification_request"`.
-* `sprequest`: contains an extended disclosure session request as defined above.
-
-For each possible session type, the contents of the `sub` field and the name of the field containing the session request must be as follows.
-
-| Session type | `sub` contents | Session request field name | Go function |
-| ------------ | -------------- | -------------------------- | ----------- |
-| Disclosure | `verification_request` | `sprequest` | `irma.NewServiceProviderJwt()` |
-| Attribute-based signature | `signature_request` | `absrequest` | `irma.NewSignatureRequestorJwt()` |
-| Issuance | `issue_request` | `iprequest` | `irma.NewIdentityProviderJwt()` |
-
-Currently the following libraries can produce JWTs of this form:
-* The [`irmago`](https://godoc.org/github.com/privacybydesign/irmago) library, using the mentioned functions
-* The [`irmajs`](irmajs.md) Javascript library
-* The [`irma-requestor`](https://github.com/privacybydesign/irma-requestor) PHP library
-* The [`irma_api_common`](https://github.com/privacybydesign/irma_api_common) Java library
-* The [`irma-diva-js`](https://github.com/Alliander/diva-irma-js) Javascript library
-
-`irma server` currently supports JWTs signed (asymmetrically with RSA) with the `RS256` algorithm, and (symmetrically signed with HMAC-SHA256) `RS256`. The IRMA API server only supports `RS256`.
diff --git a/website/versioned_docs/version-v0.4.1/what-is-irma.md b/website/versioned_docs/version-v0.4.1/what-is-irma.md
deleted file mode 100644
index 91ace09..0000000
--- a/website/versioned_docs/version-v0.4.1/what-is-irma.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: What is IRMA?
-id: version-v0.4.1-what-is-irma
-original_id: what-is-irma
----
-
-IRMA is a set of free and open source software projects implementing the Idemix attribute-based credential scheme, allowing users to safely and securely authenticate themselves as privacy-preserving as the situation permits. Users receive digitally signed attributes from trusted issuer, storing them in their IRMA app, after which the user can selectively disclose attributes to others. Schematically:
-
-
-
-
-
-
-Using the issuer's digital signature over the attributes the verifier can verify that the attributes were given to the user in the past, and that they have not been modified since.
-
-## IRMA session flow
-
-A typical IRMA session is depicted schematically below.
-
-![IRMA session flow](assets/irmaflow.png)
-
-Software components:
-* *Requestor backend and frontend*: Generally the requestor runs a website with a (JavaScript) frontend in the user's browser, and a backend server. During an IRMA session the frontend displays the IRMA QR that the IRMA app scans. All frontend tasks depicted in the diagram are supported by [`irmajs`](irmajs.md).
-* [*IRMA server*](#irma-servers): Handles IRMA protocol with the IRMA app for the requestor.
-* [*IRMA mobile app*](https://github.com/privacybydesign/irma_mobile): [Android](https://play.google.com/store/apps/details?id=org.irmacard.cardemu), [iOS](https://itunes.apple.com/nl/app/irma-authentication/id1294092994).
-
-Explanation of the steps:
-
-1. Usually the session starts by the user performing some action on the website (e.g. clicking on "Log in with IRMA").
-1. The requestor sends its [session request](session-requests.md) (containing the attributes to be disclosed or issued, or message to be signed) to the [IRMA server](#irma-servers). Depending on its configuration, the IRMA server accepts the session request only if the session request is authentic (e.g. a validly signed [session request JWT](session-requests.md#jwts-signed-session-requests)) from an authorized requestor.
-1. The IRMA server accepts the request and assigns a session token (a random string) to it. It returns the contents of the QR code that the frontend must display: the URL to itself and the session token.
-1. The frontend ([`irmajs`](irmajs.md)) receives and displays the QR code, which is scanned by the IRMA app.
-1. The IRMA app requests the session request from step 1, receiving the attributes to be disclosed or issued, or message to be signed.
-1. The IRMA server returns the session request.
-1. The IRMA app displays the attributes to be disclosed or issued, or message to be signed, and asks the user if she wants to proceed.
-1. The user accepts.
-1. The IRMA server performs the IRMA protocol with the IRMA app, issuing new attributes to the user, or receiving and verifying attributes from the user's IRMA app, or receiving and verifying an attribute-based signature made by the user's app.
-1. The session status (`DONE`, `CANCELLED`, `TIMEOUT`), along with disclosed and verified attributes or signature depending on the session type, are returned to the requestor.
-
-Additional notes:
-
-* Which of these tasks are performed by the requestor's backend and which by its frontend differs case by case:
- - Often the session request is sent to the IRMA server by the requestor's backend, after which the IRMA server's reply in step 2 is forwarded to the frontend which renders it as a QR code. Step 1 can however also be done by `irmajs`, in which case `irmajs` automatically picks up the IRMA server's reply in step 2 and renders the QR code.
- - Similarly, `irmajs` can be instructed to fetch the session result in step 10, but this can also be done in the backend.
-* The IRMA server could be deployed on the same machine as the requestor's backend, but it need not be; possibly it is not even controlled by the requestor. In case the [`irmaserver`](irma-server-lib.md) library is used, steps 2/3 and 10 are function calls.
-
-## Session types
-
-In an IRMA session, the [IRMA mobile app](https://github.com/privacybydesign/irma_mobile) performs one of the following three *session types* with an [*IRMA server*](#irma-servers):
-
-* *Disclosure sessions*: Upon receiving a list of requested attributes from the IRMA server, the app discloses the required attributes to the IRMA server if the app user agrees, after which they are verified by the IRMA server.
-* *Attribute-based signature sessions*: Similar to disclosure sessions, but the attributes are attached to a message digitally signed into an [*attribute-based signature*](overview.md#attribute-based-signatures). The attribute-based signature can be verified at any later time, ensuring that the signed message is intact, and that the IRMA attributes attached to it were valid at the time of creation of the attribute-based signature.
-* *Issuance sessions*: the IRMA app receives a new set of IRMA attributes including valid issuer signatures from the IRMA server, to use in later disclosure or attribute-based signature sessions. (Possibly the user is asked to disclose some attributes as well, within the same IRMA session, before receiving the new attributes. This is called a *combined issuance-disclosure session*.)
-
-This process is depicted schematically and explained in more detail [here](what-is-irma.md#irma-session-flow). For the user, after scanning the QR in his/her IRMA app a disclosure session generally looks like the following. (Attribute-based signature sessions and issuance sessions are identical in terms of their flow (scan qr, provide permission, success screen); only the graphical interface is different.)
-
-
-
-
-
-
-## IRMA servers
-
-Various existing software components documented on this website can perform the role of the IRMA server.
-Apart from exposing an API that is used by the IRMA app during IRMA sessions, each of these components also offer an API with which IRMA sessions can be started and monitored, for use by the [*requestor*](overview.md#participants): the party wishing to issue attributes to or verify attributes from an IRMA app. The IRMA server handles the IRMA session with the IRMA app for the requestor.
-
-Currently the following IRMA servers exist:
-
-* The `irma server` command of the [`irma`](irma-cli.md) binary: a standalone daemon exposing its requestor API as HTTP endpoints. [Documentation](irma-server.md); [API reference](api-irma-server.md).
-* The `irmaserver` Go library, exposing a HTTP server that handles IRMA sessions with the IRMA app, and Go functions for starting and managing IRMA sessions. [Documentation](irma-server-lib.mdrary); [API reference](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver).
-* The now deprecated [`irma_api_server`](https://github.com/privacybydesign/irma_api_server).
-
-## About this documentation
-
-IRMA uses JSON to pass messages within IRMA sessions. The majority of IRMA is [written in Go](https://github.com/privacybydesign/irmago), and the JSON messages generally correspond to specific Go structs. For example, the [`GET /session/{token}/result`](api-irma-server.md#get-session-token-result) endpoint of the [`irma server`](irma-server.md) outputs instances of the [`server.SessionResult`](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult). In such cases, a link to the corresponding Go struct will be included. This can tell you what fields you can use or expect. (Note that some structs have custom (un)marshalers. See also the [Go documentation](https://blog.golang.org/json-and-go) on JSON and Go.)
diff --git a/website/versioned_docs/version-v0.5.0/api-irma-frontend.md b/website/versioned_docs/version-v0.5.0/api-irma-frontend.md
deleted file mode 100644
index 7def2cb..0000000
--- a/website/versioned_docs/version-v0.5.0/api-irma-frontend.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: IRMA frontend packages
-id: version-v0.5.0-api-irma-frontend
-original_id: api-irma-frontend
----
-
-The IRMA frontend packages consist of multiple packages. Therefore we describe the API per package.
-The API description of the IRMA frontend plugins is combined into one section.
-
-## IRMA core
-The [IRMA core](irma-frontend.md#irma-core) package only exports the `IrmaCore` class. To handle an IRMA session,
-an instance of this class can be made with the relevant options for your session. The options object is shared
-between all plugins that are registered at the `IrmaCore` instance. The plugins don't need to be configured
-individually. The options that can be specified depend on the specific plugins you are using. You can find all
-possible options in the READMEs of the plugins. You can find an overview of all available IRMA core plugins
-[here](#plugins).
-
-The IRMA core class has one constructor:
-```javascript
-const IrmaCore = require('@privacybydesign/irma-core');
-const irma = new IrmaCore({/* Options */});
-```
-
-Below you can find an overview of all methods an IRMA core instance offers you.
-
-| Method | Functionality |
-|---|---|
-| `use(/* Plugin*/)` | With this method plugins can be added to the IRMA core instance. This method takes care of instantiating the plugin. You simply pass the plugin class as an argument to this function; you must not instantiate the plugin yourself.|
-| `start()` | The start method activates the state machine. From then the IRMA core instance is ready to be used and no plugins can be added to the instance anymore. It returns a promise that resolves when a session is finished successfully and rejects when a unrecoverable error occurs. By calling IRMA core's `start` method, the plugins will be started too.|
-| `abort()` | The abort method forces an `irma-core` instance to abort the session and all associated plugins should stop making changes. In this way you can stop the instance from being active when it is not relevant anymore. If a promise returned by the `start` method is still active, the promise will be rejected with error message `Aborted`.|
-
-For an example of how the IRMA core API can be used, you can also check the [usage guide](irma-frontend.md#usage-guide).
-
-## IRMA frontend
-[IRMA frontend](irma-frontend.md#irma-frontend) is a wrapper
-package around IRMA core combined with several of its plugins and the default [`irma-css`](irma-frontend.md#irma-css)
-styling. The package can only be used in web browser environments.
-
-It exports two functions:
-
-| Function | Functionality |
-|---|---|
-| `newWeb({/* Options */})` | With this method an `IrmaCore` instance is initialized, using the given options, configured to control an embedded web element. The options that can be used are all options from [`irma-client`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client) and [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web).
-| `newPopup({/* Options */})` | With this method an `IrmaCore` instance is initialized, using the given options, configured to start a popup overlay. The options that can be used are all options from [`irma-client`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client) and [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-popup).
-
-Both functions return an interface with the following methods:
-
-| Method | Functionality |
-|---|---|
-| `start()` | Calls the `start` method of the initialized `IrmaCore` instance and returns the promise it gets as result.
-| `abort()` | Calls the `abort` method of the initialized `IrmaCore` instance.
-
-When importing this library via a `
-```
-as well as in Node or Webpack:
-```js
-// ES modules
-import * as irma from '@privacybydesign/irmajs';
-// CommonJS
-const irma = require('@privacybydesign/irmajs');
-```
-
-Its primary functions are [`startSession()`](#startsession), which can start an IRMA session by sending a (unsigned or JWT) [session request](session-requests.md) to an IRMA server, and [`handleSession()`](#handlesession), which given the output of `startSession()` handles the remainder of an IRMA session.
-
-Since version 0.2.0, `irmajs` is converted into a wrapper of [`irma-core`](irma-frontend.md#irma-core)
-and several [`irma-frontend-packages` plugins](irma-frontend.md#available-plugins-for-irma-core) that makes it
-backwards compatible with the `irmajs` API. This makes it possible to update to the `irma-frontend-packages` look and feel
-without having to change your software.
-
-## Deprecated API features
-Due to technical changes in IRMA, we had to make breaking changes when introducing version 0.2.0.
-All changes are related to the function call `handleSession`.
-* Method `canvas` is not supported anymore. Please use the module `irma-frontend` instead or make
- your own composition of plugins and layouts using `irma-core`.
- This also means the canvas related options `element` and `showConnectedIcon` are deprecated.
-* Method `mobile` has the same behaviour as method `popup` now. On mobile devices, the popup
- mode automatically detects whether a mobile device is used and then shows the user the option to open
- the [IRMA app](irma-app.md) installed on the mobile device itself. It is now an explicit choice, so users can also get
- a QR on mobile devices instead (useful for tablets).
-* The option `disableMobile` is not useful anymore. This module does not have
- automatic redirects to other apps anymore without explicit user interaction.
- The option is therefore deprecated.
-* Because the explicit methods for mobile devices are deprecated, the undocumented exported function `detectUserAgent`
- and the undocumented exported struct `UserAgent` are also deprecated. An explicit distinction based on user agent
- is not necessary anymore. This is all handled internally now.
-* The option `returnStatus` is deprecated. Instead you can use the functions `waitConnected` and `waitDone`
- to detect yourself whether the session reached a certain status.
-
-## API reference
-
-
-
----
-
-### `SessionStatus`
-A enum containing possible IRMA [session statuses](https://godoc.org/github.com/privacybydesign/irmago/server#Status), defined as follows:
-
-```js
-const SessionStatus = {
- Initialized: 'INITIALIZED', // The session has been started and is waiting for the client to connect (scan the QR)
- Connected : 'CONNECTED', // The client has retrieved the session request, we wait for its response
- Cancelled : 'CANCELLED', // The session is cancelled, possibly due to an error
- Done : 'DONE', // The session has completed successfully
- Timeout : 'TIMEOUT', // Session timed out
-};
-```
-
----
-
-### `handleSession()`
-
-```js
-irma.handleSession(qr, [options])
-```
-
-> Please check the [deprecated API features](#deprecated-api-features) to see which options are deprecated since version 0.2.0.
-
-Handle an IRMA session after it has been created at an IRMA server, given the QR contents obtained from the IRMA server (e.g. using [`startSession()`](#startsession)) to be sent to the [IRMA app](irma-app.md). This function can
-1. draw an IRMA QR,
-2. wait for the phone to connect,
-3. wait for the session to complete,
-4. retrieve the session result afterwards from the irma server.
-
-Returns a promise that can resolve at any of these phases, depending on the options:
-
-| Option | Default | Effect |
-|---|---|---|
-| `method` | `'popup'` | Supported methods: `'popup'`, `'canvas'`, `'mobile'` (only browser), `'console'` (only node), `'url'` (both) |
-| `element` | `'irmaqr'` | HTML `id` of the canvas to draw to if `method === 'canvas'` |
-| `language` | `'en'` | Popup language when `method === 'popup'` |
-| `showConnectedIcon` | `true` | When method is `'popup'` or `'canvas'`, replace QR with a phone icon when phone connects |
-| `returnStatus` | `SessionStatus.Done` | When the session reaches this status control is returned to the caller |
-| `server` | `''` | Server URL to fetch the session result when session is done. Implies `returnStatus === SessionStatus.Done` |
-| `token` | `''` | Session token required to fetch the session result when session is done |
-| `resultJwt` | `false` | Retrieve signed session result from the irma server |
-| `disableMobile` | `false` | Disable automatic navigation to IRMA app on mobile |
-
-The following `method`s are supported:
-* `popup`: Draw a popup overlay with the QR and a cancel button in it.
-* `canvas`: Draw the QR into the HTML `canvas` specified by the `element` option.
-* `mobile`: For mobile browsers, open the IRMA app directly instead of drawing a QR. Note that this mode is default when running `irmajs` in a mobile browser, even if you specify another method. You can disable this behavior and use your own `method` by setting `disableMobile` to true.
-* `console`: Draw the QR into the console.
-* `url`: Return the QR as a data URL (for in an `img` HTML tag). Implies `returnStatus = SessionStatus.Initialized`.
-
-What the promise returned by this function receives depends on the options as follows:
-* If the `server` and `token` options are not provided then the session status is returned.
-* If the `server` and `token` parameters are given, containing a URL to an IRMA server and the session token at the IRMA server, respectively, then the session result is retrieved from the IRMA server. In that case, the promise returned by this function receives one of the following:
- * If `resultJwt` is `false` (default), a [`SessionResult` message](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult) as returned by the [`GET /session/{token}/result`](api-irma-server.md#get-session-token-result) endpoint of the `irma server`.
- * Otherwise, a session result JWT as returned by the [`GET /session/{token}/result-jwt`](api-irma-server.md#get-session-token-result-jwt) endpoint of the `irma server`.
-
-If the session is not successful, an exception is thrown. If the session is cancelled or times out, the message will be `SessionStatus.Cancelled` or `SessionStatus.Timeout`.
-
-> The session is cancelled and receives status `SessionStatus.Cancelled` not only when the IRMA app user refuses, but also when the session is aborted due to an error. In each of these cases an exception is thrown. Check its error argument.
-
-> If the session is cancelled due to the user aborting, it is (by design) not possible to distinguish between (1) the user had the requested attributes but refused to disclose them, and (2) the session was aborted by the user's IRMA app because (s)he did not have the required attributes.
-
----
-
-### `startSession()`
-
-```js
-irma.startSession(server, request[, method, [key[, name]]])
-```
-
-Start an IRMA session at an IRMA server. This function supports all authentication methods of the `POST /session` endpoint of the `irma server`. It returns a promise with the response (the session QR contents) from the IRMA server (which can be handled by [`handleSession()`](#handlesession)).
-
-Parameters:
-* `server`: URL to IRMA server at which to start the session.
-* `request`: Session request, either a JWT or an [(extended) session request](session-requests.md) (see below).
-* `method`: authentication method (supported: `none`, `token`, `hmac`, `publickey`; default is `none`).
-* `key`: API token or JWT key.
-* `name`: name of the requestor (only for `hmac` and `publickey` mode).
-
-The authentication method is determined by the `request` and `method` parameters as follows.
-* If `request` is a `string` then it is posted as a [session request JWT](session-requests.md#jwts-signed-session-requests) to the IRMA server. In this case, the `method` parameter needs to be set appropriately (`hmac` or `publickey`).
-* Otherwise it should be an `object` containing an [(extended) session request](session-requests.md). How it is handled depends on `method`:
- * `none`: it is POSTed as JSON to the IRMA server (which must be configured to accept unauthorized session requests).
- * `token`: it is POSTed as JSON to the IRMA server along with the `key` parameter as an API token in a HTTP header.
- * `publickey`: it is first signed into a JWT with the specified RSA private `key` in PEM, using `name` as the requestor name, and then POSTed to the IRMA server.
- * `hmac`: it is first signed into a JWT with the specified symmetric HMAC `key`, using `name` as the requestor name, and then POSTed to the IRMA server.
-
----
-
-### `signSessionRequest()`
-```js
-signSessionRequest(request, method, key, name)
-```
-
----
-
-### `waitConnected()`
-```js
-waitConnected(url)
-```
-
----
-
-### `waitDone()`
-```js
-waitDone(url)
-```
diff --git a/website/versioned_docs/version-v0.5.0/condiscon.md b/website/versioned_docs/version-v0.5.0/condiscon.md
deleted file mode 100644
index 2fa6e68..0000000
--- a/website/versioned_docs/version-v0.5.0/condiscon.md
+++ /dev/null
@@ -1,195 +0,0 @@
----
-title: "Condiscon" session requests
-id: version-v0.5.0-condiscon
-original_id: condiscon
----
-
-
-
-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.
-- The [`irma` command](irma-cli.md) including [`irma server`](irma-server.md) (`0.3.0` and up supports condiscon).
-- The [IRMA app](irma-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) IRMA app, this looks as follows.
-
-
-
-
-
-```json
-{
- "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"
- ]
- }]
-}
-```
-
-
-"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:
-
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.MijnOverheid.root.BSN" ]
- ],
- [
- [
- "irma-demo.nijmegen.address.street",
- "irma-demo.nijmegen.address.houseNumber",
- "irma-demo.nijmegen.address.city"
- ],
- [
- "irma-demo.idin.idin.address",
- "irma-demo.idin.idin.city"
- ]
- ]
- ]
-}
-```
-
-```golang
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.root.BSN")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.nijmegen.address.street"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.houseNumber"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.city"),
- },
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.idin.idin.address"),
- irma.NewAttributeRequest("irma-demo.idin.idin.city"),
- },
- },
-}
-```
-
-
-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).
-- 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 IRMA app automatically only offers candidate sets as choices to the user that satisfy this property.)
-
-For example, consider the following condiscon session request:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- "pbdf.pbdf.diploma.degree",
- "pbdf.pbdf.diploma.institute"
- ]
- ]
- ]
-}
-```
-
-```golang
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("pbdf.pbdf.diploma.degree"),
- irma.NewAttributeRequest("pbdf.pbdf.diploma.institute"),
- },
- },
-}
-```
-
-
-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.)
-
-When combining multiple credential types within a disjunction these restrictions ensure that when the IRMA app computes candidate attribute sets for the user to choose from, the amount of resulting options stays manageable. In adddition, the second restriction is a new feature on its own, allowing verifiers to request multiple attributes coming from one credential instance.
-
-## Other features
-
-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 IRMA 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:
-
-
- ```json
- {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [],
- [ "pbdf.pbdf.diploma.degree" ]
- ]
- ]
- }
- ```
-
- ```golang
- request := irma.NewDisclosureRequest()
- request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{},
- irma.AttributeCon{irma.NewAttributeRequest("pbdf.pbdf.diploma.degree")},
- },
- }
- ```
-
- 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 IRMA 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).
-
-For full details, see the documentation of the [session request format](session-requests.md).
-
-## Compatibility
-
-The `irma server` of version `0.3.0` and up is:
-- Backwards compatible with the old session request format, i.e. with old IRMA requestor applications. New session request JSON objects are recognized as such by the presence of their `@context` property; if this is absent the request is interpreted as a pre-condiscon IRMA session request.
-- Backwards compatible with old IRMA apps, as long as the condiscon feature is not used in the session (i.e., all inner conjunctions contain exactly 1 attribute).
-- [This `irmago` unit test](https://github.com/privacybydesign/irmago/blob/condiscon/irmago_test.go#L259) shows how pre-condiscon session requests are converted, by asserting equality of pre- and post-condiscon session requests, for all three session types.
-- The documentation of the pre-condiscon session format can be found on the [session requests](/v0.2.0/session-requests) page.
-
-The new IRMA app is backwards compatible with the old session request format, i.e. with old `irma server`s, *except* in case of signature sessions (see below).
-
-## Signature sessions
-
-For attribute-based signatures, the condiscon version of the IRMA software brings another update that fixes the [following issue](https://github.com/privacybydesign/irmago/issues/35): if the scheme manager adds a new attribute to an existing credential type, then attribute-based signatures using attributes from that credential type that were created before the attribute was added would fail to verify by the IRMA server, due to the signature not incorporating the new attribute. In effect, adding a new attribute to an existing credential type would invalidate all attribute-based signatures previously made that contain attributes from that credential.
-
-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 IRMA 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 IRMA app is released (probably some weeks from now).
-
diff --git a/website/versioned_docs/version-v0.5.0/getting-started.md b/website/versioned_docs/version-v0.5.0/getting-started.md
deleted file mode 100644
index 6d8faf0..0000000
--- a/website/versioned_docs/version-v0.5.0/getting-started.md
+++ /dev/null
@@ -1,159 +0,0 @@
----
-title: Getting started
-id: version-v0.5.0-getting-started
-original_id: getting-started
----
-
-This page shows how to get started with verifying or issuing IRMA attributes, using the following components:
-
- * [`irma server`](irma-server.md), a server that verifies or issues IRMA attributes to [IRMA apps](irma-app.md),
- * [`irma-frontend`](irma-frontend.md), a JavaScript library for drawing the IRMA QR in your website, and handling IRMA session with the `irma server`.
-
-You should have the [IRMA app](irma-app.md) installed ([Android](https://play.google.com/store/apps/details?id=org.irmacard.cardemu), [iOS](https://itunes.apple.com/nl/app/irma-authentication/id1294092994)). If you want to compile from source instead of using prebuilt binaries, you should additionally have [Git](https://git-scm.com/), [Go](https://golang.org/doc/install), and [npm](https://docs.npmjs.com/cli/npm) installed.
-
-
-## Installing and running `irma server`
-You can install the `irma` command line tool in the following two ways.
-
-* **Download prebuilt binary**: From our [CI build server](https://gitlab.science.ru.nl/irma/github-mirrors/irmago/-/jobs/artifacts/master/download?job=binaries). Extract the zip file, and use the binary for your OS and architecture (most likely amd64). Rename the file to `/usr/local/bin/irma` to have it available in your PATH.
-* **Compile and install from source** as follows:
- ```shell
- git clone https://github.com/privacybydesign/irmago
- cd irmago
- go install ./irma
- ```
-
-After installing the `irma` binary, start the server (with increased verbosity but otherwise default configuration):
-```shell
-irma server -v
-```
-Run `irma server -h` to see configuration options. In order to verify your configuration, run `irma server check -v`. General documentation can be found on the [irma server](irma-server.md) page, API documentation of HTTP endpoints can be found on the [api irma server](api-irma-server.md) page.
-
-## Perform a command line IRMA session
-You can perform a first IRMA session using your server on the command line as follows:
-```shell
-irma session --server http://localhost:8088 --disclose pbdf.pbdf.irmatube.type
-```
-([IRMATube attributes](https://privacybydesign.foundation/attribute-index/en/pbdf.pbdf.irmatube.html) are available on the [IRMATube demo](https://privacybydesign.foundation/demo/irmaTube/)) page. This will print a QR that you can scan with your IRMA app, and the attribute contents after they have been received and verified by the server. `irma session` can also perform issuance sessions and attribute-based signature sessions. If you pass `-v` it logs the session request JSON that it sends to your `irma server`.
-
-
-## Installing an example webpage for `irma-frontend`
-Download the `irma-frontend-packages` source code, as [zip](https://github.com/privacybydesign/irma-frontend-packages/archive/master.zip) from GitHub, or using git:
-```shell
-git clone https://github.com/privacybydesign/irma-frontend-packages && cd irma-frontend-packages
-```
-
-Examples for the browser and for nodejs are included in the `examples` folder. In this guide we will use the `irma-frontend` example for browsers to realize the example webpage. This example has to be installed first.
-```shell
-cd examples/browser/irma-frontend/
-npm install
-npm run build
-```
-
-## Perform browser IRMA session
-
-(Re)start your `irma server`, configuring it such that it statically hosts the `irma-frontend` example webpage we just built:
-```shell
-irma server -v --static-path ~/irma-frontend-packages/examples/browser/irma-frontend
-```
-A webpage demoing IRMA attribute issuance verification should now be available at http://localhost:8088.
-
-> Open the browser console and the console running `irma server` to see various log messages and possibly error messages as the IRMA session proceeds.
-
-## Example configuration and IRMA session
-
-Generally, your IRMA server runs in your backend alongside a server application serving your frontend (website), with which the IRMA app user is interacting. Your server application starts and manages sessions at your IRMA server to verify or issue attributes (for example, when the user wants to log in). This can be setup as follows.
-
-### Configure `irma server`
-
-In production it is generally best to [authenticate incoming session requests](irma-server.md#requestor-authentication) from your application. The following is an example production configuration file ([in YAML](irma-server.md#configuring)) for the `irma server` (start with `irma server -c /path/to/config.yml`) that will accept [session requests](session-requests.md) if they include a `Authorization: mysecrettoken` HTTP header.
-
-```yaml
-production: true
-email: "example@example.com" # see https://irma.app/docs/email
-
-port: 443
-url: "https://example.com/irma/"
-tls_cert: "/etc/letsencrypt/live/example.com/fullchain.pem"
-tls_privkey: "/etc/letsencrypt/live/example.com/privkey.pem"
-
-no_auth: false
-requestors:
- myapp:
- auth_method: "token"
- key: "mysecrettoken"
-```
-
-* You may want to [restrict permissions](irma-server.md/#permissions) to verify or issue specific attributes, globally or per requestor.
-* The server can be made into a daemon on most Linux systems [using a systemd unit file](irma-server.md#running-as-daemon).
-* Another common setup is to have a reverse proxy between the IRMA server and the internet, which handles TLS instead and forwards traffic on `https://example.com/irma/` to the IRMA server.
-
-### Perform a session
-
-Assuming your application runs on the same server as the IRMA server, your application can now start a session at your IRMA server as follows (using `curl` as example):
-
-```bash
-curl https://example.com/session \
- -X POST \
- -H "Content-Type: application/json" \
- -H "Authorization: mysecrettoken" \
- -d '{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[["irma-demo.MijnOverheid.ageLower.over18"]]]
- }'
-```
-
-This will output something like the following:
-
-```json
-{
- "token": "X7LU5Q8Jhig0330gjYUO",
- "sessionPtr": {"u": "https://example.com/irma/t1nXs4ZduyhvAeAAlB77","irmaqr": "disclosing"},
- "frontendRequest":{"authorization":"X9XeI0gJG2HZv4hZ1WkP","minProtocolVersion":"1.0","maxProtocolVersion":"1.1"}
-}
-```
-
-* Use the `token` to [track the session status](api-irma-server.md#get-session-token-status), and to [get the session result](api-irma-server.md#get-session-token-result) after the session has finished.
-* The `sessionPtr` and `frontendRequest` are used by [`irma-frontend`](api-irma-frontend.md) to show an IRMA QR code or toggle to the IRMA app. Generally you [configure `irma-frontend`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client#usage) with an URL that returns the `sessionPtr` and `frontendRequest`; it will then start the session automatically.
-
-Instead of managing sessions with HTTP requests as shown here, [for certain languages](irma-backend.md) (currently Go and JavaScript) it is also possible to include an IRMA library and manage sessions using function invocations.
-
-## Issuing IRMA attributes
-
-This page mostly focuses on verifying, i.e. receiving IRMA attributes from IRMA apps and establishing their authenticity. Issuing attributes to IRMA apps can be done with the same software and with largely similar flows, but is more involved, because the identity of prospective issuers need to be verified and the contents and structure of the credentials to be issued needs to be established. This process is documented (among other things) in the [issuer guide](issuer.md).
-
-For experimenting and demoing, however, it is possible to issue [any of the existing credentials](https://privacybydesign.foundation/attribute-index/en/irma-demo.html) within the [`irma-demo` scheme](schemes.md). For example, if the `requestors` block in the [YAML example configuration](#configure-irma-server) of the IRMA server above would include permission to issue `irma-demo` attrbutes, as follows:
-
-```yaml
-requestors:
- myapp:
- auth_method: "token"
- key: "mysecrettoken"
- issue_perms:
- - "irma-demo.*"
-```
-
-Then an issuance session for the credential used in the [example disclosure session](#perform-a-session) above can be started at the IRMA server as follows:
-
-```bash
-curl https://example.com/session \
- -X POST \
- -H "Content-Type: application/json" \
- -H "Authorization: mysecrettoken" \
- -d '{
- "@context": "https://irma.app/ld/request/issuance/v2",
- "credentials": [
- {
- "credential": "irma-demo.MijnOverheid.ageLower",
- "attributes": {
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no"
- }
- }
- ]
- }'
-```
-
-To issue a demo credential of your own not already present in the `irma-demo` scheme, see the [issuer guide](issuer.md).
diff --git a/website/versioned_docs/version-v0.5.0/irma-app.md b/website/versioned_docs/version-v0.5.0/irma-app.md
deleted file mode 100644
index 5b2baf3..0000000
--- a/website/versioned_docs/version-v0.5.0/irma-app.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-title: IRMA app
-id: version-v0.5.0-irma-app
-original_id: irma-app
----
-
-
-
-
-
-
-
-
-The IRMA app allows users to receive and store digitally signed attributes from trusted issuers, after which they can be selectively disclosed to others. The app is essentially a GUI for the [`irmaclient`](https://github.com/privacybydesign/irmago/tree/master/irmaclient) Go package, which implements the client relative to the [IRMA server](irma-server.md). It is available in the iOS and Android app stores and may also be compiled from source.
-
-
-
-
-## Source code
-
-The source code of the IRMA app is published [on GitHub](https://github.com/privacybydesign/irmamobile/) under the [GPLv3 license](https://www.gnu.org/licenses/gpl-3.0.en.html).
-
-## Developer mode
-
-The IRMA app has a developer mode, which is disabled by default. It can be enabled by tapping 7 times on the version number at the bottom of the "About IRMA" screen, reachable from the side menu.
-
-While developer mode is disabled (default), the IRMA app will:
-- Block all HTTP connections that don't use TLS (i.e. the URL of the server must start with `https`), in order to prevent attributes from being sent unencrypted over the internet.
-- Block all HTTP connections to IRMA servers *not* running in [`production` mode](irma-server.md#production-mode). Since the majority of the IRMA app users will not have developer mode enabled, this requires IRMA servers facing those users to enable `production` mode (which makes the IRMA server switch to safer default values for some of its configuration options).
-
-Developer mode thus enables performing IRMA sessions with locally running IRMA servers, during development of an application using IRMA. After it has been enabled, a toggle will appear in the "Settings" screen with which it can be disabled again.
-
-For normal users this feature is made difficult to discover by design, for their protection. On the other hand, developers will notice its existence as soon as they try to do an IRMA session with a locally running IRMA server, by the error message displayed by the app.
-
-> Use developer mode with care: when enabled, the IRMA app will not protect you from accidentally sending your attributes unencrypted over the internet.
diff --git a/website/versioned_docs/version-v0.5.0/irma-backend.md b/website/versioned_docs/version-v0.5.0/irma-backend.md
deleted file mode 100644
index db04fd2..0000000
--- a/website/versioned_docs/version-v0.5.0/irma-backend.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: IRMA backend packages
-id: version-v0.5.0-irma-backend
-original_id: irma-backend
----
-
-[`irma-backend-packages`](https://github.com/privacybydesign/irma-backend-packages/)
-is a collection of libraries in multiple programming languages assuming the role
-of the [IRMA server](what-is-irma.md#irma-servers) in the IRMA protocol, allowing you to integrate IRMA in the backend
-of your application. In particular, these libraries allow you to do the following:
-
- * Starting IRMA sessions using a session request or a JWT at the IRMA server
- * Retrieving the current status of IRMA sessions (only once or by receiving events on status updates)
- * Retrieving session result or session result JWT when a session succeeded
- * Cancelling IRMA sessions
- * Retrieving the JWT public key of the IRMA server
- * Generating a JWT of a session request
- * Verifying a JWT of a session request or a session result
-
-Additionally, they will handle all communication with the [IRMA app](irma-app.md).
-
-Depending on the programming language, the libraries achieve this by either directly including
-the IRMA server functionality, or by consuming the [REST API](api-irma-server.md) exposed
-by the [`irma server`](irma-server.md).
-
-The library will slightly differ per language, since each programming language has its own conventions.
-
-## Available languages
-For the list of currently available programming languages, check the [GitHub README](https://github.com/privacybydesign/irma-backend-packages/). (Note that for the Go programming language, there is
-a separate [`irmaserver`](irma-server-lib.md) Go package.)
-
-If the programming language of your choice is not available yet, you can
-always directly invoke the `irma server` [REST API](api-irma-server.md).
-If you think the programming language of your choice would benefit being part of
-`irma-backend-packages`, you can always contact us or make an issue on [GitHub](https://github.com/privacybydesign/irma-backend-packages/issues).
-
-If you made a library for a programming language yourself that we do not support yet,
-or if you added features to existing libraries, please send us a pull request.
-We are always interested in extending the IRMA ecosystem with support for additional
-programming languages.
diff --git a/website/versioned_docs/version-v0.5.0/irma-cli.md b/website/versioned_docs/version-v0.5.0/irma-cli.md
deleted file mode 100644
index 3654bfb..0000000
--- a/website/versioned_docs/version-v0.5.0/irma-cli.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: irma command line tool
-id: version-v0.5.0-irma-cli
-original_id: irma-cli
----
-
-`irma` is an IRMA Swiss knife in the form of a command line executable, supporting the following subcommands:
-
-* [`irma server`](irma-server.md): an IRMA server daemon allowing you to perform IRMA sessions with [IRMA apps](irma-app.md).
-* `irma session`: Perform an IRMA disclosure, issuance or signature session, using the [builtin](irma-server-lib.md) IRMA server or a remote [`irma server`](irma-server.md)
-* [`irma scheme`](schemes.md#updating-and-signing-schemes-with-irma): Manage IRMA schemes, supporting downloading, updating, verifying, and signing schemes, and IRMA key generation
-* `irma request`: compose an IRMA session request
-* `irma meta`: Parse an IRMA metadata attribute and print its contents
-
-Pass `-h` or `--help` to any of these subcommands to see usage details and examples.
-
-## Installation
-
-Preferably, you should build `irma` from source, but we also provided binary releases built by our CI server.
-
-### Compiling from source
-
-```shell
-git clone https://github.com/privacybydesign/irmago
-cd irmago
-go install ./irma
-```
-
-### Using the binary release
-
-You can download the precompiled `irmago` binaries from our [CI build server](https://gitlab.science.ru.nl/irma/github-mirrors/irmago/-/jobs/artifacts/master/download?job=binaries). Extract the zip file, and use the binary for your OS and architecture (most likely amd64). Rename the file to `/usr/local/bin/irma` to have it available in your PATH.
-
-## Examples
-
-Perform IRMA sessions on the command line. By default, this starts a IRMA server specfically for one session on port 48680, prints the QR, and prints session results when the session is done:
-```shell
-$ irma session --disclose pbdf.nijmegen.personalData.fullname
-$ irma session --issue irma-demo.MijnOverheid.ageLower=yes,yes,yes,no
-$ irma session --noqr --request '{"type":"disclosing","content":[{"label":"BSN","attributes":["irma-demo.MijnOverheid.ageLower.over18"]}]}'
-$ irma session --server http://localhost:8088 --authmethod token --key mytoken --disclose irma-demo.MijnOverheid.ageLower.over18
-```
-
-Download an IRMA scheme and then verify its authenticity:
-```shell
-$ irma scheme download . https://privacybydesign.foundation/schememanager/irma-demo
-$ irma scheme verify irma-demo
-Verifying scheme irma-demo
-
-Verification was successful.
-```
-
-Generate an IRMA issuer private-public keypair (of 2048 bits and supporting a maximum of 10 attributes):
-```shell
-$ cd irma-demo/MijnIssuer
-$ irma scheme issuer keygen # takes a while
-$ ls PublicKeys PrivateKeys
-PrivateKeys:
-0.xml
-
-PublicKeys:
-0.xml
-```
-
-Sign an IRMA scheme after having made modifications:
-```shell
-$ cd irma-demo
-# Make modifications (e.g. add a public key to an issuer with irma scheme issuer keygen)
-$ irma scheme sign
-$ irma scheme verify
-Verifying scheme irma-demo
-
-Verification was successful.
-```
diff --git a/website/versioned_docs/version-v0.5.0/irma-frontend.md b/website/versioned_docs/version-v0.5.0/irma-frontend.md
deleted file mode 100644
index b6177ab..0000000
--- a/website/versioned_docs/version-v0.5.0/irma-frontend.md
+++ /dev/null
@@ -1,385 +0,0 @@
----
-title: IRMA frontend JavaScript packages
-id: version-v0.5.0-irma-frontend
-original_id: irma-frontend
----
-
-The [`irma-frontend-packages`](https://github.com/privacybydesign/irma-frontend-packages) repository is a set of
-related JavaScript packages that together form a Javascript frontend client to the
-[`irma server`](https://github.com/privacybydesign/irmago/tree/master/irma). The packages contain a state
-machine package [`irma-core`](#irma-core) to which several plugin packages can be added to achieve IRMA support
-for your application. We also provide a wrapper package [`irma-frontend`](#irma-frontend) that combines `irma-core` with some of the
-plugins in a bundle. With this wrapper package you have an easy starting point for handling sessions using an embedded
-web element or using a popup overlay in the browser.
-
-Using the default styling, the browser version will look like this:
-
-![IRMA frontend web element](assets/irma-frontend-web.gif)
-
-All packages are published on [npm](https://www.npmjs.com/) in `@privacybydesign` scoped packages.
-
-## IRMA core
-
-This package contains the [state machine](https://github.com/privacybydesign/irma-frontend-packages/blob/master/irma-core/state-transitions.js)
-for implementing IRMA flows. `irma-core` itself does not provide any real functionality. Plugins can be registered at the
-state machine and the plugins then provide the functionality depending on the state the state machine is in.
-The plugins can also request state modifications to the state machine.
-
-IRMA core can be initialized in the following way:
-```javascript
-const IrmaCore = require('@privacybydesign/irma-core');
-const irma = new IrmaCore(/* options */);
-
-irma.use(/* Plugin A */);
-irma.use(/* Plugin B */);
-
-irma.start();
-```
-
-More information about the methods IRMA core offers to you can be found
-in the [API overview](api-irma-frontend.md#irma-core).
-
-### Available plugins for IRMA core
-Below is a list of the plugins we provide. Detailed explanations of the plugins can be found in the READMEs
-on GitHub (linked to in the left column).
-
-| Plugin | Functionality |
-|---|---|
-| [`irma-client`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client) | Plugin to fetch a [session package](api-irma-server.md#post-session), to check the `irma server` for the current session status and optionally to fetch the result. The plugin is widely configurable, so you can also fetch a session package or a session result at custom endpoints. |
-| [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web) | Plugin to handle user interaction via a web element that developers can embed within the contents of their webpages. It is designed to be used with [`irma-css`](#irma-css). `irma-css` is not embedded in this package, so you have to manually include this. You are also free to use your own styling. |
-| [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-popup) | `irma-web` element embedded in a popup overlay. The popup is displayed on top of your content and is hidden again when a session is completed, when a fatal error occurs or when the user closes the popup. It is designed to be used with [`irma-css`](#irma-css). `irma-css` is not embedded in this package, so you have to manually include this. You are also free to use your own styling. |
-| [`irma-console`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-console) | Plugin to handle user interaction via the console (either the browser console or the command line console) using node.js. |
-| [`irma-dummy`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-dummy) | Plugin that provides a dummy implementation of the `irma-client` plugin. This can be used to test the user interaction without actually having to do a session at an IRMA server. Instead, the state machine will be instructed to continue after fixed timeouts. |
-
-If a plugin for your use case is not available, we offer you the option to [construct one yourself](#make-your-own-irma-core-plugin).
-
-### Usage guide
-Here we explain the scenario in which the web element is embedded within the contents of our website.
-This web element will be controlled by the `irma-web` plugin. We use `irma-client` for the communication
-with the IRMA server and our backend.
-
-In the body of our HTML page we need to have an HTML element where `irma-web` can render its user interface.
-We also import the [`irma-css`](#irma-css) styling to nicely style our `irma-web-form` element.
-```html
-
-
- ...
-
- ...
-
-
- ...
-
- ...
-
-
-```
-
-In our JavaScript we import `irma-core` and the relevant plugins first.
-```javascript
-const IrmaCore = require('@privacybydesign/irma-core');
-const IrmaWeb = require('@privacybydesign/irma-web');
-const IrmaClient = require('@privacybydesign/irma-client');
-```
-
-Then we can instantiate IRMA core. Let's assume we already have an endpoint `/get-irma-session`
-in our backend that starts a relevant IRMA session at the [`irma server`](irma-server.md). Let's say the endpoint
-returns a single session package (in JSON) without any backend token.
-```javascript
-const irma = new IrmaCore({
- // Enable to get helpful output in the browser console.
- debugging: false,
-
- // The option 'element' is used by irma-web to find its HTML element in the DOM.
- element: '#irma-web-form',
-
- // The 'session' option struct is used by irma-client to find the session information.
- session: {
- // The base url of our website
- url: 'http://example.com',
-
- // The 'start' option struct specifies where irma-client can fetch a new session package.
- start: {
- // Specifies how the endpoint url can be derived from the base url (see above).
- url: o => `${o.url}/get-irma-session`,
- // A GET request is used.
- method: 'GET',
- // No additional HTTP headers are needed.
- headers: {},
- // Note: a GET request with empty headers is fetch's default, so
- // omitting these options would lead to the same result.
- // All options the fetch API exposes can be used here to customize the request.
- // https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch
- },
-
- // The 'mapping' option specifies how the data can be derived from a 'start' response.
- mapping: {
- // The only thing included in the request is the session pointer, so no additional parsing is needed.
- sessionPtr: r => r,
- },
-
- // Since we did not receive a backend token, we cannot retrieve any session result here.
- result: false,
- },
-});
-```
-
-Now we can add the plugins to our IRMA core instance and start running it.
-```javascript
-irma.use(IrmaWeb);
-irma.use(IrmaClient);
-
-const promise = irma.start();
-```
-
-IRMA core is now started and the IRMA web element should be visible.
-By looking at the state of the promise, you can detect whether the user has finished.
-```javascript
-promise.then(() => {
- // The user has completed the session.
-})
-.catch((err) => {
- // Some fatal error has occurred.
-});
-```
-
-Be aware that you can start an instance of `irma-core` only once.
-When you want to call `start()` again, you have to create a new instance.
-When a promise of an earlier `start()` call is not completed yet, promise rejection
-can be forced by calling the `abort()` method. In this way a new `irma-core`
-instance can be created without any risk on interference with other running instances.
-When a promise is rejected because of an `abort()` call, the promise will return the
-error message `Aborted`.
-
-```javascript
-irma.abort();
-```
-
-For detailed information about all available options, you can check the README of the
-particular plugin on GitHub. There are links in the plugin overview [above](#available-plugins-for-IRMA-core).
-
-## IRMA frontend
-For convenience we already bundled `irma-core`, `irma-web`, `irma-popup` and `irma-client` together with the default styling
-from `irma-css`. We also added polyfills in this package to realize support for Internet Explorer 11.
-The package can be installed from the npm registry.
-The bundled package can also be downloaded directly [here](https://github.com/privacybydesign/irma-frontend-packages/releases/latest/download/irma.js).
-Please host this file as asset yourself.
-
-The bundle can be imported in your JavaScript file by doing `require('@privacybydesign/irma-frontend')` or it can
-be included directly in the HTML.
-
-```html
-
-```
-
-You can then instantiate `irma-frontend` and start a session like this when using an embedded web element:
-```javascript
-const exampleWeb = irma.newWeb({
- debugging: false, // Enable to get helpful output in the browser console
- element: '#irma-web-form', // Which DOM element to render to
-
- // Back-end options
- session: {
- // Configure your flow here, see usage guide of irma-core
- },
-
- ...
-});
-
-exampleWeb.start()
-.then(result => console.log("Successful disclosure! 🎉", result))
-.catch(error => console.error("Couldn't do what you asked 😢", error));
-```
-
-When you want a popup overlay to be used to, you can do the following:
-```javascript
-const examplePopup = irma.newPopup({
- debugging: false, // Enable to get helpful output in the browser console
-
- // Back-end options
- session: {
- // Configure your flow here, see usage guide of irma-core
- },
-
- ...
-});
-
-examplePopup.start()
-.then(result => console.log("Successful disclosure! 🎉", result))
-.catch(error => console.error("Couldn't do what you asked 😢", error));
-```
-
-Be aware that you can start an instance of `irma-frontend` only once.
-When you want to call `start()` again, you have to create a new instance.
-When a promise of an earlier `start()` call is not completed yet, promise rejection
-can be forced by calling the `abort()` method. In this way a new `irma-frontend`
-instance can be created without any risk on interference with other running instances.
-When a promise is rejected because of an `abort()` call, the promise will return the
-error message `Aborted`.
-
-```javascript
-exampleWeb.abort();
-examplePopup.abort();
-```
-
-More information about the methods the IRMA frontend package offers to you can be found
-in the [API overview](api-irma-frontend.md#irma-frontend).
-
-## IRMA css
-For the IRMA core plugins `irma-web` and `irma-popup` we made it possible to manually include the style
-that it will use. We provide to you a [normal version](https://github.com/privacybydesign/irma-frontend-packages/releases/latest/download/irma.css)
-and a [minified version](https://github.com/privacybydesign/irma-frontend-packages/releases/latest/download/irma.min.css)
-of the default styles. The CSS can be linked into your website the regular way:
-
-```html
-
-```
-
-When you want to adapt the design to suit for your own use case, you can take a look in the [styleguide](https://privacybydesign.github.io/irma-frontend-packages/styleguide/).
-Based on this you can adapt the CSS and then import the modified version into your project.
-Customized versions of `irma-css` can be used in combination with the `irma-web` and
-`irma-popup` plugins for `irma-core`.
-
-### Customizing the design
-Customizing the design is especially useful for developers that want to use an embedded
-web element to initiate the IRMA flow and see that the default design does not fit
-into the design of their website. We provide you a convenient way to alter the
-design and build a new, customized style. This can be done in the following way:
-
-1. Clone the [`irma-frontend-packages` repository](https://github.com/privacybydesign/irma-frontend-packages).
-2. Use our [guide](https://github.com/privacybydesign/irma-frontend-packages/tree/master/irma-css#compiling-locally)
- to compile the CSS styleguide locally.
-3. Make the desired changes in the source files. These files can be found in the
- `irma-css/src` directory.
-4. Check **all pages** of the locally built styleguide to check whether your local
- changes work for all flows.
-5. Build a release version for your customized CSS by running `npm run release` in the
- `irma-css` directory. The built CSS files can be found in the `irma-css/dist` directory.
-6. Include the new style in your website and use [IRMA core](#irma-core) in combination
- with the `irma-web` plugin (for embedded web elements) or the `irma-popup` plugin (for
- a popup overlay). The plugins will use the custom CSS that you have embedded. For
- managing the session state we recommend you to use the `irma-client` plugin.
-
-```javascript
-require('assets/my-custom-irma-css-design.min.css');
-
-const IrmaCore = require('@privacybydesign/irma-core');
-const IrmaWeb = require('@privacybydesign/irma-web');
-const IrmaClient = require('@privacybydesign/irma-client');
-
-const irma = new IrmaCore({
- debugging: true,
- element: '#irma-web-form',
- language: 'en',
- // Check the irma-web README on how to customize the default texts.
- session: {
- // Check the irma-client README for all options.
- },
-});
-
-irma.use(IrmaWeb);
-irma.use(IrmaClient);
-
-irma.start()
-.then(result => console.log("Successful disclosure! 🎉", result))
-.catch(error => {
- if (error === 'Aborted') {
- console.log('We closed it ourselves, so no problem 😅');
- return;
- }
- console.error("Couldn't do what you asked 😢", error);
-});
-```
-
-## Make your own IRMA core plugin
-If you need functionality that is not covered by one of the existing IRMA core plugins, you can also define
-one yourself. In the constructor the `stateMachine` and the `options` from `IrmaCore` can be accessed.
-The constructor can be omitted if you do not need it.
-Furthermore a plugin can have a `start` method that is
-called when the `start` method of the associated `IrmaCore` instance is called, and a `stateChange` method
-that is called when the state of the state machine changes:
-
-```javascript
-class IrmaPlugin {
- // Optional
- constructor({stateMachine, options}) {
- ...
- }
-
- // Optional method
- start() {
- ...
- }
-
- // Optional method
- stateChange({newState, oldState, transition, isFinal, payload}) {
- ...
- }
-
- // Optional method
- close() {
- ...
- return Promise.resolve(); // Must return a Promise
- }
-}
-```
-
-A plugin can request the state machine to make changes. This can be done using the `transition` and
-`finalTransition` methods of the `stateMachine`. The first parameter of these functions is the requested
-transition. The possible transitions can be found in the [state machine](https://github.com/privacybydesign/irma-frontend-packages/blob/master/irma-core/state-transitions.js).
-As second parameter `payload` can be added to the transition. The payload can then be accessed by all other plugins
-as it is one of the parameters of the `stateChange` method. When requesting a `finalTransition`, the state
-machine will be locked in the new state. From then no transitions can be made anymore. For a `finalTransition`
-the potential `newState` must be in the list of possible end states. Otherwise an error is returned. After
-a `finalTransition` the `close` method of the plugin is called to close the plugin's state. This method should
-return a Promise which resolves when the plugin finishes closing. When the `close` Promises of all plugins are
-resolved, the promise returned by the `start` method of `IrmaCore` will resolve or reject (depending on the
-transaction). In this way we can guarantee that plugins are not active anymore when the promise returned by the
-`start` method of `IrmaCore` is finished. Besides when calling `finalTransition`, the closing procedure can also
-be activated when the `transition` method is used and the state machine gets in a state from which no
-transitions are possible anymore.
-
-For example, in the `IrmaPopup` plugin the user can press on the close button in the UI to abort the session.
-When this happens the `IrmaPopup` plugin must request a state change at the IRMA core state machine to
-notify all other plugins that the new state becomes `Aborted`. This is done in the following way:
-```javascript
-stateMachine.transition('abort', 'Popup closed');
-```
-
-There are no transitions possible anymore from the state `Aborted`. This means that unless the transition
-is not explicitly marked as final, the `stateChange` method of your plugin will be called with `isFinal` set
-to true.
-
-## Differences with [irmajs](irmajs.md)
-The previous JavaScript library `irmajs` combined frontend and backend functionality. The `startSession` related
-functions could be used to start sessions, and `handleSession` could be used for actually being the
-frontend to the user.
-
-In the new library we have split these functionalities into two libraries. The session management functionality
-for node.js server applications now belongs to the [`irma-backend-packages`](https://github.com/privacybydesign/irma-backend-packages).
-The `irma-frontend-packages` only deals with session handling for the (web)client, starting
-with fetching a session package from a remote server, then communicating with the `irma server` what the current status
-of the session is, and finally fetching the result if the client needs it.
-It also handles the user interaction related to all of these actions.
-
-As a rule of thumb, `irma-frontend-packages` is meant to handle the `/irma/...` endpoints, and
-`irma-backend-packages` is meant to handle the `/session/...` endpoints of the `irma server`. Theoretically,
-`irma-frontend-packages` is able to fetch a session package directly at the `irma server` and therefore also
-use the `/session` endpoint of the `irma server`. This flow is however not recommended. A better
-practice is to put a backend layer in between that starts the session at the `irma server`.
-
-For user interaction, we currently have support for a web element embedded in the content, a web browser
-popup overlay and console user interaction using node.js. Below you can find an overview of the plugins for
-`irma-core` and how they map to the methods known from `irmajs`. In all cases the [`irma-client`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client)
-plugin is needed for server communication.
-
-| irmajs method | irma-frontend plugin | Differences |
-|---|---|---|
-| `'popup'` | [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-popup) | Does not always reject on cancellation or timeout. When a `start` endpoint is specified at `irma-client` to fetch a new session package, the user gets the opportunity to try again. Also, support for tablets has been added. The default [`irma-css`](#irma-css) style can be used or a custom CSS template can be defined to give it your own look and feel. |
-| `'canvas'` | [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web) | Has been upgraded to a full web element to also be able to handle tablets. Auto-refreshment of the QR on session timeout is now supported. Furthermore, the differences mentioned at the method `popup` also apply here. |
-| `'mobile'` | [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web) or [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-popup) | The mobile flow is fully integrated into the web and popup interfaces. Please check those options to see the differences. |
-| `'console'` | [`irma-console`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-console) | No major differences. |
-| `'url'` | _No support_ | The url can simply be constructed according to the format `https://irma.app/-/session#` where `` has to be replaced with the session package JSON object (converted to a string using url encoding). A session package can be retrieved using the [`irma-backend-packages`](https://github.com/privacybydesign/irma-backend-packages). |
-
-For users that have difficulties integrating a new library, but do want to upgrade, we also provide a [`irma-legacy`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/irma-legacy)
-wrapper that maps the legacy `irmajs` calls onto the new `irma-frontend-packages`. More information about this will follow.
diff --git a/website/versioned_docs/version-v0.5.0/irma-server-lib.md b/website/versioned_docs/version-v0.5.0/irma-server-lib.md
deleted file mode 100644
index f08bd50..0000000
--- a/website/versioned_docs/version-v0.5.0/irma-server-lib.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: irma server library
-id: version-v0.5.0-irma-server-lib
-original_id: irma-server-lib
----
-
-
-
-`irmaserver` is a Go library providing a HTTP server that handles IRMA session with the IRMA app, and functions for starting and managing IRMA sessions.
-
-## Installing
-
-```shell
-go get github.com/privacybydesign/irmago
-```
-
-## Configuring
-The server is configured by passing a `server.Configuration` instance to `irmaserver.New()`. For the options and their meaning, see [Godoc](https://godoc.org/github.com/privacybydesign/irmago/server/#Configuration).
-
-## Email
-
-Users are encouraged to provide an email address with the `Email` option in the `server.Configuration` struct, subscribing for notifications about changes in the IRMA software or ecosystem. [More information](email.md).
-
-## Example
-
-```go
-package main
-
-import (
- "github.com/privacybydesign/irmago/server"
- "github.com/privacybydesign/irmago/server/irmaserver"
- "net/http"
- "fmt"
- "encoding/json"
-)
-
-func main() {
- configuration := &server.Configuration{
- // Replace with address that IRMA apps can reach
- URL: "http://localhost:1234/irma",
- }
-
- err := irmaserver.Initialize(configuration)
- if err != nil {
- // ...
- }
-
- http.Handle("/irma/", irmaserver.HandlerFunc())
- http.HandleFunc("/createrequest", createFullnameRequest)
-
- // Start the server
- fmt.Println("Going to listen on :1234")
- err = http.ListenAndServe(":1234", nil)
- if err != nil {
- fmt.Println("Failed to listen on :1234")
- }
-}
-
-func createFullnameRequest(w http.ResponseWriter, r *http.Request) {
- request := `{
- "type": "disclosing",
- "content": [{ "label": "Full name", "attributes": [ "pbdf.nijmegen.personalData.fullname" ]}]
- }`
-
- sessionPointer, token, err := irmaserver.StartSession(request, func (r *server.SessionResult) {
- fmt.Println("Session done, result: ", server.ToJson(r))
- })
- if err != nil {
- // ...
- }
-
- fmt.Println("Created session with token ", token)
-
- // Send session pointer to frontend, which can render it as a QR
- w.Header().Add("Content-Type", "text/json")
-
- jsonSessionPointer, _ := json.Marshal(sessionPointer)
- w.Write(jsonSessionPointer)
-}
-```
-
-## See also
-
-* The Go library [`requestorserver`](https://godoc.org/github.com/privacybydesign/irmago/server/requestorserver) wraps the functions that this library exposes for starting and managing IRMA sessions into HTTP endpoints.
-* The [`irma server`](irma-server.md) command wraps `requestorserver` into an executable.
-* The [client](https://godoc.org/github.com/privacybydesign/irmago/irmaclient) corresponding to this server is implemented by the [IRMA mobile app](irma-app.md).
diff --git a/website/versioned_docs/version-v0.5.0/irma-server.md b/website/versioned_docs/version-v0.5.0/irma-server.md
deleted file mode 100644
index ead3408..0000000
--- a/website/versioned_docs/version-v0.5.0/irma-server.md
+++ /dev/null
@@ -1,286 +0,0 @@
----
-title: irma server
-id: version-v0.5.0-irma-server
-original_id: irma-server
----
-
-
-`irma server` is an IRMA server executable (daemon) allowing you to perform IRMA sessions with
-[IRMA apps](irma-app.md). It handles all IRMA-specific cryptographic details of issuing or verifying IRMA attributes with an IRMA app on behalf of a [requestor](overview.md#participants) (the application wishing to verify or issue attributes). It exposes the following:
- * HTTP endpoints under `/irma`, used by the IRMA app during IRMA sessions
- * a JSON API under `/sessions` for requestors, allowing them to request the server to verify or issue attributes.
-
-`irma server` is a subcommand of the [`irma`](irma-cli.md) command line tool, which additionally contains subcommands to start or perform IRMA sessions, handle [IRMA schemes](schemes.md), and more.
-
-For installation instructions, see [`irma`](irma-cli.md).
-
-## Running the server
-
-Simply run `irma server` to run the server with the default configuration in development mode. Use `irma server -v` for more verbose logging, for example to see the current configuration. Use `irma server -vv` to also log session contents.
-
-Run `irma server --help` to see configuration options. In order to verify your configuration, run `irma server check -v`.
-
-## Starting a session
-Assuming the server runs in the [default configuration](#default-configuration) (in particular [requestor authentication](#requestor-authentication) is disabled (`no_auth` is `true`) and the `irma-demo` [scheme](schemes.md) is installed), issue `irma-demo.MijnOverheid.ageLower` attributes using the [`session`](irma-cli.md) subcommand of the `irma` tool:
-```shell
-irma session --server http://localhost:8088 --issue irma-demo.MijnOverheid.ageLower=yes,yes,yes,no
-```
-Verify the `irma-demo.MijnOverheid.ageLower.over18` attribute:
-```shell
-irma session --server http://localhost:8088 --disclose irma-demo.MijnOverheid.ageLower.over18
-```
-These print QRs in your terminal that you can scan with your [IRMA app](irma-app.md) to perform the session. For more extensive examples, see [irmajs](irmajs.md).
-
-## Configuring
-Run `irma server -h` to see all configuration options. Each option may be passed as:
- 1. a command line flags (e.g. [`--listen-addr`](#http-server-endpoints))
- 2. a environmental variable (e.g. `IRMASERVER_LISTEN_ADDR`)
- 3. an item in a configuration file (e.g. `"listen_addr"`) (which may be in JSON, TOML or YAML)
-
- with the following rules:
- * Flags supersede environmental variables which supersede configuration file entries.
- * Dashes are used in flags, but underscores are used in environmental variables and configuration file entries.
- * Environmental variables are uppercased and prefixed with `IRMASERVER_`.
- * The [`requestors`](#requestor-authentication) and [`static_sessions`](#static-irma-qrs) options are special: when passed as a flag or environmental variable, they must be passed as a JSON object (for example: `--requestors '{"myapp":{"auth_method":"token","key":"12345"}}'`).
- * When passing a boolean flag [use an `=`](https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax), for example [`--no-auth=false`](#requestor-authentication).
-
-In order to see the configuration that the server uses after having gathered input from these sources, specify `-v` or `-vv` or use the `verbose` option. Use `irma server check -v` (with the same flags, env vars and config files as `irma server`) to check your configuration for correctness before running the server.
-
-For a full configuation example, see [Getting started](getting-started.md#example-configuration-and-irma-session).
-
-In the remainder of this document, when referring to options we write them as configuration file entries, with underscores and without prefix.
-
-### Default configuration
-In the default configuration (run `irma server check -v` to see it) the server is immediately usable. In particular, it
-* uses the [default IRMA schemes](schemes.md#default-schemes-pbdf-and-irma-demo) ([`pbdf`](https://github.com/credentials/pbdf-schememanager) and [`irma-demo`](https://github.com/credentials/irma-demo-schememanager)), downloading them if necessary
-* allows anyone to use the server [without authentication](#requestor-authentication) (the `no_auth` setting is `true`).
-
-If the server is reachable from the internet, you should consider enabling authentication of session requests.
-
-### Configuration files
-A configuration file can be provided using the `config` option (for example: `irma server --config ./irmaserver.json`). When not specified, the server looks for a configuration file called `irmaserver.json` or `irmaserver.toml` or `irmaserver.yaml` in (1) the current path; (2) `/etc/irmaserver/`; (3) `$HOME/irmaserver`, in that order. A configuration file is not required; if none is found at any of these locations the server takes its configuration from just command line flags and environmental variables.
-
-### Production mode
-When running the server in production, you should enable the `production` option. This enables stricter defaults on the configuration options for safety and prints warnings on possibly unsafe configurations. In particular, when `production` is enabled, the default values of some options change as follows (cf. `diff <(irma server -h) <(irma server -h --production)`):
-
-* `url` from `"http://$YOUR_LOCAL_IP:port"` to `""`: in development mode the `url` to which IRMA apps will connect is set by default to your current local IP address; in `production` mode you must configure it yourself.
-* [`no_auth`](#requestor-authentication) from `true` to `false`: you should consider enabling requestor authentication, or explicitly disable this by setting this flag to `true`.
-* [`issue_perms`](#global-permissions) from `[*]` (everything) to `[]` (none).
-* [`no_email`](email.md) from `true` to `false`: in `production` mode, opting out of providing an email address can be done by explicitly setting this flag to `true`.
-
-In addition, when [developer mode is not enabled in the IRMA app](irma-app.md#developer-mode) (the default setting), the IRMA app wil refuse to perform sessions with IRMA servers not running in `production` mode. Since the majority of the IRMA app users will not have developer mode enabled, this requires IRMA servers facing those users to enable `production` mode.
-
-### Keys and certificates
-For each configuration option that refers to some kind of key or certificate (for example `jwt_privkey`), there is a corresponding option with the `_file` suffix (for example `jwt_privkey_file`). Keys can be specified either by setting former to a (PEM) string, or setting the the latter to a file containing the (PEM) string.
-
-### HTTP server endpoints
-The HTTP endpoints that this server offers is split into two parts:
-* `/session`: used by the requestor to start sessions, check session status, or get session results.
-* `/irma`: used by the IRMA app during IRMA sessions.
-
-In the default mode, the server starts one HTTP server that offers both, configured with `listen_addr` and `port`. If however the `client_port` and `client_listen_addr` options are provided, then the server starts two separate HTTP servers:
-* `/session` attaches to the address and port provided with `port` and `listen_addr`.
-* `/irma` attaches to the address and port provided with `client_port` and `client_listen_addr`.
-
-The `/irma` endpoints must always be reachable for the IRMA app. Using this double server mode you can restrict access to the `/session` endpoints by e.g. setting `listen_addr` to `127.0.0.1` or to an interface only reachable from an internal network. Restricting access to the `/session` endpoints in this way may make requestor authentication unnecessary.
-
-### Requestor authentication
-The server runs in one of two modes: it either accepts all session requests from anyone that can reach the server, or it accepts only authenticated session requests from authorized requestors. This can be toggled with the `no_auth` boolean option. If the `/session` creation endpoint of your `irma server` is publicly accessible from the internet (i.e. the `client_port` option is used, see [above](#http-server-endpoints)), then you should consider enabling requestor authentication (i.e. turn `no_auth` off), otherwise anyone can use your `irma server`.
-
-The default is `true` (requests are not authenticated) when `production` is disabled and `false` otherwise.
-
-When authentication is enabled (`no_auth` is `false`), requestors that are authorized to use the server must be configured in the `requestor` option in the form of a map, for example:
-
-```json
-{
- "requestors": {
- "myapp": {
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-
-The server supports several authentication methods, one of which must be specified in the `auth_method` field for each requestor. The snippet above demonstrates the recommended and easiest to use authentication method, called `token`. When using this method the requestor must include the `key` as an API token in a HTTP header (for more details see the [API reference](api-irma-server.md#post-session)).
-
-In addition the server supports the following authentication methods:
-* `hmac`: the requestor symmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/), with HMAC-SHA256 (`HS256`) using `key`. The `key` provided should be the Base64 encoding of the actual secret.
-* `publickey`: the requestor asymmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/) with RSA (`RS256`), in this case `key` should be the PEM public key of the requestor.
-
-For each of these modes it is also possible to specify `key_file` instead `key`; in that case the file at `key_file` will be read and used as `key`.
-
-### Static IRMA QRs
-Unlike normal QRs which differ per session (as they contain the session token), the server also supports static QRs which, when scanned by the IRMA app, start preconfigured IRMA sessions. This makes it possible to for example print such a static QR. These preconfigured sessions are configured with the `static_sessions` options, for example:
-```json
-{
- "static_sessions": {
- "mystaticsession": {
- "callbackUrl": "https://example.com/callbackUrl",
- "request": {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "irma-demo.MijnOverheid.ageLower.over18" ]]]
- }
- }
- }
-}
-```
-Thus `static_sessions` must contain a map of which each item must be an [extended session request](session-requests.md#extra-parameters). Including a `callbackUrl` to which the [session result](api-irma-server.md#get-session-token-result) is sent after the session is required (since for these sessions there is no requestor waiting to receive the attributes after the session has finished). If a JWT private key is installed, then the session result is sent as a [JWT](api-irma-server.md#get-session-token-result-jwt).
-
-> If no JWT private key is installed, then the `callbackUrl` should either not be publically reachable, or it should include a secret token (e.g. https://example.com/cX5aTins5kEZpjDpfYcN) and have TLS enabled (which it should anyway as personal data will be POSTed to it). Otherwise there is no way of distinguishing POSTs from your `irma server` from POSTs made by someone else.
-
-Assuming the URL of the `irma server` is `http://example.com`, the session configured above is started when the IRMA app scans a QR with the following contents:
-```json
-{
- "irmaqr": "redirect",
- "u": "http://example.com/irma/session/mystaticsession"
-}
-```
-
-Only static [disclosure or attribute-based signature sessions](what-is-irma.md#session-types) are supported.
-
-### Permissions
-For each of the [three IRMA session types](what-is-irma.md#session-types) (attribute verification; attribute-based signature sessions; and attribute issuance), permission to use specific attributes/credentials can be granted to requestors in the configuration. For example, including permissions in the `myapp` requestor from above:
-```json
-{
- "requestors": {
- "myapp": {
- "disclose_perms": [ "irma-demo.MijnOverheid.ageLower.over18" ],
- "sign_perms": [ "irma-demo.MijnOverheid.ageLower.*" ],
- "issue_perms": [ "irma-demo.MijnOverheid.ageLower" ],
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-This means that `myapp` is authorized to request `irma-demo.MijnOverheid.ageLower.over18` in disclosure session, and any attribute from `irma-demo.MijnOverheid.ageLower` in attribute-based signature sessions. Additionally `myapp` can issue `irma-demo.MijnOverheid.ageLower` instances. In each level wildcards are permitted (`irma-demo.MijnOverheid.ageLower.*`, `irma-demo.MijnOverheid.*`, `irma-demo.*`, `*`). Thus `"disclose_perms": [ "*" ]` allows the requestor to verify any attribute.
-
-### Global permissions
-
-Global permissions can be applied to all requestors by using the global `disclose_perms`, `sign_perms` and `issue_perms` options. For each requestor, the effective set of permissions is the union of the permissions specified in its `requestors` map and the global permission set.
-
-The global options also work when `no_auth` is enabled. Thus in this case a session type can be disabled by granting no one the permission, e.g., `issue_perms: []` would disable issuance.
-
-In development mode, when `production` is `false`, the defaults for `disclose_perms`, `sign_perms` and `issue_perms` are `["*"]`. In order to protect any IRMA private keys that the server has access to from unintended use by others, when `production` is true the default of `issue_perms` is `[]`: no one can issue unless the global `issue_perms` is modified or unless specific requestors receive nonempty `issue_perms`.
-
-### Static file hosting
-
-Apart from hosting endpoints under [`/session` and `/irma`](irma-server.md#http-server-endpoints), the server also supports statically hosting all files from a certain directory. This can be useful [for experimenting](getting-started.md#perform-browser-irma-session). It can be configured with the following options:
-
-* `static_path`: Host files under this path as static files. Leave empty to disable static file hosting.
-* `static_prefix`: Host static files under this URL prefix (default: no prefix)
-
-### IRMA schemes
-
-The server uses [IRMA schemes](schemes.md) to retrieve issuer, credential and attribute names, as well as public and private keys with which attributes can be verified an issued, respectively. By default the server uses the [`pbdf` and `irma-demo` schemes](schemes.md#default-schemes-pbdf-and-irma-demo). This can be configured with the following options:
-
-* `schemes_path`: path containing IRMA schemes (often called `irma_configuration`). Default: `C:\Users\Username\AppData\Local\irma\irma_configuration` on Windows, `$HOME/.local/share/irma/irma_configuration` otherwise. Created if it does not exist. If empty, the default schemes [`pbdf` and `irma-demo`](schemes.md#default-schemes-pbdf-and-irma-demo) are downloaded into it.
-* `schemes_assets_path`: path containing initial, read-only IRMA schemes. If specified, the schemes found here are copied into the path specified by `schemes_path`. Can be used to avoid downloading default schemes on first run.
-* `schemes_update`: update IRMA schemes from their scheme URL every this many minutes. Default is `60`. Set to `0` to disable automatic scheme updating (not recommended).
-
-### IRMA issuer private keys
-
-If IRMA issuer private keys are included in the server configuration, then the server can issue all credential types of all issuers for which private keys are installed. IRMA issuer private keys can be configured in the following two ways:
-
-* Include the private keys within the [IRMA scheme](schemes.md) in the issuer's `PrivateKeys` folder, with filenames `0.xml`, `1.xml`, etc ([example](https://github.com/privacybydesign/irma-demo-schememanager/tree/master/MijnOverheid/PrivateKeys)).
-* Set the `privkeys` option to a folder containing IRMA issuer private keys called `scheme.issuer.xml` or `scheme.issuer.counter.xml` (for example, `irma-demo.MijnOverheid.xml` or `irma-demo.MijnOverheid.2.xml`).
-
-If issuance is enabled in production and private keys are configured, then you should ensure that only authenticated requestors can start issuance requests (otherwise if anyone can use your server to issue attributes then those attributes cannot be trusted or used). You should either:
-
-* disable `no_auth` and [send authenticated session requests](irma-server.md#requestor-authentication),
-* Restrict the [`/session` HTTP endpoints](#http-server-endpoints) to a internal network interface only accessible by your applications and not from outside.
-
-Taking neither approach is an unsafe configuration as in that case anyone can create issuance sessions. In this case, if `production` mode is enabled then the server will refuse to run.
-
-### Signed JWT session results
-
-If a `jwt_privkey` (or `jwt_privkey_file`) is given, then the following endpoints are enabled:
-
-* `GET /session/{sessiontoken}/result-jwt`: returns the session result signed by the `irma server` into a JWT.
-* `GET /session/{sessiontoken}/getproof`: returns a JWT similar to the one from `result-jwt`, but with the same structure as the IRMA API server session result JWTs.
-* `GET /publickey`: returns the public key with which the JWTs output by this server can be verified.
-
-This can be useful if the session result travels along an unsafe or untrusted route from the IRMA server to the requestor. As long as the `irma server` is trusted and its public key is known, the JWT can be verified to ensure that the session result was untampered with since it left the `irma server`.
-
-### TLS
-
-The IRMA protocol relies on TLS for encryption of the attributes as they travel along the internet. If your server is connected to the internet and it handles actual attributes (personal data from people), then you ***must*** ensure that the attributes are protected in transit with TLS. In its default configuration (i.e. with [developer mode](irma-app.md#developer-mode) disabled), the IRMA app will refuse to connect to servers not using TLS.
-
-You can enable TLS in the `irma server` with the `tls_cert` and `tls_privkey` options (or the `_file` equivalents), specifying a PEM certificate (chain) and PEM private key. If you use [separate requestor and app endpoints](#http-server-endpoints), additionally use `client_tls_cert` and `client_tls_privkey`.
-
-Alternatively, if your IRMA server is connected to the internet through a reverse proxy then your reverse proxy probably handles TLS for you.
-
-### Email
-
-Users of the server are encouraged to provide an email address with the `email` option, subscribing for notifications about changes in the IRMA software or ecosystem. [More information](email.md). In `production` mode, it is required to either provide an email address or to explicitly out with the `no_email` option.
-
-### Logging and verbosity
-
-The server's verbosity can be increased by two degrees:
-* `-v` flag is given, or `verbosity` option set to `1`: includes `DEBUG` messages. Logs server configuration when starting the server, stack traces of errors, and more.
-* `-vv` flag is given, or `verbosity` option set to `2`: includes `TRACE` messages. Additionally includes dumps of all HTTP traffic from and to the server.
-
-> in its default mode, the server will not log attribute values (personal data). If the verbosity is increased, then attribute values may be logged. You should avoid doing this in production.
-
-The output is [structured](https://github.com/sirupsen/logrus#fields), putting certain recurring values in fields:
-```text
-[2019-02-28T20:51:09+01:00] INFO Session started action=disclosing session=WdypvSs97JTotpfl1Dtd
-```
-Outputting JSON is enabled with the `log-json` option:
-```json
-{"action":"disclosing","level":"info","msg":"Session started","session":"WdypvSs97JTotpfl1Dtd","time":"2019-02-28T20:51:09+01:00"}
-```
-
-## Running as daemon
-
-On most Linux systems, the `irma server` can be made into an automatically started daemon as follows:
-
-1. Write a new systemd unit file to `/etc/systemd/system/irmaserver.service`:
- ```ini
- [Unit]
- Description=IRMA server
- Documentation=https://irma.app/docs/irma-server
- Requires=network.target
-
- [Service]
- Type=simple
- ExecStart=/usr/local/bin/irma server --config=/etc/irmaserver/config.json
- TimeoutStopSec=60
- Restart=always
- RestartSec=1
- StandardOutput=syslog
- StandardError=syslog
- SyslogIdentifier=irma
- User=irmaserver
- Group=irmaserver
-
- [Install]
- WantedBy=multi-user.target
- ```
- Modify the path to `irma` and [your configuration file (or flags or environmental variables)](#configuring) in `ExecStart` as needed, as well as `User` and `Group`.
-2. Start the daemon and schedule it for automatic start on boot by running `systemctl start irmaserver.service && systemctl enable irmaserver.service`.
-
-See `systemctl status irmaserver.service` for the status of the daemon, and `journalctl -u irmaserver.service` for the console output of the IRMA server.
-
-## Design goals
-
-The server was designed with the following goals in mind.
-- Developer and user friendliness
- - Each of the [configuration options](#configuring) can be specified in a configuration file, command line flag, or environmental vars (see `-h`)
- - Default configuration (demo mode) is immediately useful
- - Thorough and configurable logging (`-v`, `-vv`; by default logs exclude attribute values)
- - Partial backwards compatibility with predecessor [`irma_api_server`](https://github.com/privacybydesign/irma_api_server)
- - Small startup time
-- Also available as [Go library](irma-server-lib.md) instead of standalone server
- - Bindings to other programming languages (Python, Ruby) are expected
-
-Being written in [Go](https://golang.org/), this server (in fact, the containing [`irma` binary](irma-cli.md)) additionally automatically has the following properties.
-- Simple to install (one binary, no dependencies, cross platform) and/or compile
-- [Reproducible builds](https://www.gnu.org/software/mes/manual/html_node/Reproducible-Builds.html)
-- [API documentation](https://godoc.org/github.com/privacybydesign/irmago) (generated automatically from `master` branch)
-
-Referring to Go packages (i.e. folders) under [`irmago`](https://github.com/privacybydesign/irmago), the server is structured as follows.
-* [`server/irmaserver`](irma-server-lib.md): Go library implementing the HTTP endpoints for the IRMA protocol (in which the IRMA app is the client), and a Go API for requestors to manage sessons. ([Godoc API documentation](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver))
-* `server/requestorserver`: Go library wrapping `server/irmaserver`, exposing the requestor API as a second HTTP endpoint set under `/session` URLs instead of as Go functions (next to `/irma` for the IRMA app endpoints). ([Godoc API documentation](https://godoc.org/github.com/privacybydesign/irmago/server/requestorserver))
-* `irma`: executuable whose `server` commands wraps `server/requestorserver`.
diff --git a/website/versioned_docs/version-v0.5.0/irmajs.md b/website/versioned_docs/version-v0.5.0/irmajs.md
deleted file mode 100644
index 5074332..0000000
--- a/website/versioned_docs/version-v0.5.0/irmajs.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-title: irmajs JavaScript library
-id: version-v0.5.0-irmajs
-original_id: irmajs
----
-
-> This concerns documentation of a deprecated library. Please use [`irma-frontend`](irma-frontend.md) instead. If you are looking for a library to manage your `irma server` using Node.js, you can use the JavaScript packages from [`irma-backend`](irma-backend.md).
-
-`irmajs` is a Javascript client of the RESTful JSON API offered by the [`irma server`](https://github.com/privacybydesign/irmago/tree/master/irma). It allows you to use the `irma server` to:
-
-* Verify IRMA attributes. You specify which attributes, the library handles the user interaction and the communication with the `irma server` and the [IRMA app](irma-app.md)).
-* Issue IRMA attributes.
-* Perform IRMA attribute-based signature sessions, resulting in a signature on a string to which IRMA attributes are verifiably attached.
-
-`irmajs` supports all major browsers (Firefox, Chrome, Safari, Edge, Internet Explorer 11).
-
-## Installation
-
-### Compiling from source
-Compile the library:
-
- git clone https://github.com/privacybydesign/irmajs.git
- cd irmajs
- npm install
- npm run build
-
-This writes `irma.js` to the `dist` folder, which you can include in your website in a ``) you can start an IRMA disclosure session as follows:
-
-```js
-const request = {
- '@context': 'https://irma.app/ld/request/disclosure/v2',
- 'disclose': [[[ 'irma-demo.MijnOverheid.ageLower.over18' ]]]
-};
-
-irma.startSession(server, request)
- .then(({ sessionPtr, token }) => irma.handleSession(sessionPtr, {server, token}))
- .then(result => console.log('Done', result));
-```
-
-This assumes you have an [`irma server`](irma-server.md) that is configured to [accept unauthenticated session requests](irma-server.md#requestor-authentication) listening at the URL indicated by `server`.
-
-For complete examples, see the `examples` folder. You can host these examples using the IRMA server, with:
-
- irma server -v --static-path examples/browser
-
-> If your `irma server` is publically reachable, having a setup like the one above allows anyone on the internet to start IRMA sessions at your `irma server`. Additionally, starting IRMA sessions from the browser is generally an antipattern. You should enable either [requestor authentication](irma-server.md#requestor-authentication) or [restrict access to the IRMA session creation endpoints](irma-server.md#http-server-endpoints).
-
-A more realistic configuration for this case may be found in the [Getting started](getting-started.md#example-configuration-and-irma-session) page.
diff --git a/website/versioned_docs/version-v0.5.0/issuer.md b/website/versioned_docs/version-v0.5.0/issuer.md
deleted file mode 100644
index b40fbee..0000000
--- a/website/versioned_docs/version-v0.5.0/issuer.md
+++ /dev/null
@@ -1,111 +0,0 @@
----
-title: Issuer guide
-id: version-v0.5.0-issuer
-original_id: issuer
----
-
-Being an IRMA issuer allows you to issue credentials containing attributes to IRMA app users, which they can then disclose to yourself or to others. Contrary to verifying IRMA attributes from the [IRMA app](irma-app.md) which can be done by anyone running an [IRMA server](irma-server.md), issuing to IRMA apps cannot be done without involvement the developers of IRMA ([the Privacy by Design Foundation](https://privacybydesign.foundation) and [SIDN](https://sidn.nl/irma)): registering your organization and the credentials you will be issuing is required. As part of this registration process the identity of your organization is verified, and the contents and structure of the credentials that you will be issuing is finetuned for correctness and consistency with the rest of the IRMA ecosystem. This process includes signing a contract that among others requires you to properly protect your IRMA private key, as well as paying a yearly fee.
-
-This page documents some of the processes involved.
-
-## Becoming an issuer
-
-In IRMA, information on all issuers, their credentials and the contained attributes is stored in datastructures called [IRMA schemes](schemes.md). The two standard IRMA schemes, `irma-demo` and `pbdf`, meant for demo and production respectively, are maintained by [the Privacy by Design Foundation](https://privacybydesign.foundation) and [SIDN](https://sidn.nl/irma). All IRMA apps and servers contain a copy of these two schemes, which they automatically periodically update. A party wishing to become an issuer must therefore be included in these schemes.
-
-Generally, the process of becoming an IRMA issuer looks as follows. These steps are documented in detail in the sections below.
-
-1. Collect all relevant information on your issuer, its credentials and the contained attributes, and submit that as a pull request (PR) to the [`irma-demo` scheme](https://github.com/privacybydesign/irma-demo-schememanager). (We can help creating the PR based on the relevant information, if required.) Once that is merged, it becomes automatically available for your IRMA server and for IRMA apps. Then you can start issuing the new credentials in your application during development and in demos, using the [IRMA server](irma-server.md). In this phase, you can finetune your credential structure and your issuance application.
-2. When your credential structure has become finalized and you are ready to move to production, [contact us](/about). Once you are verified as the valid issuer of the credentials and the issuer contract has been signed, your issuer information from the `irma-demo` scheme can be copied over to the production scheme, `pbdf` using another PR. At this point you will need to generate your IRMA issuer private/public keypair (more on that [below](#generating-irma-issuer-keys)), and include the public key in the PR. Once your issuer information is included in the `pbdf` scheme, you can start issuing credentials.
-
-> Credentials within the `irma-demo` scheme are not meant for production application and actual personal data, since attributes within this scheme cannot be trusted: all private keys of all issuers under the `irma-demo` scheme are included in it, so that anyone can issue any `irma-demo` credential containing any attribute values.
-
-### Creating an `irma-demo` issuer and credentials
-
-Within the scheme, all issuer and credential information is contained in a folder that schematically looks like the following.
-
-```text
-issuer-id
-├── Issues
-│ └── credentialtype-id
-│ ├── description.xml
-│ └── logo.png
-├── PublicKeys
-│ ├── 0.xml
-| └── 1.xml
-├── PrivateKeys
-│ ├── 0.xml
-│ └── 1.xml
-├── description.xml
-└── logo.png
-```
-
-To get started, it is easiest to use an existing folder of another issuer in `irma-demo` as base by duplicating it, and modifying its contents. In order to check correctness of your modifications, you can try to sign the scheme by running `irma scheme sign` in your `irma-demo` checkout, which will point out common mistakes. For more details about the contents of schemes, see the [IRMA schemes](schemes.md) page.
-
-Some notes about the `irma-demo` scheme:
-
-* The contents of the `` tags in the `description.xml` of both the issuer and all of its credential types must start with `Demo ` for all translations, to distinguish them from production (`pbdf`) credentials in the IRMA app.
-* Using the IRMA logo as `logo.png` for the issuer and credential type is fine.
-* For the private and public keypair, since no trust is associated to anything within `irma-demo`, using those of another issuer in `irma-demo` is fine (but generating a new keypair is fine too; see [below](#generating-irma-issuer-keys)).
-
-Once your modifcations are complete, ensure the scheme is validly signed by running `irma scheme sign` in your irma-demo checkout, and submit your changes as a [PR](https://github.com/privacybydesign/irma-demo-schememanager/compare). Once the PR is merged, your demo issuer and its credentials become available for issuance to your IRMA server when it updates its copy of the scheme: periodically (hourly by default), or when you restart your server.
-
-You can then use your IRMA server to issue the new credentials to your IRMA app. Alternatively, after the `irma-demo` PR is merged, the new credentials can also be issued from their corresponding pages in the [attribute index](https://privacybydesign.foundation/attribute-index/en/) (only in the case of `irma-demo` credentials).
-
-#### Using a locally modified `irma-demo` scheme
-
-Instead of submitting a PR to the `irma-demo` scheme to us, it is also possible to modify a local copy of the `irma-demo` scheme, and embed that local copy in the IRMA server and a manually compiled IRMA app, as follows.
-
-1. Create your modifications in `irma-demo`.
-2. Ensure the scheme is validly signed by running `irma scheme sign` in your `irma-demo` checkout.
-3. When starting your [IRMA server](irma-server.md#irma-schemes), point it to the folder containing your `irma-demo` checkout and disable scheme updating:
- ```sh
- irma server --schemes-path ... --schemes-update 0
- ```
-4. Create a checkout of [`irmamobile`](https://github.com/privacybydesign/irmamobile/), the IRMA app source code; replace the `irma-demo` copy in `irmamobile/irma_configuration/irma-demo` with your modified copy; and compile the IRMA app using the instructions in its README.
-
-If you use the IRMA server from step 3 to issue your credentials, then the IRMA app from step 4 will accept them. Note, however, that the standard App/Play Store versions of the IRMA app will not.
-
-### Creating a `pbdf` issuer and credentials
-
-After the development phase of your issuance application is finished and the issuer contract has been signed, your issuer and credentials can be moved to production as follows.
-
-1. Copy your issuer and its credentials from `irma-demo` to a local checkout of the production scheme, [`pbdf`](https://github.com/privacybydesign/pbdf-schememanager).
-2. Change all occurences of `irma-demo` within your issuer and credentials to `pbdf`; ensure the `Demo ` prefix is everywhere removed; and use actual logos for your issuer and credentials.
-3. [Generate](#generating-irma-issuer-keys) a new 2048 bit IRMA issuer private/public keypair; put the public key within your issuer folder in `PublicKeys/0.xml`; and keep your private key private.
-4. Submit your changes to `pbdf` as a PR.
-
-Your PR will then be signed by us, and merged. As with `irma-demo`, your issuer and its credentials then become available for issuance to your IRMA server when it updates its copy of the scheme: periodically (hourly by default), or when you restart your server. Your credentials will also automatically appear in the [attribute index](https://privacybydesign.foundation/attribute-index/en/), but in contrast with `irma-demo` credentials, they cannot be issued from there.
-
-### Generating IRMA issuer keys
-
-Generating a new IRMA issuer private/public keypair is done with the [`irma`](irma-cli.md) command line tool:
-
-```sh
-irma issuer keygen
-```
-
-See `irma issuer keygen -h` for the flags that this command accepts. By default, it will emit the private and public keys in directories called `PrivateKeys` and `PublicKeys` under your current directory, creating them if they don't exist.
-
-Some notes:
-
-* When generating a new keypair for the `irma-demo` scheme, the private key is expected to be included in the PR to the `irma-demo` repository, within the `PrivateKeys` folder under your issuer folder. However, when generating a new keypair for the production `pbdf` scheme, you *must* keep your private key private.
-* Your past and current public keys are stored within your issuer folder in the `pbdf` scheme in the `PublicKeys` folder with increasing filenames: `0.xml`, `1.xml`, et cetera. The number in the filename is the counter of your public key. When generating a new public key, you can ensure it gets the correct counter in one of the following ways:
- - By specifying it explicitly using the `-c` or `--counter` flag.
- - By running `irma issuer keygen` within your issuer folder in the scheme; it will then infer the appropriate counter using the public keys already present in the `PublicKeys` folder.
- - Alternatively, after generating the keypair you can open the private and public keys in a text editor and set the `` tag to the appropriate number.
-* If one of your credentials contains more than 10 attributes, then that amount of attributes *increased by 2* (to account for [the secret key and metadata attributes](overview.md#special-attributes)) must be passed to the `-a` or `--numattributes` flag, to ensure that the new public key supports the required amount of attributes.
-
-## Issuer maintenance
-
-Production IRMA issuer keypairs are valid for a year. Once a keypair expires it cannot be used anymore for issuance, so it is important that it is replaced by a fresh keypair before that time. Once a new public key has been included in the `pbdf` scheme, the corresponding private key can be included in your IRMA server configuration. After a restart it will use to the new private key.
-
-Please note that although the old private key cannot be used for new credentials, you MUST still keep this private key private. Someone with access to the private key could otherwise forge credentials with a creation date set to a date in the past when the key was not yet expired.
-
-### Submitting a new production public key
-
-The process for getting a new issuer public key included in the production `pbdf` scheme is as follows.
-
-1. Generate a new keypair as documented above.
-2. Send the public key to the `pbdf` scheme manager, using a [PR](https://github.com/privacybydesign/pbdf-schememanager/compare), email or Slack.
-3. The scheme manager will contact you out-of-band to verify that the public key arrived intactly, by checking its SHA256 hash.
-4. If this check succeeds, your new key will be included in the scheme. You can then install the corresponding private key in your issuing IRMA server.
diff --git a/website/versioned_docs/version-v0.5.0/keyshare-protocol.md b/website/versioned_docs/version-v0.5.0/keyshare-protocol.md
deleted file mode 100644
index 2acbf74..0000000
--- a/website/versioned_docs/version-v0.5.0/keyshare-protocol.md
+++ /dev/null
@@ -1,183 +0,0 @@
----
-title: Keyshare protocol
-id: version-v0.5.0-keyshare-protocol
-original_id: keyshare-protocol
----
-
-
-
-
-This document describes the goals and details of the IRMA keyshare protocol.
-
-## Introduction
-
-The [IRMA mobile app](irma-app.md) allows users to obtain and disclose [IRMA attributes](overview.md#cryptographic-entities), as well as attach them to signed statements. Before such an IRMA session proceeds, the IRMA app may ask the user to enter her IRMA PIN code so that the [requestor](overview.md#participants) can be sure that it is indeed the attribute owner initiating the session (as opposed to, e.g., a thief of the user's phone). The verification of the correctness of the IRMA PIN code, and preventing the session from happening when it is not, is the responsibility of the [IRMA keyshare server](https://github.com/privacybydesign/irma_keyshare_server). In order to do this, it interacts with the IRMA app and possibly the IRMA API server in a protocol that we call the *keyshare protocol*. This protocol is documented here.
-
-Each [IRMA scheme](schemes.md) decides whether or not it employs an IRMA keyshare server. If it does, then this keyshare server is involved in any IRMA session that involves attributes that fall under the scheme manager's responsibility.
-
-Upon app installation, the IRMA user *registers* to the keyshare servers of the installed scheme managers. At this point the user chooses her IRMA PIN code. Afterwards, whenever the user performs an IRMA session, the user must first enter her IRMA PIN code. Only if the PIN is correct will the keyshare server allow the session to proceed.
-
-### Goals
-
-The keyshare server must:
-- Authenticate a user as being the same person that registered to the keyshare server in the past, just before an IRMA session occurs,
-- Block the IRMA session from happening when this authentication fails,
-- Allow users to remotely block their IRMA app from performing future IRMA session in case of loss or theft of their phone. That is, the user can *revoke* her own attributes.
-- The keyshare server must not learn the values of any of the attributes of any user, and also not to whom the user discloses attributes.
-
-The latter two points imply that it is insufficient to verify the user's IRMA PIN code locally in the IRMA app, because the IRMA app should not be trusted: the user could create a malicious version that does not check the IRMA PIN. Instead we have chosen to modify the cryptography that is used in IRMA sessions in such a way that the keyshare server's contribution to it is necessary for the session to complete, so that the keyshare server can reliably block sessions from happening by refusing to cooperate.
-
-### IRMA secret keys and keyshares
-
-IRMA is an implementation of the Idemix attribute-based credential (ABC) scheme. In such schemes a *credential* is a set of numbers $(k_0, ..., k_n)$ along with a digital signature over this set of numbers, created by the [issuer](https://credentials.github.io/docs/irma.html#participants) using the [issuer's private key](https://credentials.github.io/docs/irma.html#cryptographic-entities). The ABC scheme provides an *attribute disclosure protocol* in which the user can selectively disclose any subset of the attributes $(k_0, ..., k_n)$ to another party (called the *verifier* or *service provider*), in such a way that the verifier is assured of the validity of the issuer's signature over all attributes (including the ones that were not shown).
-
-In IRMA, the first attribute $k_0$ of a credential is always the user's *secret key*. When the user discloses attributes, this secret key is always kept hidden. The *issuance protocol* in which an issuer grants an IRMA credential to a user is such that whenever the user receives a second or third or $n$-th credential, the value of this secret key $k_0$ of the new credential is the same as that of the user's first credential. Consequentially, the first attributes $k_0$ of all credentials of the user have the same value. Then, when the user discloses two attributes that come from two distinct credentials, the user not only proves to the verifier that she owns two valid signatures over the two credentials, but also that the values of the first attributes (i.e. the secret keys) of the two credential coincides. To the verifier, this proves that even though the two attributes come from distinct credentials, they still come from the same IRMA app, and therefore the same user.
-
-Thus each user has her own secret key, namely the integer that serves as the first attribute in each of her credentials. We shall drop the index and call this integer $m$. Recalling that the signed tuple of attributes of a credential is then $(m, k_1, ..., k_n)$, the purpose of the keyshare protocol is to enforce that the tuple of integers that is effectively signed in the issuance protocol is $(m_u + m_k, k_1, ..., k_n)$, where $m_u$ is known to the user and hidden from the keyshare server (along with all other attributes), and $m_k$ is known to the keyshare server and hidden from the user. That is, the user's secret key is *split* into two halves, one of which resides at the keyshare server (hence its name). Consequentially, the cooperation of the keyshare server in IRMA sessions, which necessarily always involve the secret key $m = m_u + m_k$, has become necessary.
-
-### Splitting the secret key across the user and keyshare server
-
-As mentioned, in IRMA the secret key $m$ is always kept hidden from the verifier using [a zero-knowledge proof](zkp.md). Now let $m = m_u + m_k$ with $m_u$ only known to the user, $m_k$ only known to the keyshare server, and $m$ known to neither. We now describe how we can modify the zero-knowledge proof of the secret key in such a way that the user and keyshare server *jointly* prove knowledge of the number $m$, as follows. We refer to the diagram and use the notation of the [page on zero-knowledge proofs](zkp.md).
-
-* After step 2.2, the user asks the keyshare server to generate its own random $w_k$ and compute $W_k = R^{w_k}$. The keyshare server keeps $w_k$ hidden but sends $W_k$ to the user.
-* The user computes the challenge as $c = H(P, WW_k, \eta)$, and then sends $c$ to the keyshare server.
-* The keyshare server computes $s_k = cm_k + w_k$ and sends this number to the user.
-* Instead of sending $(c,s)$ to the verifier in step 2.5, the user sends $(c, s + s_k)$.
-
-The verifier then uses this tuple to verify the proof of knowledge as it normally would. If both the user and the keyshare server follow the protocol, then the verification equation $c = c'$ will hold, so that the verifier will accept. This is effectively a proof of knowledge of the sum $m = m_u + m_k$, in the sense that the messages going back and forth between the user and verifier have exactly the same structure as they would have if they were a proof of knowledge of $m$ - in fact, to the verifier an execution of this modified protocol is completely indistinguishable from a normal one without a keyshare server. Additionally, the protocol has the following properties:
-
-* The keyshare server essentially proves a normal (i.e., non-Fiat-Shamir heuristic) zero-knowledge proof of $m_k$ to the user. Consequentially, the user learns nothing about the number $m_k$.
-* As the user does not know the number $m_k$ and gains no knowledge of it even through multiple session with the keyshare server, she can impossibly prove knowledge of the sum $m = m_u + m_k$ if the keyshare server refuses to cooperate.
-
-For these reasons this protocol is very well suited for our aims of making the keyshare server's contributions necessary in IRMA sessions, while simultaneously keeping the amount of information that the keyshare server learns about the user, her activities and her attributes as little as possible.
-
-## The protocol
-
-### Overview
-
-We now describe the IRMA keyshare protocol at a high level. When the IRMA app runs for the first time, it registers to the keyshare server, by asking the user for the IRMA PIN that she wishes to use in future sessions, and optionally for her email address. It sends these to the keyshare server. The keyshare server then generates a random username for the user, which is automatically issued to the user as her first attribute. At this point registration is complete in the sense that the user can now receive and disclose attributes. If she entered her email address on registration a confirmation link is sent to it, and if the user clicks on it then the keyshare server issues an email address attribute to the user, and stores the email address.
-
-When performing an IRMA session, the user and keyshare server use the protocol described above to compute a proof of knowledge of the sum $m = m_u + m_k$, with an important addition: when sending the response $s_k$, the keyshare server always includes a digital signature over this number. The keyshare server's public key with which these signatures can be verified is known to all IRMA participants.
-
-Now the IRMA protocol is modified as follows.
-
-* The user authenticates to the keyshare server, by entering her PIN in the IRMA app, which sends it along with the user's username at the keyshare server to the keyshare server. The keyshare server checks if the user is known and if the PIN is correct, and aborts if not.
-* When performing a disclosure or attribute-based signing session, the user engages in the protocol described above with the keyshare server to produce a proof of knowledge of the sum $m = m_u + m_k$, and sends this proof to the verifier.
-* When issuing the user does the same, except for computing and sending the sum $s + s_k$ in the final step of the protocol described above. Instead, the user sends $s$ and $s_k$, along with the keyshare server's signature over $s_k$, separately to the issuer. The issuer then checks the signature over $s_k$, and computes the sum $s + s_k$ which it uses for checking the proof of knowledge.
-
-In this way, the issuer enforces that the user uses the help of the keyshare server in the issuance protocol, and that the resulting credential indeed has $m = m_u + m_k$ as its first attribute. Consequentially, the modified disclosure protocol as described in the second item will succeed, and as the keyshare server's contributions are not directly communicated from the keyshare server to the verifier but only to the user, the keyshare server never learns to whom the user is disclosing attributes.
-
-
-### Registration
-
-When registering, the IRMA app POSTs a message like the one below to the to `/api/v1/client/register` at the keyshare server:
-
-```json
-{
- "email": "example@example.com",
- "language": "en",
- "pin": "0kO3xbCrWMK1336eKzI3KOKWWogGb/oW4xErUd5rwFI=\n",
-}
-```
-
-The email address is optional and may be absent. The `language` indicates the user's preferred language, used for a confirmation mail if the email address is present. Lastly, the `pin` field is computed as `Base64(SHA256(salt, pin))\n` (the trailing newline is there for legacy purposes and will be removed in the future).
-
-### Authentication
-
-During an IRMA session, authenticating to the keyshare server during the protocol between the IRMA client and keyshare server is done as follows. After computing the PIN as `Base64(SHA256(salt, pin))\n`, a message like the following is sent to the keyshare server at `POST /api/v1/user/verify/pin`:
-
-```json
-{
- "id": "FVP1kMRcF2s",
- "pin": "0kO3xbCrWMK1336eKzI3KOKWWogGb/oW4xErUd5rwFI=\n"
-}
-```
-If the PIN is correct for the specified user, then the user has successfully authenticated. The keyshare server then returns an object like the following:
-```json
-{
- "status": "succes",
- "message": ""
-}
-```
-
-Here, `success` indicates to the user that authentication was succesful. The `message` field contains a signed JWT that is used as authentication in the rest of the protocol. This JWT has an expiry of 15 minutes. The contents of this JWT is like the following:
-
-```json
-{
- "iss": "name_of_keyshare_server",
- "sub": "auth_tok",
- "exp": 1523914956,
- "user_id": "FVP1kMRcF2s",
- "iat": 1523914056
-}
-```
-
-### The keyshare protocol
-
-At the start of the keyshare protocol, the client needs to inform the keyshare server which IRMA public keys are involved, in the sense that they are necessary to verify the attributes that are being disclosed. An issuer may have multiple public keys, indexed by integers starting at 0, so the string `"irma-demo.IRMATube-1"` refers to the second public key of the `IRMATube` issuer.
-
-The keyshare server's API endpoints are the following.
-
-* `POST /api/v1/prove/getCommitments`: The client sends a list of public key identifiers (e.g. `["irma-demo.IRMATube-1"]`) to the keyshare server (along with the authentication JWT described above in a HTTP header). If the user is authenticated and the public keys are known to the keyshare server, the keyshare server reacts with a commitment to its part of the secret key, for each of the specified public keys:
-
- ```json
- {
- "c": {
- "irma-demo.IRMATube-1": {
- "P": 121212,
- "Pcommit": 909090,
- }
- }
- }
- ```
- Here `P ` $ = R^{m_k}\mod n$ and `Pcommit ` $=W_k$ is the commitment mentioned above, `Pcommit ` $= W_k = R^{w_k} \mod n$, with $R$ and $n$ coming from the second public key of the `irma-demo.IRMATube` issuer.
-* `POST /api/v1/prove/getResponse`: after calculating the challenge, the client posts it to the keyshare server, who replies with a signed JWT with the following as content:
-
- ```json
- {
- "iss": "name_of_keyshare_server",
- "sub": "ProofP",
- "ProofP": {
- "P": 121212,
- "c": 343434,
- "s_response": 565656
- },
- "iat": 1523914056
- }
- ```
- `s_response` is the response integer $s_k$ in the Schnorr zero-knowledge proof.
-
-This ends the involvement of the keyshare server in the IRMA session. In case of attribute disclosures or attribute-based signatures, the client next merges the keyshare server's contributions `Pcommit` and `s_response` into its proof of knowledge of the secret key. In case of issuance this is skipped; instead the entire JWT from the final endpoint is sent to the issuer alongside the client's own proof of knowledge of its part of the secret key.
-
-The structure of the message in which the client sends the keyshare server's signed response to the issuance session currently unfortunately supports at most one keyshare server simultaneously. This means that it is impossible for two (or more) issuers falling under two distinct scheme managers that use distinct keyshare servers to both issue credential simultaneously to a client (i.e., within one IRMA session). Although this is an unlikely scenario, this will still be fixed in a future version of the protocol. Although all other issuance or disclosure sessions involving multiple keyshare server simultaneously are theoretically already possible, currently no IRMA client yet supports being registered to more than one keyshare server at once.
-
-### Changing the PIN
-
-When the user wants to change her IRMA PIN, she sends a message like the following to `POST /api/v1/user/change/pin`:
-
-```json
-{
- "id": "FVP1kMRcF2s",
- "oldpin": "0kO3xbCrWMK1336eKzI3KOKWWogGb/oW4xErUd5rwFI=\n",
- "newpin": "IjBrTzN4YkNyV01LMTMzNmVLekkzS09LV1dvZ0diL29=\n"
-}
-```
-
-The keyshare server then looks up the user given the specified `id`, and checks if the `oldpin` is correct. If so it changes the user's PIN to the `newpin`, and responds with the following:
-```json
-{"status": "success"}
-```
-(That is, the same JSON message as `POST /api/v1/user/verify/pin` but without an authentication JWT).
-
-In addition to these API endpoints, the keyshare server exposes a number of other endpoints that are used by the [MyIRMA webclient](https://github.com/privacybydesign/irma_keyshare_webclient), which allows the IRMA user to manage her registration at the keyshare server. These endpoints are not documented here.
\ No newline at end of file
diff --git a/website/versioned_docs/version-v0.5.0/overview.md b/website/versioned_docs/version-v0.5.0/overview.md
deleted file mode 100644
index bdeef0b..0000000
--- a/website/versioned_docs/version-v0.5.0/overview.md
+++ /dev/null
@@ -1,184 +0,0 @@
----
-title: Technical overview
-id: version-v0.5.0-overview
-original_id: overview
----
-
-This document presents a technical overview of the IRMA project.
-
-## IRMA terminology
-
-### Participants
-
-* *IRMA app*: (mobile) application that receives attributes, and can disclose them. Also called *client* as it acts as the client in the [IRMA protocol](irma-protocol.md).
-* *Verifier* or *service provider*: a party wanting to verify someone's attributes (in order to provide some service).
-* *Issuer* or *Identity provider*: a party wanting to issue attributes to someone.
-* *Issuer*: uses an Idemix private key in order to issue credentials to a client, when instructed to by an identity provider
-* *Requestor*: the service or identity provider that wants to, respectively, verify someone's attributes or issue attributes to them.
-* *Scheme manager*: distributes Idemix public keys, credential types and issuer information to clients and requestors; also decides which issuers may join its domain and what credential types they may issue.
-
-### Cryptographic entities
-
-* *Attribute*: a small piece of data, generally containing a statement about the attribute owner (e.g., '> 18 years old').
-* *Credential*: a group of attributes, jointly signed by the issuer using an Idemix private key, in an interactive protocol (called the *issuance protocol*) between the issuer and client.
-* *Credential type*: each IRMA credential is an instance of a credential type, which determines the names of the contained attributes, its validity period, and by which issuer the credential is issued.
- * *Singleton credential type*: users can store at most one instance of such credential types in their IRMA app.
-* *Idemix private-public keypair*: a pair of related keys:
- * *Idemix private key*: used by the issuer to sign a credential in the issuance protocol.
- * *Idemix public key*: used by a verifier when attributes are disclosed to it, in order to establish that the disclosed attributes have been signed using the corresponding Idemix private key.
-* *Disclosure proof*: a set of disclosed attributes, along with a proof of knowledge showing that these disclosed attributes originated from a credential that was validly signed by the issuer.
-* [*Attribute-based signature*](#attribute-based-signatures): a digital signature, with IRMA attributes cryptographically attached to it, on some document or message.
-
-### Core software projects
-
-* [IRMA mobile app](irma-app.md): (mobile) application that receives attributes, and can disclose them.
-* [`irma` command](irma-cli.md): contains an IRMA attribute verification and issuance server, scheme management, and more.
-* [irmajs](irmajs.md): javascript library acting as glue between an IRMA server and the requestor's website, allowing the requestor to instruct an API server to issue or verify attributes.
-
-## Overview
-
-IRMA is at its core a set of software projects implementing the Idemix attribute-based credential scheme. An *attribute* is a statement or property about a person, such as "I am over 18 years old" or "my name is John Doe".
-
-These attributes are grouped together in a *credential*. In attribute-based credential schemes such as Idemix, such a credential can be issued to a user by a trusted party called the *issuer*. This issuer creates a digital signature over the credential and its containing attributes using its *private key*. The user receives the credential as well as the issuer's signature in her [IRMA mobile app](irma-app.md).
-
-After that, the user can disclose these attributes to other parties, who are called *verifiers*, selectively showing some and hiding the other attributes from the credential. The verifier then receives the disclosed attributes, as well as a *proof of knowledge* which proves to the verifier that the user
-
-* knows the attributes from the credential which are not being disclosed
-* owns a valid issuer signature over the disclosed attributes and hidden attributes.
-
-The verifier can check the validity of this proof of knowledge using the issuer's *public key* that corresponds with the private key with which the issuer signed the attributes (thus, the verifier must know this public key). The verifier can tell from this that the user has at some point received the disclosed attributes from the trusted issuer. Therefore, it can trust the authenticity of the attributes. (This proof of knowledge does *not* include a full copy of the signature over the attributes, so that even if all attributes of the credential were disclosed simultaneously, the verifier can impossibly use the received attributes and proof of knowledge to disclose these attributes itself to others.)
-
-In addition to attribute disclosure, users can also attach their attributes to messages in an *IRMA attribute-based signature*. This is explained in more detail [below](#attribute-based-signatures).
-
-## Credential types
-
-In IRMA, each credential is an instance of a *credential type*. A credential type specifies (among other things) how many attributes its instances have, what their names are, and by which issuer instances of this credential type are issued. Credential types are not shared between issuers: even if two issuers would issue two credential types with the same name and with the same amount of attributes having the same names, they still are distinct credential types. On [Github](https://github.com/privacybydesign/pbdf-schememanager/blob/master/pbdf/Issues/irmatube/description.xml) an example of such a credential type is available, defining the "IRMATube" credential type which is issued and verified in [this IRMA demo](https://privacybydesign.foundation/demo/irmaTube/). Schematically, an instance of such a credential type would look as follows.
-
-| Attribute name | Attribute value |
-| -------------- | --------------- |
-| **type** | member |
-| **id** | 123456 |
-
-In this table, the right column are the attribute values which are stored and signed in the credential. The left column contains the attribute names from the credential type.
-
-### Singletons
-
-A credential type can be marked as a *singleton* by the scheme manager. If so the IRMA app will store at most one instance of this credential type simultaneously, and receiving a new one would overwrite any older instance. (Example: [`pbdf.nijmegen.bsn`](https://privacybydesign.foundation/attribute-index/en/pbdf.nijmegen.bsn.html)) If a credential type is not a singleton (example: [`pbdf.pbdf.diploma`](https://privacybydesign.foundation/attribute-index/en/pbdf.pbdf.diploma.html)), then the user can have any number of instances of that credential type in her IRMA app.
-
-### Special attributes
-
-#### The metadata attribute
-
-In IRMA, each credential always contains a special attribute called the *metadata attribute*, which must always be disclosed whenever other attributes are disclosed from this credential. This metadata attribute contains:
-
-* which credential type this credential is an instance of (from which it follows by which issuer this credential was issued),
-* the date at which this credential was issued,
-* the expiry date of this credential.
-
-In order to lessen linkability issues (see the [security properties](#irma-security-properties) section below), the issuance and expiry dates are always chosen to fall on the boundary of an *epoch*, which is one week.
-
-#### The secret key attribute
-
-The first attribute of any IRMA credential is always a 256-bit integer which is called the user's *secret key*. The user's IRMA app randomly chooses and stores this integer when it is run for the first time. Whenever it receives a new credential, the app ensures that this number is used as the first attribute, so that all credentials that the app manages share this integer as their first attribute. Contrary to the metadata attribute this attribute is never disclosed; it is even kept hidden from the issuer during issuance. When the user discloses attributes that come from multiple credentials, the proof of knowledge that the IRMA app calculates and sends to the verifier proves multiple facts:
-
-* The app knows a valid issuer signature over each credential from which attributes are currently being disclosed,
-* The first attribute from all of these credentials coincide.
-
-From this the verifier can conclude that the credentials from which attributes are being disclosed belong to one and the same person; that is, it defends against users pooling their credentials.
-
-## Schemes
-
-IRMA schemes are documented on the [Schemes](schemes.md) page.
-
-## Issuers
-
-Each IRMA issuer has an Idemix private key, which it must keep secret as it is used when issuing credentials, and a corresponding public key which is distributed to attribute verifiers and IRMA apps in the IRMA scheme. An issuer may issue multiple credential types (and a scheme may contain many issuers).
-
-Issuers cannot independently create credential types and start issuing them to IRMA app users: the credential type must first be included in an [IRMA scheme](schemes.md) by the scheme manager. In case of the default scheme `pbdf` of the IRMA app, this is the [Privacy by Design Foundation](https://privacybydesign.foundation/issuance/).
-
-When verifying IRMA attributes, out of all possible attributes the verifier could ask for, it must decide which attributes suite its purposes best. In order to be able to make this decision, it is important that for each credential type it is clearly documented how the attributes are obtained, and how it is ensured that they indeed belong to the person that receives them. For each credential type in the `pbdf` scheme, this is documented on the [Privacy by Design Foundation website](https://privacybydesign.foundation/issuance/).
-
-## IRMA PIN codes using the keyshare server
-
-When a user's device containing her IRMA app along with her attributes is lost or stolen, the finder of the phone can potentially abuse the owner's attributes. In order to protect against this, scheme managers may decide to employ an *IRMA keyshare server*. In this case, whenever a credential type that falls under the scheme is used, the user must enter her PIN code before the IRMA session can proceed. The correctness of this PIN code is verified by the keyshare server. When an incorrect PIN code is entered three times in a row, the keyshare server blocks IRMA sessions by refusing to cooperate, for an amount of time that exponentially increases with the amount of consecutive incorrect PIN codes entered. Additionally, users can remotely block their own IRMA app from performing future IRMA sessions on the keyshare server's website, in case their phone is lost or stolen.
-
-The keyshare server's most important function is twofold. It provides a stronger binding of the attributes to their owner, by forcing the correctness of the IRMA PIN code: as long as the user can be trusted to not reveal her PIN code to anyone, the party that receives the attributes can be sure that the person who is disclosing them right now is the same person as the one to which they were issued in the past. Additionally, it provides a way of blocking future IRMA sessions; currently, this feature is only exposed to the users themselves. The price of these advantages is that there is now a single entity that has to cooperate in each IRMA session. This means that whenever the keyshare server is not online, no user can issue or disclose any of the attributes falling under the authority of the relevant scheme. It is thus very important that this component is carefully protected and monitored. Additionally, the keyshare server learns and records a limited amount of data whenever the user performs an IRMA session (how limited this data is is discussed below).
-
-At the Privacy by Design Foundation we believe that the advantages of using a keyshare server far outweigh the disadvantages, so the Foundation's scheme uses a keyshare server. Like all other software, this server is open source.
-
-At a high level keyshare servers work as follows. The user's secret key is split across the user's IRMA app and the keyshare server: both of them hold a part of the secret key. The actual secret key that is effectively used in each credential from this scheme is the sum of these two secret keys. When the user does not enter the correct PIN code the keyshare server will refuse to use its part of the secret key in the IRMA protocol, making it impossible for the session to complete.
-
-In more detail: whenever a scheme is installed in the IRMA app that uses a keyshare server (or when the IRMA app starts for the first time and encounters a hardcoded scheme manager that uses a keyshare server), the user *registers* at the keyshare server, by entering her email address and choosing a PIN code. The IRMA app chooses and stores a random salt of 8 bytes, calculates `SHA256(salt || PIN)`, and sends this along with the user's email address to the keyshare server.
-
-At that moment, the keyshare server chooses and stores a *keyshare* for this user: a 32-bit integer just like the user's secret key. Whenever the users performs an IRMA session using attributes from this scheme, the following happens:
-
-* The IRMA app sends the email address along with `SHA256(salt || PIN)` to the keyshare server. If this hash is not equal to the hash with which the user registered, the keyshare server aborts the session.
-* Assuming the user entered the correct PIN code, the keyshare server generates a proof of knowledge for its part of the user's secret key and sends this to the IRMA app.
-
-What happens next depends on the type of the IRMA session:
-
-* When receiving newly issued attributes, the IRMA app sends the keyshare's proof of knowledge to the issuance server, who first verifies its correctness and authenticity. If correct and authentic, it completes the issuance session in such a way that the actual secret key used in the resulting credential is the sum of both secret keys: that of the user and that of the keyshare server.
-* When disclosing attributes, the IRMA app merges this proof of knowledge with its own proof of knowledge of its own part of the secret key (and the other hidden attributes) in a certain fashion. The result of this is a valid proof of knowledge of the sum of the two secret keys.
-
-Consequentially, it is cryptographically enforced during issuance that the user will need the keyshare server's cooperation whenever she later wants to disclose attributes from the resulting credential. By refusing to cooperate, the keyshare can completely block the user from using her attributes, which is what happens when the user enters an incorrect PIN code too often.
-
-Additionally, the keyshare server comes with a small website on which users can, after logging in with their email address attribute (which they received upon registering at the keyshare server):
-
-* Instruct the keyshare server to block future IRMA sessions, remotely blocking their own IRMA app;
-* Delete their account at the keyshare server (which also blocks future IRMA sessions),
-* View a log of earlier IRMA transactions and PIN code entry attempts.
-
-As the keyshare server's contribution to the proof of knowledge of the secret key is passed to the verifier through the IRMA app instead of directly from the keyshare server to the verifier, the keyshare server does not know to whom attributes are being disclosed. In fact, the only thing it learns is which issuer (and which Idemix public keys) are involved; it does not get to see which attributes are being disclosed nor their values, nor which attributes are kept hidden, nor how many attributes from how many credentials. The transaction log that the user sees in the keyshare server's website is correspondingly bare.
-
-Summarizing, the keyshare server increases the binding between the attributes and the user through the PIN code and through the option of revocation in case of loss or theft, at the cost of a decrease in the decentral nature of IRMA and in some of the privacy guarantees. In order to keep the privacy cost as low as possible, using various cryptographic means we have tried to keep the amount of information that the keyshare server learns about the participants as small as possible. Although we are still looking at ways to make the keyshare server still more privacy-friendly, at the Privacy by Design Foundation we believe that this tradeoff is already worth it. Thus, the `pbdf` scheme indeed uses a keyshare server (towards users we call it ["MyIRMA"](https://privacybydesign.foundation/myirma/)).
-
-Each scheme manager can decide for itself whether or not to use a keyshare server in its scheme. Currently, however, due to a limitation in the IRMA protocol only one keyshare server can be involved simultaneously in IRMA sessions. This will be solved in future new versions of the IRMA app and the IRMA API server.
-
-Full details on the protocol spoken between the IRMA client and an [IRMA keyshare server](https://github.com/privacybydesign/irma_keyshare_server) is documented on the [Keyshare protocol](keyshare-protocol.md) page.
-
-## Attribute-based signatures
-
-Apart from attribute disclosure, IRMA also supports *attribute-based signatures*: a digital signature with IRMA attributes attached to it, on some document or string (more accurately this can generally be any set of bytes, though currently IRMA only support strings). The IRMA app can create such signatures with any of the attributes that it contains. The validity of such a signature can be verified using the Idemix public keys of the issuers of the used attributes, and valid attribute-based signatures can only be created using valid credentials. Contrary to [disclosure proofs](#cryptographic-entities) which are tied to an authentication session, and thus of no more use afterwards, attribute-based signatures are attached to the document that they sign, so their validity is useful as long as the signed document exist. IRMA attribute-based signatures have the same properties as conventional (non-attribute-based) [digital signatures](https://en.wikipedia.org/wiki/Digital_signature) such as non-repudiation, integrity of the signed message, and unforgeability with respect to the issuer private key. In addition, the attributes are cryptographically verifiably attached to the signature and message.
-
-IRMA attribute-based signatures can be used in any case where conventional (digital or conventional "wet") signatures are used and in which it is necessary to know something about the signature creator. For example:
-
-* A doctor could attach his name and "I am a doctor"-attribute to a medical prescription.
-* Teachers could sign student grades with their "I am a teacher"-attribute.
-* If a bank were to issue bank account numbers as an attribute to bank account owners, then a bank account owner could attach her account number attribute to a statement like "I transfer $10 to account 424242", effectively creating a cheque.
-
-Technically, IRMA attribute-based signatures are very similar to disclosure proofs. As mentioned earlier IRMA disclosures use a challenge-response protocol: the verifier generates a random number called the nonce and sends it to the IRMA app, whose response has to take this nonce into account in a precise fashion (this is achieved using the [Fiat-Shamir heuristic](https://en.wikipedia.org/wiki/Fiat%E2%80%93Shamir_heuristic)). More precisely, the disclosure proof is a digital signature on the nonce that was used; if the nonce was freshly generated then the verifier can be sure that the attribute owner is actually present instead of replaying an earlier or eavesdropped disclosure proof. An IRMA attribute-based signature is the same except that not a nonce but an actual message is signed (or rather its SHA256 hash).
-
-Currently IRMA only supports creating attribute-based signatures on strings, although we plan to support other types of documents as well. They can be created using [irmajs](https://github.com/privacybydesign/irmajs) and verified using [IRMA servers](what-is-irma.md#irma-servers) almost the same as disclosure proofs. An online demo is available on the [website of the Foundation](https://privacybydesign.foundation/demo/ondertekenen/).
-
-## IRMA security properties
-
-* **Credential unforgeability:**
- Only the issuer (that is, the holder of the Idemix private key) can issue credentials that will verify under the Idemix public key. Thus when a verifier receives valid attributes, it can safely assume they were issued by the issuer.
-
-* **Multi-show unlinkability:**
- When a verifier performs two IRMA sessions in which the attributes that it receives are identical, then it cannot tell whether the two IRMA sessions were performed with one user who disclosed the same attributes twice, or with two distinct users. In other words, such sessions are not linkable as coming from the same user. (It is important to note that this property holds only at the cryptographic level; using identifying data from the transport layer such as the user's IP or MAC address verifiers can potentially still link sessions.)
-
-* **Grouping credentials using the private key:**
- When attributes are disclosed coming from multiple credentials, the IRMA app additionally proves that the credentials share the same secret key, and thus that the attributes come from the same user.
-
-* **Eavesdroppers cannot perform replay attacks:**
- When verifying attributes, the verifier first sends a number of random bits called the nonce to the IRMA app, and the IRMA app's reply containing the disclosed attributes and the proofs of knowledge has to fit on this nonce in a precise fashion. Assuming that the verifier never reuses nonces, this means that an eavesdropper cannot replay an IRMA disclosure.
-
-* **Verifiers cannot perform replay attacks:**
- Even if all attributes were disclosed (and the secret key is in fact never disclosed), the IRMA app does not send a complete copy of the credential's signature to the verifier; instead parts of it are hidden using proofs of knowledge. This means that verifiers cannot use what they learn in IRMA disclosures to disclose the received attributes to other verifiers, acting as an IRMA app possessing the attributes that were disclosed to it.
-
-* **No impersonation attacks:**
- The credentials and attributes reside in the IRMA app installation of the users. This is contrary to other identity management systems such as for example "Log in with Facebook": when someone presses such a Facebook login button on some website, it is really Facebook who authenticates on that website on behalf of the user. Consequentially, Facebook can potentially authenticate itself as any of its users to such websites. This is not possible in IRMA.
-
-* **No privacy hotspots:**
- When a user discloses IRMA attributes to a verifier, the attributes are sent directly from the user to the verifier without passing through any central party.
-
-It must be mentioned that these properties only hold assuming that our software contains no bugs that break these properties. For this reason all of the IRMA software is open source so that anyone can verify its correctness. We encourage anyone to inspect the IRMA source code, and inform us of any errors that might lessen security or other aspects of the functionality.
-
-## Other resources
-
-* Website of the [Privacy by Design Foundation](http://privacybydesign.foundation/), the creators and maintainers of IRMA
- * An [introduction to IRMA](https://privacybydesign.foundation/irma-start/) for IRMA app users
- * A general and more complete [introduction to IRMA](https://privacybydesign.foundation/irma-explanation/)
- * [Live IRMA demos](https://privacybydesign.foundation/demo-en/)
-* The Android and iOS [IRMA apps](https://privacybydesign.foundation/download-en/)
diff --git a/website/versioned_docs/version-v0.5.0/revocation.md b/website/versioned_docs/version-v0.5.0/revocation.md
deleted file mode 100644
index 9effb94..0000000
--- a/website/versioned_docs/version-v0.5.0/revocation.md
+++ /dev/null
@@ -1,330 +0,0 @@
----
-title: Revocation
-id: version-v0.5.0-revocation
-original_id: revocation
----
-
-
-
-
-Revocation adds to IRMA issuers the ability to revoke a credential that it previously issued to an [IRMA app](irma-app.md), when the contained attributes are no longer accurate. This allows IRMA attribute verifiers to establish that the attributes it received are still factual, as otherwise the credential would have been revoked by the issuer.
-
-This page explains in detail how revocation is implemented in IRMA and what it means to requestors and app users, on three levels:
-* In the first part of the section below, we give a summarizing overview fitting in one page.
-* In the [API section](#api) we give a much more expansive explanation, including the new revocation API for issuers and verifiers.
-* In the [cryptography section](#cryptography) we explain the cryptographic mechanism enabling revocation.
-
-## Overview
-
-Revocation in IRMA is an implementation of the RSA-B scheme from ["Accumulators with applications to anonymity-preserving revocation"](https://eprint.iacr.org/2017/043.pdf) by Baldimtsi et al, which in turn is based on ["Dynamic accumulators and application to efficient revocation of anonymous credentials"](http://static.cs.brown.edu/people/alysyans/papers/camlys02.pdf) by Camenisch et al. Using this scheme the app can prove nonrevocation of its credential in zero-knowledge, preserving [unlinkability of multiple disclosures](overview.md#irma-security-properties) of the attributes within the credential.
-
-In IRMA, revocation is enabled per credential type in the IRMA scheme. If so, when properly configured (more on that [below](#revocation-settings)) the issuer's IRMA server will issue revocation-enabled credentials of that type. During disclosures the IRMA app can then prove nonrevocation (but it will only do so if explicitly asked for by the requestor).
-
-In short, revocation works as follows.
-
-* **Key generation**: The issuer generates an **accumulator** and makes it available to all IRMA participants (i.e. requestors and apps; more on how this is done later). This accumulator changes value whenever the issuer revokes a credential.
-* **Issuance**: If the issuer issues a credential for which revocation is enabled in the scheme, then along with the credential the issuer computes a **nonrevocation witness**, consisting of two large integers. This witness is valid against the issuer's current accumulator (like a signature over a message can be valid against a public key). One of these integers is also included in the credential as a new **revocation attribute** (hidden in de IRMA app GUI), binding the witness to the credential. During issuance, the issuer stores the revocation attribute for this credential in a database for later revocation. The IRMA app stores the witness alongside the credential.
-* **Disclosure**: If the requestor asks for a nonrevocation proof for a given credential type and the app has a revocation-enabled credential instance of that type, then along with the disclosed attributes the client sends to the requestor a **nonrevocation proof**, which proves in zero knowledge to the requestor that the witness of the credential is valid against the issuer's current accumulator. From this the requestor infers that the credential is not revoked.
-* **Revocation**: When the issuer wants to revoke a credential, it first looks up in its database the revocation attribute for that credential that it stored after issuance. Using this, it (1) updates its accumulator to a new value, and (2) makes available to all IRMA participants a **revocation update message**, consisting of the new accumulator and the revocation attribute of the revoked credential. IRMA apps containing (non-revoked) credentials use these update messages to update their witness, so that it becomes valid to the new accumulator. This update algorithm is such that it always fails for the witness of the revoked credential, so that the containing app can no longer prove nonrevocation.
-
-Computing a nonrevocation proof for a credential is much more expensive than just computing a disclosure proof out of that credential. If the user has a revocation-enabled credential then proving nonrevocation is not required; instead she can also just normally disclose attributes from the credential, without using the witness, which is much cheaper. For this reason the app will only prove nonrevocation for a credential type if the requestor explicitly requests it. Requestors should only request nonrevocation proofs when it is really necessary for them to establish that they received nonrevoked attributes.
-
-In the papers linked to above (and generally in the scientific literature on revocation), the party that is able to revoke credentials is called the **revocation authority**, which is not necessarily the same as the party that issues credentials. Within IRMA we have decided to endow the issuer with this responsibility, i.e. the issuer is also the revocation authority for revocation-enabled credential types, because conceptually and technically this simplifies many details.
-
-> In the remainder of this post when we refer to the requestor, issuer, or verifier, we generally refer to the IRMA server software implementing APIs for those parties. The term "IRMA server" itself refers to the following variants of the IRMA server:
-> * The [`irma server`](irma-server.md) daemon.
-> * The [`irmaserver` Go library](irma-server-lib.md).
->
-> Support for revocation will be added to the [bindings of the above library](https://github.com/privacybydesign/irmago/tree/master/server/irmac) to other programming languages soon.
-
-### Revocation updates
-
-Whenever the issuer revokes a credential, updating its accumulator, it publishes a revocation update message as explained above, which apps require to update their witness so that it is valid against the new accumulator. Accumulators are labeled with an index which is increased whenever the issuer makes a new accumulator by revoking. Apps use the index to keep track of against which accumulator their witness is valid in the chain of all past accumulators, and thus how many update messages it needs to obtain and apply. The app requires all of the update messages that it has not already received and applied; if it misses one or more of them it cannot update its witness and it is no longer able to compute nonrevocation proofs for the witness's credential. If that happens but the verifier requires a nonrevocation proof, then the user is unable to disclose attributes from the credential.
-
-It is thus crucial that the set of update messages is always available to each IRMA app. In IRMA, the issuer is responsible for ensuring that all update messages and the latest accumulator are available. To that end, the IRMA server exposes these messages through new HTTP endpoints, if so configured. For each revocation-enabled credential type, at least one URL to such an IRMA server instance must be included within the credential type in the scheme.
-
-If within an IRMA session a requestor requests revocation for a given credential type but the app's witness is out of date (i.e. credentials have been revoked and the accumulator changed value since the app last updated), then before the app can prove nonrevocation it needs to update its witness so that it becomes valid against the latest accumulator. If the app would have to contact the issuer's IRMA server to download updates whenever that happens, then the issuer could infer from its logs that the user is updating probably because she now wants to disclose attributes, harming the user's privacy towards the issuer. In order to prevent this, whenever a requestor requests a nonrevocation proof for a given credential type in a session request, it is required to include the last few revocation update messages for that credential type with the session request. The app uses those to update its witness, if it is not too far behind. The IRMA server will automatically include the required amount of update messages when it sends the session request to the app during the IRMA protocol. (If the app is too far behind then it will need to contact the issuer to download the updates that it did not receive from the requestor in the session request. The IRMA app will do this periodically, i.e. outside of IRMA sessions, for all of its witnesses.)
-
-#### Revocation update chain
-
-Whenever a credential is revoked and the accumulator changes value, the accumulator's index is incremented. If an app has a witness at index $i$ but the current accumulator $\nu_j$ has index $j$, then the app requires $(e_i,\dots,e_j,\nu_j)$ to update its witness to the latest index $j$, where the $e$'s are the revocation attributes of the revoked credentials. As soon as another credential is revoked and the current accumulator becomes $\nu_{j+1}$, the old accumulator $\nu_j$ is no longer needed. Thus the revocation attributes $e_i$ naturally form a chain, always headed with the latest accumulator $\nu_j$.
-
-Each element of this chain (including the head element $\nu_j$) contains the cryptographic hash of its predecessor, and $\nu_j$ is signed by the issuer using ECDSA. Thus this one ECDSA signature signs the entire partial chain $(e_i,\dots,e_j,\nu_j)$: apps and IRMA servers can check its authenticity regardless of its length. This makes it safe for the IRMA app to receive revocation update messages through the requestor in the session request.
-
-Each accumulator $\nu_j$ contains the time of its creation, and every minute this timestamp is refreshed: the accumulator is replaced with a new (signed) accumulator $\nu'_j$ with the same value and index but newer timestamp. To others receiving the updated accumulator, this proves that the issuer's revocation setup is still live. In addition, when verifying an attribute-based signature this makes it possible to establish that the attributes in it were not revoked at creation time of the signature.
-
-A requestor by itself only needs the accumulator $\nu_j$ against which the app has proved nonrevocation in order to verify the proof, and not necessarily the revocation attributes $e_j$ of the revoked credentials. However, they will still fetch a number of these attributes from the issuer's revocation IRMA server in order to pass them on to apps during IRMA sessions.
-
-### Issuer responsibilities
-
-The issuer of a revocation-enabled credential type must:
-
-* Store all revocation update messages in order to be able to offer these to other IRMA participants needing them;
-* Offer the revocation update messages to other IRMA participants through an HTTP API;
-* Store the revocation attribute of each revocation-enabled credential during issuance, as the revocation attribute is necessary during revocation;
-* Revoke a credential when necessary by updating the accumulator and adding a revocation update message.
-
-The IRMA server can handle any or all of the above responsibilies if so configured (see [below](#revocation-settings)).
-
-If the server hosting the revocation update messages is unreachable, then the requestor and app cannot update their accumulator and witness to the latest version. In that case nonrevocation can only be proved against the last known accumulator, from before the issuer's server became unreachable.
-
-> In the event that the issuer's server is unreachable and the requestor's IRMA server cannot update its accumulator to the latest version, then the requestor's IRMA server will accept nonrevocation proofs from the app against its last known accumulator. This results in a time window in which nonrevocation is not guaranteed. If that time window is longer than a configurable maximum the server will report the length of the nonrevocation window to the requestor, but still accept the attributes.
-
-The only possible alternative behaviour would be for the requestor to not accept the attributes, but we want to avoid burdening the user with the consequences of the problem; she would then no longer be able to do whatever she wanted to do with her attributes. Therefore we leave this decision to the requestor. Instead it is the issuer's responsibility to always keep its server online so that this does not happen; and when it does go offline, to restore it as soon as possible. The shorter it is offline, the smaller the "nonrevocation window" and the smaller the problem.
-
-Before revocation is enabled for a given credential type, revocation-specific public and private key material has to be included in the IRMA public and private key of the issuer of the credential type. The [`irma` binary](irma-cli.md) will do so automatically for new keypairs and it can also augment existing keypairs.
-
-#### Scalability
-
-The issuer of a revocation-enabled credential type must always have at least one publically reachable IRMA server running, which is contacted in the following cases.
-* Requestor IRMA servers verifying instances of this credential type will periodically fetch revocation updates (by default every 5 minutes), in order to pass them along to IRMA apps during sessions.
-* IRMA apps also periodically fetch revocation updates to ensure their witness does not become too far outdated (with random time intervals, around 1 day). The average amount of time between two such updates can be configured in the scheme.
-* During a session, if the IRMA app's witness is so far outdated that the update messages provided by the requestor are not sufficient.
-
-The load on this server will increase with the amount of (1) requestors, (2) IRMA apps posessing revocation-enabled credentials, and (3) revocations performed by the issuer. If the load becomes too heavy for one IRMA server, the issuer can do the following:
-* Deploy multiple revocation IRMA servers, with for example a DNS load balancer in front of them, or putting multiple `RevocationServer` URLs in the scheme (see below).
-* Deploying HTTP caching servers in front of the revocation IRMA servers, as it outputs `Cache-Control` HTTP headers on revocation HTTP endpoints that output stable information.
-
-All revocation update messages and accumulators are always digitally signed by the issuer using ECDSA before they are published, and in particular, the entire revocation update chain is signed. This means that other parties than the issuer itself can also run IRMA servers running in revocation server mode for the issuer's credential type. Apart from sharing the load this can also increase uptime.
-
-## API
-
-The addition of revocation to IRMA is designed to be backwards compatible: when revocation is not enabled for a credential type or when a nonrevocation proof is not requested, everything works as it used to; and all of the API changes documented below are additions, adopting the style and conventions of the existing API wherever applicable.
-
-### Scheme
-
-Revocation for a credential type is enabled in the scheme by including at least one `RevocationServer` XML tag and a separate `Attribute` XML tag with a `revocation="true"` attribute inside `description.xml`:
-```xml
-
-
- http://example.com/
-
-
-
-
-
-
-
-
-
-
-```
-See for example [this demo credential type](https://github.com/privacybydesign/irmago/blob/master/testdata/irma_configuration/irma-demo/MijnOverheid/Issues/root/description.xml#L19). Specifying more than one URL allows IRMA requestors and apps to fallback to other URLs when one of them is offline. Once revocation is enabled in the scheme, issuing IRMA servers will automatically issue revocation-enabled credentials. (From this moment the issuing requestor [needs to include](#issuance) `revocationKey`s in its issuance requests, and the issuing IRMA server(s) need to be correctly [configured](#revocation-settings) for revocation.)
-
-Existing credential types can gain support for revocation by adding a `RevocationServer` and adding an attribute with `revocation` enabled.
-
-The IRMA issuer private and public keys used for revocation-enabled credentials must contain revocation-specific key material. When generating new keypairs, `irma issuer keygen` now always includes this. Existing keypairs may be augmented using the new `irma issuer revocation keypair` subcommand.
-
-### Revocation settings
-
-The primary new responsibility for an issuer of a revocation-enabled credential type is to maintain the [revocation update chain](#revocation-update-chain) $(...,e_{i-1},e_i,\nu_i)$. The IRMA server supports a new *revocation mode* for this which can be enabled per credential type by the issuer. At minimum, for each credential type supporting revocation one IRMA server must run in revocation mode for that credential type (publically reachable via its URL in a `RevocationServer` tag in the credential type).
-
-Revocation can be configured in the IRMA server configuration using a new `revocation_settings` map, containing options per credential type. Below is a full example of an IRMA server running in revocation mode for `irma-demo.MijnOverheid.root`.
-
-```json
-{
- "revocation_db": "host=127.0.0.1 port=5432 user=testuser dbname=test password='testpassword'",
- "revocation_db_type": "mysql",
- "no_auth": false,
- "revocation_settings": {
- "irma-demo.MijnOverheid.root": {
- "authority": true
- }
- },
- "requestors": {
- "myapp": {
- "authmethod": "token",
- "key": "mypresharedtoken",
- "issue_perms": [ "irma-demo.MijnOverheid.root" ],
- "revoke_perms": [ "irma-demo.MijnOverheid.root" ]
- }
- }
-}
-```
-
-Note the following:
-* A server running in revocation mode for any credential type requires a SQL database to be configured. In this database all revocation state will be stored. Currently MySQL and Postgres are supported.
-* This configuration also grants permission to a requestor called `myapp` to issue and revoke `irma-demo.MijnOverheid.root` instances. Alternatively, if `no_auth` would be `true` then any requestor capable of reaching the server could issue and revoke instances (in production settings, such a server should not be publically reachable).
-
-For each credential type revocation settings may be specified in the `revocation_settings` block as above. The following specifies all possible options and their defaults.
-```json
-{
- "server": false,
- "authority": false,
- "revocation_server_url": "",
- "tolerance": 600,
- "sse": false
-}
-```
-The options are as follows.
-* `server` enables endpoints used by IRMA apps and other IRMA servers to fetch part of the revocation update chain.
-* `authority` implies `server` and additionally enables (1) an endpoint required by issuing IRMA servers to send **issuance records** to for each issued credential, required for later revocation of the credentials; and (2) an endpoint accepting revocation requests (subject to the server's requestor authentication configuration).
-* `revocation_server_url`, if present, overrides the `RevocationServer` URL from the credential type in the scheme. In the following cases, this must point to an `authority` IRMA server:
- - If `server` is true but `authority` is false (in this case, revocation updates are fetched from here);
- - If this server will issue instances of the current credential type, and `authority` is false (otherwise it just stores the records locally).
-* `tolerance`: at the latest, the nonrevocation guarantee provided by the IRMA app lasts until the moment that it first connected to the IRMA server in the current session (see [below](#disclosure)). If during an IRMA session this time window is more than `tolerance` seconds, then it will be reported back to the requestor (who may then decide to accept the attributes or abort).
-* `sse`: if `true` then the IRMA server will attempt to open a [Server Sent Events](https://en.wikipedia.org/wiki/Server-sent_events) channel to the revocation server (as specified by either the scheme or `revocation_server_url`). If successful, the revocation server will push new revocation updates to the IRMA server as it creates them (instead of the IRMA server having to periodically fetch then). Note that the revocation server may have disabled SSE support, and (forward) proxies sitting between the current server and the revocation server may break SSE channels. If enabled, it should always be tested that it works.
-
-Note that the `RevocationServer` URL from the credential type must point to a publically reachable IRMA server with `server` enabled for the credential type. This IRMA server must be online at all times. It does not need to have `authority` enabled (if not, the issuer will need at least one other server for which `authority` is enabled, as only those servers can write to the revocation chain).
-
-The example IRMA server configuration above is the minumum setup enabling revocation for `irma-demo.MijnOverheid.root`, with one server handling everything. A more elaborate setup could be as follows (using schematic example URLs without `https://`).
-
-| URL | Public | Configuration |
-|----------|--------|------------------------------------------------------------------|
-| `issuer` | yes | `{"revocation_server_url": "auth"}` |
-| `rs` | yes | `{"server": true, "revocation_server_url": "auth", "sse": true}` |
-| `auth` | no | `{"authority": true}` |
-
-The middle column indicates whether or not the server needs to be publically reachable. This setup assumes that `rs` and `auth` use distinct SQL databases. The URL of `rs` must be included as the `RevocationServer` in the scheme. Enabling `sse` in `rs` ensures its revocation state remains up to date with the authority `auth`. This setup avoids that the issuance record endpoint and revocation endpoint are exposed to the internet, and also allows scaling `rs` to multiple instances to share the load if required.
-
-### Issuance
-
-When issuing a revocation-enabled credential to a user, the issuer includes a `revocationKey` for each credential in the session request. For example:
-```json
-{
- "@context": "https://irma.app/ld/request/issuance/v2",
- "credentials": [{
- "credential": "irma-demo.MijnOverheid.root",
- "attributes": { "BSN": "12345" },
- "revocationKey": "bsn-12345"
- }],
-}
-```
-
-The state that would be needed during revocation (in particular, the revocation attribute of this credential) is stored in the database with the `revocationKey` acting as primary key: when later this credential needs to be revoked the issuer can refer to it out of all issued credentials using its `revocationKey`.
-
-Note that the issuance IRMA server must be [configured](#revocation-settings) with the URL to the authoritative revocation server.
-
-### Disclosure
-
-Requestors can request nonrevocation proof for a given credential type by including it in the new `revocation` array in the session request:
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "irma-demo.MijnOverheid.root.BSN" ]]],
- "revocation": [ "irma-demo.MijnOverheid.root" ]
-}
-```
-This instructs the IRMA server to only accept the attributes if the app includes a valid nonrevocation proof for all instances of `irma-demo.MijnOverheid.root` out of which it discloses attributes. If a credential type is not listed there and the app has a revocation-enabled credential of that type, then it will not include a nonrevocation proof.
-
-Since attribute disclosures can occur during [any of the three session types](session-requests.md#disclosure-requests) (disclosure, attribute-based signatures, issuance), the `revocation` key can be included in the session requests of any type.
-
-The IRMA server of the requestor obtains new revocation update messages from the `RevocationServer` specified in the credential type in the scheme in one of two possible ways: either through a Server Sent Events channel so that the server is always up to date, or by periodically fetching. Either way, when the IRMA app connects to the IRMA server (e.g. after scanning the QR code), for each credential type of which nonrevocation proofs are requested in the session request, the server looks up in its own memory or database (1) the last accumulator that it knows and (2) a certain amount of the most recent update messages, and it includes these in the session request that it sends to the IRMA app.
-
-The server will accept the nonrevocation proof of the app if the proof is valid against either the accumulator that it included in the session request, or a newer one. The app always includes the accumulator against which it proved nonrevocation with the nonrevocation proof, so that during verification it is never necessary to retrieve accumulators from the issuer; by including the accumulator the response of the app contains all information required to verify it.
-
-When reporting verified attributes for which the app proved nonrevocation to the requestor at the end of the session, the corresponding entry in the [`SessionResult`](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult) might look as follows.
-
-```json
-{
- "disclosed": [
- [
- {
- "rawvalue": "299792458",
- "id": "irma-demo.MijnOverheid.root.BSN",
- "status": "PRESENT",
- "issuancetime": 1583366400,
- "notrevoked": true
- }
- ]
- ]
-}
-```
-The `notrevoked` boolean indicates that the app proved nonrevocation of this attribute.
-
-The IRMA app proves nonrevocation against a certain accumulator which it includes in its response to the IRMA server. The verifying IRMA server determines which accumulator this must be when the app first connects to it, by choosing the latest one that it knows of and sending it to the app in the session request.
-
->The nonrevocation guarantee inferrable from an IRMA app's nonrevocation proof lasts only until the creation time of the accumulator used by the app.
-
-If the age of the accumulator is greater than a configurable value called `tolerance` (see [above](#revocation-settings)), then this age will be reported alongside `notrevoked` (which remains `true`). This can happen in the following cases:
-* The IRMA app user took longer over deciding whether or not to perform the session than the `tolerance`;
-* The issuer's revocation IRMA server is offline and no updates can be retrieved.
-
-When signing the newest accumulator the issuer always includes the current time, and as mentioned earlier, when disclosing attributes (or when constructing an attribute-based signature), the IRMA app includes the accumulator against which it proves nonrevocation in its disclosure (or attribute-based signature). In case of signatures, this means that by checking that the accumulator time is sufficiently close to the time in the timestamp of the signature, it can be established that the attributes were not revoked at the moment the attribute-based signature was created. The attribute-based signature by itself is sufficient to establish this; i.e., it is not necessary to contact either the issuer or timestamp server during verification.
-
-If during disclosure the requestor asks for a nonrevocation proof of a given credential type, but the app only posesses credentials of that type that do not support revocation (i.e., no witnesses were included with them during issuance), then the app will abort as it is not able to fulfill the requestor's request.
-
-IRMA apps can disclose attributes out of revocation-aware credentials even to non-revocation aware IRMA servers. In this case only knowledge of the revocation attribute $e$ is proved.
-
-### Revocation
-
-The API that the IRMA server exposes for revoking previously issued credentials is similar to the API for starting and managing IRMA sessions:
-* A new revocation endpoint is available as a function on the [`irmaserver` Go library](irma-server-lib.md), and as a corresponding HTTP endpoint in the `irma server`.
-* Similar to session request data structures, (e.g. [`DisclosureRequest`](https://godoc.org/github.com/privacybydesign/irmago#DisclosureRequest)), revocation is initiated at the `irma server` by a [`RevocationRequest`](https://godoc.org/github.com/privacybydesign/irmago#RevocationRequest) data structure identified as such by a [JSON-LD](https://json-ld.org/) `@context` tag (having constant value `https://irma.app/ld/request/revocation/v1`).
-* As with ordinary session requests, when the `no-auth` setting is disabled in the `irma server` configuration this request has to be authenticated using one of the [existing authentication methods](irma-server.md#requestor-authentication) (i.e., by including a preshared `token` in an HTTP header or by signing the request into a JWT using `hmac` or `publickey`).
-* Each requestor configured in the `irma server` can be endowed with permission to revoke specific credential types (possibly in addition to [permissions to issue or verify attributes](irma-server#permissions)). If `no-auth` is disabled, and the revocation request can be succesfully authenticated as originating from a requestor present in the `irma server` configuration, and that requestor is authorized to revoke the credential type mentioned in the request, then the revocation command is executed and the credential is revoked.
-
-For example, the following `RevocationRequest` instructs the server to revoke the `irma-demo.MijnOverheid.root` instance to which it previously assigned `bsn-12345` as `revocationKey` during issuance, and which was issued at Unix nano timestamp `1583765731750425000`. If `issued` is not specified, all previously issued credentials with matching `revocationKey` are revoked.
-
-```json
-{
- "@context": "https://irma.app/ld/request/revocation/v1",
- "type": "irma-demo.MijnOverheid.root",
- "revocationKey": "bsn-12345",
- "issued": 1583765731750425000
-}
-```
-
-## Cryptography
-
-The IRMA issuer private key is $(p', q')$ where $p', q'$ are both [safe primes](https://en.wikipedia.org/wiki/Safe_prime): if written as $p' = 2p+1$ and $q' = 2q+1$, then $p$ and $q$ are also prime. The issuer uses this private key for issuing attributes as well as for revoking. The corresponding IRMA issuer public key contains the modulus $n = p'q'$. This modulus defines the group $QR_n = ((\mathbb{Z}/n\mathbb{Z})^*)^2$ of quadratic residues within the multiplicative integers modulo $n$, in which both the Idemix and the revocation cryptography takes place. For signing various revocation related messages the issuer additionally generates an ECDSA private/public keypair. These are included in the existing IRMA private/public keys.
-
-### Issuance
-The current accumulator is a number $\nu \in QR_n$. The first accumulator is randomly chosen by the issuer from $QR_n$. During issuance, the issuer
- 1. generates a prime $e$,
- 2. embeds the prime $e$ as an attribute within the credential being issued,
- 3. uses its private key to compute $u = \nu^{1/e\bmod pq}$, and sends the tuple $(u,e)$ to the app along with the credential,
- 4. stores the number $e$ in a database for later revocation.
-
-### Disclosure
-The revocation witness is the tuple $(u, e)$. By definition it is valid only if $u^e = \nu \bmod n$. When using revocation, the app now proves the following to the verifier:
-* "I possess a valid credential containing the disclosed attributes as well as an undisclosed attribute $e$."
-* "I know a number $u$ which is such that $u^e = \nu \bmod n$."
-
-The app proves this in zero-knowledge, meaning that the verifier can infer nothing from this proof except the above two facts. In particular, the proof hides the undisclosed attributes as well as $u$ and $e$. This provides unlinkability, as it ensures that a later session using the same credential and same witness cannot be linked to earlier ones (before or after the credential has been revoked). From the fact that the witness is valid, the verifier infers that the witness's credential is not revoked.
-
-The app includes the accumulator $\nu$ signed by the issuer against which it proved nonrevocation with its nonrevocation proof. The verifier accepts if this included accumulator is validly signed by the issuer; if the nonrevocation proof is valid against that accumulator; and if the accumulator is the same or newer than its own copy.
-
-### Revocation
-Henceforth, we label the current accumulator and witnesses with an index $i$, so the current accumulator value is $\nu_i$. If the issuer wants to revoke a credential it first looks up in its database the revocation attribute $\tilde{e}$ that it used for that credential (we use a tilde to distinguish this $\tilde{e}$ from the revocation attributes $e$ of other apps wanting to update their own (nonrevoked) witness, see below). Then it uses its private key to compute the new accumulator value as follows:
-
- $\displaystyle \nu_{i+1} = \nu_{i}^{1/\tilde{e}\bmod pq}$
-
-The update message consists of $(\nu_{i+1}, \tilde{e})$; the issuer signs this using its ECDSA private key and then offers it to others using an HTTP API. Apps and requestors only use update messages if it is validly signed, confirmed using the ECDSA public key of the issuer of the credential type.
-
-Apps having a (nonrevoked) credential with witness $(u_i, e)$ (satisfying $u_i^{e} = \nu_i$) first compute the numbers $a, b$ which are such that $ae + b\tilde{e} = 1$, using the [Extended Euclidean algorithm](https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm), and then they update their witness as follows:
-
- $\displaystyle u_{i+1} = u_i^b\nu_{i+1}^a$
-
-This is valid against the new accumulator $\nu_{i+1}$:
-
-
-$
- \begin{eqnarray*}
- u_{i+1}^{e}
- &=& (u_i^b\nu_{i+1}^a)^{e}
- = u_i^{be}\nu_{i+1}^{ae} \\
- &=& \nu_i^{b}\nu_{i}^{ae/\tilde{e}}
- = (\nu_i^{b\tilde{e}}\nu_{i}^{ae})^{1/\tilde{e}}
- = (\nu_i^{b\tilde{e}+ae})^{1/\tilde{e}} \\
- &=& \nu_i^{1/\tilde{e}}
- = \nu_{i+1}
- \end{eqnarray*}
-$
-
-
-(The $\bmod n$ after each equality sign is implied.) The revoked credential having revocation attribute $\tilde{e}$ cannot use this algorithm and update message $(\nu_{i+1}, \tilde{e})$ to compute a new witness, as in this case there exist no integers $a, b$ such that $a\tilde{e} + b\tilde{e} = 1$. In fact, [one can prove that](http://static.cs.brown.edu/people/alysyans/papers/camlys02.pdf) knowing only $\nu_i$, $\nu_{i+1} = \nu_{i}^{1/\tilde{e}}$ and $\tilde{e}$, by the [Strong RSA assumption](https://en.wikipedia.org/wiki/Strong_RSA_assumption) which is used by both Idemix and the RSA-B accumulator scheme, *no* efficient algorithm can compute the correct witness $u_{i+1} = \nu_{i+1}^{1/\tilde{e}} = \nu_{i}^{1/\tilde{e}^2}$.
-
-Thus the app owning the revoked credential has no way to compute a new witness on its own without the issuer private key. Since the app no longer posesses a valid witness, it can no longer prove that it does, i.e., construct a nonrevocation proof: the credential is revoked.
diff --git a/website/versioned_docs/version-v0.5.0/schemes.md b/website/versioned_docs/version-v0.5.0/schemes.md
deleted file mode 100644
index 9a82ec7..0000000
--- a/website/versioned_docs/version-v0.5.0/schemes.md
+++ /dev/null
@@ -1,250 +0,0 @@
----
-title: IRMA schemes
-id: version-v0.5.0-schemes
-original_id: schemes
----
-
-In IRMA, every party ([IRMA apps](irma-app.md), [IRMA servers](what-is-irma.md#irma-servers), [requestors](overview.md#participants)) must be aware of existing [credential types](overview.md#credential-types), attribute names, and the [issuers](overview.md#issuers) and their public keys. All such information is contained in IRMA *schemes*. It is the task of the *scheme manager* to determine and distribute this information to all parties, in the form of a directory structure [such as this one](https://github.com/privacybydesign/pbdf-schememanager), which contains:
-
-* All information about all issuers that fall under this scheme including their logos,
-* The IRMA public keys of said issuers,
-* All credential types that these issuers may issue, including their logos.
-
-This entire directory structure is signed using an (ECDSA) private-public keypair that the scheme manager has for this purpose.
-
-Each scheme has a *scheme URL*, defined by the `` tag in the root `description.xml`. At that location the scheme manager must host the current version of the scheme. IRMA components that have the scheme installed will periodically update their local version of the scheme using this remote copy.
-
-All of the information contained in the scheme is thus signed by as well as distributed by the scheme manager. This means that the scheme manager has exclusive and total control over which issuers may join his domain, and what credential types and attributes this issuer may issue.
-
-## Scheme contents
-
-Schematically the directory structure of a scheme looks as follows:
-
-```text
-scheme-id
-├── issuer-id
-│ ├── Issues
-│ │ └── credentialtype-id
-│ │ ├── description.xml
-│ │ └── logo.png
-│ ├── PublicKeys
-│ │ ├── 0.xml
-│ │ └── 1.xml
-│ ├── PrivateKeys (need not be present)
-│ │ ├── 0.xml
-│ │ └── 1.xml
-│ ├── description.xml
-│ └── logo.png
-├── description.xml
-├── index
-├── index.sig
-├── timestamp
-├── pk.pem
-└── kss-0.pem
-```
-
-Multiple issuers are grouped under the scheme, and each issuer may issue multiple credential types.
-
-Description of the files:
-* A scheme, issuer, or credential type (call it an *entity*) is always stored in `description.xml`, contained in a folder whose name *must* be that of the entity as specified by the xml file.
-* Each issuer and each credential type should include a `logo.png` for in the IRMA app.
-* `index` contains of each file in the tree its SHA256 hash, as well as its path and filename.
-* `index.sig` is an ECDSA signature over the `index`, thus effectively signing each file listed in the `index`.
-* `timestamp` contains the Unix timestamp of the last time the scheme was modified.
-* `pk.pem` is the scheme's public key against which `index.sig` should verify.
-* `kss-0.pem` (optional): if the scheme uses a [keyshare server](keyshare-protocol.md), then this contains the keyshare server's public key.
-
-IRMA schemes have the following nested structure: a scheme contains (multiple) issuers, which contain (multiple) credentials, which contain (multiple) attributes. Each of these are identified and referred to using a string that we call the *identifier*. In the case of schemes, issuers and credentials, these can be seen in the directory structure. In the directory tree above:
-
-* The identifier of the scheme is `scheme-id`,
-* This scheme contains an issuer whose identifier is `issuer-id`,
-* This issuer contains a credential type whose identifier is `credentialtype-id`.
-
-The `description.xml` of a credential type contains the definitions, including their identifiers, of the attributes contained within that credential type.
-
-These identifiers are used to refer to these entities within [IRMA session requests](session-requests.md), joined together using a dot `.` as separator. For example, the `description.xml` [below](#credential-types) shows the definition of the credential type `credentialtype-id` included in the directory tree above. This file contains an attribute whose identifier, as defined by the `id` XML attribute, is `boolean-attr`. Then the following would be a valid IRMA disclosure request that requests an IRMA app user to disclose this attribute:
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "scheme-id.issuer-id.credentialtype-id.boolean-attr" ]]]
-}
-```
-
-```golang
-irma.NewDisclosureRequest(irma.NewAttributeTypeIdentifier(
- "scheme-id.issuer-id.credentialtype-id.boolean-attr",
-))
-```
-
-
-IRMA identifiers may not themselves contain dots. Generally, only alphanumeric characters and the dash `-`are used.
-
-## File contents
-
-### Scheme
-
-The `description.xml` of a scheme looks like the following.
-
-```xml
-
- scheme-id
- https://example.com/scheme
- true
-
- English human-readable name
- Nederlandse human-readable naam
-
-
- A description of this scheme
- Een beschrijving van dit scheme
-
- https://example.com/atumd
- https://example.com/keyshareserver
- https://example.com/myirma
- scheme-id.issuer-id.credential-id.keyshare-attr
- https://example.com
-
-```
-
-* The `version` XML attribute of the `` tag is a constant, versioning the XML structure in the file.
-* The identifier of the issuer is specified by the `` tag (`scheme-id` in this example).
-* The `` tag points to the location where an online copy of this scheme is hosted, from which IRMA apps and servers update their local copies.
-* The `` tag, containing `true` or `false`, defines whether this is a demo or a production scheme. When `true`, the human-readable names (i.e., the contents of the `` tags) of all issuers and credential types within the scheme are required to start with the prefix `Demo `, and some requirements checked by `irma scheme verify` and `irma scheme sign` are slightly relaxed.
-* The `` defines which timestamp server is used for [attribute-based signatures](session-requests.md#attribute-based-signature-requests) that contain attributes from this scheme.
-* The ``, ``, and `` tags, when present, enable the use of a [keyshare server](keyshare-protocol.md) for this scheme, and define the URL of the keyshare server; the URL of the MyIRMA webinterface for it; and which attribute is used by the keyshare server, respectively.
-
-### Issuers
-
-The `description.xml` of an issuer looks like the following.
-
-```xml
-
- issuer-id
-
- English human-readable name
- Nederlandse human-readable naam
-
-
- English name
- Nederlandse naam
-
- scheme-id
- https://example.org
- example@example.org
-
-```
-
-* The `version` XML attribute of the `` tag is a constant, versioning the XML structure in the file.
-* The identifier of the issuer, specified by the `` tag (`issuer-id` in this example), must equal the folder name in which the file is stored.
-* The `` tag must contain the identifier of the containing scheme.
-* The `` tag should be present but is not currently shown in the IRMA app GUI or elsewhere.
-
-### Credential types
-
-The `description.xml` of a credential type looks like the following.
-
-```xml
-
-
- English human-readable name
- Nederlandse human-readable naam
-
-
- English name
- Nederlandse naam
-
- scheme-id
- issuer-id
- credential-id
-
- A description of this credential type
- Een beschrijving van dit credentialtype
-
-
- https://example.com/issue-url/en
- https://example.com/issue-url/nl
-
- true
-
-
-
-
- Boolean attribute
- Boolean attribuut
-
-
- A description of this boolean attribute
- Een beschrijving van dit boolean attribuut
-
-
-
-
- Optional attribute
- Optioneel attribuut
-
-
- A description of this optional attribute
- Een beschrijving van dit optionele attribuut
-
-
-
-
-```
-
-* The `version` XML attribute of the `` tag is a constant, versioning the XML structure in the file.
-* The identifier of the credential type, specified by the `` tag (`credential-id` in this example), must equal the folder name in which the file is stored.
-* The `` tag must contain the identifier of the containing issuer.
-* The `` tag must contain the identifier of the containing scheme.
-* The `` and `` tags should be present but are not currently shown in the IRMA app GUI or elsewhere.
-* The `` tag should contain translated URLs referring to where the user can obtain this credential. If the user refreshes an instance of the credential type, or tries to obtain it during a session, this URL is used.
-* The `` tag should contain either `true` or `false`, and determines if the user is allowed to possess more than one instance of the credential type simultaneously in her IRMA app. Default is `false`.
-
-An attribute is defined by an `` XML tag, which must at minimum contain an identifier in the `id` XML attribute, and `` and `` XML subtags. Additionally, the following XML attributes are supported:
-
-* `displayIndex`: Once an `` has been added to the credential type, its position relative to the other `` XML tags cannot be changed. However, its position as shown in the IRMA app may be set using the `displayIndex` XML attribute. In the example above, the IRMA app will first show the `optional-attr` and then the `boolean-attr`. If not present, the value of `displayIndex` is inferred from its position within the `` XML tag.
-* `optional`: if `true`, the issuer [may skip this attribute during issuance](session-requests.md#null-attributes), for example when the value of the corresponding attribute is unknown or not applicable.
-* `displayHint="yesno"`: used to indicate that the attribute will contain boolean values such as `yes`, `no`, `ja` or `nee` (case insensitive). When present, the IRMA app will translate the boolean to the user's language.
-
-New attributes can be added to existing credential types at any point in time. Existing attributes within a credential type may not be removed once they exist, but they may be marked `optional` so that the issuer can skip them during issuance.
-
-## Default schemes: `pbdf` and `irma-demo`
-
-Most IRMA software components automatically use the following two schemes:
-
-* [`pbdf`](https://github.com/privacybydesign/pbdf-schememanager): the production scheme of the [Privacy by Design Foundation](https://privacybydesign.foundation/).
-* [`irma-demo`](https://github.com/privacybydesign/irma-demo-schememanager): exclusively for development, demoing and experimenting, as the scheme private key and all issuer private keys are included.
-
-The [Privacy by Design Foundation](https://privacybydesign.foundation/), which develops IRMA and issues a basic set of attributes, is the scheme manager of these two schemes. New issuers wishing to issue attributes under the `pbdf` scheme, or existing issuers wishing to issue new credential types, can [ask](https://privacybydesign.foundation/people#developers) the Foundation to be included in these schemes.
-For more information on this process, see the [issuer documentation page](issuer.md).
-
-These two schemes are hardcoded into the [IRMA app](irma-app.md), and if an [`irma`](irma-cli.md) subcommand that requires schemes is run for the first time, these two schemes are downloaded to a default location on disk (`~/.local/share/irma/irma_configuration` on Linux/macOS). It is always possible to use other schemes in conjunction with these two, or without them, either by making a custom build of the IRMA app, or by passing the appropriate options to the `irma` subcommands (see the `--help` messages).
-
-
-## Updating and signing schemes with `irma`
-
-The following `irma scheme` subcommands from the [`irma`](irma-cli.md) command line tool act on IRMA schemes:
-
-* `download`: Download a scheme from its remote URL
-* `issuer`: Manage IRMA issuers within an IRMA scheme
- * `keygen`: Generate a new IRMA issuer private/public keypair
-* `keygen`: Generate ECDSA private/public keypair for scheme signing
-* `sign`: Sign a scheme directory after update its contents
-* `update`: Download scheme updates from its remote URL
-* `verify`: Verify scheme signature and check directory structure
-
-Check `-h` or `--help` of these for usage details.
-
-## Other schemes
-
-Anyone can create their own IRMA scheme. At minimum the following must be done:
-
-* Create a directory structure like the one above (you can use the `scheme` subcommand of the [`irma`](irma-cli.md) command line tool to generate an ECDSA public-private keypair and sign the directory tree);
-* Define at least one issuer and generate its Idemix public-private keypair (again using `irma`), putting the public key in the directory structure;
-* Define at least one credential type that this issuer will issue;
-* Compile a version of the IRMA app with this directory tree hardcoded in it;
-* Host an [`irma server`](irma-server.md) that will issue and verify your credential type (as this server will issue credentials it must have a copy of the scheme directory tree, and the Idemix private key);
-* Create a website using [`irma-frontend`](irma-frontend.md) that will issue and verify instances of your credential type.
-
diff --git a/website/versioned_docs/version-v0.5.0/session-requests.md b/website/versioned_docs/version-v0.5.0/session-requests.md
deleted file mode 100644
index 6974f2c..0000000
--- a/website/versioned_docs/version-v0.5.0/session-requests.md
+++ /dev/null
@@ -1,459 +0,0 @@
----
-title: Session requests
-id: version-v0.5.0-session-requests
-original_id: session-requests
----
-
-
-
-Each [IRMA server](what-is-irma.md#irma-servers) exposes APIs for creating IRMA sessions with a session request. An *IRMA session request* contains all information required for the IRMA server and [IRMA app](irma-app.md) to perform an IRMA session with, such as the attributes to be issued or verified. This page documents IRMA session requests. It applies to:
-
-* The [`POST /session`](api-irma-server.md#post-session) endpoint from [`irma server`](irma-server.md).
-* The [`StartSession()` function](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver#StartSession) in the `irmaserver` Go library.
-* The [`startSession()` function](api-irmajs.md#startsession) of `irmajs`.
-
-For the precise role of session requests in an IRMA session, see this [diagram of an IRMA session](what-is-irma.md#irma-session-flow).
-
-## Session request data types
-
-For each of the [three IRMA session types](what-is-irma.md#session-types), we define a *session request* data type: an object whose JSON representation contains at least a [JSON-LD `@context`](https://w3c.github.io/json-ld-syntax/#the-context) key identifying which message type it is, and extra keys specific to the session type. The following three `@context` values identify disclosure, attribute-based signature, and issuance session requests respectively:
-
-* `"@context": "https://irma.app/ld/request/disclosure/v2"`
-* `"@context": "https://irma.app/ld/request/signature/v2"`
-* `"@context": "https://irma.app/ld/request/issuance/v2"`
-
-(For now these URIs do not resolve to anything; they just distinguish the message type.)
-
-## Disclosure requests
-Disclosure sessions are started with an [`irma.DisclosureRequest`](https://godoc.org/github.com/privacybydesign/irmago#DisclosureRequest). Example:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.MijnOverheid.root.BSN" ]
- ],
- [
- [
- "irma-demo.nijmegen.address.street",
- "irma-demo.nijmegen.address.houseNumber",
- "irma-demo.nijmegen.address.city"
- ],
- [
- "irma-demo.idin.idin.address",
- "irma-demo.idin.idin.city"
- ]
- ]
- ]
-}
-```
-
-```golang
-// Create a new empty request
-request := irma.NewDisclosureRequest()
-
-// Request specific attributes
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.root.BSN")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.nijmegen.address.street"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.houseNumber"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.city"),
- },
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.idin.idin.address"),
- irma.NewAttributeRequest("irma-demo.idin.idin.city"),
- },
- },
-}
-```
-
-
-
-
-This asks for a (demo) `BSN` attribute, as well as either `street`, `houseNumber` and `city` from `irma-demo.nijmegen.address`, or `address` and `city` from `irma-demo.idin.idin`. The three levels correspond to a *conjunction* of *disjunctions* of *conjunctions* of requested attributes, allowing verifiers to request multiple attribute sets from the user, offering choices for some or all of these sets.
-
-All of the attribute types (i.e., the string values) contained in the request must exist in their scheme ([`irma-demo`](https://github.com/privacybydesign/irma-demo-schememanager) in the example above). For the `irma-demo` and `pbdf` schemes, an index of existing attribute types that can be requested can be found [here](https://privacybydesign.foundation/attribute-index/en/).
-
-> Attributes can be disclosed to the requestor in any of the three session types: in issuance sessions issuance proceeds only if the user discloses the required attributes just before issuance, and in attribute-based signature sessions the requested attributes are attached to the resulting attribute-based signature. Thus the `disclose` and `labels` fields introduced above can also occur in issuance or attribute-based signature session requests (see below).
-
-### Multiple credential types within inner conjunctions
-In the request above 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).
-- 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 IRMA app automatically only offers candidate sets as choices to the user that satisfy this property.)
-
-For example, consider the following session request:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- "pbdf.pbdf.diploma.degree",
- "pbdf.pbdf.diploma.institute"
- ]
- ]
- ]
-}
-```
-
-```golang
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("pbdf.pbdf.diploma.degree"),
- irma.NewAttributeRequest("pbdf.pbdf.diploma.institute"),
- },
- },
-}
-```
-
-
-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.)
-
-When combining multiple credential types within a disjunction these restrictions ensure that when the IRMA app computes candidate attribute sets for the user to choose from, the amount of resulting options stays manageable. In adddition, the second restriction is a feature on its own, allowing verifiers to request multiple attributes coming from one credential instance.
-
-### Requesting specific attribute values
-Within inner conjunctions, specific attribute values can be requested by replacing the string with an object like the following:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "pbdf.pbdf.diploma.degree", "value": "PhD" },
- { "type": "pbdf.pbdf.diploma.institute", "value": null }
- ]
- ]
- ]
-}
-```
-
-```go
-phd := "PhD"
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.degree"),
- Value: &phd,
- }, {
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.institute"),
- Value: nil,
- }},
- },
-}
-```
-
-
-This would only be satisfied by a `degree` attribute whose value is `PhD`, together with any `institute` attribute. (Note that the object and string syntaxes can be mixed within an inner conjunction, i.e. it would be permissible in the JSON example above to replace the second object with just `"pbdf.pbdf.diploma.institute"`.)
-
-### Null attributes
-
-Whenever an attribute is marked with `optional` in the scheme ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)), the issuer may skip it when it issues an instance of the containing credential type, assigning a `null` value to it (which is distinct from the empty string `""`). When disclosing the attribute, the verifier receives `null` instead of a string containing the attribute value.
-
-If a non-null attribute is required this can be requested using `notNull` as follows:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "irma-demo.MijnOverheid.fullName.prefix", "notNull": true }
- ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("irma-demo.MijnOverheid.fullName.prefix"),
- NotNull: true,
- }},
- },
-}
-```
-
-
-The default value of `notNull` is `false`.
-
-### Optional disjunctions
-
-A disjunction within a session request can be marked as *optional*, by including an empty inner conjunction in it:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.nijmegen.address.city" ]
- ],
- [
- [],
- [ "irma-demo.MijnOverheid.fullName.firstname" ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.nijmegen.address.city")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{},
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.fullName.firstname")},
- },
-}
-```
-
-
-
-
-This can be useful when certain attributes are not required, so that if the user does not have them the session does not need to be aborted.
-
-### Disjunction labels
-
-Per disjunction a *label* can be specified, which is shown in the IRMA app when the user is asked for permission to disclose attributes. For example, the session request from [above](#disclosure-requests) could be augmented with a label for the second disjunction as follows:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [ ... ],
- [ ... ]
- ],
- "labels": {
- "1": { "en": "Work address", "nl": "Werk adres" }
- }
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Labels = map[int]irma.TranslatedString{
- 1: {"en": "Work address", "nl": "Werk adres"},
-}
-```
-
-
-
-
-In this way each disjunction can be given a optional label explaining to the user the purpose of the disjunction. It is recommended to only provide a label to explain something to the user that would otherwise not be obvious; for example, to request the user to send a work email address instead of a personal one. Repeating the credential or attribute name or description in labels is an antipattern.
-
-## Attribute-based signature requests
-Attribute-based signature sessions are started with an [`irma.SignatureRequest`](https://godoc.org/github.com/privacybydesign/irmago#SignatureRequest), which are similar to disclosure requests:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/signature/v2",
- "message": "Message to be signed by user",
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-request := irma.NewSignatureRequest("Message to be signed by user")
-request.Disclose = irma.AttributeConDisCon{ /* request attributes to attach to ABS */ }
-request.Labels = map[int]irma.TranslatedString{}
-```
-
-
-The `message` field is required. The attributes to be attached to the attribute-based signature are requested with the `disclose` field, which along with the `labels` field work exactly like in disclosure sessions.
-
-## Issuance requests
-Issuance sessions are started with an [`irma.IssuanceRequest`](https://godoc.org/github.com/privacybydesign/irmago#IssuanceRequest). Example:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/issuance/v2",
- "credentials": [{
- "credential": "irma-demo.MijnOverheid.ageLower",
- "validity": 1592438400,
- "attributes": {
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no"
- }
- }],
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-validity := irma.Timestamp(time.Unix(1592438400, 0))
-request := irma.NewIssuanceRequest([]*irma.CredentialRequest{
- {
- CredentialTypeID: irma.NewCredentialTypeIdentifier("irma-demo.MijnOverheid.ageLower"),
- Validity: &validity, // optional
- Attributes: map[string]string{
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no",
- },
- },
-})
-request.Disclose = irma.AttributeConDisCon{} // optional
-request.Labels = map[int]irma.TranslatedString{} // optional
-```
-
-
-Per credential in the `credentials` array the `validity` is optional; if skipped it is assigned the default value of 6 months. If present, the validity is always rounded down to the [nearest epoch boundary](overview.md#special-attributes), which is one week (60 * 60 * 24 * 7 = 604800 seconds).
-
-Attributes marked as `optional` in the containing credential type ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)) may be skipped in the `attributes` map. This issues [the `null` value](#null-attributes) to these attributes.
-
-`disclose` and `labels` are optional, allowing for *combined disclosure-issuance sessions*, in which the user is required to disclose attributes before the IRMA server will issue the credentials.
-
-The `clientReturnUrl` option can also be used, both for issuance only and combined disclosure-issuance sessions. Usage is similar as in [disclosure sessions](#client-return-url).
-
-## Client return URL
-If the user performs a mobile session, i.e. on the same device as where the IRMA app is installed on, then after the session has completed the user will be redirect to the `clientReturnUrl` specified in the session request, if present.
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- ...
- ],
- "clientReturnUrl": "https://privacybydesign.foundation"
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.ClientReturnURL = "https://privacybydesign.foundation"
-```
-
-
-The example shows a disclosure request but `clientReturnUrl` can be set on session requests of any type. If set, when the user finishes a session (either successfully or unsuccessfully), she is redirected to the location specified by `clientReturnUrl`.
-
-If *not* set:
-* On Android the IRMA app automatically toggles back to the previous app;
-* On iOS it is not possible to toggle back to the previous app due to restrictions by Apple, so the IRMA app stays open. In the top left corner of the screen, however, a button appears that leads back to the previous app.
-
-This URL does not necessarily have to be a web URL; it can also be a universal link to another app. Universal links work both on Android and iOS. It is also possible to use iOS or Android scheme URLs. (Note however that iOS and Android scheme URLs differ from one another, so when starting a session with a scheme URL as return URL you should therefore determine on which platform the user's app is running.)
-
-On iOS, toggling back to the calling app or website after the session can be simulated by navigating towards the calling app using a `clientReturnUrl`, either a normal URL or universal link. This works on Android as well, so currently this is the only platform-independent way of ensuring that the used ends up at a specified place after the session. If the URL opens a website, however, then the user is navigated towards a new browser tab instead of back to an existing browser tab, so in website-IRMA-website flows you will need to reload your webapp and state in the newly opened tab.
-
-## Extra parameters
-For each API that accepts one of the above session request data types, the requestor can provide additional parameters to configure the session at the IRMA server, by providing an *extended session request* instead, as follows:
-
-
-```json
-{
- "validity": 120,
- "timeout": 120,
- "callbackUrl": "https://example.com",
- "request": ...
-}
-```
-
-```go
-// See also corresponding types irma.SignatureRequestorRequest
-// and irma.IdentityProviderRequest
-irma.ServiceProviderRequest{
- irma.RequestorBaseRequest{
- ResultJwtValidity: 120,
- ClientTimeout: 120,
- CallbackUrl: "https://example.com",
- },
- irma.NewDisclosureRequest(),
-}
-```
-
-
-Below you can find an overview of all extra parameters and their default value.
-
-| Option (JSON) | Option (Go) | Meaning | Default value |
-| ------------- | ----------- | ------- | ------------- |
-| `"validity"` | `ResultJwtValidity` | Validity of session result JWT in seconds (to determine JWT expiration time `exp`) | 0 seconds |
-| `"timeout"` | `ClientTimeout` | Wait this many seconds for the IRMA app to connect before the session times out | 300 seconds (5 minutes) |
-| `"callbackUrl"` | `CallbackUrl` | URL to post session result to | `""` (no callback is performed) |
-
-## JWTs: signed session requests
-The IRMA API server or [`irma server`](irma-server.md) can be configured such that it only accepts session requests that have been digitally signed in the form of a [JWT](https://jwt.io). The form of the JWT depends on the [session type](what-is-irma.md#session-types). An example requesting [IRMATube](https://privacybydesign.foundation/demo/irmaTube) attributes::
-```
-eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImlybWF0dWJlIn0.eyJpYXQiOjE1NjQ2NTczNzUsInN1YiI6InZlcmlmaWNhdGlvbl9yZXF1ZXN0Iiwic3ByZXF1ZXN0Ijp7InJlcXVlc3QiOnsiQGNvbnRleHQiOiJodHRwczovL2lybWEuYXBwL2xkL3JlcXVlc3QvZGlzY2xvc3VyZS92MiIsImRpc2Nsb3NlIjpbW1sicGJkZi5wYmRmLmlybWF0dWJlLnR5cGUiXV0sW1sicGJkZi5wYmRmLmFnZUxpbWl0cy5vdmVyMTIiXSxbInBiZGYuZ2VtZWVudGUucGVyc29uYWxEYXRhLm92ZXIxMiJdXV19fX0.lW9mqjrLkoahDP6Fcw_9mH5hlfl1tq5qp3W3ga0Nrd_j0NXFj-6ngqHVXEV1zhC_OkVH4LN8fMBAgN8nqaFWgEdQvrCuB7-ynuBVjLR-QU272Ym86zLEWYggAkbZ5KY40MpTxU1dgFMucG7fyAESic04OribWOCVxstAMsM28yCxvzkBMCOSjFEe3abcg_N6VvQnLn3LgZP_UrxQmQsh4DK7mBjW04LesLG1vjcliyhDGUb52FHOP_NAsG7G2FvIgojPzALlPrpTMu5p8a95wc5CGR791wybmh0F8kDdwZWAU0W2FjlX5bNPsyXN8AxRVWaRmWoGrGsQhy_sKEf8lg
-```
-In case of disclosure sessions, the body of the JWT (the part in between the two dots) contains a Base64-encoding of the following:
-
-
-```json
-{
- "iat": 1550424847,
- "sub": "verification_request",
- "sprequest": ...
-}
-```
-
-```go
-// Sets iat, iss, and sub fields.
-// See also corresponding functions irma.NewSignatureRequestorJwt()
-// and irma.NewIdentityProviderJwt().
-// Obtain signed JWT string to POST to an irma server using Sign() method.
-irma.NewServiceProviderJwt("IRMATube", irma.NewDisclosureRequest())
-```
-
-
-The fields are as follows:
-* `iat`: Unix timestamp of the creation date of the JWT. IRMA servers may reject JWTs beyond a certain age.
-* `iss`: contains the requestor name, and is used by the IRMA server to lookup the appropriate key with which to verify the JWT.
-* `sub`: JWT subject, in case of disclosure sessions this must always be `"verification_request"`.
-* `sprequest`: contains an extended disclosure session request as defined above.
-
-For each possible session type, the contents of the `sub` field and the name of the field containing the session request must be as follows.
-
-| Session type | `sub` contents | Session request field name | Go function |
-| ------------ | -------------- | -------------------------- | ----------- |
-| Disclosure | `verification_request` | `sprequest` | `irma.NewServiceProviderJwt()` |
-| Attribute-based signature | `signature_request` | `absrequest` | `irma.NewSignatureRequestorJwt()` |
-| Issuance | `issue_request` | `iprequest` | `irma.NewIdentityProviderJwt()` |
-
-Currently the following libraries can produce JWTs of this form:
-* The [`irmago`](https://godoc.org/github.com/privacybydesign/irmago) library, using the mentioned functions
-* The [`irmajs`](irmajs.md) Javascript library
-* The [`irma-requestor`](https://github.com/privacybydesign/irma-requestor) PHP library
-* The [`irma_api_common`](https://github.com/privacybydesign/irma_api_common) Java library
-* The [`irma-diva-js`](https://github.com/Alliander/diva-irma-js) Javascript library
-
-`irma server` currently supports JWTs signed (asymmetrically with RSA) with the `RS256` algorithm, and (symmetrically signed with HMAC-SHA256) `RS256`. The IRMA API server only supports `RS256`.
diff --git a/website/versioned_docs/version-v0.5.0/what-is-irma.md b/website/versioned_docs/version-v0.5.0/what-is-irma.md
deleted file mode 100644
index 8f77c4c..0000000
--- a/website/versioned_docs/version-v0.5.0/what-is-irma.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: What is IRMA?
-id: version-v0.5.0-what-is-irma
-original_id: what-is-irma
----
-
-IRMA is a set of free and open source software projects implementing the Idemix attribute-based credential scheme, allowing users to safely and securely authenticate themselves as privacy-preserving as the situation permits. Users receive digitally signed attributes from trusted issuer, storing them in their IRMA app, after which the user can selectively disclose attributes to others. Schematically:
-
-
-
-
-
-
-Using the issuer's digital signature over the attributes the verifier can verify that the attributes were given to the user in the past, and that they have not been modified since.
-
-## IRMA session flow
-
-A typical IRMA session is depicted schematically below.
-
-![IRMA session flow](assets/irmaflow.png)
-
-Software components:
-* *Requestor backend and frontend*: Generally the requestor runs a website with a (JavaScript) frontend in the user's browser, and a backend server. During an IRMA session the frontend displays the IRMA QR that the [IRMA app](irma-app.md) scans. All frontend tasks depicted in the diagram are supported by [`irma-frontend`](irma-frontend.md).
-* [*IRMA server*](#irma-servers): Handles [IRMA protocol](irma-protocol.md) with the IRMA app for the requestor.
-* [*IRMA mobile app*](irma-app.md): [Android](https://play.google.com/store/apps/details?id=org.irmacard.cardemu), [iOS](https://itunes.apple.com/nl/app/irma-authentication/id1294092994).
-
-Explanation of the steps:
-
-1. Usually the session starts by the user performing some action on the website (e.g. clicking on "Log in with IRMA").
-1. The requestor sends its [session request](session-requests.md) (containing the attributes to be disclosed or issued, or message to be signed) to the [IRMA server](#irma-servers). Depending on its configuration, the IRMA server accepts the session request only if the session request is authentic (e.g. a validly signed [session request JWT](session-requests.md#jwts-signed-session-requests)) from an authorized requestor.
-1. The IRMA server accepts the request and assigns a session token (a random string) to it. It returns the contents of the QR code that the frontend must display: the URL to itself and the session token.
-1. The frontend ([`irma-frontend`](irma-frontend.md)) receives and displays the QR code, which is scanned by the IRMA app.
-1. The IRMA app requests the session request from step 1, receiving the attributes to be disclosed or issued, or message to be signed.
-1. The IRMA server returns the session request.
-1. The IRMA app displays the attributes to be disclosed or issued, or message to be signed, and asks the user if she wants to proceed.
-1. The user accepts.
-1. The IRMA server performs the IRMA protocol with the IRMA app, issuing new attributes to the user, or receiving and verifying attributes from the user's IRMA app, or receiving and verifying an attribute-based signature made by the user's app.
-1. The session status (`DONE`, `CANCELLED`, `TIMEOUT`), along with disclosed and verified attributes or signature depending on the session type, are returned to the requestor.
-
-Additional notes:
-
-* Which of these tasks are performed by the requestor's backend and which by its frontend differs case by case:
- - Often the session request is sent to the IRMA server by the requestor's backend, after which the IRMA server's reply in step 2 is forwarded to the frontend which renders it as a QR code. Step 1 can however also be done by `irma-frontend`, in which case `irma-frontend` automatically picks up the IRMA server's reply in step 2 and renders the QR code.
- - Similarly, `irma-frontend` can be instructed to fetch the session result in step 10, but this can also be done in the backend. In the latter, `irma-frontend` can fetch a custom result at your backend, if desired.
-* The IRMA server could be deployed on the same machine as the requestor's backend, but it need not be; possibly it is not even controlled by the requestor. Generally, steps 2/3 and 10 are done with REST HTTP calls to the IRMA server, but in case the [`irmaserver`](irma-server-lib.md) library is used, these steps are function calls. Alternatively, you could use one of the packages in [`irma-backend-packages`](irma-backend.md) to do these steps with function calls in other programming languages.
-
-## Session types
-
-In an IRMA session, the [IRMA mobile app](irma-app.md) performs one of the following three *session types* with an [*IRMA server*](#irma-servers):
-
-* *Disclosure sessions*: Upon receiving a list of requested attributes from the IRMA server, the app discloses the required attributes to the IRMA server if the app user agrees, after which they are verified by the IRMA server.
-* *Attribute-based signature sessions*: Similar to disclosure sessions, but the attributes are attached to a message digitally signed into an [*attribute-based signature*](overview.md#attribute-based-signatures). The attribute-based signature can be verified at any later time, ensuring that the signed message is intact, and that the IRMA attributes attached to it were valid at the time of creation of the attribute-based signature.
-* *Issuance sessions*: the IRMA app receives a new set of IRMA attributes including valid issuer signatures from the IRMA server, to use in later disclosure or attribute-based signature sessions. (Possibly the user is asked to disclose some attributes as well, within the same IRMA session, before receiving the new attributes. This is called a *combined issuance-disclosure session*.)
-
-This process is depicted schematically and explained in more detail in the [IRMA session flow](what-is-irma.md#irma-session-flow) chapter. For the user, after scanning the QR in his/her IRMA app a disclosure session generally looks like the following. (Attribute-based signature sessions and issuance sessions are identical in terms of their flow (scan qr, provide permission, success screen); only the graphical interface is different.)
-
-
-
-
-
-
-## IRMA servers
-
-Various existing software components documented on this website can perform the role of the IRMA server.
-Apart from exposing an API that is used by the [IRMA app](irma-app.md) during IRMA sessions, each of these components also offer an API with which IRMA sessions can be started and monitored, for use by the [*requestor*](overview.md#participants): the party wishing to issue attributes to or verify attributes from an IRMA app. The IRMA server handles the IRMA session with the IRMA app for the requestor.
-
-Currently the following IRMA servers exist:
-
-* The `irma server` command of the [`irma`](irma-cli.md) binary: a standalone daemon exposing its requestor API as HTTP endpoints. [Documentation](irma-server.md); [API reference](api-irma-server.md).
-* The `irmaserver` Go library, exposing a HTTP server that handles IRMA sessions with the IRMA app, and Go functions for starting and managing IRMA sessions. [Documentation](irma-server-lib.mdrary); [API reference](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver).
-* The now deprecated [`irma_api_server`](https://github.com/privacybydesign/irma_api_server).
-
-## About this documentation
-
-IRMA uses JSON to pass messages within IRMA sessions. The majority of IRMA is [written in Go](https://github.com/privacybydesign/irmago), and the JSON messages generally correspond to specific Go structs. For example, the [`GET /session/{token}/result`](api-irma-server.md#get-session-token-result) endpoint of the [`irma server`](irma-server.md) outputs instances of the [`server.SessionResult`](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult). In such cases, a link to the corresponding Go struct will be included. This can tell you what fields you can use or expect. (Note that some structs have custom (un)marshalers. See also the [Go documentation](https://blog.golang.org/json-and-go) on JSON and Go.)
diff --git a/website/versioned_docs/version-v0.5.0/workshop.md b/website/versioned_docs/version-v0.5.0/workshop.md
deleted file mode 100644
index 73a53ea..0000000
--- a/website/versioned_docs/version-v0.5.0/workshop.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: May 22 IRMA Workshop
-id: version-v0.5.0-workshop
-original_id: workshop
----
-
-## Resources
-
-- Technical documentation: https://irma.app/docs
-- IRMA source code: https://github.com/privacybydesign/
-- Attribute index: https://privacybydesign.foundation/attribute-index/en/
-- Slack: ask for invite
-
-Other resources:
-- Privacy by Design Foundation website: https://privacybydesign.foundation/
-- Privacy by Design Foundation twitter: https://twitter.com/IRMA_privacy/
-- Attribute issuance: https://privacybydesign.foundation/issuance
-
-## Prerequisites
-
-Make sure you have installed the IRMA app on your [Android](https://play.google.com/store/apps/details?id=org.irmacard.cardemu) or [iOS](https://itunes.apple.com/nl/app/irma-authentication/id1294092994) device.
-
-If you haven't before, try one of the demos on our [demo page](https://privacybydesign.foundation/demo/). For many demos you need for example an [email or age limit attribute](https://privacybydesign.foundation/issuance/). [IRMATube](https://privacybydesign.foundation/demo/irmaTube) is an entirely self-contained demo.
-
-## Part 1
-
-For this part, follow the instructions in the [Getting Started](getting-started.md) page of the technical documentation. You will download or compile from source the IRMA command line tool, which includes the IRMA server. You then download or compile the `irmajs` JavaScript library and let the IRMA server host the static pages.
-
-This IRMA server automatically detects your LAN IP address, and adjusts the URL in the QR to match that address. This is necessary because the IRMA app on your phone somehow needs to connect to your server. However, not all network allow direct LAN access, especially not corporate wifi. Mobile hotspots often work well.
-
-#### Using a workshop server
-
-To bypass any compilation and network issues, you can also use one of our workshop Debian Linux servers over an SSH connection. Please reserve one by grabbing a token at the front of the room. Then edit and execute the following:
-
-```
-PASSWORD=...
-SERVER_NUMBER=01
-
-wget -O irma_workshop_id_rsa "https://irma.app/irma_workshop_id_rsa_${PASSWORD}"
-chmod 600 irma_workshop_id_rsa
-ssh -i irma_workshop_id_rsa "debian@irma${SERVER_NUMBER}.irma.app"
-```
-
-Add the `PASSWORD` you received during the workshop (as a super basic precaution). The private key gives access to all workshop servers. Enter the two-digit server number that's on your token as `SERVER_NUMBER`.
-
-You can then run the example with `./run_example.sh` and browse to the address listed in the output. The server is completely yours to use for purposes of the workshop, and can also be easily reset on request.
-
-
-## Part 2
-Integrate IRMA attribute verification in your own website or application, for example with one of the following use cases:
-
-* Use case 1: Instead of logging in with username/passwords, users can register and then login at your website by showing their IRMA email address attribute ([index](https://privacybydesign.foundation/attribute-index/en/pbdf.pbdf.email.html), [issuance](https://privacybydesign.foundation/issuance/email/), [info](https://privacybydesign.foundation/issuance-email/)).
-* Use case 2: Auto-fill an HTML form in your website by asking the user to disclose IRMA attributes, as in [this demo](https://privacybydesign.foundation/demo/adres/).
-* Use case 3: Ask your users to provide, for example, consent to receive ads per email, with an [attribute-based signature](what-is-irma.md#session-types).
-* Use case 4 (experimental): if you develop an iOS or Android app, start an IRMA session from within your app using these libraries: [iOS](https://github.com/privacybydesign/irmaios), [Android](https://github.com/privacybydesign/irmaandroid).
-
-## Advanced/take home exercises
-
-1. In production scenarios, you should switch to the [`pbdf`](https://github.com/credentials/pbdf-schememanager) [scheme](schemes.md), which contrary to the [`irma-demo`](https://github.com/credentials/irma-demo-schememanager) scheme contains actual personal data.
-2. Start issuing your own attributes, as follows:
- 1. Create a new credential type within the `irma-demo` scheme, and re-sign the scheme (`irma scheme sign`)
- 2. Create a custom build of the IRMA app [`irma_mobile`](irma-app.md) with your modified `irma-demo` scheme in its `irma_configuration` folder
- 3. Start an `irma server` and point it to your modified `irma-demo` scheme, e.g. with the `--schemes-path` flag
- 4. Start an issuance session of your new credential type, e.g. by modifying the [`irmajs` browser demo](https://github.com/privacybydesign/irmajs)
-3. The HTTP endpoints exposed by the `irma server` are also available as Go functions in the [`irmaserver`](irma-server-lib.md) Go library, and as C functions [here](https://github.com/privacybydesign/irmago/tree/master/server/irmac). Enable IRMA attribute verification and issuance from your own favorite programming language by binding to these C functions.
\ No newline at end of file
diff --git a/website/versioned_docs/version-v0.6.1/randomblind.md b/website/versioned_docs/version-v0.6.1/randomblind.md
deleted file mode 100644
index b218fc6..0000000
--- a/website/versioned_docs/version-v0.6.1/randomblind.md
+++ /dev/null
@@ -1,195 +0,0 @@
----
-title: Randomblind issuance
-id: version-v0.6.1-randomblind
-original_id: randomblind
----
-
-
-
-
-*Randomblind* attributes are a new IRMA feature introduced in
-[`irmago` v0.6.0](https://github.com/privacybydesign/irmago/releases/tag/v0.6.0)
-that can give the user extra privacy
-guarantees during issuance. Specifically, if this mode of issuance is enabled
-for an attribute within a credential type, this attribute is guaranteed to
- 1) be random, i.e., unequal to all previously issued instances of this attribute and
- 2) remain unknown to the issuer, while it still signs the attribute as part of the credential.
-
-Note that the latter property holds up until a user decides to disclose the
-attribute. In this sense, the attribute can be seen as a one-time attribute.
-
-This page explains how to enable this feature and later how this guarantee is
-upheld cryptographically. The primary use case of this feature is online
-voting, where voting secrecy plays a vital role. In the last section,
-we will explain how randomblind attributes can be used in digital elections.
-
-
-## API
-
-Randomblind issuance is enabled in the scheme by adding the `randomblind` XML
-attribute to an `Attribute` tag within the issue specification of a given
-credential. For more information about schemes, see [this
-page](/schemes/). In the example below we enable this for
-the second attribute in the credential. Any or all atributes in a credential
-type can be randomblind.
-
-``` xml
-
- ...
-
-
- ...
-
-
- ...
-
- ...
-
-...
-
-```
-
-When issuing a credential specified by the above, the
-issuing party, i.e., the requestor that submits the issuance request to the
-IRMA server, must *not* pass attribute values for attributes that are tagged as
-randomblind. Instead, the issuer and user jointly decide on the value of these
-attributes (in this case the `votingnumber` attribute) during the session.
-We explain in detail how this comes to pass in the next section.
-
-
-As a concrete example we use the
-"Demo Voting Card" credential type, see [this page in the attribute
-index](https://privacybydesign.foundation/attribute-index/en/irma-demo.stemmen.stempas.html#irma-demo.stemmen.stempas.election).
-Even though the credential contains five attributes, the issuer must only give
-four concrete values to construct the credential. For example, a requestor can
-start an issuance session to issue such a credential using the following
-command:
-
-```
-irma session --issue irma-demo.stemmen.stempas=test,test.com,14-12-2020,15-12-2020
-```
-
-Upon scanning the QR code, the IRMA app user is asked permission to perform the
-session and obtain this credential. At this point, the value of `votingnumber`
-has not been decided yet. After the issuance, a fifth attribute,
-`votingnumber`, which is at most 256 bits, shows up in the credential. The app
-displays this attribute in a [base62
-representation](https://en.wikipedia.org/wiki/Base62).
-
-
-Before issuance | After issuance
-:----------------------------:|:----------------------------:
-![Permission](assets/rb_permission.jpg) | ![Card](assets/rb_card.jpg)
-
-## Cryptography
-In this section we will explain in detail how the issuer and the user are able
-to perform such an issuance session. Randomblindness of attributes only concerns
-the issuance protocol. The disclosure and signature protocols involving randomblind attributes
-are in every aspect identical to disclosing or signing using a normal attribute.
-
-We can assume that the schemes of both parties agree on the indices of the
-randomblind attributes. If this is not the case, either party cancels the
-session. In the following example, we only have one randomblind attribute, but
-the protocol can be extended straightforwardly to issue multiple randomblind
-attributes.
-
-The following requires a bit of background regarding Camenisch-Lysyanskaya (CL)
-signatures. A short summary can be found
-[here](https://privacybydesign.foundation/pdf/Idemix_overview.pdf). A more
-extensive description of the Idemix specification can be found
-[here](https://dominoweb.draco.res.ibm.com/reports/rz3730_revised.pdf).
-
-In the following, the variables $R, S$ and $Z$ are public parameters defined by the
-Idemix public key of the issuer. The issuance goes as follows:
-- The user starts by sampling a random $v'$ and a random 255-bit integer $m_{r}'$ at
- the index $r$ of the randomblind attribute.
- This so-called *share* of the attribute remains secret, similar to
- how the user's secret key remains secret during issuance.
- The user computes the commitment $U = S^{v'} R_0^{m_0} R_r^{m_{r}'} \mod n$.
- Note that $m_0$ is always the user's secret key. This commitment is sent to
- the issuer along with a [zero-knowledge proof](/zkp/)
- of $v', m_0$ and $m_{r}'$.
-
-- The issuer samples a random prime $e$.
- The issuer also samples $v''$ and $m_{r}''$ (also 255 bits) at random.
- Next, the issuer computes
-
- $$
- A = \Bigg(\frac{Z}{U S^{v''} R_{1}^{m_1} \dots \ R_{r}^{m_r''} \dots \ R_{n}^{m_n}}\Bigg)^{1/e}
- $$
-
- For every attribute that is tagged randomblind, the issuer includes its share
- of the attribute in the exponent (in this case, only for index $r$). For
- regular attributes, the exponent is simply the attribute value that the
- issuer wants to pass. The issuer sends $(A, e, v'', m_{r}'')$ back to the
- user.
-
-- Finally, the user is able to reconstruct any attributes that are the sum of two shares:
- $$
- m_r = m_r' + m_r''
- $$
-
- The CL signature becomes $(A, e, v)$ with $v = v' + v''$. It follows that $Z
- = A^e S^v \prod_{i=0}^{l} R_{i}^{m_i}$ holds for the attributes $m$ in the
- resulting credential, meaning that the signature (and thereby the credential) is
- valid. We also note that the issuer does not have enough information to
- fully uncover $m_r$, which ends up as the attribute value in the resulting
- credential. The user is now free to use this attribute, knowing the issuer
- cannot trace it back to her. Note that after revealing this attribute
- once, this guarantee no longer holds.
-
-## Use case: Digital elections
-
-Two important requirements in digital elections in not just an online setting,
-but rather in general, are *secrecy* and *verifiability*. Secrecy means that
-nobody else is able to figure whom someone voted for. Verifiability means that
-any user of the system is able to verify that her vote is included in the
-final tally. In this section we explain how IRMA's randomblind attributes can
-help realize these requirements.
-
-A key observation to preserve secrecy is that there has to be a split between
-authenticating the user and registering the votes. In physically held
-elections this is realized by handing out an anonymized ballot after the user
-has proven eligibility. For this purpose, two parties are required; one that
-the user authenticates to after which this party determines if the user is
-eligible (party A); and one that registers votes (party B). It is crucial
-that these parties are strictly separate and do not conspire together.
-
-In digital elections, the same principle applies. Using IRMA randomblind
-attributes the following system can be realized:
-
-1. (Eligibility check \& voting pass retrieval). The user authenticates to
- party A (perhaps using IRMA), which then decides whether or not
- this user is eligible as per the system's criteria. In this process,
- party A learns (part of) the identity of the user. If the user is
- eligible, the party issues a voting card, which includes a randomblind
- attribute. Since party A does not learn the value of the
- attribute, this party can also not learn whom or what a user decides to vote
- for in the upcoming steps. Note that in order to prevent a user from
- fetching more than one voting card (and thus being able to cast multiple
- votes), the user must be uniquely identified in this stage.
-
-2. (Casting the vote). To vote, a user creates an [attribute-based
- signature](/overview/#attribute-based-signatures) on a
- "ballot" string, i.e., the user's choice using the randomblind attribute
- acquired in the previous step. This signature, the choice and the attribute
- are then registered in a database at party B. The signature ensures
- authentication, integrity and non-repudiation. Note that party B only
- learns what somebody voted for, but not the actual identity of the voter.
-
-3. (Verification).
- After the election ends, the database is published. To verify whether her
- vote has been correctly cast, the user can simply check if the
- attribute-based signature created in the previous step containing her
- randomblind attribute is among the registered vote entries.
diff --git a/website/versioned_docs/version-v0.7.0/api-irma-frontend.md b/website/versioned_docs/version-v0.7.0/api-irma-frontend.md
deleted file mode 100644
index 0e3a140..0000000
--- a/website/versioned_docs/version-v0.7.0/api-irma-frontend.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: IRMA frontend packages
-id: version-v0.7.0-api-irma-frontend
-original_id: api-irma-frontend
----
-
-The IRMA frontend packages consist of multiple packages. Therefore we describe the API per package.
-The API description of the IRMA frontend plugins is combined into one section.
-
-## IRMA core
-The [IRMA core](irma-frontend.md#irma-core) package only exports the `IrmaCore` class. To handle an IRMA session,
-an instance of this class can be made with the relevant options for your session. The options object is shared
-between all plugins that are registered at the `IrmaCore` instance. The plugins don't need to be configured
-individually. The options that can be specified depend on the specific plugins you are using. You can find all
-possible options in the READMEs of the plugins. You can find an overview of all available IRMA core plugins
-[here](#plugins).
-
-The IRMA core class has one constructor:
-```javascript
-const IrmaCore = require('@privacybydesign/irma-core');
-const irma = new IrmaCore({/* Options */});
-```
-
-Below you can find an overview of all methods an IRMA core instance offers you.
-
-| Method | Functionality |
-|---|---|
-| `use(/* Plugin*/)` | With this method plugins can be added to the IRMA core instance. This method takes care of instantiating the plugin. You simply pass the plugin class as an argument to this function; you must not instantiate the plugin yourself.|
-| `start()` | The start method activates the state machine. From then the IRMA core instance is ready to be used and no plugins can be added to the instance anymore. It returns a promise that resolves when a session is finished successfully and rejects when a unrecoverable error occurs. By calling IRMA core's `start` method, the plugins will be started too.|
-| `abort()` | The abort method forces an `irma-core` instance to abort the session and all associated plugins should stop making changes. In this way you can stop the instance from being active when it is not relevant anymore. If a promise returned by the `start` method is still active, the promise will be rejected with error message `Aborted`.|
-
-For an example of how the IRMA core API can be used, you can also check the [usage guide](irma-frontend.md#usage-guide).
-
-## IRMA frontend
-[IRMA frontend](irma-frontend.md#irma-frontend) is a wrapper
-package around IRMA core combined with several of its plugins and the default [`irma-css`](irma-frontend.md#irma-css)
-styling. The package can only be used in web browser environments.
-
-It exports two functions:
-
-| Function | Functionality |
-|---|---|
-| `newWeb({/* Options */})` | With this method an `IrmaCore` instance is initialized, using the given options, configured to control an embedded web element. The options that can be used are all options from [`irma-client`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client) and [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web).
-| `newPopup({/* Options */})` | With this method an `IrmaCore` instance is initialized, using the given options, configured to start a popup overlay. The options that can be used are all options from [`irma-client`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client) and [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-popup).
-
-Both functions return an interface with the following methods:
-
-| Method | Functionality |
-|---|---|
-| `start()` | Calls the `start` method of the initialized `IrmaCore` instance and returns the promise it gets as result.
-| `abort()` | Calls the `abort` method of the initialized `IrmaCore` instance.
-
-When importing this library via a `
-```
-as well as in Node or Webpack:
-```js
-// ES modules
-import * as irma from '@privacybydesign/irmajs';
-// CommonJS
-const irma = require('@privacybydesign/irmajs');
-```
-
-Its primary functions are [`startSession()`](#startsession), which can start an IRMA session by sending a (unsigned or JWT) [session request](session-requests.md) to an IRMA server, and [`handleSession()`](#handlesession), which given the output of `startSession()` handles the remainder of an IRMA session.
-
-Since version 0.2.0, `irmajs` is converted into a wrapper of [`irma-core`](irma-frontend.md#irma-core)
-and several [`irma-frontend-packages` plugins](irma-frontend.md#available-plugins-for-irma-core) that makes it
-backwards compatible with the `irmajs` API. This makes it possible to update to the `irma-frontend-packages` look and feel
-without having to change your software.
-
-## Deprecated API features
-Due to technical changes in IRMA, we had to make breaking changes when introducing version 0.2.0.
-All changes are related to the function call `handleSession`.
-* Method `canvas` is not supported anymore. Please use the module `irma-frontend` instead or make
- your own composition of plugins and layouts using `irma-core`.
- This also means the canvas related options `element` and `showConnectedIcon` are deprecated.
-* Method `mobile` has the same behaviour as method `popup` now. On mobile devices, the popup
- mode automatically detects whether a mobile device is used and then shows the user the option to open
- the [IRMA app](irma-app.md) installed on the mobile device itself. It is now an explicit choice, so users can also get
- a QR on mobile devices instead (useful for tablets).
-* The option `disableMobile` is not useful anymore. This module does not have
- automatic redirects to other apps anymore without explicit user interaction.
- The option is therefore deprecated.
-* Because the explicit methods for mobile devices are deprecated, the undocumented exported function `detectUserAgent`
- and the undocumented exported struct `UserAgent` are also deprecated. An explicit distinction based on user agent
- is not necessary anymore. This is all handled internally now.
-* The option `returnStatus` is deprecated. Instead you can use the functions `waitConnected` and `waitDone`
- to detect yourself whether the session reached a certain status.
-
-## API reference
-
-
-
----
-
-### `SessionStatus`
-A enum containing possible IRMA [session statuses](https://godoc.org/github.com/privacybydesign/irmago/server#Status), defined as follows:
-
-```js
-const SessionStatus = {
- Initialized: 'INITIALIZED', // The session has been started and is waiting for the client to connect (scan the QR)
- Connected : 'CONNECTED', // The client has retrieved the session request, we wait for its response
- Cancelled : 'CANCELLED', // The session is cancelled, possibly due to an error
- Done : 'DONE', // The session has completed successfully
- Timeout : 'TIMEOUT', // Session timed out
-};
-```
-
----
-
-### `handleSession()`
-
-```js
-irma.handleSession(qr, [options])
-```
-
-> Please check the [deprecated API features](#deprecated-api-features) to see which options are deprecated since version 0.2.0.
-
-Handle an IRMA session after it has been created at an IRMA server, given the QR contents obtained from the IRMA server (e.g. using [`startSession()`](#startsession)) to be sent to the [IRMA app](irma-app.md). This function can
-1. draw an IRMA QR,
-2. wait for the phone to connect,
-3. wait for the session to complete,
-4. retrieve the session result afterwards from the irma server.
-
-Returns a promise that can resolve at any of these phases, depending on the options:
-
-| Option | Default | Effect |
-|---|---|---|
-| `method` | `'popup'` | Supported methods: `'popup'`, `'canvas'`, `'mobile'` (only browser), `'console'` (only node), `'url'` (both) |
-| `element` | `'irmaqr'` | HTML `id` of the canvas to draw to if `method === 'canvas'` |
-| `language` | `'en'` | Popup language when `method === 'popup'` |
-| `showConnectedIcon` | `true` | When method is `'popup'` or `'canvas'`, replace QR with a phone icon when phone connects |
-| `returnStatus` | `SessionStatus.Done` | When the session reaches this status control is returned to the caller |
-| `server` | `''` | Server URL to fetch the session result when session is done. Implies `returnStatus === SessionStatus.Done` |
-| `token` | `''` | Session token required to fetch the session result when session is done |
-| `resultJwt` | `false` | Retrieve signed session result from the irma server |
-| `disableMobile` | `false` | Disable automatic navigation to IRMA app on mobile |
-
-The following `method`s are supported:
-* `popup`: Draw a popup overlay with the QR and a cancel button in it.
-* `canvas`: Draw the QR into the HTML `canvas` specified by the `element` option.
-* `mobile`: For mobile browsers, open the IRMA app directly instead of drawing a QR. Note that this mode is default when running `irmajs` in a mobile browser, even if you specify another method. You can disable this behavior and use your own `method` by setting `disableMobile` to true.
-* `console`: Draw the QR into the console.
-* `url`: Return the QR as a data URL (for in an `img` HTML tag). Implies `returnStatus = SessionStatus.Initialized`.
-
-What the promise returned by this function receives depends on the options as follows:
-* If the `server` and `token` options are not provided then the session status is returned.
-* If the `server` and `token` parameters are given, containing a URL to an IRMA server and the session token at the IRMA server, respectively, then the session result is retrieved from the IRMA server. In that case, the promise returned by this function receives one of the following:
- * If `resultJwt` is `false` (default), a [`SessionResult` message](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult) as returned by the [`GET /session/{token}/result`](api-irma-server.md#get-session-token-result) endpoint of the `irma server`.
- * Otherwise, a session result JWT as returned by the [`GET /session/{token}/result-jwt`](api-irma-server.md#get-session-token-result-jwt) endpoint of the `irma server`.
-
-If the session is not successful, an exception is thrown. If the session is cancelled or times out, the message will be `SessionStatus.Cancelled` or `SessionStatus.Timeout`.
-
-> The session is cancelled and receives status `SessionStatus.Cancelled` not only when the IRMA app user refuses, but also when the session is aborted due to an error. In each of these cases an exception is thrown. Check its error argument.
-
-> If the session is cancelled due to the user aborting, it is (by design) not possible to distinguish between (1) the user had the requested attributes but refused to disclose them, and (2) the session was aborted by the user's IRMA app because (s)he did not have the required attributes.
-
----
-
-### `startSession()`
-
-```js
-irma.startSession(server, request[, method, [key[, name]]])
-```
-
-Start an IRMA session at an IRMA server. This function supports all authentication methods of the `POST /session` endpoint of the `irma server`. It returns a promise with the response (the session QR contents) from the IRMA server (which can be handled by [`handleSession()`](#handlesession)).
-
- Parameters:
- * `server`: URL to IRMA server at which to start the session.
- * `request`: Session request, either a JWT or an [(extended) session request](session-requests.md) (see below).
- * `method`: authentication method (supported: `none`, `token`, `hmac`, `publickey`; default is `none`).
- * `key`: API token or JWT key.
- * `name`: name of the requestor (only for `hmac` and `publickey` mode).
-
-The authentication method is determined by the `request` and `method` parameters as follows.
-* If `request` is a `string` then it is posted as a [session request JWT](session-requests.md#jwts-signed-session-requests) to the IRMA server. In this case, the `method` parameter needs to be set appropriately (`hmac` or `publickey`).
-* Otherwise it should be an `object` containing an [(extended) session request](session-requests.md). How it is handled depends on `method`:
- * `none`: it is POSTed as JSON to the IRMA server (which must be configured to accept unauthorized session requests).
- * `token`: it is POSTed as JSON to the IRMA server along with the `key` parameter as an API token in a HTTP header.
- * `publickey`: it is first signed into a JWT with the specified RSA private `key` in PEM, using `name` as the requestor name, and then POSTed to the IRMA server.
- * `hmac`: it is first signed into a JWT with the specified symmetric HMAC `key`, using `name` as the requestor name, and then POSTed to the IRMA server.
-
----
-
-### `signSessionRequest()`
-```js
-signSessionRequest(request, method, key, name)
-```
-
----
-
-### `waitConnected()`
-```js
-waitConnected(url)
-```
-
----
-
-### `waitDone()`
-```js
-waitDone(url)
-```
diff --git a/website/versioned_docs/version-v0.7.0/irma-frontend.md b/website/versioned_docs/version-v0.7.0/irma-frontend.md
deleted file mode 100644
index f9c2fb2..0000000
--- a/website/versioned_docs/version-v0.7.0/irma-frontend.md
+++ /dev/null
@@ -1,385 +0,0 @@
----
-title: IRMA frontend JavaScript packages
-id: version-v0.7.0-irma-frontend
-original_id: irma-frontend
----
-
-The [`irma-frontend-packages`](https://github.com/privacybydesign/irma-frontend-packages) repository is a set of
-related JavaScript packages that together form a Javascript frontend client to the
-[`irma server`](https://github.com/privacybydesign/irmago/tree/master/irma). The packages contain a state
-machine package [`irma-core`](#irma-core) to which several plugin packages can be added to achieve IRMA support
-for your application. We also provide a wrapper package [`irma-frontend`](#irma-frontend) that combines `irma-core` with some of the
-plugins in a bundle. With this wrapper package you have an easy starting point for handling sessions using an embedded
-web element or using a popup overlay in the browser.
-
-Using the default styling, the browser version will look like this:
-
-![IRMA frontend web element](assets/irma-frontend-web.gif)
-
-All packages are published on [npm](https://www.npmjs.com/) in `@privacybydesign` scoped packages.
-
-## IRMA core
-
-This package contains the [state machine](https://github.com/privacybydesign/irma-frontend-packages/blob/master/irma-core/state-transitions.js)
-for implementing IRMA flows. `irma-core` itself does not provide any real functionality. Plugins can be registered at the
-state machine and the plugins then provide the functionality depending on the state the state machine is in.
-The plugins can also request state modifications to the state machine.
-
-IRMA core can be initialized in the following way:
-```javascript
-const IrmaCore = require('@privacybydesign/irma-core');
-const irma = new IrmaCore(/* options */);
-
-irma.use(/* Plugin A */);
-irma.use(/* Plugin B */);
-
-irma.start();
-```
-
-More information about the methods IRMA core offers to you can be found
-in the [API overview](api-irma-frontend.md#irma-core).
-
-### Available plugins for IRMA core
-Below is a list of the plugins we provide. Detailed explanations of the plugins can be found in the READMEs
-on GitHub (linked to in the left column).
-
-| Plugin | Functionality |
-|---|---|
-| [`irma-client`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client) | Plugin to fetch a [session package](api-irma-server.md#post-session), to check the `irma server` for the current session status and optionally to fetch the result. The plugin is widely configurable, so you can also fetch a session package or a session result at custom endpoints. |
-| [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web) | Plugin to handle user interaction via a web element that developers can embed within the contents of their webpages. It is designed to be used with [`irma-css`](#irma-css). `irma-css` is not embedded in this package, so you have to manually include this. You are also free to use your own styling. |
-| [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-popup) | `irma-web` element embedded in a popup overlay. The popup is displayed on top of your content and is hidden again when a session is completed, when a fatal error occurs or when the user closes the popup. It is designed to be used with [`irma-css`](#irma-css). `irma-css` is not embedded in this package, so you have to manually include this. You are also free to use your own styling. |
-| [`irma-console`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-console) | Plugin to handle user interaction via the console (either the browser console or the command line console) using node.js. |
-| [`irma-dummy`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-dummy) | Plugin that provides a dummy implementation of the `irma-client` plugin. This can be used to test the user interaction without actually having to do a session at an IRMA server. Instead, the state machine will be instructed to continue after fixed timeouts. |
-
-If a plugin for your use case is not available, we offer you the option to [construct one yourself](#make-your-own-irma-core-plugin).
-
-### Usage guide
-Here we explain the scenario in which the web element is embedded within the contents of our website.
-This web element will be controlled by the `irma-web` plugin. We use `irma-client` for the communication
-with the IRMA server and our backend.
-
-In the body of our HTML page we need to have an HTML element where `irma-web` can render its user interface.
-We also import the [`irma-css`](#irma-css) styling to nicely style our `irma-web-form` element.
-```html
-
-
- ...
-
- ...
-
-
- ...
-
- ...
-
-
-```
-
-In our JavaScript we import `irma-core` and the relevant plugins first.
-```javascript
-const IrmaCore = require('@privacybydesign/irma-core');
-const IrmaWeb = require('@privacybydesign/irma-web');
-const IrmaClient = require('@privacybydesign/irma-client');
-```
-
-Then we can instantiate IRMA core. Let's assume we already have an endpoint `/get-irma-session`
-in our backend that starts a relevant IRMA session at the [`irma server`](irma-server.md). Let's say the endpoint
-returns a single session package (in JSON) without any backend token.
-```javascript
-const irma = new IrmaCore({
- // Enable to get helpful output in the browser console.
- debugging: false,
-
- // The option 'element' is used by irma-web to find its HTML element in the DOM.
- element: '#irma-web-form',
-
- // The 'session' option struct is used by irma-client to find the session information.
- session: {
- // The base url of our website
- url: 'http://example.com',
-
- // The 'start' option struct specifies where irma-client can fetch a new session package.
- start: {
- // Specifies how the endpoint url can be derived from the base url (see above).
- url: o => `${o.url}/get-irma-session`,
- // A GET request is used.
- method: 'GET',
- // No additional HTTP headers are needed.
- headers: {},
- // Note: a GET request with empty headers is fetch's default, so
- // omitting these options would lead to the same result.
- // All options the fetch API exposes can be used here to customize the request.
- // https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch
- },
-
- // The 'mapping' option specifies how the data can be derived from a 'start' response.
- mapping: {
- // The only thing included in the request is the session pointer, so no additional parsing is needed.
- sessionPtr: r => r,
- },
-
- // Since we did not receive a backend token, we cannot retrieve any session result here.
- result: false,
- },
-});
-```
-
-Now we can add the plugins to our IRMA core instance and start running it.
-```javascript
-irma.use(IrmaWeb);
-irma.use(IrmaClient);
-
-const promise = irma.start();
-```
-
-IRMA core is now started and the IRMA web element should be visible.
-By looking at the state of the promise, you can detect whether the user has finished.
-```javascript
-promise.then(() => {
- // The user has completed the session.
-})
-.catch((err) => {
- // Some fatal error has occurred.
-});
-```
-
-Be aware that you can start an instance of `irma-core` only once.
-When you want to call `start()` again, you have to create a new instance.
-When a promise of an earlier `start()` call is not completed yet, promise rejection
-can be forced by calling the `abort()` method. In this way a new `irma-core`
-instance can be created without any risk on interference with other running instances.
-When a promise is rejected because of an `abort()` call, the promise will return the
-error message `Aborted`.
-
-```javascript
-irma.abort();
-```
-
-For detailed information about all available options, you can check the README of the
-particular plugin on GitHub. There are links in the plugin overview [above](#available-plugins-for-IRMA-core).
-
-## IRMA frontend
-For convenience we already bundled `irma-core`, `irma-web`, `irma-popup` and `irma-client` together with the default styling
-from `irma-css`. We also added polyfills in this package to realize support for Internet Explorer 11.
-The package can be installed from the npm registry.
-The bundled package can also be downloaded directly [here](https://github.com/privacybydesign/irma-frontend-packages/releases/latest/download/irma.js).
-Please host this file as asset yourself.
-
-The bundle can be imported in your JavaScript file by doing `require('@privacybydesign/irma-frontend')` or it can
-be included directly in the HTML.
-
-```html
-
-```
-
-You can then instantiate `irma-frontend` and start a session like this when using an embedded web element:
-```javascript
-const exampleWeb = irma.newWeb({
- debugging: false, // Enable to get helpful output in the browser console
- element: '#irma-web-form', // Which DOM element to render to
-
- // Back-end options
- session: {
- // Configure your flow here, see usage guide of irma-core
- },
-
- ...
-});
-
-exampleWeb.start()
-.then(result => console.log("Successful disclosure! 🎉", result))
-.catch(error => console.error("Couldn't do what you asked 😢", error));
-```
-
-When you want a popup overlay to be used to, you can do the following:
-```javascript
-const examplePopup = irma.newPopup({
- debugging: false, // Enable to get helpful output in the browser console
-
- // Back-end options
- session: {
- // Configure your flow here, see usage guide of irma-core
- },
-
- ...
-});
-
-examplePopup.start()
-.then(result => console.log("Successful disclosure! 🎉", result))
-.catch(error => console.error("Couldn't do what you asked 😢", error));
-```
-
-Be aware that you can start an instance of `irma-frontend` only once.
-When you want to call `start()` again, you have to create a new instance.
-When a promise of an earlier `start()` call is not completed yet, promise rejection
-can be forced by calling the `abort()` method. In this way a new `irma-frontend`
-instance can be created without any risk on interference with other running instances.
-When a promise is rejected because of an `abort()` call, the promise will return the
-error message `Aborted`.
-
-```javascript
-exampleWeb.abort();
-examplePopup.abort();
-```
-
-More information about the methods the IRMA frontend package offers to you can be found
-in the [API overview](api-irma-frontend.md#irma-frontend).
-
-## IRMA css
-For the IRMA core plugins `irma-web` and `irma-popup` we made it possible to manually include the style
-that it will use. We provide to you a [normal version](https://github.com/privacybydesign/irma-frontend-packages/releases/latest/download/irma.css)
-and a [minified version](https://github.com/privacybydesign/irma-frontend-packages/releases/latest/download/irma.min.css)
-of the default styles. The CSS can be linked into your website the regular way:
-
-```html
-
-```
-
-When you want to adapt the design to suit for your own use case, you can take a look in the [styleguide](https://privacybydesign.github.io/irma-frontend-packages/styleguide/).
-Based on this you can adapt the CSS and then import the modified version into your project.
-Customized versions of `irma-css` can be used in combination with the `irma-web` and
-`irma-popup` plugins for `irma-core`.
-
-### Customizing the design
-Customizing the design is especially useful for developers that want to use an embedded
-web element to initiate the IRMA flow and see that the default design does not fit
-into the design of their website. We provide you a convenient way to alter the
-design and build a new, customized style. This can be done in the following way:
-
-1. Clone the [`irma-frontend-packages` repository](https://github.com/privacybydesign/irma-frontend-packages).
-2. Use our [guide](https://github.com/privacybydesign/irma-frontend-packages/tree/master/irma-css#compiling-locally)
- to compile the CSS styleguide locally.
-3. Make the desired changes in the source files. These files can be found in the
- `irma-css/src` directory.
-4. Check **all pages** of the locally built styleguide to check whether your local
- changes work for all flows.
-5. Build a release version for your customized CSS by running `npm run release` in the
- `irma-css` directory. The built CSS files can be found in the `irma-css/dist` directory.
-6. Include the new style in your website and use [IRMA core](#irma-core) in combination
- with the `irma-web` plugin (for embedded web elements) or the `irma-popup` plugin (for
- a popup overlay). The plugins will use the custom CSS that you have embedded. For
- managing the session state we recommend you to use the `irma-client` plugin.
-
-```javascript
-require('assets/my-custom-irma-css-design.min.css');
-
-const IrmaCore = require('@privacybydesign/irma-core');
-const IrmaWeb = require('@privacybydesign/irma-web');
-const IrmaClient = require('@privacybydesign/irma-client');
-
-const irma = new IrmaCore({
- debugging: true,
- element: '#irma-web-form',
- language: 'en',
- // Check the irma-web README on how to customize the default texts.
- session: {
- // Check the irma-client README for all options.
- },
-});
-
-irma.use(IrmaWeb);
-irma.use(IrmaClient);
-
-irma.start()
-.then(result => console.log("Successful disclosure! 🎉", result))
-.catch(error => {
- if (error === 'Aborted') {
- console.log('We closed it ourselves, so no problem 😅');
- return;
- }
- console.error("Couldn't do what you asked 😢", error);
-});
-```
-
-## Make your own IRMA core plugin
-If you need functionality that is not covered by one of the existing IRMA core plugins, you can also define
-one yourself. In the constructor the `stateMachine` and the `options` from `IrmaCore` can be accessed.
-The constructor can be omitted if you do not need it.
-Furthermore a plugin can have a `start` method that is
-called when the `start` method of the associated `IrmaCore` instance is called, and a `stateChange` method
-that is called when the state of the state machine changes:
-
-```javascript
-class IrmaPlugin {
- // Optional
- constructor({stateMachine, options}) {
- ...
- }
-
- // Optional method
- start() {
- ...
- }
-
- // Optional method
- stateChange({newState, oldState, transition, isFinal, payload}) {
- ...
- }
-
- // Optional method
- close() {
- ...
- return Promise.resolve(); // Must return a Promise
- }
-}
-```
-
-A plugin can request the state machine to make changes. This can be done using the `transition` and
-`finalTransition` methods of the `stateMachine`. The first parameter of these functions is the requested
-transition. The possible transitions can be found in the [state machine](https://github.com/privacybydesign/irma-frontend-packages/blob/master/irma-core/state-transitions.js).
-As second parameter `payload` can be added to the transition. The payload can then be accessed by all other plugins
-as it is one of the parameters of the `stateChange` method. When requesting a `finalTransition`, the state
-machine will be locked in the new state. From then no transitions can be made anymore. For a `finalTransition`
-the potential `newState` must be in the list of possible end states. Otherwise an error is returned. After
-a `finalTransition` the `close` method of the plugin is called to close the plugin's state. This method should
-return a Promise which resolves when the plugin finishes closing. When the `close` Promises of all plugins are
-resolved, the promise returned by the `start` method of `IrmaCore` will resolve or reject (depending on the
-transaction). In this way we can guarantee that plugins are not active anymore when the promise returned by the
-`start` method of `IrmaCore` is finished. Besides when calling `finalTransition`, the closing procedure can also
-be activated when the `transition` method is used and the state machine gets in a state from which no
-transitions are possible anymore.
-
-For example, in the `IrmaPopup` plugin the user can press on the close button in the UI to abort the session.
-When this happens the `IrmaPopup` plugin must request a state change at the IRMA core state machine to
-notify all other plugins that the new state becomes `Aborted`. This is done in the following way:
-```javascript
-stateMachine.transition('abort', 'Popup closed');
-```
-
-There are no transitions possible anymore from the state `Aborted`. This means that unless the transition
-is not explicitly marked as final, the `stateChange` method of your plugin will be called with `isFinal` set
-to true.
-
-## Differences with [irmajs](irmajs.md)
-The previous JavaScript library `irmajs` combined frontend and backend functionality. The `startSession` related
-functions could be used to start sessions, and `handleSession` could be used for actually being the
-frontend to the user.
-
-In the new library we have split these functionalities into two libraries. The session management functionality
-for node.js server applications now belongs to the [`irma-backend-packages`](https://github.com/privacybydesign/irma-backend-packages).
-The `irma-frontend-packages` only deals with session handling for the (web)client, starting
-with fetching a session package from a remote server, then communicating with the `irma server` what the current status
-of the session is, and finally fetching the result if the client needs it.
-It also handles the user interaction related to all of these actions.
-
-As a rule of thumb, `irma-frontend-packages` is meant to handle the `/irma/...` endpoints, and
-`irma-backend-packages` is meant to handle the `/session/...` endpoints of the `irma server`. Theoretically,
-`irma-frontend-packages` is able to fetch a session package directly at the `irma server` and therefore also
-use the `/session` endpoint of the `irma server`. This flow is however not recommended. A better
-practice is to put a backend layer in between that starts the session at the `irma server`.
-
-For user interaction, we currently have support for a web element embedded in the content, a web browser
-popup overlay and console user interaction using node.js. Below you can find an overview of the plugins for
-`irma-core` and how they map to the methods known from `irmajs`. In all cases the [`irma-client`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client)
-plugin is needed for server communication.
-
-| irmajs method | irma-frontend plugin | Differences |
-|---|---|---|
-| `'popup'` | [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-popup) | Does not always reject on cancellation or timeout. When a `start` endpoint is specified at `irma-client` to fetch a new session package, the user gets the opportunity to try again. Also, support for tablets has been added. The default [`irma-css`](#irma-css) style can be used or a custom CSS template can be defined to give it your own look and feel. |
-| `'canvas'` | [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web) | Has been upgraded to a full web element to also be able to handle tablets. Auto-refreshment of the QR on session timeout is now supported. Furthermore, the differences mentioned at the method `popup` also apply here. |
-| `'mobile'` | [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web) or [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-popup) | The mobile flow is fully integrated into the web and popup interfaces. Please check those options to see the differences. |
-| `'console'` | [`irma-console`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-console) | No major differences. |
-| `'url'` | _No support_ | The url can simply be constructed according to the format `https://irma.app/-/session#` where `` has to be replaced with the session package JSON object (converted to a string using url encoding). A session package can be retrieved using the [`irma-backend-packages`](https://github.com/privacybydesign/irma-backend-packages). |
-
-For users that have difficulties integrating a new library, but do want to upgrade, we also provide a [`irma-legacy`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/irma-legacy)
-wrapper that maps the legacy `irmajs` calls onto the new `irma-frontend-packages`. More information about this will follow.
diff --git a/website/versioned_docs/version-v0.7.0/irma-server.md b/website/versioned_docs/version-v0.7.0/irma-server.md
deleted file mode 100644
index 6a04466..0000000
--- a/website/versioned_docs/version-v0.7.0/irma-server.md
+++ /dev/null
@@ -1,294 +0,0 @@
----
-title: irma server
-id: version-v0.7.0-irma-server
-original_id: irma-server
----
-
-
-`irma server` is an IRMA server executable (daemon) allowing you to perform IRMA sessions with
-[IRMA apps](irma-app.md). It handles all IRMA-specific cryptographic details of issuing or verifying IRMA attributes with an IRMA app on behalf of a [requestor](overview.md#participants) (the application wishing to verify or issue attributes). It exposes the following:
- * HTTP endpoints under `/irma`, used by the IRMA app during IRMA sessions
- * a JSON API under `/sessions` for requestors, allowing them to request the server to verify or issue attributes.
-
-`irma server` is a subcommand of the [`irma`](irma-cli.md) command line tool, which additionally contains subcommands to start or perform IRMA sessions, handle [IRMA schemes](schemes.md), and more.
-
-For installation instructions, see [`irma`](irma-cli.md).
-
-## Running the server
-
-Simply run `irma server` to run the server with the default configuration in development mode. Use `irma server -v` for more verbose logging, for example to see the current configuration. Use `irma server -vv` to also log session contents.
-
-Run `irma server --help` to see configuration options. In order to verify your configuration, run `irma server check -v`.
-
-## Starting a session
-Assuming the server runs in the [default configuration](#default-configuration) (in particular [requestor authentication](#requestor-authentication) is disabled (`no_auth` is `true`) and the `irma-demo` [scheme](schemes.md) is installed), issue `irma-demo.MijnOverheid.ageLower` attributes using the [`session`](irma-cli.md) subcommand of the `irma` tool:
-```shell
-irma session --server http://localhost:8088 --issue irma-demo.MijnOverheid.ageLower=yes,yes,yes,no
-```
-Verify the `irma-demo.MijnOverheid.ageLower.over18` attribute:
-```shell
-irma session --server http://localhost:8088 --disclose irma-demo.MijnOverheid.ageLower.over18
-```
-These print QRs in your terminal that you can scan with your [IRMA app](irma-app.md) to perform the session. For more extensive examples, see [irmajs](irmajs.md).
-
-## Configuring
-Run `irma server -h` to see all configuration options. Each option may be passed as:
- 1. a command line flags (e.g. [`--listen-addr`](#http-server-endpoints))
- 2. a environmental variable (e.g. `IRMASERVER_LISTEN_ADDR`)
- 3. an item in a configuration file (e.g. `"listen_addr"`) (which may be in JSON, TOML or YAML)
-
- with the following rules:
- * Flags supersede environmental variables which supersede configuration file entries.
- * Dashes are used in flags, but underscores are used in environmental variables and configuration file entries.
- * Environmental variables are uppercased and prefixed with `IRMASERVER_`.
- * The [`requestors`](#requestor-authentication) and [`static_sessions`](#static-irma-qrs) options are special: when passed as a flag or environmental variable, they must be passed as a JSON object (for example: `--requestors '{"myapp":{"auth_method":"token","key":"12345"}}'`).
- * When passing a boolean flag [use an `=`](https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax), for example [`--no-auth=false`](#requestor-authentication).
-
-In order to see the configuration that the server uses after having gathered input from these sources, specify `-v` or `-vv` or use the `verbose` option. Use `irma server check -v` (with the same flags, env vars and config files as `irma server`) to check your configuration for correctness before running the server.
-
-For a full configuation example, see [Getting started](getting-started.md#example-configuration-and-irma-session).
-
-In the remainder of this document, when referring to options we write them as configuration file entries, with underscores and without prefix.
-
-### Default configuration
-In the default configuration (run `irma server check -v` to see it) the server is immediately usable. In particular, it
-* uses the [default IRMA schemes](schemes.md#default-schemes-pbdf-and-irma-demo) ([`pbdf`](https://github.com/credentials/pbdf-schememanager) and [`irma-demo`](https://github.com/credentials/irma-demo-schememanager)), downloading them if necessary
-* allows anyone to use the server [without authentication](#requestor-authentication) (the `no_auth` setting is `true`).
-
-If the server is reachable from the internet, you should consider enabling authentication of session requests.
-
-### Configuration files
-A configuration file can be provided using the `config` option (for example: `irma server --config ./irmaserver.json`). When not specified, the server looks for a configuration file called `irmaserver.json` or `irmaserver.toml` or `irmaserver.yaml` in (1) the current path; (2) `/etc/irmaserver/`; (3) `$HOME/irmaserver`, in that order. A configuration file is not required; if none is found at any of these locations the server takes its configuration from just command line flags and environmental variables.
-
-### Production mode
-When running the server in production, you should enable the `production` option. This enables stricter defaults on the configuration options for safety and prints warnings on possibly unsafe configurations. In particular, when `production` is enabled, the default values of some options change as follows (cf. `diff <(irma server -h) <(irma server -h --production)`):
-
-* `url` from `"http://$YOUR_LOCAL_IP:port"` to `""`: in development mode the `url` to which IRMA apps will connect is set by default to your current local IP address; in `production` mode you must configure it yourself.
-* [`no_auth`](#requestor-authentication) from `true` to `false`: you should consider enabling requestor authentication, or explicitly disable this by setting this flag to `true`.
-* [`issue_perms`](#global-permissions) from `[*]` (everything) to `[]` (none).
-* [`no_email`](email.md) from `true` to `false`: in `production` mode, opting out of providing an email address can be done by explicitly setting this flag to `true`.
-
-In addition, when [developer mode is not enabled in the IRMA app](irma-app.md#developer-mode) (the default setting), the IRMA app wil refuse to perform sessions with IRMA servers not running in `production` mode. Since the majority of the IRMA app users will not have developer mode enabled, this requires IRMA servers facing those users to enable `production` mode.
-
-### Keys and certificates
-For each configuration option that refers to some kind of key or certificate (for example `jwt_privkey`), there is a corresponding option with the `_file` suffix (for example `jwt_privkey_file`). Keys can be specified either by setting former to a (PEM) string, or setting the the latter to a file containing the (PEM) string.
-
-### HTTP server endpoints
-The HTTP endpoints that this server offers is split into two parts:
-* `/session`: used by the requestor to start sessions, check session status, or get session results.
-* `/irma`: used by the IRMA app during IRMA sessions.
-
-In the default mode, the server starts one HTTP server that offers both, configured with `listen_addr` and `port`. If however the `client_port` and `client_listen_addr` options are provided, then the server starts two separate HTTP servers:
-* `/session` attaches to the address and port provided with `port` and `listen_addr`.
-* `/irma` attaches to the address and port provided with `client_port` and `client_listen_addr`.
-
-The `/irma` endpoints must always be reachable for the IRMA app. Using this double server mode you can restrict access to the `/session` endpoints by e.g. setting `listen_addr` to `127.0.0.1` or to an interface only reachable from an internal network. Restricting access to the `/session` endpoints in this way may make requestor authentication unnecessary.
-
-### Requestor authentication
-The server runs in one of two modes: it either accepts all session requests from anyone that can reach the server, or it accepts only authenticated session requests from authorized requestors. This can be toggled with the `no_auth` boolean option. If the `/session` creation endpoint of your `irma server` is publicly accessible from the internet (i.e. the `client_port` option is used, see [above](#http-server-endpoints)), then you should consider enabling requestor authentication (i.e. turn `no_auth` off), otherwise anyone can use your `irma server`.
-
-The default is `true` (requests are not authenticated) when `production` is disabled and `false` otherwise.
-
-When authentication is enabled (`no_auth` is `false`), requestors that are authorized to use the server must be configured in the `requestor` option in the form of a map, for example:
-
-```json
-{
- "requestors": {
- "myapp": {
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-
-The server supports several authentication methods, one of which must be specified in the `auth_method` field for each requestor. The snippet above demonstrates the recommended and easiest to use authentication method, called `token`. When using this method the requestor must include the `key` as an API token in a HTTP header (for more details see the [API reference](api-irma-server.md#post-session)).
-
-In addition the server supports the following authentication methods:
-* `hmac`: the requestor symmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/), with HMAC-SHA256 (`HS256`) using `key`. The `key` provided should be the Base64 encoding of the actual secret.
-* `publickey`: the requestor asymmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/) with RSA (`RS256`), in this case `key` should be the PEM public key of the requestor.
-
-For each of these modes it is also possible to specify `key_file` instead `key`; in that case the file at `key_file` will be read and used as `key`.
-
-### Static IRMA QRs
-Unlike normal QRs which differ per session (as they contain the session token), the server also supports static QRs which, when scanned by the IRMA app, start preconfigured IRMA sessions. This makes it possible to for example print such a static QR. These preconfigured sessions are configured with the `static_sessions` options, for example:
-```json
-{
- "static_sessions": {
- "mystaticsession": {
- "callbackUrl": "https://example.com/callbackUrl",
- "request": {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "irma-demo.MijnOverheid.ageLower.over18" ]]]
- }
- }
- }
-}
-```
-Thus `static_sessions` must contain a map of which each item must be an [extended session request](session-requests.md#extra-parameters). Including a `callbackUrl` to which the [session result](api-irma-server.md#get-session-token-result) is sent after the session is required (since for these sessions there is no requestor waiting to receive the attributes after the session has finished). If a JWT private key is installed, then the session result is sent as a [JWT](api-irma-server.md#get-session-token-result-jwt).
-
-> If no JWT private key is installed, then the `callbackUrl` should either not be publically reachable, or it should include a secret token (e.g. https://example.com/cX5aTins5kEZpjDpfYcN) and have TLS enabled (which it should anyway as personal data will be POSTed to it). Otherwise there is no way of distinguishing POSTs from your `irma server` from POSTs made by someone else.
-
-Assuming the URL of the `irma server` is `http://example.com`, the session configured above is started when the IRMA app scans a QR with the following contents:
-```json
-{
- "irmaqr": "redirect",
- "u": "http://example.com/irma/session/mystaticsession"
-}
-```
-
-Only static [disclosure or attribute-based signature sessions](what-is-irma.md#session-types) are supported.
-
-### Permissions
-For each of the [three IRMA session types](what-is-irma.md#session-types) (attribute verification; attribute-based signature sessions; and attribute issuance), permission to use specific attributes/credentials can be granted to requestors in the configuration. For example, including permissions in the `myapp` requestor from above:
-```json
-{
- "requestors": {
- "myapp": {
- "disclose_perms": [ "irma-demo.MijnOverheid.ageLower.over18" ],
- "sign_perms": [ "irma-demo.MijnOverheid.ageLower.*" ],
- "issue_perms": [ "irma-demo.MijnOverheid.ageLower" ],
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-This means that `myapp` is authorized to request `irma-demo.MijnOverheid.ageLower.over18` in disclosure session, and any attribute from `irma-demo.MijnOverheid.ageLower` in attribute-based signature sessions. Additionally `myapp` can issue `irma-demo.MijnOverheid.ageLower` instances. In each level wildcards are permitted (`irma-demo.MijnOverheid.ageLower.*`, `irma-demo.MijnOverheid.*`, `irma-demo.*`, `*`). Thus `"disclose_perms": [ "*" ]` allows the requestor to verify any attribute.
-
-### Global permissions
-
-Global permissions can be applied to all requestors by using the global `disclose_perms`, `sign_perms` and `issue_perms` options. For each requestor, the effective set of permissions is the union of the permissions specified in its `requestors` map and the global permission set.
-
-The global options also work when `no_auth` is enabled. Thus in this case a session type can be disabled by granting no one the permission, e.g., `issue_perms: []` would disable issuance.
-
-In development mode, when `production` is `false`, the defaults for `disclose_perms`, `sign_perms` and `issue_perms` are `["*"]`. In order to protect any IRMA private keys that the server has access to from unintended use by others, when `production` is true the default of `issue_perms` is `[]`: no one can issue unless the global `issue_perms` is modified or unless specific requestors receive nonempty `issue_perms`.
-
-### Client return urls
-
-In session requests, the server can be asked to pass a [client return url](session-requests.md#client-return-url) to the IRMA app, which the app will open after completing the session for sessions that involve only one device. This feature is always enabled.
-
-### Augmented client return urls
-
-The server can be configured to [augment the client return url](session-requests.md#augmenting-the-client-return-url) when requested. In order to enable this feature, the `augment_client_return_url` setting needs to be set to `true`.
-
-### Static file hosting
-
-Apart from hosting endpoints under [`/session` and `/irma`](irma-server.md#http-server-endpoints), the server also supports statically hosting all files from a certain directory. This can be useful [for experimenting](getting-started.md#perform-browser-irma-session). It can be configured with the following options:
-
-* `static_path`: Host files under this path as static files. Leave empty to disable static file hosting.
-* `static_prefix`: Host static files under this URL prefix (default: no prefix)
-
-### IRMA schemes
-
-The server uses [IRMA schemes](schemes.md) to retrieve issuer, credential and attribute names, as well as public and private keys with which attributes can be verified an issued, respectively. By default the server uses the [`pbdf` and `irma-demo` schemes](schemes.md#default-schemes-pbdf-and-irma-demo). This can be configured with the following options:
-
-* `schemes_path`: path containing IRMA schemes (often called `irma_configuration`). Default: `C:\Users\Username\AppData\Local\irma\irma_configuration` on Windows, `$HOME/.local/share/irma/irma_configuration` otherwise. Created if it does not exist. If empty, the default schemes [`pbdf` and `irma-demo`](schemes.md#default-schemes-pbdf-and-irma-demo) are downloaded into it.
-* `schemes_assets_path`: path containing initial, read-only IRMA schemes. If specified, the schemes found here are copied into the path specified by `schemes_path`. Can be used to avoid downloading default schemes on first run.
-* `schemes_update`: update IRMA schemes from their scheme URL every this many minutes. Default is `60`. Set to `0` to disable automatic scheme updating (not recommended).
-
-### IRMA issuer private keys
-
-If IRMA issuer private keys are included in the server configuration, then the server can issue all credential types of all issuers for which private keys are installed. IRMA issuer private keys can be configured in the following two ways:
-
-* Include the private keys within the [IRMA scheme](schemes.md) in the issuer's `PrivateKeys` folder, with filenames `0.xml`, `1.xml`, etc ([example](https://github.com/privacybydesign/irma-demo-schememanager/tree/master/MijnOverheid/PrivateKeys)).
-* Set the `privkeys` option to a folder containing IRMA issuer private keys called `scheme.issuer.xml` or `scheme.issuer.counter.xml` (for example, `irma-demo.MijnOverheid.xml` or `irma-demo.MijnOverheid.2.xml`).
-
-If issuance is enabled in production and private keys are configured, then you should ensure that only authenticated requestors can start issuance requests (otherwise if anyone can use your server to issue attributes then those attributes cannot be trusted or used). You should either:
-
-* disable `no_auth` and [send authenticated session requests](irma-server.md#requestor-authentication),
-* Restrict the [`/session` HTTP endpoints](#http-server-endpoints) to a internal network interface only accessible by your applications and not from outside.
-
-Taking neither approach is an unsafe configuration as in that case anyone can create issuance sessions. In this case, if `production` mode is enabled then the server will refuse to run.
-
-### Signed JWT session results
-
-If a `jwt_privkey` (or `jwt_privkey_file`) is given, then the following endpoints are enabled:
-
-* `GET /session/{sessiontoken}/result-jwt`: returns the session result signed by the `irma server` into a JWT.
-* `GET /session/{sessiontoken}/getproof`: returns a JWT similar to the one from `result-jwt`, but with the same structure as the IRMA API server session result JWTs.
-* `GET /publickey`: returns the public key with which the JWTs output by this server can be verified.
-
-This can be useful if the session result travels along an unsafe or untrusted route from the IRMA server to the requestor. As long as the `irma server` is trusted and its public key is known, the JWT can be verified to ensure that the session result was untampered with since it left the `irma server`.
-
-### TLS
-
-The [IRMA protocol](irma-protocol.md) relies on TLS for encryption of the attributes as they travel along the internet. If your server is connected to the internet and it handles actual attributes (personal data from people), then you ***must*** ensure that the attributes are protected in transit with TLS. In its default configuration (i.e. with [developer mode](irma-app.md#developer-mode) disabled), the IRMA app will refuse to connect to servers not using TLS.
-
-You can enable TLS in the `irma server` with the `tls_cert` and `tls_privkey` options (or the `_file` equivalents), specifying a PEM certificate (chain) and PEM private key. If you use [separate requestor and app endpoints](#http-server-endpoints), additionally use `client_tls_cert` and `client_tls_privkey`.
-
-Alternatively, if your IRMA server is connected to the internet through a reverse proxy then your reverse proxy probably handles TLS for you.
-
-### Email
-
-Users of the server are encouraged to provide an email address with the `email` option, subscribing for notifications about changes in the IRMA software or ecosystem. [More information](email.md). In `production` mode, it is required to either provide an email address or to explicitly out with the `no_email` option.
-
-### Logging and verbosity
-
-The server's verbosity can be increased by two degrees:
-* `-v` flag is given, or `verbosity` option set to `1`: includes `DEBUG` messages. Logs server configuration when starting the server, stack traces of errors, and more.
-* `-vv` flag is given, or `verbosity` option set to `2`: includes `TRACE` messages. Additionally includes dumps of all HTTP traffic from and to the server.
-
-> in its default mode, the server will not log attribute values (personal data). If the verbosity is increased, then attribute values may be logged. You should avoid doing this in production.
-
-The output is [structured](https://github.com/sirupsen/logrus#fields), putting certain recurring values in fields:
-```text
-[2019-02-28T20:51:09+01:00] INFO Session started action=disclosing session=WdypvSs97JTotpfl1Dtd
-```
-Outputting JSON is enabled with the `log-json` option:
-```json
-{"action":"disclosing","level":"info","msg":"Session started","session":"WdypvSs97JTotpfl1Dtd","time":"2019-02-28T20:51:09+01:00"}
-```
-
-## Running as daemon
-
-On most Linux systems, the `irma server` can be made into an automatically started daemon as follows:
-
-1. Write a new systemd unit file to `/etc/systemd/system/irmaserver.service`:
- ```ini
- [Unit]
- Description=IRMA server
- Documentation=https://irma.app/docs/irma-server
- Requires=network.target
-
- [Service]
- Type=simple
- ExecStart=/usr/local/bin/irma server --config=/etc/irmaserver/config.json
- TimeoutStopSec=60
- Restart=always
- RestartSec=1
- StandardOutput=syslog
- StandardError=syslog
- SyslogIdentifier=irma
- User=irmaserver
- Group=irmaserver
-
- [Install]
- WantedBy=multi-user.target
- ```
- Modify the path to `irma` and [your configuration file (or flags or environmental variables)](#configuring) in `ExecStart` as needed, as well as `User` and `Group`.
-2. Start the daemon and schedule it for automatic start on boot by running `systemctl start irmaserver.service && systemctl enable irmaserver.service`.
-
-See `systemctl status irmaserver.service` for the status of the daemon, and `journalctl -u irmaserver.service` for the console output of the IRMA server.
-
-## Design goals
-
-The server was designed with the following goals in mind.
-- Developer and user friendliness
- - Each of the [configuration options](#configuring) can be specified in a configuration file, command line flag, or environmental vars (see `-h`)
- - Default configuration (demo mode) is immediately useful
- - Thorough and configurable logging (`-v`, `-vv`; by default logs exclude attribute values)
- - Partial backwards compatibility with predecessor [`irma_api_server`](https://github.com/privacybydesign/irma_api_server)
- - Small startup time
-- Also available as [Go library](irma-server-lib.md) instead of standalone server
- - Bindings to other programming languages (Python, Ruby) are expected
-
-Being written in [Go](https://golang.org/), this server (in fact, the containing [`irma` binary](irma-cli.md)) additionally automatically has the following properties.
-- Simple to install (one binary, no dependencies, cross platform) and/or compile
-- [Reproducible builds](https://www.gnu.org/software/mes/manual/html_node/Reproducible-Builds.html)
-- [API documentation](https://godoc.org/github.com/privacybydesign/irmago) (generated automatically from `master` branch)
-
-Referring to Go packages (i.e. folders) under [`irmago`](https://github.com/privacybydesign/irmago), the server is structured as follows.
-* [`server/irmaserver`](irma-server-lib.md): Go library implementing the HTTP endpoints for the [IRMA protocol](irma-protocol.md) (in which the IRMA app is the client), and a Go API for requestors to manage sessons. ([Godoc API documentation](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver))
-* `server/requestorserver`: Go library wrapping `server/irmaserver`, exposing the requestor API as a second HTTP endpoint set under `/session` URLs instead of as Go functions (next to `/irma` for the IRMA app endpoints). ([Godoc API documentation](https://godoc.org/github.com/privacybydesign/irmago/server/requestorserver))
-* `irma`: executuable whose `server` commands wraps `server/requestorserver`.
diff --git a/website/versioned_docs/version-v0.7.0/irmajs.md b/website/versioned_docs/version-v0.7.0/irmajs.md
deleted file mode 100644
index 97812d3..0000000
--- a/website/versioned_docs/version-v0.7.0/irmajs.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-title: irmajs JavaScript library
-id: version-v0.7.0-irmajs
-original_id: irmajs
----
-
-> This concerns documentation of a deprecated library. Please use [`irma-frontend`](irma-frontend.md) instead. If you are looking for a library to manage your `irma server` using Node.js, you can use the JavaScript packages from [`irma-backend`](irma-backend.md).
-
-`irmajs` is a Javascript client of the RESTful JSON API offered by the [`irma server`](https://github.com/privacybydesign/irmago/tree/master/irma). It allows you to use the `irma server` to:
-
- * Verify IRMA attributes. You specify which attributes, the library handles the user interaction and the communication with the `irma server` and the [IRMA app](irma-app.md)).
- * Issue IRMA attributes.
- * Perform IRMA attribute-based signature sessions, resulting in a signature on a string to which IRMA attributes are verifiably attached.
-
-`irmajs` supports all major browsers (Firefox, Chrome, Safari, Edge, Internet Explorer 11).
-
-## Installation
-
-### Compiling from source
-Compile the library:
-
- git clone https://github.com/privacybydesign/irmajs.git
- cd irmajs
- npm install
- npm run build
-
-This writes `irma.js` to the `dist` folder, which you can include in your website in a ``) you can start an IRMA disclosure session as follows:
-
-```js
-const request = {
- '@context': 'https://irma.app/ld/request/disclosure/v2',
- 'disclose': [[[ 'irma-demo.MijnOverheid.ageLower.over18' ]]]
-};
-
-irma.startSession(server, request)
- .then(({ sessionPtr, token }) => irma.handleSession(sessionPtr, {server, token}))
- .then(result => console.log('Done', result));
-```
-
-This assumes you have an [`irma server`](irma-server.md) that is configured to [accept unauthenticated session requests](irma-server.md#requestor-authentication) listening at the URL indicated by `server`.
-
-For complete examples, see the `examples` folder. You can host these examples using the IRMA server, with:
-
- irma server -v --static-path examples/browser
-
-> If your `irma server` is publically reachable, having a setup like the one above allows anyone on the internet to start IRMA sessions at your `irma server`. Additionally, starting IRMA sessions from the browser is generally an antipattern. You should enable either [requestor authentication](irma-server.md#requestor-authentication) or [restrict access to the IRMA session creation endpoints](irma-server.md#http-server-endpoints).
-
-A more realistic configuration for this case may be found in the [Getting started](getting-started.md#example-configuration-and-irma-session) page.
diff --git a/website/versioned_docs/version-v0.7.0/session-requests.md b/website/versioned_docs/version-v0.7.0/session-requests.md
deleted file mode 100644
index ac2a178..0000000
--- a/website/versioned_docs/version-v0.7.0/session-requests.md
+++ /dev/null
@@ -1,486 +0,0 @@
----
-title: Session requests
-id: version-v0.7.0-session-requests
-original_id: session-requests
----
-
-
-
-Each [IRMA server](what-is-irma.md#irma-servers) exposes APIs for creating IRMA sessions with a session request. An *IRMA session request* contains all information required for the IRMA server and [IRMA app](irma-app.md) to perform an IRMA session with, such as the attributes to be issued or verified. This page documents IRMA session requests. It applies to:
-
-* The [`POST /session`](api-irma-server.md#post-session) endpoint from [`irma server`](irma-server.md).
-* The [`StartSession()` function](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver#StartSession) in the `irmaserver` Go library.
-* The [`startSession()` function](api-irmajs.md#startsession) of `irmajs`.
-
-For the precise role of session requests in an IRMA session, see this [diagram of an IRMA session](what-is-irma.md#irma-session-flow).
-
-## Session request data types
-
-For each of the [three IRMA session types](what-is-irma.md#session-types), we define a *session request* data type: an object whose JSON representation contains at least a [JSON-LD `@context`](https://w3c.github.io/json-ld-syntax/#the-context) key identifying which message type it is, and extra keys specific to the session type. The following three `@context` values identify disclosure, attribute-based signature, and issuance session requests respectively:
-
-* `"@context": "https://irma.app/ld/request/disclosure/v2"`
-* `"@context": "https://irma.app/ld/request/signature/v2"`
-* `"@context": "https://irma.app/ld/request/issuance/v2"`
-
-(For now these URIs do not resolve to anything; they just distinguish the message type.)
-
-## Disclosure requests
-Disclosure sessions are started with an [`irma.DisclosureRequest`](https://godoc.org/github.com/privacybydesign/irmago#DisclosureRequest). Example:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.MijnOverheid.root.BSN" ]
- ],
- [
- [
- "irma-demo.nijmegen.address.street",
- "irma-demo.nijmegen.address.houseNumber",
- "irma-demo.nijmegen.address.city"
- ],
- [
- "irma-demo.idin.idin.address",
- "irma-demo.idin.idin.city"
- ]
- ]
- ]
-}
-```
-
-```golang
-// Create a new empty request
-request := irma.NewDisclosureRequest()
-
-// Request specific attributes
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.root.BSN")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.nijmegen.address.street"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.houseNumber"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.city"),
- },
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.idin.idin.address"),
- irma.NewAttributeRequest("irma-demo.idin.idin.city"),
- },
- },
-}
-```
-
-
-
-
-This asks for a (demo) `BSN` attribute, as well as either `street`, `houseNumber` and `city` from `irma-demo.nijmegen.address`, or `address` and `city` from `irma-demo.idin.idin`. The three levels correspond to a *conjunction* of *disjunctions* of *conjunctions* of requested attributes, allowing verifiers to request multiple attribute sets from the user, offering choices for some or all of these sets.
-
-All of the attribute types (i.e., the string values) contained in the request must exist in their scheme ([`irma-demo`](https://github.com/privacybydesign/irma-demo-schememanager) in the example above). For the `irma-demo` and `pbdf` schemes, an index of existing attribute types that can be requested can be found [here](https://privacybydesign.foundation/attribute-index/en/).
-
-> Attributes can be disclosed to the requestor in any of the three session types: in issuance sessions issuance proceeds only if the user discloses the required attributes just before issuance, and in attribute-based signature sessions the requested attributes are attached to the resulting attribute-based signature. Thus the `disclose` and `labels` fields introduced above can also occur in issuance or attribute-based signature session requests (see below).
-
-### Multiple credential types within inner conjunctions
-In the request above 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).
-- 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 IRMA app automatically only offers candidate sets as choices to the user that satisfy this property.)
-
-For example, consider the following session request:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- "pbdf.pbdf.diploma.degree",
- "pbdf.pbdf.diploma.institute"
- ]
- ]
- ]
-}
-```
-
-```golang
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("pbdf.pbdf.diploma.degree"),
- irma.NewAttributeRequest("pbdf.pbdf.diploma.institute"),
- },
- },
-}
-```
-
-
-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.)
-
-When combining multiple credential types within a disjunction these restrictions ensure that when the IRMA app computes candidate attribute sets for the user to choose from, the amount of resulting options stays manageable. In adddition, the second restriction is a feature on its own, allowing verifiers to request multiple attributes coming from one credential instance.
-
-### Requesting specific attribute values
-Within inner conjunctions, specific attribute values can be requested by replacing the string with an object like the following:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "pbdf.pbdf.diploma.degree", "value": "PhD" },
- { "type": "pbdf.pbdf.diploma.institute", "value": null }
- ]
- ]
- ]
-}
-```
-
-```go
-phd := "PhD"
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.degree"),
- Value: &phd,
- }, {
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.institute"),
- Value: nil,
- }},
- },
-}
-```
-
-
-This would only be satisfied by a `degree` attribute whose value is `PhD`, together with any `institute` attribute. (Note that the object and string syntaxes can be mixed within an inner conjunction, i.e. it would be permissible in the JSON example above to replace the second object with just `"pbdf.pbdf.diploma.institute"`.)
-
-### Null attributes
-
-Whenever an attribute is marked with `optional` in the scheme ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)), the issuer may skip it when it issues an instance of the containing credential type, assigning a `null` value to it (which is distinct from the empty string `""`). When disclosing the attribute, the verifier receives `null` instead of a string containing the attribute value.
-
-If a non-null attribute is required this can be requested using `notNull` as follows:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "irma-demo.MijnOverheid.fullName.prefix", "notNull": true }
- ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("irma-demo.MijnOverheid.fullName.prefix"),
- NotNull: true,
- }},
- },
-}
-```
-
-
-The default value of `notNull` is `false`.
-
-### Optional disjunctions
-
-A disjunction within a session request can be marked as *optional*, by including an empty inner conjunction in it:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.nijmegen.address.city" ]
- ],
- [
- [],
- [ "irma-demo.MijnOverheid.fullName.firstname" ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.nijmegen.address.city")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{},
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.fullName.firstname")},
- },
-}
-```
-
-
-
-
-This can be useful when certain attributes are not required, so that if the user does not have them the session does not need to be aborted.
-
-### Disjunction labels
-
-Per disjunction a *label* can be specified, which is shown in the IRMA app when the user is asked for permission to disclose attributes. For example, the session request from [above](#disclosure-requests) could be augmented with a label for the second disjunction as follows:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [ ... ],
- [ ... ]
- ],
- "labels": {
- "1": { "en": "Work address", "nl": "Werk adres" }
- }
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Labels = map[int]irma.TranslatedString{
- 1: {"en": "Work address", "nl": "Werk adres"},
-}
-```
-
-
-
-
-In this way each disjunction can be given a optional label explaining to the user the purpose of the disjunction. It is recommended to only provide a label to explain something to the user that would otherwise not be obvious; for example, to request the user to send a work email address instead of a personal one. Repeating the credential or attribute name or description in labels is an antipattern.
-
-## Attribute-based signature requests
-Attribute-based signature sessions are started with an [`irma.SignatureRequest`](https://godoc.org/github.com/privacybydesign/irmago#SignatureRequest), which are similar to disclosure requests:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/signature/v2",
- "message": "Message to be signed by user",
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-request := irma.NewSignatureRequest("Message to be signed by user")
-request.Disclose = irma.AttributeConDisCon{ /* request attributes to attach to ABS */ }
-request.Labels = map[int]irma.TranslatedString{}
-```
-
-
-The `message` field is required. The attributes to be attached to the attribute-based signature are requested with the `disclose` field, which along with the `labels` field work exactly like in disclosure sessions.
-
-## Issuance requests
-Issuance sessions are started with an [`irma.IssuanceRequest`](https://godoc.org/github.com/privacybydesign/irmago#IssuanceRequest). Example:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/issuance/v2",
- "credentials": [{
- "credential": "irma-demo.MijnOverheid.ageLower",
- "validity": 1592438400,
- "attributes": {
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no"
- }
- }],
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-validity := irma.Timestamp(time.Unix(1592438400, 0))
-request := irma.NewIssuanceRequest([]*irma.CredentialRequest{
- {
- CredentialTypeID: irma.NewCredentialTypeIdentifier("irma-demo.MijnOverheid.ageLower"),
- Validity: &validity, // optional
- Attributes: map[string]string{
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no",
- },
- },
-})
-request.Disclose = irma.AttributeConDisCon{} // optional
-request.Labels = map[int]irma.TranslatedString{} // optional
-```
-
-
-Per credential in the `credentials` array the `validity` is optional; if skipped it is assigned the default value of 6 months. If present, the validity is always rounded down to the [nearest epoch boundary](overview.md#special-attributes), which is one week (60 * 60 * 24 * 7 = 604800 seconds).
-
-Attributes marked as `optional` in the containing credential type ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)) may be skipped in the `attributes` map. This issues [the `null` value](#null-attributes) to these attributes.
-
-`disclose` and `labels` are optional, allowing for *combined disclosure-issuance sessions*, in which the user is required to disclose attributes before the IRMA server will issue the credentials.
-
-The `clientReturnUrl` option can also be used, both for issuance only and combined disclosure-issuance sessions. Usage is similar as in [disclosure sessions](#client-return-url).
-
-## Client return URL
-If the user performs a mobile session, i.e. on the same device as where the IRMA app is installed on, then after the session has completed the user will be redirect to the `clientReturnUrl` specified in the session request, if present.
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- ...
- ],
- "clientReturnUrl": "https://example.com"
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.ClientReturnURL = "https://example.com"
-```
-
-
-The example shows a disclosure request but `clientReturnUrl` can be set on session requests of any type. If set, when the user finishes a session (either successfully or unsuccessfully), she is redirected to the location specified by `clientReturnUrl`.
-
-If *not* set:
-* On Android the IRMA app automatically toggles back to the previous app;
-* On iOS it is not possible to toggle back to the previous app due to restrictions by Apple, so the IRMA app stays open. In the top left corner of the screen, however, a button appears that leads back to the previous app.
-
-This URL does not necessarily have to be a web URL; it can also be a universal link to another app. Universal links work both on Android and iOS. It is also possible to use iOS or Android scheme URLs. (Note however that iOS and Android scheme URLs differ from one another, so when starting a session with a scheme URL as return URL you should therefore determine on which platform the user's app is running.)
-
-On iOS, toggling back to the calling app or website after the session can be simulated by navigating towards the calling app using a `clientReturnUrl`, either a normal URL or universal link. This works on Android as well, so currently this is the only platform-independent way of ensuring that the used ends up at a specified place after the session. If the URL opens a website, however, then the user is navigated towards a new browser tab instead of back to an existing browser tab, so in website-IRMA-website flows you will need to reload your webapp and state in the newly opened tab.
-
-### Augmenting the client return URL
-
-It is possible to have the IRMA server augment the `clientReturnUrl` with the server token of a session (i.e., the `token` in the [response of the `/session` endpoint](api-irma-server.md#post-session)). This token is then appended as a query parameter with name `token` to the `clientReturnUrl`. Using this token, one can the retrieve the [session result](api-irma-server.md#get-session-token-result).
-
-To enable this, both the server configuration flag `augment-client-return-url` needs to be enabled, as well as the `augmentReturnUrl` session request parameter needs to be true.
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- ...
- ],
- "augmentReturnUrl": true,
- "clientReturnUrl": "https://example.com"
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.ClientReturnURL = "https://example.com"
-request.AugmentReturnURL = true
-```
-
-
-In this example, the client return url would be augmented to become `https://example.com?token=0123456789abcdef`, where `0123456789abcdef` would be the server token of the session.
-
-## Extra parameters
-For each API that accepts one of the above session request data types, the requestor can provide additional parameters to configure the session at the IRMA server, by providing an *extended session request* instead, as follows:
-
-
-```json
-{
- "validity": 120,
- "timeout": 120,
- "callbackUrl": "https://example.com",
- "request": ...
-}
-```
-
-```go
-// See also corresponding types irma.SignatureRequestorRequest
-// and irma.IdentityProviderRequest
-irma.ServiceProviderRequest{
- irma.RequestorBaseRequest{
- ResultJwtValidity: 120,
- ClientTimeout: 120,
- CallbackUrl: "https://example.com",
- },
- irma.NewDisclosureRequest(),
-}
-```
-
-
-Below you can find an overview of all extra parameters and their default value.
-
-| Option (JSON) | Option (Go) | Meaning | Default value |
-| ------------- | ----------- | ------- | ------------- |
-| `"validity"` | `ResultJwtValidity` | Validity of session result JWT in seconds (to determine JWT expiration time `exp`) | 120 seconds |
-| `"timeout"` | `ClientTimeout` | Wait this many seconds for the IRMA app to connect before the session times out | 300 seconds (5 minutes) |
-| `"callbackUrl"` | `CallbackUrl` | URL to post session result to | `""` (no callback is performed) |
-
-## JWTs: signed session requests
-The IRMA API server or [`irma server`](irma-server.md) can be configured such that it only accepts session requests that have been digitally signed in the form of a [JWT](https://jwt.io). The form of the JWT depends on the [session type](what-is-irma.md#session-types). An example requesting [IRMATube](https://privacybydesign.foundation/demo/irmaTube) attributes::
-```
-eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImlybWF0dWJlIn0.eyJpYXQiOjE1NjQ2NTczNzUsInN1YiI6InZlcmlmaWNhdGlvbl9yZXF1ZXN0Iiwic3ByZXF1ZXN0Ijp7InJlcXVlc3QiOnsiQGNvbnRleHQiOiJodHRwczovL2lybWEuYXBwL2xkL3JlcXVlc3QvZGlzY2xvc3VyZS92MiIsImRpc2Nsb3NlIjpbW1sicGJkZi5wYmRmLmlybWF0dWJlLnR5cGUiXV0sW1sicGJkZi5wYmRmLmFnZUxpbWl0cy5vdmVyMTIiXSxbInBiZGYuZ2VtZWVudGUucGVyc29uYWxEYXRhLm92ZXIxMiJdXV19fX0.lW9mqjrLkoahDP6Fcw_9mH5hlfl1tq5qp3W3ga0Nrd_j0NXFj-6ngqHVXEV1zhC_OkVH4LN8fMBAgN8nqaFWgEdQvrCuB7-ynuBVjLR-QU272Ym86zLEWYggAkbZ5KY40MpTxU1dgFMucG7fyAESic04OribWOCVxstAMsM28yCxvzkBMCOSjFEe3abcg_N6VvQnLn3LgZP_UrxQmQsh4DK7mBjW04LesLG1vjcliyhDGUb52FHOP_NAsG7G2FvIgojPzALlPrpTMu5p8a95wc5CGR791wybmh0F8kDdwZWAU0W2FjlX5bNPsyXN8AxRVWaRmWoGrGsQhy_sKEf8lg
-```
-In case of disclosure sessions, the body of the JWT (the part in between the two dots) contains a Base64-encoding of the following:
-
-
-```json
-{
- "iat": 1550424847,
- "sub": "verification_request",
- "sprequest": ...
-}
-```
-
-```go
-// Sets iat, iss, and sub fields.
-// See also corresponding functions irma.NewSignatureRequestorJwt()
-// and irma.NewIdentityProviderJwt().
-// Obtain signed JWT string to POST to an irma server using Sign() method.
-irma.NewServiceProviderJwt("IRMATube", irma.NewDisclosureRequest())
-```
-
-
-The fields are as follows:
-* `iat`: Unix timestamp of the creation date of the JWT. IRMA servers may reject JWTs beyond a certain age.
-* `iss`: contains the requestor name, and is used by the IRMA server to lookup the appropriate key with which to verify the JWT.
-* `sub`: JWT subject, in case of disclosure sessions this must always be `"verification_request"`.
-* `sprequest`: contains an extended disclosure session request as defined above.
-
-For each possible session type, the contents of the `sub` field and the name of the field containing the session request must be as follows.
-
-| Session type | `sub` contents | Session request field name | Go function |
-| ------------ | -------------- | -------------------------- | ----------- |
-| Disclosure | `verification_request` | `sprequest` | `irma.NewServiceProviderJwt()` |
-| Attribute-based signature | `signature_request` | `absrequest` | `irma.NewSignatureRequestorJwt()` |
-| Issuance | `issue_request` | `iprequest` | `irma.NewIdentityProviderJwt()` |
-
-Currently the following libraries can produce JWTs of this form:
-* The [`irmago`](https://godoc.org/github.com/privacybydesign/irmago) library, using the mentioned functions
-* The [`irmajs`](irmajs.md) Javascript library
-* The [`irma-requestor`](https://github.com/privacybydesign/irma-requestor) PHP library
-* The [`irma_api_common`](https://github.com/privacybydesign/irma_api_common) Java library
-* The [`irma-diva-js`](https://github.com/Alliander/diva-irma-js) Javascript library
-
-`irma server` currently supports JWTs signed (asymmetrically with RSA) with the `RS256` algorithm, and (symmetrically signed with HMAC-SHA256) `RS256`. The IRMA API server only supports `RS256`.
diff --git a/website/versioned_docs/version-v0.8.0/api-irma-server.md b/website/versioned_docs/version-v0.8.0/api-irma-server.md
deleted file mode 100644
index b196455..0000000
--- a/website/versioned_docs/version-v0.8.0/api-irma-server.md
+++ /dev/null
@@ -1,294 +0,0 @@
----
-title: irma server
-id: version-v0.8.0-api-irma-server
-original_id: api-irma-server
----
-
-```shell
-irma server [options...]
-```
-
-The API that this server offers consists of two parts:
-
-* [Endpoints under `/session`](#api-reference-requestor-endpoints) with which IRMA session requestors can start IRMA sessions, monitor their status and retrieve their result afterwards.
-* [Endpoints under `/irma`](#api-reference-irma-endpoints) for [frontend libraries](irma-frontend.md) and the [irmaclient](https://github.com/privacybydesign/irmago/tree/master/irmaclient)/[IRMA app](irma-app.md).
- * [Frontend endpoints under `/irma`](#api-reference-irma-frontend-endpoints) exclusively for [frontend libraries](irma-frontend.md).
-
----
-## API overview
-
-
-
----
-
-For each of these endpoints, if the HTTP status code indicates that the request was not successful (i.e. not in the 2xx range), then the server returns an [`irma.RemoteError`](https://godoc.org/github.com/privacybydesign/irmago#RemoteError) instance. For example, attempting to [retrieve the session result](#get-session-requestortoken-result) of an unknown session returns:
-```json
-{"status": 400, "error": "SESSION_UNKNOWN", "description": "Unknown or expired session"}
-```
-The following fields may occur in this message:
-* `status`: HTTP error code associated to this error
-* `error`: an error `Type` from the list of possible errors in the [server API documentation](https://godoc.org/github.com/privacybydesign/irmago/server#Error)
-* `description`: English human-readable description of this error
-* `message`: May contain additional information
-* `stacktrace`: Stack trace of the error, only if verbose mode is enabled
-
-## API reference requestor endpoints
-
----
-
-### `POST /session`
-
-Start an IRMA session. What to POST to this endpoint depends on the server configuration:
-
-* If `no_auth` is true, an [(extended) JSON session request](session-requests.md)
-* If `no_auth` is false:
- * [(extended) JSON session request](session-requests.md) with an API token in the `Authorization` HTTP header
- * [JWT session request](session-requests.md#jwts-signed-session-requests) signed with RS256 or HS256
-
-If `no_auth` is false, then which of these options should be taken depends on the [`requestors`](irma-server.md#requestor-authentication) option passed to the `irma server`.
-
-In each case an appropriate `Content-Type` with `text/plain` or `application/json` must be included.
-
-If the request was successfully parsed, and authenticated if applicable, then the server returns a *session package*:
-```json
-{
- "token":"KzxuWKwL5KGLKr4uerws",
- "sessionPtr": {"u":"https://example.com/irma/session/ysDohpoySavbHAUDjmpz","irmaqr":"disclosing"},
- "frontendRequest": {
- "authorization":"qGrMmL8UZwZ88Sq8gobV",
- "minProtocolVersion": "1.0",
- "maxProtocolVersion": "1.1"
- }
-}
-```
-In the endpoints below, the `{requestorToken}` placeholder must be replaced with the above session `token`. The `sessionPtr` points to the IRMA session for the IRMA app user, and should be displayed as a QR for the user to scan, or encoded in a universal link for a mobile session, e.g. using [`irma-frontend`](api-irma-frontend.md).
-The final part of the `u` field in the `sessionPtr` is called the `clientToken`. The `clientToken` can be used to access the [public `/irma` endpoints](#api-reference-irma-endpoints) of the irma server.
-For accessing and using the [`/irma` frontend endpoints](#api-reference-irma-frontend-endpoints), you need the `frontendRequest`.
-
-Each session starts in the `"INITIALIZED"` [session status](#get-session-requestortoken-status). Regardless of how it reaches its ending status (`"DONE"`, `"CANCELLED"`, `"TIMEOUT"`), it is kept in memory for 5 minutes after reaching its ending status. After that all endpoints below requiring the requestor `token` return error `"SESSION_UNKNOWN"`.
-
----
-
-### `DELETE /session/{requestorToken}`
-
-Cancel the session: set the [session status](#get-session-requestortoken-status) to `"CANCELLED"`.
-
-> There is also a [variant of this endpoint](#delete-irma-session-clienttoken) for frontends (and IRMA apps) using client tokens (the final part of the `u` field in a `sessionPtr`).
-
----
-
-### `GET /session/{requestorToken}/status`
-
-Retrieve the [session status](https://godoc.org/github.com/privacybydesign/irmago/server#Status) as a JSON string. Returns one of:
-* `"INITIALIZED"`: the session has been started and is waiting for the client
-* `"PAIRING"`: the client is waiting for the frontend to [give permission to connect](#post-irma-session-clienttoken-frontend-pairingcompleted)
-* `"CONNECTED"`: the client has retrieved the session request, we wait for its response
-* `"CANCELLED"`: the session is cancelled: the user refused, or the user did not have the requested attributes, or an error occurred during the session
-* `"DONE"`: the session has completed successfully
-* `"TIMEOUT"`: session timed out
-
-Of these the latter three are *ending statuses*; once the session reaches such a status, it will not switch status again. A session starts as `"INITIALIZED"`. When being in a non-ending status (one of the first three), all statuses below that status in the list are possible next statuses.
-
-> The session is cancelled and receives status `"CANCELLED"` not only when the IRMA app user refuses, but also when the session is aborted due to an error.
-
-> If the session is cancelled due to the user aborting, it is (by design) not possible using this or the other endpoints of the `irma server` to distinguish between (1) the user had the requested attributes but refused to disclose them, and (2) the session was aborted by the user's IRMA app because (s)he did not have the required attributes.
-
-> There is also a [variant of this endpoint](#get-irma-session-clienttoken-status) for frontends (and IRMA apps) using client tokens (the final part of the `u` field in a `sessionPtr`).
-
----
-
-### `GET /session/{requestorToken}/statusevents`
-
-Subscribe to a [server-sent event](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events) stream of status updates. Whenever the session status changes, an event is sent with the new session status as a JSON string. If you need to monitor the status of a session, this is preferred over polling to `GET /session/{requestorToken}/status`.
-
-> There is also a [variant of this endpoint](#get-irma-session-clienttoken-statusevents) for frontends (and IRMA apps) using client tokens (the final part of the `u` field in a `sessionPtr`)
-
----
-
-### `GET /session/{requestorToken}/result`
-
-Get the [session result](https://godoc.org/github.com/privacybydesign/irmago/server#SessionResult). Example output:
-```json
-{
- "type" : "disclosing",
- "status" : "DONE",
- "disclosed" : [
- [{
- "status" : "PRESENT",
- "rawvalue" : "yes",
- "id" : "irma-demo.MijnOverheid.ageLower.over18",
- "value" : {
- "en" : "yes",
- "nl" : "yes",
- "" : "yes"
- }
- }]
- ],
- "proofStatus" : "VALID",
- "token" : "ELMExi5iauWYHzbH7gwU"
-}
-```
-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"`
-* `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
- * `"INVALID_TIMESTAMP"`: Attribute-based signature has invalid timestamp
- * `"UNMATCHED_REQUEST"`: proofs do not correspond to a specified request
- * `"MISSING_ATTRIBUTES"`: proofs do not contain all requested attributes
- * `"EXPIRED"`: Attributes were expired at creation time
-* `disclosed`: List of [attributes disclosed](https://godoc.org/github.com/privacybydesign/irmago#DisclosedAttribute) by the user. The array structure mirrors that of the [session request](session-requests#disclosure-requests) that started the session: the i-th item of the outer array is a conjunction of attributes satisfying the i-th outer conjunction of the session request. (*Note*: if the session was started with a legacy, pre-[condiscon](condiscon.md) session request, then this array structure has a different legacy structure; see the [legacy documentation](/v0.2.0/api-irma-server#get-session-requestortoken-result))
-* `signature`: The full attribute-based signature in case of `"signing"` sessions
-* `error`: Error message in case of failure
-
-If the session is not yet finished (that is, the session status is `INITIALIZED` or `CONNECTED`), then only the first three fields are populated. (For getting just the current session status, using [`GET /session/{requestorToken}/statusevents`](#get-session-requestortoken-statusevents) or [`GET /session/{requestorToken}/status`](#get-session-requestortoken-status) is preferred.)
-
-This endpoint just fetches the session result, and works normally even if the session failed. If so, the `status`, `proofStatus` or `error` fields will indicate what happened. Be sure to check these fields when retrieving and handling the session result.
-
----
-
-### `GET /session/{requestorToken}/result-jwt`
-
-If a JWT private key was [provided in the configuration of the `irma server`](irma-server.md#signed-jwt-session-results), then this returns a [JWT](https://jwt.io) signed by the `irma server` with the message from [`GET /session/{requestorToken}/result`](#get-session-requestortoken-result) above as JWT body, along with the following standard JWT fields:
-* `iss`: name of the current `irma server` as defined in its configuration
-* `iat`: Unix timestamp indicating when this JWT was created
-* `sub`: `verification_result` or `signing_result` or `issuing_result`
-
-This way, even if the session result from the `irma server` travels along an untrusted route (for example the user's browser), the session result can still be validated and trusted.
-
----
-
-### `GET /session/{requestorToken}/getproof`
-
-Also returns a session result JWT, but one whose structure is the same as the session JWTs returned by the [`irma_api_server`](https://github.com/privacybydesign/irma_api_server). Only works if a JWT private key was [provided in the configuration of the `irma server`](irma-server.md#signed-jwt-session-results).
-
----
-
-### `GET /publickey`
-
-If a JWT private key was [provided in the configuration of the `irma server`](irma-server.md#signed-jwt-session-results), then this returns the corresponding public key in PEM with which the server's session result JWTs returned by [`GET /session/{requestorToken}/result-jwt`](#get-session-requestortoken-result-jwt) and [`GET /session/{requestorToken}/getproof`](#get-session-requestortoken-getproof) can be verified.
-
----
-
-## API reference `/irma` endpoints
-The `/irma` endpoints of your IRMA server have to be publicly reachable from the internet. Most of the endpoints
-behind the `/irma` prefix are exclusively used by the
-[irmaclient](https://github.com/privacybydesign/irmago/tree/master/irmaclient)/[IRMA app](irma-app.md).
-These endpoints are documented in full in the page on the [IRMA protocol](irma-protocol.md).
-The endpoints used by both the IRMA app and the [frontend libraries](irma-frontend.md) are documented below.
-The endpoints exclusively meant for frontend libraries can be found below [in a separate section](#api-reference-irma-frontend-endpoints).
-
----
-
-### `DELETE /irma/session/{clientToken}`
-Behaves exactly the same as the [delete endpoint for requestors](#delete-session-requestortoken), but uses the
-[client token from the `sessionPtr`](#post-session) instead of the requestor token.
-
----
-
-### `GET /irma/session/{clientToken}/status`
-Behaves exactly the same as the [status endpoint for requestors](#get-session-requestortoken-status), but uses the [client token
-from the `sessionPtr`](#post-session) instead of the requestor token. For frontend libraries, this endpoint is deprecated.
-Please use the [frontend status endpoint](#get-irma-session-clienttoken-frontend-status) instead.
-
----
-
-### `GET /irma/session/{clientToken}/statusevents`
-Behaves exactly the same as the [statusevents endpoint for requestors](#get-session-requestortoken-statusevents), but uses the
-[client token from the `sessionPtr`](#post-session) instead of the requestor token. For frontend libraries this endpoint is deprecated.
-Please use the [frontend statusevents endpoint](#get-irma-session-clienttoken-frontend-statusevents) instead.
-
----
-
-## API reference `/irma` frontend endpoints
-The frontend endpoints are exclusively meant for [frontend libraries](irma-frontend.md) to communicate with the IRMA server.
-Frontends need the information from the `frontendRequest` in order to use these endpoints. The `frontendRequest` is received
-along with the `sessionPtr` from the [`POST /session`](#post-session) requestor endpoint.
-Just like the [other `/irma` endpoints](#api-reference-irma-endpoints), the frontend endpoints of your IRMA server
-have to be publicly reachable from the internet.
-
-To make sure these endpoints can only be accessed by frontends, requests should be done with an
-additional `Authorization` HTTP request header. The expected value for this request header is the `authorization`
-token in the `frontendRequest`.
-
-The frontend endpoints in this version of the IRMA server implement frontend protocol version 1.1.
-
-### `GET /irma/session/{clientToken}/frontend/status`
-Retrieve the current [session status](https://godoc.org/github.com/privacybydesign/irmago/server#Status), and additional information
-being relevant for that session status, as a JSON object.
-
-The JSON object always contains a `status` field, containing the session status as being described in [status endpoint for requestors](#get-session-requestortoken-status).
-Additionally, when the session status is `DONE`, the `nextSession` field might be included.
-It contains the `sessionPtr` of the IRMA session following up the current session (a chained session).
-This happens when the `nextSession` option is used as [extra parameter in the session request](session-requests.md#extra-parameters).
-
-
-Below you can find an example response:
-```json
-{
- "status" : "DONE",
- "nextSession": {"u":"https://example.com/irma/ysDohpoySavbHAUDjmpz","irmaqr":"disclosing"}
-}
-```
-
-### `GET /irma/session/{clientToken}/frontend/statusevents`
-Subscribe to a [server-sent event](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events) stream of status updates.
-Whenever the session status changes, an event is sent as a JSON object. This JSON object follows the exact same format as the
-output of the [frontend status endpoint](#get-irma-session-clienttoken-frontend-status).
-If you need to monitor the status of a session, this is preferred over polling the frontend status endpoint.
-
-### `POST /irma/session/{clientToken}/frontend/options`
-This endpoint can be used to set pairing options for an IRMA session. Specific options can be sent to this endpoint and
-in the response an overview of the current pairing options is sent. If an options request holds an invalid combination
-of options, an error is returned.
-
-Session options can be changed multiple times. However, as soon as an
-[irmaclient](https://github.com/privacybydesign/irmago/tree/master/irmaclient)/[IRMA app](irma-app.md)
-has connected to the session, it is not possible to change the options anymore. In other words, this
-endpoint can only be used when the [session status](#get-irma-session-clienttoken-frontend-status) is `"INITIALIZED"`.
-
-The body of an options request should have the following structure:
-```json
-{
- "@context": "https://irma.app/ld/request/frontendoptions/v1",
- "pairingMethod": "..."
-}
-```
-
-Currently we only have one option, the option `pairingMethod`. It can have two values:
- * `"pairingMethod": "none"` **(default value)**
- No device pairing is used. This is the normal, already known behaviour.
- * `"pairingMethod": "pin"`
- When an [irmaclient](https://github.com/privacybydesign/irmago/tree/master/irmaclient)/[IRMA app](irma-app.md)
- connects to a session in which pairing is enabled, the [session status](#get-irma-session-clienttoken-frontend-status)
- becomes `PAIRING`. The irmaclient shows a 4 digit pairing code and only after the user correctly enters this code
- in the frontend the session continues, and the status becomes `CONNECTED`. This method can be
- used when a user is expected to scan an IRMA QR code using his/her phone and there is a risk on shoulder surfing
- (i.e. someone in close physical proximity to the user scans the QR code that was meant for the user).
-
- Pairing confirmation can be communicated by the frontend using the [`pairingcompleted` endpoint](#post-irma-session-clienttoken-frontend-pairingcompleted).
-
- When this option is requested, the session options response on this request will contain an extra field
- `pairingCode` containing the expected 4 digit code.
-
-A response of this endpoint has the following structure:
-```json
-{
- "@context": "https://irma.app/ld/options/v1",
- "pairingMethod": "pin",
- "pairingCode": "1234"
-}
-```
-
-If the `pairingMethod` field has the value `none`, the `pairingCode` field is omitted.
-
----
-
-### `POST /irma/session/{clientToken}/frontend/pairingcompleted`
-This endpoint can be used by the frontend to confirm the pairing of the frontend
-and the [irmaclient](https://github.com/privacybydesign/irmago/tree/master/irmaclient)/[IRMA app](irma-app.md).
-The endpoint can only be used while the [session status](#get-session-requestortoken-status) is set to `PAIRING`.
-A valid request to this endpoint will cause the session status to change from `PAIRING` to `CONNECTED`.
-When the request succeeds, a `204 No Content` response is returned.
diff --git a/website/versioned_docs/version-v0.8.0/chained-sessions.md b/website/versioned_docs/version-v0.8.0/chained-sessions.md
deleted file mode 100644
index 4301f2e..0000000
--- a/website/versioned_docs/version-v0.8.0/chained-sessions.md
+++ /dev/null
@@ -1,166 +0,0 @@
----
-title: Chained sessions
-id: version-v0.8.0-chained-sessions
-original_id: chained-sessions
----
-
-Since version 6.1.0 of the [IRMA app](irma-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 IRMA 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.
-
-
-
-
-
-
-The IRMA server enables this by sending the session results of the intermediate sessions in the chain to a server chosen by the requestor, which can process the session results and respond with a session request for the next session in the chain.
-
-Attributes disclosed in earlier sessions in a session chain can also be used to lookup data to be issued in a new credential, later in the session chain. More generally, within a session chain later sessions may depend on the results of the earlier sessions. With ordinary (that is, non-chained) IRMA sessions, the only possible way to achieve this is to send the user to a webpage between each session to start the next session.
-
-This page documents how this feature works.
-
-## The `nextSession` URL
-
-An [extended session request](session-requests.md#extra-parameters) may now contain a `nextSession` object which must contain a `url` field. If so, then at the end of the session (i.e., after the user has agreed to perform the session in the session screen of the IRMA app), the IRMA server will POST the [session result](https://pkg.go.dev/github.com/privacybydesign/irmago/server#SessionResult) in JSON (as returned by the [`/result` endpoint](api-irma-server#get-session-requestortoken-result)) to that `url`. The server at that `url` must then respond with one of the following:
-
-* a new (extended) session request in JSON, which may depend on the received session result;
-* HTTP 204, signifying that there is no next session to be performed. In this case, no further sessions take place and the flow stops normally.
-
-In the first case, the IRMA server will then start a new session using that session request and pass it to the IRMA app, which will show the corresponding session screen. Thus, the app user moves from the first session screen immediately to the next one.
-
-The session request returned by the server at the `nextSession` URL may itself contain a `nextSession` object (possibly but not necessarily referring to the same server). If so, then yet another session will be started using the same mechanism, after the one specified by the current session request. In this fashion, a session chain can consist of any number of sessions (although ideally it is kept as short as possible for optimal UX; in most cases two sessions will suffice).
-
-## Signing POSTed session results
-
-If a [JWT private key is installed in the IRMA server](irma-server.md#signed-jwt-session-results), then instead of POSTing plain JSON session results (as returned by the [`/result` endpoint](api-irma-server#get-session-requestortoken-result)) to the `nextSession` URL, the server will POST a session result JWT signed with the private key (as returned by the [`/result-jwt` endpoint](api-irma-server.md#get-session-requestortoken-result-jwt)) to the `nextSession` URL. The server at that URL can verify the JWT using the corresponding public key to authenticate the request as coming from the expected IRMA server.
-
-If a JWT private key is not installed, then the boolean `--allow-unsigned-callbacks` option must be passed to the IRMA server before chained sessions may be used, to explicitly enable POSTing unsigned session results. Otherwise, the server will reject session requests containing a `nextSession` object.
-
-> If no JWT private key is installed, then the `nextSession` URL should either not be publically reachable, or it should include a secret token (e.g. `https://example.com/cX5aTins5kEZpjDpfYcN`) and have TLS enabled (which it should anyway as personal data will be POSTed to it). Otherwise there is no way for the server at the `nextSession` URL to distinguish POSTs from your IRMA server from POSTs made by anyone else.
-
-## Use cases
-
-* Retrieving an attribute and then issuing it into a new credential.
-* Retrieving an attribute; use that to lookup related data; and issue that data into new credentials.
-* Refreshing a nearly expired credential, by retrieving an identifying attribute from it; use that to lookup fresh values for the other attributes, and issue a fresh credential.
-
-## Example
-
-In this example, we use an IRMA disclosure request to retrieve the user's name, and then issue that into a new credential, as shown in the two screenshots on top of this page. A live demo very similar to this may be found [here](https://privacybydesign.foundation/demo/irmaTubePremium).
-
-First, we deploy the following Go program at `https://example.com`. This program unmarshals the request body into a session result, takes the discloed attribute from it, and returns an issuance request containing that attribute.
-
-Note that this program assumes that no JWT private key is installed; see the remark in the previous paragraph.
-
-```go
-package main
-
-import (
- "encoding/json"
- "fmt"
- "io/ioutil"
- "log"
- "net/http"
-
- irma "github.com/privacybydesign/irmago"
- "github.com/privacybydesign/irmago/server"
-)
-
-func main() {
- log.Fatal(http.ListenAndServe(":80", http.HandlerFunc(handler)))
-}
-
-func handler(w http.ResponseWriter, r *http.Request) {
- // Read and unmarshal the POSTed session result
- bts, err := ioutil.ReadAll(r.Body)
- if err != nil {
- writeError(w, err.Error())
- return
- }
- var result server.SessionResult
- if err := json.Unmarshal(bts, &result); err != nil {
- writeError(w, err.Error())
- return
- }
-
- // Perform sanity checks on the session result.
- // NB: this endpoint is called by the IRMA server just before it ends the
- // session, so the session status is expected to be server.StatusConnected
- // (or the JSON string "CONNECTED").
- if result.Status != server.StatusConnected ||
- result.ProofStatus != irma.ProofStatusValid ||
- len(result.Disclosed) == 0 || len(result.Disclosed[0]) == 0 ||
- result.Disclosed[0][0].Identifier.String() != "irma-demo.gemeente.personalData.fullname" ||
- result.Disclosed[0][0].RawValue == nil {
- writeError(w, "received invalid session result")
- return
- }
-
- // Construct issuance request to respond with,
- // containing the attribute from the session result
- issuanceRequest := irma.NewIssuanceRequest([]*irma.CredentialRequest{{
- CredentialTypeID: irma.NewCredentialTypeIdentifier("irma-demo.IRMATube.member"),
- Attributes: map[string]string{
- "fullname": *result.Disclosed[0][0].RawValue,
- "type": "premium",
- "id": "123456",
- }}},
- )
-
- // Marshal and write our issuance request
- bts, err = json.Marshal(issuanceRequest)
- if err != nil {
- writeError(w, err.Error())
- return
- }
- w.Header().Set("Content-Type", "application/json")
- if _, err = w.Write(bts); err != nil {
- fmt.Println(err.Error())
- }
-}
-
-func writeError(w http.ResponseWriter, msg string) {
- w.WriteHeader(500)
- w.Write([]byte(msg))
-}
-```
-
-The session chain can then be started by sending the following session request to our IRMA server.
-
-
-
-```jsonc
-{
- "nextSession": {
- "url": "https://example.com"
- },
- "request": {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "irma-demo.gemeente.personalData.fullname" ]]]
- }
-}
-```
-
-```go
-irma.ServiceProviderRequest{
- RequestorBaseRequest: irma.RequestorBaseRequest{
- NextSession: &irma.NextSessionData{
- URL: "https://example.com",
- },
- },
- Request: irma.NewDisclosureRequest(
- irma.NewAttributeTypeIdentifier("irma-demo.gemeente.personalData.fullname"),
- ),
-}
-```
-
-
-After the user discloses the `irma-demo.gemeente.personalData.fullname` attribute, the IRMA server POSTs it to `https://example.com`. Our Go server responds to the IRMA server with the `issuanceRequest` found near the end of the program. Next, the IRMA server immediately starts this issuance session with the user's IRMA app, resulting in the screenshots shown on top of this page.
-
-## Differences with combined issuance-disclosure requests
-
-[Combined issuance-disclosure requests](session-requests.md#issuance-requests), i.e. issuance requests with a nonempty `disclose` field requesting attributes to be disclosed, is another way of first requesting and then issuing attributes from/to an IRMA app user within a single flow. Thus, this is very similar to a session chain consisting of first a disclosure request and then an issuance request. However, contrary to session chains, this flow is started using a single session request. Thus, when using combined issuance-disclosure requests it is impossible for the issued attributes to depend on the disclosed attributes, because at the time the session request is composed the value of the disclosed attributes are not yet known.
-
-Comparing the two, chained sessions are more powerful in the following ways:
-
-* As mentioned, sessions later in the chain may depend on the session results of earlier sessions in the chain;
-* Session chains can consist of more than two sessions (although this may lead to bad UX);
-* The sessions occuring in a session chain may be of any type (although first disclosure and then issuance is probably the most common scenario).
diff --git a/website/versioned_docs/version-v0.8.0/irma-frontend.md b/website/versioned_docs/version-v0.8.0/irma-frontend.md
deleted file mode 100644
index ad56b7d..0000000
--- a/website/versioned_docs/version-v0.8.0/irma-frontend.md
+++ /dev/null
@@ -1,386 +0,0 @@
----
-title: IRMA frontend JavaScript packages
-id: version-v0.8.0-irma-frontend
-original_id: irma-frontend
----
-
-The [`irma-frontend-packages`](https://github.com/privacybydesign/irma-frontend-packages) repository is a set of
-related JavaScript packages that together form a Javascript frontend client to the
-[`irma server`](https://github.com/privacybydesign/irmago/tree/master/irma). The packages contain a state
-machine package [`irma-core`](#irma-core) to which several plugin packages can be added to achieve IRMA support
-for your application. We also provide a wrapper package [`irma-frontend`](#irma-frontend) that combines `irma-core` with some of the
-plugins in a bundle. With this wrapper package you have an easy starting point for handling sessions using an embedded
-web element or using a popup overlay in the browser.
-
-Using the default styling, the browser version will look like this:
-
-![IRMA frontend web element](assets/irma-frontend-web.gif)
-
-All packages are published on [npm](https://www.npmjs.com/) in `@privacybydesign` scoped packages.
-
-## IRMA core
-
-This package contains the [state machine](https://github.com/privacybydesign/irma-frontend-packages/blob/master/irma-core/state-transitions.js)
-for implementing IRMA flows. `irma-core` itself does not provide any real functionality. Plugins can be registered at the
-state machine and the plugins then provide the functionality depending on the state the state machine is in.
-The plugins can also request state modifications to the state machine.
-
-IRMA core can be initialized in the following way:
-```javascript
-const IrmaCore = require('@privacybydesign/irma-core');
-const irma = new IrmaCore(/* options */);
-
-irma.use(/* Plugin A */);
-irma.use(/* Plugin B */);
-
-irma.start();
-```
-
-More information about the methods IRMA core offers to you can be found
-in the [API overview](api-irma-frontend.md#irma-core).
-
-### Available plugins for IRMA core
-Below is a list of the plugins we provide. Detailed explanations of the plugins can be found in the READMEs
-on GitHub (linked to in the left column).
-
-| Plugin | Functionality |
-|---|---|
-| [`irma-client`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client) | Plugin to fetch a [session package](api-irma-server.md#post-session), to check the `irma server` for the current session status and optionally to fetch the result. The plugin is widely configurable, so you can also fetch a session package or a session result at custom endpoints. |
-| [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web) | Plugin to handle user interaction via a web element that developers can embed within the contents of their webpages. It is designed to be used with [`irma-css`](#irma-css). `irma-css` is not embedded in this package, so you have to manually include this. You are also free to use your own styling. |
-| [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-popup) | `irma-web` element embedded in a popup overlay. The popup is displayed on top of your content and is hidden again when a session is completed, when a fatal error occurs or when the user closes the popup. It is designed to be used with [`irma-css`](#irma-css). `irma-css` is not embedded in this package, so you have to manually include this. You are also free to use your own styling. |
-| [`irma-console`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-console) | Plugin to handle user interaction via the console (either the browser console or the command line console) using node.js. |
-| [`irma-dummy`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/examples/browser/irma-dummy) | Plugin that provides a dummy implementation of the `irma-client` plugin. This can be used to test the user interaction without actually having to do a session at an IRMA server. Instead, the state machine will be instructed to continue after fixed timeouts. |
-
-If a plugin for your use case is not available, we offer you the option to [construct one yourself](#make-your-own-irma-core-plugin).
-
-### Usage guide
-Here we explain the scenario in which the web element is embedded within the contents of our website.
-This web element will be controlled by the `irma-web` plugin. We use `irma-client` for the communication
-with the IRMA server and our backend.
-
-In the body of our HTML page we need to have an HTML element where `irma-web` can render its user interface.
-We also import the [`irma-css`](#irma-css) styling to nicely style our `irma-web-form` element.
-```html
-
-
- ...
-
- ...
-
-
- ...
-
- ...
-
-
-```
-
-In our JavaScript we import `irma-core` and the relevant plugins first.
-```javascript
-const IrmaCore = require('@privacybydesign/irma-core');
-const IrmaWeb = require('@privacybydesign/irma-web');
-const IrmaClient = require('@privacybydesign/irma-client');
-```
-
-Then we can instantiate IRMA core. Let's assume we already have an endpoint `/get-irma-session`
-in our backend that starts a relevant IRMA session at the [`irma server`](irma-server.md). Let's say the endpoint
-returns a single session package (in JSON) without any backend token.
-```javascript
-const irma = new IrmaCore({
- // Enable to get helpful output in the browser console.
- debugging: false,
-
- // The option 'element' is used by irma-web to find its HTML element in the DOM.
- element: '#irma-web-form',
-
- // The 'session' option struct is used by irma-client to find the session information.
- session: {
- // The base url of our website
- url: 'http://example.com',
-
- // The 'start' option struct specifies where irma-client can fetch a new session package.
- start: {
- // Specifies how the endpoint url can be derived from the base url (see above).
- url: o => `${o.url}/get-irma-session`,
- // A GET request is used.
- method: 'GET',
- // No additional HTTP headers are needed.
- headers: {},
- // Note: a GET request with empty headers is fetch's default, so
- // omitting these options would lead to the same result.
- // All options the fetch API exposes can be used here to customize the request.
- // https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch
- },
-
- // The 'mapping' option specifies how the data can be derived from a 'start' response.
- mapping: {
- // The only thing included in the request is the session pointer, so no additional parsing is needed.
- sessionPtr: r => r,
- },
-
- // Since we did not receive a backend token, we cannot retrieve any session result here.
- result: false,
- },
-});
-```
-
-Now we can add the plugins to our IRMA core instance and start running it.
-```javascript
-irma.use(IrmaWeb);
-irma.use(IrmaClient);
-
-const promise = irma.start();
-```
-
-IRMA core is now started and the IRMA web element should be visible.
-By looking at the state of the promise, you can detect whether the user has finished.
-```javascript
-promise.then(() => {
- // The user has completed the session.
-})
-.catch((err) => {
- // Some fatal error has occurred.
-});
-```
-
-Be aware that you can start an instance of `irma-core` only once.
-When you want to call `start()` again, you have to create a new instance.
-When a promise of an earlier `start()` call is not completed yet, promise rejection
-can be forced by calling the `abort()` method. In this way a new `irma-core`
-instance can be created without any risk on interference with other running instances.
-When a promise is rejected because of an `abort()` call, the promise will return the
-error message `Aborted`.
-
-```javascript
-irma.abort();
-```
-
-For detailed information about all available options, you can check the README of the
-particular plugin on GitHub. There are links in the plugin overview [above](#available-plugins-for-IRMA-core).
-
-## IRMA frontend
-For convenience we already bundled `irma-core`, `irma-web`, `irma-popup` and `irma-client` together with the default styling
-from `irma-css`. We also added polyfills in this package to realize support for Internet Explorer 11.
-The package can be installed from the npm registry.
-The bundled package can also be downloaded directly [here](https://github.com/privacybydesign/irma-frontend-packages/releases/latest/download/irma.js).
-Please host this file as asset yourself.
-
-The bundle can be imported in your JavaScript file by doing `require('@privacybydesign/irma-frontend')` or it can
-be included directly in the HTML.
-
-```html
-
-```
-
-You can then instantiate `irma-frontend` and start a session like this when using an embedded web element:
-```javascript
-const exampleWeb = irma.newWeb({
- debugging: false, // Enable to get helpful output in the browser console
- element: '#irma-web-form', // Which DOM element to render to
-
- // Back-end options
- session: {
- // Configure your flow here, see usage guide of irma-core
- },
-
- ...
-});
-
-exampleWeb.start()
-.then(result => console.log("Successful disclosure! 🎉", result))
-.catch(error => console.error("Couldn't do what you asked 😢", error));
-```
-
-When you want a popup overlay to be used to, you can do the following:
-```javascript
-const examplePopup = irma.newPopup({
- debugging: false, // Enable to get helpful output in the browser console
-
- // Back-end options
- session: {
- // Configure your flow here, see usage guide of irma-core
- },
-
- ...
-});
-
-examplePopup.start()
-.then(result => console.log("Successful disclosure! 🎉", result))
-.catch(error => console.error("Couldn't do what you asked 😢", error));
-```
-
-Be aware that you can start an instance of `irma-frontend` only once.
-When you want to call `start()` again, you have to create a new instance.
-When a promise of an earlier `start()` call is not completed yet, promise rejection
-can be forced by calling the `abort()` method. In this way a new `irma-frontend`
-instance can be created without any risk on interference with other running instances.
-When a promise is rejected because of an `abort()` call, the promise will return the
-error message `Aborted`.
-
-```javascript
-exampleWeb.abort();
-examplePopup.abort();
-```
-
-More information about the methods the IRMA frontend package offers to you can be found
-in the [API overview](api-irma-frontend.md#irma-frontend).
-
-## IRMA css
-For the IRMA core plugins `irma-web` and `irma-popup` we made it possible to manually include the style
-that it will use. We provide to you a [normal version](https://github.com/privacybydesign/irma-frontend-packages/releases/latest/download/irma.css)
-and a [minified version](https://github.com/privacybydesign/irma-frontend-packages/releases/latest/download/irma.min.css)
-of the default styles. The CSS can be linked into your website the regular way:
-
-```html
-
-```
-
-When you want to adapt the design to suit for your own use case, you can take a look in the [styleguide](https://privacybydesign.github.io/irma-frontend-packages/styleguide/).
-Based on this you can adapt the CSS and then import the modified version into your project.
-Customized versions of `irma-css` can be used in combination with the `irma-web` and
-`irma-popup` plugins for `irma-core`.
-
-### Customizing the design
-Customizing the design is especially useful for developers that want to use an embedded
-web element to initiate the IRMA flow and see that the default design does not fit
-into the design of their website. We provide you a convenient way to alter the
-design and build a new, customized style. This can be done in the following way:
-
-1. Clone the [`irma-frontend-packages` repository](https://github.com/privacybydesign/irma-frontend-packages).
-2. Use our [guide](https://github.com/privacybydesign/irma-frontend-packages/tree/master/irma-css#compiling-locally)
- to compile the CSS styleguide locally.
-3. Make the desired changes in the source files. These files can be found in the
- `irma-css/src` directory.
-4. Check **all pages** of the locally built styleguide to check whether your local
- changes work for all flows.
-5. Build a release version for your customized CSS by running `npm run release` in the
- `irma-css` directory. The built CSS files can be found in the `irma-css/dist` directory.
-6. Include the new style in your website and use [IRMA core](#irma-core) in combination
- with the `irma-web` plugin (for embedded web elements) or the `irma-popup` plugin (for
- a popup overlay). The plugins will use the custom CSS that you have embedded. For
- managing the session state we recommend you to use the `irma-client` plugin.
-
-```javascript
-require('assets/my-custom-irma-css-design.min.css');
-
-const IrmaCore = require('@privacybydesign/irma-core');
-const IrmaWeb = require('@privacybydesign/irma-web');
-const IrmaClient = require('@privacybydesign/irma-client');
-
-const irma = new IrmaCore({
- debugging: true,
- element: '#irma-web-form',
- language: 'en',
- // Check the irma-web README on how to customize the default texts.
- session: {
- // Check the irma-client README for all options.
- },
-});
-
-irma.use(IrmaWeb);
-irma.use(IrmaClient);
-
-irma.start()
-.then(result => console.log("Successful disclosure! 🎉", result))
-.catch(error => {
- if (error === 'Aborted') {
- console.log('We closed it ourselves, so no problem 😅');
- return;
- }
- console.error("Couldn't do what you asked 😢", error);
-});
-```
-
-## Make your own IRMA core plugin
-If you need functionality that is not covered by one of the existing IRMA core plugins, you can also define
-one yourself. In the constructor the `stateMachine` and the `options` from `IrmaCore` can be accessed.
-The constructor can be omitted if you do not need it.
-Furthermore, a plugin can have a `start` method that is
-called when the `start` method of the associated `IrmaCore` instance is called, a `stateChange` method
-that is called when the state of the state machine changes, and a `close` method (check the explanation below for details).
-
-```javascript
-class IrmaPlugin {
- // Optional
- constructor({stateMachine, options}) {
- ...
- }
-
- // Optional method
- start() {
- ...
- }
-
- // Optional method
- stateChange({newState, oldState, transition, isFinal, payload}) {
- ...
- }
-
- // Optional method
- close() {
- // May return a Promise when the closing operation is async;
- // irma-core will then wait for the Promise to be completed.
- ...
- }
-}
-```
-
-A plugin can request the state machine to make changes. This can be done using the `transition` and
-`finalTransition` methods of the `stateMachine`. The first parameter of these functions is the requested
-transition. The possible transitions can be found in the [state machine](https://github.com/privacybydesign/irma-frontend-packages/blob/master/irma-core/state-transitions.js).
-As second parameter `payload` can be added to the transition. The payload can then be accessed by all other plugins
-as it is one of the parameters of the `stateChange` method. When requesting a `finalTransition`, the state
-machine will be locked in the new state. From then no transitions can be made anymore. For a `finalTransition`
-the potential `newState` must be in the list of possible end states. Otherwise, an error is returned. After
-a `finalTransition` the `close` method of the plugin is called to close the plugin's state. This method should
-return a Promise which resolves when the plugin finishes closing. When the `close` Promises of all plugins are
-resolved, the promise returned by the `start` method of `IrmaCore` will resolve or reject (depending on the
-transaction). In this way we can guarantee that plugins are not active anymore when the promise returned by the
-`start` method of `IrmaCore` is finished. Besides when calling `finalTransition`, the closing procedure can also
-be activated when the `transition` method is used and the state machine gets in a state from which no
-transitions are possible anymore.
-
-For example, in the `IrmaPopup` plugin the user can press on the close button in the UI to abort the session.
-When this happens the `IrmaPopup` plugin must request a state change at the IRMA core state machine to
-notify all other plugins that the new state becomes `Aborted`. This is done in the following way:
-```javascript
-stateMachine.transition('abort', 'Popup closed');
-```
-
-There are no transitions possible anymore from the state `Aborted`. This means that unless the transition
-is not explicitly marked as final, the `stateChange` method of your plugin will be called with `isFinal` set
-to true.
-
-## Differences with [irmajs](irmajs.md)
-The previous JavaScript library `irmajs` combined frontend and backend functionality. The `startSession` related
-functions could be used to start sessions, and `handleSession` could be used for actually being the
-frontend to the user.
-
-In the new library we have split these functionalities into two libraries. The session management functionality
-for node.js server applications now belongs to the [`irma-backend-packages`](https://github.com/privacybydesign/irma-backend-packages).
-The `irma-frontend-packages` only deals with session handling for the (web)client, starting
-with fetching a session package from a remote server, then communicating with the `irma server` what the current status
-of the session is, and finally fetching the result if the client needs it.
-It also handles the user interaction related to all of these actions.
-
-As a rule of thumb, `irma-frontend-packages` is meant to handle the `/irma/...` endpoints, and
-`irma-backend-packages` is meant to handle the `/session/...` endpoints of the `irma server`. Theoretically,
-`irma-frontend-packages` is able to fetch a session package directly at the `irma server` and therefore also
-use the `/session` endpoint of the `irma server`. This flow is however not recommended. A better
-practice is to put a backend layer in between that starts the session at the `irma server`.
-
-For user interaction, we currently have support for a web element embedded in the content, a web browser
-popup overlay and console user interaction using node.js. Below you can find an overview of the plugins for
-`irma-core` and how they map to the methods known from `irmajs`. In all cases the [`irma-client`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-client)
-plugin is needed for server communication.
-
-| irmajs method | irma-frontend plugin | Differences |
-|---|---|---|
-| `'popup'` | [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-popup) | Does not always reject on cancellation or timeout. When a `start` endpoint is specified at `irma-client` to fetch a new session package, the user gets the opportunity to try again. Also, support for tablets has been added. The default [`irma-css`](#irma-css) style can be used or a custom CSS template can be defined to give it your own look and feel. |
-| `'canvas'` | [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web) | Has been upgraded to a full web element to also be able to handle tablets. Auto-refreshment of the QR on session timeout is now supported. Furthermore, the differences mentioned at the method `popup` also apply here. |
-| `'mobile'` | [`irma-web`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-web) or [`irma-popup`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-popup) | The mobile flow is fully integrated into the web and popup interfaces. Please check those options to see the differences. |
-| `'console'` | [`irma-console`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/plugins/irma-console) | No major differences. |
-| `'url'` | _No support_ | The url can simply be constructed according to the format `https://irma.app/-/session#` where `` has to be replaced with the session package JSON object (converted to a string using url encoding). A session package can be retrieved using the [`irma-backend-packages`](https://github.com/privacybydesign/irma-backend-packages). |
-
-For users that have difficulties integrating a new library, but do want to upgrade, we also provide a [`irma-legacy`](https://github.com/privacybydesign/irma-frontend-packages/tree/master/irma-legacy)
-wrapper that maps the legacy `irmajs` calls onto the new `irma-frontend-packages`. More information about this will follow.
diff --git a/website/versioned_docs/version-v0.8.0/irma-protocol.md b/website/versioned_docs/version-v0.8.0/irma-protocol.md
deleted file mode 100644
index 665481c..0000000
--- a/website/versioned_docs/version-v0.8.0/irma-protocol.md
+++ /dev/null
@@ -1,378 +0,0 @@
----
-title: IRMA protocol
-id: version-v0.8.0-irma-protocol
-original_id: irma-protocol
----
-
-During an IRMA session, the IRMA protocol is used by the [IRMA server](irma-server.md) and [IRMA app](irma-app.md) to issue or verify attributes. The IRMA app sends and receives various data by invoking a number of HTTP endpoints of the IRMA server, making the session progress through a number of stages. This page documents those endpoints, the data being handled, and the states the session goes through.
-
-## Introduction
-
-The IRMA protocol consists of a set of messages that are exchanged between the IRMA server and an IRMA app during a session. Each message being sent or received is a JSON serialization of a particular Go struct defined within the [`irmago`](https://github.com/privacybydesign/irmago) source code repository. Thus, whenever we say below that an instance of a particular struct is sent or received, we refer to its JSON serialization. For most of the messages being sent and received, the default Go (un)marshaler is used. Whenever we say that a particular Go struct is sent or received, we will link to its [API documentation](https://pkg.go.dev/github.com/privacybydesign/irmago), from which its JSON structure may be inferred.
-
-We assume here that the IRMA app and server both support the latest IRMA protocol version. Some of the messages have custom unmarshalers, which if an older protocol version is used transform the message to comply with the older protocol version.
-
-The HTTP endpoints of the IRMA server documented here are invoked exclusively by the IRMA app, in particular by the [`irmaclient` Go library](https://pkg.go.dev/github.com/privacybydesign/irmago/irmaclient) used by the IRMA app. These endpoints are not meant for direct use by any other party or software. The endpoints of the IRMA server used by requestors and/or by frontends are documented in the [API reference of the IRMA server](api-irma-server.md).
-
-In order to protect the attributes as they travel over the internet from being read or modified by anyone else than the IRMA app and server to which they are sent, it is important that they are encrypted. The IRMA protocol does not deal with encryption by itself; instead it relies on TLS for this, as well as for authenticating the requestor. Thus, the messages being sent in the protocol as shown below are normally TLS encrypted. The IRMA app will refuse to connect to IRMA servers over plain HTTP without TLS, unless [developer mode](irma-app.md#developer-mode) is enabled.
-
-The IRMA protocol as outlined below can be seen in action by performing an IRMA session with an IRMA server configured with [maximum verbosity](irma-server.md#logging-and-verbosity), as then it will log all HTTP traffic that it sends and receives.
-
-### The session state
-
-At any time after its creation an IRMA session is in a particular [session state](https://pkg.go.dev/github.com/privacybydesign/irmago#ServerStatus), and with respect to this state the IRMA server acts as a state machine. Each of the endpoints below may be invoked only when the session is in a particular state, and most of them cause the session to progress to a next state. The requestor, the frontend and the IRMA app may keep track of the session state through server-sent events or through polling. An IRMA session progresses through the following states, in the order as they appear here:
-
-* `INITIALIZED`: after the session [is created](#session-creation).
-* `PAIRING`: only if device pairing is enabled, after the IRMA app [first connects to the IRMA server](#retrieving-the-session-request).
-* `CONNECTED`: either when device pairing is disabled and the IRMA app [first connects to the IRMA server](#retrieving-the-session-request), or after the frontend indicates to the IRMA server that pairing has been completed successfully.
-* `DONE`: after the HTTP request has finished processing in which IRMA app has sent its [session response](#sending-the-session-response). In this state, any attributes that were disclosed by the IRMA app to the server are ready to be retrieved by the requestor.
-
-At any time, the session may move from one of the first three states to any of the following states:
-
-* `TIMEOUT`: the session has been in one of the first three states longer than a timeout (configurable in the IRMA server, by default 5 minutes).
-* `CANCELLED`: the session was cancelled [by the IRMA app](#cancelling-delete-irma-session-clienttoken), [the requestor or by the frontend](api-irma-server.md#delete-session-requestortoken); or an error occurred.
-
-Of these states, `DONE`, `TIMEOUT` and `CANCELLED` are final states: no valid state transition exists from these to any other state.
-
-### Sequence diagram
-
-The following sequence diagrams showing an IRMA session in the happy flow, without and with device pairing, summarize the above. Note that these diagrams show a complete session for completeness, including the actions of the frontend, while the remainder of this document focuses on the actions of the IRMA app.
-
-
-
-
-
-
-
-
-
-
-### Further reading
-
-This page is concerned only with the IRMA protocol. For more technical information on IRMA in general, as well as explanations and definitions of some of the terms mentioned in this page, see the [technical overview](overview.md).
-
-This page does not deal with the cryptographic contents of the messages being passed nor how they achieve [IRMA's security properties](overview.md#irma-security-properties), only with how and when they are passed. IRMA being an implementation of the Idemix attribute-based credential scheme, details on the cryptographic contents and mechanisms of the messages may be found in the [Idemix specification](https://dominoweb.draco.res.ibm.com/reports/rz3730_revised.pdf) and in the [paper introducing Idemix](https://cs.brown.edu/people/alysyans/papers/camlys02b.pdf) by Camenisch and Lysyanskaya.
-
-## Session creation
-
-The [requestor](overview.md#participants) creates a session by sending a [session request](session-requests.md) for one of the three supported [session types](what-is-irma.md#session-types) to the [`POST /session`](api-irma-server.md#post-session) endpoint of the `irma server`, or by invoking the [`StartSession()`](https://pkg.go.dev/github.com/privacybydesign/irmago/server/irmaserver#Server.StartSession) function of the `irmaserver` Go library. If the IRMA server accepts the session (i.e., the session request is valid and the requestor is authorized to start sessions), the session is created and its state is set to [`INITIALIZED`](https://pkg.go.dev/github.com/privacybydesign/irmago#ServerStatusInitialized). This means that the IRMA server is waiting for the first HTTP request of the IRMA app, documented below.
-
-When the requestor creates the session, the IRMA server responds with a [session package](api-irma-server.md#post-session). For example:
-
-```json
-{
- "sessionPtr": {
- "u": "https://example.com/irma/session/6xyh0D2CdLsloWljYFH1",
- "irmaqr": "disclosing"
- },
- "token": "NsuDGnWtfpLX7nv4Gn1M",
- "frontendRequest": {
- "authorization": "MfEl17feZHbfOfPQtiJe",
- "minProtocolVersion": "1.0",
- "maxProtocolVersion": "1.1"
- }
-}
-```
-
-The requestor takes the `sessionPtr` and `frontendRequest` from the session package and sends those to its [frontend](irma-frontend.md), which uses them to create a QR code or a universal link. The IRMA app then picks that up by either scanning the QR code (desktop flow) or clicking on the universal link (mobile flow).
-
-Next, there are two possibilities: the frontend either enables device pairing, or not. Pairing is only used in the desktop flow, i.e. when the frontend displays a QR code for the IRMA app to scan (and even then not necessarily in all cases; it can be disabled by the frontend). If device pairing is enabled, then after the IRMA app connects to the server (using the information in the QR code or the universal link) but before the IRMA app receives the session request, the user must enter a random 4-digit pairing code in the frontend, as protection against shoulder surfing (QR code stealing).
-
-## Retrieving the session request
-
-### `GET /irma/session/{clientToken}`
-
-After the IRMA app scans the QR code or the user taps on the universal link displayed by the frontend, containing a token identifying the session that we will denote with `clientToken`, the app performs a GET request to `/irma/session/{clientToken}`. It sends along the minimum and maximum versions of the IRMA protocol that it supports. For example:
-
-```
-GET /irma/session/6xyh0D2CdLsloWljYFH1/ HTTP/1.1
-X-Irma-Minprotocolversion: 2.4
-X-Irma-Maxprotocolversion: 2.8
-```
-
-The server responds with an [`irma.ClientSessionRequest` instance](https://pkg.go.dev/github.com/privacybydesign/irmago#ClientSessionRequest), containing the protocol version that it chooses (the highest protocol version supported by both itself and by the app), the pairing code if device pairing is enabled, or the session request if not. For example:
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/client/v1",
- "protocolVersion": "2.8",
- "options": {
- "@context": "https://irma.app/ld/options/v1",
- "pairingMethod": "pin",
- "pairingCode": "1761"
- }
-}
-```
-
-```json
-{
- "@context": "https://irma.app/ld/request/client/v1",
- "protocolVersion": "2.8",
- "options": {
- "@context": "https://irma.app/ld/options/v1",
- "pairingMethod": "none"
- },
- "request": {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "context": "AQ==",
- "nonce": "Il2FiK8uCIApjzkWeRouSQ==",
- "protocolVersion": "2.8",
- "devMode": true,
- "disclose": [
- [
- [
- "pbdf.pbdf.irmatube.type"
- ]
- ]
- ]
- }
-}
-```
-
-
-If device pairing is disabled, then the session state is set to [`CONNECTED`](https://pkg.go.dev/github.com/privacybydesign/irmago#ServerStatusConnected). Otherwise the session state is set to [`PAIRING`](https://pkg.go.dev/github.com/privacybydesign/irmago#ServerStatusPairing). In that case the IRMA app shows the `pairingCode` in the response above in its GUI, and instructs the user to type that into the frontend. It uses [`/irma/session/{clientToken}/statusevents`](api-irma-server.md#get-irma-session-clienttoken-statusevents) or polls to [`/irma/session/{clientToken}/status`](api-irma-server.md#get-irma-session-clienttoken-status) to keep track of the session status. After the user enters the pairing code into the frontend, the frontend invokes the [`POST /irma/session/{clientToken}/frontend/pairingcompleted` endpoint](api-irma-server.md#post-irma-session-clienttoken-frontend-pairingcompleted), triggering the IRMA server to switch the session status to `CONNECTED`. When that happens the IRMA app notices through a server-sent event or through its polling, after which it invokes the below endpoint to retrieve the session request.
-
-### `GET /irma/session/{clientToken}/request`
-
-This endpoint is only used to retrieve the session request when device pairing is enabled (if not, this endpoint is not invoked since the session request is included in the response to the previous HTTP request, see above). The server responds with the session request, for example:
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "nonce": "Il2FiK8uCIApjzkWeRouSQ==",
- "context": "AQ==",
- "protocolVersion": "2.8",
- "devMode": true,
- "disclose": [
- [
- [
- "pbdf.pbdf.irmatube.type"
- ]
- ]
- ]
-}
-```
-
-This is the session request that was passed by the requestor to the IRMA server [when the session was started](#session-creation), with the following additions:
-
-* `nonce` (standing for a *n*umber that is used *once*): this base64-encoded number serves as the challenge in the IRMA protocol, which is a challenge-response protocol: the IRMA app's [response](#sending-the-session-response) must take this number into account in a specific way. That is, this number guarantees liveness of the prover (the app) and prevents against replay attacks. It is randomly chosen by the IRMA server and unique per session.
-* `context`: always contains a base64 encoding of the number 1; this is not currently used in IRMA.
-* `protocolVersion`: the protocol version chosen by the IRMA server (see above).
-* `devMode`: `true` when [production mode](irma-server.md#production-mode) is *not* enabled in the IRMA server, false otherwise. (If this is `true`, then the IRMA app will accept the session request only if [developer mode](irma-app.md#developer-mode) is enabled in it).
-
-## Sending the session response
-
-After receiving the session request, the following happens.
-
-* The IRMA app compares the requested attributes (if any) in the session request against its store to decide if it currently has them in possession, and computes a list of options containing attributes for the user to choose from that will satisfy the requestor, according to the session request.
-* The app presents those options as well as information about the requestor to the user, asking her to either choose from the options and proceed with the session, or to abort.
-* If the user decides to proceed with the session, then based on the user's choices of attributes to be disclosed the IRMA app computes the appropriate response to the IRMA server, in conjunction with the keyshare server using the [keyshare protocol](keyshare-protocol.md). If instead the user decides to abort, or if any error occurs, then the IRMA app cancels the session (see [below](#cancelling-delete-irma-session-clienttoken)).
-
-In the remainder of this section, we assume that so far no error occurred and the user chooses to proceed. In that case, after constructing the response to the IRMA server as mentioned above one of the following three endpoints is invoked, depending on the session type.
-
-### Disclosure: `POST /irma/session/{clientToken}/proofs`
-
-The app POSTs an [`irma.Disclosure` instance](https://pkg.go.dev/github.com/privacybydesign/irmago#Disclosure), for example:
-
-```json
-{
- "proofs": [
- {
- "c": "Hg+cpDeB85nH0hZFmQ2AzLIv+CxVi6mPR2LeDZ+7XVU=",
- "A": "1Uf2V5PRILh6cjo64wWcwIDm39SqnXAXu+tOwq90GmceiahyG5h1zH5/HMA4vwxZfF+9pkqIX1/7twRU6dI5ct2hqAq6qWWcYrwqFV2PsMLVzIyrdU1xVeo4YOIajJ4DMX5rxrCJjjLb28VNWxWUqieXs/iz8Dn67+nYTxxdv4tQw7B3i45PtrD+sKbZPGjTQP0iBHOp5OOvlWNKDYZhKAYgkx+upjcDMHUSCDZPLUCzVBK7LZRqzsh02QrBRyFmeWKxqHpOKzyN9V1GHnUpXWPehenwGFD+N9/TB7rDfMciAV/BaC6pbPbjYCT0bWaBxe07kKT0O4PSsOHBf643jA==",
- "e_response": "oB02Vcm+NekUq4qA92p45jWj4L/QAIJW2SxnMOSyX6GmhV62KeU5+hQUvAv6hK/Jkw+NqdX0kiwV8DUQFc4d",
- "v_response": "C8NbtoNAwYX/OiYMbVBHcDExpIId2a6k5e/JC2rAbp7qATkHTfOjhvjjdSQNy6CYguW67Zn26lp817EWRNxia6ScAuQjkT+8nxBfFIOG5+qFANiRp2MhNCcbyFFPjQGL9m5fPHAoRkyvAPydwvOwomXuj2zX0LbReuYxlBviwLjikNHeWrPAxzk11NCnSxQd3jo+cHzKmJd24RbeOWoyuBRtoXBEV/cKcFbfAd0vamr9n5LYNDK7BXqazBzkP6VeTyzvKFgalW/7mzilYgLAe5htSsHnAQCe7gOP//12iPxQe7NX1aGUmOmTZfQmNv4AxU9tCb3ylPTXPPImYaUiVt8k91+ADvgF/uwf2gLPs3QtsvYqi6njozrRt1ZyIL9dHxf9AQMQiWDBGXkw2rbywx/UmfZV/TqZmU7j/NFLqlDC7u1UYfzMQFSvy/pamImQ20njTG9bZY8geAGc0mMLhwtSY8GIHaCG7Qmgz/cNWuAszX2w4bG9hZaznBCbOOA/q2UH962Majum4DbJo+12/jY=",
- "a_responses": {
- "0": "X1DnHADwaDTOQGb2SS+bJCebTCRbZserzi5wqu0K8SQI7729hH39YC2y9PK4x6m+6Ep1MTqRDF7ZT8ThSV6Fg2ngqTytVJv9t7mobp3fTnY=",
- "3": "vrmbFFjN2NepjEiDXSwhnb5AC7Y2ZWAluAu2gUUmLD4Re3BG/Jia9WGFWU6SEifmT269BHE8LmsT0/UkGFr+CRPddXPDJUFWaEsoQ2NtNz0=",
- "4": "E4BMmNXOAHNCMEVGLiA9WZ8GkqLRPlWs+3H3uEZ8G/I/6ct1O98OJI0+C7hD3zP6yD1M1qXbWE7DTWo4tt/rXDju6Zdhq+olST8OzLxwU5Q="
- },
- "a_disclosed": {
- "1": "AwAKhwAaAAXZZxdMn4TvQ6F/mVxWb6a7",
- "2": "5MrO6tjC5Q=="
- }
- }
- ],
- "indices": [
- [
- {
- "cred": 0,
- "attr": 2
- }
- ]
- ]
-}
-```
-
-The `proofs` array contains a list of disclosure proofs, i.e. [`gabi.ProofD`](https://pkg.go.dev/github.com/privacybydesign/gabi#ProofD) instances, for each credential out of which attributes are being disclosed (present in the `a_disclosed` map, see below). The remainder of the fields within the `gabi.ProofD` are [zero-knowledge proofs](zkp.md) of the hidden attributes (`a_responses`) and of the issuer signature over the attributes of this credential.
-
-The `indices` double array informs the IRMA server where it can find the attributes that it requested in the session request within the `proofs` array, schematically as follows: if `indices[i][j]` contains `{"cred": k, "attr": l}`, then the attribute requested in the [inner conjunction](session-requests.md#multiple-credential-types-within-inner-conjunctions) `j` in the outer conjunction `i` can be found in `proofs[k].a_disclosed[l]`.
-
-#### The attributes in `a_disclosed`
-
-The IRMA protocol uses Base64 to encode large integers, as can be seen in the strings in the message above. The disclosed attributes additionally contain an extra bit in the least significant position encoding their presence, which is used to distinguish [absent attributes](session-requests.md#issuance-requests) from attributes containing the empty string as values. Thus, a (non-empty) string found within `a_disclosed` containing a disclosed attribute can be converted to its string value as follows:
-
-* Base64-decode the string,
-* Bit-shift the resulting bytes one position to the right,
-* Parse the resulting bytes as a UTF-8 string.
-
-For example, taking attribute `2` from `a_disclosed` in the message above, the following [Go snippet](https://play.golang.org/p/GTWeM_uHr98) outputs `regular`.
-
-```go
-bts, _ := base64.StdEncoding.DecodeString("5MrO6tjC5Q==")
-i := new(big.Int).SetBytes(bts)
-i.Rsh(i, 1)
-fmt.Println(string(i.Bytes()))
-```
-
-Note that attribute `1` is the [metadata attribute](overview.md#the-metadata-attribute), containing among others the credential type and the expiry date of the credential in a custom encoding. This attribute is always disclosed. The above snippet will not output anything sensible for metadata attributes, but instead the [`irma` command line tool](irma-cli.md) can be used as follows.
-
-```text
-$ irma meta "AwAKhwAaAAXZZxdMn4TvQ6F/mVxWb6a7"
-Identifier : pbdf.pbdf.irmatube
-Signed : 2021-08-26 02:00:00 +0200 CEST
-Expires : 2022-02-24 01:00:00 +0100 CET
-IsValid : true
-Version : 3
-KeyCounter : 5
-KeyExpires : 2021-09-23 11:43:09 +0200 CEST
-KeyModulusBitlen: 2048
-```
-
-### Attribute-based signatures: `POST /irma/session/{clientToken}/proofs`
-
-The app POSTs an [`irma.SignedMessage` instance](https://pkg.go.dev/github.com/privacybydesign/irmago#SignedMessage), for example:
-
-```json
-{
- "@context": "https://irma.app/ld/signature/v2",
- "signature": [
- {
- "c": "fxMY3mOBnyuh+snmkvpza7R8yoNhXk5WWWDAddxpmwM=",
- "A": "pU8O3BUrdgAZ5+Xekea+++MJSsZKkqdHRJOv11Nog5BmKnFpbV388ZMaSFOj1BsFT6vA3O7sWNMfxgWrgWYDONdIrd9zLt+GbT4kcqDvp/ual2u9JqAOkt6xHoG2kDX9VLLBRxsPzgeyic/NReqXotQ7qcSppf/9NGe6u+BJnmEWPALIdSfv+dwycfrWf3qAblMmwwYKodUBLwRd0nvR1NXsq5omieM9QRf12rXyZHJ4/jxDL7YKXk3CbKQxqZP84Q8MWoL3BnaVvL+XcAdZcxh4ayZSNBfOF2ovZQhNtWmIueLMf2MrVVF6V8Z4j+WBHEE0bTJLXfSsWzi1ex89Ww==",
- "e_response": "CtS3r/LSInVqRzb7fbF9g/TozXmPHzoPbR2O/Hap2sWJlIC2qxaDwGkiJuCxw/nhLrV7u9Qy8b4jpd70xwno",
- "v_response": "AUMG/sw2Dx34g2eYrm15+/lgubKoQR0tHctZIfOHs2IT+9n7lmXW/kA57f5O43LxG14yo6G7vSdqwW5QRsCfix/nbl2El0C31sFb5ZyKVcHsFDB4derCQYaAqr6lbSUS6mjHSl5p8JMMoGErF/B0f+9dNrbZlWXbdzckdZUruWEbnoSvXvt8v6oXmHCE7ngHrxa+0ft/Fs6phvgYbAA/ABXwxuSjsm2U0FUMdfpKwhwClOFWZzgX5HLV4rNq/Z6j9DYd6NEKnwSavLB0h8F1gibV2IyxdTFWM7B62Izq8W2NvJkvNE7Z+CaeAFyyHGmA12rSfPfPqspEGd87UJo2ByfZ8DZZsWoe0EYM/LYPnK4BDsaKNiNXc1+42QkZkeL7ZL2p+er7F6CfuhpebEt7gaANiBUJfR0XFMC1IH/eLvx6Y9Sa7h9NvcHFGC1/cHgEOk9SZi4AXpg7W05Tv01IYQg6o+hgjwAI23dEm2TM4CMDyFXsi0XSa/m9DcnZXWrRrz8DLz3XDLO6SlBkKDzOfyw=",
- "a_responses": {
- "0": "09um7BUT1sfj4G8NJfNTxVrxQR5Fxyjb88EWOtICeQAcwMJPeL7HjfjkVuDSsnUbO/a95PMwWo2QOjz3pYx5TwfxksfODhov1SdGQublems=",
- "3": "wXFVVu64epTtUeuwYhkTsStWRoKJKjgo69Y2YBFdWJY2D4oIH3ut0Fprs/p2Mhm+g180Gc0JuiFqVJfMnTUhBbs26ENDGbAZZRVdobu7520=",
- "4": "A8rAICtm6tykmm21SBkOFrjZQt7K2xukuPaoXhYJOtX180p29tzueTipAp/nfDyRwLkWox26QBj0s8AXmOvzU0S4vq5oHSxsHVWvKosMHLM="
- },
- "a_disclosed": {
- "1": "AwAKhwAaAAXZZxdMn4TvQ6F/mVxWb6a7",
- "2": "5MrO6tjC5Q=="
- }
- }
- ],
- "indices": [
- [
- {
- "cred": 0,
- "attr": 2
- }
- ]
- ],
- "nonce": "u9llQevSkYoDEiz/qAtJDQ==",
- "context": "AQ==",
- "message": "The message signed by this signature",
- "timestamp": {
- "Time": 1630063199,
- "ServerUrl": "https://irma.sidn.nl/atumd",
- "Sig": {
- "Alg": "ed25519",
- "Data": "iAyQutB26ZaVLgfXvMa+sjAeXOYclpInq+xIaROdoWG/WqIg6xWQuFwaPvZQ0PQk5C3e0EYNDGsjNTpQejWBCw==",
- "PublicKey": "MKdXxJxEWPRIwNP7SuvP0J/M/NV51VZvqCyO+7eDwJ8="
- }
- }
-}
-```
-
-Here, the fields are as follows:
-
-* `@context` identifies this as an IRMA attribute-based signature.
-* `signature` is the same as [`proofs` in disclosure sessions](#disclosure-post-irma-session-clienttoken-proofs).
-* `indices` is the same as in [disclosure sessions](#disclosure-post-irma-session-clienttoken-proofs).
-* `nonce` and `context` have the same values as in the [session request](#get-irma-session-clienttoken-request). Contrary to the response of disclosure sessions they are included here, so that the signature is completely self-contained: it contains all information necessary to verify its validity.
-* `message` is the message signed by this signature.
-* `timestamp` contains a signed timestamp, which is used during verification of the attribute-based signature to establish that the attributes within it were valid at creation time of the signature.
-
-### Issuance: `POST /irma/session/{clientToken}/commitments`
-
-The app POSTs an [`irma.IssueCommitmentMessage` instance](https://pkg.go.dev/github.com/privacybydesign/irmago#IssueCommitmentMessage), for example:
-
-```json
-{
- "combinedProofs": [
- {
- "U": "LcIn9Bbp2HN0gLPU11fFSWbLlGcUz1SzmsSk0yxY7Qou3RlucUErR/xvBuhUG3kCOhVVuZm2tw/W0OAWc/ivsYZ+XxV/bJURcFjaDt7cyKN7hIG1LYTtUHy343eSSCUBTKshO4cNy+QdL7jwzh5+wXdGUuUvJ4FEg1ktjOt2zaA=",
- "c": "FTgz4JDU+B5C21ieVZ7b+d8DDohXSRDRm311Kv8T9/o=",
- "v_prime_response": "f6kkO0Z85+gjE3av3bEyr7EJgh7yjW39aKtt/oI4m6QyGu95CqLMbHLObz3cPAnGsm/GhL2KnGZiyF89KnHBrSaiCyAjzpaqTK17/SisNdqSI0gTtqMnQLdVlHGQLeBiS00iHRbG943p6kXXiBCNz7RUxDU3uDgVMq58YaragkYHwudd2YANUFe0XuTbkQ0HEdIOyhJA5PRfxcpsXPg2P9MlL1oppqM69PL/Sy3v9mgdc8G/",
- "s_response": "R71lJ6mVIeLb6g2sabiShN2hOHoSirE2b0/DoESEEDntHlOyaLrPIxjuH2DNV8PTYa/NonBvF9Wfpn9zRNnIyrr6C5+0XRjpYPM="
- }
- ],
- "n_2": "kRNuTr7JcrhXvwIfR+EUKQ=="
-}
-```
-
-The `combinedProofs` array contains, for each credential being issued within the session (one in this example), a [zero-knowledge proof](zkp.md) of the IRMA app's secret key (which will become [the first attribute](overview.md#the-secret-key-attribute) of the credential(s) being issued). In addition, in case of [combined disclosure-issuance sessions](session-requests.md#issuance-requests) this array will also contain [`gabi.ProofD`](https://pkg.go.dev/github.com/privacybydesign/gabi#ProofD) instances, like the `proofs` array in [disclosure sessions](irma-protocol.md#disclosure-post-irma-session-clienttoken-proofs).
-
-When responding to this HTTP request (see below) with its signature(s) over the attributes, the IRMA server includes a zero-knowledge proof of its own, proving that it correctly constructed its signatures. The `n_2` field contains the nonce over which the issuer is to construct that zero-knowledge proof (c.f. the `nonce` in the session request, see [above](irma-protocol.md#get-irma-session-clienttoken-request)).
-
-### The IRMA server's response
-
-When receiving data from the IRMA app on any of the above three endpoints, the IRMA server first verifies the proofs contained in them (note that the app sends zero-knowledge proofs for each session type). The IRMA app is a challenge-response protocol, so referring back to the `nonce` in the session request (as [mentioned earlier](irma-protocol.md#get-irma-session-clienttoken-request)) which acts as the challenge, the data that the IRMA app sends to these endpoints must be a valid response to that particular challenge.
-
-The server responds with an [`irma.ServerSessionResponse`](https://pkg.go.dev/github.com/privacybydesign/irmago#ServerSessionResponse) for each of the three above endpoints. For example:
-
-```json
-{
- "proofStatus": "VALID",
- "nextSession": {
- "u": "https://example.com/irma/session/QBeuXS3iWcYY76rdHfP6",
- "irmaqr": "disclosing"
- },
- "sigs": [
- {
- "signature": {
- "A": "QyeTB0DyqPV9563K0bANaQqQ+zshEUfjcc/fB0pGgc4TXVtu+0mTvohePatBNt3G7GJeJEjnjJHW5AvmhpN74PWJiqXxjlrlkAIJ3oKW0BDIT4t1eaicpXeICq2MU441YWR5dxNX5oYB3fNqjGPnXNJA5XuIBnME3hPl1M4EgTc=",
- "e": "EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACBXzy0nbspQi7Bn5leUl",
- "v": "D3D/nmdPqJ0s3f936ZQ6mKm73J/nA2Aoc0whTGXnYLfr1PwpuHCeI5uSZ5P2TI92h6GSKbiWdmRSjYZPq9K4uqITaJp+ojKwNEomgcUrEKb+VK+dPjEzwvSwC5MoyfPhoEjxSsRiOgCX4rqAheAdFYQru481hZz7ljmNrp0NgYb8vjxLE3YGshamhRYBe03aO1ZSuS8I54qrRQqqOsoL5+D/olZYlv9K5RV8ndz2Q8Kp/0GpB3rTo8okohP5Sx1uAKKJg10bv+Z0OolGli3o76bbc5I6",
- "KeyshareP": null
- },
- "proof": {
- "c": "39uLUi9wzUQMFes7y5l7Es/Xm2LBRJdfI0cFz1AdtmA=",
- "e_response": "FmokcMY3fjT7G4qGMZAnkfgofCm/xmnzNLxxulxsOALtTWCePNi9W5yBe7y83DT6KBBaOmvf29OunzjorK9DOnXaSt64DX8hLw8J/pqn+1RfpvKpBwXfILS26FP7iZVGuUmozp26sai0iuL7qiV1QL/eXD0C+6bgUtcWUusBbR0="
- }
- }
- ]
-}
-```
-
-Here the fields are as follows:
-
-* `proofStatus`: an [`irma.ProofStatus`](https://pkg.go.dev/github.com/privacybydesign/irmago#ProofStatus) constant containing whether or not the server successfully validated the proofs that it received from the app. Anything else than `VALID` is considered an error by the app. (The same status is reported to the requestor in the session result, see below.)
-* `nextSession` optionally contains the [session pointer](https://pkg.go.dev/github.com/privacybydesign/irmago#Qr) to the next session in the [session chain](chained-sessions.md). If this field is present, then after processing the current response the app will immediately start the next session using this session pointer.
-* In case of issuance sessions, the `sigs` array contains the issuer's signatures over each of the credentials being issued (if `proofStatus` is `VALID`). For each object within this array, the `signature` object contains the signature itself, and the `proof` is the issuer's proof of correctness of the signature, over the nonce `n_2` mentioned [above](#issuance-post-irma-session-clienttoken-commitments).
-
-After this, the session state is set to [`DONE`](https://pkg.go.dev/github.com/privacybydesign/irmago#ServerStatusDone), and the requestor can retrieve the [session result](https://pkg.go.dev/github.com/privacybydesign/irmago/server#SessionResult) at the [`GET /session/{requestorToken}/result`](api-irma-server.md#get-session-requestortoken-result) or [`GET /session/{requestorToken}/result-jwt`](api-irma-server.md#get-session-requestortoken-result-jwt) endpoints, or using the [`GetSessionResult()` function](https://pkg.go.dev/github.com/privacybydesign/irmago/server/irmaserver#Server.GetSessionResult).
-
-## Cancelling: `DELETE /irma/session/{clientToken}`
-
-If the user decides to cancel the session, or if the IRMA app finds that it does not possess the attributes being requested, or if the app encounters any error during any part of the session, then the the app cancels the session by invoking `DELETE /irma/session/{clientToken}`. The server responds with HTTP status 200 and no response body. The session state is set to [`CANCELLED`](https://pkg.go.dev/github.com/privacybydesign/irmago#ServerStatusCancelled).
-
-## Errors
-
-If the server encounters any error when handling invocations of any of the endpoints documented here, it will set the session state to `CANCELLED`, and instead of responding to the IRMA app with the objects documented above it responds with an [`irma.RemoteError`](https://pkg.go.dev/github.com/privacybydesign/irmago#RemoteError), containing details about the error. For example, when invoking any of the above four endpoints using a `clientToken` that does not refer to an existing session in the `CONNECTED` state, the server responds with the following:
-
-```json
-{
- "status": 400,
- "error": "SESSION_UNKNOWN",
- "description": "Unknown or expired session"
-}
-```
-
-The IRMA app will then inform the user that an error occurred, and in some cases allow the user to report the error to the IRMA team.
diff --git a/website/versioned_docs/version-v0.8.0/session-requests.md b/website/versioned_docs/version-v0.8.0/session-requests.md
deleted file mode 100644
index dfcfbea..0000000
--- a/website/versioned_docs/version-v0.8.0/session-requests.md
+++ /dev/null
@@ -1,491 +0,0 @@
----
-title: Session requests
-id: version-v0.8.0-session-requests
-original_id: session-requests
----
-
-
-
-Each [IRMA server](what-is-irma.md#irma-servers) exposes APIs for creating IRMA sessions with a session request. An *IRMA session request* contains all information required for the IRMA server and [IRMA app](irma-app.md) to perform an IRMA session with, such as the attributes to be issued or verified. This page documents IRMA session requests. It applies to:
-
-* The [`POST /session`](api-irma-server.md#post-session) endpoint from [`irma server`](irma-server.md).
-* The [`StartSession()` function](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver#StartSession) in the `irmaserver` Go library.
-* The [`startSession()` function](api-irmajs.md#startsession) of `irmajs`.
-
-For the precise role of session requests in an IRMA session, see this [diagram of an IRMA session](what-is-irma.md#irma-session-flow).
-
-## Session request data types
-
-For each of the [three IRMA session types](what-is-irma.md#session-types), we define a *session request* data type: an object whose JSON representation contains at least a [JSON-LD `@context`](https://w3c.github.io/json-ld-syntax/#the-context) key identifying which message type it is, and extra keys specific to the session type. The following three `@context` values identify disclosure, attribute-based signature, and issuance session requests respectively:
-
-* `"@context": "https://irma.app/ld/request/disclosure/v2"`
-* `"@context": "https://irma.app/ld/request/signature/v2"`
-* `"@context": "https://irma.app/ld/request/issuance/v2"`
-
-(For now these URIs do not resolve to anything; they just distinguish the message type.)
-
-## Disclosure requests
-Disclosure sessions are started with an [`irma.DisclosureRequest`](https://godoc.org/github.com/privacybydesign/irmago#DisclosureRequest). Example:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.MijnOverheid.root.BSN" ]
- ],
- [
- [
- "irma-demo.nijmegen.address.street",
- "irma-demo.nijmegen.address.houseNumber",
- "irma-demo.nijmegen.address.city"
- ],
- [
- "irma-demo.idin.idin.address",
- "irma-demo.idin.idin.city"
- ]
- ]
- ]
-}
-```
-
-```golang
-// Create a new empty request
-request := irma.NewDisclosureRequest()
-
-// Request specific attributes
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.root.BSN")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.nijmegen.address.street"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.houseNumber"),
- irma.NewAttributeRequest("irma-demo.nijmegen.address.city"),
- },
- irma.AttributeCon{
- irma.NewAttributeRequest("irma-demo.idin.idin.address"),
- irma.NewAttributeRequest("irma-demo.idin.idin.city"),
- },
- },
-}
-```
-
-
-
-
-This asks for a (demo) `BSN` attribute, as well as either `street`, `houseNumber` and `city` from `irma-demo.nijmegen.address`, or `address` and `city` from `irma-demo.idin.idin`. The three levels correspond to a *conjunction* of *disjunctions* of *conjunctions* of requested attributes, allowing verifiers to request multiple attribute sets from the user, offering choices for some or all of these sets.
-
-All of the attribute types (i.e., the string values) contained in the request must exist in their scheme ([`irma-demo`](https://github.com/privacybydesign/irma-demo-schememanager) in the example above). For the `irma-demo` and `pbdf` schemes, an index of existing attribute types that can be requested can be found [here](https://privacybydesign.foundation/attribute-index/en/).
-
-> Attributes can be disclosed to the requestor in any of the three session types: in issuance sessions issuance proceeds only if the user discloses the required attributes just before issuance, and in attribute-based signature sessions the requested attributes are attached to the resulting attribute-based signature. Thus the `disclose` and `labels` fields introduced above can also occur in issuance or attribute-based signature session requests (see below).
-
-### Multiple credential types within inner conjunctions
-In the request above 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).
-- 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 IRMA app automatically only offers candidate sets as choices to the user that satisfy this property.)
-
-For example, consider the following session request:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- "pbdf.pbdf.diploma.degree",
- "pbdf.pbdf.diploma.institute"
- ]
- ]
- ]
-}
-```
-
-```golang
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{
- irma.NewAttributeRequest("pbdf.pbdf.diploma.degree"),
- irma.NewAttributeRequest("pbdf.pbdf.diploma.institute"),
- },
- },
-}
-```
-
-
-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.)
-
-When combining multiple credential types within a disjunction these restrictions ensure that when the IRMA app computes candidate attribute sets for the user to choose from, the amount of resulting options stays manageable. In adddition, the second restriction is a feature on its own, allowing verifiers to request multiple attributes coming from one credential instance.
-
-### Requesting specific attribute values
-Within inner conjunctions, specific attribute values can be requested by replacing the string with an object like the following:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "pbdf.pbdf.diploma.degree", "value": "PhD" },
- { "type": "pbdf.pbdf.diploma.institute", "value": null }
- ]
- ]
- ]
-}
-```
-
-```go
-phd := "PhD"
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.degree"),
- Value: &phd,
- }, {
- Type: irma.NewAttributeTypeIdentifier("pbdf.pbdf.diploma.institute"),
- Value: nil,
- }},
- },
-}
-```
-
-
-This would only be satisfied by a `degree` attribute whose value is `PhD`, together with any `institute` attribute. (Note that the object and string syntaxes can be mixed within an inner conjunction, i.e. it would be permissible in the JSON example above to replace the second object with just `"pbdf.pbdf.diploma.institute"`.)
-
-### Null attributes
-
-Whenever an attribute is marked with `optional` in the scheme ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)), the issuer may skip it when it issues an instance of the containing credential type, assigning a `null` value to it (which is distinct from the empty string `""`). When disclosing the attribute, the verifier receives `null` instead of a string containing the attribute value.
-
-If a non-null attribute is required this can be requested using `notNull` as follows:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [
- { "type": "irma-demo.MijnOverheid.fullName.prefix", "notNull": true }
- ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{{
- Type: irma.NewAttributeTypeIdentifier("irma-demo.MijnOverheid.fullName.prefix"),
- NotNull: true,
- }},
- },
-}
-```
-
-
-The default value of `notNull` is `false`.
-
-### Optional disjunctions
-
-A disjunction within a session request can be marked as *optional*, by including an empty inner conjunction in it:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [
- [ "irma-demo.nijmegen.address.city" ]
- ],
- [
- [],
- [ "irma-demo.MijnOverheid.fullName.firstname" ]
- ]
- ]
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Disclose = irma.AttributeConDisCon{
- irma.AttributeDisCon{
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.nijmegen.address.city")},
- },
- irma.AttributeDisCon{
- irma.AttributeCon{},
- irma.AttributeCon{irma.NewAttributeRequest("irma-demo.MijnOverheid.fullName.firstname")},
- },
-}
-```
-
-
-
-
-This can be useful when certain attributes are not required, so that if the user does not have them the session does not need to be aborted.
-
-### Disjunction labels
-
-Per disjunction a *label* can be specified, which is shown in the IRMA app when the user is asked for permission to disclose attributes. For example, the session request from [above](#disclosure-requests) could be augmented with a label for the second disjunction as follows:
-
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- [ ... ],
- [ ... ]
- ],
- "labels": {
- "1": { "en": "Work address", "nl": "Werk adres" }
- }
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.Labels = map[int]irma.TranslatedString{
- 1: {"en": "Work address", "nl": "Werk adres"},
-}
-```
-
-
-
-
-In this way each disjunction can be given a optional label explaining to the user the purpose of the disjunction. It is recommended to only provide a label to explain something to the user that would otherwise not be obvious; for example, to request the user to send a work email address instead of a personal one. Repeating the credential or attribute name or description in labels is an antipattern.
-
-## Attribute-based signature requests
-Attribute-based signature sessions are started with an [`irma.SignatureRequest`](https://godoc.org/github.com/privacybydesign/irmago#SignatureRequest), which are similar to disclosure requests:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/signature/v2",
- "message": "Message to be signed by user",
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-request := irma.NewSignatureRequest("Message to be signed by user")
-request.Disclose = irma.AttributeConDisCon{ /* request attributes to attach to ABS */ }
-request.Labels = map[int]irma.TranslatedString{}
-```
-
-
-The `message` field is required. The attributes to be attached to the attribute-based signature are requested with the `disclose` field, which along with the `labels` field work exactly like in disclosure sessions.
-
-## Issuance requests
-Issuance sessions are started with an [`irma.IssuanceRequest`](https://godoc.org/github.com/privacybydesign/irmago#IssuanceRequest). Example:
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/issuance/v2",
- "credentials": [{
- "credential": "irma-demo.MijnOverheid.ageLower",
- "validity": 1592438400,
- "attributes": {
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no"
- }
- }],
- "disclose": ...,
- "labels": ...
-}
-```
-
-```go
-validity := irma.Timestamp(time.Unix(1592438400, 0))
-request := irma.NewIssuanceRequest([]*irma.CredentialRequest{
- {
- CredentialTypeID: irma.NewCredentialTypeIdentifier("irma-demo.MijnOverheid.ageLower"),
- Validity: &validity, // optional
- Attributes: map[string]string{
- "over12": "yes",
- "over16": "yes",
- "over18": "yes",
- "over21": "no",
- },
- },
-})
-request.Disclose = irma.AttributeConDisCon{} // optional
-request.Labels = map[int]irma.TranslatedString{} // optional
-```
-
-
-Per credential in the `credentials` array the `validity` is optional; if skipped it is assigned the default value of 6 months. If present, the validity is always rounded down to the [nearest epoch boundary](overview.md#special-attributes), which is one week (60 * 60 * 24 * 7 = 604800 seconds).
-
-Attributes marked as `optional` in the containing credential type ([example](https://github.com/privacybydesign/irma-demo-schememanager/blob/482ba298ee038ea43bd0cf8017567a844be0919e/MijnOverheid/Issues/fullName/description.xml#L54)) may be skipped in the `attributes` map. This issues [the `null` value](#null-attributes) to these attributes.
-
-`disclose` and `labels` are optional, allowing for *combined disclosure-issuance sessions*, in which the user is required to disclose attributes before the IRMA server will issue the credentials.
-
-The `clientReturnUrl` option can also be used, both for issuance only and combined disclosure-issuance sessions. Usage is similar as in [disclosure sessions](#client-return-url).
-
-## Client return URL
-If the user performs a mobile session, i.e. on the same device as where the IRMA app is installed on, then after the session has completed the user will be redirect to the `clientReturnUrl` specified in the session request, if present.
-
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- ...
- ],
- "clientReturnUrl": "https://example.com"
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.ClientReturnURL = "https://example.com"
-```
-
-
-The example shows a disclosure request but `clientReturnUrl` can be set on session requests of any type. If set, when the user finishes a session (either successfully or unsuccessfully), she is redirected to the location specified by `clientReturnUrl`.
-
-If *not* set:
-* On Android the IRMA app automatically toggles back to the previous app;
-* On iOS it is not possible to toggle back to the previous app due to restrictions by Apple, so the IRMA app stays open. In the top left corner of the screen, however, a button appears that leads back to the previous app.
-
-This URL does not necessarily have to be a web URL; it can also be a universal link to another app. Universal links work both on Android and iOS. It is also possible to use iOS or Android scheme URLs. (Note however that iOS and Android scheme URLs differ from one another, so when starting a session with a scheme URL as return URL you should therefore determine on which platform the user's app is running.)
-
-On iOS, toggling back to the calling app or website after the session can be simulated by navigating towards the calling app using a `clientReturnUrl`, either a normal URL or universal link. This works on Android as well, so currently this is the only platform-independent way of ensuring that the used ends up at a specified place after the session. If the URL opens a website, however, then the user is navigated towards a new browser tab instead of back to an existing browser tab, so in website-IRMA-website flows you will need to reload your webapp and state in the newly opened tab.
-
-### Augmenting the client return URL
-
-It is possible to have the IRMA server augment the `clientReturnUrl` with the server token of a session (i.e., the `token` in the [response of the `/session` endpoint](api-irma-server.md#post-session)). This token is then appended as a query parameter with name `token` to the `clientReturnUrl`. Using this token, one can the retrieve the [session result](api-irma-server.md#get-session-token-result).
-
-To enable this, both the server configuration flag `augment-client-return-url` needs to be enabled, as well as the `augmentReturnUrl` session request parameter needs to be true.
-
-
-```json
-{
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [
- ...
- ],
- "augmentReturnUrl": true,
- "clientReturnUrl": "https://example.com"
-}
-```
-
-```go
-request := irma.NewDisclosureRequest()
-request.ClientReturnURL = "https://example.com"
-request.AugmentReturnURL = true
-```
-
-
-In this example, the client return url would be augmented to become `https://example.com?token=0123456789abcdef`, where `0123456789abcdef` would be the server token of the session.
-
-## Extra parameters
-For each API that accepts one of the above session request data types, the requestor can provide additional parameters to configure the session at the IRMA server, by providing an *extended session request* instead, as follows:
-
-
-```json
-{
- "validity": 120,
- "timeout": 120,
- "callbackUrl": "https://example.com",
- "nextSession": {
- "url": "https://example.com/nextsession"
- },
- "request": ...
-}
-```
-
-```go
-// See also corresponding types irma.SignatureRequestorRequest
-// and irma.IdentityProviderRequest
-irma.ServiceProviderRequest{
- irma.RequestorBaseRequest{
- ResultJwtValidity: 120,
- ClientTimeout: 120,
- CallbackUrl: "https://example.com",
- NextSession: &irma.NextSessionData{URL: "https://example.com/nextsession"},
- },
- irma.NewDisclosureRequest(),
-}
-```
-
-
-Below you can find an overview of all extra parameters and their default value.
-
-| Option (JSON) | Option (Go) | Meaning | Default value |
-| ------------- | ----------- | ------- | ------------- |
-| `"validity"` | `ResultJwtValidity` | Validity of session result JWT in seconds (to determine JWT expiration time `exp`) | 120 seconds |
-| `"timeout"` | `ClientTimeout` | Wait this many seconds for the IRMA app to connect before the session times out | 300 seconds (5 minutes) |
-| `"callbackUrl"` | `CallbackUrl` | URL to post session result to | `""` (no callback is performed) |
-| `"nextSession"` | `NextSession` | Continue with a follow-up IRMA session when this session succeeds. The session result is posted to `URL`, and as response on the `POST` a new session request should be returned for the IRMA server to start. More documentation [here](chained-sessions.md). | `nil` (there is no next session) |
-
-## JWTs: signed session requests
-The IRMA API server or [`irma server`](irma-server.md) can be configured such that it only accepts session requests that have been digitally signed in the form of a [JWT](https://jwt.io). The form of the JWT depends on the [session type](what-is-irma.md#session-types). An example requesting [IRMATube](https://privacybydesign.foundation/demo/irmaTube) attributes::
-```
-eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImlybWF0dWJlIn0.eyJpYXQiOjE1NjQ2NTczNzUsInN1YiI6InZlcmlmaWNhdGlvbl9yZXF1ZXN0Iiwic3ByZXF1ZXN0Ijp7InJlcXVlc3QiOnsiQGNvbnRleHQiOiJodHRwczovL2lybWEuYXBwL2xkL3JlcXVlc3QvZGlzY2xvc3VyZS92MiIsImRpc2Nsb3NlIjpbW1sicGJkZi5wYmRmLmlybWF0dWJlLnR5cGUiXV0sW1sicGJkZi5wYmRmLmFnZUxpbWl0cy5vdmVyMTIiXSxbInBiZGYuZ2VtZWVudGUucGVyc29uYWxEYXRhLm92ZXIxMiJdXV19fX0.lW9mqjrLkoahDP6Fcw_9mH5hlfl1tq5qp3W3ga0Nrd_j0NXFj-6ngqHVXEV1zhC_OkVH4LN8fMBAgN8nqaFWgEdQvrCuB7-ynuBVjLR-QU272Ym86zLEWYggAkbZ5KY40MpTxU1dgFMucG7fyAESic04OribWOCVxstAMsM28yCxvzkBMCOSjFEe3abcg_N6VvQnLn3LgZP_UrxQmQsh4DK7mBjW04LesLG1vjcliyhDGUb52FHOP_NAsG7G2FvIgojPzALlPrpTMu5p8a95wc5CGR791wybmh0F8kDdwZWAU0W2FjlX5bNPsyXN8AxRVWaRmWoGrGsQhy_sKEf8lg
-```
-In case of disclosure sessions, the body of the JWT (the part in between the two dots) contains a Base64-encoding of the following:
-
-
-```json
-{
- "iat": 1550424847,
- "sub": "verification_request",
- "sprequest": ...
-}
-```
-
-```go
-// Sets iat, iss, and sub fields.
-// See also corresponding functions irma.NewSignatureRequestorJwt()
-// and irma.NewIdentityProviderJwt().
-// Obtain signed JWT string to POST to an irma server using Sign() method.
-irma.NewServiceProviderJwt("IRMATube", irma.NewDisclosureRequest())
-```
-
-
-The fields are as follows:
-* `iat`: Unix timestamp of the creation date of the JWT. IRMA servers may reject JWTs beyond a certain age.
-* `iss`: contains the requestor name, and is used by the IRMA server to lookup the appropriate key with which to verify the JWT.
-* `sub`: JWT subject, in case of disclosure sessions this must always be `"verification_request"`.
-* `sprequest`: contains an extended disclosure session request as defined above.
-
-For each possible session type, the contents of the `sub` field and the name of the field containing the session request must be as follows.
-
-| Session type | `sub` contents | Session request field name | Go function |
-| ------------ | -------------- | -------------------------- | ----------- |
-| Disclosure | `verification_request` | `sprequest` | `irma.NewServiceProviderJwt()` |
-| Attribute-based signature | `signature_request` | `absrequest` | `irma.NewSignatureRequestorJwt()` |
-| Issuance | `issue_request` | `iprequest` | `irma.NewIdentityProviderJwt()` |
-
-Currently the following libraries can produce JWTs of this form:
-* The [`irmago`](https://godoc.org/github.com/privacybydesign/irmago) library, using the mentioned functions
-* The [`irmajs`](irmajs.md) Javascript library
-* The [`irma-requestor`](https://github.com/privacybydesign/irma-requestor) PHP library
-* The [`irma_api_common`](https://github.com/privacybydesign/irma_api_common) Java library
-* The [`irma-diva-js`](https://github.com/Alliander/diva-irma-js) Javascript library
-
-`irma server` currently supports JWTs signed (asymmetrically with RSA) with the `RS256` algorithm, and (symmetrically signed with HMAC-SHA256) `RS256`. The IRMA API server only supports `RS256`.
diff --git a/website/versioned_docs/version-v0.9.0/irma-server.md b/website/versioned_docs/version-v0.9.0/irma-server.md
deleted file mode 100644
index d2042a4..0000000
--- a/website/versioned_docs/version-v0.9.0/irma-server.md
+++ /dev/null
@@ -1,300 +0,0 @@
----
-title: irma server
-id: version-v0.9.0-irma-server
-original_id: irma-server
----
-
-
-`irma server` is an IRMA server executable (daemon) allowing you to perform IRMA sessions with
-[IRMA apps](irma-app.md). It handles all IRMA-specific cryptographic details of issuing or verifying IRMA attributes with an IRMA app on behalf of a [requestor](overview.md#participants) (the application wishing to verify or issue attributes). It exposes the following:
- * HTTP endpoints under `/irma`, used by the IRMA app during IRMA sessions
- * a JSON API under `/sessions` for requestors, allowing them to request the server to verify or issue attributes.
-
-`irma server` is a subcommand of the [`irma`](irma-cli.md) command line tool, which additionally contains subcommands to start or perform IRMA sessions, handle [IRMA schemes](schemes.md), and more.
-
-For installation instructions, see [`irma`](irma-cli.md).
-
-## Running the server
-
-Simply run `irma server` to run the server with the default configuration in development mode. Use `irma server -v` for more verbose logging, for example to see the current configuration. Use `irma server -vv` to also log session contents.
-
-Run `irma server --help` to see configuration options. In order to verify your configuration, run `irma server check -v`.
-
-## Starting a session
-Assuming the server runs in the [default configuration](#default-configuration) (in particular [requestor authentication](#requestor-authentication) is disabled (`no_auth` is `true`) and the `irma-demo` [scheme](schemes.md) is installed), issue `irma-demo.MijnOverheid.ageLower` attributes using the [`session`](irma-cli.md) subcommand of the `irma` tool:
-```shell
-irma session --server http://localhost:8088 --issue irma-demo.MijnOverheid.ageLower=yes,yes,yes,no
-```
-Verify the `irma-demo.MijnOverheid.ageLower.over18` attribute:
-```shell
-irma session --server http://localhost:8088 --disclose irma-demo.MijnOverheid.ageLower.over18
-```
-These print QRs in your terminal that you can scan with your [IRMA app](irma-app.md) to perform the session. For more extensive examples, see [irmajs](irmajs.md).
-
-## Configuring
-Run `irma server -h` to see all configuration options. Each option may be passed as:
- 1. a command line flags (e.g. [`--listen-addr`](#http-server-endpoints))
- 2. a environmental variable (e.g. `IRMASERVER_LISTEN_ADDR`)
- 3. an item in a configuration file (e.g. `"listen_addr"`) (which may be in JSON, TOML or YAML)
-
- with the following rules:
- * Flags supersede environmental variables which supersede configuration file entries.
- * Dashes are used in flags, but underscores are used in environmental variables and configuration file entries.
- * Environmental variables are uppercased and prefixed with `IRMASERVER_`.
- * The [`requestors`](#requestor-authentication) and [`static_sessions`](#static-irma-qrs) options are special: when passed as a flag or environmental variable, they must be passed as a JSON object (for example: `--requestors '{"myapp":{"auth_method":"token","key":"12345"}}'`).
- * When passing a boolean flag [use an `=`](https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax), for example [`--no-auth=false`](#requestor-authentication).
-
-In order to see the configuration that the server uses after having gathered input from these sources, specify `-v` or `-vv` or use the `verbose` option. Use `irma server check -v` (with the same flags, env vars and config files as `irma server`) to check your configuration for correctness before running the server.
-
-For a full configuation example, see [Getting started](getting-started.md#example-configuration-and-irma-session).
-
-In the remainder of this document, when referring to options we write them as configuration file entries, with underscores and without prefix.
-
-### Default configuration
-In the default configuration (run `irma server check -v` to see it) the server is immediately usable. In particular, it
-* uses the [default IRMA schemes](schemes.md#default-schemes-pbdf-and-irma-demo) ([`pbdf`](https://github.com/credentials/pbdf-schememanager) and [`irma-demo`](https://github.com/credentials/irma-demo-schememanager)), downloading them if necessary
-* allows anyone to use the server [without authentication](#requestor-authentication) (the `no_auth` setting is `true`)
-* saves the session state in memory.
-
-If the server is reachable from the internet, you should consider enabling authentication of session requests.
-
-### Configuration files
-A configuration file can be provided using the `config` option (for example: `irma server --config ./irmaserver.json`). When not specified, the server looks for a configuration file called `irmaserver.json` or `irmaserver.toml` or `irmaserver.yaml` in (1) the current path; (2) `/etc/irmaserver/`; (3) `$HOME/irmaserver`, in that order. A configuration file is not required; if none is found at any of these locations the server takes its configuration from just command line flags and environmental variables.
-
-### Production mode
-When running the server in production, you should enable the `production` option. This enables stricter defaults on the configuration options for safety and prints warnings on possibly unsafe configurations. In particular, when `production` is enabled, the default values of some options change as follows (cf. `diff <(irma server -h) <(irma server -h --production)`):
-
-* `url` from `"http://$YOUR_LOCAL_IP:port"` to `""`: in development mode the `url` to which IRMA apps will connect is set by default to your current local IP address; in `production` mode you must configure it yourself.
-* [`no_auth`](#requestor-authentication) from `true` to `false`: you should consider enabling requestor authentication, or explicitly disable this by setting this flag to `true`.
-* [`issue_perms`](#global-permissions) from `[*]` (everything) to `[]` (none).
-* [`no_email`](email.md) from `true` to `false`: in `production` mode, opting out of providing an email address can be done by explicitly setting this flag to `true`.
-
-In addition, when [developer mode is not enabled in the IRMA app](irma-app.md#developer-mode) (the default setting), the IRMA app wil refuse to perform sessions with IRMA servers not running in `production` mode. Since the majority of the IRMA app users will not have developer mode enabled, this requires IRMA servers facing those users to enable `production` mode.
-
-### Stateless mode
-By default session states are kept in memory. If you want to run several IRMA servers in parallel or if you wish data persistence for sessions, you can use [stateless mode](stateless.md) which is implemented in the IRMA server via a Redis data store.
-
-You can enable the Redis data store in the `irma server` by setting the `store_type` option to `redis` and specifying the `redis_addr` and `redis_pw` options.
-
-### Keys and certificates
-For each configuration option that refers to some kind of key or certificate (for example `jwt_privkey`), there is a corresponding option with the `_file` suffix (for example `jwt_privkey_file`). Keys can be specified either by setting former to a (PEM) string, or setting the the latter to a file containing the (PEM) string.
-
-### HTTP server endpoints
-The HTTP endpoints that this server offers is split into two parts:
-* `/session`: used by the requestor to start sessions, check session status, or get session results.
-* `/irma`: used by the IRMA app during IRMA sessions.
-
-In the default mode, the server starts one HTTP server that offers both, configured with `listen_addr` and `port`. If however the `client_port` and `client_listen_addr` options are provided, then the server starts two separate HTTP servers:
-* `/session` attaches to the address and port provided with `port` and `listen_addr`.
-* `/irma` attaches to the address and port provided with `client_port` and `client_listen_addr`.
-
-The `/irma` endpoints must always be reachable for the IRMA app. Using this double server mode you can restrict access to the `/session` endpoints by e.g. setting `listen_addr` to `127.0.0.1` or to an interface only reachable from an internal network. Restricting access to the `/session` endpoints in this way may make requestor authentication unnecessary.
-
-### Requestor authentication
-The server runs in one of two modes: it either accepts all session requests from anyone that can reach the server, or it accepts only authenticated session requests from authorized requestors. This can be toggled with the `no_auth` boolean option. If the `/session` creation endpoint of your `irma server` is publicly accessible from the internet (i.e. the `client_port` option is used, see [above](#http-server-endpoints)), then you should consider enabling requestor authentication (i.e. turn `no_auth` off), otherwise anyone can use your `irma server`.
-
-The default is `true` (requests are not authenticated) when `production` is disabled and `false` otherwise.
-
-When authentication is enabled (`no_auth` is `false`), requestors that are authorized to use the server must be configured in the `requestor` option in the form of a map, for example:
-
-```json
-{
- "requestors": {
- "myapp": {
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-
-The server supports several authentication methods, one of which must be specified in the `auth_method` field for each requestor. The snippet above demonstrates the recommended and easiest to use authentication method, called `token`. When using this method the requestor must include the `key` as an API token in a HTTP header (for more details see the [API reference](api-irma-server.md#post-session)).
-
-In addition the server supports the following authentication methods:
-* `hmac`: the requestor symmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/), with HMAC-SHA256 (`HS256`) using `key`. The `key` provided should be the Base64 encoding of the actual secret.
-* `publickey`: the requestor asymmetrically [signs the session request](session-requests.md#jwts-signed-session-requests) in a [JWT](https://jwt.io/) with RSA (`RS256`), in this case `key` should be the PEM public key of the requestor.
-
-For each of these modes it is also possible to specify `key_file` instead `key`; in that case the file at `key_file` will be read and used as `key`.
-
-### Static IRMA QRs
-Unlike normal QRs which differ per session (as they contain the session token), the server also supports static QRs which, when scanned by the IRMA app, start preconfigured IRMA sessions. This makes it possible to for example print such a static QR. These preconfigured sessions are configured with the `static_sessions` options, for example:
-```json
-{
- "static_sessions": {
- "mystaticsession": {
- "callbackUrl": "https://example.com/callbackUrl",
- "request": {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "irma-demo.MijnOverheid.ageLower.over18" ]]]
- }
- }
- }
-}
-```
-Thus `static_sessions` must contain a map of which each item must be an [extended session request](session-requests.md#extra-parameters). Including a `callbackUrl` to which the [session result](api-irma-server.md#get-session-token-result) is sent after the session is required (since for these sessions there is no requestor waiting to receive the attributes after the session has finished). If a JWT private key is installed, then the session result is sent as a [JWT](api-irma-server.md#get-session-token-result-jwt).
-
-> If no JWT private key is installed, then the `callbackUrl` should either not be publically reachable, or it should include a secret token (e.g. https://example.com/cX5aTins5kEZpjDpfYcN) and have TLS enabled (which it should anyway as personal data will be POSTed to it). Otherwise there is no way of distinguishing POSTs from your `irma server` from POSTs made by someone else.
-
-Assuming the URL of the `irma server` is `http://example.com`, the session configured above is started when the IRMA app scans a QR with the following contents:
-```json
-{
- "irmaqr": "redirect",
- "u": "http://example.com/irma/session/mystaticsession"
-}
-```
-
-Only static [disclosure or attribute-based signature sessions](what-is-irma.md#session-types) are supported.
-
-### Permissions
-For each of the [three IRMA session types](what-is-irma.md#session-types) (attribute verification; attribute-based signature sessions; and attribute issuance), permission to use specific attributes/credentials can be granted to requestors in the configuration. For example, including permissions in the `myapp` requestor from above:
-```json
-{
- "requestors": {
- "myapp": {
- "disclose_perms": [ "irma-demo.MijnOverheid.ageLower.over18" ],
- "sign_perms": [ "irma-demo.MijnOverheid.ageLower.*" ],
- "issue_perms": [ "irma-demo.MijnOverheid.ageLower" ],
- "auth_method": "token",
- "key": "eGE2PSomOT84amVVdTU"
- }
- }
-}
-```
-This means that `myapp` is authorized to request `irma-demo.MijnOverheid.ageLower.over18` in disclosure session, and any attribute from `irma-demo.MijnOverheid.ageLower` in attribute-based signature sessions. Additionally `myapp` can issue `irma-demo.MijnOverheid.ageLower` instances. In each level wildcards are permitted (`irma-demo.MijnOverheid.ageLower.*`, `irma-demo.MijnOverheid.*`, `irma-demo.*`, `*`). Thus `"disclose_perms": [ "*" ]` allows the requestor to verify any attribute.
-
-### Global permissions
-
-Global permissions can be applied to all requestors by using the global `disclose_perms`, `sign_perms` and `issue_perms` options. For each requestor, the effective set of permissions is the union of the permissions specified in its `requestors` map and the global permission set.
-
-The global options also work when `no_auth` is enabled. Thus in this case a session type can be disabled by granting no one the permission, e.g., `issue_perms: []` would disable issuance.
-
-In development mode, when `production` is `false`, the defaults for `disclose_perms`, `sign_perms` and `issue_perms` are `["*"]`. In order to protect any IRMA private keys that the server has access to from unintended use by others, when `production` is true the default of `issue_perms` is `[]`: no one can issue unless the global `issue_perms` is modified or unless specific requestors receive nonempty `issue_perms`.
-
-### Client return urls
-
-In session requests, the server can be asked to pass a [client return url](session-requests.md#client-return-url) to the IRMA app, which the app will open after completing the session for sessions that involve only one device. This feature is always enabled.
-
-### Augmented client return urls
-
-The server can be configured to [augment the client return url](session-requests.md#augmenting-the-client-return-url) when requested. In order to enable this feature, the `augment_client_return_url` setting needs to be set to `true`.
-
-### Static file hosting
-
-Apart from hosting endpoints under [`/session` and `/irma`](irma-server.md#http-server-endpoints), the server also supports statically hosting all files from a certain directory. This can be useful [for experimenting](getting-started.md#perform-browser-irma-session). It can be configured with the following options:
-
-* `static_path`: Host files under this path as static files. Leave empty to disable static file hosting.
-* `static_prefix`: Host static files under this URL prefix (default: no prefix)
-
-### IRMA schemes
-
-The server uses [IRMA schemes](schemes.md) to retrieve issuer, credential and attribute names, as well as public and private keys with which attributes can be verified an issued, respectively. By default the server uses the [`pbdf` and `irma-demo` schemes](schemes.md#default-schemes-pbdf-and-irma-demo). This can be configured with the following options:
-
-* `schemes_path`: path containing IRMA schemes (often called `irma_configuration`). Default: `C:\Users\Username\AppData\Local\irma\irma_configuration` on Windows, `$HOME/.local/share/irma/irma_configuration` otherwise. Created if it does not exist. If empty, the default schemes [`pbdf` and `irma-demo`](schemes.md#default-schemes-pbdf-and-irma-demo) are downloaded into it.
-* `schemes_assets_path`: path containing initial, read-only IRMA schemes. If specified, the schemes found here are copied into the path specified by `schemes_path`. Can be used to avoid downloading default schemes on first run.
-* `schemes_update`: update IRMA schemes from their scheme URL every this many minutes. Default is `60`. Set to `0` to disable automatic scheme updating (not recommended).
-
-### IRMA issuer private keys
-
-If IRMA issuer private keys are included in the server configuration, then the server can issue all credential types of all issuers for which private keys are installed. IRMA issuer private keys can be configured in the following two ways:
-
-* Include the private keys within the [IRMA scheme](schemes.md) in the issuer's `PrivateKeys` folder, with filenames `0.xml`, `1.xml`, etc ([example](https://github.com/privacybydesign/irma-demo-schememanager/tree/master/MijnOverheid/PrivateKeys)).
-* Set the `privkeys` option to a folder containing IRMA issuer private keys called `scheme.issuer.xml` or `scheme.issuer.counter.xml` (for example, `irma-demo.MijnOverheid.xml` or `irma-demo.MijnOverheid.2.xml`).
-
-If issuance is enabled in production and private keys are configured, then you should ensure that only authenticated requestors can start issuance requests (otherwise if anyone can use your server to issue attributes then those attributes cannot be trusted or used). You should either:
-
-* disable `no_auth` and [send authenticated session requests](irma-server.md#requestor-authentication),
-* Restrict the [`/session` HTTP endpoints](#http-server-endpoints) to a internal network interface only accessible by your applications and not from outside.
-
-Taking neither approach is an unsafe configuration as in that case anyone can create issuance sessions. In this case, if `production` mode is enabled then the server will refuse to run.
-
-### Signed JWT session results
-
-If a `jwt_privkey` (or `jwt_privkey_file`) is given, then the following endpoints are enabled:
-
-* `GET /session/{sessiontoken}/result-jwt`: returns the session result signed by the `irma server` into a JWT.
-* `GET /session/{sessiontoken}/getproof`: returns a JWT similar to the one from `result-jwt`, but with the same structure as the IRMA API server session result JWTs.
-* `GET /publickey`: returns the public key with which the JWTs output by this server can be verified.
-
-This can be useful if the session result travels along an unsafe or untrusted route from the IRMA server to the requestor. As long as the `irma server` is trusted and its public key is known, the JWT can be verified to ensure that the session result was untampered with since it left the `irma server`.
-
-### TLS
-
-The [IRMA protocol](irma-protocol.md) relies on TLS for encryption of the attributes as they travel along the internet. If your server is connected to the internet and it handles actual attributes (personal data from people), then you ***must*** ensure that the attributes are protected in transit with TLS. In its default configuration (i.e. with [developer mode](irma-app.md#developer-mode) disabled), the IRMA app will refuse to connect to servers not using TLS.
-
-You can enable TLS in the `irma server` with the `tls_cert` and `tls_privkey` options (or the `_file` equivalents), specifying a PEM certificate (chain) and PEM private key. If you use [separate requestor and app endpoints](#http-server-endpoints), additionally use `client_tls_cert` and `client_tls_privkey`.
-
-Alternatively, if your IRMA server is connected to the internet through a reverse proxy then your reverse proxy probably handles TLS for you.
-
-### Email
-
-Users of the server are encouraged to provide an email address with the `email` option, subscribing for notifications about changes in the IRMA software or ecosystem. [More information](email.md). In `production` mode, it is required to either provide an email address or to explicitly out with the `no_email` option.
-
-### Logging and verbosity
-
-The server's verbosity can be increased by two degrees:
-* `-v` flag is given, or `verbosity` option set to `1`: includes `DEBUG` messages. Logs server configuration when starting the server, stack traces of errors, and more.
-* `-vv` flag is given, or `verbosity` option set to `2`: includes `TRACE` messages. Additionally includes dumps of all HTTP traffic from and to the server.
-
-> in its default mode, the server will not log attribute values (personal data). If the verbosity is increased, then attribute values may be logged. You should avoid doing this in production.
-
-The output is [structured](https://github.com/sirupsen/logrus#fields), putting certain recurring values in fields:
-```text
-[2019-02-28T20:51:09+01:00] INFO Session started action=disclosing session=WdypvSs97JTotpfl1Dtd
-```
-Outputting JSON is enabled with the `log-json` option:
-```json
-{"action":"disclosing","level":"info","msg":"Session started","session":"WdypvSs97JTotpfl1Dtd","time":"2019-02-28T20:51:09+01:00"}
-```
-
-## Running as daemon
-
-On most Linux systems, the `irma server` can be made into an automatically started daemon as follows:
-
-1. Write a new systemd unit file to `/etc/systemd/system/irmaserver.service`:
- ```ini
- [Unit]
- Description=IRMA server
- Documentation=https://irma.app/docs/irma-server
- Requires=network.target
-
- [Service]
- Type=simple
- ExecStart=/usr/local/bin/irma server --config=/etc/irmaserver/config.json
- TimeoutStopSec=60
- Restart=always
- RestartSec=1
- StandardOutput=syslog
- StandardError=syslog
- SyslogIdentifier=irma
- User=irmaserver
- Group=irmaserver
-
- [Install]
- WantedBy=multi-user.target
- ```
- Modify the path to `irma` and [your configuration file (or flags or environmental variables)](#configuring) in `ExecStart` as needed, as well as `User` and `Group`.
-2. Start the daemon and schedule it for automatic start on boot by running `systemctl start irmaserver.service && systemctl enable irmaserver.service`.
-
-See `systemctl status irmaserver.service` for the status of the daemon, and `journalctl -u irmaserver.service` for the console output of the IRMA server.
-
-## Design goals
-
-The server was designed with the following goals in mind.
-- Developer and user friendliness
- - Each of the [configuration options](#configuring) can be specified in a configuration file, command line flag, or environmental vars (see `-h`)
- - Default configuration (demo mode) is immediately useful
- - Thorough and configurable logging (`-v`, `-vv`; by default logs exclude attribute values)
- - Partial backwards compatibility with predecessor [`irma_api_server`](https://github.com/privacybydesign/irma_api_server)
- - Small startup time
-- Also available as [Go library](irma-server-lib.md) instead of standalone server
- - Bindings to other programming languages (Python, Ruby) are expected
-
-Being written in [Go](https://golang.org/), this server (in fact, the containing [`irma` binary](irma-cli.md)) additionally automatically has the following properties.
-- Simple to install (one binary, no dependencies, cross platform) and/or compile
-- [Reproducible builds](https://www.gnu.org/software/mes/manual/html_node/Reproducible-Builds.html)
-- [API documentation](https://godoc.org/github.com/privacybydesign/irmago) (generated automatically from `master` branch)
-
-Referring to Go packages (i.e. folders) under [`irmago`](https://github.com/privacybydesign/irmago), the server is structured as follows.
-* [`server/irmaserver`](irma-server-lib.md): Go library implementing the HTTP endpoints for the [IRMA protocol](irma-protocol.md) (in which the IRMA app is the client), and a Go API for requestors to manage sessons. ([Godoc API documentation](https://godoc.org/github.com/privacybydesign/irmago/server/irmaserver))
-* `server/requestorserver`: Go library wrapping `server/irmaserver`, exposing the requestor API as a second HTTP endpoint set under `/session` URLs instead of as Go functions (next to `/irma` for the IRMA app endpoints). ([Godoc API documentation](https://godoc.org/github.com/privacybydesign/irmago/server/requestorserver))
-* `irma`: executuable whose `server` commands wraps `server/requestorserver`.
diff --git a/website/versioned_docs/version-v0.9.0/stateless.md b/website/versioned_docs/version-v0.9.0/stateless.md
deleted file mode 100644
index 9debd1c..0000000
--- a/website/versioned_docs/version-v0.9.0/stateless.md
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: Stateless IRMA server
-id: version-v0.9.0-stateless
-original_id: stateless
----
-
-For each IRMA session the [IRMA server](irma-server.md) needs to keep track of the [session state](irma-protocol.md#the-session-state).
-By default the session state is kept in memory. With version 0.9.0 of the IRMA server it is possible to run the IRMA server in a stateless mode. The session data will then be stored in a Redis datastore. This page explains how the stateless IRMA server works and how to run the IRMA server in stateless mode.
-
-## Overview
-During an IRMA session, the IRMA server acts as a state machine which is described in detail on the [IRMA protocol page](irma-protocol.md). The IRMA session progresses through various states such as `INITIALIZED`, `CONNECTED` and `DONE`. The IRMA server contains logic when to switch from one state into the other. The state itself can be kept in memory or, alternatively, in a Redis data store. Saving the session state in memory requires no extra setup and is currently the default behaviour of the IRMA server. However, the data in memory cannot be shared between several IRMA servers. This means that you cannot scale the IRMA server horizontally when using this in-memory solution. Next to poor scalability, the in-memory solution is problematic when the IRMA server needs to be restarted or - even worse - when the server crashes. In such cases, the in-memory information of all sessions gets irreversibly lost.
-
-With the new feature of running the IRMA server in stateless mode, the session data gets decoupled from the IRMA server, making the server itself stateless. The IRMA server still contains the logic when to switch between states but will retrieve and update the session data from and to a dedicated store. Hence, several IRMA servers can be run in parallel and connect to the same data store. Also, no data is lost when the IRMA server restarts or crashes.
-
-### Use cases
-* Scaling the IRMA server horizontally, i.e. running several IRMA severs in parallel.
-* Preventing data loss when restarting an IRMA server.
-* Preventing data loss in case of IRMA server crashes.
-
-## Running the IRMA server in stateless mode
-### Example
-You can start the IRMA server in stateless mode by setting the `store-type` option to `redis`. Additionally you need to provide a Redis server address and password. For test purposes you can override the need for a password by setting the `redis-allow-empty-password` option to `true`. However, make sure to use a secure Redis password in production. Your Redis data store will contain sensitive data and must be password-protected.
-
-```
-irma server -vv --store-type redis --redis-addr "localhost:6379" --redis-pw "placeholderPassword"
-```
-
-If you want to run several IRMA servers, you can now run them behind a load balancer and connect them to the same Redis instance.
-
-> Currently a simple locking mechanism is implemented. When running several Redis instances in parallel, edge cases may occur. We recommend to use a single Redis instance.
-
-By default the IRMA server connects to Redis with TLS, using the system store of certificate authorities. Alternatively, you can specify the certificate that Redis uses, or the certificate authority with which that certificate is signed, using the `redis-tls-cert` or `redis-tls-cert-file` options. A certificate may be configured in Redis as follows:
-
-```
-requirepass placeholderPassword
-
-# Disable the non-TLS port completely
-port 0
-# Enable TLS on the default Redis port
-tls-port 6379
-
-# X.509 certificate and a private key
-tls-cert-file /path/to/cert.pem
-tls-key-file /path/to/privkey.pem
-
-# Disable TLS client authentication
-tls-auth-clients no
-```
-
-It is also possible to disable TLS altogether for connections to Redis, using the `redis-no-tls` option.
-
-> In production, always using TLS for Redis is recommended. If you disable TLS, be sure to run your Redis server in an internal network protected against unauthorized access.
-
-### Using multiple Redis instances
-Currently the IRMA server does not support Redis clusters or a master/slave mode. You can only connect to one Redis address. This means that the Redis connection is currently a bottleneck and single point of failure. You could use [Redis Enterprise](https://redis.com/redis-enterprise-cloud/overview/) which will let you connect with one outward-facing Redis connection and will provide you with an underlying failover mechanism.
-
-Please get in touch with us, should you wish the IRMA server to support multiple Redis instances.
-
-### Server-sent events
-Currently the IRMA server does not support a stateless mode in combination with server-sent events. Please contact us, should you be in need of this combination.
\ No newline at end of file
diff --git a/website/versioned_sidebars/version-v0.11.0-sidebars.json b/website/versioned_sidebars/version-v0.11.0-sidebars.json
deleted file mode 100644
index f2e4a43..0000000
--- a/website/versioned_sidebars/version-v0.11.0-sidebars.json
+++ /dev/null
@@ -1,39 +0,0 @@
-{
- "version-v0.11.0-docs": {
- "Intro": [
- "version-v0.11.0-what-is-irma",
- "version-v0.11.0-getting-started"
- ],
- "New": [
- "version-v0.11.0-stateless",
- "version-v0.11.0-revocation",
- "version-v0.11.0-randomblind",
- "version-v0.11.0-chained-sessions"
- ],
- "Guides": [
- "version-v0.11.0-irma-cli",
- "version-v0.11.0-irma-server",
- "version-v0.11.0-irma-server-lib",
- "version-v0.11.0-irma-backend",
- "version-v0.11.0-irma-frontend",
- "version-v0.11.0-schemes",
- "version-v0.11.0-issuer",
- "version-v0.11.0-session-requests",
- "version-v0.11.0-email",
- "version-v0.11.0-irma-app",
- "version-v0.11.0-irmajs"
- ],
- "API reference": [
- "version-v0.11.0-api-go",
- "version-v0.11.0-api-irma-server",
- "version-v0.11.0-api-irma-frontend",
- "version-v0.11.0-api-irmajs"
- ],
- "Documentation": [
- "version-v0.11.0-overview",
- "version-v0.11.0-irma-protocol",
- "version-v0.11.0-zkp",
- "version-v0.11.0-keyshare-protocol"
- ]
- }
-}
diff --git a/website/versioned_sidebars/version-v0.12.0-sidebars.json b/website/versioned_sidebars/version-v0.12.0-sidebars.json
deleted file mode 100644
index 0dbae5d..0000000
--- a/website/versioned_sidebars/version-v0.12.0-sidebars.json
+++ /dev/null
@@ -1,39 +0,0 @@
-{
- "version-v0.12.0-docs": {
- "Intro": [
- "version-v0.12.0-what-is-irma",
- "version-v0.12.0-getting-started"
- ],
- "New": [
- "version-v0.12.0-stateless",
- "version-v0.12.0-revocation",
- "version-v0.12.0-randomblind",
- "version-v0.12.0-chained-sessions"
- ],
- "Guides": [
- "version-v0.12.0-irma-cli",
- "version-v0.12.0-irma-server",
- "version-v0.12.0-irma-server-lib",
- "version-v0.12.0-irma-backend",
- "version-v0.12.0-irma-frontend",
- "version-v0.12.0-schemes",
- "version-v0.12.0-issuer",
- "version-v0.12.0-session-requests",
- "version-v0.12.0-email",
- "version-v0.12.0-irma-app",
- "version-v0.12.0-irmajs"
- ],
- "API reference": [
- "version-v0.12.0-api-go",
- "version-v0.12.0-api-irma-server",
- "version-v0.12.0-api-irma-frontend",
- "version-v0.12.0-api-irmajs"
- ],
- "Documentation": [
- "version-v0.12.0-overview",
- "version-v0.12.0-irma-protocol",
- "version-v0.12.0-zkp",
- "version-v0.12.0-keyshare-protocol"
- ]
- }
-}
diff --git a/website/versioned_sidebars/version-v0.13.0-sidebars.json b/website/versioned_sidebars/version-v0.13.0-sidebars.json
deleted file mode 100644
index ca98085..0000000
--- a/website/versioned_sidebars/version-v0.13.0-sidebars.json
+++ /dev/null
@@ -1,39 +0,0 @@
-{
- "version-v0.13.0-docs": {
- "Intro": [
- "version-v0.13.0-what-is-irma",
- "version-v0.13.0-getting-started"
- ],
- "New": [
- "version-v0.13.0-stateless",
- "version-v0.13.0-revocation",
- "version-v0.13.0-randomblind",
- "version-v0.13.0-chained-sessions"
- ],
- "Guides": [
- "version-v0.13.0-irma-cli",
- "version-v0.13.0-irma-server",
- "version-v0.13.0-irma-server-lib",
- "version-v0.13.0-irma-backend",
- "version-v0.13.0-irma-frontend",
- "version-v0.13.0-schemes",
- "version-v0.13.0-issuer",
- "version-v0.13.0-session-requests",
- "version-v0.13.0-email",
- "version-v0.13.0-yivi-app",
- "version-v0.13.0-irmajs"
- ],
- "API reference": [
- "version-v0.13.0-api-go",
- "version-v0.13.0-api-irma-server",
- "version-v0.13.0-api-irma-frontend",
- "version-v0.13.0-api-irmajs"
- ],
- "Documentation": [
- "version-v0.13.0-overview",
- "version-v0.13.0-irma-protocol",
- "version-v0.13.0-zkp",
- "version-v0.13.0-keyshare-protocol"
- ]
- }
-}
diff --git a/website/versioned_sidebars/version-v0.14.2-sidebars.json b/website/versioned_sidebars/version-v0.14.2-sidebars.json
deleted file mode 100644
index 833e2eb..0000000
--- a/website/versioned_sidebars/version-v0.14.2-sidebars.json
+++ /dev/null
@@ -1,37 +0,0 @@
-{
- "version-v0.14.2-docs": {
- "Intro": [
- "version-v0.14.2-what-is-irma",
- "version-v0.14.2-getting-started"
- ],
- "New": [
- "version-v0.14.2-stateless",
- "version-v0.14.2-revocation",
- "version-v0.14.2-randomblind",
- "version-v0.14.2-chained-sessions"
- ],
- "Guides": [
- "version-v0.14.2-irma-cli",
- "version-v0.14.2-irma-server",
- "version-v0.14.2-irma-server-lib",
- "version-v0.14.2-irma-backend",
- "version-v0.14.2-yivi-frontend",
- "version-v0.14.2-schemes",
- "version-v0.14.2-issuer",
- "version-v0.14.2-session-requests",
- "version-v0.14.2-email",
- "version-v0.14.2-yivi-app"
- ],
- "API reference": [
- "version-v0.14.2-api-go",
- "version-v0.14.2-api-irma-server",
- "version-v0.14.2-api-yivi-frontend"
- ],
- "Documentation": [
- "version-v0.14.2-overview",
- "version-v0.14.2-irma-protocol",
- "version-v0.14.2-zkp",
- "version-v0.14.2-keyshare-protocol"
- ]
- }
-}
diff --git a/website/versioned_sidebars/version-v0.2.0-sidebars.json b/website/versioned_sidebars/version-v0.2.0-sidebars.json
deleted file mode 100644
index adda0e4..0000000
--- a/website/versioned_sidebars/version-v0.2.0-sidebars.json
+++ /dev/null
@@ -1,28 +0,0 @@
-{
- "version-v0.2.0-docs": {
- "Intro": [
- "version-v0.2.0-what-is-irma",
- "version-v0.2.0-getting-started",
- "version-v0.2.0-workshop"
- ],
- "Guides": [
- "version-v0.2.0-irma-cli",
- "version-v0.2.0-irma-server",
- "version-v0.2.0-irma-server-lib",
- "version-v0.2.0-irmajs",
- "version-v0.2.0-schemes",
- "version-v0.2.0-session-requests",
- "version-v0.2.0-email"
- ],
- "API reference": [
- "version-v0.2.0-api-go",
- "version-v0.2.0-api-irmajs",
- "version-v0.2.0-api-irma-server"
- ],
- "Documentation": [
- "version-v0.2.0-overview",
- "version-v0.2.0-zkp",
- "version-v0.2.0-keyshare-protocol"
- ]
- }
-}
diff --git a/website/versioned_sidebars/version-v0.3.0-sidebars.json b/website/versioned_sidebars/version-v0.3.0-sidebars.json
deleted file mode 100644
index 294518b..0000000
--- a/website/versioned_sidebars/version-v0.3.0-sidebars.json
+++ /dev/null
@@ -1,30 +0,0 @@
-{
- "version-v0.3.0-docs": {
- "Intro": [
- "version-v0.3.0-what-is-irma",
- "version-v0.3.0-getting-started"
- ],
- "New": [
- "version-v0.3.0-condiscon"
- ],
- "Guides": [
- "version-v0.3.0-irma-cli",
- "version-v0.3.0-irma-server",
- "version-v0.3.0-irma-server-lib",
- "version-v0.3.0-irmajs",
- "version-v0.3.0-schemes",
- "version-v0.3.0-session-requests",
- "version-v0.3.0-email"
- ],
- "API reference": [
- "version-v0.3.0-api-go",
- "version-v0.3.0-api-irmajs",
- "version-v0.3.0-api-irma-server"
- ],
- "Documentation": [
- "version-v0.3.0-overview",
- "version-v0.3.0-zkp",
- "version-v0.3.0-keyshare-protocol"
- ]
- }
-}
diff --git a/website/versioned_sidebars/version-v0.4.1-sidebars.json b/website/versioned_sidebars/version-v0.4.1-sidebars.json
deleted file mode 100644
index 1d45f8f..0000000
--- a/website/versioned_sidebars/version-v0.4.1-sidebars.json
+++ /dev/null
@@ -1,33 +0,0 @@
-{
- "version-v0.4.1-docs": {
- "Intro": [
- "version-v0.4.1-what-is-irma",
- "version-v0.4.1-getting-started"
- ],
- "New": [
- "version-v0.4.1-revocation"
- ],
- "Guides": [
- "version-v0.4.1-irma-cli",
- "version-v0.4.1-irma-server",
- "version-v0.4.1-irma-server-lib",
- "version-v0.4.1-irma-backend",
- "version-v0.4.1-irma-frontend",
- "version-v0.4.1-irmajs",
- "version-v0.4.1-schemes",
- "version-v0.4.1-session-requests",
- "version-v0.4.1-email"
- ],
- "API reference": [
- "version-v0.4.1-api-go",
- "version-v0.4.1-api-irmajs",
- "version-v0.4.1-api-irma-server",
- "version-v0.4.1-api-irma-frontend"
- ],
- "Documentation": [
- "version-v0.4.1-overview",
- "version-v0.4.1-zkp",
- "version-v0.4.1-keyshare-protocol"
- ]
- }
-}
diff --git a/website/versioned_sidebars/version-v0.5.0-sidebars.json b/website/versioned_sidebars/version-v0.5.0-sidebars.json
deleted file mode 100644
index a9d45ff..0000000
--- a/website/versioned_sidebars/version-v0.5.0-sidebars.json
+++ /dev/null
@@ -1,35 +0,0 @@
-{
- "version-v0.5.0-docs": {
- "Intro": [
- "version-v0.5.0-what-is-irma",
- "version-v0.5.0-getting-started"
- ],
- "New": [
- "version-v0.5.0-revocation"
- ],
- "Guides": [
- "version-v0.5.0-irma-cli",
- "version-v0.5.0-irma-server",
- "version-v0.5.0-irma-server-lib",
- "version-v0.5.0-irma-backend",
- "version-v0.5.0-irma-frontend",
- "version-v0.5.0-schemes",
- "version-v0.5.0-issuer",
- "version-v0.5.0-session-requests",
- "version-v0.5.0-email",
- "version-v0.5.0-irma-app",
- "version-v0.5.0-irmajs"
- ],
- "API reference": [
- "version-v0.5.0-api-go",
- "version-v0.5.0-api-irma-server",
- "version-v0.5.0-api-irma-frontend",
- "version-v0.5.0-api-irmajs"
- ],
- "Documentation": [
- "version-v0.5.0-overview",
- "version-v0.5.0-zkp",
- "version-v0.5.0-keyshare-protocol"
- ]
- }
-}
diff --git a/website/versioned_sidebars/version-v0.6.1-sidebars.json b/website/versioned_sidebars/version-v0.6.1-sidebars.json
deleted file mode 100644
index 1244680..0000000
--- a/website/versioned_sidebars/version-v0.6.1-sidebars.json
+++ /dev/null
@@ -1,36 +0,0 @@
-{
- "version-v0.6.1-docs": {
- "Intro": [
- "version-v0.6.1-what-is-irma",
- "version-v0.6.1-getting-started"
- ],
- "New": [
- "version-v0.6.1-revocation",
- "version-v0.6.1-randomblind"
- ],
- "Guides": [
- "version-v0.6.1-irma-cli",
- "version-v0.6.1-irma-server",
- "version-v0.6.1-irma-server-lib",
- "version-v0.6.1-irma-backend",
- "version-v0.6.1-irma-frontend",
- "version-v0.6.1-schemes",
- "version-v0.6.1-issuer",
- "version-v0.6.1-session-requests",
- "version-v0.6.1-email",
- "version-v0.6.1-irma-app",
- "version-v0.6.1-irmajs"
- ],
- "API reference": [
- "version-v0.6.1-api-go",
- "version-v0.6.1-api-irma-server",
- "version-v0.6.1-api-irma-frontend",
- "version-v0.6.1-api-irmajs"
- ],
- "Documentation": [
- "version-v0.6.1-overview",
- "version-v0.6.1-zkp",
- "version-v0.6.1-keyshare-protocol"
- ]
- }
-}
diff --git a/website/versioned_sidebars/version-v0.8.0-sidebars.json b/website/versioned_sidebars/version-v0.8.0-sidebars.json
deleted file mode 100644
index 2ea6032..0000000
--- a/website/versioned_sidebars/version-v0.8.0-sidebars.json
+++ /dev/null
@@ -1,38 +0,0 @@
-{
- "version-v0.8.0-docs": {
- "Intro": [
- "version-v0.8.0-what-is-irma",
- "version-v0.8.0-getting-started"
- ],
- "New": [
- "version-v0.8.0-revocation",
- "version-v0.8.0-randomblind",
- "version-v0.8.0-chained-sessions"
- ],
- "Guides": [
- "version-v0.8.0-irma-cli",
- "version-v0.8.0-irma-server",
- "version-v0.8.0-irma-server-lib",
- "version-v0.8.0-irma-backend",
- "version-v0.8.0-irma-frontend",
- "version-v0.8.0-schemes",
- "version-v0.8.0-issuer",
- "version-v0.8.0-session-requests",
- "version-v0.8.0-email",
- "version-v0.8.0-irma-app",
- "version-v0.8.0-irmajs"
- ],
- "API reference": [
- "version-v0.8.0-api-go",
- "version-v0.8.0-api-irma-server",
- "version-v0.8.0-api-irma-frontend",
- "version-v0.8.0-api-irmajs"
- ],
- "Documentation": [
- "version-v0.8.0-overview",
- "version-v0.8.0-irma-protocol",
- "version-v0.8.0-zkp",
- "version-v0.8.0-keyshare-protocol"
- ]
- }
-}
diff --git a/website/versioned_sidebars/version-v0.9.0-sidebars.json b/website/versioned_sidebars/version-v0.9.0-sidebars.json
deleted file mode 100644
index bd795e0..0000000
--- a/website/versioned_sidebars/version-v0.9.0-sidebars.json
+++ /dev/null
@@ -1,39 +0,0 @@
-{
- "version-v0.9.0-docs": {
- "Intro": [
- "version-v0.9.0-what-is-irma",
- "version-v0.9.0-getting-started"
- ],
- "New": [
- "version-v0.9.0-stateless",
- "version-v0.9.0-revocation",
- "version-v0.9.0-randomblind",
- "version-v0.9.0-chained-sessions"
- ],
- "Guides": [
- "version-v0.9.0-irma-cli",
- "version-v0.9.0-irma-server",
- "version-v0.9.0-irma-server-lib",
- "version-v0.9.0-irma-backend",
- "version-v0.9.0-irma-frontend",
- "version-v0.9.0-schemes",
- "version-v0.9.0-issuer",
- "version-v0.9.0-session-requests",
- "version-v0.9.0-email",
- "version-v0.9.0-irma-app",
- "version-v0.9.0-irmajs"
- ],
- "API reference": [
- "version-v0.9.0-api-go",
- "version-v0.9.0-api-irma-server",
- "version-v0.9.0-api-irma-frontend",
- "version-v0.9.0-api-irmajs"
- ],
- "Documentation": [
- "version-v0.9.0-overview",
- "version-v0.9.0-irma-protocol",
- "version-v0.9.0-zkp",
- "version-v0.9.0-keyshare-protocol"
- ]
- }
-}
diff --git a/website/versions.json b/website/versions.json
deleted file mode 100644
index fc4d3a5..0000000
--- a/website/versions.json
+++ /dev/null
@@ -1,18 +0,0 @@
-[
- "v0.15.0",
- "v0.14.2",
- "v0.14.0",
- "v0.13.0",
- "v0.12.0",
- "v0.11.0",
- "v0.10.0",
- "v0.9.0",
- "v0.8.0",
- "v0.7.0",
- "v0.6.1",
- "v0.5.0",
- "v0.4.1",
- "v0.3.1",
- "v0.3.0",
- "v0.2.0"
-]
diff --git a/website/yarn.lock b/website/yarn.lock
deleted file mode 100644
index a490d13..0000000
--- a/website/yarn.lock
+++ /dev/null
@@ -1,6832 +0,0 @@
-# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
-# yarn lockfile v1
-
-
-"@ampproject/remapping@^2.1.0":
- version "2.2.0"
- resolved "https://registry.yarnpkg.com/@ampproject/remapping/-/remapping-2.2.0.tgz#56c133824780de3174aed5ab6834f3026790154d"
- integrity sha512-qRmjj8nj9qmLTQXXmaR1cck3UXSRMPrbsLJAasZpF+t3riI71BXed5ebIOYwQntykeZuhjsdweEc9BxH5Jc26w==
- dependencies:
- "@jridgewell/gen-mapping" "^0.1.0"
- "@jridgewell/trace-mapping" "^0.3.9"
-
-"@babel/code-frame@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/code-frame/-/code-frame-7.18.6.tgz#3b25d38c89600baa2dcc219edfa88a74eb2c427a"
- integrity sha512-TDCmlK5eOvH+eH7cdAFlNXeVJqWIQ7gW9tY1GJIpUtFb6CmjVyq2VM3u71bOyR8CRihcCgMUYoDNyLXao3+70Q==
- dependencies:
- "@babel/highlight" "^7.18.6"
-
-"@babel/compat-data@^7.17.7", "@babel/compat-data@^7.20.0", "@babel/compat-data@^7.20.1":
- version "7.20.1"
- resolved "https://registry.yarnpkg.com/@babel/compat-data/-/compat-data-7.20.1.tgz#f2e6ef7790d8c8dbf03d379502dcc246dcce0b30"
- integrity sha512-EWZ4mE2diW3QALKvDMiXnbZpRvlj+nayZ112nK93SnhqOtpdsbVD4W+2tEoT3YNBAG9RBR0ISY758ZkOgsn6pQ==
-
-"@babel/core@^7.0.0":
- version "7.20.2"
- resolved "https://registry.yarnpkg.com/@babel/core/-/core-7.20.2.tgz#8dc9b1620a673f92d3624bd926dc49a52cf25b92"
- integrity sha512-w7DbG8DtMrJcFOi4VrLm+8QM4az8Mo+PuLBKLp2zrYRCow8W/f9xiXm5sN53C8HksCyDQwCKha9JiDoIyPjT2g==
- dependencies:
- "@ampproject/remapping" "^2.1.0"
- "@babel/code-frame" "^7.18.6"
- "@babel/generator" "^7.20.2"
- "@babel/helper-compilation-targets" "^7.20.0"
- "@babel/helper-module-transforms" "^7.20.2"
- "@babel/helpers" "^7.20.1"
- "@babel/parser" "^7.20.2"
- "@babel/template" "^7.18.10"
- "@babel/traverse" "^7.20.1"
- "@babel/types" "^7.20.2"
- convert-source-map "^1.7.0"
- debug "^4.1.0"
- gensync "^1.0.0-beta.2"
- json5 "^2.2.1"
- semver "^6.3.0"
-
-"@babel/generator@^7.20.1", "@babel/generator@^7.20.2":
- version "7.20.4"
- resolved "https://registry.yarnpkg.com/@babel/generator/-/generator-7.20.4.tgz#4d9f8f0c30be75fd90a0562099a26e5839602ab8"
- integrity sha512-luCf7yk/cm7yab6CAW1aiFnmEfBJplb/JojV56MYEK7ziWfGmFlTfmL9Ehwfy4gFhbjBfWO1wj7/TuSbVNEEtA==
- dependencies:
- "@babel/types" "^7.20.2"
- "@jridgewell/gen-mapping" "^0.3.2"
- jsesc "^2.5.1"
-
-"@babel/helper-annotate-as-pure@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/helper-annotate-as-pure/-/helper-annotate-as-pure-7.18.6.tgz#eaa49f6f80d5a33f9a5dd2276e6d6e451be0a6bb"
- integrity sha512-duORpUiYrEpzKIop6iNbjnwKLAKnJ47csTyRACyEmWj0QdUrm5aqNJGHSSEQSUAvNW0ojX0dOmK9dZduvkfeXA==
- dependencies:
- "@babel/types" "^7.18.6"
-
-"@babel/helper-builder-binary-assignment-operator-visitor@^7.18.6":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/helper-builder-binary-assignment-operator-visitor/-/helper-builder-binary-assignment-operator-visitor-7.18.9.tgz#acd4edfd7a566d1d51ea975dff38fd52906981bb"
- integrity sha512-yFQ0YCHoIqarl8BCRwBL8ulYUaZpz3bNsA7oFepAzee+8/+ImtADXNOmO5vJvsPff3qi+hvpkY/NYBTrBQgdNw==
- dependencies:
- "@babel/helper-explode-assignable-expression" "^7.18.6"
- "@babel/types" "^7.18.9"
-
-"@babel/helper-compilation-targets@^7.17.7", "@babel/helper-compilation-targets@^7.18.9", "@babel/helper-compilation-targets@^7.20.0":
- version "7.20.0"
- resolved "https://registry.yarnpkg.com/@babel/helper-compilation-targets/-/helper-compilation-targets-7.20.0.tgz#6bf5374d424e1b3922822f1d9bdaa43b1a139d0a"
- integrity sha512-0jp//vDGp9e8hZzBc6N/KwA5ZK3Wsm/pfm4CrY7vzegkVxc65SgSn6wYOnwHe9Js9HRQ1YTCKLGPzDtaS3RoLQ==
- dependencies:
- "@babel/compat-data" "^7.20.0"
- "@babel/helper-validator-option" "^7.18.6"
- browserslist "^4.21.3"
- semver "^6.3.0"
-
-"@babel/helper-create-class-features-plugin@^7.18.6":
- version "7.20.2"
- resolved "https://registry.yarnpkg.com/@babel/helper-create-class-features-plugin/-/helper-create-class-features-plugin-7.20.2.tgz#3c08a5b5417c7f07b5cf3dfb6dc79cbec682e8c2"
- integrity sha512-k22GoYRAHPYr9I+Gvy2ZQlAe5mGy8BqWst2wRt8cwIufWTxrsVshhIBvYNqC80N0GSFWTsqRVexOtfzlgOEDvA==
- dependencies:
- "@babel/helper-annotate-as-pure" "^7.18.6"
- "@babel/helper-environment-visitor" "^7.18.9"
- "@babel/helper-function-name" "^7.19.0"
- "@babel/helper-member-expression-to-functions" "^7.18.9"
- "@babel/helper-optimise-call-expression" "^7.18.6"
- "@babel/helper-replace-supers" "^7.19.1"
- "@babel/helper-split-export-declaration" "^7.18.6"
-
-"@babel/helper-create-regexp-features-plugin@^7.18.6", "@babel/helper-create-regexp-features-plugin@^7.19.0":
- version "7.19.0"
- resolved "https://registry.yarnpkg.com/@babel/helper-create-regexp-features-plugin/-/helper-create-regexp-features-plugin-7.19.0.tgz#7976aca61c0984202baca73d84e2337a5424a41b"
- integrity sha512-htnV+mHX32DF81amCDrwIDr8nrp1PTm+3wfBN9/v8QJOLEioOCOG7qNyq0nHeFiWbT3Eb7gsPwEmV64UCQ1jzw==
- dependencies:
- "@babel/helper-annotate-as-pure" "^7.18.6"
- regexpu-core "^5.1.0"
-
-"@babel/helper-define-polyfill-provider@^0.3.3":
- version "0.3.3"
- resolved "https://registry.yarnpkg.com/@babel/helper-define-polyfill-provider/-/helper-define-polyfill-provider-0.3.3.tgz#8612e55be5d51f0cd1f36b4a5a83924e89884b7a"
- integrity sha512-z5aQKU4IzbqCC1XH0nAqfsFLMVSo22SBKUc0BxGrLkolTdPTructy0ToNnlO2zA4j9Q/7pjMZf0DSY+DSTYzww==
- dependencies:
- "@babel/helper-compilation-targets" "^7.17.7"
- "@babel/helper-plugin-utils" "^7.16.7"
- debug "^4.1.1"
- lodash.debounce "^4.0.8"
- resolve "^1.14.2"
- semver "^6.1.2"
-
-"@babel/helper-environment-visitor@^7.18.9":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/helper-environment-visitor/-/helper-environment-visitor-7.18.9.tgz#0c0cee9b35d2ca190478756865bb3528422f51be"
- integrity sha512-3r/aACDJ3fhQ/EVgFy0hpj8oHyHpQc+LPtJoY9SzTThAsStm4Ptegq92vqKoE3vD706ZVFWITnMnxucw+S9Ipg==
-
-"@babel/helper-explode-assignable-expression@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/helper-explode-assignable-expression/-/helper-explode-assignable-expression-7.18.6.tgz#41f8228ef0a6f1a036b8dfdfec7ce94f9a6bc096"
- integrity sha512-eyAYAsQmB80jNfg4baAtLeWAQHfHFiR483rzFK+BhETlGZaQC9bsfrugfXDCbRHLQbIA7U5NxhhOxN7p/dWIcg==
- dependencies:
- "@babel/types" "^7.18.6"
-
-"@babel/helper-function-name@^7.18.9", "@babel/helper-function-name@^7.19.0":
- version "7.19.0"
- resolved "https://registry.yarnpkg.com/@babel/helper-function-name/-/helper-function-name-7.19.0.tgz#941574ed5390682e872e52d3f38ce9d1bef4648c"
- integrity sha512-WAwHBINyrpqywkUH0nTnNgI5ina5TFn85HKS0pbPDfxFfhyR/aNQEn4hGi1P1JyT//I0t4OgXUlofzWILRvS5w==
- dependencies:
- "@babel/template" "^7.18.10"
- "@babel/types" "^7.19.0"
-
-"@babel/helper-hoist-variables@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/helper-hoist-variables/-/helper-hoist-variables-7.18.6.tgz#d4d2c8fb4baeaa5c68b99cc8245c56554f926678"
- integrity sha512-UlJQPkFqFULIcyW5sbzgbkxn2FKRgwWiRexcuaR8RNJRy8+LLveqPjwZV/bwrLZCN0eUHD/x8D0heK1ozuoo6Q==
- dependencies:
- "@babel/types" "^7.18.6"
-
-"@babel/helper-member-expression-to-functions@^7.18.9":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/helper-member-expression-to-functions/-/helper-member-expression-to-functions-7.18.9.tgz#1531661e8375af843ad37ac692c132841e2fd815"
- integrity sha512-RxifAh2ZoVU67PyKIO4AMi1wTenGfMR/O/ae0CCRqwgBAt5v7xjdtRw7UoSbsreKrQn5t7r89eruK/9JjYHuDg==
- dependencies:
- "@babel/types" "^7.18.9"
-
-"@babel/helper-module-imports@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/helper-module-imports/-/helper-module-imports-7.18.6.tgz#1e3ebdbbd08aad1437b428c50204db13c5a3ca6e"
- integrity sha512-0NFvs3VkuSYbFi1x2Vd6tKrywq+z/cLeYC/RJNFrIX/30Bf5aiGYbtvGXolEktzJH8o5E5KJ3tT+nkxuuZFVlA==
- dependencies:
- "@babel/types" "^7.18.6"
-
-"@babel/helper-module-transforms@^7.18.6", "@babel/helper-module-transforms@^7.19.6", "@babel/helper-module-transforms@^7.20.2":
- version "7.20.2"
- resolved "https://registry.yarnpkg.com/@babel/helper-module-transforms/-/helper-module-transforms-7.20.2.tgz#ac53da669501edd37e658602a21ba14c08748712"
- integrity sha512-zvBKyJXRbmK07XhMuujYoJ48B5yvvmM6+wcpv6Ivj4Yg6qO7NOZOSnvZN9CRl1zz1Z4cKf8YejmCMh8clOoOeA==
- dependencies:
- "@babel/helper-environment-visitor" "^7.18.9"
- "@babel/helper-module-imports" "^7.18.6"
- "@babel/helper-simple-access" "^7.20.2"
- "@babel/helper-split-export-declaration" "^7.18.6"
- "@babel/helper-validator-identifier" "^7.19.1"
- "@babel/template" "^7.18.10"
- "@babel/traverse" "^7.20.1"
- "@babel/types" "^7.20.2"
-
-"@babel/helper-optimise-call-expression@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/helper-optimise-call-expression/-/helper-optimise-call-expression-7.18.6.tgz#9369aa943ee7da47edab2cb4e838acf09d290ffe"
- integrity sha512-HP59oD9/fEHQkdcbgFCnbmgH5vIQTJbxh2yf+CdM89/glUNnuzr87Q8GIjGEnOktTROemO0Pe0iPAYbqZuOUiA==
- dependencies:
- "@babel/types" "^7.18.6"
-
-"@babel/helper-plugin-utils@^7.0.0", "@babel/helper-plugin-utils@^7.10.4", "@babel/helper-plugin-utils@^7.12.13", "@babel/helper-plugin-utils@^7.14.5", "@babel/helper-plugin-utils@^7.16.7", "@babel/helper-plugin-utils@^7.18.6", "@babel/helper-plugin-utils@^7.18.9", "@babel/helper-plugin-utils@^7.19.0", "@babel/helper-plugin-utils@^7.20.2", "@babel/helper-plugin-utils@^7.8.0", "@babel/helper-plugin-utils@^7.8.3":
- version "7.20.2"
- resolved "https://registry.yarnpkg.com/@babel/helper-plugin-utils/-/helper-plugin-utils-7.20.2.tgz#d1b9000752b18d0877cff85a5c376ce5c3121629"
- integrity sha512-8RvlJG2mj4huQ4pZ+rU9lqKi9ZKiRmuvGuM2HlWmkmgOhbs6zEAw6IEiJ5cQqGbDzGZOhwuOQNtZMi/ENLjZoQ==
-
-"@babel/helper-remap-async-to-generator@^7.18.6", "@babel/helper-remap-async-to-generator@^7.18.9":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/helper-remap-async-to-generator/-/helper-remap-async-to-generator-7.18.9.tgz#997458a0e3357080e54e1d79ec347f8a8cd28519"
- integrity sha512-dI7q50YKd8BAv3VEfgg7PS7yD3Rtbi2J1XMXaalXO0W0164hYLnh8zpjRS0mte9MfVp/tltvr/cfdXPvJr1opA==
- dependencies:
- "@babel/helper-annotate-as-pure" "^7.18.6"
- "@babel/helper-environment-visitor" "^7.18.9"
- "@babel/helper-wrap-function" "^7.18.9"
- "@babel/types" "^7.18.9"
-
-"@babel/helper-replace-supers@^7.18.6", "@babel/helper-replace-supers@^7.19.1":
- version "7.19.1"
- resolved "https://registry.yarnpkg.com/@babel/helper-replace-supers/-/helper-replace-supers-7.19.1.tgz#e1592a9b4b368aa6bdb8784a711e0bcbf0612b78"
- integrity sha512-T7ahH7wV0Hfs46SFh5Jz3s0B6+o8g3c+7TMxu7xKfmHikg7EAZ3I2Qk9LFhjxXq8sL7UkP5JflezNwoZa8WvWw==
- dependencies:
- "@babel/helper-environment-visitor" "^7.18.9"
- "@babel/helper-member-expression-to-functions" "^7.18.9"
- "@babel/helper-optimise-call-expression" "^7.18.6"
- "@babel/traverse" "^7.19.1"
- "@babel/types" "^7.19.0"
-
-"@babel/helper-simple-access@^7.19.4", "@babel/helper-simple-access@^7.20.2":
- version "7.20.2"
- resolved "https://registry.yarnpkg.com/@babel/helper-simple-access/-/helper-simple-access-7.20.2.tgz#0ab452687fe0c2cfb1e2b9e0015de07fc2d62dd9"
- integrity sha512-+0woI/WPq59IrqDYbVGfshjT5Dmk/nnbdpcF8SnMhhXObpTq2KNBdLFRFrkVdbDOyUmHBCxzm5FHV1rACIkIbA==
- dependencies:
- "@babel/types" "^7.20.2"
-
-"@babel/helper-skip-transparent-expression-wrappers@^7.18.9":
- version "7.20.0"
- resolved "https://registry.yarnpkg.com/@babel/helper-skip-transparent-expression-wrappers/-/helper-skip-transparent-expression-wrappers-7.20.0.tgz#fbe4c52f60518cab8140d77101f0e63a8a230684"
- integrity sha512-5y1JYeNKfvnT8sZcK9DVRtpTbGiomYIHviSP3OQWmDPU3DeH4a1ZlT/N2lyQ5P8egjcRaT/Y9aNqUxK0WsnIIg==
- dependencies:
- "@babel/types" "^7.20.0"
-
-"@babel/helper-split-export-declaration@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/helper-split-export-declaration/-/helper-split-export-declaration-7.18.6.tgz#7367949bc75b20c6d5a5d4a97bba2824ae8ef075"
- integrity sha512-bde1etTx6ZyTmobl9LLMMQsaizFVZrquTEHOqKeQESMKo4PlObf+8+JA25ZsIpZhT/WEd39+vOdLXAFG/nELpA==
- dependencies:
- "@babel/types" "^7.18.6"
-
-"@babel/helper-string-parser@^7.19.4":
- version "7.19.4"
- resolved "https://registry.yarnpkg.com/@babel/helper-string-parser/-/helper-string-parser-7.19.4.tgz#38d3acb654b4701a9b77fb0615a96f775c3a9e63"
- integrity sha512-nHtDoQcuqFmwYNYPz3Rah5ph2p8PFeFCsZk9A/48dPc/rGocJ5J3hAAZ7pb76VWX3fZKu+uEr/FhH5jLx7umrw==
-
-"@babel/helper-validator-identifier@^7.18.6", "@babel/helper-validator-identifier@^7.19.1":
- version "7.19.1"
- resolved "https://registry.yarnpkg.com/@babel/helper-validator-identifier/-/helper-validator-identifier-7.19.1.tgz#7eea834cf32901ffdc1a7ee555e2f9c27e249ca2"
- integrity sha512-awrNfaMtnHUr653GgGEs++LlAvW6w+DcPrOliSMXWCKo597CwL5Acf/wWdNkf/tfEQE3mjkeD1YOVZOUV/od1w==
-
-"@babel/helper-validator-option@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/helper-validator-option/-/helper-validator-option-7.18.6.tgz#bf0d2b5a509b1f336099e4ff36e1a63aa5db4db8"
- integrity sha512-XO7gESt5ouv/LRJdrVjkShckw6STTaB7l9BrpBaAHDeF5YZT+01PCwmR0SJHnkW6i8OwW/EVWRShfi4j2x+KQw==
-
-"@babel/helper-wrap-function@^7.18.9":
- version "7.19.0"
- resolved "https://registry.yarnpkg.com/@babel/helper-wrap-function/-/helper-wrap-function-7.19.0.tgz#89f18335cff1152373222f76a4b37799636ae8b1"
- integrity sha512-txX8aN8CZyYGTwcLhlk87KRqncAzhh5TpQamZUa0/u3an36NtDpUP6bQgBCBcLeBs09R/OwQu3OjK0k/HwfNDg==
- dependencies:
- "@babel/helper-function-name" "^7.19.0"
- "@babel/template" "^7.18.10"
- "@babel/traverse" "^7.19.0"
- "@babel/types" "^7.19.0"
-
-"@babel/helpers@^7.20.1":
- version "7.20.1"
- resolved "https://registry.yarnpkg.com/@babel/helpers/-/helpers-7.20.1.tgz#2ab7a0fcb0a03b5bf76629196ed63c2d7311f4c9"
- integrity sha512-J77mUVaDTUJFZ5BpP6mMn6OIl3rEWymk2ZxDBQJUG3P+PbmyMcF3bYWvz0ma69Af1oobDqT/iAsvzhB58xhQUg==
- dependencies:
- "@babel/template" "^7.18.10"
- "@babel/traverse" "^7.20.1"
- "@babel/types" "^7.20.0"
-
-"@babel/highlight@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/highlight/-/highlight-7.18.6.tgz#81158601e93e2563795adcbfbdf5d64be3f2ecdf"
- integrity sha512-u7stbOuYjaPezCuLj29hNW1v64M2Md2qupEKP1fHc7WdOA3DgLh37suiSrZYY7haUB7iBeQZ9P1uiRF359do3g==
- dependencies:
- "@babel/helper-validator-identifier" "^7.18.6"
- chalk "^2.0.0"
- js-tokens "^4.0.0"
-
-"@babel/parser@^7.18.10", "@babel/parser@^7.20.1", "@babel/parser@^7.20.2":
- version "7.20.3"
- resolved "https://registry.yarnpkg.com/@babel/parser/-/parser-7.20.3.tgz#5358cf62e380cf69efcb87a7bb922ff88bfac6e2"
- integrity sha512-OP/s5a94frIPXwjzEcv5S/tpQfc6XhxYUnmWpgdqMWGgYCuErA3SzozaRAMQgSZWKeTJxht9aWAkUY+0UzvOFg==
-
-"@babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression/-/plugin-bugfix-safari-id-destructuring-collision-in-function-expression-7.18.6.tgz#da5b8f9a580acdfbe53494dba45ea389fb09a4d2"
- integrity sha512-Dgxsyg54Fx1d4Nge8UnvTrED63vrwOdPmyvPzlNN/boaliRP54pm3pGzZD1SJUwrBA+Cs/xdG8kXX6Mn/RfISQ==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-bugfix-v8-spread-parameters-in-optional-chaining@^7.18.9":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/plugin-bugfix-v8-spread-parameters-in-optional-chaining/-/plugin-bugfix-v8-spread-parameters-in-optional-chaining-7.18.9.tgz#a11af19aa373d68d561f08e0a57242350ed0ec50"
- integrity sha512-AHrP9jadvH7qlOj6PINbgSuphjQUAK7AOT7DPjBo9EHoLhQTnnK5u45e1Hd4DbSQEO9nqPWtQ89r+XEOWFScKg==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.9"
- "@babel/helper-skip-transparent-expression-wrappers" "^7.18.9"
- "@babel/plugin-proposal-optional-chaining" "^7.18.9"
-
-"@babel/plugin-proposal-async-generator-functions@^7.20.1":
- version "7.20.1"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-async-generator-functions/-/plugin-proposal-async-generator-functions-7.20.1.tgz#352f02baa5d69f4e7529bdac39aaa02d41146af9"
- integrity sha512-Gh5rchzSwE4kC+o/6T8waD0WHEQIsDmjltY8WnWRXHUdH8axZhuH86Ov9M72YhJfDrZseQwuuWaaIT/TmePp3g==
- dependencies:
- "@babel/helper-environment-visitor" "^7.18.9"
- "@babel/helper-plugin-utils" "^7.19.0"
- "@babel/helper-remap-async-to-generator" "^7.18.9"
- "@babel/plugin-syntax-async-generators" "^7.8.4"
-
-"@babel/plugin-proposal-class-properties@^7.0.0", "@babel/plugin-proposal-class-properties@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-class-properties/-/plugin-proposal-class-properties-7.18.6.tgz#b110f59741895f7ec21a6fff696ec46265c446a3"
- integrity sha512-cumfXOF0+nzZrrN8Rf0t7M+tF6sZc7vhQwYQck9q1/5w2OExlD+b4v4RpMJFaV1Z7WcDRgO6FqvxqxGlwo+RHQ==
- dependencies:
- "@babel/helper-create-class-features-plugin" "^7.18.6"
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-proposal-class-static-block@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-class-static-block/-/plugin-proposal-class-static-block-7.18.6.tgz#8aa81d403ab72d3962fc06c26e222dacfc9b9020"
- integrity sha512-+I3oIiNxrCpup3Gi8n5IGMwj0gOCAjcJUSQEcotNnCCPMEnixawOQ+KeJPlgfjzx+FKQ1QSyZOWe7wmoJp7vhw==
- dependencies:
- "@babel/helper-create-class-features-plugin" "^7.18.6"
- "@babel/helper-plugin-utils" "^7.18.6"
- "@babel/plugin-syntax-class-static-block" "^7.14.5"
-
-"@babel/plugin-proposal-dynamic-import@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-dynamic-import/-/plugin-proposal-dynamic-import-7.18.6.tgz#72bcf8d408799f547d759298c3c27c7e7faa4d94"
- integrity sha512-1auuwmK+Rz13SJj36R+jqFPMJWyKEDd7lLSdOj4oJK0UTgGueSAtkrCvz9ewmgyU/P941Rv2fQwZJN8s6QruXw==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
- "@babel/plugin-syntax-dynamic-import" "^7.8.3"
-
-"@babel/plugin-proposal-export-namespace-from@^7.18.9":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-export-namespace-from/-/plugin-proposal-export-namespace-from-7.18.9.tgz#5f7313ab348cdb19d590145f9247540e94761203"
- integrity sha512-k1NtHyOMvlDDFeb9G5PhUXuGj8m/wiwojgQVEhJ/fsVsMCpLyOP4h0uGEjYJKrRI+EVPlb5Jk+Gt9P97lOGwtA==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.9"
- "@babel/plugin-syntax-export-namespace-from" "^7.8.3"
-
-"@babel/plugin-proposal-json-strings@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-json-strings/-/plugin-proposal-json-strings-7.18.6.tgz#7e8788c1811c393aff762817e7dbf1ebd0c05f0b"
- integrity sha512-lr1peyn9kOdbYc0xr0OdHTZ5FMqS6Di+H0Fz2I/JwMzGmzJETNeOFq2pBySw6X/KFL5EWDjlJuMsUGRFb8fQgQ==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
- "@babel/plugin-syntax-json-strings" "^7.8.3"
-
-"@babel/plugin-proposal-logical-assignment-operators@^7.18.9":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-logical-assignment-operators/-/plugin-proposal-logical-assignment-operators-7.18.9.tgz#8148cbb350483bf6220af06fa6db3690e14b2e23"
- integrity sha512-128YbMpjCrP35IOExw2Fq+x55LMP42DzhOhX2aNNIdI9avSWl2PI0yuBWarr3RYpZBSPtabfadkH2yeRiMD61Q==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.9"
- "@babel/plugin-syntax-logical-assignment-operators" "^7.10.4"
-
-"@babel/plugin-proposal-nullish-coalescing-operator@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-nullish-coalescing-operator/-/plugin-proposal-nullish-coalescing-operator-7.18.6.tgz#fdd940a99a740e577d6c753ab6fbb43fdb9467e1"
- integrity sha512-wQxQzxYeJqHcfppzBDnm1yAY0jSRkUXR2z8RePZYrKwMKgMlE8+Z6LUno+bd6LvbGh8Gltvy74+9pIYkr+XkKA==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
- "@babel/plugin-syntax-nullish-coalescing-operator" "^7.8.3"
-
-"@babel/plugin-proposal-numeric-separator@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-numeric-separator/-/plugin-proposal-numeric-separator-7.18.6.tgz#899b14fbafe87f053d2c5ff05b36029c62e13c75"
- integrity sha512-ozlZFogPqoLm8WBr5Z8UckIoE4YQ5KESVcNudyXOR8uqIkliTEgJ3RoketfG6pmzLdeZF0H/wjE9/cCEitBl7Q==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
- "@babel/plugin-syntax-numeric-separator" "^7.10.4"
-
-"@babel/plugin-proposal-object-rest-spread@^7.0.0", "@babel/plugin-proposal-object-rest-spread@^7.20.2":
- version "7.20.2"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-object-rest-spread/-/plugin-proposal-object-rest-spread-7.20.2.tgz#a556f59d555f06961df1e572bb5eca864c84022d"
- integrity sha512-Ks6uej9WFK+fvIMesSqbAto5dD8Dz4VuuFvGJFKgIGSkJuRGcrwGECPA1fDgQK3/DbExBJpEkTeYeB8geIFCSQ==
- dependencies:
- "@babel/compat-data" "^7.20.1"
- "@babel/helper-compilation-targets" "^7.20.0"
- "@babel/helper-plugin-utils" "^7.20.2"
- "@babel/plugin-syntax-object-rest-spread" "^7.8.3"
- "@babel/plugin-transform-parameters" "^7.20.1"
-
-"@babel/plugin-proposal-optional-catch-binding@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-optional-catch-binding/-/plugin-proposal-optional-catch-binding-7.18.6.tgz#f9400d0e6a3ea93ba9ef70b09e72dd6da638a2cb"
- integrity sha512-Q40HEhs9DJQyaZfUjjn6vE8Cv4GmMHCYuMGIWUnlxH6400VGxOuwWsPt4FxXxJkC/5eOzgn0z21M9gMT4MOhbw==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
- "@babel/plugin-syntax-optional-catch-binding" "^7.8.3"
-
-"@babel/plugin-proposal-optional-chaining@^7.18.9":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-optional-chaining/-/plugin-proposal-optional-chaining-7.18.9.tgz#e8e8fe0723f2563960e4bf5e9690933691915993"
- integrity sha512-v5nwt4IqBXihxGsW2QmCWMDS3B3bzGIk/EQVZz2ei7f3NJl8NzAJVvUmpDW5q1CRNY+Beb/k58UAH1Km1N411w==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.9"
- "@babel/helper-skip-transparent-expression-wrappers" "^7.18.9"
- "@babel/plugin-syntax-optional-chaining" "^7.8.3"
-
-"@babel/plugin-proposal-private-methods@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-private-methods/-/plugin-proposal-private-methods-7.18.6.tgz#5209de7d213457548a98436fa2882f52f4be6bea"
- integrity sha512-nutsvktDItsNn4rpGItSNV2sz1XwS+nfU0Rg8aCx3W3NOKVzdMjJRu0O5OkgDp3ZGICSTbgRpxZoWsxoKRvbeA==
- dependencies:
- "@babel/helper-create-class-features-plugin" "^7.18.6"
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-proposal-private-property-in-object@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-private-property-in-object/-/plugin-proposal-private-property-in-object-7.18.6.tgz#a64137b232f0aca3733a67eb1a144c192389c503"
- integrity sha512-9Rysx7FOctvT5ouj5JODjAFAkgGoudQuLPamZb0v1TGLpapdNaftzifU8NTWQm0IRjqoYypdrSmyWgkocDQ8Dw==
- dependencies:
- "@babel/helper-annotate-as-pure" "^7.18.6"
- "@babel/helper-create-class-features-plugin" "^7.18.6"
- "@babel/helper-plugin-utils" "^7.18.6"
- "@babel/plugin-syntax-private-property-in-object" "^7.14.5"
-
-"@babel/plugin-proposal-unicode-property-regex@^7.18.6", "@babel/plugin-proposal-unicode-property-regex@^7.4.4":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-unicode-property-regex/-/plugin-proposal-unicode-property-regex-7.18.6.tgz#af613d2cd5e643643b65cded64207b15c85cb78e"
- integrity sha512-2BShG/d5yoZyXZfVePH91urL5wTG6ASZU9M4o03lKK8u8UW1y08OMttBSOADTcJrnPMpvDXRG3G8fyLh4ovs8w==
- dependencies:
- "@babel/helper-create-regexp-features-plugin" "^7.18.6"
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-syntax-async-generators@^7.8.4":
- version "7.8.4"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-async-generators/-/plugin-syntax-async-generators-7.8.4.tgz#a983fb1aeb2ec3f6ed042a210f640e90e786fe0d"
- integrity sha512-tycmZxkGfZaxhMRbXlPXuVFpdWlXpir2W4AMhSJgRKzk/eDlIXOhb2LHWoLpDF7TEHylV5zNhykX6KAgHJmTNw==
- dependencies:
- "@babel/helper-plugin-utils" "^7.8.0"
-
-"@babel/plugin-syntax-class-properties@^7.12.13":
- version "7.12.13"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-class-properties/-/plugin-syntax-class-properties-7.12.13.tgz#b5c987274c4a3a82b89714796931a6b53544ae10"
- integrity sha512-fm4idjKla0YahUNgFNLCB0qySdsoPiZP3iQE3rky0mBUtMZ23yDJ9SJdg6dXTSDnulOVqiF3Hgr9nbXvXTQZYA==
- dependencies:
- "@babel/helper-plugin-utils" "^7.12.13"
-
-"@babel/plugin-syntax-class-static-block@^7.14.5":
- version "7.14.5"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-class-static-block/-/plugin-syntax-class-static-block-7.14.5.tgz#195df89b146b4b78b3bf897fd7a257c84659d406"
- integrity sha512-b+YyPmr6ldyNnM6sqYeMWE+bgJcJpO6yS4QD7ymxgH34GBPNDM/THBh8iunyvKIZztiwLH4CJZ0RxTk9emgpjw==
- dependencies:
- "@babel/helper-plugin-utils" "^7.14.5"
-
-"@babel/plugin-syntax-dynamic-import@^7.8.3":
- version "7.8.3"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-dynamic-import/-/plugin-syntax-dynamic-import-7.8.3.tgz#62bf98b2da3cd21d626154fc96ee5b3cb68eacb3"
- integrity sha512-5gdGbFon+PszYzqs83S3E5mpi7/y/8M9eC90MRTZfduQOYW76ig6SOSPNe41IG5LoP3FGBn2N0RjVDSQiS94kQ==
- dependencies:
- "@babel/helper-plugin-utils" "^7.8.0"
-
-"@babel/plugin-syntax-export-namespace-from@^7.8.3":
- version "7.8.3"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-export-namespace-from/-/plugin-syntax-export-namespace-from-7.8.3.tgz#028964a9ba80dbc094c915c487ad7c4e7a66465a"
- integrity sha512-MXf5laXo6c1IbEbegDmzGPwGNTsHZmEy6QGznu5Sh2UCWvueywb2ee+CCE4zQiZstxU9BMoQO9i6zUFSY0Kj0Q==
- dependencies:
- "@babel/helper-plugin-utils" "^7.8.3"
-
-"@babel/plugin-syntax-import-assertions@^7.20.0":
- version "7.20.0"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-import-assertions/-/plugin-syntax-import-assertions-7.20.0.tgz#bb50e0d4bea0957235390641209394e87bdb9cc4"
- integrity sha512-IUh1vakzNoWalR8ch/areW7qFopR2AEw03JlG7BbrDqmQ4X3q9uuipQwSGrUn7oGiemKjtSLDhNtQHzMHr1JdQ==
- dependencies:
- "@babel/helper-plugin-utils" "^7.19.0"
-
-"@babel/plugin-syntax-json-strings@^7.8.3":
- version "7.8.3"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-json-strings/-/plugin-syntax-json-strings-7.8.3.tgz#01ca21b668cd8218c9e640cb6dd88c5412b2c96a"
- integrity sha512-lY6kdGpWHvjoe2vk4WrAapEuBR69EMxZl+RoGRhrFGNYVK8mOPAW8VfbT/ZgrFbXlDNiiaxQnAtgVCZ6jv30EA==
- dependencies:
- "@babel/helper-plugin-utils" "^7.8.0"
-
-"@babel/plugin-syntax-jsx@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-jsx/-/plugin-syntax-jsx-7.18.6.tgz#a8feef63b010150abd97f1649ec296e849943ca0"
- integrity sha512-6mmljtAedFGTWu2p/8WIORGwy+61PLgOMPOdazc7YoJ9ZCWUyFy3A6CpPkRKLKD1ToAesxX8KGEViAiLo9N+7Q==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-syntax-logical-assignment-operators@^7.10.4":
- version "7.10.4"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-logical-assignment-operators/-/plugin-syntax-logical-assignment-operators-7.10.4.tgz#ca91ef46303530448b906652bac2e9fe9941f699"
- integrity sha512-d8waShlpFDinQ5MtvGU9xDAOzKH47+FFoney2baFIoMr952hKOLp1HR7VszoZvOsV/4+RRszNY7D17ba0te0ig==
- dependencies:
- "@babel/helper-plugin-utils" "^7.10.4"
-
-"@babel/plugin-syntax-nullish-coalescing-operator@^7.8.3":
- version "7.8.3"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-nullish-coalescing-operator/-/plugin-syntax-nullish-coalescing-operator-7.8.3.tgz#167ed70368886081f74b5c36c65a88c03b66d1a9"
- integrity sha512-aSff4zPII1u2QD7y+F8oDsz19ew4IGEJg9SVW+bqwpwtfFleiQDMdzA/R+UlWDzfnHFCxxleFT0PMIrR36XLNQ==
- dependencies:
- "@babel/helper-plugin-utils" "^7.8.0"
-
-"@babel/plugin-syntax-numeric-separator@^7.10.4":
- version "7.10.4"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-numeric-separator/-/plugin-syntax-numeric-separator-7.10.4.tgz#b9b070b3e33570cd9fd07ba7fa91c0dd37b9af97"
- integrity sha512-9H6YdfkcK/uOnY/K7/aA2xpzaAgkQn37yzWUMRK7OaPOqOpGS1+n0H5hxT9AUw9EsSjPW8SVyMJwYRtWs3X3ug==
- dependencies:
- "@babel/helper-plugin-utils" "^7.10.4"
-
-"@babel/plugin-syntax-object-rest-spread@^7.8.3":
- version "7.8.3"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-object-rest-spread/-/plugin-syntax-object-rest-spread-7.8.3.tgz#60e225edcbd98a640332a2e72dd3e66f1af55871"
- integrity sha512-XoqMijGZb9y3y2XskN+P1wUGiVwWZ5JmoDRwx5+3GmEplNyVM2s2Dg8ILFQm8rWM48orGy5YpI5Bl8U1y7ydlA==
- dependencies:
- "@babel/helper-plugin-utils" "^7.8.0"
-
-"@babel/plugin-syntax-optional-catch-binding@^7.8.3":
- version "7.8.3"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-optional-catch-binding/-/plugin-syntax-optional-catch-binding-7.8.3.tgz#6111a265bcfb020eb9efd0fdfd7d26402b9ed6c1"
- integrity sha512-6VPD0Pc1lpTqw0aKoeRTMiB+kWhAoT24PA+ksWSBrFtl5SIRVpZlwN3NNPQjehA2E/91FV3RjLWoVTglWcSV3Q==
- dependencies:
- "@babel/helper-plugin-utils" "^7.8.0"
-
-"@babel/plugin-syntax-optional-chaining@^7.8.3":
- version "7.8.3"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-optional-chaining/-/plugin-syntax-optional-chaining-7.8.3.tgz#4f69c2ab95167e0180cd5336613f8c5788f7d48a"
- integrity sha512-KoK9ErH1MBlCPxV0VANkXW2/dw4vlbGDrFgz8bmUsBGYkFRcbRwMh6cIJubdPrkxRwuGdtCk0v/wPTKbQgBjkg==
- dependencies:
- "@babel/helper-plugin-utils" "^7.8.0"
-
-"@babel/plugin-syntax-private-property-in-object@^7.14.5":
- version "7.14.5"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-private-property-in-object/-/plugin-syntax-private-property-in-object-7.14.5.tgz#0dc6671ec0ea22b6e94a1114f857970cd39de1ad"
- integrity sha512-0wVnp9dxJ72ZUJDV27ZfbSj6iHLoytYZmh3rFcxNnvsJF3ktkzLDZPy/mA17HGsaQT3/DQsWYX1f1QGWkCoVUg==
- dependencies:
- "@babel/helper-plugin-utils" "^7.14.5"
-
-"@babel/plugin-syntax-top-level-await@^7.14.5":
- version "7.14.5"
- resolved "https://registry.yarnpkg.com/@babel/plugin-syntax-top-level-await/-/plugin-syntax-top-level-await-7.14.5.tgz#c1cfdadc35a646240001f06138247b741c34d94c"
- integrity sha512-hx++upLv5U1rgYfwe1xBQUhRmU41NEvpUvrp8jkrSCdvGSnM5/qdRMtylJ6PG5OFkBaHkbTAKTnd3/YyESRHFw==
- dependencies:
- "@babel/helper-plugin-utils" "^7.14.5"
-
-"@babel/plugin-transform-arrow-functions@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-arrow-functions/-/plugin-transform-arrow-functions-7.18.6.tgz#19063fcf8771ec7b31d742339dac62433d0611fe"
- integrity sha512-9S9X9RUefzrsHZmKMbDXxweEH+YlE8JJEuat9FdvW9Qh1cw7W64jELCtWNkPBPX5En45uy28KGvA/AySqUh8CQ==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-transform-async-to-generator@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-async-to-generator/-/plugin-transform-async-to-generator-7.18.6.tgz#ccda3d1ab9d5ced5265fdb13f1882d5476c71615"
- integrity sha512-ARE5wZLKnTgPW7/1ftQmSi1CmkqqHo2DNmtztFhvgtOWSDfq0Cq9/9L+KnZNYSNrydBekhW3rwShduf59RoXag==
- dependencies:
- "@babel/helper-module-imports" "^7.18.6"
- "@babel/helper-plugin-utils" "^7.18.6"
- "@babel/helper-remap-async-to-generator" "^7.18.6"
-
-"@babel/plugin-transform-block-scoped-functions@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-block-scoped-functions/-/plugin-transform-block-scoped-functions-7.18.6.tgz#9187bf4ba302635b9d70d986ad70f038726216a8"
- integrity sha512-ExUcOqpPWnliRcPqves5HJcJOvHvIIWfuS4sroBUenPuMdmW+SMHDakmtS7qOo13sVppmUijqeTv7qqGsvURpQ==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-transform-block-scoping@^7.20.2":
- version "7.20.2"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-block-scoping/-/plugin-transform-block-scoping-7.20.2.tgz#f59b1767e6385c663fd0bce655db6ca9c8b236ed"
- integrity sha512-y5V15+04ry69OV2wULmwhEA6jwSWXO1TwAtIwiPXcvHcoOQUqpyMVd2bDsQJMW8AurjulIyUV8kDqtjSwHy1uQ==
- dependencies:
- "@babel/helper-plugin-utils" "^7.20.2"
-
-"@babel/plugin-transform-classes@^7.20.2":
- version "7.20.2"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-classes/-/plugin-transform-classes-7.20.2.tgz#c0033cf1916ccf78202d04be4281d161f6709bb2"
- integrity sha512-9rbPp0lCVVoagvtEyQKSo5L8oo0nQS/iif+lwlAz29MccX2642vWDlSZK+2T2buxbopotId2ld7zZAzRfz9j1g==
- dependencies:
- "@babel/helper-annotate-as-pure" "^7.18.6"
- "@babel/helper-compilation-targets" "^7.20.0"
- "@babel/helper-environment-visitor" "^7.18.9"
- "@babel/helper-function-name" "^7.19.0"
- "@babel/helper-optimise-call-expression" "^7.18.6"
- "@babel/helper-plugin-utils" "^7.20.2"
- "@babel/helper-replace-supers" "^7.19.1"
- "@babel/helper-split-export-declaration" "^7.18.6"
- globals "^11.1.0"
-
-"@babel/plugin-transform-computed-properties@^7.18.9":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-computed-properties/-/plugin-transform-computed-properties-7.18.9.tgz#2357a8224d402dad623caf6259b611e56aec746e"
- integrity sha512-+i0ZU1bCDymKakLxn5srGHrsAPRELC2WIbzwjLhHW9SIE1cPYkLCL0NlnXMZaM1vhfgA2+M7hySk42VBvrkBRw==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.9"
-
-"@babel/plugin-transform-destructuring@^7.20.2":
- version "7.20.2"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-destructuring/-/plugin-transform-destructuring-7.20.2.tgz#c23741cfa44ddd35f5e53896e88c75331b8b2792"
- integrity sha512-mENM+ZHrvEgxLTBXUiQ621rRXZes3KWUv6NdQlrnr1TkWVw+hUjQBZuP2X32qKlrlG2BzgR95gkuCRSkJl8vIw==
- dependencies:
- "@babel/helper-plugin-utils" "^7.20.2"
-
-"@babel/plugin-transform-dotall-regex@^7.18.6", "@babel/plugin-transform-dotall-regex@^7.4.4":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-dotall-regex/-/plugin-transform-dotall-regex-7.18.6.tgz#b286b3e7aae6c7b861e45bed0a2fafd6b1a4fef8"
- integrity sha512-6S3jpun1eEbAxq7TdjLotAsl4WpQI9DxfkycRcKrjhQYzU87qpXdknpBg/e+TdcMehqGnLFi7tnFUBR02Vq6wg==
- dependencies:
- "@babel/helper-create-regexp-features-plugin" "^7.18.6"
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-transform-duplicate-keys@^7.18.9":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-duplicate-keys/-/plugin-transform-duplicate-keys-7.18.9.tgz#687f15ee3cdad6d85191eb2a372c4528eaa0ae0e"
- integrity sha512-d2bmXCtZXYc59/0SanQKbiWINadaJXqtvIQIzd4+hNwkWBgyCd5F/2t1kXoUdvPMrxzPvhK6EMQRROxsue+mfw==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.9"
-
-"@babel/plugin-transform-exponentiation-operator@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-exponentiation-operator/-/plugin-transform-exponentiation-operator-7.18.6.tgz#421c705f4521888c65e91fdd1af951bfefd4dacd"
- integrity sha512-wzEtc0+2c88FVR34aQmiz56dxEkxr2g8DQb/KfaFa1JYXOFVsbhvAonFN6PwVWj++fKmku8NP80plJ5Et4wqHw==
- dependencies:
- "@babel/helper-builder-binary-assignment-operator-visitor" "^7.18.6"
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-transform-for-of@^7.18.8":
- version "7.18.8"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-for-of/-/plugin-transform-for-of-7.18.8.tgz#6ef8a50b244eb6a0bdbad0c7c61877e4e30097c1"
- integrity sha512-yEfTRnjuskWYo0k1mHUqrVWaZwrdq8AYbfrpqULOJOaucGSp4mNMVps+YtA8byoevxS/urwU75vyhQIxcCgiBQ==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-transform-function-name@^7.18.9":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-function-name/-/plugin-transform-function-name-7.18.9.tgz#cc354f8234e62968946c61a46d6365440fc764e0"
- integrity sha512-WvIBoRPaJQ5yVHzcnJFor7oS5Ls0PYixlTYE63lCj2RtdQEl15M68FXQlxnG6wdraJIXRdR7KI+hQ7q/9QjrCQ==
- dependencies:
- "@babel/helper-compilation-targets" "^7.18.9"
- "@babel/helper-function-name" "^7.18.9"
- "@babel/helper-plugin-utils" "^7.18.9"
-
-"@babel/plugin-transform-literals@^7.18.9":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-literals/-/plugin-transform-literals-7.18.9.tgz#72796fdbef80e56fba3c6a699d54f0de557444bc"
- integrity sha512-IFQDSRoTPnrAIrI5zoZv73IFeZu2dhu6irxQjY9rNjTT53VmKg9fenjvoiOWOkJ6mm4jKVPtdMzBY98Fp4Z4cg==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.9"
-
-"@babel/plugin-transform-member-expression-literals@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-member-expression-literals/-/plugin-transform-member-expression-literals-7.18.6.tgz#ac9fdc1a118620ac49b7e7a5d2dc177a1bfee88e"
- integrity sha512-qSF1ihLGO3q+/g48k85tUjD033C29TNTVB2paCwZPVmOsjn9pClvYYrM2VeJpBY2bcNkuny0YUyTNRyRxJ54KA==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-transform-modules-amd@^7.19.6":
- version "7.19.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-modules-amd/-/plugin-transform-modules-amd-7.19.6.tgz#aca391801ae55d19c4d8d2ebfeaa33df5f2a2cbd"
- integrity sha512-uG3od2mXvAtIFQIh0xrpLH6r5fpSQN04gIVovl+ODLdUMANokxQLZnPBHcjmv3GxRjnqwLuHvppjjcelqUFZvg==
- dependencies:
- "@babel/helper-module-transforms" "^7.19.6"
- "@babel/helper-plugin-utils" "^7.19.0"
-
-"@babel/plugin-transform-modules-commonjs@^7.19.6":
- version "7.19.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-modules-commonjs/-/plugin-transform-modules-commonjs-7.19.6.tgz#25b32feef24df8038fc1ec56038917eacb0b730c"
- integrity sha512-8PIa1ym4XRTKuSsOUXqDG0YaOlEuTVvHMe5JCfgBMOtHvJKw/4NGovEGN33viISshG/rZNVrACiBmPQLvWN8xQ==
- dependencies:
- "@babel/helper-module-transforms" "^7.19.6"
- "@babel/helper-plugin-utils" "^7.19.0"
- "@babel/helper-simple-access" "^7.19.4"
-
-"@babel/plugin-transform-modules-systemjs@^7.19.6":
- version "7.19.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-modules-systemjs/-/plugin-transform-modules-systemjs-7.19.6.tgz#59e2a84064b5736a4471b1aa7b13d4431d327e0d"
- integrity sha512-fqGLBepcc3kErfR9R3DnVpURmckXP7gj7bAlrTQyBxrigFqszZCkFkcoxzCp2v32XmwXLvbw+8Yq9/b+QqksjQ==
- dependencies:
- "@babel/helper-hoist-variables" "^7.18.6"
- "@babel/helper-module-transforms" "^7.19.6"
- "@babel/helper-plugin-utils" "^7.19.0"
- "@babel/helper-validator-identifier" "^7.19.1"
-
-"@babel/plugin-transform-modules-umd@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-modules-umd/-/plugin-transform-modules-umd-7.18.6.tgz#81d3832d6034b75b54e62821ba58f28ed0aab4b9"
- integrity sha512-dcegErExVeXcRqNtkRU/z8WlBLnvD4MRnHgNs3MytRO1Mn1sHRyhbcpYbVMGclAqOjdW+9cfkdZno9dFdfKLfQ==
- dependencies:
- "@babel/helper-module-transforms" "^7.18.6"
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-transform-named-capturing-groups-regex@^7.19.1":
- version "7.19.1"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-named-capturing-groups-regex/-/plugin-transform-named-capturing-groups-regex-7.19.1.tgz#ec7455bab6cd8fb05c525a94876f435a48128888"
- integrity sha512-oWk9l9WItWBQYS4FgXD4Uyy5kq898lvkXpXQxoJEY1RnvPk4R/Dvu2ebXU9q8lP+rlMwUQTFf2Ok6d78ODa0kw==
- dependencies:
- "@babel/helper-create-regexp-features-plugin" "^7.19.0"
- "@babel/helper-plugin-utils" "^7.19.0"
-
-"@babel/plugin-transform-new-target@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-new-target/-/plugin-transform-new-target-7.18.6.tgz#d128f376ae200477f37c4ddfcc722a8a1b3246a8"
- integrity sha512-DjwFA/9Iu3Z+vrAn+8pBUGcjhxKguSMlsFqeCKbhb9BAV756v0krzVK04CRDi/4aqmk8BsHb4a/gFcaA5joXRw==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-transform-object-super@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-object-super/-/plugin-transform-object-super-7.18.6.tgz#fb3c6ccdd15939b6ff7939944b51971ddc35912c"
- integrity sha512-uvGz6zk+pZoS1aTZrOvrbj6Pp/kK2mp45t2B+bTDre2UgsZZ8EZLSJtUg7m/no0zOJUWgFONpB7Zv9W2tSaFlA==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
- "@babel/helper-replace-supers" "^7.18.6"
-
-"@babel/plugin-transform-parameters@^7.20.1":
- version "7.20.3"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-parameters/-/plugin-transform-parameters-7.20.3.tgz#7b3468d70c3c5b62e46be0a47b6045d8590fb748"
- integrity sha512-oZg/Fpx0YDrj13KsLyO8I/CX3Zdw7z0O9qOd95SqcoIzuqy/WTGWvePeHAnZCN54SfdyjHcb1S30gc8zlzlHcA==
- dependencies:
- "@babel/helper-plugin-utils" "^7.20.2"
-
-"@babel/plugin-transform-property-literals@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-property-literals/-/plugin-transform-property-literals-7.18.6.tgz#e22498903a483448e94e032e9bbb9c5ccbfc93a3"
- integrity sha512-cYcs6qlgafTud3PAzrrRNbQtfpQ8+y/+M5tKmksS9+M1ckbH6kzY8MrexEM9mcA6JDsukE19iIRvAyYl463sMg==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-transform-react-display-name@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-react-display-name/-/plugin-transform-react-display-name-7.18.6.tgz#8b1125f919ef36ebdfff061d664e266c666b9415"
- integrity sha512-TV4sQ+T013n61uMoygyMRm+xf04Bd5oqFpv2jAEQwSZ8NwQA7zeRPg1LMVg2PWi3zWBz+CLKD+v5bcpZ/BS0aA==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-transform-react-jsx-development@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-react-jsx-development/-/plugin-transform-react-jsx-development-7.18.6.tgz#dbe5c972811e49c7405b630e4d0d2e1380c0ddc5"
- integrity sha512-SA6HEjwYFKF7WDjWcMcMGUimmw/nhNRDWxr+KaLSCrkD/LMDBvWRmHAYgE1HDeF8KUuI8OAu+RT6EOtKxSW2qA==
- dependencies:
- "@babel/plugin-transform-react-jsx" "^7.18.6"
-
-"@babel/plugin-transform-react-jsx@^7.18.6":
- version "7.19.0"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-react-jsx/-/plugin-transform-react-jsx-7.19.0.tgz#b3cbb7c3a00b92ec8ae1027910e331ba5c500eb9"
- integrity sha512-UVEvX3tXie3Szm3emi1+G63jyw1w5IcMY0FSKM+CRnKRI5Mr1YbCNgsSTwoTwKphQEG9P+QqmuRFneJPZuHNhg==
- dependencies:
- "@babel/helper-annotate-as-pure" "^7.18.6"
- "@babel/helper-module-imports" "^7.18.6"
- "@babel/helper-plugin-utils" "^7.19.0"
- "@babel/plugin-syntax-jsx" "^7.18.6"
- "@babel/types" "^7.19.0"
-
-"@babel/plugin-transform-react-pure-annotations@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-react-pure-annotations/-/plugin-transform-react-pure-annotations-7.18.6.tgz#561af267f19f3e5d59291f9950fd7b9663d0d844"
- integrity sha512-I8VfEPg9r2TRDdvnHgPepTKvuRomzA8+u+nhY7qSI1fR2hRNebasZEETLyM5mAUr0Ku56OkXJ0I7NHJnO6cJiQ==
- dependencies:
- "@babel/helper-annotate-as-pure" "^7.18.6"
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-transform-regenerator@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-regenerator/-/plugin-transform-regenerator-7.18.6.tgz#585c66cb84d4b4bf72519a34cfce761b8676ca73"
- integrity sha512-poqRI2+qiSdeldcz4wTSTXBRryoq3Gc70ye7m7UD5Ww0nE29IXqMl6r7Nd15WBgRd74vloEMlShtH6CKxVzfmQ==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
- regenerator-transform "^0.15.0"
-
-"@babel/plugin-transform-reserved-words@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-reserved-words/-/plugin-transform-reserved-words-7.18.6.tgz#b1abd8ebf8edaa5f7fe6bbb8d2133d23b6a6f76a"
- integrity sha512-oX/4MyMoypzHjFrT1CdivfKZ+XvIPMFXwwxHp/r0Ddy2Vuomt4HDFGmft1TAY2yiTKiNSsh3kjBAzcM8kSdsjA==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-transform-shorthand-properties@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-shorthand-properties/-/plugin-transform-shorthand-properties-7.18.6.tgz#6d6df7983d67b195289be24909e3f12a8f664dc9"
- integrity sha512-eCLXXJqv8okzg86ywZJbRn19YJHU4XUa55oz2wbHhaQVn/MM+XhukiT7SYqp/7o00dg52Rj51Ny+Ecw4oyoygw==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-transform-spread@^7.19.0":
- version "7.19.0"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-spread/-/plugin-transform-spread-7.19.0.tgz#dd60b4620c2fec806d60cfaae364ec2188d593b6"
- integrity sha512-RsuMk7j6n+r752EtzyScnWkQyuJdli6LdO5Klv8Yx0OfPVTcQkIUfS8clx5e9yHXzlnhOZF3CbQ8C2uP5j074w==
- dependencies:
- "@babel/helper-plugin-utils" "^7.19.0"
- "@babel/helper-skip-transparent-expression-wrappers" "^7.18.9"
-
-"@babel/plugin-transform-sticky-regex@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-sticky-regex/-/plugin-transform-sticky-regex-7.18.6.tgz#c6706eb2b1524028e317720339583ad0f444adcc"
- integrity sha512-kfiDrDQ+PBsQDO85yj1icueWMfGfJFKN1KCkndygtu/C9+XUfydLC8Iv5UYJqRwy4zk8EcplRxEOeLyjq1gm6Q==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/plugin-transform-template-literals@^7.18.9":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-template-literals/-/plugin-transform-template-literals-7.18.9.tgz#04ec6f10acdaa81846689d63fae117dd9c243a5e"
- integrity sha512-S8cOWfT82gTezpYOiVaGHrCbhlHgKhQt8XH5ES46P2XWmX92yisoZywf5km75wv5sYcXDUCLMmMxOLCtthDgMA==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.9"
-
-"@babel/plugin-transform-typeof-symbol@^7.18.9":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-typeof-symbol/-/plugin-transform-typeof-symbol-7.18.9.tgz#c8cea68263e45addcd6afc9091429f80925762c0"
- integrity sha512-SRfwTtF11G2aemAZWivL7PD+C9z52v9EvMqH9BuYbabyPuKUvSWks3oCg6041pT925L4zVFqaVBeECwsmlguEw==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.9"
-
-"@babel/plugin-transform-unicode-escapes@^7.18.10":
- version "7.18.10"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-unicode-escapes/-/plugin-transform-unicode-escapes-7.18.10.tgz#1ecfb0eda83d09bbcb77c09970c2dd55832aa246"
- integrity sha512-kKAdAI+YzPgGY/ftStBFXTI1LZFju38rYThnfMykS+IXy8BVx+res7s2fxf1l8I35DV2T97ezo6+SGrXz6B3iQ==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.9"
-
-"@babel/plugin-transform-unicode-regex@^7.18.6":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/plugin-transform-unicode-regex/-/plugin-transform-unicode-regex-7.18.6.tgz#194317225d8c201bbae103364ffe9e2cea36cdca"
- integrity sha512-gE7A6Lt7YLnNOL3Pb9BNeZvi+d8l7tcRrG4+pwJjK9hD2xX4mEvjlQW60G9EEmfXVYRPv9VRQcyegIVHCql/AA==
- dependencies:
- "@babel/helper-create-regexp-features-plugin" "^7.18.6"
- "@babel/helper-plugin-utils" "^7.18.6"
-
-"@babel/polyfill@^7.0.0":
- version "7.12.1"
- resolved "https://registry.yarnpkg.com/@babel/polyfill/-/polyfill-7.12.1.tgz#1f2d6371d1261bbd961f3c5d5909150e12d0bd96"
- integrity sha512-X0pi0V6gxLi6lFZpGmeNa4zxtwEmCs42isWLNjZZDE0Y8yVfgu0T2OAHlzBbdYlqbW/YXVvoBHpATEM+goCj8g==
- dependencies:
- core-js "^2.6.5"
- regenerator-runtime "^0.13.4"
-
-"@babel/preset-env@^7.0.0":
- version "7.20.2"
- resolved "https://registry.yarnpkg.com/@babel/preset-env/-/preset-env-7.20.2.tgz#9b1642aa47bb9f43a86f9630011780dab7f86506"
- integrity sha512-1G0efQEWR1EHkKvKHqbG+IN/QdgwfByUpM5V5QroDzGV2t3S/WXNQd693cHiHTlCFMpr9B6FkPFXDA2lQcKoDg==
- dependencies:
- "@babel/compat-data" "^7.20.1"
- "@babel/helper-compilation-targets" "^7.20.0"
- "@babel/helper-plugin-utils" "^7.20.2"
- "@babel/helper-validator-option" "^7.18.6"
- "@babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression" "^7.18.6"
- "@babel/plugin-bugfix-v8-spread-parameters-in-optional-chaining" "^7.18.9"
- "@babel/plugin-proposal-async-generator-functions" "^7.20.1"
- "@babel/plugin-proposal-class-properties" "^7.18.6"
- "@babel/plugin-proposal-class-static-block" "^7.18.6"
- "@babel/plugin-proposal-dynamic-import" "^7.18.6"
- "@babel/plugin-proposal-export-namespace-from" "^7.18.9"
- "@babel/plugin-proposal-json-strings" "^7.18.6"
- "@babel/plugin-proposal-logical-assignment-operators" "^7.18.9"
- "@babel/plugin-proposal-nullish-coalescing-operator" "^7.18.6"
- "@babel/plugin-proposal-numeric-separator" "^7.18.6"
- "@babel/plugin-proposal-object-rest-spread" "^7.20.2"
- "@babel/plugin-proposal-optional-catch-binding" "^7.18.6"
- "@babel/plugin-proposal-optional-chaining" "^7.18.9"
- "@babel/plugin-proposal-private-methods" "^7.18.6"
- "@babel/plugin-proposal-private-property-in-object" "^7.18.6"
- "@babel/plugin-proposal-unicode-property-regex" "^7.18.6"
- "@babel/plugin-syntax-async-generators" "^7.8.4"
- "@babel/plugin-syntax-class-properties" "^7.12.13"
- "@babel/plugin-syntax-class-static-block" "^7.14.5"
- "@babel/plugin-syntax-dynamic-import" "^7.8.3"
- "@babel/plugin-syntax-export-namespace-from" "^7.8.3"
- "@babel/plugin-syntax-import-assertions" "^7.20.0"
- "@babel/plugin-syntax-json-strings" "^7.8.3"
- "@babel/plugin-syntax-logical-assignment-operators" "^7.10.4"
- "@babel/plugin-syntax-nullish-coalescing-operator" "^7.8.3"
- "@babel/plugin-syntax-numeric-separator" "^7.10.4"
- "@babel/plugin-syntax-object-rest-spread" "^7.8.3"
- "@babel/plugin-syntax-optional-catch-binding" "^7.8.3"
- "@babel/plugin-syntax-optional-chaining" "^7.8.3"
- "@babel/plugin-syntax-private-property-in-object" "^7.14.5"
- "@babel/plugin-syntax-top-level-await" "^7.14.5"
- "@babel/plugin-transform-arrow-functions" "^7.18.6"
- "@babel/plugin-transform-async-to-generator" "^7.18.6"
- "@babel/plugin-transform-block-scoped-functions" "^7.18.6"
- "@babel/plugin-transform-block-scoping" "^7.20.2"
- "@babel/plugin-transform-classes" "^7.20.2"
- "@babel/plugin-transform-computed-properties" "^7.18.9"
- "@babel/plugin-transform-destructuring" "^7.20.2"
- "@babel/plugin-transform-dotall-regex" "^7.18.6"
- "@babel/plugin-transform-duplicate-keys" "^7.18.9"
- "@babel/plugin-transform-exponentiation-operator" "^7.18.6"
- "@babel/plugin-transform-for-of" "^7.18.8"
- "@babel/plugin-transform-function-name" "^7.18.9"
- "@babel/plugin-transform-literals" "^7.18.9"
- "@babel/plugin-transform-member-expression-literals" "^7.18.6"
- "@babel/plugin-transform-modules-amd" "^7.19.6"
- "@babel/plugin-transform-modules-commonjs" "^7.19.6"
- "@babel/plugin-transform-modules-systemjs" "^7.19.6"
- "@babel/plugin-transform-modules-umd" "^7.18.6"
- "@babel/plugin-transform-named-capturing-groups-regex" "^7.19.1"
- "@babel/plugin-transform-new-target" "^7.18.6"
- "@babel/plugin-transform-object-super" "^7.18.6"
- "@babel/plugin-transform-parameters" "^7.20.1"
- "@babel/plugin-transform-property-literals" "^7.18.6"
- "@babel/plugin-transform-regenerator" "^7.18.6"
- "@babel/plugin-transform-reserved-words" "^7.18.6"
- "@babel/plugin-transform-shorthand-properties" "^7.18.6"
- "@babel/plugin-transform-spread" "^7.19.0"
- "@babel/plugin-transform-sticky-regex" "^7.18.6"
- "@babel/plugin-transform-template-literals" "^7.18.9"
- "@babel/plugin-transform-typeof-symbol" "^7.18.9"
- "@babel/plugin-transform-unicode-escapes" "^7.18.10"
- "@babel/plugin-transform-unicode-regex" "^7.18.6"
- "@babel/preset-modules" "^0.1.5"
- "@babel/types" "^7.20.2"
- babel-plugin-polyfill-corejs2 "^0.3.3"
- babel-plugin-polyfill-corejs3 "^0.6.0"
- babel-plugin-polyfill-regenerator "^0.4.1"
- core-js-compat "^3.25.1"
- semver "^6.3.0"
-
-"@babel/preset-modules@^0.1.5":
- version "0.1.5"
- resolved "https://registry.yarnpkg.com/@babel/preset-modules/-/preset-modules-0.1.5.tgz#ef939d6e7f268827e1841638dc6ff95515e115d9"
- integrity sha512-A57th6YRG7oR3cq/yt/Y84MvGgE0eJG2F1JLhKuyG+jFxEgrd/HAMJatiFtmOiZurz+0DkrvbheCLaV5f2JfjA==
- dependencies:
- "@babel/helper-plugin-utils" "^7.0.0"
- "@babel/plugin-proposal-unicode-property-regex" "^7.4.4"
- "@babel/plugin-transform-dotall-regex" "^7.4.4"
- "@babel/types" "^7.4.4"
- esutils "^2.0.2"
-
-"@babel/preset-react@^7.0.0":
- version "7.18.6"
- resolved "https://registry.yarnpkg.com/@babel/preset-react/-/preset-react-7.18.6.tgz#979f76d6277048dc19094c217b507f3ad517dd2d"
- integrity sha512-zXr6atUmyYdiWRVLOZahakYmOBHtWc2WGCkP8PYTgZi0iJXDY2CN180TdrIW4OGOAdLc7TifzDIvtx6izaRIzg==
- dependencies:
- "@babel/helper-plugin-utils" "^7.18.6"
- "@babel/helper-validator-option" "^7.18.6"
- "@babel/plugin-transform-react-display-name" "^7.18.6"
- "@babel/plugin-transform-react-jsx" "^7.18.6"
- "@babel/plugin-transform-react-jsx-development" "^7.18.6"
- "@babel/plugin-transform-react-pure-annotations" "^7.18.6"
-
-"@babel/register@^7.0.0":
- version "7.18.9"
- resolved "https://registry.yarnpkg.com/@babel/register/-/register-7.18.9.tgz#1888b24bc28d5cc41c412feb015e9ff6b96e439c"
- integrity sha512-ZlbnXDcNYHMR25ITwwNKT88JiaukkdVj/nG7r3wnuXkOTHc60Uy05PwMCPre0hSkY68E6zK3xz+vUJSP2jWmcw==
- dependencies:
- clone-deep "^4.0.1"
- find-cache-dir "^2.0.0"
- make-dir "^2.1.0"
- pirates "^4.0.5"
- source-map-support "^0.5.16"
-
-"@babel/runtime@^7.8.4":
- version "7.20.1"
- resolved "https://registry.yarnpkg.com/@babel/runtime/-/runtime-7.20.1.tgz#1148bb33ab252b165a06698fde7576092a78b4a9"
- integrity sha512-mrzLkl6U9YLF8qpqI7TB82PESyEGjm/0Ly91jG575eVxMMlb8fYfOXFZIJ8XfLrJZQbm7dlKry2bJmXBUEkdFg==
- dependencies:
- regenerator-runtime "^0.13.10"
-
-"@babel/template@^7.18.10":
- version "7.18.10"
- resolved "https://registry.yarnpkg.com/@babel/template/-/template-7.18.10.tgz#6f9134835970d1dbf0835c0d100c9f38de0c5e71"
- integrity sha512-TI+rCtooWHr3QJ27kJxfjutghu44DLnasDMwpDqCXVTal9RLp3RSYNh4NdBrRP2cQAoG9A8juOQl6P6oZG4JxA==
- dependencies:
- "@babel/code-frame" "^7.18.6"
- "@babel/parser" "^7.18.10"
- "@babel/types" "^7.18.10"
-
-"@babel/traverse@^7.0.0", "@babel/traverse@^7.19.0", "@babel/traverse@^7.19.1", "@babel/traverse@^7.20.1":
- version "7.20.1"
- resolved "https://registry.yarnpkg.com/@babel/traverse/-/traverse-7.20.1.tgz#9b15ccbf882f6d107eeeecf263fbcdd208777ec8"
- integrity sha512-d3tN8fkVJwFLkHkBN479SOsw4DMZnz8cdbL/gvuDuzy3TS6Nfw80HuQqhw1pITbIruHyh7d1fMA47kWzmcUEGA==
- dependencies:
- "@babel/code-frame" "^7.18.6"
- "@babel/generator" "^7.20.1"
- "@babel/helper-environment-visitor" "^7.18.9"
- "@babel/helper-function-name" "^7.19.0"
- "@babel/helper-hoist-variables" "^7.18.6"
- "@babel/helper-split-export-declaration" "^7.18.6"
- "@babel/parser" "^7.20.1"
- "@babel/types" "^7.20.0"
- debug "^4.1.0"
- globals "^11.1.0"
-
-"@babel/types@^7.1.2", "@babel/types@^7.18.10", "@babel/types@^7.18.6", "@babel/types@^7.18.9", "@babel/types@^7.19.0", "@babel/types@^7.20.0", "@babel/types@^7.20.2", "@babel/types@^7.4.4":
- version "7.20.2"
- resolved "https://registry.yarnpkg.com/@babel/types/-/types-7.20.2.tgz#67ac09266606190f496322dbaff360fdaa5e7842"
- integrity sha512-FnnvsNWgZCr232sqtXggapvlkk/tuwR/qhGzcmxI0GXLCjmPYQPzio2FbdlWuY6y1sHFfQKk+rRbUZ9VStQMog==
- dependencies:
- "@babel/helper-string-parser" "^7.19.4"
- "@babel/helper-validator-identifier" "^7.19.1"
- to-fast-properties "^2.0.0"
-
-"@jridgewell/gen-mapping@^0.1.0":
- version "0.1.1"
- resolved "https://registry.yarnpkg.com/@jridgewell/gen-mapping/-/gen-mapping-0.1.1.tgz#e5d2e450306a9491e3bd77e323e38d7aff315996"
- integrity sha512-sQXCasFk+U8lWYEe66WxRDOE9PjVz4vSM51fTu3Hw+ClTpUSQb718772vH3pyS5pShp6lvQM7SxgIDXXXmOX7w==
- dependencies:
- "@jridgewell/set-array" "^1.0.0"
- "@jridgewell/sourcemap-codec" "^1.4.10"
-
-"@jridgewell/gen-mapping@^0.3.2":
- version "0.3.2"
- resolved "https://registry.yarnpkg.com/@jridgewell/gen-mapping/-/gen-mapping-0.3.2.tgz#c1aedc61e853f2bb9f5dfe6d4442d3b565b253b9"
- integrity sha512-mh65xKQAzI6iBcFzwv28KVWSmCkdRBWoOh+bYQGW3+6OZvbbN3TqMGo5hqYxQniRcH9F2VZIoJCm4pa3BPDK/A==
- dependencies:
- "@jridgewell/set-array" "^1.0.1"
- "@jridgewell/sourcemap-codec" "^1.4.10"
- "@jridgewell/trace-mapping" "^0.3.9"
-
-"@jridgewell/resolve-uri@3.1.0":
- version "3.1.0"
- resolved "https://registry.yarnpkg.com/@jridgewell/resolve-uri/-/resolve-uri-3.1.0.tgz#2203b118c157721addfe69d47b70465463066d78"
- integrity sha512-F2msla3tad+Mfht5cJq7LSXcdudKTWCVYUgw6pLFOOHSTtZlj6SWNYAp+AhuqLmWdBO2X5hPrLcu8cVP8fy28w==
-
-"@jridgewell/set-array@^1.0.0", "@jridgewell/set-array@^1.0.1":
- version "1.1.2"
- resolved "https://registry.yarnpkg.com/@jridgewell/set-array/-/set-array-1.1.2.tgz#7c6cf998d6d20b914c0a55a91ae928ff25965e72"
- integrity sha512-xnkseuNADM0gt2bs+BvhO0p78Mk762YnZdsuzFV018NoG1Sj1SCQvpSqa7XUaTam5vAGasABV9qXASMKnFMwMw==
-
-"@jridgewell/sourcemap-codec@1.4.14", "@jridgewell/sourcemap-codec@^1.4.10":
- version "1.4.14"
- resolved "https://registry.yarnpkg.com/@jridgewell/sourcemap-codec/-/sourcemap-codec-1.4.14.tgz#add4c98d341472a289190b424efbdb096991bb24"
- integrity sha512-XPSJHWmi394fuUuzDnGz1wiKqWfo1yXecHQMRf2l6hztTO+nPru658AyDngaBe7isIxEkRsPR3FZh+s7iVa4Uw==
-
-"@jridgewell/trace-mapping@^0.3.9":
- version "0.3.17"
- resolved "https://registry.yarnpkg.com/@jridgewell/trace-mapping/-/trace-mapping-0.3.17.tgz#793041277af9073b0951a7fe0f0d8c4c98c36985"
- integrity sha512-MCNzAp77qzKca9+W/+I0+sEpaUnZoeasnghNeVc41VZCEKaCH73Vq3BZZ/SzWIgrqE4H4ceI+p+b6C0mHf9T4g==
- dependencies:
- "@jridgewell/resolve-uri" "3.1.0"
- "@jridgewell/sourcemap-codec" "1.4.14"
-
-"@mrmlnc/readdir-enhanced@^2.2.1":
- version "2.2.1"
- resolved "https://registry.yarnpkg.com/@mrmlnc/readdir-enhanced/-/readdir-enhanced-2.2.1.tgz#524af240d1a360527b730475ecfa1344aa540dde"
- integrity sha512-bPHp6Ji8b41szTOcaP63VlnbbO5Ny6dwAATtY6JTjh5N2OLrb5Qk/Th5cRkRQhkWCt+EJsYrNB0MiL+Gpn6e3g==
- dependencies:
- call-me-maybe "^1.0.1"
- glob-to-regexp "^0.3.0"
-
-"@nodelib/fs.stat@^1.1.2":
- version "1.1.3"
- resolved "https://registry.yarnpkg.com/@nodelib/fs.stat/-/fs.stat-1.1.3.tgz#2b5a3ab3f918cca48a8c754c08168e3f03eba61b"
- integrity sha512-shAmDyaQC4H92APFoIaVDHCx5bStIocgvbwQyxPRrbUY20V1EYTbSDchWbuwlMG3V17cprZhA6+78JfB+3DTPw==
-
-"@sindresorhus/is@^0.7.0":
- version "0.7.0"
- resolved "https://registry.yarnpkg.com/@sindresorhus/is/-/is-0.7.0.tgz#9a06f4f137ee84d7df0460c1fdb1135ffa6c50fd"
- integrity sha512-ONhaKPIufzzrlNbqtWFFd+jlnemX6lJAgq9ZeiZtS7I1PIf/la7CW4m83rTXRnVnsMbW2k56pGYu7AUFJD9Pow==
-
-"@types/cheerio@^0.22.8":
- version "0.22.31"
- resolved "https://registry.yarnpkg.com/@types/cheerio/-/cheerio-0.22.31.tgz#b8538100653d6bb1b08a1e46dec75b4f2a5d5eb6"
- integrity sha512-Kt7Cdjjdi2XWSfrZ53v4Of0wG3ZcmaegFXjMmz9tfNrZSkzzo36G0AL1YqSdcIA78Etjt6E609pt5h1xnQkPUw==
- dependencies:
- "@types/node" "*"
-
-"@types/node@*":
- version "18.11.9"
- resolved "https://registry.yarnpkg.com/@types/node/-/node-18.11.9.tgz#02d013de7058cea16d36168ef2fc653464cfbad4"
- integrity sha512-CRpX21/kGdzjOpFsZSkcrXMGIBWMGNIHXXBVFSH+ggkftxg+XYP20TESbh+zFvFj3EQOl5byk0HTRn1IL6hbqg==
-
-"@types/q@^1.5.1":
- version "1.5.5"
- resolved "https://registry.yarnpkg.com/@types/q/-/q-1.5.5.tgz#75a2a8e7d8ab4b230414505d92335d1dcb53a6df"
- integrity sha512-L28j2FcJfSZOnL1WBjDYp2vUHCeIFlyYI/53EwD/rKUBQ7MtUUfbQWiyKJGpcnv4/WgrhWsFKrcPstcAt/J0tQ==
-
-accepts@~1.3.8:
- version "1.3.8"
- resolved "https://registry.yarnpkg.com/accepts/-/accepts-1.3.8.tgz#0bf0be125b67014adcb0b0921e62db7bffe16b2e"
- integrity sha512-PYAthTa2m2VKxuvSD3DPC/Gy+U+sOA1LAuT8mkmRuvw+NACSaeXEQ+NHcVF7rONl6qcaxV3Uuemwawk+7+SJLw==
- dependencies:
- mime-types "~2.1.34"
- negotiator "0.6.3"
-
-address@1.0.3:
- version "1.0.3"
- resolved "https://registry.yarnpkg.com/address/-/address-1.0.3.tgz#b5f50631f8d6cec8bd20c963963afb55e06cbce9"
- integrity sha512-z55ocwKBRLryBs394Sm3ushTtBeg6VAeuku7utSoSnsJKvKcnXFIyC6vh27n3rXyxSgkJBBCAvyOn7gSUcTYjg==
-
-address@^1.0.1:
- version "1.2.1"
- resolved "https://registry.yarnpkg.com/address/-/address-1.2.1.tgz#25bb61095b7522d65b357baa11bc05492d4c8acd"
- integrity sha512-B+6bi5D34+fDYENiH5qOlA0cV2rAGKuWZ9LeyUUehbXy8e0VS9e498yO0Jeeh+iM+6KbfudHTFjXw2MmJD4QRA==
-
-ajv@^6.12.3:
- version "6.12.6"
- resolved "https://registry.yarnpkg.com/ajv/-/ajv-6.12.6.tgz#baf5a62e802b07d977034586f8c3baf5adf26df4"
- integrity sha512-j3fVLgvTo527anyYyJOGTYJbG+vnnQYvE0m5mmkc1TK+nxAppkCLMIL0aZ4dblVCNoGShhm+kzE4ZUykBoMg4g==
- dependencies:
- fast-deep-equal "^3.1.1"
- fast-json-stable-stringify "^2.0.0"
- json-schema-traverse "^0.4.1"
- uri-js "^4.2.2"
-
-alphanum-sort@^1.0.0:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/alphanum-sort/-/alphanum-sort-1.0.2.tgz#97a1119649b211ad33691d9f9f486a8ec9fbe0a3"
- integrity sha512-0FcBfdcmaumGPQ0qPn7Q5qTgz/ooXgIyp1rf8ik5bGX8mpE2YHjC0P/eyQvxu1GURYQgq9ozf2mteQ5ZD9YiyQ==
-
-ansi-escapes@^3.0.0:
- version "3.2.0"
- resolved "https://registry.yarnpkg.com/ansi-escapes/-/ansi-escapes-3.2.0.tgz#8780b98ff9dbf5638152d1f1fe5c1d7b4442976b"
- integrity sha512-cBhpre4ma+U0T1oM5fXg7Dy1Jw7zzwv7lt/GoCpr+hDQJoYnKVPLL4dCvSEFMmQurOQvSrwT7SL/DAlhBI97RQ==
-
-ansi-red@^0.1.1:
- version "0.1.1"
- resolved "https://registry.yarnpkg.com/ansi-red/-/ansi-red-0.1.1.tgz#8c638f9d1080800a353c9c28c8a81ca4705d946c"
- integrity sha512-ewaIr5y+9CUTGFwZfpECUbFlGcC0GCw1oqR9RI6h1gQCd9Aj2GxSckCnPsVJnmfMZbwFYE+leZGASgkWl06Jow==
- dependencies:
- ansi-wrap "0.1.0"
-
-ansi-regex@^2.0.0:
- version "2.1.1"
- resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-2.1.1.tgz#c3b33ab5ee360d86e0e628f0468ae7ef27d654df"
- integrity sha512-TIGnTpdo+E3+pCyAluZvtED5p5wCqLdezCyhPZzKPcxvFplEt4i+W7OONCKgeZFT3+y5NZZfOOS/Bdcanm1MYA==
-
-ansi-regex@^3.0.0:
- version "3.0.1"
- resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-3.0.1.tgz#123d6479e92ad45ad897d4054e3c7ca7db4944e1"
- integrity sha512-+O9Jct8wf++lXxxFc4hc8LsjaSq0HFzzL7cVsw8pRDIPdjKD2mT4ytDZlLuSBZ4cLKZFXIrMGO7DbQCtMJJMKw==
-
-ansi-styles@^2.2.1:
- version "2.2.1"
- resolved "https://registry.yarnpkg.com/ansi-styles/-/ansi-styles-2.2.1.tgz#b432dd3358b634cf75e1e4664368240533c1ddbe"
- integrity sha512-kmCevFghRiWM7HB5zTPULl4r9bVFSWjz62MhqizDGUrq2NWuNMQyuv4tHHoKJHs69M/MF64lEcHdYIocrdWQYA==
-
-ansi-styles@^3.2.1:
- version "3.2.1"
- resolved "https://registry.yarnpkg.com/ansi-styles/-/ansi-styles-3.2.1.tgz#41fbb20243e50b12be0f04b8dedbf07520ce841d"
- integrity sha512-VT0ZI6kZRdTh8YyJw3SMbYm/u+NqfsAxEpWO0Pf9sq8/e94WxxOpPKx9FR1FlyCtOVDNOQ+8ntlqFxiRc+r5qA==
- dependencies:
- color-convert "^1.9.0"
-
-ansi-wrap@0.1.0:
- version "0.1.0"
- resolved "https://registry.yarnpkg.com/ansi-wrap/-/ansi-wrap-0.1.0.tgz#a82250ddb0015e9a27ca82e82ea603bbfa45efaf"
- integrity sha512-ZyznvL8k/FZeQHr2T6LzcJ/+vBApDnMNZvfVFy3At0knswWd6rJ3/0Hhmpu8oqa6C92npmozs890sX9Dl6q+Qw==
-
-anymatch@~3.1.2:
- version "3.1.2"
- resolved "https://registry.yarnpkg.com/anymatch/-/anymatch-3.1.2.tgz#c0557c096af32f106198f4f4e2a383537e378716"
- integrity sha512-P43ePfOAIupkguHUycrc4qJ9kz8ZiuOUijaETwX7THt0Y/GNK7v0aa8rY816xWjZ7rJdA5XdMcpVFTKMq+RvWg==
- dependencies:
- normalize-path "^3.0.0"
- picomatch "^2.0.4"
-
-arch@^2.1.0:
- version "2.2.0"
- resolved "https://registry.yarnpkg.com/arch/-/arch-2.2.0.tgz#1bc47818f305764f23ab3306b0bfc086c5a29d11"
- integrity sha512-Of/R0wqp83cgHozfIYLbBMnej79U/SVGOOyuB3VVFv1NRM/PSFMK12x9KVtiYzJqmnU5WR2qp0Z5rHb7sWGnFQ==
-
-archive-type@^4.0.0:
- version "4.0.0"
- resolved "https://registry.yarnpkg.com/archive-type/-/archive-type-4.0.0.tgz#f92e72233056dfc6969472749c267bdb046b1d70"
- integrity sha512-zV4Ky0v1F8dBrdYElwTvQhweQ0P7Kwc1aluqJsYtOBP01jXcWCyW2IEfI1YiqsG+Iy7ZR+o5LF1N+PGECBxHWA==
- dependencies:
- file-type "^4.2.0"
-
-argparse@^1.0.10, argparse@^1.0.7:
- version "1.0.10"
- resolved "https://registry.yarnpkg.com/argparse/-/argparse-1.0.10.tgz#bcd6791ea5ae09725e17e5ad988134cd40b3d911"
- integrity sha512-o5Roy6tNG4SL/FOkCAN6RzjiakZS25RLYFrcMttJqbdd8BWrnA+fGz57iN5Pb06pvBGvl5gQ0B48dJlslXvoTg==
- dependencies:
- sprintf-js "~1.0.2"
-
-arr-diff@^4.0.0:
- version "4.0.0"
- resolved "https://registry.yarnpkg.com/arr-diff/-/arr-diff-4.0.0.tgz#d6461074febfec71e7e15235761a329a5dc7c520"
- integrity sha512-YVIQ82gZPGBebQV/a8dar4AitzCQs0jjXwMPZllpXMaGjXPYVUawSxQrRsjhjupyVxEvbHgUmIhKVlND+j02kA==
-
-arr-flatten@^1.1.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/arr-flatten/-/arr-flatten-1.1.0.tgz#36048bbff4e7b47e136644316c99669ea5ae91f1"
- integrity sha512-L3hKV5R/p5o81R7O02IGnwpDmkp6E982XhtbuwSe3O4qOtMMMtodicASA1Cny2U+aCXcNpml+m4dPsvsJ3jatg==
-
-arr-union@^3.1.0:
- version "3.1.0"
- resolved "https://registry.yarnpkg.com/arr-union/-/arr-union-3.1.0.tgz#e39b09aea9def866a8f206e288af63919bae39c4"
- integrity sha512-sKpyeERZ02v1FeCZT8lrfJq5u6goHCtpTAzPwJYe7c8SPFOboNjNg1vz2L4VTn9T4PQxEx13TbXLmYUcS6Ug7Q==
-
-array-filter@~0.0.0:
- version "0.0.1"
- resolved "https://registry.yarnpkg.com/array-filter/-/array-filter-0.0.1.tgz#7da8cf2e26628ed732803581fd21f67cacd2eeec"
- integrity sha512-VW0FpCIhjZdarWjIz8Vpva7U95fl2Jn+b+mmFFMLn8PIVscOQcAgEznwUzTEuUHuqZqIxwzRlcaN/urTFFQoiw==
-
-array-find-index@^1.0.1:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/array-find-index/-/array-find-index-1.0.2.tgz#df010aa1287e164bbda6f9723b0a96a1ec4187a1"
- integrity sha512-M1HQyIXcBGtVywBt8WVdim+lrNaK7VHp99Qt5pSNziXznKHViIBbXWtfRTpEFpF/c4FdfxNAsCCwPp5phBYJtw==
-
-array-flatten@1.1.1:
- version "1.1.1"
- resolved "https://registry.yarnpkg.com/array-flatten/-/array-flatten-1.1.1.tgz#9a5f699051b1e7073328f2a008968b64ea2955d2"
- integrity sha512-PCVAQswWemu6UdxsDFFX/+gVeYqKAod3D3UVm91jHwynguOwAvYPhx8nNlM++NqRcK6CxxpUafjmhIdKiHibqg==
-
-array-map@~0.0.0:
- version "0.0.1"
- resolved "https://registry.yarnpkg.com/array-map/-/array-map-0.0.1.tgz#d1bf3cc8813a7daaa335e5c8eb21d9d06230c1a7"
- integrity sha512-sxHIeJTGEsRC8/hYkZzdJNNPZ41EXHVys7pqMw1iwE/Kx8/hto0UbDuGQsSJ0ujPovj9qUZl6EOY/EiZ2g3d9Q==
-
-array-reduce@~0.0.0:
- version "0.0.0"
- resolved "https://registry.yarnpkg.com/array-reduce/-/array-reduce-0.0.0.tgz#173899d3ffd1c7d9383e4479525dbe278cab5f2b"
- integrity sha512-8jR+StqaC636u7h3ye1co3lQRefgVVUQUhuAmRbDqIMeR2yuXzRvkCNQiQ5J/wbREmoBLNtp13dhaaVpZQDRUw==
-
-array-union@^1.0.1:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/array-union/-/array-union-1.0.2.tgz#9a34410e4f4e3da23dea375be5be70f24778ec39"
- integrity sha512-Dxr6QJj/RdU/hCaBjOfxW+q6lyuVE6JFWIrAUpuOOhoJJoQ99cUn3igRaHVB5P9WrgFVN0FfArM3x0cueOU8ng==
- dependencies:
- array-uniq "^1.0.1"
-
-array-uniq@^1.0.1:
- version "1.0.3"
- resolved "https://registry.yarnpkg.com/array-uniq/-/array-uniq-1.0.3.tgz#af6ac877a25cc7f74e058894753858dfdb24fdb6"
- integrity sha512-MNha4BWQ6JbwhFhj03YK552f7cb3AzoE8SzeljgChvL1dl3IcvggXVz1DilzySZkCja+CXuZbdW7yATchWn8/Q==
-
-array-unique@^0.3.2:
- version "0.3.2"
- resolved "https://registry.yarnpkg.com/array-unique/-/array-unique-0.3.2.tgz#a894b75d4bc4f6cd679ef3244a9fd8f46ae2d428"
- integrity sha512-SleRWjh9JUud2wH1hPs9rZBZ33H6T9HOiL0uwGnGx9FpE6wKGyfWugmbkEOIs6qWrZhg0LWeLziLrEwQJhs5mQ==
-
-array.prototype.reduce@^1.0.5:
- version "1.0.5"
- resolved "https://registry.yarnpkg.com/array.prototype.reduce/-/array.prototype.reduce-1.0.5.tgz#6b20b0daa9d9734dd6bc7ea66b5bbce395471eac"
- integrity sha512-kDdugMl7id9COE8R7MHF5jWk7Dqt/fs4Pv+JXoICnYwqpjjjbUurz6w5fT5IG6brLdJhv6/VoHB0H7oyIBXd+Q==
- dependencies:
- call-bind "^1.0.2"
- define-properties "^1.1.4"
- es-abstract "^1.20.4"
- es-array-method-boxes-properly "^1.0.0"
- is-string "^1.0.7"
-
-arrify@^1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/arrify/-/arrify-1.0.1.tgz#898508da2226f380df904728456849c1501a4b0d"
- integrity sha512-3CYzex9M9FGQjCGMGyi6/31c8GJbgb0qGyrx5HWxPd0aCwh4cB2YjMb2Xf9UuoogrMrlO9cTqnB5rI5GHZTcUA==
-
-asn1@~0.2.3:
- version "0.2.6"
- resolved "https://registry.yarnpkg.com/asn1/-/asn1-0.2.6.tgz#0d3a7bb6e64e02a90c0303b31f292868ea09a08d"
- integrity sha512-ix/FxPn0MDjeyJ7i/yoHGFt/EX6LyNbxSEhPPXODPL+KB0VPk86UYfL0lMdy+KCnv+fmvIzySwaK5COwqVbWTQ==
- dependencies:
- safer-buffer "~2.1.0"
-
-assert-plus@1.0.0, assert-plus@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/assert-plus/-/assert-plus-1.0.0.tgz#f12e0f3c5d77b0b1cdd9146942e4e96c1e4dd525"
- integrity sha512-NfJ4UzBCcQGLDlQq7nHxH+tv3kyZ0hHQqF5BO6J7tNJeP5do1llPr8dZ8zHonfhAu0PHAdMkSo+8o0wxg9lZWw==
-
-assign-symbols@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/assign-symbols/-/assign-symbols-1.0.0.tgz#59667f41fadd4f20ccbc2bb96b8d4f7f78ec0367"
- integrity sha512-Q+JC7Whu8HhmTdBph/Tq59IoRtoy6KAm5zzPv00WdujX82lbAL8K7WVjne7vdCsAmbF4AYaDOPyO3k0kl8qIrw==
-
-async@^2.6.4:
- version "2.6.4"
- resolved "https://registry.yarnpkg.com/async/-/async-2.6.4.tgz#706b7ff6084664cd7eae713f6f965433b5504221"
- integrity sha512-mzo5dfJYwAn29PeiJ0zvwTo04zj8HDJj0Mn8TD7sno7q12prdbnasKJHhkm2c1LgrhlJ0teaea8860oxi51mGA==
- dependencies:
- lodash "^4.17.14"
-
-asynckit@^0.4.0:
- version "0.4.0"
- resolved "https://registry.yarnpkg.com/asynckit/-/asynckit-0.4.0.tgz#c79ed97f7f34cb8f2ba1bc9790bcc366474b4b79"
- integrity sha512-Oei9OH4tRh0YqU3GxhX79dM/mwVgvbZJaSNaRk+bshkj0S5cfHcgYakreBjrHwatXKbz+IoIdYLxrKim2MjW0Q==
-
-atob@^2.1.2:
- version "2.1.2"
- resolved "https://registry.yarnpkg.com/atob/-/atob-2.1.2.tgz#6d9517eb9e030d2436666651e86bd9f6f13533c9"
- integrity sha512-Wm6ukoaOGJi/73p/cl2GvLjTI5JM1k/O14isD73YML8StrH/7/lRFgmg8nICZgD3bZZvjwCGxtMOD3wWNAu8cg==
-
-autolinker@~0.28.0:
- version "0.28.1"
- resolved "https://registry.yarnpkg.com/autolinker/-/autolinker-0.28.1.tgz#0652b491881879f0775dace0cdca3233942a4e47"
- integrity sha512-zQAFO1Dlsn69eXaO6+7YZc+v84aquQKbwpzCE3L0stj56ERn9hutFxPopViLjo9G+rWwjozRhgS5KJ25Xy19cQ==
- dependencies:
- gulp-header "^1.7.1"
-
-autoprefixer@^9.6.0:
- version "9.8.8"
- resolved "https://registry.yarnpkg.com/autoprefixer/-/autoprefixer-9.8.8.tgz#fd4bd4595385fa6f06599de749a4d5f7a474957a"
- integrity sha512-eM9d/swFopRt5gdJ7jrpCwgvEMIayITpojhkkSMRsFHYuH5bkSQ4p/9qTEHtmNudUZh22Tehu7I6CxAW0IXTKA==
- dependencies:
- browserslist "^4.12.0"
- caniuse-lite "^1.0.30001109"
- normalize-range "^0.1.2"
- num2fraction "^1.2.2"
- picocolors "^0.2.1"
- postcss "^7.0.32"
- postcss-value-parser "^4.1.0"
-
-aws-sign2@~0.7.0:
- version "0.7.0"
- resolved "https://registry.yarnpkg.com/aws-sign2/-/aws-sign2-0.7.0.tgz#b46e890934a9591f2d2f6f86d7e6a9f1b3fe76a8"
- integrity sha512-08kcGqnYf/YmjoRhfxyu+CLxBjUtHLXLXX/vUfx9l2LYzG3c1m61nrpyFUZI6zeS+Li/wWMMidD9KgrqtGq3mA==
-
-aws4@^1.8.0:
- version "1.11.0"
- resolved "https://registry.yarnpkg.com/aws4/-/aws4-1.11.0.tgz#d61f46d83b2519250e2784daf5b09479a8b41c59"
- integrity sha512-xh1Rl34h6Fi1DC2WWKfxUTVqRsNnr6LsKz2+hfwDxQJWmrx8+c7ylaqBMcHfl1U1r2dsifOvKX3LQuLNZ+XSvA==
-
-babel-code-frame@6.26.0:
- version "6.26.0"
- resolved "https://registry.yarnpkg.com/babel-code-frame/-/babel-code-frame-6.26.0.tgz#63fd43f7dc1e3bb7ce35947db8fe369a3f58c74b"
- integrity sha512-XqYMR2dfdGMW+hd0IUZ2PwK+fGeFkOxZJ0wY+JaQAHzt1Zx8LcvpiZD2NiGkEG8qx0CfkAOr5xt76d1e8vG90g==
- dependencies:
- chalk "^1.1.3"
- esutils "^2.0.2"
- js-tokens "^3.0.2"
-
-babel-plugin-polyfill-corejs2@^0.3.3:
- version "0.3.3"
- resolved "https://registry.yarnpkg.com/babel-plugin-polyfill-corejs2/-/babel-plugin-polyfill-corejs2-0.3.3.tgz#5d1bd3836d0a19e1b84bbf2d9640ccb6f951c122"
- integrity sha512-8hOdmFYFSZhqg2C/JgLUQ+t52o5nirNwaWM2B9LWteozwIvM14VSwdsCAUET10qT+kmySAlseadmfeeSWFCy+Q==
- dependencies:
- "@babel/compat-data" "^7.17.7"
- "@babel/helper-define-polyfill-provider" "^0.3.3"
- semver "^6.1.1"
-
-babel-plugin-polyfill-corejs3@^0.6.0:
- version "0.6.0"
- resolved "https://registry.yarnpkg.com/babel-plugin-polyfill-corejs3/-/babel-plugin-polyfill-corejs3-0.6.0.tgz#56ad88237137eade485a71b52f72dbed57c6230a"
- integrity sha512-+eHqR6OPcBhJOGgsIar7xoAB1GcSwVUA3XjAd7HJNzOXT4wv6/H7KIdA/Nc60cvUlDbKApmqNvD1B1bzOt4nyA==
- dependencies:
- "@babel/helper-define-polyfill-provider" "^0.3.3"
- core-js-compat "^3.25.1"
-
-babel-plugin-polyfill-regenerator@^0.4.1:
- version "0.4.1"
- resolved "https://registry.yarnpkg.com/babel-plugin-polyfill-regenerator/-/babel-plugin-polyfill-regenerator-0.4.1.tgz#390f91c38d90473592ed43351e801a9d3e0fd747"
- integrity sha512-NtQGmyQDXjQqQ+IzRkBVwEOz9lQ4zxAQZgoAYEtU9dJjnl1Oc98qnN7jcp+bE7O7aYzVpavXE3/VKXNzUbh7aw==
- dependencies:
- "@babel/helper-define-polyfill-provider" "^0.3.3"
-
-babylon@^6.17.4:
- version "6.18.0"
- resolved "https://registry.yarnpkg.com/babylon/-/babylon-6.18.0.tgz#af2f3b88fa6f5c1e4c634d1a0f8eac4f55b395e3"
- integrity sha512-q/UEjfGJ2Cm3oKV71DJz9d25TPnq5rhBVL2Q4fA5wcC3jcrdn7+SssEybFIxwAvvP+YCsCYNKughoF33GxgycQ==
-
-balanced-match@^1.0.0:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/balanced-match/-/balanced-match-1.0.2.tgz#e83e3a7e3f300b34cb9d87f615fa0cbf357690ee"
- integrity sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==
-
-base64-js@^1.3.1:
- version "1.5.1"
- resolved "https://registry.yarnpkg.com/base64-js/-/base64-js-1.5.1.tgz#1b1b440160a5bf7ad40b650f095963481903930a"
- integrity sha512-AKpaYlHn8t4SVbOHCy+b5+KKgvR4vrsD8vbvrbiQJps7fKDTkjkDry6ji0rUJjC0kzbNePLwzxq8iypo41qeWA==
-
-base@^0.11.1:
- version "0.11.2"
- resolved "https://registry.yarnpkg.com/base/-/base-0.11.2.tgz#7bde5ced145b6d551a90db87f83c558b4eb48a8f"
- integrity sha512-5T6P4xPgpp0YDFvSWwEZ4NoE3aM4QBQXDzmVbraCkFj8zHM+mba8SyqB5DbZWyR7mYHo6Y7BdQo3MoA4m0TeQg==
- dependencies:
- cache-base "^1.0.1"
- class-utils "^0.3.5"
- component-emitter "^1.2.1"
- define-property "^1.0.0"
- isobject "^3.0.1"
- mixin-deep "^1.2.0"
- pascalcase "^0.1.1"
-
-bcrypt-pbkdf@^1.0.0:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/bcrypt-pbkdf/-/bcrypt-pbkdf-1.0.2.tgz#a4301d389b6a43f9b67ff3ca11a3f6637e360e9e"
- integrity sha512-qeFIXtP4MSoi6NLqO12WfqARWWuCKi2Rn/9hJLEmtB5yTNr9DqFWkJRCf2qShWzPeAMRnOgCrq0sg/KLv5ES9w==
- dependencies:
- tweetnacl "^0.14.3"
-
-big-integer@^1.6.17:
- version "1.6.51"
- resolved "https://registry.yarnpkg.com/big-integer/-/big-integer-1.6.51.tgz#0df92a5d9880560d3ff2d5fd20245c889d130686"
- integrity sha512-GPEid2Y9QU1Exl1rpO9B2IPJGHPSupF5GnVIP0blYvNOMer2bTvSWs1jGOUg04hTmu67nmLsQ9TBo1puaotBHg==
-
-bin-build@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/bin-build/-/bin-build-3.0.0.tgz#c5780a25a8a9f966d8244217e6c1f5082a143861"
- integrity sha512-jcUOof71/TNAI2uM5uoUaDq2ePcVBQ3R/qhxAz1rX7UfvduAL/RXD3jXzvn8cVcDJdGVkiR1shal3OH0ImpuhA==
- dependencies:
- decompress "^4.0.0"
- download "^6.2.2"
- execa "^0.7.0"
- p-map-series "^1.0.0"
- tempfile "^2.0.0"
-
-bin-check@^4.1.0:
- version "4.1.0"
- resolved "https://registry.yarnpkg.com/bin-check/-/bin-check-4.1.0.tgz#fc495970bdc88bb1d5a35fc17e65c4a149fc4a49"
- integrity sha512-b6weQyEUKsDGFlACWSIOfveEnImkJyK/FGW6FAG42loyoquvjdtOIqO6yBFzHyqyVVhNgNkQxxx09SFLK28YnA==
- dependencies:
- execa "^0.7.0"
- executable "^4.1.0"
-
-bin-version-check@^4.0.0:
- version "4.0.0"
- resolved "https://registry.yarnpkg.com/bin-version-check/-/bin-version-check-4.0.0.tgz#7d819c62496991f80d893e6e02a3032361608f71"
- integrity sha512-sR631OrhC+1f8Cvs8WyVWOA33Y8tgwjETNPyyD/myRBXLkfS/vl74FmH/lFcRl9KY3zwGh7jFhvyk9vV3/3ilQ==
- dependencies:
- bin-version "^3.0.0"
- semver "^5.6.0"
- semver-truncate "^1.1.2"
-
-bin-version@^3.0.0:
- version "3.1.0"
- resolved "https://registry.yarnpkg.com/bin-version/-/bin-version-3.1.0.tgz#5b09eb280752b1bd28f0c9db3f96f2f43b6c0839"
- integrity sha512-Mkfm4iE1VFt4xd4vH+gx+0/71esbfus2LsnCGe8Pi4mndSPyT+NGES/Eg99jx8/lUGWfu3z2yuB/bt5UB+iVbQ==
- dependencies:
- execa "^1.0.0"
- find-versions "^3.0.0"
-
-bin-wrapper@^4.0.0:
- version "4.1.0"
- resolved "https://registry.yarnpkg.com/bin-wrapper/-/bin-wrapper-4.1.0.tgz#99348f2cf85031e3ef7efce7e5300aeaae960605"
- integrity sha512-hfRmo7hWIXPkbpi0ZltboCMVrU+0ClXR/JgbCKKjlDjQf6igXa7OwdqNcFWQZPZTgiY7ZpzE3+LjjkLiTN2T7Q==
- dependencies:
- bin-check "^4.1.0"
- bin-version-check "^4.0.0"
- download "^7.1.0"
- import-lazy "^3.1.0"
- os-filter-obj "^2.0.0"
- pify "^4.0.1"
-
-binary-extensions@^2.0.0:
- version "2.2.0"
- resolved "https://registry.yarnpkg.com/binary-extensions/-/binary-extensions-2.2.0.tgz#75f502eeaf9ffde42fc98829645be4ea76bd9e2d"
- integrity sha512-jDctJ/IVQbZoJykoeHbhXpOlNBqGNcwXJKJog42E5HDPUwQTSdjCHdihjj0DlnheQ7blbT6dHOafNAiS8ooQKA==
-
-binary@~0.3.0:
- version "0.3.0"
- resolved "https://registry.yarnpkg.com/binary/-/binary-0.3.0.tgz#9f60553bc5ce8c3386f3b553cff47462adecaa79"
- integrity sha512-D4H1y5KYwpJgK8wk1Cue5LLPgmwHKYSChkbspQg5JtVuR5ulGckxfR62H3AE9UDkdMC8yyXlqYihuz3Aqg2XZg==
- dependencies:
- buffers "~0.1.1"
- chainsaw "~0.1.0"
-
-bl@^1.0.0:
- version "1.2.3"
- resolved "https://registry.yarnpkg.com/bl/-/bl-1.2.3.tgz#1e8dd80142eac80d7158c9dccc047fb620e035e7"
- integrity sha512-pvcNpa0UU69UT341rO6AYy4FVAIkUHuZXRIWbq+zHnsVcRzDDjIAhGuuYoi0d//cwIwtt4pkpKycWEfjdV+vww==
- dependencies:
- readable-stream "^2.3.5"
- safe-buffer "^5.1.1"
-
-bluebird@~3.4.1:
- version "3.4.7"
- resolved "https://registry.yarnpkg.com/bluebird/-/bluebird-3.4.7.tgz#f72d760be09b7f76d08ed8fae98b289a8d05fab3"
- integrity sha512-iD3898SR7sWVRHbiQv+sHUtHnMvC1o3nW5rAcqnq3uOn07DSAppZYUkIGslDz6gXC7HfunPe7YVBgoEJASPcHA==
-
-body-parser@1.20.1:
- version "1.20.1"
- resolved "https://registry.yarnpkg.com/body-parser/-/body-parser-1.20.1.tgz#b1812a8912c195cd371a3ee5e66faa2338a5c668"
- integrity sha512-jWi7abTbYwajOytWCQc37VulmWiRae5RyTpaCyDcS5/lMdtwSz5lOpDE67srw/HYe35f1z3fDQw+3txg7gNtWw==
- dependencies:
- bytes "3.1.2"
- content-type "~1.0.4"
- debug "2.6.9"
- depd "2.0.0"
- destroy "1.2.0"
- http-errors "2.0.0"
- iconv-lite "0.4.24"
- on-finished "2.4.1"
- qs "6.11.0"
- raw-body "2.5.1"
- type-is "~1.6.18"
- unpipe "1.0.0"
-
-body@^5.1.0:
- version "5.1.0"
- resolved "https://registry.yarnpkg.com/body/-/body-5.1.0.tgz#e4ba0ce410a46936323367609ecb4e6553125069"
- integrity sha512-chUsBxGRtuElD6fmw1gHLpvnKdVLK302peeFa9ZqAEk8TyzZ3fygLyUEDDPTJvL9+Bor0dIwn6ePOsRM2y0zQQ==
- dependencies:
- continuable-cache "^0.3.1"
- error "^7.0.0"
- raw-body "~1.1.0"
- safe-json-parse "~1.0.1"
-
-boolbase@^1.0.0, boolbase@~1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/boolbase/-/boolbase-1.0.0.tgz#68dff5fbe60c51eb37725ea9e3ed310dcc1e776e"
- integrity sha512-JZOSA7Mo9sNGB8+UjSgzdLtokWAky1zbztM3WRLCbZ70/3cTANmQmOdR7y2g+J0e2WXywy1yS468tY+IruqEww==
-
-brace-expansion@^1.0.0, brace-expansion@^1.1.7:
- version "1.1.11"
- resolved "https://registry.yarnpkg.com/brace-expansion/-/brace-expansion-1.1.11.tgz#3c7fcbf529d87226f3d2f52b966ff5271eb441dd"
- integrity sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==
- dependencies:
- balanced-match "^1.0.0"
- concat-map "0.0.1"
-
-braces@^2.3.1:
- version "2.3.2"
- resolved "https://registry.yarnpkg.com/braces/-/braces-2.3.2.tgz#5979fd3f14cd531565e5fa2df1abfff1dfaee729"
- integrity sha512-aNdbnj9P8PjdXU4ybaWLK2IF3jc/EoDYbC7AazW6to3TRsfXxscC9UXOB5iDiEQrkyIbWp2SLQda4+QAa7nc3w==
- dependencies:
- arr-flatten "^1.1.0"
- array-unique "^0.3.2"
- extend-shallow "^2.0.1"
- fill-range "^4.0.0"
- isobject "^3.0.1"
- repeat-element "^1.1.2"
- snapdragon "^0.8.1"
- snapdragon-node "^2.0.1"
- split-string "^3.0.2"
- to-regex "^3.0.1"
-
-braces@~3.0.2:
- version "3.0.2"
- resolved "https://registry.yarnpkg.com/braces/-/braces-3.0.2.tgz#3454e1a462ee8d599e236df336cd9ea4f8afe107"
- integrity sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==
- dependencies:
- fill-range "^7.0.1"
-
-browserslist@^4.0.0, browserslist@^4.12.0, browserslist@^4.21.3, browserslist@^4.21.4:
- version "4.21.4"
- resolved "https://registry.yarnpkg.com/browserslist/-/browserslist-4.21.4.tgz#e7496bbc67b9e39dd0f98565feccdcb0d4ff6987"
- integrity sha512-CBHJJdDmgjl3daYjN5Cp5kbTf1mUhZoS+beLklHIvkOWscs83YAhLlF3Wsh/lciQYAcbBJgTOD44VtG31ZM4Hw==
- dependencies:
- caniuse-lite "^1.0.30001400"
- electron-to-chromium "^1.4.251"
- node-releases "^2.0.6"
- update-browserslist-db "^1.0.9"
-
-buffer-alloc-unsafe@^1.1.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/buffer-alloc-unsafe/-/buffer-alloc-unsafe-1.1.0.tgz#bd7dc26ae2972d0eda253be061dba992349c19f0"
- integrity sha512-TEM2iMIEQdJ2yjPJoSIsldnleVaAk1oW3DBVUykyOLsEsFmEc9kn+SFFPz+gl54KQNxlDnAwCXosOS9Okx2xAg==
-
-buffer-alloc@^1.2.0:
- version "1.2.0"
- resolved "https://registry.yarnpkg.com/buffer-alloc/-/buffer-alloc-1.2.0.tgz#890dd90d923a873e08e10e5fd51a57e5b7cce0ec"
- integrity sha512-CFsHQgjtW1UChdXgbyJGtnm+O/uLQeZdtbDo8mfUgYXCHSM1wgrVxXm6bSyrUuErEb+4sYVGCzASBRot7zyrow==
- dependencies:
- buffer-alloc-unsafe "^1.1.0"
- buffer-fill "^1.0.0"
-
-buffer-crc32@~0.2.3:
- version "0.2.13"
- resolved "https://registry.yarnpkg.com/buffer-crc32/-/buffer-crc32-0.2.13.tgz#0d333e3f00eac50aa1454abd30ef8c2a5d9a7242"
- integrity sha512-VO9Ht/+p3SN7SKWqcrgEzjGbRSJYTx+Q1pTQC0wrWqHx0vpJraQ6GtHx8tvcg1rlK1byhU5gccxgOgj7B0TDkQ==
-
-buffer-fill@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/buffer-fill/-/buffer-fill-1.0.0.tgz#f8f78b76789888ef39f205cd637f68e702122b2c"
- integrity sha512-T7zexNBwiiaCOGDg9xNX9PBmjrubblRkENuptryuI64URkXDFum9il/JGL8Lm8wYfAXpredVXXZz7eMHilimiQ==
-
-buffer-from@^1.0.0:
- version "1.1.2"
- resolved "https://registry.yarnpkg.com/buffer-from/-/buffer-from-1.1.2.tgz#2b146a6fd72e80b4f55d255f35ed59a3a9a41bd5"
- integrity sha512-E+XQCRwSbaaiChtv6k6Dwgc+bx+Bs6vuKJHHl5kox/BaKbhiXzqQOwK4cO22yElGp2OCmjwVhT3HmxgyPGnJfQ==
-
-buffer-indexof-polyfill@~1.0.0:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/buffer-indexof-polyfill/-/buffer-indexof-polyfill-1.0.2.tgz#d2732135c5999c64b277fcf9b1abe3498254729c"
- integrity sha512-I7wzHwA3t1/lwXQh+A5PbNvJxgfo5r3xulgpYDB5zckTu/Z9oUK9biouBKQUjEqzaz3HnAT6TYoovmE+GqSf7A==
-
-buffer@^5.2.1:
- version "5.7.1"
- resolved "https://registry.yarnpkg.com/buffer/-/buffer-5.7.1.tgz#ba62e7c13133053582197160851a8f648e99eed0"
- integrity sha512-EHcyIPBQ4BSGlvjB16k5KgAJ27CIsHY/2JBmCRReo48y9rQ3MaUzWX3KVlBa4U7MyX02HdVj0K7C3WaB3ju7FQ==
- dependencies:
- base64-js "^1.3.1"
- ieee754 "^1.1.13"
-
-buffers@~0.1.1:
- version "0.1.1"
- resolved "https://registry.yarnpkg.com/buffers/-/buffers-0.1.1.tgz#b24579c3bed4d6d396aeee6d9a8ae7f5482ab7bb"
- integrity sha512-9q/rDEGSb/Qsvv2qvzIzdluL5k7AaJOTrw23z9reQthrbF7is4CtlT0DXyO1oei2DCp4uojjzQ7igaSHp1kAEQ==
-
-bytes@1:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/bytes/-/bytes-1.0.0.tgz#3569ede8ba34315fab99c3e92cb04c7220de1fa8"
- integrity sha512-/x68VkHLeTl3/Ll8IvxdwzhrT+IyKc52e/oyHhA2RwqPqswSnjVbSddfPRwAsJtbilMAPSRWwAlpxdYsSWOTKQ==
-
-bytes@3.1.2:
- version "3.1.2"
- resolved "https://registry.yarnpkg.com/bytes/-/bytes-3.1.2.tgz#8b0beeb98605adf1b128fa4386403c009e0221a5"
- integrity sha512-/Nf7TyzTx6S3yRJObOAV7956r8cr2+Oj8AC5dt8wSP3BQAoeX58NoHyCU8P8zGkNXStjTSi6fzO6F0pBdcYbEg==
-
-cache-base@^1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/cache-base/-/cache-base-1.0.1.tgz#0a7f46416831c8b662ee36fe4e7c59d76f666ab2"
- integrity sha512-AKcdTnFSWATd5/GCPRxr2ChwIJ85CeyrEyjRHlKxQ56d4XJMGym0uAiKn0xbLOGOl3+yRpOTi484dVCEc5AUzQ==
- dependencies:
- collection-visit "^1.0.0"
- component-emitter "^1.2.1"
- get-value "^2.0.6"
- has-value "^1.0.0"
- isobject "^3.0.1"
- set-value "^2.0.0"
- to-object-path "^0.3.0"
- union-value "^1.0.0"
- unset-value "^1.0.0"
-
-cacheable-request@^2.1.1:
- version "2.1.4"
- resolved "https://registry.yarnpkg.com/cacheable-request/-/cacheable-request-2.1.4.tgz#0d808801b6342ad33c91df9d0b44dc09b91e5c3d"
- integrity sha512-vag0O2LKZ/najSoUwDbVlnlCFvhBE/7mGTY2B5FgCBDcRD+oVV1HYTOwM6JZfMg/hIcM6IwnTZ1uQQL5/X3xIQ==
- dependencies:
- clone-response "1.0.2"
- get-stream "3.0.0"
- http-cache-semantics "3.8.1"
- keyv "3.0.0"
- lowercase-keys "1.0.0"
- normalize-url "2.0.1"
- responselike "1.0.2"
-
-call-bind@^1.0.0, call-bind@^1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/call-bind/-/call-bind-1.0.2.tgz#b1d4e89e688119c3c9a903ad30abb2f6a919be3c"
- integrity sha512-7O+FbCihrB5WGbFYesctwmTKae6rOiIzmz1icreWJ+0aA7LJfuqhEso2T9ncpcFtzMQtzXf2QGGueWJGTYsqrA==
- dependencies:
- function-bind "^1.1.1"
- get-intrinsic "^1.0.2"
-
-call-me-maybe@^1.0.1:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/call-me-maybe/-/call-me-maybe-1.0.2.tgz#03f964f19522ba643b1b0693acb9152fe2074baa"
- integrity sha512-HpX65o1Hnr9HH25ojC1YGs7HCQLq0GCOibSaWER0eNpgJ/Z1MZv2mTc7+xh6WOPxbRVcmgbv4hGU+uSQ/2xFZQ==
-
-caller-callsite@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/caller-callsite/-/caller-callsite-2.0.0.tgz#847e0fce0a223750a9a027c54b33731ad3154134"
- integrity sha512-JuG3qI4QOftFsZyOn1qq87fq5grLIyk1JYd5lJmdA+fG7aQ9pA/i3JIJGcO3q0MrRcHlOt1U+ZeHW8Dq9axALQ==
- dependencies:
- callsites "^2.0.0"
-
-caller-path@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/caller-path/-/caller-path-2.0.0.tgz#468f83044e369ab2010fac5f06ceee15bb2cb1f4"
- integrity sha512-MCL3sf6nCSXOwCTzvPKhN18TU7AHTvdtam8DAogxcrJ8Rjfbbg7Lgng64H9Iy+vUV6VGFClN/TyxBkAebLRR4A==
- dependencies:
- caller-callsite "^2.0.0"
-
-callsites@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/callsites/-/callsites-2.0.0.tgz#06eb84f00eea413da86affefacbffb36093b3c50"
- integrity sha512-ksWePWBloaWPxJYQ8TL0JHvtci6G5QTKwQ95RcWAa/lzoAKuAOflGdAK92hpHXjkwb8zLxoLNUoNYZgVsaJzvQ==
-
-camelcase-keys@^2.0.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/camelcase-keys/-/camelcase-keys-2.1.0.tgz#308beeaffdf28119051efa1d932213c91b8f92e7"
- integrity sha512-bA/Z/DERHKqoEOrp+qeGKw1QlvEQkGZSc0XaY6VnTxZr+Kv1G5zFwttpjv8qxZ/sBPT4nthwZaAcsAZTJlSKXQ==
- dependencies:
- camelcase "^2.0.0"
- map-obj "^1.0.0"
-
-camelcase@^2.0.0:
- version "2.1.1"
- resolved "https://registry.yarnpkg.com/camelcase/-/camelcase-2.1.1.tgz#7c1d16d679a1bbe59ca02cacecfb011e201f5a1f"
- integrity sha512-DLIsRzJVBQu72meAKPkWQOLcujdXT32hwdfnkI1frSiSRMK1MofjKHf+MEx0SB6fjEFXL8fBDv1dKymBlOp4Qw==
-
-caniuse-api@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/caniuse-api/-/caniuse-api-3.0.0.tgz#5e4d90e2274961d46291997df599e3ed008ee4c0"
- integrity sha512-bsTwuIg/BZZK/vreVTYYbSWoe2F+71P7K5QGEX+pT250DZbfU1MQ5prOKpPR+LL6uWKK3KMwMCAS74QB3Um1uw==
- dependencies:
- browserslist "^4.0.0"
- caniuse-lite "^1.0.0"
- lodash.memoize "^4.1.2"
- lodash.uniq "^4.5.0"
-
-caniuse-lite@^1.0.0, caniuse-lite@^1.0.30001109, caniuse-lite@^1.0.30001400:
- version "1.0.30001431"
- resolved "https://registry.yarnpkg.com/caniuse-lite/-/caniuse-lite-1.0.30001431.tgz#e7c59bd1bc518fae03a4656be442ce6c4887a795"
- integrity sha512-zBUoFU0ZcxpvSt9IU66dXVT/3ctO1cy4y9cscs1szkPlcWb6pasYM144GqrUygUbT+k7cmUCW61cvskjcv0enQ==
-
-caseless@~0.12.0:
- version "0.12.0"
- resolved "https://registry.yarnpkg.com/caseless/-/caseless-0.12.0.tgz#1b681c21ff84033c826543090689420d187151dc"
- integrity sha512-4tYFyifaFfGacoiObjJegolkwSU4xQNGbVgUiNYVUxbQ2x2lUsFvY4hVgVzGiIe6WLOPqycWXA40l+PWsxthUw==
-
-caw@^2.0.0, caw@^2.0.1:
- version "2.0.1"
- resolved "https://registry.yarnpkg.com/caw/-/caw-2.0.1.tgz#6c3ca071fc194720883c2dc5da9b074bfc7e9e95"
- integrity sha512-Cg8/ZSBEa8ZVY9HspcGUYaK63d/bN7rqS3CYCzEGUxuYv6UlmcjzDUz2fCFFHyTvUW5Pk0I+3hkA3iXlIj6guA==
- dependencies:
- get-proxy "^2.0.0"
- isurl "^1.0.0-alpha5"
- tunnel-agent "^0.6.0"
- url-to-options "^1.0.1"
-
-chainsaw@~0.1.0:
- version "0.1.0"
- resolved "https://registry.yarnpkg.com/chainsaw/-/chainsaw-0.1.0.tgz#5eab50b28afe58074d0d58291388828b5e5fbc98"
- integrity sha512-75kWfWt6MEKNC8xYXIdRpDehRYY/tNSgwKaJq+dbbDcxORuVrrQ+SEHoWsniVn9XPYfP4gmdWIeDk/4YNp1rNQ==
- dependencies:
- traverse ">=0.3.0 <0.4"
-
-chalk@1.1.3, chalk@^1.0.0, chalk@^1.1.3:
- version "1.1.3"
- resolved "https://registry.yarnpkg.com/chalk/-/chalk-1.1.3.tgz#a8115c55e4a702fe4d150abd3872822a7e09fc98"
- integrity sha512-U3lRVLMSlsCfjqYPbLyVv11M9CPW4I728d6TCKMAOJueEeB9/8o+eSsMnxPJD+Q+K909sdESg7C+tIkoH6on1A==
- dependencies:
- ansi-styles "^2.2.1"
- escape-string-regexp "^1.0.2"
- has-ansi "^2.0.0"
- strip-ansi "^3.0.0"
- supports-color "^2.0.0"
-
-chalk@^2.0.0, chalk@^2.4.1, chalk@^2.4.2:
- version "2.4.2"
- resolved "https://registry.yarnpkg.com/chalk/-/chalk-2.4.2.tgz#cd42541677a54333cf541a49108c1432b44c9424"
- integrity sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ==
- dependencies:
- ansi-styles "^3.2.1"
- escape-string-regexp "^1.0.5"
- supports-color "^5.3.0"
-
-chardet@^0.4.0:
- version "0.4.2"
- resolved "https://registry.yarnpkg.com/chardet/-/chardet-0.4.2.tgz#b5473b33dc97c424e5d98dc87d55d4d8a29c8bf2"
- integrity sha512-j/Toj7f1z98Hh2cYo2BVr85EpIRWqUi7rtRSGxh/cqUjqrnJe9l9UE7IUGd2vQ2p+kSHLkSzObQPZPLUC6TQwg==
-
-cheerio@0.22.0:
- version "0.22.0"
- resolved "https://registry.yarnpkg.com/cheerio/-/cheerio-0.22.0.tgz#a9baa860a3f9b595a6b81b1a86873121ed3a269e"
- integrity sha512-8/MzidM6G/TgRelkzDG13y3Y9LxBjCb+8yOEZ9+wwq5gVF2w2pV0wmHvjfT0RvuxGyR7UEuK36r+yYMbT4uKgA==
- dependencies:
- css-select "~1.2.0"
- dom-serializer "~0.1.0"
- entities "~1.1.1"
- htmlparser2 "^3.9.1"
- lodash.assignin "^4.0.9"
- lodash.bind "^4.1.4"
- lodash.defaults "^4.0.1"
- lodash.filter "^4.4.0"
- lodash.flatten "^4.2.0"
- lodash.foreach "^4.3.0"
- lodash.map "^4.4.0"
- lodash.merge "^4.4.0"
- lodash.pick "^4.2.1"
- lodash.reduce "^4.4.0"
- lodash.reject "^4.4.0"
- lodash.some "^4.4.0"
-
-chokidar@^3.0.1:
- version "3.5.3"
- resolved "https://registry.yarnpkg.com/chokidar/-/chokidar-3.5.3.tgz#1cf37c8707b932bd1af1ae22c0432e2acd1903bd"
- integrity sha512-Dr3sfKRP6oTcjf2JmUmFJfeVMvXBdegxB0iVQ5eb2V10uFJUCAS8OByZdVAyVb8xXNz3GjjTgj9kLWsZTqE6kw==
- dependencies:
- anymatch "~3.1.2"
- braces "~3.0.2"
- glob-parent "~5.1.2"
- is-binary-path "~2.1.0"
- is-glob "~4.0.1"
- normalize-path "~3.0.0"
- readdirp "~3.6.0"
- optionalDependencies:
- fsevents "~2.3.2"
-
-class-utils@^0.3.5:
- version "0.3.6"
- resolved "https://registry.yarnpkg.com/class-utils/-/class-utils-0.3.6.tgz#f93369ae8b9a7ce02fd41faad0ca83033190c463"
- integrity sha512-qOhPa/Fj7s6TY8H8esGu5QNpMMQxz79h+urzrNYN6mn+9BnxlDGf5QZ+XeCDsxSjPqsSR56XOZOJmpeurnLMeg==
- dependencies:
- arr-union "^3.1.0"
- define-property "^0.2.5"
- isobject "^3.0.0"
- static-extend "^0.1.1"
-
-classnames@^2.2.6:
- version "2.3.2"
- resolved "https://registry.yarnpkg.com/classnames/-/classnames-2.3.2.tgz#351d813bf0137fcc6a76a16b88208d2560a0d924"
- integrity sha512-CSbhY4cFEJRe6/GQzIk5qXZ4Jeg5pcsP7b5peFSDpffpe1cqjASH/n9UTjBwOp6XpMSTwQ8Za2K5V02ueA7Tmw==
-
-cli-cursor@^2.1.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/cli-cursor/-/cli-cursor-2.1.0.tgz#b35dac376479facc3e94747d41d0d0f5238ffcb5"
- integrity sha512-8lgKz8LmCRYZZQDpRyT2m5rKJ08TnU4tR9FFFW2rxpxR1FzWi4PQ/NfyODchAatHaUgnSPVcx/R5w6NuTBzFiw==
- dependencies:
- restore-cursor "^2.0.0"
-
-cli-width@^2.0.0:
- version "2.2.1"
- resolved "https://registry.yarnpkg.com/cli-width/-/cli-width-2.2.1.tgz#b0433d0b4e9c847ef18868a4ef16fd5fc8271c48"
- integrity sha512-GRMWDxpOB6Dgk2E5Uo+3eEBvtOOlimMmpbFiKuLFnQzYDavtLFY3K5ona41jgN/WdRZtG7utuVSVTL4HbZHGkw==
-
-clone-deep@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/clone-deep/-/clone-deep-4.0.1.tgz#c19fd9bdbbf85942b4fd979c84dcf7d5f07c2387"
- integrity sha512-neHB9xuzh/wk0dIHweyAXv2aPGZIVk3pLMe+/RNzINf17fe0OG96QroktYAUm7SM1PBnzTabaLboqqxDyMU+SQ==
- dependencies:
- is-plain-object "^2.0.4"
- kind-of "^6.0.2"
- shallow-clone "^3.0.0"
-
-clone-response@1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/clone-response/-/clone-response-1.0.2.tgz#d1dc973920314df67fbeb94223b4ee350239e96b"
- integrity sha512-yjLXh88P599UOyPTFX0POsd7WxnbsVsGohcwzHOLspIhhpalPw1BcqED8NblyZLKcGrL8dTgMlcaZxV2jAD41Q==
- dependencies:
- mimic-response "^1.0.0"
-
-coa@^2.0.2:
- version "2.0.2"
- resolved "https://registry.yarnpkg.com/coa/-/coa-2.0.2.tgz#43f6c21151b4ef2bf57187db0d73de229e3e7ec3"
- integrity sha512-q5/jG+YQnSy4nRTV4F7lPepBJZ8qBNJJDBuJdoejDyLXgmL7IEo+Le2JDZudFTFt7mrCqIRaSjws4ygRCTCAXA==
- dependencies:
- "@types/q" "^1.5.1"
- chalk "^2.4.1"
- q "^1.1.2"
-
-coffee-script@^1.12.4:
- version "1.12.7"
- resolved "https://registry.yarnpkg.com/coffee-script/-/coffee-script-1.12.7.tgz#c05dae0cb79591d05b3070a8433a98c9a89ccc53"
- integrity sha512-fLeEhqwymYat/MpTPUjSKHVYYl0ec2mOyALEMLmzr5i1isuG+6jfI2j2d5oBO3VIzgUXgBVIcOT9uH1TFxBckw==
-
-collection-visit@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/collection-visit/-/collection-visit-1.0.0.tgz#4bc0373c164bc3291b4d368c829cf1a80a59dca0"
- integrity sha512-lNkKvzEeMBBjUGHZ+q6z9pSJla0KWAQPvtzhEV9+iGyQYG+pBpl7xKDhxoNSOZH2hhv0v5k0y2yAM4o4SjoSkw==
- dependencies:
- map-visit "^1.0.0"
- object-visit "^1.0.0"
-
-color-convert@^1.9.0, color-convert@^1.9.1, color-convert@^1.9.3:
- version "1.9.3"
- resolved "https://registry.yarnpkg.com/color-convert/-/color-convert-1.9.3.tgz#bb71850690e1f136567de629d2d5471deda4c1e8"
- integrity sha512-QfAUtd+vFdAtFQcC8CCyYt1fYWxSqAiK2cSD6zDB8N3cpsEBAvRxp9zOGg6G/SHHJYAT88/az/IuDGALsNVbGg==
- dependencies:
- color-name "1.1.3"
-
-color-name@1.1.3:
- version "1.1.3"
- resolved "https://registry.yarnpkg.com/color-name/-/color-name-1.1.3.tgz#a7d0558bd89c42f795dd42328f740831ca53bc25"
- integrity sha512-72fSenhMw2HZMTVHeCA9KCmpEIbzWiQsjN+BHcBbS9vr1mtt+vJjPdksIBNUmKAW8TFUDPJK5SUU3QhE9NEXDw==
-
-color-name@^1.0.0:
- version "1.1.4"
- resolved "https://registry.yarnpkg.com/color-name/-/color-name-1.1.4.tgz#c2a09a87acbde69543de6f63fa3995c826c536a2"
- integrity sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==
-
-color-string@^1.5.2, color-string@^1.6.0:
- version "1.9.1"
- resolved "https://registry.yarnpkg.com/color-string/-/color-string-1.9.1.tgz#4467f9146f036f855b764dfb5bf8582bf342c7a4"
- integrity sha512-shrVawQFojnZv6xM40anx4CkoDP+fZsw/ZerEMsW/pyzsRbElpsL/DBVW7q3ExxwusdNXI3lXpuhEZkzs8p5Eg==
- dependencies:
- color-name "^1.0.0"
- simple-swizzle "^0.2.2"
-
-color@^2.0.1:
- version "2.0.1"
- resolved "https://registry.yarnpkg.com/color/-/color-2.0.1.tgz#e4ed78a3c4603d0891eba5430b04b86314f4c839"
- integrity sha512-ubUCVVKfT7r2w2D3qtHakj8mbmKms+tThR8gI8zEYCbUBl8/voqFGt3kgBqGwXAopgXybnkuOq+qMYCRrp4cXw==
- dependencies:
- color-convert "^1.9.1"
- color-string "^1.5.2"
-
-color@^3.0.0:
- version "3.2.1"
- resolved "https://registry.yarnpkg.com/color/-/color-3.2.1.tgz#3544dc198caf4490c3ecc9a790b54fe9ff45e164"
- integrity sha512-aBl7dZI9ENN6fUGC7mWpMTPNHmWUSNan9tuWN6ahh5ZLNk9baLJOnSMlrQkHcrfFgz2/RigjUVAjdx36VcemKA==
- dependencies:
- color-convert "^1.9.3"
- color-string "^1.6.0"
-
-combined-stream@^1.0.6, combined-stream@~1.0.6:
- version "1.0.8"
- resolved "https://registry.yarnpkg.com/combined-stream/-/combined-stream-1.0.8.tgz#c3d45a8b34fd730631a110a8a2520682b31d5a7f"
- integrity sha512-FQN4MRfuJeHf7cBbBMJFXhKSDq+2kAArBlmRBvcvFE5BB1HZKXtSFASDhdlz9zOYwxh8lDdnvmMOe/+5cdoEdg==
- dependencies:
- delayed-stream "~1.0.0"
-
-commander@^2.20.0, commander@^2.8.1:
- version "2.20.3"
- resolved "https://registry.yarnpkg.com/commander/-/commander-2.20.3.tgz#fd485e84c03eb4881c20722ba48035e8531aeb33"
- integrity sha512-GpVkmM8vF2vQUkj2LvZmD35JxeJOLCwJ9cUkugyk2nuhbv3+mJvpLYYt+0+USMxE+oj+ey/lJEnhZw75x/OMcQ==
-
-commander@^5.0.0:
- version "5.1.0"
- resolved "https://registry.yarnpkg.com/commander/-/commander-5.1.0.tgz#46abbd1652f8e059bddaef99bbdcb2ad9cf179ae"
- integrity sha512-P0CysNDQ7rtVw4QIQtm+MRxV66vKFSvlsQvGYXZWR3qFU0jlMKHZZZgw8e+8DSah4UDKMqnknRDQz+xuQXQ/Zg==
-
-commondir@^1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/commondir/-/commondir-1.0.1.tgz#ddd800da0c66127393cca5950ea968a3aaf1253b"
- integrity sha512-W9pAhw0ja1Edb5GVdIF1mjZw/ASI0AlShXM83UUGe2DVr5TdAPEA1OA8m/g8zWp9x6On7gqufY+FatDbC3MDQg==
-
-component-emitter@^1.2.1:
- version "1.3.0"
- resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.3.0.tgz#16e4070fba8ae29b679f2215853ee181ab2eabc0"
- integrity sha512-Rd3se6QB+sO1TwqZjscQrurpEPIfO0/yYnSin6Q/rD3mOutHvUrCAhJub3r90uNb+SESBuE0QYoB90YdfatsRg==
-
-concat-map@0.0.1:
- version "0.0.1"
- resolved "https://registry.yarnpkg.com/concat-map/-/concat-map-0.0.1.tgz#d8a96bd77fd68df7793a73036a3ba0d5405d477b"
- integrity sha512-/Srv4dswyQNBfohGpz9o6Yb3Gz3SrUDqBH5rTuhGR7ahtlbYKnVxw2bCFMRljaA7EXHaXZ8wsHdodFvbkhKmqg==
-
-concat-stream@^1.5.2:
- version "1.6.2"
- resolved "https://registry.yarnpkg.com/concat-stream/-/concat-stream-1.6.2.tgz#904bdf194cd3122fc675c77fc4ac3d4ff0fd1a34"
- integrity sha512-27HBghJxjiZtIk3Ycvn/4kbJk/1uZuJFfuPEns6LaEvpvG1f0hTea8lilrouyo9mVc2GWdcEZ8OLoGmSADlrCw==
- dependencies:
- buffer-from "^1.0.0"
- inherits "^2.0.3"
- readable-stream "^2.2.2"
- typedarray "^0.0.6"
-
-concat-with-sourcemaps@*:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/concat-with-sourcemaps/-/concat-with-sourcemaps-1.1.0.tgz#d4ea93f05ae25790951b99e7b3b09e3908a4082e"
- integrity sha512-4gEjHJFT9e+2W/77h/DS5SGUgwDaOwprX8L/gl5+3ixnzkVJJsZWDSelmN3Oilw3LNDZjZV0yqH1hLG3k6nghg==
- dependencies:
- source-map "^0.6.1"
-
-config-chain@^1.1.11:
- version "1.1.13"
- resolved "https://registry.yarnpkg.com/config-chain/-/config-chain-1.1.13.tgz#fad0795aa6a6cdaff9ed1b68e9dff94372c232f4"
- integrity sha512-qj+f8APARXHrM0hraqXYb2/bOVSV4PvJQlNZ/DVj0QrmNM2q2euizkeuVckQ57J+W0mRH6Hvi+k50M4Jul2VRQ==
- dependencies:
- ini "^1.3.4"
- proto-list "~1.2.1"
-
-console-stream@^0.1.1:
- version "0.1.1"
- resolved "https://registry.yarnpkg.com/console-stream/-/console-stream-0.1.1.tgz#a095fe07b20465955f2fafd28b5d72bccd949d44"
- integrity sha512-QC/8l9e6ofi6nqZ5PawlDgzmMw3OxIXtvolBzap/F4UDBJlDaZRSNbL/lb41C29FcbSJncBFlJFj2WJoNyZRfQ==
-
-content-disposition@0.5.4, content-disposition@^0.5.2:
- version "0.5.4"
- resolved "https://registry.yarnpkg.com/content-disposition/-/content-disposition-0.5.4.tgz#8b82b4efac82512a02bb0b1dcec9d2c5e8eb5bfe"
- integrity sha512-FveZTNuGw04cxlAiWbzi6zTAL/lhehaWbTtgluJh4/E95DqMwTmha3KZN1aAWA8cFIhHzMZUvLevkw5Rqk+tSQ==
- dependencies:
- safe-buffer "5.2.1"
-
-content-type@~1.0.4:
- version "1.0.4"
- resolved "https://registry.yarnpkg.com/content-type/-/content-type-1.0.4.tgz#e138cc75e040c727b1966fe5e5f8c9aee256fe3b"
- integrity sha512-hIP3EEPs8tB9AT1L+NUqtwOAps4mk2Zob89MWXMHjHWg9milF/j4osnnQLXBCBFBk/tvIG/tUc9mOUJiPBhPXA==
-
-continuable-cache@^0.3.1:
- version "0.3.1"
- resolved "https://registry.yarnpkg.com/continuable-cache/-/continuable-cache-0.3.1.tgz#bd727a7faed77e71ff3985ac93351a912733ad0f"
- integrity sha512-TF30kpKhTH8AGCG3dut0rdd/19B7Z+qCnrMoBLpyQu/2drZdNrrpcjPEoJeSVsQM+8KmWG5O56oPDjSSUsuTyA==
-
-convert-source-map@^1.7.0:
- version "1.9.0"
- resolved "https://registry.yarnpkg.com/convert-source-map/-/convert-source-map-1.9.0.tgz#7faae62353fb4213366d0ca98358d22e8368b05f"
- integrity sha512-ASFBup0Mz1uyiIjANan1jzLQami9z1PoYSZCiiYW2FczPbenXc45FZdBZLzOT+r6+iciuEModtmCti+hjaAk0A==
-
-cookie-signature@1.0.6:
- version "1.0.6"
- resolved "https://registry.yarnpkg.com/cookie-signature/-/cookie-signature-1.0.6.tgz#e303a882b342cc3ee8ca513a79999734dab3ae2c"
- integrity sha512-QADzlaHc8icV8I7vbaJXJwod9HWYp8uCqf1xa4OfNu1T7JVxQIrUgOWtHdNDtPiywmFbiS12VjotIXLrKM3orQ==
-
-cookie@0.5.0:
- version "0.5.0"
- resolved "https://registry.yarnpkg.com/cookie/-/cookie-0.5.0.tgz#d1f5d71adec6558c58f389987c366aa47e994f8b"
- integrity sha512-YZ3GUyn/o8gfKJlnlX7g7xq4gyO6OSuhGPKaaGssGB2qgDUS0gPgtTvoyZLTt9Ab6dC4hfc9dV5arkvc/OCmrw==
-
-copy-descriptor@^0.1.0:
- version "0.1.1"
- resolved "https://registry.yarnpkg.com/copy-descriptor/-/copy-descriptor-0.1.1.tgz#676f6eb3c39997c2ee1ac3a924fd6124748f578d"
- integrity sha512-XgZ0pFcakEUlbwQEVNg3+QAis1FyTL3Qel9FYy8pSkQqoG3PNoT0bOCQtOXcOkur21r2Eq2kI+IE+gsmAEVlYw==
-
-core-js-compat@^3.25.1:
- version "3.26.1"
- resolved "https://registry.yarnpkg.com/core-js-compat/-/core-js-compat-3.26.1.tgz#0e710b09ebf689d719545ac36e49041850f943df"
- integrity sha512-622/KzTudvXCDLRw70iHW4KKs1aGpcRcowGWyYJr2DEBfRrd6hNJybxSWJFuZYD4ma86xhrwDDHxmDaIq4EA8A==
- dependencies:
- browserslist "^4.21.4"
-
-core-js@^2.6.5:
- version "2.6.12"
- resolved "https://registry.yarnpkg.com/core-js/-/core-js-2.6.12.tgz#d9333dfa7b065e347cc5682219d6f690859cc2ec"
- integrity sha512-Kb2wC0fvsWfQrgk8HU5lW6U/Lcs8+9aaYcy4ZFc6DDlo4nZ7n70dEgE5rtR0oG6ufKDUnrwfWL1mXR5ljDatrQ==
-
-core-util-is@1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/core-util-is/-/core-util-is-1.0.2.tgz#b5fd54220aa2bc5ab57aab7140c940754503c1a7"
- integrity sha512-3lqz5YjWTYnW6dlDa5TLaTCcShfar1e40rmcJVwCBJC6mWlFuj0eCHIElmG1g5kyuJ/GD+8Wn4FFCcz4gJPfaQ==
-
-core-util-is@~1.0.0:
- version "1.0.3"
- resolved "https://registry.yarnpkg.com/core-util-is/-/core-util-is-1.0.3.tgz#a6042d3634c2b27e9328f837b965fac83808db85"
- integrity sha512-ZQBvi1DcpJ4GDqanjucZ2Hj3wEO5pZDS89BWbkcrvdxksJorwUDDZamX9ldFkp9aw2lmBDLgkObEA4DWNJ9FYQ==
-
-cosmiconfig@^5.0.0:
- version "5.2.1"
- resolved "https://registry.yarnpkg.com/cosmiconfig/-/cosmiconfig-5.2.1.tgz#040f726809c591e77a17c0a3626ca45b4f168b1a"
- integrity sha512-H65gsXo1SKjf8zmrJ67eJk8aIRKV5ff2D4uKZIBZShbhGSpEmsQOPW/SKMKYhSTrqR7ufy6RP69rPogdaPh/kA==
- dependencies:
- import-fresh "^2.0.0"
- is-directory "^0.3.1"
- js-yaml "^3.13.1"
- parse-json "^4.0.0"
-
-cross-spawn@5.1.0, cross-spawn@^5.0.1:
- version "5.1.0"
- resolved "https://registry.yarnpkg.com/cross-spawn/-/cross-spawn-5.1.0.tgz#e8bd0efee58fcff6f8f94510a0a554bbfa235449"
- integrity sha512-pTgQJ5KC0d2hcY8eyL1IzlBPYjTkyH72XRZPnLyKus2mBfNjQs3klqbJU2VILqZryAZUt9JOb3h/mWMy23/f5A==
- dependencies:
- lru-cache "^4.0.1"
- shebang-command "^1.2.0"
- which "^1.2.9"
-
-cross-spawn@^6.0.0, cross-spawn@^6.0.5:
- version "6.0.5"
- resolved "https://registry.yarnpkg.com/cross-spawn/-/cross-spawn-6.0.5.tgz#4a5ec7c64dfae22c3a14124dbacdee846d80cbc4"
- integrity sha512-eTVLrBSt7fjbDygz805pMnstIs2VTBNkRm0qxZd+M7A5XDdxVRWO5MxGBXZhjY4cqLYLdtrGqRf8mBPmzwSpWQ==
- dependencies:
- nice-try "^1.0.4"
- path-key "^2.0.1"
- semver "^5.5.0"
- shebang-command "^1.2.0"
- which "^1.2.9"
-
-crowdin-cli@^0.3.0:
- version "0.3.0"
- resolved "https://registry.yarnpkg.com/crowdin-cli/-/crowdin-cli-0.3.0.tgz#eac9989a6fe7feaaf33090397afc187c67b46191"
- integrity sha512-s1vSRqWalCqd+vW7nF4oZo1a2pMpEgwIiwVlPRD0HmGY3HjJwQKXqZ26NpX5qCDVN8UdEsScy+2jle0PPQBmAg==
- dependencies:
- request "^2.53.0"
- yamljs "^0.2.1"
- yargs "^2.3.0"
-
-css-color-names@0.0.4, css-color-names@^0.0.4:
- version "0.0.4"
- resolved "https://registry.yarnpkg.com/css-color-names/-/css-color-names-0.0.4.tgz#808adc2e79cf84738069b646cb20ec27beb629e0"
- integrity sha512-zj5D7X1U2h2zsXOAM8EyUREBnnts6H+Jm+d1M2DbiQQcUtnqgQsMrdo8JW9R80YFUmIdBZeMu5wvYM7hcgWP/Q==
-
-css-declaration-sorter@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/css-declaration-sorter/-/css-declaration-sorter-4.0.1.tgz#c198940f63a76d7e36c1e71018b001721054cb22"
- integrity sha512-BcxQSKTSEEQUftYpBVnsH4SF05NTuBokb19/sBt6asXGKZ/6VP7PLG1CBCkFDYOnhXhPh0jMhO6xZ71oYHXHBA==
- dependencies:
- postcss "^7.0.1"
- timsort "^0.3.0"
-
-css-select-base-adapter@^0.1.1:
- version "0.1.1"
- resolved "https://registry.yarnpkg.com/css-select-base-adapter/-/css-select-base-adapter-0.1.1.tgz#3b2ff4972cc362ab88561507a95408a1432135d7"
- integrity sha512-jQVeeRG70QI08vSTwf1jHxp74JoZsr2XSgETae8/xC8ovSnL2WF87GTLO86Sbwdt2lK4Umg4HnnwMO4YF3Ce7w==
-
-css-select@^2.0.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/css-select/-/css-select-2.1.0.tgz#6a34653356635934a81baca68d0255432105dbef"
- integrity sha512-Dqk7LQKpwLoH3VovzZnkzegqNSuAziQyNZUcrdDM401iY+R5NkGBXGmtO05/yaXQziALuPogeG0b7UAgjnTJTQ==
- dependencies:
- boolbase "^1.0.0"
- css-what "^3.2.1"
- domutils "^1.7.0"
- nth-check "^1.0.2"
-
-css-select@~1.2.0:
- version "1.2.0"
- resolved "https://registry.yarnpkg.com/css-select/-/css-select-1.2.0.tgz#2b3a110539c5355f1cd8d314623e870b121ec858"
- integrity sha512-dUQOBoqdR7QwV90WysXPLXG5LO7nhYBgiWVfxF80DKPF8zx1t/pUd2FYy73emg3zrjtM6dzmYgbHKfV2rxiHQA==
- dependencies:
- boolbase "~1.0.0"
- css-what "2.1"
- domutils "1.5.1"
- nth-check "~1.0.1"
-
-css-tree@1.0.0-alpha.37:
- version "1.0.0-alpha.37"
- resolved "https://registry.yarnpkg.com/css-tree/-/css-tree-1.0.0-alpha.37.tgz#98bebd62c4c1d9f960ec340cf9f7522e30709a22"
- integrity sha512-DMxWJg0rnz7UgxKT0Q1HU/L9BeJI0M6ksor0OgqOnF+aRCDWg/N2641HmVyU9KVIu0OVVWOb2IpC9A+BJRnejg==
- dependencies:
- mdn-data "2.0.4"
- source-map "^0.6.1"
-
-css-tree@^1.1.2:
- version "1.1.3"
- resolved "https://registry.yarnpkg.com/css-tree/-/css-tree-1.1.3.tgz#eb4870fb6fd7707327ec95c2ff2ab09b5e8db91d"
- integrity sha512-tRpdppF7TRazZrjJ6v3stzv93qxRcSsFmW6cX0Zm2NVKpxE1WV1HblnghVv9TreireHkqI/VDEsfolRF1p6y7Q==
- dependencies:
- mdn-data "2.0.14"
- source-map "^0.6.1"
-
-css-what@2.1:
- version "2.1.3"
- resolved "https://registry.yarnpkg.com/css-what/-/css-what-2.1.3.tgz#a6d7604573365fe74686c3f311c56513d88285f2"
- integrity sha512-a+EPoD+uZiNfh+5fxw2nO9QwFa6nJe2Or35fGY6Ipw1R3R4AGz1d1TEZrCegvw2YTmZ0jXirGYlzxxpYSHwpEg==
-
-css-what@^3.2.1:
- version "3.4.2"
- resolved "https://registry.yarnpkg.com/css-what/-/css-what-3.4.2.tgz#ea7026fcb01777edbde52124e21f327e7ae950e4"
- integrity sha512-ACUm3L0/jiZTqfzRM3Hi9Q8eZqd6IK37mMWPLz9PJxkLWllYeRf+EHUSHYEtFop2Eqytaq1FizFVh7XfBnXCDQ==
-
-cssesc@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/cssesc/-/cssesc-3.0.0.tgz#37741919903b868565e1c09ea747445cd18983ee"
- integrity sha512-/Tb/JcjK111nNScGob5MNtsntNM1aCNUDipB/TkwZFhyDrrE47SOx/18wF2bbjgc3ZzCSKW1T5nt5EbFoAz/Vg==
-
-cssnano-preset-default@^4.0.8:
- version "4.0.8"
- resolved "https://registry.yarnpkg.com/cssnano-preset-default/-/cssnano-preset-default-4.0.8.tgz#920622b1fc1e95a34e8838203f1397a504f2d3ff"
- integrity sha512-LdAyHuq+VRyeVREFmuxUZR1TXjQm8QQU/ktoo/x7bz+SdOge1YKc5eMN6pRW7YWBmyq59CqYba1dJ5cUukEjLQ==
- dependencies:
- css-declaration-sorter "^4.0.1"
- cssnano-util-raw-cache "^4.0.1"
- postcss "^7.0.0"
- postcss-calc "^7.0.1"
- postcss-colormin "^4.0.3"
- postcss-convert-values "^4.0.1"
- postcss-discard-comments "^4.0.2"
- postcss-discard-duplicates "^4.0.2"
- postcss-discard-empty "^4.0.1"
- postcss-discard-overridden "^4.0.1"
- postcss-merge-longhand "^4.0.11"
- postcss-merge-rules "^4.0.3"
- postcss-minify-font-values "^4.0.2"
- postcss-minify-gradients "^4.0.2"
- postcss-minify-params "^4.0.2"
- postcss-minify-selectors "^4.0.2"
- postcss-normalize-charset "^4.0.1"
- postcss-normalize-display-values "^4.0.2"
- postcss-normalize-positions "^4.0.2"
- postcss-normalize-repeat-style "^4.0.2"
- postcss-normalize-string "^4.0.2"
- postcss-normalize-timing-functions "^4.0.2"
- postcss-normalize-unicode "^4.0.1"
- postcss-normalize-url "^4.0.1"
- postcss-normalize-whitespace "^4.0.2"
- postcss-ordered-values "^4.1.2"
- postcss-reduce-initial "^4.0.3"
- postcss-reduce-transforms "^4.0.2"
- postcss-svgo "^4.0.3"
- postcss-unique-selectors "^4.0.1"
-
-cssnano-util-get-arguments@^4.0.0:
- version "4.0.0"
- resolved "https://registry.yarnpkg.com/cssnano-util-get-arguments/-/cssnano-util-get-arguments-4.0.0.tgz#ed3a08299f21d75741b20f3b81f194ed49cc150f"
- integrity sha512-6RIcwmV3/cBMG8Aj5gucQRsJb4vv4I4rn6YjPbVWd5+Pn/fuG+YseGvXGk00XLkoZkaj31QOD7vMUpNPC4FIuw==
-
-cssnano-util-get-match@^4.0.0:
- version "4.0.0"
- resolved "https://registry.yarnpkg.com/cssnano-util-get-match/-/cssnano-util-get-match-4.0.0.tgz#c0e4ca07f5386bb17ec5e52250b4f5961365156d"
- integrity sha512-JPMZ1TSMRUPVIqEalIBNoBtAYbi8okvcFns4O0YIhcdGebeYZK7dMyHJiQ6GqNBA9kE0Hym4Aqym5rPdsV/4Cw==
-
-cssnano-util-raw-cache@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/cssnano-util-raw-cache/-/cssnano-util-raw-cache-4.0.1.tgz#b26d5fd5f72a11dfe7a7846fb4c67260f96bf282"
- integrity sha512-qLuYtWK2b2Dy55I8ZX3ky1Z16WYsx544Q0UWViebptpwn/xDBmog2TLg4f+DBMg1rJ6JDWtn96WHbOKDWt1WQA==
- dependencies:
- postcss "^7.0.0"
-
-cssnano-util-same-parent@^4.0.0:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/cssnano-util-same-parent/-/cssnano-util-same-parent-4.0.1.tgz#574082fb2859d2db433855835d9a8456ea18bbf3"
- integrity sha512-WcKx5OY+KoSIAxBW6UBBRay1U6vkYheCdjyVNDm85zt5K9mHoGOfsOsqIszfAqrQQFIIKgjh2+FDgIj/zsl21Q==
-
-cssnano@^4.1.0:
- version "4.1.11"
- resolved "https://registry.yarnpkg.com/cssnano/-/cssnano-4.1.11.tgz#c7b5f5b81da269cb1fd982cb960c1200910c9a99"
- integrity sha512-6gZm2htn7xIPJOHY824ERgj8cNPgPxyCSnkXc4v7YvNW+TdVfzgngHcEhy/8D11kUWRUMbke+tC+AUcUsnMz2g==
- dependencies:
- cosmiconfig "^5.0.0"
- cssnano-preset-default "^4.0.8"
- is-resolvable "^1.0.0"
- postcss "^7.0.0"
-
-csso@^4.0.2:
- version "4.2.0"
- resolved "https://registry.yarnpkg.com/csso/-/csso-4.2.0.tgz#ea3a561346e8dc9f546d6febedd50187cf389529"
- integrity sha512-wvlcdIbf6pwKEk7vHj8/Bkc0B4ylXZruLvOgs9doS5eOsOpuodOV2zJChSpkp+pRpYQLQMeF04nr3Z68Sta9jA==
- dependencies:
- css-tree "^1.1.2"
-
-currently-unhandled@^0.4.1:
- version "0.4.1"
- resolved "https://registry.yarnpkg.com/currently-unhandled/-/currently-unhandled-0.4.1.tgz#988df33feab191ef799a61369dd76c17adf957ea"
- integrity sha512-/fITjgjGU50vjQ4FH6eUoYu+iUoUKIXws2hL15JJpIR+BbTxaXQsMuuyjtNh2WqsSBS5nsaZHFsFecyw5CCAng==
- dependencies:
- array-find-index "^1.0.1"
-
-dashdash@^1.12.0:
- version "1.14.1"
- resolved "https://registry.yarnpkg.com/dashdash/-/dashdash-1.14.1.tgz#853cfa0f7cbe2fed5de20326b8dd581035f6e2f0"
- integrity sha512-jRFi8UDGo6j+odZiEpjazZaWqEal3w/basFjQHQEwVtZJGDpxbH1MeYluwCS8Xq5wmLJooDlMgvVarmWfGM44g==
- dependencies:
- assert-plus "^1.0.0"
-
-debug@0.7.4:
- version "0.7.4"
- resolved "https://registry.yarnpkg.com/debug/-/debug-0.7.4.tgz#06e1ea8082c2cb14e39806e22e2f6f757f92af39"
- integrity sha512-EohAb3+DSHSGx8carOSKJe8G0ayV5/i609OD0J2orCkuyae7SyZSz2aoLmQF2s0Pj5gITDebwPH7GFBlqOUQ1Q==
-
-debug@2.6.9, debug@^2.2.0, debug@^2.3.3, debug@^2.6.0, debug@^2.6.6:
- version "2.6.9"
- resolved "https://registry.yarnpkg.com/debug/-/debug-2.6.9.tgz#5d128515df134ff327e90a4c93f4e077a536341f"
- integrity sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==
- dependencies:
- ms "2.0.0"
-
-debug@^3.1.0, debug@^3.2.7:
- version "3.2.7"
- resolved "https://registry.yarnpkg.com/debug/-/debug-3.2.7.tgz#72580b7e9145fb39b6676f9c5e5fb100b934179a"
- integrity sha512-CFjzYYAi4ThfiQvizrFQevTTXHtnCqWfe7x1AhgEscTz6ZbLbfoLRLPugTQyBth6f8ZERVUSyWHFD/7Wu4t1XQ==
- dependencies:
- ms "^2.1.1"
-
-debug@^4.1.0, debug@^4.1.1:
- version "4.3.4"
- resolved "https://registry.yarnpkg.com/debug/-/debug-4.3.4.tgz#1319f6579357f2338d3337d2cdd4914bb5dcc865"
- integrity sha512-PRWFHuSU3eDtQJPvnNY7Jcket1j0t5OuOsFzPPzsekD52Zl8qUfFIPEiswXqIvHWGVHOgX+7G/vCNNhehwxfkQ==
- dependencies:
- ms "2.1.2"
-
-decamelize@^1.1.2:
- version "1.2.0"
- resolved "https://registry.yarnpkg.com/decamelize/-/decamelize-1.2.0.tgz#f6534d15148269b20352e7bee26f501f9a191290"
- integrity sha512-z2S+W9X73hAUUki+N+9Za2lBlun89zigOyGrsax+KUQ6wKW4ZoWpEYBkGhQjwAjjDCkWxhY0VKEhk8wzY7F5cA==
-
-decode-uri-component@^0.2.0:
- version "0.2.0"
- resolved "https://registry.yarnpkg.com/decode-uri-component/-/decode-uri-component-0.2.0.tgz#eb3913333458775cb84cd1a1fae062106bb87545"
- integrity sha512-hjf+xovcEn31w/EUYdTXQh/8smFL/dzYjohQGEIgjyNavaJfBY2p5F527Bo1VPATxv0VYTUC2bOcXvqFwk78Og==
-
-decompress-response@^3.2.0, decompress-response@^3.3.0:
- version "3.3.0"
- resolved "https://registry.yarnpkg.com/decompress-response/-/decompress-response-3.3.0.tgz#80a4dd323748384bfa248083622aedec982adff3"
- integrity sha512-BzRPQuY1ip+qDonAOz42gRm/pg9F768C+npV/4JOsxRC2sq+Rlk+Q4ZCAsOhnIaMrgarILY+RMUIvMmmX1qAEA==
- dependencies:
- mimic-response "^1.0.0"
-
-decompress-tar@^4.0.0, decompress-tar@^4.1.0, decompress-tar@^4.1.1:
- version "4.1.1"
- resolved "https://registry.yarnpkg.com/decompress-tar/-/decompress-tar-4.1.1.tgz#718cbd3fcb16209716e70a26b84e7ba4592e5af1"
- integrity sha512-JdJMaCrGpB5fESVyxwpCx4Jdj2AagLmv3y58Qy4GE6HMVjWz1FeVQk1Ct4Kye7PftcdOo/7U7UKzYBJgqnGeUQ==
- dependencies:
- file-type "^5.2.0"
- is-stream "^1.1.0"
- tar-stream "^1.5.2"
-
-decompress-tarbz2@^4.0.0:
- version "4.1.1"
- resolved "https://registry.yarnpkg.com/decompress-tarbz2/-/decompress-tarbz2-4.1.1.tgz#3082a5b880ea4043816349f378b56c516be1a39b"
- integrity sha512-s88xLzf1r81ICXLAVQVzaN6ZmX4A6U4z2nMbOwobxkLoIIfjVMBg7TeguTUXkKeXni795B6y5rnvDw7rxhAq9A==
- dependencies:
- decompress-tar "^4.1.0"
- file-type "^6.1.0"
- is-stream "^1.1.0"
- seek-bzip "^1.0.5"
- unbzip2-stream "^1.0.9"
-
-decompress-targz@^4.0.0:
- version "4.1.1"
- resolved "https://registry.yarnpkg.com/decompress-targz/-/decompress-targz-4.1.1.tgz#c09bc35c4d11f3de09f2d2da53e9de23e7ce1eee"
- integrity sha512-4z81Znfr6chWnRDNfFNqLwPvm4db3WuZkqV+UgXQzSngG3CEKdBkw5jrv3axjjL96glyiiKjsxJG3X6WBZwX3w==
- dependencies:
- decompress-tar "^4.1.1"
- file-type "^5.2.0"
- is-stream "^1.1.0"
-
-decompress-unzip@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/decompress-unzip/-/decompress-unzip-4.0.1.tgz#deaaccdfd14aeaf85578f733ae8210f9b4848f69"
- integrity sha512-1fqeluvxgnn86MOh66u8FjbtJpAFv5wgCT9Iw8rcBqQcCo5tO8eiJw7NNTrvt9n4CRBVq7CstiS922oPgyGLrw==
- dependencies:
- file-type "^3.8.0"
- get-stream "^2.2.0"
- pify "^2.3.0"
- yauzl "^2.4.2"
-
-decompress@^4.0.0, decompress@^4.2.0:
- version "4.2.1"
- resolved "https://registry.yarnpkg.com/decompress/-/decompress-4.2.1.tgz#007f55cc6a62c055afa37c07eb6a4ee1b773f118"
- integrity sha512-e48kc2IjU+2Zw8cTb6VZcJQ3lgVbS4uuB1TfCHbiZIP/haNXm+SVyhu+87jts5/3ROpd82GSVCoNs/z8l4ZOaQ==
- dependencies:
- decompress-tar "^4.0.0"
- decompress-tarbz2 "^4.0.0"
- decompress-targz "^4.0.0"
- decompress-unzip "^4.0.1"
- graceful-fs "^4.1.10"
- make-dir "^1.0.0"
- pify "^2.3.0"
- strip-dirs "^2.0.0"
-
-deep-is@0.1.2:
- version "0.1.2"
- resolved "https://registry.yarnpkg.com/deep-is/-/deep-is-0.1.2.tgz#9ced65ea0bc0b09f42a6d79c1b1903f9d913cc18"
- integrity sha512-+ykBpFL44/E8TlSBn0kDHZ1+IseXxUu/Om3bS2nqNscaeYWzxx54R9CewU6pLrsXLmEeTRZsGMTQIHfSUEEcUw==
-
-define-properties@^1.1.3, define-properties@^1.1.4:
- version "1.1.4"
- resolved "https://registry.yarnpkg.com/define-properties/-/define-properties-1.1.4.tgz#0b14d7bd7fbeb2f3572c3a7eda80ea5d57fb05b1"
- integrity sha512-uckOqKcfaVvtBdsVkdPv3XjveQJsNQqmhXgRi8uhvWWuPYZCNlzT8qAyblUgNoXdHdjMTzAqeGjAoli8f+bzPA==
- dependencies:
- has-property-descriptors "^1.0.0"
- object-keys "^1.1.1"
-
-define-property@^0.2.5:
- version "0.2.5"
- resolved "https://registry.yarnpkg.com/define-property/-/define-property-0.2.5.tgz#c35b1ef918ec3c990f9a5bc57be04aacec5c8116"
- integrity sha512-Rr7ADjQZenceVOAKop6ALkkRAmH1A4Gx9hV/7ZujPUN2rkATqFO0JZLZInbAjpZYoJ1gUx8MRMQVkYemcbMSTA==
- dependencies:
- is-descriptor "^0.1.0"
-
-define-property@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/define-property/-/define-property-1.0.0.tgz#769ebaaf3f4a63aad3af9e8d304c9bbe79bfb0e6"
- integrity sha512-cZTYKFWspt9jZsMscWo8sc/5lbPC9Q0N5nBLgb+Yd915iL3udB1uFgS3B8YCx66UVHq018DAVFoee7x+gxggeA==
- dependencies:
- is-descriptor "^1.0.0"
-
-define-property@^2.0.2:
- version "2.0.2"
- resolved "https://registry.yarnpkg.com/define-property/-/define-property-2.0.2.tgz#d459689e8d654ba77e02a817f8710d702cb16e9d"
- integrity sha512-jwK2UV4cnPpbcG7+VRARKTZPUWowwXA8bzH5NP6ud0oeAxyYPuGZUAC7hMugpCdz4BeSZl2Dl9k66CHJ/46ZYQ==
- dependencies:
- is-descriptor "^1.0.2"
- isobject "^3.0.1"
-
-delayed-stream@~1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/delayed-stream/-/delayed-stream-1.0.0.tgz#df3ae199acadfb7d440aaae0b29e2272b24ec619"
- integrity sha512-ZySD7Nf91aLB0RxL4KGrKHBXl7Eds1DAmEdcoVawXnLD7SDhpNgtuII2aAkg7a7QS41jxPSZ17p4VdGnMHk3MQ==
-
-depd@2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/depd/-/depd-2.0.0.tgz#b696163cc757560d09cf22cc8fad1571b79e76df"
- integrity sha512-g7nH6P6dyDioJogAAGprGpCtVImJhpPk/roCzdb3fIh61/s/nPsfR6onyMwkCAR/OlC3yBC0lESvUoQEAssIrw==
-
-destroy@1.2.0:
- version "1.2.0"
- resolved "https://registry.yarnpkg.com/destroy/-/destroy-1.2.0.tgz#4803735509ad8be552934c67df614f94e66fa015"
- integrity sha512-2sJGJTaXIIaR1w4iJSNoN0hnMY7Gpc/n8D4qSCJw8QqFWXf7cuAgnEHxBpweaVcPevC2l3KpjYCx3NypQQgaJg==
-
-detect-port-alt@1.1.6:
- version "1.1.6"
- resolved "https://registry.yarnpkg.com/detect-port-alt/-/detect-port-alt-1.1.6.tgz#24707deabe932d4a3cf621302027c2b266568275"
- integrity sha512-5tQykt+LqfJFBEYaDITx7S7cR7mJ/zQmLXZ2qt5w04ainYZw6tBf9dBunMjVeVOdYVRUzUOE4HkY5J7+uttb5Q==
- dependencies:
- address "^1.0.1"
- debug "^2.6.0"
-
-diacritics-map@^0.1.0:
- version "0.1.0"
- resolved "https://registry.yarnpkg.com/diacritics-map/-/diacritics-map-0.1.0.tgz#6dfc0ff9d01000a2edf2865371cac316e94977af"
- integrity sha512-3omnDTYrGigU0i4cJjvaKwD52B8aoqyX/NEIkukFFkogBemsIbhSa1O414fpTp5nuszJG6lvQ5vBvDVNCbSsaQ==
-
-dir-glob@2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/dir-glob/-/dir-glob-2.0.0.tgz#0b205d2b6aef98238ca286598a8204d29d0a0034"
- integrity sha512-37qirFDz8cA5fimp9feo43fSuRo2gHwaIn6dXL8Ber1dGwUosDrGZeCCXq57WnIqE4aQ+u3eQZzsk1yOzhdwag==
- dependencies:
- arrify "^1.0.1"
- path-type "^3.0.0"
-
-docusaurus@sietseringers/docusaurus#860be33493f95239c3cbc0e75a009064fc2052a1:
- version "1.11.1"
- resolved "https://codeload.github.com/sietseringers/docusaurus/tar.gz/860be33493f95239c3cbc0e75a009064fc2052a1"
- dependencies:
- "@babel/core" "^7.0.0"
- "@babel/plugin-proposal-class-properties" "^7.0.0"
- "@babel/plugin-proposal-object-rest-spread" "^7.0.0"
- "@babel/polyfill" "^7.0.0"
- "@babel/preset-env" "^7.0.0"
- "@babel/preset-react" "^7.0.0"
- "@babel/register" "^7.0.0"
- "@babel/traverse" "^7.0.0"
- "@babel/types" "^7.1.2"
- autoprefixer "^9.6.0"
- babylon "^6.17.4"
- chalk "^2.4.2"
- chokidar "^3.0.1"
- classnames "^2.2.6"
- color "^2.0.1"
- commander "^2.20.0"
- cross-spawn "^6.0.5"
- crowdin-cli "^0.3.0"
- cssnano "^4.1.0"
- escape-string-regexp "^1.0.5"
- express "^4.17.1"
- feed "^1.1.0"
- fs-extra "^5.0.0"
- gaze "^1.1.2"
- glob "^7.1.3"
- highlight.js "^9.12.0"
- imagemin "^6.0.0"
- imagemin-gifsicle "^6.0.1"
- imagemin-jpegtran "^6.0.0"
- imagemin-optipng "^6.0.0"
- imagemin-svgo "^7.0.0"
- lodash "^4.17.11"
- markdown-toc "^1.2.0"
- mkdirp "^0.5.1"
- portfinder "^1.0.17"
- postcss "^7.0.1"
- prismjs "^1.15.0"
- react "^16.5.0"
- react-dev-utils "^5.0.2"
- react-dom "^16.5.0"
- remarkable "^1.7.1"
- request "^2.87.0"
- shelljs "^0.8.3"
- sitemap "^1.13.0"
- tcp-port-used "^0.1.2"
- tiny-lr "^1.1.1"
- tree-node-cli "^1.2.5"
- truncate-html "^1.0.1"
-
-dom-serializer@0:
- version "0.2.2"
- resolved "https://registry.yarnpkg.com/dom-serializer/-/dom-serializer-0.2.2.tgz#1afb81f533717175d478655debc5e332d9f9bb51"
- integrity sha512-2/xPb3ORsQ42nHYiSunXkDjPLBaEj/xTwUO4B7XCZQTRk7EBtTOPaygh10YAAh2OI1Qrp6NWfpAhzswj0ydt9g==
- dependencies:
- domelementtype "^2.0.1"
- entities "^2.0.0"
-
-dom-serializer@~0.1.0:
- version "0.1.1"
- resolved "https://registry.yarnpkg.com/dom-serializer/-/dom-serializer-0.1.1.tgz#1ec4059e284babed36eec2941d4a970a189ce7c0"
- integrity sha512-l0IU0pPzLWSHBcieZbpOKgkIn3ts3vAh7ZuFyXNwJxJXk/c4Gwj9xaTJwIDVQCXawWD0qb3IzMGH5rglQaO0XA==
- dependencies:
- domelementtype "^1.3.0"
- entities "^1.1.1"
-
-domelementtype@1, domelementtype@^1.3.0, domelementtype@^1.3.1:
- version "1.3.1"
- resolved "https://registry.yarnpkg.com/domelementtype/-/domelementtype-1.3.1.tgz#d048c44b37b0d10a7f2a3d5fee3f4333d790481f"
- integrity sha512-BSKB+TSpMpFI/HOxCNr1O8aMOTZ8hT3pM3GQ0w/mWRmkhEDSFJkkyzz4XQsBV44BChwGkrDfMyjVD0eA2aFV3w==
-
-domelementtype@^2.0.1:
- version "2.3.0"
- resolved "https://registry.yarnpkg.com/domelementtype/-/domelementtype-2.3.0.tgz#5c45e8e869952626331d7aab326d01daf65d589d"
- integrity sha512-OLETBj6w0OsagBwdXnPdN0cnMfF9opN69co+7ZrbfPGrdpPVNBUj02spi6B1N7wChLQiPn4CSH/zJvXw56gmHw==
-
-domhandler@^2.3.0:
- version "2.4.2"
- resolved "https://registry.yarnpkg.com/domhandler/-/domhandler-2.4.2.tgz#8805097e933d65e85546f726d60f5eb88b44f803"
- integrity sha512-JiK04h0Ht5u/80fdLMCEmV4zkNh2BcoMFBmZ/91WtYZ8qVXSKjiw7fXMgFPnHcSZgOo3XdinHvmnDUeMf5R4wA==
- dependencies:
- domelementtype "1"
-
-domutils@1.5.1:
- version "1.5.1"
- resolved "https://registry.yarnpkg.com/domutils/-/domutils-1.5.1.tgz#dcd8488a26f563d61079e48c9f7b7e32373682cf"
- integrity sha512-gSu5Oi/I+3wDENBsOWBiRK1eoGxcywYSqg3rR960/+EfY0CF4EX1VPkgHOZ3WiS/Jg2DtliF6BhWcHlfpYUcGw==
- dependencies:
- dom-serializer "0"
- domelementtype "1"
-
-domutils@^1.5.1, domutils@^1.7.0:
- version "1.7.0"
- resolved "https://registry.yarnpkg.com/domutils/-/domutils-1.7.0.tgz#56ea341e834e06e6748af7a1cb25da67ea9f8c2a"
- integrity sha512-Lgd2XcJ/NjEw+7tFvfKxOzCYKZsdct5lczQ2ZaQY8Djz7pfAD3Gbp8ySJWtreII/vDlMVmxwa6pHmdxIYgttDg==
- dependencies:
- dom-serializer "0"
- domelementtype "1"
-
-dot-prop@^5.2.0:
- version "5.3.0"
- resolved "https://registry.yarnpkg.com/dot-prop/-/dot-prop-5.3.0.tgz#90ccce708cd9cd82cc4dc8c3ddd9abdd55b20e88"
- integrity sha512-QM8q3zDe58hqUqjraQOmzZ1LIH9SWQJTlEKCH4kJ2oQvLZk7RbQXvtDM2XEq3fwkV9CCvvH4LA0AV+ogFsBM2Q==
- dependencies:
- is-obj "^2.0.0"
-
-download@^6.2.2:
- version "6.2.5"
- resolved "https://registry.yarnpkg.com/download/-/download-6.2.5.tgz#acd6a542e4cd0bb42ca70cfc98c9e43b07039714"
- integrity sha512-DpO9K1sXAST8Cpzb7kmEhogJxymyVUd5qz/vCOSyvwtp2Klj2XcDt5YUuasgxka44SxF0q5RriKIwJmQHG2AuA==
- dependencies:
- caw "^2.0.0"
- content-disposition "^0.5.2"
- decompress "^4.0.0"
- ext-name "^5.0.0"
- file-type "5.2.0"
- filenamify "^2.0.0"
- get-stream "^3.0.0"
- got "^7.0.0"
- make-dir "^1.0.0"
- p-event "^1.0.0"
- pify "^3.0.0"
-
-download@^7.1.0:
- version "7.1.0"
- resolved "https://registry.yarnpkg.com/download/-/download-7.1.0.tgz#9059aa9d70b503ee76a132897be6dec8e5587233"
- integrity sha512-xqnBTVd/E+GxJVrX5/eUJiLYjCGPwMpdL+jGhGU57BvtcA7wwhtHVbXBeUk51kOpW3S7Jn3BQbN9Q1R1Km2qDQ==
- dependencies:
- archive-type "^4.0.0"
- caw "^2.0.1"
- content-disposition "^0.5.2"
- decompress "^4.2.0"
- ext-name "^5.0.0"
- file-type "^8.1.0"
- filenamify "^2.0.0"
- get-stream "^3.0.0"
- got "^8.3.1"
- make-dir "^1.2.0"
- p-event "^2.1.0"
- pify "^3.0.0"
-
-duplexer2@~0.1.4:
- version "0.1.4"
- resolved "https://registry.yarnpkg.com/duplexer2/-/duplexer2-0.1.4.tgz#8b12dab878c0d69e3e7891051662a32fc6bddcc1"
- integrity sha512-asLFVfWWtJ90ZyOUHMqk7/S2w2guQKxUI2itj3d92ADHhxUSbCMGi1f1cBcJ7xM1To+pE/Khbwo1yuNbMEPKeA==
- dependencies:
- readable-stream "^2.0.2"
-
-duplexer3@^0.1.4:
- version "0.1.5"
- resolved "https://registry.yarnpkg.com/duplexer3/-/duplexer3-0.1.5.tgz#0b5e4d7bad5de8901ea4440624c8e1d20099217e"
- integrity sha512-1A8za6ws41LQgv9HrE/66jyC5yuSjQ3L/KOpFtoBilsAK2iA2wuS5rTt1OCzIvtS2V7nVmedsUU+DGRcjBmOYA==
-
-duplexer@^0.1.1:
- version "0.1.2"
- resolved "https://registry.yarnpkg.com/duplexer/-/duplexer-0.1.2.tgz#3abe43aef3835f8ae077d136ddce0f276b0400e6"
- integrity sha512-jtD6YG370ZCIi/9GTaJKQxWTZD045+4R4hTk/x1UyoqadyJ9x9CgSi1RlVDQF8U2sxLLSnFkCaMihqljHIWgMg==
-
-ecc-jsbn@~0.1.1:
- version "0.1.2"
- resolved "https://registry.yarnpkg.com/ecc-jsbn/-/ecc-jsbn-0.1.2.tgz#3a83a904e54353287874c564b7549386849a98c9"
- integrity sha512-eh9O+hwRHNbG4BLTjEl3nw044CkGm5X6LoaCf7LPp7UU8Qrt47JYNi6nPX8xjW97TKGKm1ouctg0QSpZe9qrnw==
- dependencies:
- jsbn "~0.1.0"
- safer-buffer "^2.1.0"
-
-ee-first@1.1.1:
- version "1.1.1"
- resolved "https://registry.yarnpkg.com/ee-first/-/ee-first-1.1.1.tgz#590c61156b0ae2f4f0255732a158b266bc56b21d"
- integrity sha512-WMwm9LhRUo+WUaRN+vRuETqG89IgZphVSNkdFgeb6sS/E4OrDIN7t48CAewSHXc6C8lefD8KKfr5vY61brQlow==
-
-electron-to-chromium@^1.4.251:
- version "1.4.284"
- resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.284.tgz#61046d1e4cab3a25238f6bf7413795270f125592"
- integrity sha512-M8WEXFuKXMYMVr45fo8mq0wUrrJHheiKZf6BArTKk9ZBYCKJEOU5H8cdWgDT+qCVZf7Na4lVUaZsA+h6uA9+PA==
-
-encodeurl@~1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/encodeurl/-/encodeurl-1.0.2.tgz#ad3ff4c86ec2d029322f5a02c3a9a606c95b3f59"
- integrity sha512-TPJXq8JqFaVYm2CWmPvnP2Iyo4ZSM7/QKcSmuMLDObfpH5fi7RUGmd/rTDf+rut/saiDiQEeVTNgAmJEdAOx0w==
-
-end-of-stream@^1.0.0, end-of-stream@^1.1.0:
- version "1.4.4"
- resolved "https://registry.yarnpkg.com/end-of-stream/-/end-of-stream-1.4.4.tgz#5ae64a5f45057baf3626ec14da0ca5e4b2431eb0"
- integrity sha512-+uw1inIHVPQoaVuHzRyXd21icM+cnt4CzD5rW+NC1wjOUSTOs+Te7FOv7AhN7vS9x/oIyhLP5PR1H+phQAHu5Q==
- dependencies:
- once "^1.4.0"
-
-entities@^1.1.1, entities@~1.1.1:
- version "1.1.2"
- resolved "https://registry.yarnpkg.com/entities/-/entities-1.1.2.tgz#bdfa735299664dfafd34529ed4f8522a275fea56"
- integrity sha512-f2LZMYl1Fzu7YSBKg+RoROelpOaNrcGmE9AZubeDfrCEia483oW4MI4VyFd5VNHIgQ/7qm1I0wUHK1eJnn2y2w==
-
-entities@^2.0.0:
- version "2.2.0"
- resolved "https://registry.yarnpkg.com/entities/-/entities-2.2.0.tgz#098dc90ebb83d8dffa089d55256b351d34c4da55"
- integrity sha512-p92if5Nz619I0w+akJrLZH0MX0Pb5DX39XOwQTtXSdQQOaYH03S1uIQp4mhOZtAXrxq4ViO67YTiLBo2638o9A==
-
-error-ex@^1.2.0, error-ex@^1.3.1:
- version "1.3.2"
- resolved "https://registry.yarnpkg.com/error-ex/-/error-ex-1.3.2.tgz#b4ac40648107fdcdcfae242f428bea8a14d4f1bf"
- integrity sha512-7dFHNmqeFSEt2ZBsCriorKnn3Z2pj+fd9kmI6QoWw4//DL+icEBfc0U7qJCisqrTsKTjw4fNFy2pW9OqStD84g==
- dependencies:
- is-arrayish "^0.2.1"
-
-error@^7.0.0:
- version "7.2.1"
- resolved "https://registry.yarnpkg.com/error/-/error-7.2.1.tgz#eab21a4689b5f684fc83da84a0e390de82d94894"
- integrity sha512-fo9HBvWnx3NGUKMvMwB/CBCMMrfEJgbDTVDEkPygA3Bdd3lM1OyCd+rbQ8BwnpF6GdVeOLDNmyL4N5Bg80ZvdA==
- dependencies:
- string-template "~0.2.1"
-
-es-abstract@^1.17.2, es-abstract@^1.19.0, es-abstract@^1.20.4:
- version "1.20.4"
- resolved "https://registry.yarnpkg.com/es-abstract/-/es-abstract-1.20.4.tgz#1d103f9f8d78d4cf0713edcd6d0ed1a46eed5861"
- integrity sha512-0UtvRN79eMe2L+UNEF1BwRe364sj/DXhQ/k5FmivgoSdpM90b8Jc0mDzKMGo7QS0BVbOP/bTwBKNnDc9rNzaPA==
- dependencies:
- call-bind "^1.0.2"
- es-to-primitive "^1.2.1"
- function-bind "^1.1.1"
- function.prototype.name "^1.1.5"
- get-intrinsic "^1.1.3"
- get-symbol-description "^1.0.0"
- has "^1.0.3"
- has-property-descriptors "^1.0.0"
- has-symbols "^1.0.3"
- internal-slot "^1.0.3"
- is-callable "^1.2.7"
- is-negative-zero "^2.0.2"
- is-regex "^1.1.4"
- is-shared-array-buffer "^1.0.2"
- is-string "^1.0.7"
- is-weakref "^1.0.2"
- object-inspect "^1.12.2"
- object-keys "^1.1.1"
- object.assign "^4.1.4"
- regexp.prototype.flags "^1.4.3"
- safe-regex-test "^1.0.0"
- string.prototype.trimend "^1.0.5"
- string.prototype.trimstart "^1.0.5"
- unbox-primitive "^1.0.2"
-
-es-array-method-boxes-properly@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/es-array-method-boxes-properly/-/es-array-method-boxes-properly-1.0.0.tgz#873f3e84418de4ee19c5be752990b2e44718d09e"
- integrity sha512-wd6JXUmyHmt8T5a2xreUwKcGPq6f1f+WwIJkijUqiGcJz1qqnZgP6XIK+QyIWU5lT7imeNxUll48bziG+TSYcA==
-
-es-to-primitive@^1.2.1:
- version "1.2.1"
- resolved "https://registry.yarnpkg.com/es-to-primitive/-/es-to-primitive-1.2.1.tgz#e55cd4c9cdc188bcefb03b366c736323fc5c898a"
- integrity sha512-QCOllgZJtaUo9miYBcLChTUaHNjJF3PYs1VidD7AwiEj1kYxKeQTctLAezAOH5ZKRH0g2IgPn6KwB4IT8iRpvA==
- dependencies:
- is-callable "^1.1.4"
- is-date-object "^1.0.1"
- is-symbol "^1.0.2"
-
-escalade@^3.1.1:
- version "3.1.1"
- resolved "https://registry.yarnpkg.com/escalade/-/escalade-3.1.1.tgz#d8cfdc7000965c5a0174b4a82eaa5c0552742e40"
- integrity sha512-k0er2gUkLf8O0zKJiAhmkTnJlTvINGv7ygDNPbeIsX/TJjGJZHuh9B2UxbsaEkmlEo9MfhrSzmhIlhRlI2GXnw==
-
-escape-html@~1.0.3:
- version "1.0.3"
- resolved "https://registry.yarnpkg.com/escape-html/-/escape-html-1.0.3.tgz#0258eae4d3d0c0974de1c169188ef0051d1d1988"
- integrity sha512-NiSupZ4OeuGwr68lGIeym/ksIZMJodUGOSCZ/FSnTxcrekbvqrgdUxlJOMpijaKZVjAJrWrGs/6Jy8OMuyj9ow==
-
-escape-string-regexp@1.0.5, escape-string-regexp@^1.0.2, escape-string-regexp@^1.0.5:
- version "1.0.5"
- resolved "https://registry.yarnpkg.com/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz#1b61c0562190a8dff6ae3bb2cf0200ca130b86d4"
- integrity sha512-vbRorB5FUQWvla16U8R/qgaFIya2qGzwDrNmCZuYKrbdSUMG6I1ZCGQRefkRVhuOkIGVne7BQ35DSfo1qvJqFg==
-
-esprima@^4.0.0:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/esprima/-/esprima-4.0.1.tgz#13b04cdb3e6c5d19df91ab6987a8695619b0aa71"
- integrity sha512-eGuFFw7Upda+g4p+QHvnW0RyTX/SVeJBDM/gCtMARO0cLuT2HcEKnTPvhjV6aGeqrCB/sbNop0Kszm0jsaWU4A==
-
-esutils@^2.0.2:
- version "2.0.3"
- resolved "https://registry.yarnpkg.com/esutils/-/esutils-2.0.3.tgz#74d2eb4de0b8da1293711910d50775b9b710ef64"
- integrity sha512-kVscqXk4OCp68SZ0dkgEKVi6/8ij300KBWTJq32P/dYeWTSwK41WyTxalN1eRmA5Z9UU/LX9D7FWSmV9SAYx6g==
-
-etag@~1.8.1:
- version "1.8.1"
- resolved "https://registry.yarnpkg.com/etag/-/etag-1.8.1.tgz#41ae2eeb65efa62268aebfea83ac7d79299b0887"
- integrity sha512-aIL5Fx7mawVa300al2BnEE4iNvo1qETxLrPI/o05L7z6go7fCw1J6EQmbK4FmJ2AS7kgVF/KEZWufBfdClMcPg==
-
-eventsource@0.1.6:
- version "0.1.6"
- resolved "https://registry.yarnpkg.com/eventsource/-/eventsource-0.1.6.tgz#0acede849ed7dd1ccc32c811bb11b944d4f29232"
- integrity sha512-bbB5tEuvC+SuRUG64X8ghvjgiRniuA4WlehWbFnoN4z6TxDXpyX+BMHF7rMgZAqoe+EbyNRUbHN0uuP9phy5jQ==
- dependencies:
- original ">=0.0.5"
-
-exec-buffer@^3.0.0:
- version "3.2.0"
- resolved "https://registry.yarnpkg.com/exec-buffer/-/exec-buffer-3.2.0.tgz#b1686dbd904c7cf982e652c1f5a79b1e5573082b"
- integrity sha512-wsiD+2Tp6BWHoVv3B+5Dcx6E7u5zky+hUwOHjuH2hKSLR3dvRmX8fk8UD8uqQixHs4Wk6eDmiegVrMPjKj7wpA==
- dependencies:
- execa "^0.7.0"
- p-finally "^1.0.0"
- pify "^3.0.0"
- rimraf "^2.5.4"
- tempfile "^2.0.0"
-
-execa@^0.7.0:
- version "0.7.0"
- resolved "https://registry.yarnpkg.com/execa/-/execa-0.7.0.tgz#944becd34cc41ee32a63a9faf27ad5a65fc59777"
- integrity sha512-RztN09XglpYI7aBBrJCPW95jEH7YF1UEPOoX9yDhUTPdp7mK+CQvnLTuD10BNXZ3byLTu2uehZ8EcKT/4CGiFw==
- dependencies:
- cross-spawn "^5.0.1"
- get-stream "^3.0.0"
- is-stream "^1.1.0"
- npm-run-path "^2.0.0"
- p-finally "^1.0.0"
- signal-exit "^3.0.0"
- strip-eof "^1.0.0"
-
-execa@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/execa/-/execa-1.0.0.tgz#c6236a5bb4df6d6f15e88e7f017798216749ddd8"
- integrity sha512-adbxcyWV46qiHyvSp50TKt05tB4tK3HcmF7/nxfAdhnox83seTDbwnaqKO4sXRy7roHAIFqJP/Rw/AuEbX61LA==
- dependencies:
- cross-spawn "^6.0.0"
- get-stream "^4.0.0"
- is-stream "^1.1.0"
- npm-run-path "^2.0.0"
- p-finally "^1.0.0"
- signal-exit "^3.0.0"
- strip-eof "^1.0.0"
-
-executable@^4.1.0:
- version "4.1.1"
- resolved "https://registry.yarnpkg.com/executable/-/executable-4.1.1.tgz#41532bff361d3e57af4d763b70582db18f5d133c"
- integrity sha512-8iA79xD3uAch729dUG8xaaBBFGaEa0wdD2VkYLFHwlqosEj/jT66AzcreRDSgV7ehnNLBW2WR5jIXwGKjVdTLg==
- dependencies:
- pify "^2.2.0"
-
-expand-brackets@^2.1.4:
- version "2.1.4"
- resolved "https://registry.yarnpkg.com/expand-brackets/-/expand-brackets-2.1.4.tgz#b77735e315ce30f6b6eff0f83b04151a22449622"
- integrity sha512-w/ozOKR9Obk3qoWeY/WDi6MFta9AoMR+zud60mdnbniMcBxRuFJyDt2LdX/14A1UABeqk+Uk+LDfUpvoGKppZA==
- dependencies:
- debug "^2.3.3"
- define-property "^0.2.5"
- extend-shallow "^2.0.1"
- posix-character-classes "^0.1.0"
- regex-not "^1.0.0"
- snapdragon "^0.8.1"
- to-regex "^3.0.1"
-
-expand-range@^1.8.1:
- version "1.8.2"
- resolved "https://registry.yarnpkg.com/expand-range/-/expand-range-1.8.2.tgz#a299effd335fe2721ebae8e257ec79644fc85337"
- integrity sha512-AFASGfIlnIbkKPQwX1yHaDjFvh/1gyKJODme52V6IORh69uEYgZp0o9C+qsIGNVEiuuhQU0CSSl++Rlegg1qvA==
- dependencies:
- fill-range "^2.1.0"
-
-expand-tilde@^2.0.0, expand-tilde@^2.0.2:
- version "2.0.2"
- resolved "https://registry.yarnpkg.com/expand-tilde/-/expand-tilde-2.0.2.tgz#97e801aa052df02454de46b02bf621642cdc8502"
- integrity sha512-A5EmesHW6rfnZ9ysHQjPdJRni0SRar0tjtG5MNtm9n5TUvsYU8oozprtRD4AqHxcZWWlVuAmQo2nWKfN9oyjTw==
- dependencies:
- homedir-polyfill "^1.0.1"
-
-express@^4.17.1:
- version "4.18.2"
- resolved "https://registry.yarnpkg.com/express/-/express-4.18.2.tgz#3fabe08296e930c796c19e3c516979386ba9fd59"
- integrity sha512-5/PsL6iGPdfQ/lKM1UuielYgv3BUoJfz1aUwU9vHZ+J7gyvwdQXFEBIEIaxeGf0GIcreATNyBExtalisDbuMqQ==
- dependencies:
- accepts "~1.3.8"
- array-flatten "1.1.1"
- body-parser "1.20.1"
- content-disposition "0.5.4"
- content-type "~1.0.4"
- cookie "0.5.0"
- cookie-signature "1.0.6"
- debug "2.6.9"
- depd "2.0.0"
- encodeurl "~1.0.2"
- escape-html "~1.0.3"
- etag "~1.8.1"
- finalhandler "1.2.0"
- fresh "0.5.2"
- http-errors "2.0.0"
- merge-descriptors "1.0.1"
- methods "~1.1.2"
- on-finished "2.4.1"
- parseurl "~1.3.3"
- path-to-regexp "0.1.7"
- proxy-addr "~2.0.7"
- qs "6.11.0"
- range-parser "~1.2.1"
- safe-buffer "5.2.1"
- send "0.18.0"
- serve-static "1.15.0"
- setprototypeof "1.2.0"
- statuses "2.0.1"
- type-is "~1.6.18"
- utils-merge "1.0.1"
- vary "~1.1.2"
-
-ext-list@^2.0.0:
- version "2.2.2"
- resolved "https://registry.yarnpkg.com/ext-list/-/ext-list-2.2.2.tgz#0b98e64ed82f5acf0f2931babf69212ef52ddd37"
- integrity sha512-u+SQgsubraE6zItfVA0tBuCBhfU9ogSRnsvygI7wht9TS510oLkBRXBsqopeUG/GBOIQyKZO9wjTqIu/sf5zFA==
- dependencies:
- mime-db "^1.28.0"
-
-ext-name@^5.0.0:
- version "5.0.0"
- resolved "https://registry.yarnpkg.com/ext-name/-/ext-name-5.0.0.tgz#70781981d183ee15d13993c8822045c506c8f0a6"
- integrity sha512-yblEwXAbGv1VQDmow7s38W77hzAgJAO50ztBLMcUyUBfxv1HC+LGwtiEN+Co6LtlqT/5uwVOxsD4TNIilWhwdQ==
- dependencies:
- ext-list "^2.0.0"
- sort-keys-length "^1.0.0"
-
-extend-shallow@^2.0.1:
- version "2.0.1"
- resolved "https://registry.yarnpkg.com/extend-shallow/-/extend-shallow-2.0.1.tgz#51af7d614ad9a9f610ea1bafbb989d6b1c56890f"
- integrity sha512-zCnTtlxNoAiDc3gqY2aYAWFx7XWWiasuF2K8Me5WbN8otHKTUKBwjPtNpRs/rbUZm7KxWAaNj7P1a/p52GbVug==
- dependencies:
- is-extendable "^0.1.0"
-
-extend-shallow@^3.0.0, extend-shallow@^3.0.2:
- version "3.0.2"
- resolved "https://registry.yarnpkg.com/extend-shallow/-/extend-shallow-3.0.2.tgz#26a71aaf073b39fb2127172746131c2704028db8"
- integrity sha512-BwY5b5Ql4+qZoefgMj2NUmx+tehVTH/Kf4k1ZEtOHNFcm2wSxMRo992l6X3TIgni2eZVTZ85xMOjF31fwZAj6Q==
- dependencies:
- assign-symbols "^1.0.0"
- is-extendable "^1.0.1"
-
-extend@~3.0.2:
- version "3.0.2"
- resolved "https://registry.yarnpkg.com/extend/-/extend-3.0.2.tgz#f8b1136b4071fbd8eb140aff858b1019ec2915fa"
- integrity sha512-fjquC59cD7CyW6urNXK0FBufkZcoiGG80wTuPujX590cB5Ttln20E2UB4S/WARVqhXffZl2LNgS+gQdPIIim/g==
-
-external-editor@^2.0.4:
- version "2.2.0"
- resolved "https://registry.yarnpkg.com/external-editor/-/external-editor-2.2.0.tgz#045511cfd8d133f3846673d1047c154e214ad3d5"
- integrity sha512-bSn6gvGxKt+b7+6TKEv1ZycHleA7aHhRHyAqJyp5pbUFuYYNIzpZnQDk7AsYckyWdEnTeAnay0aCy2aV6iTk9A==
- dependencies:
- chardet "^0.4.0"
- iconv-lite "^0.4.17"
- tmp "^0.0.33"
-
-extglob@^2.0.4:
- version "2.0.4"
- resolved "https://registry.yarnpkg.com/extglob/-/extglob-2.0.4.tgz#ad00fe4dc612a9232e8718711dc5cb5ab0285543"
- integrity sha512-Nmb6QXkELsuBr24CJSkilo6UHHgbekK5UiZgfE6UHD3Eb27YC6oD+bhcT+tJ6cl8dmsgdQxnWlcry8ksBIBLpw==
- dependencies:
- array-unique "^0.3.2"
- define-property "^1.0.0"
- expand-brackets "^2.1.4"
- extend-shallow "^2.0.1"
- fragment-cache "^0.2.1"
- regex-not "^1.0.0"
- snapdragon "^0.8.1"
- to-regex "^3.0.1"
-
-extsprintf@1.3.0:
- version "1.3.0"
- resolved "https://registry.yarnpkg.com/extsprintf/-/extsprintf-1.3.0.tgz#96918440e3041a7a414f8c52e3c574eb3c3e1e05"
- integrity sha512-11Ndz7Nv+mvAC1j0ktTa7fAb0vLyGGX+rMHNBYQviQDGU0Hw7lhctJANqbPhu9nV9/izT/IntTgZ7Im/9LJs9g==
-
-extsprintf@^1.2.0:
- version "1.4.1"
- resolved "https://registry.yarnpkg.com/extsprintf/-/extsprintf-1.4.1.tgz#8d172c064867f235c0c84a596806d279bf4bcc07"
- integrity sha512-Wrk35e8ydCKDj/ArClo1VrPVmN8zph5V4AtHwIuHhvMXsKf73UT3BOD+azBIW+3wOJ4FhEH7zyaJCFvChjYvMA==
-
-fast-deep-equal@^3.1.1:
- version "3.1.3"
- resolved "https://registry.yarnpkg.com/fast-deep-equal/-/fast-deep-equal-3.1.3.tgz#3a7d56b559d6cbc3eb512325244e619a65c6c525"
- integrity sha512-f3qQ9oQy9j2AhBe/H9VC91wLmKBCCU/gDOnKNAYG5hswO7BLKj09Hc5HYNz9cGI++xlpDCIgDaitVs03ATR84Q==
-
-fast-folder-size@1.6.1:
- version "1.6.1"
- resolved "https://registry.yarnpkg.com/fast-folder-size/-/fast-folder-size-1.6.1.tgz#1dc1674842854032cf07a387ba77c66546c547eb"
- integrity sha512-F3tRpfkAzb7TT2JNKaJUglyuRjRa+jelQD94s9OSqkfEeytLmupCqQiD+H2KoIXGtp4pB5m4zNmv5m2Ktcr+LA==
- dependencies:
- unzipper "^0.10.11"
-
-fast-glob@^2.0.2:
- version "2.2.7"
- resolved "https://registry.yarnpkg.com/fast-glob/-/fast-glob-2.2.7.tgz#6953857c3afa475fff92ee6015d52da70a4cd39d"
- integrity sha512-g1KuQwHOZAmOZMuBtHdxDtju+T2RT8jgCC9aANsbpdiDDTSnjgfuVsIBNKbUeJI3oKMRExcfNDtJl4OhbffMsw==
- dependencies:
- "@mrmlnc/readdir-enhanced" "^2.2.1"
- "@nodelib/fs.stat" "^1.1.2"
- glob-parent "^3.1.0"
- is-glob "^4.0.0"
- merge2 "^1.2.3"
- micromatch "^3.1.10"
-
-fast-json-stable-stringify@^2.0.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/fast-json-stable-stringify/-/fast-json-stable-stringify-2.1.0.tgz#874bf69c6f404c2b5d99c481341399fd55892633"
- integrity sha512-lhd/wF+Lk98HZoTCtlVraHtfh5XYijIjalXck7saUtuanSDyLMxnHhSXEDJqHxD7msR8D0uCmqlkwjCV8xvwHw==
-
-fast-xml-parser@^3.19.0:
- version "3.21.1"
- resolved "https://registry.yarnpkg.com/fast-xml-parser/-/fast-xml-parser-3.21.1.tgz#152a1d51d445380f7046b304672dd55d15c9e736"
- integrity sha512-FTFVjYoBOZTJekiUsawGsSYV9QL0A+zDYCRj7y34IO6Jg+2IMYEtQa+bbictpdpV8dHxXywqU7C0gRDEOFtBFg==
- dependencies:
- strnum "^1.0.4"
-
-faye-websocket@~0.10.0:
- version "0.10.0"
- resolved "https://registry.yarnpkg.com/faye-websocket/-/faye-websocket-0.10.0.tgz#4e492f8d04dfb6f89003507f6edbf2d501e7c6f4"
- integrity sha512-Xhj93RXbMSq8urNCUq4p9l0P6hnySJ/7YNRhYNug0bLOuii7pKO7xQFb5mx9xZXWCar88pLPb805PvUkwrLZpQ==
- dependencies:
- websocket-driver ">=0.5.1"
-
-faye-websocket@~0.11.0:
- version "0.11.4"
- resolved "https://registry.yarnpkg.com/faye-websocket/-/faye-websocket-0.11.4.tgz#7f0d9275cfdd86a1c963dc8b65fcc451edcbb1da"
- integrity sha512-CzbClwlXAuiRQAlUyfqPgvPoNKTckTPGfwZV4ZdAhVcP2lh9KUxJg2b5GkE7XbjKQ3YJnQ9z6D9ntLAlB+tP8g==
- dependencies:
- websocket-driver ">=0.5.1"
-
-fd-slicer@~1.1.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/fd-slicer/-/fd-slicer-1.1.0.tgz#25c7c89cb1f9077f8891bbe61d8f390eae256f1e"
- integrity sha512-cE1qsB/VwyQozZ+q1dGxR8LBYNZeofhEdUNGSMbQD3Gw2lAzX9Zb3uIU6Ebc/Fmyjo9AWWfnn0AUCHqtevs/8g==
- dependencies:
- pend "~1.2.0"
-
-feed@^1.1.0:
- version "1.1.1"
- resolved "https://registry.yarnpkg.com/feed/-/feed-1.1.1.tgz#914897517e94fa327cc6f73bb585a47c4a9ed321"
- integrity sha512-FydlyIcoAJL6c4qq/kQzUlxv7+Ck+zOq7xx6uZmjxN8nli/K3OPY3YUnxLpo68+F6gVI9MELZJTgBMtR3QK3qQ==
- dependencies:
- xml "^1.0.1"
-
-figures@^1.3.5:
- version "1.7.0"
- resolved "https://registry.yarnpkg.com/figures/-/figures-1.7.0.tgz#cbe1e3affcf1cd44b80cadfed28dc793a9701d2e"
- integrity sha512-UxKlfCRuCBxSXU4C6t9scbDyWZ4VlaFFdojKtzJuSkuOBQ5CNFum+zZXFwHjo+CxBC1t6zlYPgHIgFjL8ggoEQ==
- dependencies:
- escape-string-regexp "^1.0.5"
- object-assign "^4.1.0"
-
-figures@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/figures/-/figures-2.0.0.tgz#3ab1a2d2a62c8bfb431a0c94cb797a2fce27c962"
- integrity sha512-Oa2M9atig69ZkfwiApY8F2Yy+tzMbazyvqv21R0NsSC8floSOC09BbT1ITWAdoMGQvJ/aZnR1KMwdx9tvHnTNA==
- dependencies:
- escape-string-regexp "^1.0.5"
-
-file-type@5.2.0, file-type@^5.2.0:
- version "5.2.0"
- resolved "https://registry.yarnpkg.com/file-type/-/file-type-5.2.0.tgz#2ddbea7c73ffe36368dfae49dc338c058c2b8ad6"
- integrity sha512-Iq1nJ6D2+yIO4c8HHg4fyVb8mAJieo1Oloy1mLLaB2PvezNedhBVm+QU7g0qM42aiMbRXTxKKwGD17rjKNJYVQ==
-
-file-type@^10.4.0, file-type@^10.7.0:
- version "10.11.0"
- resolved "https://registry.yarnpkg.com/file-type/-/file-type-10.11.0.tgz#2961d09e4675b9fb9a3ee6b69e9cd23f43fd1890"
- integrity sha512-uzk64HRpUZyTGZtVuvrjP0FYxzQrBf4rojot6J65YMEbwBLB0CWm0CLojVpwpmFmxcE/lkvYICgfcGozbBq6rw==
-
-file-type@^3.8.0:
- version "3.9.0"
- resolved "https://registry.yarnpkg.com/file-type/-/file-type-3.9.0.tgz#257a078384d1db8087bc449d107d52a52672b9e9"
- integrity sha512-RLoqTXE8/vPmMuTI88DAzhMYC99I8BWv7zYP4A1puo5HIjEJ5EX48ighy4ZyKMG9EDXxBgW6e++cn7d1xuFghA==
-
-file-type@^4.2.0:
- version "4.4.0"
- resolved "https://registry.yarnpkg.com/file-type/-/file-type-4.4.0.tgz#1b600e5fca1fbdc6e80c0a70c71c8dba5f7906c5"
- integrity sha512-f2UbFQEk7LXgWpi5ntcO86OeA/cC80fuDDDaX/fZ2ZGel+AF7leRQqBBW1eJNiiQkrZlAoM6P+VYP5P6bOlDEQ==
-
-file-type@^6.1.0:
- version "6.2.0"
- resolved "https://registry.yarnpkg.com/file-type/-/file-type-6.2.0.tgz#e50cd75d356ffed4e306dc4f5bcf52a79903a919"
- integrity sha512-YPcTBDV+2Tm0VqjybVd32MHdlEGAtuxS3VAYsumFokDSMG+ROT5wawGlnHDoz7bfMcMDt9hxuXvXwoKUx2fkOg==
-
-file-type@^8.1.0:
- version "8.1.0"
- resolved "https://registry.yarnpkg.com/file-type/-/file-type-8.1.0.tgz#244f3b7ef641bbe0cca196c7276e4b332399f68c"
- integrity sha512-qyQ0pzAy78gVoJsmYeNgl8uH8yKhr1lVhW7JbzJmnlRi0I4R2eEDEJZVKG8agpDnLpacwNbDhLNG/LMdxHD2YQ==
-
-filename-reserved-regex@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/filename-reserved-regex/-/filename-reserved-regex-2.0.0.tgz#abf73dfab735d045440abfea2d91f389ebbfa229"
- integrity sha512-lc1bnsSr4L4Bdif8Xb/qrtokGbq5zlsms/CYH8PP+WtCkGNF65DPiQY8vG3SakEdRn8Dlnm+gW/qWKKjS5sZzQ==
-
-filenamify@^2.0.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/filenamify/-/filenamify-2.1.0.tgz#88faf495fb1b47abfd612300002a16228c677ee9"
- integrity sha512-ICw7NTT6RsDp2rnYKVd8Fu4cr6ITzGy3+u4vUujPkabyaz+03F24NWEX7fs5fp+kBonlaqPH8fAO2NM+SXt/JA==
- dependencies:
- filename-reserved-regex "^2.0.0"
- strip-outer "^1.0.0"
- trim-repeated "^1.0.0"
-
-filesize@3.5.11:
- version "3.5.11"
- resolved "https://registry.yarnpkg.com/filesize/-/filesize-3.5.11.tgz#1919326749433bb3cf77368bd158caabcc19e9ee"
- integrity sha512-ZH7loueKBoDb7yG9esn1U+fgq7BzlzW6NRi5/rMdxIZ05dj7GFD/Xc5rq2CDt5Yq86CyfSYVyx4242QQNZbx1g==
-
-fill-range@^2.1.0:
- version "2.2.4"
- resolved "https://registry.yarnpkg.com/fill-range/-/fill-range-2.2.4.tgz#eb1e773abb056dcd8df2bfdf6af59b8b3a936565"
- integrity sha512-cnrcCbj01+j2gTG921VZPnHbjmdAf8oQV/iGeV2kZxGSyfYjjTyY79ErsK1WJWMpw6DaApEX72binqJE+/d+5Q==
- dependencies:
- is-number "^2.1.0"
- isobject "^2.0.0"
- randomatic "^3.0.0"
- repeat-element "^1.1.2"
- repeat-string "^1.5.2"
-
-fill-range@^4.0.0:
- version "4.0.0"
- resolved "https://registry.yarnpkg.com/fill-range/-/fill-range-4.0.0.tgz#d544811d428f98eb06a63dc402d2403c328c38f7"
- integrity sha512-VcpLTWqWDiTerugjj8e3+esbg+skS3M9e54UuR3iCeIDMXCLTsAH8hTSzDQU/X6/6t3eYkOKoZSef2PlU6U1XQ==
- dependencies:
- extend-shallow "^2.0.1"
- is-number "^3.0.0"
- repeat-string "^1.6.1"
- to-regex-range "^2.1.0"
-
-fill-range@^7.0.1:
- version "7.0.1"
- resolved "https://registry.yarnpkg.com/fill-range/-/fill-range-7.0.1.tgz#1919a6a7c75fe38b2c7c77e5198535da9acdda40"
- integrity sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==
- dependencies:
- to-regex-range "^5.0.1"
-
-finalhandler@1.2.0:
- version "1.2.0"
- resolved "https://registry.yarnpkg.com/finalhandler/-/finalhandler-1.2.0.tgz#7d23fe5731b207b4640e4fcd00aec1f9207a7b32"
- integrity sha512-5uXcUVftlQMFnWC9qu/svkWv3GTd2PfUhK/3PLkYNAe7FbqJMt3515HaxE6eRL74GdsriiwujiawdaB1BpEISg==
- dependencies:
- debug "2.6.9"
- encodeurl "~1.0.2"
- escape-html "~1.0.3"
- on-finished "2.4.1"
- parseurl "~1.3.3"
- statuses "2.0.1"
- unpipe "~1.0.0"
-
-find-cache-dir@^2.0.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/find-cache-dir/-/find-cache-dir-2.1.0.tgz#8d0f94cd13fe43c6c7c261a0d86115ca918c05f7"
- integrity sha512-Tq6PixE0w/VMFfCgbONnkiQIVol/JJL7nRMi20fqzA4NRs9AfeqMGeRdPi3wIhYkxjeBaWh2rxwapn5Tu3IqOQ==
- dependencies:
- commondir "^1.0.1"
- make-dir "^2.0.0"
- pkg-dir "^3.0.0"
-
-find-up@^1.0.0:
- version "1.1.2"
- resolved "https://registry.yarnpkg.com/find-up/-/find-up-1.1.2.tgz#6b2e9822b1a2ce0a60ab64d610eccad53cb24d0f"
- integrity sha512-jvElSjyuo4EMQGoTwo1uJU5pQMwTW5lS1x05zzfJuTIyLR3zwO27LYrxNg+dlvKpGOuGy/MzBdXh80g0ve5+HA==
- dependencies:
- path-exists "^2.0.0"
- pinkie-promise "^2.0.0"
-
-find-up@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/find-up/-/find-up-3.0.0.tgz#49169f1d7993430646da61ecc5ae355c21c97b73"
- integrity sha512-1yD6RmLI1XBfxugvORwlck6f75tYL+iR0jqwsOrOxMZyGYqUuDhJ0l4AXdO1iX/FTs9cBAMEk1gWSEx1kSbylg==
- dependencies:
- locate-path "^3.0.0"
-
-find-versions@^3.0.0:
- version "3.2.0"
- resolved "https://registry.yarnpkg.com/find-versions/-/find-versions-3.2.0.tgz#10297f98030a786829681690545ef659ed1d254e"
- integrity sha512-P8WRou2S+oe222TOCHitLy8zj+SIsVJh52VP4lvXkaFVnOFFdoWv1H1Jjvel1aI6NCFOAaeAVm8qrI0odiLcww==
- dependencies:
- semver-regex "^2.0.0"
-
-for-in@^1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/for-in/-/for-in-1.0.2.tgz#81068d295a8142ec0ac726c6e2200c30fb6d5e80"
- integrity sha512-7EwmXrOjyL+ChxMhmG5lnW9MPt1aIeZEwKhQzoBUdTV0N3zuwWDZYVJatDvZ2OyzPUvdIAZDsCetk3coyMfcnQ==
-
-forever-agent@~0.6.1:
- version "0.6.1"
- resolved "https://registry.yarnpkg.com/forever-agent/-/forever-agent-0.6.1.tgz#fbc71f0c41adeb37f96c577ad1ed42d8fdacca91"
- integrity sha512-j0KLYPhm6zeac4lz3oJ3o65qvgQCcPubiyotZrXqEaG4hNagNYO8qdlUrX5vwqv9ohqeT/Z3j6+yW067yWWdUw==
-
-form-data@~2.3.2:
- version "2.3.3"
- resolved "https://registry.yarnpkg.com/form-data/-/form-data-2.3.3.tgz#dcce52c05f644f298c6a7ab936bd724ceffbf3a6"
- integrity sha512-1lLKB2Mu3aGP1Q/2eCOx0fNbRMe7XdwktwOruhfqqd0rIJWwN4Dh+E3hrPSlDCXnSR7UtZ1N38rVXm+6+MEhJQ==
- dependencies:
- asynckit "^0.4.0"
- combined-stream "^1.0.6"
- mime-types "^2.1.12"
-
-forwarded@0.2.0:
- version "0.2.0"
- resolved "https://registry.yarnpkg.com/forwarded/-/forwarded-0.2.0.tgz#2269936428aad4c15c7ebe9779a84bf0b2a81811"
- integrity sha512-buRG0fpBtRHSTCOASe6hD258tEubFoRLb4ZNA6NxMVHNw2gOcwHo9wyablzMzOA5z9xA9L1KNjk/Nt6MT9aYow==
-
-fragment-cache@^0.2.1:
- version "0.2.1"
- resolved "https://registry.yarnpkg.com/fragment-cache/-/fragment-cache-0.2.1.tgz#4290fad27f13e89be7f33799c6bc5a0abfff0d19"
- integrity sha512-GMBAbW9antB8iZRHLoGw0b3HANt57diZYFO/HL1JGIC1MjKrdmhxvrJbupnVvpys0zsz7yBApXdQyfepKly2kA==
- dependencies:
- map-cache "^0.2.2"
-
-fresh@0.5.2:
- version "0.5.2"
- resolved "https://registry.yarnpkg.com/fresh/-/fresh-0.5.2.tgz#3d8cadd90d976569fa835ab1f8e4b23a105605a7"
- integrity sha512-zJ2mQYM18rEFOudeV4GShTGIQ7RbzA7ozbU9I/XBpm7kqgMywgmylMwXHxZJmkVoYkna9d2pVXVXPdYTP9ej8Q==
-
-from2@^2.1.1:
- version "2.3.0"
- resolved "https://registry.yarnpkg.com/from2/-/from2-2.3.0.tgz#8bfb5502bde4a4d36cfdeea007fcca21d7e382af"
- integrity sha512-OMcX/4IC/uqEPVgGeyfN22LJk6AZrMkRZHxcHBMBvHScDGgwTm2GT2Wkgtocyd3JfZffjj2kYUDXXII0Fk9W0g==
- dependencies:
- inherits "^2.0.1"
- readable-stream "^2.0.0"
-
-fs-constants@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/fs-constants/-/fs-constants-1.0.0.tgz#6be0de9be998ce16af8afc24497b9ee9b7ccd9ad"
- integrity sha512-y6OAwoSIf7FyjMIv94u+b5rdheZEjzR63GTyZJm5qh4Bi+2YgwLCcI/fPFZkL5PSixOt6ZNKm+w+Hfp/Bciwow==
-
-fs-extra@^5.0.0:
- version "5.0.0"
- resolved "https://registry.yarnpkg.com/fs-extra/-/fs-extra-5.0.0.tgz#414d0110cdd06705734d055652c5411260c31abd"
- integrity sha512-66Pm4RYbjzdyeuqudYqhFiNBbCIuI9kgRqLPSHIlXHidW8NIQtVdkM1yeZ4lXwuhbTETv3EUGMNHAAw6hiundQ==
- dependencies:
- graceful-fs "^4.1.2"
- jsonfile "^4.0.0"
- universalify "^0.1.0"
-
-fs.realpath@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/fs.realpath/-/fs.realpath-1.0.0.tgz#1504ad2523158caa40db4a2787cb01411994ea4f"
- integrity sha512-OO0pH2lK6a0hZnAdau5ItzHPI6pUlvI7jMVnxUQRtw4owF2wk8lOSabtGDCTP4Ggrg2MbGnWO9X8K1t4+fGMDw==
-
-fsevents@~2.3.2:
- version "2.3.2"
- resolved "https://registry.yarnpkg.com/fsevents/-/fsevents-2.3.2.tgz#8a526f78b8fdf4623b709e0b975c52c24c02fd1a"
- integrity sha512-xiqMQR4xAeHTuB9uWm+fFRcIOgKBMiOBP+eXiyT7jsgVCq1bkVygt00oASowB7EdtpOHaaPgKt812P9ab+DDKA==
-
-fstream@^1.0.12:
- version "1.0.12"
- resolved "https://registry.yarnpkg.com/fstream/-/fstream-1.0.12.tgz#4e8ba8ee2d48be4f7d0de505455548eae5932045"
- integrity sha512-WvJ193OHa0GHPEL+AycEJgxvBEwyfRkN1vhjca23OaPVMCaLCXTd5qAu82AjTcgP1UJmytkOKb63Ypde7raDIg==
- dependencies:
- graceful-fs "^4.1.2"
- inherits "~2.0.0"
- mkdirp ">=0.5 0"
- rimraf "2"
-
-function-bind@^1.1.1:
- version "1.1.1"
- resolved "https://registry.yarnpkg.com/function-bind/-/function-bind-1.1.1.tgz#a56899d3ea3c9bab874bb9773b7c5ede92f4895d"
- integrity sha512-yIovAzMX49sF8Yl58fSCWJ5svSLuaibPxXQJFLmBObTuCr0Mf1KiPopGM9NiFjiYBCbfaa2Fh6breQ6ANVTI0A==
-
-function.prototype.name@^1.1.5:
- version "1.1.5"
- resolved "https://registry.yarnpkg.com/function.prototype.name/-/function.prototype.name-1.1.5.tgz#cce0505fe1ffb80503e6f9e46cc64e46a12a9621"
- integrity sha512-uN7m/BzVKQnCUF/iW8jYea67v++2u7m5UgENbHRtdDVclOUP+FMPlCNdmk0h/ysGyo2tavMJEDqJAkJdRa1vMA==
- dependencies:
- call-bind "^1.0.2"
- define-properties "^1.1.3"
- es-abstract "^1.19.0"
- functions-have-names "^1.2.2"
-
-functions-have-names@^1.2.2:
- version "1.2.3"
- resolved "https://registry.yarnpkg.com/functions-have-names/-/functions-have-names-1.2.3.tgz#0404fe4ee2ba2f607f0e0ec3c80bae994133b834"
- integrity sha512-xckBUXyTIqT97tq2x2AMb+g163b5JFysYk0x4qxNFwbfQkmNZoiRHb6sPzI9/QV33WeuvVYBUIiD4NzNIyqaRQ==
-
-gaze@^1.1.2:
- version "1.1.3"
- resolved "https://registry.yarnpkg.com/gaze/-/gaze-1.1.3.tgz#c441733e13b927ac8c0ff0b4c3b033f28812924a"
- integrity sha512-BRdNm8hbWzFzWHERTrejLqwHDfS4GibPoq5wjTPIoJHoBtKGPg3xAFfxmM+9ztbXelxcf2hwQcaz1PtmFeue8g==
- dependencies:
- globule "^1.0.0"
-
-gensync@^1.0.0-beta.2:
- version "1.0.0-beta.2"
- resolved "https://registry.yarnpkg.com/gensync/-/gensync-1.0.0-beta.2.tgz#32a6ee76c3d7f52d46b2b1ae5d93fea8580a25e0"
- integrity sha512-3hN7NaskYvMDLQY55gnW3NQ+mesEAepTqlg+VEbj7zzqEMBVNhzcGYYeqFo/TlYz6eQiFcp1HcsCZO+nGgS8zg==
-
-get-intrinsic@^1.0.2, get-intrinsic@^1.1.0, get-intrinsic@^1.1.1, get-intrinsic@^1.1.3:
- version "1.1.3"
- resolved "https://registry.yarnpkg.com/get-intrinsic/-/get-intrinsic-1.1.3.tgz#063c84329ad93e83893c7f4f243ef63ffa351385"
- integrity sha512-QJVz1Tj7MS099PevUG5jvnt9tSkXN8K14dxQlikJuPt4uD9hHAHjLyLBiLR5zELelBdD9QNRAXZzsJx0WaDL9A==
- dependencies:
- function-bind "^1.1.1"
- has "^1.0.3"
- has-symbols "^1.0.3"
-
-get-proxy@^2.0.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/get-proxy/-/get-proxy-2.1.0.tgz#349f2b4d91d44c4d4d4e9cba2ad90143fac5ef93"
- integrity sha512-zmZIaQTWnNQb4R4fJUEp/FC51eZsc6EkErspy3xtIYStaq8EB/hDIWipxsal+E8rz0qD7f2sL/NA9Xee4RInJw==
- dependencies:
- npm-conf "^1.1.0"
-
-get-stdin@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/get-stdin/-/get-stdin-4.0.1.tgz#b968c6b0a04384324902e8bf1a5df32579a450fe"
- integrity sha512-F5aQMywwJ2n85s4hJPTT9RPxGmubonuB10MNYo17/xph174n2MIR33HRguhzVag10O/npM7SPk73LMZNP+FaWw==
-
-get-stream@3.0.0, get-stream@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/get-stream/-/get-stream-3.0.0.tgz#8e943d1358dc37555054ecbe2edb05aa174ede14"
- integrity sha512-GlhdIUuVakc8SJ6kK0zAFbiGzRFzNnY4jUuEbV9UROo4Y+0Ny4fjvcZFVTeDA4odpFyOQzaw6hXukJSq/f28sQ==
-
-get-stream@^2.2.0:
- version "2.3.1"
- resolved "https://registry.yarnpkg.com/get-stream/-/get-stream-2.3.1.tgz#5f38f93f346009666ee0150a054167f91bdd95de"
- integrity sha512-AUGhbbemXxrZJRD5cDvKtQxLuYaIbNtDTK8YqupCI393Q2KSTreEsLUN3ZxAWFGiKTzL6nKuzfcIvieflUX9qA==
- dependencies:
- object-assign "^4.0.1"
- pinkie-promise "^2.0.0"
-
-get-stream@^4.0.0:
- version "4.1.0"
- resolved "https://registry.yarnpkg.com/get-stream/-/get-stream-4.1.0.tgz#c1b255575f3dc21d59bfc79cd3d2b46b1c3a54b5"
- integrity sha512-GMat4EJ5161kIy2HevLlr4luNjBgvmj413KaQA7jt4V8B4RDsfpHk7WQ9GVqfYyyx8OS/L66Kox+rJRNklLK7w==
- dependencies:
- pump "^3.0.0"
-
-get-symbol-description@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/get-symbol-description/-/get-symbol-description-1.0.0.tgz#7fdb81c900101fbd564dd5f1a30af5aadc1e58d6"
- integrity sha512-2EmdH1YvIQiZpltCNgkuiUnyukzxM/R6NDJX31Ke3BG1Nq5b0S2PhX59UKi9vZpPDQVdqn+1IcaAwnzTT5vCjw==
- dependencies:
- call-bind "^1.0.2"
- get-intrinsic "^1.1.1"
-
-get-value@^2.0.3, get-value@^2.0.6:
- version "2.0.6"
- resolved "https://registry.yarnpkg.com/get-value/-/get-value-2.0.6.tgz#dc15ca1c672387ca76bd37ac0a395ba2042a2c28"
- integrity sha512-Ln0UQDlxH1BapMu3GPtf7CuYNwRZf2gwCuPqbyG6pB8WfmFpzqcy4xtAaAMUhnNqjMKTiCPZG2oMT3YSx8U2NA==
-
-getpass@^0.1.1:
- version "0.1.7"
- resolved "https://registry.yarnpkg.com/getpass/-/getpass-0.1.7.tgz#5eff8e3e684d569ae4cb2b1282604e8ba62149fa"
- integrity sha512-0fzj9JxOLfJ+XGLhR8ze3unN0KZCgZwiSSDz168VERjK8Wl8kVSdcu2kspd4s4wtAa1y/qrVRiAA0WclVsu0ng==
- dependencies:
- assert-plus "^1.0.0"
-
-gifsicle@^4.0.0:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/gifsicle/-/gifsicle-4.0.1.tgz#30e1e61e3ee4884ef702641b2e98a15c2127b2e2"
- integrity sha512-A/kiCLfDdV+ERV/UB+2O41mifd+RxH8jlRG8DMxZO84Bma/Fw0htqZ+hY2iaalLRNyUu7tYZQslqUBJxBggxbg==
- dependencies:
- bin-build "^3.0.0"
- bin-wrapper "^4.0.0"
- execa "^1.0.0"
- logalot "^2.0.0"
-
-glob-parent@^3.1.0:
- version "3.1.0"
- resolved "https://registry.yarnpkg.com/glob-parent/-/glob-parent-3.1.0.tgz#9e6af6299d8d3bd2bd40430832bd113df906c5ae"
- integrity sha512-E8Ak/2+dZY6fnzlR7+ueWvhsH1SjHr4jjss4YS/h4py44jY9MhK/VFdaZJAWDz6BbL21KeteKxFSFpq8OS5gVA==
- dependencies:
- is-glob "^3.1.0"
- path-dirname "^1.0.0"
-
-glob-parent@~5.1.2:
- version "5.1.2"
- resolved "https://registry.yarnpkg.com/glob-parent/-/glob-parent-5.1.2.tgz#869832c58034fe68a4093c17dc15e8340d8401c4"
- integrity sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==
- dependencies:
- is-glob "^4.0.1"
-
-glob-to-regexp@^0.3.0:
- version "0.3.0"
- resolved "https://registry.yarnpkg.com/glob-to-regexp/-/glob-to-regexp-0.3.0.tgz#8c5a1494d2066c570cc3bfe4496175acc4d502ab"
- integrity sha512-Iozmtbqv0noj0uDDqoL0zNq0VBEfK2YFoMAZoxJe4cwphvLR+JskfF30QhXHOR4m3KrE6NLRYw+U9MRXvifyig==
-
-glob@^7.0.0, glob@^7.0.5, glob@^7.1.2, glob@^7.1.3:
- version "7.2.3"
- resolved "https://registry.yarnpkg.com/glob/-/glob-7.2.3.tgz#b8df0fb802bbfa8e89bd1d938b4e16578ed44f2b"
- integrity sha512-nFR0zLpU2YCaRxwoCJvL6UvCH2JFyFVIvwTLsIf21AuHlMskA1hhTdk+LlYJtOlYt9v6dvszD2BGRqBL+iQK9Q==
- dependencies:
- fs.realpath "^1.0.0"
- inflight "^1.0.4"
- inherits "2"
- minimatch "^3.1.1"
- once "^1.3.0"
- path-is-absolute "^1.0.0"
-
-glob@~7.1.1:
- version "7.1.7"
- resolved "https://registry.yarnpkg.com/glob/-/glob-7.1.7.tgz#3b193e9233f01d42d0b3f78294bbeeb418f94a90"
- integrity sha512-OvD9ENzPLbegENnYP5UUfJIirTg4+XwMWGaQfQTY0JenxNvvIKP3U3/tAQSPIu/lHxXYSZmpXlUHeqAIdKzBLQ==
- dependencies:
- fs.realpath "^1.0.0"
- inflight "^1.0.4"
- inherits "2"
- minimatch "^3.0.4"
- once "^1.3.0"
- path-is-absolute "^1.0.0"
-
-global-modules@1.0.0, global-modules@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/global-modules/-/global-modules-1.0.0.tgz#6d770f0eb523ac78164d72b5e71a8877265cc3ea"
- integrity sha512-sKzpEkf11GpOFuw0Zzjzmt4B4UZwjOcG757PPvrfhxcLFbq0wpsgpOqxpxtxFiCG4DtG93M6XRVbF2oGdev7bg==
- dependencies:
- global-prefix "^1.0.1"
- is-windows "^1.0.1"
- resolve-dir "^1.0.0"
-
-global-prefix@^1.0.1:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/global-prefix/-/global-prefix-1.0.2.tgz#dbf743c6c14992593c655568cb66ed32c0122ebe"
- integrity sha512-5lsx1NUDHtSjfg0eHlmYvZKv8/nVqX4ckFbM+FrGcQ+04KWcWFo9P5MxPZYSzUvyzmdTbI7Eix8Q4IbELDqzKg==
- dependencies:
- expand-tilde "^2.0.2"
- homedir-polyfill "^1.0.1"
- ini "^1.3.4"
- is-windows "^1.0.1"
- which "^1.2.14"
-
-globals@^11.1.0:
- version "11.12.0"
- resolved "https://registry.yarnpkg.com/globals/-/globals-11.12.0.tgz#ab8795338868a0babd8525758018c2a7eb95c42e"
- integrity sha512-WOBp/EEGUiIsJSp7wcv/y6MO+lV9UoncWqxuFfm8eBwzWNgyfBd6Gz+IeKQ9jCmyhoH99g15M3T+QaVHFjizVA==
-
-globby@^8.0.1:
- version "8.0.2"
- resolved "https://registry.yarnpkg.com/globby/-/globby-8.0.2.tgz#5697619ccd95c5275dbb2d6faa42087c1a941d8d"
- integrity sha512-yTzMmKygLp8RUpG1Ymu2VXPSJQZjNAZPD4ywgYEaG7e4tBJeUQBO8OpXrf1RCNcEs5alsoJYPAMiIHP0cmeC7w==
- dependencies:
- array-union "^1.0.1"
- dir-glob "2.0.0"
- fast-glob "^2.0.2"
- glob "^7.1.2"
- ignore "^3.3.5"
- pify "^3.0.0"
- slash "^1.0.0"
-
-globule@^1.0.0:
- version "1.3.4"
- resolved "https://registry.yarnpkg.com/globule/-/globule-1.3.4.tgz#7c11c43056055a75a6e68294453c17f2796170fb"
- integrity sha512-OPTIfhMBh7JbBYDpa5b+Q5ptmMWKwcNcFSR/0c6t8V4f3ZAVBEsKNY37QdVqmLRYSMhOUGYrY0QhSoEpzGr/Eg==
- dependencies:
- glob "~7.1.1"
- lodash "^4.17.21"
- minimatch "~3.0.2"
-
-got@^7.0.0:
- version "7.1.0"
- resolved "https://registry.yarnpkg.com/got/-/got-7.1.0.tgz#05450fd84094e6bbea56f451a43a9c289166385a"
- integrity sha512-Y5WMo7xKKq1muPsxD+KmrR8DH5auG7fBdDVueZwETwV6VytKyU9OX/ddpq2/1hp1vIPvVb4T81dKQz3BivkNLw==
- dependencies:
- decompress-response "^3.2.0"
- duplexer3 "^0.1.4"
- get-stream "^3.0.0"
- is-plain-obj "^1.1.0"
- is-retry-allowed "^1.0.0"
- is-stream "^1.0.0"
- isurl "^1.0.0-alpha5"
- lowercase-keys "^1.0.0"
- p-cancelable "^0.3.0"
- p-timeout "^1.1.1"
- safe-buffer "^5.0.1"
- timed-out "^4.0.0"
- url-parse-lax "^1.0.0"
- url-to-options "^1.0.1"
-
-got@^8.3.1:
- version "8.3.2"
- resolved "https://registry.yarnpkg.com/got/-/got-8.3.2.tgz#1d23f64390e97f776cac52e5b936e5f514d2e937"
- integrity sha512-qjUJ5U/hawxosMryILofZCkm3C84PLJS/0grRIpjAwu+Lkxxj5cxeCU25BG0/3mDSpXKTyZr8oh8wIgLaH0QCw==
- dependencies:
- "@sindresorhus/is" "^0.7.0"
- cacheable-request "^2.1.1"
- decompress-response "^3.3.0"
- duplexer3 "^0.1.4"
- get-stream "^3.0.0"
- into-stream "^3.1.0"
- is-retry-allowed "^1.1.0"
- isurl "^1.0.0-alpha5"
- lowercase-keys "^1.0.0"
- mimic-response "^1.0.0"
- p-cancelable "^0.4.0"
- p-timeout "^2.0.1"
- pify "^3.0.0"
- safe-buffer "^5.1.1"
- timed-out "^4.0.1"
- url-parse-lax "^3.0.0"
- url-to-options "^1.0.1"
-
-graceful-fs@^4.1.10, graceful-fs@^4.1.2, graceful-fs@^4.1.6, graceful-fs@^4.2.2:
- version "4.2.10"
- resolved "https://registry.yarnpkg.com/graceful-fs/-/graceful-fs-4.2.10.tgz#147d3a006da4ca3ce14728c7aefc287c367d7a6c"
- integrity sha512-9ByhssR2fPVsNZj478qUUbKfmL0+t5BDVyjShtyZZLiK7ZDAArFFfopyOTj0M05wE2tJPisA4iTnnXl2YoPvOA==
-
-gray-matter@^2.1.0:
- version "2.1.1"
- resolved "https://registry.yarnpkg.com/gray-matter/-/gray-matter-2.1.1.tgz#3042d9adec2a1ded6a7707a9ed2380f8a17a430e"
- integrity sha512-vbmvP1Fe/fxuT2QuLVcqb2BfK7upGhhbLIt9/owWEvPYrZZEkelLcq2HqzxosV+PQ67dUFLaAeNpH7C4hhICAA==
- dependencies:
- ansi-red "^0.1.1"
- coffee-script "^1.12.4"
- extend-shallow "^2.0.1"
- js-yaml "^3.8.1"
- toml "^2.3.2"
-
-gulp-header@^1.7.1:
- version "1.8.12"
- resolved "https://registry.yarnpkg.com/gulp-header/-/gulp-header-1.8.12.tgz#ad306be0066599127281c4f8786660e705080a84"
- integrity sha512-lh9HLdb53sC7XIZOYzTXM4lFuXElv3EVkSDhsd7DoJBj7hm+Ni7D3qYbb+Rr8DuM8nRanBvkVO9d7askreXGnQ==
- dependencies:
- concat-with-sourcemaps "*"
- lodash.template "^4.4.0"
- through2 "^2.0.0"
-
-gzip-size@3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/gzip-size/-/gzip-size-3.0.0.tgz#546188e9bdc337f673772f81660464b389dce520"
- integrity sha512-6s8trQiK+OMzSaCSVXX+iqIcLV9tC+E73jrJrJTyS4h/AJhlxHvzFKqM1YLDJWRGgHX8uLkBeXkA0njNj39L4w==
- dependencies:
- duplexer "^0.1.1"
-
-har-schema@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/har-schema/-/har-schema-2.0.0.tgz#a94c2224ebcac04782a0d9035521f24735b7ec92"
- integrity sha512-Oqluz6zhGX8cyRaTQlFMPw80bSJVG2x/cFb8ZPhUILGgHka9SsokCCOQgpveePerqidZOrT14ipqfJb7ILcW5Q==
-
-har-validator@~5.1.3:
- version "5.1.5"
- resolved "https://registry.yarnpkg.com/har-validator/-/har-validator-5.1.5.tgz#1f0803b9f8cb20c0fa13822df1ecddb36bde1efd"
- integrity sha512-nmT2T0lljbxdQZfspsno9hgrG3Uir6Ks5afism62poxqBM6sDnMEuPmzTq8XN0OEwqKLLdh1jQI3qyE66Nzb3w==
- dependencies:
- ajv "^6.12.3"
- har-schema "^2.0.0"
-
-has-ansi@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/has-ansi/-/has-ansi-2.0.0.tgz#34f5049ce1ecdf2b0649af3ef24e45ed35416d91"
- integrity sha512-C8vBJ8DwUCx19vhm7urhTuUsr4/IyP6l4VzNQDv+ryHQObW3TTTp9yB68WpYgRe2bbaGuZ/se74IqFeVnMnLZg==
- dependencies:
- ansi-regex "^2.0.0"
-
-has-bigints@^1.0.1, has-bigints@^1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/has-bigints/-/has-bigints-1.0.2.tgz#0871bd3e3d51626f6ca0966668ba35d5602d6eaa"
- integrity sha512-tSvCKtBr9lkF0Ex0aQiP9N+OpV4zi2r/Nee5VkRDbaqv35RLYMzbwQfFSZZH0kR+Rd6302UJZ2p/bJCEoR3VoQ==
-
-has-flag@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/has-flag/-/has-flag-3.0.0.tgz#b5d454dc2199ae225699f3467e5a07f3b955bafd"
- integrity sha512-sKJf1+ceQBr4SMkvQnBDNDtf4TXpVhVGateu0t918bl30FnbE2m4vNLX+VWe/dpjlb+HugGYzW7uQXH98HPEYw==
-
-has-property-descriptors@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/has-property-descriptors/-/has-property-descriptors-1.0.0.tgz#610708600606d36961ed04c196193b6a607fa861"
- integrity sha512-62DVLZGoiEBDHQyqG4w9xCuZ7eJEwNmJRWw2VY84Oedb7WFcA27fiEVe8oUQx9hAUJ4ekurquucTGwsyO1XGdQ==
- dependencies:
- get-intrinsic "^1.1.1"
-
-has-symbol-support-x@^1.4.1:
- version "1.4.2"
- resolved "https://registry.yarnpkg.com/has-symbol-support-x/-/has-symbol-support-x-1.4.2.tgz#1409f98bc00247da45da67cee0a36f282ff26455"
- integrity sha512-3ToOva++HaW+eCpgqZrCfN51IPB+7bJNVT6CUATzueB5Heb8o6Nam0V3HG5dlDvZU1Gn5QLcbahiKw/XVk5JJw==
-
-has-symbols@^1.0.1, has-symbols@^1.0.2, has-symbols@^1.0.3:
- version "1.0.3"
- resolved "https://registry.yarnpkg.com/has-symbols/-/has-symbols-1.0.3.tgz#bb7b2c4349251dce87b125f7bdf874aa7c8b39f8"
- integrity sha512-l3LCuF6MgDNwTDKkdYGEihYjt5pRPbEg46rtlmnSPlUbgmB8LOIrKJbYYFBSbnPaJexMKtiPO8hmeRjRz2Td+A==
-
-has-to-string-tag-x@^1.2.0:
- version "1.4.1"
- resolved "https://registry.yarnpkg.com/has-to-string-tag-x/-/has-to-string-tag-x-1.4.1.tgz#a045ab383d7b4b2012a00148ab0aa5f290044d4d"
- integrity sha512-vdbKfmw+3LoOYVr+mtxHaX5a96+0f3DljYd8JOqvOLsf5mw2Otda2qCDT9qRqLAhrjyQ0h7ual5nOiASpsGNFw==
- dependencies:
- has-symbol-support-x "^1.4.1"
-
-has-tostringtag@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/has-tostringtag/-/has-tostringtag-1.0.0.tgz#7e133818a7d394734f941e73c3d3f9291e658b25"
- integrity sha512-kFjcSNhnlGV1kyoGk7OXKSawH5JOb/LzUc5w9B02hOTO0dfFRjbHQKvg1d6cf3HbeUmtU9VbbV3qzZ2Teh97WQ==
- dependencies:
- has-symbols "^1.0.2"
-
-has-value@^0.3.1:
- version "0.3.1"
- resolved "https://registry.yarnpkg.com/has-value/-/has-value-0.3.1.tgz#7b1f58bada62ca827ec0a2078025654845995e1f"
- integrity sha512-gpG936j8/MzaeID5Yif+577c17TxaDmhuyVgSwtnL/q8UUTySg8Mecb+8Cf1otgLoD7DDH75axp86ER7LFsf3Q==
- dependencies:
- get-value "^2.0.3"
- has-values "^0.1.4"
- isobject "^2.0.0"
-
-has-value@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/has-value/-/has-value-1.0.0.tgz#18b281da585b1c5c51def24c930ed29a0be6b177"
- integrity sha512-IBXk4GTsLYdQ7Rvt+GRBrFSVEkmuOUy4re0Xjd9kJSUQpnTrWR4/y9RpfexN9vkAPMFuQoeWKwqzPozRTlasGw==
- dependencies:
- get-value "^2.0.6"
- has-values "^1.0.0"
- isobject "^3.0.0"
-
-has-values@^0.1.4:
- version "0.1.4"
- resolved "https://registry.yarnpkg.com/has-values/-/has-values-0.1.4.tgz#6d61de95d91dfca9b9a02089ad384bff8f62b771"
- integrity sha512-J8S0cEdWuQbqD9//tlZxiMuMNmxB8PlEwvYwuxsTmR1G5RXUePEX/SJn7aD0GMLieuZYSwNH0cQuJGwnYunXRQ==
-
-has-values@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/has-values/-/has-values-1.0.0.tgz#95b0b63fec2146619a6fe57fe75628d5a39efe4f"
- integrity sha512-ODYZC64uqzmtfGMEAX/FvZiRyWLpAC3vYnNunURUnkGVTS+mI0smVsWaPydRBsE3g+ok7h960jChO8mFcWlHaQ==
- dependencies:
- is-number "^3.0.0"
- kind-of "^4.0.0"
-
-has@^1.0.0, has@^1.0.3:
- version "1.0.3"
- resolved "https://registry.yarnpkg.com/has/-/has-1.0.3.tgz#722d7cbfc1f6aa8241f16dd814e011e1f41e8796"
- integrity sha512-f2dvO0VU6Oej7RkWJGrehjbzMAjFp5/VKPp5tTpWIV4JHHZK1/BxbFRtf/siA2SWTe09caDmVtYYzWEIbBS4zw==
- dependencies:
- function-bind "^1.1.1"
-
-hex-color-regex@^1.1.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/hex-color-regex/-/hex-color-regex-1.1.0.tgz#4c06fccb4602fe2602b3c93df82d7e7dbf1a8a8e"
- integrity sha512-l9sfDFsuqtOqKDsQdqrMRk0U85RZc0RtOR9yPI7mRVOa4FsR/BVnZ0shmQRM96Ji99kYZP/7hn1cedc1+ApsTQ==
-
-highlight.js@^9.12.0:
- version "9.18.5"
- resolved "https://registry.yarnpkg.com/highlight.js/-/highlight.js-9.18.5.tgz#d18a359867f378c138d6819edfc2a8acd5f29825"
- integrity sha512-a5bFyofd/BHCX52/8i8uJkjr9DYwXIPnM/plwI6W7ezItLGqzt7X2G2nXuYSfsIJdkwwj/g9DG1LkcGJI/dDoA==
-
-homedir-polyfill@^1.0.1:
- version "1.0.3"
- resolved "https://registry.yarnpkg.com/homedir-polyfill/-/homedir-polyfill-1.0.3.tgz#743298cef4e5af3e194161fbadcc2151d3a058e8"
- integrity sha512-eSmmWE5bZTK2Nou4g0AI3zZ9rswp7GRKoKXS1BLUkvPviOqs4YTN1djQIqrXy9k5gEtdLPy86JjRwsNM9tnDcA==
- dependencies:
- parse-passwd "^1.0.0"
-
-hosted-git-info@^2.1.4:
- version "2.8.9"
- resolved "https://registry.yarnpkg.com/hosted-git-info/-/hosted-git-info-2.8.9.tgz#dffc0bf9a21c02209090f2aa69429e1414daf3f9"
- integrity sha512-mxIDAb9Lsm6DoOJ7xH+5+X4y1LU/4Hi50L9C5sIswK3JzULS4bwk1FvjdBgvYR4bzT4tuUQiC15FE2f5HbLvYw==
-
-hsl-regex@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/hsl-regex/-/hsl-regex-1.0.0.tgz#d49330c789ed819e276a4c0d272dffa30b18fe6e"
- integrity sha512-M5ezZw4LzXbBKMruP+BNANf0k+19hDQMgpzBIYnya//Al+fjNct9Wf3b1WedLqdEs2hKBvxq/jh+DsHJLj0F9A==
-
-hsla-regex@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/hsla-regex/-/hsla-regex-1.0.0.tgz#c1ce7a3168c8c6614033a4b5f7877f3b225f9c38"
- integrity sha512-7Wn5GMLuHBjZCb2bTmnDOycho0p/7UVaAeqXZGbHrBCl6Yd/xDhQJAXe6Ga9AXJH2I5zY1dEdYw2u1UptnSBJA==
-
-htmlparser2@^3.9.1:
- version "3.10.1"
- resolved "https://registry.yarnpkg.com/htmlparser2/-/htmlparser2-3.10.1.tgz#bd679dc3f59897b6a34bb10749c855bb53a9392f"
- integrity sha512-IgieNijUMbkDovyoKObU1DUhm1iwNYE/fuifEoEHfd1oZKZDaONBSkal7Y01shxsM49R4XaMdGez3WnF9UfiCQ==
- dependencies:
- domelementtype "^1.3.1"
- domhandler "^2.3.0"
- domutils "^1.5.1"
- entities "^1.1.1"
- inherits "^2.0.1"
- readable-stream "^3.1.1"
-
-http-cache-semantics@3.8.1:
- version "3.8.1"
- resolved "https://registry.yarnpkg.com/http-cache-semantics/-/http-cache-semantics-3.8.1.tgz#39b0e16add9b605bf0a9ef3d9daaf4843b4cacd2"
- integrity sha512-5ai2iksyV8ZXmnZhHH4rWPoxxistEexSi5936zIQ1bnNTW5VnA85B6P/VpXiRM017IgRvb2kKo1a//y+0wSp3w==
-
-http-errors@2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/http-errors/-/http-errors-2.0.0.tgz#b7774a1486ef73cf7667ac9ae0858c012c57b9d3"
- integrity sha512-FtwrG/euBzaEjYeRqOgly7G0qviiXoJWnvEH2Z1plBdXgbyjv34pHTSb9zoeHMyDy33+DWy5Wt9Wo+TURtOYSQ==
- dependencies:
- depd "2.0.0"
- inherits "2.0.4"
- setprototypeof "1.2.0"
- statuses "2.0.1"
- toidentifier "1.0.1"
-
-http-parser-js@>=0.5.1:
- version "0.5.8"
- resolved "https://registry.yarnpkg.com/http-parser-js/-/http-parser-js-0.5.8.tgz#af23090d9ac4e24573de6f6aecc9d84a48bf20e3"
- integrity sha512-SGeBX54F94Wgu5RH3X5jsDtf4eHyRogWX1XGT3b4HuW3tQPM4AaBzoUji/4AAJNXCEOWZ5O0DgZmJw1947gD5Q==
-
-http-signature@~1.2.0:
- version "1.2.0"
- resolved "https://registry.yarnpkg.com/http-signature/-/http-signature-1.2.0.tgz#9aecd925114772f3d95b65a60abb8f7c18fbace1"
- integrity sha512-CAbnr6Rz4CYQkLYUtSNXxQPUH2gK8f3iWexVlsnMeD+GjlsQ0Xsy1cOX+mN3dtxYomRy21CiOzU8Uhw6OwncEQ==
- dependencies:
- assert-plus "^1.0.0"
- jsprim "^1.2.2"
- sshpk "^1.7.0"
-
-iconv-lite@0.4.24, iconv-lite@^0.4.17:
- version "0.4.24"
- resolved "https://registry.yarnpkg.com/iconv-lite/-/iconv-lite-0.4.24.tgz#2022b4b25fbddc21d2f524974a474aafe733908b"
- integrity sha512-v3MXnZAcvnywkTUEZomIActle7RXXeedOR31wwl7VlyoXO4Qi9arvSenNQWne1TcRwhCL1HwLI21bEqdpj8/rA==
- dependencies:
- safer-buffer ">= 2.1.2 < 3"
-
-ieee754@^1.1.13:
- version "1.2.1"
- resolved "https://registry.yarnpkg.com/ieee754/-/ieee754-1.2.1.tgz#8eb7a10a63fff25d15a57b001586d177d1b0d352"
- integrity sha512-dcyqhDvX1C46lXZcVqCpK+FtMRQVdIMN6/Df5js2zouUsqG7I6sFxitIC+7KYK29KdXOLHdu9zL4sFnoVQnqaA==
-
-ignore@^3.3.5:
- version "3.3.10"
- resolved "https://registry.yarnpkg.com/ignore/-/ignore-3.3.10.tgz#0a97fb876986e8081c631160f8f9f389157f0043"
- integrity sha512-Pgs951kaMm5GXP7MOvxERINe3gsaVjUWFm+UZPSq9xYriQAksyhg0csnS0KXSNRD5NmNdapXEpjxG49+AKh/ug==
-
-imagemin-gifsicle@^6.0.1:
- version "6.0.1"
- resolved "https://registry.yarnpkg.com/imagemin-gifsicle/-/imagemin-gifsicle-6.0.1.tgz#6abad4e95566d52e5a104aba1c24b4f3b48581b3"
- integrity sha512-kuu47c6iKDQ6R9J10xCwL0lgs0+sMz3LRHqRcJ2CRBWdcNmo3T5hUaM8hSZfksptZXJLGKk8heSAvwtSdB1Fng==
- dependencies:
- exec-buffer "^3.0.0"
- gifsicle "^4.0.0"
- is-gif "^3.0.0"
-
-imagemin-jpegtran@^6.0.0:
- version "6.0.0"
- resolved "https://registry.yarnpkg.com/imagemin-jpegtran/-/imagemin-jpegtran-6.0.0.tgz#c8d3bcfb6ec9c561c20a987142854be70d90b04f"
- integrity sha512-Ih+NgThzqYfEWv9t58EItncaaXIHR0u9RuhKa8CtVBlMBvY0dCIxgQJQCfwImA4AV1PMfmUKlkyIHJjb7V4z1g==
- dependencies:
- exec-buffer "^3.0.0"
- is-jpg "^2.0.0"
- jpegtran-bin "^4.0.0"
-
-imagemin-optipng@^6.0.0:
- version "6.0.0"
- resolved "https://registry.yarnpkg.com/imagemin-optipng/-/imagemin-optipng-6.0.0.tgz#a6bfc7b542fc08fc687e83dfb131249179a51a68"
- integrity sha512-FoD2sMXvmoNm/zKPOWdhKpWdFdF9qiJmKC17MxZJPH42VMAp17/QENI/lIuP7LCUnLVAloO3AUoTSNzfhpyd8A==
- dependencies:
- exec-buffer "^3.0.0"
- is-png "^1.0.0"
- optipng-bin "^5.0.0"
-
-imagemin-svgo@^7.0.0:
- version "7.1.0"
- resolved "https://registry.yarnpkg.com/imagemin-svgo/-/imagemin-svgo-7.1.0.tgz#528a42fd3d55eff5d4af8fd1113f25fb61ad6d9a"
- integrity sha512-0JlIZNWP0Luasn1HT82uB9nU9aa+vUj6kpT+MjPW11LbprXC+iC4HDwn1r4Q2/91qj4iy9tRZNsFySMlEpLdpg==
- dependencies:
- is-svg "^4.2.1"
- svgo "^1.3.2"
-
-imagemin@^6.0.0:
- version "6.1.0"
- resolved "https://registry.yarnpkg.com/imagemin/-/imagemin-6.1.0.tgz#62508b465728fea36c03cdc07d915fe2d8cf9e13"
- integrity sha512-8ryJBL1CN5uSHpiBMX0rJw79C9F9aJqMnjGnrd/1CafegpNuA81RBAAru/jQQEOWlOJJlpRnlcVFF6wq+Ist0A==
- dependencies:
- file-type "^10.7.0"
- globby "^8.0.1"
- make-dir "^1.0.0"
- p-pipe "^1.1.0"
- pify "^4.0.1"
- replace-ext "^1.0.0"
-
-import-fresh@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/import-fresh/-/import-fresh-2.0.0.tgz#d81355c15612d386c61f9ddd3922d4304822a546"
- integrity sha512-eZ5H8rcgYazHbKC3PG4ClHNykCSxtAhxSSEM+2mb+7evD2CKF5V7c0dNum7AdpDh0ZdICwZY9sRSn8f+KH96sg==
- dependencies:
- caller-path "^2.0.0"
- resolve-from "^3.0.0"
-
-import-lazy@^3.1.0:
- version "3.1.0"
- resolved "https://registry.yarnpkg.com/import-lazy/-/import-lazy-3.1.0.tgz#891279202c8a2280fdbd6674dbd8da1a1dfc67cc"
- integrity sha512-8/gvXvX2JMn0F+CDlSC4l6kOmVaLOO3XLkksI7CI3Ud95KDYJuYur2b9P/PUt/i/pDAMd/DulQsNbbbmRRsDIQ==
-
-indent-string@^2.1.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/indent-string/-/indent-string-2.1.0.tgz#8e2d48348742121b4a8218b7a137e9a52049dc80"
- integrity sha512-aqwDFWSgSgfRaEwao5lg5KEcVd/2a+D1rvoG7NdilmYz0NwRk6StWpWdz/Hpk34MKPpx7s8XxUqimfcQK6gGlg==
- dependencies:
- repeating "^2.0.0"
-
-indexes-of@^1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/indexes-of/-/indexes-of-1.0.1.tgz#f30f716c8e2bd346c7b67d3df3915566a7c05607"
- integrity sha512-bup+4tap3Hympa+JBJUG7XuOsdNQ6fxt0MHyXMKuLBKn0OqsTfvUxkUrroEX1+B2VsSHvCjiIcZVxRtYa4nllA==
-
-inflight@^1.0.4:
- version "1.0.6"
- resolved "https://registry.yarnpkg.com/inflight/-/inflight-1.0.6.tgz#49bd6331d7d02d0c09bc910a1075ba8165b56df9"
- integrity sha512-k92I/b08q4wvFscXCLvqfsHCrjrF7yiXsQuIVvVE7N82W3+aqpzuUdBbfhWcy/FZR3/4IgflMgKLOsvPDrGCJA==
- dependencies:
- once "^1.3.0"
- wrappy "1"
-
-inherits@2, inherits@2.0.4, inherits@^2.0.1, inherits@^2.0.3, inherits@~2.0.0, inherits@~2.0.3:
- version "2.0.4"
- resolved "https://registry.yarnpkg.com/inherits/-/inherits-2.0.4.tgz#0fa2c64f932917c3433a0ded55363aae37416b7c"
- integrity sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==
-
-ini@^1.3.4:
- version "1.3.8"
- resolved "https://registry.yarnpkg.com/ini/-/ini-1.3.8.tgz#a29da425b48806f34767a4efce397269af28432c"
- integrity sha512-JV/yugV2uzW5iMRSiZAyDtQd+nxtUnjeLt0acNdw98kKLrvuRVyB80tsREOE7yvGVgalhZ6RNXCmEHkUKBKxew==
-
-inquirer@3.3.0:
- version "3.3.0"
- resolved "https://registry.yarnpkg.com/inquirer/-/inquirer-3.3.0.tgz#9dd2f2ad765dcab1ff0443b491442a20ba227dc9"
- integrity sha512-h+xtnyk4EwKvFWHrUYsWErEVR+igKtLdchu+o0Z1RL7VU/jVMFbYir2bp6bAj8efFNxWqHX0dIss6fJQ+/+qeQ==
- dependencies:
- ansi-escapes "^3.0.0"
- chalk "^2.0.0"
- cli-cursor "^2.1.0"
- cli-width "^2.0.0"
- external-editor "^2.0.4"
- figures "^2.0.0"
- lodash "^4.3.0"
- mute-stream "0.0.7"
- run-async "^2.2.0"
- rx-lite "^4.0.8"
- rx-lite-aggregates "^4.0.8"
- string-width "^2.1.0"
- strip-ansi "^4.0.0"
- through "^2.3.6"
-
-internal-slot@^1.0.3:
- version "1.0.3"
- resolved "https://registry.yarnpkg.com/internal-slot/-/internal-slot-1.0.3.tgz#7347e307deeea2faac2ac6205d4bc7d34967f59c"
- integrity sha512-O0DB1JC/sPyZl7cIo78n5dR7eUSwwpYPiXRhTzNxZVAMUuB8vlnRFyLxdrVToks6XPLVnFfbzaVd5WLjhgg+vA==
- dependencies:
- get-intrinsic "^1.1.0"
- has "^1.0.3"
- side-channel "^1.0.4"
-
-interpret@^1.0.0:
- version "1.4.0"
- resolved "https://registry.yarnpkg.com/interpret/-/interpret-1.4.0.tgz#665ab8bc4da27a774a40584e812e3e0fa45b1a1e"
- integrity sha512-agE4QfB2Lkp9uICn7BAqoscw4SZP9kTE2hxiFI3jBPmXJfdqiahTbUuKGsMoN2GtqL9AxhYioAcVvgsb1HvRbA==
-
-into-stream@^3.1.0:
- version "3.1.0"
- resolved "https://registry.yarnpkg.com/into-stream/-/into-stream-3.1.0.tgz#96fb0a936c12babd6ff1752a17d05616abd094c6"
- integrity sha512-TcdjPibTksa1NQximqep2r17ISRiNE9fwlfbg3F8ANdvP5/yrFTew86VcO//jk4QTaMlbjypPBq76HN2zaKfZQ==
- dependencies:
- from2 "^2.1.1"
- p-is-promise "^1.1.0"
-
-ipaddr.js@1.9.1:
- version "1.9.1"
- resolved "https://registry.yarnpkg.com/ipaddr.js/-/ipaddr.js-1.9.1.tgz#bff38543eeb8984825079ff3a2a8e6cbd46781b3"
- integrity sha512-0KI/607xoxSToH7GjN1FfSbLoU0+btTicjsQSWQlh/hZykN8KpmMf7uYwPW3R+akZ6R/w18ZlXSHBYXiYUPO3g==
-
-is-absolute-url@^2.0.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/is-absolute-url/-/is-absolute-url-2.1.0.tgz#50530dfb84fcc9aa7dbe7852e83a37b93b9f2aa6"
- integrity sha512-vOx7VprsKyllwjSkLV79NIhpyLfr3jAp7VaTCMXOJHu4m0Ew1CZ2fcjASwmV1jI3BWuWHB013M48eyeldk9gYg==
-
-is-accessor-descriptor@^0.1.6:
- version "0.1.6"
- resolved "https://registry.yarnpkg.com/is-accessor-descriptor/-/is-accessor-descriptor-0.1.6.tgz#a9e12cb3ae8d876727eeef3843f8a0897b5c98d6"
- integrity sha512-e1BM1qnDbMRG3ll2U9dSK0UMHuWOs3pY3AtcFsmvwPtKL3MML/Q86i+GilLfvqEs4GW+ExB91tQ3Ig9noDIZ+A==
- dependencies:
- kind-of "^3.0.2"
-
-is-accessor-descriptor@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/is-accessor-descriptor/-/is-accessor-descriptor-1.0.0.tgz#169c2f6d3df1f992618072365c9b0ea1f6878656"
- integrity sha512-m5hnHTkcVsPfqx3AKlyttIPb7J+XykHvJP2B9bZDjlhLIoEq4XoK64Vg7boZlVWYK6LUY94dYPEE7Lh0ZkZKcQ==
- dependencies:
- kind-of "^6.0.0"
-
-is-arrayish@^0.2.1:
- version "0.2.1"
- resolved "https://registry.yarnpkg.com/is-arrayish/-/is-arrayish-0.2.1.tgz#77c99840527aa8ecb1a8ba697b80645a7a926a9d"
- integrity sha512-zz06S8t0ozoDXMG+ube26zeCTNXcKIPJZJi8hBrF4idCLms4CG9QtK7qBl1boi5ODzFpjswb5JPmHCbMpjaYzg==
-
-is-arrayish@^0.3.1:
- version "0.3.2"
- resolved "https://registry.yarnpkg.com/is-arrayish/-/is-arrayish-0.3.2.tgz#4574a2ae56f7ab206896fb431eaeed066fdf8f03"
- integrity sha512-eVRqCvVlZbuw3GrM63ovNSNAeA1K16kaR/LRY/92w0zxQ5/1YzwblUX652i4Xs9RwAGjW9d9y6X88t8OaAJfWQ==
-
-is-bigint@^1.0.1:
- version "1.0.4"
- resolved "https://registry.yarnpkg.com/is-bigint/-/is-bigint-1.0.4.tgz#08147a1875bc2b32005d41ccd8291dffc6691df3"
- integrity sha512-zB9CruMamjym81i2JZ3UMn54PKGsQzsJeo6xvN3HJJ4CAsQNB6iRutp2To77OfCNuoxspsIhzaPoO1zyCEhFOg==
- dependencies:
- has-bigints "^1.0.1"
-
-is-binary-path@~2.1.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/is-binary-path/-/is-binary-path-2.1.0.tgz#ea1f7f3b80f064236e83470f86c09c254fb45b09"
- integrity sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==
- dependencies:
- binary-extensions "^2.0.0"
-
-is-boolean-object@^1.1.0:
- version "1.1.2"
- resolved "https://registry.yarnpkg.com/is-boolean-object/-/is-boolean-object-1.1.2.tgz#5c6dc200246dd9321ae4b885a114bb1f75f63719"
- integrity sha512-gDYaKHJmnj4aWxyj6YHyXVpdQawtVLHU5cb+eztPGczf6cjuTdwve5ZIEfgXqH4e57An1D1AKf8CZ3kYrQRqYA==
- dependencies:
- call-bind "^1.0.2"
- has-tostringtag "^1.0.0"
-
-is-buffer@^1.1.5:
- version "1.1.6"
- resolved "https://registry.yarnpkg.com/is-buffer/-/is-buffer-1.1.6.tgz#efaa2ea9daa0d7ab2ea13a97b2b8ad51fefbe8be"
- integrity sha512-NcdALwpXkTm5Zvvbk7owOUSvVvBKDgKP5/ewfXEznmQFfs4ZRmanOeKBTjRVjka3QFoN6XJ+9F3USqfHqTaU5w==
-
-is-callable@^1.1.4, is-callable@^1.2.7:
- version "1.2.7"
- resolved "https://registry.yarnpkg.com/is-callable/-/is-callable-1.2.7.tgz#3bc2a85ea742d9e36205dcacdd72ca1fdc51b055"
- integrity sha512-1BC0BVFhS/p0qtw6enp8e+8OD0UrK0oFLztSjNzhcKA3WDuJxxAPXzPuPtKkjEY9UUoEWlX/8fgKeu2S8i9JTA==
-
-is-color-stop@^1.0.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/is-color-stop/-/is-color-stop-1.1.0.tgz#cfff471aee4dd5c9e158598fbe12967b5cdad345"
- integrity sha512-H1U8Vz0cfXNujrJzEcvvwMDW9Ra+biSYA3ThdQvAnMLJkEHQXn6bWzLkxHtVYJ+Sdbx0b6finn3jZiaVe7MAHA==
- dependencies:
- css-color-names "^0.0.4"
- hex-color-regex "^1.1.0"
- hsl-regex "^1.0.0"
- hsla-regex "^1.0.0"
- rgb-regex "^1.0.1"
- rgba-regex "^1.0.0"
-
-is-core-module@^2.9.0:
- version "2.11.0"
- resolved "https://registry.yarnpkg.com/is-core-module/-/is-core-module-2.11.0.tgz#ad4cb3e3863e814523c96f3f58d26cc570ff0144"
- integrity sha512-RRjxlvLDkD1YJwDbroBHMb+cukurkDWNyHx7D3oNB5x9rb5ogcksMC5wHCadcXoo67gVr/+3GFySh3134zi6rw==
- dependencies:
- has "^1.0.3"
-
-is-data-descriptor@^0.1.4:
- version "0.1.4"
- resolved "https://registry.yarnpkg.com/is-data-descriptor/-/is-data-descriptor-0.1.4.tgz#0b5ee648388e2c860282e793f1856fec3f301b56"
- integrity sha512-+w9D5ulSoBNlmw9OHn3U2v51SyoCd0he+bB3xMl62oijhrspxowjU+AIcDY0N3iEJbUEkB15IlMASQsxYigvXg==
- dependencies:
- kind-of "^3.0.2"
-
-is-data-descriptor@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/is-data-descriptor/-/is-data-descriptor-1.0.0.tgz#d84876321d0e7add03990406abbbbd36ba9268c7"
- integrity sha512-jbRXy1FmtAoCjQkVmIVYwuuqDFUbaOeDjmed1tOGPrsMhtJA4rD9tkgA0F1qJ3gRFRXcHYVkdeaP50Q5rE/jLQ==
- dependencies:
- kind-of "^6.0.0"
-
-is-date-object@^1.0.1:
- version "1.0.5"
- resolved "https://registry.yarnpkg.com/is-date-object/-/is-date-object-1.0.5.tgz#0841d5536e724c25597bf6ea62e1bd38298df31f"
- integrity sha512-9YQaSxsAiSwcvS33MBk3wTCVnWK+HhF8VZR2jRxehM16QcVOdHqPn4VPHmRK4lSr38n9JriurInLcP90xsYNfQ==
- dependencies:
- has-tostringtag "^1.0.0"
-
-is-descriptor@^0.1.0:
- version "0.1.6"
- resolved "https://registry.yarnpkg.com/is-descriptor/-/is-descriptor-0.1.6.tgz#366d8240dde487ca51823b1ab9f07a10a78251ca"
- integrity sha512-avDYr0SB3DwO9zsMov0gKCESFYqCnE4hq/4z3TdUlukEy5t9C0YRq7HLrsN52NAcqXKaepeCD0n+B0arnVG3Hg==
- dependencies:
- is-accessor-descriptor "^0.1.6"
- is-data-descriptor "^0.1.4"
- kind-of "^5.0.0"
-
-is-descriptor@^1.0.0, is-descriptor@^1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/is-descriptor/-/is-descriptor-1.0.2.tgz#3b159746a66604b04f8c81524ba365c5f14d86ec"
- integrity sha512-2eis5WqQGV7peooDyLmNEPUrps9+SXX5c9pL3xEB+4e9HnGuDa7mB7kHxHw4CbqS9k1T2hOH3miL8n8WtiYVtg==
- dependencies:
- is-accessor-descriptor "^1.0.0"
- is-data-descriptor "^1.0.0"
- kind-of "^6.0.2"
-
-is-directory@^0.3.1:
- version "0.3.1"
- resolved "https://registry.yarnpkg.com/is-directory/-/is-directory-0.3.1.tgz#61339b6f2475fc772fd9c9d83f5c8575dc154ae1"
- integrity sha512-yVChGzahRFvbkscn2MlwGismPO12i9+znNruC5gVEntG3qu0xQMzsGg/JFbrsqDOHtHFPci+V5aP5T9I+yeKqw==
-
-is-extendable@^0.1.0, is-extendable@^0.1.1:
- version "0.1.1"
- resolved "https://registry.yarnpkg.com/is-extendable/-/is-extendable-0.1.1.tgz#62b110e289a471418e3ec36a617d472e301dfc89"
- integrity sha512-5BMULNob1vgFX6EjQw5izWDxrecWK9AM72rugNr0TFldMOi0fj6Jk+zeKIt0xGj4cEfQIJth4w3OKWOJ4f+AFw==
-
-is-extendable@^1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/is-extendable/-/is-extendable-1.0.1.tgz#a7470f9e426733d81bd81e1155264e3a3507cab4"
- integrity sha512-arnXMxT1hhoKo9k1LZdmlNyJdDDfy2v0fXjFlmok4+i8ul/6WlbVge9bhM74OpNPQPMGUToDtz+KXa1PneJxOA==
- dependencies:
- is-plain-object "^2.0.4"
-
-is-extglob@^2.1.0, is-extglob@^2.1.1:
- version "2.1.1"
- resolved "https://registry.yarnpkg.com/is-extglob/-/is-extglob-2.1.1.tgz#a88c02535791f02ed37c76a1b9ea9773c833f8c2"
- integrity sha512-SbKbANkN603Vi4jEZv49LeVJMn4yGwsbzZworEoyEiutsN3nJYdbO36zfhGJ6QEDpOZIFkDtnq5JRxmvl3jsoQ==
-
-is-finite@^1.0.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/is-finite/-/is-finite-1.1.0.tgz#904135c77fb42c0641d6aa1bcdbc4daa8da082f3"
- integrity sha512-cdyMtqX/BOqqNBBiKlIVkytNHm49MtMlYyn1zxzvJKWmFMlGzm+ry5BBfYyeY9YmNKbRSo/o7OX9w9ale0wg3w==
-
-is-fullwidth-code-point@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/is-fullwidth-code-point/-/is-fullwidth-code-point-2.0.0.tgz#a3b30a5c4f199183167aaab93beefae3ddfb654f"
- integrity sha512-VHskAKYM8RfSFXwee5t5cbN5PZeq1Wrh6qd5bkyiXIf6UQcN6w/A0eXM9r6t8d+GYOh+o6ZhiEnb88LN/Y8m2w==
-
-is-gif@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/is-gif/-/is-gif-3.0.0.tgz#c4be60b26a301d695bb833b20d9b5d66c6cf83b1"
- integrity sha512-IqJ/jlbw5WJSNfwQ/lHEDXF8rxhRgF6ythk2oiEvhpG29F704eX9NO6TvPfMiq9DrbwgcEDnETYNcZDPewQoVw==
- dependencies:
- file-type "^10.4.0"
-
-is-glob@^3.1.0:
- version "3.1.0"
- resolved "https://registry.yarnpkg.com/is-glob/-/is-glob-3.1.0.tgz#7ba5ae24217804ac70707b96922567486cc3e84a"
- integrity sha512-UFpDDrPgM6qpnFNI+rh/p3bUaq9hKLZN8bMUWzxmcnZVS3omf4IPK+BrewlnWjO1WmUsMYuSjKh4UJuV4+Lqmw==
- dependencies:
- is-extglob "^2.1.0"
-
-is-glob@^4.0.0, is-glob@^4.0.1, is-glob@~4.0.1:
- version "4.0.3"
- resolved "https://registry.yarnpkg.com/is-glob/-/is-glob-4.0.3.tgz#64f61e42cbbb2eec2071a9dac0b28ba1e65d5084"
- integrity sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==
- dependencies:
- is-extglob "^2.1.1"
-
-is-jpg@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/is-jpg/-/is-jpg-2.0.0.tgz#2e1997fa6e9166eaac0242daae443403e4ef1d97"
- integrity sha512-ODlO0ruzhkzD3sdynIainVP5eoOFNN85rxA1+cwwnPe4dKyX0r5+hxNO5XpCrxlHcmb9vkOit9mhRD2JVuimHg==
-
-is-natural-number@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/is-natural-number/-/is-natural-number-4.0.1.tgz#ab9d76e1db4ced51e35de0c72ebecf09f734cde8"
- integrity sha512-Y4LTamMe0DDQIIAlaer9eKebAlDSV6huy+TWhJVPlzZh2o4tRP5SQWFlLn5N0To4mDD22/qdOq+veo1cSISLgQ==
-
-is-negative-zero@^2.0.2:
- version "2.0.2"
- resolved "https://registry.yarnpkg.com/is-negative-zero/-/is-negative-zero-2.0.2.tgz#7bf6f03a28003b8b3965de3ac26f664d765f3150"
- integrity sha512-dqJvarLawXsFbNDeJW7zAz8ItJ9cd28YufuuFzh0G8pNHjJMnY08Dv7sYX2uF5UpQOwieAeOExEYAWWfu7ZZUA==
-
-is-number-object@^1.0.4:
- version "1.0.7"
- resolved "https://registry.yarnpkg.com/is-number-object/-/is-number-object-1.0.7.tgz#59d50ada4c45251784e9904f5246c742f07a42fc"
- integrity sha512-k1U0IRzLMo7ZlYIfzRu23Oh6MiIFasgpb9X76eqfFZAqwH44UI4KTBvBYIZ1dSL9ZzChTB9ShHfLkR4pdW5krQ==
- dependencies:
- has-tostringtag "^1.0.0"
-
-is-number@^2.1.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/is-number/-/is-number-2.1.0.tgz#01fcbbb393463a548f2f466cce16dece49db908f"
- integrity sha512-QUzH43Gfb9+5yckcrSA0VBDwEtDUchrk4F6tfJZQuNzDJbEDB9cZNzSfXGQ1jqmdDY/kl41lUOWM9syA8z8jlg==
- dependencies:
- kind-of "^3.0.2"
-
-is-number@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/is-number/-/is-number-3.0.0.tgz#24fd6201a4782cf50561c810276afc7d12d71195"
- integrity sha512-4cboCqIpliH+mAvFNegjZQ4kgKc3ZUhQVr3HvWbSh5q3WH2v82ct+T2Y1hdU5Gdtorx/cLifQjqCbL7bpznLTg==
- dependencies:
- kind-of "^3.0.2"
-
-is-number@^4.0.0:
- version "4.0.0"
- resolved "https://registry.yarnpkg.com/is-number/-/is-number-4.0.0.tgz#0026e37f5454d73e356dfe6564699867c6a7f0ff"
- integrity sha512-rSklcAIlf1OmFdyAqbnWTLVelsQ58uvZ66S/ZyawjWqIviTWCjg2PzVGw8WUA+nNuPTqb4wgA+NszrJ+08LlgQ==
-
-is-number@^7.0.0:
- version "7.0.0"
- resolved "https://registry.yarnpkg.com/is-number/-/is-number-7.0.0.tgz#7535345b896734d5f80c4d06c50955527a14f12b"
- integrity sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==
-
-is-obj@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/is-obj/-/is-obj-2.0.0.tgz#473fb05d973705e3fd9620545018ca8e22ef4982"
- integrity sha512-drqDG3cbczxxEJRoOXcOjtdp1J/lyp1mNn0xaznRs8+muBhgQcrnbspox5X5fOw0HnMnbfDzvnEMEtqDEJEo8w==
-
-is-object@^1.0.1:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/is-object/-/is-object-1.0.2.tgz#a56552e1c665c9e950b4a025461da87e72f86fcf"
- integrity sha512-2rRIahhZr2UWb45fIOuvZGpFtz0TyOZLf32KxBbSoUCeZR495zCKlWUKKUByk3geS2eAs7ZAABt0Y/Rx0GiQGA==
-
-is-plain-obj@^1.0.0, is-plain-obj@^1.1.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/is-plain-obj/-/is-plain-obj-1.1.0.tgz#71a50c8429dfca773c92a390a4a03b39fcd51d3e"
- integrity sha512-yvkRyxmFKEOQ4pNXCmJG5AEQNlXJS5LaONXo5/cLdTZdWvsZ1ioJEonLGAosKlMWE8lwUy/bJzMjcw8az73+Fg==
-
-is-plain-object@^2.0.3, is-plain-object@^2.0.4:
- version "2.0.4"
- resolved "https://registry.yarnpkg.com/is-plain-object/-/is-plain-object-2.0.4.tgz#2c163b3fafb1b606d9d17928f05c2a1c38e07677"
- integrity sha512-h5PpgXkWitc38BBMYawTYMWJHFZJVnBquFE57xFpjB8pJFiF6gZ+bU+WyI/yqXiFR5mdLsgYNaPe8uao6Uv9Og==
- dependencies:
- isobject "^3.0.1"
-
-is-png@^1.0.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/is-png/-/is-png-1.1.0.tgz#d574b12bf275c0350455570b0e5b57ab062077ce"
- integrity sha512-23Rmps8UEx3Bzqr0JqAtQo0tYP6sDfIfMt1rL9rzlla/zbteftI9LSJoqsIoGgL06sJboDGdVns4RTakAW/WTw==
-
-is-regex@^1.1.4:
- version "1.1.4"
- resolved "https://registry.yarnpkg.com/is-regex/-/is-regex-1.1.4.tgz#eef5663cd59fa4c0ae339505323df6854bb15958"
- integrity sha512-kvRdxDsxZjhzUX07ZnLydzS1TU/TJlTUHHY4YLL87e37oUA49DfkLqgy+VjFocowy29cKvcSiu+kIv728jTTVg==
- dependencies:
- call-bind "^1.0.2"
- has-tostringtag "^1.0.0"
-
-is-resolvable@^1.0.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/is-resolvable/-/is-resolvable-1.1.0.tgz#fb18f87ce1feb925169c9a407c19318a3206ed88"
- integrity sha512-qgDYXFSR5WvEfuS5dMj6oTMEbrrSaM0CrFk2Yiq/gXnBvD9pMa2jGXxyhGLfvhZpuMZe18CJpFxAt3CRs42NMg==
-
-is-retry-allowed@^1.0.0, is-retry-allowed@^1.1.0:
- version "1.2.0"
- resolved "https://registry.yarnpkg.com/is-retry-allowed/-/is-retry-allowed-1.2.0.tgz#d778488bd0a4666a3be8a1482b9f2baafedea8b4"
- integrity sha512-RUbUeKwvm3XG2VYamhJL1xFktgjvPzL0Hq8C+6yrWIswDy3BIXGqCxhxkc30N9jqK311gVU137K8Ei55/zVJRg==
-
-is-root@1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/is-root/-/is-root-1.0.0.tgz#07b6c233bc394cd9d02ba15c966bd6660d6342d5"
- integrity sha512-1d50EJ7ipFxb9bIx213o6KPaJmHN8f+nR48UZWxWVzDx+NA3kpscxi02oQX3rGkEaLBi9m3ZayHngQc3+bBX9w==
-
-is-shared-array-buffer@^1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/is-shared-array-buffer/-/is-shared-array-buffer-1.0.2.tgz#8f259c573b60b6a32d4058a1a07430c0a7344c79"
- integrity sha512-sqN2UDu1/0y6uvXyStCOzyhAjCSlHceFoMKJW8W9EU9cvic/QdsZ0kEU93HEy3IUEFZIiH/3w+AH/UQbPHNdhA==
- dependencies:
- call-bind "^1.0.2"
-
-is-stream@^1.0.0, is-stream@^1.1.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/is-stream/-/is-stream-1.1.0.tgz#12d4a3dd4e68e0b79ceb8dbc84173ae80d91ca44"
- integrity sha512-uQPm8kcs47jx38atAcWTVxyltQYoPT68y9aWYdV6yWXSyW8mzSat0TL6CiWdZeCdF3KrAvpVtnHbTv4RN+rqdQ==
-
-is-string@^1.0.5, is-string@^1.0.7:
- version "1.0.7"
- resolved "https://registry.yarnpkg.com/is-string/-/is-string-1.0.7.tgz#0dd12bf2006f255bb58f695110eff7491eebc0fd"
- integrity sha512-tE2UXzivje6ofPW7l23cjDOMa09gb7xlAqG6jG5ej6uPV32TlWP3NKPigtaGeHNu9fohccRYvIiZMfOOnOYUtg==
- dependencies:
- has-tostringtag "^1.0.0"
-
-is-svg@^4.2.1:
- version "4.3.2"
- resolved "https://registry.yarnpkg.com/is-svg/-/is-svg-4.3.2.tgz#a119e9932e1af53f6be1969d1790d6cc5fd947d3"
- integrity sha512-mM90duy00JGMyjqIVHu9gNTjywdZV+8qNasX8cm/EEYZ53PHDgajvbBwNVvty5dwSAxLUD3p3bdo+7sR/UMrpw==
- dependencies:
- fast-xml-parser "^3.19.0"
-
-is-symbol@^1.0.2, is-symbol@^1.0.3:
- version "1.0.4"
- resolved "https://registry.yarnpkg.com/is-symbol/-/is-symbol-1.0.4.tgz#a6dac93b635b063ca6872236de88910a57af139c"
- integrity sha512-C/CPBqKWnvdcxqIARxyOh4v1UUEOCHpgDa0WYgpKDFMszcrPcffg5uhwSgPCLD2WWxmq6isisz87tzT01tuGhg==
- dependencies:
- has-symbols "^1.0.2"
-
-is-typedarray@~1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/is-typedarray/-/is-typedarray-1.0.0.tgz#e479c80858df0c1b11ddda6940f96011fcda4a9a"
- integrity sha512-cyA56iCMHAh5CdzjJIa4aohJyeO1YbwLi3Jc35MmRU6poroFjIGZzUzupGiRPOjgHg9TLu43xbpwXk523fMxKA==
-
-is-utf8@^0.2.0:
- version "0.2.1"
- resolved "https://registry.yarnpkg.com/is-utf8/-/is-utf8-0.2.1.tgz#4b0da1442104d1b336340e80797e865cf39f7d72"
- integrity sha512-rMYPYvCzsXywIsldgLaSoPlw5PfoB/ssr7hY4pLfcodrA5M/eArza1a9VmTiNIBNMjOGr1Ow9mTyU2o69U6U9Q==
-
-is-weakref@^1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/is-weakref/-/is-weakref-1.0.2.tgz#9529f383a9338205e89765e0392efc2f100f06f2"
- integrity sha512-qctsuLZmIQ0+vSSMfoVvyFe2+GSEvnmZ2ezTup1SBse9+twCCeial6EEi3Nc2KFcf6+qz2FBPnjXsk8xhKSaPQ==
- dependencies:
- call-bind "^1.0.2"
-
-is-windows@^1.0.1, is-windows@^1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/is-windows/-/is-windows-1.0.2.tgz#d1850eb9791ecd18e6182ce12a30f396634bb19d"
- integrity sha512-eXK1UInq2bPmjyX6e3VHIzMLobc4J94i4AWn+Hpq3OU5KkrRC96OAcR3PRJ/pGu6m8TRnBHP9dkXQVsT/COVIA==
-
-is-wsl@^1.1.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/is-wsl/-/is-wsl-1.1.0.tgz#1f16e4aa22b04d1336b66188a66af3c600c3a66d"
- integrity sha512-gfygJYZ2gLTDlmbWMI0CE2MwnFzSN/2SZfkMlItC4K/JBlsWVDB0bO6XhqcY13YXE7iMcAJnzTCJjPiTeJJ0Mw==
-
-is2@0.0.9:
- version "0.0.9"
- resolved "https://registry.yarnpkg.com/is2/-/is2-0.0.9.tgz#119556d1d1651a41ba105af803267c80b299f629"
- integrity sha512-coTlYFtfW9GLTi5Ub86408bKfV3/tSikXWMo0oENBCSz+RhBeOzjm0rOIerdBmcykbywUH5xMUuBtMDj1HTisQ==
- dependencies:
- deep-is "0.1.2"
-
-isarray@1.0.0, isarray@~1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/isarray/-/isarray-1.0.0.tgz#bb935d48582cba168c06834957a54a3e07124f11"
- integrity sha512-VLghIWNM6ELQzo7zwmcg0NmTVyWKYjvIeM83yjp0wRDTmUnrM678fQbcKBo6n2CJEF0szoG//ytg+TKla89ALQ==
-
-isexe@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/isexe/-/isexe-2.0.0.tgz#e8fbf374dc556ff8947a10dcb0572d633f2cfa10"
- integrity sha512-RHxMLp9lnKHGHRng9QFhRCMbYAcVpn69smSGcq3f36xjgVVWThj4qqLbTLlq7Ssj8B+fIQ1EuCEGI2lKsyQeIw==
-
-isobject@^2.0.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/isobject/-/isobject-2.1.0.tgz#f065561096a3f1da2ef46272f815c840d87e0c89"
- integrity sha512-+OUdGJlgjOBZDfxnDjYYG6zp487z0JGNQq3cYQYg5f5hKR+syHMsaztzGeml/4kGG55CSpKSpWTY+jYGgsHLgA==
- dependencies:
- isarray "1.0.0"
-
-isobject@^3.0.0, isobject@^3.0.1:
- version "3.0.1"
- resolved "https://registry.yarnpkg.com/isobject/-/isobject-3.0.1.tgz#4e431e92b11a9731636aa1f9c8d1ccbcfdab78df"
- integrity sha512-WhB9zCku7EGTj/HQQRz5aUQEUeoQZH2bWcltRErOpymJ4boYE6wL9Tbr23krRPSZ+C5zqNSrSw+Cc7sZZ4b7vg==
-
-isstream@~0.1.2:
- version "0.1.2"
- resolved "https://registry.yarnpkg.com/isstream/-/isstream-0.1.2.tgz#47e63f7af55afa6f92e1500e690eb8b8529c099a"
- integrity sha512-Yljz7ffyPbrLpLngrMtZ7NduUgVvi6wG9RJ9IUcyCd59YQ911PBJphODUcbOVbqYfxe1wuYf/LJ8PauMRwsM/g==
-
-isurl@^1.0.0-alpha5:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/isurl/-/isurl-1.0.0.tgz#b27f4f49f3cdaa3ea44a0a5b7f3462e6edc39d67"
- integrity sha512-1P/yWsxPlDtn7QeRD+ULKQPaIaN6yF368GZ2vDfv0AL0NwpStafjWCDDdn0k8wgFMWpVAqG7oJhxHnlud42i9w==
- dependencies:
- has-to-string-tag-x "^1.2.0"
- is-object "^1.0.1"
-
-jpegtran-bin@^4.0.0:
- version "4.0.0"
- resolved "https://registry.yarnpkg.com/jpegtran-bin/-/jpegtran-bin-4.0.0.tgz#d00aed809fba7aa6f30817e59eee4ddf198f8f10"
- integrity sha512-2cRl1ism+wJUoYAYFt6O/rLBfpXNWG2dUWbgcEkTt5WGMnqI46eEro8T4C5zGROxKRqyKpCBSdHPvt5UYCtxaQ==
- dependencies:
- bin-build "^3.0.0"
- bin-wrapper "^4.0.0"
- logalot "^2.0.0"
-
-"js-tokens@^3.0.0 || ^4.0.0", js-tokens@^4.0.0:
- version "4.0.0"
- resolved "https://registry.yarnpkg.com/js-tokens/-/js-tokens-4.0.0.tgz#19203fb59991df98e3a287050d4647cdeaf32499"
- integrity sha512-RdJUflcE3cUzKiMqQgsCu06FPu9UdIJO0beYbPhHN4k6apgJtifcoCtT9bcxOpYBtpD2kCM6Sbzg4CausW/PKQ==
-
-js-tokens@^3.0.2:
- version "3.0.2"
- resolved "https://registry.yarnpkg.com/js-tokens/-/js-tokens-3.0.2.tgz#9866df395102130e38f7f996bceb65443209c25b"
- integrity sha512-RjTcuD4xjtthQkaWH7dFlH85L+QaVtSoOyGdZ3g6HFhS9dFNDfLyqgm2NFe2X6cQpeFmt0452FJjFG5UameExg==
-
-js-yaml@^3.13.1, js-yaml@^3.8.1:
- version "3.14.1"
- resolved "https://registry.yarnpkg.com/js-yaml/-/js-yaml-3.14.1.tgz#dae812fdb3825fa306609a8717383c50c36a0537"
- integrity sha512-okMH7OXXJ7YrN9Ok3/SXrnu4iX9yOk+25nqX4imS2npuvTYDmo/QEZoqwZkYaIDk3jVvBOTOIEgEhaLOynBS9g==
- dependencies:
- argparse "^1.0.7"
- esprima "^4.0.0"
-
-jsbn@~0.1.0:
- version "0.1.1"
- resolved "https://registry.yarnpkg.com/jsbn/-/jsbn-0.1.1.tgz#a5e654c2e5a2deb5f201d96cefbca80c0ef2f513"
- integrity sha512-UVU9dibq2JcFWxQPA6KCqj5O42VOmAY3zQUfEKxU0KpTGXwNoCjkX1e13eHNvw/xPynt6pU0rZ1htjWTNTSXsg==
-
-jsesc@^2.5.1:
- version "2.5.2"
- resolved "https://registry.yarnpkg.com/jsesc/-/jsesc-2.5.2.tgz#80564d2e483dacf6e8ef209650a67df3f0c283a4"
- integrity sha512-OYu7XEzjkCQ3C5Ps3QIZsQfNpqoJyZZA99wd9aWd05NCtC5pWOkShK2mkL6HXQR6/Cy2lbNdPlZBpuQHXE63gA==
-
-jsesc@~0.5.0:
- version "0.5.0"
- resolved "https://registry.yarnpkg.com/jsesc/-/jsesc-0.5.0.tgz#e7dee66e35d6fc16f710fe91d5cf69f70f08911d"
- integrity sha512-uZz5UnB7u4T9LvwmFqXii7pZSouaRPorGs5who1Ip7VO0wxanFvBL7GkM6dTHlgX+jhBApRetaWpnDabOeTcnA==
-
-json-buffer@3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/json-buffer/-/json-buffer-3.0.0.tgz#5b1f397afc75d677bde8bcfc0e47e1f9a3d9a898"
- integrity sha512-CuUqjv0FUZIdXkHPI8MezCnFCdaTAacej1TZYulLoAg1h/PhwkdXFN4V/gzY4g+fMBCOV2xF+rp7t2XD2ns/NQ==
-
-json-parse-better-errors@^1.0.1:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/json-parse-better-errors/-/json-parse-better-errors-1.0.2.tgz#bb867cfb3450e69107c131d1c514bab3dc8bcaa9"
- integrity sha512-mrqyZKfX5EhL7hvqcV6WG1yYjnjeuYDzDhhcAAUrq8Po85NBQBJP+ZDUT75qZQ98IkUoBqdkExkukOU7Ts2wrw==
-
-json-schema-traverse@^0.4.1:
- version "0.4.1"
- resolved "https://registry.yarnpkg.com/json-schema-traverse/-/json-schema-traverse-0.4.1.tgz#69f6a87d9513ab8bb8fe63bdb0979c448e684660"
- integrity sha512-xbbCH5dCYU5T8LcEhhuh7HJ88HXuW3qsI3Y0zOZFKfZEHcpWiHU/Jxzk629Brsab/mMiHQti9wMP+845RPe3Vg==
-
-json-schema@0.4.0:
- version "0.4.0"
- resolved "https://registry.yarnpkg.com/json-schema/-/json-schema-0.4.0.tgz#f7de4cf6efab838ebaeb3236474cbba5a1930ab5"
- integrity sha512-es94M3nTIfsEPisRafak+HDLfHXnKBhV3vU5eqPcS3flIWqcxJWgXHXiey3YrpaNsanY5ei1VoYEbOzijuq9BA==
-
-json-stringify-safe@~5.0.1:
- version "5.0.1"
- resolved "https://registry.yarnpkg.com/json-stringify-safe/-/json-stringify-safe-5.0.1.tgz#1296a2d58fd45f19a0f6ce01d65701e2c735b6eb"
- integrity sha512-ZClg6AaYvamvYEE82d3Iyd3vSSIjQ+odgjaTzRuO3s7toCdFKczob2i0zCh7JE8kWn17yvAWhUVxvqGwUalsRA==
-
-json3@^3.3.2:
- version "3.3.3"
- resolved "https://registry.yarnpkg.com/json3/-/json3-3.3.3.tgz#7fc10e375fc5ae42c4705a5cc0aa6f62be305b81"
- integrity sha512-c7/8mbUsKigAbLkD5B010BK4D9LZm7A1pNItkEwiUZRpIN66exu/e7YQWysGun+TRKaJp8MhemM+VkfWv42aCA==
-
-json5@^2.2.1:
- version "2.2.1"
- resolved "https://registry.yarnpkg.com/json5/-/json5-2.2.1.tgz#655d50ed1e6f95ad1a3caababd2b0efda10b395c"
- integrity sha512-1hqLFMSrGHRHxav9q9gNjJ5EXznIxGVO09xQRrwplcS8qs28pZ8s8hupZAmqDwZUmVZ2Qb2jnyPOWcDH8m8dlA==
-
-jsonfile@^4.0.0:
- version "4.0.0"
- resolved "https://registry.yarnpkg.com/jsonfile/-/jsonfile-4.0.0.tgz#8771aae0799b64076b76640fca058f9c10e33ecb"
- integrity sha512-m6F1R3z8jjlf2imQHS2Qez5sjKWQzbuuhuJ/FKYFRZvPE3PuHcSMVZzfsLhGVOkfd20obL5SWEBew5ShlquNxg==
- optionalDependencies:
- graceful-fs "^4.1.6"
-
-jsonify@~0.0.0:
- version "0.0.1"
- resolved "https://registry.yarnpkg.com/jsonify/-/jsonify-0.0.1.tgz#2aa3111dae3d34a0f151c63f3a45d995d9420978"
- integrity sha512-2/Ki0GcmuqSrgFyelQq9M05y7PS0mEwuIzrf3f1fPqkVDVRvZrPZtVSMHxdgo8Aq0sxAOb/cr2aqqA3LeWHVPg==
-
-jsprim@^1.2.2:
- version "1.4.2"
- resolved "https://registry.yarnpkg.com/jsprim/-/jsprim-1.4.2.tgz#712c65533a15c878ba59e9ed5f0e26d5b77c5feb"
- integrity sha512-P2bSOMAc/ciLz6DzgjVlGJP9+BrJWu5UDGK70C2iweC5QBIeFf0ZXRvGjEj2uYgrY2MkAAhsSWHDWlFtEroZWw==
- dependencies:
- assert-plus "1.0.0"
- extsprintf "1.3.0"
- json-schema "0.4.0"
- verror "1.10.0"
-
-keyv@3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/keyv/-/keyv-3.0.0.tgz#44923ba39e68b12a7cec7df6c3268c031f2ef373"
- integrity sha512-eguHnq22OE3uVoSYG0LVWNP+4ppamWr9+zWBe1bsNcovIMy6huUJFPgy4mGwCd/rnl3vOLGW1MTlu4c57CT1xA==
- dependencies:
- json-buffer "3.0.0"
-
-kind-of@^3.0.2, kind-of@^3.0.3, kind-of@^3.2.0:
- version "3.2.2"
- resolved "https://registry.yarnpkg.com/kind-of/-/kind-of-3.2.2.tgz#31ea21a734bab9bbb0f32466d893aea51e4a3c64"
- integrity sha512-NOW9QQXMoZGg/oqnVNoNTTIFEIid1627WCffUBJEdMxYApq7mNE7CpzucIPc+ZQg25Phej7IJSmX3hO+oblOtQ==
- dependencies:
- is-buffer "^1.1.5"
-
-kind-of@^4.0.0:
- version "4.0.0"
- resolved "https://registry.yarnpkg.com/kind-of/-/kind-of-4.0.0.tgz#20813df3d712928b207378691a45066fae72dd57"
- integrity sha512-24XsCxmEbRwEDbz/qz3stgin8TTzZ1ESR56OMCN0ujYg+vRutNSiOj9bHH9u85DKgXguraugV5sFuvbD4FW/hw==
- dependencies:
- is-buffer "^1.1.5"
-
-kind-of@^5.0.0:
- version "5.1.0"
- resolved "https://registry.yarnpkg.com/kind-of/-/kind-of-5.1.0.tgz#729c91e2d857b7a419a1f9aa65685c4c33f5845d"
- integrity sha512-NGEErnH6F2vUuXDh+OlbcKW7/wOcfdRHaZ7VWtqCztfHri/++YKmP51OdWeGPuqCOba6kk2OTe5d02VmTB80Pw==
-
-kind-of@^6.0.0, kind-of@^6.0.2:
- version "6.0.3"
- resolved "https://registry.yarnpkg.com/kind-of/-/kind-of-6.0.3.tgz#07c05034a6c349fa06e24fa35aa76db4580ce4dd"
- integrity sha512-dcS1ul+9tmeD95T+x28/ehLgd9mENa3LsvDTtzm3vyBEO7RPptvAD+t44WVXaUjTBRcrpFeFlC8WCruUR456hw==
-
-lazy-cache@^2.0.2:
- version "2.0.2"
- resolved "https://registry.yarnpkg.com/lazy-cache/-/lazy-cache-2.0.2.tgz#b9190a4f913354694840859f8a8f7084d8822264"
- integrity sha512-7vp2Acd2+Kz4XkzxGxaB1FWOi8KjWIWsgdfD5MCb86DWvlLqhRPM+d6Pro3iNEL5VT9mstz5hKAlcd+QR6H3aA==
- dependencies:
- set-getter "^0.1.0"
-
-list-item@^1.1.1:
- version "1.1.1"
- resolved "https://registry.yarnpkg.com/list-item/-/list-item-1.1.1.tgz#0c65d00e287cb663ccb3cb3849a77e89ec268a56"
- integrity sha512-S3D0WZ4J6hyM8o5SNKWaMYB1ALSacPZ2nHGEuCjmHZ+dc03gFeNZoNDcqfcnO4vDhTZmNrqrpYZCdXsRh22bzw==
- dependencies:
- expand-range "^1.8.1"
- extend-shallow "^2.0.1"
- is-number "^2.1.0"
- repeat-string "^1.5.2"
-
-listenercount@~1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/listenercount/-/listenercount-1.0.1.tgz#84c8a72ab59c4725321480c975e6508342e70937"
- integrity sha512-3mk/Zag0+IJxeDrxSgaDPy4zZ3w05PRZeJNnlWhzFz5OkX49J4krc+A8X2d2M69vGMBEX0uyl8M+W+8gH+kBqQ==
-
-livereload-js@^2.3.0:
- version "2.4.0"
- resolved "https://registry.yarnpkg.com/livereload-js/-/livereload-js-2.4.0.tgz#447c31cf1ea9ab52fc20db615c5ddf678f78009c"
- integrity sha512-XPQH8Z2GDP/Hwz2PCDrh2mth4yFejwA1OZ/81Ti3LgKyhDcEjsSsqFWZojHG0va/duGd+WyosY7eXLDoOyqcPw==
-
-load-json-file@^1.0.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/load-json-file/-/load-json-file-1.1.0.tgz#956905708d58b4bab4c2261b04f59f31c99374c0"
- integrity sha512-cy7ZdNRXdablkXYNI049pthVeXFurRyb9+hA/dZzerZ0pGTx42z+y+ssxBaVV2l70t1muq5IdKhn4UtcoGUY9A==
- dependencies:
- graceful-fs "^4.1.2"
- parse-json "^2.2.0"
- pify "^2.0.0"
- pinkie-promise "^2.0.0"
- strip-bom "^2.0.0"
-
-locate-path@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/locate-path/-/locate-path-3.0.0.tgz#dbec3b3ab759758071b58fe59fc41871af21400e"
- integrity sha512-7AO748wWnIhNqAuaty2ZWHkQHRSNfPVIsPIfwEOWO22AmaoVrWavlOcMR5nzTLNYvp36X220/maaRsrec1G65A==
- dependencies:
- p-locate "^3.0.0"
- path-exists "^3.0.0"
-
-lodash._reinterpolate@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/lodash._reinterpolate/-/lodash._reinterpolate-3.0.0.tgz#0ccf2d89166af03b3663c796538b75ac6e114d9d"
- integrity sha512-xYHt68QRoYGjeeM/XOE1uJtvXQAgvszfBhjV4yvsQH0u2i9I6cI6c6/eG4Hh3UAOVn0y/xAXwmTzEay49Q//HA==
-
-lodash.assignin@^4.0.9:
- version "4.2.0"
- resolved "https://registry.yarnpkg.com/lodash.assignin/-/lodash.assignin-4.2.0.tgz#ba8df5fb841eb0a3e8044232b0e263a8dc6a28a2"
- integrity sha512-yX/rx6d/UTVh7sSVWVSIMjfnz95evAgDFdb1ZozC35I9mSFCkmzptOzevxjgbQUsc78NR44LVHWjsoMQXy9FDg==
-
-lodash.bind@^4.1.4:
- version "4.2.1"
- resolved "https://registry.yarnpkg.com/lodash.bind/-/lodash.bind-4.2.1.tgz#7ae3017e939622ac31b7d7d7dcb1b34db1690d35"
- integrity sha512-lxdsn7xxlCymgLYo1gGvVrfHmkjDiyqVv62FAeF2i5ta72BipE1SLxw8hPEPLhD4/247Ijw07UQH7Hq/chT5LA==
-
-lodash.debounce@^4.0.8:
- version "4.0.8"
- resolved "https://registry.yarnpkg.com/lodash.debounce/-/lodash.debounce-4.0.8.tgz#82d79bff30a67c4005ffd5e2515300ad9ca4d7af"
- integrity sha512-FT1yDzDYEoYWhnSGnpE/4Kj1fLZkDFyqRb7fNt6FdYOSxlUWAtp42Eh6Wb0rGIv/m9Bgo7x4GhQbm5Ys4SG5ow==
-
-lodash.defaults@^4.0.1:
- version "4.2.0"
- resolved "https://registry.yarnpkg.com/lodash.defaults/-/lodash.defaults-4.2.0.tgz#d09178716ffea4dde9e5fb7b37f6f0802274580c"
- integrity sha512-qjxPLHd3r5DnsdGacqOMU6pb/avJzdh9tFX2ymgoZE27BmjXrNy/y4LoaiTeAb+O3gL8AfpJGtqfX/ae2leYYQ==
-
-lodash.filter@^4.4.0:
- version "4.6.0"
- resolved "https://registry.yarnpkg.com/lodash.filter/-/lodash.filter-4.6.0.tgz#668b1d4981603ae1cc5a6fa760143e480b4c4ace"
- integrity sha512-pXYUy7PR8BCLwX5mgJ/aNtyOvuJTdZAo9EQFUvMIYugqmJxnrYaANvTbgndOzHSCSR0wnlBBfRXJL5SbWxo3FQ==
-
-lodash.flatten@^4.2.0:
- version "4.4.0"
- resolved "https://registry.yarnpkg.com/lodash.flatten/-/lodash.flatten-4.4.0.tgz#f31c22225a9632d2bbf8e4addbef240aa765a61f"
- integrity sha512-C5N2Z3DgnnKr0LOpv/hKCgKdb7ZZwafIrsesve6lmzvZIRZRGaZ/l6Q8+2W7NaT+ZwO3fFlSCzCzrDCFdJfZ4g==
-
-lodash.foreach@^4.3.0:
- version "4.5.0"
- resolved "https://registry.yarnpkg.com/lodash.foreach/-/lodash.foreach-4.5.0.tgz#1a6a35eace401280c7f06dddec35165ab27e3e53"
- integrity sha512-aEXTF4d+m05rVOAUG3z4vZZ4xVexLKZGF0lIxuHZ1Hplpk/3B6Z1+/ICICYRLm7c41Z2xiejbkCkJoTlypoXhQ==
-
-lodash.map@^4.4.0:
- version "4.6.0"
- resolved "https://registry.yarnpkg.com/lodash.map/-/lodash.map-4.6.0.tgz#771ec7839e3473d9c4cde28b19394c3562f4f6d3"
- integrity sha512-worNHGKLDetmcEYDvh2stPCrrQRkP20E4l0iIS7F8EvzMqBBi7ltvFN5m1HvTf1P7Jk1txKhvFcmYsCr8O2F1Q==
-
-lodash.memoize@^4.1.2:
- version "4.1.2"
- resolved "https://registry.yarnpkg.com/lodash.memoize/-/lodash.memoize-4.1.2.tgz#bcc6c49a42a2840ed997f323eada5ecd182e0bfe"
- integrity sha512-t7j+NzmgnQzTAYXcsHYLgimltOV1MXHtlOWf6GjL9Kj8GK5FInw5JotxvbOs+IvV1/Dzo04/fCGfLVs7aXb4Ag==
-
-lodash.merge@^4.4.0:
- version "4.6.2"
- resolved "https://registry.yarnpkg.com/lodash.merge/-/lodash.merge-4.6.2.tgz#558aa53b43b661e1925a0afdfa36a9a1085fe57a"
- integrity sha512-0KpjqXRVvrYyCsX1swR/XTK0va6VQkQM6MNo7PqW77ByjAhoARA8EfrP1N4+KlKj8YS0ZUCtRT/YUuhyYDujIQ==
-
-lodash.pick@^4.2.1:
- version "4.4.0"
- resolved "https://registry.yarnpkg.com/lodash.pick/-/lodash.pick-4.4.0.tgz#52f05610fff9ded422611441ed1fc123a03001b3"
- integrity sha512-hXt6Ul/5yWjfklSGvLQl8vM//l3FtyHZeuelpzK6mm99pNvN9yTDruNZPEJZD1oWrqo+izBmB7oUfWgcCX7s4Q==
-
-lodash.reduce@^4.4.0:
- version "4.6.0"
- resolved "https://registry.yarnpkg.com/lodash.reduce/-/lodash.reduce-4.6.0.tgz#f1ab6b839299ad48f784abbf476596f03b914d3b"
- integrity sha512-6raRe2vxCYBhpBu+B+TtNGUzah+hQjVdu3E17wfusjyrXBka2nBS8OH/gjVZ5PvHOhWmIZTYri09Z6n/QfnNMw==
-
-lodash.reject@^4.4.0:
- version "4.6.0"
- resolved "https://registry.yarnpkg.com/lodash.reject/-/lodash.reject-4.6.0.tgz#80d6492dc1470864bbf583533b651f42a9f52415"
- integrity sha512-qkTuvgEzYdyhiJBx42YPzPo71R1aEr0z79kAv7Ixg8wPFEjgRgJdUsGMG3Hf3OYSF/kHI79XhNlt+5Ar6OzwxQ==
-
-lodash.some@^4.4.0:
- version "4.6.0"
- resolved "https://registry.yarnpkg.com/lodash.some/-/lodash.some-4.6.0.tgz#1bb9f314ef6b8baded13b549169b2a945eb68e4d"
- integrity sha512-j7MJE+TuT51q9ggt4fSgVqro163BEFjAt3u97IqU+JA2DkWl80nFTrowzLpZ/BnpN7rrl0JA/593NAdd8p/scQ==
-
-lodash.template@^4.4.0:
- version "4.5.0"
- resolved "https://registry.yarnpkg.com/lodash.template/-/lodash.template-4.5.0.tgz#f976195cf3f347d0d5f52483569fe8031ccce8ab"
- integrity sha512-84vYFxIkmidUiFxidA/KjjH9pAycqW+h980j7Fuz5qxRtO9pgB7MDFTdys1N7A5mcucRiDyEq4fusljItR1T/A==
- dependencies:
- lodash._reinterpolate "^3.0.0"
- lodash.templatesettings "^4.0.0"
-
-lodash.templatesettings@^4.0.0:
- version "4.2.0"
- resolved "https://registry.yarnpkg.com/lodash.templatesettings/-/lodash.templatesettings-4.2.0.tgz#e481310f049d3cf6d47e912ad09313b154f0fb33"
- integrity sha512-stgLz+i3Aa9mZgnjr/O+v9ruKZsPsndy7qPZOchbqk2cnTU1ZaldKK+v7m54WoKIyxiuMZTKT2H81F8BeAc3ZQ==
- dependencies:
- lodash._reinterpolate "^3.0.0"
-
-lodash.uniq@^4.5.0:
- version "4.5.0"
- resolved "https://registry.yarnpkg.com/lodash.uniq/-/lodash.uniq-4.5.0.tgz#d0225373aeb652adc1bc82e4945339a842754773"
- integrity sha512-xfBaXQd9ryd9dlSDvnvI0lvxfLJlYAZzXomUYzLKtUeOQvOP5piqAWuGtrhWeqaXK9hhoM/iyJc5AV+XfsX3HQ==
-
-lodash@^4.17.11, lodash@^4.17.14, lodash@^4.17.21, lodash@^4.3.0:
- version "4.17.21"
- resolved "https://registry.yarnpkg.com/lodash/-/lodash-4.17.21.tgz#679591c564c3bffaae8454cf0b3df370c3d6911c"
- integrity sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg==
-
-logalot@^2.0.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/logalot/-/logalot-2.1.0.tgz#5f8e8c90d304edf12530951a5554abb8c5e3f552"
- integrity sha512-Ah4CgdSRfeCJagxQhcVNMi9BfGYyEKLa6d7OA6xSbld/Hg3Cf2QiOa1mDpmG7Ve8LOH6DN3mdttzjQAvWTyVkw==
- dependencies:
- figures "^1.3.5"
- squeak "^1.0.0"
-
-longest@^1.0.0:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/longest/-/longest-1.0.1.tgz#30a0b2da38f73770e8294a0d22e6625ed77d0097"
- integrity sha512-k+yt5n3l48JU4k8ftnKG6V7u32wyH2NfKzeMto9F/QRE0amxy/LayxwlvjjkZEIzqR+19IrtFO8p5kB9QaYUFg==
-
-loose-envify@^1.1.0, loose-envify@^1.4.0:
- version "1.4.0"
- resolved "https://registry.yarnpkg.com/loose-envify/-/loose-envify-1.4.0.tgz#71ee51fa7be4caec1a63839f7e682d8132d30caf"
- integrity sha512-lyuxPGr/Wfhrlem2CL/UcnUc1zcqKAImBDzukY7Y5F/yQiNdko6+fRLevlw1HgMySw7f611UIY408EtxRSoK3Q==
- dependencies:
- js-tokens "^3.0.0 || ^4.0.0"
-
-loud-rejection@^1.0.0:
- version "1.6.0"
- resolved "https://registry.yarnpkg.com/loud-rejection/-/loud-rejection-1.6.0.tgz#5b46f80147edee578870f086d04821cf998e551f"
- integrity sha512-RPNliZOFkqFumDhvYqOaNY4Uz9oJM2K9tC6JWsJJsNdhuONW4LQHRBpb0qf4pJApVffI5N39SwzWZJuEhfd7eQ==
- dependencies:
- currently-unhandled "^0.4.1"
- signal-exit "^3.0.0"
-
-lowercase-keys@1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/lowercase-keys/-/lowercase-keys-1.0.0.tgz#4e3366b39e7f5457e35f1324bdf6f88d0bfc7306"
- integrity sha512-RPlX0+PHuvxVDZ7xX+EBVAp4RsVxP/TdDSN2mJYdiq1Lc4Hz7EUSjUI7RZrKKlmrIzVhf6Jo2stj7++gVarS0A==
-
-lowercase-keys@^1.0.0:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/lowercase-keys/-/lowercase-keys-1.0.1.tgz#6f9e30b47084d971a7c820ff15a6c5167b74c26f"
- integrity sha512-G2Lj61tXDnVFFOi8VZds+SoQjtQC3dgokKdDG2mTm1tx4m50NUHBOZSBwQQHyy0V12A0JTG4icfZQH+xPyh8VA==
-
-lpad-align@^1.0.1:
- version "1.1.2"
- resolved "https://registry.yarnpkg.com/lpad-align/-/lpad-align-1.1.2.tgz#21f600ac1c3095c3c6e497ee67271ee08481fe9e"
- integrity sha512-MMIcFmmR9zlGZtBcFOows6c2COMekHCIFJz3ew/rRpKZ1wR4mXDPzvcVqLarux8M33X4TPSq2Jdw8WJj0q0KbQ==
- dependencies:
- get-stdin "^4.0.1"
- indent-string "^2.1.0"
- longest "^1.0.0"
- meow "^3.3.0"
-
-lru-cache@^4.0.1:
- version "4.1.5"
- resolved "https://registry.yarnpkg.com/lru-cache/-/lru-cache-4.1.5.tgz#8bbe50ea85bed59bc9e33dcab8235ee9bcf443cd"
- integrity sha512-sWZlbEP2OsHNkXrMl5GYk/jKk70MBng6UU4YI/qGDYbgf6YbP4EvmqISbXCoJiRKs+1bSpFHVgQxvJ17F2li5g==
- dependencies:
- pseudomap "^1.0.2"
- yallist "^2.1.2"
-
-make-dir@^1.0.0, make-dir@^1.2.0:
- version "1.3.0"
- resolved "https://registry.yarnpkg.com/make-dir/-/make-dir-1.3.0.tgz#79c1033b80515bd6d24ec9933e860ca75ee27f0c"
- integrity sha512-2w31R7SJtieJJnQtGc7RVL2StM2vGYVfqUOvUDxH6bC6aJTxPxTF0GnIgCyu7tjockiUWAYQRbxa7vKn34s5sQ==
- dependencies:
- pify "^3.0.0"
-
-make-dir@^2.0.0, make-dir@^2.1.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/make-dir/-/make-dir-2.1.0.tgz#5f0310e18b8be898cc07009295a30ae41e91e6f5"
- integrity sha512-LS9X+dc8KLxXCb8dni79fLIIUA5VyZoyjSMCwTluaXA0o27cCK0bhXkpgw+sTXVpPy/lSO57ilRixqk0vDmtRA==
- dependencies:
- pify "^4.0.1"
- semver "^5.6.0"
-
-map-cache@^0.2.2:
- version "0.2.2"
- resolved "https://registry.yarnpkg.com/map-cache/-/map-cache-0.2.2.tgz#c32abd0bd6525d9b051645bb4f26ac5dc98a0dbf"
- integrity sha512-8y/eV9QQZCiyn1SprXSrCmqJN0yNRATe+PO8ztwqrvrbdRLA3eYJF0yaR0YayLWkMbsQSKWS9N2gPcGEc4UsZg==
-
-map-obj@^1.0.0, map-obj@^1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/map-obj/-/map-obj-1.0.1.tgz#d933ceb9205d82bdcf4886f6742bdc2b4dea146d"
- integrity sha512-7N/q3lyZ+LVCp7PzuxrJr4KMbBE2hW7BT7YNia330OFxIf4d3r5zVpicP2650l7CPN6RM9zOJRl3NGpqSiw3Eg==
-
-map-visit@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/map-visit/-/map-visit-1.0.0.tgz#ecdca8f13144e660f1b5bd41f12f3479d98dfb8f"
- integrity sha512-4y7uGv8bd2WdM9vpQsiQNo41Ln1NvhvDRuVt0k2JZQ+ezN2uaQes7lZeZ+QQUHOLQAtDaBJ+7wCbi+ab/KFs+w==
- dependencies:
- object-visit "^1.0.0"
-
-markdown-link@^0.1.1:
- version "0.1.1"
- resolved "https://registry.yarnpkg.com/markdown-link/-/markdown-link-0.1.1.tgz#32c5c65199a6457316322d1e4229d13407c8c7cf"
- integrity sha512-TurLymbyLyo+kAUUAV9ggR9EPcDjP/ctlv9QAFiqUH7c+t6FlsbivPo9OKTU8xdOx9oNd2drW/Fi5RRElQbUqA==
-
-markdown-toc@^1.2.0:
- version "1.2.0"
- resolved "https://registry.yarnpkg.com/markdown-toc/-/markdown-toc-1.2.0.tgz#44a15606844490314afc0444483f9e7b1122c339"
- integrity sha512-eOsq7EGd3asV0oBfmyqngeEIhrbkc7XVP63OwcJBIhH2EpG2PzFcbZdhy1jutXSlRBBVMNXHvMtSr5LAxSUvUg==
- dependencies:
- concat-stream "^1.5.2"
- diacritics-map "^0.1.0"
- gray-matter "^2.1.0"
- lazy-cache "^2.0.2"
- list-item "^1.1.1"
- markdown-link "^0.1.1"
- minimist "^1.2.0"
- mixin-deep "^1.1.3"
- object.pick "^1.2.0"
- remarkable "^1.7.1"
- repeat-string "^1.6.1"
- strip-color "^0.1.0"
-
-math-random@^1.0.1:
- version "1.0.4"
- resolved "https://registry.yarnpkg.com/math-random/-/math-random-1.0.4.tgz#5dd6943c938548267016d4e34f057583080c514c"
- integrity sha512-rUxjysqif/BZQH2yhd5Aaq7vXMSx9NdEsQcyA07uEzIvxgI7zIr33gGsh+RU0/XjmQpCW7RsVof1vlkvQVCK5A==
-
-mdn-data@2.0.14:
- version "2.0.14"
- resolved "https://registry.yarnpkg.com/mdn-data/-/mdn-data-2.0.14.tgz#7113fc4281917d63ce29b43446f701e68c25ba50"
- integrity sha512-dn6wd0uw5GsdswPFfsgMp5NSB0/aDe6fK94YJV/AJDYXL6HVLWBsxeq7js7Ad+mU2K9LAlwpk6kN2D5mwCPVow==
-
-mdn-data@2.0.4:
- version "2.0.4"
- resolved "https://registry.yarnpkg.com/mdn-data/-/mdn-data-2.0.4.tgz#699b3c38ac6f1d728091a64650b65d388502fd5b"
- integrity sha512-iV3XNKw06j5Q7mi6h+9vbx23Tv7JkjEVgKHW4pimwyDGWm0OIQntJJ+u1C6mg6mK1EaTv42XQ7w76yuzH7M2cA==
-
-media-typer@0.3.0:
- version "0.3.0"
- resolved "https://registry.yarnpkg.com/media-typer/-/media-typer-0.3.0.tgz#8710d7af0aa626f8fffa1ce00168545263255748"
- integrity sha512-dq+qelQ9akHpcOl/gUVRTxVIOkAJ1wR3QAvb4RsVjS8oVoFjDGTc679wJYmUmknUF5HwMLOgb5O+a3KxfWapPQ==
-
-meow@^3.3.0:
- version "3.7.0"
- resolved "https://registry.yarnpkg.com/meow/-/meow-3.7.0.tgz#72cb668b425228290abbfa856892587308a801fb"
- integrity sha512-TNdwZs0skRlpPpCUK25StC4VH+tP5GgeY1HQOOGP+lQ2xtdkN2VtT/5tiX9k3IWpkBPV9b3LsAWXn4GGi/PrSA==
- dependencies:
- camelcase-keys "^2.0.0"
- decamelize "^1.1.2"
- loud-rejection "^1.0.0"
- map-obj "^1.0.1"
- minimist "^1.1.3"
- normalize-package-data "^2.3.4"
- object-assign "^4.0.1"
- read-pkg-up "^1.0.1"
- redent "^1.0.0"
- trim-newlines "^1.0.0"
-
-merge-descriptors@1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/merge-descriptors/-/merge-descriptors-1.0.1.tgz#b00aaa556dd8b44568150ec9d1b953f3f90cbb61"
- integrity sha512-cCi6g3/Zr1iqQi6ySbseM1Xvooa98N0w31jzUYrXPX2xqObmFGHJ0tQ5u74H3mVh7wLouTseZyYIq39g8cNp1w==
-
-merge2@^1.2.3:
- version "1.4.1"
- resolved "https://registry.yarnpkg.com/merge2/-/merge2-1.4.1.tgz#4368892f885e907455a6fd7dc55c0c9d404990ae"
- integrity sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg==
-
-methods@~1.1.2:
- version "1.1.2"
- resolved "https://registry.yarnpkg.com/methods/-/methods-1.1.2.tgz#5529a4d67654134edcc5266656835b0f851afcee"
- integrity sha512-iclAHeNqNm68zFtnZ0e+1L2yUIdvzNoauKU4WBA3VvH/vPFieF7qfRlwUZU+DA9P9bPXIS90ulxoUoCH23sV2w==
-
-micromatch@^3.1.10:
- version "3.1.10"
- resolved "https://registry.yarnpkg.com/micromatch/-/micromatch-3.1.10.tgz#70859bc95c9840952f359a068a3fc49f9ecfac23"
- integrity sha512-MWikgl9n9M3w+bpsY3He8L+w9eF9338xRl8IAO5viDizwSzziFEyUzo2xrrloB64ADbTf8uA8vRqqttDTOmccg==
- dependencies:
- arr-diff "^4.0.0"
- array-unique "^0.3.2"
- braces "^2.3.1"
- define-property "^2.0.2"
- extend-shallow "^3.0.2"
- extglob "^2.0.4"
- fragment-cache "^0.2.1"
- kind-of "^6.0.2"
- nanomatch "^1.2.9"
- object.pick "^1.3.0"
- regex-not "^1.0.0"
- snapdragon "^0.8.1"
- to-regex "^3.0.2"
-
-mime-db@1.52.0, mime-db@^1.28.0:
- version "1.52.0"
- resolved "https://registry.yarnpkg.com/mime-db/-/mime-db-1.52.0.tgz#bbabcdc02859f4987301c856e3387ce5ec43bf70"
- integrity sha512-sPU4uV7dYlvtWJxwwxHD0PuihVNiE7TyAbQ5SWxDCB9mUYvOgroQOwYQQOKPJ8CIbE+1ETVlOoK1UC2nU3gYvg==
-
-mime-types@^2.1.12, mime-types@~2.1.19, mime-types@~2.1.24, mime-types@~2.1.34:
- version "2.1.35"
- resolved "https://registry.yarnpkg.com/mime-types/-/mime-types-2.1.35.tgz#381a871b62a734450660ae3deee44813f70d959a"
- integrity sha512-ZDY+bPm5zTTF+YpCrAU9nK0UgICYPT0QtT1NZWFv4s++TNkcgVaT0g6+4R2uI4MjQjzysHB1zxuWL50hzaeXiw==
- dependencies:
- mime-db "1.52.0"
-
-mime@1.6.0:
- version "1.6.0"
- resolved "https://registry.yarnpkg.com/mime/-/mime-1.6.0.tgz#32cd9e5c64553bd58d19a568af452acff04981b1"
- integrity sha512-x0Vn8spI+wuJ1O6S7gnbaQg8Pxh4NNHb7KSINmEWKiPE4RKOplvijn+NkmYmmRgP68mc70j2EbeTFRsrswaQeg==
-
-mimic-fn@^1.0.0:
- version "1.2.0"
- resolved "https://registry.yarnpkg.com/mimic-fn/-/mimic-fn-1.2.0.tgz#820c86a39334640e99516928bd03fca88057d022"
- integrity sha512-jf84uxzwiuiIVKiOLpfYk7N46TSy8ubTonmneY9vrpHNAnp0QBt2BxWV9dO3/j+BoVAb+a5G6YDPW3M5HOdMWQ==
-
-mimic-response@^1.0.0:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/mimic-response/-/mimic-response-1.0.1.tgz#4923538878eef42063cb8a3e3b0798781487ab1b"
- integrity sha512-j5EctnkH7amfV/q5Hgmoal1g2QHFJRraOtmx0JpIqkxhBhI/lJSl1nMpQ45hVarwNETOoWEimndZ4QK0RHxuxQ==
-
-minimatch@3.0.3:
- version "3.0.3"
- resolved "https://registry.yarnpkg.com/minimatch/-/minimatch-3.0.3.tgz#2a4e4090b96b2db06a9d7df01055a62a77c9b774"
- integrity sha512-NyXjqu1IwcqH6nv5vmMtaG3iw7kdV3g6MwlUBZkc3Vn5b5AMIWYKfptvzipoyFfhlfOgBQ9zoTxQMravF1QTnw==
- dependencies:
- brace-expansion "^1.0.0"
-
-minimatch@^3.0.4, minimatch@^3.1.1:
- version "3.1.2"
- resolved "https://registry.yarnpkg.com/minimatch/-/minimatch-3.1.2.tgz#19cd194bfd3e428f049a70817c038d89ab4be35b"
- integrity sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw==
- dependencies:
- brace-expansion "^1.1.7"
-
-minimatch@~3.0.2:
- version "3.0.8"
- resolved "https://registry.yarnpkg.com/minimatch/-/minimatch-3.0.8.tgz#5e6a59bd11e2ab0de1cfb843eb2d82e546c321c1"
- integrity sha512-6FsRAQsxQ61mw+qP1ZzbL9Bc78x2p5OqNgNpnoAFLTrX8n5Kxph0CsnhmKKNXTWjXqU5L0pGPR7hYk+XWZr60Q==
- dependencies:
- brace-expansion "^1.1.7"
-
-minimist@^1.1.3, minimist@^1.2.0, minimist@^1.2.6:
- version "1.2.7"
- resolved "https://registry.yarnpkg.com/minimist/-/minimist-1.2.7.tgz#daa1c4d91f507390437c6a8bc01078e7000c4d18"
- integrity sha512-bzfL1YUZsP41gmu/qjrEk0Q6i2ix/cVeAhbCbqH9u3zYutS1cLg00qhrD0M2MVdCcx4Sc0UpP2eBWo9rotpq6g==
-
-mixin-deep@^1.1.3, mixin-deep@^1.2.0:
- version "1.3.2"
- resolved "https://registry.yarnpkg.com/mixin-deep/-/mixin-deep-1.3.2.tgz#1120b43dc359a785dce65b55b82e257ccf479566"
- integrity sha512-WRoDn//mXBiJ1H40rqa3vH0toePwSsGb45iInWlTySa+Uu4k3tYUSxa2v1KqAiLtvlrSzaExqS1gtk96A9zvEA==
- dependencies:
- for-in "^1.0.2"
- is-extendable "^1.0.1"
-
-"mkdirp@>=0.5 0", mkdirp@^0.5.1, mkdirp@^0.5.6, mkdirp@~0.5.1:
- version "0.5.6"
- resolved "https://registry.yarnpkg.com/mkdirp/-/mkdirp-0.5.6.tgz#7def03d2432dcae4ba1d611445c48396062255f6"
- integrity sha512-FP+p8RB8OWpF3YZBCrP5gtADmtXApB5AMLn+vdyA+PyxCjrCs00mjyUozssO33cwDeT3wNGdLxJ5M//YqtHAJw==
- dependencies:
- minimist "^1.2.6"
-
-ms@2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/ms/-/ms-2.0.0.tgz#5608aeadfc00be6c2901df5f9861788de0d597c8"
- integrity sha512-Tpp60P6IUJDTuOq/5Z8cdskzJujfwqfOTkrwIwj7IRISpnkJnT6SyJ4PCPnGMoFjC9ddhal5KVIYtAt97ix05A==
-
-ms@2.1.2:
- version "2.1.2"
- resolved "https://registry.yarnpkg.com/ms/-/ms-2.1.2.tgz#d09d1f357b443f493382a8eb3ccd183872ae6009"
- integrity sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==
-
-ms@2.1.3, ms@^2.1.1:
- version "2.1.3"
- resolved "https://registry.yarnpkg.com/ms/-/ms-2.1.3.tgz#574c8138ce1d2b5861f0b44579dbadd60c6615b2"
- integrity sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==
-
-mute-stream@0.0.7:
- version "0.0.7"
- resolved "https://registry.yarnpkg.com/mute-stream/-/mute-stream-0.0.7.tgz#3075ce93bc21b8fab43e1bc4da7e8115ed1e7bab"
- integrity sha512-r65nCZhrbXXb6dXOACihYApHw2Q6pV0M3V0PSxd74N0+D8nzAdEAITq2oAjA1jVnKI+tGvEBUpqiMh0+rW6zDQ==
-
-nanomatch@^1.2.9:
- version "1.2.13"
- resolved "https://registry.yarnpkg.com/nanomatch/-/nanomatch-1.2.13.tgz#b87a8aa4fc0de8fe6be88895b38983ff265bd119"
- integrity sha512-fpoe2T0RbHwBTBUOftAfBPaDEi06ufaUai0mE6Yn1kacc3SnTErfb/h+X94VXzI64rKFHYImXSvdwGGCmwOqCA==
- dependencies:
- arr-diff "^4.0.0"
- array-unique "^0.3.2"
- define-property "^2.0.2"
- extend-shallow "^3.0.2"
- fragment-cache "^0.2.1"
- is-windows "^1.0.2"
- kind-of "^6.0.2"
- object.pick "^1.3.0"
- regex-not "^1.0.0"
- snapdragon "^0.8.1"
- to-regex "^3.0.1"
-
-negotiator@0.6.3:
- version "0.6.3"
- resolved "https://registry.yarnpkg.com/negotiator/-/negotiator-0.6.3.tgz#58e323a72fedc0d6f9cd4d31fe49f51479590ccd"
- integrity sha512-+EUsqGPLsM+j/zdChZjsnX51g4XrHFOIXwfnCVPGlQk/k5giakcKsuxCObBRu6DSm9opw/O6slWbJdghQM4bBg==
-
-nice-try@^1.0.4:
- version "1.0.5"
- resolved "https://registry.yarnpkg.com/nice-try/-/nice-try-1.0.5.tgz#a3378a7696ce7d223e88fc9b764bd7ef1089e366"
- integrity sha512-1nh45deeb5olNY7eX82BkPO7SSxR5SSYJiPTrTdFUVYwAl8CKMA5N9PjTYkHiRjisVcxcQ1HXdLhx2qxxJzLNQ==
-
-node-releases@^2.0.6:
- version "2.0.6"
- resolved "https://registry.yarnpkg.com/node-releases/-/node-releases-2.0.6.tgz#8a7088c63a55e493845683ebf3c828d8c51c5503"
- integrity sha512-PiVXnNuFm5+iYkLBNeq5211hvO38y63T0i2KKh2KnUs3RpzJ+JtODFjkD8yjLwnDkTYF1eKXheUwdssR+NRZdg==
-
-normalize-package-data@^2.3.2, normalize-package-data@^2.3.4:
- version "2.5.0"
- resolved "https://registry.yarnpkg.com/normalize-package-data/-/normalize-package-data-2.5.0.tgz#e66db1838b200c1dfc233225d12cb36520e234a8"
- integrity sha512-/5CMN3T0R4XTj4DcGaexo+roZSdSFW/0AOOTROrjxzCG1wrWXEsGbRKevjlIL+ZDE4sZlJr5ED4YW0yqmkK+eA==
- dependencies:
- hosted-git-info "^2.1.4"
- resolve "^1.10.0"
- semver "2 || 3 || 4 || 5"
- validate-npm-package-license "^3.0.1"
-
-normalize-path@^3.0.0, normalize-path@~3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/normalize-path/-/normalize-path-3.0.0.tgz#0dcd69ff23a1c9b11fd0978316644a0388216a65"
- integrity sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==
-
-normalize-range@^0.1.2:
- version "0.1.2"
- resolved "https://registry.yarnpkg.com/normalize-range/-/normalize-range-0.1.2.tgz#2d10c06bdfd312ea9777695a4d28439456b75942"
- integrity sha512-bdok/XvKII3nUpklnV6P2hxtMNrCboOjAcyBuQnWEhO665FwrSNRxU+AqpsyvO6LgGYPspN+lu5CLtw4jPRKNA==
-
-normalize-url@2.0.1:
- version "2.0.1"
- resolved "https://registry.yarnpkg.com/normalize-url/-/normalize-url-2.0.1.tgz#835a9da1551fa26f70e92329069a23aa6574d7e6"
- integrity sha512-D6MUW4K/VzoJ4rJ01JFKxDrtY1v9wrgzCX5f2qj/lzH1m/lW6MhUZFKerVsnyjOhOsYzI9Kqqak+10l4LvLpMw==
- dependencies:
- prepend-http "^2.0.0"
- query-string "^5.0.1"
- sort-keys "^2.0.0"
-
-normalize-url@^3.0.0:
- version "3.3.0"
- resolved "https://registry.yarnpkg.com/normalize-url/-/normalize-url-3.3.0.tgz#b2e1c4dc4f7c6d57743df733a4f5978d18650559"
- integrity sha512-U+JJi7duF1o+u2pynbp2zXDW2/PADgC30f0GsHZtRh+HOcXHnw137TrNlyxxRvWW5fjKd3bcLHPxofWuCjaeZg==
-
-npm-conf@^1.1.0:
- version "1.1.3"
- resolved "https://registry.yarnpkg.com/npm-conf/-/npm-conf-1.1.3.tgz#256cc47bd0e218c259c4e9550bf413bc2192aff9"
- integrity sha512-Yic4bZHJOt9RCFbRP3GgpqhScOY4HH3V2P8yBj6CeYq118Qr+BLXqT2JvpJ00mryLESpgOxf5XlFv4ZjXxLScw==
- dependencies:
- config-chain "^1.1.11"
- pify "^3.0.0"
-
-npm-run-path@^2.0.0:
- version "2.0.2"
- resolved "https://registry.yarnpkg.com/npm-run-path/-/npm-run-path-2.0.2.tgz#35a9232dfa35d7067b4cb2ddf2357b1871536c5f"
- integrity sha512-lJxZYlT4DW/bRUtFh1MQIWqmLwQfAxnqWG4HhEdjMlkrJYnJn0Jrr2u3mgxqaWsdiBc76TYkTG/mhrnYTuzfHw==
- dependencies:
- path-key "^2.0.0"
-
-nth-check@^1.0.2, nth-check@~1.0.1:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/nth-check/-/nth-check-1.0.2.tgz#b2bd295c37e3dd58a3bf0700376663ba4d9cf05c"
- integrity sha512-WeBOdju8SnzPN5vTUJYxYUxLeXpCaVP5i5e0LF8fg7WORF2Wd7wFX/pk0tYZk7s8T+J7VLy0Da6J1+wCT0AtHg==
- dependencies:
- boolbase "~1.0.0"
-
-num2fraction@^1.2.2:
- version "1.2.2"
- resolved "https://registry.yarnpkg.com/num2fraction/-/num2fraction-1.2.2.tgz#6f682b6a027a4e9ddfa4564cd2589d1d4e669ede"
- integrity sha512-Y1wZESM7VUThYY+4W+X4ySH2maqcA+p7UR+w8VWNWVAd6lwuXXWz/w/Cz43J/dI2I+PS6wD5N+bJUF+gjWvIqg==
-
-oauth-sign@~0.9.0:
- version "0.9.0"
- resolved "https://registry.yarnpkg.com/oauth-sign/-/oauth-sign-0.9.0.tgz#47a7b016baa68b5fa0ecf3dee08a85c679ac6455"
- integrity sha512-fexhUFFPTGV8ybAtSIGbV6gOkSv8UtRbDBnAyLQw4QPKkgNlsH2ByPGtMUqdWkos6YCRmAqViwgZrJc/mRDzZQ==
-
-object-assign@^4.0.1, object-assign@^4.1.0, object-assign@^4.1.1:
- version "4.1.1"
- resolved "https://registry.yarnpkg.com/object-assign/-/object-assign-4.1.1.tgz#2109adc7965887cfc05cbbd442cac8bfbb360863"
- integrity sha512-rJgTQnkUnH1sFw8yT6VSU3zD3sWmu6sZhIseY8VX+GRu3P6F7Fu+JNDoXfklElbLJSnc3FUQHVe4cU5hj+BcUg==
-
-object-copy@^0.1.0:
- version "0.1.0"
- resolved "https://registry.yarnpkg.com/object-copy/-/object-copy-0.1.0.tgz#7e7d858b781bd7c991a41ba975ed3812754e998c"
- integrity sha512-79LYn6VAb63zgtmAteVOWo9Vdj71ZVBy3Pbse+VqxDpEP83XuujMrGqHIwAXJ5I/aM0zU7dIyIAhifVTPrNItQ==
- dependencies:
- copy-descriptor "^0.1.0"
- define-property "^0.2.5"
- kind-of "^3.0.3"
-
-object-inspect@^1.12.2, object-inspect@^1.9.0:
- version "1.12.2"
- resolved "https://registry.yarnpkg.com/object-inspect/-/object-inspect-1.12.2.tgz#c0641f26394532f28ab8d796ab954e43c009a8ea"
- integrity sha512-z+cPxW0QGUp0mcqcsgQyLVRDoXFQbXOwBaqyF7VIgI4TWNQsDHrBpUQslRmIfAoYWdYzs6UlKJtB2XJpTaNSpQ==
-
-object-keys@^1.1.1:
- version "1.1.1"
- resolved "https://registry.yarnpkg.com/object-keys/-/object-keys-1.1.1.tgz#1c47f272df277f3b1daf061677d9c82e2322c60e"
- integrity sha512-NuAESUOUMrlIXOfHKzD6bpPu3tYt3xvjNdRIQ+FeT0lNb4K8WR70CaDxhuNguS2XG+GjkyMwOzsN5ZktImfhLA==
-
-object-visit@^1.0.0:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/object-visit/-/object-visit-1.0.1.tgz#f79c4493af0c5377b59fe39d395e41042dd045bb"
- integrity sha512-GBaMwwAVK9qbQN3Scdo0OyvgPW7l3lnaVMj84uTOZlswkX0KpF6fyDBJhtTthf7pymztoN36/KEr1DyhF96zEA==
- dependencies:
- isobject "^3.0.0"
-
-object.assign@^4.1.4:
- version "4.1.4"
- resolved "https://registry.yarnpkg.com/object.assign/-/object.assign-4.1.4.tgz#9673c7c7c351ab8c4d0b516f4343ebf4dfb7799f"
- integrity sha512-1mxKf0e58bvyjSCtKYY4sRe9itRk3PJpquJOjeIkz885CczcI4IvJJDLPS72oowuSh+pBxUFROpX+TU++hxhZQ==
- dependencies:
- call-bind "^1.0.2"
- define-properties "^1.1.4"
- has-symbols "^1.0.3"
- object-keys "^1.1.1"
-
-object.getownpropertydescriptors@^2.1.0:
- version "2.1.5"
- resolved "https://registry.yarnpkg.com/object.getownpropertydescriptors/-/object.getownpropertydescriptors-2.1.5.tgz#db5a9002489b64eef903df81d6623c07e5b4b4d3"
- integrity sha512-yDNzckpM6ntyQiGTik1fKV1DcVDRS+w8bvpWNCBanvH5LfRX9O8WTHqQzG4RZwRAM4I0oU7TV11Lj5v0g20ibw==
- dependencies:
- array.prototype.reduce "^1.0.5"
- call-bind "^1.0.2"
- define-properties "^1.1.4"
- es-abstract "^1.20.4"
-
-object.pick@^1.2.0, object.pick@^1.3.0:
- version "1.3.0"
- resolved "https://registry.yarnpkg.com/object.pick/-/object.pick-1.3.0.tgz#87a10ac4c1694bd2e1cbf53591a66141fb5dd747"
- integrity sha512-tqa/UMy/CCoYmj+H5qc07qvSL9dqcs/WZENZ1JbtWBlATP+iVOe778gE6MSijnyCnORzDuX6hU+LA4SZ09YjFQ==
- dependencies:
- isobject "^3.0.1"
-
-object.values@^1.1.0:
- version "1.1.6"
- resolved "https://registry.yarnpkg.com/object.values/-/object.values-1.1.6.tgz#4abbaa71eba47d63589d402856f908243eea9b1d"
- integrity sha512-FVVTkD1vENCsAcwNs9k6jea2uHC/X0+JcjG8YA60FN5CMaJmG95wT9jek/xX9nornqGRrBkKtzuAu2wuHpKqvw==
- dependencies:
- call-bind "^1.0.2"
- define-properties "^1.1.4"
- es-abstract "^1.20.4"
-
-on-finished@2.4.1:
- version "2.4.1"
- resolved "https://registry.yarnpkg.com/on-finished/-/on-finished-2.4.1.tgz#58c8c44116e54845ad57f14ab10b03533184ac3f"
- integrity sha512-oVlzkg3ENAhCk2zdv7IJwd/QUD4z2RxRwpkcGY8psCVcCYZNq4wYnVWALHM+brtuJjePWiYF/ClmuDr8Ch5+kg==
- dependencies:
- ee-first "1.1.1"
-
-once@^1.3.0, once@^1.3.1, once@^1.4.0:
- version "1.4.0"
- resolved "https://registry.yarnpkg.com/once/-/once-1.4.0.tgz#583b1aa775961d4b113ac17d9c50baef9dd76bd1"
- integrity sha512-lNaJgI+2Q5URQBkccEKHTQOPaXdUxnZZElQTZY0MFUAuaEqe1E+Nyvgdz/aIyNi6Z9MzO5dv1H8n58/GELp3+w==
- dependencies:
- wrappy "1"
-
-onetime@^2.0.0:
- version "2.0.1"
- resolved "https://registry.yarnpkg.com/onetime/-/onetime-2.0.1.tgz#067428230fd67443b2794b22bba528b6867962d4"
- integrity sha512-oyyPpiMaKARvvcgip+JV+7zci5L8D1W9RZIz2l1o08AM3pfspitVWnPt3mzHcBPp12oYMTy0pqrFs/C+m3EwsQ==
- dependencies:
- mimic-fn "^1.0.0"
-
-opn@5.2.0:
- version "5.2.0"
- resolved "https://registry.yarnpkg.com/opn/-/opn-5.2.0.tgz#71fdf934d6827d676cecbea1531f95d354641225"
- integrity sha512-Jd/GpzPyHF4P2/aNOVmS3lfMSWV9J7cOhCG1s08XCEAsPkB7lp6ddiU0J7XzyQRDUh8BqJ7PchfINjR8jyofRQ==
- dependencies:
- is-wsl "^1.1.0"
-
-optipng-bin@^5.0.0:
- version "5.1.0"
- resolved "https://registry.yarnpkg.com/optipng-bin/-/optipng-bin-5.1.0.tgz#a7c7ab600a3ab5a177dae2f94c2d800aa386b5a9"
- integrity sha512-9baoqZTNNmXQjq/PQTWEXbVV3AMO2sI/GaaqZJZ8SExfAzjijeAP7FEeT+TtyumSw7gr0PZtSUYB/Ke7iHQVKA==
- dependencies:
- bin-build "^3.0.0"
- bin-wrapper "^4.0.0"
- logalot "^2.0.0"
-
-original@>=0.0.5:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/original/-/original-1.0.2.tgz#e442a61cffe1c5fd20a65f3261c26663b303f25f"
- integrity sha512-hyBVl6iqqUOJ8FqRe+l/gS8H+kKYjrEndd5Pm1MfBtsEKA038HkkdbAl/72EAXGyonD/PFsvmVG+EvcIpliMBg==
- dependencies:
- url-parse "^1.4.3"
-
-os-filter-obj@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/os-filter-obj/-/os-filter-obj-2.0.0.tgz#1c0b62d5f3a2442749a2d139e6dddee6e81d8d16"
- integrity sha512-uksVLsqG3pVdzzPvmAHpBK0wKxYItuzZr7SziusRPoz67tGV8rL1szZ6IdeUrbqLjGDwApBtN29eEE3IqGHOjg==
- dependencies:
- arch "^2.1.0"
-
-os-tmpdir@~1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/os-tmpdir/-/os-tmpdir-1.0.2.tgz#bbe67406c79aa85c5cfec766fe5734555dfa1274"
- integrity sha512-D2FR03Vir7FIu45XBY20mTb+/ZSWB00sjU9jdQXt83gDrI4Ztz5Fs7/yy74g2N5SVQY4xY1qDr4rNddwYRVX0g==
-
-p-cancelable@^0.3.0:
- version "0.3.0"
- resolved "https://registry.yarnpkg.com/p-cancelable/-/p-cancelable-0.3.0.tgz#b9e123800bcebb7ac13a479be195b507b98d30fa"
- integrity sha512-RVbZPLso8+jFeq1MfNvgXtCRED2raz/dKpacfTNxsx6pLEpEomM7gah6VeHSYV3+vo0OAi4MkArtQcWWXuQoyw==
-
-p-cancelable@^0.4.0:
- version "0.4.1"
- resolved "https://registry.yarnpkg.com/p-cancelable/-/p-cancelable-0.4.1.tgz#35f363d67d52081c8d9585e37bcceb7e0bbcb2a0"
- integrity sha512-HNa1A8LvB1kie7cERyy21VNeHb2CWJJYqyyC2o3klWFfMGlFmWv2Z7sFgZH8ZiaYL95ydToKTFVXgMV/Os0bBQ==
-
-p-event@^1.0.0:
- version "1.3.0"
- resolved "https://registry.yarnpkg.com/p-event/-/p-event-1.3.0.tgz#8e6b4f4f65c72bc5b6fe28b75eda874f96a4a085"
- integrity sha512-hV1zbA7gwqPVFcapfeATaNjQ3J0NuzorHPyG8GPL9g/Y/TplWVBVoCKCXL6Ej2zscrCEv195QNWJXuBH6XZuzA==
- dependencies:
- p-timeout "^1.1.1"
-
-p-event@^2.1.0:
- version "2.3.1"
- resolved "https://registry.yarnpkg.com/p-event/-/p-event-2.3.1.tgz#596279ef169ab2c3e0cae88c1cfbb08079993ef6"
- integrity sha512-NQCqOFhbpVTMX4qMe8PF8lbGtzZ+LCiN7pcNrb/413Na7+TRoe1xkKUzuWa/YEJdGQ0FvKtj35EEbDoVPO2kbA==
- dependencies:
- p-timeout "^2.0.1"
-
-p-finally@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/p-finally/-/p-finally-1.0.0.tgz#3fbcfb15b899a44123b34b6dcc18b724336a2cae"
- integrity sha512-LICb2p9CB7FS+0eR1oqWnHhp0FljGLZCWBE9aix0Uye9W8LTQPwMTYVGWQWIw9RdQiDg4+epXQODwIYJtSJaow==
-
-p-is-promise@^1.1.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/p-is-promise/-/p-is-promise-1.1.0.tgz#9c9456989e9f6588017b0434d56097675c3da05e"
- integrity sha512-zL7VE4JVS2IFSkR2GQKDSPEVxkoH43/p7oEnwpdCndKYJO0HVeRB7fA8TJwuLOTBREtK0ea8eHaxdwcpob5dmg==
-
-p-limit@^2.0.0:
- version "2.3.0"
- resolved "https://registry.yarnpkg.com/p-limit/-/p-limit-2.3.0.tgz#3dd33c647a214fdfffd835933eb086da0dc21db1"
- integrity sha512-//88mFWSJx8lxCzwdAABTJL2MyWB12+eIY7MDL2SqLmAkeKU9qxRvWuSyTjm3FUmpBEMuFfckAIqEaVGUDxb6w==
- dependencies:
- p-try "^2.0.0"
-
-p-locate@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/p-locate/-/p-locate-3.0.0.tgz#322d69a05c0264b25997d9f40cd8a891ab0064a4"
- integrity sha512-x+12w/To+4GFfgJhBEpiDcLozRJGegY+Ei7/z0tSLkMmxGZNybVMSfWj9aJn8Z5Fc7dBUNJOOVgPv2H7IwulSQ==
- dependencies:
- p-limit "^2.0.0"
-
-p-map-series@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/p-map-series/-/p-map-series-1.0.0.tgz#bf98fe575705658a9e1351befb85ae4c1f07bdca"
- integrity sha512-4k9LlvY6Bo/1FcIdV33wqZQES0Py+iKISU9Uc8p8AjWoZPnFKMpVIVD3s0EYn4jzLh1I+WeUZkJ0Yoa4Qfw3Kg==
- dependencies:
- p-reduce "^1.0.0"
-
-p-pipe@^1.1.0:
- version "1.2.0"
- resolved "https://registry.yarnpkg.com/p-pipe/-/p-pipe-1.2.0.tgz#4b1a11399a11520a67790ee5a0c1d5881d6befe9"
- integrity sha512-IA8SqjIGA8l9qOksXJvsvkeQ+VGb0TAzNCzvKvz9wt5wWLqfWbV6fXy43gpR2L4Te8sOq3S+Ql9biAaMKPdbtw==
-
-p-reduce@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/p-reduce/-/p-reduce-1.0.0.tgz#18c2b0dd936a4690a529f8231f58a0fdb6a47dfa"
- integrity sha512-3Tx1T3oM1xO/Y8Gj0sWyE78EIJZ+t+aEmXUdvQgvGmSMri7aPTHoovbXEreWKkL5j21Er60XAWLTzKbAKYOujQ==
-
-p-timeout@^1.1.1:
- version "1.2.1"
- resolved "https://registry.yarnpkg.com/p-timeout/-/p-timeout-1.2.1.tgz#5eb3b353b7fce99f101a1038880bb054ebbea386"
- integrity sha512-gb0ryzr+K2qFqFv6qi3khoeqMZF/+ajxQipEF6NteZVnvz9tzdsfAVj3lYtn1gAXvH5lfLwfxEII799gt/mRIA==
- dependencies:
- p-finally "^1.0.0"
-
-p-timeout@^2.0.1:
- version "2.0.1"
- resolved "https://registry.yarnpkg.com/p-timeout/-/p-timeout-2.0.1.tgz#d8dd1979595d2dc0139e1fe46b8b646cb3cdf038"
- integrity sha512-88em58dDVB/KzPEx1X0N3LwFfYZPyDc4B6eF38M1rk9VTZMbxXXgjugz8mmwpS9Ox4BDZ+t6t3QP5+/gazweIA==
- dependencies:
- p-finally "^1.0.0"
-
-p-try@^2.0.0:
- version "2.2.0"
- resolved "https://registry.yarnpkg.com/p-try/-/p-try-2.2.0.tgz#cb2868540e313d61de58fafbe35ce9004d5540e6"
- integrity sha512-R4nPAVTAU0B9D35/Gk3uJf/7XYbQcyohSKdvAxIRSNghFl4e71hVoGnBNQz9cWaXxO2I10KTC+3jMdvvoKw6dQ==
-
-parse-json@^2.2.0:
- version "2.2.0"
- resolved "https://registry.yarnpkg.com/parse-json/-/parse-json-2.2.0.tgz#f480f40434ef80741f8469099f8dea18f55a4dc9"
- integrity sha512-QR/GGaKCkhwk1ePQNYDRKYZ3mwU9ypsKhB0XyFnLQdomyEqk3e8wpW3V5Jp88zbxK4n5ST1nqo+g9juTpownhQ==
- dependencies:
- error-ex "^1.2.0"
-
-parse-json@^4.0.0:
- version "4.0.0"
- resolved "https://registry.yarnpkg.com/parse-json/-/parse-json-4.0.0.tgz#be35f5425be1f7f6c747184f98a788cb99477ee0"
- integrity sha512-aOIos8bujGN93/8Ox/jPLh7RwVnPEysynVFE+fQZyg6jKELEHwzgKdLRFHUgXJL6kylijVSBC4BvN9OmsB48Rw==
- dependencies:
- error-ex "^1.3.1"
- json-parse-better-errors "^1.0.1"
-
-parse-passwd@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/parse-passwd/-/parse-passwd-1.0.0.tgz#6d5b934a456993b23d37f40a382d6f1666a8e5c6"
- integrity sha512-1Y1A//QUXEZK7YKz+rD9WydcE1+EuPr6ZBgKecAB8tmoW6UFv0NREVJe1p+jRxtThkcbbKkfwIbWJe/IeE6m2Q==
-
-parseurl@~1.3.3:
- version "1.3.3"
- resolved "https://registry.yarnpkg.com/parseurl/-/parseurl-1.3.3.tgz#9da19e7bee8d12dff0513ed5b76957793bc2e8d4"
- integrity sha512-CiyeOxFT/JZyN5m0z9PfXw4SCBJ6Sygz1Dpl0wqjlhDEGGBP1GnsUVEL0p63hoG1fcj3fHynXi9NYO4nWOL+qQ==
-
-pascalcase@^0.1.1:
- version "0.1.1"
- resolved "https://registry.yarnpkg.com/pascalcase/-/pascalcase-0.1.1.tgz#b363e55e8006ca6fe21784d2db22bd15d7917f14"
- integrity sha512-XHXfu/yOQRy9vYOtUDVMN60OEJjW013GoObG1o+xwQTpB9eYJX/BjXMsdW13ZDPruFhYYn0AG22w0xgQMwl3Nw==
-
-path-dirname@^1.0.0:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/path-dirname/-/path-dirname-1.0.2.tgz#cc33d24d525e099a5388c0336c6e32b9160609e0"
- integrity sha512-ALzNPpyNq9AqXMBjeymIjFDAkAFH06mHJH/cSBHAgU0s4vfpBn6b2nf8tiRLvagKD8RbTpq2FKTBg7cl9l3c7Q==
-
-path-exists@^2.0.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/path-exists/-/path-exists-2.1.0.tgz#0feb6c64f0fc518d9a754dd5efb62c7022761f4b"
- integrity sha512-yTltuKuhtNeFJKa1PiRzfLAU5182q1y4Eb4XCJ3PBqyzEDkAZRzBrKKBct682ls9reBVHf9udYLN5Nd+K1B9BQ==
- dependencies:
- pinkie-promise "^2.0.0"
-
-path-exists@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/path-exists/-/path-exists-3.0.0.tgz#ce0ebeaa5f78cb18925ea7d810d7b59b010fd515"
- integrity sha512-bpC7GYwiDYQ4wYLe+FA8lhRjhQCMcQGuSgGGqDkg/QerRWw9CmGRT0iSOVRSZJ29NMLZgIzqaljJ63oaL4NIJQ==
-
-path-is-absolute@^1.0.0:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/path-is-absolute/-/path-is-absolute-1.0.1.tgz#174b9268735534ffbc7ace6bf53a5a9e1b5c5f5f"
- integrity sha512-AVbw3UJ2e9bq64vSaS9Am0fje1Pa8pbGqTTsmXfaIiMpnr5DlDhfJOuLj9Sf95ZPVDAUerDfEk88MPmPe7UCQg==
-
-path-key@^2.0.0, path-key@^2.0.1:
- version "2.0.1"
- resolved "https://registry.yarnpkg.com/path-key/-/path-key-2.0.1.tgz#411cadb574c5a140d3a4b1910d40d80cc9f40b40"
- integrity sha512-fEHGKCSmUSDPv4uoj8AlD+joPlq3peND+HRYyxFz4KPw4z926S/b8rIuFs2FYJg3BwsxJf6A9/3eIdLaYC+9Dw==
-
-path-parse@^1.0.7:
- version "1.0.7"
- resolved "https://registry.yarnpkg.com/path-parse/-/path-parse-1.0.7.tgz#fbc114b60ca42b30d9daf5858e4bd68bbedb6735"
- integrity sha512-LDJzPVEEEPR+y48z93A0Ed0yXb8pAByGWo/k5YYdYgpY2/2EsOsksJrq7lOHxryrVOn1ejG6oAp8ahvOIQD8sw==
-
-path-to-regexp@0.1.7:
- version "0.1.7"
- resolved "https://registry.yarnpkg.com/path-to-regexp/-/path-to-regexp-0.1.7.tgz#df604178005f522f15eb4490e7247a1bfaa67f8c"
- integrity sha512-5DFkuoqlv1uYQKxy8omFBeJPQcdoE07Kv2sferDCrAq1ohOU+MSDswDIbnx3YAM60qIOnYa53wBhXW0EbMonrQ==
-
-path-type@^1.0.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/path-type/-/path-type-1.1.0.tgz#59c44f7ee491da704da415da5a4070ba4f8fe441"
- integrity sha512-S4eENJz1pkiQn9Znv33Q+deTOKmbl+jj1Fl+qiP/vYezj+S8x+J3Uo0ISrx/QoEvIlOaDWJhPaRd1flJ9HXZqg==
- dependencies:
- graceful-fs "^4.1.2"
- pify "^2.0.0"
- pinkie-promise "^2.0.0"
-
-path-type@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/path-type/-/path-type-3.0.0.tgz#cef31dc8e0a1a3bb0d105c0cd97cf3bf47f4e36f"
- integrity sha512-T2ZUsdZFHgA3u4e5PfPbjd7HDDpxPnQb5jN0SrDsjNSuVXHJqtwTnWqG0B1jZrgmJ/7lj1EmVIByWt1gxGkWvg==
- dependencies:
- pify "^3.0.0"
-
-pend@~1.2.0:
- version "1.2.0"
- resolved "https://registry.yarnpkg.com/pend/-/pend-1.2.0.tgz#7a57eb550a6783f9115331fcf4663d5c8e007a50"
- integrity sha512-F3asv42UuXchdzt+xXqfW1OGlVBe+mxa2mqI0pg5yAHZPvFmY3Y6drSf/GQ1A86WgWEN9Kzh/WrgKa6iGcHXLg==
-
-performance-now@^2.1.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/performance-now/-/performance-now-2.1.0.tgz#6309f4e0e5fa913ec1c69307ae364b4b377c9e7b"
- integrity sha512-7EAHlyLHI56VEIdK57uwHdHKIaAGbnXPiw0yWbarQZOKaKpvUIgW0jWRVLiatnM+XXlSwsanIBH/hzGMJulMow==
-
-picocolors@^0.2.1:
- version "0.2.1"
- resolved "https://registry.yarnpkg.com/picocolors/-/picocolors-0.2.1.tgz#570670f793646851d1ba135996962abad587859f"
- integrity sha512-cMlDqaLEqfSaW8Z7N5Jw+lyIW869EzT73/F5lhtY9cLGoVxSXznfgfXMO0Z5K0o0Q2TkTXq+0KFsdnSe3jDViA==
-
-picocolors@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/picocolors/-/picocolors-1.0.0.tgz#cb5bdc74ff3f51892236eaf79d68bc44564ab81c"
- integrity sha512-1fygroTLlHu66zi26VoTDv8yRgm0Fccecssto+MhsZ0D/DGW2sm8E8AjW7NU5VVTRt5GxbeZ5qBuJr+HyLYkjQ==
-
-picomatch@^2.0.4, picomatch@^2.2.1:
- version "2.3.1"
- resolved "https://registry.yarnpkg.com/picomatch/-/picomatch-2.3.1.tgz#3ba3833733646d9d3e4995946c1365a67fb07a42"
- integrity sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==
-
-pify@^2.0.0, pify@^2.2.0, pify@^2.3.0:
- version "2.3.0"
- resolved "https://registry.yarnpkg.com/pify/-/pify-2.3.0.tgz#ed141a6ac043a849ea588498e7dca8b15330e90c"
- integrity sha512-udgsAY+fTnvv7kI7aaxbqwWNb0AHiB0qBO89PZKPkoTmGOgdbrHDKD+0B2X4uTfJ/FT1R09r9gTsjUjNJotuog==
-
-pify@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/pify/-/pify-3.0.0.tgz#e5a4acd2c101fdf3d9a4d07f0dbc4db49dd28176"
- integrity sha512-C3FsVNH1udSEX48gGX1xfvwTWfsYWj5U+8/uK15BGzIGrKoUpghX8hWZwa/OFnakBiiVNmBvemTJR5mcy7iPcg==
-
-pify@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/pify/-/pify-4.0.1.tgz#4b2cd25c50d598735c50292224fd8c6df41e3231"
- integrity sha512-uB80kBFb/tfd68bVleG9T5GGsGPjJrLAUpR5PZIrhBnIaRTQRjqdJSsIKkOP6OAIFbj7GOrcudc5pNjZ+geV2g==
-
-pinkie-promise@^2.0.0:
- version "2.0.1"
- resolved "https://registry.yarnpkg.com/pinkie-promise/-/pinkie-promise-2.0.1.tgz#2135d6dfa7a358c069ac9b178776288228450ffa"
- integrity sha512-0Gni6D4UcLTbv9c57DfxDGdr41XfgUjqWZu492f0cIGr16zDU06BWP/RAEvOuo7CQ0CNjHaLlM59YJJFm3NWlw==
- dependencies:
- pinkie "^2.0.0"
-
-pinkie@^2.0.0:
- version "2.0.4"
- resolved "https://registry.yarnpkg.com/pinkie/-/pinkie-2.0.4.tgz#72556b80cfa0d48a974e80e77248e80ed4f7f870"
- integrity sha512-MnUuEycAemtSaeFSjXKW/aroV7akBbY+Sv+RkyqFjgAe73F+MR0TBWKBRDkmfWq/HiFmdavfZ1G7h4SPZXaCSg==
-
-pirates@^4.0.5:
- version "4.0.5"
- resolved "https://registry.yarnpkg.com/pirates/-/pirates-4.0.5.tgz#feec352ea5c3268fb23a37c702ab1699f35a5f3b"
- integrity sha512-8V9+HQPupnaXMA23c5hvl69zXvTwTzyAYasnkb0Tts4XvO4CliqONMOnvlq26rkhLC3nWDFBJf73LU1e1VZLaQ==
-
-pkg-dir@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/pkg-dir/-/pkg-dir-3.0.0.tgz#2749020f239ed990881b1f71210d51eb6523bea3"
- integrity sha512-/E57AYkoeQ25qkxMj5PBOVgF8Kiu/h7cYS30Z5+R7WaiCCBfLq58ZI/dSeaEKb9WVJV5n/03QwrN3IeWIFllvw==
- dependencies:
- find-up "^3.0.0"
-
-portfinder@^1.0.17:
- version "1.0.32"
- resolved "https://registry.yarnpkg.com/portfinder/-/portfinder-1.0.32.tgz#2fe1b9e58389712429dc2bea5beb2146146c7f81"
- integrity sha512-on2ZJVVDXRADWE6jnQaX0ioEylzgBpQk8r55NE4wjXW1ZxO+BgDlY6DXwj20i0V8eB4SenDQ00WEaxfiIQPcxg==
- dependencies:
- async "^2.6.4"
- debug "^3.2.7"
- mkdirp "^0.5.6"
-
-posix-character-classes@^0.1.0:
- version "0.1.1"
- resolved "https://registry.yarnpkg.com/posix-character-classes/-/posix-character-classes-0.1.1.tgz#01eac0fe3b5af71a2a6c02feabb8c1fef7e00eab"
- integrity sha512-xTgYBc3fuo7Yt7JbiuFxSYGToMoz8fLoE6TC9Wx1P/u+LfeThMOAqmuyECnlBaaJb+u1m9hHiXUEtwW4OzfUJg==
-
-postcss-calc@^7.0.1:
- version "7.0.5"
- resolved "https://registry.yarnpkg.com/postcss-calc/-/postcss-calc-7.0.5.tgz#f8a6e99f12e619c2ebc23cf6c486fdc15860933e"
- integrity sha512-1tKHutbGtLtEZF6PT4JSihCHfIVldU72mZ8SdZHIYriIZ9fh9k9aWSppaT8rHsyI3dX+KSR+W+Ix9BMY3AODrg==
- dependencies:
- postcss "^7.0.27"
- postcss-selector-parser "^6.0.2"
- postcss-value-parser "^4.0.2"
-
-postcss-colormin@^4.0.3:
- version "4.0.3"
- resolved "https://registry.yarnpkg.com/postcss-colormin/-/postcss-colormin-4.0.3.tgz#ae060bce93ed794ac71264f08132d550956bd381"
- integrity sha512-WyQFAdDZpExQh32j0U0feWisZ0dmOtPl44qYmJKkq9xFWY3p+4qnRzCHeNrkeRhwPHz9bQ3mo0/yVkaply0MNw==
- dependencies:
- browserslist "^4.0.0"
- color "^3.0.0"
- has "^1.0.0"
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
-
-postcss-convert-values@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/postcss-convert-values/-/postcss-convert-values-4.0.1.tgz#ca3813ed4da0f812f9d43703584e449ebe189a7f"
- integrity sha512-Kisdo1y77KUC0Jmn0OXU/COOJbzM8cImvw1ZFsBgBgMgb1iL23Zs/LXRe3r+EZqM3vGYKdQ2YJVQ5VkJI+zEJQ==
- dependencies:
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
-
-postcss-discard-comments@^4.0.2:
- version "4.0.2"
- resolved "https://registry.yarnpkg.com/postcss-discard-comments/-/postcss-discard-comments-4.0.2.tgz#1fbabd2c246bff6aaad7997b2b0918f4d7af4033"
- integrity sha512-RJutN259iuRf3IW7GZyLM5Sw4GLTOH8FmsXBnv8Ab/Tc2k4SR4qbV4DNbyyY4+Sjo362SyDmW2DQ7lBSChrpkg==
- dependencies:
- postcss "^7.0.0"
-
-postcss-discard-duplicates@^4.0.2:
- version "4.0.2"
- resolved "https://registry.yarnpkg.com/postcss-discard-duplicates/-/postcss-discard-duplicates-4.0.2.tgz#3fe133cd3c82282e550fc9b239176a9207b784eb"
- integrity sha512-ZNQfR1gPNAiXZhgENFfEglF93pciw0WxMkJeVmw8eF+JZBbMD7jp6C67GqJAXVZP2BWbOztKfbsdmMp/k8c6oQ==
- dependencies:
- postcss "^7.0.0"
-
-postcss-discard-empty@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/postcss-discard-empty/-/postcss-discard-empty-4.0.1.tgz#c8c951e9f73ed9428019458444a02ad90bb9f765"
- integrity sha512-B9miTzbznhDjTfjvipfHoqbWKwd0Mj+/fL5s1QOz06wufguil+Xheo4XpOnc4NqKYBCNqqEzgPv2aPBIJLox0w==
- dependencies:
- postcss "^7.0.0"
-
-postcss-discard-overridden@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/postcss-discard-overridden/-/postcss-discard-overridden-4.0.1.tgz#652aef8a96726f029f5e3e00146ee7a4e755ff57"
- integrity sha512-IYY2bEDD7g1XM1IDEsUT4//iEYCxAmP5oDSFMVU/JVvT7gh+l4fmjciLqGgwjdWpQIdb0Che2VX00QObS5+cTg==
- dependencies:
- postcss "^7.0.0"
-
-postcss-merge-longhand@^4.0.11:
- version "4.0.11"
- resolved "https://registry.yarnpkg.com/postcss-merge-longhand/-/postcss-merge-longhand-4.0.11.tgz#62f49a13e4a0ee04e7b98f42bb16062ca2549e24"
- integrity sha512-alx/zmoeXvJjp7L4mxEMjh8lxVlDFX1gqWHzaaQewwMZiVhLo42TEClKaeHbRf6J7j82ZOdTJ808RtN0ZOZwvw==
- dependencies:
- css-color-names "0.0.4"
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
- stylehacks "^4.0.0"
-
-postcss-merge-rules@^4.0.3:
- version "4.0.3"
- resolved "https://registry.yarnpkg.com/postcss-merge-rules/-/postcss-merge-rules-4.0.3.tgz#362bea4ff5a1f98e4075a713c6cb25aefef9a650"
- integrity sha512-U7e3r1SbvYzO0Jr3UT/zKBVgYYyhAz0aitvGIYOYK5CPmkNih+WDSsS5tvPrJ8YMQYlEMvsZIiqmn7HdFUaeEQ==
- dependencies:
- browserslist "^4.0.0"
- caniuse-api "^3.0.0"
- cssnano-util-same-parent "^4.0.0"
- postcss "^7.0.0"
- postcss-selector-parser "^3.0.0"
- vendors "^1.0.0"
-
-postcss-minify-font-values@^4.0.2:
- version "4.0.2"
- resolved "https://registry.yarnpkg.com/postcss-minify-font-values/-/postcss-minify-font-values-4.0.2.tgz#cd4c344cce474343fac5d82206ab2cbcb8afd5a6"
- integrity sha512-j85oO6OnRU9zPf04+PZv1LYIYOprWm6IA6zkXkrJXyRveDEuQggG6tvoy8ir8ZwjLxLuGfNkCZEQG7zan+Hbtg==
- dependencies:
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
-
-postcss-minify-gradients@^4.0.2:
- version "4.0.2"
- resolved "https://registry.yarnpkg.com/postcss-minify-gradients/-/postcss-minify-gradients-4.0.2.tgz#93b29c2ff5099c535eecda56c4aa6e665a663471"
- integrity sha512-qKPfwlONdcf/AndP1U8SJ/uzIJtowHlMaSioKzebAXSG4iJthlWC9iSWznQcX4f66gIWX44RSA841HTHj3wK+Q==
- dependencies:
- cssnano-util-get-arguments "^4.0.0"
- is-color-stop "^1.0.0"
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
-
-postcss-minify-params@^4.0.2:
- version "4.0.2"
- resolved "https://registry.yarnpkg.com/postcss-minify-params/-/postcss-minify-params-4.0.2.tgz#6b9cef030c11e35261f95f618c90036d680db874"
- integrity sha512-G7eWyzEx0xL4/wiBBJxJOz48zAKV2WG3iZOqVhPet/9geefm/Px5uo1fzlHu+DOjT+m0Mmiz3jkQzVHe6wxAWg==
- dependencies:
- alphanum-sort "^1.0.0"
- browserslist "^4.0.0"
- cssnano-util-get-arguments "^4.0.0"
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
- uniqs "^2.0.0"
-
-postcss-minify-selectors@^4.0.2:
- version "4.0.2"
- resolved "https://registry.yarnpkg.com/postcss-minify-selectors/-/postcss-minify-selectors-4.0.2.tgz#e2e5eb40bfee500d0cd9243500f5f8ea4262fbd8"
- integrity sha512-D5S1iViljXBj9kflQo4YutWnJmwm8VvIsU1GeXJGiG9j8CIg9zs4voPMdQDUmIxetUOh60VilsNzCiAFTOqu3g==
- dependencies:
- alphanum-sort "^1.0.0"
- has "^1.0.0"
- postcss "^7.0.0"
- postcss-selector-parser "^3.0.0"
-
-postcss-normalize-charset@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/postcss-normalize-charset/-/postcss-normalize-charset-4.0.1.tgz#8b35add3aee83a136b0471e0d59be58a50285dd4"
- integrity sha512-gMXCrrlWh6G27U0hF3vNvR3w8I1s2wOBILvA87iNXaPvSNo5uZAMYsZG7XjCUf1eVxuPfyL4TJ7++SGZLc9A3g==
- dependencies:
- postcss "^7.0.0"
-
-postcss-normalize-display-values@^4.0.2:
- version "4.0.2"
- resolved "https://registry.yarnpkg.com/postcss-normalize-display-values/-/postcss-normalize-display-values-4.0.2.tgz#0dbe04a4ce9063d4667ed2be476bb830c825935a"
- integrity sha512-3F2jcsaMW7+VtRMAqf/3m4cPFhPD3EFRgNs18u+k3lTJJlVe7d0YPO+bnwqo2xg8YiRpDXJI2u8A0wqJxMsQuQ==
- dependencies:
- cssnano-util-get-match "^4.0.0"
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
-
-postcss-normalize-positions@^4.0.2:
- version "4.0.2"
- resolved "https://registry.yarnpkg.com/postcss-normalize-positions/-/postcss-normalize-positions-4.0.2.tgz#05f757f84f260437378368a91f8932d4b102917f"
- integrity sha512-Dlf3/9AxpxE+NF1fJxYDeggi5WwV35MXGFnnoccP/9qDtFrTArZ0D0R+iKcg5WsUd8nUYMIl8yXDCtcrT8JrdA==
- dependencies:
- cssnano-util-get-arguments "^4.0.0"
- has "^1.0.0"
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
-
-postcss-normalize-repeat-style@^4.0.2:
- version "4.0.2"
- resolved "https://registry.yarnpkg.com/postcss-normalize-repeat-style/-/postcss-normalize-repeat-style-4.0.2.tgz#c4ebbc289f3991a028d44751cbdd11918b17910c"
- integrity sha512-qvigdYYMpSuoFs3Is/f5nHdRLJN/ITA7huIoCyqqENJe9PvPmLhNLMu7QTjPdtnVf6OcYYO5SHonx4+fbJE1+Q==
- dependencies:
- cssnano-util-get-arguments "^4.0.0"
- cssnano-util-get-match "^4.0.0"
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
-
-postcss-normalize-string@^4.0.2:
- version "4.0.2"
- resolved "https://registry.yarnpkg.com/postcss-normalize-string/-/postcss-normalize-string-4.0.2.tgz#cd44c40ab07a0c7a36dc5e99aace1eca4ec2690c"
- integrity sha512-RrERod97Dnwqq49WNz8qo66ps0swYZDSb6rM57kN2J+aoyEAJfZ6bMx0sx/F9TIEX0xthPGCmeyiam/jXif0eA==
- dependencies:
- has "^1.0.0"
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
-
-postcss-normalize-timing-functions@^4.0.2:
- version "4.0.2"
- resolved "https://registry.yarnpkg.com/postcss-normalize-timing-functions/-/postcss-normalize-timing-functions-4.0.2.tgz#8e009ca2a3949cdaf8ad23e6b6ab99cb5e7d28d9"
- integrity sha512-acwJY95edP762e++00Ehq9L4sZCEcOPyaHwoaFOhIwWCDfik6YvqsYNxckee65JHLKzuNSSmAdxwD2Cud1Z54A==
- dependencies:
- cssnano-util-get-match "^4.0.0"
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
-
-postcss-normalize-unicode@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/postcss-normalize-unicode/-/postcss-normalize-unicode-4.0.1.tgz#841bd48fdcf3019ad4baa7493a3d363b52ae1cfb"
- integrity sha512-od18Uq2wCYn+vZ/qCOeutvHjB5jm57ToxRaMeNuf0nWVHaP9Hua56QyMF6fs/4FSUnVIw0CBPsU0K4LnBPwYwg==
- dependencies:
- browserslist "^4.0.0"
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
-
-postcss-normalize-url@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/postcss-normalize-url/-/postcss-normalize-url-4.0.1.tgz#10e437f86bc7c7e58f7b9652ed878daaa95faae1"
- integrity sha512-p5oVaF4+IHwu7VpMan/SSpmpYxcJMtkGppYf0VbdH5B6hN8YNmVyJLuY9FmLQTzY3fag5ESUUHDqM+heid0UVA==
- dependencies:
- is-absolute-url "^2.0.0"
- normalize-url "^3.0.0"
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
-
-postcss-normalize-whitespace@^4.0.2:
- version "4.0.2"
- resolved "https://registry.yarnpkg.com/postcss-normalize-whitespace/-/postcss-normalize-whitespace-4.0.2.tgz#bf1d4070fe4fcea87d1348e825d8cc0c5faa7d82"
- integrity sha512-tO8QIgrsI3p95r8fyqKV+ufKlSHh9hMJqACqbv2XknufqEDhDvbguXGBBqxw9nsQoXWf0qOqppziKJKHMD4GtA==
- dependencies:
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
-
-postcss-ordered-values@^4.1.2:
- version "4.1.2"
- resolved "https://registry.yarnpkg.com/postcss-ordered-values/-/postcss-ordered-values-4.1.2.tgz#0cf75c820ec7d5c4d280189559e0b571ebac0eee"
- integrity sha512-2fCObh5UanxvSxeXrtLtlwVThBvHn6MQcu4ksNT2tsaV2Fg76R2CV98W7wNSlX+5/pFwEyaDwKLLoEV7uRybAw==
- dependencies:
- cssnano-util-get-arguments "^4.0.0"
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
-
-postcss-reduce-initial@^4.0.3:
- version "4.0.3"
- resolved "https://registry.yarnpkg.com/postcss-reduce-initial/-/postcss-reduce-initial-4.0.3.tgz#7fd42ebea5e9c814609639e2c2e84ae270ba48df"
- integrity sha512-gKWmR5aUulSjbzOfD9AlJiHCGH6AEVLaM0AV+aSioxUDd16qXP1PCh8d1/BGVvpdWn8k/HiK7n6TjeoXN1F7DA==
- dependencies:
- browserslist "^4.0.0"
- caniuse-api "^3.0.0"
- has "^1.0.0"
- postcss "^7.0.0"
-
-postcss-reduce-transforms@^4.0.2:
- version "4.0.2"
- resolved "https://registry.yarnpkg.com/postcss-reduce-transforms/-/postcss-reduce-transforms-4.0.2.tgz#17efa405eacc6e07be3414a5ca2d1074681d4e29"
- integrity sha512-EEVig1Q2QJ4ELpJXMZR8Vt5DQx8/mo+dGWSR7vWXqcob2gQLyQGsionYcGKATXvQzMPn6DSN1vTN7yFximdIAg==
- dependencies:
- cssnano-util-get-match "^4.0.0"
- has "^1.0.0"
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
-
-postcss-selector-parser@^3.0.0:
- version "3.1.2"
- resolved "https://registry.yarnpkg.com/postcss-selector-parser/-/postcss-selector-parser-3.1.2.tgz#b310f5c4c0fdaf76f94902bbaa30db6aa84f5270"
- integrity sha512-h7fJ/5uWuRVyOtkO45pnt1Ih40CEleeyCHzipqAZO2e5H20g25Y48uYnFUiShvY4rZWNJ/Bib/KVPmanaCtOhA==
- dependencies:
- dot-prop "^5.2.0"
- indexes-of "^1.0.1"
- uniq "^1.0.1"
-
-postcss-selector-parser@^6.0.2:
- version "6.0.10"
- resolved "https://registry.yarnpkg.com/postcss-selector-parser/-/postcss-selector-parser-6.0.10.tgz#79b61e2c0d1bfc2602d549e11d0876256f8df88d"
- integrity sha512-IQ7TZdoaqbT+LCpShg46jnZVlhWD2w6iQYAcYXfHARZ7X1t/UGhhceQDs5X0cGqKvYlHNOuv7Oa1xmb0oQuA3w==
- dependencies:
- cssesc "^3.0.0"
- util-deprecate "^1.0.2"
-
-postcss-svgo@^4.0.3:
- version "4.0.3"
- resolved "https://registry.yarnpkg.com/postcss-svgo/-/postcss-svgo-4.0.3.tgz#343a2cdbac9505d416243d496f724f38894c941e"
- integrity sha512-NoRbrcMWTtUghzuKSoIm6XV+sJdvZ7GZSc3wdBN0W19FTtp2ko8NqLsgoh/m9CzNhU3KLPvQmjIwtaNFkaFTvw==
- dependencies:
- postcss "^7.0.0"
- postcss-value-parser "^3.0.0"
- svgo "^1.0.0"
-
-postcss-unique-selectors@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/postcss-unique-selectors/-/postcss-unique-selectors-4.0.1.tgz#9446911f3289bfd64c6d680f073c03b1f9ee4bac"
- integrity sha512-+JanVaryLo9QwZjKrmJgkI4Fn8SBgRO6WXQBJi7KiAVPlmxikB5Jzc4EvXMT2H0/m0RjrVVm9rGNhZddm/8Spg==
- dependencies:
- alphanum-sort "^1.0.0"
- postcss "^7.0.0"
- uniqs "^2.0.0"
-
-postcss-value-parser@^3.0.0:
- version "3.3.1"
- resolved "https://registry.yarnpkg.com/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz#9ff822547e2893213cf1c30efa51ac5fd1ba8281"
- integrity sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==
-
-postcss-value-parser@^4.0.2, postcss-value-parser@^4.1.0:
- version "4.2.0"
- resolved "https://registry.yarnpkg.com/postcss-value-parser/-/postcss-value-parser-4.2.0.tgz#723c09920836ba6d3e5af019f92bc0971c02e514"
- integrity sha512-1NNCs6uurfkVbeXG4S8JFT9t19m45ICnif8zWLd5oPSZ50QnwMfK+H3jv408d4jw/7Bttv5axS5IiHoLaVNHeQ==
-
-postcss@^7.0.0, postcss@^7.0.1, postcss@^7.0.27, postcss@^7.0.32:
- version "7.0.39"
- resolved "https://registry.yarnpkg.com/postcss/-/postcss-7.0.39.tgz#9624375d965630e2e1f2c02a935c82a59cb48309"
- integrity sha512-yioayjNbHn6z1/Bywyb2Y4s3yvDAeXGOyxqD+LnVOinq6Mdmd++SW2wUNVzavyyHxd6+DxzWGIuosg6P1Rj8uA==
- dependencies:
- picocolors "^0.2.1"
- source-map "^0.6.1"
-
-prepend-http@^1.0.1:
- version "1.0.4"
- resolved "https://registry.yarnpkg.com/prepend-http/-/prepend-http-1.0.4.tgz#d4f4562b0ce3696e41ac52d0e002e57a635dc6dc"
- integrity sha512-PhmXi5XmoyKw1Un4E+opM2KcsJInDvKyuOumcjjw3waw86ZNjHwVUOOWLc4bCzLdcKNaWBH9e99sbWzDQsVaYg==
-
-prepend-http@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/prepend-http/-/prepend-http-2.0.0.tgz#e92434bfa5ea8c19f41cdfd401d741a3c819d897"
- integrity sha512-ravE6m9Atw9Z/jjttRUZ+clIXogdghyZAuWJ3qEzjT+jI/dL1ifAqhZeC5VHzQp1MSt1+jxKkFNemj/iO7tVUA==
-
-pretty-bytes@^5.6.0:
- version "5.6.0"
- resolved "https://registry.yarnpkg.com/pretty-bytes/-/pretty-bytes-5.6.0.tgz#356256f643804773c82f64723fe78c92c62beaeb"
- integrity sha512-FFw039TmrBqFK8ma/7OL3sDz/VytdtJr044/QUJtH0wK9lb9jLq9tJyIxUwtQJHwar2BqtiA4iCWSwo9JLkzFg==
-
-prismjs@^1.15.0:
- version "1.29.0"
- resolved "https://registry.yarnpkg.com/prismjs/-/prismjs-1.29.0.tgz#f113555a8fa9b57c35e637bba27509dcf802dd12"
- integrity sha512-Kx/1w86q/epKcmte75LNrEoT+lX8pBpavuAbvJWRXar7Hz8jrtF+e3vY751p0R8H9HdArwaCTNDDzHg/ScJK1Q==
-
-process-nextick-args@~2.0.0:
- version "2.0.1"
- resolved "https://registry.yarnpkg.com/process-nextick-args/-/process-nextick-args-2.0.1.tgz#7820d9b16120cc55ca9ae7792680ae7dba6d7fe2"
- integrity sha512-3ouUOpQhtgrbOa17J7+uxOTpITYWaGP7/AhoR3+A+/1e9skrzelGi/dXzEYyvbxubEF6Wn2ypscTKiKJFFn1ag==
-
-prop-types@^15.6.2:
- version "15.8.1"
- resolved "https://registry.yarnpkg.com/prop-types/-/prop-types-15.8.1.tgz#67d87bf1a694f48435cf332c24af10214a3140b5"
- integrity sha512-oj87CgZICdulUohogVAR7AjlC0327U4el4L6eAvOqCeudMDVU0NThNaV+b9Df4dXgSP1gXMTnPdhfe/2qDH5cg==
- dependencies:
- loose-envify "^1.4.0"
- object-assign "^4.1.1"
- react-is "^16.13.1"
-
-proto-list@~1.2.1:
- version "1.2.4"
- resolved "https://registry.yarnpkg.com/proto-list/-/proto-list-1.2.4.tgz#212d5bfe1318306a420f6402b8e26ff39647a849"
- integrity sha512-vtK/94akxsTMhe0/cbfpR+syPuszcuwhqVjJq26CuNDgFGj682oRBXOP5MJpv2r7JtE8MsiepGIqvvOTBwn2vA==
-
-proxy-addr@~2.0.7:
- version "2.0.7"
- resolved "https://registry.yarnpkg.com/proxy-addr/-/proxy-addr-2.0.7.tgz#f19fe69ceab311eeb94b42e70e8c2070f9ba1025"
- integrity sha512-llQsMLSUDUPT44jdrU/O37qlnifitDP+ZwrmmZcoSKyLKvtZxpyV0n2/bD/N4tBAAZ/gJEdZU7KMraoK1+XYAg==
- dependencies:
- forwarded "0.2.0"
- ipaddr.js "1.9.1"
-
-pseudomap@^1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/pseudomap/-/pseudomap-1.0.2.tgz#f052a28da70e618917ef0a8ac34c1ae5a68286b3"
- integrity sha512-b/YwNhb8lk1Zz2+bXXpS/LK9OisiZZ1SNsSLxN1x2OXVEhW2Ckr/7mWE5vrC1ZTiJlD9g19jWszTmJsB+oEpFQ==
-
-psl@^1.1.28:
- version "1.9.0"
- resolved "https://registry.yarnpkg.com/psl/-/psl-1.9.0.tgz#d0df2a137f00794565fcaf3b2c00cd09f8d5a5a7"
- integrity sha512-E/ZsdU4HLs/68gYzgGTkMicWTLPdAftJLfJFlLUAAKZGkStNU72sZjT66SnMDVOfOWY/YAoiD7Jxa9iHvngcag==
-
-pump@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/pump/-/pump-3.0.0.tgz#b4a2116815bde2f4e1ea602354e8c75565107a64"
- integrity sha512-LwZy+p3SFs1Pytd/jYct4wpv49HiYCqd9Rlc5ZVdk0V+8Yzv6jR5Blk3TRmPL1ft69TxP0IMZGJ+WPFU2BFhww==
- dependencies:
- end-of-stream "^1.1.0"
- once "^1.3.1"
-
-punycode@^2.1.0, punycode@^2.1.1:
- version "2.1.1"
- resolved "https://registry.yarnpkg.com/punycode/-/punycode-2.1.1.tgz#b58b010ac40c22c5657616c8d2c2c02c7bf479ec"
- integrity sha512-XRsRjdf+j5ml+y/6GKHPZbrF/8p2Yga0JPtdqTIY2Xe5ohJPD9saDJJLPvp9+NSBprVvevdXZybnj2cv8OEd0A==
-
-q@0.9.7:
- version "0.9.7"
- resolved "https://registry.yarnpkg.com/q/-/q-0.9.7.tgz#4de2e6cb3b29088c9e4cbc03bf9d42fb96ce2f75"
- integrity sha512-ijt0LhxWClXBtc1RCt8H0WhlZLAdVX26nWbpsJy+Hblmp81d2F/pFsvlrJhJDDruFHM+ECtxP0H0HzGSrARkwg==
-
-q@^1.1.2:
- version "1.5.1"
- resolved "https://registry.yarnpkg.com/q/-/q-1.5.1.tgz#7e32f75b41381291d04611f1bf14109ac00651d7"
- integrity sha512-kV/CThkXo6xyFEZUugw/+pIOywXcDbFYgSct5cT3gqlbkBE1SJdwy6UQoZvodiWF/ckQLZyDE/Bu1M6gVu5lVw==
-
-qs@6.11.0, qs@^6.4.0:
- version "6.11.0"
- resolved "https://registry.yarnpkg.com/qs/-/qs-6.11.0.tgz#fd0d963446f7a65e1367e01abd85429453f0c37a"
- integrity sha512-MvjoMCJwEarSbUYk5O+nmoSzSutSsTwF85zcHPQ9OrlFoZOYIjaqBAJIqIXjptyD5vThxGq52Xu/MaJzRkIk4Q==
- dependencies:
- side-channel "^1.0.4"
-
-qs@~6.5.2:
- version "6.5.3"
- resolved "https://registry.yarnpkg.com/qs/-/qs-6.5.3.tgz#3aeeffc91967ef6e35c0e488ef46fb296ab76aad"
- integrity sha512-qxXIEh4pCGfHICj1mAJQ2/2XVZkjCDTcEgfoSQxc/fYivUZxTkk7L3bDBJSoNrEzXI17oUO5Dp07ktqE5KzczA==
-
-query-string@^5.0.1:
- version "5.1.1"
- resolved "https://registry.yarnpkg.com/query-string/-/query-string-5.1.1.tgz#a78c012b71c17e05f2e3fa2319dd330682efb3cb"
- integrity sha512-gjWOsm2SoGlgLEdAGt7a6slVOk9mGiXmPFMqrEhLQ68rhQuBnpfs3+EmlvqKyxnCo9/PPlF+9MtY02S1aFg+Jw==
- dependencies:
- decode-uri-component "^0.2.0"
- object-assign "^4.1.0"
- strict-uri-encode "^1.0.0"
-
-querystringify@^2.1.1:
- version "2.2.0"
- resolved "https://registry.yarnpkg.com/querystringify/-/querystringify-2.2.0.tgz#3345941b4153cb9d082d8eee4cda2016a9aef7f6"
- integrity sha512-FIqgj2EUvTa7R50u0rGsyTftzjYmv/a3hO345bZNrqabNqjtgiDMgmo4mkUjd+nzU5oF3dClKqFIPUKybUyqoQ==
-
-randomatic@^3.0.0:
- version "3.1.1"
- resolved "https://registry.yarnpkg.com/randomatic/-/randomatic-3.1.1.tgz#b776efc59375984e36c537b2f51a1f0aff0da1ed"
- integrity sha512-TuDE5KxZ0J461RVjrJZCJc+J+zCkTb1MbH9AQUq68sMhOMcy9jLcb3BrZKgp9q9Ncltdg4QVqWrH02W2EFFVYw==
- dependencies:
- is-number "^4.0.0"
- kind-of "^6.0.0"
- math-random "^1.0.1"
-
-range-parser@~1.2.1:
- version "1.2.1"
- resolved "https://registry.yarnpkg.com/range-parser/-/range-parser-1.2.1.tgz#3cf37023d199e1c24d1a55b84800c2f3e6468031"
- integrity sha512-Hrgsx+orqoygnmhFbKaHE6c296J+HTAQXoxEF6gNupROmmGJRoyzfG3ccAveqCBrwr/2yxQ5BVd/GTl5agOwSg==
-
-raw-body@2.5.1:
- version "2.5.1"
- resolved "https://registry.yarnpkg.com/raw-body/-/raw-body-2.5.1.tgz#fe1b1628b181b700215e5fd42389f98b71392857"
- integrity sha512-qqJBtEyVgS0ZmPGdCFPWJ3FreoqvG4MVQln/kCgF7Olq95IbOp0/BWyMwbdtn4VTvkM8Y7khCQ2Xgk/tcrCXig==
- dependencies:
- bytes "3.1.2"
- http-errors "2.0.0"
- iconv-lite "0.4.24"
- unpipe "1.0.0"
-
-raw-body@~1.1.0:
- version "1.1.7"
- resolved "https://registry.yarnpkg.com/raw-body/-/raw-body-1.1.7.tgz#1d027c2bfa116acc6623bca8f00016572a87d425"
- integrity sha512-WmJJU2e9Y6M5UzTOkHaM7xJGAPQD8PNzx3bAd2+uhZAim6wDk6dAZxPVYLF67XhbR4hmKGh33Lpmh4XWrCH5Mg==
- dependencies:
- bytes "1"
- string_decoder "0.10"
-
-react-dev-utils@^5.0.2:
- version "5.0.3"
- resolved "https://registry.yarnpkg.com/react-dev-utils/-/react-dev-utils-5.0.3.tgz#92f97668f03deb09d7fa11ea288832a8c756e35e"
- integrity sha512-Mvs6ofsc2xTjeZIrMaIfbXfsPVrbdVy/cVqq6SAacnqfMlcBpDuivhWZ1ODGeJ8HgmyWTLH971PYjj/EPCDVAw==
- dependencies:
- address "1.0.3"
- babel-code-frame "6.26.0"
- chalk "1.1.3"
- cross-spawn "5.1.0"
- detect-port-alt "1.1.6"
- escape-string-regexp "1.0.5"
- filesize "3.5.11"
- global-modules "1.0.0"
- gzip-size "3.0.0"
- inquirer "3.3.0"
- is-root "1.0.0"
- opn "5.2.0"
- react-error-overlay "^4.0.1"
- recursive-readdir "2.2.1"
- shell-quote "1.6.1"
- sockjs-client "1.1.5"
- strip-ansi "3.0.1"
- text-table "0.2.0"
-
-react-dom@^16.5.0:
- version "16.14.0"
- resolved "https://registry.yarnpkg.com/react-dom/-/react-dom-16.14.0.tgz#7ad838ec29a777fb3c75c3a190f661cf92ab8b89"
- integrity sha512-1gCeQXDLoIqMgqD3IO2Ah9bnf0w9kzhwN5q4FGnHZ67hBm9yePzB5JJAIQCc8x3pFnNlwFq4RidZggNAAkzWWw==
- dependencies:
- loose-envify "^1.1.0"
- object-assign "^4.1.1"
- prop-types "^15.6.2"
- scheduler "^0.19.1"
-
-react-error-overlay@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/react-error-overlay/-/react-error-overlay-4.0.1.tgz#417addb0814a90f3a7082eacba7cee588d00da89"
- integrity sha512-xXUbDAZkU08aAkjtUvldqbvI04ogv+a1XdHxvYuHPYKIVk/42BIOD0zSKTHAWV4+gDy3yGm283z2072rA2gdtw==
-
-react-is@^16.13.1:
- version "16.13.1"
- resolved "https://registry.yarnpkg.com/react-is/-/react-is-16.13.1.tgz#789729a4dc36de2999dc156dd6c1d9c18cea56a4"
- integrity sha512-24e6ynE2H+OKt4kqsOvNd8kBpV65zoxbA4BVsEOB3ARVWQki/DHzaUoC5KuON/BiccDaCCTZBuOcfZs70kR8bQ==
-
-react@^16.5.0:
- version "16.14.0"
- resolved "https://registry.yarnpkg.com/react/-/react-16.14.0.tgz#94d776ddd0aaa37da3eda8fc5b6b18a4c9a3114d"
- integrity sha512-0X2CImDkJGApiAlcf0ODKIneSwBPhqJawOa5wCtKbu7ZECrmS26NvtSILynQ66cgkT/RJ4LidJOc3bUESwmU8g==
- dependencies:
- loose-envify "^1.1.0"
- object-assign "^4.1.1"
- prop-types "^15.6.2"
-
-read-pkg-up@^1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/read-pkg-up/-/read-pkg-up-1.0.1.tgz#9d63c13276c065918d57f002a57f40a1b643fb02"
- integrity sha512-WD9MTlNtI55IwYUS27iHh9tK3YoIVhxis8yKhLpTqWtml739uXc9NWTpxoHkfZf3+DkCCsXox94/VWZniuZm6A==
- dependencies:
- find-up "^1.0.0"
- read-pkg "^1.0.0"
-
-read-pkg@^1.0.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/read-pkg/-/read-pkg-1.1.0.tgz#f5ffaa5ecd29cb31c0474bca7d756b6bb29e3f28"
- integrity sha512-7BGwRHqt4s/uVbuyoeejRn4YmFnYZiFl4AuaeXHlgZf3sONF0SOGlxs2Pw8g6hCKupo08RafIO5YXFNOKTfwsQ==
- dependencies:
- load-json-file "^1.0.0"
- normalize-package-data "^2.3.2"
- path-type "^1.0.0"
-
-readable-stream@^2.0.0, readable-stream@^2.0.2, readable-stream@^2.2.2, readable-stream@^2.3.0, readable-stream@^2.3.5, readable-stream@~2.3.6:
- version "2.3.7"
- resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.3.7.tgz#1eca1cf711aef814c04f62252a36a62f6cb23b57"
- integrity sha512-Ebho8K4jIbHAxnuxi7o42OrZgF/ZTNcsZj6nRKyUmkhLFq8CHItp/fy6hQZuZmP/n3yZ9VBUbp4zz/mX8hmYPw==
- dependencies:
- core-util-is "~1.0.0"
- inherits "~2.0.3"
- isarray "~1.0.0"
- process-nextick-args "~2.0.0"
- safe-buffer "~5.1.1"
- string_decoder "~1.1.1"
- util-deprecate "~1.0.1"
-
-readable-stream@^3.1.1:
- version "3.6.0"
- resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-3.6.0.tgz#337bbda3adc0706bd3e024426a286d4b4b2c9198"
- integrity sha512-BViHy7LKeTz4oNnkcLJ+lVSL6vpiFeX6/d3oSH8zCW7UxP2onchk+vTGB143xuFjHS3deTgkKoXXymXqymiIdA==
- dependencies:
- inherits "^2.0.3"
- string_decoder "^1.1.1"
- util-deprecate "^1.0.1"
-
-readdirp@~3.6.0:
- version "3.6.0"
- resolved "https://registry.yarnpkg.com/readdirp/-/readdirp-3.6.0.tgz#74a370bd857116e245b29cc97340cd431a02a6c7"
- integrity sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA==
- dependencies:
- picomatch "^2.2.1"
-
-rechoir@^0.6.2:
- version "0.6.2"
- resolved "https://registry.yarnpkg.com/rechoir/-/rechoir-0.6.2.tgz#85204b54dba82d5742e28c96756ef43af50e3384"
- integrity sha512-HFM8rkZ+i3zrV+4LQjwQ0W+ez98pApMGM3HUrN04j3CqzPOzl9nmP15Y8YXNm8QHGv/eacOVEjqhmWpkRV0NAw==
- dependencies:
- resolve "^1.1.6"
-
-recursive-readdir@2.2.1:
- version "2.2.1"
- resolved "https://registry.yarnpkg.com/recursive-readdir/-/recursive-readdir-2.2.1.tgz#90ef231d0778c5ce093c9a48d74e5c5422d13a99"
- integrity sha512-BKWLxPZb4B07G/4LzyzsHaw24fC41/tL7LrECr1//X9ykRhmxlYgyl7G7X+6A7nvJyOGE/ED7refqmSGORVYqQ==
- dependencies:
- minimatch "3.0.3"
-
-redent@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/redent/-/redent-1.0.0.tgz#cf916ab1fd5f1f16dfb20822dd6ec7f730c2afde"
- integrity sha512-qtW5hKzGQZqKoh6JNSD+4lfitfPKGz42e6QwiRmPM5mmKtR0N41AbJRYu0xJi7nhOJ4WDgRkKvAk6tw4WIwR4g==
- dependencies:
- indent-string "^2.1.0"
- strip-indent "^1.0.1"
-
-regenerate-unicode-properties@^10.1.0:
- version "10.1.0"
- resolved "https://registry.yarnpkg.com/regenerate-unicode-properties/-/regenerate-unicode-properties-10.1.0.tgz#7c3192cab6dd24e21cb4461e5ddd7dd24fa8374c"
- integrity sha512-d1VudCLoIGitcU/hEg2QqvyGZQmdC0Lf8BqdOMXGFSvJP4bNV1+XqbPQeHHLD51Jh4QJJ225dlIFvY4Ly6MXmQ==
- dependencies:
- regenerate "^1.4.2"
-
-regenerate@^1.4.2:
- version "1.4.2"
- resolved "https://registry.yarnpkg.com/regenerate/-/regenerate-1.4.2.tgz#b9346d8827e8f5a32f7ba29637d398b69014848a"
- integrity sha512-zrceR/XhGYU/d/opr2EKO7aRHUeiBI8qjtfHqADTwZd6Szfy16la6kqD0MIUs5z5hx6AaKa+PixpPrR289+I0A==
-
-regenerator-runtime@^0.13.10, regenerator-runtime@^0.13.4:
- version "0.13.10"
- resolved "https://registry.yarnpkg.com/regenerator-runtime/-/regenerator-runtime-0.13.10.tgz#ed07b19616bcbec5da6274ebc75ae95634bfc2ee"
- integrity sha512-KepLsg4dU12hryUO7bp/axHAKvwGOCV0sGloQtpagJ12ai+ojVDqkeGSiRX1zlq+kjIMZ1t7gpze+26QqtdGqw==
-
-regenerator-transform@^0.15.0:
- version "0.15.0"
- resolved "https://registry.yarnpkg.com/regenerator-transform/-/regenerator-transform-0.15.0.tgz#cbd9ead5d77fae1a48d957cf889ad0586adb6537"
- integrity sha512-LsrGtPmbYg19bcPHwdtmXwbW+TqNvtY4riE3P83foeHRroMbH6/2ddFBfab3t7kbzc7v7p4wbkIecHImqt0QNg==
- dependencies:
- "@babel/runtime" "^7.8.4"
-
-regex-not@^1.0.0, regex-not@^1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/regex-not/-/regex-not-1.0.2.tgz#1f4ece27e00b0b65e0247a6810e6a85d83a5752c"
- integrity sha512-J6SDjUgDxQj5NusnOtdFxDwN/+HWykR8GELwctJ7mdqhcyy1xEc4SRFHUXvxTp661YaVKAjfRLZ9cCqS6tn32A==
- dependencies:
- extend-shallow "^3.0.2"
- safe-regex "^1.1.0"
-
-regexp.prototype.flags@^1.4.3:
- version "1.4.3"
- resolved "https://registry.yarnpkg.com/regexp.prototype.flags/-/regexp.prototype.flags-1.4.3.tgz#87cab30f80f66660181a3bb7bf5981a872b367ac"
- integrity sha512-fjggEOO3slI6Wvgjwflkc4NFRCTZAu5CnNfBd5qOMYhWdn67nJBBu34/TkD++eeFmd8C9r9jfXJ27+nSiRkSUA==
- dependencies:
- call-bind "^1.0.2"
- define-properties "^1.1.3"
- functions-have-names "^1.2.2"
-
-regexpu-core@^5.1.0:
- version "5.2.2"
- resolved "https://registry.yarnpkg.com/regexpu-core/-/regexpu-core-5.2.2.tgz#3e4e5d12103b64748711c3aad69934d7718e75fc"
- integrity sha512-T0+1Zp2wjF/juXMrMxHxidqGYn8U4R+zleSJhX9tQ1PUsS8a9UtYfbsF9LdiVgNX3kiX8RNaKM42nfSgvFJjmw==
- dependencies:
- regenerate "^1.4.2"
- regenerate-unicode-properties "^10.1.0"
- regjsgen "^0.7.1"
- regjsparser "^0.9.1"
- unicode-match-property-ecmascript "^2.0.0"
- unicode-match-property-value-ecmascript "^2.1.0"
-
-regjsgen@^0.7.1:
- version "0.7.1"
- resolved "https://registry.yarnpkg.com/regjsgen/-/regjsgen-0.7.1.tgz#ee5ef30e18d3f09b7c369b76e7c2373ed25546f6"
- integrity sha512-RAt+8H2ZEzHeYWxZ3H2z6tF18zyyOnlcdaafLrm21Bguj7uZy6ULibiAFdXEtKQY4Sy7wDTwDiOazasMLc4KPA==
-
-regjsparser@^0.9.1:
- version "0.9.1"
- resolved "https://registry.yarnpkg.com/regjsparser/-/regjsparser-0.9.1.tgz#272d05aa10c7c1f67095b1ff0addae8442fc5709"
- integrity sha512-dQUtn90WanSNl+7mQKcXAgZxvUe7Z0SqXlgzv0za4LwiUhyzBC58yQO3liFoUgu8GiJVInAhJjkj1N0EtQ5nkQ==
- dependencies:
- jsesc "~0.5.0"
-
-remarkable@^1.7.1:
- version "1.7.4"
- resolved "https://registry.yarnpkg.com/remarkable/-/remarkable-1.7.4.tgz#19073cb960398c87a7d6546eaa5e50d2022fcd00"
- integrity sha512-e6NKUXgX95whv7IgddywbeN/ItCkWbISmc2DiqHJb0wTrqZIexqdco5b8Z3XZoo/48IdNVKM9ZCvTPJ4F5uvhg==
- dependencies:
- argparse "^1.0.10"
- autolinker "~0.28.0"
-
-repeat-element@^1.1.2:
- version "1.1.4"
- resolved "https://registry.yarnpkg.com/repeat-element/-/repeat-element-1.1.4.tgz#be681520847ab58c7568ac75fbfad28ed42d39e9"
- integrity sha512-LFiNfRcSu7KK3evMyYOuCzv3L10TW7yC1G2/+StMjK8Y6Vqd2MG7r/Qjw4ghtuCOjFvlnms/iMmLqpvW/ES/WQ==
-
-repeat-string@^1.5.2, repeat-string@^1.6.1:
- version "1.6.1"
- resolved "https://registry.yarnpkg.com/repeat-string/-/repeat-string-1.6.1.tgz#8dcae470e1c88abc2d600fff4a776286da75e637"
- integrity sha512-PV0dzCYDNfRi1jCDbJzpW7jNNDRuCOG/jI5ctQcGKt/clZD+YcPS3yIlWuTJMmESC8aevCFmWJy5wjAFgNqN6w==
-
-repeating@^2.0.0:
- version "2.0.1"
- resolved "https://registry.yarnpkg.com/repeating/-/repeating-2.0.1.tgz#5214c53a926d3552707527fbab415dbc08d06dda"
- integrity sha512-ZqtSMuVybkISo2OWvqvm7iHSWngvdaW3IpsT9/uP8v4gMi591LY6h35wdOfvQdWCKFWZWm2Y1Opp4kV7vQKT6A==
- dependencies:
- is-finite "^1.0.0"
-
-replace-ext@^1.0.0:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/replace-ext/-/replace-ext-1.0.1.tgz#2d6d996d04a15855d967443631dd5f77825b016a"
- integrity sha512-yD5BHCe7quCgBph4rMQ+0KkIRKwWCrHDOX1p1Gp6HwjPM5kVoCdKGNhN7ydqqsX6lJEnQDKZ/tFMiEdQ1dvPEw==
-
-request@^2.53.0, request@^2.87.0:
- version "2.88.2"
- resolved "https://registry.yarnpkg.com/request/-/request-2.88.2.tgz#d73c918731cb5a87da047e207234146f664d12b3"
- integrity sha512-MsvtOrfG9ZcrOwAW+Qi+F6HbD0CWXEh9ou77uOb7FM2WPhwT7smM833PzanhJLsgXjN89Ir6V2PczXNnMpwKhw==
- dependencies:
- aws-sign2 "~0.7.0"
- aws4 "^1.8.0"
- caseless "~0.12.0"
- combined-stream "~1.0.6"
- extend "~3.0.2"
- forever-agent "~0.6.1"
- form-data "~2.3.2"
- har-validator "~5.1.3"
- http-signature "~1.2.0"
- is-typedarray "~1.0.0"
- isstream "~0.1.2"
- json-stringify-safe "~5.0.1"
- mime-types "~2.1.19"
- oauth-sign "~0.9.0"
- performance-now "^2.1.0"
- qs "~6.5.2"
- safe-buffer "^5.1.2"
- tough-cookie "~2.5.0"
- tunnel-agent "^0.6.0"
- uuid "^3.3.2"
-
-requires-port@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/requires-port/-/requires-port-1.0.0.tgz#925d2601d39ac485e091cf0da5c6e694dc3dcaff"
- integrity sha512-KigOCHcocU3XODJxsu8i/j8T9tzT4adHiecwORRQ0ZZFcp7ahwXuRU1m+yuO90C5ZUyGeGfocHDI14M3L3yDAQ==
-
-resolve-dir@^1.0.0:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/resolve-dir/-/resolve-dir-1.0.1.tgz#79a40644c362be82f26effe739c9bb5382046f43"
- integrity sha512-R7uiTjECzvOsWSfdM0QKFNBVFcK27aHOUwdvK53BcW8zqnGdYp0Fbj82cy54+2A4P2tFM22J5kRfe1R+lM/1yg==
- dependencies:
- expand-tilde "^2.0.0"
- global-modules "^1.0.0"
-
-resolve-from@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/resolve-from/-/resolve-from-3.0.0.tgz#b22c7af7d9d6881bc8b6e653335eebcb0a188748"
- integrity sha512-GnlH6vxLymXJNMBo7XP1fJIzBFbdYt49CuTwmB/6N53t+kMPRMFKz783LlQ4tv28XoQfMWinAJX6WCGf2IlaIw==
-
-resolve-url@^0.2.1:
- version "0.2.1"
- resolved "https://registry.yarnpkg.com/resolve-url/-/resolve-url-0.2.1.tgz#2c637fe77c893afd2a663fe21aa9080068e2052a"
- integrity sha512-ZuF55hVUQaaczgOIwqWzkEcEidmlD/xl44x1UZnhOXcYuFN2S6+rcxpG+C1N3So0wvNI3DmJICUFfu2SxhBmvg==
-
-resolve@^1.1.6, resolve@^1.10.0, resolve@^1.14.2:
- version "1.22.1"
- resolved "https://registry.yarnpkg.com/resolve/-/resolve-1.22.1.tgz#27cb2ebb53f91abb49470a928bba7558066ac177"
- integrity sha512-nBpuuYuY5jFsli/JIs1oldw6fOQCBioohqWZg/2hiaOybXOft4lonv85uDOKXdf8rhyK159cxU5cDcK/NKk8zw==
- dependencies:
- is-core-module "^2.9.0"
- path-parse "^1.0.7"
- supports-preserve-symlinks-flag "^1.0.0"
-
-responselike@1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/responselike/-/responselike-1.0.2.tgz#918720ef3b631c5642be068f15ade5a46f4ba1e7"
- integrity sha512-/Fpe5guzJk1gPqdJLJR5u7eG/gNY4nImjbRDaVWVMRhne55TCmj2i9Q+54PBRfatRC8v/rIiv9BN0pMd9OV5EQ==
- dependencies:
- lowercase-keys "^1.0.0"
-
-restore-cursor@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/restore-cursor/-/restore-cursor-2.0.0.tgz#9f7ee287f82fd326d4fd162923d62129eee0dfaf"
- integrity sha512-6IzJLuGi4+R14vwagDHX+JrXmPVtPpn4mffDJ1UdR7/Edm87fl6yi8mMBIVvFtJaNTUvjughmW4hwLhRG7gC1Q==
- dependencies:
- onetime "^2.0.0"
- signal-exit "^3.0.2"
-
-ret@~0.1.10:
- version "0.1.15"
- resolved "https://registry.yarnpkg.com/ret/-/ret-0.1.15.tgz#b8a4825d5bdb1fc3f6f53c2bc33f81388681c7bc"
- integrity sha512-TTlYpa+OL+vMMNG24xSlQGEJ3B/RzEfUlLct7b5G/ytav+wPrplCpVMFuwzXbkecJrb6IYo1iFb0S9v37754mg==
-
-rgb-regex@^1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/rgb-regex/-/rgb-regex-1.0.1.tgz#c0e0d6882df0e23be254a475e8edd41915feaeb1"
- integrity sha512-gDK5mkALDFER2YLqH6imYvK6g02gpNGM4ILDZ472EwWfXZnC2ZEpoB2ECXTyOVUKuk/bPJZMzwQPBYICzP+D3w==
-
-rgba-regex@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/rgba-regex/-/rgba-regex-1.0.0.tgz#43374e2e2ca0968b0ef1523460b7d730ff22eeb3"
- integrity sha512-zgn5OjNQXLUTdq8m17KdaicF6w89TZs8ZU8y0AYENIU6wG8GG6LLm0yLSiPY8DmaYmHdgRW8rnApjoT0fQRfMg==
-
-rimraf@2, rimraf@^2.5.4:
- version "2.7.1"
- resolved "https://registry.yarnpkg.com/rimraf/-/rimraf-2.7.1.tgz#35797f13a7fdadc566142c29d4f07ccad483e3ec"
- integrity sha512-uWjbaKIK3T1OSVptzX7Nl6PvQ3qAGtKEtVRjRuazjfL3Bx5eI409VZSqgND+4UNnmzLVdPj9FqFJNPqBZFve4w==
- dependencies:
- glob "^7.1.3"
-
-run-async@^2.2.0:
- version "2.4.1"
- resolved "https://registry.yarnpkg.com/run-async/-/run-async-2.4.1.tgz#8440eccf99ea3e70bd409d49aab88e10c189a455"
- integrity sha512-tvVnVv01b8c1RrA6Ep7JkStj85Guv/YrMcwqYQnwjsAS2cTmmPGBBjAjpCW7RrSodNSoE2/qg9O4bceNvUuDgQ==
-
-rx-lite-aggregates@^4.0.8:
- version "4.0.8"
- resolved "https://registry.yarnpkg.com/rx-lite-aggregates/-/rx-lite-aggregates-4.0.8.tgz#753b87a89a11c95467c4ac1626c4efc4e05c67be"
- integrity sha512-3xPNZGW93oCjiO7PtKxRK6iOVYBWBvtf9QHDfU23Oc+dLIQmAV//UnyXV/yihv81VS/UqoQPk4NegS8EFi55Hg==
- dependencies:
- rx-lite "*"
-
-rx-lite@*, rx-lite@^4.0.8:
- version "4.0.8"
- resolved "https://registry.yarnpkg.com/rx-lite/-/rx-lite-4.0.8.tgz#0b1e11af8bc44836f04a6407e92da42467b79444"
- integrity sha512-Cun9QucwK6MIrp3mry/Y7hqD1oFqTYLQ4pGxaHTjIdaFDWRGGLikqp6u8LcWJnzpoALg9hap+JGk8sFIUuEGNA==
-
-safe-buffer@5.2.1, safe-buffer@>=5.1.0, safe-buffer@^5.0.1, safe-buffer@^5.1.1, safe-buffer@^5.1.2, safe-buffer@~5.2.0:
- version "5.2.1"
- resolved "https://registry.yarnpkg.com/safe-buffer/-/safe-buffer-5.2.1.tgz#1eaf9fa9bdb1fdd4ec75f58f9cdb4e6b7827eec6"
- integrity sha512-rp3So07KcdmmKbGvgaNxQSJr7bGVSVk5S9Eq1F+ppbRo70+YeaDxkw5Dd8NPN+GD6bjnYm2VuPuCXmpuYvmCXQ==
-
-safe-buffer@~5.1.0, safe-buffer@~5.1.1:
- version "5.1.2"
- resolved "https://registry.yarnpkg.com/safe-buffer/-/safe-buffer-5.1.2.tgz#991ec69d296e0313747d59bdfd2b745c35f8828d"
- integrity sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==
-
-safe-json-parse@~1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/safe-json-parse/-/safe-json-parse-1.0.1.tgz#3e76723e38dfdda13c9b1d29a1e07ffee4b30b57"
- integrity sha512-o0JmTu17WGUaUOHa1l0FPGXKBfijbxK6qoHzlkihsDXxzBHvJcA7zgviKR92Xs841rX9pK16unfphLq0/KqX7A==
-
-safe-regex-test@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/safe-regex-test/-/safe-regex-test-1.0.0.tgz#793b874d524eb3640d1873aad03596db2d4f2295"
- integrity sha512-JBUUzyOgEwXQY1NuPtvcj/qcBDbDmEvWufhlnXZIm75DEHp+afM1r1ujJpJsV/gSM4t59tpDyPi1sd6ZaPFfsA==
- dependencies:
- call-bind "^1.0.2"
- get-intrinsic "^1.1.3"
- is-regex "^1.1.4"
-
-safe-regex@^1.1.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/safe-regex/-/safe-regex-1.1.0.tgz#40a3669f3b077d1e943d44629e157dd48023bf2e"
- integrity sha512-aJXcif4xnaNUzvUuC5gcb46oTS7zvg4jpMTnuqtrEPlR3vFr4pxtdTwaF1Qs3Enjn9HK+ZlwQui+a7z0SywIzg==
- dependencies:
- ret "~0.1.10"
-
-"safer-buffer@>= 2.1.2 < 3", safer-buffer@^2.0.2, safer-buffer@^2.1.0, safer-buffer@~2.1.0:
- version "2.1.2"
- resolved "https://registry.yarnpkg.com/safer-buffer/-/safer-buffer-2.1.2.tgz#44fa161b0187b9549dd84bb91802f9bd8385cd6a"
- integrity sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==
-
-sax@~1.2.4:
- version "1.2.4"
- resolved "https://registry.yarnpkg.com/sax/-/sax-1.2.4.tgz#2816234e2378bddc4e5354fab5caa895df7100d9"
- integrity sha512-NqVDv9TpANUjFm0N8uM5GxL36UgKi9/atZw+x7YFnQ8ckwFGKrl4xX4yWtrey3UJm5nP1kUbnYgLopqWNSRhWw==
-
-scheduler@^0.19.1:
- version "0.19.1"
- resolved "https://registry.yarnpkg.com/scheduler/-/scheduler-0.19.1.tgz#4f3e2ed2c1a7d65681f4c854fa8c5a1ccb40f196"
- integrity sha512-n/zwRWRYSUj0/3g/otKDRPMh6qv2SYMWNq85IEa8iZyAv8od9zDYpGSnpBEjNgcMNq6Scbu5KfIPxNF72R/2EA==
- dependencies:
- loose-envify "^1.1.0"
- object-assign "^4.1.1"
-
-seek-bzip@^1.0.5:
- version "1.0.6"
- resolved "https://registry.yarnpkg.com/seek-bzip/-/seek-bzip-1.0.6.tgz#35c4171f55a680916b52a07859ecf3b5857f21c4"
- integrity sha512-e1QtP3YL5tWww8uKaOCQ18UxIT2laNBXHjV/S2WYCiK4udiv8lkG89KRIoCjUagnAmCBurjF4zEVX2ByBbnCjQ==
- dependencies:
- commander "^2.8.1"
-
-semver-regex@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/semver-regex/-/semver-regex-2.0.0.tgz#a93c2c5844539a770233379107b38c7b4ac9d338"
- integrity sha512-mUdIBBvdn0PLOeP3TEkMH7HHeUP3GjsXCwKarjv/kGmUFOYg1VqEemKhoQpWMu6X2I8kHeuVdGibLGkVK+/5Qw==
-
-semver-truncate@^1.1.2:
- version "1.1.2"
- resolved "https://registry.yarnpkg.com/semver-truncate/-/semver-truncate-1.1.2.tgz#57f41de69707a62709a7e0104ba2117109ea47e8"
- integrity sha512-V1fGg9i4CL3qesB6U0L6XAm4xOJiHmt4QAacazumuasc03BvtFGIMCduv01JWQ69Nv+JST9TqhSCiJoxoY031w==
- dependencies:
- semver "^5.3.0"
-
-"semver@2 || 3 || 4 || 5", semver@^5.3.0, semver@^5.5.0, semver@^5.6.0:
- version "5.7.1"
- resolved "https://registry.yarnpkg.com/semver/-/semver-5.7.1.tgz#a954f931aeba508d307bbf069eff0c01c96116f7"
- integrity sha512-sauaDf/PZdVgrLTNYHRtpXa1iRiKcaebiKQ1BJdpQlWH2lCvexQdX55snPFyK7QzpudqbCI0qXFfOasHdyNDGQ==
-
-semver@^6.1.1, semver@^6.1.2, semver@^6.3.0:
- version "6.3.0"
- resolved "https://registry.yarnpkg.com/semver/-/semver-6.3.0.tgz#ee0a64c8af5e8ceea67687b133761e1becbd1d3d"
- integrity sha512-b39TBaTSfV6yBrapU89p5fKekE2m/NwnDocOVruQFS1/veMgdzuPcnOM34M6CwxW8jH/lxEa5rBoDeUwu5HHTw==
-
-send@0.18.0:
- version "0.18.0"
- resolved "https://registry.yarnpkg.com/send/-/send-0.18.0.tgz#670167cc654b05f5aa4a767f9113bb371bc706be"
- integrity sha512-qqWzuOjSFOuqPjFe4NOsMLafToQQwBSOEpS+FwEt3A2V3vKubTquT3vmLTQpFgMXp8AlFWFuP1qKaJZOtPpVXg==
- dependencies:
- debug "2.6.9"
- depd "2.0.0"
- destroy "1.2.0"
- encodeurl "~1.0.2"
- escape-html "~1.0.3"
- etag "~1.8.1"
- fresh "0.5.2"
- http-errors "2.0.0"
- mime "1.6.0"
- ms "2.1.3"
- on-finished "2.4.1"
- range-parser "~1.2.1"
- statuses "2.0.1"
-
-serve-static@1.15.0:
- version "1.15.0"
- resolved "https://registry.yarnpkg.com/serve-static/-/serve-static-1.15.0.tgz#faaef08cffe0a1a62f60cad0c4e513cff0ac9540"
- integrity sha512-XGuRDNjXUijsUL0vl6nSD7cwURuzEgglbOaFuZM9g3kwDXOWVTck0jLzjPzGD+TazWbboZYu52/9/XPdUgne9g==
- dependencies:
- encodeurl "~1.0.2"
- escape-html "~1.0.3"
- parseurl "~1.3.3"
- send "0.18.0"
-
-set-getter@^0.1.0:
- version "0.1.1"
- resolved "https://registry.yarnpkg.com/set-getter/-/set-getter-0.1.1.tgz#a3110e1b461d31a9cfc8c5c9ee2e9737ad447102"
- integrity sha512-9sVWOy+gthr+0G9DzqqLaYNA7+5OKkSmcqjL9cBpDEaZrr3ShQlyX2cZ/O/ozE41oxn/Tt0LGEM/w4Rub3A3gw==
- dependencies:
- to-object-path "^0.3.0"
-
-set-value@^2.0.0, set-value@^2.0.1:
- version "2.0.1"
- resolved "https://registry.yarnpkg.com/set-value/-/set-value-2.0.1.tgz#a18d40530e6f07de4228c7defe4227af8cad005b"
- integrity sha512-JxHc1weCN68wRY0fhCoXpyK55m/XPHafOmK4UWD7m2CI14GMcFypt4w/0+NV5f/ZMby2F6S2wwA7fgynh9gWSw==
- dependencies:
- extend-shallow "^2.0.1"
- is-extendable "^0.1.1"
- is-plain-object "^2.0.3"
- split-string "^3.0.1"
-
-setimmediate@~1.0.4:
- version "1.0.5"
- resolved "https://registry.yarnpkg.com/setimmediate/-/setimmediate-1.0.5.tgz#290cbb232e306942d7d7ea9b83732ab7856f8285"
- integrity sha512-MATJdZp8sLqDl/68LfQmbP8zKPLQNV6BIZoIgrscFDQ+RsvK/BxeDQOgyxKKoh0y/8h3BqVFnCqQ/gd+reiIXA==
-
-setprototypeof@1.2.0:
- version "1.2.0"
- resolved "https://registry.yarnpkg.com/setprototypeof/-/setprototypeof-1.2.0.tgz#66c9a24a73f9fc28cbe66b09fed3d33dcaf1b424"
- integrity sha512-E5LDX7Wrp85Kil5bhZv46j8jOeboKq5JMmYM3gVGdGH8xFpPWXUMsNrlODCrkoxMEeNi/XZIwuRvY4XNwYMJpw==
-
-shallow-clone@^3.0.0:
- version "3.0.1"
- resolved "https://registry.yarnpkg.com/shallow-clone/-/shallow-clone-3.0.1.tgz#8f2981ad92531f55035b01fb230769a40e02efa3"
- integrity sha512-/6KqX+GVUdqPuPPd2LxDDxzX6CAbjJehAAOKlNpqqUpAqPM6HeL8f+o3a+JsyGjn2lv0WY8UsTgUJjU9Ok55NA==
- dependencies:
- kind-of "^6.0.2"
-
-shebang-command@^1.2.0:
- version "1.2.0"
- resolved "https://registry.yarnpkg.com/shebang-command/-/shebang-command-1.2.0.tgz#44aac65b695b03398968c39f363fee5deafdf1ea"
- integrity sha512-EV3L1+UQWGor21OmnvojK36mhg+TyIKDh3iFBKBohr5xeXIhNBcx8oWdgkTEEQ+BEFFYdLRuqMfd5L84N1V5Vg==
- dependencies:
- shebang-regex "^1.0.0"
-
-shebang-regex@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/shebang-regex/-/shebang-regex-1.0.0.tgz#da42f49740c0b42db2ca9728571cb190c98efea3"
- integrity sha512-wpoSFAxys6b2a2wHZ1XpDSgD7N9iVjg29Ph9uV/uaP9Ex/KXlkTZTeddxDPSYQpgvzKLGJke2UU0AzoGCjNIvQ==
-
-shell-quote@1.6.1:
- version "1.6.1"
- resolved "https://registry.yarnpkg.com/shell-quote/-/shell-quote-1.6.1.tgz#f4781949cce402697127430ea3b3c5476f481767"
- integrity sha512-V0iQEZ/uoem3NmD91rD8XiuozJnq9/ZJnbHVXHnWqP1ucAhS3yJ7sLIIzEi57wFFcK3oi3kFUC46uSyWr35mxg==
- dependencies:
- array-filter "~0.0.0"
- array-map "~0.0.0"
- array-reduce "~0.0.0"
- jsonify "~0.0.0"
-
-shelljs@^0.8.3:
- version "0.8.5"
- resolved "https://registry.yarnpkg.com/shelljs/-/shelljs-0.8.5.tgz#de055408d8361bed66c669d2f000538ced8ee20c"
- integrity sha512-TiwcRcrkhHvbrZbnRcFYMLl30Dfov3HKqzp5tO5b4pt6G/SezKcYhmDg15zXVBswHmctSAQKznqNW2LO5tTDow==
- dependencies:
- glob "^7.0.0"
- interpret "^1.0.0"
- rechoir "^0.6.2"
-
-side-channel@^1.0.4:
- version "1.0.4"
- resolved "https://registry.yarnpkg.com/side-channel/-/side-channel-1.0.4.tgz#efce5c8fdc104ee751b25c58d4290011fa5ea2cf"
- integrity sha512-q5XPytqFEIKHkGdiMIrY10mvLRvnQh42/+GoBlFW3b2LXLE2xxJpZFdm94we0BaoV3RwJyGqg5wS7epxTv0Zvw==
- dependencies:
- call-bind "^1.0.0"
- get-intrinsic "^1.0.2"
- object-inspect "^1.9.0"
-
-signal-exit@^3.0.0, signal-exit@^3.0.2:
- version "3.0.7"
- resolved "https://registry.yarnpkg.com/signal-exit/-/signal-exit-3.0.7.tgz#a9a1767f8af84155114eaabd73f99273c8f59ad9"
- integrity sha512-wnD2ZE+l+SPC/uoS0vXeE9L1+0wuaMqKlfz9AMUo38JsyLSBWSFcHR1Rri62LZc12vLr1gb3jl7iwQhgwpAbGQ==
-
-simple-swizzle@^0.2.2:
- version "0.2.2"
- resolved "https://registry.yarnpkg.com/simple-swizzle/-/simple-swizzle-0.2.2.tgz#a4da6b635ffcccca33f70d17cb92592de95e557a"
- integrity sha512-JA//kQgZtbuY83m+xT+tXJkmJncGMTFT+C+g2h2R9uxkYIrE2yy9sgmcLhCnw57/WSD+Eh3J97FPEDFnbXnDUg==
- dependencies:
- is-arrayish "^0.3.1"
-
-sitemap@^1.13.0:
- version "1.13.0"
- resolved "https://registry.yarnpkg.com/sitemap/-/sitemap-1.13.0.tgz#569cbe2180202926a62a266cd3de09c9ceb43f83"
- integrity sha512-++mJIYR1+WpO1m0iqZv9viGmalxkm6r8Zq8OOFcFzx3aLlXU50T0JV3pvr6WHyFkwudlXmt190ZRbtH3yOm3Hg==
- dependencies:
- underscore "^1.7.0"
- url-join "^1.1.0"
-
-slash@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/slash/-/slash-1.0.0.tgz#c41f2f6c39fc16d1cd17ad4b5d896114ae470d55"
- integrity sha512-3TYDR7xWt4dIqV2JauJr+EJeW356RXijHeUlO+8djJ+uBXPn8/2dpzBc8yQhh583sVvc9CvFAeQVgijsH+PNNg==
-
-snapdragon-node@^2.0.1:
- version "2.1.1"
- resolved "https://registry.yarnpkg.com/snapdragon-node/-/snapdragon-node-2.1.1.tgz#6c175f86ff14bdb0724563e8f3c1b021a286853b"
- integrity sha512-O27l4xaMYt/RSQ5TR3vpWCAB5Kb/czIcqUFOM/C4fYcLnbZUc1PkjTAMjof2pBWaSTwOUd6qUHcFGVGj7aIwnw==
- dependencies:
- define-property "^1.0.0"
- isobject "^3.0.0"
- snapdragon-util "^3.0.1"
-
-snapdragon-util@^3.0.1:
- version "3.0.1"
- resolved "https://registry.yarnpkg.com/snapdragon-util/-/snapdragon-util-3.0.1.tgz#f956479486f2acd79700693f6f7b805e45ab56e2"
- integrity sha512-mbKkMdQKsjX4BAL4bRYTj21edOf8cN7XHdYUJEe+Zn99hVEYcMvKPct1IqNe7+AZPirn8BCDOQBHQZknqmKlZQ==
- dependencies:
- kind-of "^3.2.0"
-
-snapdragon@^0.8.1:
- version "0.8.2"
- resolved "https://registry.yarnpkg.com/snapdragon/-/snapdragon-0.8.2.tgz#64922e7c565b0e14204ba1aa7d6964278d25182d"
- integrity sha512-FtyOnWN/wCHTVXOMwvSv26d+ko5vWlIDD6zoUJ7LW8vh+ZBC8QdljveRP+crNrtBwioEUWy/4dMtbBjA4ioNlg==
- dependencies:
- base "^0.11.1"
- debug "^2.2.0"
- define-property "^0.2.5"
- extend-shallow "^2.0.1"
- map-cache "^0.2.2"
- source-map "^0.5.6"
- source-map-resolve "^0.5.0"
- use "^3.1.0"
-
-sockjs-client@1.1.5:
- version "1.1.5"
- resolved "https://registry.yarnpkg.com/sockjs-client/-/sockjs-client-1.1.5.tgz#1bb7c0f7222c40f42adf14f4442cbd1269771a83"
- integrity sha512-PmPRkAYIeuRgX+ZSieViT4Z3Q23bLS2Itm/ck1tSf5P0/yVuFDiI5q9mcnpXoMdToaPSRS9MEyUx/aaBxrFzyw==
- dependencies:
- debug "^2.6.6"
- eventsource "0.1.6"
- faye-websocket "~0.11.0"
- inherits "^2.0.1"
- json3 "^3.3.2"
- url-parse "^1.1.8"
-
-sort-keys-length@^1.0.0:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/sort-keys-length/-/sort-keys-length-1.0.1.tgz#9cb6f4f4e9e48155a6aa0671edd336ff1479a188"
- integrity sha512-GRbEOUqCxemTAk/b32F2xa8wDTs+Z1QHOkbhJDQTvv/6G3ZkbJ+frYWsTcc7cBB3Fu4wy4XlLCuNtJuMn7Gsvw==
- dependencies:
- sort-keys "^1.0.0"
-
-sort-keys@^1.0.0:
- version "1.1.2"
- resolved "https://registry.yarnpkg.com/sort-keys/-/sort-keys-1.1.2.tgz#441b6d4d346798f1b4e49e8920adfba0e543f9ad"
- integrity sha512-vzn8aSqKgytVik0iwdBEi+zevbTYZogewTUM6dtpmGwEcdzbub/TX4bCzRhebDCRC3QzXgJsLRKB2V/Oof7HXg==
- dependencies:
- is-plain-obj "^1.0.0"
-
-sort-keys@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/sort-keys/-/sort-keys-2.0.0.tgz#658535584861ec97d730d6cf41822e1f56684128"
- integrity sha512-/dPCrG1s3ePpWm6yBbxZq5Be1dXGLyLn9Z791chDC3NFrpkVbWGzkBwPN1knaciexFXgRJ7hzdnwZ4stHSDmjg==
- dependencies:
- is-plain-obj "^1.0.0"
-
-source-map-resolve@^0.5.0:
- version "0.5.3"
- resolved "https://registry.yarnpkg.com/source-map-resolve/-/source-map-resolve-0.5.3.tgz#190866bece7553e1f8f267a2ee82c606b5509a1a"
- integrity sha512-Htz+RnsXWk5+P2slx5Jh3Q66vhQj1Cllm0zvnaY98+NFx+Dv2CF/f5O/t8x+KaNdrdIAsruNzoh/KpialbqAnw==
- dependencies:
- atob "^2.1.2"
- decode-uri-component "^0.2.0"
- resolve-url "^0.2.1"
- source-map-url "^0.4.0"
- urix "^0.1.0"
-
-source-map-support@^0.5.16:
- version "0.5.21"
- resolved "https://registry.yarnpkg.com/source-map-support/-/source-map-support-0.5.21.tgz#04fe7c7f9e1ed2d662233c28cb2b35b9f63f6e4f"
- integrity sha512-uBHU3L3czsIyYXKX88fdrGovxdSCoTGDRZ6SYXtSRxLZUzHg5P/66Ht6uoUlHu9EZod+inXhKo3qQgwXUT/y1w==
- dependencies:
- buffer-from "^1.0.0"
- source-map "^0.6.0"
-
-source-map-url@^0.4.0:
- version "0.4.1"
- resolved "https://registry.yarnpkg.com/source-map-url/-/source-map-url-0.4.1.tgz#0af66605a745a5a2f91cf1bbf8a7afbc283dec56"
- integrity sha512-cPiFOTLUKvJFIg4SKVScy4ilPPW6rFgMgfuZJPNoDuMs3nC1HbMUycBoJw77xFIp6z1UJQJOfx6C9GMH80DiTw==
-
-source-map@^0.5.6:
- version "0.5.7"
- resolved "https://registry.yarnpkg.com/source-map/-/source-map-0.5.7.tgz#8a039d2d1021d22d1ea14c80d8ea468ba2ef3fcc"
- integrity sha512-LbrmJOMUSdEVxIKvdcJzQC+nQhe8FUZQTXQy6+I75skNgn3OoQ0DZA8YnFa7gp8tqtL3KPf1kmo0R5DoApeSGQ==
-
-source-map@^0.6.0, source-map@^0.6.1:
- version "0.6.1"
- resolved "https://registry.yarnpkg.com/source-map/-/source-map-0.6.1.tgz#74722af32e9614e9c287a8d0bbde48b5e2f1a263"
- integrity sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g==
-
-spdx-correct@^3.0.0:
- version "3.1.1"
- resolved "https://registry.yarnpkg.com/spdx-correct/-/spdx-correct-3.1.1.tgz#dece81ac9c1e6713e5f7d1b6f17d468fa53d89a9"
- integrity sha512-cOYcUWwhCuHCXi49RhFRCyJEK3iPj1Ziz9DpViV3tbZOwXD49QzIN3MpOLJNxh2qwq2lJJZaKMVw9qNi4jTC0w==
- dependencies:
- spdx-expression-parse "^3.0.0"
- spdx-license-ids "^3.0.0"
-
-spdx-exceptions@^2.1.0:
- version "2.3.0"
- resolved "https://registry.yarnpkg.com/spdx-exceptions/-/spdx-exceptions-2.3.0.tgz#3f28ce1a77a00372683eade4a433183527a2163d"
- integrity sha512-/tTrYOC7PPI1nUAgx34hUpqXuyJG+DTHJTnIULG4rDygi4xu/tfgmq1e1cIRwRzwZgo4NLySi+ricLkZkw4i5A==
-
-spdx-expression-parse@^3.0.0:
- version "3.0.1"
- resolved "https://registry.yarnpkg.com/spdx-expression-parse/-/spdx-expression-parse-3.0.1.tgz#cf70f50482eefdc98e3ce0a6833e4a53ceeba679"
- integrity sha512-cbqHunsQWnJNE6KhVSMsMeH5H/L9EpymbzqTQ3uLwNCLZ1Q481oWaofqH7nO6V07xlXwY6PhQdQ2IedWx/ZK4Q==
- dependencies:
- spdx-exceptions "^2.1.0"
- spdx-license-ids "^3.0.0"
-
-spdx-license-ids@^3.0.0:
- version "3.0.12"
- resolved "https://registry.yarnpkg.com/spdx-license-ids/-/spdx-license-ids-3.0.12.tgz#69077835abe2710b65f03969898b6637b505a779"
- integrity sha512-rr+VVSXtRhO4OHbXUiAF7xW3Bo9DuuF6C5jH+q/x15j2jniycgKbxU09Hr0WqlSLUs4i4ltHGXqTe7VHclYWyA==
-
-split-string@^3.0.1, split-string@^3.0.2:
- version "3.1.0"
- resolved "https://registry.yarnpkg.com/split-string/-/split-string-3.1.0.tgz#7cb09dda3a86585705c64b39a6466038682e8fe2"
- integrity sha512-NzNVhJDYpwceVVii8/Hu6DKfD2G+NrQHlS/V/qgv763EYudVwEcMQNxd2lh+0VrUByXN/oJkl5grOhYWvQUYiw==
- dependencies:
- extend-shallow "^3.0.0"
-
-sprintf-js@~1.0.2:
- version "1.0.3"
- resolved "https://registry.yarnpkg.com/sprintf-js/-/sprintf-js-1.0.3.tgz#04e6926f662895354f3dd015203633b857297e2c"
- integrity sha512-D9cPgkvLlV3t3IzL0D0YLvGA9Ahk4PcvVwUbN0dSGr1aP0Nrt4AEnTUbuGvquEC0mA64Gqt1fzirlRs5ibXx8g==
-
-squeak@^1.0.0:
- version "1.3.0"
- resolved "https://registry.yarnpkg.com/squeak/-/squeak-1.3.0.tgz#33045037b64388b567674b84322a6521073916c3"
- integrity sha512-YQL1ulInM+ev8nXX7vfXsCsDh6IqXlrremc1hzi77776BtpWgYJUMto3UM05GSAaGzJgWekszjoKDrVNB5XG+A==
- dependencies:
- chalk "^1.0.0"
- console-stream "^0.1.1"
- lpad-align "^1.0.1"
-
-sshpk@^1.7.0:
- version "1.17.0"
- resolved "https://registry.yarnpkg.com/sshpk/-/sshpk-1.17.0.tgz#578082d92d4fe612b13007496e543fa0fbcbe4c5"
- integrity sha512-/9HIEs1ZXGhSPE8X6Ccm7Nam1z8KcoCqPdI7ecm1N33EzAetWahvQWVqLZtaZQ+IDKX4IyA2o0gBzqIMkAagHQ==
- dependencies:
- asn1 "~0.2.3"
- assert-plus "^1.0.0"
- bcrypt-pbkdf "^1.0.0"
- dashdash "^1.12.0"
- ecc-jsbn "~0.1.1"
- getpass "^0.1.1"
- jsbn "~0.1.0"
- safer-buffer "^2.0.2"
- tweetnacl "~0.14.0"
-
-stable@^0.1.8:
- version "0.1.8"
- resolved "https://registry.yarnpkg.com/stable/-/stable-0.1.8.tgz#836eb3c8382fe2936feaf544631017ce7d47a3cf"
- integrity sha512-ji9qxRnOVfcuLDySj9qzhGSEFVobyt1kIOSkj1qZzYLzq7Tos/oUUWvotUPQLlrsidqsK6tBH89Bc9kL5zHA6w==
-
-static-extend@^0.1.1:
- version "0.1.2"
- resolved "https://registry.yarnpkg.com/static-extend/-/static-extend-0.1.2.tgz#60809c39cbff55337226fd5e0b520f341f1fb5c6"
- integrity sha512-72E9+uLc27Mt718pMHt9VMNiAL4LMsmDbBva8mxWUCkT07fSzEGMYUCk0XWY6lp0j6RBAG4cJ3mWuZv2OE3s0g==
- dependencies:
- define-property "^0.2.5"
- object-copy "^0.1.0"
-
-statuses@2.0.1:
- version "2.0.1"
- resolved "https://registry.yarnpkg.com/statuses/-/statuses-2.0.1.tgz#55cb000ccf1d48728bd23c685a063998cf1a1b63"
- integrity sha512-RwNA9Z/7PrK06rYLIzFMlaF+l73iwpzsqRIFgbMLbTcLD6cOao82TaWefPXQvB2fOC4AjuYSEndS7N/mTCbkdQ==
-
-strict-uri-encode@^1.0.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/strict-uri-encode/-/strict-uri-encode-1.1.0.tgz#279b225df1d582b1f54e65addd4352e18faa0713"
- integrity sha512-R3f198pcvnB+5IpnBlRkphuE9n46WyVl8I39W/ZUTZLz4nqSP/oLYUrcnJrw462Ds8he4YKMov2efsTIw1BDGQ==
-
-string-template@~0.2.1:
- version "0.2.1"
- resolved "https://registry.yarnpkg.com/string-template/-/string-template-0.2.1.tgz#42932e598a352d01fc22ec3367d9d84eec6c9add"
- integrity sha512-Yptehjogou2xm4UJbxJ4CxgZx12HBfeystp0y3x7s4Dj32ltVVG1Gg8YhKjHZkHicuKpZX/ffilA8505VbUbpw==
-
-string-width@^2.1.0:
- version "2.1.1"
- resolved "https://registry.yarnpkg.com/string-width/-/string-width-2.1.1.tgz#ab93f27a8dc13d28cac815c462143a6d9012ae9e"
- integrity sha512-nOqH59deCq9SRHlxq1Aw85Jnt4w6KvLKqWVik6oA9ZklXLNIOlqg4F2yrT1MVaTjAqvVwdfeZ7w7aCvJD7ugkw==
- dependencies:
- is-fullwidth-code-point "^2.0.0"
- strip-ansi "^4.0.0"
-
-string.prototype.trimend@^1.0.5:
- version "1.0.6"
- resolved "https://registry.yarnpkg.com/string.prototype.trimend/-/string.prototype.trimend-1.0.6.tgz#c4a27fa026d979d79c04f17397f250a462944533"
- integrity sha512-JySq+4mrPf9EsDBEDYMOb/lM7XQLulwg5R/m1r0PXEFqrV0qHvl58sdTilSXtKOflCsK2E8jxf+GKC0T07RWwQ==
- dependencies:
- call-bind "^1.0.2"
- define-properties "^1.1.4"
- es-abstract "^1.20.4"
-
-string.prototype.trimstart@^1.0.5:
- version "1.0.6"
- resolved "https://registry.yarnpkg.com/string.prototype.trimstart/-/string.prototype.trimstart-1.0.6.tgz#e90ab66aa8e4007d92ef591bbf3cd422c56bdcf4"
- integrity sha512-omqjMDaY92pbn5HOX7f9IccLA+U1tA9GvtU4JrodiXFfYB7jPzzHpRzpglLAjtUV6bB557zwClJezTqnAiYnQA==
- dependencies:
- call-bind "^1.0.2"
- define-properties "^1.1.4"
- es-abstract "^1.20.4"
-
-string_decoder@0.10:
- version "0.10.31"
- resolved "https://registry.yarnpkg.com/string_decoder/-/string_decoder-0.10.31.tgz#62e203bc41766c6c28c9fc84301dab1c5310fa94"
- integrity sha512-ev2QzSzWPYmy9GuqfIVildA4OdcGLeFZQrq5ys6RtiuF+RQQiZWr8TZNyAcuVXyQRYfEO+MsoB/1BuQVhOJuoQ==
-
-string_decoder@^1.1.1:
- version "1.3.0"
- resolved "https://registry.yarnpkg.com/string_decoder/-/string_decoder-1.3.0.tgz#42f114594a46cf1a8e30b0a84f56c78c3edac21e"
- integrity sha512-hkRX8U1WjJFd8LsDJ2yQ/wWWxaopEsABU1XfkM8A+j0+85JAGppt16cr1Whg6KIbb4okU6Mql6BOj+uup/wKeA==
- dependencies:
- safe-buffer "~5.2.0"
-
-string_decoder@~1.1.1:
- version "1.1.1"
- resolved "https://registry.yarnpkg.com/string_decoder/-/string_decoder-1.1.1.tgz#9cf1611ba62685d7030ae9e4ba34149c3af03fc8"
- integrity sha512-n/ShnvDi6FHbbVfviro+WojiFzv+s8MPMHBczVePfUpDJLwoLT0ht1l4YwBCbi8pJAveEEdnkHyPyTP/mzRfwg==
- dependencies:
- safe-buffer "~5.1.0"
-
-strip-ansi@3.0.1, strip-ansi@^3.0.0:
- version "3.0.1"
- resolved "https://registry.yarnpkg.com/strip-ansi/-/strip-ansi-3.0.1.tgz#6a385fb8853d952d5ff05d0e8aaf94278dc63dcf"
- integrity sha512-VhumSSbBqDTP8p2ZLKj40UjBCV4+v8bUSEpUb4KjRgWk9pbqGF4REFj6KEagidb2f/M6AzC0EmFyDNGaw9OCzg==
- dependencies:
- ansi-regex "^2.0.0"
-
-strip-ansi@^4.0.0:
- version "4.0.0"
- resolved "https://registry.yarnpkg.com/strip-ansi/-/strip-ansi-4.0.0.tgz#a8479022eb1ac368a871389b635262c505ee368f"
- integrity sha512-4XaJ2zQdCzROZDivEVIDPkcQn8LMFSa8kj8Gxb/Lnwzv9A8VctNZ+lfivC/sV3ivW8ElJTERXZoPBRrZKkNKow==
- dependencies:
- ansi-regex "^3.0.0"
-
-strip-bom@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/strip-bom/-/strip-bom-2.0.0.tgz#6219a85616520491f35788bdbf1447a99c7e6b0e"
- integrity sha512-kwrX1y7czp1E69n2ajbG65mIo9dqvJ+8aBQXOGVxqwvNbsXdFM6Lq37dLAY3mknUwru8CfcCbfOLL/gMo+fi3g==
- dependencies:
- is-utf8 "^0.2.0"
-
-strip-color@^0.1.0:
- version "0.1.0"
- resolved "https://registry.yarnpkg.com/strip-color/-/strip-color-0.1.0.tgz#106f65d3d3e6a2d9401cac0eb0ce8b8a702b4f7b"
- integrity sha512-p9LsUieSjWNNAxVCXLeilaDlmuUOrDS5/dF9znM1nZc7EGX5+zEFC0bEevsNIaldjlks+2jns5Siz6F9iK6jwA==
-
-strip-dirs@^2.0.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/strip-dirs/-/strip-dirs-2.1.0.tgz#4987736264fc344cf20f6c34aca9d13d1d4ed6c5"
- integrity sha512-JOCxOeKLm2CAS73y/U4ZeZPTkE+gNVCzKt7Eox84Iej1LT/2pTWYpZKJuxwQpvX1LiZb1xokNR7RLfuBAa7T3g==
- dependencies:
- is-natural-number "^4.0.1"
-
-strip-eof@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/strip-eof/-/strip-eof-1.0.0.tgz#bb43ff5598a6eb05d89b59fcd129c983313606bf"
- integrity sha512-7FCwGGmx8mD5xQd3RPUvnSpUXHM3BWuzjtpD4TXsfcZ9EL4azvVVUscFYwD9nx8Kh+uCBC00XBtAykoMHwTh8Q==
-
-strip-indent@^1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/strip-indent/-/strip-indent-1.0.1.tgz#0c7962a6adefa7bbd4ac366460a638552ae1a0a2"
- integrity sha512-I5iQq6aFMM62fBEAIB/hXzwJD6EEZ0xEGCX2t7oXqaKPIRgt4WruAQ285BISgdkP+HLGWyeGmNJcpIwFeRYRUA==
- dependencies:
- get-stdin "^4.0.1"
-
-strip-outer@^1.0.0:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/strip-outer/-/strip-outer-1.0.1.tgz#b2fd2abf6604b9d1e6013057195df836b8a9d631"
- integrity sha512-k55yxKHwaXnpYGsOzg4Vl8+tDrWylxDEpknGjhTiZB8dFRU5rTo9CAzeycivxV3s+zlTKwrs6WxMxR95n26kwg==
- dependencies:
- escape-string-regexp "^1.0.2"
-
-strnum@^1.0.4:
- version "1.0.5"
- resolved "https://registry.yarnpkg.com/strnum/-/strnum-1.0.5.tgz#5c4e829fe15ad4ff0d20c3db5ac97b73c9b072db"
- integrity sha512-J8bbNyKKXl5qYcR36TIO8W3mVGVHrmmxsd5PAItGkmyzwJvybiw2IVq5nqd0i4LSNSkB/sx9VHllbfFdr9k1JA==
-
-stylehacks@^4.0.0:
- version "4.0.3"
- resolved "https://registry.yarnpkg.com/stylehacks/-/stylehacks-4.0.3.tgz#6718fcaf4d1e07d8a1318690881e8d96726a71d5"
- integrity sha512-7GlLk9JwlElY4Y6a/rmbH2MhVlTyVmiJd1PfTCqFaIBEGMYNsrO/v3SeGTdhBThLg4Z+NbOk/qFMwCa+J+3p/g==
- dependencies:
- browserslist "^4.0.0"
- postcss "^7.0.0"
- postcss-selector-parser "^3.0.0"
-
-supports-color@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/supports-color/-/supports-color-2.0.0.tgz#535d045ce6b6363fa40117084629995e9df324c7"
- integrity sha512-KKNVtd6pCYgPIKU4cp2733HWYCpplQhddZLBUryaAHou723x+FRzQ5Df824Fj+IyyuiQTRoub4SnIFfIcrp70g==
-
-supports-color@^5.3.0:
- version "5.5.0"
- resolved "https://registry.yarnpkg.com/supports-color/-/supports-color-5.5.0.tgz#e2e69a44ac8772f78a1ec0b35b689df6530efc8f"
- integrity sha512-QjVjwdXIt408MIiAqCX4oUKsgU2EqAGzs2Ppkm4aQYbjm+ZEWEcW4SfFNTr4uMNZma0ey4f5lgLrkB0aX0QMow==
- dependencies:
- has-flag "^3.0.0"
-
-supports-preserve-symlinks-flag@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/supports-preserve-symlinks-flag/-/supports-preserve-symlinks-flag-1.0.0.tgz#6eda4bd344a3c94aea376d4cc31bc77311039e09"
- integrity sha512-ot0WnXS9fgdkgIcePe6RHNk1WA8+muPa6cSjeR3V8K27q9BB1rTE3R1p7Hv0z1ZyAc8s6Vvv8DIyWf681MAt0w==
-
-svgo@^1.0.0, svgo@^1.3.2:
- version "1.3.2"
- resolved "https://registry.yarnpkg.com/svgo/-/svgo-1.3.2.tgz#b6dc511c063346c9e415b81e43401145b96d4167"
- integrity sha512-yhy/sQYxR5BkC98CY7o31VGsg014AKLEPxdfhora76l36hD9Rdy5NZA/Ocn6yayNPgSamYdtX2rFJdcv07AYVw==
- dependencies:
- chalk "^2.4.1"
- coa "^2.0.2"
- css-select "^2.0.0"
- css-select-base-adapter "^0.1.1"
- css-tree "1.0.0-alpha.37"
- csso "^4.0.2"
- js-yaml "^3.13.1"
- mkdirp "~0.5.1"
- object.values "^1.1.0"
- sax "~1.2.4"
- stable "^0.1.8"
- unquote "~1.1.1"
- util.promisify "~1.0.0"
-
-tar-stream@^1.5.2:
- version "1.6.2"
- resolved "https://registry.yarnpkg.com/tar-stream/-/tar-stream-1.6.2.tgz#8ea55dab37972253d9a9af90fdcd559ae435c555"
- integrity sha512-rzS0heiNf8Xn7/mpdSVVSMAWAoy9bfb1WOTYC78Z0UQKeKa/CWS8FOq0lKGNa8DWKAn9gxjCvMLYc5PGXYlK2A==
- dependencies:
- bl "^1.0.0"
- buffer-alloc "^1.2.0"
- end-of-stream "^1.0.0"
- fs-constants "^1.0.0"
- readable-stream "^2.3.0"
- to-buffer "^1.1.1"
- xtend "^4.0.0"
-
-tcp-port-used@^0.1.2:
- version "0.1.2"
- resolved "https://registry.yarnpkg.com/tcp-port-used/-/tcp-port-used-0.1.2.tgz#9450e8768c83b416fd4d1a6a9449eeccbf496c29"
- integrity sha512-jZI6bc4i0bRpxHprkCzqsi8r8jvaWXghDvFEdjH1yGNfSe3KH1l8TlM+TyEmB42p1XUCrOCbHh/55C6Hszqj6A==
- dependencies:
- debug "0.7.4"
- is2 "0.0.9"
- q "0.9.7"
-
-temp-dir@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/temp-dir/-/temp-dir-1.0.0.tgz#0a7c0ea26d3a39afa7e0ebea9c1fc0bc4daa011d"
- integrity sha512-xZFXEGbG7SNC3itwBzI3RYjq/cEhBkx2hJuKGIUOcEULmkQExXiHat2z/qkISYsuR+IKumhEfKKbV5qXmhICFQ==
-
-tempfile@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/tempfile/-/tempfile-2.0.0.tgz#6b0446856a9b1114d1856ffcbe509cccb0977265"
- integrity sha512-ZOn6nJUgvgC09+doCEF3oB+r3ag7kUvlsXEGX069QRD60p+P3uP7XG9N2/at+EyIRGSN//ZY3LyEotA1YpmjuA==
- dependencies:
- temp-dir "^1.0.0"
- uuid "^3.0.1"
-
-text-table@0.2.0:
- version "0.2.0"
- resolved "https://registry.yarnpkg.com/text-table/-/text-table-0.2.0.tgz#7f5ee823ae805207c00af2df4a84ec3fcfa570b4"
- integrity sha512-N+8UisAXDGk8PFXP4HAzVR9nbfmVJ3zYLAWiTIoqC5v5isinhr+r5uaO8+7r3BMfuNIufIsA7RdpVgacC2cSpw==
-
-through2@^2.0.0:
- version "2.0.5"
- resolved "https://registry.yarnpkg.com/through2/-/through2-2.0.5.tgz#01c1e39eb31d07cb7d03a96a70823260b23132cd"
- integrity sha512-/mrRod8xqpA+IHSLyGCQ2s8SPHiCDEeQJSep1jqLYeEUClOFG2Qsh+4FU6G9VeqpZnGW/Su8LQGc4YKni5rYSQ==
- dependencies:
- readable-stream "~2.3.6"
- xtend "~4.0.1"
-
-through@^2.3.6, through@^2.3.8:
- version "2.3.8"
- resolved "https://registry.yarnpkg.com/through/-/through-2.3.8.tgz#0dd4c9ffaabc357960b1b724115d7e0e86a2e1f5"
- integrity sha512-w89qg7PI8wAdvX60bMDP+bFoD5Dvhm9oLheFp5O4a2QF0cSBGsBX4qZmadPMvVqlLJBBci+WqGGOAPvcDeNSVg==
-
-timed-out@^4.0.0, timed-out@^4.0.1:
- version "4.0.1"
- resolved "https://registry.yarnpkg.com/timed-out/-/timed-out-4.0.1.tgz#f32eacac5a175bea25d7fab565ab3ed8741ef56f"
- integrity sha512-G7r3AhovYtr5YKOWQkta8RKAPb+J9IsO4uVmzjl8AZwfhs8UcUwTiD6gcJYSgOtzyjvQKrKYn41syHbUWMkafA==
-
-timsort@^0.3.0:
- version "0.3.0"
- resolved "https://registry.yarnpkg.com/timsort/-/timsort-0.3.0.tgz#405411a8e7e6339fe64db9a234de11dc31e02bd4"
- integrity sha512-qsdtZH+vMoCARQtyod4imc2nIJwg9Cc7lPRrw9CzF8ZKR0khdr8+2nX80PBhET3tcyTtJDxAffGh2rXH4tyU8A==
-
-tiny-lr@^1.1.1:
- version "1.1.1"
- resolved "https://registry.yarnpkg.com/tiny-lr/-/tiny-lr-1.1.1.tgz#9fa547412f238fedb068ee295af8b682c98b2aab"
- integrity sha512-44yhA3tsaRoMOjQQ+5v5mVdqef+kH6Qze9jTpqtVufgYjYt08zyZAwNwwVBj3i1rJMnR52IxOW0LK0vBzgAkuA==
- dependencies:
- body "^5.1.0"
- debug "^3.1.0"
- faye-websocket "~0.10.0"
- livereload-js "^2.3.0"
- object-assign "^4.1.0"
- qs "^6.4.0"
-
-tmp@^0.0.33:
- version "0.0.33"
- resolved "https://registry.yarnpkg.com/tmp/-/tmp-0.0.33.tgz#6d34335889768d21b2bcda0aa277ced3b1bfadf9"
- integrity sha512-jRCJlojKnZ3addtTOjdIqoRuPEKBvNXcGYqzO6zWZX8KfKEpnGY5jfggJQ3EjKuu8D4bJRr0y+cYJFmYbImXGw==
- dependencies:
- os-tmpdir "~1.0.2"
-
-to-buffer@^1.1.1:
- version "1.1.1"
- resolved "https://registry.yarnpkg.com/to-buffer/-/to-buffer-1.1.1.tgz#493bd48f62d7c43fcded313a03dcadb2e1213a80"
- integrity sha512-lx9B5iv7msuFYE3dytT+KE5tap+rNYw+K4jVkb9R/asAb+pbBSM17jtunHplhBe6RRJdZx3Pn2Jph24O32mOVg==
-
-to-fast-properties@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/to-fast-properties/-/to-fast-properties-2.0.0.tgz#dc5e698cbd079265bc73e0377681a4e4e83f616e"
- integrity sha512-/OaKK0xYrs3DmxRYqL/yDc+FxFUVYhDlXMhRmv3z915w2HF1tnN1omB354j8VUGO/hbRzyD6Y3sA7v7GS/ceog==
-
-to-object-path@^0.3.0:
- version "0.3.0"
- resolved "https://registry.yarnpkg.com/to-object-path/-/to-object-path-0.3.0.tgz#297588b7b0e7e0ac08e04e672f85c1f4999e17af"
- integrity sha512-9mWHdnGRuh3onocaHzukyvCZhzvr6tiflAy/JRFXcJX0TjgfWA9pk9t8CMbzmBE4Jfw58pXbkngtBtqYxzNEyg==
- dependencies:
- kind-of "^3.0.2"
-
-to-regex-range@^2.1.0:
- version "2.1.1"
- resolved "https://registry.yarnpkg.com/to-regex-range/-/to-regex-range-2.1.1.tgz#7c80c17b9dfebe599e27367e0d4dd5590141db38"
- integrity sha512-ZZWNfCjUokXXDGXFpZehJIkZqq91BcULFq/Pi7M5i4JnxXdhMKAK682z8bCW3o8Hj1wuuzoKcW3DfVzaP6VuNg==
- dependencies:
- is-number "^3.0.0"
- repeat-string "^1.6.1"
-
-to-regex-range@^5.0.1:
- version "5.0.1"
- resolved "https://registry.yarnpkg.com/to-regex-range/-/to-regex-range-5.0.1.tgz#1648c44aae7c8d988a326018ed72f5b4dd0392e4"
- integrity sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==
- dependencies:
- is-number "^7.0.0"
-
-to-regex@^3.0.1, to-regex@^3.0.2:
- version "3.0.2"
- resolved "https://registry.yarnpkg.com/to-regex/-/to-regex-3.0.2.tgz#13cfdd9b336552f30b51f33a8ae1b42a7a7599ce"
- integrity sha512-FWtleNAtZ/Ki2qtqej2CXTOayOH9bHDQF+Q48VpWyDXjbYxA4Yz8iDB31zXOBUlOHHKidDbqGVrTUvQMPmBGBw==
- dependencies:
- define-property "^2.0.2"
- extend-shallow "^3.0.2"
- regex-not "^1.0.2"
- safe-regex "^1.1.0"
-
-toidentifier@1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/toidentifier/-/toidentifier-1.0.1.tgz#3be34321a88a820ed1bd80dfaa33e479fbb8dd35"
- integrity sha512-o5sSPKEkg/DIQNmH43V0/uerLrpzVedkUh8tGNvaeXpfpuwjKenlSox/2O/BTlZUtEe+JG7s5YhEz608PlAHRA==
-
-toml@^2.3.2:
- version "2.3.6"
- resolved "https://registry.yarnpkg.com/toml/-/toml-2.3.6.tgz#25b0866483a9722474895559088b436fd11f861b"
- integrity sha512-gVweAectJU3ebq//Ferr2JUY4WKSDe5N+z0FvjDncLGyHmIDoxgY/2Ie4qfEIDm4IS7OA6Rmdm7pdEEdMcV/xQ==
-
-tough-cookie@~2.5.0:
- version "2.5.0"
- resolved "https://registry.yarnpkg.com/tough-cookie/-/tough-cookie-2.5.0.tgz#cd9fb2a0aa1d5a12b473bd9fb96fa3dcff65ade2"
- integrity sha512-nlLsUzgm1kfLXSXfRZMc1KLAugd4hqJHDTvc2hDIwS3mZAfMEuMbc03SujMF+GEcpaX/qboeycw6iO8JwVv2+g==
- dependencies:
- psl "^1.1.28"
- punycode "^2.1.1"
-
-"traverse@>=0.3.0 <0.4":
- version "0.3.9"
- resolved "https://registry.yarnpkg.com/traverse/-/traverse-0.3.9.tgz#717b8f220cc0bb7b44e40514c22b2e8bbc70d8b9"
- integrity sha512-iawgk0hLP3SxGKDfnDJf8wTz4p2qImnyihM5Hh/sGvQ3K37dPi/w8sRhdNIxYA1TwFwc5mDhIJq+O0RsvXBKdQ==
-
-tree-node-cli@^1.2.5:
- version "1.6.0"
- resolved "https://registry.yarnpkg.com/tree-node-cli/-/tree-node-cli-1.6.0.tgz#15b76fd7381be650746f5ea06bd70049a3448c08"
- integrity sha512-M8um5Lbl76rWU5aC8oOeEhruiCM29lFCKnwpxrwMjpRicHXJx+bb9Cak11G3zYLrMb6Glsrhnn90rHIzDJrjvg==
- dependencies:
- commander "^5.0.0"
- fast-folder-size "1.6.1"
- pretty-bytes "^5.6.0"
-
-trim-newlines@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/trim-newlines/-/trim-newlines-1.0.0.tgz#5887966bb582a4503a41eb524f7d35011815a613"
- integrity sha512-Nm4cF79FhSTzrLKGDMi3I4utBtFv8qKy4sq1enftf2gMdpqI8oVQTAfySkTz5r49giVzDj88SVZXP4CeYQwjaw==
-
-trim-repeated@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/trim-repeated/-/trim-repeated-1.0.0.tgz#e3646a2ea4e891312bf7eace6cfb05380bc01c21"
- integrity sha512-pkonvlKk8/ZuR0D5tLW8ljt5I8kmxp2XKymhepUeOdCEfKpZaktSArkLHZt76OB1ZvO9bssUsDty4SWhLvZpLg==
- dependencies:
- escape-string-regexp "^1.0.2"
-
-truncate-html@^1.0.1:
- version "1.0.4"
- resolved "https://registry.yarnpkg.com/truncate-html/-/truncate-html-1.0.4.tgz#268de7ba2650d697d748f1692a78197a88886e9d"
- integrity sha512-FpDAlPzpJ3jlZiNEahRs584FS3jOSQafgj4cC9DmAYPct6uMZDLY625+eErRd43G35vGDrNq3i7b4aYUQ/Bxqw==
- dependencies:
- "@types/cheerio" "^0.22.8"
- cheerio "0.22.0"
-
-tunnel-agent@^0.6.0:
- version "0.6.0"
- resolved "https://registry.yarnpkg.com/tunnel-agent/-/tunnel-agent-0.6.0.tgz#27a5dea06b36b04a0a9966774b290868f0fc40fd"
- integrity sha512-McnNiV1l8RYeY8tBgEpuodCC1mLUdbSN+CYBL7kJsJNInOP8UjDDEwdk6Mw60vdLLrr5NHKZhMAOSrR2NZuQ+w==
- dependencies:
- safe-buffer "^5.0.1"
-
-tweetnacl@^0.14.3, tweetnacl@~0.14.0:
- version "0.14.5"
- resolved "https://registry.yarnpkg.com/tweetnacl/-/tweetnacl-0.14.5.tgz#5ae68177f192d4456269d108afa93ff8743f4f64"
- integrity sha512-KXXFFdAbFXY4geFIwoyNK+f5Z1b7swfXABfL7HXCmoIWMKU3dmS26672A4EeQtDzLKy7SXmfBu51JolvEKwtGA==
-
-type-is@~1.6.18:
- version "1.6.18"
- resolved "https://registry.yarnpkg.com/type-is/-/type-is-1.6.18.tgz#4e552cd05df09467dcbc4ef739de89f2cf37c131"
- integrity sha512-TkRKr9sUTxEH8MdfuCSP7VizJyzRNMjj2J2do2Jr3Kym598JVdEksuzPQCnlFPW4ky9Q+iA+ma9BGm06XQBy8g==
- dependencies:
- media-typer "0.3.0"
- mime-types "~2.1.24"
-
-typedarray@^0.0.6:
- version "0.0.6"
- resolved "https://registry.yarnpkg.com/typedarray/-/typedarray-0.0.6.tgz#867ac74e3864187b1d3d47d996a78ec5c8830777"
- integrity sha512-/aCDEGatGvZ2BIk+HmLf4ifCJFwvKFNb9/JeZPMulfgFracn9QFcAf5GO8B/mweUjSoblS5In0cWhqpfs/5PQA==
-
-unbox-primitive@^1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/unbox-primitive/-/unbox-primitive-1.0.2.tgz#29032021057d5e6cdbd08c5129c226dff8ed6f9e"
- integrity sha512-61pPlCD9h51VoreyJ0BReideM3MDKMKnh6+V9L08331ipq6Q8OFXZYiqP6n/tbHx4s5I9uRhcye6BrbkizkBDw==
- dependencies:
- call-bind "^1.0.2"
- has-bigints "^1.0.2"
- has-symbols "^1.0.3"
- which-boxed-primitive "^1.0.2"
-
-unbzip2-stream@^1.0.9:
- version "1.4.3"
- resolved "https://registry.yarnpkg.com/unbzip2-stream/-/unbzip2-stream-1.4.3.tgz#b0da04c4371311df771cdc215e87f2130991ace7"
- integrity sha512-mlExGW4w71ebDJviH16lQLtZS32VKqsSfk80GCfUlwT/4/hNRFsoscrF/c++9xinkMzECL1uL9DDwXqFWkruPg==
- dependencies:
- buffer "^5.2.1"
- through "^2.3.8"
-
-underscore@^1.7.0:
- version "1.13.6"
- resolved "https://registry.yarnpkg.com/underscore/-/underscore-1.13.6.tgz#04786a1f589dc6c09f761fc5f45b89e935136441"
- integrity sha512-+A5Sja4HP1M08MaXya7p5LvjuM7K6q/2EaC0+iovj/wOcMsTzMvDFbasi/oSapiwOlt252IqsKqPjCl7huKS0A==
-
-unicode-canonical-property-names-ecmascript@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/unicode-canonical-property-names-ecmascript/-/unicode-canonical-property-names-ecmascript-2.0.0.tgz#301acdc525631670d39f6146e0e77ff6bbdebddc"
- integrity sha512-yY5PpDlfVIU5+y/BSCxAJRBIS1Zc2dDG3Ujq+sR0U+JjUevW2JhocOF+soROYDSaAezOzOKuyyixhD6mBknSmQ==
-
-unicode-match-property-ecmascript@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/unicode-match-property-ecmascript/-/unicode-match-property-ecmascript-2.0.0.tgz#54fd16e0ecb167cf04cf1f756bdcc92eba7976c3"
- integrity sha512-5kaZCrbp5mmbz5ulBkDkbY0SsPOjKqVS35VpL9ulMPfSl0J0Xsm+9Evphv9CoIZFwre7aJoa94AY6seMKGVN5Q==
- dependencies:
- unicode-canonical-property-names-ecmascript "^2.0.0"
- unicode-property-aliases-ecmascript "^2.0.0"
-
-unicode-match-property-value-ecmascript@^2.1.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/unicode-match-property-value-ecmascript/-/unicode-match-property-value-ecmascript-2.1.0.tgz#cb5fffdcd16a05124f5a4b0bf7c3770208acbbe0"
- integrity sha512-qxkjQt6qjg/mYscYMC0XKRn3Rh0wFPlfxB0xkt9CfyTvpX1Ra0+rAmdX2QyAobptSEvuy4RtpPRui6XkV+8wjA==
-
-unicode-property-aliases-ecmascript@^2.0.0:
- version "2.1.0"
- resolved "https://registry.yarnpkg.com/unicode-property-aliases-ecmascript/-/unicode-property-aliases-ecmascript-2.1.0.tgz#43d41e3be698bd493ef911077c9b131f827e8ccd"
- integrity sha512-6t3foTQI9qne+OZoVQB/8x8rk2k1eVy1gRXhV3oFQ5T6R1dqQ1xtin3XqSlx3+ATBkliTaR/hHyJBm+LVPNM8w==
-
-union-value@^1.0.0:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/union-value/-/union-value-1.0.1.tgz#0b6fe7b835aecda61c6ea4d4f02c14221e109847"
- integrity sha512-tJfXmxMeWYnczCVs7XAEvIV7ieppALdyepWMkHkwciRpZraG/xwT+s2JN8+pr1+8jCRf80FFzvr+MpQeeoF4Xg==
- dependencies:
- arr-union "^3.1.0"
- get-value "^2.0.6"
- is-extendable "^0.1.1"
- set-value "^2.0.1"
-
-uniq@^1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/uniq/-/uniq-1.0.1.tgz#b31c5ae8254844a3a8281541ce2b04b865a734ff"
- integrity sha512-Gw+zz50YNKPDKXs+9d+aKAjVwpjNwqzvNpLigIruT4HA9lMZNdMqs9x07kKHB/L9WRzqp4+DlTU5s4wG2esdoA==
-
-uniqs@^2.0.0:
- version "2.0.0"
- resolved "https://registry.yarnpkg.com/uniqs/-/uniqs-2.0.0.tgz#ffede4b36b25290696e6e165d4a59edb998e6b02"
- integrity sha512-mZdDpf3vBV5Efh29kMw5tXoup/buMgxLzOt/XKFKcVmi+15ManNQWr6HfZ2aiZTYlYixbdNJ0KFmIZIv52tHSQ==
-
-universalify@^0.1.0:
- version "0.1.2"
- resolved "https://registry.yarnpkg.com/universalify/-/universalify-0.1.2.tgz#b646f69be3942dabcecc9d6639c80dc105efaa66"
- integrity sha512-rBJeI5CXAlmy1pV+617WB9J63U6XcazHHF2f2dbJix4XzpUF0RS3Zbj0FGIOCAva5P/d/GBOYaACQ1w+0azUkg==
-
-unpipe@1.0.0, unpipe@~1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/unpipe/-/unpipe-1.0.0.tgz#b2bf4ee8514aae6165b4817829d21b2ef49904ec"
- integrity sha512-pjy2bYhSsufwWlKwPc+l3cN7+wuJlK6uz0YdJEOlQDbl6jo/YlPi4mb8agUkVC8BF7V8NuzeyPNqRksA3hztKQ==
-
-unquote@~1.1.1:
- version "1.1.1"
- resolved "https://registry.yarnpkg.com/unquote/-/unquote-1.1.1.tgz#8fded7324ec6e88a0ff8b905e7c098cdc086d544"
- integrity sha512-vRCqFv6UhXpWxZPyGDh/F3ZpNv8/qo7w6iufLpQg9aKnQ71qM4B5KiI7Mia9COcjEhrO9LueHpMYjYzsWH3OIg==
-
-unset-value@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/unset-value/-/unset-value-1.0.0.tgz#8376873f7d2335179ffb1e6fc3a8ed0dfc8ab559"
- integrity sha512-PcA2tsuGSF9cnySLHTLSh2qrQiJ70mn+r+Glzxv2TWZblxsxCC52BDlZoPCsz7STd9pN7EZetkWZBAvk4cgZdQ==
- dependencies:
- has-value "^0.3.1"
- isobject "^3.0.0"
-
-unzipper@^0.10.11:
- version "0.10.11"
- resolved "https://registry.yarnpkg.com/unzipper/-/unzipper-0.10.11.tgz#0b4991446472cbdb92ee7403909f26c2419c782e"
- integrity sha512-+BrAq2oFqWod5IESRjL3S8baohbevGcVA+teAIOYWM3pDVdseogqbzhhvvmiyQrUNKFUnDMtELW3X8ykbyDCJw==
- dependencies:
- big-integer "^1.6.17"
- binary "~0.3.0"
- bluebird "~3.4.1"
- buffer-indexof-polyfill "~1.0.0"
- duplexer2 "~0.1.4"
- fstream "^1.0.12"
- graceful-fs "^4.2.2"
- listenercount "~1.0.1"
- readable-stream "~2.3.6"
- setimmediate "~1.0.4"
-
-update-browserslist-db@^1.0.9:
- version "1.0.10"
- resolved "https://registry.yarnpkg.com/update-browserslist-db/-/update-browserslist-db-1.0.10.tgz#0f54b876545726f17d00cd9a2561e6dade943ff3"
- integrity sha512-OztqDenkfFkbSG+tRxBeAnCVPckDBcvibKd35yDONx6OU8N7sqgwc7rCbkJ/WcYtVRZ4ba68d6byhC21GFh7sQ==
- dependencies:
- escalade "^3.1.1"
- picocolors "^1.0.0"
-
-uri-js@^4.2.2:
- version "4.4.1"
- resolved "https://registry.yarnpkg.com/uri-js/-/uri-js-4.4.1.tgz#9b1a52595225859e55f669d928f88c6c57f2a77e"
- integrity sha512-7rKUyy33Q1yc98pQ1DAmLtwX109F7TIfWlW1Ydo8Wl1ii1SeHieeh0HHfPeL2fMXK6z0s8ecKs9frCuLJvndBg==
- dependencies:
- punycode "^2.1.0"
-
-urix@^0.1.0:
- version "0.1.0"
- resolved "https://registry.yarnpkg.com/urix/-/urix-0.1.0.tgz#da937f7a62e21fec1fd18d49b35c2935067a6c72"
- integrity sha512-Am1ousAhSLBeB9cG/7k7r2R0zj50uDRlZHPGbazid5s9rlF1F/QKYObEKSIunSjIOkJZqwRRLpvewjEkM7pSqg==
-
-url-join@^1.1.0:
- version "1.1.0"
- resolved "https://registry.yarnpkg.com/url-join/-/url-join-1.1.0.tgz#741c6c2f4596c4830d6718460920d0c92202dc78"
- integrity sha512-zz1wZk4Lb5PTVwZ3HWDmm8XnlPvmOof6/fjdDPA5yBrUcbtV64U6bV832Zf1BtU2WkBBWaUT46wCs+l0HP5nhg==
-
-url-parse-lax@^1.0.0:
- version "1.0.0"
- resolved "https://registry.yarnpkg.com/url-parse-lax/-/url-parse-lax-1.0.0.tgz#7af8f303645e9bd79a272e7a14ac68bc0609da73"
- integrity sha512-BVA4lR5PIviy2PMseNd2jbFQ+jwSwQGdJejf5ctd1rEXt0Ypd7yanUK9+lYechVlN5VaTJGsu2U/3MDDu6KgBA==
- dependencies:
- prepend-http "^1.0.1"
-
-url-parse-lax@^3.0.0:
- version "3.0.0"
- resolved "https://registry.yarnpkg.com/url-parse-lax/-/url-parse-lax-3.0.0.tgz#16b5cafc07dbe3676c1b1999177823d6503acb0c"
- integrity sha512-NjFKA0DidqPa5ciFcSrXnAltTtzz84ogy+NebPvfEgAck0+TNg4UJ4IN+fB7zRZfbgUf0syOo9MDxFkDSMuFaQ==
- dependencies:
- prepend-http "^2.0.0"
-
-url-parse@^1.1.8, url-parse@^1.4.3:
- version "1.5.10"
- resolved "https://registry.yarnpkg.com/url-parse/-/url-parse-1.5.10.tgz#9d3c2f736c1d75dd3bd2be507dcc111f1e2ea9c1"
- integrity sha512-WypcfiRhfeUP9vvF0j6rw0J3hrWrw6iZv3+22h6iRMJ/8z1Tj6XfLP4DsUix5MhMPnXpiHDoKyoZ/bdCkwBCiQ==
- dependencies:
- querystringify "^2.1.1"
- requires-port "^1.0.0"
-
-url-to-options@^1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/url-to-options/-/url-to-options-1.0.1.tgz#1505a03a289a48cbd7a434efbaeec5055f5633a9"
- integrity sha512-0kQLIzG4fdk/G5NONku64rSH/x32NOA39LVQqlK8Le6lvTF6GGRJpqaQFGgU+CLwySIqBSMdwYM0sYcW9f6P4A==
-
-use@^3.1.0:
- version "3.1.1"
- resolved "https://registry.yarnpkg.com/use/-/use-3.1.1.tgz#d50c8cac79a19fbc20f2911f56eb973f4e10070f"
- integrity sha512-cwESVXlO3url9YWlFW/TA9cshCEhtu7IKJ/p5soJ/gGpj7vbvFrAY/eIioQ6Dw23KjZhYgiIo8HOs1nQ2vr/oQ==
-
-util-deprecate@^1.0.1, util-deprecate@^1.0.2, util-deprecate@~1.0.1:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/util-deprecate/-/util-deprecate-1.0.2.tgz#450d4dc9fa70de732762fbd2d4a28981419a0ccf"
- integrity sha512-EPD5q1uXyFxJpCrLnCc1nHnq3gOa6DZBocAIiI2TaSCA7VCJ1UJDMagCzIkXNsUYfD1daK//LTEQ8xiIbrHtcw==
-
-util.promisify@~1.0.0:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/util.promisify/-/util.promisify-1.0.1.tgz#6baf7774b80eeb0f7520d8b81d07982a59abbaee"
- integrity sha512-g9JpC/3He3bm38zsLupWryXHoEcS22YHthuPQSJdMy6KNrzIRzWqcsHzD/WUnqe45whVou4VIsPew37DoXWNrA==
- dependencies:
- define-properties "^1.1.3"
- es-abstract "^1.17.2"
- has-symbols "^1.0.1"
- object.getownpropertydescriptors "^2.1.0"
-
-utils-merge@1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/utils-merge/-/utils-merge-1.0.1.tgz#9f95710f50a267947b2ccc124741c1028427e713"
- integrity sha512-pMZTvIkT1d+TFGvDOqodOclx0QWkkgi6Tdoa8gC8ffGAAqz9pzPTZWAybbsHHoED/ztMtkv/VoYTYyShUn81hA==
-
-uuid@^3.0.1, uuid@^3.3.2:
- version "3.4.0"
- resolved "https://registry.yarnpkg.com/uuid/-/uuid-3.4.0.tgz#b23e4358afa8a202fe7a100af1f5f883f02007ee"
- integrity sha512-HjSDRw6gZE5JMggctHBcjVak08+KEVhSIiDzFnT9S9aegmp85S/bReBVTb4QTFaRNptJ9kuYaNhnbNEOkbKb/A==
-
-validate-npm-package-license@^3.0.1:
- version "3.0.4"
- resolved "https://registry.yarnpkg.com/validate-npm-package-license/-/validate-npm-package-license-3.0.4.tgz#fc91f6b9c7ba15c857f4cb2c5defeec39d4f410a"
- integrity sha512-DpKm2Ui/xN7/HQKCtpZxoRWBhZ9Z0kqtygG8XCgNQ8ZlDnxuQmWhj566j8fN4Cu3/JmbhsDo7fcAJq4s9h27Ew==
- dependencies:
- spdx-correct "^3.0.0"
- spdx-expression-parse "^3.0.0"
-
-vary@~1.1.2:
- version "1.1.2"
- resolved "https://registry.yarnpkg.com/vary/-/vary-1.1.2.tgz#2299f02c6ded30d4a5961b0b9f74524a18f634fc"
- integrity sha512-BNGbWLfd0eUPabhkXUVm0j8uuvREyTh5ovRa/dyow/BqAbZJyC+5fU+IzQOzmAKzYqYRAISoRhdQr3eIZ/PXqg==
-
-vendors@^1.0.0:
- version "1.0.4"
- resolved "https://registry.yarnpkg.com/vendors/-/vendors-1.0.4.tgz#e2b800a53e7a29b93506c3cf41100d16c4c4ad8e"
- integrity sha512-/juG65kTL4Cy2su4P8HjtkTxk6VmJDiOPBufWniqQ6wknac6jNiXS9vU+hO3wgusiyqWlzTbVHi0dyJqRONg3w==
-
-verror@1.10.0:
- version "1.10.0"
- resolved "https://registry.yarnpkg.com/verror/-/verror-1.10.0.tgz#3a105ca17053af55d6e270c1f8288682e18da400"
- integrity sha512-ZZKSmDAEFOijERBLkmYfJ+vmk3w+7hOLYDNkRCuRuMJGEmqYNCNLyBBFwWKVMhfwaEF3WOd0Zlw86U/WC/+nYw==
- dependencies:
- assert-plus "^1.0.0"
- core-util-is "1.0.2"
- extsprintf "^1.2.0"
-
-websocket-driver@>=0.5.1:
- version "0.7.4"
- resolved "https://registry.yarnpkg.com/websocket-driver/-/websocket-driver-0.7.4.tgz#89ad5295bbf64b480abcba31e4953aca706f5760"
- integrity sha512-b17KeDIQVjvb0ssuSDF2cYXSg2iztliJ4B9WdsuB6J952qCPKmnVq4DyW5motImXHDC1cBT/1UezrJVsKw5zjg==
- dependencies:
- http-parser-js ">=0.5.1"
- safe-buffer ">=5.1.0"
- websocket-extensions ">=0.1.1"
-
-websocket-extensions@>=0.1.1:
- version "0.1.4"
- resolved "https://registry.yarnpkg.com/websocket-extensions/-/websocket-extensions-0.1.4.tgz#7f8473bc839dfd87608adb95d7eb075211578a42"
- integrity sha512-OqedPIGOfsDlo31UNwYbCFMSaO9m9G/0faIHj5/dZFDMFqPTcx6UwqyOy3COEaEOg/9VsGIpdqn62W5KhoKSpg==
-
-which-boxed-primitive@^1.0.2:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/which-boxed-primitive/-/which-boxed-primitive-1.0.2.tgz#13757bc89b209b049fe5d86430e21cf40a89a8e6"
- integrity sha512-bwZdv0AKLpplFY2KZRX6TvyuN7ojjr7lwkg6ml0roIy9YeuSr7JS372qlNW18UQYzgYK9ziGcerWqZOmEn9VNg==
- dependencies:
- is-bigint "^1.0.1"
- is-boolean-object "^1.1.0"
- is-number-object "^1.0.4"
- is-string "^1.0.5"
- is-symbol "^1.0.3"
-
-which@^1.2.14, which@^1.2.9:
- version "1.3.1"
- resolved "https://registry.yarnpkg.com/which/-/which-1.3.1.tgz#a45043d54f5805316da8d62f9f50918d3da70b0a"
- integrity sha512-HxJdYWq1MTIQbJ3nw0cqssHoTNU267KlrDuGZ1WYlxDStUtKUhOaJmh112/TZmHxxUfuJqPXSOm7tDyas0OSIQ==
- dependencies:
- isexe "^2.0.0"
-
-wordwrap@0.0.2:
- version "0.0.2"
- resolved "https://registry.yarnpkg.com/wordwrap/-/wordwrap-0.0.2.tgz#b79669bb42ecb409f83d583cad52ca17eaa1643f"
- integrity sha512-xSBsCeh+g+dinoBv3GAOWM4LcVVO68wLXRanibtBSdUvkGWQRGeE9P7IwU9EmDDi4jA6L44lz15CGMwdw9N5+Q==
-
-wrappy@1:
- version "1.0.2"
- resolved "https://registry.yarnpkg.com/wrappy/-/wrappy-1.0.2.tgz#b5243d8f3ec1aa35f1364605bc0d1036e30ab69f"
- integrity sha512-l4Sp/DRseor9wL6EvV2+TuQn63dMkPjZ/sp9XkghTEbV9KlPS1xUsZ3u7/IQO4wxtcFB4bgpQPRcR3QCvezPcQ==
-
-xml@^1.0.1:
- version "1.0.1"
- resolved "https://registry.yarnpkg.com/xml/-/xml-1.0.1.tgz#78ba72020029c5bc87b8a81a3cfcd74b4a2fc1e5"
- integrity sha512-huCv9IH9Tcf95zuYCsQraZtWnJvBtLVE0QHMOs8bWyZAFZNDcYjsPq1nEx8jKA9y+Beo9v+7OBPRisQTjinQMw==
-
-xtend@^4.0.0, xtend@~4.0.1:
- version "4.0.2"
- resolved "https://registry.yarnpkg.com/xtend/-/xtend-4.0.2.tgz#bb72779f5fa465186b1f438f674fa347fdb5db54"
- integrity sha512-LKYU1iAXJXUgAXn9URjiu+MWhyUXHsvfp7mcuYm9dSUKK0/CjtrUwFAxD82/mCWbtLsGjFIad0wIsod4zrTAEQ==
-
-yallist@^2.1.2:
- version "2.1.2"
- resolved "https://registry.yarnpkg.com/yallist/-/yallist-2.1.2.tgz#1c11f9218f076089a47dd512f93c6699a6a81d52"
- integrity sha512-ncTzHV7NvsQZkYe1DW7cbDLm0YpzHmZF5r/iyP3ZnQtMiJ+pjzisCiMNI+Sj+xQF5pXhSHxSB3uDbsBTzY/c2A==
-
-yamljs@^0.2.1:
- version "0.2.10"
- resolved "https://registry.yarnpkg.com/yamljs/-/yamljs-0.2.10.tgz#481cc7c25ca73af59f591f0c96e3ce56c757a40f"
- integrity sha512-sbkbOosewjeRmJ23Hjee1RgTxn+xa7mt4sew3tfD0SdH0LTcswnZC9dhSNq4PIz15roQMzb84DjECyQo5DWIww==
- dependencies:
- argparse "^1.0.7"
- glob "^7.0.5"
-
-yargs@^2.3.0:
- version "2.3.0"
- resolved "https://registry.yarnpkg.com/yargs/-/yargs-2.3.0.tgz#e900c87250ec5cd080db6009fe3dd63156f1d7fb"
- integrity sha512-w48USdbTdaVMcE3CnXsEtSY9zYSN7dTyVnLBgrJF2quA5rLwobC9zixxfexereLGFaxjxtR3oWdydC0qoayakw==
- dependencies:
- wordwrap "0.0.2"
-
-yauzl@^2.4.2:
- version "2.10.0"
- resolved "https://registry.yarnpkg.com/yauzl/-/yauzl-2.10.0.tgz#c7eb17c93e112cb1086fa6d8e51fb0667b79a5f9"
- integrity sha512-p4a9I6X6nu6IhoGmBqAcbJy1mlC4j27vEPZX9F4L4/vZT3Lyq1VkFHw/V/PUcB9Buo+DG3iHkT0x3Qya58zc3g==
- dependencies:
- buffer-crc32 "~0.2.3"
- fd-slicer "~1.1.0"
diff --git a/yivi-docs/.gitignore b/yivi-docs/.gitignore
new file mode 100644
index 0000000..b2d6de3
--- /dev/null
+++ b/yivi-docs/.gitignore
@@ -0,0 +1,20 @@
+# Dependencies
+/node_modules
+
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
diff --git a/yivi-docs/README.md b/yivi-docs/README.md
new file mode 100644
index 0000000..0c6c2c2
--- /dev/null
+++ b/yivi-docs/README.md
@@ -0,0 +1,41 @@
+# Website
+
+This website is built using [Docusaurus](https://docusaurus.io/), a modern static website generator.
+
+### Installation
+
+```
+$ yarn
+```
+
+### Local Development
+
+```
+$ yarn start
+```
+
+This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
+
+### Build
+
+```
+$ yarn build
+```
+
+This command generates static content into the `build` directory and can be served using any static contents hosting service.
+
+### Deployment
+
+Using SSH:
+
+```
+$ USE_SSH=true yarn deploy
+```
+
+Not using SSH:
+
+```
+$ GIT_USER= yarn deploy
+```
+
+If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.
diff --git a/yivi-docs/blog/2024-11-21-welcome/index.md b/yivi-docs/blog/2024-11-21-welcome/index.md
new file mode 100644
index 0000000..e43973b
--- /dev/null
+++ b/yivi-docs/blog/2024-11-21-welcome/index.md
@@ -0,0 +1,66 @@
+---
+slug: vision, roadmap
+title: Caesar Groep to continue development of Yivi - Our roadmap
+authors: [dibranmulder]
+tags: [yivi, vision, roadmap]
+---
+
+We are excited to announce that Caesar Groep will be continuing the development of Yivi. Yivi is the most privacy friendly ID-Wallet that empowers users with privacy-first, secure, and user-friendly solutions. Our mission is to build upon the excellent foundation already laid and innovate further to ensure Yivi remains at the forefront of digital identity technology.
+
+
+
+Here’s what you can expect as we embark on this journey together:
+
+## Short-Term Roadmap: Laying a Solid Foundation
+We are focusing on key actions to ensure a seamless transition from SIDN to Caesar Groep with focus on operational stability.
+
+### Ownership and Migration of Accounts
+We are securing ownership of all critical accounts such as GitHub, App Stores, Firebase, Sentry, and others. Migrating these systems is complex, but we’re making steady progress.
+
+### Secure cloud hosting
+A new landing zone(hosting environment) is being created on the Scaleway cloud. Kubernetes is our technology off choice, we will enhance security by integrating a robust secret manager and standardize on DNS zones. Scaleways offers hosting in Amsterdam, Paris as well as Warschaw, we will start off in Amsterdam but we will be ready to expand to other regions. We chose Scaleway because we value European sovereignty and condemn the privacy mentality of big-tech companies.
+
+### Migrating SIDN Issuers
+The migration of SIDN issuers is underway, on our staging environment we already have the SMS and Email issuers up and running, we still have to migrate the SAML issuer for social media and educational account issuance. You can test our staging scheme using:
+- https://schemes.staging.yivi.app/pbdf-staging/description.xml
+- https://emailissuer.staging.yivi.app/en/
+- https://sms-issuer.staging.yivi.app/en/
+
+### YiviConnect Migration
+Yivi connect is the trusted SaaS offering of Yivi. Brokers like Signicat offer Yivi plug and play support with the use of Yivi Connect. We want migrate the Yivi Connect hosting to our Scaleway landing some ensuring an uninterrupted service.
+
+### Mobile App Update
+We already updated Flutter and our dependencies to the latest versions. We fixed the broken integration tests for iOS and will continue to improve the app. Our team already addressed some small UI issues and will continue to push on usability. Feel free to report any issues you might have with the Mobile App [here](https://github.com/privacybydesign/irmamobile/issues).
+
+### Keyshare Server Migration
+The migration of the Keyshare server is also on our immediate agenda. We are still debating our migration strategy since it also requires state to move from SIDN to Scaleway. Once we have our final migration strategy we will publish it on this blog.
+
+## Long-Term Roadmap: Innovating and Expanding Yivi’s Potential
+As we look to the future, our focus remains on driving innovation, enhancing usability, and ensuring Yivi plays a pivotal role in the evolving landscape of digital identity. Here’s how we plan to achieve this:
+
+### Pretty Verifier Implementation
+To ensure Yivi’s long-term viability and fairness in the ecosystem, we are requiring Pretty Verifiers. This initiative balances free access for individuals while enabling a sustainable business model. Here's how it works:
+
+- Initially, we will issue warnings to non-verified relying parties and verifiers, creating awareness of upcoming changes. Subsequently after a period of time we will require
+- Protection for Citizens: By verifying verifiers, we protect users from misuse and ensure secure and compliant data exchanges.
+- Fair cost distribution: This system helps offset the downstream costs borne by issuers and the wallet fostering a sustainable ecosystem.
+
+### Embracing EUDI-Wallet Standards
+The European digital identity landscape is evolving at a rapid pace, and Yivi has consistently been a pioneer in ID wallets within the Netherlands. We believe that Idemix and Zero-Knowledge Proofs (ZKPs) represent the ideal technologies for this space. However, these technologies were unfortunately not included in the Architectural Reference Framework developed by the eIDAS Expert Group.
+
+Discussions around BBS+ have stagnated, prompting us to explore alternative solutions. Yivi will transition from Idemix to ECDSA or another privacy-preserving cryptographic protocol. Innovation remains at the core of our mission, as we collaborate with Radboud University on initiatives like Post-Quantum Cryptography. Additionally, adopting community standards such as OpenID4VP and OpenID4VCI is a top priority to ensure interoperability and alignment with the broader ecosystem.
+
+### User Experience
+User experience is the cornerstone of Yivi's mission to provide the most user-friendly ID wallet on the market. Our commitment to continuous improvement ensures that managing your digital identity is as seamless and intuitive as possible:
+
+- Enhanced Attribute Management: Simplify navigation with features like categorization and customizable attribute reordering, putting control and clarity in the hands of our users.
+- Brand Extensions: Enable organizations to seamlessly embed their branding and visual identity within Yivi, delivering a tailored and cohesive experience for their users.
+
+By prioritizing user experience, we aim to make Yivi an indispensable tool for digital identity management.
+
+## Our Commitment
+Caesar Groep is committed to ensuring Yivi’s continued success as a trusted digital identity platform. With a clear short-term plan and a vision for the future, we aim to make Yivi indispensable for individuals, businesses, and governments.
+
+Stay tuned for more updates as we roll out these changes and work together to shape the future of digital identity.
+
+Let’s build a more secure and private digital world with Yivi!
\ No newline at end of file
diff --git a/yivi-docs/blog/authors.yml b/yivi-docs/blog/authors.yml
new file mode 100644
index 0000000..54b87c9
--- /dev/null
+++ b/yivi-docs/blog/authors.yml
@@ -0,0 +1,10 @@
+dibranmulder:
+ name: Dibran Mulder
+ title: CTO @ Caesar Groep
+ url: https://github.com/dibranmulder
+ image_url: https://github.com/dibranmulder.png
+ page: true
+ socials:
+ x: dibranmulder
+ github: dibranmulder
+ linkedin: dibranmulder
\ No newline at end of file
diff --git a/yivi-docs/blog/tags.yml b/yivi-docs/blog/tags.yml
new file mode 100644
index 0000000..bfaa778
--- /dev/null
+++ b/yivi-docs/blog/tags.yml
@@ -0,0 +1,19 @@
+facebook:
+ label: Facebook
+ permalink: /facebook
+ description: Facebook tag description
+
+hello:
+ label: Hello
+ permalink: /hello
+ description: Hello tag description
+
+docusaurus:
+ label: Docusaurus
+ permalink: /docusaurus
+ description: Docusaurus tag description
+
+hola:
+ label: Hola
+ permalink: /hola
+ description: Hola tag description
diff --git a/docs/api-go.md b/yivi-docs/docs/api-go.md
similarity index 100%
rename from docs/api-go.md
rename to yivi-docs/docs/api-go.md
diff --git a/docs/api-irma-frontend.md b/yivi-docs/docs/api-irma-frontend.md
similarity index 100%
rename from docs/api-irma-frontend.md
rename to yivi-docs/docs/api-irma-frontend.md
diff --git a/docs/api-irma-server.md b/yivi-docs/docs/api-irma-server.md
similarity index 99%
rename from docs/api-irma-server.md
rename to yivi-docs/docs/api-irma-server.md
index cc4f5cc..384e214 100644
--- a/docs/api-irma-server.md
+++ b/yivi-docs/docs/api-irma-server.md
@@ -15,7 +15,8 @@ The API that this server offers consists of two parts:
---
## API overview
-
+:::toc
+:::
---
@@ -137,7 +138,7 @@ The response may contain the following fields:
* `"UNMATCHED_REQUEST"`: proofs do not correspond to a specified request
* `"MISSING_ATTRIBUTES"`: proofs do not contain all requested attributes
* `"EXPIRED"`: Attributes were expired at creation time
-* `disclosed`: List of [attributes disclosed](https://godoc.org/github.com/privacybydesign/irmago#DisclosedAttribute) by the user. The array structure mirrors that of the [session request](session-requests#disclosure-requests) that started the session: the i-th item of the outer array is a conjunction of attributes satisfying the i-th outer conjunction of the session request. (*Note*: if the session was started with a legacy, pre-[condiscon](condiscon.md) session request, then this array structure has a different legacy structure; see the [legacy documentation](/v0.2.0/api-irma-server#get-session-requestortoken-result))
+* `disclosed`: List of [attributes disclosed](https://godoc.org/github.com/privacybydesign/irmago#DisclosedAttribute) by the user. The array structure mirrors that of the [session request](session-requests#disclosure-requests) that started the session: the i-th item of the outer array is a conjunction of attributes satisfying the i-th outer conjunction of the session request. (*Note*: if the session was started with a legacy, pre-[condiscon](condiscon.md) session request, then this array structure has a different legacy structure; see the [legacy documentation](https://irma.app/docs/v0.2.0/api-irma-server/#get-session-requestortoken-result))
* `signature`: The full attribute-based signature in case of `"signing"` sessions
* `error`: Error message in case of failure
diff --git a/docs/api-irmajs.md b/yivi-docs/docs/api-irmajs.md
similarity index 100%
rename from docs/api-irmajs.md
rename to yivi-docs/docs/api-irmajs.md
diff --git a/docs/api-yivi-frontend.md b/yivi-docs/docs/api-yivi-frontend.md
similarity index 100%
rename from docs/api-yivi-frontend.md
rename to yivi-docs/docs/api-yivi-frontend.md
diff --git a/docs/chained-sessions.md b/yivi-docs/docs/chained-sessions.md
similarity index 89%
rename from docs/chained-sessions.md
rename to yivi-docs/docs/chained-sessions.md
index 1e2058b..531ef80 100644
--- a/docs/chained-sessions.md
+++ b/yivi-docs/docs/chained-sessions.md
@@ -1,12 +1,23 @@
+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.
-
-
-
+
+
+
The IRMA server enables this by sending the session results of the intermediate sessions in the chain to a server chosen by the requestor, which can process the session results and respond with a session request for the next session in the chain.
@@ -123,33 +134,35 @@ func writeError(w http.ResponseWriter, msg string) {
The session chain can then be started by sending the following session request to our IRMA server.
-
-
-```jsonc
-{
- "nextSession": {
- "url": "https://example.com"
- },
- "request": {
- "@context": "https://irma.app/ld/request/disclosure/v2",
- "disclose": [[[ "irma-demo.gemeente.personalData.fullname" ]]]
- }
-}
-```
-
-```go
-irma.ServiceProviderRequest{
- RequestorBaseRequest: irma.RequestorBaseRequest{
- NextSession: &irma.NextSessionData{
- URL: "https://example.com",
+
+
+ ```jsonc
+ {
+ "nextSession": {
+ "url": "https://example.com"
},
- },
- Request: irma.NewDisclosureRequest(
- irma.NewAttributeTypeIdentifier("irma-demo.gemeente.personalData.fullname"),
- ),
-}
-```
-
+ "request": {
+ "@context": "https://irma.app/ld/request/disclosure/v2",
+ "disclose": [[[ "irma-demo.gemeente.personalData.fullname" ]]]
+ }
+ }
+ ```
+
+
+ ```go
+ irma.ServiceProviderRequest{
+ RequestorBaseRequest: irma.RequestorBaseRequest{
+ NextSession: &irma.NextSessionData{
+ URL: "https://example.com",
+ },
+ },
+ Request: irma.NewDisclosureRequest(
+ irma.NewAttributeTypeIdentifier("irma-demo.gemeente.personalData.fullname"),
+ ),
+ }
+ ```
+
+
After the user discloses the `irma-demo.gemeente.personalData.fullname` attribute, the IRMA server POSTs it to `https://example.com`. Our Go server responds to the IRMA server with the `issuanceRequest` found near the end of the program. Next, the IRMA server immediately starts this issuance session with the user's Yivi app, resulting in the screenshots shown on top of this page.
diff --git a/docs/condiscon.md b/yivi-docs/docs/condiscon.md
similarity index 97%
rename from docs/condiscon.md
rename to yivi-docs/docs/condiscon.md
index dd0df79..8d625e8 100644
--- a/docs/condiscon.md
+++ b/yivi-docs/docs/condiscon.md
@@ -2,15 +2,6 @@
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.
- The [`irma` command](irma-cli.md) including [`irma server`](irma-server.md) (`0.3.0` and up supports condiscon).
@@ -24,7 +15,7 @@ An [IRMA disclosure session](what-is-irma.md#session-types) is started by a veri
-
+
```json
{
@@ -51,7 +42,7 @@ An [IRMA disclosure session](what-is-irma.md#session-types) is started by a veri
-
+
```json
{
@@ -179,7 +170,7 @@ The `irma server` of version `0.3.0` and up is:
- Backwards compatible with the old session request format, i.e. with old IRMA requestor applications. New session request JSON objects are recognized as such by the presence of their `@context` property; if this is absent the request is interpreted as a pre-condiscon IRMA session request.
- Backwards compatible with old Yivi apps, as long as the condiscon feature is not used in the session (i.e., all inner conjunctions contain exactly 1 attribute).
- [This `irmago` unit test](https://github.com/privacybydesign/irmago/blob/condiscon/irmago_test.go#L259) shows how pre-condiscon session requests are converted, by asserting equality of pre- and post-condiscon session requests, for all three session types.
-- The documentation of the pre-condiscon session format can be found on the [session requests](/v0.2.0/session-requests) page.
+- The documentation of the pre-condiscon session format can be found on the [session requests](https://irma.app/docs/v0.2.0/session-requests/) page.
The new Yivi app is backwards compatible with the old session request format, i.e. with old `irma server`s, *except* in case of signature sessions (see below).
diff --git a/docs/email.md b/yivi-docs/docs/email.md
similarity index 100%
rename from docs/email.md
rename to yivi-docs/docs/email.md
diff --git a/docs/getting-started.md b/yivi-docs/docs/getting-started.md
similarity index 96%
rename from docs/getting-started.md
rename to yivi-docs/docs/getting-started.md
index 9e5b0f1..b6a8360 100644
--- a/docs/getting-started.md
+++ b/yivi-docs/docs/getting-started.md
@@ -77,7 +77,7 @@ npm run build
```
A webpage demoing IRMA attribute issuance verification should now be available at http://localhost:8088.
-> Open the browser console and the console running `irma server` to see various log messages and possibly error messages as the IRMA session proceeds.
+> **⚠️ Warning:** Open the browser console and the console running `irma server` to see various log messages and possibly error messages as the IRMA session proceeds.
## Example configuration and IRMA session
@@ -103,7 +103,7 @@ requestors:
key: "mysecrettoken"
```
-* You may want to [restrict permissions](irma-server.md/#permissions) to verify or issue specific attributes, globally or per requestor.
+* You may want to [restrict permissions](/irma-server/#permissions) to verify or issue specific attributes, globally or per requestor.
* The server can be made into a daemon on most Linux systems [using a systemd unit file](irma-server.md#running-as-daemon).
* Another common setup is to have a reverse proxy between the IRMA server and the internet, which handles TLS instead and forwards traffic on `https://example.com/irma/` to the IRMA server.
diff --git a/docs/irma-app.md b/yivi-docs/docs/irma-app.md
similarity index 100%
rename from docs/irma-app.md
rename to yivi-docs/docs/irma-app.md
diff --git a/docs/irma-backend.md b/yivi-docs/docs/irma-backend.md
similarity index 100%
rename from docs/irma-backend.md
rename to yivi-docs/docs/irma-backend.md
diff --git a/docs/irma-cli.md b/yivi-docs/docs/irma-cli.md
similarity index 100%
rename from docs/irma-cli.md
rename to yivi-docs/docs/irma-cli.md
diff --git a/docs/irma-frontend.md b/yivi-docs/docs/irma-frontend.md
similarity index 100%
rename from docs/irma-frontend.md
rename to yivi-docs/docs/irma-frontend.md
diff --git a/docs/irma-protocol.md b/yivi-docs/docs/irma-protocol.md
similarity index 99%
rename from docs/irma-protocol.md
rename to yivi-docs/docs/irma-protocol.md
index 376a9a7..add5609 100644
--- a/docs/irma-protocol.md
+++ b/yivi-docs/docs/irma-protocol.md
@@ -42,9 +42,9 @@ Generate these using `java -jar path-to-plantuml.jar -tsvg *.puml` in docs/asset
-![Pairing disabled](/assets/session-no-pairing.svg)
+![Pairing disabled](/img/session-no-pairing.svg)
-![Pairing enabled](/assets/session-pairing.svg)
+![Pairing enabled](/img/session-pairing.svg)
### Further reading
diff --git a/docs/irma-server-lib.md b/yivi-docs/docs/irma-server-lib.md
similarity index 99%
rename from docs/irma-server-lib.md
rename to yivi-docs/docs/irma-server-lib.md
index f9d4e0f..964dc76 100644
--- a/docs/irma-server-lib.md
+++ b/yivi-docs/docs/irma-server-lib.md
@@ -2,7 +2,7 @@
title: irma server library
---
-
+
`irmaserver` is a Go library providing a HTTP server that handles IRMA session with the Yivi app, and functions for starting and managing IRMA sessions.
diff --git a/docs/irma-server.md b/yivi-docs/docs/irma-server.md
similarity index 100%
rename from docs/irma-server.md
rename to yivi-docs/docs/irma-server.md
diff --git a/docs/irmajs.md b/yivi-docs/docs/irmajs.md
similarity index 100%
rename from docs/irmajs.md
rename to yivi-docs/docs/irmajs.md
diff --git a/docs/issuer.md b/yivi-docs/docs/issuer.md
similarity index 95%
rename from docs/issuer.md
rename to yivi-docs/docs/issuer.md
index 8b765fb..38d2a8c 100644
--- a/docs/issuer.md
+++ b/yivi-docs/docs/issuer.md
@@ -13,7 +13,7 @@ In IRMA, information on all issuers, their credentials and the contained attribu
Generally, the process of becoming an IRMA issuer looks as follows. These steps are documented in detail in the sections below.
1. Collect all relevant information on your issuer, its credentials and the contained attributes, and submit that as a pull request (PR) to the [`irma-demo` scheme](https://github.com/privacybydesign/irma-demo-schememanager). (We can help creating the PR based on the relevant information, if required.) Once that is merged, it becomes automatically available for your IRMA server and for Yivi apps. Then you can start issuing the new credentials in your application during development and in demos, using the [IRMA server](irma-server.md). In this phase, you can finetune your credential structure and your issuance application.
-2. When your credential structure has become finalized and you are ready to move to production, [contact us](/about). Once you are verified as the valid issuer of the credentials and the issuer contract has been signed, your issuer information from the `irma-demo` scheme can be copied over to the production scheme, `pbdf` using another PR. At this point you will need to generate your IRMA issuer private/public keypair (more on that [below](#generating-irma-issuer-keys)), and include the public key in the PR. Once your issuer information is included in the `pbdf` scheme, you can start issuing credentials.
+2. When your credential structure has become finalized and you are ready to move to production, [contact us](/). Once you are verified as the valid issuer of the credentials and the issuer contract has been signed, your issuer information from the `irma-demo` scheme can be copied over to the production scheme, `pbdf` using another PR. At this point you will need to generate your IRMA issuer private/public keypair (more on that [below](#generating-irma-issuer-keys)), and include the public key in the PR. Once your issuer information is included in the `pbdf` scheme, you can start issuing credentials.
> Credentials within the `irma-demo` scheme are not meant for production application and actual personal data, since attributes within this scheme cannot be trusted: all private keys of all issuers under the `irma-demo` scheme are included in it, so that anyone can issue any `irma-demo` credential containing any attribute values.
diff --git a/docs/keyshare-protocol.md b/yivi-docs/docs/keyshare-protocol.md
similarity index 96%
rename from docs/keyshare-protocol.md
rename to yivi-docs/docs/keyshare-protocol.md
index cc460a3..0969c4a 100644
--- a/docs/keyshare-protocol.md
+++ b/yivi-docs/docs/keyshare-protocol.md
@@ -2,20 +2,6 @@
title: Keyshare protocol
---
-
-
-
This document describes the goals and details of the IRMA keyshare protocol.
## Introduction
@@ -62,7 +48,7 @@ For these reasons this protocol is very well suited for our aims of making the k
## The protocol
-We now describe the IRMA keyshare protocol. The version of the keyshare protocol documented here is supported by the keyshare server since `v0.11.0` of `irmago`. The previous version of the protocol, which was largely the same but did not use ECDSA for device binding, is documented [here](/v0.9.0/keyshare-protocol). The [Yivi app](yivi-app.md) always uses the latest keyshare protocol version that it knows of, but the keyshare server is backwards compatible: it understands both protocols.
+We now describe the IRMA keyshare protocol. The version of the keyshare protocol documented here is supported by the keyshare server since `v0.11.0` of `irmago`. The previous version of the protocol, which was largely the same but did not use ECDSA for device binding, is documented [here](https://irma.app/docs/v0.9.0/keyshare-protocol/). The [Yivi app](yivi-app.md) always uses the latest keyshare protocol version that it knows of, but the keyshare server is backwards compatible: it understands both protocols.
### Overview
diff --git a/docs/overview.md b/yivi-docs/docs/overview.md
similarity index 100%
rename from docs/overview.md
rename to yivi-docs/docs/overview.md
diff --git a/docs/randomblind.md b/yivi-docs/docs/randomblind.md
similarity index 94%
rename from docs/randomblind.md
rename to yivi-docs/docs/randomblind.md
index ff843a4..b8bc8b7 100644
--- a/docs/randomblind.md
+++ b/yivi-docs/docs/randomblind.md
@@ -2,20 +2,6 @@
title: Randomblind issuance
---
-
-
-
*Randomblind* attributes are a new IRMA feature introduced in
[`irmago` v0.6.0](https://github.com/privacybydesign/irmago/releases/tag/v0.6.0)
that can give the user extra privacy
@@ -88,7 +74,7 @@ representation](https://en.wikipedia.org/wiki/Base62).
Before issuance | After issuance
:----------------------------:|:----------------------------:
-![Permission](assets/rb_permission.jpg) | ![Card](assets/rb_card.jpg)
+![Permission](/img/rb_permission.jpg) | ![Card](/img/rb_card.jpg)
## Cryptography
In this section we will explain in detail how the issuer and the user are able
diff --git a/docs/revocation.md b/yivi-docs/docs/revocation.md
similarity index 97%
rename from docs/revocation.md
rename to yivi-docs/docs/revocation.md
index 5e7b4d3..4e9e420 100644
--- a/docs/revocation.md
+++ b/yivi-docs/docs/revocation.md
@@ -2,20 +2,6 @@
title: Revocation
---
-
-
-
Revocation adds to IRMA issuers the ability to revoke a credential that it previously issued to an [Yivi app](yivi-app.md), when the contained attributes are no longer accurate. This allows IRMA attribute verifiers to establish that the attributes it received are still factual, as otherwise the credential would have been revoked by the issuer.
This page explains in detail how revocation is implemented in IRMA and what it means to requestors and app users, on three levels:
@@ -40,6 +26,7 @@ Computing a nonrevocation proof for a credential is much more expensive than jus
In the papers linked to above (and generally in the scientific literature on revocation), the party that is able to revoke credentials is called the **revocation authority**, which is not necessarily the same as the party that issues credentials. Within IRMA we have decided to endow the issuer with this responsibility, i.e. the issuer is also the revocation authority for revocation-enabled credential types, because conceptually and technically this simplifies many details.
+> **⚠️ Note:**
> In the remainder of this post when we refer to the requestor, issuer, or verifier, we generally refer to the IRMA server software implementing APIs for those parties. The term "IRMA server" itself refers to the following variants of the IRMA server:
> * The [`irma server`](irma-server.md) daemon.
> * The [`irmaserver` Go library](irma-server-lib.md).
@@ -320,30 +307,27 @@ The app includes the accumulator $\nu$ signed by the issuer against which it pro
### Revocation
Henceforth, we label the current accumulator and witnesses with an index $i$, so the current accumulator value is $\nu_i$. If the issuer wants to revoke a credential it first looks up in its database the revocation attribute $\tilde{e}$ that it used for that credential (we use a tilde to distinguish this $\tilde{e}$ from the revocation attributes $e$ of other apps wanting to update their own (nonrevoked) witness, see below). Then it uses its private key to compute the new accumulator value as follows:
- $\displaystyle \nu_{i+1} = \nu_{i}^{1/\tilde{e}\bmod pq}$
+$$
+\nu_{i+1} = \nu_{i}^{1/\tilde{e}\bmod pq}
+$$
The update message consists of $(\nu_{i+1}, \tilde{e})$; the issuer signs this using its ECDSA private key and then offers it to others using an HTTP API. Apps and requestors only use update messages if it is validly signed, confirmed using the ECDSA public key of the issuer of the credential type.
Apps having a (nonrevoked) credential with witness $(u_i, e)$ (satisfying $u_i^{e} = \nu_i$) first compute the numbers $a, b$ which are such that $ae + b\tilde{e} = 1$, using the [Extended Euclidean algorithm](https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm), and then they update their witness as follows:
- $\displaystyle u_{i+1} = u_i^b\nu_{i+1}^a$
+$$
+u_{i+1} = u_i^b\nu_{i+1}^a
+$$
This is valid against the new accumulator $\nu_{i+1}$:
-
-$
- \begin{eqnarray*}
- u_{i+1}^{e}
- &=& (u_i^b\nu_{i+1}^a)^{e}
- = u_i^{be}\nu_{i+1}^{ae} \\
- &=& \nu_i^{b}\nu_{i}^{ae/\tilde{e}}
- = (\nu_i^{b\tilde{e}}\nu_{i}^{ae})^{1/\tilde{e}}
- = (\nu_i^{b\tilde{e}+ae})^{1/\tilde{e}} \\
- &=& \nu_i^{1/\tilde{e}}
- = \nu_{i+1}
- \end{eqnarray*}
-$
-
+$$
+\begin{align*}
+u_{i+1}^{e} &= (u_i^b\nu_{i+1}^a)^{e} = u_i^{be}\nu_{i+1}^{ae} \\
+ &= \nu_i^{b}\nu_{i}^{ae/\tilde{e}} = (\nu_i^{b\tilde{e}}\nu_{i}^{ae})^{1/\tilde{e}} = (\nu_i^{b\tilde{e}+ae})^{1/\tilde{e}} \\
+ &= \nu_i^{1/\tilde{e}} = \nu_{i+1}
+\end{align*}
+$$
(The $\bmod n$ after each equality sign is implied.) The revoked credential having revocation attribute $\tilde{e}$ cannot use this algorithm and update message $(\nu_{i+1}, \tilde{e})$ to compute a new witness, as in this case there exist no integers $a, b$ such that $a\tilde{e} + b\tilde{e} = 1$. In fact, [one can prove that](http://static.cs.brown.edu/people/alysyans/papers/camlys02.pdf) knowing only $\nu_i$, $\nu_{i+1} = \nu_{i}^{1/\tilde{e}}$ and $\tilde{e}$, by the [Strong RSA assumption](https://en.wikipedia.org/wiki/Strong_RSA_assumption) which is used by both Idemix and the RSA-B accumulator scheme, *no* efficient algorithm can compute the correct witness $u_{i+1} = \nu_{i+1}^{1/\tilde{e}} = \nu_{i}^{1/\tilde{e}^2}$.
diff --git a/docs/schemes.md b/yivi-docs/docs/schemes.md
similarity index 100%
rename from docs/schemes.md
rename to yivi-docs/docs/schemes.md
diff --git a/docs/session-requests.md b/yivi-docs/docs/session-requests.md
similarity index 98%
rename from docs/session-requests.md
rename to yivi-docs/docs/session-requests.md
index b2df590..689a13c 100644
--- a/docs/session-requests.md
+++ b/yivi-docs/docs/session-requests.md
@@ -2,15 +2,6 @@
title: Session requests
---
-
-
Each [IRMA server](what-is-irma.md#irma-servers) exposes APIs for creating IRMA sessions with a session request. An *IRMA session request* contains all information required for the IRMA server and [Yivi app](yivi-app.md) to perform an IRMA session with, such as the attributes to be issued or verified. This page documents IRMA session requests. It applies to:
* The [`POST /session`](api-irma-server.md#post-session) endpoint from [`irma server`](irma-server.md).
@@ -80,7 +71,7 @@ request.Disclose = irma.AttributeConDisCon{
}
```
-
+
This asks for a (demo) `BSN` attribute, as well as either `street`, `houseNumber` and `city` from `irma-demo.nijmegen.address`, or `address` and `city` from `irma-demo.idin.idin`. The three levels correspond to a *conjunction* of *disjunctions* of *conjunctions* of requested attributes, allowing verifiers to request multiple attribute sets from the user, offering choices for some or all of these sets.
@@ -234,7 +225,7 @@ request.Disclose = irma.AttributeConDisCon{
}
```
-
+
This can be useful when certain attributes are not required, so that if the user does not have them the session does not need to be aborted.
@@ -266,7 +257,7 @@ request.Labels = map[int]irma.TranslatedString{
}
```
-
+
In this way each disjunction can be given a optional label explaining to the user the purpose of the disjunction. It is recommended to only provide a label to explain something to the user that would otherwise not be obvious; for example, to request the user to send a work email address instead of a personal one. Repeating the credential or attribute name or description in labels is an antipattern.
diff --git a/docs/stateless.md b/yivi-docs/docs/stateless.md
similarity index 95%
rename from docs/stateless.md
rename to yivi-docs/docs/stateless.md
index 44ed4a5..6ab5cc5 100644
--- a/docs/stateless.md
+++ b/yivi-docs/docs/stateless.md
@@ -45,7 +45,7 @@ tls-auth-clients no
It is also possible to disable TLS altogether for connections to Redis, using the `redis-no-tls` option.
-> In production, always using TLS for Redis is recommended. If you disable TLS, be sure to run your Redis server in an internal network protected against unauthorized access.
+> **⚠️ Warning:** In production, always using TLS for Redis is recommended. If you disable TLS, be sure to run your Redis server in an internal network protected against unauthorized access.
### Using multiple Redis instances
The IRMA server supports Redis in Sentinel mode, which allows you to use multiple Redis instances in a failover configuration. For data consistency, we currently require at least 1 replica to be present. This means that you need a minimum of 2 replicas for high availability. Please check the [configuration options](irma-server.md#stateless-mode) for more information about this mode.
diff --git a/website/versioned_docs/version-v0.14.2/what-is-irma.md b/yivi-docs/docs/what-is-irma.md
similarity index 84%
rename from website/versioned_docs/version-v0.14.2/what-is-irma.md
rename to yivi-docs/docs/what-is-irma.md
index d74720d..e69263e 100644
--- a/website/versioned_docs/version-v0.14.2/what-is-irma.md
+++ b/yivi-docs/docs/what-is-irma.md
@@ -1,23 +1,34 @@
---
-title: What is IRMA?
-id: version-v0.14.2-what-is-irma
-original_id: what-is-irma
+title: What is Yivi?
---
-IRMA is a set of free and open source software projects implementing the Idemix attribute-based credential scheme, allowing users to safely and securely authenticate themselves as privacy-preserving as the situation permits. Users receive digitally signed attributes from trusted issuer, storing them in their Yivi app, after which the user can selectively disclose attributes to others. Schematically:
+Yivi is a set of open source software project implementing the Idemix attribute-based credential scheme, allowing users to safely and securely authenticate themselves as privacy-preserving as the situation permits. Users receive digitally signed attributes from trusted issuer, storing them in their Yivi app, after which the user can selectively disclose attributes to others.
-
-
-
+Yivi's roots lie within Radboud University. Back in the day, its code name was IRMA, which stands for "I Reveal My Attributes." IRMA was later rebranded as Yivi, but many technical dependencies, such as the protocol and repositories, continue to bear the name IRMA.
+
+Schematically:
+
+
+
+
+
Using the issuer's digital signature over the attributes the verifier can verify that the attributes were given to the user in the past, and that they have not been modified since.
## IRMA session flow
A typical IRMA session is depicted schematically below.
-![IRMA session flow](assets/irmaflow.png)
+![IRMA session flow](/img/irmaflow.png)
Software components:
* *Requestor backend and frontend*: Generally the requestor runs a website with a (JavaScript) frontend in the user's browser, and a backend server. During an IRMA session the frontend displays the IRMA QR that the [Yivi app](yivi-app.md) scans. All frontend tasks depicted in the diagram are supported by [`yivi-frontend`](yivi-frontend.md).
@@ -54,11 +65,20 @@ In an IRMA session, the [Yivi mobile app](yivi-app.md) performs one of the follo
This process is depicted schematically and explained in more detail in the [IRMA session flow](what-is-irma.md#irma-session-flow) chapter. For the user, after scanning the QR in his/her Yivi app a disclosure session generally looks like the following. (Attribute-based signature sessions and issuance sessions are identical in terms of their flow (scan qr, provide permission, success screen); only the graphical interface is different.)
-