generated from camaraproject/Template_API_Repository
-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IdentityAndConsentManagement meeting notes 2023-07-26 #53
Merged
Merged
Changes from 2 commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,86 @@ | ||
| # Identity and Consent Management meeting | ||
|
|
||
| #### *26th of July 2023* | ||
|
|
||
| <br> | ||
|
|
||
| ## Attendees | ||
|
|
||
|
|
||
| | Companies | Attendees | | ||
| | --------- | --------- | | ||
| | Deutsche Telekom AG | Shilpa Padgaonkar, Rafal Artych| | ||
| | Vonage | Chris Howell | | ||
| | Vodafone | Eric Murray, Sönke Peters | | ||
| | Telefónica | Jesús Peña, Diego Gonzalez, Guido García, Jorge García Hospital | | ||
| | T-Mobile US | Murat Karabulut | | ||
| | GSMA | Mark Cornall, Toyeeb Rehman, Tom van Pelt | | ||
| | KDDI | Toshiyasu Wakayama | | ||
| | | Daniel Okonkwo | | ||
| | | Elangovan Thanasekaran | | ||
|
|
||
| <br> | ||
|
|
||
| ## Agenda | ||
|
|
||
| 1. Recent updates & recap | ||
| 2. Issues and PRs. | ||
| - Discussion on Issue #32. "The concept of purpose". @Jesús (Telefónica) to present the use case proposed and Telefónica resolution proposal. @Orange to present their resolution proposal. | ||
| - Discussion on Issue #15. "Subscriber Identity API". @ChrisHowell to present Vonage proposal provided on github and Telefónica (@Jesús) to comment on the feedback provided from their side. | ||
| - Disscussion on new Issue #52. "Differences in authentication on APIs between deployments can lead to differences in API usage and break federation". | ||
| - Review of the remaining issues & housekeeping. If there is room for it. Otherwise it will be done offline. | ||
| 3. Action Points | ||
| 4. AoB | ||
|
|
||
| <br> | ||
|
|
||
| ## Recent updates & recap | ||
|
|
||
| Telefonica presents the status of WG: | ||
|
|
||
| - 1 new issues #52. To be further discussed in this call. | ||
| - 5 ongoing issues #15, #21, #32, #45 & #46. Main updates on: | ||
| - Issue #15 "Subscriber Identity API". To be further discussed in this call. | ||
| - Issue #21 "Definition of scenarios for consent management". No updates about this issue other topics being prioritized. | ||
| - Issue #32 "The concept of purpose". To be further discussed in this call. | ||
| - Issue #45 "Add missing details in authN-authZ doc". To document details of network-based auth. Pending. | ||
| - Issue #46 "Extend AuthN-AuthZ doc with detailed CIBA flow description". To document details of CIBA. Pending. | ||
| - 1 issues closed: #47. | ||
| - CAPIF content has been removed from the AuthN-AuthZ document. | ||
|
|
||
| <br> | ||
|
|
||
| ## Issues and PRs | ||
|
|
||
| | **Issue** | Owner | Description | | ||
| | ----------| ----- | ----------- | | ||
| | **Open issues** | | | | ||
| | [#15](https://github.com/camaraproject/IdentityAndConsentManagement/issues/15) | GSMA/Vonage | **Subscriber Identity API**<br> -Chris points out that what is discussed in issue #52 is related to the Subscriber Identity API and the proposed alternative flow because it tries to abstract the difference between authentication and authorisation flows. The Subscriber Identity will serve as a Subscriber Token to get an Access Token, always using the same mechanism (the BE based CIBA flow).<br>- Telefónica disagree, as what is proposed is in fact an alternative flow to the FE flow and Telco Finder routing logic based on IP.<br>-Telefonica suggests to split the scenarios where the API can be used to go through them one by one and check for which there is agreement on the need for the API.<br>- There is a discussion about the security of the API if it is open to the Internet. Chris does not agree that there is a security issue in the proposed flow. Telefónica disagree and there are real concerns about this point which is being validated with security teams.<br>- Regarding user consent, Chris points out that the subscriber token won't be personal information, it will be scrambled data. Need to be validated by privacy teams.<br><br>As a way forward, it was agreed to split the discussion on the Subscriber Identity API into several separate issues related to specific use cases for the API or points of misalignment. For example:<ul><li> Having a "standard" user identifier for subsequent calls to CAMARA APIs (avoiding having IPv4, IPv6, MSISDN, external_id, etc.) or to use as login_hint in AuthN/AuthZ flows. **NOTE: Telefonica recommends not to use any and to simply refer to the user identifier associated with the 3-legged access token used to access the corresponding CAMARA API.**<li>Allow offline access to CAMARA APIs.<li>Having a routable user identifier.<li>Having an "opaque" user identifier that is not sensitive to be stored by the application/aggregator.<li>Security.<li>Handling of PII.<li>... </ul>Chris volunteers to do this. | | ||
| | [#21](https://github.com/camaraproject/IdentityAndConsentManagement/issues/21) ([PR#33](https://github.com/camaraproject/IdentityAndConsentManagement/pull/33))| Deutsche Telekom AG | **Definition of scenarios for consent management**<br> No updates about this issue other topics being prioritized. | | ||
| | [#32](https://github.com/camaraproject/IdentityAndConsentManagement/issues/32) | Orange | **The concept of purpose**<br> There was no Orange participant in the call. So the details of the low level proposal were not discussed. It will be taken offline.<br>As agreed in the previous call, Telefonica has already defined a representative CAMARA APIs scenario related to the definition and declaration of "purposes" and how the Telefonica solution proposal would address it.<br>Orange was asked to do the same analysis in order to compare both proposals and make a decision. | | ||
| | [#45](https://github.com/camaraproject/IdentityAndConsentManagement/issues/45) | Deutsche Telekom AG | **Add missing details in authN-authZ doc**<br> To document details of network-based auth in authN-authZ doc. [PR](https://github.com/camaraproject/NumberVerification/pull/50) change to fix https://github.com/camaraproject/NumberVerification/issues/46 to be piggybacked here. Still pending. | | ||
| | [#46](https://github.com/camaraproject/IdentityAndConsentManagement/issues/46) | Deutsche Telekom AG | **Extend AuthN-AuthZ doc with detailed CIBA flow description**<br> The AuthN-AuthZ document will be maintained as the generic AuthN/AuthZ guidelines and recommendations used in CAMARA APIs. And in particular for the CIBA flow, this document will refer to the `user-consent.md` document, where the detailed CIBA flow will be included (WIP).<br><br>The issue will be kept in the backlog and activated later when the corresponding PR for the `user-consent.md` document including the mentioned flow is ready. | | ||
| | **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. | | ||
|
|
||
| <br> | ||
|
|
||
| ## Action Points | ||
|
|
||
| | AP Identifier | AP Owner | Status | Description | | ||
| | ------------- | -------- | ------ | ----------- | | ||
| | 20230712-01 | Deutsche Telekom AG (Shilpa) | Ongoing | Move authN-authZ concept doc from Commonalities and update content according to open issues in github | | ||
| | 20230712-02 | Telefónica (Jesús) | Ongoing | Fill in [user-consent.md](https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/user-consent.md) with the information related to the CAMARA APIs access flows approved in the GSMA. | | ||
| | 20230712-03 | Telefónica (Jesús) | Done | ~~Propose a representative CAMARA APIs scenario related to the definition and declaration of "purposes" and how the TEF proposal would address it.~~ | | ||
| | 20230712-04 | Orange (Sébastien) | Pending | Provide how the Orange proposal would address same CAMARA APIs scenario proposed in `20230712-03` | | ||
| | 20230712-05 | Sub-Project participants | Pending | Agree on the technical solution to be implemented for purpose management as a result of the practical scenario comparison. | | ||
| | 20230726-01 | Chris (Vonage) | Pending | Split the Subscriber Identity API discussion into several separate issues related to each specific use case identified for the API or points of misalignment. | | ||
|
|
||
| <br> | ||
|
|
||
| ## AoB | ||
|
|
||
| - Next call schedule: 23th Aug. 2023 | ||
| - Closed [discussion #48](https://github.com/camaraproject/IdentityAndConsentManagement/discussions/48) "IdentityAndConsentManagement summer break" - We will skip the 9th August IdentityAndConsentManagement call. Same week as Commonalities break [camaraproject/WorkingGroups#261](https://github.com/camaraproject/WorkingGroups/discussions/261).. | ||
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 24ef413