ratiolat

OIDC is based on Oauth2. The auth part of Oauth stands for authorization, not authentication which brings me to the problem I have with OIDC - namely OIDC is about granting external party access to your data. You can mitigate this a bit via using something like Okta, which just does not have this data, but lets say you don't have Okta and all you have is Google Workspace.

I really wish that OIDC / Oauth(orization) would be less confusing from user experience and security perspective.

What I have in mind - I'd say only very small population understand that OIDC / Oauth(orization) is about granting access to a service to access your data. Meaning once you have approved service (lets say Dropbox), now Dropbox can access your data on your google account (this of course depends what exactly dropbox asked and if you clicked on "approve", but most people do click as they want to login to Dropbox via their Google account).

SAML is better, as it can be defined at Google side what data is being sent to DropBox when Single Sign On happens and DropBox cannot access your google data as it sees fit.

SAML ain't perfect either because there's no practical way to "sign me out everywhere"

IBM Storage Protect (used to be called IBM Spectrum Protect, Tivoli Storage Manager, ADSM) used to be a thing, probably still is. Not cheap though.

Interesting. For example how would one find a "new" Tool or Deftones? Current algorithms probably don't "pick up" not-yet-so-popular things. For example Shelton San (I found out about them via word-of-mouth), although I'm frequent user of Spotify. This means that classical promotion channels are still necessary, as otherwise things get lost in noise.

That's the thing - authentication capability is basically sideeffect of Oauth/OIDC. SAAS x can request whatever they want via OIDC and then user can either accept it or decline it. This is protocol, not google specific matter. Ask ordinary user how they understand what is being asked from them when they are trying "to log in" via OIDC/Oauth. With SAML it's the other way around - administrator chooses what is being sent to SAAS x, user does not need to decide anything nor do they get hard to understand prompts.

From adminstration and user perspective Oauth (Oauthorization) is alot more confusing though.

"Why is google asking me to grant access to my google drive for SAAS X, I just want to login to SAAS X via Google"

Would be great if chromeos flex would start supporting organisation provided wifi credentials - currently only device generated keys are an option, meaning one has no idea whatsoever if keys generated are actually good enough or are just looking random while generated might be generated predictably. No idea, as it's a black box. Allow organisations to generate keys off device and allow these to be uploaded to the device, and then we can start considering it.

The other problem is that other vendors do not provide chromeos versions of their tools. Looking at you Fortinet and your vpn.

Agree with the article. The worst offender is probably Oauth providing endless confusion to developers and end users

When has the switch been toggled though and how can I know in each implementation?

1. Is it when I pushed the toggle, regardless of when animation finishes? 2. Is it when the animation finishes

This is necessary when flipping many toggles on one page and it needs to be done many times over. In case there's no animation, it simple and clear. In case there's animation you need the know is it case 1 or 2. If it's case 2 it will additionally slow you down as you now need to wait until all animations lengths * number of switches toggled has finished.

Looked very promising, but there are some hard blockers: 1. It's not shipping yet, meaning there are no trustworthy reviews. 2. It will be shipped to USA only. 3. It needs apple device for (full) control.

Hopefully all of these will be adressed

Dirigera still does not support Matter. I bought it for 'coming soon' Matter support, but it's still not there. Have been waiting for looong time now.