(Q)EAA – domains. How will a verification work in the end?
We can think of various use cases where various (Q)EAA’s could play a role. Obviously, these (Q)EAA’s may fall under different trust domains and may therefore use different trust anchor/lists, as we understood.
What if same area trust domains would even differ between member states? Or new schemes defining the same attribute pop up every now and then, like a certain provider proving an email address via EAA on a locally declared schema?
If this understanding is correct, we fear it will almost be impossible or at least a huge hassle for a RP to handle all possible variation and signup/accept the various trust-schemes.
Shouldn’t a new technical solution embrace that and save processual efforts on the usecases side, therefore rather shift it to the backend processes?
Our idea would be that it needs inheritance starting from a single trust anchor at the EU top level. Each domain then needs to register with its purpose and comply with certain general regulations to be certified via the root certificate. Every (Q)EAA provider of a specific domain, then again needs to register and thereby complies with general as well as the domain specific regulation. Provided (Q)EAA’s clearly fall under a certain domain and hold the inherited trust chain, so in the end each (Q)EAA can be validated only knowing a single trust anchor.
Self-signed EAA which may not be sufficient for certain usecases, would of course be excluded from the above process.