The bmannconsulting.com website
bmann.ca
1[[ATProtocol]] and [[MCP]] are both picking OAuth as their authorization layer.
2
3In both scenarios, the need is for a wide set of distributed participants that need to authorize, who can't do pre-registration of all the different endpoints that are available.
4
5This is made possible by [[OAuth]] advancements like RFC 7591 [Dynamic Client Registration](https://oauth.net/2/dynamic-client-registration/):
6
7> The OAuth 2.0 Dynamic Client Registration extension provides a mechanism for dynamically or programmatically registering clients. This spec was derived from the OpenID Connect Dynamic Client Registration spec and is still compatible with OpenID Connect servers.
8
9And increased security with RFC 9449 [Demonstrating Proof-of-Possession (DPoP)](https://oauth.net/2/dpop/):
10
11> [DPoP](https://datatracker.ietf.org/doc/html/rfc9449), or Demonstrating Proof of Possession, is an extension that describes a technique to cryptographically bind access tokens to a particular client when they are issued. This is one of many attempts at improving the security of [Bearer Tokens](https://oauth.net/2/bearer-tokens/) by requiring the application using the token to prove possession of the same private key that was used to obtain the token.
12
13[[Aaron Parecki]] who works on the OAuth spec has also written [[Let's fix OAuth in MCP]] which goes into more details.
14
15---
16
17[[UCAN]] as a way to delegate capabilities also plays in this space. I am actively looking for high value use cases where these OAuth approaches do not solve the problem.
18
19