Initial content for Number Verify #2

DT-DawidWroblewski · 2022-11-17T12:04:41Z

Please find initial content for Number Verify

first Pull Request

monamok · 2022-11-21T09:14:07Z

Thank you @DT-DawidWroblewski for your proposal.
Based on the documentation you uploaded I think Telefonica’s roadmap in general is similar to yours but I would like to go through some of the concepts and make some suggestions so we can hopefully align the differences.
A question that was raised and briefly discussed during the meeting was if the MC service already exists what is the point to duplicate it in CAMARA? I think the key here, as you also mentioned at the meeting, is to simplify the API and make it easier to use globally.
The API as its name indicates, should focus on verifying the number. The authentication flow and getting the token, from our point of view should be managed outside of this API. In this case, there should be a 3-legged token as a result of user authenticating using their device IP address through the mobile network (as you mentioned WIFI connections are out of scope here). Checking token AMR value can help us to make sure that the authentication was via IP address.

About the part that we would like to include in this API, we agree with you that “Share” use case is out of scope of this API, as we definitely don’t want to share personal information with 3d parties.
For the “Match” use case, even though the issue is still open in Commonalities, we think that the nature of this API forces us to use MSISDN as input.
Having that in mind, in your proposal based on MC, there is only one endpoint and the Resource Request contains a JSON Payload with mc_claims parameter which contains the requested service value and you can send either device_msisdn or device_msisdn_hash as input. Instead of having a general endpoint as /userinfo here we would prefer to have two separate endpoints, one for device_msisdn and another for device_msisdn_hash. Our suggestion is to use something like this:

POST /verify
{
"phone_number": "+346661113334"
}

POST /verify-hashed
{
"hashed_phone_number": "32f67ab4e4312618b09cd23ed8ce41b13e095fe52b73b2e8da8ef49830e50dba"
}

The reason why we prefer to separate them is to have control over the scopes and be able to manage the permissions separately. But as a result, the suggested API remains very simple and straight forward.
About the response, we can’t find any reason to return the ‘sub’ back. The API receives the token to get the MSISDN from it. It doesn’t make sense to return token information in the response.
I agree with you that it’s a good idea to have “correlation_id” but adapting the concept to the Design Guidelines that were approved last week, we should change it to “x-correlator” which will be included as a header parameter.

In both cases the response could look like this:
{
"phone_number_verified": true
}

I also think once we get into an agreement between all the participants, we should proceed to update the document as the idea is not to follow the exact same steps as MC and for example to exclude “Share” use case from CAMARA API.

Please feel free to share your thoughts and add any comments.

DT-DawidWroblewski · 2022-11-23T09:49:08Z

