diff --git a/docs/en/remote-flow.rst b/docs/en/remote-flow.rst index 07c28afd..52fc1c27 100644 --- a/docs/en/remote-flow.rst +++ b/docs/en/remote-flow.rst @@ -476,7 +476,8 @@ When an SD-JWT is presented, its KB-JWT MUST contain the following parameters in - REQUIRED. Signature Algorithm using one of the specified in the section Cryptographic Algorithms. -When an SD-JWT is presented, its KB-JWT MUST contain the following parameters in the JWS payload: +When an SD-JWT is presented, the KB-JWT signature MUST be verified by the same public key included in the SD-JWT within the `cnf` parameter. +The KB-JWT MUST contain the following parameters in the JWS payload: .. list-table:: :widths: 25 50 @@ -491,7 +492,7 @@ When an SD-JWT is presented, its KB-JWT MUST contain the following parameters in * - **nonce** - REQUIRED. Ensures the freshness of the signature. The value type of this claim MUST be a string. The value MUST match with the one provided in the request object. * - **sd_hash** - - REQUIRED. The base64url-encoded hash digest over the Issuer-signed JWT and the selected disclosures. + - REQUIRED. The base64url-encoded hash digest over the Issuer-signed JWT and the selected disclosures. Revocation Checks diff --git a/docs/en/trust.rst b/docs/en/trust.rst index 2ee1d9a0..a3a12e00 100644 --- a/docs/en/trust.rst +++ b/docs/en/trust.rst @@ -376,6 +376,7 @@ In addition to the previously defined claims, the Entity Configuration of the Le - A JSON Array containing the Trust Marks. - |uncheck-icon| + Metadata Types ^^^^^^^^^^^^^^^^ @@ -462,6 +463,7 @@ The *federation_entity* metadata for Leaves MUST contain the following claims. * - **federation_resolve_endpoint** - See `OID-FED`_ Draft 36 Section 5.1.1 + Entity Statements ----------------- @@ -602,19 +604,45 @@ 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. -Relying Party Trust Evaluation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +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. +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. +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 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 SHOULD be contained within the signed request in the form of a JWS header parameter. +The Trust Chain MAY be contained within the signed request in the form of a JWS header parameter. In offline flows, Trust Chain verification enables the assessment of the reliability of Trust Marks and Attestations contained within. +Establishing Trust with Credential Issuers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +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. + +Trust evaluations implement different ways, as defined below: + +* **Federation Entity Discovery**: Wallet Instances and Relying Parties MUST verify the identity of the Issuer through a Federation Entity Discovery process. This involves querying a trusted list or directory to confirm the Issuer's validity status and compliance with the Trust Framework. + +* **Trust Chains**: Wallet Instances and Relying Parties evaluate Issuer's Trust Chains, be provided statically or build though a Federation Entity Discovery process, to ensure that the entity requesting the Credential is part of a recognized and trusted federation. This involves checking the Trust Chain from the root authority to the Issuer. + +* **Trust Marks Evaluation**: Trust Marks are assessed to ensure ongoing compliance with federation policies. These marks indicate adherence to specific standards and practices required by the federation. + +* **Policy Evaluation**: Continuous evaluation of policies ensures that the Issuer and the requesting entity comply with the latest security and operational standards. + +In the process represented in the sequence diagram below, the Wallet Instance uses the Federation API to discover and collect all the Credential Issuers enabled within the federation. + +.. figure:: ../../images/trust-with-ci-discovery.svg + :figwidth: 100% + :align: center + :target: //www.plantuml.com/plantuml/svg/fPCzRzim48Pt_ef3bavkzWn13DTfXIv1quyboqKynOTIH-9uj9D_NqQ46hkmkaGJGJtty7q5wYORgfKnk8Hgt7D2CVY58P2TR6qwm0mN6oLFOem1kfmBwSK9rMqdgXCZ7Sap6br-rv8DrjBlOgLTSyFg-hewh-2MhD_LrOSCs-gr5zX46VYfA1f7UH10Wuy72c7rM-91BcCYORyQo5D3WCIdo69kqqtQTi8LV2ChAcUr9p5cVljiYdsDMgn6VPtvKgqP1erZI_YF8yIOO8WAXBN3wPY3-XmTqctdhk-jkMo-BuzHFGiQmRsXqKXYJJrCm99Y_W8_CR1_dROTGLBQSomPyfkgP9QdwUtjts1peQ_qaXyaQTop9myi4tSsaoFnplqlGBiqcnsoE8V1e1kEzu1pOm75mm-XvyHAVgdNdSQUoCE1RNUKlEtdx2XaMffTr_msaysmLOsws66TKc3AS1S3ztLnZlb4odjgbsfWmG0Z6NeqF4T_9WFS8mTy30Hlls262iG3-UaISiu5fITtG-BB6Fu0 + Wallet Attestation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/images/trust-with-ci-discovery.svg b/images/trust-with-ci-discovery.svg new file mode 100644 index 00000000..480c3765 --- /dev/null +++ b/images/trust-with-ci-discovery.svg @@ -0,0 +1 @@ +WalletWalletCredential IssuerCredential IssuerIntermediate/Trust AnchorIntermediate/Trust AnchorFetch CI's Entity Configurationat .well-known/openid-federation endpointReturn Entity ConfigurationExtract Authority Hints from CI's Configurationloop[for each Authority Hint]Fetch Entity Configurationat .well-known/openid-federation endpointFetch Subordinate Statementat fetch endpointValidate the previous statementusing the Federation Entity Keysprovided in the Subordinate StatementValidate Trust Chainalt[If Trust Chain is Valid and Unexpired]Proceed with Federation ProcessAbort Process with ErrorApplies PoliciesDerive CI's final metadataGet available Credentials allowed for issuance \ No newline at end of file