When we started C1.ai - 2020 - as someone who worked previously at Okta - I made a decision to only implement OIDC. (see article for all of the reasons). We were worried in the first 2 years, that some big enterprise would force us to implement SAML.
But it turns out, all the major IDPs support OIDC now. It's a non-issue.
Yes, these folks came out of Intel Labs. But that's also a fabless startup. When you start talking about fabs you're talking about needing real money (in the multi billions of dollars). That kind of funding could only come from the likes of Apple and Nvidia.
They did not come (directly) out of Intel Labs. They left because they were working on a moonshot project that lost corporate support. Just like Ampere computing, just a few years later.
okta is not "active-active" in a multi-region sense, they run in a single active AWS single Region per-tenant. You can pay extra to have a faster failover in a region level failure scenario:
Bcrypt is still perfectly usable for its original purpose. They just picked/wrote a bad implementation that silently truncated inputs longer than the maximum input length. Would you also ask why they picked AES (a cipher from 1998) when the error was with the user (e.g. picking fixed/too short key)?
What about "access controls" for the AuthZ side, instead of Permissions?
Wondering HNs collective wisdom on this-- at work we've been using Access Controls on our homepage for awhile- https://www.conductorone.com/ - to the people outside the IAM-geek space does this make more sense?
I like the idea of exposing Roles for selection, and having those roles generally apply to permissions or workflows internally. This tends to work pretty well for many, or even most applications. I can't stand fine-grained access controls in general.
The API for Let's Encrypt to do this requires possession of the private key, which pwned keys doesn't always have. Sometimes they just have an "attestation" of compromise:
You can also just, Log the spans as they are being created to stderr/stdout -- I've done this on a previous project with this approach of "spans first".
It made it debuggable via output if needed, but the primary consumption became span oriented.
But it turns out, all the major IDPs support OIDC now. It's a non-issue.