Creation of a Pull Request for Age Verification API

[GillesInnov35]

To start the discussion

• Orange do not have implemented such a API
  nevertheless this is a request with high priority

• some key points
  . countries' laws and data storage restriction (for example age of minor)

  . What data are held by the MNOs : for some of them, only the primary phone number has been known

  . API as a decision support with restrictions
  Example of existing offer restriction: The MSISDN must belong to the bill payer (also known as the primary subscription on the account), The subscription must be pay monthly (PAYM, also known as post-pay)

• creation of a Pull request
  @ToshiWakayama-KDDI may I ask you to create a Pull request. I face a problem when creating a second PR when the last one has not been merged.

CAMARA Milestone:
YAML files with supporting documentation for all drop 2&3 APIs 'included AGE Verification) completed by the end of March 2024
Thanks

[GillesInnov35]

Bellow proposal:
Age Verification API specifications for Service access restriction to adults to age-restricted sites.

Some functional restrictions may exist, for example:

• User MSISDN must be the primary phone number of the contract holder.

Swagger view:

Additional comments:

• considering that the API will be able (in the future) to determine that a user is minor, the attribute isVerified (boolean) could be replaced by an enum string (Y:Yes, N-AV: No information not available, N-NAV: No because information not available).
• Also, some information could be help with the decision, for example does a parental control exist for this user mobile phone.

[ToshiWakayama-KDDI]

Hi @GillesInnov35 ,

I have just created PR #50 for this, with a kind of dummy yaml file. Hope you can update the yaml file or replace it with your initial proposal

Please let me know if you have any problem.

Best regards,
Toshi

[GillesInnov35]

Thanks a lot @ToshiWakayama-KDDI. I'll complete PR with a proposal of design specifications.
Gilles

[HuubAppelboom]

Hi, in the Netherlands we only accept people of 18+ for a monthly subscription, this has to do with national law. You can make a contract with a minor, but such a contract can easily de cancelled by a parent without any financial consequence. As a results, all telco's don't accept minors as contract holders.

For the Netherlands , this means that any customer that can be positively matched (for example, based on first name, middles name and lastname, and phone number), you can already safely assume they are 18+, without asking for someone's date of birth.

So for 18+, we don't need to have an extra specification. We do however have some other age categories, like 24+.

For these categories, and for cases where the relying party does not want to ask for date of birth (for privacy reasons), it may be good to add an attribute whether te subject is over a certain age.

I suggest to make the parameter a bit more descriptive than "age" in above example, for example like

In the Request Body:
{
"phoneNumber :" +31612345678
"ageVerification": 24
}

In the Response:, if the user is indeed older, repeat the reqye
{
"phoneNumber :" +31612345678
"ageVerification": Y
}

(Verification: Yes seems a bit ambiguous to me, especially if you combine it with other parameters). I would suggest to keep the answers the same as we do now with MC Match, ie. Y, N, N-NA.

[HuubAppelboom]

And as for the issue whether the end user is the same as the contract holder, the simplest way to solve this is by responding to an age verification request only when as a minumum alle th name attributes (First Name, Last Name etc) have a perfect match. If the name does not match sufficiently, it makes no sense to report an age verification.
I know this kind of verification is not 100% waterproof (you may have a parent and a minor with the same First Name), but this is probably the best you can do without overasking someone with additional attributes, like passportnumber, address when it is not needed etc etc

[GillesInnov35]

hi @HuubAppelboom, thanks for your comment. In France we have the same restriction
I've proposed something in line with your suggestion in the PR #50 with a draft yaml.
BR Gilles

[GillesInnov35]

to your comment @HuubAppelboom

And as for the issue whether the end user is the same as the contract holder, the simplest way to solve this is by responding to an age verification request only when as a minumum alle th name attributes (First Name, Last Name etc) have a perfect match. If the name does not match sufficiently, it makes no sense to report an age verification.

don't you think that as the phone number has been retreived we should not have to compare other informaiton.

[HuubAppelboom]

Hi @GillesInnov35 ,

In case a minor is using the phone and the contract owner is a parent, the minor will fill out the phone number, and that will verify as correct, so then the age verification would not work, because for the age you are checking the date of birth of the parent.

You need to test as a minimum that the user is the same individual as the contract owner, so by comparing the names it will show whether this is the case or not.

So, if you ask me, it makes sense to offer age verification only as part of the Match api, or to combine it at least with name verification. Otherwise you are assuming that the telco knows who the end user is, which is often not the case.

[GillesInnov35]

hi @HuubAppelboom, one comment to

In case a minor is using the phone and the contract owner is a parent, the minor will fill out the phone number,

From what I know, in 3-Legged authentication (which is a requirement for KYC APIs), the phone number is retreived through the authentication journey and should not be filled out.
BR
Gilles

[HuubAppelboom]

@GillesInnov35 Correct, if you decide to use the front end flow. In that case you can retrieve the phone number from the authentication journey. For any backend flow (like CIBA) that will not work.

Anyway, the point is that it makes no sense to offer the Age Verification as a single attribute in the API without an additional identity check (for example based on a name match), because that will not work with most Telco's. Moreover, if you would provide its as such, it may lead to a confusing situation and wrong interpretation of the result.

[GillesInnov35]

thanks a lot @HuubAppelboom, I totally agree with you that the more controls we put in, the more reliable the solution will be. My remark was just to clearly understand and not to limit attributes to a unique field of course.
As you say, adding firstName and LastName match result is a first level of control.
BR
Gilles

[HuubAppelboom]

@GillesInnov35 An alternative control could also be the email address of the contract owner. If that matches, in mos cases you can also assume that the end user is the contract owner, and return the age verification result based on the age of the contract owner.

In any case, I would strongly recommend to make the use of at least one of these checks mandatory within the API request. Most developers don't read documentation, and if you provide the API without these, you will see lots of cases where the developer assumes the age check is done against the date of birth of the end user.

[GillesInnov35]

Thanks @HuubAppelboom for your comment.
@ToshiWakayama-KDDI , @fernandopradocabrillo, GSMA is asking for an update on this API by the end of the week.
Thanks
BR
Gilles