monamok
commented
1 year ago Thank you @DT-DawidWroblewski for the proposal.
As it was mentioned during the meeting, Mobile Connect offers an OICD flow for authentication using SMS/OTP but the goal of CAMARA is defining APIs not having an authentication flow. In this case we would like to define an API that is used to verify a phone number via sending a SMS and validating the OTP. Similar to my comment on Number Verification I think this API should focus on verifying the number as well. The authentication flow and getting the token, from our point of view should be managed outside of this API. In this case the token can be 2-legged though.
We also believe that using a general endpoint such as /userinfo is not the best option (already mentioned and discussed on commonalities issue #105).
We suggest to have two endpoints, one to send an OTP to the phone number and another to validate the OTP. The operations can be something like this:
_POST /authentication/phone-number/send-code { "phonenumber": "+34628649832", "message": "{{code}} is your short code to authenticate with Cool App via SMS" }
And as a response we can return: _{ "authenticationid": "ea0840f3-3663-4149-bd10-c7c6b8912105" --> unique identifier of this authentication attempt }
And then:
_POST /authentication/phone-number/validate-code { "authenticationid": "ea0840f3-3663-4149-bd10-c7c6b8912105", "code": "AJY3" }
And in the response we can return 200 and the same authenticationid. { "authenticationid": "ea0840f3-3663-4149-bd10-c7c6b8912105" --> unique identifier of this authentication attempt }
As approved Design Guidelines indicate, we should include x-correlator both in query and response headers.
On the other hand, the uploaded version of API_definition is identical to Number Verification and it doesn’t include SMS+OTP specifications. But we can align the documentation once all the participants agree on the API approach.
Looking forward to receiving your feedbacks.
MarkusKuemmerle
DT-DawidWroblewski
Initial content based on Verified MSISDN docs