Feedback for: Architecture Proposal for the German eIDAS Implementation
Thank you for providing us with additional information and the opportunity to publicly discuss these. In the following I would like to rase seven points, which I noticed while reading the architectural proposal.
-
“The EUDIW shall enable issuance, management and presentation of (qualified) electronic attestations of attributes in a generic manner”. In what case the Wallet issues itself issues another party an (Q)EAA? If the issuance is part of the Wallet it’s a backend service as already mentioned in “PID provider implementation considerations". While I guess it’s meant that the wallet can receive a (Q)EAA, we should stay in the perspective of the Wallet, which we do with “presentation”, but not with “issuance”.
-
“Use Case 3: Besides the standard roles (Wallet, Issuer, Relying Party)”; A wallet is not a role, but a component, which can be used by a holder (“inhaber”) as very well described later in the document.
-
“The Relying Party must register in order to be able to access EUDI Wallets and the authorization to access EUDI Wallets can be suspended or revoked.” RPs at no point have "access” to an EUDI Wallet. They only request data from them. This should be reflected in the language used.
-
Every EUDI Wallet MUST be able to authenticate and authorize RPs registered in any of the EU member states.” What kind of authorization of the RP would be required from a citizens?
-
The document mentions identification and authentication of the RP multiple times. While for the wallet it’s always an identification process, for the user only the first time he or she interacts with the RP it’s an identification. Once the “contact” is established, for the user it’s an authentication mechanism, because he or she already has an interaction history with the RP.
-
User Journey: (Q)EAA Issuance with Authorization Code Flow / (Q)EAA presentation cross device; Screen: “Qr-code scanner”: Nobody opens the wallet to scan the QR-code. Most people will use their camera. Hence, the QR-code should display a deeplink, which can also be interpreted by a phone camera instead of the wallet camera.
-
The user right to report a complaint about an unlawful or inappropriate request of data from an RP described in article 6a) on Page 4 of the latest legislative text should be executable in all PID/(Q)EAA presentation screens independent from who is asking for what information.