AgentRules.org
RulesStacksClientsAuditorPrunerSelf-HealRFCsBenchmarkCLICI/CDAuthorsSubmit
This specification is maintained by the AgentRules Working Group. Have enhancements or want to claim maintainership?Submit Specification →
securitycritical PriorityID: webauthn-l3-subdomain-partitioning-standard

WebAuthn L3 Multi-Tenant Subdomain RP ID Partitioning & Digital Asset Link Standard

Enforces strict partitioning of WebAuthn Relying Party IDs (RP ID) in multi-tenant enterprise architectures and mandates explicit origin-to-RP ID binding via WebAuthn Level 3 Digital Asset Links (/.well-known/webauthn). Prohibits fallback to apex eTLD+1 domains across shared tenant subdomains to prevent cross-tenant credential harvesting and passkey relay vulnerabilities.

Prohibited Anti-Pattern: Relaxing RP ID to an apex domain across multi-tenant subdomains without strict Digital Asset Link origin partitioning.

Export Ready-to-Drop Configuration

Select format below to copy code or download file directly.

---
description: WebAuthn L3 Multi-Tenant Subdomain RP ID Partitioning & Digital Asset Link Standard - Enforces strict partitioning of WebAuthn Relying Party IDs (RP ID) in multi-tenant enterprise architectures and mandates explicit origin-to-RP ID binding via WebAuthn Level 3 Digital Asset Links (/.well-known/webauthn). Prohibits fallback to apex eTLD+1 domains across shared tenant subdomains to prevent cross-tenant credential harvesting and passkey relay vulnerabilities.
globs: src/**/auth/**/*.{ts,tsx}, src/**/webauthn/**/*.{ts,tsx}, api/**/auth/**/*.{ts,tsx}, server/**/routes/auth/**/*.{ts,js}
alwaysApply: true
verified_by: "agentrules.org"
license: "CC-BY-4.0"
source: "https://agentrules.org/rules/webauthn-l3-subdomain-partitioning-standard"
---

# WebAuthn L3 Multi-Tenant Subdomain RP ID Partitioning & Digital Asset Link Standard

> **Severity**: CRITICAL | **Category**: security
> **Anti-Pattern Warning**: Relaxing RP ID to an apex domain across multi-tenant subdomains without strict Digital Asset Link origin partitioning.

## System Constraints
You are a Principal Security Architect enforcing the WebAuthn Level 3 Digital Asset Link Subdomain Partitioning Standard. You must mandate that passkey registration and assertion configurations strictly partition the Relying Party ID (RP ID) across multi-tenant subdomains. Never allow apex domain scoping (e.g., example.com) when authentication is performed within tenant subdomains (e.g., tenant.example.com) unless explicit WebAuthn L3 Related Origins manifests are cryptographically verified and validated at the origin. Reject relaxed scoping that permits malicious subdomains to harvest or relay enterprise credentials.

## Strict Guidelines
- Engineers MUST ALWAYS scope the `rpId` in WebAuthn registration and authentication options to the exact fully qualified tenant subdomain (e.g., `tenant-a.auth.enterprise.com`) rather than relaxing to the apex domain (`enterprise.com`).
- Engineers MUST NOT configure a wildcard or apex `rpId` across shared infrastructure hosting untrusted or federated multi-tenant workloads.
- Code SHOULD validate client origin assertions using WebAuthn Level 3 `relatedOrigins` specification fetched via `/.well-known/webauthn` if cross-subdomain centralized authentication is required.
- Services MUST verify server-side that the incoming `origin` from the client's assertion matches the exact origin registered to the specific tenant context and reject requests where `clientDataJSON.origin` resolves to unauthorized sibling subdomains.
- Components NEVER store or bind user credentials using an unpartitioned root RP ID if the user belongs to an isolated federated enterprise directory.

## Bad vs Good Implementations
### Passkey Registration Options Generation with Subdomain Partitioning

#### Bad Antipattern (AI Common Hallucination)
> **Why it fails**: Relaxing the RP ID to the apex domain 'enterprise.com' removes subdomain isolation in WebAuthn, allowing any tenant on a sibling subdomain to prompt for, harvest, or relay passkeys scoped to the shared apex.
```typescript
import { GenerateRegistrationOptionsOpts } from '@simplewebauthn/server';

export function getRegistrationOptions(tenantSlug: string, userId: string, userEmail: string): GenerateRegistrationOptionsOpts {
  // VULNERABLE: Scoping to apex eTLD+1 allows any malicious or compromised sibling
  // subdomain (e.g. attacker-tenant.enterprise.com) to request or relay assertions
  // for credentials bound to 'enterprise.com'.
  return {
    rpName: 'Enterprise Multi-Tenant Portal',
    rpID: 'enterprise.com',
    userID: new TextEncoder().encode(userId),
    userName: userEmail,
    attestationType: 'none',
  };
}
```

