As a legal person I want to have a digital wallet and a trust infrastructure which allows me to act in the role of Issuer, Holder and especially Relying Party. In the Relying Party role I want to verify an EAA issued several times ago by an EAA Provider that no longer exists (e.g., he is insolvent) and the corresponding domain is also not available. The holder has paid for the EAA and expects EAA’s content and a trust infrastructure that enables the Relying Party to verify the owned EAA.
An example organizational identity-based scenario that require the requested functionality:
Tax authorities in some EU countries already define taxes for products based on the plastic recycling percentage. A manufacturer has issued an EAA (subject is the product type) to a dealer, attesting the plastic recycling percentage of the product that is exported by the dealer. The tax authority of the importing country receives the EAA in the relying party role and needs to verify the EAA issued by the manufacturer. In the meantime, the EAA Provider and its internet domain no longer exists.
The currently specified Trust Model and the trust architecture has no solution to implement the requirements resulting from the above user story.
Comment on 899/900: “The trust anchors of the PID provider or Attestation Provider are included in a Trusted List”:
If the "EUDI Wallet trust architecture" from Fig. 6 is implemented based on the existing EU Trusted List of Lists then the EAA Provider support is insufficient. Therefore, EUDIWallets for legal persons will not be able to include Relying Party instance functionality to verify an EAA.
The technology of the EU Trusted list of lists is not designed to include all the EAA Providers (all legal persons in EU with an EUDIW) or even the number of trust anchors of the Attestation Providers. Therefore EAA Provider and trust anchors probably will not be included in the Trusted Lists. This is anticipated and explicitly mentioned in line 933: "Non-qualified EAA Providers may be included in a Trusted List, although this is not required. Alternatively, non-qualified EAA Providers may be included in a Trusted List unrelated to the EUDI
Wallet ecosystem but specific to another domain with a domain-specific governance such as for mDLs or other types of EAAs."_
Comment on 938/939: “To help with this, [Topic12] requires that non-qualified EAAs contain the URL at which relevant trust anchor can be obtained”:
If EAA Providers are not included in the “Trusted List” (e.g. EU TLOL) the recommendation is to include them in other Trusted List unrelated to the EUDI wallet ecosystem. (line 934) and that non-qualified EAAs should contain the URL at which relevant trust anchors can be obtained. The two proposed mechanisms will not work in practice due to:
• When the trust anchor, or EAA Provider, has ceased to exists and the corresponding domain is no longer available, the RP will not be able to verify EAAs for which the holder of the EAA has paid. If a qualified TSP (or an QEAA-Provider) ceases to exists, then the Supervisory Body is responsible for enabling verification of issued certificates (e.g QSEAL). This mechanism is not available for EAA-Provider
• There is no incentive for legal entities to become “domain specific trust anchors” and to maintain a “Trusted List”. The missing incentive is also due to the fact that there is an alternative solution available today. The solution was piloted in the LSPs and can be used even if "domain specific trust anchors" are not available in the beginning of the ecosystem: The RP are responsible for “onboarding” trust anchors and EAA Providers. They maintain in their internal IT systems a proprietary trusted EAA Provider list based on their own legal entity policies.
User Story
User: Legal entity in the Relying Party role using the EUDIW legal person that includes Relying Party instance functionality
Goal: Enable EAA verification even if the EAA provider has ceased to exists and the domain no longer exists
Reason: Practical experience from the European Wallet Consortium related supply chain use cases
Acceptance Criteria
A possible solution is described in : "EAA Provider Support for legal person wallets"
Scenario 1: The ARF solution should be rated equal or even better then the proposed solution from the above issue
Description
As a legal person I want to have a digital wallet and a trust infrastructure which allows me to act in the role of Issuer, Holder and especially Relying Party. In the Relying Party role I want to verify an EAA issued several times ago by an EAA Provider that no longer exists (e.g., he is insolvent) and the corresponding domain is also not available. The holder has paid for the EAA and expects EAA’s content and a trust infrastructure that enables the Relying Party to verify the owned EAA. An example organizational identity-based scenario that require the requested functionality: Tax authorities in some EU countries already define taxes for products based on the plastic recycling percentage. A manufacturer has issued an EAA (subject is the product type) to a dealer, attesting the plastic recycling percentage of the product that is exported by the dealer. The tax authority of the importing country receives the EAA in the relying party role and needs to verify the EAA issued by the manufacturer. In the meantime, the EAA Provider and its internet domain no longer exists.
The currently specified Trust Model and the trust architecture has no solution to implement the requirements resulting from the above user story.
Comment on 899/900: “The trust anchors of the PID provider or Attestation Provider are included in a Trusted List”: If the "EUDI Wallet trust architecture" from Fig. 6 is implemented based on the existing EU Trusted List of Lists then the EAA Provider support is insufficient. Therefore, EUDIWallets for legal persons will not be able to include Relying Party instance functionality to verify an EAA. The technology of the EU Trusted list of lists is not designed to include all the EAA Providers (all legal persons in EU with an EUDIW) or even the number of trust anchors of the Attestation Providers. Therefore EAA Provider and trust anchors probably will not be included in the Trusted Lists. This is anticipated and explicitly mentioned in line 933: "Non-qualified EAA Providers may be included in a Trusted List, although this is not required. Alternatively, non-qualified EAA Providers may be included in a Trusted List unrelated to the EUDI Wallet ecosystem but specific to another domain with a domain-specific governance such as for mDLs or other types of EAAs."_
Comment on 938/939: “To help with this, [Topic12] requires that non-qualified EAAs contain the URL at which relevant trust anchor can be obtained”:
If EAA Providers are not included in the “Trusted List” (e.g. EU TLOL) the recommendation is to include them in other Trusted List unrelated to the EUDI wallet ecosystem. (line 934) and that non-qualified EAAs should contain the URL at which relevant trust anchors can be obtained. The two proposed mechanisms will not work in practice due to: • When the trust anchor, or EAA Provider, has ceased to exists and the corresponding domain is no longer available, the RP will not be able to verify EAAs for which the holder of the EAA has paid. If a qualified TSP (or an QEAA-Provider) ceases to exists, then the Supervisory Body is responsible for enabling verification of issued certificates (e.g QSEAL). This mechanism is not available for EAA-Provider • There is no incentive for legal entities to become “domain specific trust anchors” and to maintain a “Trusted List”. The missing incentive is also due to the fact that there is an alternative solution available today. The solution was piloted in the LSPs and can be used even if "domain specific trust anchors" are not available in the beginning of the ecosystem: The RP are responsible for “onboarding” trust anchors and EAA Providers. They maintain in their internal IT systems a proprietary trusted EAA Provider list based on their own legal entity policies.
User Story
User: Legal entity in the Relying Party role using the EUDIW legal person that includes Relying Party instance functionality Goal: Enable EAA verification even if the EAA provider has ceased to exists and the domain no longer exists Reason: Practical experience from the European Wallet Consortium related supply chain use cases
Acceptance Criteria
A possible solution is described in : "EAA Provider Support for legal person wallets"
Scenario 1: The ARF solution should be rated equal or even better then the proposed solution from the above issue
Priority
High:
Estimates
to be estimated by ARF experts