Initial contribution of Age_Verification.yaml #50

ToshiWakayama-KDDI · 2024-02-02T10:40:23Z

What type of PR is this?

enhancement/feature

What this PR does / why we need it:

Initial contribution of Age_Verification.yaml to create the initial version of Age Verification API (v0.1.0)

Which issue(s) this PR fixes:

Related to Issue Creation of a Pull Request for Age Verification API #46

Special notes for reviewers:

Changelog input

Additional documentation

Update the design proposal for Age Verification API specifications

GillesInnov35 · 2024-02-02T13:21:52Z

To start the discussion

Some functional restrictions may exist, for example:
- User's phone number must be the primary phone number of the contract holder because the age of secondary phone number and (particularly for a minor) must not be stored according to the local law
- the returned attribute isVerified (boolean) could be replaced by a string (enum=Y:Yes, N-AV: No, information available, N-NAV: No, information not available).
Also, some information could be help with the decision,
- does a parental control exist for this user phone number?
- tenure of the contract

GillesInnov35

Thanks

GillesInnov35 · 2024-02-05T14:12:01Z

Proposition of User Story

User Story: KYC Age Verification - Verify the age of a user

Item	Details
Summary	As an application developer of an age-restricted site or application, I want to verifiy the age of a customer with user's information held by the MNO.
Roles, Actors and Scope	Roles: Customer:User Actors: Mobile Network Operators (MNO), hyperscalers, application developers, enterprise. Scope: Any phone line (not limited to 4G, 5G)
Pre-conditions	The preconditions are listed below: The Customer:User has provided mandatory information of its identity Application developer has onboarded to MNO API Application developer has API credentials Privacy legal base requirement has been solved (Customer privacy)
Activities/Steps	Starts when: The customer application server makes a request to the Age Verification service (API) with the age restricted value. Ends when: The MNO service returns *True* if the age has been correctly verified else it returns *False*.
Post-conditions	The application developer can make decision to use this customer data to follow-up its process
Exceptions	Several exceptions might occur during the KYC Age Verification API operations: Unauthorized: Not valid credentials (e.g. use of already expired access token). Not Found: The number provided is not managed by the MNO Invalid input: Not all mandatory input data to invoke operation (e.g. phone number).

Add firstName and FamilyName attributes to be compared with MNO information

Addition of MiddleNames

GillesInnov35 · 2024-03-12T08:49:23Z

Find a draft proposal of API documentation (to be reviewed)
KYC-AgeVerify.MD

with Huub (KPN) proposition: assurance level

ToshiWakayama-KDDI · 2024-04-01T10:16:21Z

Hi @GillesInnov35 , all,

Regarding the draft User Story above, it looks good to me. Just some comments for error corrections:

'Scope: Any phone line (not limlited to 4G, 5G)'

limlited -> limited

'Starts when: The customer application server makes a request to the KYC service (API) with the age restricted value.'

the KYC service (API) -> the Age Verification service (API)

'Exceptions Several exceptions might occur during the KYC Match API operations:'

the KYC Match API operations -> the Age Verificaiton API operations

Thanks.
Toshi

assuranceLevel is now a enum (Low, Substancial, High) and not a score.

GillesInnov35 · 2024-04-10T13:48:23Z

Thanks a lot @ToshiWakayama-KDDI , errors have been corrected.
BR
Gilles

Corrections, updated Design and description

GillesInnov35 · 2024-10-09T14:47:09Z

@ToshiWakayama-KDDI, @HuubAppelboom , @KevScarr, @fernandopradocabrillo I've updated this design proposal. Let me know if it's ok according to your comments
Thanks
BR
Gilles

luislopezcorpas · 2024-11-18T08:53:07Z

Hi @ToshiWakayama-KDDI and @GillesInnov35 ,

I wanted to bring to your attention a concern regarding the proposed change from 'unverified' to 'not available' for age verification.

Context

Changing the status from 'unverified' to 'not available' could have significant implications for verification processes and overall system efficiency because some users are typically classified as 'unverified' due to the lack of mandatory identity verification (e.g. UK prepaid users).

Best regards.

