Digital Wallets and Payment Agents

Although the capabilities described in this document may be used and composed in a variety of ways to fulfill payments use cases, the Interest Group anticipates that in many cases, they will be packaged in “payment agents” (or “digital wallets”) that act as a bridge between the merchant, the user, and the user’s account providers.

Core and Security

1. Key Management
   1. All participants require an interchangeable mechanism for creation, management, storage, and exchange of cryptographic keys
   2. Key management capabilities are required to:
      1. Securely communicate unique identifiers of payment process participants
      2. Digitally sign and authenticate information exchanged as part of the payments process (e.g., payments, receipts, invoices, etc.)
      3. Provide reference key for independent elements of the payments process to compose/link transactions and related data across asynchronous segments of the payment process
2. Cryptographic Signatures
1. Information transferred should be cryptographically signed to ensure
   1. Authenticity of the participants and ownership of value/asset being transferred or exchanged
   2. Nonrepudiationof participants intent related to information / communication being exchanged

Identity and Credentials

1. Identity
   1. 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
   2. 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.
2. Credentials
   1. 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. Thisallows 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)
   2. Payer is able to exchange standard format credentials with Payee to validate attributes necessary to complete the payment
3. Rights
4. Authentication
   1. Participants are able to authenticate the validity of identifiers presented by entities that they are interacting with
5. Authorization
6. Privacy
   1. 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.
7. Discovery
   1. Payer is able to securely locate public identifier of Payee to be used as part of payment process
   2. Payee is able to obtain public identifier of Payer participating in payment process
   3. Payer identifier is persistent across devices
8. Registration
   1. Payer and Payee able to register with Payment Services Provider to obtain credentials used for payments process
9. Enrollment
   1. Payment services 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.
10. Legal/Regulatory concerns related to Trust and Identity

Accounts and Settlement

Payments and Exchange

1. Payment Instrument Discovery and Selection
   1. Payer and payee are able to discover payment instruments/schemes which they have in common and may be used in the payment process
   2. Payer is able to establish the different costs of making the payment using the various combinations of payer and payee instruments and schemes (payment methods)
   3. Payer is able to select payment instrument for use in the payment process
   4. 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
2. Payment Initiation
   1. Payer is able to initiate a payment using selected payment instrument
   2. Payer is able to identify Payee via:
      1. Information received via Invoice
      2. Individual contact information
      3. Information from past payees
   3. Payee is able to initiate a request for payment to payee’s designated account provider
   4. Account provider is able to initiate a payment on behalf of the Payee based on Payee’s requested schedule and frequency (recurring payment)
3. Payment Authorization
   1. 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
   2. Payment service provider is able to demonstrate to payer account provider that payment is authorised
4. Payment Execution
   1. Payment orchestrator is able to evaluate that all requirements have been met to execute the payment including authorization(s) and compliance checks as required.
   2. 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.
5. Payment Acknowledgement
   1. Payee is able to receive confirmation that payment has been successfully completed
   2. Payer is able to receive verification that payment has been successfully received
   3. Account provider is able to receive confirmation that payment is complete
6. Regulatory/Legal Compliance
   1. Regulator is able to access/view required payment, payer, and payee details for payments that take place within their jurisdiction
   2. Regulator is able to intervene in payments meeting or exceeding certain thresholds or criteria in order to comply with jurisdictional laws and requirements
7. Payment Settlement and Clearing
   1. Payment service provider is able to provide payer with quotesto settle payee via all payee supported payment schemes

Commerce

Invoices

1. Invoice creation
   1. Payee is able to generate a standard formatted invoice and communicate to Payer as part of the negotiation of payment terms
2. Invoice receipt
   1. Payer is able to receive standard formatted invoice
3. Invoice data
   1. Invoice provides payer with Payment instructions for making payment to Payee
   2. Invoice identifier is returned to Payee via payment process to verify payment is complete

Receipts

1. Create Receipt
   1. Payee is able to create receipt and communicate receipt to Payer following completion of payment
2. Receive Receipt
   1. Payer is able to receive receipt and persist for future use (ex. returns, reimbursement, etc)

Loyalty

1. Payer is able to register with Payee’s loyalty program by requesting loyalty identifier from Payee.
2. Payee can “opt-in” to loyalty program by providing program specific public identifier

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).