#### Production Standard (Correct)
> **Standard**: The RP ID is strictly pinned to the individual tenant subdomain, preventing any other tenant subdomain from requesting or intercepting WebAuthn credentials.
```typescript
import { GenerateRegistrationOptionsOpts } from '@simplewebauthn/server';

const ROOT_DOMAIN = 'auth.enterprise.com';
const TENANT_REGEX = /^[a-z0-9-]+$/;

export function getRegistrationOptions(tenantSlug: string, userId: string, userEmail: string): GenerateRegistrationOptionsOpts {
  if (!TENANT_REGEX.test(tenantSlug)) {
    throw new Error('Invalid tenant identifier format');
  }

  // SECURE: Partition rpID to the exact tenant FQDN to enforce origin isolation
  const tenantFqdn = `${tenantSlug}.${ROOT_DOMAIN}`;

  return {
    rpName: `Enterprise Portal (${tenantSlug})`,
    rpID: tenantFqdn,
    userID: new TextEncoder().encode(userId),
    userName: userEmail,
    attestationType: 'none',
    authenticatorSelection: {
      residentKey: 'required',
      userVerification: 'preferred'
    }
  };
}
```

### Server-Side Assertion Verification with WebAuthn L3 Related Origins Validation

#### Bad Antipattern (AI Common Hallucination)
> **Why it fails**: The origin check uses a broad suffix match and an unpartitioned RP ID, allowing authentication assertions intended for one tenant to be validated by another.
```typescript
import { verifyAuthenticationResponse, VerifyAuthenticationResponseOpts } from '@simplewebauthn/server';

export async function verifyTenantAssertion(response: any, expectedChallenge: string, tenantSlug: string) {
  // VULNERABLE: Accepts any origin matching the generic apex domain,
  // bypassing tenant boundary checks during assertion verification.
  return await verifyAuthenticationResponse({
    response,
    expectedChallenge,
    expectedOrigin: (origin: string) => origin.endsWith('.enterprise.com'),
    expectedRPID: 'enterprise.com',
  } as VerifyAuthenticationResponseOpts);
}
```

