CryptoVision v2 Support

[StefanKert]

Since the CryptoVision v2 has been released (https://www.cryptovision.com/de/cryptovision-tsev2-erhaelt-bsi-zertifikat/) we should validate which changes we do need to make the Middleware work with the new firmware.

This issue should summarize the necessary steps and design decisions that we are making for adding support. As a first step we need to analyze the new interface description and compare it to our current implementation to see which changes are required.

Beside that we will need to check if there are any conceptual changes to the v2 and if we are still able to use File I/O the way we are currently doing it.

Todos

• Analyze new documentation and compare with current implementation
• Check if the current implementation will be extended or if we should create a new package
• Prepare documentation on how to switch v1 to v2
• The new legislation requires us to collect info on the connection to the so called Sperrliste we should check how we can get this information

[TSchmiedlechner]

Hi @StefanKert, thanks for the summary! 💯
In general, I'd prefer if we could re-use the existing SCU and maybe support both versions (unless they are technically very different, ofc). We received several questions about our reasoning with the different SCU for fiskaly v2 back then - and while I think this was the right decision for this TSS, I'd also not be sad if we could avoid that 😄

In addition, it might generally make sense to discuss how we can make the SCU switch more pleasant to use. I'll create a discussion about this topic (#147).

[StefanKert]

One thing that we should keep in mind when reusing the existing package is that the switch to the new version is not 100 percent explicit.

IMO there are two main cases that we should take in consideration:

• The packagename itself. Mainly important during the rollout
• The SCU during runtime.

The first one is IMO just a matter of communication. Initially I was thinking that it might make sense to have a new packagename to make the switch more explicit and to prevent users from making too many mistakes during the switch operation. I guess this could be also making things more complicated 🤔. A con for the nameswitch would be the requirement to change all existing templates.

For the second one, I am not sure if you would put that also in the same SCU during runtime or if you where just talking about having the same Package being delivered.

[TSchmiedlechner]

I agree with the thoughts on the first point 👍 IMO the advantages of the same name outweigh the disadvantages a bit, but that's just my opinion ofc. 😄

Not 100% sure what you mean with the second point, sorry

[paulcristiann]

Hi everybody, I analysed the new interface and have some initial findings.

Todos

• Analyze new documentation and compare with current implementation

• Check if the current implementation will be extended or if we should create a new package
  I would argue for extending the current SCU implementation and to approach a feature flagging mechanism for some functions in order to know they are only available on new hardware. I would also suggest we find a way to query and know the hardware version at runtime.

• Prepare documentation on how to switch v1 to v2
  I prepared a document with my findings and an action plan for the transition.

• The new legislation requires us to collect info on the connection to the so called Sperrliste we should check how we can get this information
  I was thinking that the first step for integrating this would be to get infos regarding the signature key from the module and store them as part of the cash register bundle.

changelog_proposal.pdf

[StefanKert]

Hi @paulcristiann ,

thanks for the summary of the changes :) that looks great. Also the proposed changes LGTM. IMO we should get started with implementing the breaking changes / changes in behavior and s soon as we have a running prototype we can think of adding the new methods. @mijomilicevic can you probably take a quick look at the new capabilities that Paul has listed in his document? IMO most of these functionalities don't have a lot of value for us.

[mijomilicevic]

Hi @paulcristiann,
thank you for sharing your findings, really looks great :) I agree with @StefanKert that we should start with implementing the breaking changes and then think about adding the newly added functions.
When looking at your document, IMO there is no real "must have" among the newly added functions, but I will double-check with the Pos Creator Experience Team and come back to you. Thanks again for all the preparation work!