To be fair, SIMD made a massive difference for early multimedia PCs for things like music playback, gaming, and composited UIs.

My point being: assuming you have RFCs (which leave A LOT to the imagination) and some OSS implementations to train on, each implementation usually has too many highly specific choices made to safely assume an LLM would be able to cobble something together without an amount of oversight effort approaching simply writing the damned thing yourself.

As much as it pains me to say it, Canada's diversity is also it's weakness, and there needs to be precedent - perhaps not as severe as in the US - that you do NOT leave the dominion.

This misses the mark - scopes are abstractions for capabilities granted to the authorized bearer (client) of the issued access token. These capabilities are granted by the resource owner, let's say, a human principal, in the case of the authorization_code grant flow, in the form of a prompt for consent. The defined capabilities/scopes are specifically ambiguous as to how they would/should align with finer-grained runtime authorization checks (RBAC, etc), since it's entirely out of the purview of the standard and would infringe on underlying product decisions that may have been established decades prior. Moreover, scopes are overloaded in the OAuth2.0/OIDC ecosystem: some trigger certain authorization server behaviours (refresh token, OIDC, etc), whereas others are concerned with the protected resource.

It's worth noting that the ambiguity around scopes and fine-grained runtime access permissions is an industry unto itself :)

RFC 9396 is interesting, but naive, and for a couple of reasons: 1) it assumes that information would like to be placed on the front-channel; 2) does not scale in JWT-based token systems without introducing heavier back-channel state.

I personally do not view OIDC as an authentication standard - at least not a very good one - since all it can prove is that the principal was valid within a few milliseconds of the iat on that id_token. The recipient cannot and should not take receipt of this token as true proof of authentication, especially when we consider that the authorization server delegates authentication to a separate system. The true gap that OIDC fills is the omission of principal identification from the original OAuth2.0 specification. Prior to OIDC, many authorization servers would issue principal information as part of their response to a token introspection endpoint.

The sad part of this is that code is absolutely a side-effect of design and conception: without a reason and reasonable approach, code shouldn't exist. I really think that the relative austerity happening in industry right now will shine a light on poor design: if your solution to solving poorly understood spaces was to add yet another layer of indirection in the form of a new "microservice" as the problem space changed over time, it's probably more likely that there was an inherent poor underlying understanding of the domain and lack of planning extensibility in anticipation. Essentially, code (bodies) and compute aren't as "cheap" as they were when money was free, so front-loading intelligent design and actually thinking about your space and it's use-cases becomes more and more important.

I don't know where our industry lost design rigor, but it happened; was it in the schools, the interviewing pipeline, lowering of the bar, or all of the above?

Other nonsense I've seen: leaking internally signed tokens for external use (front-channel), JWTs being validated without a kid claim in the header - so there's some sketchy coupling going on, skipping audience validation, etc...

Not much surprises me anymore when it comes to this kinda stuff - internally, I suspect most cloud providers operate like "feature factories" and security is treated as a CYA/least-concern thing. Try pushing for proper authz infrastructure inside your company and see what kinda support you'll get.

I think last year my total $-amount for SFMTA tickets came to ~$1300? Still cheaper than paying for a garage or wasting my time trying to find street parking.

More on context here: the sidewalks of the outer sunset and outer richmond are extremely wide, to the point were you could easily parallel park 1.5 cars right on the sidewalk, so it's trivial to park a car such that it being partially in the driveway will leave more than enough space for anyone to pass.

I also had a quick look into the social media (primarily reddit) aspect of these vascular conditions, and it's a pile of dogshit. Most of these patient communities bill themselves as "support groups", but there's never any real discussion on meaningful research, drug, or device advancements. They places serve primarily as "pity pits" for chronic moaners and scammers selling alternative medicine.

1. The OG OAuth2 spec never said anything about identifying principals 2. OIDC mandated an id_token to avoid the hit of POSTing the access token to an introspection endpoint 3. The shape of the id_token is a JWT

This doc is junk, btw - it's suggesting the client use the id_token for the purposes of authentication? I wouldn't trust that token beyond some basics, unless you have very strong controls over the authorization server and IdP to ensure things like email verification are propagated correctly.