Spring25-v2

[FabrizioMoggio]

V2 PR to fulfill Spring25 scope: #114

• update of the Authorization and authentication section in Info. description
• alignment of section "Identifying the phone number from the access token" in info.description with Commonalities 0.5.0
• partial update of the RCL
• update the Readme.md file
• Remove unused Error codes
• Alignments in Errors
• Phone Number retrieval
• Phone Number retrieval and Testing
• Align API-Testing with Error codes
• 422 error code
• 50x error too obvious
• Test Case: login_hint

What type of PR is this?

• documentation
• correction

What this PR does / why we need it:

To be aligned with Commonalities v0.5.0
To update the code according to the outcomes of the implementation of v0.2.0

Which issue(s) this PR fixes:

#114
#120
#122
#126 (not a complete fix)
#127
#129
#119
#130
#131
#123
#132
#133
#134

[FabrizioMoggio]

Dear @bigludo7 and @chinaunicomyangfan we must merge the PR before mid January. when this PR will be merged I will create a new one moving the release number from WIP to V1.0.0-rc.1 (hoping that GSMA certifies the implementation developed by @StefanoFalsetto-CKHIOD). To meet M3.

[bigludo7]

Hello dear @FabrizioMoggio
Thanks for this !
Comments to your consideration:

• We should remove 500 & 503 errors from the yaml as stated here: Enhancements and Alignments in Errors Commonalities#321 (comment) - Indeed we do not have specificities from our API requiring them
• As in the request we use strictly the phoneNumber and not the device structure (allowing use of ip or externalIdentifier) we should never have the case for 422 UNSUPPORTED_IDENTIFIER. We will not be able to provide a test case. WDYT?
• IDENTIFIER_MISMATCH value in your enum line 531 must be also removed I guess

[bigludo7]

Another one @FabrizioMoggio where I would like to get your view (not asking for change but to get your perspective).

In the TC you use the formulation "login_hint" is set to a properly formatted phone number - It closes the use of the 3-legged to CIBA. Should we flex this and use instead The header "Authorization" is set to a valid access token identifying a phoneNumber formulation?

Perhaps the use of CIBA is so evident for this API?

[FabrizioMoggio]

Hello dear @FabrizioMoggio Thanks for this ! Comments to your consideration:

• We should remove 500 & 503 errors from the yaml as stated here: Enhancements and Alignments in Errors Commonalities#321 (comment) - Indeed we do not have specificities from our API requiring them
• As in the request we use strictly the phoneNumber and not the device structure (allowing use of ip or externalIdentifier) we should never have the case for 422 UNSUPPORTED_IDENTIFIER. We will not be able to provide a test case. WDYT?
• IDENTIFIER_MISMATCH value in your enum line 531 must be also removed I guess

• In my understanding the reason for removing 500 and 503 is that they are common and generic errors that should be implemented but not documented in the YAML because too obvious. Is this correct? So I agree.
• About 422 UNSUPPORTED_IDENTIFIER, I agree.
• Bout IDENTIFIER_MISMATCH, I agree

what about 504? I think that, for the same reason we have for 500 and 504, we should also remove 504.

[FabrizioMoggio]

Another one @FabrizioMoggio where I would like to get your view (not asking for change but to get your perspective).

In the TC you use the formulation "login_hint" is set to a properly formatted phone number - It closes the use of the 3-legged to CIBA. Should we flex this and use instead The header "Authorization" is set to a valid access token identifying a phoneNumber formulation?

Perhaps the use of CIBA is so evident for this API?

You are totally right, login_hint is too specific, I also prefer a more generic phrasing as you suggested.

[bigludo7]

Thanks @FabrizioMoggio

I share your understanding for 5xx errors.
--> Yes we should also remove 504

[FabrizioMoggio]

"phoneNumber" is the name of the parameter in the API. The header identifies the "phone number". Isn't it? So I suggest to modify the sentence as:

The header "Authorization" is set to a valid access token identifying a phone number.

[bigludo7]

@FabrizioMoggio I've update the feature files to replace the login_hint by the The header "Authorization" is set to a valid access token identifying a phoneNumber

[bigludo7]

"phoneNumber" is the name of the parameter in the API. The header identifies the "phone number". Isn't it? So I suggest to modify the sentence as:

The header "Authorization" is set to a valid access token identifying a phone number.

Yes you're right !
I update the files

[bigludo7]

Changed phoneNumber to phone number ;)

[FabrizioMoggio]

LGTM

[bigludo7]

LGTM