Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add user story #71

Merged
merged 7 commits into from
Jul 18, 2024
Merged

Add user story #71

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
73d39ed
Add Readiness checklist
bigludo7 Jul 9, 2024
5fa40b4
Add user story
bigludo7 Jul 9, 2024
6ff2e46
Update OTPValidationAPI_User_Story following Jorge review
bigludo7 Jul 15, 2024
9b64b1f
Update OTPValidationAPI_User_Story.md
bigludo7 Jul 15, 2024
c891f6a
Update OTPValidationAPI_User_Story after internal review
bigludo7 Jul 16, 2024
ee927bf
Delete documentation/API_documentation/OTPvalidationAPI-Readiness-Che…
bigludo7 Jul 16, 2024
f3d3909
Update documentation/API_documentation/OTPValidationAPI_User_Story.md
bigludo7 Jul 17, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions documentation/API_documentation/OTPValidationAPI_User_Story.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
# OTPVAlidationAPI API User Story

OTP Validation user story is splitted in 2 steps. Both steps are mandatory to perform this user story.
bigludo7 marked this conversation as resolved.
Show resolved Hide resolved

## Step 1 - Request to send a code

| **Item** | **Details** |
| ---- | ------- |
| ***Summary*** | As an enterprise application developer, I want to verify the phone number associated with the line from which the call was made, so I can get a proof of possession of the phone number. |
| ***Roles, Actors and Scope*** | **Roles:** Customer:User, Customer:BusinessManager, Customer:Administrator<br> **Actors:** Application service providers, hyperscalers, application developers, end users. <br> **Scope:** <br> - Customer:user asks CSP to send a message featuring a 'code' variable via SMS. The message is specified by Customer:user. In the API response a request identifier is provided to link with validation step. |
| ***Pre-conditions*** |The preconditions are listed below:<br><ol><li>The Customer:BusinessManager and Customer:Administrator have been onboarded to the CSP's API platform.</li><li>The Customer:BusinessManager has successfully subscribed to the OTP Validation API product from the product catalog.</li><li>The Customer:Administrator has onboarded the Customer:User to the platform.</li><li>The Customer:user performs an authorization request to CSP</li><li>The Customer:user has the access token alllowing a secure access of the API.|
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alllowing --> allowing

| ***Activities/Steps*** | **Starts when:** The customer application makes a POST send-code via the OTPValidation API providing in the request the phone number keyed by the user on the application and a message to be displayed in the SMS. This message must indicate where the code must be indicated (like _"Your code to validate your onboarding for niceApp is {code}"_).<br>**Ends when:** The OTP Validation server performs two operations: 1/answers to the API request providing a request identifier (authenticationId), and 2/send the SMS to the line identified by provided phone number. |
| ***Post-conditions*** | The customer application has a request identifier (authenticationId) and will be able to validate code keyed by the user. |
| ***Exceptions*** | Several exceptions might occur during the OTP Validation API operations<br>- Unauthorized: Not valid credentials.<br>- Invalid input: Not valid input data to invoke operation (e.g. phone number without the '+' prefix).<br>- Permission denied: Too any request to send code for a phone number in a short time. <br>- Permission denied: phone number not able to receive SMS.|


## Step 2 - Validate a code

| **Item** | **Details** |
| ---- | ------- |
| ***Summary*** | As an enterprise application developer, I want to verify the phone number associated with the line from which the call was made, so I can get a proof of possession of the phone number. |
| ***Roles, Actors and Scope*** | **Roles:** Customer:User, Customer:BusinessManager, Customer:Administrator<br> **Actors:** Application service providers, hyperscalers, application developers, end users. <br> **Scope:** <br> - Following a send code request, customer:user asks end user to keyed the code received by SMS. Then customer:user send this code to the CSP to validate that the code matches the one send by the CSP in the SMS. |
| ***Pre-conditions*** |The preconditions are listed below:<br><ol><li>The Customer:BusinessManager and Customer:Administrator have been onboarded to the CSP's API platform.</li><li>The Customer:BusinessManager has successfully subscribed to the OTP Validation API product from the product catalog.</li><li>The Customer:Administrator has onboarded the Customer:User to the platform.</li><li>The Customer:user performs an authorization request to CSP</li><li>The Customer:user has the access token alllowing a secure access of the API.</li><li> The Customer:user has performed a valid send code previously and have the request identifier (authenticationId). |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: Include action end-user receives SMS code and provides to Customer:user application

| ***Activities/Steps*** | **Starts when:** The customer application makes a POST validate-code via the OTPValidation API providing in the request the code keyed by the user on the application and the authenticationId obtained in the response of the send-code step. .<br>**Ends when:** The OTP Validation server check the code and answers 204 if the code matches else an exception is sent. |
| ***Post-conditions*** | The customer application could continue offering its service to the user with the confirmation of the user phone number. |
| ***Exceptions*** | Several exceptions might occur during the OTP Validation API operations<br>- Unauthorized: Not valid credentials.<br>- Invalid input: Not valid input data to invoke operation (e.g. code not provided).<br>- Invalid input: The maximum number of attempts for this authenticationId was exceeded without providing a valid OTP <br>- Invalid input:The provided OTP is not valid for this authenticationId<br>- Invalid input:The authenticationId is no longer valid|
25 changes: 25 additions & 0 deletions documentation/API_documentation/OTPvalidationAPI-Readiness-Checklist.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# API Readiness Checklist

Checklist for one-time-password-sms api-version in vx

| Nr | API release assets | alpha | release-candidate | public-release<br>initial | public-release<br> stable | Status | Comments |
|----|----------------------------------------------|:-----:|:-----------------:|:-------:|:------:|:----:|:----:|
| 1 | API definition | M | M | M | M | Y | [link](https://github.com/camaraproject/OTPvalidationAPI/blob/main/code/API_definitions/one-time-password-sms.yaml) |
| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | |
| 3 | Guidelines from ICM applied | O | M | M | M | Y | |
| 4 | API versioning convention applied | M | M | M | M | Y | |
| 5 | API documentation | M | M | M | M | Y | Embed documentation into API spec - [link](https://github.com/camaraproject/OTPvalidationAPI/blob/main/code/API_definitions/one-time-password-sms.yaml) |
| 6 | User stories | O | O | O | M | N | link |
| 7 | Basic API test cases & documentation | O | M | M | M | N | link |
| 8 | Enhanced API test cases & documentation | O | O | O | M | N | link |
| 9 | Test result statement | O | O | O | M | N | link |
| 10 | API release numbering convention applied | M | M | M | M | Y | |
| 11 | Change log updated | M | M | M | M | N | link |
| 12 | Previous public-release was certified | O | O | O | M | Y | |




Note: It is normal that the checklists of the (final) release-candidate and its subsequent public-release are the same, while additional release assets are required for a subsequent stable public-release.

The documentation for the content of the checklist is here: [API Readiness Checklist documentation](https://wiki.camaraproject.org/x/AgAVAQ#APIReleaseProcess-APIreadinesschecklist)