From 72b45d3444f09f9b152c4522657370fc2fd19ecd Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Tue, 17 Sep 2024 19:16:49 +0200 Subject: [PATCH 1/4] Trust Evaluation notes added --- docs/en/trust.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/en/trust.rst b/docs/en/trust.rst index 1bcc37f5..11c6bd27 100644 --- a/docs/en/trust.rst +++ b/docs/en/trust.rst @@ -631,6 +631,17 @@ Below is a non-normative example of a Trust Chain in its original format (JSON A .. note:: The entire Trust Chain is verifiable by only possessing the Trust Anchor's public keys. +There are events where keys are unavailable to verify the entire trust chain. These cases can arise as follows: + + - **Key Change by Credential Issuer**: When the credential issuer updates its keys (the previous keys MUST be valid for their designated validity period). This can be managed using the Federation Historical Keys Endpoint. + + - **Change in Credential Types**: The credential issuer changes the types of credentials issued (removing one or more is the critical case); this eveny MUST be triggered at intermediate/root level, thus MAY be forced by an upper authority. Previously issued credentials within previous MUST be valid for their validity period. + + - **Credential Issuers Merge**: When a credential issuer merges with another, both a Federation Historical Keys Endpoint and a Federation Historical Entity Endpoint are necessary. + + - **Credential Issuer Becomes Inactive**: If a credential issuer becomes inactive for any reason, a Federation Historical Entity Endpoint would be required, likely managed by a higher authority, as in the previous scenario. This situation may not only apply to the credential issuer (leaf) but could also occur at an intermediate or root entity level. In such cases, the root or trust anchor may be the entity responsible for managing the Federation Historical Entity Endpoint. + +In the last scenarios, the root authority, or an entity authorized by the root authority, MUST retain the keys and trust chain information. In case of any issue involving any actor in the trust chain, the root authority is responsible for maintaining the historical record of the trust chain for a period established by law. Offline Trust Attestation Mechanisms From 056bcccf2691f020ff5ea15db19cdf00f7c14f67 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 19 Sep 2024 09:51:21 +0200 Subject: [PATCH 2/4] code review From 1bd98ee112d2d33fc6ceb6500c85afd2d00c4f6f Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 19 Sep 2024 13:09:47 +0200 Subject: [PATCH 3/4] Editorial changes --- docs/en/trust.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/en/trust.rst b/docs/en/trust.rst index 11c6bd27..8bc10e8e 100644 --- a/docs/en/trust.rst +++ b/docs/en/trust.rst @@ -631,17 +631,17 @@ Below is a non-normative example of a Trust Chain in its original format (JSON A .. note:: The entire Trust Chain is verifiable by only possessing the Trust Anchor's public keys. -There are events where keys are unavailable to verify the entire trust chain. These cases can arise as follows: +There are events where keys are unavailable to verify the entire trust chain: - - **Key Change by Credential Issuer**: When the credential issuer updates its keys (the previous keys MUST be valid for their designated validity period). This can be managed using the Federation Historical Keys Endpoint. + - **Key Change by Credential Issuer**: If the credential issuer updates its keys, the previous keys MUST be valid for their originally designated validity period. This MUST be managed using the Federation Historical Keys Endpoint. - - **Change in Credential Types**: The credential issuer changes the types of credentials issued (removing one or more is the critical case); this eveny MUST be triggered at intermediate/root level, thus MAY be forced by an upper authority. Previously issued credentials within previous MUST be valid for their validity period. + - **Change in Credential Types**: If the credential issuer changes the credential issued, for example deciding not to issue one or more credential types, the related keys MUST be available for the originally designated validity period. - - **Credential Issuers Merge**: When a credential issuer merges with another, both a Federation Historical Keys Endpoint and a Federation Historical Entity Endpoint are necessary. + - **Credential Issuers Merge**: If a credential issuer merges with another, the previousòly available federation configuration MUST be available throught both Federation Historical Keys Endpoint and Federation Historical Entity Endpoint. - - **Credential Issuer Becomes Inactive**: If a credential issuer becomes inactive for any reason, a Federation Historical Entity Endpoint would be required, likely managed by a higher authority, as in the previous scenario. This situation may not only apply to the credential issuer (leaf) but could also occur at an intermediate or root entity level. In such cases, the root or trust anchor may be the entity responsible for managing the Federation Historical Entity Endpoint. + - **Credential Issuer Becomes Inactive**: If a credential issuer becomes inactive for any reason, a Federation Historical Entity Endpoint MUST be available, managed by a higher authority. This situation may not only apply to the credential issuer (leaf) but could also occur at an intermediate or root entity level. In such cases the root or trust anchor may be the entity responsible for managing the Federation Historical Entity Endpoint. -In the last scenarios, the root authority, or an entity authorized by the root authority, MUST retain the keys and trust chain information. In case of any issue involving any actor in the trust chain, the root authority is responsible for maintaining the historical record of the trust chain for a period established by law. +In the latter scenarios, the root authority, or an entity authorized by the root authority, MUST retain the keys and trust chain end points for a period established by law. Offline Trust Attestation Mechanisms From 9eed492ffd725837c7f7b5d78ab0d59c46cfc8a5 Mon Sep 17 00:00:00 2001 From: SaraConsoliACN <167582839+SaraConsoliACN@users.noreply.github.com> Date: Thu, 19 Sep 2024 14:33:20 +0200 Subject: [PATCH 4/4] editorial changes --- docs/en/trust.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/en/trust.rst b/docs/en/trust.rst index 8bc10e8e..8bdebd0d 100644 --- a/docs/en/trust.rst +++ b/docs/en/trust.rst @@ -631,15 +631,16 @@ Below is a non-normative example of a Trust Chain in its original format (JSON A .. note:: The entire Trust Chain is verifiable by only possessing the Trust Anchor's public keys. + There are events where keys are unavailable to verify the entire trust chain: - **Key Change by Credential Issuer**: If the credential issuer updates its keys, the previous keys MUST be valid for their originally designated validity period. This MUST be managed using the Federation Historical Keys Endpoint. - - **Change in Credential Types**: If the credential issuer changes the credential issued, for example deciding not to issue one or more credential types, the related keys MUST be available for the originally designated validity period. + - **Change in Credential Types**: If the credential issuer changes the credential **types** issued, for example deciding not to issue one or more credential types, the related keys MUST be available for the originally designated validity period. - - **Credential Issuers Merge**: If a credential issuer merges with another, the previousòly available federation configuration MUST be available throught both Federation Historical Keys Endpoint and Federation Historical Entity Endpoint. + - **Credential Issuers Merge**: If a credential issuer merges with another, the **previously** available federation configuration MUST be available throught both Federation Historical Keys Endpoint and Federation Historical Entity Endpoint. - - **Credential Issuer Becomes Inactive**: If a credential issuer becomes inactive for any reason, a Federation Historical Entity Endpoint MUST be available, managed by a higher authority. This situation may not only apply to the credential issuer (leaf) but could also occur at an intermediate or root entity level. In such cases the root or trust anchor may be the entity responsible for managing the Federation Historical Entity Endpoint. + - **Credential Issuer Becomes Inactive**: If a credential issuer becomes inactive for any reason, a **related** Federation Historical Entity Endpoint MUST be available, managed by a higher authority. This situation may not only apply to the credential issuer (leaf) but could also occur at an intermediate or root entity level. In such cases the root or trust anchor may be the entity responsible for managing the Federation Historical Entity Endpoint. In the latter scenarios, the root authority, or an entity authorized by the root authority, MUST retain the keys and trust chain end points for a period established by law.