Online setting of account parameters, parameters of client's authenitcation etc. – shall be the most protected, for the attacker not to be able to bypass strong authentication by tampering with the settings (e. g. pairing other security device replacing customer’s one, phone number change etc.).

We consider data as a possession element. As an example we can provide certificate saved in a file (*.p12, *. pfx extensions), in a browser or in a secured storage as a part of strong authentication.
Data (e.g. certificates in files) are stored on clients’ devices like USB stick, PC, etc. and it is users’ responsibility to protect these files/data from stealing or copying. Users’ education is needed to explain that these data can be provided only on trusted sites of PSC issuer (bank). It will be crucial to solve authentication processing when initiating payment by 3rd party provider, so that user will provide credentials only on trusted sites of PCS issuer and they are not in possession of 3rd party.

Regarding to credentials stored in a mobile devices - mobile device with secret stored in app’s internal storage on condition that operating system ensures confidentiality in reasonable way (applications are not allowed to read other application’s data).

When providing online services we always need to balance between user friendliness and security. We would like to use behavior based characteristics of transactions as a part of decision mechanism regarding to level of authentication. If a sophisticated mechanism decide, that the transaction is reflecting typical behavior of a client we do not want him to bother with complicated strong authorization mechanism.

Regarding to possible practical implementation - behaviour-based characteristics shall be checked in trusted environment controlled by bank. Liveness shall be ensured e.g. by random challenge (when possible). E. g. user shall say or type given random phrase that is unlikely to be said/typed and recorded in real-life scenario.

Independence shall be considered with respect to circumstances (i.e. independent under ordinary circumstances).

Under ordinary circumstances, both shall be considered independent:
• physical key (possession) and combination lock sequence (knowledge) to open a safe
• encrypted secret (possession) stored in internal storage of mobile device and password (knowledge) used to decrypt the secret used to authorize a payment

An attacker can indeed apply force either against the authorized person or against the device (malware) to gain access. In both cases these acts of violence be considered as extraordinary circumstances.

There can be some troubles when using some specific solutions such as an offline OTP tokens. Offline OTP tokens are based on time synchronization without transaction linking.

Proposed strong customer authentication is Retail-centric. It does not propose a solution for batch payment processing common in Corporate domain.
E.g. how would you present information for 10 000 transactions being signed in a batch? We believe that e.g. SHA256 digest can be introduced as another possibility for dynamically binding the OTP with transaction.

Conclusion: We suggest to allow in specific cases allow ASPSP not to ensure dynamic linking when considering other aspects of respective activity or parameters of transactions (low value payments, low risk payment evaluated by fraud detection system, batch payments etc.)

Example:
1. Mobile device stores secret which counterpart is stored server-side (e.g. private and public key).
2. Secret is stored in encrypted form. Encryption/decryption key is derived from user password (PIN). Password derivation and encryption schemes are built so that wrong PIN allows decryption, decrypted secret is wrong and this fact cannot be validated without communication with server.
3. During operation authorization, user is asked to enter the PIN which is used to decrypt the secret in run-time.
4. Secret is used to sign the key operation data (payee, amount …) displayed to customer (What you see is what you sign principle, abbr. WYSIWYS), together with operation identification (random id, timestamp).
5. Signature together with operation data is sent to the back-end system.
6. Back-end system validates
• the signature of received operation data (integrity check)
• operation identification (to prevent replay attack)
7. If signature is valid, back-end system performs the operation

Fulfilled objectives:
• Dynamic linking: received signature is valid only for operation data displayed to customer and confirmed by himself (WYSIWYS).
• Independence:
o Device itself (e.g. stolen) cannot be used –encrypted secret is useless without PIN. Brute-force attack (guessing PIN) cannot be performed without interaction with back-end system, which is thus able to detect the attack and block the compromised device.
o Password itself (e.g. disclosed by accident) cannot be used – even if the attacker would be able to perform client-side authorization logic, he is not able to generate a valid signature without customer’s secret stored on mobile device.
While in use for 3 years, there is no report of single incident compromising security of this scheme.

We prefer some kind of a list of examples rather than exhaustive list of possible exemptions. ASPSP should be able to decide whether strong authentication is needed or where are risk covered by other methods. For example if ASPSP is making huge investments into ensuring of clients end-points protection, detection mechanism of fraudulent activities and clients’ education, than it should be allowed to use weaker authentication (to deliver comfort and client friendliness) as whole chain of payment entering and processing is secured in other segments of transaction processing.
Other point of view is to let clients decide what level of security they prefer. There are segments of clients which prefer user friendliness to security when accessing particular services (e.g. passive view of the account where there is no risk of fraudulent transactions, automatic download of statements secured by password only, e-mail enclosed statements without password protection (popular among students))

