camaraproject / OTPValidation

Repository to describe, develop, document and test the OTP Validation API family
https://wiki.camaraproject.org/display/CAM/OTPValidation
Apache License 2.0
6 stars 13 forks source link

Send Code api: Parameter details #27

Closed sahidkhangithub closed 1 year ago

sahidkhangithub commented 1 year ago

Hi Team,

Can you support to provide detail/suggestion/comment on below points

  1. '{{code}}' : do this code(OTP) will have expire, a. if yes do it changes from useCase to useCase. b. how end client will be aware of this expire duration.
  2. '{{code}}': What will be length of this code (OTP). Do this length will also change from useCase to useCase.
  3. Do message contain can change from case by case.
  4. Do this api 'sendSMS' is specific to any country(like UAE).
  5. Can the mobileNumber can be of any country.
  6. For sendSMS: do 'message' field can be changed to number(messageID), so this number will define the message to be sent to phoneNumber. This will help to avoid free text which may be potential spam. A table can be created to define message with respect to messageNumber.
bigludo7 commented 1 year ago

Hello From my perspective:

  1. Yes but the code expiration has not be set in our work. This is case for case right now end depending on implem. This information should be in the API documentation of the API provider.
  2. We have pending discussion there: https://github.com/camaraproject/OTPvalidationAPI/issues/24 - I proposed a max length of 10. Implementation are free to use between 4 to 10.
  3. Yes - this is define by API consumer in send-code request.
  4. SMS sending is not out of scope of this API. Here we manage the request to send a code by SMS but the SMS sending is internally implemented by each API provider
  5. Yes - after implementation could limit the scope of reached mobile.
  6. The message is provided by the application requesting the OTP - so it will be something something like this "Application > is requiring to validate code " - The message is crafted by the ISV. Adding a table could be a problem if we're not covering all potential message but get your point about spam. Probably it could be helpful to check how other actors manages this OTP.

Hope it helps.

sahidkhangithub commented 1 year ago
  1. So for expiry of code, do API provider can have a table in general or can agree for each client for each different type of message(as expiry can vary of each message type), or we can expire(in sec) as request field in api.
  2. In sendCode api, who will create the {{code}}? Please confirm my understanding, the message will be provided by api consumer and api provider will prepend {{code}}(newly create code/OTP) in the message and send this appended msg on mobileNumber.
  3. As messages can change from case by case, can each api provider(for SendCode) can have table(agreement) specific to each client and this table will define messageID and expiry for each different message type, this will help in eliminating spam and standardizing the things. (most regulatory do not allow providers to have free text SMS api.)
  4. If forum agreed on above point and we(api provider) will create api as per above agreed point, do we will get CAMARA compliance certification.
  5. As these api will grow, how api provider will get notification of updated version of api.
bigludo7 commented 1 year ago

Hello 1) As of now, we did not have a discussion about a 'standardized' OTP expiration time. For me it will be up to each implementation, depending on policy, to set it but probably we can discuss specifically this point in next meeting. 2/ yes - message is provided by API consumer, code is generated by API server and send on the mobile. 3/ Need to be discussed in team meeting - same than number 6 in previous message no? 4/ I'm not involved or aware of Compliance integration - This point should be directed to commonalities project probably. 5/ same - this is a fair question but not related only to this API --> This point should be directed to commonalities project

hope it helps

sahidkhangithub commented 1 year ago

Hello, Thanks for your responses, can you let me know how to approach/emailID for 'commonalities project'.

bigludo7 commented 1 year ago

@sahidkhangithub : commonalities project is there: https://github.com/camaraproject/WorkingGroups From my perspective for topic not related to one API but global to all API (notification on new API version, conformance), it should be raised there via git hub issue. Commonalities meeting are every 2 week and better to attend if you raise issue. You can follow this project by subscribing there: https://lists.camaraproject.org/g/wg-com

sahidkhangithub commented 1 year ago

hi, can you please include me in byweekly meeting: my emailID: sahidkhan@etisalat.ae

sahidkhangithub commented 1 year ago

Hi Team,

I tried to join both the links (1 under Tuesday and 1 under 30 May) at 4:30 CET (Dubai 6:30 PM) on tuesday, but I am not pulled in, seems meeting is not executed . Can you please let me know when is the next meeting and how I can join it. emailId : sahidkan@etisalat.ae

bigludo7 commented 1 year ago

Hi @sahidkhangithub We need to fix the page... indeed we have only meeting Thursday. I will correct the page and very sorry for this.

sahidkhangithub commented 1 year ago

hi @bigludo7, For 'SensSMS {{code}}' as discuss to have separate api with messageID, can you please arrange to check on how this new api can be added with its documentation. New api input : phoneNumber, messageID Response: 200: authenticationId All other error response as per the standard.

As each client(any business) will have different requirement and will have different expire value. I will suggest that client will propose its message detail and its expire and api provider will add this message and expire against a new messageID, client have to pass this new messageID in each call.

bigludo7 commented 1 year ago

@sahidkhangithub I'm a bit confusing with your proposal as my initial thinking was you did no want client to provide message. But here, in your proposal, you suggest client to propose message detail.

Does it mean that you want to introduce:

I'm always nervous to manage 2 flavors of an api as this is really an issue for the app developer.

jgarciahospital commented 1 year ago

@sahidkhangithub as per OpenGateway procedure, new functionalities from now on are supposed to be handled following this path:

GSMA OGW Product WS --> OGW Backlog prioritization (vote) --> CAMARA Backlog

If wanting to add new features affecting the funcionality of the service (not only technical modifications of an existing one), it's preferable to follow that track since GSMA is the one managing priorities at product level. Let us know if you need any support reaching that track.

sahidkhangithub commented 1 year ago

Hi @jgarciahospital , Thanks for the detail, whereas I try to seek for below path, but cannot find it exactly. Can you advice for the path for it.

GSMA OGW Product WS --> OGW Backlog prioritization (vote) --> CAMARA Backlog

sahidkhangithub commented 1 year ago

@bigludo7 , Thanks for the reply, whereas if new client will come, then new client have to interact with us (api provider) manually to provide us messageText and will share messageID for it. Then this messageID will be used by client for each transaction. Client can agree for multiple messageText and its respective messageID.

DT-DawidWroblewski commented 1 year ago

please reopen this issue on demand