Summary

  • RFC 3505 defined requirements for a common hierarchy of electronic-commerce fields so wallets, forms and back-end systems could exchange payment-related data with less translation.
  • It explicitly did not replace transport security, object integrity, payment authorization or smart-card systems; a recognized field name proved semantics, not merchant identity, user consent, charge execution or settlement.

The early checkout problem looked mundane. One merchant called a field “surname,” another “last_name,” and a third buried the same datum inside a proprietary hierarchy. A person could decipher the labels and retype an address or card detail. A software wallet could not reliably infer which box meant what.

RFC 3505, published as an Informational document in March 2003, treated that friction as an interoperability problem. ECML version 2 would provide hierarchically organized Payment Processing Objects for consumer-to-merchant and business-to-business exchanges. It would extend earlier HTML-form field work toward XML, additional payment methods and back-end systems.

The intended coverage was broad: cost, receipt, currency, card, payment and bank or telecommunications data; credit card, electronic check, ACH, mobile-phone and PDA payment types; wallets, marketplaces and enterprise systems. Yet the design principle was also restraint. Add as few fields beyond version 1.1 as practical, retain existing function, and use the wider Web architecture of URIs, layering and extensibility.

This was a vocabulary contract. If a wallet recognized the structured name for a shipping city, it could offer the value without guessing from a human label. If a back-end system recognized the payment hierarchy, it could map the same concept into its own processing. Shared names lowered the cost of translation between independently built software.

The RFC did not confuse that convenience with security. It explicitly said ECML v2 was not an alternative to TLS, SET, EMV, XML or IOTP. Those technologies supplied different capabilities: confidentiality, non-repudiated transactions, payment-scheme selection, smart-card support or trading flow. ECML named data. It did not absorb every control surrounding the data.

The distinction was especially important because many proposed fields were sensitive. Names, addresses, account identifiers, card information and user credentials could become easier to release at scale once wallets understood them automatically. RFC 3505 therefore made ECML dependent on the transmission infrastructure and on applications that stored or released the information. The vocabulary itself did not have to invent a security mechanism, but its specification had to warn implementers.

Well-formedness stayed equally bounded. The requirements called for a DTD and perhaps a schema, tested XML examples and comparison with prior vocabularies. A document that passed those checks proved that names and structure obeyed the grammar. It did not prove that a card number belonged to the user, that a price was honest, that the merchant was authentic or that a processor had authorized payment.

One detailed request exposed the migration problem. ECML v2 might include a hidden translation field mapping standardized fields onto existing merchant fields, allowing support without rewriting old code. That reduced adoption cost. It also meant invisible mappings could move sensitive data between layers the user did not see. Compatibility was not consent.

RFC 4112 supplied the ECML v2 specification in 2005. It defined the hierarchical field names and offered XML as an exemplar syntax, while allowing other encodings and protocols. Conformance governed the names and structure used on the wire, not the human-visible label. A merchant could display local language while preserving common machine semantics.

The minimum sizes in its field table were capacity obligations, not validity tests. A form had to accept at least a given length, but a shorter or longer value might still be legitimate. Treating MIN as proof of a valid name, telephone number or address would turn an interoperability floor into a false identity rule.

RFC 4112 also defined query and assertion modes. A query could ask for a value; an assertion could supply one. These modes described message intent. They did not authenticate the asker or make the asserted value true. Before an automated wallet answered, a separate policy still had to decide whether this counterparty, purpose and moment justified release.

For Web use, Ecom_SchemaVersion identified which field vocabulary was present. That marker helped software choose the correct interpretation and was required in every ECML Web transaction. It did not identify the merchant, validate the page or protect a channel. Version recognition was not endpoint authentication.

Multi-page forms created another hazard. Automation might continue filling personal data after the commercial interaction had effectively ended. RFC 4112 introduced Ecom_TransactionComplete as a hint telling automated logic to stop until further authorization. The field bounded disclosure. Its name did not certify that a payment was authorized, captured, settled, fulfilled or accepted by the customer.

The security section kept the external dependencies explicit. Sensitive information needed confidentiality and protection from unauthorized modification. Authenticity might require object security such as XML signatures or CMS, or channel security such as TLS or IPsec. The specification named possibilities but did not define one universal protection mechanism.

User control over release remained necessary. Software on shared terminals should be able to disable memory of personal information. Stored data needed protection options. Hidden and default values could be maliciously changed before returning to another party. Standard structure made processing predictable; it did not make the surrounding application benign.

An honest receipt ladder therefore begins with field-name recognition. Next comes structural validity, then authenticated counterparty, authorized user release, protected transmission, application acceptance, payment authorization, clearing or settlement, and delivery. A dashboard that jumps from the first two steps to “paid” converts machine readability into a commercial claim.

Nor does publication prove deployment. RFC 3505 recorded requirements, and RFC 4112 later published a Standards Track specification. Neither fact demonstrates browser adoption, wallet use, merchant interoperability, privacy outcomes or successful transactions. Those claims need implementation and operational evidence.

ECML’s narrow contribution was still meaningful. It reduced one kind of friction without claiming to solve every layer. The lesson is that semantic coordination can make good systems easier to connect—and can make unsafe systems disclose data faster. Common names are a capability. Whether that capability is authorized, protected and economically complete remains a different decision.

Sources