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

[GillesInnov35]

to all,
find a draft of design in the PR #50
As proposed by @HuubAppelboom, I've added first name and family name in the attributes' request. Those 2 attributes should be compared with information held by MNO to confirm the identity of the user.
BR
Gilles

[HuubAppelboom]

@GillesInnov35 Hi Gilles, In the list of attributes there is also the middle name, can you add these as well to the proposal ?

[GillesInnov35]

@HuubAppelboom , yes sure. I update the swagger design.
Thanks
BR
Gilles

[GillesInnov35]

Can we summarize the discussion like this ?

• a KYC Match is performed with identity information (first name, family name and middles name (optional)) to confirm the identity of the user (identity of the contract owner)
  • Match score result must be equal to 100, else isVerified = false
• a response isVerified returned True if the verification has been done else False if the age could not be verified
• age verification will only work if the user phone number is that of the contract onwer
  • if true the user's age is 18+
  • if true we can check if the age is over a value (for example 21+)
• What about other cases ?
  • if response isVerified returned false could we use the tenure of the contract to verify the age ?

[HuubAppelboom]

@GillesInnov35 Hi Gilles, sounds like a good summary to me.

Regarding the tenure of the contract in case isVeried = False, how would that work and what would it proof ?

We don't have many contracts which exsist longer that 18 years, and the phone number may also be passed along between family members....
Moreover, we don't know what the relationship is between the contract owner and the user of the phone number, so we can't do much what that either. If the isVerified returns false, I simply would not do any age verification based on what the telco knows.

[javier-carrocalabor]

Hi all,
I've been out of this discussion so far. This is becaming a priority for us too. Sorry for entering late.
I have read it all your comments... The main problem we see is also that, usually, the known age is for the owner of the contract, and how to verify that the user at that moment is really the owner of the contract.
It's true that a common practice in other services or even customer services given through phone, is to ask for some other contact details (even recording the conversation), but the first/family/middleName seems weak to me. In some countries the idDocument is also asked, which seems stronger.
What do you think?

[HuubAppelboom]

@javier-carrocalabor I agree that the first / family / middleName is relatively weak. However I see this as a minimum verification that should be done.

In case you want a higher level of assurance, you can also ask for other identifiers, like idDocument, or email address, bank account number, your home address etc. For these cases (where you want more assurance), you can also advice customers t you use both the Age Verification api and the KYC Match API.

[GillesInnov35]

hi @javier-carrocalabor , @HuubAppelboom , thanks for your contribution.
I think also that if the channel partner or application developer want to propose a high level of identity control of the user it will have perhaps to subscribe to a bundle of API composed of KYC-Match KYC-AgeVerify.
As mentionned by @HuubAppelboom, a first level of control based on first name, family name and optinally middles name might be a useful.
As listed in the API documentation included in the PR #50 there are restrictions on AgeVerify API usage.
BR
Gilles

[ToshiWakayama-KDDI]

Hi @GillesInnov35 , @HuubAppelboom , @javier-carrocalabor ,

Thank you for your active discussions. As KYC Match/Fill-in v0.1.0 release version is completed, we(KYC SP) can focus on this now.

I have read it all your comments... The main problem we see is also that, usually, the known age is for the owner of the contract, and how to verify that the user at that moment is really the owner of the contract.

I agree with this. For this problem, one thought I have now is that OIDF guys are going to introduce their activity and views on Age Verificaiton at our next meeting on 19th March, so we may be able to get some additional hints from them.

@GillesInnov35 ,
Thanks for drafting the API documentation in the PR #50. One scenario we are thinking to add would be:
To verify the age of a user to buy online age-restricted goods e.g. cigarettes, alcohol.

Many thanks,
Toshi

[GillesInnov35]

@ToshiWakayama-KDDI Thanks a lot for the information.
Yes it'll be very interesting to see how OIDF manage to improve age verification without any upload of identity document (passport, national id card, etc).
Regarding the first design proposal and the main restriction that the user mobile phone number must be that of the onwer of the contract, interest in the API could be less or not.
BR
Gilles

[GillesInnov35]

Hi all, we have discussed at Orange about the first proposition of an Age Verification API design.
According to information held :

