feat(cart): Embedded protocol transport binding for cart capability + reauth mechanism in ECP#244
Conversation
lemonmade
left a comment
lemonmade
left a comment
There was a problem hiding this comment.
Left a few small nits and questions, but I am really liking how this has shaped up, especially the symmetry with Embedded Checkout 👍 This PR does still have one Cart-only message, ect.line_items.change_request; do we think this same feature makes sense in embedded checkout?
| - **Result Payload:** | ||
| - `authorization` (string, **REQUIRED**): The requested authorization data, | ||
| can be in the form of an OAuth token, JWT, API keys, etc. | ||
| - `checkout` (object, **REQUIRED**): An optional checkout holding the last known state to the host. |
There was a problem hiding this comment.
Why is this needed? The embedded checkout should know the last checkout it sent before this message.
| "id": "auth_1", | ||
| "method": "ec.auth", | ||
| "params": { | ||
| "type": "oauth" |
There was a problem hiding this comment.
What are the allowed types here?
| - **Direction:** host → Embedded Checkout | ||
| - **Type:** Response | ||
| - **Result Payload:** | ||
| - `authorization` (string, **REQUIRED**): The requested authorization data, |
There was a problem hiding this comment.
IMO, authorization reads a little weirdly for a message called ec.auth. What about using token here, or credential, which mirrors the name for a similar concept in payment instruments?
| ``` | ||
|
|
||
| If the ingestion of the authorization is not successful, Embedded Checkout **MAY** | ||
| re-initiate this request with the host again. |
There was a problem hiding this comment.
Can we should how a Host would indicate failure, and what an Embedded Checkout should do with failures that come up?
| in the cart interface. These are informational only. The cart has | ||
| already applied the changes and rendered the updated UI. | ||
|
|
||
| #### `ect.line_items.change` |
There was a problem hiding this comment.
I think we are missing documentation for ect.line_items.change_request.
3 participants
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
Non-Goals
Detailed Design
Key methods supported by ECaP:
ect.readyect.authect.start,ect.completeect.line_items.change,ect.buyer.change,ect.messages.changeRisks and Mitigations
servicesadvertisement. Also structurally it's also very similar to ECP so businesses already supporting ECP should be familiar with the design already.ect.auth) to exchange required authorization data instead of adding them as query parameters incontinue_urlto avoid hijacking attacks & support reauth scenarios.Graduation Criteria
Working Draft → Candidate:
Candidate → Stable:
Implementation History
TBD