Create MOM-2023-05-03.md

documentation/MeetingMinutes/MOM-2023-05-03.md

@@ -0,0 +1,64 @@
+# Identity and Consent Management meeting
+
+#### *3rd of May 2023*
+
+## Attendees
+
+| Companies | Attendees |
+| ---- | ------- |
+| Alicon | Ike Alisson |
+| CodeB | Stefan Engelbert, Juss Makela |
+| Ericsson | Jan Friman |
+| Microsoft | Landon Cox | 
+| GSMA | Mark Cornall, Tom van Pelt |
+| Telefónica | Guido García, Jose Ordonez-Lucena  |
+| T-Mobile US| Murat Karabulut |
+| Vodafone| Eric Murray, Alexander, Nevin Aquinas |
+| Vonage| Chris Howell |
+
+
+## Agenda
+
+1. Recent updates & recap 
+2. Issues and PRs
+3. Action Points 
+4. AoB
+
+
+## Recent updates & recap
+The call in 19th April was cancelled as per Telefónica's request. Reason is that the [baseline document](https://github.com/camaraproject/IdentityAndConsentManagement/pull/13/commits/11e4a3d44ad3a2731d8af70b447d50f81c8efda6#diff-d9ac5140672a5e419688aab0947167d98cee83680cc623f4366923919868e9c4) was presented to the group in 12th April, so it was unlikely that participants had the chance to digest the content and align internally. 
+For the last three weeks, progress have been made through Github.
+On issue [#12](https://github.com/camaraproject/IdentityAndConsentManagement/issues/12) ([PR#13](https://github.com/camaraproject/IdentityAndConsentManagement/pull/13)), there has been a thread between DT and TEF with RFCs. 
+New issues have been opened as well (see next clause).
+
+## Issues and PRs
+
+| **Issue**  |  Owner| Description |
+| ----------- | --- | ----------- |
+| **Open issues** |  |  |
+|  [#11](https://github.com/camaraproject/IdentityAndConsentManagement/issues/11)  | Centillion | **OpenId vs Mobile Number**<br> None from Centillion on the call to clarify posted questions, though it seems there's been a confusion between the use and intention of Open ID Connect (OIDC). OIDC is not used for the purposes of subscriber identification; it is an identity later built atop OAuth2.0 instead, used for the purpose of API authentication OIDC is de-facto standard for handling authentication in REST ecosystem. <br> It is reminded that solutions in scope of CAMARA are not tied to the actual capabilities of the underlying network (e.g., which 3GPP capabilities are deployed). We need to agree on solutions understandable/workable for developer ecosystem, and that can be used in different deployed networks, including not only public mobile 4G/5G, but also fixed networks, home environments (e.g., WiFi) and even private networks <br>. | 
+|  [#12](https://github.com/camaraproject/IdentityAndConsentManagement/issues/12) ([PR#13](https://github.com/camaraproject/IdentityAndConsentManagement/pull/13)) | Telefónica | **Baseline Document to describe User Consent Management**<br> Progress has been made on the PR with the thread involving DT and Telefónica. The rest of participants are encouraged to go through the doc, post their comments on existing text and open new issues (and associated PRs) for those sections that remain empty. |
+| **Closed issues** |  |  |
+|  |  | | 
+| **New issues** |  | |
+| [#15](https://github.com/camaraproject/IdentityAndConsentManagement/issues/15)  | Vonage | **Application Subscriber Identity**</br> MSFT [Q]: we prefer the tuple {IP address + port} as input param, as we have today for QoD API. It might be a problem/issue for developers when they are not able to use this tuple in their API calls. <br> Vonage [A]: agree that IP address is recommendable for use when doable; however, it is not always doable. There are many issues with IP address: i) it can change during the session, ii) it does not work in off-net scenarios, and iii) it does not fit well with some real-use cases such as anti-fraud with DeviceLocation API, where other identifier such as MSISDN are more convenient. All this justifies the need to consider input parameters other than IP address for subscriber identity. This analysis shall be made on a per service API cases, depending on the casuistry behind and in-scope use cases. <br> GSMA [A]: support Vonage comment. Also ackknowledge that temporary identifiers should be discouraged when/if possible.  <br> <br> GSMA [Q]: we need to make sure the proposed identity API solution works in federation environments. The use of semi-permanent/permanent identifiers for the susbcriber has also been discussed during . <br> Vonage [A]: Agree, there is a need to take this into account when defining the actual API solution. <br> <br> TEF [Q]: susbcriber and application identity is a topic which has been discussed for long time in GSMA Open Gateway Technical Workstream, so GSMA input in this regard is quite valuable for CAMARA -- we need to ensure convergent and consistent discussions at both GSMA and CAMARA communities. TEF wonder which is the best option to make it happen. Would GSMA Openverse like to lead discussion on the technical approach, defining a stage 2 solution (input/output params and API usage in different scenarios) and let CAMARA define the the actual stage 3 (YAML)? Or do GSMA prefer that CAMARA make a first proposal? <br> GSMA [A]: Both options are fine. The first option require Open Gateway to include this Identity API in the backlog. The second option would require that Open Gateway validates whether CAMARA proposed solution works in federated environment; as long as it works, GSMA are fine with it. <br><br> GSMA [Q]: How to deal with subscriber identity in portability scenarios, when user moves from operator 1 to operator 2? From the ASP standpoint, the subscriber remains the same despite cross-opreator mobility; however, there exists impact on operator 2 side (it may reject the connection because the subscriber identity in the API request is no [longer] valid for the operator 2). <br> Vonage [A]: very good scenario that deserves attention and further analysis.  <br><br> TMUS: propose using this issue to document areas/use cases/requirements on susbcriber and application identification, and then come up with implementation details. TMUS also note that the discussion on input parameters for subscriber identifier might depend on targeted service API. <br> TEF: support TMUS comment above. <br> | 
+| [#16](https://github.com/camaraproject/IdentityAndConsentManagement/issues/16)  | Vonage | **Signed Consent - Certificate Authorities**</br> No time for discussion in the call. Continue off-line in Github. | 
+| [#17](https://github.com/camaraproject/IdentityAndConsentManagement/issues/17)  | DT | **Use of term NaaS**</br> No time for discussion in the call. Continue off-line in Github. | 
+| [#20](https://github.com/camaraproject/IdentityAndConsentManagement/issues/20)  | DT | **Introduction of Github Templates**</br>No time for discussion in the call. Continue off-line in Github.  | 
+| [#21](https://github.com/camaraproject/IdentityAndConsentManagement/issues/21)  | DT | **Definition of scenarios for consent management**</br>No time for discussion in the call. Continue off-line in Github.  |
+
+
+## Action Points
+
+| AP Identifier | AP Owner | Status | Description |
+| ------------- | -------- | ------ | ----------- |
+| 20230322-01 | Sub-Project participants | Open | Involve privacy/legal teams in the Sub-Project discussions. |
+| 20230322-02 | Sub-Project participants | Open | Review the [slide deck](https://github.com/camaraproject/IdentityAndConsentManagement/raw/main/documentation/SupportingDocuments/Identity%20and%20Consent%20Sub%20Project%20kickoff.pptx), align internally and provide comments in the mail list |
+| 20230412-01 | Sub-Project participants | Open | Review the [baseline document](https://github.com/camaraproject/IdentityAndConsentManagement/pull/13/commits/11e4a3d44ad3a2731d8af70b447d50f81c8efda6#diff-d9ac5140672a5e419688aab0947167d98cee83680cc623f4366923919868e9c4) and provide comments in PR#13.|
+
+
+
+## AoB
+
+Next call schedule: 17th May 2023
+