OBG behaves diffently for HBCI and SCA - how can client know what to do?

Currently API of OBG offers two ways of "consent reusage". For xs2a its ok to send PSUSessionID. If consent is available, it will bereused and consent is retrieved without ConsentUI interaction.
As FintechServer currently has no idea which protocol is used, it does the same for HBCI Bank. But in this case, once list of accounts have been retrieved, sending the PSUSessionID results in error in OBG Server.
And switching on Settings Option of FintechUI
TRUE "Discard propably existing consent ONE TIME ONLY"
TRUE "Use protocol cache of TPP Server"
result in another OBG error. Only Setting both options to first option to false and second to true results in ok
FALSE "Discard propably existing consent ONE TIME ONLY"
TRUE "Use protocol cache of TPP Server"
So it looks like PSU ID has to be send AND Option use Cache too. Otherwise Exception is thrown.

This was tested with real bank. Log with test bank will follow.

From bankingProfile client knows if consent is supported or not. Is this sufficiant to decide what to do. If yes, would rule look like this?

`consent supported -> (xs2a)
always send psuSessionID (if available), always ignore TPP Cache Flag
consent not supported -> (HBCI)
when sending psuSessionID send TPP CacheFlag TRUE
never send TPP CacheFlag false when PsuSessionId is not available.
`
If this is ok, the logic should be hidden in FintechUI. It should take place in fintechServer.

Start by tracing consent handling between FintechUI and fintechServer, using the bankingProfile, PSUSessionID, and TPP Cache Flag behavior described in the issue. Compare the xs2a and HBCI paths and confirm the expected rule with a test bank; done means the client can select the correct settings without triggering an OBG error.

Escrito por el modelo de indexación a partir del texto del issue.