I am very curious how many MCP servers will actually implement all of this:

"MCP authorization today is built around a person approving access in a browser. That works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present, or delegating narrower authority to sub-agents. We want MCP servers to have a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long-lived tokens.

The work here covers finalizing Demonstrating Proof of Possession (DPoP) and driving its adoption, and defining an opinionated path for agent identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange. We will also continue to grow our engagement with the OAuth standards bodies, including the IETF OAuth and WIMSE working groups, to help the underlying standards evolve with the building blocks that agent identity needs."

▲

zackify an hour ago | parent | next [-]

I think the spec overcomplicates everything honestly. Its not that hard to add a long running auth token and put it in the MCP config as a header to send along and then avoid all the extra special rules.

"Oh no it's a long lived token that's bad"

Put it in a secret manager like 1pw cli and now start an agent...

	▲	danappelxx 22 minutes ago \| parent [-]
		How does the agent auth with 1pw? How do you give it access to only the credentials it needs, with an approval flow and revocation? Who renews the token? You’ll likely end up reinventing something pretty close to what MCP is building towards. Authn/authz is one of those things that can be really simple for pointed use cases but gets really complex when you need to support everything.

▲

_puk an hour ago | parent | prev | next [-]

Authorization for sub-entities is what is needed.

Having to define what an agent can do when it identifies on my behalf is cumbersome, especially when you start to get specialised agents.

Pattern based would be too easy for AI to game, but there's got to be a service independent way to limit permissions based on role.

I am Jack's right ear - awesome you get to hear stuff.

I am jack's right hand - great you get to input stuff.

	▲	kelseyfrog 41 minutes ago \| parent [-]
		I am Jack's synaesthesia.

▲

alasano 2 hours ago | parent | prev | next [-]

Hopefully quite a few.

I really love the idea of fully enabled agents and being able to cut down on human in the loop moments.

Things like https://projects.dev/ for example.

A ton of security problems and others to solve but it's still where I want the future of all this to go.

▲

jstummbillig 2 hours ago | parent | prev | next [-]

Why, directionally all of them. What they say is obviously true. Having to manually click things in the browser is a bottleneck and will be less and less acceptable for serious users.

And the individual work attached to making that transition will be done by agents.

▲

aliasxneo 40 minutes ago | parent | prev | next [-]

I've been working on a protocol that promises all of that and more. We're currently targeting a NOSTR/Buzz demo in the coming week as a proof of concept.

▲

gz5 2 hours ago | parent | prev | next [-]

agree. it seems there are two streams and they could diverge or converge?

1. workloads use existing credentials support RFC 7523 and OIDC discovery, 'trust the trust (credentials) which has already been established'. basically extend current dominant NHI paradigm.

2. DPoP mandate a signed proof for each request. so tie credential to a client-held key and specific request detail or context. viable to do at scale with #1, or does it diverge (e.g. because most #1 methods as most are not designed for DPoP?

	▲	maxwellg 40 minutes ago \| parent [-]
		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.

▲

bandofthehawk 2 hours ago | parent | prev | next [-]

Even now, the mcp server itself doesn't have to implement all of the possible security options. You can use something like agentgateway to act as an auth proxy for your mcp servers.

▲

huksley 2 hours ago | parent | prev [-]

Such an example of overengineering, why not just use OAuth?

	▲	dayjah an hour ago \| parent \| next [-]
		WIF works far better when you don’t want humans in the loop. For example, we’d do our development on cloud instances, those have identity linked to our humans via our IdP. Our IdP governs all access, for example: it lets devs use Datadog. If an agentic workflow needs Datadog access and the MCP requests OAuth that slows the loop down. At the same time, we don’t want Service Accounts everywhere because we need to be able to answer “who” a lot for compliance reasons.
	▲	brookst 2 hours ago \| parent \| prev [-]
		Oauth assumes interactivity