diff --git a/.github/workflows/ci-html.yml b/.github/workflows/ci-html.yml index 5d8a5d3e4..7777dc223 100644 --- a/.github/workflows/ci-html.yml +++ b/.github/workflows/ci-html.yml @@ -43,7 +43,7 @@ jobs: - uses: actions/setup-python@v2 with: - python-version: '3.8' # Version range or exact version of a Python version to use, using SemVer's version range syntax + python-version: '3.10' # Version range or exact version of a Python version to use, using SemVer's version range syntax architecture: 'x64' # optional x64 or x86. Defaults to x64 if not specified # Runs a single command using the runners shell diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index d619f3dff..defe7d450 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -44,7 +44,7 @@ jobs: - uses: actions/setup-python@v2 with: - python-version: "3.8" # Version range or exact version of a Python version to use, using SemVer's version range syntax + python-version: "3.10" # Version range or exact version of a Python version to use, using SemVer's version range syntax architecture: "x64" # optional x64 or x86. Defaults to x64 if not specified - name: Install deps diff --git a/.github/workflows/latex.yml b/.github/workflows/latex.yml index 6e52a62c9..df147be5d 100644 --- a/.github/workflows/latex.yml +++ b/.github/workflows/latex.yml @@ -27,7 +27,7 @@ jobs: - uses: actions/setup-python@v2 with: - python-version: '3.8' # Version range or exact version of a Python version to use, using SemVer's version range syntax + python-version: '3.10' # Version range or exact version of a Python version to use, using SemVer's version range syntax architecture: 'x64' # optional x64 or x86. Defaults to x64 if not specified # TODO: temporary disabled diff --git a/README.md b/README.md index c3de1c155..2669b2582 100644 --- a/README.md +++ b/README.md @@ -62,10 +62,6 @@ HTML ```` pip install -r requirements.txt -# italian version -sphinx-build -b html -d html/it/doctrees docs/it/ html/it - -# english version sphinx-build -b html -d html/en/doctrees docs/en/ html/en ```` diff --git a/docs/en/conf.py b/docs/en/conf.py index 2f95d177b..95bbf7205 100644 --- a/docs/en/conf.py +++ b/docs/en/conf.py @@ -13,7 +13,6 @@ # -- No need to change below here import sys, os -docs_italia_theme = __import__("docs_italia_theme") from recommonmark.transform import AutoStructify from recommonmark.parser import CommonMarkParser @@ -48,7 +47,6 @@ 'sphinx.ext.todo', 'sphinx.ext.coverage', 'sphinx.ext.ifconfig', - 'docs_italia_theme', 'sphinx.ext.autosectionlabel', ] @@ -112,9 +110,9 @@ def setup(app): # -- Options for HTML output ---------------------------------------------- -html_theme = 'docs-italia-theme' +html_theme = 'piccolo_theme' -html_theme_path = [docs_italia_theme.get_html_theme_path()] +# html_theme_path = [docs_italia_theme.get_html_theme_path()] # Theme options are theme-specific and customize the look and feel of a theme # further. For a list of options available for each theme, see the @@ -131,8 +129,9 @@ def setup(app): on_rtd = os.environ.get('READTHEDOCS', None) == 'True' if not on_rtd: # only import and set the theme if we're building docs locally - html_theme_path = [docs_italia_theme.get_html_theme_path()] - html_theme = 'docs_italia_theme' + # html_theme_path = [docs_italia_theme.get_html_theme_path()] + # html_theme = 'docs_italia_theme' + pass else: # Override default css to get a larger width for ReadTheDoc build html_context = { diff --git a/docs/en/contribute.rst b/docs/en/contribute.rst index 16606dd80..c4bea2975 100644 --- a/docs/en/contribute.rst +++ b/docs/en/contribute.rst @@ -5,7 +5,7 @@ How to contribute +++++++++++++++++++++++++++ -The IT Wallet project, including this document, follows an **open development process**. This approach ensures the development process is accessible to all, inviting all interested parties to participate. +The IT-Wallet project, including this document, follows an **open development process**. This approach ensures the development process is accessible to all, inviting all interested parties to participate. Consequently, stakeholders, national and international community members are not only encouraged but also heartily welcomed to contribute to the refinement of these technical rules. diff --git a/docs/en/defined-terms.rst b/docs/en/defined-terms.rst index 34f073076..bcb98e626 100644 --- a/docs/en/defined-terms.rst +++ b/docs/en/defined-terms.rst @@ -16,63 +16,157 @@ The terms *User*, *Trust Service*, *Trust Model*, *Trusted List*, *Trust Framewo Below are the description of acronyms and definitions which are useful for further insights into topics that complement the it-wallet and the interacting components. - .. list-table:: - :widths: 20 60 :header-rows: 1 - * - **Claim** - - **Description** - * - Accreditation Body - - An entity accredited by the Federation Authority, responsible for managing the process of verification and certification of accreditation requirements for ecosystem roles. + * - Name + - Description + - Notes + * - User + - A natural or legal person using an EUDI Wallet. [ARF v1.3] + - - + * - User Attribute + - A feature, characteristic or quality of a natural or legal person or of an entity, in electronic form. [ARF v1.3] + - Other alternative terms: User Claim * - Digital Identity Provider - An entity, recognized and accredited by the State, responsible for identifying citizens for the issuance of an Electronic Identity Certificate. + - * - Digital Credential - - An signed Credential whose integrity can be cryptographically verified using the public keys of its Issuer. It is also known as Credential. - * - Federation Authority - - A public governance entity that issues guidelines and technical rules, and administers - directly or through its intermediary - Trusted Lists, services, and accreditation processes, the status of participants, and their eligibility evaluation. It also performs oversight functions. + - A signed set of Attributes encapsulated in a specific data format, such as mdoc format specified in [ISO 18013-5] or the SD-JWT VC format specified in [SD-JWT-VC]. This may be a Personal Identification Data (PID), (Qualified) Electronic Attestation of Attribute ((Q)EAA). [Revised from ARF v1.3] + - Differences with ARF: The definition from ARF restricts the data format to mdoc and SD-JWT VC. For the scope of the Trust Model, a Digital Credential definition should be neutral on the format. ARF alternative terms: Attestation Other alternative terms: Verifiable Credential + * - Organizational Entity + - A legal person (only considering organizations and public entities, not natural/physical persons) recognized by the Member State through a unique identifier to operate a certain role within the EUDI Wallet ecosystem. + - In this category the following entity roles are included: Wallet Provider, Credential Issuer, Relying Party, QTSP In general, any kind of Entity that must be accredited through a national or European accreditation mechanism. ARF alternative terms: legal person (only considering organizations and public entities, not natural/physical persons) * - Wallet Solution - - System designed to store and manage digital assets and identity information. - * - Wallet Instance - - An instance of the Wallet Solution, installed on a personal mobile device and controlled by a specific User who is its sole owner. It is the application that enables citizens to fully and autonomously manage their digital identity and EAAs. + - A Wallet Solution is the entire eIDAS-compliant product and service provided by a Wallet Provider to all Users. [Revised from ARF v1.3] + - Differences with ARF: editorial ARF alternative terms: EUDI Wallet Solution * - Wallet Provider - - All public and/or private entities, conforming to a technical profile and accredited by the Federation Authority, that provide citizens with an IT Wallet Instance. + - An Organizational Entity, responsible for the management and release operation of a Wallet Solution. [Revised from ARF v1.3] + - Differences with ARF: Removed “instantiated on a User's device, e.g., through installation and initialization” as this is a technical aspect that is not related with the WP definition. ARF alternative terms: EUDI Wallet Provider + * - Wallet Instance + - Instance of a Wallet Solution belonging to and which is controlled by a User. It enables the storage and management of Digital Credentials. [Revised from ARF v1.3] + - Differences with ARF: added the last sentence. ARF alternative terms: EUDI Wallet Instance Other alternative terms: Personal Wallet * - Wallet Provider Backend - Is the technical infrastructure and server-side components, including a set of endpoints, managed by a Wallet Provider. + - + * - Credential Issuer + - An Organizational Entity providing Digital Credentials to Users. It may be PID Provider and (Q)EAA Providers. [Revised from ARF v1.3] + - Differences with ARF: (i) merged the PID Providers and (Q)EEA Providers definitions using the general term Digital Credential, (ii) renamed “Member Stare or other legal entity” in “Organizational Entity” ARF alternative terms: PID Providers,(Q)EEA Providers, Attestation Provider Other alternative terms: Verifiable Credential Issuer + * - Relying Party + - An Organizational Entity that relies upon an electronic identification or a Trust Service originating from a Wallet Instance. [Revised from ARF v1.3] + - Differences with ARF: renamed “natural or legal person” in “Organizational Entity” + * - RP Instance + - A Relying Party Instance in the context of a mobile application or a standalone embedded device refers to a specific deployment of the application or device. These instances depend on an User Authentication through a Wallet Instance to confirm User identities before granting access to their functionalities. Each version or environment where the application or device is running, be it a particular release of a mobile app installed on a User's smartphone or a specific embedded device in use, constitutes a separate instance. In case of proximity supervised scenarios, it belongs to and is controlled by a Verifier. [Revised from ARF v1.3] + - Differences with ARF: added a sentence on proximity supervised scenarios. Other alternative terms: Verifier App + * - Verifier + - A natural person or legal person using an RP Instance. [New] + - + * - Trust + - Trust is the confidence in the security, reliability, and integrity of entities (such as systems, organizations, or individuals) and their actions, ensuring that they will operate as expected in a secure and predictable manner. It is often established through empirical proof, such as past performance, security certifications, or transparent operational practices, which demonstrate a track record of adherence to security standards and ethical conduct. [Revised from ARF v1.3] + - + * - Trust Framework + - A legally enforceable set of operational and technical rules and agreements that govern a multi-party system designed for conducting specific types of transactions among a community of participants and bound by a common set of requirements. [ARF v1.3] + - + * - Trust Model + - Collection of rules that ensure the legitimacy of the components and the entities involved in the EUDI Wallet ecosystem. [ARF v1.3] + - + * - Trusted List + - Repository of information about authoritative entities in a particular legal or contractual context which provides information about their current and historical status. It serves as the bedrock of trust, acting as federative sources that publish the crucial information about root entities within the ecosystem. [Revised from ARF v1.3] + - Differences with ARF: added the last sentence + * - Registration Authority + - A party responsible for registering all the Organizational Entities by issuing a Trust Assertion. + - ARF: Registrar + * - Conformity Assessment Body (CAB) + - A conformity assessment body as defined in Article 2, point 13, of Regulation (EC) No 765/2008, which is accredited in accordance with that Regulation as competent to carry out conformity assessment of a qualified trust service provider and the qualified trust services it provides, or as competent to carry out certification of European Digital Identity Wallets or electronic identification means. [ARF v1.3] + - + * - National Accreditation Bodies (NAB) + - A body that performs accreditation with authority derived from a Member State under Regulation (EC) No 765/2008. [ARF v1.3] + - Other alternative terms: Accreditation Authority + * - Trust Evaluation + - The process of verifying the trustworthiness of registered Organizational Entities, in accordance with pre-established rules. For example, involving the retrieval and validation of entity configurations and trust chains. + - Other alternative terms: Trust Discovery, Trust Establishment + * - Trust Assertion + - Cryptographically verifiable artifact that proves the compliance of an Organizational Entity with known rules and requirements defined within the Trust Model. + - Other alternative terms: Verifiable Attestation, Access Certificate + * - Trust Relationship + - Positive outcome of Trust Evaluation, which produces a reliable relationship between Organizational Entities, where one Organizational Entity trusts the other to securely handle data, execute transactions, or perform actions on its behalf. + - + * - Metadata + - Digital artifact that contains all the required information about an Organizational Entity, e.g., protocol related endpoints and the Organizational Entity’s cryptographic public keys (for the complete list check requirement “Metadata Content”). + - + * - Policy Language + - A formal language used to define security, privacy, and identity management policies that govern interactions and transactions within a Trust Framework. This language allows for the clear and unambiguous expression of rules and conditions, facilitating the automation of processes and interoperability among different systems and organizations. + - + * - Registration Process + - Process performed by a Registration Authority verifying necessary information to ensure Organizational Entity eligibility and compliance with the relevant rules and standards. The main goal of the Registration Process is for the Organizational Entity to receive one or more Trust Assertions to be used for the Trust Evaluation processes. + - + * - Accreditation Process + - Process performed by the National Accreditation Body to accreditate CABs. As a result of the Accreditation Process, a NAB issues an accreditation certificate to a CAB. + - Currently, out of scope of the Trust Model requirements + * - Certification Process + - Process performed by Conformity Assessment Bodies to certify the Wallet Solution. The Certification Process aims to periodically assess technical Wallet Solutions (e.g. performing vulnerability assessment and risk analysis). As a result of the Certification Process a certification is provided to the Wallet Solution. [New] + - Currently, out of scope of the Trust Model requirements + * - Notification Process + - Process defining how information is transferred to the European Commission and the inclusion of an entity in the Trusted List. + - + * - Supervision Process + - Process performed by a Supervisory Body to review and ensure proper functioning of the Wallet Provider and other relevant actors. + - Currently, out of scope of the Trust Model requirements + * - Federation Authority + - A public governance entity that issues guidelines and technical rules, and administers - directly or through its intermediary - Trusted Lists, services, and accreditation processes, the status of participants, and their eligibility evaluation. It also performs oversight functions. + - * - Wallet Attestation - Verifiable Attestation, issued by the Wallet Provider, that proves the security compliace of the Wallet Instance. + - * - Wallet Secure Cryptographic Device - Hardware-backed secure environment for creating, storing, and/or managing cryptographic keys and data. A WSCD MAY implement an association proof in different ways. This largely depends on the implementation of the WSCD for example: remote HSM, external smart card, internal UICC, internal native cryptographic hardware, such as the iOS Secure Enclave or the Android Hardware Backed Keystore or StrongBox + - * - Credential Status Attestation - Verifiable Attestation proving that a related Digital Credential is not revoked. + - * - Device Integrity Service - A service provided by device manufacturers that verifies the integrity and authenticity of the app instance (Wallet Instance), as well as certifying the secure storage of private keys generated by the device within its dedicated hardware. It's important to note that the terminology used to describe this service varies among manufacturers. + - * - Cryptographic Hardware Keys - During the app initialization, the Wallet Instance generates a pair of keys, one public and one private, which remain valid for the entire duration of the Wallet Instance's life. Functioning as a Master Key for the personal device, these Cryptographic Hardware Keys are confined to the OS domain and are not designed for signing arbitrary payloads. Their primary role is to provide a unique identification for each Wallet Instance. + - * - Cryptographic Hardware Key Tag - A unique identifier created by the operating system for the Cryptographic Hardware Keys, utilized to gain access to the private key stored in the hardware. + - * - Key Attestation - An attestation from the device's OEM that enhances your confidence in the keys used in your Wallet Instance being securely stored within the device's hardware-backed keystore. + - * - Qualified Electronic Attestation of Attributes (QEAA) - A digitally verifiable attestation in electronic form, issued by a QTSP, that substantiates a person's possession of attributes. + - * - Qualified Electronic Signature Provider - The Electronic Trust Service Provider responsible for the issuing of Qualified Electronic Signature certificates to the User. + - * - Relying Party - A natural or legal person that implements an authentication system requiring electronic attribute attestation submissions as an authentication mechanism. + - * - Verifier - - See Relying Party. + - See Relying Party + - * - Trust Attestation - Electronic attestation of an entity's compliance with the national regulatory framework, which is cryptographically verifiable and cannot be repudiated over time by the entity that issued it. A Trust Attestation is always related to a particular Trust Framework. + - * - Trust Layer - - An architectural component that enables IT Wallet system participants to establish trust, in terms of reliability and compliance of all participants with the regulatory framework governing the digital identity system. + - Architectural component that enables IT-Wallet system participants to establish trust, in terms of reliability and compliance of all participants with the regulatory framework governing the digital identity system. + - * - Trust Model - System defining how the participants of the ecosystem establish and maintain trust in their interactions. The Trust Model outlines the rules and the procedures for the entities (like users, systems, or applications) should validate each other's identities, authenticate, and establish the level of trust before exchanging information. + - * - Level of Assurance - The degree of confidence in the vetting process used to establish the identity of the User and the degree of confidence that the User who presents the credential is the same User to whom the Digital Credential was issued. + - * - Holder Key Binding - Ability of the Holder to prove legitimate possession of the private part, related to the public part attested by a Trusted Third Party. + - * - Holder - Natural or Legal person that receives Verifiable Credentials from the Credential Issuers, manages the Verifiable Credentials within the Wallet, and presents them to Verifiers. The Holder is the User in control of the Wallet. + - + Acronyms -------- diff --git a/docs/en/index.rst b/docs/en/index.rst index 18fbe5939..b4948f0b4 100644 --- a/docs/en/index.rst +++ b/docs/en/index.rst @@ -9,11 +9,11 @@ Introduction The European Parliament `has adopted `_ the revision of the eIDAS Regulation concerning electronic identification and trust services, introducing a significant innovation: the `European Digital Identity Wallet `_. This update marks a pivotal advancement in the EU's digital strategy, aiming to enhance the security, interoperability, and usability of digital identities across Member States. For further details, resources, and notes on this legislative development, please refer to the official EU Commission and Parliament websites. -Italy has launched the National digital identity Wallet solution, known as IT Wallet, in direct response to the European community's directives. This initiative ensures full interoperability with the digital identity solutions provided by other European Member States, aligning completely with European regulations. +Italy has launched the National digital identity Wallet solution, known as IT-Wallet, established by the Legislative Decree of March 2, 2024, No. 19 (commonly referred to as the PNRR Decree)., in direct response to the European community's directives. This initiative ensures full interoperability with the digital identity solutions provided by other European Member States, aligning with European regulations. -The purpose of the following technical rules is to define the technical architecture and reference framework to be used as a guideline by all the parties involved in the development of the IT Wallet project. +The purpose of the following technical rules is to define the technical architecture and reference framework to be used as a guideline by all the parties involved in the development of the IT-Wallet project. -This documentation defines the national implementation profile of EUDI Wallet, containing the technical details about components of the Wallet ecosystem, as listed below: +This documentation defines the national implementation profile of IT-Wallet, containing the technical details about components of the Wallet ecosystem, as listed below: - Entities of the ecosystem according to `EIDAS-ARF`_. - Infrastructure of trust attesting realiability and eligibility of the participants. diff --git a/docs/en/trust.rst b/docs/en/trust.rst index 2acec1384..d654bfa0d 100644 --- a/docs/en/trust.rst +++ b/docs/en/trust.rst @@ -17,12 +17,12 @@ The Infrastructure of trust facilitates the application of a trust assessment me The roles within the Federation, where the Trust Anchor oversees its subordinates, which include one or more Intermediates and Leaves. In this - representation, both the Trust Anchor and the Intermediates MAY assume the role of Accreditation Body. + representation, both the Trust Anchor and the Intermediates assume the role of Registration Authority. Federation Roles ------------------ -All the participants are Federation Entities that MUST be accredited by an Accreditation Body, +All the participants are Federation Entities that MUST be registered by an Registration Body, except for Wallet Instances which are End-User's personal devices certified by their Wallet Provider. .. note:: @@ -137,11 +137,11 @@ This section includes the requirements necessary for the successful implementati * - [FR #21] - **Future-Proof Cryptography**: the system should employ a flexible cryptographic framework that can be updated in response to new threats or advancements in cryptographic research, ensuring long-term security and integrity of federation operations. * - [FR #23] - - **Autonomous Accreditation Bodies**: the system must facilitate the integration of autonomous accreditation bodies that operate in compliance with federation rules. These bodies are tasked with evaluating and accrediting entities within the federation, according to the pre-established rules and their compliance that must be periodically asserted. + - **Autonomous Registration Bodies**: the system must facilitate the integration of autonomous registration bodies that operate in compliance with federation rules. These bodies are tasked with evaluating and accrediting entities within the federation, according to the pre-established rules and their compliance that must be periodically asserted. * - [FR #24] - - **Compliance Evaluation for Federation Entity Candidates**: accreditation bodies must evaluate the compliance of candidate entities against federation standards before their registration in the federation. + - **Compliance Evaluation for Federation Entity Candidates**: registration bodies must evaluate the compliance of candidate entities against federation standards before their registration in the federation. * - [FR #25] - - **Periodic Auditing of Accreditation Bodies and Entities**: implement mechanisms for the periodic auditing and monitoring of the compliance status of both accreditation bodies and their accredited entities. This ensures ongoing adherence to federation standards and policies. + - **Periodic Auditing of Registration Bodies and Entities**: implement mechanisms for the periodic auditing and monitoring of the compliance status of both registration bodies and their accredited entities. This ensures ongoing adherence to federation standards and policies. * - [FR #26] - **Certification of Compliance for Personal Devices**: trusted bodies, in the form of federation entities, should issue certifications of compliance and provide signed proof of such compliance for the hardware of personal devices used within the federation. These certifications should be attested and periodically renewed to ensure the devices meet current security standards. * - [FR #27] @@ -454,7 +454,7 @@ Trust Anchors and Intermediates MUST expose the Federation Fetch endpoint, where .. note:: The Federation Fetch endpoint MAY also publish X.509 certificates for each of the public keys of the Subordinate. Making the distribution of the issued X.509 certificates via a RESTful service. -Below there is a non-normative example of an Entity Statement issued by an Accreditation Body (such as the Trust Anchor or its Intermediate) in relation to one of its Subordinates. +Below there is a non-normative example of an Entity Statement issued by an Registration Body (such as the Trust Anchor or its Intermediate) in relation to one of its Subordinates. .. code-block:: text @@ -639,7 +639,7 @@ Offline Trust Attestation Mechanisms The offline flows do not allow for real-time evaluation of an Entity's status, such as its revocation. At the same time, using short-lived Trust Chains enables the attainment of trust attestations compatible with the required revocation administrative protocols (e.g., a revocation must be propagated in less than 24 hours, thus the Trust Chain must not be valid for more than that period). -Offline EUDI Wallet Trust Attestation +Offline Wallet Trust Attestation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Given that the Wallet Instance cannot publish its metadata online at the *.well-known/openid-federation* endpoint, diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 3b09eae39..25bae668a 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -106,7 +106,7 @@ Wallet Instance Initialization and Registration **Device Integrity Service**: In this section the Device Integrity Service is considered as it is provided by device manufacturers. This service allows the verification of a key being securely stored within the device's hardware through a signed object. Additionally, it offers the verifiable proof that a specific Wallet Instance is authentic, unaltered, and in its original state using a specialized signed document made for this scope. The service also incorporates details in the signed object, such as the device type, model, app version, operating system version, bootloader status, and other relevant information to assess the device has not been compromised. For Android, the DIS is represented by *Key Attestation*, a feature supported by *StrongBox Keymaster*, which is a physical HSM installed directly on the motherboard, and the *TEE* (Trusted Execution Environment), a secure area of the main processor. *Key Attestation* aims to provide a way to strongly determine if a key pair is hardware-backed, what the properties of the key are, and what constraints are applied to its usage. Developers can leverage its functionality through the *Play Integrity API*.For Apple devices, the DIS is represented by *DeviceCheck*, which provides a framework and server interface to manage device-specific data securely. *DeviceCheck* is used in combination with the *Secure Enclave*, a dedicated HSM integrated into Apple's SoCs. *DeviceCheck* can be used to attest the integrity of the device, apps, and/or encryption keys generated on the device, ensuring they were created in a secure environment like *Secure Enclave*. Developers can leverage *DeviceCheck* functionality by using the framework itself. - These services, specifically developed by the manufacturer, are integrated within the Android or iOS SDKs, eliminating the need for a predefined endpoint to access them. Additionally, as they are specifically developed for mobile architecture, they do not need to be registered as Federation Entities through national accreditation systems. + These services, specifically developed by the manufacturer, are integrated within the Android or iOS SDKs, eliminating the need for a predefined endpoint to access them. Additionally, as they are specifically developed for mobile architecture, they do not need to be registered as Federation Entities through national registration systems. For Apple devices *Secure Enclave* is available since the iPhone 5s (2013). For Android devices, the inclusion of **Strongbox Keymaster** may vary by each smartphone manufacturer, who decides whether to include it or not. diff --git a/docs/en/wallet-solution.rst b/docs/en/wallet-solution.rst index d204cbdd9..398aa1b17 100644 --- a/docs/en/wallet-solution.rst +++ b/docs/en/wallet-solution.rst @@ -234,7 +234,7 @@ Below a non-normative example of the Entity Configuration. ] }, "federation_entity": { - "organization_name": "IT Wallet Provider", + "organization_name": "IT-Wallet Provider", "homepage_uri": "https://wallet-provider.example.org", "policy_uri": "https://wallet-provider.example.org/privacy_policy", "tos_uri": "https://wallet-provider.example.org/info_policy", diff --git a/docs/it/conf.py b/docs/it/conf.py index dd23e066e..95bbf7205 100644 --- a/docs/it/conf.py +++ b/docs/it/conf.py @@ -13,7 +13,6 @@ # -- No need to change below here import sys, os -docs_italia_theme = __import__("docs_italia_theme") from recommonmark.transform import AutoStructify from recommonmark.parser import CommonMarkParser @@ -48,7 +47,7 @@ 'sphinx.ext.todo', 'sphinx.ext.coverage', 'sphinx.ext.ifconfig', - 'docs_italia_theme', + 'sphinx.ext.autosectionlabel', ] # Add any paths that contain templates here, relative to this directory. @@ -111,9 +110,9 @@ def setup(app): # -- Options for HTML output ---------------------------------------------- -html_theme = 'docs-italia-theme' +html_theme = 'piccolo_theme' -html_theme_path = [docs_italia_theme.get_html_theme_path()] +# html_theme_path = [docs_italia_theme.get_html_theme_path()] # Theme options are theme-specific and customize the look and feel of a theme # further. For a list of options available for each theme, see the @@ -130,8 +129,9 @@ def setup(app): on_rtd = os.environ.get('READTHEDOCS', None) == 'True' if not on_rtd: # only import and set the theme if we're building docs locally - html_theme_path = [docs_italia_theme.get_html_theme_path()] - html_theme = 'docs_italia_theme' + # html_theme_path = [docs_italia_theme.get_html_theme_path()] + # html_theme = 'docs_italia_theme' + pass else: # Override default css to get a larger width for ReadTheDoc build html_context = { @@ -281,5 +281,5 @@ def setup(app): numfig = True -# to turn smartquotes off and be able to use ’ +# to turn smartquotes off and be able to use smartquotes = False diff --git a/requirements-dev.txt b/requirements-dev.txt index 03dd1049a..d58675ffa 100644 --- a/requirements-dev.txt +++ b/requirements-dev.txt @@ -1,28 +1,33 @@ -alabaster==0.7.12 -Babel==2.10.1 +alabaster==0.7.16 +Babel==2.15.0 certifi==2024.7.4 -charset-normalizer==2.0.12 +charset-normalizer==3.3.2 commonmark==0.9.1 -doc8==0.11.1 -docs-italia-theme @ git+https://github.com/italia/docs-italia-theme.git@3209d99db00ef965c528fd2932ae7da7dcee26b0 -docutils==0.18.1 +doc8==1.1.1 +docutils==0.20.1 idna==3.7 -imagesize==1.3.0 +imagesize==1.4.1 Jinja2==3.1.4 -MarkupSafe==2.1.1 -packaging==21.3 -Pygments==2.15.0 -pyparsing==3.0.9 -pytz==2022.1 -PyYAML==6.0 +MarkupSafe==2.1.5 +packaging==24.1 +pbr==6.0.0 +Pygments==2.18.0 +pyparsing==3.1.2 +pytz==2024.1 +PyYAML==6.0.1 recommonmark==0.7.1 -requests==2.32.0 +requests==2.32.3 +restructuredtext-lint==1.4.0 snowballstemmer==2.2.0 -Sphinx==5.0.1 -sphinxcontrib-applehelp==1.0.2 -sphinxcontrib-devhelp==1.0.2 -sphinxcontrib-htmlhelp==2.0.0 +Sphinx==7.4.5 +sphinx-theme==1.0 +sphinxcontrib-applehelp==1.0.8 +sphinxcontrib-devhelp==1.0.6 +sphinxcontrib-htmlhelp==2.0.5 sphinxcontrib-jsmath==1.0.1 -sphinxcontrib-qthelp==1.0.3 -sphinxcontrib-serializinghtml==1.1.5 -urllib3==1.26.19 +sphinxcontrib-qthelp==1.0.7 +sphinxcontrib-serializinghtml==1.1.10 +stevedore==5.2.0 +tomli==2.0.1 +urllib3==2.2.2 +piccolo_theme