Redirect after Consent is retrieved

[electronicpeter]

Today (12.3.2020) we (Hergy, Roman, Valentyn and Peter) agreed that redirect after Consent will work like this:

1) after Call listAccounts(1a) was done from fintechUI, and tpp answers with missing content and redirect, redirect is done from fintechUI to given location.

2) before this, fintechServer get fintechRedirectOKURL from header field. This URL will look like /bank//redirecttransaction This redirectURL is changed from fintech server with a prefix given in the propertyfile of the fintechserver and appended with the /{redirectcode} So the path might look like: http://localhost:4444/bank/53c47f54-b9a4-465a-8f77-bc6cd5f0cf46/redirectaccount/12345

3) eventually this url is called. When browser gets urls, hopefully UI Session is recovered automaticly. So XSRF-Token should be known.

4) Now FintechUI has to call GET /v1/1/fromConsentOk/{xsrf-token}?{redirectCode=redirectCode}

Fintech Server now can recover from xsrf-Token what was called (e.g. listAccounts, or any other service) and redoes the the call which was done in step a), but now with the sessionID so that backend can retrieve consent. Eventually this GET returns the accounts.

If other services were used (e.g. listTransactions or initatePayment) the okurls given by the frontend would look differently like: /bank//redirecttransaction/ /bank//redirectpayment/???

TODO in Frontend:

1) create correct redirect url 2) creaate route that listenes to this url (including the appended redirect code) 3) call backend with redirect call addding xsrftoken and redirect code 4) retrieve result and show like list accounts

[DG0lden]

Protocol out of the discussion (TODOs):

• [ x] Call 2b shall erase session cookie and replace it with redirection cookie
• [ x] Call 4b call comes with redirect_code. Using the redirection cookie it shall be matched with service-session-id received from call 2a. Next session cookie to be established later.
• [ x] Call 4c shall verify the pair redirect_code and service-session-id. If they match, authorisation token to be issued and returned back.
• [ x] The authorisation token and service-session-id are to be used with the repeat of call 1b to get the service response.

Note: For payments successful matching on TPP server of these parameters is a trigger for payment confirmation call to bank.

Further TODOs (for a separate task) - handle XSRF Token correctly

[electronicpeter]

LoA Introduction: .................

• the FinTechContext transported as jwt-Token in the Authorization header of each FinTech request to the TPP

• [ ] We dont do this

LoA-030 : FinTechApi.listOfAccounts ...................................

• withBalance: optional, instruct the TPP to request balances associated with each account.

• [ ] As talked about a hundred times, not done yet too. Even not part of the structure.

LoA-031 : FinTechApi.checkAuthorization .......................................

• Call specification: : checkAuthorization(SessionCookie,\nX-XSRF-TOKEN):psu-id@fintech Before proceeding with the request, the FinTechApi must validate the request for it authenticity and extract a unique identifier of the PSU in the world of the FinTech (psu-id@fintech).

• [ x] FintechServer does not care about SessionCookie yet

• [ x] We dont have pus-id@fintech in Fintech Server yet

• [ x] We allways pass user login-name but get a redirect anyway. So it looks like tpp does not care about users yet.

LoA-032 : FinTechApi.userAgentContext .....................................

• Parses the HTTP request and extract information associated with the user agent (see UserAgentContext).

• [ ] Fintech Server does not care about UserAgentContext yet. As I understood, tppServer does.

LoA-033 : FinTechApi.buildUrlTemplates ......................................

• In order to distinguish redirect cookie associated with different authorization flows, we scope the Fintech-Redirect-URL with a dynamic path parameter "$AUTH-ID". This must be set as part of the cookie path of the RedirectCookie returned to the FinTechUI. -

• [ ] The FintechServer just memorizes one state for the user, thus is not able to do more than one request in parallel. For memorizing the state, the AUTH-ID is not used yet.

• [ x] When redirecting to Fintech-UI no RedirectCookie is returned.

LoA-034 : FinTechApi.loadServiceSession .......................................

• Uses the given psu-id and service type to load a corresponding service session if the FinTech judges the request of the PSU is the repetition of an existing service request.

• [ ] How can the FintechServer know, that it is a repetition? The X-Request-ID is allways new.

LoA-040 : TppBankingApi.listOfAccounts ......................................

• withBalance: See LoA-030.
• [ ] as mentioned above response structure does not contain fields

LoA-076 TppBankingApi:303_SeeOther ..................................

• The TppBankingApi turns the BankingProtocolResponse into a 303_SeeOther(authId,serviceSessionID,\ntppConsentEntryPoint,redirectExp).

• [ x] Tpp Returns 202 not 303

LoA-078 FinTechApi.expireSessionCookie(SessionCookie) .....................................................

Upon redirecting the PSU user agent to the ConsentAuthorizationApi, the regular session between the FinTechUI and the FinTechApi has to be removed

• [ x] not done yet
• [ x] but a new SessionCookie has to be created? Not mentioned in description.
• [ x] what is, if user goes back in UI and does another list accounts (for another) bank. As sessionCookie now is gone, request would fail until user logs in again?

LoA-079 FinTechApi.createRedirectCookie .......................................

• Purpose: The RedirectCookie is used make sure that the UserAgent that started a redirect flow is the same as the one the terminated that redirect flow. This is essential to assume that the PSU physically using this user agent is the same as the one that accessed the authorization interfaces of the (TPP resp. ASPSP).

• [ x] not done yet, including all further requriements of this Cookie

• Expiration: This RedirectCookie shall be set for the max time we think the PSU needs to complete authorization of the corresponding consent.

• [ x] currently all cookies created in FinTechServer have same duration. A second parameter is needed.

LoA-080 : FinTechApi redirects userAgent to the ConsentAuthorisationApi .......................................................................

The service response carries a response code 302 instructing the FinTechUI to redirect the PsuUserDevice to the ConsentAuthorisationApi, with following information: - redirectCode : attached as a query parameter - SessionCookie : for deletion - RedirectCookie : with the expected duration of the consent authorization.

• [x ] is 202
• [x ] new SessionCookie not yet, see LoA-078
• [x ] new RedirectCookie not yet, see Loa-079

LoA-090 Suitable Consent Present ................................

• If there is a suitable consent reference in the database of the TPP, this will be loaded and used to forward request to the ASPSP.

• [ x] currently Information which Consent to be retrieved is not passed to ConsentUI.

InitConsent-010 ConsentAuthorisationApi .......................................

• The redirect starts with a get request to ConsentAuthorisationApi.auth. The entryPoint of the ConsentAuthorisationApi for processing a consent initiated on the TppBankingApi side.

• [x ] Here it is not marked, that a redirect page has to be showed. We actually dont do it, but this was remarked as a bug in the last presentation?