4.1.   W3C Web Payment Interest Group (John)

4.2.   Australia (Dima/Stuart)

• FAPI workshop planning underway. It will be announced by next week. The first one will be 20th of April.
• Commonwealth Bank of Australia certified its Open Banking (CDR) implementation including the first PAR certification (globally).

4.3.   Berlin Group (Francis)

• Francis is drafting a letter to be sent from BG to an official application to OIDF.

4.4.   Brazil (Chris/Ralph)

• Formal acceptance of FAPI Advanced and certification.
• Dynamic scope, not PAR.
• 830 banks registered (440 or so is under one cooperative)
• No news of RP testing though they are looking at. Chris believes it will be a year two thing.
• There is no link. Redirect Mandatory, CIBA optional.
• Security profile is not existent.
• Working document: https://openbanking-brasil.github.io/areadesenvolvedor-fase2/#financial-grade-api-fapi
• It is not yet in a usable form. It is still a fork of AU.
• Standard Body: Open Banking Brazil. MIRO is the consulting party.
• Central bank made this happen.

4.5.   Canada (Ralph)

N/A

4.6.   UK (Don/Ralph)

• Meetings being scheduled.
• Recurring payments standard (optional) will be announced next week.
• Consultation from CMA on the next steps of OBIE.
• Approval from the eKYC WG to extend the customer attribute.
• OBIE job will be transitioned Fiona.

4.7.   USA (Joseph)

• FDX security committee is finalizing the review of FAPI 1.0 for approval.
• Joseph will be giving updates on FAPI in April in their FDX Global Summit.

5.1.   GOFCOE/GOFTS (Don)

• A bit of grey area between adoption and official announcement.
• We still lack the central reference to look at. GOFCOE could create a library that could work as a global reference point.

5.2.   FIN/SUM 2021 (Nat)

6.1.   247: Grant Management Refactoring & Clarification (Torsten)

6.2.   249: Grant Management Refactoring Alternative (Torsten)

• https://bitbucket.org/openid/fapi/pull-requests/249

247 and 249 are two approaches on one issue. People's preference seems to be 249 so it will be merged into it.

Taka compiled a table on the use-cases. It was compiled with an assumption that a new grant_id will be issued from the token endpoint as the response. Torsten pointed out that he was assuming that the same grant_id as in the request is being returned from the token endpoint. Ralph agreed.

Lukasz: Two use-cases. Single grant gets updated. In AU - there will be concurrent grant_ids. If in the later case, no one is expecting the grant to be updated.

Dima pointed out that something like refresh token exchange could happen, but in that case they will not exist in parallel.

Replacing the grant_id seems reasonable but no parallel grant_id based on a single baseline grant.

Stuart

6.3.   251: Grant Management: Use cases section added (Dima)