Payments and the ability to exchange value efficiently and securely over
the web are critical to global commerce. Open standards for payments and
value exchange help ensure open access and interoperability to financial
systems for all the people that use the Web. This document describes
a set of capabilities and key top-level architectrual principles that, if standardized, will improve payments on the
Web.
Status of This Document
This section describes the status of this document at the time of its publication.
Other documents may supersede this document. A list of current W3C publications and the
latest revision of this technical report can be found in the W3C technical reports index at
http://www.w3.org/TR/.
This document is in early draft state and is expected to rapidly evolve
based on broad feedback and input from the Web Payments Interest Group.
Publication as an Editor's Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite this document as other than work in
progress.
In October of 2014, the W3C chartered the Web Payments Interest group with the goal of providing a forum for Web Payments technical discussions to identify use cases and requirements for existing and/or new specifications to ease payments on the Web, and to establish a common ground for organizations providing payment services on the Web Platform. The overall objective of this group is to identify and help create the conditions for greater uptake and wider use of Web Payments through the identification of standardization needs to increase interoperability between the different stakeholders and the different payment methods.
The Web Payments Interest Group's scope covers payment transactions using Web technologies on all computer devices (desktop, laptop, mobile, tablet, etc.) running a Web user-agent (a Web browser, a hybrid app, or an installed Web application) and using all possible legal payments methods across a variety of scenarios including Web-mediated Business-to-Consumer (B2C), Business-to-Business (B2B), Business-to-Business to Consumer (B2B2C), and Person-to-Person (P2P) transactions in the case of physical (payment at physical shops) and online payments for physical or digital goods, including in-app payments.
Due to the fundamental importance of payments to the web and the intricate relationship with other core aspects of the open web platform such as identity and commerce, the Web Payments IG created this document with the following goals in mind:
Provide a common place to capture and document key capabilities that are necessary for payments on the web
Communcate important architectural principles related to payments on the web and how they relate to other standards such as identity and commerce
Increasing visibility and improving coordination of various payments and related standardization efforts within the W3C Interest, Working, and Community groups and other standards bodies
1.2 Audience of this document
This document is intended to broadly inform discussions on standardization of key capabilities and high level architecture of payments on the web. The intended audience for this document includes:
Participants in W3C Activities
Other groups and individuals designing technologies to be integrated into the Web
Implementers of W3C specifications
Web content authors and publishers
1.3 Scope of this document
This document presents the general capabilities and architecture of payments on the Web and is one part of a greater body of work around Web Payments
that the W3C is producing. These other documents include:
Web Payments
Use Cases 1.0 is a prioritized list of all Web Payments scenarios
that the Web Payments Interest Group expects the architecture to
address in time.
Web Payments Capabilities 1.0 (this document) derives a set of
capabilities from the use cases that, if standardized, will improve
payments on the Web.
Web Payments Roadmap
1.0 proposes an implementation and deployment plan that will
result in enhancements to the Open Web Platform that will achieve the
scenarios outlined in the Use Cases document and the capabilities
listed in the Capabilities document.
This document attempts to communicate the concepts outlined in the Web
Payments space by using specific terms to discuss particular concepts. This
terminology is included below and linked to throughout the document to aid
the reader:
account provider
[PSD2] account servicing payment service provider: a payment
service provider providing and maintaining the payment account from
which the payer wants the specific payment transaction to be made
invoked payment app
The selected payment app that the user agent has invoked (executed) and passed
payment app input data.
payee
An entity that receives funds as required by a transaction.
payer
An entity that provides a source of funds as required by a
transaction.
payment
[ECB] in a strict sense, a payment is a transfer of funds which
discharges an obligation on the part of a payer vis-a-vis a payee.
However, in a technical or statistical sense, it is often used as a
synonym for transfer order
[EXPERIMENTAL] A way of paying. A system and set of rules for payments.
A payment app may support one or more payment methods. For example,
Visa, Mastercard, American Express, bobspay.com are payment methods.
payment method data
[EXPERIMENTAL] The data describing an instance of a payment method.
For example, for the Visa payment method this might be the card primary
account number (PAN), expiry date, and CVV.
payment request
A request from a payee to be paid. It contains the
details of what to pay and how the payment can be made. How the
payment can be made is specified as a list of payment method
identifiers. The payment request MUST contain all of the
payment method data required for each payment method
identified in it's set of supported payment methods.
payment request API
The javascript API specified in the
Payment Request API specification. This API can be used by
merchants to trigger a payment flow in the user agent or by
payment apps to register or update their information in the user
agent.
A response to a payment request (normally the result of
processing by a payment app). The content of a payment
response will be dependant on how the payment is being
processed.
payment service provider
A body executing payment services such as credit institutions,
electronic money institutions, post office giro institutions,
payment institutions, central banks other than when acting in their
capacity as a monetary authority or carrying out other functions of a
public nature, and government departments and local authorities, other
than when carrying out functions of a public nature.
regulator
The regulator is responsible for monitoring some payments
activities and enforcing legal requirements.
transaction
An economic exchange between a payer and one or more
payees. An agreement, communication, or movement
carried out between a buyer and a seller to exchange an asset for
payment.
user agent
A piece of software that acts on behalf of the user.
3. Capability Domains
In order to illustrate core aspects of payments on the web, this section of the document is organized by functional capability domains. This is intended to help highlight specific areas that are needed for standardization of payments, and also to help communicate relationships and dependencies to adjacent standards work such as Identity and Commercial aspects of the web.
The capabilities have been organized into course grained domains which were structured to help promote consistent and cohesive concepts in similar functional aspects, reduce coupling between core payments standards and those which are useful more broadly than payments, and to minimize redundant or overlapping work being done on standards in this space by providing visbility into cross cutting concerns and topics across each functional domain.
Each capability includes backgound context specific to its domain, key goals and architecural principles related to the capability and outlines significant relationships with other standards work and capability domains. The five top level capability domains are represented in the diagram below:
3.1 Core and Security
These capabilities provide the
security foundation for payments.
Capabilities: Key Creation and Management,
Cryptographic Signatures, Encryption
Issue 1
Right now this group has only security capabilities in it. We may
wish to have a more general purpose Core set. If so, what would this
core set include?
3.2 Identity and Credentials
Includes features related to
establishing trust among parties, and credentialing or authorization
of parties involved in a transaction.
Includes capabilities
related to managing stores of value (such as Deposit Accounts) and
recorded accounts of ownership (such as Ledger entries, Deeds, etc.)
used as part of the settlement of payments or commercial exchanges.
Settlement via the Web involves access to the accounts of the
participants and ledgers of the account
providers and capabilities to manage accounts and capture and
monitor transactions in a ledger against those accounts.
Capabilities: Accounts, Account Management and Legal/Regulatory concerns related to accounts and recorded ownership
3.4 Clearing and Settlement
These are the capabilities
that help parties in a transaction establish the mechanics of how the
payment will be executed and the directly or indirectly make this
happen. This involves the ability to discover and negotiate the
mechanism that will be used to execute the payment and agree on the
terms including facts such as the costs of making the payment, time
between clearing of the payment and settlement into the payee's
account, regulatory requirements and required authorisations.
Capabilities: Messaging, Clearing, Markets, Foreign/Currency Exchange, and Legal/regulatory concerns specific to payment clearing, settlement and Exchange of Value.
3.5 Commerce
Includes capabilities related to
commercial and economic interactions.
Capabilities: Offers, Invoicing, Receipts, Loyalty,
Rewards, Contracts, Lending, Insurance, Taxation, Legal/Regulatory
concerns related to aspects of commercial and economic interactions.
4. Key Principles
5. Capabilities in Context
Issue 2
We will be overhauling this section to move into Key principles section and simplify the intent of the interaction wheel - namely the key principle that activities related to payments and adjacent domains may take place asynchronously over an extended time horizon and that required standards may be best expressed as a discrete interactions between 2 parties which can be recombined to express larger payments "flows" or multi-step scenarios.
To simplify and harmonize the descriptions of capabilities necessary for
payments and value exchange on the Web, it is helpful to understand the
parties involved and the direction that information flows among them at
various
phases of a payment. We use the following diagram to help illustrate
roles and information flow:
Figure: Payment Interaction Wheel
For example, the following diagrams illustrate three interactions in a
comment payment scenario.
Interaction 1:
Payee communicates request for payment to payer and shares
payment instructions
The roles illustrated here may be carried out by many different
entities. For example, "account provider" may be carried out by
financial institutions, mobile operators, tech companies, or
cryptocurrency systems; 'payee' may be an individual, a business,
an NGO, or any entity that can accept a payment.
A payment may involve just two parties (e.g., peer-to-peer) or may be
carried out by several collaborating parties. For instance, apayee may use a payment service provider which in turn uses a
card network. The actions of these intermediaries may vary, from simply
forwarding messages to fulfilling regulatory obligations. Additionally,
these interactions may happen in different sequences and direction
depending on the payment context.
6. Capabilities in Detail
6.1 Core and Security
Key Management
All participants require an interchangeable mechanism for
creation, management, storage, and exchange of cryptographic keys
Key management capabilities are required to:
Securely communicate unique identifiers of payment process
participants
Digitally sign and authenticate information exchanged as
part of the payments process (e.g., payments, receipts,
invoices, etc.)
Provide reference key for independent elements of the
payments process to compose/link transactions and related data
across asynchronous segments of the payment process
Cryptographic Signatures
Information transferred should be cryptographically signed to
ensure
Authenticity of the participants and ownership of
value/asset being transferred or exchanged
Nonrepudiationof participants intent related to information
/ communication being exchanged
Key Concepts:
(describe any key concepts/relationship to other capabilities here)
Suggested Deliverables:
Data model with a concrete syntax for expressing data in the
architecture
Web-based key public key infrastructure data formats and protocols
New normalization mechanisms for data model serialization (if
necessary, for digital signatures)
Digital signature mechanism for data model
Related Specifications:
Data models: Graph (RDF), Document/Tree (JSON, XML)
Syntaxes: XML, JSON, JSON-LD
Normalization: XML Canonicalization, RDF Dataset Normalization
Signatures: Linked Data Signatures, Javascript Object Signing and
Encryption, XML Digital Signature
Responsible Working Group(s) or Standards Bodies:
Linked Data Signatures Working Group (W3C)
JOSE (IETF)
6.2 Identity and Credentials
The word identity means different things to different people
and is often discussed as a problem waiting to be solved on the Web. In
the physical world, we have many identities. We have an identity for
work life and home life. We have an identity that we use when we talk
with our friends and one that we use when we talk with our families. The
concept of identity is as nuanced as it is broad.
There are aspects of our identities that have very little consequence
to others, such as whether we have dark brown hair or black hair. There
are also aspects of our identities that are vital for proving that we
should be able to perform certain tasks, like a drivers license or
a medical board certification. Then there are aspects of our identities
that are important for social reasons, such as the rapport that we build
with our friends over our lifetimes.
Many aspects of our identity are often expressed via
credentials, which can be seen as verifiable statements made by
one person or organization about another. There have been multiple
attempts at formalizing credentials on the Web; each one of them have
been met with varying degrees of mild success, but mostly failure. The
rest of this section focuses on the goals of a healthy identity and
credentialing ecosystem as well as capabilities that would enable such
and ecosystem to thrive.
6.2.1 Goals
A healthy credentialing ecosystem should have a number of
qualities:
Credentials should be
interoperable and portable. Credentials should be
used by as broad of a range of organizations as possible. The
recipient of a credential should be able to store, manage, and share
credentials throughout their lifetime with relative ease.
The ecosystem should scale to the 3
billion people using the Web today and then to the 6 billion
people that will be using the Web by the year 2020.
The process of exchanging a credential should be
privacy enhancing and recipient
controlled such that the system protects the privacy of the
individual or organization using the credential by placing the
recipient in control of who is allowed to access their
credential.
Implementing systems that issue and
consume credentials should be easy for Web developers
in order to lower barriers to entry and increase the amount of
software solutions in the ecosystem.
Creating systems that are
accessible should be a fundamental design criteria,
as 10% of the world’s population have disabilities and the solution
should be usable by as many people as possible.
The solution should follow a number of core Web
principles such as being patent and royalty-free,
adhering to Web architecture fundamentals, supporting network
and device independence, and being
machine-readable where possible to enable
automation and engagement of non-human actors.
6.2.2 Capabilities
Identity
Entities in the System are able to access Identity information
of other parties it is interacting with if specifically required by
law, or if consented to by owner of the information
Identity and credentials of an entity are able to be
linked/associated with Accounts and payments to satisfy requirements
for Account Providers and
Payments Service Providers
to comply with KYC/AML requirements.
Credentials
Entities in the system are able to be associated with 1 or more
credentials. A credential is a qualification, achievement, quality,
or piece of information about an entity's background such as a name,
home address, government ID, professional license, or university
degree, typically used to indicate suitability. This allows for the
exchange of suitable qualities of the entity (ex. over age 21)
without divulging sensitive attributes/details about the entity (ex.
date of birth)
Payer is able to exchange standard format credentials withPayee
to validate attributes necessary to complete the payment
Entities in the system may store a credential at an arbitrary identity
provider after it has been issued by an arbitrary issuer. This helps create a
level playing field for all actors in the ecosystem.
A protocol for migrating from one identity provider to another without
the need to reissue each credential. This promotes a healthy identity
provider ecosystem.
Data Model
The data model should be extensible such that it supports an entity making
an unbounded set of claims about another entity. This enables a very
broad applicability of credentials to different use cases and market verticals.
The data model should be capable of being expressed in a variety of data
syntaxes. This increases interoperability between disparate credentialing
systems and increases the long-term viability of the technology.
A formal mechanism of expressing new types of claims without
centralized coordination. This promotes a high degree of parallel
adoption and innovation.
Rights
An entity should be able to express what "allowable use" of a credential
is when providing it to another entity such that there is recourse if a
credential is misused. For example, when providing an email address credential
an assertion is made such that the email address cannot be used as a
destination for marketing material.
Authentication
Participants are able to authenticate the validity of
identifiers presented by entities that they are interacting with
A digital signature mechanism that does not require out-of-band information to
verify the authenticity of claims; instead it should enable public
keys to be automatically fetched via the Web during verification. It
should not render the signed data opaque because opaque data is harder
to learn from, program to, and debug. This makes the digital signature
mechanism easier to use for developers and system integrators.
An issuer should be able to revoke a previously issued credential. This
enables issuers to ensure that the credentials they have issued
accurately represent their claims throughout the lifetime of the credential.
Authorization
Entities may use credentials to get access to protected resources or get
approval to perform protected tasks.
Privacy
All capabilities in this document should be standardized in a
way that minimizes the inclusion/exchange of personal or other
sensitive metadata that are part of the payments process unless
specifically required by law, or consented to by the owner of the
information.
A protocol that enables the recipient to share their credentials without
revealing the intended destination to their identity provider. This
enhances privacy.
Discovery
Payer is able to securely locate public identifier ofPayee to be used as part of payment process
Payee is able to obtain public identifier of Payer
participating in payment process
Payment service provider is able to perform the necessary steps
during payer/payee enrollment to collect required identity
and credential information about the payer/payee and
associate it with an Account.
Regulatory and Legal
Entities should be able to detect when the collection of particular data
would violate personally identifiable information regulations. For example,
collecting the name and home address of a minor should be detectable and
avoided in jurisdictions where that is not allowed.
Entities should be able to easily request credentials and prove that they
performed the required regulatory checks before allowing a transaction
to complete. Ideally, this process should be automated.
Key Concepts:
TO DISCUSS: Trust Agent???
Suggested Deliverables:
Data format and vocabularies for expressing cryptographically
verifiable credentials
Protocol to issue credentials to a recipient
Protocol to store credentials at an arbitrary location as decided by
a recipient
Protocol to request and transmit credentials, given a recipient's
authorization, to a credential consumer
Protocol to strongly bind an identifier to a real world identity and
a cryptographic token (ex: two-factor hardware device)
Protocol to request and deliver untraceable, short-lived, privacy
enhancing credentials.
Protocol to discover entity's credential service
Related Specifications:
SAML (OASIS)
OpenID Connect (IETF)
Identity Credentials (Credentials WG)
Credentials Vocabulary (Credentials WG)
Responsible Working Group(s) or Standards Bodies:
Credentials Working Group (W3C)
Authentication Working Groups (W3C)
6.3 Accounts and Ownership
Accounts
Manage Accounts
Payers and Payees
(account owners) require the capability to create accounts at an
account provider.
Payees are able to receive funds into
theiraccounts
Send funds
Payers are able to transfer funds from their
accounts
Key Concepts:
(describe any key concepts/relationship to other capabilities here)
Suggested Deliverables:
(include suggested/needed deliverables here)
Responsible Working Group(s) or Standards Bodies:
Related Specifications:
(Insert relevant related existing or in progress standards for
capability segment)
Ledgers
Discovery of Ledger services
Participants require the capability to locate the endpoints at
which ledger services are offered by an account provider
Participants require the capability to discover which services
are available against a ledger at an account provider
Capture transactions in ledger
Participants in the settlement process require the capability to
capture a transaction in a ledger transferring value from one
account to another on the same ledger.
Monitor a ledger
Participants in the settlement process require the ability
to monitor a ledger for new transactions that impact a specific
account.
Reserve funds in an account
To execute settlement across ledgers a counterparty may require
the ability to request that an account provider temporarily reserve
funds in an account while settlement is finalised on the other
ledger(s).
Key Concepts:
TODO
Suggested Deliverables:
Standardised data model for accounts and ledgers
Standardised interface for account management
Standardised interface for ledger services
Protocol for discovering ledger services
Protocol for executing settlement between participants on the open
Web
Related Specifications:
ISO20022 / X9 specs
Web Commerce Formats and Protocols (Web Payments WG)
Web Payments Vocabulary (Web Payments WG)
Responsible Working Group(s) or Standards Bodies:
Web Settlement Working Group (W3C)
6.4 Clearing and Settlement
Payment Instrument Discovery and Selection
Payer and payee are able to discover payment
instruments/schemes which they have in common and may be used in
the payment process
Payer is able to establish the different costs of making
the payment using the various combinations of payer andpayee instruments and schemes (payment methods)
Payer is able to select payment instrument for use in the
payment process
Payee is able to communicate requirements(or preference) to
payer as to whether a specific instrument is accepted and
the payment terms for using that instrument
Payment Initiation
Payer is able to initiate a payment using selected payment
instrument
Payee is able to initiate a request for payment to payee's
designated account provider
Account provider is able to initiate a payment on behalf of the
Payee based on Payee's requested schedule and frequency (recurring
payment)
Payment Authorization
Payment service provider or payee is able to get
authorization from payer to execute payment either in real-time or
using a preloaded authorization mechanism
Payment service provider is able to demonstrate to payer
account provider that payment is authorised
Payment Execution
Payment orchestrator is able to evaluate that all requirements
have been met to execute the payment including authorization(s) and
compliance checks as required.
Payment orchestrator is able to instruct all participants to
execute the payment and perform any roll-back steps that may be
required in case of a failure by any participant to complete the
payment.
Payment Acknowledgement
Payee is able to receive confirmation that payment has been
successfully completed
Payer is able to receive verification that payment has been
successfully received
Account provider is able to receive confirmation that payment is
complete
Regulatory/Legal Compliance
Regulator is able to access/view required payment, payer,
and payee details for payments that take place within their
jurisdiction
Regulator is able to intervene in payments meeting or
exceeding certain thresholds or criteria in order to comply with
jurisdictional laws and requirements
Payment Settlement and Clearing
Payment service provider is able to provide payer with
quotesto settle payee via all payee supported payment
schemes
Key Concepts:
TODO: Payment Agent
Suggested Deliverables:
Protocol for discovering all payment instruments available to a
payer.
User Agent API and REST API for initiating a payment and protocol
for routing an invoice to a payment service
Protocol for authorizing payment via regulatory API
User Agent API and REST API for completing a payment and protocol
for routing payment acknowledgement to payer
Related Specifications:
ISO20022 / X9 specs
Web Commerce Formats and Protocols (Web Payments WG)
Web Commerce User Agent API (Web Payments WG)
Web Payments Vocabulary (Web Payments WG)
Responsible Working Group(s) or Standards Bodies:
Web Payments Working Group (W3C)
6.5 Commerce
Offers
Generate Offer
Payee is able to generate a standard format offer which
provides information on specific products or services being
offered, and additional information on payment instruments
accepted, or terms of the offer.
Payer is able to generate a standard format offer which can
be accepted or declined by the payee.
Payee is able to create scheduled/recurring offers
Receive Offer
Payer is able to receive offer in machine readable format
and use it to initiate payment request
Payeeis able to receive offer in machine readable format and use
it to create invoice
Discounts
Payee is able toable tocommunicate discounts which may be
applied to Offers
Payee is able to receive and apply discount to offer
Payee is able to apply standard loyalty identifiers to offers
Payee is able to issue coupons specific to payer
identifier
Key Concepts:
Suggested Deliverables:
Data format and vocabularies for expressing offers and coupons
User Agent API for using an offer to initiate a payment
Related Specifications:
Web Commerce Formats and Protocols (Web Payments WG)
Web Commerce User Agent API (Web Payments WG)
Web Payments Vocabulary (Web Payments WG)
Responsible Working Group(s) or Standards Bodies:
Web Payments Working Group (W3C)
Invoices
Invoice creation
Payee is able to generate a standard formatted invoice and
communicate to Payer as part of the negotiation of payment
terms
Invoice receipt
Payer is able to receive standard formatted invoice
Invoice data
Invoice provides payer with Payment instructions for
making payment to Payee
Invoice identifier is returned to Payee via payment
process to verify payment is complete
Key Concepts:
Suggested Deliverables:
Data format and vocabulary for expressing an invoice
User Agent API for initiating a payment and protocol for routing an
invoice to a payment service
Related Specifications:
Web Commerce Formats and Protocols (Web Payments WG)
Web Commerce User Agent API (Web Payments WG)
Web Payments Vocabulary (Web Payments WG)
Responsible Working Group(s) or Standards Bodies:
Web Payments Working Group (W3C)
Receipts
Create Receipt
Payee is able to create receipt and communicate receipt to
Payer following completion of payment
Receive Receipt
Payer is able to receive receipt and persist for future use
(ex. returns, reimbursement, etc)
Key Concepts:
Suggested Deliverables:
Data format and vocabulary for expressing a receipt
Protocol for routing an receipt to a payer's receipt storage service
Related Specifications:
Web Commerce Formats and Protocols (Web Payments WG)
Web Payments Vocabulary (Web Payments WG)
Responsible Working Group(s) or Standards Bodies:
Web Payments Working Group (W3C)
Loyalty
Payer is able to register with Payee's loyalty program by
requesting loyalty identifier from Payee.
Payee can 'opt-in' to loyalty program by providing program
specific public identifier
Key Concepts:
Suggested Deliverables:
Same as 'Trust' deliverables
Related Specifications:
Identity Credentials (Credentials WG)
Credentials Vocabulary (Credentials WG)
Web Commerce Vocabulary (Credentials WG)
Responsible Working Group(s) or Standards Bodies:
Credentials Working Group (W3C)
7. Guiding principles and key considerations
Due to the breadth of the capabilities that will require
standardization, it is important to outline certain guiding principles
which are expected to be incorporated across each of the defined
capabilities in this document as they are undertaken by standards teams.
The principles include:
Extensibility
Because the Web payments architecture will accommodate a great
variety of payment schemes (existing and new), we expect to future
standards to support interoperability on a minimal set of features and
also support scheme-specific extensions. Therefore, data formats must be
easily extensible.
Composability
Different parties will want to add information to messages that are
forwarded.
Identifiers
Payment schemes define identifier syntax and semantics (e.g.,
primary account numbers (PANs) for credit cards, or bitcoin account
identifiers). We expect to support scheme-specific identifiers. But
where global identifiers are required and are not scheme specific, we
expect to use URIs.
Due to the nature of payments and the fundamental challenge of
preventing 'double-spending' as part of the payments process, it is
important that every actor/system be uniquely identifiable to other
actors and systems participating in the payments process. While each
actor must be identifiable, a number of use cases that need to be
addressed include low value or less-sensitive payments which do not
require the knowledge of a participant's identity as a part of the
transaction. Because of this, it is important to de-couple the
identification (non-identity based unique ID) of each participant in the
Architecture from the Identity data (sensitive/private data about the
participant) which describes information about a participant taking part
in the system
Security
Messages must not be altered in transit, but may be included as part
of encapsulating messages created by intermediaries.
It must be possible to provide read-only access to transaction
information to third parties (with user consent).
Signatures must be non-forgeable.
Identity, Privacy, and Consumer Protection
To satisfy regulatory requirements and financial industry
expectations, some use cases will require strong assurances of
connections between a Web identity and a real-world identity.
At the same time, any source of information that can lead to the
unintended disclosure or leakage of a user's identity (or purchasing
habits) is likely protected in a jurisdiction somewhere in the world by
a legal/regulatory entity having responsibility for its citizens.
For discussion: the role of per-transaction pseudo-anonymous
identity mechanisms for some use cases. These mechanisms would make it
much more difficult for an unauthorized party to track a user's
purchasing habits from 1 transaction to another transaction. This will
also eliminate the loss of that identity from affecting other services
that user is enrolled in.
Regulations in several jurisdictions require the consumer to be
notified every time their personal information/credentials are accessed.
To discuss: cryptography requiring a user's input/knowledge to open that
information.
Some purchases in combination (e.g., products accommodating prenatal
care needs) will leak sensitive information. To discuss: dynamic key
construction can be applied to each line item in a receipt to help
prevent unauthorized data mining of individuals, legal & regulatory
snooping. Even if the protected information is stolen or accidentally
forwarded to unauthorized parties they will not have the correct
tokenized inputs to recreate the dynamic keys to unlock access to the
protected information.
Role based access controls when applied to dynamic key construction
for each individual credential or large sets of data will help
facilitate interoperable access without needless duplication and
encryption of information for each authorized party. For discussion: Use
dynamic keys to protect a static key where various dynamic keys can be
used to unlock the static key that protects the sensitive content.
The system should support privacy by requiring only the minimal
amount of information necessary to carry out a transaction. Additional
considerations (e.g., marketing initiatives with user consent, or legal
requirements) may lead to additional information exchange beyond the
minimum required.
Payment account providers must take measures to ensure that account
identifiers are not, on their own, sufficient to identify the account
holder.
Another suggestion: 'Don't require personal authentication, but make
sure it can be done properly'
Legal and Regulatory
In some jurisdictions legal or regulatory entities may need to be
granted 'time-limited access' to a transaction to view specific
credentials and purchased items of the user. The system should limit
what is viewed to the minimum necessary. Examples: Government subsidies
such as food stamps, controlled substances. In these cases those
particular line items in the receipt may be required to be viewable via
individuals or computers charged with the responsibility to prevent
abuse of those programs (e.g., unauthorized reselling). There may also
be a requirement to view identities or credentials.
For certain classes of payments, such as high value or
international, it must be possible to provide role-based access controls
to pierce a pseudo-anonymous identity mechanism so the transaction can
be counter signed by a legal, regulatory, or KYC/AML system yet
safeguard against disclosing unnecessary information. It must be
infeasible for the piercing of this mechanisms to leak enough
information for those authorities to forge user information.
Accessibility
Web payment schemas, interfaces, data and the architectures that
enable them need to be made accessible for people with disabilities. Web
APIs and applications must be developed and implemented with
accessibility-in-mind and allow for accessibility features. If not,
developers, payees, providers and retailers may be in violation of
disability laws.
Discovery and instrument selection
Default expectation for privacy reasons is that payee will
present accepted schemes and computation of intersection (or other
compution) will happen on the payer side.
There are other scenarios to discuss that would presumably involve
user consent (e.g., computation done on payee side, or by a third
party platform).
Manual card entry will be with us for a while. When there is no
digital wallet, the working group should discuss (and possibly recommend
good practice) for dealing with the case where there is no registered
digital wallet. For example, one idea was for browsers to offer a sort
of "transient digital wallet" that acts within the protocol to handle
manual data entry.
Quoting Adrian Hope-Bailie idea: 'The algorithm MUST not prevent any
scheme from being available as a candidate for registration AND for this
matching/discovery process. i.e. It shouldn't be possible for the
browser (or any other component that executes this discovery process) to
exclude schemes or instruments on the basis of anything but technical
incompatibility.'
The standard should not hard-code a selection process. Regulatory
and cultural preferences may vary (e.g., the
Alibaba escrow use case).
