Open
Conversation
Prior spec required businesses to process any request from a platform
at an older protocol version ("MUST process if platform ≤ business").
This imposed an unbounded backwards-compatibility obligation — every
business must support every historical version indefinitely.
New model: the business's protocol version is canonical. Businesses
declare accepted versions via a `supported_versions` array in their
profile (defaults to [version] when omitted). Platforms MUST support
the business's declared version to initiate a request. The business
validates the platform's version against its supported_versions list
and rejects with 422 if there is no match.
This also reclassifies version_unsupported from a negotiation result
(HTTP 200 with checkout message schema) to a protocol error (HTTP 422),
since version mismatch is a pre-negotiation gate check — the buyer
cannot resolve a protocol incompatibility.
deinck6
reviewed
Feb 23, 2026
deinck6
reviewed
Feb 23, 2026
deinck6
reviewed
Feb 23, 2026
The intersection algorithm matched capabilities by name only, without specifying how versions are resolved when multiple are present. Add explicit step: compute mutual version set, select highest, exclude capability if no mutual version exists.
Protocol and capability versions are independent axes — a flat profile cannot express which capabilities are available at which protocol version. supported_versions becomes a map from protocol version to profile URI, where each URI points to a complete, self-contained profile for that version. Platform bootstrap: fetch /.well-known/ucp, match version or follow the URI in supported_versions, get an unambiguous capability set. Key design choices: - uri-reference format allows relative paths (/.well-known/ucp/2026-01-11) - Current version served by the root profile; only older versions in map - Version-specific profiles are leaf documents (no supported_versions) - Both platform and business obligations explicit at version mismatch
Extension schemas SHOULD declare min_protocol_version to indicate the
minimum UCP protocol version they require. This makes the protocol
dependency explicit and verifiable, rather than relying on profile
publishers to self-attest compatibility.
The schema author declares the requirement; the profile publisher
selects and advertises compatible versions. When present, platforms
and businesses SHOULD verify negotiated version >= min_protocol_version
during schema resolution. Incompatible extensions are excluded from
the active capability set with orphan re-pruning.
Changes:
- New "Protocol Version Constraint" subsection under Extension Schema
Pattern with field definition, example, and verification contract
- Resolution Flow gains step 4 (Protocol Compatibility) between
Schema Fetch and Compose
Contributor
Super-linter summary
All files and directories linted successfully For more information, see the Powered by Super-linter |
Contributor
Author
|
@deinck6 @sinhanurag great feedback, ptal at updated draft. |
richmolj
reviewed
Feb 26, 2026
| The business's profile at `/.well-known/ucp` describes capabilities for | ||
| its current protocol version. Businesses that support older protocol | ||
| versions **SHOULD** publish version-specific profiles and advertise them | ||
| via the `supported_versions` field — a map from protocol version to |
Contributor
There was a problem hiding this comment.
I think we'd also need some concept of deprecation cycle baked in. I assume businesses will not want to support every version forever, but need some way to signal to platforms "this will no longer be in supported_versions on this date"
lemonmade
approved these changes
Feb 26, 2026
| flow between platform and business. | ||
| UCP separates protocol version compatibility from capability negotiation. | ||
| The business's profile at `/.well-known/ucp` describes capabilities for | ||
| its current protocol version. Businesses that support older protocol |
Contributor
There was a problem hiding this comment.
Is "current" synonymous with "latest"/ "most recent" here?
| advertises compatible versions in their profile. | ||
|
|
||
| If `min_protocol_version` is present, platforms and businesses | ||
| **SHOULD** verify the negotiated protocol version is >= |
Contributor
There was a problem hiding this comment.
Why should, and not must here?
manumilou
reviewed
Feb 27, 2026
| Businesses that support older protocol versions **SHOULD** include a | ||
| `supported_versions` object mapping each older version to a | ||
| version-specific profile URI. See [Protocol Version](#protocol-version) | ||
| for details. |
There was a problem hiding this comment.
This flow requires an additional HTTP fetch when the platform's version doesn't match version.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently, spec requires businesses to process any request from a platform at an older protocol version (via "MUST process if platform ≤ business"). This imposed an unbounded backwards-compatibility obligation — every business must support every historical version indefinitely. Further, the negotiation mechanism is underspecified and missing a primitive for business to advertise which older versions are supported.
Update: businesses can list accepted versions via a
supported_versionsarray in their profile. Platforms can discover the list by fetching the profile from well-known and MUST support the business's declared version to initiate a request -- the request carries a profile link with the version platform wants to use. The business validates the platform's version against its supported_versions list and rejects with 422 if there is no match.Checklist