IdentityAndConsentManagement meeting notes 2023-07-26 #53
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rartych
previously approved these changes
Jul 27, 2023
| | **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. | |
There was a problem hiding this comment.
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.
rartych
approved these changes
Jul 28, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
What this PR does / why we need it:
MoM of the call held in 2023-07-26.
Which issue(s) this PR fixes:
None.