-
Notifications
You must be signed in to change notification settings - Fork 46
Create APIproposal_Voice OTP Call #263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
03b1810
2bd5b64
92d5b5b
2874f41
1ea62cd
3f7c0de
66e7e5b
369e172
68a16e0
30f744f
992df41
e9cb367
03461b5
03399a4
af8316a
92a07b1
c1da7c6
ae8875e
85c677c
e98cc0e
0e99810
924cc4a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,48 @@ | ||
| # API Proposal Template | ||
| This template captures all the information that a partner should fill out when proposing a new API (or API family) to CAMARA. | ||
|
|
||
|
|
||
| ### API family name | ||
| Voice One-Time Password (OTP) Call | ||
|
|
||
| ### API family owner | ||
| Heksagon | ||
|
|
||
| ### API summary | ||
| The “Voice One Time Password Call” API is used to send short-lived one time passwords (OTP) to a phone number via voice call and validate it afterwards, in order to provide a proof of possession of the phone number. | ||
| Voice OTP Call API performs real-time checks to verify that the user possessed the device that carries the indicated mobile phone number. It provides a frequent method of verifying possession of the device by delivering an OTP through voice call and validating it afterwards. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Reading this in more depth, I see it more as a scope enhancement of the current OTP repository than a new API. Could you have a conversation via an issue with the OTP group?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @albertoramosmonagas if you can kindly elaborate the exact requirement and I would be happy to do so.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would simply create an issue in the group or a discussion thread asking if there could be an overlap in functionality between this API proposal and the existing OTPValidation API, because after reading the description of this proposal, I feel that it could be an improvement on the current API. |
||
| Voice OTP Call API is a secure method for providing one-time access to an application or performing a single transaction. It is possible to deliver OTP code in different languages including regional and local languages in different countries. Upon answering the voice call, the recipient would hear OTP code two to three times in different supported languages e.g. English-German-Spanish, English-Hindi-Urdu etc. | ||
| The recipient then uses this code or password as an additional layer of security to login to a service, website or app. | ||
| Use cases | ||
| • Online Banking: To authenticate users during login and transactions, ensuring secure access to financial accounts. | ||
| • Account Registration: To confirm user identity during account creation by sending a verification code to their mobile device. | ||
| • Password Recovery: To securely verify users when they request to reset their passwords, ensuring only the rightful owner can make changes. | ||
| • Two-Factor Authentication (2FA): To enhance security for sensitive applications by requiring a second verification step via call after entering a password. | ||
| Benefits | ||
| The One Time Password Call API has several benefits for the API consumer: | ||
| • Enhanced Security: OTPs provide an additional layer of security beyond passwords, reducing the risk of unauthorized access. | ||
| • User Verification: Ensures that the user has access to the registered mobile device, confirming their identity. | ||
| • Cost-Effective: Reduces the need for complex authentication systems while providing strong security. | ||
| • User Trust: Increases user confidence in the security of the platform, leading to higher user satisfaction. | ||
|
|
||
| ### Technical viability | ||
| API represents an attempt to standardize interfaces between OTP Call solutions deployed by MNOs or external providers and their enterprise users. As such the API is not bound to any specific cloud platform or specific solution but aims to encourage vendors providing MNO or enterprise solution to support this API format and assure interoperability between different solutions. | ||
|
|
||
| ### Commercial viability | ||
mbkhanhex marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| For user registration, part of 2FA, dynamic verification codes, payment confirmation, and other scenarios. | ||
|
|
||
| ### YAML code available? | ||
mbkhanhex marked this conversation as resolved.
Show resolved
Hide resolved
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And if you already have a YAML file from the API, you can upload it to this PR, but to the documentation/SupportingDocuments path with the API name.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @albertoramosmonagas I dont have the privileges to do so, please check the snapshot below
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In this case, it is not “uploading a file” by attaching it to the pull request. In the “mbkhanhex:patch-3” branch you created, you would create a new file in the “documentation/SupportingDocuments” path for the YAML and another for the PPT associated with the proposal. |
||
| YES | ||
|
|
||
| ### Validated in lab/productive environments? | ||
| YES, Lab environment | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Specify if was a lab network or productive network
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is already mentioned as Lab environment, please check |
||
|
|
||
| ### Validated with real customers? | ||
| NO. API has not been deployed real use yet but we are in communication with several interested parties and expect PoC by Q1 2026 | ||
|
|
||
| ### Validated with operators? | ||
mbkhanhex marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Not yet. It is one of our new products and hence we didn’t get an opportunity to get it validated with some telco operators. We are expecting some PoC to start by Q1 2026 | ||
|
|
||
| ### Supporters in API Backlog Working Group | ||
| List of supporters. | ||
| *NOTE: That shall be added by the Working Group. Supporting an API proposal means that the supporting company must provide at least 1 (one) Maintainer at the time of the Sub Project creation.* | ||

Uh oh!
There was an error while loading. Please reload this page.