Review: Universal EUDIW Bank API

[cyberphone]

At the time of writing, the interfacing of EUDIW based services to banks remain unresolved.

To cope with this major obstacle, a joint proposal by one of the LSPs and the Berlin Group is currently in an evaluation phase. The proposal is said to be based on messages secured by SD-JWT. Although I haven't seen the actual proposal, my experiences with "universal" solutions in an ever-changing world makes me believe that this may not be what we are looking for. The following is a kind of high-level peer review of the proposal on a conceptual level.

• Digitally signed messages, regardless of format etc. do not come with built-in semantics. That is, the verifier (in this case the Bank), must know in advance what the purpose of a message is in order to process it correctly.
• If we consider TPP-based payment initiations, TPP-signatures are unlikely to be based on SD-JWT. In EMV-like scenarios, such messages would rather hold an embedded EUDIW-based user authorization object which could be in SD-JWT format.
• Although user authentication and payment authorization could [maybe] use the same format, the actions performed are entirely different.
• Why would payment authorizations use selective disclosure (as provided by SD-JWT)? This is probably the result of mixing user-related data like "over 18" attestations with payment authorization data. However, it should be possible to in a UX-friendly way deal with non-payment data before the actual payment authorization. Loyalty cards more or less require this separation, because loyalty may affect the price of purchased items as well. Mixing non-payment data and payment authorizations also impacts the design of the EUDI wallet. Separation of duties reduce complexity and provide a consistent UX, albeit maybe at the expense of an additional "click" or two. Actually, a slightly smarter wallet could when asked for a loyalty card remember the user's choice to make this operation transparent for future purchases. This (of course) requires that loyalty cards are bound to domains like ikea.com in similarity to FIDO keys.

[david-bakker]

Thanks for your comments and our apologies for not answering sooner.

In ARF 2.3.0 (the latest version as of today), the only 'EUDI Wallet-based services to banks' envisioned is in Strong Customer Authentication / Strong User Authentication. This is discussed in Section 2.6.4 of the ARF main document and in Topic 20 in Annex 2.

With that in mind, please allow us to react to each of your points:

• We agree. The semantics of both the transactional data included in the presentation request and the signed data in the presentation response must be specified in the Attestation Rulebook of the relevant SUA attestation (i.e., the attestation that was requested).
• Indeed, the 'authorization object' in the response message from the Wallet Unit is signed by the WSCD in the Wallet Unit, not by the Attestation Provider. The private key used for signing corresponds to the public key in the SUA attestation, and is therefore attested to by the Attestation Provider. However, this does not mean that SD-JWT VC or ISO/IEC 18013-5 can therefore not be used. In fact, both of these specifications make it relatively easy to include data signed by a WSCD, since both already use such a signature for device binding (= 'key binding' in SD-JWT VC and 'mdoc authentication' in ISO/IEC 18013-5.)
• We are not sure what you mean by 'entirely different'. Note that in a 'standard' attribute presentation flow, User authorization is already needed for the presentation of the requested attributes; the ARF calls this User approval. This mechanism can easily be extended by including data sent by the Relying Party (the merchant or bank, depending on the use case flow) in the message shown to the User by the Wallet Unit UI. Of course, a prerequisite for User authorization is User authentication. User authentication by the Wallet Unit is discussed in section 6.5.3.3 of the ARF main document and in Topic 40 of Annex 2.
• Your last bullet touches different topics:
  • Why would payment authorizations use selective disclosure? -> Because this a fundamental feature of the EUDI Wallet ecosystem and the ISO/IEC 18103-5 and SD-JWT VC standards used in that ecosystem. There is no reason to use a different standard for the payments use case only.
  • We are aware of the UI and UX aspects of payment transactions. However, the ARF delegates such aspects to the respective Attestation Rulebooks. Since the authors of such Rulebooks will have a background in the payments industry, they are better suited to specify such aspects than the EC.
  • Both ISO/IEC 18013-5 and OpenID4VP allow multiple attestations to be requested and multiple sets of transactional data to be sent in a single presentation request. This could indeed loyalty cards, age attestations, etc. Of course it is also possible to send multiple requests in a single 'session'. In other words: a lot is possible, depending on what will be specified in the respective Attestation Rulebook.

Closing this comment because it is rather old already. If you want to react to the specifics requirements in the ARF on this topic, please open a new issue.