GillesInnov35 · 2024-11-18T09:02:37Z

@luislopezcorpas , thanks for your comment.

some users are typically classified as 'unverified' due to the lack of mandatory identity verification (e.g. UK prepaid users).

In this case my thought was that verifiedStatus should be returned to false, shouldn't it ? unverified must be removed from the ageCheck enumeration and the description as prposed by @ToshiWakayama-KDDI .

properties:
ageCheck:
type: "string"
description: Indicates if the age has been verified (true) or not (false). If age information is not available not_available is returned, else unverified indicates that MNO has not verified the validity of the information it holds.
enum:
- 'true'
- 'false'
- 'unverified'
- 'not_available'

BR
Gilles

ToshiWakayama-KDDI · 2024-11-19T06:45:56Z

Thanks, @GillesInnov35 , @luislopezcorpas ,

Actially I would like to propose the following for correction, based on our agreement in Issue #81:

---Current (Line 257 around)---

  properties:

    ageCheck:
     type: "string"
     description: Indicates if the age has been verified (true) or not (false). If age information is not available not_available is returned, else unverified indicates that MNO has not verified the validity of the information it holds.
     enum:
            - 'true'
            - 'false'
            - 'unverified'
            - 'not_available'

---Proposal---

  properties:

    ageCheck:
     type: "string"
     description: 
     Indicate 'true' when the age of the user is older than the age threshold (age >= age threshold), and 'false' if not (age < age threshold).  Otherwise, 'not_available'.
     
     enum:
            - 'true'
            - 'false'
            - 'not_available'

Can I propose the above change directly into the yaml file, @GillesInnov35 ? I am not sure how to do it..

Do you have any problem, @luislopezcorpas ?

Thanks,
Toshi

ToshiWakayama-KDDI · 2024-11-19T06:51:53Z

Hi @GillesInnov35 , all,

I have another proposal for clarification of API Description part for ##Otputs, Line 40 around~ :

---Current---

- `verifiedStatus`: true if the information provided was checked against another form of official identification, otherwise false.
- `identityMatchScore`: the overall match score of identity information provided in the request compared to what MNO holds.

---Proposed---

- `verifiedStatus`: true if the information provided was checked against another form of official identification, otherwise false. [Optional]
- `identityMatchScore`: the overall match score of identity information provided in the request compared to what MNO holds. [Optional]
Note: It is optional for a MNO/API provider to return the match score.  If a MNO/API provider decides not to return the match score, even though any of `idDocument`, `name`, `givenName`, `familyName`, `middieNames`, `familyNameAtBirth`, `birthdate`, `email` are included in the request body, no identityMatchScore parameter will not be returned.

Thanks.

ToshiWakayama-KDDI · 2024-11-19T06:56:15Z

Hi @GillesInnov35 , all,

Another proposal for Request Body Example, LIne 127 around~ :

---Current---

          $ref: '#/components/schemas/KYC_RequestBody'
        examples:
          RequestExample:
            value:
              phoneNumber: '+34629255833'
              idDocument: 66666666q
              name: Federica Sanchez Arjona
              givenName: Federica
              familyName: Sanchez Arjona
              middleNames: Sanchez
              familyNameAtBirth: YYYY
              birthdate: '1978-08-22'                     
              email: "[email protected]" 
              ageThreshold: 18

---Proposeal backgrounds---
・move 'ageThreshold' to the top, as it is only the required parameter.
・remove 'phoneNumber', or add note 'Only required in case a 2-legged flow has been agreed between API Provider and API Consumer'. Not quite sure if this is the right way, though.

---Proposal---

          $ref: '#/components/schemas/KYC_RequestBody'
        examples:
          RequestExample:
            value:
              ageThreshold: 18
              phoneNumber: '+34629255833' [Note: Only required in case a 2-legged flow has been agreed between API Provider and API Consumer; otherwise, none]
              idDocument: 66666666q
              name: Federica Sanchez Arjona
              givenName: Federica
              familyName: Sanchez Arjona
              middleNames: Sanchez
              familyNameAtBirth: YYYY
              birthdate: '1978-08-22'                     
              email: "[email protected]"

