Skip to content
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

Update ProjectStructureAndRoles.md - Add ICM WG #157

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

MarkusKuemmerle
Copy link
Collaborator

What type of PR is this?

  • documentation

What this PR does / why we need it:

  • ICM WG missing in enumeration

Which issue(s) this PR fixes:

Fixes #147

Special notes for reviewers:

Additional documentation

@hdamker
Copy link
Collaborator

hdamker commented Aug 7, 2024

@camaraproject/identity-and-consent-management_codeowners Would you please have a short view on this PR?

**Identity and Consent Management**

In the Identity and Consent Management Working Group solutions are defined and developed to identify users/subscribers, to capture, store and manage user consent, and to make sure that end user experience of using the API is not compromised.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that the Working Group “Identity and Consent Management” (as Commonalities) also works under the supervision of the TSC.

On the other hand, as Commonalities, all subprojects must be consistent (comply) with the work of the Identity and Consent Management Working Group.

Finally, we can also mention the ICM work around API access definitions and the Security and Interoperability Profile, which includes CAMARA definitions for AuthN/AuthZ flows.

These are just suggestions :)

Comment on lines 78 to 81
**Identity and Consent Management**

In the Identity and Consent Management Working Group solutions are defined and developed to identify users/subscribers, to capture, store and manage user consent, and to make sure that end user experience of using the API is not compromised.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
**Identity and Consent Management**
In the Identity and Consent Management Working Group solutions are defined and developed to identify users/subscribers, to capture, store and manage user consent, and to make sure that end user experience of using the API is not compromised.
**Identity and Consent Management**
The Identity and Consent Management Working Group, operating under the supervision of the Technical Steering Committee (TSC), focuses on defining and developing comprehensive solutions for user/subscriber identification, consent capture, storage, and management. These solutions ensure that user experience with the API remains seamless and uncompromised.
All Sub Projects must comply with the work in the "Identity and Consent Management" Working Group. The Working Group's efforts include defining API access parameters and developing the Security and Interoperability Profile, which encompasses CAMARA definitions for authentication and authorization (AuthN/AuthZ) flows.

Does this look good? Please feel free to change anything you like.

Copy link
Collaborator

@hdamker hdamker Aug 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point to express the same level of governance and compliance for Identity and Consent Management.

Small changes in my proposal below:

  • I haven't understood what is meant with "defining API access parameters" so I left it out.
  • Proposal to not start a new explanation after the sentence "All Sub Projects must comply with the work in the Identity and Consent Management Working Group."
  • replaced "uncompromised" (which my syntax check does not like) with "protected".
Suggested change
**Identity and Consent Management**
In the Identity and Consent Management Working Group solutions are defined and developed to identify users/subscribers, to capture, store and manage user consent, and to make sure that end user experience of using the API is not compromised.
**Identity and Consent Management**
The Identity and Consent Management Working Group, operating under the supervision of the Technical Steering Committee (TSC), focuses on defining and developing comprehensive solutions for user/subscriber identification, consent capture, storage, and management. These solutions ensure that user experience with the API remains seamless and protected.
The Working Group's efforts include developing the Security and Interoperability Profile, which encompasses CAMARA definitions for authentication and authorization (AuthN/AuthZ) flows.
All Sub Projects must comply with the work in the Identity and Consent Management Working Group.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not want it to be too complicated but usually there is no "user identification".
Telcos do identify the subscriber but we do not identify the user. At least not what commonly is understood as the "user".

Also, I would rephrase making it clearer that "storage, and management" are related to consent.

The Identity and Consent Management Working Group, operating under the supervision of the Technical Steering Committee (TSC), focuses on defining and developing privacy-first solutions for subscriber identification, and user authentication, and the purpose of the API access, and user consent capture, storage, and management. These solutions ensure that the API access is always authorized and secure.

That got somewhat lengthy...

ProjectStructureAndRoles.md Outdated Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add Identity And Consent Management (ICM) Working Group to ProjectStructureAndRoles
5 participants