Skip to content

Commit

Permalink
editorial: Roland Hedberg rev
Browse files Browse the repository at this point in the history
  • Loading branch information
@peppelinux
peppelinux committed Jul 4, 2023
1 parent f9e1929 commit 20af3d0
Showing 1 changed file with 23 additions and 12 deletions.
35 changes: 23 additions & 12 deletions docs/en/trust.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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 | |
Expand Down Expand Up @@ -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 |
| | | | |
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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
Expand All @@ -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.
Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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.

Expand Down

0 comments on commit 20af3d0

Please sign in to comment.