• (1) MNO can verify if the user phone number is the that of the contract owner or that of the contact declared in the contract
• (2) MNO can verify if the identity given by the user (first name, family name and middles name) match with information held by the MNO
• (3) If both (1) & (2) checks are OK, as MNO we can say with that the phone number passed as parameter is the one of the contract owner/contact with a high probability (close to 90%) and as such a people with an age 18+

We think that the API Age Verification API should expose a resource named /contactverify which would much reflect what could be definitely performed by the MNO.

Nevertheless, if a age verification service /ageverify must be defined for example to cover Use Cases such as verifying 18+ 21+ 25+, the limitation due to restrictions and the probability lower than 100% must be clearly indicated (T&C) in order not to engage the MNO.
In this case, perhaps a score result could be returned which could be a help for partners combined with others results to evaluate or estimate the age.

[HuubAppelboom]

@GillesInnov35 What do you mean by a resource named /contactverify ? I would not use this name, it is generating confusion,.

As far is the inputs that are minimum required, we can also add other attributes to the input that can help to determine whether the end user in question and the contract owner are the same person. To avoid giving away too much information on the matching details, you will only report the result of the ageVerification request, not whether any of the attributes actually matches.
And yes, you can combine this with a parameter that indicates how likely it is that the age verification is correct.

For example, this how this could work:

In the Request Body:
{
"phoneNumber :" +31612345678
"ageVerification": 24
"givenName": John
"middleName": "William"
"familyName": "Hutchinson"
"email": "[email protected]"
}

In the Response body:
{
"phoneNumber :" +31612345678
"ageVerification": Y
"ageAssuranceLevel": 95%
}

This way you can also cater for scenarios where the MNO has validated the age of that particular user by others means (and you report the assuranceLevel at 100%, and you can also extend this apporach with more input parameters in the request body that can help identify whether the user and contract owner are the same individual. The above example includes email, but this could be extended further, for example with bank account number etc.

The ageAssuranceLevel is something that the MNO determines, and it might be a good idea to draft some guidelines on this.

[HuubAppelboom]

@ToshiWakayama-KDDI @GillesInnov35 @javier-carrocalabor

Regarding assurance levels, the assurance level of the Age Verification API and also of the KYC Match API strongly depends on the assurance level of the identity data that the MNO holds. It may be a good idea to add the assurance level of the data that the MNO uses in the response of the API.

For Europe, a commonly used specification for identity assurance levels is that of eIDAS (see https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eIDAS+Levels+of+Assurance). For other regions other specifications may be used like that of NIST: https://csrc.nist.gov/glossary/term/identity_assurance_level

For eIDAS, I would put for example something in the response like:
"identityAssuranceSpecification" : "eIDAS"
"identityAssuranceLevel" : "substantial"

(the level can be low, substantial or high)

This way you can communicate how reliable the identity data is. Especially if there are telco's where no or hardly any identity verification is done during onboarding (level low) this will become relevant. And when extra effeort has been done (level high), this can also be reflected).

[GillesInnov35]

Thanks @HuubAppelboom , a very interesting thought.
Adding a level of assurance could be useful for a partner to decide how to understand the response. The difficulty will be to define and explain how the assurance level has been evaluated.
BR
Gilles

[GillesInnov35]

@HuubAppelboom , to your comment

What do you mean by a resource named /contactverify ? I would not use this name, it is generating confusion,.

The objective was to differenciate the 2 opérations which have not the same objective

• /contactverify: verify that the user is the contact or the owner of the contract which should be confirmed by verifying the contract information. If true, in most of the cases (90%) the result is a confirmed result.
• /ageverify: verify the age of the phone user that might be difficult with a assurance level depending on elements/information held by the MNO.

I understand that what is expected is mainly the second one.

I've updated the PR #50 with Huub's proposition with an assurance level returned in the response to continue the discussion.
Thanks a lot
Gilles

[HuubAppelboom]

@GillesInnov35 The Y/N is more of an advice form the MNO (because the MNO can see all data). What I expect with the Fuzzy Name Logic is that when you plot the cumulative distribution function of Score versus percentage of users is that there are sharp drop-offs in the data. The MNO can probably see this, and decide below which percentage you should not assume anymore that the end user is the contract owner. This cut-off probably varies per MNO, depending on the quality of the data the MNO has.

As an alternative, the MNO can also provide just the ageVerificationScore when it is above the cut-off point, and when it is below the cut-off provide a N.

[KevScarr]

@HuubAppelboom Question from me... relates to this concept"Telco applies either a Yes/No match or Fuzzy Name Matching logic".

1. Is there a scenario where you wouldn't provide the 'score' if the response was an 'N' (ie so return both for the non-numeric fields and no-matches)?
2. And if you don't have the information available, what is the response value? (apologies if you've answered this already).

