Agenda

Antitrust Policy

• ICM 0.3.0 - preparing the scope for meta-release Spring25 #193

  • Completing the Sprin25 scope items should now be our highest priority. The WG is running out of time to meet the Release Management milestones and schedule:

    • Clarity on the use of login_hint #191 (No associated PR)

    • New sections with error scenarios #211
      -> Add response codes for error scenarios #220

    • Add exemples full CIBA flow for CIBA in CAMARA-ICM-examples.md #236
      -> Update CAMARA-ICM-examples.md with CIBA examples #237

    • Spring25: Proposal to RECOMMEND the use of Signed Request Object for the /authorize endpoint to prevent abuse #205
      -> recommend auth code flow using signed requests #226

    • Proposal for CAMARA mandated minimum acceptable JWT token lifetime #208
      -> Update section on client authentication #216

    • DPoP support in CAMARA OIDC Profile #125
      -> Clarifications on using sender-constraint tokens DPoP #225

• Question on Purpose definition, W3C Data Privacy Vocabulary​ (DPV) #222

• Allow to use operator token for device authentication in OpenID Auth code flow #232
  -> Add a section on operator token usage in authorization code flow #238

Minutes

ICM 0.3.0 - preparing the scope for meta-release Spring25 #193

• The working group (WG) reviewed and prioritized open issues and pull requests (PRs) critical for the Spring25 meta-release. The main goal was to finalize discussions and consolidate decisions on key scope items to meet release management deadlines. The deadline proposed for closing these scope-related topics was set for the end of this week to avoid delays into January.

Topics Reviewed:

• Clarity on login_hint (#191):

  • The issue revolves around whether login_hint should be mandatory or optional in the authorization code flow. Historically defined as mandatory in CIBA, its use for other flows was less clear.

  • WG consensus: “Optional” status for login_hint in the authorization code flow, ensuring implementations can ignore it if not applicable. A PR will be created to update the documentation accordingly, emphasizing interoperability. @Jesús Peña García-Oliva takes the AP to create the requested PR.

    • UPDATE (19/12): done. PR is available at https://github.com/camaraproject/IdentityAndConsentManagement/pull/242

• Error Scenarios Appendix (#211, #220):

  • Proposal: Consolidate all potential error scenarios into a normative appendix for ease of reference by developers.

  • Debate: Some concerns were raised about inadvertently contradicting standards. However, the majority supported this addition as a valuable tool for implementers.

  • Action: Add comments clarifying WG alignment and seek to unblock PR #220.

  • @Eric Murray propose to ask @Herbert Damker to remove Axel's PR block if there is no review/response from @Axel Nennker

• CIBA Flow Examples (#236, #237):

  • Discussed enhancing the CAMARA-ICM-examples.md file to include a full CIBA flow example (BC request, BC response, and token request).

  • Pending: Address minor comments and Eric’s suggestion regarding clarification on signed vs. unsigned examples. @Sébastien Dewet

• Signed Request Object for /authorize (#205, #226):

  • Reviewed the need to recommend signed request objects to mitigate abuse at the /authorize endpoint.

  • Pending topics:

    • OIDC vs. RFC 9101 as a reference.

    • aud value.

    • sub claim requirement (not include it in request object assertion) to avoid cross-JWT confusion.

  • Discussed discrepancies between OpenID Connect (OIDC) and RFC 9101, Telefónica propose to follow RFC 9101 as the primary reference.

  • Telefónica’s position to use the “aud” claim as the issuer URL.

  • Additional clarification on not including the “sub” claim to avoid JWT confusion was requested. A final review will validate this approach.

• JWT Token Lifetime (#208, #216):

  • Consensus on token lifetime computation:

    • If the iat (issued at) claim is present, use it as the baseline.

    • If absent, use the token’s arrival time at the authorization server.

  • @Eric Murray propose to ask @Herbert Damker to remove Axel's PR block if there is no review/response from @Axel Nennker

• DPoP Support (#125, #225):

  • Simplified behavioral requirements for DPoP tokens:

    • If an API consumer does not provide a DPoP proof, the API provider can issue a bearer token.

    • Scenarios where DPoP is required or ignored were clarified using a simplified table.

  • Action: Approval needed from key contributors to finalize the PR.

Question on Purpose definition, W3C Data Privacy Vocabulary​ (DPV) #222

• Discussed referencing the W3C’s DPV for naming purposes in ICM specifications.

• Concern: DPV is currently a W3C community report, not a formal standard.

• Consensus:

  • Continue using DPV as the de facto reference for interoperability.

  • Emphasize linking to a specific version (e.g., Version 2) to ensure consistency even if the vocabulary evolves.

  • Acknowledged similar references in industry (e.g., TM Forum, GSMA) reinforcing its credibility.

Operator Token Usage in Authentication (#232, #238)

• Key discussion: Operator tokens—used in login_hint—are suitable for identifying devices but not for authentication due to security risks (e.g., theft on Android platforms).

• Additional considerations:

  • Binding operator tokens to apps could mitigate risks, but current implementations lack this feature.

  • Improvements under discussion with Apple and Google may enhance token security.

• Proposal:

  • Update ICM documentation to clarify operator tokens’ limited use cases. @Elisabeth Mueller takes the action point to create the PR.

  • Link related Issue and PRs (#232, #238) to streamline alignment and close both.

AOB

• Operator Token Discussion Extended

  • @Mark Cornall (GSMA) highlighted that operator tokens are not fully standardized or suitable for routing in multi-aggregator environments.

  • @Elisabeth Mueller emphasized the need to expand operator tokens’ use cases, such as routing, while recognizing current limitations.

  • Discussion on whether such improvements should be driven by GSMA or CAMARA.

  • It was mentioned that routing capabilities are out of CAMARA’s scope but could be addressed by extending the operator token via other forums (e.g., GSMA’s TS.43).

  • Participants noted ongoing efforts to enhance operator tokens’ security and functionality (e.g., binding tokens to apps).

  • The group stressed the importance of ensuring CAMARA’s APIs can adapt to future enhancements to maintain relevance across various implementations.

  • @Jesús Peña García-Oliva suggested that further requirements (if any) for operator token capabilities (apart from existing login_hint) be formalized and submitted to CAMARA for evaluation.

Next Meeting

The next working group call is tentatively scheduled for January 15, 2025, as the upcoming holiday season will delay regular meetings.