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

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

@@ -41,7 +41,7 @@ New issues have been opened as well (see next clause).
 | **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. Ideally we should have a unified identity API that, upon taking the input  "applicable subscriber identifier + ASP id + aggregator id (if needed)", with subscriber identifier being dependent on targeted service API, is able to always produce the same output parameter. <br> | 
+| [#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.  |