2e7108d366## Motivation and Context Docs currently don't have very clear organisation, and don't explain core flows. This fixes #89 (although we still might want to push these to `https://modelcontextprotocol.io/docs/`), based on the plan there. One minor change from that plan is that I merged tutorials and guides, because they ended up basically being duplicates which I thought would be annoying for us to keep in sync. Additionally in the Diátaxis framework, tutorials and guides are separated by whether they are focused on acquisition of skills (e.g. in a learning environment) or application of skills (e.g. in a work environment). I expect the registry to be something that will be used occasionally in a work environment, rather than a fundamental 'learnable' skill so I think it's reasonable not to have tutorials and fold these into guides. ## How Has This Been Tested? - Read through all these updated docs - Unit and integration tests (that previously used examples.md and use the schema) working - Ran `npx markdown-link-check .` to check all the links work ## Breaking Changes Links to old docs will break, but I don't think there are any. All internal links have been checked and updated. ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [x] Documentation update
45 lines
1.7 KiB
Markdown
45 lines
1.7 KiB
Markdown
# Namespacing and Security
|
|
|
|
Namespacing prevents name squatting, makes impersonation and typo squatting much harder, and provides attribution through domain-based identity.
|
|
|
|
For practical steps on how to authenticate for different namespaces, see the [publishing guide](../guides/publishing/publish-server.md#authenticate).
|
|
|
|
## Namespace Format
|
|
|
|
All server names follow reverse-DNS format. Examples:
|
|
- `io.github.alice/weather-server` - GitHub user `alice`
|
|
- `com.acme/internal-tool` - Company domain `acme.com`
|
|
- `org.nonprofit.research/data-analyzer` - Subdomain `research.nonprofit.org`
|
|
|
|
## Security Model
|
|
|
|
### Ownership Verification
|
|
|
|
Publishing to a namespace requires proving you control the corresponding identity:
|
|
|
|
**GitHub namespaces** (`io.github.*`):
|
|
- OAuth login to GitHub account/organization
|
|
- OIDC tokens in GitHub Actions workflows
|
|
|
|
**Domain namespaces** (`com.company.*`):
|
|
- DNS verification: TXT record at `_mcp-registry.company.com`
|
|
- HTTP verification: File at `https://company.com/.well-known/mcp-registry-auth`
|
|
|
|
## Namespace Scoping
|
|
|
|
Different authentication methods grant different namespace access:
|
|
|
|
**GitHub OAuth/OIDC**:
|
|
- `io.github.username/*` (for personal accounts)
|
|
- `io.github.orgname/*` (for organizations)
|
|
|
|
**DNS verification**:
|
|
- `com.domain/*` and `com.domain.*/*` (domain + all subdomains)
|
|
|
|
**HTTP verification**:
|
|
- `com.domain/*` only (exact domain, no subdomains)
|
|
|
|
## Limitations
|
|
|
|
**Domain ownership changes**: If someone loses/sells a domain, they lose publishing rights. Similarly if someone gains a domain, they gain publishing rights.
|
|
**Package validation**: Registry validates namespace ownership, but actual packages may still be malicious etc.
|