Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

editorial: trust model #48

Merged
merged 8 commits into from
Jul 4, 2023
Merged

editorial: trust model #48

Show file tree
Hide file tree
Changes from 5 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
98f0fad
editorial: trust model
peppelinux Jul 4, 2023
be7b436
editorial: trust model - rewording
peppelinux Jul 4, 2023
cd51dcc
editorial: eidas -> eudi
peppelinux Jul 4, 2023
5a3485e
editorial: roles tables
peppelinux Jul 4, 2023
f9e1929
fix: max_path_length typo
peppelinux Jul 4, 2023
20af3d0
editorial: Roland Hedberg rev
peppelinux Jul 4, 2023
625b2ea
editorial: Roland Hedberg rev - typo
peppelinux Jul 4, 2023
a07e27c
fix: doc8 on trust model
peppelinux Jul 4, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/en/index.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
.. include:: ../common/common_definitions.rst

=============================================
Italian eIDAS Wallet Technical Specifications
Italian EUDI Wallet Technical Specifications
=============================================

Introduction
Expand Down
25 changes: 16 additions & 9 deletions docs/en/trust.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -138,26 +138,33 @@ All the endpoints listed below are defined in the `OIDC-FED`_ specs.
| endpoint name | http request | scope | required by |
+===========================+==============================================+================================+=================+
| | | | Trust Anchor |
| | | | |
| federation metadata | **GET** .well-known/openid-federation |Metadata that an Entity | Intermediate |
| | |publishes about itself, | Wallet Provider|
| | |verifiable with a trusted third | Relying Party |
| | |publishes about itself, | |
| | |verifiable with a trusted third | Wallet Provider|
| | |party (Superior Entity). It’s | |
| | |called Entity Configuration. | |
| | |called Entity Configuration. | Relying Party |
| | | | |
| | | | |
+---------------------------+----------------------------------------------+--------------------------------+-----------------+
| subordinate list endpoint | **GET** /list |Lists the Subordinates. | Trust Anchor |
| | | | |
| | | | Intermediate |
+---------------------------+----------------------------------------------+--------------------------------+-----------------+
| fetch endpoint | **GET** /fetch?sub=https://rp.example.org |Returns a document (JWS) | Trust Anchor |
| fetch endpoint | **GET** /fetch?sub=https://rp.example.org | | Trust Anchor |
| | |Returns a document (JWS) | |
| | |about a specific subject, its | Intermediate |
| | |Subordinate. It’s called Entity | |
| | |Statement. | |
+---------------------------+----------------------------------------------+--------------------------------+-----------------+
| trust mark status | **POST** /status?sub=...&trust_mark_id=... |Returns the status of the | Trust Anchor |
| trust mark status | **POST** /status?sub=...&trust_mark_id=... | | Trust Anchor |
| | |Returns the status of the | |
| | |issuance (validity) of a Trust | Intermediate |
| | |Mark related to a specific | |
| | |subject. | |
+---------------------------+----------------------------------------------+--------------------------------+-----------------+
| historical keys | **GET** |Lists its expired and revoked | Trust Anchor |
| historical keys | **GET** | | Trust Anchor |
| | |Lists its expired and revoked | |
| | |keys, with the motivation of the| Intermediate |
| | .well-known/openid-federation-historical-jwks|revocation. | |
| | | | |
Expand All @@ -173,7 +180,7 @@ The configuration of the Federation is published by the Trust Anchor within its

All entities MUST obtain the Federation configuration before entering the operational phase, and they
MUST keep it up-to-date. The Federation configuration contains the Trust Anchor
public keys for signature operations and the maximum number of Intermediates allowed between a Leaf and the Trust Anchor (**max_path length**).
public keys for signature operations and the maximum number of Intermediates allowed between a Leaf and the Trust Anchor (**max_path_length**).

Below is a non-normative example of a Trust Anchor Entity Configuration, where each parameter is documented in the `OpenID Connect Federation <OIDC-FED>`_ specifications, Section 3.1 for the Federation statements and Section 4 for the Metadata identifiers:

Expand Down Expand Up @@ -513,11 +520,11 @@ The Trust Chains can also be verified offline, using only the Trust Anchor's pub
Relying Party Attestation
^^^^^^^^^^^^^^^^^^^^^^^^^^

The Relying Party is accredited by a Trust Anchor or its Intermediate and obtains a Trust Mark to be included in its Entity Configuration, where it also publishes the interoperability metadata to disclose the requested user attributes. Additionally, it includes signature and encryption algorithms, and any other necessary information in accordance with one or more specific protocols.
The Relying Party is accredited 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 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 contain the verifiable Trust Chain regarding the Relying Party.

The Wallet Instance verifies the Trust Chain related to the Relying Party and its revocation. It does this by using an HTTP request to the Relying Party's federation Entity Statement.
The Wallet Instance verifies that the Trust Chain related to the Relying Party is still active, having the proof that the Relying Party is still part of the Federation and not revoked.

The Trust Chain should be contained within the signed request in the form of a JWS header parameter.

Expand Down