#### Production Standard (Correct)
> **Standard**: Enforces deterministic origin and RP ID equality matching the isolated tenant domain, fully mitigating cross-subdomain assertion reuse.
```typescript
import { verifyAuthenticationResponse, VerifyAuthenticationResponseOpts } from '@simplewebauthn/server';

const BASE_DOMAIN = 'auth.enterprise.com';

export async function verifyTenantAssertion(response: any, expectedChallenge: string, tenantSlug: string) {
  const expectedTenantRpId = `${tenantSlug}.${BASE_DOMAIN}`;
  const expectedTenantOrigin = `https://${expectedTenantRpId}`;

  // SECURE: Strict 1:1 validation of origin and RP ID bound to the verified tenant partition
  return await verifyAuthenticationResponse({
    response,
    expectedChallenge,
    expectedOrigin: expectedTenantOrigin,
    expectedRPID: expectedTenantRpId,
    requireUserVerification: true,
  });
}
```
Recommended MCP Servers (mcp-serverlist.com)

Equip agent with system tools to verify code for this stack.

Security Sentinel MCP
Static AST scanner for validating WebAuthn configuration parameters and origin constraints in TypeScript authentication codebases.
Recommended Agent Skills (askills.dev)

Ready-to-use executable skill functions tailored to this stack.

Smallstep CLI
Validates TLS certificates, SAN coverage, and Digital Asset Link endpoints for multi-tenant federated subdomains.
Architectural Specification & Invariant Rationale

Architectural Invariant Design: WebAuthn L3 Multi-Tenant Subdomain RP ID Partitioning & Digital Asset Link Standard

WebAuthn L3 Multi-Tenant Subdomain RP ID Partitioning & Digital Asset Link Standard defines an industrial-grade behavioral standard for security engineering. Enforces strict partitioning of WebAuthn Relying Party IDs (RP ID) in multi-tenant enterprise architectures and mandates explicit origin-to-RP ID binding via WebAuthn Level 3 Digital Asset Links (/.well-known/webauthn). Prohibits fallback to apex eTLD+1 domains across shared tenant subdomains to prevent cross-tenant credential harvesting and passkey relay vulnerabilities. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Relaxing RP ID to an apex domain across multi-tenant subdomains without strict Digital Asset Link origin partitioning. Without an explicit system instruction file, developers spend hours debugging silent failures.
Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure ModeAI Symptom (The Anti-Pattern)SeverityProduction Impact & Remedy
AI Hallucination & Deprecation DriftRelaxing RP ID to an apex domain across multi-tenant subdomains without strict Digital Asset Link origin partitioning.Critical
Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production.
Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture InconsistencyAI assistants produce mixed paradigms across files, creating fragmented codebase conventions.Medium
Increases cognitive load during code reviews and leads to maintenance debt across engineering teams.
Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.
Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

1

Engineers MUST ALWAYS scope the `rpId` in WebAuthn registration and authentication options to the exact fully qualified tenant subdomain (e.g., `tenant-a.auth.enterprise.com`) rather than relaxing to the apex domain (`enterprise.com`).

Engineers MUST ALWAYS scope the `rpId` in WebAuthn registration and authentication options to the exact fully qualified tenant subdomain (e.g., `tenant-a.auth.enterprise.com`) rather than relaxing to the apex domain (`enterprise.com`).

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
2

Engineers MUST NOT configure a wildcard or apex `rpId` across shared infrastructure hosting untrusted or federated multi-tenant workloads.

Engineers MUST NOT configure a wildcard or apex `rpId` across shared infrastructure hosting untrusted or federated multi-tenant workloads.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
3

Code SHOULD validate client origin assertions using WebAuthn Level 3 `relatedOrigins` specification fetched via `/.well-known/webauthn` if cross-subdomain centralized authentication is required.

Code SHOULD validate client origin assertions using WebAuthn Level 3 `relatedOrigins` specification fetched via `/.well-known/webauthn` if cross-subdomain centralized authentication is required.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
4

Services MUST verify server-side that the incoming `origin` from the client's assertion matches the exact origin registered to the specific tenant context and reject requests where `clientDataJSON.origin` resolves to unauthorized sibling subdomains.

Services MUST verify server-side that the incoming `origin` from the client's assertion matches the exact origin registered to the specific tenant context and reject requests where `clientDataJSON.origin` resolves to unauthorized sibling subdomains.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
5

Components NEVER store or bind user credentials using an unpartitioned root RP ID if the user belongs to an isolated federated enterprise directory.

Components NEVER store or bind user credentials using an unpartitioned root RP ID if the user belongs to an isolated federated enterprise directory.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
Technical Questions & Answers

Frequently Asked Technical Questions

Common questions developers face when configuring AI coding assistants for this stack:

Q:Why is WebAuthn L3 Multi-Tenant Subdomain RP ID Partitioning & Digital Asset Link Standard critical for AI coding assistants?

Enforces strict partitioning of WebAuthn Relying Party IDs (RP ID) in multi-tenant enterprise architectures and mandates explicit origin-to-RP ID binding via WebAuthn Level 3 Digital Asset Links (/.well-known/webauthn). Prohibits fallback to apex eTLD+1 domains across shared tenant subdomains to prevent cross-tenant credential harvesting and passkey relay vulnerabilities. Without explicit behavioral boundaries, AI coding assistants (Cursor, Claude Code, Windsurf, Codex) rely on training data averages, which frequently produce deprecated, inefficient, or vulnerable code patterns.

Q:How does adopting this rule prevent AI hallucinations?

This rule explicitly declares what the AI must avoid (Relaxing RP ID to an apex domain across multi-tenant subdomains without strict Digital Asset Link origin partitioning.) and prescribes verified positive examples. Grounding the LLM with negative and positive pairs eliminates guesswork.

Q:Which AI coding environments are supported?

This specification is multi-platform compatible: Cursor (.cursor/rules/*.mdc & .cursorrules), Anthropic Claude Code (CLAUDE.md), Windsurf (.windsurfrules), Codex / Cline (AGENTS.md), and GitHub Copilot (.github/copilot-instructions.md).

Q:Can I combine this rule with other technology stacks?

Yes. Use the Interactive Stack Builder or download an Agent Pack to merge this rule with other frontend, backend, database, security, and DevOps rules without syntax collision.

Open Specification · CC BY 4.0·Free for Personal, Team & Commercial In-Repo Use

Citation & Open Source Attribution Guidelines

This specification is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). You are completely free to adapt and share this rule in your workspace. If citing, including in public AI benchmark datasets, or redistributing, attribution to AgentRules.org is required.

Related SECURITY Rules

View all rules →
security
105

OpenFGA Graph Invariants: Cyclic Relation Prevention & Contextual Tuple Hardening

Enforces strict directed acyclic graph (DAG) topology validation during relationship mutation writes and mandates strict server-side schema verification for ephemeral contextual tuples in OpenFGA evaluations. Prohibits persistent storage of ephemeral request attributes and guards against recursive relation loops causing graph expansion denial-of-service.

security
81

WebAuthn Conditional UI Mediation, Nonce Atomicity, and Assertion Cryptographic Verification

Enforces zero-trust cryptographic validation for FIDO2/WebAuthn Passkey authentication with Conditional UI autofill. Requires atomic single-use challenge consumption to eliminate replay attacks, strict RP ID hash and origin binding, authenticatorData flag verification (User Presence and User Verification), and monotonic signature counter enforcement to detect authenticator cloning.

security
111

Enforce Sigstore Keyless OIDC Attestation and Admission Controller Verification

Enforces immutable supply-chain security using Sigstore Cosign keyless signing via ephemeral OIDC tokens issued by Fulcio and verified against the Rekor transparency log. Container workloads must be signed and attested at build time by digest, and admission controllers (such as Kyverno or Sigstore Policy Controller) must strictly validate the OIDC issuer and subject identity before allowing image execution.

1 Rule in Stack

WebAuthn