Thanks.

HuubAppelboom · 2024-11-19T07:30:04Z

@ToshiWakayama-KDDI @GillesInnov35
I would suggest to make the description for ageCheck as follows:

properties:

ageCheck:
 type: "string"
 description: 
 Indicate 'true' when the age of the user is the same age or older than the age threshold (age >= age threshold), and 'false' if not (age < age threshold).  Otherwise, 'not_available'.
 
 enum:
        - 'true'
        - 'false'
        - 'not_available'

HuubAppelboom · 2024-11-19T07:37:05Z

@ToshiWakayama-KDDI

Regarding your suggestion:

phoneNumber: '+34629255833' [Note: Only required in case a 2-legged flow has been agreed between API Provider and API Consumer; otherwise, none]

I would not recommend to add "otherwise, none", otherwise you have people adding phoneNumber: 'none' literally to the request, complicating the processing. It may be better to simply omit it.

Here is a suggestion:
phoneNumber: '+34629255833' [Note: Only required in case a 2-legged flow has been agreed between API Provider and API Consumer; otherwise, do not include phoneNumber]

GillesInnov35 · 2024-11-19T09:12:35Z

hi @ToshiWakayama-KDDI , @HuubAppelboom , Thanks. if approved I can update the yaml file.
BR
Gilles

luislopezcorpas · 2024-11-20T08:14:36Z

Please @GillesInnov35 , @ToshiWakayama-KDDI , @HuubAppelboom ,

Before approval, I'm reviewing internally in VF. I need some time. I'll come back as soon as possible. Thanks!

GillesInnov35 · 2024-11-20T08:48:25Z

we should have also to update error code sections according what has been proposed by Eric for Tenure API camaraproject/Tenure#11 and the new recommended template for info.description proposed in camaraproject/Commonalities#324.

luislopezcorpas · 2024-11-20T09:47:14Z

Thanks, @GillesInnov35 , @luislopezcorpas ,

Actially I would like to propose the following for correction, based on our agreement in Issue #81:

---Current (Line 257 around)---
  properties:

    ageCheck:
     type: "string"
     description: Indicates if the age has been verified (true) or not (false). If age information is not available not_available is returned, else unverified indicates that MNO has not verified the validity of the information it holds.
     enum:
            - 'true'
            - 'false'
            - 'unverified'
            - 'not_available'
---Proposal---
  properties:

    ageCheck:
     type: "string"
     description: 
     Indicate 'true' when the age of the user is older than the age threshold (age >= age threshold), and 'false' if not (age < age threshold).  Otherwise, 'not_available'.
     
     enum:
            - 'true'
            - 'false'
            - 'not_available'
Can I propose the above change directly into the yaml file, @GillesInnov35 ? I am not sure how to do it..

Do you have any problem, @luislopezcorpas ?

Thanks, Toshi

All rigth Toshi,

No problem with changing "true, false, unverified, and not available" to "true, false, and not available" in ageCheck if verifiedStatus is keept as optional

ToshiWakayama-KDDI · 2024-11-20T10:36:41Z

Hi @GillesInnov35 , @HuubAppelboom , @luislopezcorpas ,

This is my last proposal to the current YAML, which was shared in Issue #81.

As we have decided to make phoneNumber 'not included in the request' for Age Verification API, I think we need to modify the Error handling part of the API Description, becuase current text is not applicable. (I think it is ok because Guidlielines is just a guideline.) I would propose this here in PR to incoporate into the current YAML, as there is discrepancy existing.

The following is an idea for modification.

---Current---

Identifying a device from the access token

This specification defines the phoneNumber field as optional in API requests, specifically in cases where the API is accessed using a 3-legged access token, and the device can be uniquely identified by the token. This approach simplifies API usage for API consumers by relying on the device information associated with the access token used to invoke the API.

Handling of device information:

Optional phoneNumber for 3-legged tokens:

When using a 3-legged access token, the device associated with the access token must be considered as the device for the API request. This means that the phoneNumber is not required in the request, and if included it must identify the same device, therefore it is recommended NOT to include it in these scenarios to simplify the API usage and avoid additional validations.

