Security¶

USP's security model is built on IETF standards. This page covers both the shared USP security requirements and the additional infrastructure that Standalone Mode implementations must provide.

USP Security Requirements¶

These requirements apply to both deployment modes:

Transport Security¶

• All endpoints MUST use HTTPS with TLS 1.2+ (TLS 1.3 recommended per RFC 8446).
• HTTP Strict Transport Security (HSTS) headers SHOULD be sent.

Webhook Security¶

USP uses RFC 9421 HTTP Message Signatures for webhook integrity verification:

• Businesses MUST sign webhook payloads using keys published in the business profile: UCP-canonical keys (MUST when signing), with optional identical signing_keys during transition (RECOMMENDED dual-publish). Verifiers resolve keys first, then fall back to signing_keys.
• Platforms MUST verify webhook signatures before processing events.
• Signatures MUST cover at minimum: the request body digest, Content-Type header, and a timestamp (the RFC 9421 created signature parameter, written ;created=..., not as a covered component).

Request Signing¶

Platform requests use the same RFC 9421 machinery, with the covered-component set UCP requires, so a single signature satisfies a USP verifier and a UCP verifier alike:

• Always covered: @method, @authority, @path.
• Covered when present: @query, usp-agent / ucp-agent, idempotency-key, content-digest, content-type.
• @target-uri MAY be covered additionally, but MUST NOT replace @authority and @path; a verifier that enforces covered components treats a request whose target components are unsigned as unsigned.
• Verifiers MUST support ES256; signers SHOULD default to it. ECDSA values use fixed-width raw r||s encoding, not DER.

See Section 9.1.4 in the normative specification.

Hold Abuse Prevention¶

Time slot holds are a potential abuse vector. Businesses SHOULD implement:

• Maximum concurrent holds per buyer — Prevent a single buyer from locking up all available slots.
• Short TTLs — Recommended 5-10 minutes. Holds auto-expire.
• Backoff for repeated hold-and-release — Detect patterns of holding and releasing without booking, and apply progressive delays.

Idempotency¶

State-changing operations (booking creation, cancellation, rescheduling, payment confirmation) SHOULD use an idempotency key:

• REST: Idempotency-Key header (per draft-ietf-httpapi-idempotency-key-header)
• MCP: _meta.usp.idempotency_key field

Platform Authentication for Privileged Operations¶

This requirement applies in both deployment modes: it is not inherited from UCP in UCP-Native Mode. See Section 10.1.6 for the full normative text and rationale.

• Public operations (catalog, availability, profile discovery) MAY remain unauthenticated.
• Privileged operations (booking create/update/cancel/reschedule, business-authenticated confirmation of a booking which a platform principal MUST NOT invoke, holds, waitlist actions, payment-adjacent completion, registry writes, and any response carrying buyer personal data) MUST be authenticated.
• Every request to a privileged operation MUST carry a USP-Agent (or UCP-Agent) header on REST, or _meta.usp.profile on MCP, that resolves to a profile fetchable over HTTPS with no redirects, cached by URI.
• Identity binding is trust-on-first-use keyed by principal, not by profile URI. On first contact a business records the pairing of principal to profile URI. On later requests it MUST reject a request where that principal presents a different profile URI. Many distinct principals legitimately present the same shared platform profile URI; a business MAY flag or rate-limit that case and MUST NOT treat it as a required rejection.
• A business MUST accept at least one of: HTTP Message Signatures (RFC 9421, recommended default, permissionless, works the same for one platform or a million distinct personal-agent instances), platform key proof-of-possession (platform_key_pop, permissionless, derived from DPoP (RFC 9449); the caller proves possession of an ephemeral key it never transmits), a booking-scoped capability credential (authorizes get/cancel/PII operations on one booking regardless of platform identity), OAuth 2.0 Bearer, an API key, or mTLS. That list is illustrative rather than closed. A business SHOULD NOT accept only a pre-established mechanism (OAuth, API key, mTLS) once it intends to serve platforms it has not individually vetted.
• The last two compose: a booking-scoped credential issued to a caller that authenticated with platform_key_pop carries a cnf confirmation key, which makes it sender-constrained. Without that binding the credential is a plain bearer token, so anyone who observes it in a log, an HTTP trace, or a compromised database can act on the booking. With it, the value alone is useless.
• Businesses declare which mechanisms they require in an authorization policy (schemas/profile.json $defs/AuthorizationPolicy / $defs/AuthorizationMechanism), published top-level in a Standalone /.well-known/usp profile and as config.authorization on the dev.usp-protocol.services service binding in a UCP-Native /.well-known/ucp profile. USP does not add top-level members to a UCP profile document; it declares only under its own dev.usp-protocol.* namespace authority, and config is the member UCP defines for entity-specific settings. The same mechanism set is expressed in openapi/usp-rest.json components.securitySchemes and openrpc/usp-mcp.json components.x-usp-securitySchemes; MCP may present credentials on the HTTP layer (when MCP is over HTTP) or via _meta.usp.authorization.
• On rejection, businesses SHOULD return 401 with WWW-Authenticate naming what they would have accepted, so a mismatch is diagnosable instead of silent.
• Forward compatibility: mechanism identifiers, JWK members, algorithms, and profile fields are open vocabularies. Consumers MUST ignore what they do not recognize rather than reject the document, and MUST NOT treat an unrecognized mechanism as accepted (fail closed).

Data Privacy¶

USP carries buyer and recipient personal data: buyer, recipient, delivery_address, and free-text notes, which in scheduling frequently contains health, accessibility, or household detail. Both parties hold that data, so both are constrained.

Business Requirements¶

• Buyer personal data MUST be transmitted only over encrypted connections.
• Businesses SHOULD minimize the buyer data returned in responses to what the operation needs.
• Businesses MUST comply with applicable data protection regulations (GDPR, CCPA, and similar) on retention and deletion.

Platform Requirements¶

A platform or agent is a processor of the same data and, unlike the business, often handles many buyers across many businesses.

Catalog and availability data carry no personal data and are cached per the normal caching strategy without these limits.

Standalone Mode Security Infrastructure¶

Standalone Mode implementations MUST additionally provide:

Pre-established Authentication Mechanics¶

The mechanism-agnostic requirement lives in Platform Authentication for Privileged Operations above. For platforms using a pre-established mechanism in Standalone Mode, USP uses OAuth 2.0 (RFC 6749) with DPoP (RFC 9449):

• Platform-to-business: OAuth 2.0 client credentials flow for machine-to-machine API access, the recommended pre-established mechanism.
• Identity linking: OAuth 2.0 authorization code flow for linking buyer accounts across platforms and businesses.
• Token binding: DPoP tokens SHOULD be used to bind access tokens to the client's key pair, preventing token theft.

This list is not exclusive: HTTP Message Signatures and booking-scoped credentials remain available (and recommended alongside any of the above) for platforms without a pre-established relationship.

Rate Limiting¶

Businesses SHOULD implement rate limiting per draft-ietf-httpapi-ratelimit-headers:

• Return 429 Too Many Requests with Retry-After header when limits are exceeded.
• Include RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset headers on responses.

CORS¶

Businesses exposing USP endpoints for browser-based platforms MUST implement appropriate CORS headers.

PCI-DSS Scope Guidance¶

USP is designed to minimize PCI-DSS scope for implementations:

• USP never handles raw payment credentials. Payment processing is delegated to the checkout system (UCP or standalone).
• The payment_context object contains amount, currency, and metadata — never card numbers or sensitive payment data.
• Credential Providers (Google Wallet, Apple Pay) hold the sensitive instruments, not the platform or business.

Security Checklist¶