From 55e7e2b6bf01380c2e079307100c6960a2b62ef5 Mon Sep 17 00:00:00 2001
From: David Soria Parra <davidsp@anthropic.com>
Date: Tue, 28 Jan 2025 11:36:27 +0000
Subject: [PATCH 1/5] feat: add authentication specification for MCP HTTP+SSE
 transport

This adds a comprehensive authentication specification for the Model
Context Protocol that uses OAuth 2.1 for HTTP+SSE transport. The
spec defines the complete authentication flow including metadata
discovery, dynamic client registration, token handling, and security
best practices. It supports both localhost and non-localhost scenarios
with appropriate security measures.
---
 README.md                                     |   3 +-
 .../draft/basic/authorization.md              | 381 ++++++++++++++++++
 2 files changed, 383 insertions(+), 1 deletion(-)
 create mode 100644 docs/specification/draft/basic/authorization.md

diff --git a/README.md b/README.md
index bed47a3..96d6eed 100644
--- a/README.md
+++ b/README.md
@@ -3,7 +3,8 @@
 This repo contains the specification and protocol schema for the Model Context Protocol.
 
 The schema is [defined in TypeScript](schema/2024-11-05/schema.ts) first, but
-[made available as JSON Schema](schema/2024-11-05/schema.json) as well, for wider compatibility.
+[made available as JSON Schema](schema/2024-11-05/schema.json) as well, for wider
+compatibility.
 
 ## Contributing
 
