Two levels of scoring precision in API · Issue #23 · camaraproject/CustomerInsights

DT

ON-HOLD

Issue ON-HOLD. Check history

Management of scenario where idDocument is not related to subscription identified via access token or phoneNumber · Issue #59 · camaraproject/CustomerInsights

TEF

ONGOING

16/OCT: Issue Raised by TEF:

• Concern about reusing transversal exceptions (e.g. mismatched identifiers) across APIs like Customer Insights and Know Your Customer Match.

• TEF business prefers distinct exceptions to avoid potential misuse or false positives where an API consumer might exploit pricing differences between APIs.

• A new issue was opened to reflect this concern and propose a separate exception for Customer Insights.

Security & Fraud Considerations

• Vodafone (Kevin) raised concerns about potential fraudulent use of the API:

  • Risk of brute-force attempts to match ID documents with phone numbers.

  • Suggested using generic error messages to avoid exposing sensitive validation logic.

  • Emphasized the need for backend monitoring and rate-limiting to detect suspicious behavior.

• TEF (Pedro) acknowledged the concern and indicated to:

  • Investigate current backend behavior in place.

  • Continuing internal checkings and come back to follow-up the discussion.

30/OCT: After internal checking, Pedro (TEF) indicates there is no correlation between ‘phoneNumber' and 'idDocument’ in business logic for the 2-legged scenario. That means the exception is not triggered in 2-legged case. Besides this, TEF is internally checking with their business and KYC team as there are similar situations in KYC-Match. Therefore it is proposed to set the issue On-Hold until reaching an internal conclusion on it. Kevin and Rafal also follows KYC subproyect so all will be synched.

27/NOV: After internal aligment TEF (Pedro) has proposed removing specific exceptions (e.g., ID document mismatch, a.k.a. 422 CUSTOMER_INSIGHTS.INVALID_IDENTIFIERS and checking internally 422 CUSTOMER_INSIGHTS.ID_DOCUMENT_REQUIRED) and using a generic “422 SERVICE_NOT_AVAILABLE” error to avoid exposing sensitive logic and prevent fraudulent scenarios. Some rationale is aligment with KYC-Match camaraproject/KnowYourCustomerMatch/issues/49.
Initial feedback:

• VF (Kevin) supported the approach for better API usability and security.

• DT (Rafal) suggested considering local market requirements where explicit errors might still be needed.

Next steps: Continue internal checks and revisit in the next meeting.

11/DEC: Pedro has shared with TEF business product in order to get their detailed view in this proposal. It is waiting for their assesment. Hope to have in the next week. It will be reflected in the Issue, so let’s keep on hold until this feedback in ordert o check next steps.

15/JAN: Pedro provides the consolidated feedback by Bussiness in this comment. Basically:

• Replace 422 CUSTOMER_INSIGHTS.INVALID_IDENTIFIERS and manage the scenario with 422 SERVICE_NOT_APPLICABLE.

• Replace 422 CUSTOMER_INSIGHTS.ID_DOCUMENT_REQUIRED by 422 SERVICE_NOT_APPLICABLE as well.

Kevin asks about the scenario when an Operator does not support idDocument and API Consumer provides it. For that scenario, API defines the 422 CUSTOMER_INSIGHTS.ID_DOCUMENT_NOT_SUPPORTED scenario. Initially the proposal looks fine for him.

Rafal indicates the need to check this proposal internally and also related to KYC-Match behaviour and provide feedback.

05/FEB: TEF asks for comments about provided approach. VF confirmed alignment with this approach. DT confirmed no objections and agreed to proceed. Next Actions:

• TEF will prepare a draft Pull Request implementing the agreed changes.

• The PR will be reviewed by the WG once submitted.

12/FEB: PR#65 generated for WG review

20/FEB: PR shared and explained within the WG. The PR will be reviewed by the WG and provide comments.

05/MAR: PR has been reviewed by Kevin (OK) and it is pending review from Rafal.

Applicability of Commonalities OWASP rules in Customer Insights · Issue #64 · camaraproject/CustomerInsights

WG

ONGOING

12/FEB: Issue opened as per commented in the last meeting by the WG

20/FEB: Shared with the group the rationale of this issue. Main concepts to be discussed about their design are idDocumentand scoringType. Others will be according to Commonalities Commonalities/issues/584 output. Rafal points out that for idDocument setting maxLength is probably enough (generally, the pattern is not mandatory for every string). kevin asks for clarification about XCorrelator. Rafal indicates it is the schema object for the header/parameter x-correlator. WG will review it and move forward also when Commonalities output is consolidated

05/MAR: Commonalities/pull/590 related to Commonalities/issues/584 has been merged today. So main point is the discussion for the idDocument format. Pedro will draft a PR during the next week in order to be online discussed during the next meeting.

Add Release Plan automation

RM

NEW

23/FEB: New PR to add release-plan.yaml file for automated release tracking. Managed by RM WG
05/MAR: Comment and shared its purpose. Rafal provides additional clarifications. Today a specific call will be held including this topic. It is commented that in the WG we can directly merge (Going for option A). To be reviewed by the WG and with approval it can be merged during the next week.

AoB

WG

March, 19th 2026 -- 14:00 - 15:00 UTC (15:00 - 16:00 CET)

Meetings Link

April, 2nd 2026 -- 14:00 - 15:00 UTC (15:00 - 16:00 CET)

Meetings Link