fixed broken links and added mkdocs plugins installation (#569)

Author: paolo-de-rosa

.github/workflows/pages.yml

@@ -43,7 +43,7 @@ jobs:
           restore-keys: |
             mkdocs-material-
       - name: Install mkdocs theme
-        run: pip install mkdocs-material mike
+        run: pip install mkdocs-material mike "mkdocs-material[imaging]"
       - name: Configure fetch and merge
         run: |
           git config --local user.email "github-actions[bot]@users.noreply.github.com"

.gitignore

@@ -9,3 +9,4 @@ docs/arf.jpeg
 docs/arf.pdf
 docs/arf.png
 .vscode
+.cache

docs/architecture-and-reference-framework-main.md

@@ -5051,5 +5051,5 @@ Roadmap, which contains the latest information regarding the targeted version.
     - Blueprint Local QES - Enrolment - [Annex 4.11](./annexes/annex-4/annex-4.11-local-qes-enrolment.pdf)
     - Blueprint Local QES -- Creating a signature - [Annex 4.12](./annexes/annex-4/annex-4.12-local-qes-creating-a-signature.pdf)
 - Design Guides - Annex 5:
-    - Wallet Unit design guide - [Annex 5.1](./annexes/annex-5/annex-5.01-design-guide.pdf)
-    - Wallet Unit design guide -- data sharing scenarios - [Annex 5.2](./annexes/annex-5/annex-5.02-design-guide-data-sharing-scenarios.pdf)
+    - Wallet Unit design guide - [Annex 5.1](./annexes/annex-5/annex-5.01-design-guide.md)
+    - Wallet Unit design guide -- data sharing scenarios - [Annex 5.2](./annexes/annex-5/annex-5.02-design-guide-data-sharing-scenarios.md)

docs/discussion-topics/README.md

@@ -74,8 +74,8 @@ Iteration is planned from 26 March 2025 to 02 July 2025 covering the following t
 | I | [Natural person representing another natural person](i-natural-person-representing-another-natural-person.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/339) |
 | J | [Wallet to Wallet interaction](j-wallet-to-wallet-interactions.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/340) |
 | K | [Combined presentation of Attestations](k-combined-presentation-of-attestations.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/341) |
-| L | [User requesting data deletion to Relying Parties](l+m-data-deletion-and-dpa-complaint.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/342) |
-| M | [User reporting unlawful or suspicious request of data to DPAs](l+m-data-deletion-and-dpa-complaint.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/343) |
+| L | [User requesting data deletion to Relying Parties](l+m-data-deletion-and-reporting-of-wrp-to-dpa.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/342) |
+| M | [User reporting unlawful or suspicious request of data to DPAs](l+m-data-deletion-and-reporting-of-wrp-to-dpa.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/343) |
 | N | [Data portability](n-export-and-data-portability.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/344) |
 | U | [EUDI Wallet Trust Mark](u-eudi-wallet-trust-mark.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/351) |
 | W | [Transactional data for payments and other use cases](w-transactional-data-for-payments-and-other-use-cases.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/371) |

docs/discussion-topics/x-relying-party-registration.md

@@ -678,7 +678,7 @@ In result, the following modification are therefore proposed:
 | GenNot_01 | The European Commission SHALL establish technical specifications for a common system enabling the notification of PID Providers, PuB-EAA Providers, Wallet Providers, Access Certificate Authorities and Registrars of Registration Certificates by Member States to the Commission. *Note: Notification does not apply to QEAA Providers and (non-qualified) EAA Providers, as explained in Sections D and F below, respectively.*  |  Keep with proposed changes   |
 | GenNot_02 |  As part of the specifications referred to in GenNot_01, the European Commission SHALL establish standard operating procedures for the notification of a PID Provider, PuB-EAA Provider, Wallet Provider, Access Certificate Authorities or Registration Certificate Authorities to the Commission. *Note: The outcome of the notification procedure is the publication of the information notified by the Member State according to [Article 5a](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e1347-1-1) (18) in a machine and human readable manner using the common system mentioned in Section H, TLPub_01.* |   Keep with proposed changes   |
 | GenNot_05 |  As part of the specifications referred to in GenNot_01, the European Commission SHALL establish standard operating procedures for the suspension or cancellation of a PID Provider, PuB-EAA Provider, Wallet Provider, Access Certificate Authority or Registration Certificate Authority. These operating procedures SHALL include unambiguous conditions for suspension or cancellation. As an outcome of the suspension or cancellation procedure, the status of the suspended or cancelled PID Provider, PuB-EAA Provider, Wallet Provider, Access Certificate Authority or Registration Certificate Authority in the Trusted List SHALL be changed to Invalid. | Keep with proposed changes    |
-| PPNot_02 |  The common set of information to be notified about a PID Provider SHALL include at least: 1. Identification data: i. MS/Country of establishment, ii. Name as registered in an official record, iii. Where applicable: a. A business registration number from an official record, b. Identification data from that official record. 2. PID Provider trust anchors, i.e., public keys and name as per point 1) ii) above, supporting the authentication of PIDs issued by the PID Provider, 3. PID Provider Access Certificate Authority trust anchors, i.e., public keys and CA name, supporting the authentication of the PID Provider by Wallet Units at the service supply point(s) listed per point 4. below. 4. Service supply point(s), i.e., the URL(s) at which a Wallet Unit can start the process of requesting and obtaining a PID. *Notes: - Relating to point 3. above: PID Provider Access Certificate Authority trust anchors are notified separately from the ~~Relying Party~~ Access Certificate Authority (see Section G below), since PID Providers are -legally speaking- not Relying Parties. - For the concept of an  Access Certificate Authority, see also [[Topic 27](#a2327-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties)] and [Section 6.3.2 of the ARF main document](../../architecture-and-reference-framework-main.md#632-pid-provider-or-attestation-provider-registration-and-notification).*  |  Keep with proposed changes   |
+| PPNot_02 |  The common set of information to be notified about a PID Provider SHALL include at least: 1. Identification data: i. MS/Country of establishment, ii. Name as registered in an official record, iii. Where applicable: a. A business registration number from an official record, b. Identification data from that official record. 2. PID Provider trust anchors, i.e., public keys and name as per point 1) ii) above, supporting the authentication of PIDs issued by the PID Provider, 3. PID Provider Access Certificate Authority trust anchors, i.e., public keys and CA name, supporting the authentication of the PID Provider by Wallet Units at the service supply point(s) listed per point 4. below. 4. Service supply point(s), i.e., the URL(s) at which a Wallet Unit can start the process of requesting and obtaining a PID. *Notes: - Relating to point 3. above: PID Provider Access Certificate Authority trust anchors are notified separately from the ~~Relying Party~~ Access Certificate Authority (see Section G below), since PID Providers are -legally speaking- not Relying Parties. - For the concept of an  Access Certificate Authority, see also [[Topic 27](#a2327-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties)] and [Section 6.3.2 of the ARF main document](../architecture-and-reference-framework-main.md#632-pid-provider-or-attestation-provider-registration-and-notification).*  |  Keep with proposed changes   |
 | RPACANot_01  |  The European Commission SHALL establish technical specifications for the common set of information to be notified about Access Certificate Authorities and Registrars of Registration Certificates. |   Keep with proposed changes   |
 | RPACANot_02  | The common set of information to be notified about an Access Certificate Authority and Registrars of Registration Certificates SHALL include: 1. Identification data: i) MS/Country of establishment, ii) Name as registered in an official record, iii) Where applicable: - A business registration number from an official record, - Identification data from that official record. 2. Access Certificate Authority or Registration Certificate Authority trust anchors, i.e., public keys and name as per point 1) ii), supporting the authentication of Relying Parties by Wallet Units. |   Keep with proposed changes  |
 | RPACANot_04 | Access Certificate Authority and Registration Certificate Authority trust anchors SHALL be accepted because of their secure notification by the Member States to the Commission and by their publication in the corresponding Commission-compiled Access Certificate Authority and Registration Certificate Authority Trusted Lists which are signed or sealed by the Commission. *Note: The adopted version of the CIR for Relying Party registration will clarify how the Trusted List for Registrars of Registration Certificates are to be arranged, the certificates not being PKI/X.509 certificates as is the case with standard EU Trusted Lists. It is also to be clarified in the related technical specification if Access Certificate Authorities can sign other certificates than access certificates. * |  Keep with proposed changes  |

docs/index.md

@@ -115,7 +115,7 @@ The latest **authoritative version** is tagged as [release/tag in this repositor
 
 ## Contributing
 
-Please read [CONTRIBUTING.md](CONTRIBUTING.md) for details on our code of conduct,
+Please read [CONTRIBUTING.md](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/CONTRIBUTING.md) for details on our code of conduct,
 and the process for submitting pull requests to us.
 
 ## Versioning
@@ -130,7 +130,7 @@ who participated in this project.
 
 ## License
 
-See the [LICENSE](../LICENSE) file for details.
+See the [LICENCE](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/LICENCE) file for details.
 
 ## [European Commission website](https://commission.europa.eu/index_en)
 

mkdocs.yml

@@ -23,6 +23,8 @@ markdown_extensions:
   - footnotes
   - sane_lists
   - tables
+
+site_url: https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework
 repo_url: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework
 repo_name: eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework
 
@@ -40,3 +42,5 @@ extra:
 plugins:
   - mike
   - tags
+  - privacy
+  - social