The biggest issue is an authentication process when initiating payments using newly defined payment initiation service. It is not acceptable to allow a payment service user (PSU) to provide credentials issued by his bank to any 3rd party. PSU are continuously educated to provide credentials only on a trusted website of his bank. If it would be allowed to provide credentials on 3rd party webpages, it will completely confuse PSU and it will pave the way for fraudsters pretending to be certified 3rd party PIS provider. Current typical phishing vector is to redirect clients to fake “payment gateways” and to gather their credentials. We are educating clients that these types of gateways are fake and learn them not to provide credentials on these types of webpages. We have also noticed first confusion of clients related to these types of services. A client notified bank about possible fraudulent webpages gathering credentials, after investigation the bank has found out that this was a service of payment service provider (Sofort), which is using some kind of credentials redirection model. This is a typical example of the confusion of clients.
There must be invented some process of clients authentication chain (PSU – 3rd party - bank) where clients are providing credentials on banks’ websites. Otherwise clients’ credentials would be considered as potentially compromised and bank would have to focus on another part of payment security chain (typically fraud detection systems). Then also it becomes meaningless require strong authentication as it is inherently complicating authentication of payments.

Regarding enrolment via PISP/AISP (pairing account in PISP/AISP application to bank account), we see two options:
• Each time customer accesses his PISP/AISP account, PISP/AISP redirects him to PSP’s infrastructure for authentication. Successful authentication leads to access token issue that grants third party application time-limited access to account.
• Almost the same, but long-term and not automated: In application controlled by PSP (e. g. Internet Banking), customer grants access to certain PISP/AISP. Application generates a single-purpose token and customer gives this token to PISP/AISP. PISP/AISP uses this token for authentication for limited time. User can revoke the token any time in application controlled by PSP.

Alternative is to consider third parties to be untrusted. Then, every authentication and authorization of operation shall occur in environment of PSP and therefore is independent on third party. E. g. customer initiates payment in PISP, payment order is sent to PSP which continues in authorization as if it were a payment initiated in its own system. Customers authorizes the operation having full detail displayed in trusted environment.

The weakest point of the whole chain is a client/payment service user. Comprehensive education related to cybersecurity and prudent behavior on internet is needed. As already mentioned, the biggest issue would be to explain authorization of payments when using payment initiation services to not well educated PSUs who would be the most vulnerable segment endangered by phishing, malware and other threats

Topic b. has two sides – legal and technical. The technical standard needs to enforce a concrete AIS/PIS identification in the request and digital signature of these requests. The legal side of entrusting AIS/PIS should be either left to ASPSPs (legally neutral alternative) or should enforce a contractual consent by the end customer (account owner) for a concrete AIS/PIS (legally strict alternative). The rationale behind is that we are talking about banking secrecy and end customer funds. The access needs to be given to AIS/PIS based on an agreement with the end customer.
Topic c., d., e., and f. need to be defined. By default, obsolete technologies should be banned – such as SHA-1, MD5 in case of hashing algorithms, anything less the TLS 1.1 for a connection setup.

Ad D]
A unified common standard needs to be defined on the EU level. This would ensure at least standard one way for AIS/PIS to be integrated with ASPSs. The standard should ensure an option for direct connection between AIS/PIS and ASPSPs so AIS/PIS are not forced to use “services” of some central integrator. On the other hand, central integration concept needs to be supported as an option.
In case, that AIS/PIS would have a unique solution he could address ASPSs directly or get integrated via a central integrator.
It would be beneficial to include an option to make the payment guaranteed. The common standard could be then used as a unified alternative for eCommerce payment button solutions.
It would be benefical to include an option to make it a fast payment. The common standard could be then used as a unified alternative for eCommerce payment button solutions.

Let us consider minimalistic strictly defined API defining:
• just two operations: basic payment initialization and basic account history fetch
• request/response message data model for both operations (e. s. taking essentials from ISO 20022 vocabulary
• representation of these messages (e. g. in form of JSON objects)
• transport protocol (e. g. HTTPS)
• authentication and authorization schema where these security aspects are relayed to ASPSP infrastructure (e. g. via OAuth standard)

Pros:
• Any PISP/AISP is able to develop single API client to interact with any bank in EU
• Package solutions could emerge in software industry helping ASPSP to
• Integration costs for ASPSP are limited because interface is simple

Having costs limited to minimal possible amount, APSPSs are still able to build own, functionality-rich interface beside this mandatory “EURO-API” when an business opportunity is identified.

Generally: as common and secure open standards of communication we assume this standards:
o Communication layer via RESTful over HTTPs (RFC 2818, 5785, 7230, 7231, 7232, 7233, 7234, 7235, 7236, 7237, RFC 7540, RFC 6690)
o Authentication and authorization schema based on industry standards OAuth 1.0/2.0 (RFC 5849 or RFC 6749, RFC 7521) or SAML 2.0 (standard defined via OASIS)
o Format for data Exchange based on JavaScript Object Notation (RFC 7159)
o Ontology developed from OMG-FIBO (Object management Group -Financial Industry Business Ontology) or/and ISO 20022

• PKI for PISP/AISP–ASPSP communication security
• REST + JSON as communication protocol
• ISO 20022 for data model definition (although default syntax is XML, the same data in the same structure can be also marshalled to JSON messages more suitable for mobile devices)

The topic about credentials is quite sensitive and needs to be addressed. It is an absolute must that AIS/PIS would provide their users with own set of credentials. We cannot expose our authentication/authorization interface for end users as a service to the third party. We always educate users to enter our set of credential only in our systems.