OpenID Connect Working Group K. McGuinness Internet-Draft Independent Intended status: Informational 19 May 2026 Expires: 20 November 2026 OpenID Connect Bridge Profile for SAML 2.0 Service Providers draft-connect-saml-bridge-profile-latest Abstract This document defines an interoperability profile for deployments that present a SAML 2.0 Identity Provider interface to existing Service Providers (SPs) while using an OpenID Provider (OP) as the underlying authentication authority. The profile specifies how a Bridge component, acting simultaneously as an OIDC Relying Party toward the OP and as a SAML IdP facade toward the SP, translates OIDC authentication results into SAML assertions while preserving subject continuity, enforcing audience restrictions, and maintaining per-SP attribute release policies. Two operational patterns are defined. The browser-based flow allows a SAML SP to initiate authentication through the Bridge using standard SAML Web SSO; the Bridge in turn authenticates the end-user via the OP and constructs a signed SAML assertion for delivery to the SP's Assertion Consumer Service. A Token Exchange variant allows a confidential client to present an OIDC ID Token to the Bridge's token endpoint and receive a SAML 2.0 assertion, without a browser-based SAML exchange. The intent is to let an OP serve existing SAML SPs without changes to the SPs' trust configuration, metadata, or ACS endpoints, and without re-federating each SP one by one. The profile is scoped to federation interoperability and identity continuity; it does not define a generalized SAML IdP, authorization architectures, provisioning, or governance models. This document is the inverse companion to the OpenID Connect Migration Profile for SAML 2.0 Service Providers [SAML-OIDC-MIGRATION]. The two profiles are designed to be deployed together, using the same Bridge entity as the translation point in both directions. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/draft-connect-saml-migration. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 20 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 1.1. Non-Goals 2. Conventions and Terminology 2.1. Requirements Notation 2.2. Terminology 2.3. Role Symmetry with the Companion Profile 3. Applicability and Deployment Model 4. Bridge Binding Rationale 5. Authorization and Assertion Issuance Model 6. SP-Binding Configuration 6.1. saml_sp_entity_id 6.1.1. Authorizing the saml_sp_entity_id Binding 6.2. Per-SP-Binding Administrative Configuration 6.3. NameID Format Policy 7. Bridge Metadata 7.1. SAML IdP Metadata 7.2. OAuth Authorization Server Metadata 7.2.1. oidc_op_issuer 7.3. Capability and Metadata Matrix 7.4. Bridge Key Material 7.5. Federation Metadata Coexistence 8. ID Token Validation 8.1. Accepted ID Token Inputs 8.2. Freshness and Authentication Time 8.3. ID Token Claims Required for This Profile 9. Browser-Based Protocol Flow 9.1. Flow Overview 9.2. AuthnRequest Processing 9.3. OIDC Authorization Request 9.4. Error Handling 10. Token Exchange: ID Token to SAML Assertion 10.1. Request 10.2. Bridge Processing 10.3. Successful Response 10.4. Error Response 11. Local Subject Resolution 12. NameID Construction 12.1. Pairwise NameID Construction 12.2. Public NameID Construction 12.3. EmailAddress NameID 12.4. Transient NameID 12.5. Common Rules 13. Attribute and Authentication Context Mapping 13.1. Authentication Context Mapping 13.2. Attribute Claim Mapping 13.3. Session Validity Bound 14. SAML Assertion Construction 14.1. Required Elements 14.2. SubjectConfirmationData 14.3. SAML Response Wrapper 14.4. Assertion ID and Replay Prevention 15. Session Termination and Revocation 15.1. Session Binding 15.2. Session Termination 15.3. SAML Single Logout 16. Security Considerations 16.1. Threat Model 16.2. SAML Signature Risks 16.2.1. XML Signature Wrapping on Incoming SAML 16.2.2. Outgoing Assertion Signature Algorithms 16.3. ID Token Validation Risks 16.4. OIDC Authorization Response Splicing 16.5. Metadata Fetching and SSRF 16.6. Replay and Bearer Risks 16.7. Binding Security 16.8. Token and Claim Security 16.9. Refresh Token Compromise 16.10. Protocol Confusion and Transport Security 17. Privacy Considerations 18. IANA Considerations 18.1. OAuth Authorization Server Metadata 18.2. Notes on Reused Parameters 19. References 19.1. Normative References 19.2. Informative References Appendix A. Examples A.1. Browser-Based SAML SSO Flow A.2. Token Exchange: ID Token to SAML Assertion Appendix B. Paired Profile Summary Acknowledgments Author's Address 1. Introduction Many deployments that have adopted OpenID Connect as their primary authentication protocol still need to serve SAML 2.0 Service Providers that cannot be immediately migrated. Operating a separate SAML IdP alongside the OP duplicates authentication authority, splits the session model across two protocol stacks, and leaves the OP's authentication decisions disconnected from the SAML assertions the SPs receive. This profile addresses cross-protocol interoperability and identity continuity across the OIDC-to-SAML boundary. The scenarios below illustrate where preserving the existing SAML trust relationship matters: * *Continuing to serve legacy SAML SPs.* An organization has consolidated onto an OP but still operates SAML SPs that cannot be migrated. The Bridge exposes a SAML IdP endpoint that the SPs can continue to use without changes to their metadata, trust configuration, or ACS logic. * *Single authentication authority across protocols.* Each SP- specific NameID is derived deterministically from the OP subject, so the user appears to the SP under the same identifier they had previously, with the OP performing the underlying authentication and reflecting that decision in the issued SAML assertion. * *Programmatic SAML assertion issuance.* A back-end client holding an OIDC ID Token can present that token to the Bridge's token endpoint and receive a SAML assertion for a specific SP, without a browser-based SAML exchange. This allows scripted migration tooling, integration tests, and service-to-service flows to construct valid assertions from validated OIDC authentication events. * *Non-disruptive consolidation.* SPs continue to receive assertions through their existing SAML federation interface while the deployment moves authentication to a single OP, preserving subject identifiers, attribute release policy, and assurance signaling. This profile: * defines a deployment model for a Bridge component that acts as an OIDC RP toward the OP and as a SAML IdP facade toward the SP; * defines per-SP binding configuration that scopes subject computation and attribute release to each SP relationship; * defines rules for translating OIDC subject identifiers into SAML NameIDs that preserve SP-specific subject continuity; * defines rules for translating OIDC claims into SAML attributes and authentication context; and * defines a Token Exchange variant in which an ID Token is exchanged for a SAML assertion without a browser-based flow. What this profile does not define is enumerated in Section 1.1. This profile is the inverse companion to [SAML-OIDC-MIGRATION], which defines how a SAML assertion can be exchanged for an OAuth 2.0 or OpenID Connect token. The two profiles share a common Bridge entity and are designed to be deployed together when an organization needs to maintain SAML SPs on different migration timelines. 1.1. Non-Goals The profile is scoped to OIDC-to-SAML interoperability and identity continuity. It does NOT define: * a generalized SAML 2.0 IdP, including SAML-native authentication, generic SAML SLO orchestration, AttributeQuery, AuthzDecisionStatement, or SP-specific SAML extensions; * federation establishment between otherwise independent OIDC and SAML parties; * API authorization architectures, scope design, or resource-server policy; * provisioning, SCIM integration, or account-lifecycle workflows; * governance models (approval, attestation, audit, segregation of duties); * migration methodology (rollout patterns, cutover sequencing); or * SAML EncryptedAssertion or EncryptedID issuance. 2. Conventions and Terminology 2.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.2. Terminology This document uses the terms "authorization server", "client", "client identifier", "issuer", and "scope" from OAuth 2.0, OAuth 2.0 Authorization Server Metadata, Token Exchange, and OpenID Connect. It uses the terms "Identity Provider", "Service Provider", "entityID", "Assertion", "Attribute", "AttributeStatement", "AuthnStatement", and "AuthnContext" from SAML 2.0. For the purposes of this document: OpenID Provider (OP): The authorization server that issues OIDC ID Tokens and is the ultimate authentication authority for end-users in this profile. Bridge: The component that implements both an OIDC Relying Party toward the OP and a SAML IdP facade toward one or more SAML SPs. The Bridge is the entity that constructs and signs SAML assertions. SAML SP Entity ID: The SAML entityID of a Service Provider that receives SAML assertions from the Bridge. This value is used as the audience of constructed assertions and as the relying-party key for subject and attribute policy. SP-Binding: The per-SP administrative configuration at the Bridge that records the relationship between a SAML SP and the OIDC-based authentication context, including subject mapping policy, NameID format, attribute release policy, and ACS endpoints. Local Account: The Bridge's or OP's internal account record for the end-user. Subject continuity at the Bridge requires that a given (iss, sub) pair can be resolved to one stable SP-specific NameID per SP-Binding. Migration Client: An OAuth 2.0 client registered at the Bridge's token endpoint that uses the Token Exchange variant to obtain SAML assertions programmatically. This document uses "client" as a shorthand for Migration Client when the context is clear. 2.3. Role Symmetry with the Companion Profile The following table shows the role correspondence between this profile and its companion [SAML-OIDC-MIGRATION]: +==========================+=================+======================+ | Dimension | | This profile | +==========================+=================+======================+ | Authentication authority | SAML IdP | OpenID Provider | | | | (OP) | +--------------------------+-----------------+----------------------+ | Translation component | OAuth AS / | Bridge (SAML IdP | | | OpenID Provider | facade) | +--------------------------+-----------------+----------------------+ | Relying party | OAuth Client | SAML SP / | | | | Migration Client | +--------------------------+-----------------+----------------------+ | Token Exchange input | SAML Assertion | ID Token | +--------------------------+-----------------+----------------------+ | Token Exchange output | OAuth / OIDC | SAML Assertion | | | token | | +--------------------------+-----------------+----------------------+ Table 1 3. Applicability and Deployment Model This profile assumes that an administrative authority operates, or tightly governs, both: * an OpenID Provider identified by an OIDC issuer; and * a Bridge component, identified by a SAML IdP Entity ID, that the Bridge exposes in SAML metadata and uses to sign SAML assertions. The profile establishes three bindings: * issuer binding: the Bridge's SAML IdP Entity ID is bound to an OP issuer; * SP binding: the Bridge maintains a per-SP-binding configuration for each SAML SP it serves, scoping subject computation and attribute release; * subject and NameID binding: the Bridge derives a stable, SP- specific NameID from the OP subject, preserving subject continuity for each SP relationship. When these bindings are present, the Bridge can issue SAML assertions that preserve the subject identifiers and claim release policy each SAML SP previously relied upon, without requiring the SP to change its metadata, trust configuration, or ACS logic. This profile is intended for deployments in which the OP and the Bridge are under common administrative control. It is not intended to establish a federation trust between otherwise independent OIDC and SAML parties. This profile also assumes that the Bridge has a deterministic way to derive a stable NameID for each SP before issuing a SAML assertion, either through a pre-established account linkage or through a deterministic derivation function applied to the OP subject and the SP Entity ID. This profile applies to: * the browser-based SAML Web SSO flow, in which an SP-initiated or IdP-initiated SAML authentication request causes the Bridge to authenticate the end-user via the OP and return a SAML assertion; and * the Token Exchange variant, in which a Migration Client presents an ID Token to the Bridge's token endpoint and receives a SAML assertion. This profile is defined only for signed SAML assertions issued by the Bridge. The Bridge MUST sign every assertion it constructs under this profile. This profile binds exactly one OP issuer to one Bridge SAML IdP entity. A Bridge serving multiple OPs requires separate Bridge instances, each with its own SAML IdP entity ID and OP binding. The profile is applicable only when the Bridge can resolve each authenticated end-user deterministically to exactly one active Local Account before constructing a SAML assertion; detailed rules are in Section 11. The Token Exchange variant of this profile is defined only for confidential clients; public clients MUST NOT use it. 4. Bridge Binding Rationale This profile uses the SAML SP Entity ID as the primary translation key because SAML pairwise subject identifiers, attribute release policy, and audience restrictions are already bound to that value. The Bridge derives the SP-specific NameID and applies the SP-specific release policy by indexing into the SP-Binding configuration rather than by inspecting the ID Token alone. The primary guarantee against cross-SP assertion injection in the Token Exchange variant is a three-way binding among: * the authenticated Migration Client identity at the Bridge's token endpoint; * the client's registered authorization for a specific saml_sp_entity_id; and * the SP-Binding's authorized OP client_id set, against which the presented ID Token's aud is validated. Together these ensure that only a Migration Client legitimately holding the SP-Binding relationship can drive issuance of an assertion for that SP, and only from an ID Token that was minted for an authorized OP client. The Bridge, acting as the SAML Issuer, is then responsible for constructing the assertion's Recipient, AudienceRestriction, and InResponseTo correctly so that the SP's bearer-confirmation validation succeeds against the target SP. This profile uses Token Exchange [RFC8693] rather than a direct OIDC flow at the Bridge's token endpoint because the input is an already- issued ID Token that proves an end-user authentication event; the Bridge is converting that proof into a SAML assertion for a known SP, not performing a new authentication. The subject_token_type and issued_token_type values disambiguate this Token Exchange use from other Token Exchange profiles. A Bridge MAY support this profile alongside other Token Exchange profiles at the same token endpoint; routing is determined by subject_token_type and requested_token_type. 5. Authorization and Assertion Issuance Model The Bridge MUST NOT treat a valid ID Token as authorization to issue a SAML assertion. The ID Token proves the authentication event; the decision to issue an assertion to a given SP remains a Bridge policy decision, grounded in the SP-Binding configuration established before any assertion request is processed. Before constructing a SAML assertion, the Bridge MUST have an issuance basis that is bound to the resolved Local Account and the target SP-Binding, that authorizes the specific NameID format and attributes to be released, and — for the Token Exchange variant — that authorizes the authenticated Migration Client to request assertions for that SP-Binding. The issuance basis MAY come from static SP-Binding configuration, administrative policy, or any equivalent mechanism established before the assertion is issued. The Bridge MUST NOT create, expand, or infer an issuance basis solely from the presence, validity, or contents of the ID Token. OIDC claims MAY inform an already-established release policy rule, but the policy itself MUST exist independently of the ID Token presented in the current request. The Bridge MUST NOT release all OIDC claims to all SPs by default. Deployments MUST configure explicit attribute release allowlists per SP-Binding. 6. SP-Binding Configuration 6.1. saml_sp_entity_id This document uses the saml_sp_entity_id client metadata parameter defined by [SAML-OIDC-MIGRATION] at the Bridge's token endpoint for the Token Exchange variant. In this profile, saml_sp_entity_id binds a Migration Client to the SP-Binding configuration that the Bridge will use when constructing SAML assertions for that client. When saml_sp_entity_id is present in a client registration at the Bridge's token endpoint: * its value MUST exactly match the SAML SP Entity ID of the target SP; * the Bridge MUST bind the client registration to the corresponding SP-Binding for purposes of NameID derivation and attribute release; * the Bridge MAY allow multiple Migration Clients to share the same saml_sp_entity_id when local policy determines that those clients represent the same SP relationship; * the Bridge MUST reject registration if the value does not correspond to a configured SP-Binding; and * the Bridge MUST ensure that the client authenticated at runtime is one of the clients authorized to use that saml_sp_entity_id. Because the Token Exchange variant is defined only for confidential clients, the Bridge MUST NOT enable this profile for a public client registration. When multiple Migration Clients share the same saml_sp_entity_id, the Bridge MUST apply the same NameID derivation and attribute release policy to all such clients, producing the same NameID for the same resolved Local Account. 6.1.1. Authorizing the saml_sp_entity_id Binding The saml_sp_entity_id binding is security-critical. It determines which SP-Binding the Migration Client inherits and therefore which NameID derivation, attribute release policy, and ACS endpoints apply to assertions the Bridge constructs for that client. Establishing this binding through an unauthenticated or self-asserted client registration request is incompatible with this profile. For statically registered clients, the binding MUST be established through administrative configuration controlled by the authority that operates the Bridge. For clients registered through dynamic client registration [RFC7591], the Bridge MUST require at least one of the following before accepting a registration that sets saml_sp_entity_id: * a software statement [RFC7591] signed by a trust anchor administratively associated with the bound saml_sp_entity_id, where the software statement asserts the requesting party's entitlement to that value; * a registration credential (such as an initial access token, mTLS client certificate, or equivalent) administratively bound to the permitted saml_sp_entity_id value or to a set of values that includes the requested one; or * an equivalent administrative authorization established before the registration request. The Bridge MUST NOT accept a dynamic registration request that sets saml_sp_entity_id solely on the basis of the request's own contents. Anonymous or open dynamic client registration MUST NOT be enabled for clients that bind a saml_sp_entity_id under this profile. The same authorization rules apply to subsequent client configuration updates: a request that adds, removes, or changes saml_sp_entity_id MUST satisfy the same authorization requirements as the original registration. 6.2. Per-SP-Binding Administrative Configuration For the browser-based flow, SP-Binding configuration is maintained administratively at the Bridge, not through dynamic client registration. Each SP-Binding MUST record at minimum: * the SAML SP Entity ID; * one or more registered Assertion Consumer Service (ACS) URLs for that SP; * the NameID format to use for that SP; * the attribute release allowlist for that SP; * the AuthnContextClassRef mapping policy for that SP; * whether SP-initiated flows, IdP-initiated flows, or both are permitted; and * for the Token Exchange variant, the set of OP client_id values whose ID Tokens are authorized to trigger assertion issuance for this SP-Binding. The Bridge MUST validate that any AuthnRequest received for an SP corresponds to a configured SP-Binding before initiating an OIDC flow. IdP-initiated flows SHOULD be disabled by default. When an SP- Binding explicitly permits IdP-initiated flows, the Bridge MUST select the target SP and ACS URL from the SP-Binding's pre-configured values only and MUST employ an anti-CSRF mechanism (such as a signed, time-limited, Bridge-generated launch token) to ensure the flow was initiated by an authorized party. 6.3. NameID Format Policy Each SP-Binding MUST specify the NameID format to use for assertions issued to that SP. The following formats are supported under this profile: * urn:oasis:names:tc:SAML:2.0:nameid-format:persistent: A stable, non-reassignable identifier. Derived as defined in Section 12.1 or Section 12.2. * urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress: An email address derived from the OIDC email claim. MUST only be used when the SP-Binding explicitly permits it and when the email claim is present and permitted for release to this SP. * urn:oasis:names:tc:SAML:2.0:nameid-format:transient: A session- scoped random identifier. The Bridge MUST generate a fresh random value per assertion and MUST NOT persist or reuse it. * urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified: Deployment- defined semantics. MAY be used when the SP-Binding defines the identifier semantics explicitly. The Bridge MUST NOT use urn:oasis:names:tc:SAML:2.0:nameid- format:transient as a NameID format for any SP that requires subject continuity across sessions. If an AuthnRequest includes a NameIDPolicy element, the Bridge MUST verify that the requested format matches or is compatible with the format configured for the SP-Binding. If the requested format is incompatible, the Bridge MUST return a SAML error response and MUST NOT issue an assertion. If NameIDPolicy/@AllowCreate is false and no persisted NameID mapping exists for the resolved Local Account and SP-Binding, the Bridge MUST return a SAML error response with StatusCode urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy and MUST NOT create a new NameID mapping. If a persisted mapping already exists, the Bridge MUST use it regardless of the AllowCreate value. 7. Bridge Metadata 7.1. SAML IdP Metadata The Bridge MUST expose a SAML EntityDescriptor as defined by [SAML2-METADATA] with the Bridge's SAML IdP Entity ID as its entityID. This metadata: * MUST include an IDPSSODescriptor element; * MUST include at least one SingleSignOnService endpoint using the HTTP-POST or HTTP-Redirect binding; * MUST include the key material the Bridge uses to sign SAML assertions in KeyDescriptor elements with use="signing"; * MUST be accessible at an HTTPS URI the Bridge can publish and maintain; and * SHOULD be updated whenever the Bridge's signing key material changes. SAML SPs that federate with the Bridge use this metadata to validate the Bridge's assertion signatures. The Bridge's signing keys published in SAML metadata MUST NOT be confused with the OP's JOSE signing keys published at jwks_uri. 7.2. OAuth Authorization Server Metadata When the Bridge supports the Token Exchange variant, it operates as an OAuth 2.0 Authorization Server and SHOULD publish authorization server metadata as defined by [RFC8414] and [OIDC-DISCOVERY]. 7.2.1. oidc_op_issuer This document defines the oidc_op_issuer authorization server metadata parameter. The oidc_op_issuer value is a string that identifies the OIDC issuer of the OpenID Provider that backs the Bridge. When oidc_op_issuer is present: * it MUST equal the iss claim value in ID Tokens issued by the backing OP; * it MUST identify the OP that is operated by or under the administrative control of the same entity that operates the Bridge; and * it MUST be the value against which the Bridge validates the iss claim of incoming ID Tokens under this profile. The SAML IdP Entity ID of the Bridge and the oidc_op_issuer value identify distinct protocol entities at different layers. The Bridge's SAML IdP Entity ID is used for SAML assertion signing and metadata. The oidc_op_issuer value is used only for OIDC ID Token validation at the Bridge. The issuer value in the Bridge's own authorization server metadata, when published, identifies the Bridge's token endpoint, not the backing OP. Clients using the Token Exchange variant MUST use the Bridge's token endpoint issuer, not the oidc_op_issuer, as the OAuth issuer for that endpoint. 7.3. Capability and Metadata Matrix The following table summarizes the Bridge metadata used to signal capabilities defined by this profile. When the Bridge also publishes saml_idp_entity_id as defined by [SAML-OIDC-MIGRATION], its value MUST equal the Bridge's own SAML IdP Entity ID; this allows Migration Clients to correlate the token endpoint with the SAML IdP facade. +==========+============================+============================+ |Capability|Required metadata |Notes | +==========+============================+============================+ |SAML IdP |SAML EntityDescriptor with |The Bridge's SAML entity ID | |facade |IDPSSODescriptor |and signing keys. | +----------+----------------------------+----------------------------+ |Backing OP|oidc_op_issuer |Identifies the OP whose ID | |binding | |Tokens the Bridge accepts. | +----------+----------------------------+----------------------------+ |Token |grant_types_supported |This profile defines only | |Exchange: |containing |urn:ietf:params:oauth:token-| |ID Token |urn:ietf:params:oauth:grant-|type:id_token as the | |to SAML |type:token-exchange |accepted subject_token_type.| |assertion | | | +----------+----------------------------+----------------------------+ Table 2 A Migration Client MUST NOT assume support for the Token Exchange variant unless grant_types_supported includes urn:ietf:params:oauth:grant-type:token-exchange or an equivalent administrative configuration indicates that support. 7.4. Bridge Key Material SAML assertion signing keys are published and processed through the Bridge's SAML metadata KeyDescriptor elements. If the Bridge also publishes a jwks_uri for its OAuth token endpoint, those JOSE keys MUST be distinct from the SAML signing keys in the Bridge's SAML metadata, even when the underlying key material is the same. Each set of keys MUST be published and validated using the metadata encoding rules of its respective protocol. 7.5. Federation Metadata Coexistence A Bridge deployment operates two protocol stacks in parallel: SAML 2.0 toward the SPs it serves, and OpenID Connect toward the backing OP and (when the Token Exchange variant is offered) toward Migration Clients. The two protocols publish metadata through independent mechanisms that this profile does not unify: SAML 2.0 metadata as EntityDescriptor documents ([SAML2-METADATA]), OAuth/OIDC metadata at the .well-known/oauth-authorization-server and .well-known/openid- configuration endpoints ([RFC8414], [OIDC-DISCOVERY]). Deployments SHOULD observe the following: * The Bridge's SAML IdP entityID, the backing OP's issuer, and the Bridge's own token endpoint issuer (when published) are distinct values used in their own protocol contexts. Incidental string equality among them does not imply they refer to the same protocol entity. * SAML signing keys (published via KeyDescriptor) and JOSE signing keys (published via jwks_uri) rotate on independent schedules. Cross-protocol key reuse is permitted but the keys MUST be discovered through each protocol's own metadata. * When the Bridge also publishes saml_idp_entity_id in its OAuth/ OIDC metadata as defined by [SAML-OIDC-MIGRATION], its value MUST equal the Bridge's own SAML IdP Entity ID, allowing Migration Clients to correlate the token endpoint with the SAML IdP facade. This profile does not alter the discovery flow for either protocol. 8. ID Token Validation This section applies whenever the Bridge directly consumes an OIDC ID Token under this profile, whether in the browser-based flow (after the authorization code exchange) or in the Token Exchange variant. 8.1. Accepted ID Token Inputs The Bridge MUST only accept ID Tokens issued by the OP identified by oidc_op_issuer. ID Tokens from any other issuer MUST be rejected. The Bridge MUST perform full ID Token validation as required by [OIDC-CORE] Section 3.1.3.7, including: * verifying the iss claim matches the oidc_op_issuer value; * verifying the ID Token signature using the OP's JOSE signing keys obtained via the OP's jwks_uri; * verifying the aud claim as described below; * verifying that the exp claim has not passed; * verifying that the iat claim is not unreasonably far in the past, subject to a locally configured freshness window; and * verifying the nonce claim when the ID Token was obtained through the browser-based flow, against the nonce the Bridge included in the OIDC authorization request. For the browser-based flow, the Bridge validates the ID Token it receives after completing the authorization code exchange; the aud claim MUST contain the Bridge's own client_id at the OP. For the Token Exchange variant, the Migration Client obtains an ID Token from the OP using its own OIDC client registration; the aud claim therefore contains the Migration Client's client_id at the OP, not the Bridge's. The Bridge MUST validate the aud claim against the set of authorized OP client_id values configured in the SP-Binding for this purpose. An ID Token whose aud is not in that authorized set MUST be rejected. This set MUST be maintained administratively and MUST NOT be inferred from the presented token. If the ID Token contains multiple audiences, the Bridge MUST require an azp claim and MUST verify that azp identifies an OP client ID authorized for the SP-Binding. 8.2. Freshness and Authentication Time When the ID Token contains an auth_time claim, the Bridge SHOULD verify that the time elapsed since auth_time does not exceed a deployment-configured freshness window before issuing a SAML assertion that represents that authentication event. In the absence of a stricter local policy, a maximum freshness window of 8 hours is RECOMMENDED, consistent with typical enterprise SSO session durations. When the Bridge issues a SAML assertion whose AuthnInstant is derived from the ID Token's auth_time, the freshness window MUST be evaluated against auth_time, not against iat. 8.3. ID Token Claims Required for This Profile The Bridge MUST NOT issue a SAML assertion unless the ID Token contains a sub claim. The sub claim, together with the iss claim, forms the stable input to NameID derivation under Section 12. The Bridge SHOULD require the ID Token to contain auth_time when the SP-Binding requires AuthnInstant to reflect the original end-user authentication event rather than the Bridge's assertion issuance time. If auth_time is absent, the Bridge MAY use the current time as AuthnInstant and SHOULD document this substitution in local policy. This profile does not define processing of encrypted ID Tokens. The Bridge MUST reject any ID Token that cannot be validated as a signed JWT under the rules above. 9. Browser-Based Protocol Flow This section defines the browser-based flow in which a SAML SP initiates authentication, the Bridge authenticates the end-user via the OP, and the Bridge constructs and delivers a SAML assertion to the SP's ACS. 9.1. Flow Overview The browser-based flow proceeds as follows: 1. The end-user accesses the SP. The SP generates a SAML AuthnRequest and redirects the user's browser to the Bridge's SingleSignOnService endpoint. 2. The Bridge receives the AuthnRequest. It MUST validate the request per Section 9.2 before proceeding. 3. The Bridge initiates an OIDC Authorization Code flow by redirecting the browser to the OP's authorization endpoint. The Bridge MUST use the response_type=code flow. The Bridge MUST include a nonce parameter. 4. The OP authenticates the end-user, as required by the Bridge's authorization request. The OP redirects the browser back to the Bridge's OIDC redirect URI with an authorization code. 5. The Bridge exchanges the authorization code for an ID Token and, optionally, an access token at the OP's token endpoint. 6. The Bridge validates the ID Token per Section 8. 7. The Bridge resolves the end-user to a Local Account per Section 11. 8. The Bridge constructs a SAML assertion per Section 14 and wraps it in a SAML Response. 9. The Bridge delivers the SAML Response to the SP's ACS URL via the HTTP-POST binding. The Bridge MUST populate Response/@InResponseTo with the AuthnRequest/@ID when the flow is SP-initiated. 9.2. AuthnRequest Processing Upon receiving a SAML AuthnRequest, the Bridge MUST: 1. validate the AuthnRequest signature against the SP-Binding's registered signing key. The Bridge MUST validate AuthnRequest signatures in a manner resistant to XML Signature Wrapping; see Section 16.2.1. An unsigned AuthnRequest MUST be rejected unless the SP-Binding explicitly permits unsigned requests for a documented reason and the deployment threat model has accepted the associated risks; 2. verify that AuthnRequest/Issuer corresponds to a configured SP- Binding and that the SP-Binding permits the binding (HTTP- Redirect or HTTP-POST) over which the request was received; 3. verify that AuthnRequest/@Destination, when present, exactly matches the Bridge's SingleSignOnService endpoint URL for the binding used; 4. verify that AuthnRequest/@IssueInstant is within a deployment- configured freshness window (in the absence of stricter local policy, 5 minutes is RECOMMENDED). Requests outside the window MUST be rejected; 5. track AuthnRequest/@ID values and reject any request whose ID has been processed within the freshness window; 6. if NameIDPolicy is present, verify that the requested format is compatible with the SP-Binding's configured NameID format; 7. if RequestedAuthnContext is present, record the requested AuthnContextClassRef values and the Comparison attribute for use in constructing the AuthnContext of the issued assertion. This profile supports Comparison values of exact and minimum only; if Comparison is maximum or better, the Bridge MUST return a SAML error response with StatusCode urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext. For minimum, the Bridge MUST NOT issue an assertion whose AuthnContextClassRef has a lower assurance level than the requested class under the SP-Binding's ACR ordering policy, and MUST return a SAML error if this cannot be satisfied; 8. if @ForceAuthn is true, the Bridge MUST cause a fresh end-user authentication at the OP by including prompt=login (or, when an exact recency bound is required, max_age=0) in the OIDC authorization request; 9. if @IsPassive is true, the Bridge MUST include prompt=none in the OIDC authorization request and MUST return a SAML error response with StatusCode urn:oasis:names:tc:SAML:2.0:status:NoPassive if the OP indicates that interaction would be required; 10. record AuthnRequest/@ID for inclusion in Response/@InResponseTo and SubjectConfirmationData/@InResponseTo; and 11. if AssertionConsumerServiceURL is present, verify that its value exactly matches one of the registered ACS URLs in the SP-Binding configuration or in the SP's SAML metadata. If no match is found, the Bridge MUST return a SAML error response and MUST NOT proceed. If absent, use the default ACS URL from the SP-Binding configuration. If AssertionConsumerServiceIndex is present, the Bridge MUST resolve it against the SP's SAML metadata AssertionConsumerService entries indexed by index. AssertionConsumerServiceURL and AssertionConsumerServiceIndex MUST NOT both be present. The Bridge MUST reject AuthnRequest messages that reference SP entities without a configured SP-Binding. The Bridge MUST NOT issue assertions to SPs that have not been administratively registered. The Bridge MAY preserve the AuthnRequest's RelayState value through the OIDC flow and reflect it on the SAML Response POST to the SP's ACS, subject to the length limit in [SAML2-BINDINGS] (80 bytes). The Bridge MUST NOT treat RelayState as carrying any authorization or identity semantics. 9.3. OIDC Authorization Request When initiating the OIDC Authorization Code flow, the Bridge: * MUST include scope=openid; * MUST include a fresh, unpredictable nonce value bound to the SAML AuthnRequest context (for example, by computing it as an HMAC over the request ID under a Bridge-held key); * MUST include a state value that is unpredictable to third parties and bound to the SAML AuthnRequest context, so the returned authorization response can be matched to the original SAML request and cannot be spliced with an unrelated request; * MUST use PKCE [RFC7636] with the S256 code challenge method, in accordance with current OAuth security best practice [RFC9700]; * SHOULD request the auth_time claim in the ID Token, either via the claims parameter or by including max_age=0 when an exact auth_time value is required; * MAY translate RequestedAuthnContext values from the AuthnRequest into acr_values in the OIDC authorization request, when local policy defines this translation; * SHOULD request, via the scope and claims parameters, the claims needed to satisfy the SP-Binding's attribute release policy and NameID derivation; and * MUST translate AuthnRequest/@ForceAuthn and @IsPassive into the corresponding OIDC parameters as described in Section 9.2. The Bridge MUST NOT pass the SAML SP Entity ID to the OP in a way that allows the OP to alter its authentication behavior based on which SP initiated the request, unless local policy explicitly authorizes such conditioning. See Section 17 for the related correlation risk. 9.4. Error Handling If the OP returns an authorization error, the Bridge MUST return a SAML error Response to the SP's ACS URL. The Bridge MUST NOT expose the OP's internal error codes or descriptions to the SP. Common OIDC error codes SHOULD be mapped to SAML status codes as follows: * login_required or interaction_required → urn:oasis:names:tc:SAML:2.0:status:NoPassive (when the SP requested passive authentication) or urn:oasis:names:tc:SAML:2.0:status:AuthnFailed otherwise; * consent_required or access_denied → urn:oasis:names:tc:SAML:2.0:status:RequestDenied; * temporarily_unavailable or server_error → urn:oasis:names:tc:SAML:2.0:status:Responder; and * any other OP error → urn:oasis:names:tc:SAML:2.0:status:Responder. If ID Token validation fails, the Bridge MUST return a SAML error Response and MUST NOT issue an assertion. 10. Token Exchange: ID Token to SAML Assertion This section defines how a Migration Client can use OAuth 2.0 Token Exchange to obtain a SAML 2.0 assertion from an OIDC ID Token. A Bridge supporting this pattern MUST support Token Exchange as defined by [RFC8693]. If the Bridge publishes metadata, its grant_types_supported metadata SHOULD include urn:ietf:params:oauth:grant-type:token-exchange. Under this pattern, the Migration Client obtains an ID Token from the OP by any OIDC flow permitted by local policy, then presents that ID Token to the Bridge's token endpoint. The Bridge validates the ID Token, resolves the end-user, derives the SP-specific NameID, maps claims to attributes, constructs a SAML assertion for the SP bound to the client's saml_sp_entity_id, and returns the signed SAML assertion in the Token Exchange response. 10.1. Request The client makes a Token Exchange request to the Bridge's token endpoint using the parameters described below. The following non-normative example requests a SAML assertion from an OIDC ID Token using private_key_jwt client authentication: POST /token HTTP/1.1 Host: bridge.example.com Content-Type: application/x-www-form-urlencoded grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aid_token &subject_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ... &requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Asaml2 &client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer &client_assertion=eyJhbGciOiJSUzI1NiJ9... The request parameters are summarized below: +======================+=============+============================+ | Parameter | Requirement | Summary | +======================+=============+============================+ | grant_type | REQUIRED | Identifies the request as | | | | OAuth 2.0 Token Exchange. | +----------------------+-------------+----------------------------+ | subject_token | REQUIRED | Carries the OIDC ID Token | | | | issued by the backing OP. | +----------------------+-------------+----------------------------+ | subject_token_type | REQUIRED | Identifies the subject | | | | token as an OIDC ID Token. | +----------------------+-------------+----------------------------+ | requested_token_type | REQUIRED | Requests a SAML 2.0 | | | | assertion. | +----------------------+-------------+----------------------------+ Table 3 grant_type: REQUIRED. The value urn:ietf:params:oauth:grant-type:token-exchange. subject_token: REQUIRED. The serialized OIDC ID Token issued by the OP identified by oidc_op_issuer. The ID Token MUST be submitted in its compact serialization form as defined by [OIDC-CORE]. The Bridge MUST validate this token per Section 8. subject_token_type: REQUIRED. The value urn:ietf:params:oauth:token-type:id_token. requested_token_type: REQUIRED. The value urn:ietf:params:oauth:token-type:saml2. [RFC8693] marks requested_token_type as OPTIONAL at the Token Exchange protocol level. This profile narrows that rule: an absent or unsupported requested_token_type MUST be rejected with invalid_request. The Bridge derives the target SP from the authenticated client's registered saml_sp_entity_id. This profile does not define use of the audience parameter; clients MUST NOT send it. Only confidential clients can use this profile. Client authentication at the Bridge's token endpoint uses the client's registered OAuth 2.0 client authentication method. The authenticated client MUST be a confidential client registered with a saml_sp_entity_id corresponding to a configured SP-Binding. Asymmetric-key client authentication methods such as private_key_jwt and tls_client_auth SHOULD be preferred over client_secret_basic and client_secret_post, consistent with current OAuth security guidance [RFC9700]. 10.2. Bridge Processing Upon receiving the request, the Bridge MUST: 1. authenticate the client in accordance with its registered client authentication method; 2. verify that the authenticated client has a registered saml_sp_entity_id corresponding to a configured SP-Binding; 3. validate the ID Token as described in Section 8; 4. verify that the requested_token_type is urn:ietf:params:oauth:token-type:saml2; 5. resolve the end-user to a Local Account as described in Section 11; 6. derive the SP-specific NameID according to Section 12; 7. map claims to SAML attributes according to Section 13 and apply the SP-Binding's attribute release policy; and 8. construct and sign the SAML assertion per Section 14 and return it in the Token Exchange response. The Bridge MUST reject the request if the ID Token iss claim does not match oidc_op_issuer. The Bridge MUST reject the request if the ID Token aud claim does not match an authorized OP client_id configured in the SP-Binding per Section 8.1. The Bridge MUST reject the request if the ID Token does not contain a jti claim, or if the (iss, jti) pair has already been accepted within the token's validity window. The Bridge MUST reject the request if subject resolution yields no Local Account, more than one candidate, or a Local Account that is disabled, suspended, deprovisioned, or otherwise not eligible. 10.3. Successful Response For a successful request, the Bridge MUST return a Token Exchange response as defined by [RFC8693] with: * issued_token_type set to urn:ietf:params:oauth:token-type:saml2; * access_token containing the base64url-encoded SAML assertion, as defined in Section 5 of [RFC4648], without line wrapping and without padding characters (=); and * token_type set to N_A. The Bridge SHOULD include expires_in reflecting the SAML assertion's SubjectConfirmationData/@NotOnOrAfter duration. The following non-normative example shows a successful response: { "issued_token_type": "urn:ietf:params:oauth:token-type:saml2", "access_token": "PHNhbWwyOkFzc2VydGlvbi4uLjwvc2FtbDI6QXNzZXJ0aW9uPg", "token_type": "N_A", "expires_in": 300 } [RFC8693] uses the access_token response member to carry all issued token types. Clients MUST interpret the access_token value as a base64url-encoded SAML 2.0 assertion when issued_token_type is urn:ietf:params:oauth:token-type:saml2. 10.4. Error Response If the request is malformed, the Bridge MUST return an error response as defined by [RFC6749] and [RFC8693]. The Bridge MUST use invalid_request for malformed or internally inconsistent Token Exchange parameters, including an ID Token that is invalid, expired, issued by an unexpected OP, addressed to a different audience, or otherwise unacceptable under this profile. The Bridge SHOULD use: * unauthorized_client when the authenticated client is not permitted to use the bound SP-Binding or to request assertions for the bound SP Entity ID; * invalid_request when the ID Token lacks a jti claim, the (iss, jti) pair has been previously accepted, the ID Token aud is not in the SP-Binding's authorized set, subject resolution fails, the ID Token contains no usable sub claim, or the Bridge cannot derive a NameID for the target SP. 11. Local Subject Resolution Before deriving a NameID or constructing a SAML assertion under this profile, the Bridge MUST resolve the ID Token's sub and iss claims to exactly one active Local Account. The Bridge resolves the Local Account using the pair (iss, sub) from the ID Token. This pair is the stable input for subject resolution; the Bridge MUST NOT treat any other ID Token claim as a primary resolution key. The Bridge MAY use other claims such as email as supplemental hints to locate an existing Local Account only when local policy has already bound that supplemental value for the trusted OP to exactly one Local Account. If the email claim is present in the ID Token, the Bridge MUST treat it as a mutable account attribute, not as a stable subject identifier. It MUST NOT by itself establish a new Local Account linkage or a new NameID continuity mapping. This document does not require or define just-in-time provisioning. If a deployment performs account creation or activation based on a validated ID Token, that behavior is outside this profile and MUST complete before the Bridge applies NameID derivation and assertion construction. If resolution yields no Local Account, more than one candidate Local Account, or a Local Account that is disabled, suspended, deprovisioned, or otherwise not eligible to authenticate, the Bridge MUST fail the profile operation and MUST NOT issue a SAML assertion. Once a NameID continuity mapping has been established for a resolved Local Account and SP-Binding pair, the Bridge MUST continue to resolve the same (iss, sub) input to the same NameID for that SP- Binding unless an authorized administrative remapping occurs. 12. NameID Construction The SAML NameID in the Subject element of every assertion issued under this profile is the primary subject continuity point for SAML SPs. The Bridge MUST issue a NameID value that is stable for the SP- Binding and that is consistent with the SP's prior SAML deployment expectations. 12.1. Pairwise NameID Construction When the SP-Binding requires a pairwise NameID (urn:oasis:names:tc:SAML:2.0:nameid-format:persistent with SP- specific semantics), the Bridge MUST determine the NameID value using the first applicable rule: 1. If the Bridge already has a persisted pairwise NameID mapping for the same resolved Local Account and SP-Binding, it MUST reuse that mapping. 2. If no persisted mapping exists, the Bridge MUST derive a deterministic, non-reassignable pairwise identifier by combining the (iss, sub) pair from the ID Token, the SAML SP Entity ID, and a deployment-specific salt using a collision-resistant method. A suitable derivation function is: NameID = base64url( SHA-256( issuer || ":" || sub || ":" || sp_entity_id || ":" || salt ) ) where issuer and sub are the iss and sub values from the ID Token, sp_entity_id is the SAML SP Entity ID from the SP-Binding, and salt is a deployment-specific secret value maintained by the Bridge. The Bridge MUST persist the resulting NameID mapping for future use. The salt value MUST be at least 128 bits of entropy and MUST be kept confidential. Compromise of the salt allows derivation of NameID values from known (iss, sub, sp_entity_id) inputs, which could expose cross-SP correlation. The Bridge MUST NOT expose a pairwise NameID value to any SP other than the SP for whose SP-Binding it was derived. 12.2. Public NameID Construction When the SP-Binding uses a public or issuer-scoped persistent NameID (i.e., the same NameID value is used for the same user regardless of which SP receives the assertion), the Bridge MUST determine the NameID value using the first applicable rule: 1. If the Bridge already has a persisted public NameID mapping for the same resolved Local Account, it MUST reuse that mapping. 2. If no persisted mapping exists, the Bridge MUST derive a deterministic, non-reassignable public identifier from the (iss, sub) pair alone, without SP-specific input, using a collision- resistant method. The Bridge MUST persist the resulting mapping. 12.3. EmailAddress NameID When the SP-Binding specifies urn:oasis:names:tc:SAML:1.1:nameid- format:emailAddress, the Bridge MUST use the email claim from the ID Token as the NameID value, subject to the following conditions: * the SP-Binding MUST explicitly permit use of the email address format; * the email claim MUST be present and permitted for release to this SP; * the email_verified claim MUST be true, unless the SP-Binding explicitly permits unverified email addresses for a documented reason; * the Bridge MUST include Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" in the NameID element; and * the Bridge MUST NOT use this value as the key for persistent subject mapping, because email addresses are mutable. 12.4. Transient NameID When the SP-Binding specifies urn:oasis:names:tc:SAML:2.0:nameid- format:transient, the Bridge MUST generate a fresh, unpredictable random value per assertion. The Bridge MUST NOT persist or reuse transient NameID values. Transient NameIDs MUST only be used for SPs that explicitly require them and that do not rely on subject continuity. 12.5. Common Rules For all NameID formats: * before issuing any chosen or derived value as NameID, the Bridge MUST ensure it conforms to the constraints of the selected NameID format as defined by [SAML2-CORE]; * the Format attribute MUST be present and MUST match the format configured in the SP-Binding; * when using the persistent format with SP-specific semantics, the Bridge MUST set SPNameQualifier to the SAML SP Entity ID; * when using the persistent format with issuer-scoped semantics, the Bridge MUST set NameQualifier to its own SAML IdP Entity ID; and * the Bridge MUST NOT use a transient NameID for any SP that requires subject continuity across sessions. 13. Attribute and Authentication Context Mapping The mappings in this section govern how OIDC claims are translated into SAML attributes and authentication context for the issued assertion. 13.1. Authentication Context Mapping The Bridge MUST populate an AuthnStatement in every issued assertion. The AuthnStatement MUST include: * AuthnInstant: the time of the end-user's authentication, derived as follows: - if the ID Token contains an auth_time claim, AuthnInstant MUST be set to that value, converted from a NumericDate (seconds since epoch) to an XML dateTime value in UTC; - if auth_time is absent from the ID Token and the SP-Binding permits it, AuthnInstant MAY be set to the Bridge's assertion issuance time; and - the Bridge MUST NOT set AuthnInstant to the time of the Token Exchange or OIDC token issuance event unless that event is confirmed to represent the actual end-user authentication. * SessionIndex: OPTIONAL. The Bridge MAY populate SessionIndex from the OIDC sid claim when present and when the SP-Binding requires session continuity for logout support. If the raw sid value is not suitable as a SAML SessionIndex (e.g., it is not unique within the Bridge's SAML issuer), the Bridge MUST derive and persist a Bridge-scoped session identifier bound to the OIDC session. The AuthnContext element MUST include an AuthnContextClassRef. The Bridge MUST determine this value as follows: * if the SP-Binding defines an explicit ACR-to-AuthnContextClassRef mapping table, the Bridge MUST apply that mapping and use the mapped value; * if the ID Token contains an acr claim, the SP-Binding does not define an explicit mapping, and the SP-Binding explicitly permits passthrough of unmapped ACR values, the Bridge MAY use the acr value as AuthnContextClassRef only when that exact value appears in the SP-Binding's configured ACR allowlist; the Bridge MUST NOT pass through arbitrary acr strings as AuthnContextClassRef values; * if the acr claim is absent or cannot be resolved to a configured value, the Bridge MUST use urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified unless the SP- Binding defines a different default; and * the Bridge MUST NOT produce an AuthnContextClassRef that asserts higher assurance than the OP's authenticated event warrants. The amr claim [RFC8176] in an ID Token lists authentication method references and does not map directly to a SAML AuthnContextClassRef. The Bridge: * MUST NOT copy amr values directly into AuthnContextClassRef; * MAY reflect amr content in an extension element within AuthnContext when the SP-Binding defines such an extension and the SP is known to process it; and * MUST NOT overstate authentication assurance based on amr values alone. 13.2. Attribute Claim Mapping When the issued assertion includes an AttributeStatement, the Bridge MUST apply the SP-Binding's attribute release allowlist before populating any attribute. The Bridge MUST NOT include attributes that are not on the allowlist for the target SP-Binding, regardless of which claims are present in the ID Token. Common mappings from OIDC claims to SAML attributes: * given_name → givenName (attribute Name urn:oid:2.5.4.42) * family_name → sn (attribute Name urn:oid:2.5.4.4) * name → displayName (attribute Name urn:oid:2.16.840.1.113730.3.1.241) * email → mail (attribute Name urn:oid:0.9.2342.19200300.100.1.3) * preferred_username → uid (attribute Name urn:oid:0.9.2342.19200300.100.1.1) * phone_number → telephoneNumber (attribute Name urn:oid:2.5.4.20) These mappings are common; deployments SHOULD configure a site- specific mapping table in each SP-Binding that maps OIDC claim names to the attribute Name and NameFormat expected by the target SP. If the SP-Binding specifies a NameFormat for attributes, the Bridge MUST use that NameFormat when populating Attribute elements. If no NameFormat is configured, the Bridge SHOULD use urn:oasis:names:tc:SAML:2.0:attrname-format:uri when the attribute Name is a URI (such as an OID-based name), and urn:oasis:names:tc:SAML:2.0:attrname-format:basic otherwise. Attribute processing MUST follow these rules: * a single OIDC claim value maps to a single AttributeValue element; * a JSON array claim value MAY map to multiple AttributeValue elements in the same Attribute when the SP-Binding permits multi- valued attributes; * boolean OIDC claims SHOULD map to string AttributeValue elements with the value "true" or "false" unless the SP-Binding specifies a different encoding; * the Bridge MUST NOT expose the sub claim as an Attribute element; the OIDC subject is represented exclusively through the NameID; and * the Bridge MUST NOT include AttributeStatement at all if no attributes are permitted for release to the target SP. If the email_verified claim is false or absent, the Bridge MUST NOT emit any attribute that implies the email address has been verified unless the SP-Binding explicitly overrides this. The Bridge MUST NOT infer verification status from the presence of a phone_number claim. 13.3. Session Validity Bound The SAML assertion lifetime (governed by Conditions/@NotOnOrAfter and SubjectConfirmationData/@NotOnOrAfter) is a short-lived artifact independent of the underlying OIDC session. It MUST NOT be derived from the ID Token's exp claim, which reflects only token validity rather than session lifetime. The SAML SessionNotOnOrAfter attribute in AuthnStatement, when emitted, represents the end of the authenticated session. The Bridge SHOULD set SessionNotOnOrAfter to the earliest of: the session_expiry claim defined by OpenID Connect Enterprise Extensions [OIDC-ENTERPRISE-EXTENSIONS] when present, the OIDC session expiry as determined from the refresh token lifetime, the OP's session management state, or the SP-Binding's configured maximum session duration. If none of these can be determined, the Bridge SHOULD omit SessionNotOnOrAfter rather than guess. 14. SAML Assertion Construction The Bridge MUST construct a SAML 2.0 Assertion element conformant with [SAML2-CORE]. This section specifies the required and conditional elements. 14.1. Required Elements The Bridge MUST include the following in every issued assertion: Issuer: The Bridge's SAML IdP Entity ID. This value MUST match the entityID in the Bridge's SAML metadata. Subject: A Subject element containing: * a NameID element constructed per Section 12; and * a SubjectConfirmation element with Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" and a SubjectConfirmationData element as specified in Section 14.2. Conditions: A Conditions element containing: * NotBefore: set to the Bridge's assertion issuance time, minus any permitted clock skew allowance; * NotOnOrAfter: set to a short interval after issuance. The Bridge SHOULD set this to no more than 5 minutes from the assertion's IssueInstant; * at least one AudienceRestriction element containing the SAML SP Entity ID as the sole Audience value; and * a OneTimeUse condition SHOULD be included to prevent replay of the assertion by the SP. AuthnStatement: An AuthnStatement element constructed per Section 13.1. AttributeStatement: An AttributeStatement element, when at least one attribute is permitted for release to the target SP-Binding. Signature: A ds:Signature element over the Assertion element using the Bridge's SAML signing key. The Bridge MUST sign the Assertion element, not only the enclosing Response element. The signature MUST use RSA-SHA-256 or a stronger algorithm. Signature algorithms using SHA-1 as the message digest MUST NOT be used, including RSA with SHA-1 (http://www.w3.org/2000/09/xmldsig#rsa- sha1), DSA with SHA-1 (http://www.w3.org/2000/09/xmldsig#dsa- sha1), and ECDSA with SHA-1 (http://www.w3.org/2001/04/xmldsig- more#ecdsa-sha1). 14.2. SubjectConfirmationData The SubjectConfirmationData element MUST include: * Recipient: the ACS URL of the target SP to which the assertion will be delivered. For the browser-based flow, this is the ACS URL from the AuthnRequest (if valid per the SP-Binding) or the default ACS URL from the SP-Binding. For the Token Exchange variant, this is the ACS URL configured in the SP-Binding for the authenticated client's saml_sp_entity_id; * NotOnOrAfter: a short expiration time for the subject confirmation, MUST NOT exceed the Conditions/@NotOnOrAfter value and SHOULD be set to the same value; and * InResponseTo: for SP-initiated browser-based flows, MUST be set to the AuthnRequest/@ID. For IdP-initiated flows and the Token Exchange variant, this attribute SHOULD be omitted. 14.3. SAML Response Wrapper The Bridge MUST wrap the signed Assertion in a SAML Response element for delivery via the HTTP-POST binding in the browser-based flow. The Response MUST include: * ID: a fresh, unique identifier generated by the Bridge; * IssueInstant: the current time; * Issuer: the Bridge's SAML IdP Entity ID, as a child element of Response; * Destination: the ACS URL of the target SP; * InResponseTo: the AuthnRequest/@ID, for SP-initiated flows; * Status/StatusCode/@Value: urn:oasis:names:tc:SAML:2.0:status:Success; and * the signed Assertion as a direct child element. The Bridge SHOULD also sign the Response element in addition to signing the enclosed Assertion. When both are signed, the Response signature provides an additional integrity layer for the SP's ACS processing. For the Token Exchange variant, no Response wrapper is used; the Bridge returns only the signed Assertion in base64url encoding. 14.4. Assertion ID and Replay Prevention The Bridge MUST generate a unique, unpredictable Assertion/@ID for every issued assertion. The Bridge SHOULD include a OneTimeUse condition. When OneTimeUse is included, the Bridge SHOULD communicate this to SPs as a signal that the assertion is not intended to be submitted more than once. The Bridge MUST maintain the ability to detect and reject attempts to reuse a previously accepted assertion at its own endpoints. For the Token Exchange variant, the Bridge MUST require the submitted ID Token to contain a jti claim and MUST reject any ID Token that lacks one. The Bridge MUST track consumed jti values per iss and MUST reject any Token Exchange request that presents an ID Token whose (iss, jti) pair has been previously accepted, until the ID Token's exp has passed. 15. Session Termination and Revocation An assertion issued under this profile represents a moment in the underlying OIDC-authenticated session. The OIDC session may end at the OP before the assertion's SessionNotOnOrAfter value would otherwise expire, and the SP's own SAML session is independent of either. This section defines how the Bridge connects OIDC-side session signals to the SAML sessions it has authorized. SAML Single Logout (SLO) and OpenID Connect logout are not equivalent mechanisms, and this profile does not guarantee parity between them. SAML SLO is a multi-party protocol coordinated by the SAML IdP across all participating SPs; OIDC logout (front-channel, back-channel, and RP-Initiated Logout) targets OIDC clients individually. The operational semantics, failure modes, and trust requirements differ. Deployments that need coordinated logout across both protocols MUST design that coordination outside this profile; this profile defines only the Bridge's local obligations once it has learned that the underlying OIDC session has ended. 15.1. Session Binding The Bridge MUST maintain a session correlation record binding each issued SAML session to the OIDC session that authorized it. When the ID Token contains a sid claim, the Bridge MUST use that value as the OIDC session identifier in the correlation record. When sid is absent, the Bridge MUST establish its own internal session identifier at the time of the authorization code exchange (browser- based flow) or assertion issuance (Token Exchange variant) and bind it to the SAML sessions it subsequently creates. When sid is absent, logout propagation from the OP to the Bridge depends on the Bridge detecting token revocation or expiry through the standard refresh flow rather than through a push notification. Deployments that rely on this fallback MUST document the bound between OP-side termination and Bridge detection in local policy. 15.2. Session Termination The Bridge MUST treat the earlier of the following as the operative end of the OIDC-authorized session for a given issued assertion: * the assertion's SessionNotOnOrAfter value, when present; * any authoritative signal that the underlying OIDC session has ended (a back-channel or front-channel logout notification from the OP per [OIDC-BC-LOGOUT] and [OIDC-FC-LOGOUT], an OP revocation observed through refresh, or an equivalent administrative signal); or * a Bridge policy decision to terminate the session (administrative action, risk-based revocation, etc.). When the OIDC-authorized session has ended, the Bridge: * MUST treat any further authentication request that relies on that OIDC session as requiring reauthentication; * SHOULD propagate the termination to SPs whose SAML sessions are bound to that OIDC session, using SAML SLO when supported (see Section 15.3); and * MAY rely on assertion expiry alone when SLO is not supported by the affected SP. This document does not define how the Bridge discovers OP-side session termination beyond the mechanisms named above. 15.3. SAML Single Logout Support for SAML Single Logout (SLO) is OPTIONAL. When the Bridge supports SLO: * the Bridge's SAML metadata SHOULD include a SingleLogoutService endpoint; * upon receiving a SAML LogoutRequest from an SP, the Bridge MUST validate the request signature against the SP's key material in the SP-Binding configuration and MUST terminate the SAML session with the requesting SP; * the Bridge SHOULD propagate the logout to the OP by initiating RP- Initiated Logout or revoking the relevant tokens; * the Bridge SHOULD propagate the logout to other SPs sharing the same OIDC session by sending LogoutRequest messages to their SLO endpoints; * the Bridge MUST return a LogoutResponse to the initiating SP even if propagation to other parties fails; and * the Bridge MUST tolerate partial propagation failures gracefully and MUST NOT refuse to respond to the initiating SP because a downstream SLO request failed. 16. Security Considerations 16.1. Threat Model This profile assumes the following: * The OP and the Bridge are operated by, or under the administrative control of, the same authority (see Section 3). They share a trust boundary, but are network-separated components that communicate through their respective protocols. * SAML SPs trust the Bridge as a SAML IdP under their existing SAML federation configuration. The Bridge does not establish new federation trust; it inherits the trust the SP already has with the Bridge's SAML IdP entity. * Migration Clients (Token Exchange variant) are confidential clients. Public clients are excluded by Section 6.1. * saml_sp_entity_id binding for a Migration Client is established under the authorization rules in Section 6.1.1; self-asserted dynamic registration of that value is disallowed. The following attacker capabilities are in scope: * An attacker who obtains an ID Token in transit (through cross-site scripting, intermediary compromise, log leakage, or similar). The Token Exchange three-way binding (Section 4), the aud validation against the SP-Binding's authorized OP client set (Section 8.1), and the jti-based replay rules (Section 14.4) limit what such a token enables. * An attacker who attempts to register or modify a Migration Client with an saml_sp_entity_id they are not authorized to bind. The registration authorization rules (Section 6.1.1) require out-of- band authorization. * An attacker who forges, replays, or manipulates a SAML AuthnRequest toward the Bridge. The signature, Destination, IssueInstant freshness, and ID-replay rules in Section 9.2, together with the ACS-URL allowlist, address these. * An attacker who attempts XML Signature Wrapping against a signed AuthnRequest or LogoutRequest. The XSW rules below address this. * An attacker who attempts to splice an OIDC authorization response into a different SAML request context. The state/nonce binding and PKCE requirement in Section 9.3 address this. * An attacker who compromises the Bridge's refresh token at the OP. Such an attacker could obtain fresh ID Tokens and drive Bridge assertion issuance without further OP user interaction; see Section 16.9. The following are out of scope and remain the deployment's responsibility: * Compromise of the OP or the Bridge themselves (including their signing keys). * Side channels, traffic analysis, and other infrastructure-level threats not specific to this profile. * End-user account compromise upstream of the OP. 16.2. SAML Signature Risks 16.2.1. XML Signature Wrapping on Incoming SAML XML Signature Wrapping (XSW) attacks allow an adversary to manipulate a SAML document by inserting a malicious element while retaining a valid signature on a benign element elsewhere in the document structure. The Bridge consumes signed AuthnRequest and LogoutRequest messages from SPs and MUST validate those signatures in a manner resistant to XSW. Specifically: * when validating a signed AuthnRequest, the Bridge MUST verify that the element referenced by the signature's Reference/@URI is the same AuthnRequest element being processed and is the unique signed element in the document being acted upon; * the same rule applies to signed LogoutRequest messages received at the Bridge's SLO endpoint. The Bridge MUST reject any document structure where these bindings cannot be confirmed unambiguously. Implementations SHOULD use established SAML processing libraries that have been tested against known XSW attack patterns. 16.2.2. Outgoing Assertion Signature Algorithms The Bridge MUST sign every issued assertion with RSA-SHA-256 or a stronger algorithm. Signature algorithms using SHA-1 MUST NOT be used, including RSA with SHA-1 (http://www.w3.org/2000/09/ xmldsig#rsa-sha1), DSA with SHA-1 (http://www.w3.org/2000/09/ xmldsig#dsa-sha1), and ECDSA with SHA-1 (http://www.w3.org/2001/04/ xmldsig-more#ecdsa-sha1). Beyond SHA-1, deployments SHOULD reject other algorithms whose security margins are no longer adequate by current cryptographic guidance, including MD5-based digests, RSA signatures with key sizes below 2048 bits, and elliptic curves with effective security below 128 bits. The Bridge SHOULD track current guidance from bodies such as NIST and ENISA and adjust its minimum-algorithm policy accordingly. The Bridge MUST keep its SAML signing keys confidential. Compromise of a Bridge signing key allows an attacker to forge assertions for any SP that trusts the Bridge. The Bridge MUST publish its signing keys in its SAML metadata KeyDescriptor elements with use="signing". When the Bridge rotates its signing key, it MUST publish both the old and new keys in its metadata during a transition period long enough for SPs to refresh their cached metadata. In the absence of stricter local policy, a transition period of at least 24 hours, or at least one complete SP metadata refresh cycle if SPs are known to cache metadata for longer, is RECOMMENDED. 16.3. ID Token Validation Risks The Bridge MUST perform complete ID Token validation as specified in Section 8. In particular: * the Bridge MUST verify the ID Token signature using keys obtained from the OP's jwks_uri, not from locally cached or manually configured JOSE keys, unless a pre-approved key pinning arrangement exists; * the Bridge MUST validate aud according to the rules in Section 8.1: the Bridge's own client_id for the browser-based flow, and an SP-Binding-authorized OP client_id for the Token Exchange variant; and * the Bridge MUST NOT rely on the validity of an ID Token as evidence that the OP has authorized the issuance of a SAML assertion to any particular SP. The issuance basis described in Section 5 is a separate Bridge policy decision. The Bridge MUST enforce the freshness window described in Section 8.2. Accepting a stale ID Token would allow assertion issuance to outlive the underlying OIDC session. 16.4. OIDC Authorization Response Splicing A browser-based attacker may attempt to splice an authorization response obtained in one context onto a SAML AuthnRequest issued by the Bridge in a different context. The Bridge MUST prevent this by: * binding the OIDC state and nonce values to the SAML AuthnRequest ID it is processing, as required by Section 9.3; * using PKCE [RFC7636] with S256 so that an intercepted authorization code cannot be exchanged by another party at the OP's token endpoint; and * validating on the authorization response that the returned state matches the value the Bridge issued for the SAML AuthnRequest being completed. 16.5. Metadata Fetching and SSRF The Bridge fetches the OP's discovery document and JOSE key set to validate ID Tokens. It may also fetch SP SAML metadata to discover ACS URLs and verification keys. Fetches whose target URI is influenced by registration data carry a Server-Side Request Forgery (SSRF) risk against internal services. Implementations MUST restrict fetches to URIs that use the HTTPS scheme and MUST NOT follow redirects to non-HTTPS URIs. Deployments SHOULD additionally constrain permitted fetch targets to a pre-approved allowlist of hosts. The OP discovery URI and jwks_uri are administratively configured at the Bridge and are not exposed to dynamic registration under this profile. 16.6. Replay and Bearer Risks The Bridge MUST include short assertion lifetimes and SHOULD include a OneTimeUse condition in every issued assertion. The Bridge MUST set SubjectConfirmationData/@NotOnOrAfter to no more than the assertion's Conditions/@NotOnOrAfter. The Bridge SHOULD use assertion lifetimes of 5 minutes or less. SPs that receive assertions from the Bridge MUST implement their own replay detection for the assertions they accept; the Bridge cannot guarantee that an assertion will not be replayed after delivery. For the Token Exchange variant, the Bridge MUST reject duplicate Token Exchange requests that present the same ID Token within its validity window, as described in Section 14.4. Bridges deployed across multiple nodes MUST share jti replay state across all nodes or use equivalent distributed coordination. Per-node replay stores are insufficient. Issued assertions are bearer artifacts. Holder-of-Key SubjectConfirmation is out of scope for this profile. Deployments that require sender-constrained SAML credentials MUST establish that constraint outside this profile. 16.7. Binding Security The saml_sp_entity_id binding and the SP-Binding configuration are security-critical. If an unauthorized party can register or manipulate an saml_sp_entity_id value at a Migration Client, it inherits the SP-Binding's NameID derivation, attribute release policy, and ACS endpoints. The Bridge MUST protect registration and administrative mapping according to Section 6.1.1. Anonymous or open dynamic client registration MUST NOT be permitted to set this value. When multiple Migration Clients share the same saml_sp_entity_id, the Bridge is intentionally treating them as the same SP-Binding context. Accidental sharing can expose the same pairwise NameID and attribute set to clients that should have been isolated. Deployments MUST treat such sharing as an explicit policy decision. 16.8. Token and Claim Security Mutable, transient, or reassignable NameID formats used in place of a persistent identifier can cause account takeover or misbinding after identifier reuse; the rules in Section 12.5 restrict their use accordingly. Incorrect acr mapping can overstate the authentication assurance signaled to the SP; see Section 13.1 for the rule that AuthnContextClassRef is taken from the SP-Binding's explicit mapping or allowlist and is never copied blindly from acr. The amr claim [RFC8176] MUST NOT be copied directly into AuthnContextClassRef. The Bridge MUST NOT expose the OP sub value as a SAML Attribute element. The OIDC subject is translated exclusively into the SAML NameID. The Bridge MUST NOT release all OIDC claims to all SPs by default. Each SP-Binding MUST have an explicit attribute release allowlist that is maintained administratively and not derived from the contents of a given ID Token. 16.9. Refresh Token Compromise When the Bridge holds a refresh token at the OP to maintain its OIDC session, compromise of that refresh token allows an attacker to obtain fresh ID Tokens from the OP and drive Bridge assertion issuance for any SP-Binding the Bridge serves, without further end- user interaction at the OP. Deployments SHOULD: * store Bridge refresh tokens with the same protection as Bridge SAML signing keys; * prefer sender-constrained refresh tokens (e.g., DPoP or mTLS) where the OP supports them; and * monitor for unexpected refresh-token use patterns and rotate the Bridge's OIDC credentials promptly on suspicion of compromise. 16.10. Protocol Confusion and Transport Security Mixing SAML trust inputs and OIDC trust inputs creates a risk of protocol confusion. Implementations MUST validate ID Tokens using OIDC/JOSE key discovery and MUST validate SAML signatures using SAML metadata. Implementations MUST NOT assume that a key published in one metadata format is automatically valid in the other. The Bridge MUST apply transport security to its token endpoint, SAML SingleSignOnService endpoint, SAML SingleLogoutService endpoint, and any other endpoint used by this profile, in the same manner as the underlying OAuth, OpenID Connect, and SAML specifications require. The Bridge's SAML metadata URI and the OP's jwks_uri and discovery endpoint MUST use the HTTPS scheme. The Bridge MUST NOT follow redirects from HTTPS to non-HTTPS when fetching OP metadata or keys. 17. Privacy Considerations This profile concentrates identity data flowing from the OP and re- releases it through SAML assertions. The Bridge sits between two trust contexts that SPs and end-users would otherwise see as independent, and its design choices affect the privacy properties of both. Deployments SHOULD use per-SP pairwise NameID values to preserve subject isolation across SPs. A pairwise NameID derived per Section 12.1 ensures that an SP cannot correlate its user population with that of another SP by comparing NameID values; the derivation includes a Bridge-held salt that the SPs do not see. The Bridge MUST NOT release more attributes to an SP than would have been released in a direct SAML federation with an equivalent policy, unless a separate policy explicitly authorizes broader disclosure. The attribute release allowlist defined for each SP-Binding is the privacy-relevant boundary, and the Bridge MUST NOT widen it implicitly because the ID Token happens to carry additional claims. The Bridge MUST NOT pass the SAML SP Entity ID to the OP in a way that allows the OP to build an audit trail linking end-users to specific SPs, unless local policy explicitly permits this and the privacy implications have been assessed. Concretely, the Bridge SHOULD NOT use the SP Entity ID as part of client_id, acr_values, or otherwise convey it to the OP on the authorization request unless the deployment has determined that the OP is an appropriate audit point for SP access. Doing so could allow the OP to profile which SPs each user accesses, which is a privacy violation in many deployment contexts. When multiple Migration Clients share the same saml_sp_entity_id, they will observe the same pairwise NameID and the same attribute release for the same end-user. Deployments SHOULD grant this shared access only when those clients are intended to represent the same SP relationship. The email, phone_number, and similar OIDC contact claims carry user- visible identifiers and are likely to be PII under most regulatory regimes. Where the SP-Binding does not require them, the Bridge SHOULD omit them from the assertion even if the ID Token includes them. The urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress NameID format exposes the email address as the subject identifier and carries email- equivalent sensitivity. Private claim mappings can introduce new correlation vectors across SPs. Deployments SHOULD minimize use of private claims and SHOULD avoid emitting values whose semantics were not already established for the same SP relationship. Bridge-side audit logs combine OIDC and SAML protocol identifiers (OP sub, Bridge session ID, SP Entity ID, NameID) and so are uniquely positioned to deanonymize pairwise NameIDs. The Bridge SHOULD retain such logs for the minimum period required by deployment policy and SHOULD apply the access controls appropriate for that combined data. 18. IANA Considerations 18.1. OAuth Authorization Server Metadata This document requests registration of the following value in the OAuth Authorization Server Metadata registry established by [RFC8414]. Per [OIDC-DISCOVERY] Section 3, the same registry is authoritative for OpenID Provider configuration metadata. * Metadata Name: oidc_op_issuer * Metadata Description: OIDC issuer identifier of the OpenID Provider that backs the Bridge SAML IdP facade * Change Controller: IETF * Specification Document(s): This document, Section 7.2.1 18.2. Notes on Reused Parameters The saml_sp_entity_id client metadata parameter and the saml_idp_entity_id authorization server metadata parameter are defined by [SAML-OIDC-MIGRATION]. This document reuses those parameters with consistent semantics: * saml_sp_entity_id is used in client registrations at the Bridge's token endpoint to bind a Migration Client to an SP-Binding configuration. * saml_idp_entity_id is used in the Bridge's authorization server metadata to publish the Bridge's own SAML IdP Entity ID. No additional IANA registration is required for these parameters. The Token Exchange grant type urn:ietf:params:oauth:grant-type:token- exchange and the token type URIs urn:ietf:params:oauth:token- type:id_token and urn:ietf:params:oauth:token-type:saml2 used by this profile are already registered by [RFC8693]; this document does not modify those registrations. 19. References 19.1. Normative References [OIDC-BC-LOGOUT] Jones, M. B. and J. Bradley, "OpenID Connect Back-Channel Logout 1.0", . [OIDC-CORE] Sakimura, N., Bradley, J., Jones, M. B., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", . [OIDC-DISCOVERY] Sakimura, N., Bradley, J., Jones, M. B., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 2", . [OIDC-ENTERPRISE-EXTENSIONS] Hardt, D. and K. McGuinness, "OpenID Connect Enterprise Extensions 1.0", September 2025, . [OIDC-FC-LOGOUT] Jones, M. B., "OpenID Connect Front-Channel Logout 1.0", . [OIDC-REGISTRATION] Sakimura, N., Bradley, J., and M. B. Jones, "OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, . [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8176] Jones, M., Hunt, P., and A. Nadalin, "Authentication Method Reference Values", RFC 8176, DOI 10.17487/RFC8176, June 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, . [SAML2-BINDINGS] OASIS, "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0", 2005, . [SAML2-CORE] OASIS, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", 2005, . [SAML2-METADATA] OASIS, "Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0", 2005, . [SAML2-PROFILES] OASIS, "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0", 2005, . [SAML2-SUBJ-ID] OASIS, "SAML V2.0 Subject Identifier Attributes Profile Version 1.0", 2019, . 19.2. Informative References [I-D.ietf-oauth-identity-assertion-authz-grant] Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz- grant-03, 22 April 2026, . [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, . [RFC7522] Campbell, B., Mortimore, C., and M. Jones, "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7522, DOI 10.17487/RFC7522, May 2015, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [SAML-OIDC-MIGRATION] McGuinness, K., "OpenID Connect Migration Profile for SAML 2.0 Service Providers", . Appendix A. Examples This appendix is non-normative. Unless otherwise noted, these examples use the private_key_jwt client authentication method as defined by [OIDC-CORE]. Token values and client assertion JWTs are shortened placeholders. The examples cover the two primary deployment patterns for this profile: the browser-based SAML SSO flow in which the Bridge intercepts a SAML authentication request and backs it with an OIDC flow, and the Token Exchange variant in which a Migration Client exchanges an ID Token for a SAML assertion. All examples assume a Bridge with the following configuration: * SAML IdP Entity ID: https://bridge.example.com/saml/idp * OP issuer: https://op.example.com * Bridge token endpoint: https://bridge.example.com/token and an SP-Binding for a calendar application: * SP Entity ID: https://calendar.example.com/saml/sp * ACS URL: https://calendar.example.com/saml/acs * NameID format: urn:oasis:names:tc:SAML:2.0:nameid- format:persistent (pairwise) * Attribute release: mail, displayName, givenName, sn A.1. Browser-Based SAML SSO Flow The calendar application initiates SAML SSO by redirecting Alice's browser to the Bridge with an AuthnRequest. The Bridge has no existing OIDC session for Alice and initiates an authorization code flow with the OP. After Alice authenticates at the OP, the OP redirects back to the Bridge with an authorization code. The Bridge exchanges the code for an ID Token, validates it, derives Alice's pairwise NameID for the calendar SP, maps her claims to SAML attributes, and posts a signed SAML Response to the calendar ACS. The Bridge's outbound OIDC authorization request (HTTP-Redirect to the OP): GET /authorize?response_type=code &client_id=bridge-client &redirect_uri=https%3A%2F%2Fbridge.example.com%2Fcallback &scope=openid%20profile%20email &state=abc123 &nonce=xyz789 &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM &code_challenge_method=S256 &claims=%7B%22id_token%22%3A%7B%22auth_time%22%3A%7B%22essential%22%3Atrue%7D%7D%7D HTTP/1.1 Host: op.example.com After the OP authenticates Alice and returns an authorization code, the Bridge exchanges it for tokens and receives an ID Token whose claims include: { "iss": "https://op.example.com", "sub": "248289761001", "aud": "bridge-client", "exp": 1776808500, "iat": 1776804900, "auth_time": 1776794400, "nonce": "xyz789", "acr": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", "email": "alice@example.com", "given_name": "Alice", "family_name": "Ng", "name": "Alice Ng" } The Bridge validates the ID Token, resolves Alice's Local Account, derives a pairwise NameID for the calendar SP-Binding, and constructs the following SAML Assertion (simplified, namespace declarations omitted): https://bridge.example.com/saml/idp ... _pairwise-8a3f21bc9d4e5f6a7b https://calendar.example.com/saml/sp urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport alice@example.com Alice Ng Alice Ng The Bridge wraps this assertion in a signed SAML Response and HTTP- POST binds it to the calendar ACS at https://calendar.example.com/saml/acs. A.2. Token Exchange: ID Token to SAML Assertion A migration tool has obtained an ID Token from the OP on behalf of Alice using a permitted OIDC flow and needs to produce a SAML assertion for the calendar SP to test a migration scenario. It presents the ID Token to the Bridge's Token Exchange endpoint: POST /token HTTP/1.1 Host: bridge.example.com Content-Type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:token-exchange &subject_token_type=urn:ietf:params:oauth:token-type:id_token &subject_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJpc3MiOiJodHRwczovL29wLmV4YW1wbGUuY29tIiwic3ViIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiYnJpZGdlLWNsaWVudCIsImV4cCI6MTc3NjgwODUwMCwiaWF0IjoxNzc2ODA0OTAwLCJqdGkiOiJvcC1pZC10b2tlbi03ZjNhIiwiYXV0aF90aW1lIjoxNzc2Nzk0NDAwLCJhY3IiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImVtYWlsIjoiYWxpY2VAZXhhbXBsZS5jb20iLCJnaXZlbl9uYW1lIjoiQWxpY2UiLCJmYW1pbHlfbmFtZSI6Ik5nIiwibmFtZSI6IkFsaWNlIE5nIn0.signature &requested_token_type=urn:ietf:params:oauth:token-type:saml2 &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer &client_assertion=eyJhbGciOiJSUzI1NiJ9... The Bridge authenticates the Migration Client, validates the ID Token, derives Alice's pairwise NameID for the calendar SP-Binding, and returns: { "issued_token_type": "urn:ietf:params:oauth:token-type:saml2", "access_token": "PHNhbWwyOkFzc2VydGlvbiBJRD0iX2JyaWRnZS1hc3NlcnRpb24tN2YzYTljMjEiLi4uPi4uLjwvc2FtbDI6QXNzZXJ0aW9uPg", "token_type": "N_A", "expires_in": 300 } The access_token value is a base64url-encoded SAML assertion constructed identically to the browser-based flow example, except that InResponseTo is omitted from SubjectConfirmationData because no prior AuthnRequest was issued. Appendix B. Paired Profile Summary This appendix is non-normative. The following table summarizes the correspondence between this profile and its companion [SAML-OIDC-MIGRATION]. +================+=======================+=========================+ | Dimension | | This profile | +================+=======================+=========================+ | Direction | SAML → OIDC/OAuth | OIDC → SAML | +----------------+-----------------------+-------------------------+ | Input | SAML Assertion | OIDC ID Token | | credential | | | +----------------+-----------------------+-------------------------+ | Output | Access token / ID | SAML Assertion | | credential | Token / Refresh token | | +----------------+-----------------------+-------------------------+ | Authentication | SAML IdP | OpenID Provider (OP) | | authority | | | +----------------+-----------------------+-------------------------+ | Translation | OAuth AS / OpenID | Bridge (SAML IdP | | component | Provider | facade) | +----------------+-----------------------+-------------------------+ | Client binding | saml_sp_entity_id | saml_sp_entity_id | | parameter | (client metadata) | (client metadata at | | | | Bridge) | +----------------+-----------------------+-------------------------+ | AS metadata: | saml_idp_entity_id | saml_idp_entity_id | | bound entity | (SAML IdP entity) | (Bridge's own SAML | | | | entity) | +----------------+-----------------------+-------------------------+ | AS metadata: | — | oidc_op_issuer (backing | | peer system | | OP) | +----------------+-----------------------+-------------------------+ | Subject input | SAML NameID → OIDC | OIDC sub → SAML NameID | | | sub | | +----------------+-----------------------+-------------------------+ | Attribute | SAML attributes → | OIDC claims → SAML | | direction | OIDC claims | attributes | +----------------+-----------------------+-------------------------+ | ACR direction | AuthnContextClassRef | acr → | | | → acr | AuthnContextClassRef | +----------------+-----------------------+-------------------------+ | auth_time | AuthnInstant → | auth_time (NumericDate) | | direction | auth_time | → AuthnInstant | | | (NumericDate) | (dateTime) | +----------------+-----------------------+-------------------------+ | Pairwise | saml_sp_entity_id | SP Entity ID + salt | | subject key | (OIDC Core §8 input) | (hash-based derivation) | +----------------+-----------------------+-------------------------+ | Replay | Assertion ID tracking | ID Token jti tracking | | prevention | at AS | at Bridge | +----------------+-----------------------+-------------------------+ | Logout: SP → | SAML SLO → AS session | SAML SLO → Bridge | | IdP | revocation | propagates to OP | +----------------+-----------------------+-------------------------+ | Logout: IdP → | OIDC back-channel | Bridge propagates SAML | | SP | logout | SLO to SP | +----------------+-----------------------+-------------------------+ Table 4 Acknowledgments This draft was developed as the inverse companion to [SAML-OIDC-MIGRATION] and shares its interoperability context with the OAuth working group identity assertion draft and the OASIS SAML subject identifier profile. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com