OIDC doesn't scale, and OIDC Federation is still in draft. SAML Federation is mature with wide support and good discovery UX thanks to SeamlessAccess.
SAML has a variety of standard attribute bundles, entity categories, frameworks, and profiles covering important integrations, e.g., identity assurance. These are slowly being defined in (or ported to) OIDC.
I like OIDC and think highly of the people working on it, but it's nowhere near as cut and dry as you suggest.
I don't know a lot of security engineers that agree, and while (as a SAML implementor) I have my own opinion, "don't do new SAML implementations" is mostly me parroting what I think is the consensus.
I think... it probably is as cut and dry as I'm suggesting.
The things you just listed sounds like unnecessary complexity that inevitably leads to the “too big standard” problem, where every vendor and id provider has their own half assed, incomplete and incompatible implementation of the standard, or worse - with security bugs. Something quite often seen with SAML.
That’s not to say that oidc or oauth doesn’t have alignment issues. See https://news.ycombinator.com/item?id=35713518 “We implemented OAuth for the 50 most popular APIs. TL;DR: It is still a mess”
This cuts both ways. The last major revision of SAML predates the iPhone by several years. Things like PKCE, which are essential for security on mobile devices and in other cases don’t exist at all in SAML, yet the same attack vectors apply (plus a boatload more).
OIDC doesn't scale, and OIDC Federation is still in draft. SAML Federation is mature with wide support and good discovery UX thanks to SeamlessAccess.
SAML has a variety of standard attribute bundles, entity categories, frameworks, and profiles covering important integrations, e.g., identity assurance. These are slowly being defined in (or ported to) OIDC.
I like OIDC and think highly of the people working on it, but it's nowhere near as cut and dry as you suggest.