Weekly Sync - 21 May 2024

[github-actions[bot]]

Please add agenda items below and give your weekly update in a comment. Thank you!

Agenda

Timea - Open Payment Get Wallet Address has a mention of additional properties for a WA, key-value pair. But if you look at Rafiki graphql schema it is not included. Also these additional parameters should be update-able. JoPACC would like to save an IBAN for example for a PP/WA. Can it be done? And can it be done ASAP? :D
Opened #2730 for this.

Timea/Beni/Dragos- future improvement -> add multitenant Rafiki

Sarah - Can we please have a discussion about what two-phase transfers really are, how they differ from single-phase transfers and the different use cases for each.

Discussion

• discussing with integrator about including additional information into Payment Pointers, specifically IBAN numbers.
• Integrator wants to include IBAN numbers in Payment Pointers and seeks support for saving and updating this information in Rafiki.
• Max: Questioned the need to expose IBAN if there is already a database that tracks which IBAN is associated with which account.
• Alex explained that this approach means the integrator could work towards removing the low availability CAS system that is currently in place by locking the IBAN to the Payment Pointer during account creation. This would make Rafiki the single source of truth.
• The spec allows for additional fields. Alex argues all we are doing is using a feature that is already outlined in the spec. Adrian is concerned about introducing interoperability issues based on how people will come to assume they can use the spec if we return this additional info in Open Payments calls.
• Adrian: Mentioned the need for an admin API to handle the creation and updating of Payment Pointers, separate from what appears on Open Payments APIs.
  Sabine: Emphasized the importance of making the additional properties useful to third parties.
• Adrian: Raised concerns about security and privacy implications of associating an IBAN with a Payment Pointer, even if the information is not sensitive. Timea will confirm the security requirements with the integrator.
• Adrian: Highlighted that the current endpoint is the least secure, as it requires no authentication to access the information. Timea asked about requiring authenticated access here. Adrian suggested considering tiered access—unauthenticated calls return basic info, while authenticated calls provide a richer response. Sabine noted that a similar approach is already used for incoming payments. But this is a significant change that would require many other discussions.

Action Items:

• Timea: To check with the integrator regarding security and privacy requirements for IBAN integration.
• Rafiki Team: To ensure that additional properties can be stored in the system and to provide the integrator with the necessary functionality in the interim.
• Adrian suggests making meeting longer while this project is being implemented

[BlairCurrey]

• Finished hot reload over docker
• investigated shared apollo client/logger package and recommended no action
• working on adding spent amounts to create outgoing payment response

[njlie]

• Updated Admin UI
• Added logs to auth graphql resolvers
• Working on securing auth admin api with signatures
• Working on logs for auth routes
• Updating docs on IDP integration

[beniaminmunteanu]

jopacc week