Create a list of known SAML gaps at SL1

[deansaxe]

Over the past few weeks, the WG has held a number of discussions about the ways that SAML does not operate like OIDC. The WG has a very rough consensus from call attendees that we should not include any requirements in SL1 that would block existing SAML implementations from becoming compliant. However, we have not yet identified the list of gaps in SAML that would block existing SAML implementations from reaching SL1 with our current outcomes (see https://github.com/openid/ipsie/blob/main/ipsie-levels.md) and common requirements (see https://github.com/openid/ipsie-common-requirements-profile). As highlighted on the August 12, 2025 call, we run the risk of implementing requirements in OIDC SL1 which cannot be met in SAML SL1 that may require changing OIDC SL1 after the interop.

In order to avoid significant changes to OIDC SL1 to accommodate SAML SL1, please use this issue to document all known gaps in current SAML implementations/protocol specifications that would block SAML implementations from achieving SL1 as we have defined the outcomes today.

I'll include two examples below.

1. IdP-initiated SAML federations are in wide use today. Blocking IdP-initiated federation, as is proposed in https://github.com/openid/ipsie-common-requirements-profile based on the NIST800-63 rev4 requirements at FAL2 would preclude most SAML implementation from reaching SL1. The recommendation is to allow IdP-init at SL1 and disallow IdP-init at SL2+.
2. SAML does not have a defined mechanism for communicating amr claims. There are custom mechanisms, but no normative standard. The recommendation is that IPSIE define a normative mechanism for custom amr style claims in SAML that can be included in the SAML SL1 profile.

[deansaxe]

@timcappalli opened a similar issue (#4) late last year.

[amonika230995]

SAML doesn't have consent management as well. Would it be in the interest of IPSIE to say which protocol is modern and more appropriate to use?