Validation mechanism:

The server will extract the device identification from the access token, if available.
If the API request additionally includes a phoneNumber parameter when using a 3-legged access token, the API will validate that the device identifier provided matches the one associated with the access token.
If there is a mismatch, the API will respond with a 403 INVALID_TOKEN_CONTEXT error, indicating that the device information in the request does not match the token.

Error handling for unidentifiable devices:

If the phoneNumber parameter is not included in the request and the device information cannot be derived from the 3-legged access token, the server will return a 422 UNIDENTIFIABLE_DEVICE error.

Restrictions for tokens without an associated authenticated identifier:

For scenarios which do not have a single device identifier associated to the token during the authentication flow, e.g. 2-legged access tokens, the phoneNumber parameter MUST be provided in the API request. This ensures that the device identification is explicit and valid for each API call made with these tokens.

---Proposed change---

Identifying a device from the access token

This specification defines the phoneNumber field as required ~~optional~~ in API requests, specifically in cases where the API is accessed using a 2-legged access token (under agreement between API Consumer and API Provider). However, this specification defines it as none in cases where the API is accessed using a 3-legged access token, ~~and~~ because the device can be uniquely identified by the token. This approach simplifies API usage for API consumers by relying on the device information associated with the access token used to invoke the API.

Handling of device information:

Optional phoneNumber for 3-legged tokens:

When using a 3-legged access token, the device associated with the access token must be considered as the device for the API request. This means that the phoneNumber is not required in the request, and so if included it must be neglected identify the same device, therefore it is recommended NOT to include it in these scenarios to simplify the API usage and avoid additional validations.

Validation mechanism:

~~The server will extract the device identification from the access token, if available.~~
If the API request additionally includes a phoneNumber parameter when using a 3-legged access token, the API will validate that the device identifier provided matches the one associated with the access token.
~~If there is a mismatch, the API will respond with a 403 INVALID_TOKEN_CONTEXT error, indicating that the device information in the request does not match the token.~~

Error handling for unidentifiable devices:

If the phoneNumber ~~parameter is not included in the request and the device information~~ cannot be derived from the 3-legged access token, the server will return a 422 UNIDENTIFIABLE_DEVICE error.

Restrictions for tokens without an associated authenticated identifier:

For scenarios which do not have a single device identifier associated to the token during the authentication flow, e.g. 2-legged access tokens, the phoneNumber parameter MUST be provided in the API request. This ensures that the device identification is explicit and valid for each API call made with these tokens.

BR
Toshi

ToshiWakayama-KDDI · 2024-11-20T10:44:24Z

Thank you, @GillesInnov35 ,

we should have also to update error code sections according what has been proposed by Eric for Tenure API camaraproject/Tenure#11 and the new recommended template for info.description proposed in camaraproject/Commonalities#324.

May I ask one question? I understand the new recommended template proposed in camaraproject/Commonalities#324 is for v0.5 Spring25. Are error sections that have been proposed by Eric for Tenure API aligned with commonalities v0.5?

Thanks,
Toshi

GillesInnov35 · 2024-11-20T13:26:07Z

hi @ToshiWakayama-KDDI , I guess @rartych and Eric will confirm. From what I compared it seems to be fully aligned with https://github.com/camaraproject/Commonalities/blob/a9caf6472908abc60fdd203fe33040e0caa259a7/artifacts/CAMARA_common.yaml.
As it has been done for Tenure API we may include in advance this next version commonalities. Do you agree ?

Thanks

Gilles

ToshiWakayama-KDDI · 2024-11-21T07:44:08Z

Hi @GillesInnov35 ,

hi @ToshiWakayama-KDDI , I guess @rartych and Eric will confirm. From what I compared it seems to be fully aligned with https://github.com/camaraproject/Commonalities/blob/a9caf6472908abc60fdd203fe33040e0caa259a7/artifacts/CAMARA_common.yaml. As it has been done for Tenure API we may include in advance this next version commonalities. Do you agree ?

