feat(cart): Embedded protocol transport binding for cart capability + reauth mechanism in ECP

[jingyli]

Reopening the PR to keep commit history clean (original PR) and hopefully third-time is the charm. This will also cross-reference/carry-over comments from the old PR.

Summary

Cart capability (dev.ucp.shopping.cart) is being introduced in #73. This adds an additional transport binding (EP) on the capability (building directly upon the referenced PR), on top of existing REST & MCP bindings. It follows the main UCP principle that "Embedded bindings should retain symmetry regardless of the capability it’s implemented for" (and hence why certain special mechanisms like auth are also being introduce to ECP to maintain symmetry).

Motivation

Businesses need a way to embed their cart building UI into eligible platforms, especially when complex experiences (i.e. item recommendations & upsells) are involved during cart building. Embedded Cart Protocol (ECaP) addresses this need.

Goals

• Enable businesses to embed cart UI into eligible hosts in a secure manner, especially if identity linking is a required pre-requisite for the flow.
• Establish a new auth exchange mechanism for embedded transport binding that utilizes postMessage mechanisms.
• Maintain general schema & design consistency with existing ECP (i.e. reuse naming conventions, message types, etc.).
• Introduce a way for businesses to advertise exactly for which capability is EP active for.

Non-Goals

• Support for extensions (i.e. fulfillment) on top of cart capability in the embedded protocol.
  • This is because extensions are out-of-scope in feat(cart): Cart capability for basket building #73

Detailed Design

Key methods supported by ECaP:

Category	Communication Direction	Purpose	Pattern	Core Messages
Handshake	Embedded Cart -> Host	Establish connection between host and Embedded Cart.	Request	ect.ready
Authentication	Embedded Cart -> Host	Communicate auth data exchanges between Embedded Cart and host.	Request	ect.auth
Lifecycle	Embedded Cart -> Host	Inform of cart state in Embedded Cart.	Notification	ect.start, ect.complete
State Change	Embedded Cart -> Host	Inform of cart field changes.	Notification	ect.line_items.change, ect.buyer.change, ect.messages.change

Risks and Mitigations

• Complexity: ECaP introduces another transport mechanism to implement & support. Mitigation: Not all businesses need to support it as part of its services advertisement. Also structurally it's also very similar to ECP so businesses already supporting ECP should be familiar with the design already.
• Security: Introduced new request mechanism (ect.auth) to exchange required authorization data instead of adding them as query parameters in continue_url to avoid hijacking attacks & support reauth scenarios.
• Backward Compatibility: None, new transport binding on a new capability.
• Schema Drift: Not introducing any new schemas, only new methods that utilizes existing schema components.

Graduation Criteria

Working Draft → Candidate:

• Schema merged and documented (with Working Draft disclaimer).
• Unit and integration tests are passing.
• Initial documentation is written.
• TC majority vote to advance.

Candidate → Stable:

• Adoption feedback has been collected and addressed.
• Full documentation and migration guides are published.
• TC majority vote to advance.

Implementation History

TBD