feedback

Author: marianogonzalez

docs/specification/2025-03-26/basic/authorization.md

@@ -54,17 +54,18 @@ while maintaining simplicity:
 OAuth specifies different flows or grant types, which in essence, are different ways of obtaining an access token.
 Each of these targets different use cases and scenarios.
 
-This specification focuses on two authorization scenarios:
+MCP servers **SHOULD** support the OAuth grant types that better align with the intended audience. For instance:  
 
-1. User to system: The client is operated by the end user (a human), allowing the client to operate on the user's behalf.
-   * For instance, an agent calls an MCP tool to get the weather forecast at a particular location. This tool is backed by a secure weather service with usage quotas. The user will first authenticate with the weather service, allowing the agent to query it on the user's behalf.  
+1. Authorization Code: Useful when the client is acting on behalf of a (human) end user. 
+   * For instance, an agent calls an MCP tool implemented by a SaaS system.    
 2. System to system: The client is another application (not a human)
-   * For instance, an agent calls a secure MCP tool to check inventory at a specific store.  
+   * For instance, an agent calls a secure MCP tool to check inventory at a specific store. No need to impersonate the end user.  
 
-**NOTE**: For simplicity’s sake, the following examples will assume the MCP server to also function as the authorization server. However, 
-in a real implementation the authorization server may be deployed as its own distinct service.
 
-### 2.2 OAuth 2.1 User to System through the Authorization Code Grant Type
+### 2.2 Example: OAuth 2.1 flow for the Authorization Code Grant Type (User to system)
+
+**NOTE**: For simplicity’s sake, the following examples will assume the MCP server to also function as the authorization server. However, 
+in real implementations the authorization server may be deployed as its own distinct service.
 
 A human user completes the OAuth flow through a web browser, obtaining an access token that identifies them personally and allows the 
 client to act on their behalf.  
@@ -97,32 +98,8 @@ sequenceDiagram
     C->>M: MCP Request with Access Token
     Note over C,M: Begin standard MCP message exchange
 ```
-### 2.3 OAuth 2.1 System to System through the Client Credentials Grant Type
-
-In this case, the client acts not in behalf of a human user but a system. Therefore, the access token is obtained by only sharing the client 
-credentials and doesn't require browser interaction. 
-
-When authorization is required and not yet proven by the client, servers **MUST** respond
-with _HTTP 401 Unauthorized_.
-
-Clients initiate the
-[OAuth 2.1 IETF DRAFT](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#name-client-credentials-grant)
-Client Credentials flow after receiving the _HTTP 401 Unauthorized_.
-
-```mermaid
-sequenceDiagram
-    participant C as Client
-    participant M as MCP Server
-
-    C->>M: MCP Request
-    M->>C: HTTP 401 Unauthorized
-    C->>M: Token Request with client_id + client_secret
-    M->>C: Access Token (+ Refresh Token)
-    C->>M: MCP Request with Access Token
-    Note over C,M: Begin standard MCP message exchange
-```
 
-### 2.4 Server Metadata Discovery
+### 2.2 Server Metadata Discovery
 
 For server capability discovery: