We can have both. The resources aren't coming from the same bucket. Public transportation must be built by the local government, and is subject to that local government's ability to execute. In contrast, Self driving cars are largely siphoning resources from for-profit companies.
I live in the west side of San Francisco, and we may get a subway station by 2050 if we're exceptionally lucky. I'd rather have self-driving cars this decade, please.
To my knowledge there are only a handful of public transit systems in the world that operate at a profit, let alone that operate at enough of a profit to recover construction costs. As in, maybe 5 if you squint really hard. Who do you expect to fund new ones if not the government?
Regional or state is better than local government. Local governments would struggle to raise the required funds for the costs of modern transit and would have a mandate to really support transit within their municipal borders vs a regional solution that is agnostic to the byzantine municipal borders.
It is viable. Think of workload identity federation as the mechanism for the client to get an bearer token initially, and DPoP as the mechanism for the client to present the access token to a resource server. Each DPoP proof is entirely self-contained, so resource servers don't need to manage any additional state. The only new state is the (usually ephemeral) private key held by the client:
1. Client generates a private/public keypair and uses it to generate DPoP Proofs -
JWTs containing the entire public key embedded as a JWK within
2. Client presents credentials (WIF, client creds, auth code, etc.) to the Authorization Server along with a DPoP Proof
3. Authorization Server validates DPoP Proof and adds a claim to the access token containing the thumbprint - the SHA-256 hash - of the public JWK.
4. Resource Servers will now see the thumbprint claim and now know the access token needs to be presented with a fresh DPoP proof.
5. Clients generate fresh DPoP proofs and send them along with the access token
There are lots of additional details around nonces, timestamps, per-request binding, etc. but DPoP can be rolled out to any HTTP system that speaks Bearer token already.
No - this is built on top of SPIFFE/WIMSE work to enable cross-domain usage where the target domain speaks OAuth instead. You wouldn't expect, say, Slack's APIs to accept SPIFFE SVIDs from your internal deployment. This provides a path for you to exchange your SVID for a Slack-issued Access Token.
> There are lighter weight options that do basic stuff like transaction management and binding result sets to object properties that are much less of a PITA than ORMs.
Query builders like these are my personal favorite from a productivity perspective! The point of a query builder is to dynamically build SQL statements that have many subtle variations (do we want to filter by EmailID or PhoneID here? What about a subquery? Did the caller want all results, or just results where $field=X?). They're basically one level above string templating for SQL generation, and often have niceties around ser/de and transaction management as you mentioned.
Because they are primarily about query generation, it feels _very_ natural to pop off the hood and write raw queries directly when necessary. You can usually use the transaction management and ser/de parts with raw queries, too.
Knex has its own set of problems. Again, SQL is a very powerful, well-known language and there are simpler tools that make it possible to break up and reuse queries.
Years ago I was working on a project that used knex, then I serendipitously discovered slonik through this blog post, https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41... (slonik has subsequently had lots of development since then). I decided to rewrite the entire persistence layer from knex to slonik over a long weekend and I'm so happy I did. I liked slonik so much that it was the only time I personally contributed to a programmer through GitHub Sponsors.
> If the client wants to detect custom API gateways, it can say so plainly. It can send an explicit telemetry field with documentation. It can make the policy visible. It can put the behavior in release notes.
This seems like a very naive response. If clients send explicit telemetry fields to the gateway, a malicious gateway can trivially strip or modify the field to conform to what normal traffic looks like. The steganography cat-and-mouse game is valuable because it is much harder for a gateway to continuously reverse engineer all the fingerprinting mechanisms used. Sure, some malicious gateways will be able to stay on top of things, but not all - and not always.
Well, the first filter catches anyone whose timezone is set to mainland China. That includes presumably all individual devs just using a VPN, who have no desire to or knowledge of distilling.
(Again, could be trivially bypassed either by rewriting, mocking the timezone call, or just changing the timezone. But we are assuming no mitigation used.)
I would add that it would probably work even better than a KYC at least for some time until discovered, given that there is a very developed international market for KYC bypass services
Huge congrats to the folks behind this at Okta, A\, Microsoft, Figma, Linear, etc...
For the MCP nay-sayers - don't worry there's something here for you too :)
This is powered by a new token format called an ID-JAG - https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a... - and isn't MCP specific at all. ID-JAGs can be used for safe and secure data sharing anywhere where data is shared between applications that use the same SSO provider.
In regular OAuth, end users consent to share their data with applications individually. This makes sense for consumer usecases, where the end users own their data. But it doesn't make sense for many business usecases, where the business is the entity that should control data sharing and access, not the end user. As an employee at Acme, I shouldn't decide to link my Acme Google Drive data to Claude or ChatGPT, that should be the decision of my IT Department.
Enterprise-Managed OAuth, or Cross App Access (XAA), brings this IT-Admin centrally controlled sharing model into the OAuth framework so it works with the existing ecosystem.
There's also a great UX benefit from moving data sharing consent management from employees to IT Admins - it means that employees don't need to sit through a bunch of OAuth flows to link their accounts together. Their IT Admin has already set up all the sharing controls. Everything plugs in together and should Just Work from day one. Think joining a new company on the first day and your Slack is already linked to your Zoom, your Drive, your Calendar, etc...
Sure, if I’m a business, I will make a business decision to share, or not share, some resource with ChatGPT. But, if I do decide to share something with ChatGPT, I absolutely do NOT want it shared with every single ChatGPT thread, more or less how I don’t want it shared with every single tab an employee has open in a browser.
The article is all about reducing friction. Suppose I start a conversation and enter some highly third-party-prompt-injectable request, perhaps "Fork github.com/some_third_party/coolproject and submit a PR to do such-and-such." That repo injects a prompt that attempts to do a tool call to steal all my money. If I indeed have a bank MCP configured, I absolutely want to be prompted!
Now I realize it's silly for the prompt to look like "Would you like to grant [OpenAI/Anthropic/whatever] access to such-and-such account with such-and-such OAuth resources?", but having some kind of explicit opt-in, per conversation, to MCP access seems really quite important. But the article all about reducing friction and avoiding prompts.
So maybe LLM providers will do a good job, but I'm not holding my breath.
Just to be clear, enforcing proper access control and data seperation is the job of a client (/harness), not the job of an LLM Provider (though of course the most popular clients are the first party clients for the LLM providers).
Ensuring that an LLM doesn't have free reign over calling any MCP tool at any point in time is one of the main jobs of a client (apart from the general data persistence, etc.), and one that's very dependent on the setup (e.g. many MCP servers expose public data where tool calling is mostly not that sensitive) and the acceptable risk profile.
This MCP extension also doesn't significantly change anything about tool calling control from the perspective of the client. MCP servers were previously also authenticated once per user, and not once per conversation or once per tool call.
There's some active discussions on task level authz and multi-hop delegation in the OAuth WG right now. WorkOS wrote a good overview of the open drafts [1]. (Disclosure: one of them is mine.)
[1] https://workos.com/blog/oauth-multi-hop-delegation-ai-agents
(a) A major problem where one agent can give dangerous instructions to another.
(b) A desire for an “agent” to cleanly delegate permissions to another “agent”. I am extremely unclear as to what an “agent” is in this context. Is one’s OpenAI or Anthropic account an “agent”? How is (b) related to (a)?
(c) An observation that existing OAuth + JWT can’t really do (b) and that a new spec could allow delegation.
ISTM:
- (a)’s root cause is a complete lack of control on the portions of a repository that are interpreted by various tools in a trusted/privileged manner.
- (b) could be addressed by a capability or proxy system.
- Most services that offer OAuth or other types of API keys have absurdly coarse-grained permissions. GitHub’s OAuth cannot obviously even restrict to a particular organization, let alone a repository, and good luck blocking commits to .github. Cloudflare can’t restrict DNS operations to a particular host. A shocking number of major services have no concept of non-human accounts. The list goes on. Delegation is of dubious value in this setting.
- Why would one ever want to give a bearer token to an “agent”?
- Wouldn’t a proxy serve this purpose more flexibly and more universally?
I agree with the coarse permissions point, and I wouldn't bank on those services adding finer-grained scopes.
The idea in my draft is to do the attenuation and verification before the call reaches the service, enforced at the boundary, like the proxy setup you're describing. And the token wouldn't be a bearer token per se; there's proof of possession, and the constraints narrow at each hop and travel with the token, so the boundary can verify the chain itself rather than rely on a central authority. The design is inspired by macaroons and other capability-based access control work.
The key here is the separation of target segment for this. Enterprise identities (you being an employee) are the target for this not the consumer identity (personal account). When you are an employee then the sensitivity and security of your account can be managed by your employer.
Other way to look it is that as an employee you will not be able to connect to any MCP server anymore unless its configured in your IDP.
Pre-GenAI I wrote a new interview question for a role on our team. As far as I know, the question was never made public. The interview required implementing a pretty basic CSS-in-JS utility in vanilla javascript. We instructed the candidate read the MDN documentation for the CSSStyleSheet interface, and then gave them a public API to implement. Passing implementations usually consisted of a ~10 line for loop, and was really just a test of whether a developer pick up and work with new libraries on the fly. Still, the interview probably had a 30% pass rate.
On a lark, I asked ChatGPT to complete the interview question in late 2022. I would have hired ChatGPT back then based on its first response! It was easily in the 90th percentile of responses I have seen.
Is your agent harness dropping the entire MCP server tool description output directly into the context window? Is your agent harness always addig MCP servers to the context even when they are not being used?
MCP is a wire format protocol between clients and servers. What ends up inside the context window is the agent builder's decision.
Mikey might have a profit incentive at play, but let's be abundantly clear - the drivers he is catching are frequently flagrantly breaking the law and endangering both themselves and the people around them. I have a very hard time feeling sympathy for those who are unable or unwilling to operate a car safely on public roads.
Until they drive off while still looking at it, like the woman who drove through a pedestrian crossing a couple of weeks ago and almost hit me while I was walking across.
I think a little reasoning at global scale easily arrives at a defence of the current traffic law depending on risk tolerance, but perhaps an analogy will help: most societies believe (or at least enforce in a manner that reflects belief) that walking around with a handgun out in your hand should be illegal. In truth no harm is done until one pulls the trigger, and there is certainly benefit: it is much faster to stop a criminal when you're ready at hand.
The reasons we don't do that are manifold, but at least a few are analogous:
* legibility: we don't need just lack of harm, we require common knowledge that harm is unlikely in order for society to work with frictionlessness we desire
* distinguishability: at some percentage of accidental behaviour, we must constrain all people because we don't have a mechanism to determine who will likely cause it and who won't
* reversibility: for sufficient harm, it is better to restrict the error condition than it is to punish
Because we know we cannot bring the dead back to life, and no amount of prison will bring solace to their loved ones, we have decided that doing things that are high-risk to others is not permissible. Given this framework for the moral concern, it's just an optimization problem. The question then becomes what fraction of pedestrians killed in crosswalks is acceptable, or even what fraction of pedestrians following the law killed in crosswalks is acceptable. Some societies believe this should be zero (hence the amusingly named Vision Zero and so on as practised in Northern Europe). Others believe this should be fairly high (like the US) because the utility loss from constraint is too high.
Now the handgun case has a very high number for potential risk, so it's obvious why most societies have that law. The crossing point of risk for almost everyone is below it, consequently most agree. The question then becomes what your crossing point for risk is and whether the number of accidental deaths is above your threshold or below your threshold. But in either case, I don't think the argument "until they hurt someone, no harm is done, and therefore it should be permissible" holds, for if it did, surely we would allow for people walking around with handguns, perhaps even pointed directly in front of them as they walk, so long as they do not pull the trigger. And that seems to be an absurdity.
The specificity of handgun versus firearms in general belies the weakness of the argument. Would it matter in the thought experiment if it were a long gun?
The status of open carry legality in a US state is not correlated with firearms violence rates. Firearm prevalence in general is.
I support Vision Zero. It has a sound logical and statistical basis.
Vision Zero is orthogonal to a law against using a mobile telephone while operating a vehicle that is stopped.
Here are two daily occurrences contradicting that:
1. The driver realizes out of their peripheral vision that the light has changed but wants to finish the urgent TikTok they’re watching so they accelerate, often rapidly, without looking around and fails to notice other road users. I’ve seen people hit other cars because they didn’t notice the car ahead of them had stopped accelerating due to congestion, and countless times where they almost or did hit someone (fortunately never fatally) in the crosswalk because they were in “green means go mode” before they were fully back to looking outside their vehicle.
2. The driver continues to look at their phone and fails to notice when the light changes. Someone behind them gets mad and does something dangerous to pass such as driving in the opposite traffic lane, a bike lane, or in a pedestrian space.
Yes, many people do look at phones without hitting anyone but that’s like saying it’s okay to celebrate by firing a gun in the air because only a few people get hit. It’s a statistical certainty that the more times someone engages in unsafe activity, the more people will be on the unlucky side of those odds. If you have a couple million daily car trips in London, even 99.9999% safety means someone getting hurt every day.
I almost can't beleive adults are having this conversation.
You have never been sitting at a light, and see everone around you with their heads down, while the light has been green for 4 seconds?
Inverse, Have you ever been rear ended because a person staring down at their phone at a red light just decides to roll forward because someones brake lights in the pack deluminate for a moment?
I ask, because point 1 happens to me daily, and point 2 has put my car in the shop for weeks twice in the last 5 years.
A totally separate point to make; what could you possibly be doing on the phone? Like how addicted to social media or work must one be that they wait for the briefest of moments to distract themselves? I ask that not to judge or poke fun, but to say that you MUST be doing something that you find so important, and thus taking your attention, that it is now your priority. Or else, you would choose to wait.
I know you, as a reasonable adult on this forum, know what people are talking about here.
I can stay parked at a green light the entire cycle, and it still will be 100% the fault of the person who rear ends me.
As for what I'm doing, it's probably something like scrolling the map to see what road I'll be turning on in 5 minutes, so that I don't have to look at it (regardless of whether I'd be touching it) later. Or a dozen other similar things, none of which have anything to do with social media.
And I know you, as a reasonable adult on this forum, know this.
With all due respect, I could not imagine one thing, nor a dozen, that would involve me fiddling with my phone while on a commute of any length.
I say this having both a vehicle with wireless carplay, and another where I need to manually configure maps. And yes, I often fiddle with maps as I'm a nervous wreck, but I truly cannot imagine doing it "on the fly".
my company does not pay me enough to hyper scan my phone for teams/outlook, nor does my interest in "task/notification x" trump my desire to not have my car in the shop for weeks.
Different strokes I guess. I'm sure you're a safe driver all things considered.
Perhaps not while you’re not moving, but when you suddenly realise that the traffic light has changed to green and move off in a rush while distracted without having been monitoring the traffic, don’t you think that it’s more likely you’ll be hit by the truck that rolled through the lights as it turned red?
I'm comparing someone getting off on reporting people to the authorities to people who got off on reporting people to the authorities. It's the same self-righteous attitude either way.
Other drivers are doing dangerous actions. For example, the embedded video in the article showed a driver crash into his bicycle as he crossed the street. That driver then departed the scene. Hit and run is culturally and legally offensive in the UK and the rest of the OECD.
I live in the west side of San Francisco, and we may get a subway station by 2050 if we're exceptionally lucky. I'd rather have self-driving cars this decade, please.
reply