Instead of talking about network-based auth and non-network-based auth methods in general, shouldn't we discuss each new auth method to be supported by CAMARA (and its implications) individually? And consider network-based auth as the default method for backwards compatibility with previous meta-releases.

I would like to start the discussion by proposing changes that allow API consumers to interoperable ask for network-based authentication if they need it.
I took a stab at these needed changes in Allow API to decide on network-based authentication in OIDC authorization code flow

That would also allow APIs to make that mandatory.

This issue was first discussed at the last WG call (https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/69435394/2025-01-29+ICM+Draft+Agenda+Minutes). I will add the meeting notes here for the record.

Issue: Discuss and specify requirements for enabling Interoperable Authorization Code Flow with Network and Non-Network based Authentication Methods in Camara

Background

• The discussion originated from Issue #215, which aimed to clarify authentication methods in the Authorization Code Flow.
• The outcome of Issue Authentication method in authorization code flow #215 confirmed that CAMARA currently only considers network-based authentication for issuing access tokens, but there was agreement that CAMARA does not intend to restrict the flow to network authentication exclusively.
• As a result, Issue #245 and PR #244 were created to explore new authentication methods while ensuring interoperability.

...

Proposal for Supporting Non-Network-Based Authentication

• A new issue was created to discuss how to introduce additional authentication methods while maintaining interoperability.
• An initial proposal from Axel Nennker suggests modifying the profile to support non-network-based authentication methods. Currently, CAMARA's Authorization Code Flow assumes network-based authentication. The proposal suggests that API consumers should explicitly request network-based authentication via an acr value. If no acr is provided, the flow would follow OpenID standards, which do not mandate a specific authentication method.

Concerns on Backward Compatibility

• Jesús expressed concerns that this proposal would break backward compatibility. Under the current implementation, if no acr value is provided, the default behavior is to use network-based authentication. The proposed change would alter this, leading to potential integration issues.
• Jesús suggested:
  • Maintain backward compatibility by keeping Network-Based Authentication as the default behavior, with acr_values providing optional flexibility.
  • Standardize acr_values for each supported authentication method, ensuring granularity and clear expectations for both UX and security.
  • Define error scenarios for unsupported acr_values and standardize their handling to avoid inconsistencies across operators.
  • Ensure token-device/phone number association is preserved for all supported authentication methods.
• The group needs to further analyze whether this approach is the best way to introduce non-network-based authentication while preserving compatibility with existing integrations.