From 20af3d01acee634a190bc516b9a0a8b85e915171 Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Tue, 4 Jul 2023 17:10:57 +0200 Subject: [PATCH] editorial: Roland Hedberg rev --- docs/en/trust.rst | 35 +++++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/docs/en/trust.rst b/docs/en/trust.rst index be7fbc3aa..e7404dec2 100644 --- a/docs/en/trust.rst +++ b/docs/en/trust.rst @@ -12,16 +12,19 @@ This section defines how the Trust Model is implemented in an infrastructure of The infrastructure of Trust enables the trust assessment mechanism to be applied between the parties defined in the `EIDAS-ARF`_. .. figure:: ../../images/trust-roles.svg - :alt: federation portrain + :alt: federation portrait :width: 100% - The roles of the Federation infrastructure, where a Trust Anchor has one or more Intermediates and Leafs and the Intermediates have their Leafs. In this representation both Trust Anchor and Intermediates play the role of Accreditation Body. + The roles of the Federation infrastructure, where a Trust Anchor has as subordinates + one or more Intermediates and Leafs and where Intermediates has Leafs as subordinates. In this + representation both Trust Anchor and Intermediates play the role of an Accreditation Body. Federation Roles ------------------ -All the participants are Federation Entities that must be accredited by an Accreditation Body, except the Wallet Instances that are personal devices and are certified by their Wallet Provider. +All the participants are Federation Entities that must be accredited by an Accreditation Body, +except the Wallet Instances which are personal devices and are certified by their Wallet Provider. .. note:: The Wallet Instance, as a personal device, is certified as trusted through a verifiable attestation issued and signed by its Wallet Provider. @@ -63,7 +66,7 @@ Therein a table with the summary of the Federation Entity roles mapped on the co | | | the Trusted List distributed | | | | over multiple Federation Entities,| | | | where each of these is responsible| -| | | of their accredited subordinates. | +| | | for their accredited subordinates. | | | | | +-----------------------------------------+----------------+-----------------------------------+ | EUDI Wallet Provider | Leaf | | @@ -130,12 +133,14 @@ In the table below there’s the map of the components that the ARF defines with Federation API endpoints ------------------------ -OpenID Connect Federation is similar to a PKI that uses RESTful Web Services secured over HTTPs. OpenID Connect Federation defines which are the web endpoints that the participants made publicly available. In the table below the summary of these and their scopes. +OpenID Connect Federation is similar to a PKI in that it uses RESTful Web Services secured over +HTTPs. OpenID Connect Federation defines which are the web endpoints that the participants make +publicly available. The table below summarises the endpoints and their scopes. All the endpoints listed below are defined in the `OIDC-FED`_ specs. +---------------------------+----------------------------------------------+--------------------------------+-----------------+ -| endpoint name | http request | scope | required by | +| endpoint name | http request | scope | required for | +===========================+==============================================+================================+=================+ | | | | Trust Anchor | | | | | | @@ -170,7 +175,7 @@ All the endpoints listed below are defined in the `OIDC-FED`_ specs. | | | | | +---------------------------+----------------------------------------------+--------------------------------+-----------------+ -All the responses of the Federation endpoints are JWS, with the exception of the **Subordinate Listing endpoint** and the **Trust Mark Status endpoint** that are served as plain JSON by default, however these may be signed if required. +All the responses of the Federation endpoints are in the form of a JWS, with the exception of the **Subordinate Listing endpoint** and the **Trust Mark Status endpoint** that are served as plain JSON by default, however these may be signed if required. Configuration of the Federation @@ -250,7 +255,8 @@ Entity Configuration -------------------- The Entity Configuration is the verifiable document that each Federation Entity must publish on its own behalf. -The Entity Configuration must be cryptographycally signed, and it must be verified with one of the public keys contained within it and one of the public keys within the Entity Statement issued by the Trust Anchor or its Intermediate. +The Entity Configuration must be cryptographically signed. The public part of this key must be present in the +Entity Configuration and within the Entity Statement issued by a immediate superior concerning the Federation Entity. The Entity Configuration may also contain one or more Trust Marks. @@ -306,10 +312,14 @@ The Trust Anchor Entity Configuration, in addition of the common parameters list - JSON Object that describes the Trust Chain bounds and MUST contain the attribute **max_path_length**. It represents the maximum number of Intermediate between a Leaf and the Trust Anchor. - |check-icon| - * - **trust_marks_issuers** + * - **trust_mark_issuers** - JSON Array that indicates which Federation authorities are considered trustworthy for issuing specific Trust Marks, assigned with their unique identifiers. - |uncheck-icon| + * - **trust_mark_owners** + - JSON Array that lists which entities are considered to be the owners of + specific Trust Marks. + - |uncheck-icon| Entity Configuration Leaves and Intermediates @@ -326,7 +336,8 @@ In addition to the previously defined claims, the Entity Configuration of the Le - **Description** - **Required** * - **authority_hints** - - Array of URLs (String). It contains a list of URLs of the superior Entities, such as the Trust Anchor or an Intermediate, that MAY issue an Entity Statement related to this subject. + - Array of URLs (String). It contains a list of URLs of the immediate superior Entities, such as the Trust Anchor or + an Intermediate, that MAY issue an Entity Statement related to this subject. - |check-icon| * - **trust_marks** - A JSON Array containing the Trust Marks. @@ -505,7 +516,7 @@ Each of these can be verified using the Entity Statement issued by a superior, T Each Entity Statement is verifiable over time and has an expiration date. The revocation of each statement is verifiable in real time and online (only for remote flows) through the federation endpoints. .. note:: - The revocation of an Entity is made with the unavailability of the Entity Statement related to it. If the Trust Anchor or its Intermediates doesn't publish a valid Entity Statement, or if they publish an expired/invalid Entity Configuration, the subject of the Entity Statement must be intended as not valid or revoked. + The revocation of an Entity is made with the unavailability of the Entity Statement related to it. If the Trust Anchor or its Intermediates doesn't publish a valid Entity Statement, or if they publish an expired/invalid Entity Statement, the subject of the Entity Statement must be intended as not valid or revoked. The concatenation of the statements, through the combination of these signing mechanisms and the binding of claims and public keys, creates the Trust Chain. @@ -543,7 +554,7 @@ The Wallet Instance presents its Wallet Instance Attestation within the signed r Trust Chain ^^^^^^^^^^^^^^^ -The Trust Chain is the sequence of verified statements that validates a participant's compliance with the eIDAS Federation. It has an expiration date, beyond which it should be renewed to obtain updated metadata. The expiration date of the Trust Chain is determined by the earliest expiration date among all the expiration dates contained in the statements. No Entity can force the expiration date of the Trust Chain to be higher than the one configured by the Trust Anchor. +The Trust Chain is a sequence of verified statements that validates a participant's compliance with the eIDAS Federation. It has an expiration date, beyond which it should be renewed to obtain updated metadata. The expiration date of the Trust Chain is determined by the earliest expiration date among all the expiration dates contained in the statements. No Entity can force the expiration date of the Trust Chain to be higher than the one configured by the Trust Anchor. Below is an abstract representation of a Trust Chain.