s/rfc9700/oauth-2.1/g

Author: pcarleton

docs/specification/draft/basic/authorization.mdx

@@ -255,15 +255,14 @@ Servers **MUST** return appropriate HTTP status codes for authorization errors:
 
 ## 3. Security Considerations
 
-Implementations **MUST** follow OAuth 2.1 security best practices. Refer to
-[RFC9700](https://datatracker.ietf.org/doc/html/rfc9700) for details.
+Implementations **MUST** follow OAuth 2.1 security best practices as laid out in [Section 7. Security Considerations](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#name-security-considerations).
 
 ### 3.1 Token Theft
 Attackers who obtain tokens stored by the client, or tokens cached or logged on the server can access protected resources with
 requests that appear legitimate to resource servers.
 
 Clients **MUST** implement secure token storage and follow OAuth 2.0 best practices,
-as outlined in [RFC 9700](https://datatracker.ietf.org/doc/html/rfc9700).
+as outlined in [OAuth 2.1, section 7.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-7.1).
 
 MCP authorization servers SHOULD enforce token expiration and rotation to limit the window of exploitation.
 
@@ -278,7 +277,7 @@ Specifically:
 
 ### 3.3 Authorization Code Protection
 
-An attacker who has gained access to an authorization code contained in an authorization response can try to redeem the authorization code for an access token or otherwise make use of the authorization code. (Further described in [RFC 9700 Section 4.5](https://www.rfc-editor.org/rfc/rfc9700.html#name-authorization-code-injectio))
+An attacker who has gained access to an authorization code contained in an authorization response can try to redeem the authorization code for an access token or otherwise make use of the authorization code. (Further described in [OAuth 2.1, section 7.5](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-7.5))
 
 MCP 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). PKCE helps  prevent authorization code interception attacks by requiring clients to create a secret verifier-challenge pair, ensuring that only the original requestor can exchange an authorization code for tokens.
 
@@ -293,4 +292,4 @@ Authorization servers **MUST** validate exact redirect URIs against pre-register
 MCP clients **SHOULD** use and verify state parameters in the authorization code flow
 and discard any results that do not include or have a mis-match with the original state.
 
-Authorization servers **MUST** take precautions to prevent redirecting user agents to untrusted URI's, following suggestions laid out in [RFC 9700 Section 4.11.2](https://www.rfc-editor.org/rfc/rfc9700.html#section-4.11.2)
+Authorization servers **MUST** take precautions to prevent redirecting user agents to untrusted URI's, following suggestions laid out in [OAuth 2.1, Section 7.12.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-7.12.2)