search

eu-digital-identity-wallet / eudi-doc-architecture-and-reference-framework

The European Digital Identity Wallet
https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/
Other
431 stars 60 forks source link

EAA Provider support for legal person wallets #232

Open wfolkendt opened 4 months ago

wfolkendt commented 4 months ago

Description

As a legal person I want to have an EU Digital Identity Wallet (EUDIW) for legal entities which allows me to act as Holder, Relying Party and also EAA Provider in order to issue attestations to my employees (e.g. company ID, mandates, power of attorney) or EAAs which have an product/object as the subject (e.g. material composition, product carbon footprint) and need to be exchanged in supply chains or with authorities (e.g. tax authorities , notified bodies). As a legal person I have several internal IT systems that contain the authentic data (e.g. human resource databases or product data bases) and that integrate the EUDIW wallet core component (WCC) as a backend system. The EUDIW is used to sign EAAs and to transfer the EAAs to the holder wallets.

Problem Description: As a legal person with an EUDIW I need at least one designated “EAA-Provider”-public/private key pair managed by the EUDIW and a mechanism to enable unknown Relying Parties to get access to my public key and my legal PID (LPID) that attests my legal person identity.

Solution Description based on “EAA Provider-LPID Chaining” mechanism:

  1. The LPID (in SD-JWT-VC format) shall include in the header the x509 certificate chain including the qualified seal certificate used by the qualified trust service provider who has issued the LPID.
  2. The payload of an LPID shall include a public key attribute with a key generated by the EUDIW and attested by the LPID provider. The other mandatory attributes are the EUID and the legal entity name. The LPID Provider may use the Wallet Instance Attestation as the “authentic source” for the public key attribute value.
  3. Each EAA (in SD-JWT-VC format) shall include in the header the LPID of the EAA Provider. 4.The RP will receive all the cryptographic keys required to verify the EAA with the EAA itself.

Significant benefit and advantage of “EAA Provider-LPID Chaining”:

  1. The RP does not need to access data from the EAA Provider domain to authenticate and identify the EAA Provider. Therefore, the mechanism enables EAA verification even when the EAA Provider has ceased to exists and the corresponding domain is no longer available.
  2. The existing EU TLOL does not need to include millions of EAA Providers
  3. The “EAA-provider LPID” can be used in parallel with the “Holder-LPID” that does not contain the public key attribute.
  4. An additional “EAA-Provider-LPID” variant “LPID-qSeal” can be created by including the public key of the qualified seal of a legal entity. This variant enables the parallel use of the qualified seal to seal EAA’s which require the highest legal value
  5. An additional “EAA-Provider-LPID” variant “LPID-kid” can be created by including the “kid” parameter containing a key identifier (e.g. a DID). This variant enables the parallel use of a verifiable data registry that may contain DID documents.

User Story

User: legal person as User Goal: Enable millions of legal entities to become EAA provider simply by using their EUDIW Reason: In several organizational identity use cases of the Europeean Wallet Consortium (EWC) a power of attorney or employee mandate attestation is required. Within the travel use cases the “Hotel Check In” scenario requires

Acceptance Criteria

Priority

High:

Estimates

Has to be estimated by ARF expert group

Presentation that explains the mechanism developed within the European Wallet Consortium (EWC) and the IDunion publicly funded project from Germany: [##https://nextcloud.idunion.org/s/enZDRWaTMtXttWM] For additional questions please contact: werner.folkendt@de.bosch.com

digeorgi commented 2 days ago

Thank you for your input. We agree that the ARF should provide clearer guidance on the definition of a legal person and its implications for attestations and wallets used by legal entities. For example, it should clarify whether legal-person wallets must be controlled by natural persons and better address the delegation process—specifically, when to issue an attestation to a legal person versus authorizing a natural person to represent them.

However, we must stress that your suggestion for a legal-person wallet to function as a Holder (User), Relying Party, and EAA Provider is not aligned with the Regulation. Additionally, the development of the legal-person wallet concept is still in progress within the ARF, and further details will be addressed in future updates.