kyc-age-verification API’s common behaviours

[ToshiWakayama-KDDI]

This topic was discussed in the KYC SP Meeting on 2026-06-23, of which meeting agenda/minutes is here: https://lf-camaraproject.atlassian.net/wiki/x/GQD_N

According to the Meeting 2025-10-14's minutes (https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/256606335/2025-10-14+KYC+Match+Fill-in+Age+Veri+Tenure+Number+Rec+Sub+Status+Minutes#Age-Verification-API-New-Repo), it seems that the point is:

• if age_check is not possible and "age_check: not_available" is returned, all other optional attributes will not be returned (verefiedStatus, identityMatchScore, contentLock, parentalControl),

or,

• contentLock and parentalControl can be returned, as these two are independent of age_check (or any other rationalization).

Which one would be the expected behaviour? We could add a note for clarification to the Age Verification yaml.


If we conclude this quickly, we may be able to include this in PR #48 (Enhance KYC age verification documentation).

[ToshiWakayama-KDDI]

By my reading, it seems the above point is not clearly specified in the current KYC Age Verification yaml.

For example, the /verify description has the following sentences. The 2nd bullet is the behaviour about verifiedStatus and identityMatchScore, while the 3rd bullet is the behaviour about contentLock and paranteControl, but nothing is specified about the relationship between them.

• Verify that the age of the subscriber associated with a phone number is equal to or greater than the specified age threshold value.

• As it is possible that the person holding the contract and the end-user of the subscription may not be the same, the endpoint also admits a list of optional properties to be included in the request to improve the identification. The response may optionally include the identityMatchScore property with a value that indicates how certain it is that the information returned relates to the person that the API Client is requesting. To increase the reliability of the information returned, the API Provider may include in the response the verifiedStatus property, indicating whether the identity information in its possession has been verified against an identification document legally accepted as an age verification document (Note). Note: Depending on the country, credit-check or other mechanism can be used instead of official identification for Age Verification. For details, please contact API Provider.

• If the API Client indicates request properties includeContentLock or includeParentalControl with value true and the API Provider implements this functionality, then the response will also include contentLock and parentalControl properties to indicate if the subscription has any kind of content filtering enabled. On the other hand, if the request properties are not included or the API Client specifies value false, then the response properties will not be returned. If the API Provider doesn't implement this functionality, request properties will be ignored and response properties won't be returned in any case.

I think we need to specify the behaviour clearly, especially if we aim at the stable v1.0.0 for Sync26.

[ToshiWakayama-KDDI]

In addition to the above point, any other potential clarification for Age Verificaiton API's behaviour would also be beneficial.

[PedroDiez]

In TEF case, this is the behaviour:

contentLock and parentalControl can be returned, as they are independent of age_check

[ToshiWakayama-KDDI]

Thanks, @pedro.

I still don't quite understand why these two properties, which seem to be independent of age_check, are included in the Age Verification API. However, I understand that this was the approach agreed for our Spring25 release.

If there are no further comments, I will open an Issue and a corresponding PR to address this (2nd option).

If anyone would like to share their thoughts or concerns before then, please let us know.

[PedroDiez]

Hi @ToshiWakayama-KDDI,

That is the feedback we have from our Business, as in our business case those concepts/features are not attached to the age of the person behind the involved subscription.

@albertoramosmonagas, @claraserranosolsona FYI

[GillesInnov35]

@PedroDiez , @ToshiWakayama-KDDI , at Orange we consider that those 2 properties may be useful and seen as a signal when the age verification result (boolean) could not be returned.
So I support scenario of a response body including contentLock and parentalControl without age_check .
Thanks
Gilles