Thanks. Yeah. I think we should release the initial version as early as possible, as GSMA is pushing us. So, basically it is fine with me to include those error codes in advance, as long as they are aligned with Commonalities v0.5 i.e. for Spring25 meta. Shoud I look at this Tenure YAML https://github.com/camaraproject/Tenure/pull/11/files ?

But I would also like to iterate my last proposal above #50 (comment) , as I believe we should do this customisation because, for Age Verification API, we have decided to omit phoneNumber attribute in the request body, so there is no optional phoneNumber and no need for validation between phoneNumber input and phoneNumber derived from 3-legged access token. Template is just a template (not must), and we should customise it for our Age Verification API. Hope everyone agrees with this.

Thanks,
Toshi

fernandopradocabrillo · 2024-11-22T13:34:16Z

But I would also like to iterate my last proposal above #50 (comment) , as I believe we should do this customisation because, for Age Verification API, we have decided to omit phoneNumber attribute in the request body, so there is no optional phoneNumber and no need for validation between phoneNumber input and phoneNumber derived from 3-legged access token. Template is just a template (not must), and we should customise it for our Age Verification API. Hope everyone agrees with this.

Hi @ToshiWakayama-KDDI I'm sorry I think I've missed this discussion, can you point me to the conversatation where it was decided to drop the phone number from the request? Thanks!!

ToshiWakayama-KDDI · 2024-11-23T04:41:19Z

Hi @fernandopradocabrillo ,

Thanks for your comment. Sure.

(1) GitHub Issue #81 Discussions before Meeting 2024-10-29

#81 (comment)

(2) Discussion at the Meeting 2024-10-29

https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/30867809/2024-10-29+KYC+Match+Fill-in+Age+Veri+Tenure+Number+Rec+Sub+Status+Minutes#Age-Verification-API--Repo
Meeting minutes Age Verification Part、2024-10-29

It seemed that only KDDI was against removing optional phoneNumber.

(3) GitHub Issue #81 Discussion after the Meeting 2024-10-29

#81 (comment)
KDDI agreed to remove optional phoneNumber from Age Verification API.
(Note: We did not agree to remove optional phoneNumber from KYC Match API.)

Then, our agreed core spec of Age Verification was modified as:
#81 (comment)

Hope this helps, but please let me know if you need anything else or if you have any other questions.

Best regards,
Toshi

ToshiWakayama-KDDI · 2024-11-25T10:59:20Z

Hi @GillesInnov35 ,

Hi @GillesInnov35 ,

hi @ToshiWakayama-KDDI , I guess @rartych and Eric will confirm. From what I compared it seems to be fully aligned with https://github.com/camaraproject/Commonalities/blob/a9caf6472908abc60fdd203fe33040e0caa259a7/artifacts/CAMARA_common.yaml. As it has been done for Tenure API we may include in advance this next version commonalities. Do you agree ?

Thanks. Yeah. I think we should release the initial version as early as possible, as GSMA is pushing us. So, basically it is fine with me to include those error codes in advance, as long as they are aligned with Commonalities v0.5 i.e. for Spring25 meta. Shoud I look at this Tenure YAML https://github.com/camaraproject/Tenure/pull/11/files ?

But I would also like to iterate my last proposal above #50 (comment) , as I believe we should do this customisation because, for Age Verification API, we have decided to omit phoneNumber attribute in the request body, so there is no optional phoneNumber and no need for validation between phoneNumber input and phoneNumber derived from 3-legged access token. Template is just a template (not must), and we should customise it for our Age Verification API. Hope everyone agrees with this.

Thanks, Toshi

I have looked through the latest Tenure yaml file, and I think it is fine with me to follow their error responses. There might be some differences because of diffferent scope of Age Verification API and Tenure API, though.

Other than this, I have also checked Commonalities PR #324 (camaraproject/Commonalities#324) to find the new sentences about "Identifying the phone number from the access token" part as below. We need to modify the same part of Age Verification based on this.

========

Identifying the phone number from the access token

This API requires the API consumer to identify a phone number as the subject of the API as follows:

When the API is invoked using a two-legged access token, the subject will be identified from the optional phoneNumber field, which therefore MUST be provided.
When a three-legged access token is used however, this optional identifier MUST NOT be provided, as the subject will be uniquely identified from the access token.

