[PID/(Q)EAA - SD-JWT parameters ] trust chain

[pietroACN]

Here the parameter "trust_chain" is described as " JSON array containing the trust chain that proves the reliability of the issuer of the JWT. " Link

This parameter doesn't need to identify the whole trust chain but could contain only the identifier (iss) related to the corresponding Issuer. This ID can be obtained by the federation going through the Issuer Trust Chain.

[fmarino-ipzs]

The trust_chain parameter usage aligns with Federation 1.0. Including the entire trust chain allows static verification in cases of absent connectivity.

[peppelinux]

@pietroACN the trust chain jws header parameter allows a trust path that simplifies the trust discovery

a trust chain can be fastly updated without any discovery and also to check any revocation of its subject

while the issuer of the credential is identified within the credential using the claim iss, therefore it is already there, even without the static trust chain within the jws headers

[pietroACN]

The trust_chain parameter usage aligns with Federation 1.0. Including the entire trust chain allows static verification in cases of absent connectivity.

Regardless of static verification, the entire trust chain, from cybersecurity point of view, cannot be simply trusted as provided.
There should be a Trust List.
This list is necessary for the verifier to check that, at least the trust anchor used signatures (confirmation methods) are linked to the root authority.

[pietroACN]

@pietroACN the trust chain jws header parameter allows a trust path that simplifies the trust discovery

a trust chain can be fastly updated without any discovery and also to check any revocation of its subject

while the issuer of the credential is identified within the credential using the claim iss, therefore it is already there, even without the static trust chain within the jws headers

@peppelinux the 'iss' is simply a string that anyone can set. This is not enough to ensure that who's issuing this has any connection with such entity. I need to be sure that kid used is bound to the entity named in 'iss' claim

[peppelinux]

a trust chain is made with attributes and cryptographic bindings, therefore an adversary cannot invent or use an iss.

the kid must match with one of the federation entity keys included in both the entity configuration and its superior's subordinate statements regarding the leaf.

[pietroACN]

The trust chain presence in the header is required to enable offline verification at the condition that the verifier itself has access to root anchors proofs (e.g. public keys) 'locally' (thus without the need of looking up online at this purpose).
Naturally this offline capability from verifier side must be allowed only for a short period of time (e.g. 24hours) to minimize issues related to possible anchor proofs revocations.
The trust chain into the header has a side effect to increase size and complexity of data, that will be needed to be replicated into each attestation, whether the verification happens online or offline.
I would suggest that the trust chain presence not to be mandatory: if it will be missed, offline verification will not be possible.

[peppelinux]

the trust chain in the header enables the fgast renewal of the trust chain, using the source_endpoint parameter contained in each subordinate statement

therefore I suggest to include in the current specs also this section below

Trust Chain Fast Renewal

After detailing the federation discovery process, we now turn our attention to the Trust Chain Fast Renewal method. This approach offers a streamlined way to maintain the validity of a trust chain without undergoing the full discovery process again. It's particularly useful for quickly updating trust relationships when minor changes occur or when the trust chain is close to expiration but the overall structure of the federation hasn't changed significantly.

The Trust Chain Fast Renewal process is initiated by fetching the leaf's (RP's or OP's) entity configuration anew. However, unlike the federation discovery process that may involve fetching entity configurations starting from the authority hints, the fast renewal focuses on directly obtaining the subordinate statements. These statements are requested using the source_endpoint provided within them, which points to the location where the statements can be fetched.

[peppelinux]

This issues will be resolved with a PR introducing the mechanisms though which the out of band mechanisms to obtain the trust anchor's public cryptographic material must be implemented.

sush as eIDAS Trusted List.