Release r2.2 (Fall'25 M4)

[eric-murray]

What type of PR is this?

• subproject management

What this PR does / why we need it:

Publication of Fall'25 M4 public release of kyc-tenure v0.2.0

Which issue(s) this PR fixes:

Fixes # N/A

Special notes for reviewers:

None

Changelog input

 release-note
 - Publication of Fall'25 M4 public release of kyc-tenure v0.2.0

Additional documentation

None

[hdamker]

@eric-murray Congratulations, I couldn't find a single issue in this release PR 🎉

Regarding the API Description:

• There is the open issue Clarify the Tenure API description #25 without a clear conclusion (at least not visible for me)
• Could you check that the discussion is reflected in the current API description on wiki page and confirm that it was updated accordingly? (it was last changed April 23rd, the discussion in the issue went into May)

I left also one comment within current API description as there is the potentially wrong statement "No customer data is shared, as only a binary match result is given for each attribute." First is also this attribute in a sense customer data and second is there the optional contract type information which will be shared. Especially the latter can even require customer consent before it is allowed to be shared.

Just FYI the AI comment on this point of the API design:

contractType Field Data Exposure:

• The contractType field reveals subscription type (PAYG/PAYM/Business)
• Concern: This information disclosure may not be necessary for tenure verification
• Best Practice: Consider if this data exposure aligns with data minimization principles
• Recommendation: Document why this field is included and ensure user consent covers this data point

For the next release it would make sense to add the User Story for the API.

[eric-murray]

Thanks @hdamker

I believe issue #25 was never brought to a successful conclusion. I don't attend KYC meetings, so don't know the status of discussions there (and don't have time to read through the minutes at the moment!). I'll try and get this resolved following the meta-release.

As for contractType, that is inherited from the equivalent Mobile Connect API, and was included to make migrating existing Mobile Connect customers to the CAMARA API more straightforward. I'll check with the Vodafone product manager as to the current requirements for this field.

[HuubAppelboom]

Thanks @hdamker

I believe issue #25 was never brought to a successful conclusion. I don't attend KYC meetings, so don't know the status of discussions there (and don't have time to read through the minutes at the moment!). I'll try and get this resolved following the meta-release.

As for contractType, that is inherited from the equivalent Mobile Connect API, and was included to make migrating existing Mobile Connect customers to the CAMARA API more straightforward. I'll check with the Vodafone product manager as to the current requirements for this field.

@hdamker @eric-murray Herbert, Eric, whether the contracttype is required depends on the market, and whether in that market all users have been identified, or whether for example prepaid is sold anonymously. In the latter case, fraudsters often abuse prepaid phone numbers, and you can work with legitimate interest as a legal base. In countries where all subscribers are identified, you may not have that, and you may need to work with user consent.

However, in those markets (with full identification of all susbscribers), you may also decide that the contractType is irrelevant; in these markets you can also fall back to offering just Number Recycling, because that can offer the same information (whether a number is longer than a certain period in use by an end user).

[hdamker]

@camaraproject/tenure_codeowners @camaraproject/tenure_maintainers:

I understood that #25 won't be resolved now and the current API definition is as intended.

With that there is only one blocking point for the release approval: someone from the team has to confirm in #54 that the API description is updated for the release and/or up-to-date.

[GillesInnov35]

LGTM

[hdamker]

@GillesInnov35 can you have also a look on the API Description in wiki and confirm it in #54?

[GillesInnov35]

@hdamker , yes I'd look and it seems good. I see that the comment concerning the contract type is addressed, isn't it ?

The network operator may also share which contact type the customer on (e.g. PAYG, PAYM, Business) in markets where this is relevant to establishing the level of trust that can be associated with a given length of tenure.

[fernandopradocabrillo]

LGTM

[tanjadegroot]

I tried to finish the review, but found an issue with 2 links in the readme. please fix and then we can approve.

[hdamker]

@fernandopradocabrillo @GillesInnov35 Can you shortly have a look on the two suggestions for the links in README.md above? Thanks

[GillesInnov35]

LGTM

[hdamker]

@GillesInnov35 I've committed the one supported but not yet resolved suggestion above. With that @tanjadegroot can approve from ReleaseManagement side and unblock the PR. It's then up to codeowners to merge and create the release. And sorry that I accidentally dismissed your review.

[tanjadegroot]

Perfect ! thanks

LGTM from Release Management

[ToshiWakayama-KDDI]

Hi @fernandopradocabrillo , @GillesInnov35 ,

Please be reminded to approve the PR again, because there have been some minor updates after your past approvals, and then merge it and make the release available. It seems Tenure is one of the two APIs that have not completed Fall25 M4...

Thanks and best regards,
Toshi

[GillesInnov35]

LGTM

[hdamker]

@camaraproject/tenure_codeowners You are good to go here. Can one of you pick up the remaining steps now? If not you can ask me to help out, we want to get this release done today.

Next steps for the team:
• [ ] PR merged (by API repository codeowner)
• [ ] Release created within GitHub (by API repository codeowner)
• [ ] Release Tracker updated (with creation date of the release and the release tag link)

Thanks

[GillesInnov35]

@hdamker , @fernandopradocabrillo , @ToshiWakayama-KDDI. I think I've created what is mandatry for Release r2.2
Let- me know if something else should be done.

• [X] PR merged (by API repository codeowner)
• [X] Release created within GitHub (by API repository codeowner)
• [X] Release Tracker updated (with creation date of the release and the release tag link)
Gilles

[hdamker]

@hdamker , @fernandopradocabrillo , @ToshiWakayama-KDDI. I think I've created what is mandatry for Release r2.2
Let- me know if something else should be done.

Thanks @GillesInnov35 - all done for the release, I closed also the release review issue in ReleaseManagement.