[HuubAppelboom]

@KevScarr @GillesInnov35

I think it is only a good idea to provide the score if it is above a certain level (to be determined by the MNO).

Come to think of it, we should also try to keep it in line what we have already defined in the answer for KYC Match (so [ true, false, not_available] )

So for example, let's assume the MNO has determined that the level should be at least 80% to provide an answer.

Let's assume the score is now 95%, the answer will be:

{
"ageVerification": true
"ageVerificationScore": 95%
}

or

{
"ageVerification": false
"ageVerificationScore": 95%
}

In case the ageVerificationScore drops too low, or the data is insufficiently available, you provide

{
"ageVerification": not_available
}

or, in case we must provide always the ageVerificationScore to avoid errors, we can also provide

{
"ageVerification": not_available
"ageVerificationScore": 0%
}

[HuubAppelboom]

On 2nd thought, with the idDocument may also have different valid values, for example in the Netherlands people can have a passport, driver license and id card, each of which is a valid identification document (and with a different number).

If there is a match with a document number, it is a very strong indicator the end user is also the contract owner.

In this respect, to calculate a total score for all the attributes provided, it may be a better idea to calculate a weighted average over all the inputs provided, to come to a total score, and to calculate a score with idDocument and email included and excluded.

[StefanoFalsetto-CKHIOD]

I'm sorry I couldn't attend to the latest call so maybe I am asking questions already answered.
Are we talking about record linkage or single attribute match score?
Because the use cases are quite different and I think they are both useful.

[HuubAppelboom]

@StefanoFalsetto-CKHIOD What we try to do here is to identify whether the end user is over a certain age, and part of the assesment is trying to check whether the end user is also the contract owner (otherwise the data does not make sense).

What are the other cases you are thinking about ?

[KevScarr]

@HuubAppelboom Aligning to KYCmatch response values is a good idea, it would give consistency when we come to retrofit score attributes back into the KYCMatch product. I'm not sure of the value of an overall score if you're providing back the individual scores; the Client and/or Aggregator consuming the service can use the individual attribute scores to make their Machine Learning decision; not opposed to it, just not sure if a customer of the API would use it

[HuubAppelboom]

@KevScarr The advantage of just replying with the Age info and an overall score is that you can price this at a separate price point (as compared to make the Age Verification check part of the KYC Match API), and that you do not need to expose the additional information which may not be needed. If a customer would like to have the other data verified as well, and know the answer per attribute, they can run that through the KYC Match API.

[GillesInnov35]

I'm not sure but in fact you propose to add those attributes in the AgeVerification request for being verify before age verification.

• idDocument: 66666666q
• name: Federica Sanchez Arjona
• giventName: Federica
• familyName: Sanchez Arjona
• nameKanaHankaku: federica
• nameKanaZenkaku: Ｆｅｄｅｒｉｃａ
• middleNames: Sanchez
• familyNameAtBirth: YYYY
• email: [email protected]

The Fuzzy Name Matching Logic will be only used for some them.

Response will be

• "ageVerification": True/False/not_available
• "ageVerificationScore": x percent

BR
Gilles

[KevScarr]

@HuubAppelboom Thanks, super clear. So under AgeVerify return a single score whereas in the match product, provide back the individual attribute scores. Make sense, today in our journeys, we have our customers call KYC-Match API first then the Age-verify API.

[ToshiWakayama-KDDI]

@HuubAppelboom , @GillesInnov35 , @StefanoFalsetto-CKHIOD , @KevScarr , all,

Thank you so much for the proposal and further discussion.