This approach simplifies API usage for API consumers using a three-legged access token to invoke the API by relying on the information that is associated with the access token and was identified during the authentication process.

Error handling:

If the subject cannot be identified from the access token and the optional phoneNumber field is not included in the request, then the server will return an error with the 422 MISSING_IDENTIFIER error code.
If the subject can be identified from the access token and the optional phoneNumber field is also included in the request, then the server will return an error with the 422 UNNECESSARY_IDENTIFIER error code. This will the case even if the same phone number is identified by these two methods, as the server is unable to make this comparison.

========

For the above new sentences, I still believe we need to cusutomise them. As we have decided no phoneNumber input for 3-legged access token cases, we do not need to consider "the optional phoneNumber field is not included in the request" and "the optional phoneNumber field is also included in the request" in the two Error Handling bullets, if you agree.

Thanks.
Toshi

Updates according to propositions

GillesInnov35 · 2024-11-25T16:05:32Z

hi @ToshiWakayama-KDDI , I don't get clearly what you'd like to update/add. I've updated the yaml with your and @HuubAppelboom propositions (I hope all of them have been included, excepted the last one).
Could you have a look and see what should be modified before asking approval.
Thanks a lot
Gilles

ToshiWakayama-KDDI · 2024-11-26T07:49:49Z

Thank you, @GillesInnov35 . I will take a look, and will get what I would like to update/add clear.

Thanks,
Toshi

code/API_definitions/age-vefification.yaml

fernandopradocabrillo · 2024-11-26T11:44:43Z

code/API_definitions/age-vefification.yaml

+        "400":
+          $ref: '#/components/responses/Generic400'
+        "401":
+          $ref: '#/components/responses/Generic401'
+        "403":
+          $ref: '#/components/responses/Generic403'
+        "404":
+          $ref: '#/components/responses/Generic404'
+        "406":
+          $ref: '#/components/responses/Generic406'
+        "415":
+          $ref: '#/components/responses/Generic415'
+        "422":
+          $ref: '#/components/responses/Generic422'
+        "429":
+          $ref: '#/components/responses/Generic429'
+        "500":
+          $ref: '#/components/responses/Generic500'
+        "503":
+          $ref: '#/components/responses/Generic503'
+        "504":
+          $ref: '#/components/responses/Generic504'


The current proposal in Commonalities is to only include the relevant errors (401, 403 and 429) in addition to functionality errors that the WG might include. The motive is that common errors are expected to be implemented by all services so there is no need to include them in the yaml API definition. I would remove the rest just for simplicity (406, 415, 500, 503, and 504).

Suggested change

"400":

$ref: '#/components/responses/Generic400'

"401":

$ref: '#/components/responses/Generic401'

"403":

$ref: '#/components/responses/Generic403'

"404":

$ref: '#/components/responses/Generic404'

"406":

$ref: '#/components/responses/Generic406'

"415":

$ref: '#/components/responses/Generic415'

"422":

$ref: '#/components/responses/Generic422'

"429":

$ref: '#/components/responses/Generic429'

"500":

$ref: '#/components/responses/Generic500'

"503":

$ref: '#/components/responses/Generic503'

"504":

$ref: '#/components/responses/Generic504'

"400":

$ref: '#/components/responses/Generic400'

"401":

$ref: '#/components/responses/Generic401'

"403":

$ref: '#/components/responses/Generic403'

"404":

$ref: '#/components/responses/Generic404'

"422":

$ref: '#/components/responses/Generic422'

"429":

$ref: '#/components/responses/Generic429'

Source: camaraproject/Commonalities#329

Hi @fernandopradocabrillo , at Orange only 406 - NOT_ACCEPTABLE (The server cannot produce a response matching the content requested by the client through Accept-* headers) has been currently removed from our study.
For example 504 - TIME OUT is a common error use case, isn't it ?

Hi @fernandopradocabrillo , hi @GillesInnov35 ,

For me, I am not sure if we need the following errors. Do we need them? Could you advise me in what case these errors may happen, please?

