diff --git a/adr/EAA-Chaining.md b/adr/EAA-Chaining.md new file mode 100644 index 00000000..6d3a23b3 --- /dev/null +++ b/adr/EAA-Chaining.md @@ -0,0 +1,157 @@ +# 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. +- - The planned WE BUILD trust list extension for EAA Provider will be available only during the WE BUILD project. After the project ends this mechanism will not be availble any longer, therefor EAA Provider will not be able to issue EAAs because the member state will not include the in their national trust lists. + +- EAA providers want to use a key pair generated by her own wallet to issue EAAs. + +EAA provider do not want to: +- use (remote) sealing services of qTSPs for each issuing transaction of all EAA types +- be dependant on Wallet Provider services for each issuing transactions. Once they have purchased an EBW as aproduct they want to be able to issue attestations +- 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 trusted public key transfer mechanism from the issuer to the Relying Parties who need to verify an EAA. Therefore the preferred key transfer mechanism is based on chaining of an an QEAA that binds a public key to the EUID. +- If another key transfer rmechanism is implemented, 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, it is not revocable and is verified later when the EAA Provider has ceased to exist. In such a situation the domain of the EAA provider will not be available when the attestation is verified and therefore the "genuinity" of the Diploma can not be verified. + +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? + +Option 1 is described in the rulebook for basic verification steps that must be performed for all attestations: [https://github.com/webuild-consortium/webuild-attestation-rulebooks-catalog/blob/main/rulebooks/rb-base/verifier-base-verification.md] + +Attestation provider and Attestation verifier obligations are described. The most important steps are the following: + +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: +- WG 5 needs to initiate adjustments to the relevant ETSI standards for the EBWOID +- The We Build EBWOID rulebook must be updated by the EBWOID Provider group +- The EBWOID Provider group needs to update the We Build EBWOID issuance process definition to include the new public key as an additional attribute +- The WUA 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: +- 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) +5. The EBW conformance specification for presenting and verifying attestations must be adapted. The changes need to consider the We Build rulebook describing basic verification steps required for all attestations [https://github.com/webuild-consortium/webuild-attestation-rulebooks-catalog/blob/main/rulebooks/rb-base/verifier-base-verification.md]. This ruelbook also explains in detail how the chained data from the header will be used for basic attestation verification steps. +6. EBWOID providers need to support revocation request with a timestamp from the past. Therefore: + a) Adjustments to the EBWOID rulebook +7. 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? + +- 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) +- Problem 2: Key rotation requires a new EBWOID and therefore external support. +- 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: +- 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? + +- 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: + - The EBWOID Provider group need to define the new attestation rulebook and adapt the issuing process definition + - This certificate must have the same legal value as the EBWOID. Therefore the EU Business Wallet regulation and/or implementing acts may need adaption + - The WUA 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 +- 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) +- The EBW conformance specification for verifying EAAs must specify how the evaluation of the chained data from the header is performed. The following rulebook needs to bensidered in the conformance specification: [https://github.com/webuild-consortium/webuild-attestation-rulebooks-catalog/blob/main/rulebooks/rb-base/verifier-base-verification.md] + +- EBWOID providers need to provide a revocation solution also for the new x.509 “issuing attestation” +- The solution needs to support revocation request with a timestamp from the past. +- EUDI Wallets need to verify EAAs during wallet to wallet communication. Currently it is not clear how EBW owners acting in the EAA Provider role will be identified during EAA verification. The required solution needs to scale for millions of EBW owners + +## 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? +- 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) +- 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: + - …to be added: What legal changes are needed? [Is it realistic to assume that the corresponding legal changes will be performed] +- 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 +- From a Relying Party perspective a presented EBWOID attestation used for identification of the EBW owner reduces the risk of impersonation compared to presented x.509 certificate. The EBWOID is "wallet bound" the x.509 certificate is not wallet bound. + - …to be defined by experts related x.509 certificates. Possible threads: + - Are there problems related revocation of an x.509 certificate? + - Are the interfaces between EBW and the different Europeean QTSP harmonized or does the wallet provider need to deal with proprietary QTSP interfaces? + +How do we address the risks introduced by this change? +We need to request support from legal experts. + +## Final Decision + +Decision 1: By agreeing to this ADR the participants agree that attestation chaining will be implemented by implementing one of the above options. + +Decision 2: Option 1 will be implemented, 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 +3. The EBWOID is a wallet bound issued attestation and therefore more trustable by RP than x.509 certificates + +## 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 diff --git a/adr/mutual_identification.md b/adr/mutual_identification.md new file mode 100644 index 00000000..be5625cd --- /dev/null +++ b/adr/mutual_identification.md @@ -0,0 +1,71 @@ +# Context + +What is forcing us to make this decision? What was the tradeoff? + +1. Perspective of the Holder, Relying Party, Wallet Provider roles + +Perspective of the EBW owner in the Holder role: + +An EBW Owner in the Holder role stores highly confidential data in his EBW (e.g. UBO, Control Structure,...) that need to trated confidential and securely. Therefore a EBW Relying Party request for confidential data will be answered by the holder EBW only after the requesters identity and authorization and also the requesting software authenticity and validity (e.g. based on the WUA, if the request is made by an EBW) was validated by the Holders EBW. + +According to EU Business Wallet regulation Article 14/2/b"...Wallet units shall enable authentication and validation of the wallet unit components by presenting the wallet unit attestations…". + +The wallet unit attestations therefore increases trust in the integrity of the requesting software and significantly reduces the risk of impersonation of the requesting Relying Party. The wallet unit attestation revocation status also shows that the wallet is not revoked (e.g. due to compromise, ...) + +From an holder security, confidentiality and legal perspective the requesters identification should be based on the EBWOID and the requesting software authenticity and components validity should be based on the WUA. Currently an EBWOID and a WUA are issued only to EBWs. Therefore a request made by a software component that is not part of the EBW like for example an "EUDI Wallet Relying Party Component" or an “EBW Relying Party Component" requesting confidential attestations will be ignored by EBW owners due to confidentiality, security and legal concerns. A Relying Party software component is less secure than an EBW. + +Perspective of the EBW Relying Party role: + +Legal entities that already use a Relying Party component software (as defined by eIDAS2.0) for transactions with the EUDI wallet for natural person are interested that also EBW owners answer requests made to an EBW by a Relying Party component. These legal entities are also interested to use the same component as a “EBW Relying Party component” + +Perspective of the Wallet Providers: + +Wallet providers may be interested to offer verification services based o a software component that has no Holder funtionality and does not contain attestations like the EBWOID and the WUA. Therefore they may be interested that identification of the verification component can be done also based on x.509 certificates comparable to the Access Certificate. However such a certificate is not a wallet bound issued certificate and therefore less secure from holder perspective and does not has the same legal value as the EBWOID. + +2. Currently it is not defined how mutual identification between EBWs without human interaction is performed and the "OpenID for Verifiable Presentations (OID4VP) Specification" specifies: + +- "The verifierInfo parameter allows the verifier to provide additional context or metadata as part of the authorization request. The verifierInfo parameter is optional. Wallets MAY use them to make authorization decisions or to enhance the user experience, but they SHOULD ignore any unrecognized or unsupported Verifier Info types." +We need a new verifierInfo type that includes at least the EBWOID and the WUA. This verifierInfo object SHOULD be used to request confidential attestations. + +We may need additional verifierInfo types based on x.509 certificates that can be used + +The verifierInfo parameter MUST be made mandatory to avoid unnecessary denies from holder EBWs due to missing verifierInfo objects. +- We need an interaction specification between relying party and holder EBW backends during a presentation request that does not require human interaction and that includes mutual authentication based on the above new verifierInfo object + +The rulebook for mutual identification and consent handshake referencing also the rulebook for basic attestation verification describes the proposed solution: [https://github.com/flo0x/webuild-attestations/blob/main/rulebooks/rb-base/holder-authorization-handshake.md] +Note: The version available under the above link contains BU1 feedback and will replace the released version currently available under [https://github.com/webuild-consortium/webuild-attestation-rulebooks-catalog/blob/main/rulebooks/rb-base/holder-authorization-handshake.md]. +The two rulebooks describe mutual identification steps and basic verification steps required for all attestations and are part of the BU1 rulebooks. + +# Decision: + +What change did we agree to? + +1. A new verifierInfo type will be defined [Where?]. The new verifierInfo type MUST contain an EBWOID and a WUA attestations. The verifierInfo parameter in an authorization request MUST become a mandatory parameter. +An attestation request for confidential attestations from a Relying Party software MAY be answered or denied by the EBW owner based on his internal policies. + +2. The Wallet Provider group will update the corresponding conformance specification [https://github.com/webuild-consortium/wp4-architecture/blob/main/conformance-specs/cs-02-credential-presentation.md] if the requirements resulting from the above rulebooks and this ADR are not fully included. Key requirements and goals are that a presentation can be performed without human interaction and that a presentation request includes mutual identification based on the above new verifierInfo object and the above rulebooks. + +3. The above rulebooks should be included also in other attestation rulebooks + + +# Consequences + +What becomes easier? + +1. EBW owner will accept to present requested confidential attestations if the request is received from an EBW wallet with the new verfierInfo object according to their internal policies. They will not deny a request simply because the request is made via a Relying Party software. + +2. Attestation request to an EBW backend based on OID4VCP protocols can be received and answered without natural person interaction. That is a mandatory prerequisite for BU use cases for the integration of the EBW in internal systems + +3. We avoid that different rulebooks create different basic attestation rulebooks. The basic verification rulebook also explains how attestation chaining can be used to verify EAAs also after Web Build end. + +What becomes more difficult? + +1. Legal entities that use a Relying Party component will not be able to create the new verifierInfo object because they do not have the EBWOID, the WUA and also no wallet bound attestations. As a consequence several Holder EBW will deny requests for confidential data made through the Relying Party software due to confidentiality, security and legal concerns (e.g. impersonation risk). The same EBW owner probably will answer a request made through an EBW by the same legal entity. + +2. Without a common understanding between use case participants in different role (for example banks that want to use the EUDI Relying party component and their customers) the KyC and also PA3 use case can not be scaled. + +How do we address the risks introduced by this change? + +- The “EBW Relying Party component” is enabled by their providers to receive and store “EBW Relying Party component “ bound attestations like EBWOID and WUA and therefore able to create the verifierInfo object during a request for confidential data. That can be implemented by providing also the holder component to a verifier service, even if the customer of the Wallet Provider uses only the RP component. +- Additional verifierInfo object are defined based on other attestations and certificates that may be accepted by EBW holders for requests that do not require the presentation of confidential data. +- The fact that the use of an EBW wallet for requesting confidential data reduces the risk for the EBW holder must be explained and actively communicated to the RP legal entities that want to (re)use exclusively EUDI Relying Party components