Dear Colleagues, Mona – thank you for your valuable feedback! I appreciate we’re having a discussion around the shape of CAMARA APIs 😊 Here’s feedback I want to share: “…if the MC service already exists what is the point to duplicate it in CAMARA?” There is no point to duplicate MC APIs inside CAMARA, but rather present to CAMARA initiative the work that has been done during MC project, lessons learnt and takeaways that can help CAMARAs success. In the end we need to deliver APIs that our customers desire with a good time to market and less complexity. MC project done some work, that CAMARA can definitely reuse. Quick overview of MC APIs framework: ***@***.*** Specs available here: https://www.gsma.com/identity/mobile-connect/mobile-connect-specifications (still some are pending for distribution, should be available in Dec’22) MC ATP and Verified MSISDN that corresponds to SimSwap and Number Verify APIs are Identity services that are commercially available on market and used by our customers. Therefore, we’re open to any suggestions that you heard from your customers that can enrich these services – that is why we’re having this discussion inside CAMARA. I think the key here, as you also mentioned at the meeting, is to simplify the API and make it easier to use globally. I agree – please review MC Verified MSISDN spec and I’m keen on discussing how we can improve it globally. “…result of user authenticating using their device IP address through the mobile network…” Based on current experience I can state that not every MNO is capable of making it over IP address. IP address can be confusing, because some MNOs use CNAT, so it is impossible to identify the user based on IP address that is shared on API by Service Provider/Developer (this is public IP address, NOT private). There are solutions on the market that utilize additional client-server components that delivers tokens, that identifies data session, so no IP address is shared here as well, although token can be exchanged for customer/user identity (MSISDN, subscriberId, etc.) “About the part that we would like to include in this API, we agree with you that “Share” use case is out of scope of this API, as we definitely don’t want to share personal information with 3d parties.” Some SPs (e.g. banks) expects MNOs to deliver MSISDN, because they want to take “verification” liability on their shoulders. It looks difficult for them to outsource this logic outside bank, because it means (in some cases) that MNOs are willing to adopt banking law principles here (). I’d keep it unless we have a clear picture and a good value proposal for customers that are requesting such an approach. “Instead of having a general endpoint as /userinfo here we would prefer to have two separate endpoints, one for device_msisdn and another for device_msisdn_hash. Our suggestion is to use something like this:” Currently we use “scope” parameter with a value that distinguish an API product SP wants to use… and it works. “mc_claims” wrapper was designed to meet customers expectations that are willing to pass JSON payload inside resource request BODY. For vMSISDN we require SP to pass “device_msisdn” value that is registered by customer (either as an input that is a part of a process or it is stored by SP). Although for services like KYC, we expect following mc_claims payload: { "mc_claims": { "country_hash": { "value": "76b64fa3652825ae1348dc2109d3c127b27decd34beb4cf010c302e4c13fb7aa" }, "birthdate_hash": { "value": "24b1718f532fc8ecd757be7f0ce971cbbdf0f1ed917864f8232341f1df04e411" }, "name_hash": { "value": "5df21ecc757050132809d3f7e916a498af933d7c7f4ed533dc5ba4d6a953fae4" }, "family_name_hash": { "value": "9ca7310de2c25e41561aaa1e20b69e6472b835954649d6b8bca23815776af11a" }, "given_name_hash": { "value": "ec6c537698a7d922d0b294e8fe82048198588e122766136a3d6cb8e39b0d67c0" }, "address_hash": { "value": "7003f18eb259182240a1a10204f2240a4f43c2b49b7641a9a1bfec02851e0bcf" }, "town_hash": { "value": "6fdf5ca0b24edb045be9018995030f1949a0ad2d53ad2373ea6f566f503e1ad0" }, "houseno_or_housename_hash": { "value": "6bfc60dee6ba40aad8ace839b14edb9a996dbdf6e25d0f559361485b525de9bd" }, "postal_code_hash": { "value": "08bc0500fa8af4771c9968e3db5724ce17ccc8a55628add0a64fa489c544e1fe" } } } Therefore, mc_claims wrapper is flexible and can handle various information inside it, according to specific API requirements. MC framework allows to pass parameters and values inside the request, like so: https://mobileconnect-test.telekom.de/openid/userinfo?claims=%7B%0A%22mc_claims%22%3A%20%7B%0A%20%20%20%20%22country_hash%22%3A%20%7B%0A%20%20%20%20%20%20%20%20%22value%22%3A%20%2276b64fa3652825ae1348dc2109d3c127b27decd34beb4cf010c302e4c13fb7aa%22%0A%20%20%20%20%7D%2C%0A%20%20%20%20%22birthdate_hash%22%3A%20%7B%0A%20%20%20%20%20%20%20%20%22value%22%3A%20%2224b1718f532fc8ecd757be7f0ce971cbbdf0f1ed917864f8232341f1df04e411%22%0A%20%20%20%20%7D%2C%0A%20%20%20%20%22name_hash%22%3A%20%7B%0A%20%20%20%20%20%20%20%20%22value%22%3A%20%225df21ecc757050132809d3f7e916a498af933d7c7f4ed533dc5ba4d6a953fae4%22%0A%20%20%20%20%7D%2C%0A%20%20%20%20%22family_name_hash%22%3A%20%7B%0A%20%20%20%20%20%20%20%20%22value%22%3A%20%229ca7310de2c25e41561aaa1e20b69e6472b835954649d6b8bca23815776af11a%22%0A%20%20%20%20%7D%2C%0A%20%20%20%20%22given_name_hash%22%3A%20%7B%0A%20%20%20%20%20%20%20%20%22value%22%3A%20%22ec6c537698a7d922d0b294e8fe82048198588e122766136a3d6cb8e39b0d67c0%22%0A%20%20%20%20%7D%2C%0A%20%20%20%20%22address_hash%22%3A%20%7B%0A%20%20%20%20%20%20%20%20%22value%22%3A%20%227003f18eb259182240a1a10204f2240a4f43c2b49b7641a9a1bfec02851e0bcf%22%0A%20%20%20%20%7D%2C%0A%20%20%20%20%22town_hash%22%3A%20%7B%0A%20%20%20%20%20%20%20%20%22value%22%3A%20%226fdf5ca0b24edb045be9018995030f1949a0ad2d53ad2373ea6f566f503e1ad0%22%0A%20%20%20%20%7D%2C%0A%20%20%20%20%22postal_code_hash%22%3A%20%7B%0A%20%20%20%20%20%20%20%20%22value%22%3A%20%2208bc0500fa8af4771c9968e3db5724ce17ccc8a55628add0a64fa489c544e1fe%22%0A%20%20%20%20%7D%0A%7D%0A%7D but we find it less convenient for customers. Finally, I suggest to keep mc_claims wrapper as it can help us to adopt API specific fields and it is a common standard used worldwide. “…we can’t find any reason to return the ‘sub’ back…” Here’s “sub” rationale from the MC Specs: The “sub” (subject) claim containing the PCR MUST always be returned in the Resource Response so that the Resource Response is tied with the ID Token and the User in this context. This allows the SP to validate the response. Therefore it allows SP/developer to handle additional business logic. For details please refer to IDY.03 – Mobile Connect Resource Server Technical Requirements. This one is a general description how to call protected resources and how to build attribute based API services. (there is also an article about how to capture User Consent with a sequence diagram) https://www.gsma.com/identity/wp-content/uploads/2022/11/IDY.03-v1.0.pdf “I agree with you that it’s a good idea to have “correlation_id” but adapting the concept to the Design Guidelines<https://github.com/camaraproject/WorkingGroups/blob/main/Commonalities/documentation/API-design-guidelines.md> that were approved last week, we should change it to “x-correlator” which will be included as a header parameter.” In Mobile Connect “correlation_id” is an optional parameter, therefore we do not require it to be provided by SP/developer. However, we use it to correlate transaction across whole API flow as well it is useful to assure billing, so we always share it in a response. “correlation_id” is used in Mobile Connect framework and is a part of a MC standard and what we learnt is the more standardized service we build the quicker and easier it is for developers to adopt it. Please refer to IDY.01 & IDY.05 for more info: https://www.gsma.com/identity/wp-content/uploads/2022/11/IDY.01-v3.0.pdf https://www.gsma.com/identity/wp-content/uploads/2022/11/IDY.05-v2.0.pdf Looking forward to hearing from you! Regards, David Deutsche Telekom Technology Delivery International Dawid Wróblewski Marynarska 12, 02-674 Warsaw +48 602 204 473 (phone) Email: ***@***.******@***.***> www.telekom.com<http://www.telekom.com/> ***@***.*** Life is for sharing. You can find the obligatory information on www.telekom.com/compulsory-statement<http://www.telekom.com/compulsory-statement> From: Mona Mokhber ***@***.***> Sent: Monday, November 21, 2022 10:14 AM To: camaraproject/NumberVerification ***@***.***> Cc: Wróblewski Dawid ***@***.***>; Mention ***@***.***> Subject: Re: [camaraproject/NumberVerification] Initial content for Number Verify (PR #2) SECURITY WARNING: Ta wiadomość pochodzi z zewnętrznego źródła - uważaj na załączniki i linki. Jeśli wiadomość wyda Ci się podejrzana zgłoś incydent. This email is from an external source - be careful of attachments and links. Please follow good practices and report suspicious emails. Thank you @DT-DawidWroblewski<https://github.com/DT-DawidWroblewski> for your proposal. Based on the documentation you uploaded I think Telefonica’s roadmap in general is similar to yours but I would like to go through some of the concepts and make some suggestions so we can hopefully align the differences. A question that was raised and briefly discussed during the meeting was if the MC service already exists what is the point to duplicate it in CAMARA? I think the key here, as you also mentioned at the meeting, is to simplify the API and make it easier to use globally. The API as its name indicates, should focus on verifying the number. The authentication flow and getting the token, from our point of view should be managed outside of this API. In this case, there should be a 3-legged token as a result of user authenticating using their device IP address through the mobile network (as you mentioned WIFI connections are out of scope here). Checking token AMR value can help us to make sure that the authentication was via IP address. About the part that we would like to include in this API, we agree with you that “Share” use case is out of scope of this API, as we definitely don’t want to share personal information with 3d parties. For the “Match” use case, even though the issue is still open in Commonalities, we think that the nature of this API forces us to use MSISDN as input. Having that in mind, in your proposal based on MC, there is only one endpoint and the Resource Request contains a JSON Payload with mc_claims parameter which contains the requested service value and you can send either device_msisdn or device_msisdn_hash as input. Instead of having a general endpoint as /userinfo here we would prefer to have two separate endpoints, one for device_msisdn and another for device_msisdn_hash. Our suggestion is to use something like this: POST /verify { "phone_number": "+346661113334" }