400 KNOW_YOUR_CUSTOMER.INVALID_PARAM_COMBINATION

403 KNOW_YOUR_CUSTOMER.INVALID_TOKEN_CONTEXT

Many thanks,

Thanks @GillesInnov35 . I would agree to remove 406 - NOT_ACCEPTABLE.

Best regards,
Toshi

fernandopradocabrillo · 2024-11-26T11:45:57Z

code/API_definitions/age-vefification.yaml

+    description: Operations to verify the age of a user.
+
+paths:
+  /ageverify:


can't the endpoint be just /verify?

Thanks, but no, we can't. This path name was agreed by Sub Project in the early stage and it has not been changed since then. Technically, maybe yes, but we KDDI would not agree to change it.

Thanks,
Toshi

hi @fernandopradocabrillo , @ToshiWakayama-KDDI , /verify is already used for number-verification API.
For Tenure API /check-tenure has been choosen. May be verify-age could be proposed if the previous one is not approved by all.
Gilles

It's not really a big deal, just a comment to simplify, I hadn't noticed it before. For me /verify or /verify-age is more align with the rest of CAMARA APIs, but I'm late to this conversation so I will live with whatever you decide 😶

Thanks, @fernandopradocabrillo , Thanks, @GillesInnov35 ,

I would like to stick to the existing 'ageverify', if it can be accepted by all. I think 'ageverify' is not prohibited by Commonalities, and alignment with other CAMARA APIs may be a subjective matter. But if you have problem with 'ageverify', please let me/us know. Otherwise, let's keep it.

Best regards,
Toshi

fernandopradocabrillo · 2024-11-26T11:46:59Z

code/API_definitions/age-vefification.yaml

+
+    Other errors may be returned as specified below.
+
+    # Identifying a device from the access token


If we align with commonalities for Spring25 we need to update this section

code/API_definitions/age-vefification.yaml

Co-authored-by: Fernando Prado Cabrillo <[email protected]>

ToshiWakayama-KDDI · 2024-11-28T05:15:56Z

hi @GillesInnov35 , hi @fernandopradocabrillo ,

As we have added the ageThreshold value range, we need the following error, I think:
Status: 400
Code: OUT_OF_RANGE
Message: Phone number mismatch with access token context

Thanks,
Toshi

Initial contribution of Age_Verification.yaml

2c40283

ToshiWakayama-KDDI requested review from fernandopradocabrillo and GillesInnov35 as code owners February 2, 2024 10:40

ToshiWakayama-KDDI mentioned this pull request Feb 2, 2024

Creation of a Pull Request for Age Verification API #46

Closed

Update age-verification.yaml

ed7003f

Update the design proposal for Age Verification API specifications

GillesInnov35 previously approved these changes Feb 2, 2024

View reviewed changes

Update age-vefification.yaml

0335b85

GillesInnov35 dismissed their stale review via 0335b85 February 16, 2024 09:14

GillesInnov35 added 3 commits March 5, 2024 10:20

Update age-vefification.yaml

ea5d63a

Add firstName and FamilyName attributes to be compared with MNO information

Update age-vefification.yaml

da5d59c

Addition of MiddleNames

Update age-vefification.yaml

6673fe5

Update age-vefification.yaml

ae2c024

with Huub (KPN) proposition: assurance level

HuubAppelboom approved these changes Mar 27, 2024

View reviewed changes

Update age-vefification.yaml

d35564d

assuranceLevel is now a enum (Low, Substancial, High) and not a score.

GillesInnov35 mentioned this pull request May 22, 2024

Add Age Verification to KnowYourCustomer SP's Scope in README #81

Open

GillesInnov35 added 9 commits May 22, 2024 16:22

Update age-vefification.yaml

52f2ca6

Update age-vefification.yaml

754c2e0

Update age-vefification.yaml

82647d1

Update age-vefification.yaml

830e390

Update age-vefification.yaml

4bd8a34

Update age-vefification.yaml

c4863dd

Update age-vefification.yaml

007c6c0

Update age-vefification.yaml

abc4093

Update age-vefification.yaml