Sorry for the late comment, but from KDDI side, I have discussed this internally with our product team, and for Age Verification, we don't think we need any additional attributes, i.e. we only need "phoneNumber: +31612345678 (e.g.)" and "ageVerification: 24 (e.g.)" in the Request Body and "ageVerification": True/False/not_available (e.g.) in the Response.

So, from KDDI side, we would request to make any additional attributes optional and to make the Age Verification API work without any additional attributes. Our customers like this type of Age Verification (no frill) and we don't have any problem in Japan (and some other countries, I believe).

We understand EU's case, so, if the additional attributes are necessary, it can be documented properly in the API documentation or in the MNO's service document, e.g. in EU countries, attributes AAA, BBB, CCC, DDD are necessary. So, for the API, these attributes are optional, but for the service in EU, they are mandatory.

Best Regard,
Toshi

[HuubAppelboom]

@ToshiWakayama-KDDI @GillesInnov35 @StefanoFalsetto-CKHIOD @KevScarr

As a suggestion for making the input attributes optional, this can be done. In some markets you also may want to more input mandatory (for example email) to come to a reliable result. If we make all input paramaters optional, I suggest that we can also provide feedback when the API consumer has provided too little data to come to a reliable conclusion.

For example, the response could look like:

"ageVerification": true/false/not_available/insufficient input data provided
"ageVerificationScore": x percent

[KevScarr]

@HuubAppelboom If inputs are optional then it makes sense to support an "insufficient" response to me.

In the UK market, Pay-As-You-Go customers do not need to do a formal ID check and so can enter their own information on the MNO CRM system. So it may be appropriate to also have an 'unverified' response.

Today in our age product, if the account is PAYG, or has multiple numbers on it (ie user and owner may be different) and the adult-content-bar is on, we don't provide a response. So it may be appropriate to return an "unverified" response and no score?

[HuubAppelboom]

@KevScarr Hi Kevin, it may indeed be a good idea to add an unverified response, in case you want to share such data.

In this case we can have the following response options:

"ageVerification": true/false/unverified/not_available/insufficient input data provided
"ageVerificationScore": x percent

where unverified means true, but the data is not verified, and the ageVerificationScore is only provided in case of true or false.

[HuubAppelboom]

@KevScarr In our case, we don;t have any age data on prepaid users. The end-user vs contract owner issue we are trying to solve through the additional input data (givenName, middleNames, email). But ofcourseyou can always also exclude the multiple SIM group.

[KevScarr]

@HuubAppelboom Superb, agree with your points and thanks for including unverified.

[ToshiWakayama-KDDI]

Hi @GillesInnov35 , Hi all,

As we have had very long discussions, could you summerise the conclusion before moving on to PR? It is difficult to see what proposals are remaining, I feel.

A basic question, please. We have started Match Scoring discussion. As Age Verification has scoring feature, should it be aligned with Match Scoring?

Thanks,
Toshi

[GillesInnov35]

hi @ToshiWakayama-KDDI, see bellow my understanding and I let @KevScarr and @HuubAppelboom update the summary

• as the MNO hold only information of contract owner or contact, the identity of the user must be verified before the age verification
• Main rule: MNO will be able to return a result only if the user is the owner/contact of the contract known by the MNO (so age greater than 18)
• MNO will return in the response a string result and a score level which is the aggregation of all match score results of the provided attributes
• Regarding the score result, MNO will decide what should be the age verification result (true/false/unverified/not_available/insufficient_data)
• by also returning the global score it allows consumer application to decide how to understand the response.

The request

• contains the age value to be verified and attributes of identity which might be optional
• @HuubAppelboom from KPN proposes that some of them should be mandatory
• Telefonica thinks that all attributes should be optional because identity verification could be perform with the existing KYC Match solution before verifying age of user (to be confirmed by Telefonica)

The response

• a string result (enum array) true/false/unverified/not_available/insufficient_data
• True, False and not-available attributes are standard
• new attributes have been added unverified/insufficient_data (rules to be clearly explained)
• a score result (integer) = consolidation of all match score of attributes

this is what has been mofied in the first design proposal in the PR #50:

• complete the list of identity attributes in yaml file
• update the enum for attribute isVerified with true/false/unverified/not_available/insufficient_data
• remove required from attributes
• replace verification level (string) by a score result (integer)

[KevScarr]

