Identity and Consent Management meeting

Attendees (Please add or remove yourself)

Camara People

Participants

Agenda

1. Housekeeping Topics

   • Meeting moving from MS Teams to LinuxFoundation Zoom cf Camara Calendar and Readme

   • Recording of of our Zoom meetings and AI generated Transscripts

   • Using suggestions in reviews (the +--button)

   • Move minutes to Camara Wiki

2. Issues and PRs. Priority discussions (most active issues and/or dependencies for release v0.2):

   • Profile work https://github.com/camaraproject/IdentityAndConsentManagement/pull/121

   • offline access #123

   • Discussion on Issue #100 "Claims to be used in oAuth Access tokens".

   • Discussion on Issue #108 "Question to documentation update for security schemes".

   • Discussion on Issue #104 "Alignment of Client Credential authentication / authorization using API Gateway Pattern".

3. Action Points

4. AoB

Housekeeping

Axel thanked contributers who provided text changes and asked them to use +- button to add their text suggestion to their review. Clicking the +- button in a review adds a suggestion which can easily be added to the document.

```suggestion

This is the suggested new text

```

Discussion the Way Forward regarding the Profile

Axel said that we are having good discussions and comments on #121. There is good progress. Some topics should be tackled in their own issues referencing #121. Our work should concentrate on one profile and TEF agreed that the most support seems to be for the DT proposal.

Guido Garcia's proposed focusing now on a v0.2.0 profile version including existing agreements and required clarifications on top of them. And complete this in PR #121 using DT's PR as a reference. TEF PR could be closed (or put in draft for the record). And then non previously discussed topics (like us DPoP, etc...) or mid-term solutions pending to be agreed (basically the purpose one) to be discussed in dedicated issues and considered for a next OIDC profile version (v0.3.0). TEF said that discussions like the purpose one can take a long time (like it happens in the past for for v0.1.0 agreement) and it does not make sense to block current PR until all these discussions are finished.

The group agreed that topics in #121 that lead to longer discussion should be discussed in their own issue. Axel mentioned that @Former user (Deleted) already created some issues. TEF mentioned the new ideas regarding login_hint and aud clarifications as potential new issues. New topic should move to new issues. TEF: purpose is a non-trivial issue. Also: pairwise identifiers and new ideas on login_hint Move forward with the DT profile. 

TEF proposed to use the label 0.2 on issues that we seem likely to make it into the 0.2 version of the profile. TEF said that purpose, offline access and pairwise identifiers should be removed from #121 to make it easier to agree on the profile and close the PR. Then tackle these open issues in the next version. Shilpa said that she wants a DT internal discussion first. Axel said that he thinks that offline access can make it into the current version because Jesús seems to be OK with the proposed text when authorization code flow is concerned and "only" CIBA-related text for offline access is missing.

Conclusion: move long discussions into their own issues, mark those issues with 0.2 if they go in this version, mark them as 0.3 if they go into the next version. DT internal discussion on removing the purpose, offline access and pairwise identifiers.

Consent and refresh tokens

Elisabeth raised the topic that the AZ has to evaluate the consent when the client uses a request token to get a fresh access token. Because in the meantime the consent might have been changed. Axel says that in CIBA in is specified that the AZ can deny these requests. CIBA talks about token life times etc that might lead to the request being denied. Jesús agrees with Elisabeth that the consent has to be re-evaluated. Elisabeth stresses the importance of the consent re-evalutation and asks Axel to include text regarding consent re-evaluation.

Izahir Clemencia put the link to RFC7009 into the chat and remarked that implementors have to revoke tokens if the user revokes consent. Axel said that the discussion about token revocation took years in the OIDF. Good that with RFC7009 there is a standard to revoke token. Altough Axel has not heard that implementors are really doing token revokation. Axel said he'll put some text proposal into the profile.

Important implementation details

Elisabeth suggested that the profile highlights important implementation details e.g. like that consent has to be re-evaluated. Axel was reluctant to agree because that make the document longer, but said if somebody experienced some mis-interpretation of the OIDC, Oauth2, CIBA or whatnot standards then maybe it is worth stating what the common interpretation of the standard is. Please open issues and create PRs, if you think we need to mention something or clarify someething.

Id_Token

Elisabeth suggested that the profile has some text on the id token, its format and usage. What they are meant for. The topic was derailed but please propose text.

Discussion about offline-access and Refresh Token PR

On the one hand, @Jesús Peña García-Oliva  said that he supports (and Telefónica) that the final text we end up agreeing on regarding offline access definitely needs to be included in the CAMARA OIDC profile. But specifically regarding the refresh_token/offline_access flows included in CAMARA-API-access-and-user-consent.md in that PR, the working group should make a decision if we want to merge them eventually or if the PR should be closed considering only the offline access section of the profile. The original request was to move the information from GSMA to CAMARA.

On the other hand, regarding the proposed offline access text for the OIDC profile in the PR, @Jesús Peña García-Oliva  said that he is fine with this text, except for the rules copied from the OIDC standard. In the case of CAMARA, authorization code is not the only flow to support. For example, offline_access must also be allowed for the CIBA flow. And he also mentioned that there was no requirement on the prompt value or application type to use the offline_access scope to request a refresh token to cover Opengateway off-net scenarios to access CAMARA service APIs.

Then @Axel Nennker clarified that the proposed text was only for Auth code flow, which @Jesús Peña García-Oliva  hadn't noticed before. 

Axel asked for some days to provide CIBA-related text.

Closing Remarks

Axel kindly asked participants to comment on issues and to review PRs and most importantly contribute text changes to PR. WGs thrive only if members become participants. So, again please participate. Please comment and review.

AoB

• Next call schedule: March 13, 2024.