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.

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

Extend/expand the involvment of trust in the (functional) tests #360

Open
Zicchio opened this issue Feb 7, 2025 · 0 comments
Open

Extend/expand the involvment of trust in the (functional) tests #360

Zicchio opened this issue Feb 7, 2025 · 0 comments

Comments

@Zicchio
Copy link
Collaborator

Zicchio commented Feb 7, 2025

Currenlty functional tests like this one https://github.com/italia/eudi-wallet-it-python/blob/dev/example/satosa/integration_test/same_device_integration_test.py works in the following way:

  1. a docker container with the configured satosa backend (RP-Verifier) must be up and running (we assume that it is this one https://github.com/italia/iam-proxy-italia ).
  2. a python script simulates the interaction between the user device(s) and the RP, in particular it simulates:
    2.1 the interaction between the service and satosa
    2.2 the interaction of the Wallet-Holder with the pyeudiw module (RP-Verifier).
  3. the PID Credential Issuer is not properly simulated in any way:
    3.1 we assume that the wallet somehow got good credential like a valid sd-jwt (this is ok as going further is clearly of out scope from the RP viewpoint), and
    3.2 we assume that the RP-Verifier magically has a copy of the PID Issuer public keys (as produced by the trust evaluation mechanism), which are inserted in the cache.

Point 3.2 is very brittle as the funcitonal tests basically never tests the working of the interactions between the RP and the credential Issuer, in particular; current functional tests never verify the correctness of any trust evaluation mechanism that involves the PID credential issuer.

IMO to have a full funcitonal test we should probably mock all external dependencies and not just assumme that the interaction with them magically worked in a previous interaction.
This is not very easy, but some issues like #341 and #340 (which were observed in testing with out partners) might be the result that there not enought tests with the trust module.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant