Add registry authorization specification (#756)

Add a standardized OAuth 2.1-based authentication specification for MCP
sub-registries, aligned with the MCP Authorization Specification.

This enables:
- Private registry entries with access control
- Permission-based server visibility
- Client code reuse (clients can use their existing MCP auth
implementation)

The spec is intended for downstream sub-registries. The official
registry remains public for reading.

Fixes #751

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: domdomegg

docs/reference/README.md

@@ -5,6 +5,7 @@ Technical specifications and quick lookups for the MCP Registry.
 ## API Reference
 
 - [Generic Registry API](./api/generic-registry-api.md)
+- [Registry Authorization](./api/registry-authorization.md)
 - [Official Registry API](./api/official-registry-api.md)
 
 ## server.json Reference

docs/reference/api/generic-registry-api.md

@@ -4,6 +4,7 @@ A standardized RESTful HTTP API for MCP registries to provide consistent endpoin
 
 Also see:
 - For guidance consuming the API, see the [consuming guide](../../guides/consuming/use-rest-api.md).
+- For authentication and authorization, see the [registry authorization specification](./registry-authorization.md).
 
 ## Browse the Complete API Specification
 
@@ -22,8 +23,8 @@ The official registry has some more endpoints and restrictions on top of this. S
 Server names and version strings should be URL-encoded in paths.
 
 ### Authentication
-- **Read operations**: No authentication required
-- **Write operations**: Registry-specific authentication (if supported)
+
+No authentication required by default. Subregistries may optionally require authentication following the [registry authorization specification](./registry-authorization.md).
 
 ### Content Type
 All requests and responses use `application/json`

docs/reference/api/registry-authorization.md

@@ -0,0 +1,26 @@
+# Registry Authorization
+
+MCP registries wishing to implement authentication SHOULD follow the [MCP Authorization Specification](https://modelcontextprotocol.io/specification/draft/basic/authorization).
+
+## How it works
+
+The registry acts as an OAuth 2.1 Resource Server, identical to how MCP servers work. This means:
+
+- **MCP clients** can reuse their existing MCP authorization implementation without any changes
+- **Registries** validate access tokens the same way MCP servers do
+- **Users** get a consistent login experience across MCP servers and registries
+
+## Registry-Specific Scopes
+
+Registries MAY use these scopes:
+
+- `mcp-registry:read` - List and read server metadata
+- `mcp-registry:write` - Publish, update, and delete servers
+
+These are recommendations - registries may use any set of scopes they deem sensible.
+
+Note that scopes only control what *types* of operations a user can perform. Registries should still apply user-level authorization to control which specific resources a user can access. For example, a user with `mcp-registry:write` might only be able to publish servers to namespaces they own, and may not have permissions to edit servers if the registry treats servers as immutable.
+
+## Official Registry Authentication
+
+The official modelcontextprotocol.io registry remains public for reading. For publishing servers, it uses a custom JWT-based authentication system for legacy reasons - see [its API spec](official-registry-api.md#authentication). This may change in future to align with the MCP Authorization Specification.