[Satosa Backend] Trust layer abstraction and extensions

[peppelinux]

Requirements

Implementers ...

• The trust layer should be handled with a neutral member nbame, including several other trust evaluation mechanisms. See poi 1 below.
• MUST be able to define their own Classes/Packages and include these within the trust configuration of the satosa backend

Point 1

The current satosa backend configuration is OpenID Federation driven, see below:

  federation:
    metadata_type: "wallet_relying_party"
    authority_hints:
        - http://127.0.0.1:8000
    trust_anchors:
        - http://127.0.0.1:8000
    default_sig_alg: "RS256"
    federation_entity_metadata:
        organization_name: Developers Italia SATOSA OpenID4VP backend
        homepage_uri: https://developers.italia.it
        policy_uri: https://developers.italia.it
        tos_uri: https://developers.italia.it
        logo_uri: https://developers.italia.it/assets/icons/logo-it.svg

We should generalize in this way

    trust:
      federation:
        module: $ClassNameModulePath
        class: $ClassName
        config:
            metadata_type: "openid_credential_verifier"
            authority_hints:
                - http://127.0.0.1:8000
            trust_anchors:
                - public_keys: [ ... ]
                - http://127.0.0.1:8000
            default_sig_alg: "RS256"
            federation_entity_metadata:
                organization_name: Developers Italia SATOSA OpenID4VP backend
                homepage_uri: https://developers.italia.it
                policy_uri: https://developers.italia.it
                tos_uri: https://developers.italia.it
                logo_uri: https://developers.italia.it/assets/icons/logo-it.svg
      x509:
        module: $ClassNameModulePath
        class: $ClassName
        config:
            trust_anchor_certificates: [ ... ]
            trust_anchors_cn: # we might mix CN and SAN together
                - http://127.0.0.1:8000
      direct_trust:
        module: $ClassNameModulePath
        class: $ClassName
        config:
            well_known_metadata_endpoints: [...]
      did_x509:
        module: $ClassNameModulePath
        class: $ClassName
      did_xyz:
        module: $ClassNameModulePath
        class: $ClassName

[peppelinux]

Since we are implementing a Credential Verifier solution, we only need to focus on the way the RP establishes trust with the issuers of the vp tokens, once it obtains them.

This bringsup the evidence that the trust evaluation from the credential verifier perspective starts from the signed tokens provided by the Wallets.

High-Level Tasks for Token Verification

Once the credentila verifier has obtained a token it must met the following steps:

1. Identification of the Token Issuer

   • Extract the issuer from the token payload, eg: iss using JWT.

2. Retrieval of Cryptographic Material for the Issuer

   • **IETF/OPENID:
     • Metadata Retrieval**
     • vc+sd-jwt (discovery): Retrieve in clear JSON format (specified in VC SD-JWT) from the endpoint /.well-known/jwt-vc-issuer; see
     • X.509:
     • vc+sd-jwt (static cryptographic material): x5c parameter: within the JWT protected header
     • Federation (discovery): Processing metadata starting from /.well-known/openid-federation and collecting the entire trust chain untill the final metadata being processed.
     • Federation (static cryptographic material): using the parameter trust_chain within the JWT header parameter
   • ISO 18013-5: Retrieve x509 certificate chain in DER format in an unprotected header of the MSO (Mobile Security Object; COSE Sign1 Document).

3. Selection of the Appropriate Key from the Available Set for this Token

   • Information derived from the header:
     • vc+sd-jwt: kid OR x5c (optionally also DID).
     • federation: kid alone.
     • ISO 18013-5: x509 certificate chain.

4. Verification that the Retrieved Key is Trusted

   • vc+sd-jwt: Third-party trust source/model only in the case of x5c, otherwise direct trust identified with kid (i.e., assumed fetched metadata containing jwks as trusted).
   • Federation: Third-party trust model in federation trust chain.

5. Identification of Root of Trust (Required only in models where a third-party trust exists, hence not needed in the case of direct trust.)

   • vc+sd-jwt using x5c: CA public key obtained with an out-of-band mechanism
   • ISO 18013-5: CA public key obtained with an out-of-band mechanism
   • Federation: Verification made mathcing Trust Anchor Entity Configuration via TLS with Trust Anchor public keys obtained from out-of-band sources (consolidated additional security check against data tampering).

For milestone 0.9 we only wants to have direct trust using sd-jwt-vc, the already implemented part using federation and x.509 can be moved in a component not necessarly for cross-border interop events at this stage.

generally the order in which the trust components are defined might represent the order of priority in processing and discoverying trust with an entity

[Zicchio]

An observation: in the trust layer generalization we can't "just" remove or leave as optional the federation configuration because currently those configuration are also used to publish (trusted?) verifier metadata in the /.well-known/openid-federation endpoint. IMO we should either:

1. Detached vertifier metadata configuration from the trust model configuration, or
2. Leave federation configuration mandatory, but somehow flag that they are not to be used for issuer-signed credential verification, or
3. Other ideas to be welcomed and discussed :)

[peppelinux]

according with the refactor of the trust layer, federation would be necessarly optional

direct trust would be the default one.

1. yes, client_metadata in the presentation request only
2. no
3. direct trust default, federation configured only if explicitly present in the conf. We might think to leave in the conf but not alone, direct trust as well is required for potential LSP

[elisanp]

@PascalDR FYI

[peppelinux]

Resolved by https://github.com/italia/eudi-wallet-it-python/pull/273