Fixed merge conflict

docs/develop/08_opendid/01_overview.md

@@ -37,4 +37,4 @@ This container requires the configuration file created from the `opendid-setup`
 
 ### kiltprotocol/opendid-demo
 
-This container is a [web app demo](./05_demo_project.md), including front and back end services to demonstrate the use of OpenDID.
+This container is a [web app demo](./05_demo_project.md), including front and back end services to demonstrate the use of OpenDID.

docs/develop/08_opendid/02_opendid_flow.md

@@ -9,24 +9,24 @@ Understanding this flow is helpful for setting up and configuring an OpenDID Ser
 OpenDID includes interactions between multiple apps to authenticate and authorize users.
 Common use cases include the following:
 
-- Web app front end (app that includes the login button, for example, the demo app)
-- Web app back end
-- OpenDID front end
-- OpenDID back end
-- Identity wallet that follows [the Credential API spec](https://github.com/KILTprotocol/spec-ext-credential-api) (typically a browser extension, for example, [Sporran](https://www.sporran.org/))
+-   Web app front end (app that includes the login button, for example, the demo app)
+-   Web app back end
+-   OpenDID front end
+-   OpenDID back end
+-   Identity wallet that follows [the Credential API spec](https://github.com/KILTprotocol/spec-ext-credential-api) (typically a browser extension, for example, [Sporran](https://www.sporran.org/))
 
 The following steps outline the interactions necessary to implement [the implicit flow](https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth):
 
-1. The user clicks the login button on the *web app front end*.
-2. The *web app front end* redirects the user to the *OpenDID front end*.
+1. The user clicks the login button on the _web app front end_.
+2. The _web app front end_ redirects the user to the _OpenDID front end_.
 3. The user chooses what wallet to authenticate with.
-4. The *OpenDID back end* establishes a secure session with the *identity wallet*.
-5. The *OpenDID back end* optionally requests a credential that implements a specific CType.
-6. The *identity wallet* provides the *OpenDID back end* with the requested credential, after authenticating the DID holder.
-7. The *OpenDID back end* returns a `id_token` as a JSON web token (JWT) to the *OpenDID front end*.
-8. *OpenDID front end* redirects the user back to a specific `redirect_url` on the *web app front end* including the `id_token`.
-9. The *web app front end* detects the `id_token` and sends it to the *web app back end*.
-10. The *web app back end* verifies the `id_token` and ensures the validity of the credential.
+4. The _OpenDID back end_ establishes a secure session with the _identity wallet_.
+5. The _OpenDID back end_ optionally requests a credential that implements a specific CType.
+6. The _identity wallet_ provides the _OpenDID back end_ with the requested credential, after authenticating the DID holder.
+7. The _OpenDID back end_ returns a `id_token` as a JSON web token (JWT) to the _OpenDID front end_.
+8. _OpenDID front end_ redirects the user back to a specific `redirect_url` on the _web app front end_ including the `id_token`.
+9. The _web app front end_ detects the `id_token` and sends it to the _web app back end_.
+10. The _web app back end_ verifies the `id_token` and ensures the validity of the credential.
 
 The following sequence diagram summarizes the flow:
 

docs/develop/08_opendid/03_opendid_service.md

@@ -3,8 +3,6 @@ id: opendid_service
 title: Run OpenDID Service
 ---
 
-<!-- TODO: Overview and steps -->
-
 ## Configuration
 
 Running the OpenDID service requires some configuration and a KILT DID.
@@ -68,6 +66,7 @@ The container generates sensible defaults in the `config.yaml` file, but here ar
 
     -   The client ID as a key (The default is: `example-client`).
     -   The `requirements` section, including:
+
         -   What CTypes are required for authentication.
         -   The trusted attesters as an address (The default is for the [SocialKYC attester](https://socialkyc.io/)).
 

docs/develop/08_opendid/04_integrate_opendid.md

@@ -76,7 +76,7 @@ The OpenDID service returns the `id_token` in the response body serialized as a
 In full-stack applications, calling the `token` endpoint is usually done through the back end to improve security.
 :::
 
-The `id_token` is a bearer JSON web token (JWT) signed by the JWT key-pair specified in the `config.yaml` file of the OpenDID service. 
+The `id_token` is a bearer JSON web token (JWT) signed by the JWT key-pair specified in the `config.yaml` file of the OpenDID service.
 You must verify this using the JWT public key, for example, by the back end of the Web app.
 
 ## Implicit flow

docs/develop/08_opendid/05_demo_project.md

@@ -6,9 +6,9 @@ title: Demo Project
 The example code at [demo-project](https://github.com/KILTprotocol/opendid/tree/main/demo-project) contains a minimal application that uses OpenDID.
 It's an [express](https://expressjs.com) application that exposes three things:
 
-- A login page that handles the dispatching of the user to the OpenDID service.
-- A callback page for one of the OpenID Connect flows supported to accept the token.
-- A protected resource that only authenticated users can access.
+-   A login page that handles the dispatching of the user to the OpenDID service.
+-   A callback page for one of the OpenID Connect flows supported to accept the token.
+-   A protected resource that only authenticated users can access.
 
 For the demo application to work you need a running OpenDID Service and an identity wallet that follows [the Credential API spec](https://github.com/KILTprotocol/spec-ext-credential-api) (e.g. [Sporran](https://www.sporran.org/)) with a DID and Credential issued by the required attester specified in the `config.yaml` file (Default is SocialKYC).
 If you follow the steps in this section in order, you have all the necessary components for the demo application to run.

docs/develop/08_opendid/06_advanced.md

@@ -108,4 +108,4 @@ docker run -d --rm \
 ```
 
 When you now log in with a user that has an email address ending with `kilt.io` as attested by the configured attester, the service allows you to log in.
-If you use a different email address, the service denies you access.
+If you use a different email address, the service denies you access.