diff --git a/docs/specification/draft/basic/authorization.md b/docs/specification/draft/basic/authorization.md
new file mode 100644
index 0000000..ce8ad9e
--- /dev/null
+++ b/docs/specification/draft/basic/authorization.md
@@ -0,0 +1,381 @@
+---
+title: Authorization
+type: docs
+weight: 15
+---
+
+{{< callout type="info" >}} **Protocol Revision**: draft {{< /callout >}}
+
+## 1. Introduction
+
+### 1.1 Purpose and Scope
+
+The Model Context Protocol provides authorization capabilities at the transport level,
+enabling MCP clients to make requests to restricted MCP servers on behalf of resource
+owners. This specification defines the authorization flow for HTTP+SSE transport.
+
+### 1.2 Protocol Requirements
+
+Authorization is **OPTIONAL** for MCP implementations. When supported:
+
+- Implementations using an HTTP+SSE transport **SHOULD** conform to this specification.
+- Implementations using an STDIO transport **SHOULD NOT** follow this specification, and
+  instead retrieve credentials from the environment.
+- Implementations using alternative transports **MUST** follow established security best
+  practices for their protocol.
+
+### 1.3 Standards Compliance
+
+This authorization mechanism is based on established specifications listed below, but
+implements a selected subset of their features to ensure security and interoperability
+while maintaining simplicity:
+
+- [OAuth 2.1 IETF DRAFT](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12)
+- OAuth 2.0 Authorization Server Metadata
+  ([RFC8414](https://datatracker.ietf.org/doc/html/rfc8414))
+- OAuth 2.0 Dynamic Client Registration Protocol
+  ([RFC7591](https://datatracker.ietf.org/doc/html/rfc7591))
+
+## 2. Authorization Flow
+
+### 2.1 Overview
+
+1. MCP auth implementations **MUST** implement OAuth 2.1 with appropriate security
+   measures for both confidential and public clients.
+
+2. MCP auth implementations **SHOULD** support the OAuth 2.0 Dynamic Client Registration
+   Protocol ([RFC7591](https://datatracker.ietf.org/doc/html/rfc7591)).
+
+3. MCP servers **SHOULD** and MCP clients **MUST** implement OAuth 2.0 Authorization
+   Server Metadata ([RFC8414](https://datatracker.ietf.org/doc/html/rfc8414)). Servers
+   that do not support Authorization Server Metadata **MUST** follow the default URI
+   schema.
+
+### 2.2 Basic OAuth 2.1 Authorization
+
+When authorization is required and not yet prooven 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)
+authorization flow after receiving the _HTTP 401 Unauthorized_.
+
+The following demonstrates the basic OAuth 2.1 for public clients using PKCE.
+
+```mermaid
+sequenceDiagram
+    participant B as User-Agent (Browser)
+    participant C as Client
+    participant M as MCP Server
+
+    C->>M: MCP Request
+    M->>C: HTTP 401 Unauthorized
+    Note over C: Generate code_verifier and code_challenge
+    C->>B: Open browser with authorization URL + code_challenge
+    B->>M: GET /authorize
+    Note over M: User logs in and authorizes
+    M->>B: Redirect to callback URL with auth code
+    B->>C: Callback with authorization code
+    C->>M: Token Request with code + code_verifier
+    M->>C: Access Token (+ Refresh Token)
+    C->>M: MCP Request with Access Token
+    Note over C,M: Begin standard MCP message exchange
+```
+
+### 2.3 Server Metadata Discovery
+
+For server capability discovery:
+
+- MCP clients _MUST_ follow the OAuth 2.0 Authorization Server Metadata protocol defined
+  in [RFC8414](https://datatracker.ietf.org/doc/html/rfc8414).
+- MCP server _SHOULD_ support follow the OAuth 2.0 Authorization Server Metadata
+  protocol.
+- MCP servers that do not support the OAuth 2.0 Authorization Server Metadata protocol,
+  _MUST_ support fallback URLs..
+
+The discovery flow is illustrated below:
+
+```mermaid
+sequenceDiagram
+    participant C as Client
+    participant S as Server
+
+    C->>S: GET /.well-known/oauth-authorization-server
+    alt Discovery Success
+        S->>C: 200 OK + Metadata Document
+        Note over C: Use endpoints from metadata
+    else Discovery Failed
+        S->>C: 404 Not Found
+        Note over C: Fall back to default endpoints
+    end
+    Note over C: Continue with authorization flow
+```
+
+#### 2.3.1 Server Metadata Discover Headers
+
+MCP clients _SHOULD_ include the header `MCP-Protocol-Version: <protocol-version>` during
+Server Metadata Discover to allow MCP server to respond based on MCP protocol version.
+
+For example: `MCP-Protocol-Version: 2024-11-05`
+
+#### 2.3.1 Fallbacks for Servers without Metadata Discovery
+
+For servers that do not implement OAuth 2.0 Authorization Server Metadata, clients
+**MUST** use the following default endpoint paths relative to the server's base URL:
+
+| Endpoint               | Default Path | Description                          |
+| ---------------------- | ------------ | ------------------------------------ |
+| Authorization Endpoint | /authorize   | Used for authorization requests      |
+| Token Endpoint         | /token       | Used for token exchange & refresh    |
+| Registration Endpoint  | /register    | Used for dynamic client registration |
+
+Clients **MUST** first attempt to discover endpoints via the metadata document before
+falling back to default paths. When using default paths, all other protocol requirements
+remain unchanged.
+
+### 2.3 Dynamic Client Registration
+
+MCP authorization makes use of the
+[OAuth 2.0 Dynamic Client Registration Protocol](https://datatracker.ietf.org/doc/html/rfc7591)
+to allow MCP clients to obtain OAuth client IDs without user interaction.
+
+- MCP clients **SHOULD** support
+  [OAuth 2.0 Dynamic Client Registration Protocol](https://datatracker.ietf.org/doc/html/rfc7591)
+- MCP servers with non-localhost redirect URIs **SHOULD** support Dynamic Client
+  Registration.
+- MCP servers with localhost redirect URIs **OPTIONALLY** support Dynamic Client
+  Registration.
+
+Note that are not required to support Dynamic Client Registration. MCP clients that do
+not support Dynamic Client Registration need to provide alternative ways to obtain a
+client id (and if applicable client secret).
+
+#### 2.3.1 Localhost Redirect URIs
+
+When using localhost redirect URIs (http://localhost:{port} or http://127.0.0.1:{port}),
+clients:
+
+- Dynamic registration is **OPTIONAL** (a client ID is not required)
+- **MAY** proceed directly to authorization
+- **MUST NOT** require client secrets
+
+This exception for localhost is explicitly supported by OAuth 2.1 for public clients and
+provides a secure flow through the combination of PKCE and localhost-only redirects.
+
+#### 2.3.2 Non-Localhost Redirect URIs
+
+For all other redirect URIs, MCP clients and servers **SHOULD** support dynamic client
+registration. This provides a standardized way for clients to automatically register with
+new servers, which is crucial for MCP because:
+
+- Clients cannot know all possible servers in advance
+- Manual registration would create friction for users
+- It enables seamless connection to new servers
+- Servers can implement their own registration policies
+
+### 2.4 Authorization Flow Steps
+
+The complete Authorization flow proceeds as follows:
+
+```mermaid
+sequenceDiagram
+    participant B as User-Agent (Browser)
+    participant C as Client
+    participant M as MCP Server
+
+    C->>M: GET /.well-known/oauth-authorization-server
+    alt Server Supports Discovery
+        M->>C: Authorization Server Metadata
+    else No Discovery
+        M->>C: 404 (Use default endpoints)
+    end
+
+    alt Non-Localhost Redirect URI
+        C->>M: POST /register
+        M->>C: Client Credentials
+    end
+
+    Note over C: Generate PKCE Parameters
+    C->>B: Open browser with authorization URL + code_challenge
+    B->>M: Authorization Request
+    Note over M: User /authorizes
+    M->>B: Redirect to callback with authorization code
+    B->>C: Authorization code callback
+    C->>M: Token Request + code_verifier
+    M->>C: Access Token + Refresh Token
+    C->>M: API Requests with Access Token
+```
+
+#### 2.4.1 Decision Flow Overview
+
+```mermaid
+flowchart TD
+    A[Start Auth Flow] --> B{Check Metadata Discovery}
+    B -->|Available| C[Use Metadata Endpoints]
+    B -->|Not Available| D[Use Default Endpoints]
+
+    C --> E{Check Redirect URI}
+    D --> E
+
+    E -->|Localhost| F[Skip Registration]
+    E -->|Non-localhost| G{Check Registration Endpoint}
+
+    G -->|Available| H[Perform Dynamic Registration]
+    G -->|Not Available| I[Alternative Registration Required]
+
+    F --> J[Start OAuth Flow]
+    H --> J
+    I --> J
+
+    J --> K[Generate PKCE Parameters]
+    K --> L[Request Authorization]
+    L --> M[User Authorization]
+    M --> N[Exchange Code for Tokens]
+    N --> O[Use Access Token]
+```
+
+### 2.5 Access Token Usage
+
+#### 2.5.1 Token Requirements
+
+Access token handling **MUST** conform to
+[OAuth 2.1 Section 5](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-5)
+requirements for resource requests. Specifically:
+
+1. MCP client **MUST** use the Authorization request header field
+   [Section 5.1.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-5.1.1):
+
+```
+Authorization: Bearer <access-token>
+```
+
+2. Access tokens **MUST NOT** be included in the URI query string
+
+Example request:
+
+```http
+GET /v1/contexts HTTP/1.1
+Host: mcp.example.com
+Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
+```
+
+#### 2.5.2 Token Handling
+
+Resource servers **MUST** validate access tokens as described in
+[Section 5.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-5.2).
+If validation fails, servers **MUST** respond according to
+[Section 5.3](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-5.3)
+error handling requirements. Invalid or expired tokens **MUST** receive a HTTP 401
+response.
+
+### 2.6 Security Considerations
+
+The following security requirements **MUST** be implemented:
+
+1. Clients **MUST** securely store tokens following OAuth 2.0 best practices
+2. Servers **SHOULD** enforce token expiration and rotation
+3. All authorization endpoints **MUST** be served over HTTPS
+4. Servers **MUST** validate redirect URIs to prevent open redirect vulnerabilities
+5. Redirect URIs **MUST** be either localhost URLs or HTTPS URLs
+
+### 2.7 Error Handling
+
+Servers **MUST** return appropriate HTTP status codes for authorization errors:
+
+| Status Code | Description  | Usage                                      |
+| ----------- | ------------ | ------------------------------------------ |
+| 401         | Unauthorized | Authorization required or token invalid    |
+| 403         | Forbidden    | Invalid scopes or insufficient permissions |
+| 400         | Bad Request  | Malformed authorization request            |
+
+### 2.8 Implementation Requirements
+
+1. Implementations **MUST** follow OAuth 2.1 security best practices
+2. PKCE is **REQUIRED** for all clients
+3. Token rotation **SHOULD** be implemented for enhanced security
+4. Token lifetimes **SHOULD** be limited based on security requirements
+
+### 2.9 Third-Party Authorization Flow
+
+#### 2.9.1 Overview
+
+MCP servers **MAY** support delegated authorization through third-party authorization
+servers. In this flow, the MCP server acts as both an OAuth client (to the third-party
+auth server) and an OAuth authorization server (to the MCP client).
+
+#### 2.9.2 Flow Description
+
+The third-party authorization flow comprises these steps:
+
+1. MCP client initiates standard OAuth flow with MCP server
+2. MCP server redirects user to third-party authorization server
+3. User authorizes with third-party server
+4. Third-party server redirects back to MCP server with authorization code
+5. MCP server exchanges code for third-party access token
+6. MCP server generates its own access token bound to the third-party session
+7. MCP server completes original OAuth flow with MCP client
+
+```mermaid
+sequenceDiagram
+    participant B as User-Agent (Browser)
+    participant C as MCP Client
+    participant M as MCP Server
+    participant T as Third-Party Auth Server
+
+    C->>M: Initial OAuth Request
+    M->>B: Redirect to Third-Party /authorize
+    B->>T: Authorization Request
+    Note over T: User authorizes
+    T->>B: Redirect to MCP Server callback
+    B->>M: Authorization code
+    M->>T: Exchange code for token
+    T->>M: Third-party access token
+    Note over M: Generate bound MCP token
+    M->>B: Redirect to MCP Client callback
+    B->>C: MCP authorization code
+    C->>M: Exchange code for token
+    M->>C: MCP access token
+```
+
+#### 2.9.3 Session Binding Requirements
+
+MCP servers implementing third-party authorization **MUST**:
+
+1. Maintain secure mapping between third-party tokens and issued MCP tokens
+2. Validate third-party token status before honoring MCP tokens
+3. Implement appropriate token lifecycle management
+4. Handle third-party token expiration and renewal
+
+#### 2.9.4 Security Considerations
+
+When implementing third-party authorization, servers **MUST**:
+
+1. Validate all redirect URIs
+2. Securely store third-party credentials
+3. Implement appropriate session timeout handling
+4. Consider security implications of token chaining
+5. Implement proper error handling for third-party auth failures
+
+## 3. Best Practices
+
+#### 3.1 Local clients as Public OAuth 2.1 Clients
+
+We strongly recommend that local clients implement OAuth 2.1 as public client:
+
+1. Utilizing code challenges (PKCE) for authorization requests to prevent interception
+   attacks
+2. Implementing secure token storage appropriate for the local system
+3. Following token refresh best practices to maintain sessions
+4. Properly handling token expiration and renewal
+
+#### 3.2 Authorization Metadata Discovery
+
+We strongly recommend, that all clients implement metadata discovery. This reduces the
+need for users to provide endpoints either manually or fallback to the defined defaults.
+
+#### 3.3 Dynamic Client Registration
+
+Since clients do not know the set of MCP servers in advance, we strongly recommend the
+implementation of dynamic client registration. This allows applications to automatically
+register with the MCP server, and removes the need for users to obtain client ids
+manually.

From 5c35d6dda5bf04b5c8c76352c9f7ee18d22b7a08 Mon Sep 17 00:00:00 2001
From: David Soria Parra <davidsp@anthropic.com>
Date: Wed, 29 Jan 2025 12:45:11 +0000
Subject: [PATCH 2/5] fix: review comments for authentication specification (PR
 #133)

---
 .../draft/basic/authorization.md              | 34 +++++++++----------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/docs/specification/draft/basic/authorization.md b/docs/specification/draft/basic/authorization.md
index ce8ad9e..1432a89 100644
--- a/docs/specification/draft/basic/authorization.md
+++ b/docs/specification/draft/basic/authorization.md
@@ -53,8 +53,8 @@ while maintaining simplicity:
 
 ### 2.2 Basic OAuth 2.1 Authorization
 
-When authorization is required and not yet prooven by the client, servers **MUST**
-respond with _HTTP 401 Unauthorized_.
+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)
@@ -88,10 +88,9 @@ For server capability discovery:
 
 - MCP clients _MUST_ follow the OAuth 2.0 Authorization Server Metadata protocol defined
   in [RFC8414](https://datatracker.ietf.org/doc/html/rfc8414).
-- MCP server _SHOULD_ support follow the OAuth 2.0 Authorization Server Metadata
-  protocol.
+- MCP server _SHOULD_ follow the OAuth 2.0 Authorization Server Metadata protocol.
 - MCP servers that do not support the OAuth 2.0 Authorization Server Metadata protocol,
-  _MUST_ support fallback URLs..
+  _MUST_ support fallback URLs.
 
 The discovery flow is illustrated below:
 
@@ -111,10 +110,11 @@ sequenceDiagram
     Note over C: Continue with authorization flow
 ```
 
-#### 2.3.1 Server Metadata Discover Headers
+#### 2.3.1 Server Metadata Discovery Headers
 
 MCP clients _SHOULD_ include the header `MCP-Protocol-Version: <protocol-version>` during
-Server Metadata Discover to allow MCP server to respond based on MCP protocol version.
+Server Metadata Discovery to allow the MCP server to respond based on the MCP protocol
+version.
 
 For example: `MCP-Protocol-Version: 2024-11-05`
 
@@ -143,10 +143,9 @@ to allow MCP clients to obtain OAuth client IDs without user interaction.
   [OAuth 2.0 Dynamic Client Registration Protocol](https://datatracker.ietf.org/doc/html/rfc7591)
 - MCP servers with non-localhost redirect URIs **SHOULD** support Dynamic Client
   Registration.
-- MCP servers with localhost redirect URIs **OPTIONALLY** support Dynamic Client
-  Registration.
+- MCP servers with localhost redirect URIs **MAY** support Dynamic Client Registration.
 
-Note that are not required to support Dynamic Client Registration. MCP clients that do
+Note that it is not required to support Dynamic Client Registration. MCP clients that do
 not support Dynamic Client Registration need to provide alternative ways to obtain a
 client id (and if applicable client secret).
 
@@ -155,9 +154,9 @@ client id (and if applicable client secret).
 When using localhost redirect URIs (http://localhost:{port} or http://127.0.0.1:{port}),
 clients:
 
-- Dynamic registration is **OPTIONAL** (a client ID is not required)
-- **MAY** proceed directly to authorization
-- **MUST NOT** require client secrets
+- Dynamic registration is **OPTIONAL** (a client ID is not required).
+- **MAY** proceed directly to authorization.
+- **SHOULD** be considered public clients and not store any clients secrets.
 
 This exception for localhost is explicitly supported by OAuth 2.1 for public clients and
 provides a secure flow through the combination of PKCE and localhost-only redirects.
@@ -202,7 +201,7 @@ sequenceDiagram
     M->>B: Redirect to callback with authorization code
     B->>C: Authorization code callback
     C->>M: Token Request + code_verifier
-    M->>C: Access Token + Refresh Token
+    M->>C: Access Token (+ Refresh Token)
     C->>M: API Requests with Access Token
 ```
 
@@ -360,7 +359,7 @@ When implementing third-party authorization, servers **MUST**:
 
 #### 3.1 Local clients as Public OAuth 2.1 Clients
 
-We strongly recommend that local clients implement OAuth 2.1 as public client:
+We strongly recommend that local clients implement OAuth 2.1 as a public client:
 
 1. Utilizing code challenges (PKCE) for authorization requests to prevent interception
    attacks
@@ -370,8 +369,9 @@ We strongly recommend that local clients implement OAuth 2.1 as public client:
 
 #### 3.2 Authorization Metadata Discovery
 
-We strongly recommend, that all clients implement metadata discovery. This reduces the
-need for users to provide endpoints either manually or fallback to the defined defaults.
+We strongly recommend that all clients implement metadata discovery. This reduces the
+need for users to provide endpoints manually or clients to fallback to the defined
+defaults.
 
 #### 3.3 Dynamic Client Registration
 

From 00742bd245596cf3890c49939f753dbcbf29fe87 Mon Sep 17 00:00:00 2001
From: Mahesh Murag <mahesh@anthropic.com>
Date: Mon, 3 Feb 2025 16:32:15 -0500
Subject: [PATCH 3/5] update

---
 site/layouts/index.html | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/site/layouts/index.html b/site/layouts/index.html
index 675e2aa..2001ca2 100644
--- a/site/layouts/index.html
+++ b/site/layouts/index.html
@@ -3,12 +3,12 @@
 <head>
     <meta charset="utf-8">
     <title>Model Context Protocol Specification</title>
-    <script>window.location.replace("/specification/");</script>
-    <meta http-equiv="refresh" content="0; url=/specification/">
-    <link rel="canonical" href="/specification/">
+    <script>window.location.replace("/latest");</script>
+    <meta http-equiv="refresh" content="0; url=/latest">
+    <link rel="canonical" href="/latest">
 </head>
 <body>
     <h1>Model Context Protocol Specification</h1>
-    <p>Redirecting to <a href="/specification/">specification</a>...</p>
+    <p>Redirecting to <a href="/latest">specification</a>...</p>
 </body>
 </html>
\ No newline at end of file

From 5b4a6e15acd7fbab292003cb29b566d39c137378 Mon Sep 17 00:00:00 2001
From: Zachary Lee <w.zachary.lee@gmail.com>
Date: Wed, 5 Feb 2025 17:33:06 -0500
Subject: [PATCH 4/5] update

---
 docs/specification/CLAUDE.md | 117 -----------------------------------
 1 file changed, 117 deletions(-)
 delete mode 100644 docs/specification/CLAUDE.md

diff --git a/docs/specification/CLAUDE.md b/docs/specification/CLAUDE.md
deleted file mode 100644
index bb8d9e7..0000000
--- a/docs/specification/CLAUDE.md
+++ /dev/null
@@ -1,117 +0,0 @@
-# Documentation Style Guide
-
-## General Structure
-
-1. Every markdown file MUST start with a frontmatter section containing:
-
-   ```yaml
-   ---
-   title: [Page Title]
-   type: docs
-   weight: [numeric weight for ordering]
-   ---
-   ```
-
-2. After frontmatter, include the protocol revision callout:
-   ```markdown
-   {{< callout type="info" >}} **Protocol Revision**: {{< param protocolRevision >}}
-   {{< /callout >}}
-   ```
-
-## Writing Style
-
-1. Technical Requirements
-
-   - Use RFC 2119 keywords (MUST, SHOULD, MAY) in all capitals when specifying
-     requirements
-   - Each requirement should be clear and unambiguous
-   - Include code examples for technical concepts
-
-2. Code Blocks
-
-   - Use TypeScript for interface and type definitions
-   - Include language identifier in code fence (```typescript)
-   - Format code consistently with 2-space indentation
-
-3. Lists and Structure
-
-   - Use bullet points for related items without hierarchy
-   - Use numbered lists for sequential steps or prioritized items
-   - Indent sub-bullets consistently
-
-4. Technical Accuracy
-   - All code examples must be syntactically correct
-   - Reference official specifications when applicable
-   - Include links to related documentation
-
-## Content Organization
-
-1. Page Structure
-
-   - Start with a brief overview/introduction
-   - Use clear H2 (##) and H3 (###) headings
-   - Group related concepts under common headings
-   - End with relevant links or next steps if applicable
-
-2. Section Hierarchy
-
-   - Use H1 (#) for document title only
-   - Use H2 (##) for major sections
-   - Use H3 (###) for subsections
-   - Avoid going deeper than H4
-
-3. Cross-References
-   - Use relative links for internal references
-   - Use absolute links for external references
-   - Include hover text for non-obvious links
-
-## Formatting Conventions
-
-1. Code and Technical Terms
-
-   - Use backticks for inline code and technical terms
-   - Use code blocks for multi-line code examples
-   - Use proper syntax highlighting
-
-2. Emphasis
-
-   - Use bold (\*\*) for important terms and concepts
-   - Use italics (\*) sparingly, mainly for emphasis
-   - Avoid underlining
-
-3. Tables
-   - Use tables for structured data comparison
-   - Include header row
-   - Align columns consistently
-
-## Special Elements
-
-1. Callouts
-
-   - Use for important notices or version information
-   - Include type (info, warning, etc.)
-   - Keep content concise
-
-2. Cards
-   - Use for navigation sections
-   - Include relevant icons
-   - Keep titles short and descriptive
-
-## Language and Tone
-
-1. Voice
-
-   - Use active voice
-   - Be direct and concise
-   - Maintain technical precision
-
-2. Terminology
-
-   - Use consistent terminology throughout
-   - Define technical terms on first use
-   - Follow industry standard terminology
-
-3. Audience
-   - Write for technical implementers
-   - Assume familiarity with basic concepts
-   - Explain complex concepts clearly

From 1880e06a0de995f8feb0fe76ca6ea5a908176304 Mon Sep 17 00:00:00 2001
From: Allen Zhou <46854522+allenzhou101@users.noreply.github.com>
Date: Tue, 11 Feb 2025 11:18:10 -0800
Subject: [PATCH 5/5] Add reference to Authorization spec in Base Protocol page

---
 docs/specification/draft/basic/_index.md | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/docs/specification/draft/basic/_index.md b/docs/specification/draft/basic/_index.md
index ef756d6..b05c729 100644
--- a/docs/specification/draft/basic/_index.md
+++ b/docs/specification/draft/basic/_index.md
@@ -53,14 +53,19 @@ See the following pages for more details on the different components:
 
 ## Auth
 
-Authentication and authorization are not currently part of the core MCP specification,
-but we are considering ways to introduce them in future. Join us in
+MCP provides an [Authorization]({{< ref "/specification/draft/basic/authorization" >}})
+framework for HTTP+SSE transport. Implementations using HTTP+SSE transport **SHOULD**
+conform to this specification, whereas implementations using STDIO transport **SHOULD
+NOT** follow this specification, and instead retrieve credentials from the environment.
+
+Additionally, clients and servers **MAY** negotiate their own custom authentication and
+authorization strategies.
+
+For further discussions and contributions to the evolution of MCP’s auth mechanisms, join
+us in
 [GitHub Discussions](https://github.com/modelcontextprotocol/specification/discussions)
 to help shape the future of the protocol!
 
-Clients and servers **MAY** negotiate their own custom authentication and authorization
-strategies.
-
 ## Schema
 
 The full specification of the protocol is defined as a