That's a ridiculously implausible and sensationalized rumor. At most, Microsoft may make a NPU a requirement for OEMs to use the Windows 12 logo on new PCs. Actually refusing to support the existing install base of recent and hughly-capable desktops is not at all likely. It would be far more drastic than the hardware deprecations brought by Windows 11, which were already quite controversial (and loosely enforced).
The benefits definitely do not accrue to you, though. There is no direct or indirect benefit to you supporting the invasion of another country where you can now bomb locals with impunity.
It is pretty obvious the cause, they are just doing their investigation. There is a video of it out there. I will describe it for sensitive people who might not want to actually see it. The car was going probably 100 mph out of a tunnel and understeered into a jersey barrier. The passenger was ejected still in the seat and the car caught fire a few seconds after impact. Bystanders managed to pull the passenger away from the wreck, then the video cut off.
Did you see the speed he was going on a public road? LA drivers are tired of these assholes driving recklessly. It’s gotten incredibly dangerous to drive especially at night after COVID.
> This is a TypeScript library that implements the provider side of the OAuth 2.1 protocol with PKCE support.
What is the "provider" side? OAuth 2.1 has no definition of a "provider". Is this for Clients? Resource Servers? Authorization Server?
Quickly skimming the rest of the README it seems this is for creating a mix of a Client and a Resource Server, but I could be mistaken.
> To emphasize, this is not "vibe coded". Every line was thoroughly reviewed and cross-referenced with relevant RFCs, by security experts with previous experience with those RFCs
Experience with the RFCs but have not been able to correctly name it.
This library helps implement both the resource server and authorization server. Most people understand these two things to be, collectively, the "provider" side of OAuth -- the service provider, who is providing an API that requires authorization. The intent when using this library is that you write one Worker that does both. This library has no use on the client side.
This is intended for building lightweight services quickly. Historically there has been no real need for "lightweight" OAuth providers -- if you were big enough that people wanted to connect to you using OAuth, you were not lightweight. MCP has sort of changed that as the "big" side of an MCP interaction is the client side (the LLM provider), whereas lots of people want to create all kinds of little MCP servers to do all kinds of little things. But MCP specifies OAuth as the authentication mechanism. So now people need to be able to implement OAuth from the provider side easily.
> Experience with the RFCs but have not been able to correctly name it.
These docs are written for people building MCP servers, most of whom only know they want to expose an API to AIs and have never read OAuth RFCs. They do not know or care about the difference between an authorization server and a resource server.
> Most people understand these two things to be, collectively, the "provider" side of OAuth
Citation needed. As another commenter already noted, the term "Provider" is rarely used in OAuth itself. When it is mentioned, it's typically in the context of OpenID Connect, where it refers specifically to the Authorization Server - not the Resource Server.
> the service provider, who is providing an API that requires authorization
That’s actually the Resource Server.
I understand that the current MCP spec [1] merges the Authorization Server and Resource Server roles, similar to what your library does. However, there are strong reasons to keep these roles separate [2].
In fact, the MCP spec authors acknowledge this [3], and the latest draft [4] makes implementing an Authorization Server optional for MCP services.
That’s why I’m being particular about clearly naming the roles your library supports in the OAuth flow. Going forward, MCP servers will always act as OAuth Resource Servers, but will only optionally act as Authorization Servers. Your library should make that distinction explicit.
Strictly speaking, yes. But speaking of IDPs more broadly, it’s perfectly acceptable to refer to the authorisation-server as an auth-provider, especially in OIDC (which is OAuth, with extensions) where it’s explicitly called “OpenID provider” - so it’s natural for anyone well-versed in both to cross terminology like that.
