scoot implementation requirements down

Author: pcarleton

docs/specification/draft/basic/authorization.mdx

@@ -257,31 +257,23 @@ Servers **MUST** return appropriate HTTP status codes for authorization errors:
 | 403         | Forbidden    | Invalid scopes or insufficient permissions |
 | 400         | Bad Request  | Malformed authorization request            |
 
-### 2.9 Implementation Requirements
-
-1. Implementations **MUST** follow OAuth 2.1 security best practices
-1. PKCE is **REQUIRED** for all clients
-1. MCP clients or MCP servers that also act as an AS
-    1. **SHOULD** implement token rotation for enhanced security
-    1. Token lifetimes **SHOULD** be limited based on security requirements
-
 
 ## 3. Security Considerations
 
 ### 3.1 Client Token Theft
 An attacker who gains access to a client's stored tokens can make unauthorized requests to resource servers. Clients MUST securely store tokens following OAuth 2.0 best practices.
 
 ### 3.2 Server Token Theft
-An attacker who compromises an authorization server may access stored tokens. Servers SHOULD enforce token expiration and rotation to limit the window of exploitation.
+An attacker who compromises an MCP authorization server may access stored tokens. MCP authorization servers SHOULD enforce token expiration and rotation to limit the window of exploitation.
 
 ### 3.3 Token Interception
-An attacker positioned between clients and servers can intercept tokens transmitted over insecure connections. All authorization endpoints MUST be served over HTTPS.
+An attacker positioned between clients and servers can intercept tokens transmitted over insecure connections. All authorization endpoints MUST be served over HTTPS. Clients MUST implement PKCE according to [OAuth 2.1 section 7.5.2](https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-12.html#name-countermeasures)
 
 ### 3.4 Open Redirection
-An attacker may craft malicious redirect URIs to direct users to phishing sites. Servers MUST validate redirect URIs against pre-registered values to prevent redirection attacks.
+An attacker may craft malicious redirect URIs to direct users to phishing sites. MCP authorization servers MUST validate redirect URIs against pre-registered values to prevent redirection attacks.
 
 ###  3.5 Insecure Redirect URIs
 An attacker can capture data transmitted to non-secure endpoints. Redirect URIs MUST be either localhost URLs or HTTPS URLs to prevent token and code interception.
 
 ### 3.6 Confused Deputy Problem
-An attacker can exploit OAuth proxy configurations that share 3rd party client credentials across multiple users. When an MCP server fronts another authorization server that does not support dynamic client registration, the MCP uses a static client_id with the backing service. If the backing service sets cookies after user authorization, an attacker can craft malicious authorization requests that bypass consent screens for previously authorized applications. MCP servers using a static client_id for a backing service MUST require explicit approval for each newly registered dynamic clients prior to forwarding requests to the backing authorization server for user consent.
+An attacker can exploit OAuth proxy configurations that share 3rd party client credentials across multiple users. When an MCP server fronts another authorization server that does not support dynamic client registration, the MCP uses a static client_id with the backing service. If the backing service sets cookies after user authorization, an attacker can craft malicious authorization requests that bypass consent screens for previously authorized applications. MCP servers using a static client_id for a backing service MUST require explicit approval for each newly registered dynamic client prior to forwarding requests to the backing authorization server for user consent.