Update authorization.mdx

Author: localden

docs/specification/draft/basic/authorization.mdx

@@ -45,7 +45,7 @@ while maintaining simplicity:
 1. MCP authorization servers and MCP clients **SHOULD** support the OAuth 2.0 Dynamic Client Registration
    Protocol ([RFC7591](https://datatracker.ietf.org/doc/html/rfc7591)).
 
-1. MCP servers **MUST** implement [OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-13).
+1. MCP servers **MUST** implement [OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/rfc9728).
    MCP clients **MUST** use OAuth 2.0 Protected Resource Metadata for authorization server discovery.
 
 1. MCP authorization servers and MCP clients **MUST** implement OAuth 2.0 Authorization
@@ -82,22 +82,22 @@ authorization servers to MCP clients, as well as the discovery process through w
 clients can determine authorization server endpoints and supported capabilities.
 
 ### 2.3.1 Authorization Server Location
-MCP servers **MUST** implement the [OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-13)
+MCP servers **MUST** implement the [OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/rfc9728)
 specification to indicate the locations of authorization servers. The Protected Resource Metadata document returned by the MCP server **MUST** include
 the `authorization_servers` field containing at least one authorization server.
 
 The specific use of `authorization_servers` is beyond the scope of this specification; implementers should consult
-the [OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-13) documentation for
+the [OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/rfc9728) documentation for
 guidance on implementation details.
 
 Protected Resource Metadata documents can define multiple authorization servers. Most MCP server
 implementations will only require a single authorization server entry.
 
 The responsibility for selecting which authorization server to use lies with the MCP client, following the guidelines specified in
-[RFC9728 Section 7.6 "Authorization Servers"](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-13#name-authorization-servers).
+[RFC9728 Section 7.6 "Authorization Servers"](https://datatracker.ietf.org/doc/html/rfc9728#name-authorization-servers).
 
 MCP servers **MUST** use the HTTP header `WWW-Authenticate` when returning a _401 Unauthorized_ to indicate the location of the resource server metadata URL
-as described in [OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-13).
+as described in [OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/rfc9728).
 
 MCP clients **MUST** be able to parse `WWW-Authenticate` headers and respond appropriately to `HTTP 401 Unauthorized` responses from the MCP server.