diff --git a/refs/pull/453/merge/en/.doctrees/environment.pickle b/refs/pull/453/merge/en/.doctrees/environment.pickle index 5dfd355b..13e1a5d0 100644 Binary files a/refs/pull/453/merge/en/.doctrees/environment.pickle and b/refs/pull/453/merge/en/.doctrees/environment.pickle differ diff --git a/refs/pull/453/merge/en/.doctrees/trust.doctree b/refs/pull/453/merge/en/.doctrees/trust.doctree index 2be28321..1a5ea601 100644 Binary files a/refs/pull/453/merge/en/.doctrees/trust.doctree and b/refs/pull/453/merge/en/.doctrees/trust.doctree differ diff --git a/refs/pull/453/merge/en/_sources/trust.rst.txt b/refs/pull/453/merge/en/_sources/trust.rst.txt index d319f30b..1bac68e8 100644 --- a/refs/pull/453/merge/en/_sources/trust.rst.txt +++ b/refs/pull/453/merge/en/_sources/trust.rst.txt @@ -604,24 +604,6 @@ The Trust Chains can also be verified offline, using one of the Trust Anchor's p The Wallet Attestation conveys all the required information pertaining to the instance, such as its public key and any other technical or administrative information, without any User's personal data. -Establishing Trust with Relying Parties -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The Relying Party is registered by a Trust Anchor or its Intermediate and obtains a Trust Mark to be included in its Entity Configuration. -In its Entity Configuration the Relying Party publishes its specific metadata, including the supported signature and encryption algorithms -and any other necessary information for the interoperability requirements. - -Any requests for User attributes, such as PID or (Q)EAA, from the Relying Party to Wallet Instances are signed and SHOULD contain the verifiable -Trust Chain regarding the Relying Party. - -The Wallet Instance verifies that the Trust Chain related to the Relying Party is still active, -proving that the Relying Party is still part of the Federation and not revoked. - -The Trust Chain MAY be contained within the signed request in the form of a JWS header parameter, or dynamically built through a Federation Entity Discovery process. - -In offline flows, Trust Chain verification enables the assessment of the reliability of Trust Marks and Attestations contained within. - - Establishing Trust with Credential Issuers ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/refs/pull/453/merge/en/algorithms.html b/refs/pull/453/merge/en/algorithms.html index 3f45ea16..23103fdf 100644 --- a/refs/pull/453/merge/en/algorithms.html +++ b/refs/pull/453/merge/en/algorithms.html @@ -359,7 +359,7 @@
The Relying Party is registered by a Trust Anchor or its Intermediate and obtains a Trust Mark to be included in its Entity Configuration. -In its Entity Configuration the Relying Party publishes its specific metadata, including the supported signature and encryption algorithms -and any other necessary information for the interoperability requirements.
-Any requests for User attributes, such as PID or (Q)EAA, from the Relying Party to Wallet Instances are signed and SHOULD contain the verifiable -Trust Chain regarding the Relying Party.
-The Wallet Instance verifies that the Trust Chain related to the Relying Party is still active, -proving that the Relying Party is still part of the Federation and not revoked.
-The Trust Chain MAY be contained within the signed request in the form of a JWS header parameter, or dynamically built through a Federation Entity Discovery process.
-In offline flows, Trust Chain verification enables the assessment of the reliability of Trust Marks and Attestations contained within.
-In the issuance process, trust evaluation ensures the integrity and authenticity of the Credentials being issued and the realiability of their Issuers. This section delineates the trust evaluation mechanisms distinct from the protocol flows, implemented by Wallet Instances and Relying Parties, as described in the dedicated section.
@@ -1013,7 +1001,6 @@