…

________________________________ POST /verify-hashed { "hashed_phone_number": "32f67ab4e4312618b09cd23ed8ce41b13e095fe52b73b2e8da8ef49830e50dba" } The reason why we prefer to separate them is to have control over the scopes and be able to manage the permissions separately. But as a result, the suggested API remains very simple and straight forward. About the response, we can’t find any reason to return the ‘sub’ back. The API receives the token to get the MSISDN from it. It doesn’t make sense to return token information in the response. I agree with you that it’s a good idea to have “correlation_id” but adapting the concept to the Design Guidelines<https://github.com/camaraproject/WorkingGroups/blob/main/Commonalities/documentation/API-design-guidelines.md> that were approved last week, we should change it to “x-correlator” which will be included as a header parameter. In both cases the response could look like this: { "phone_number_verified": true } I also think once we get into an agreement between all the participants, we should proceed to update the document as the idea is not to follow the exact same steps as MC and for example to exclude “Share” use case from CAMARA API. Please feel free to share your thoughts and add any comments. — Reply to this email directly, view it on GitHub<#2 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A3XZEQKPC5MO7AL3PLBBYOTWJM4OVANCNFSM6AAAAAASDJRWH4>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>> T-MOBILE POLSKA S.A. z siedzibą w Warszawie Adres: ul. Marynarska 12, 02-674 Warszawa Zarząd Spółki: Andreas Maierhofer - Prezes Zarządu; Juraj Andráš - Członek Zarządu, Dyrektor ds. Finansowych; Dorota Kuprianowicz-Legutko – Członek Zarządu, Dyrektor ds. Polityki Personalnej; Goran Marković – Członek Zarządu, Dyrektor ds. Rynku Prywatnego; Alexander Jenbar – Członek Zarządu, Dyrektor ds. Technologii i Innowacji; Agnieszka Rynkowska - Członek Zarządu, Dyrektor ds. Rynku Biznesowego. Spółka zarejestrowana w Sądzie Rejonowym dla m.st. Warszawy w Warszawie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego. KRS 0000391193 | NIP 526-10-40-567 | Regon 011417295 Kapitał zakładowy 711.210.000 złotych, kapitał wpłacony w całości. DUŻE ZMIANY ZACZYNAJĄ SIĘ OD MAŁYCH - CHROŃ PLANETĘ, NIE DRUKUJ TEGO E-MAILA, JEŻELI NIE MUSISZ. Ta wiadomość i jej treść są zastrzeżone w szczegółowym zakresie dostępnym na http://www.t-mobile.pl/stopka This e-mail and its contents are subject to a DISCLAIMER with important RESERVATIONS: see http://www.t-mobile.pl/stopka

