MCP and Security OAuth2.0
This video is about MCP, ACP and A2A but later 11+ more protocols were found
MCP : Design goal is not Agent to Agent communication. But now it is happening.
- MCP is also wroking on Agent registry.
- It is different from A2A (1) No async message. (2) No renegotation.
- It is most adopted protocol.
- MCP has conquer world like React.js
These protocols are about : Discover, communicate, authenticate. over Internet
1. Inter-Agent protocol
1.1. Robot-Agent: CrowdES, SPPs (Saptial Population Protocol)
1.2. Human Computer: LOKA, PXP
1.3. System-Agent: Agent Protocol, LMOS (Large Model Operating System)
2. Context Oriented
2.1 MCP
Few Protocols
- Agents.JSON: File has API documentation for Agent. It is in OpenAPI format
- ANP: Agent Network Protocl. DID Distributed Identity (Blockchain-based)
- AITP: Blockchain. interaction cost.
- ACP (Agent Connect Protocol) by Cisco. Like A2A except it describe how to host and launch agent
- ACP (Agent Communication Protocol) by IBM. like MCP. It has registry = distributed Database of all agents. It is fork of MCP
- Agora: Natural language protocol. protocol upgrade itself.
All protocols lack
1. Regsitry
2. Authorizatoin
3. Reputation
https://www.youtube.com/watch?v=kqB_xML1SfA
=============================
OAuth is bunch of specs
OAuth2.0 = RFC6749 (2012) + RFC6750
OAuth2.1 = Authorization code + PKCE, Client credentials (may not useful), token in HTTP header, token in POST form body. Refer MCP Github issue 830
OpenID Connect is to identify user. It provides ID token
RFC 9728 : single URL for MCP server. It points to file that define meta data of server. it has auth server meta data as per RFC 8414.
RFC 7591 : Dynamic client registration to get client ID and Client secret.
https://www.youtube.com/watch?v=mYKMwZcGynw
==========================================
Keycloak and SPIRE
CNCF IAM Whitepaper. Yet to be published
5 principals
1. mTLS
2. OAuth2 token exchange RFC 8693
3. OIDC client authentication with SPIFEE SVID
4. OAuth2 token validation
5. PDP based Authorization decision.
PDP, PAP, PIP, PEP
- PAP (Policy Administration Point): The user interface/management layer where policies (rules) are created, stored, and managed centrally.
- PDP (Policy Decision Point): The "brain" that evaluates a user's request against policies from the PAP, using attributes from PIP, to return an "Allow" or "Deny" decision.
- PIP (Policy Information Point): Fetches necessary attributes (like user roles, data from databases/LDAP) needed by the PDP to make a decision.
- PEP (Policy Enforcement Point): Sits in front of the protected resource, intercepts requests, sends them to the PDP for a decision, and enforces that decision.
1. A user requests a resource (e.g., "view my profile").
2. The PEP intercepts the request and the OAuth access token.
3. The PEP sends the request details (user context from token, resource, action) to the PDP.
4. The PDP queries the PIP (e.g., a database) for attributes like user's department.
5. The PDP evaluates policies (managed by PAP) and returns "Permit/Deny" to the PEP.
6. The PEP allows or blocks the user's request based on the decision.
https://www.youtube.com/watch?v=S6qF0N5D1tM
