When choosing between SAML 2.0 and OpenID Connect, what does each one's credential format demand of the relying side?

## Compare what you must consume, not what you like Standard-selection arguments go wrong when they are conducted on style — one is XML and old, the other is JSON and modern. That framing predicts nothing. The question that predicts everything is: **what must a relying party be able to do, on every single login, to accept this credential at all?** Answer that and the selection usually answers itself. ## The two credentials, side by side | | SAML 2.0 | OpenID Connect | |---|---|---| | Credential the relying side consumes | An XML assertion | A JWT (`RFC 7519`) | | Protection over it | An XML Signature over the document or a part of it | A JOSE signature over the compact-serialised token | | Dependency required | An XML security toolchain that canonicalises and verifies | A JOSE library and the key set (`RFC 7517`) it verifies against | | Typical size on the wire | A document, often kilobytes | A compact string, typically far smaller | | Platform availability | Good on long-lived server stacks, patchy elsewhere | Broad, including constrained and browser-adjacent platforms | | Party naming | An `entityID` names each party | An issuer identifier names the provider | What matters in that table is the **dependency row**. An XML signature is verified over a document whose exact bytes must first be agreed on, which is why canonicalisation exists and why the toolchain is substantial. A JOSE signature is verified over a string the format already pins. That is not a statement about which is more secure; it is a statement about what the relying party must ship and keep patched. ## What the difference actually decides Three selection consequences follow, in the order they usually bite: 1. **Which platforms can be a relying party cheaply.** If a member organisation's integration team can pull in a JOSE library but has no XML security stack, that asymmetry decides the standard for them regardless of anybody's preference. 2. **What your operational surface is.** A heavier parser is a larger surface to keep current. This is an argument about maintenance, not an accusation against the standard. 3. **What travels with the identity.** The two standards deliver attributes about the user differently, and they take different positions on how a logout is signalled. Both differences are **selection inputs** — confirm each one can carry what your estate needs before choosing. How either mechanism works is the subject of that standard's own material, not of this decision. ## The third option you must name rather than assume away Estates do not only contain the two standards people argue about. **WS-Federation Version 1.2** is an OASIS Standard published in **May 2009**, and organisations still carry deployments of it. In a selection review, name it at exactly that strength: a third, distinct federation standard that some members will arrive speaking, and one that needs its own implementation on both sides rather than being a dialect of either of the other two. Do not assume its messages resemble anything you know. ## How to run the comparison in practice A selection review that holds up has four columns and no adjectives: - **Client population** — what will need to log in, and can the standard serve it without an opt-in profile at both ends? - **Consumption cost** — what library and what maintenance does each credential format impose on each side? - **Expressiveness** — can the standard carry the attributes and the session behaviour the business actually needs? - **Incumbency** — what do the member organisations already run, and what does asking them to change cost them rather than you? Incumbency is the column engineers discount and estates decide on. A standard that is objectively better to consume is still the wrong answer if forty member organisations would each need a project to adopt it — which is why the realistic outcome is so often *both, for years*, and why coexistence is a first-class design problem rather than a failure of the selection. ## The trap to avoid The trap is treating the credential format as cosmetic and discovering later that it was structural: a member whose platform has no XML security stack, a client population the mainstream profile cannot serve, or an attribute the chosen standard has no natural place for. Those surface years after the decision, which is exactly why interviewers ask this as a design question rather than a trivia one.