b4a2009

Corrections, updated Design and description

Update age-vefification.yaml

a9ad64d

Updates according to propositions

fernandopradocabrillo reviewed Nov 26, 2024

View reviewed changes

GillesInnov35 and others added 7 commits November 26, 2024 13:41

Update code/API_definitions/age-vefification.yaml

a7526d1

Co-authored-by: Fernando Prado Cabrillo <[email protected]>

Update code/API_definitions/age-vefification.yaml

6b505d2

Co-authored-by: Fernando Prado Cabrillo <[email protected]>

Update code/API_definitions/age-vefification.yaml

d645e58

Co-authored-by: Fernando Prado Cabrillo <[email protected]>

Update code/API_definitions/age-vefification.yaml

81ff0fc

Co-authored-by: Fernando Prado Cabrillo <[email protected]>

Update code/API_definitions/age-vefification.yaml

e9029f2

Co-authored-by: Fernando Prado Cabrillo <[email protected]>

Update code/API_definitions/age-vefification.yaml

0f344ce

Co-authored-by: Fernando Prado Cabrillo <[email protected]>

Update code/API_definitions/age-vefification.yaml

ee4538f

Co-authored-by: Fernando Prado Cabrillo <[email protected]>


		Other errors may be returned as specified below.

		# Identifying a device from the access token

Initial contribution of Age_Verification.yaml #50

Are you sure you want to change the base?

Initial contribution of Age_Verification.yaml #50

Conversation

ToshiWakayama-KDDI commented Feb 2, 2024

What type of PR is this?

What this PR does / why we need it:

Which issue(s) this PR fixes:

Special notes for reviewers:

Changelog input

Additional documentation

GillesInnov35 commented Feb 2, 2024 • edited Loading

GillesInnov35 left a comment

Choose a reason for hiding this comment

GillesInnov35 commented Feb 5, 2024 • edited Loading

Proposition of User Story

GillesInnov35 commented Mar 12, 2024

ToshiWakayama-KDDI commented Apr 1, 2024

GillesInnov35 commented Apr 10, 2024

GillesInnov35 commented Oct 9, 2024

luislopezcorpas commented Nov 18, 2024

GillesInnov35 commented Nov 18, 2024 • edited Loading

ToshiWakayama-KDDI commented Nov 19, 2024

ToshiWakayama-KDDI commented Nov 19, 2024

ToshiWakayama-KDDI commented Nov 19, 2024

HuubAppelboom commented Nov 19, 2024

HuubAppelboom commented Nov 19, 2024

GillesInnov35 commented Nov 19, 2024

luislopezcorpas commented Nov 20, 2024

GillesInnov35 commented Nov 20, 2024 • edited Loading

luislopezcorpas commented Nov 20, 2024

ToshiWakayama-KDDI commented Nov 20, 2024

Identifying a device from the access token

Handling of device information:

Optional phoneNumber for 3-legged tokens:

Validation mechanism:

Error handling for unidentifiable devices:

Restrictions for tokens without an associated authenticated identifier:

Identifying a device from the access token

Handling of device information:

Optional phoneNumber for 3-legged tokens:

Validation mechanism:

Error handling for unidentifiable devices:

Restrictions for tokens without an associated authenticated identifier:

ToshiWakayama-KDDI commented Nov 20, 2024

GillesInnov35 commented Nov 20, 2024

ToshiWakayama-KDDI commented Nov 21, 2024

fernandopradocabrillo commented Nov 22, 2024

ToshiWakayama-KDDI commented Nov 23, 2024

ToshiWakayama-KDDI commented Nov 25, 2024

Identifying the phone number from the access token

Error handling:

GillesInnov35 commented Nov 25, 2024

ToshiWakayama-KDDI commented Nov 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ToshiWakayama-KDDI commented Nov 28, 2024

GillesInnov35 commented Feb 2, 2024 •

edited

Loading

GillesInnov35 commented Feb 5, 2024 •

edited

Loading

GillesInnov35 commented Nov 18, 2024 •

edited

Loading

GillesInnov35 commented Nov 20, 2024 •

edited

Loading