EAA provider identity verification based on chaining and TLOL

adr/EAA-Chaining.md

@@ -0,0 +1,124 @@
+# EAA provider identity verification based on chaining and TLOL
+
+**Authors:**
+
+- Werner Folkendt, Robert Bosch GmbH, Germany
+
+**Obsoletes:** Link to other ADR, or remove if N/A
+
+**Obsoleted by:** Link to other ADR, or remove if N/A
+
+## Context
+What is forcing us to make this decision? What was the tradeoff?
+•	The EU Business Wallet regulation formulates the “chaining” requirements in Article 5
+•	Most of the EU member states do not offer the possibility to register millions of EBW owners as EAA Providers in the TLoL. Therefore, the mechanism used by qTSPs to transfer her public keys to EBW Relying Parties via TLoL does not work for EAA Providers.
+•	EAA providers want to use a key pair generated by her own wallet to issue EAAs.
+  EAA provider do not want to:  
+  o	use (remote) sealing services of qTSPs for each issuing transaction of all EAA types
+  o	sign contracts with domain specific identity ledger operating companies (providing also PKI and identity services) especially because such a solution does not scale fast enough for use cases like for example supplier/customer onboarding and is currently not yet available. Currently there are no Qualified Ledger Trust Service Providers available on the market also due to high regulatory uncertainty. 
+  EAA Provider need and want:
+  •	a QEAA that binds the public key to their identity within an identity attestation with the highest legal value. Currently that is the EBWOID. If additional “issuing” attestations are defined with the same legal value also these attestations or x.509 certificates may be used
+  •	A mechanism to transfer the above identity attestation or certificate to the Relying Parties who need to verify an EAA. This mechanism must not require access to the domain of the EAA Provider to access the identity attestation and the included public key. The following example explains the requirements rationale:
+    An EAA (e.g. Diploma) was issued in the past, is not revocable and is verified later when the EAA Provider has ceased to exist. 
+There are two main solution option that implement the above requirements:
+Option 1: 
+The EBWOID attestates also the public key of the EBW owner and is included in the header of each EAA
+Option 2: 
+The EBWOID provider issues in parallel to the EBWOID an additional x.509 “issuing/sealing” certificate in which he confirms that a public key is owned by a legal entity with an unique identifier (e.g. EUID). This attestation has the same attributes as the EBWOID and the additional attribute “public key”. The certificate is used by the EBW owner in a similar way as a CA uses an intermediate certificate. 
+The “decision” and “consequences” section for both solutions are described. That helps to compare the solution and to make a final decision
+
+## Decision for Option 1
+What change did we agree to?
+1.	The seal (X.509 certificate) of the EBWOID Provider must be included in the header of each EBWOID. Therefore:
+    a) Adjustments to the relevant ETSI standards for the EBWOID may be necessary
+    b) The EBWOID We Build rulebook must be updated, currently the header is not described
+2.	The EBWOID must also contain the public key of the EBW owner, thereby ensuring that the binding of this key to an EUID is confirmed by a QTSP when issuing the EBWOID. 
+Therefore: 
+    a) WG 5 needs to initiate adjustments to the relevant ETSI standards for the EBWOID 
+    b) The We Build EBWOID rulebook must be updated by the EBWOID Provider group
+    c) The EBWOID Provider group needs to update the We Build EBWOID issuance process definition  to include the new public key as an additional attribute
+    d) The WIA can be used to confirm the public key for the EBWOID Provider generated by a specific wallet instance
+3.	Each EAA must contain the EBWOID of the issuer in the header. By doing this all data required to identify all issuers in the chain are transferred with the EAA to the relying parties. The EBW of the relying party only needs access to the TLOL to verify the identity of the EBWOID provider.
+Therefore:
+    a) Adjustment of standards also applicable to the EUDI wallet are necessary. At least for the following documents: IETF SD-JWT VC, High Assurance Interoperability Profile (HAIP document update or similar document for business wallets required)
+4.	The EBW specification for verifying EAAs must specify how the evaluation of the chained data from the header is performed (see the attached presentation)
+Therefore:
+    a) Adjustment of EBW specification
+5.	EBWOID providers need to support revocation request with a timestamp from the past. Therefore:
+    a) Adjustments to the EBWOID rulebook
+6.	EUDI Wallets need to verify EAAs during wallet to wallet communication. Currently it is not clear how issuers will be identified during EAA verification. The corresponding standards for EUDI wallets need to be adapted
+
+## Consequences for option 1
+What becomes easier?
+•	EAA provider will be able to issue EAAs without inclusion in any trusted list, therefore a lot of effort and administrative burden is avoided.
+•	The solution can be used immediately after implemented and after the “We Build” LSP ends. Only document changes and EBW wallet code is required. No additional organizations and additional technical infrastructures need to be created.
+•	The ecosystem can scale much faster because no additional contracts between EBW Provider and Trust Registry providers are required 
+•	The identity of the EAA Provider and the identity of his EBWOID Provider becomes verifiable worldwide for each EBW Owner who trusts the TLOL content accessible free of charge.
+•	The identity of the EAA issuers and their EBWOID providers can be verified even if the EAA provider has ceased to exist. That enables non revocable long lived attestations like for example diplomas or material compositions for products.
+•	Delegation for attestations like Power of Representation or Power of Attorney or Mandates issued in natural person wallet becomes very easy.
+
+
+What becomes more difficult?
+1.	Threat 1: Verification requires access to the TLoL or a recently stored copy of the TLOL that may be too big for mobile wallets in embedded devices (e.g. cars, machines, entrance access devices)
+2.	Problem 2: Key rotation requires a new EBWOID and therefore external support.
+3.	Problem 3: Standard referenced by the eIDAS implementing acts need to be extended (no braking changes!)  
+
+How do we address the risks introduced by this change?
+The following extension of solution 1 can solve the above problem 2:
+1.	Each EAA Provider self issues an “Issuing Attestation” which contains the public key of new key pair created by his wallet. The “Issuing Attestation” can be compared to an x.509 intermediate certificate. In the header of the self issued attestation the EBWOID is included. The “Issuing Attestation” is included in the header of each EAA that is signed with the corresponding key.
+
+## Decision for Option 2
+What change did we agree to?
+1.	The EBWOID provider issues in parallel to the EBWOID an additional x.509 “issuing/sealing” certificate in which he confirms that a public key is owned by a legal entity with an unique identifier (e.g. EUID).
+The seal (X.509 certificate) of the EBWOID Provider must be included in the header of “issuing/sealing” certificate. Therefore: 
+  a)	The EBWOID Provider group need to define the new attestation rulebook and adapt the issuing process definition
+  b)	This certificate must have the same legal value as the EBWOID. Therefore the EU Business Wallet regulation and/or implementing acts may need adaption
+  c)	The WIA can be used to confirm the public key for the EBWOID Provider created by the Wallet Provider's WSCD (Web Secure Cryptographic Device). The legal entities private key never leaves the WSCD
+2.	Each EAA must contain the x.509 “issuing attestation” of the issuer in the header. By doing this all data required to identify all issuers in the chain are transferred with the EAA to the relying parties. The EBW of the relying party only needs access to the TLOL to verify the identity of the EBWOID provider.
+Therefore:
+a) Adjustment of standards also applicable to the EUDI wallet are necessary. At least for the following documents: IETF SD-JWT VC, High Assurance Interoperability Profile (HAIP document update or similar document for business wallets required)
+3.	The EBW specification for verifying EAAs must specify how the evaluation of the chained data from the header is performed (see the attached presentation)
+Therefore:
+a) Adjustment of EBW specification
+4.	EBWOID providers need to provide a revocation solution also for the new x.509 “issuing attestation”
+5.	The solution needs to support revocation request with a timestamp from the past. 
+6.	EUDI Wallets need to verify EAAs during wallet to wallet communication. Currently it is not clear how issuers will be identified during EAA verification. The corresponding standards for EUDI wallets need to be adapted
+
+## Consequences for option 2
+
+What becomes easier? 
+All the advantages for option 1 are valid also for option 2:
+•	EAA provider will be able to issue EAAs without inclusion in any trusted list, therefore effort and administrative burden is avoided.
+•	The solution can be used immediately after implemented and after the “We Build” LSP ends. Only document changes and EBW wallet code is required. No additional organizations that operate additional technical infrastructure need to be created.
+•	The ecosystem can scale much faster because no additional contracts between EBW Provider and Trust Registry providers are required 
+•	The identity of the EAA Provider and the identity of his EBWOID Provider becomes verifiable worldwide for each EBW Owner who trusts the TLOL content accessible free of charge.
+•	The identity of the EAA issuers and their EBWOID providers can be verified even if the EAA provider has ceased to exist. That enables non revocable long-lived attestations like for example diplomas or material compositions for products.
+•	Delegation for attestations like “Power of Representation” or “Power of Attorney” or “Mandates” issued in natural person wallet becomes very easy.
+Options 2 specific advantages are: 
+•	Chaining is specified in the standards related to x.509 certificates. Assumption: Option 2 probably has the advantage that fewer standards need to be adapted because the chaining solution does not need to be defined for all the attestation formats (SD-JWT,…)
+•	If an EBW owner want to rotate the keys he does not need a new attestation or certificate form the EBWOID Provider
+
+What becomes more difficult? What are the problems/threats?
+1.	Threat 1: Verification requires access to the TLoL or a recently stored copy of the TLOL that may be too big for mobile wallets in embedded devices (e.g. cars, machines, entrance access devices)
+2.	The new “issuing attestation” MUST have the same legal value as the EBWOID
+The “issuing attestation” will be used by Relying Parties as an identity attestation for verifying EAA Providers identity. Therefore:
+a.	…to be added: What legal changes are needed? [Is it realistic to assume that the corresponding legal changes will be performed]
+3.	EBW Wallet provider need to handle not only x.509 certificate, they need to handle also certificate creation from the intermediate x.509 “issuing attestation” certificate
+4.	…to be defined by experts related x.509 certificates. Are there problems related revocation of an y.509 certificate?
+
+How do we address the risks introduced by this change?
+1.	Request support from legal experts
+
+## Final Decision
+I personally propose to implement option 1 including the above extension that allows each EAA Provider to self issue an "Issuing Attestation", that reduces the need to request a new EBWOID for key rotation.
+The advantages of choosing option 1 are:
+1. Assumption: No legal changes are required to create the same legal value for the "issuing attestation"
+2. EBW Wallet provider don't need to handle x.509 certificate creation
+
+## Advice
+
+Once merged, this is our consortium’s decision. This does not mean all
+participants agree it is the best possible decision. In the decision
+making process, we have heard the following advice.
+
+- yyyy-mm-dd, Name, Affiliation, Country: OK or summary of advice