Feature Storage and Trust package refactoring (#284)

[peppelinux]

• fix: variable name for more redability

• fix: use already existent functions for unsafe parse

• fix: wrong key

• feat: decode_jwt_element refactoring

• chore: removed unused functions

• fix: merged functions

• fix: find_vp_token_key refactoring

• test: added tests for jwt package

• fix: added boundary check

• feat: added as_public_dict

• feat: refactoring

• tests: added federation to the config

• chore: added todo

• feat: implemented methods for trust source

• fix: method name

• chore: module initialization

• feat: implemented TrustSourceData model

• chore: initialized module

• feat: implemented TrustHandlerInterface

• feat: initial implementation of metadata handler

• fix: class name

• feat: initial implementation of DirectTrustJWTHandler

• feat: refactoring of CombinedTrustEvaluator

• Update pyeudiw/jwt/verification.py

• feat: added trust source methods and refactoring

• feat: merged implementations

• chore: moved type

• chore: updated config

• fix: update mongo tests

• fix: fixed model

• chore: removed unused code

• chore: removed unused function

• chore: string interpolation

• feat: dinamyc backend refactoring

• feat: updated inteface

• feat: added dummy Federation handler

• fix: CombinedTrustEvaluator instantiation

• tests: added tests for trust module

• fix: parameter handling

• chore: removed unused files

• feat: db code refactoring

• feat: migrated tests

• fix: minor fixs

• chore: removed unused code

• fix: handle exception properly

• fix: test

• feat: complete refactoring of satosa backend tests

• fix: key handling

• feat: added error class

• chore: fix for test passing

• feat: integrated tests

• feat: merged implementations

• fix: display error message

• fix: possible fix to sd_hash (needs more checks)

• fix: collection name

• fix: minor fixs

• fix: test

• chore: remove unused (to re-integrate)

• feat: helper function

• fix: test

• fix: empty behavior

• Update pyeudiw/sd_jwt/sd_jwt.py

• Update pyeudiw/openid4vp/vp_sd_jwt_vc.py

• Update pyeudiw/storage/db_engine.py

• Update pyeudiw/tests/trust/test_dynamic.py

• fix: naming

• chore; added integration test in CI

• fix: path

• fix: escaping

• fix: added dependency

• Apply suggestions from code review

• feat: upodated and refactored trust package

---

[peppelinux]

this should be implemented also in the base_storage

[peppelinux]

please use a more eloquent error message

[peppelinux]

Suggested change

[peppelinux]

Suggested change

	DEAFAULT_JWK_ENDPOINT = "/.well-known/jwt-vc-issuer"
	DEAFAULT_METADATA_ENDPOINT = "/.well-known/openid-credential-issuer"
	DEFAULT_SDJWTVC_METADATA_ENDPOINT = "/.well-known/jwt-vc-issuer"
	DEFAULT_OPENID4VCI_METADATA_ENDPOINT = "/.well-known/openid-credential-issuer"

[peppelinux]

ENV vars should be included in the docs, in a section about env vars

[peppelinux]

Suggested change

	jwk_endpoint: str = DEAFAULT_JWK_ENDPOINT,
	metadata_endpoint: str = DEAFAULT_METADATA_ENDPOINT,
	jwk_endpoint: str = DEFAULT_SDJWTVC_METADATA_ENDPOINT,
	metadata_endpoint: str = DEFAULT_OPENID4VCI_METADATA_ENDPOINT,

[peppelinux]

Suggested change

[Zicchio]

I think that this function

eudi-wallet-it-python/pyeudiw/jwt/parse.py

Lines 49 to 57 in 5c3c95e

	def extract_key_identifier(token_header: dict) -> JWK | KeyIdentifier_T:
	# TODO: the trust evaluation order might be mapped on the same configuration ordering
	if "kid" in token_header.keys():
	return KeyIdentifier_T(token_header["kid"])
	if "trust_chain" in token_header.keys():
	return get_public_key_from_trust_chain(token_header["kid"])
	if "x5c" in token_header.keys():
	return get_public_key_from_x509_chain(token_header["x5c"])
	raise ValueError(f"unable to infer identifying key from token head: searched among keys {token_header.keys()}")

should be clearly delegated to the trust model implementation(s). Not only the key identifier might not exist in some trust model, but the methods stubs get_public_key_from_trust_chain and get_public_key_from_x509_chain clearly reference functionalities that only trust implementations can provide.
This is not a minor detail! The lack of this functionality, in the current code, actually BLOCKS ANY token verification method to ever work in any model different that direct trust.

We tried to provide a one and only trust evaluator that is completely agnostic to the token representation, but IMO this cannot work. This is also hinted in this exception, which is basically impossible to overcome as the given function is completely detached from any object ably to parse or vallidate a trust source (i.e. trust proof/attestation)

eudi-wallet-it-python/pyeudiw/tools/jwk_handling.py

Line 28 in 7330f41

raise NotImplementedError("TODO: matching of public key (ex. from x5c) with keys from trust source")

Moreover, only a the trust model can know which parts of a token header can be treated as trust attestation or proof that a public key is valid, hence a I am keen to conclude that the trust model SHOULD be able to parse token headers . For example, only a federation trust model can know the fact that it can find relevant information in, say, the claim trust_chain of a token header.

I think that it is best to catch two birds with one stone. The trust aware interface (TrustHandler, TrustEvaluator or whatever it might be called) might implement a functionality similar to the following.

class TrustEvaluator:
....
    def obtain_signing_key(self, issuer: str, token_header: dict) -> dict:
    """Find a public signing key of the issuer that can be uniquely referenced and trusted
    based on the content of the given token header it might verify.
    """

we could also work a more abtract and modular description that emphasize the trust attestation / proof / source, such as

....
    def obtain_attestation_from_token_header(self, issuer: str, token_header: dict) -> dict<trust_attestation>:
        ...
    def obtain_public_key(self, issuer: str, trust_attestation: dict) -> dict:
        ...

but the core idea is the same: the trust implementation should be able to parse and process token header in order to yield valid cryptographic material for that token.

I don't love the conclusion, as it basically means that we might struggle in extending the project if/when we need to process verifiable credentials that are not in the form of a sd-jwt, but I honeslty fail to see a way to overome these issues.

@peppelinux waiting an input on the topic by you.

[Zicchio]

Commenting to note that something unexpected happened here.
The file sd_jwt/__init__.py has been emptied when tackling #281 (which has been tagged as closed), but unit tests that relied on that code have not beed fixed or updated.
Until then, the CI pipeline is broken.

For exmaple, all these imports

eudi-wallet-it-python/pyeudiw/tests/satosa/__init__.py

Lines 12 to 17 in 1e97344

	from pyeudiw.sd_jwt import (
	_adapt_keys,
	issue_sd_jwt,
	load_specification_from_yaml_string,
	import_ec
	)

will fail, and so will the expressions that rely on those imports.

We should either reopen #281 or somehow handle failing unit tests.

[peppelinux]

Closed in favor of #315