feat(shopping): Add additional fields proposal (from Shopify)

[SaifBenChahed]

Summary

Adds an Additional Fields proposal using a single extension with optional config-based type narrowing.

Businesses sometimes need to collect checkout data that is specific to their workflow, such as PO numbers, gift options, delivery notes, requested dates, or buyer acknowledgements. Today there is no standard way for a business to describe those fields to a platform, for the platform to collect values, or for captured values to appear on orders.

This proposal standardizes that exchange:

• checkout additional_fields definitions and submitted values
• order read-only additional field summaries
• standard input types: text, boolean, date, and choice
• text validation hints, multiline text, date bounds, and choice options
• validation errors through existing messages[]

It also adds optional config.supported_types on the capability. Platforms and businesses may use supported_types to narrow the active type set; when both declare it, the active set is their intersection.

Notes

The payload schema remains the full standard type superset. Config is treated as an optional negotiation constraint, not the primary extension model.

[SaifBenChahed]

cc @igrigorik @richmolj

[jamesandersen]

@SaifBenChahed thanks for submitting this! I think this will unlock agentic commerce for a non-trivial cohort of merchants requiring some incidental extra inputs.

[jamesandersen]

Just a thought, for booleans, might consider making the base value accept a union, then use the same if/then pattern the PR already uses for input to pin boolean-typed fields to a real boolean:

// additional_field.value base type:
"value": { "type": ["string", "boolean", "null"], ... }

// additional_field.allOf — add:
{
"if": {
"properties": { "input": { "properties": { "type": { "const": "boolean" } }, "required": ["type"] } },
"required": ["input"]
},
"then": { "properties": { "value": { "type": ["boolean", "null"] } } }
}

Request becomes { "key": "gift_wrap", "value": true }, cleared as { "key": "gift_wrap", "value": null }.

Otherwise I'd just add some language indicated the expected string formats for boolean values

[SaifBenChahed]

Thanks, that makes sense. The conditional schema approach would work well for responses, since each field includes input.type.
For submissions, though, we only send key + value, without the field definition. The business still needs to resolve the key back to its field definition to validate type-specific rules, whether that rule is boolean format, choice membership, date bounds, or text constraints.
My slight preference is to keep value as string | null here for a uniform submission shape, so I added normative language that non-null boolean values MUST be the exact strings "true" or "false".

[jamesandersen]

While there's a preference for machine resolvable schema, this seems reasonable; we'll see if there's any second opinion here ;-)