Added correction suggested by Shilpa

documentation/MeetingMinutes/MOM-2023-07-26.md

@@ -63,7 +63,7 @@ Telefonica presents the status of WG:
 | **Closed issues** |  |  |
 | [#47](https://github.com/camaraproject/IdentityAndConsentManagement/issues/47) ([~~PR#50~~](https://github.com/camaraproject/IdentityAndConsentManagement/pull/50)) | Deutsche Telekom AG | **~~Remove CAPIF content from AuthN-AuthZ doc~~**<br> CLOSED. CAPIF content has been removed from the AuthN-AuthZ document. |
 | **New issues** |  |  |
-| [#52](https://github.com/camaraproject/IdentityAndConsentManagement/issues/52) | GSMA | **Differences in authentication on APIs between deployments can lead to differences in API usage and break federation**<br> - TEF states that any API that handles user resources should be 3-legged.<br>- Shilpa points out that it's ok for user resource to be handled with 3-legged. But for this case there are several flows e.g. AuthCode and CIBA. Shilpa points out that there should be a discussion on what rules should be applied to decide which flow or flows are valid for an API.<br>- Chris (Vonage) asks about the flows, if they have been agreed. Jesús indicates that flows have been agreed in GSMA and the agreement in the previous call was to document flows in CAMARA. Chris indicated that agreements in OpenGateway need to be discussed and eventually accepted in CAMARA.<br>- Chris indicated that he is confused about the 3-legged concept, whether it implies action by the resource owner or just includes the user identity in the access token. Chris asks whether 3-legged refers to the device or the user (user/password), as mechanisms such as network based authentication do not explicitly involve the resource owner.<br>- Diego (Telefónica) points out that network based authentication is just one of the many authentication methods that exist. And, of course, each of them has a different level of assurance based on the factors they rely on to verify a user's identity. In this case, network-based authentication could be similar to SMS 2FA, which validates proof of ownership of a mobile device.<br>- Mark (GSMA) points out that it would be good to specify in certain APIs whether they should be used one way or another. And Identity&Consent can indicate the ruleset.<br><br>It is agreed that the appropriate set of rules with the technical criteria applicable to each flow must be defined in CAMARA. |
+| [#52](https://github.com/camaraproject/IdentityAndConsentManagement/issues/52) | GSMA | **Differences in authentication on APIs between deployments can lead to differences in API usage and break federation**<br> - TEF states that any API that handles user resources should be 3-legged.<br>- Shilpa points out that where user resource is to be handled we need 3-legged authN. But for this case there are several flows e.g. AuthCode and CIBA. Shilpa points out that there should be a discussion on what rules should be applied to decide which flow is the most recommended for an API. This will help the subprojects to decide on the flows and help with an improved developer experience.<br>- Chris (Vonage) asks about the flows, if they have been agreed. Jesús indicates that flows have been agreed in GSMA and the agreement in the previous call was to document flows in CAMARA. Chris indicated that agreements in OpenGateway need to be discussed and eventually accepted in CAMARA.<br>- Chris indicated that he is confused about the 3-legged concept, whether it implies action by the resource owner or just includes the user identity in the access token. Chris asks whether 3-legged refers to the device or the user (user/password), as mechanisms such as network based authentication do not explicitly involve the resource owner.<br>- Diego (Telefónica) points out that network based authentication is just one of the many authentication methods that exist. And, of course, each of them has a different level of assurance based on the factors they rely on to verify a user's identity. In this case, network-based authentication could be similar to SMS 2FA, which validates proof of ownership of a mobile device.<br>- Mark (GSMA) points out that it would be good to specify in certain APIs whether they should be used one way or another. And Identity&Consent can indicate the ruleset.<br><br>It is agreed that the appropriate set of rules with the technical criteria applicable to each flow must be defined in CAMARA. |
 
 <br>