monamok · 2022-11-24T08:01:54Z

Thank you @DT-DawidWroblewski for the detailed explanation.
I would like to add my comments.

“… Based on current experience I can state that not every MNO is capable of making it over IP address. IP address can be confusing, because some MNOs use CNAT, so it is impossible to identify the user based on IP address that is shared on API by Service Provider/Developer (this is public IP address, NOT private). There are solutions on the market that utilize additional client-server components that delivers tokens, that identifies data session, so no IP address is shared here as well, although token can be exchanged for customer/user identity (MSISDN, subscriberId, etc.)”

I totally agree. In fact in TEF we also use CNAT and we actually use IP+port not just the IP address. What I was referring to was that the authentication must be via mobile network and as long as it’s not based on user/password or SMS+OTP it’ll be considered in the scope.

The “Share” option is related to issue #101 that is still under discussion. TEF is strongly against returning PI and sharing that information with 3d-parties. Maybe I got a wrong idea but I think we discussed that point at the meeting and all of us were at the same page about it that we were going to remove this functionality from the CAMARA API’s scope. In any case, if we should consider this UC we can include it as a separate endpoint so its use can be limited by its individual scope.

About having a general endpoint, this was raised by you in issue #105 and TEF’s approach is similar to Orange, as Ruben our colleague also expressed there. We prefer to have individual endpoints/resources per API and of course their own corresponding scopes.

As it is always easier to review a written version I’m going to open a PR including the suggested version.

DT-DawidWroblewski · 2022-12-07T08:51:59Z

@monamok
I think we're getting closer to alignment.
@bigludo7 mentioned in his comment that using

{ "mc_claims": { "device_msisdn": "+33640049871" } }

in resource request is fine. Moreover, it is following the idea of the service, meaning that we check if device "holds" the same phone number, as network detects it.

Therefore, resource response should be similar and the one that comes inside MC standard should work perfectly:

{ "sub": "cd45a691-d311-4134-9a0c-2747e5110d22 " "device_msisdn_verified": true }

This response is common for "plain" or "hashed" versions.

As Number Verify requires Device Initiated request, (either OIDC or OAUTH2.0 "code flow"), the scope is a mandatory parameter and should reflect the actual API service. I recommend following MC Verified MSISDN specification and passing:

mc_vm_match
for "plain" version
mc_vm_match_hash
for hash

"share" is out of scope.

I see no issue with having multiple configurations, meaning utilizing generic or specific endpoints. This is a common approach and I think it can work in CAMARA as well.

