Improve wallet handling

[lgblaumeiser]

WHAT

Wallet calls are done by the provider when downloading the credentials from the wallet and from the consumer when the STS token needs to be created. The idea of this feature to reduce the amount of wallet calls by applying multiple strategies.

1. Remember the availability of a credential on the provider side, by storing which credential has been checked when and for how long the validation is assumed to be valid (e.g., latest and the expiry date, the check becomes invalid, but typically much earlier, like after one or several days). Use this information in subsequent DSP requests instead of always retrieving the credentials.
2. To use the wallet to create the STS token is quite heavy weight, as it is a standard OAuth procedure, which could also be provided by some local thing, close to the connector or even within. Investigate and describe alternative STS token generation approaches which can easily applied in a setup.

WHY

Today, every DSP call ends up in retrieving the credentials from the wallet, checking the credentials according to the relevant policy and move on from there. This results in an awful lot of wallet calls, which increase network traffic and costs.

Actually, the credentials are quite stable, they expire at a certain point in time and they are stable until then. It might be, that they are revoked or renewed prematurely but these are the only expected changes on the credentials. As a consequence it makes sense to think about strategies that reduce the amount of wallet calls.

HOW

1. Store the result of the evaluation locally in the connector, e.g., in a cache. Provide mechanisms to configure the caching period. Adapt the check of the credentials to isolate the credential checking and to use the check result information in the policy engine.
2. Basically, this should already be possible. As the STS token retrieval just uses standard protocols. Still a concept should be developed, that defines steps like documentation needs or potentially things like an implementation of a token extension. An important issue is, that the public key to verify the signature on the STS token has to be part of the DID document.

[lgblaumeiser]

@ronjaquensel @AndrYurk I missed some points we discussed yesterday, would appreciate, if you could add them.