maxwellg

OIDC doesn't support IDP initiated flows for a reason - they're vulnerable to a class of attacks known as Login CSRF. An attacker can trick a victim into submitting an IdP-initiated authentication response linked to the attacker's account/session into the victim's browser profile on the SP. Think - Eve tricks Bob into signing in to Eve's PayPal account instead of Bob's. Bob, none the wiser, links his bank account. Eve now has access to Bob's funds.

IdPs that need to support an "IdP-initiated" user experience (like a portal or dashboard where users click an app icon) should instead have that icon link to a specific landing page on the SP that safely kicks off a standard, SP-initiated OIDC flow. IdP -> (SP -> IdP -> SP). Look at Okta's "Initiate Login URI" for an example of this.

Well, that’s a terrifying honeypot at best…

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.

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.

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.

> 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.

My personal favorite in this field is knex.js.

> 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.

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...

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.

Wouldn't a browser that doesn't execute JS also not execute the browser fingerprinting code in the first place?

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.

> The only issue it solves is if you want to bring your own tools to an existing chatbot.

That's a phenomenally important problem to solve for Anthropic, OpenAI, Google, and anyone else who wants to build generalized chatbots or assistants for mass consumer adoption. As well as any existing company or brand that owns data assets and wants to participate as an MCP Server. It's a chatbot app store standard. That's a huge market.

I've also had drivers do 50+ in residential areas, run red lights, play on their phones, cut off pedestrians in crosswalks, and once even park in a handicap spot at a gas station to buy cigs with me left in the back seat. If I was guaranteed a driver that could obey the traffic laws, I'd be happy to continue taking Ubers. That hasn't been the case.