TIM Italy and TIM Brasil reviews points and contributions proposal: Suggest to converge on a YAML from previous proposal A+B+C: A) Proposal by TEF (Telefonica Proposal #3) B) Proposal by DT (Initial content for Number Verify #2) C) Proposal initially by TIM Brasil (IP and Port header input parameters) Review points include in new YAML file version regarding path /authorize: IP and Port as optional input header parameters oAuth2 already mapped in DT (Initial content for Number Verify #2) Error code handling according to CAMARA others API (e.g., the Traffic Influence API)

MarkusKuemmerle · 2022-12-09T17:20:43Z

@DT-DawidWroblewski : Please contribute API definitions in the code/API_definitions/ subdirectory and not in code/API_code/. Please change this pull request in this way.

monamok · 2022-12-14T16:14:12Z

Hello @DT-DawidWroblewski,
I suggest to open an specific PR for the MoM. This way if people coment and it gets approved, it can be merged instead of getting mixed up with other files such as API documentation and defenition files.

DT-DawidWroblewski · 2022-12-14T16:17:18Z

Hi Mona, Unfortunately GIT doesn’t allow me to create two PRs ☹ Deutsche Telekom Technology Delivery International Dawid Wróblewski Marynarska 12, 02-674 Warsaw +48 602 204 473 (phone) Email: ***@***.******@***.***> www.telekom.com<http://www.telekom.com/> ***@***.*** Life is for sharing. You can find the obligatory information on www.telekom.com/compulsory-statement<http://www.telekom.com/compulsory-statement> From: Mona Mokhber ***@***.***> Sent: Wednesday, December 14, 2022 5:14 PM To: camaraproject/NumberVerification ***@***.***> Cc: Wróblewski Dawid ***@***.***>; Mention ***@***.***> Subject: Re: [camaraproject/NumberVerification] Initial content for Number Verify (PR #2) SECURITY WARNING: Ta wiadomość pochodzi z zewnętrznego źródła - uważaj na załączniki i linki. Jeśli wiadomość wyda Ci się podejrzana zgłoś incydent. This email is from an external source - be careful of attachments and links. Please follow good practices and report suspicious emails. Hello @DT-DawidWroblewski<https://github.com/DT-DawidWroblewski>, I suggest to open an specific PR for the MoM. This way if people coment and it gets approved, it can be merged instead of getting mixed up with other files such as API documentation and defenition files. — Reply to this email directly, view it on GitHub<#2 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A3XZEQPJKAB2S6UOTY5EK33WNHW57ANCNFSM6AAAAAASDJRWH4>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>> T-MOBILE POLSKA S.A. z siedzibą w Warszawie Adres: ul. Marynarska 12, 02-674 Warszawa Zarząd Spółki: Andreas Maierhofer - Prezes Zarządu; Juraj Andráš - Członek Zarządu, Dyrektor ds. Finansowych; Dorota Kuprianowicz-Legutko – Członek Zarządu, Dyrektor ds. Polityki Personalnej; Goran Marković – Członek Zarządu, Dyrektor ds. Rynku Prywatnego; Alexander Jenbar – Członek Zarządu, Dyrektor ds. Technologii i Innowacji; Agnieszka Rynkowska - Członek Zarządu, Dyrektor ds. Rynku Biznesowego. Spółka zarejestrowana w Sądzie Rejonowym dla m.st. Warszawy w Warszawie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego. KRS 0000391193 | NIP 526-10-40-567 | Regon 011417295 Kapitał zakładowy 711.210.000 złotych, kapitał wpłacony w całości. DUŻE ZMIANY ZACZYNAJĄ SIĘ OD MAŁYCH - CHROŃ PLANETĘ, NIE DRUKUJ TEGO E-MAILA, JEŻELI NIE MUSISZ. Ta wiadomość i jej treść są zastrzeżone w szczegółowym zakresie dostępnym na http://www.t-mobile.pl/stopka This e-mail and its contents are subject to a DISCLAIMER with important RESERVATIONS: see http://www.t-mobile.pl/stopka

monamok · 2022-12-14T16:34:18Z

AFAIK for each branch you can create a new PR. If you create a branch from master and put the MoM file for example there, you can create a new PR for that branch. If it doesn't let you do that maybe there's a permission problem there and maybe @MarkusKuemmerle can help you with that.

MarkusKuemmerle · 2022-12-14T17:01:50Z

Hi Dawid, you can create as much PRs as you want. BR, Markus Von: DawidWroblewski ***@***.***> Gesendet: Mittwoch, 14. Dezember 2022 17:18 An: camaraproject/NumberVerification ***@***.***> Cc: Kümmerle, Markus ***@***.***>; Comment ***@***.***> Betreff: Re: [camaraproject/NumberVerification] Initial content for Number Verify (PR #2) Hi Mona, Unfortunately GIT doesn’t allow me to create two PRs ☹ Deutsche Telekom Technology Delivery International Dawid Wróblewski Marynarska 12, 02-674 Warsaw +48 602 204 473 (phone) Email: ***@***.******@***.***<mailto:***@***.******@***.***>> www.telekom.com<http://www.telekom.com/<http://www.telekom.com%3chttp:/www.telekom.com/>> ***@***.***<mailto:***@***.***> Life is for sharing. You can find the obligatory information on www.telekom.com/compulsory-statement<http://www.telekom.com/compulsory-statement<http://www.telekom.com/compulsory-statement%3chttp:/www.telekom.com/compulsory-statement>> From: Mona Mokhber ***@***.***<mailto:***@***.***>> Sent: Wednesday, December 14, 2022 5:14 PM To: camaraproject/NumberVerification ***@***.***<mailto:***@***.***>> Cc: Wróblewski Dawid ***@***.***<mailto:***@***.***>>; Mention ***@***.***<mailto:***@***.***>> Subject: Re: [camaraproject/NumberVerification] Initial content for Number Verify (PR #2) SECURITY WARNING: Ta wiadomość pochodzi z zewnętrznego źródła - uważaj na załączniki i linki. Jeśli wiadomość wyda Ci się podejrzana zgłoś incydent. This email is from an external source - be careful of attachments and links. Please follow good practices and report suspicious emails. Hello @DT-DawidWroblewski<https://github.com/DT-DawidWroblewski>, I suggest to open an specific PR for the MoM. This way if people coment and it gets approved, it can be merged instead of getting mixed up with other files such as API documentation and defenition files. — Reply to this email directly, view it on GitHub<#2 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A3XZEQPJKAB2S6UOTY5EK33WNHW57ANCNFSM6AAAAAASDJRWH4>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***<mailto:***@***.******@***.***>>> T-MOBILE POLSKA S.A. z siedzibą w Warszawie Adres: ul. Marynarska 12, 02-674 Warszawa Zarząd Spółki: Andreas Maierhofer - Prezes Zarządu; Juraj Andráš - Członek Zarządu, Dyrektor ds. Finansowych; Dorota Kuprianowicz-Legutko – Członek Zarządu, Dyrektor ds. Polityki Personalnej; Goran Marković – Członek Zarządu, Dyrektor ds. Rynku Prywatnego; Alexander Jenbar – Członek Zarządu, Dyrektor ds. Technologii i Innowacji; Agnieszka Rynkowska - Członek Zarządu, Dyrektor ds. Rynku Biznesowego. Spółka zarejestrowana w Sądzie Rejonowym dla m.st. Warszawy w Warszawie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego. KRS 0000391193 | NIP 526-10-40-567 | Regon 011417295 Kapitał zakładowy 711.210.000 złotych, kapitał wpłacony w całości. DUŻE ZMIANY ZACZYNAJĄ SIĘ OD MAŁYCH - CHROŃ PLANETĘ, NIE DRUKUJ TEGO E-MAILA, JEŻELI NIE MUSISZ. Ta wiadomość i jej treść są zastrzeżone w szczegółowym zakresie dostępnym na http://www.t-mobile.pl/stopka This e-mail and its contents are subject to a DISCLAIMER with important RESERVATIONS: see http://www.t-mobile.pl/stopka — Reply to this email directly, view it on GitHub<#2 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AUVD2SGG5Y2DBNFS426FGVLWNHXJVANCNFSM6AAAAAASDJRWH4>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

DT-DawidWroblewski · 2022-12-19T12:33:26Z

@bigludo7 I updated swagger based on MC Verified MSISDN specs - please review

monamok · 2022-12-20T10:10:54Z

documentation/MeetingMinutes/Week50_syncCalls.md

+
+   -------
+
+   >following items were not presented during meeting, although sharing status and recommendations


Please remove the recomendation sections and the points that were not discussed during the meeting from the MoM.

We continued discussion about these APIs on the follow-up meeting that was on 15th Dec'22. I changed the naming of this item.

I think this part still might be misleading because you might have mentioned some of these points in the meeting but the rest of discussion and the answeres to your suggestion are missing here.
For example here it says that in the other API defenition "IP Address+Port passed in resource call" and it's not true. IP address is and was not included in any resource call. It uses 3-legged token and requires authentication via mobile network (excluding for example by SMS/OTP or user/password as an authentication method). It's NOT a query API either.
If someone reads this MoM might think that it was discussed and agreed in the meeting that the other proposal is a bad idea and it's not valid when it's not what happened. Could you please edit it?

Hi @monamok !

I fixed this section - now it should be clear - please check.

Please could you add some more information such as that it was decided to have two solutions, as you did for Sim Swap, one based on MC and another with specific endpoints aligned with other CAMARA APIs. Thanks.

monamok · 2022-12-20T10:12:16Z

documentation/MeetingMinutes/Week50_syncCalls.md

+
+1. GSMA to provide information about Openverse stakeholders (Done - Helen provided list to Vodafone and Hutchoison).
+2. simSwap - work with 2 yaml files with API description
+3. Number Verify - continue work based on MC Verified MSISDN specification, considering whole service flow.


This AP was not agreed on the meeting and might be confusing. Please remove it.

On a meeting we had on Thursday 15.12.2022 (week 50) we discussed following:

deliver API description based on MC specs & with a dedicated endpoint
MC APIs & Camara with dedicated API endpoint has a lot in common. MC APIs deliver enhanced service with additional info, meaning additional attributes in a single API call. Therefore, having 2 yaml files: for MC & Camara makes sense, as these services are complement to each other (not competing). This aggreement is for both Number Verify and SimSwap

Provide additional description inside NumberVerify service description that explains how service flow looks like (with options like HE, redirects, additional headers etc.)

Yes, the result of the meeting on Dec 15th was the same as Sim Swap on Dec 13th --> work with 2 yaml files with API description. So maybe you could update the AP or give more info about it.

documentation/API_documentation/API_definition.md

code/API_definitions/CAMARA_numberVerify.yaml

monamok · 2022-12-20T10:56:00Z

code/API_definitions/CAMARA_numberVerify.yaml

+            type: string
+            format: uri
+          example: http://localhost
+      responses:


What happens in the case of success?

same comment for me.

bigludo7 · 2022-12-27T09:05:45Z

code/API_code/CAMARA_numberVerify.postman_collection.json

@@ -0,0 +1,444 @@
+{


Why adding the Postman collection ? is it something that should be provided for all Camara API as I'm not sure there is this for other API proposal.

bigludo7 · 2022-12-27T09:13:03Z

documentation/API_documentation/API_definition.md

+Mobile Connect Verified MSISDN is defined as two service variants:
+
+- **Verified MSISDN Match**: in which the Mobile Operator compares the MSISDN associated with the mobile device against that provided by the SP in the service request1. The MSISDN can be supplied in an E164 format [5] or in a hashed form. Verified MSISDN Match ensures no data is shared by the Mobile Operator.
+- **Verified MSISDN Share**: in which the Mobile Operator provides the mobile device MSISDN to the SP who can then perform the check itself


This share function is not provided in the swagger - It should be clearly indicated I guess or added in the swagger.

Fine - I deleted this piece.

bigludo7 · 2022-12-27T09:20:47Z

code/API_definitions/CAMARA_numberVerify.yaml

+      security:
+        - openId: [mc_vm_match,mc_vm_match_hash]
+      summary: Authorize request for MC Verified MSISDN service
+      parameters:


I do not understand why the scope attribute is missing ?
Is it because this is a dedicated API for number verified and we considered as set in stone for this API ?
This is not aligned with API documentation table 1

I aligned with table - deleted "share".
these scopes are working only for MC Number Verify service - these are dedicated to API service flow.

Developer shall see the difference on /userInfo:

mc_vm_match

resource request requires plain msisdn passed inside the resource body

mc_vm_match_hash

resource request requires hashed msisdn passed inside the resource body

bigludo7 · 2022-12-27T09:21:02Z

code/API_definitions/CAMARA_numberVerify.yaml

+            type: string
+            format: uri
+          example: http://localhost
+      responses:


same comment for me.

bigludo7 · 2022-12-27T09:21:40Z

documentation/API_documentation/API_definition.md

+
+## Verified MSISDN Service Specification
+
+### OIDC Authorization Request Parameters - scope


Scope missing in the swagger. See previous comment

this was fixed with last commit

Co-authored-by: Mona Mokhber <mona.mokhber@telefonica.com>

…rification

bigludo7

Hi @DT-DawidWroblewski

Why no scope attribute ?
Got an error on swagger UI:
`Errors
Hide

Semantic error at paths./authorize.get.security.0
Security requirements must match a security definition
Jump to line 38`

DT-DawidWroblewski · 2023-01-04T07:14:17Z

@monamok @bigludo7 - I'd appreciate you sharing your review so that I can merge this PR.

Thx!

bigludo7

Look good for me.

monamok

Some suggestions to make it more clear. Thanks.

documentation/MeetingMinutes/Week50_syncCalls.md

Co-authored-by: Mona Mokhber <mona.mokhber@telefonica.com>

monamok

Thanks.

DT-DawidWroblewski · 2023-01-05T11:54:58Z

@bigludo7 can you please approve PR, as I placed some MoM updates from @monamok review. Thx!

bigludo7

Look good for me.

DT-DawidWroblewski added 3 commits November 16, 2022 16:42

adding MoMs of first meeting

c1bf499

first Pull Request

adding content to repo

29008c1

minor updates

d4568db

monamok mentioned this pull request Nov 28, 2022

Telefonica Proposal #3

Merged

moving yaml files

35ae75e

DT-DawidWroblewski requested a review from bigludo7 as a code owner December 2, 2022 13:54

paulocesardiaslima mentioned this pull request Dec 8, 2022

TIM Italy and TIM Brasil contributions proposal paulocesardiaslima/NumberVerification#1

Open

monamok mentioned this pull request Dec 9, 2022

TIM Italy and TIM Brasil contributions proposal DT-DawidWroblewski/NumberVerification#2

Closed

adding MoM

1e60d13

Number Verify based on MC standard - yaml update

bc7943b

DT-DawidWroblewski added 2 commits December 19, 2022 17:55

Updates to yaml - number verify

57840f3

adding error descriptions

8190af5

monamok reviewed Dec 20, 2022

View reviewed changes

Update API_definition.md

92313f4

bigludo7 reviewed Dec 27, 2022

View reviewed changes

DT-DawidWroblewski and others added 3 commits December 28, 2022 10:31

Update documentation/API_documentation/API_definition.md

21e87ba

Co-authored-by: Mona Mokhber <mona.mokhber@telefonica.com>

Update code/API_definitions/CAMARA_numberVerify.yaml

ab33427

Co-authored-by: Mona Mokhber <mona.mokhber@telefonica.com>

applying changes to files

25e9b37

Merge branch 'main' of https://github.com/DT-DawidWroblewski/NumberVe…

505fe74

…rification

DT-DawidWroblewski requested a review from bigludo7 December 29, 2022 08:49

bigludo7 reviewed Dec 29, 2022

View reviewed changes

fixed security scheme

150eb55

DT-DawidWroblewski requested a review from bigludo7 December 29, 2022 11:12

DT-DawidWroblewski added 2 commits December 29, 2022 12:18

adding scope parameter inside /auth query

17390cb

updated MoMs week50

bb6a7b7

DT-DawidWroblewski requested a review from monamok January 3, 2023 15:27

DT-DawidWroblewski mentioned this pull request Jan 5, 2023

Optional parameters proposed by TIM #8

Closed

MoM update according to review

2731ca9

bigludo7 previously approved these changes Jan 5, 2023

View reviewed changes

monamok reviewed Jan 5, 2023

View reviewed changes

documentation/MeetingMinutes/Week50_syncCalls.md Outdated Show resolved Hide resolved

documentation/MeetingMinutes/Week50_syncCalls.md Outdated Show resolved Hide resolved

DT-DawidWroblewski dismissed bigludo7’s stale review via a9e571e January 5, 2023 10:55

Update documentation/MeetingMinutes/Week50_syncCalls.md

a9e571e

Co-authored-by: Mona Mokhber <mona.mokhber@telefonica.com>

DT-DawidWroblewski requested a review from monamok January 5, 2023 10:56

Update documentation/MeetingMinutes/Week50_syncCalls.md

59edd9b

Co-authored-by: Mona Mokhber <mona.mokhber@telefonica.com>

monamok approved these changes Jan 5, 2023

View reviewed changes

DT-DawidWroblewski requested a review from bigludo7 January 5, 2023 11:26

bigludo7 approved these changes Jan 5, 2023

View reviewed changes

DT-DawidWroblewski merged commit 60714ec into camaraproject:main Jan 5, 2023


		-------

		>following items were not presented during meeting, although sharing status and recommendations


		## Verified MSISDN Service Specification

		### OIDC Authorization Request Parameters - scope

Initial content for Number Verify #2

Initial content for Number Verify #2

Conversation

DT-DawidWroblewski commented Nov 17, 2022

monamok commented Nov 21, 2022

DT-DawidWroblewski commented Nov 23, 2022 via email

monamok commented Nov 24, 2022

DT-DawidWroblewski commented Dec 7, 2022

MarkusKuemmerle commented Dec 9, 2022

monamok commented Dec 14, 2022

DT-DawidWroblewski commented Dec 14, 2022 via email

monamok commented Dec 14, 2022 • edited Loading

MarkusKuemmerle commented Dec 14, 2022 via email

DT-DawidWroblewski commented Dec 19, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bigludo7 left a comment

Choose a reason for hiding this comment

DT-DawidWroblewski commented Jan 4, 2023

bigludo7 left a comment

Choose a reason for hiding this comment

monamok left a comment

Choose a reason for hiding this comment

monamok left a comment

Choose a reason for hiding this comment

DT-DawidWroblewski commented Jan 5, 2023

bigludo7 left a comment

Choose a reason for hiding this comment

monamok commented Dec 14, 2022 •

edited

Loading