Add masking overlay to integration tests

[mitfik]

After testing masking with Kime we would need to add proper values and integration test.

[blelump]

@mitfik , we'll do further refactor a bit and join exactly the same overlays (including masking overlay) in order to not have too much boilerplate. However, we're not sure how to interpret the value for masking overlay, I mean "PA_pseudo". Should it execute somehow?

[mitfik]

@blelump
for time being is just a STRING which represent name of the attribute. Currently we are not sure how to link to that algorithm and where it could be stored. Especial that there can be hundreds of them. The idea is that whatever it would be there is should allow to resolve it in a way that the machine can interpret it.

E.g.

Identity request coming into the wallet asking for data about your driving license, schema include masking overlay which tells that they don't need your full date of birth but mask it up to the year.

So your wallet is able to understand the request and then use mentioned algorithm to mask the data and provide it to the requester. The easiest way to achieve that would be to have a list with all available algorithms which wallet could implement and everyone would stick to that but there is so many combination of that that is hard to keep that list up to date. That is the challenge to solve.
Maybe within masking overlay there would be some magic "progolog" code which can be evaluated by wallet - but then it expose wallet to some various attacks.

[blelump]

@mitfik ,
perhaps the masking overlay is unimplementable then in the proposed shape. As you've mentioned, you can't provide solution OOTB for all the possibilities you even currently don't know.
Masking sounds like an application of an additional filter, like a post-query data transformation (a very simple transformation). So perhaps this overlay would contain a supported data transformation function that will be able to resolve the data into appropriate shape. We'd then support a few functions that will cover most of the use cases and use some popular / known function source, ie. Excel/LibreOffice Calc, say: REPLACE, SUBSTITUTE with regex support for geeks.

[mitfik]

I agree with the list we won't be able to achieve the goal. Seems that without DSL we won't be able to solve the problem. Maybe we could do a research to see if there is any existing DSL which we could support. I will ask Jan to find out a bit about that space. If nothing exist we could design own but we need to remember that sometimes those functions will be run on vast amount of data.