To add to the above; we would support the Telefonica view for these attributes to be optional. Some use-cases don't have the full identity information available to check, where they do I would agree, KYC Match is a better fit to do a thorough check before calling this API.
One difference between the scoring in Match and AgeVerify; in Match each attribute receives a score when it's a non-match; Under the proposal above, it's a single overall score that is shared.
Good summary above @GillesInnov35 .

[HuubAppelboom]

There seems to be a majority for not mandating any of the individual attributes; in this case, we can also omit the response "insufficient_data" and limit the response to "true/false/unverified/not_available".

I do believe hower that it is still a good idea to ask for the attributes that can distinguish the end user from the contract owner in one and the same Age Verification API call. If you don't put it in one call, you will have to write an instruction like first you need to figure out whether the end user is the contract owner by calling KYC Match, and only if you think the end user is the contract owner, then it makes sense to call the Age Verification API (and otherwise you shouldn't). That may lead to a lot of mistakes by developers (because they didn't read the instruction, or they may try to cut costs by omitting the KYC Match call, etc). Putting the distinguishing attributes in the same call will prevent this kind of errors, it will reduce the total processing time, and you can position this call at a different price point than a full KYC Match call.

[GillesInnov35]

hi @HuubAppelboom , @KevScarr , very interesting discussion. I agree with the fact that from a technical flows point of view, adding attributes of identity will avoid to consume 2 services (Match and AgeVerification). And in my opinion it's a good thing.
According to a business approach, perhaps a bundle of APIs (KYC Match + KYC Age Verification) might be more interesting.
Nevertheless I would prefer to see those optional individual attributes in the API design. If atributes are not provided, score result will be 0 or N/A.
Thanks a lot
BR
Gilles

[ToshiWakayama-KDDI]

Hi @GillesInnov35 , all,

Thank you very much, Gilles. Good summary. Excellent.

May I ask just a few questions for clarification, please?

"Main rule: MNO will be able to return a result only if the user is the owner/contact of the contract known by the MNO (so age greater than 18)"

'so age greater than 18' may not be always true, I think. It may be different from country to country, from operator to operator, so, we do not need this pharse, do we?

"by also returning the global score it allows consumer application to decide how to understand the response."

What do you mean by 'the global score'? Sorry, I just do not understand it.

In addition, we would also support the Telefonica view for these attributes to be optional, as I have mentioned and commented some times.

But Huub's latest comment is very interesting. Good point. I will share it internally with my colleagues.

Many thanks,
Toshi
KDDI

[GillesInnov35]

hi @ToshiWakayama-KDDI , find bellow my point of view and answers

1-

'so age greater than 18' may not be always true, I think. It may be different from country to country, from operator to operator, so, we do not need this pharse, do we?

yes you're right regarding countries' law. "(so age greater than 18)" must to be removed
2-

What do you mean by 'the global score'? Sorry, I just do not understand it.

AgeVerification might return a aggregated score according all provided attributes score . Aggregated is a better word than global

BR
Gilles

[HuubAppelboom]

@GillesInnov35 @KevScarr @ToshiWakayama-KDDI In case no additional attributes are provided to asceration whether the end user is the contract owner, you could also provide for the score the chance that the end user is the contract owner and the age verification is correct, based on the statistics you may have accumulated with the KYC Match API. For example, if you know that on average in 72% of cases the end user is the contract owner, you can provide this as an aggregate score.

And ofcourse if you do have additional attributes provided, you can make an aggregate score with those attributes.

[ToshiWakayama-KDDI]

Hi @GillesInnov35 ,

I have one question from our internal discussion.

The request

contains the age value to be verified and attributes of identity which might be optional

I understand attributes of identity will be optional. Under this assumption, the mandatory attribute to be put into the request body will be the age value only. Is this correct? Or, phoneNumber will be another mandatory attribute?

Many thanks.

[GillesInnov35]

hi @ToshiWakayama-KDDI, yes age value should be mandatory but as it is the case for the others KYC API the phone number will not be mandatory because in 3-Legged Authentication it will not be provided in the request body.
BR
Gilles

[GillesInnov35]

As proposed by @ToshiWakayama-KDDI we could close this issue and continue the discussion in Issue #81 and PR #50.
Thanks