logo IPR declaration
FIDO Web Pay
Table of Contents
1 Introduction
2 Scope
3 Terminology
4 Credential Database
5 Enrollment
6 Detailed Operation
    1: Initiate PaymentRequest
    2: Show Payment Authorization UI
    3: Perform User Authorization
    4: Create FWP Assertion
        4.1 Extract PaymentRequest Core Data (PRCD)
        4.2 Create Authorization Data (AD)
        4.3 Create Signed Authorization Data (SAD)
        4.4 Create Encrypted Signed Authorization Data (ESAD)
        4.5 Assemble FWP Assertion
    5: Return FWP Assertion
    6: Process FWP Assertion and Create PSPRequest Object
    7: Send PSPRequest Object
    8: Process PSPRequest and Create IssuerRequest Object
    9: Send IssuerRequest Object
    10: Process IssuerRequest
        10.1 Core Validation
        10.2 Extract Signed Authorization Data (SAD)
        10.3 Validate Request Data
        10.4 Validate Authorization Signature
        10.5 Replay Handling
        10.6 Other Validation Steps
8 Delegated Authorization
    D1: Process PSPRequest and Create AuthorizeRequest Object
    D2: Send AuthorizeRequest Object
    D3: Process AuthorizeRequest
    D4: Return Authorized Data
    D5: Create Payment Instruction
    D6: Invoke "Payment Rails"
    D7: Process Payment Instruction
Security Considerations
Integration
Extensions
Implementation Options
Usage of CBOR
Acknowledgements
Document History
Authors
Trademarks
1. Introduction
EMV®link represents the current "Gold Standard" for secure and convenient payments in the physical world.
This document describes FIDO® Web Pay (FWP), which is a Web-adapted version of EMV, combining the technology underpinning FIDO2link with the W3C PaymentRequestlink API and a browser-resident (built-in) payment application.
Apart from obvious data format differences (CBOR/JSON/JavaScript versus ISO7816), this specification introduces two major enhancements to EMV:
  1. By separating account numbers from issuer (bank branch) identifiers, FWP can be used with virtually any account-based payment system, including the eurozone's SEPA Instantlink.
  2. Through encryption of user-authorizations, FWP enables additional security and privacy features:
    • Obviating the need for external tokenization services.
    • Limiting the amount of personally identifiable information (PII) shared with third parties like merchants, to the name of the user's bank and payment method, making FWP intrinsically compliant with PCIlink requirements as well as with GDPRlink.
Since applying FIDO to payments typically require updating multiple "backend" components and services, FWP was designed from the ground-up to keep the complexity of matching backends at a comparatively modest levellink.
2. Scope
Note that FWP is not a payment system, it is a universal payment authorization method, exclusively dealing with the user's part of the payment process. That is, the backend infrastructure and associated APIs are out of scope for this specification.
However, to guide implementers, this document outlines a sample infrastructure at a "conceptual" level. Note though that regardless of backend design, FWP assertions must (due to the EMV end-to-end security model), always be routed back to the designated issuer "verbatim" (together with other required data) in order to initiate a payment transaction.
It is assumed that at this stage in time, backend infrastructures will be independently defined by each payment network rather than becoming a unified standard. See also Integration.
3. Terminology
Throughout the rest of this document, actor names are written as Name. The Browser actor is in this specification considered to be equivalent to "User Agent". A PSP (Payment System Provider) is in this specification denoting any service or network acting as a trusted intermediary between a Merchant and an Issuer. In FWP objects, Merchant is referred to as "payee".
The CBOR types unsigned integer and negative integer are in this document denoted as integer only. That is, it is the value which governs the actual type.
4. Credential Database
The steps outlined in Detailed Operation depend on that the User already have received one or more FWP credentials ("Virtual Cards") in an Enrollment process. FWP credentials are stored in a local database in the client device, where each entry is supposed to contain the following CBOR attributes:
NameLabelTypeDescription
version 1 text string Since credential data may evolve over time, versioning is necessary. This specification covers version "1.0".
credentialId 2 byte string FIDO key identifier for creating FWP signatures.
publicKey 3 map COSE compliant FIDO public key matching the private key associated with credentialId.
signatureAlgorithm 4 integer FIDO key/signature algorithm for FWP signatures.
encryptionKey 5 map COSE compliant Issuer specific (shared) public encryption key. See FWP encryption.
encryptionKeyId 6 byte string Optional. See FWP encryption.
contentEncryptionAlgorithm 7 integer COSE compliant content encryption algorithm. See FWP encryption.
keyEncryptionAlgorithm 8 integer COSE compliant key encryption algorithm. See FWP encryption.
accountId 9 text string Account identifier associated with the credential.
serialNumber 10 text string Text string that (with respect to the Issuer), uniquely identifies the payment credential.
paymentMethod 11 text string URL holding the FWP method for a particular payment network.
issuerId 12 text string Bank Identification Number (BIN) or URL associated with the Issuer. The exact definition is specific for each paymentMethod. See also Service Discovery.
cardImage 13 byte string UTF-8 encoded SVG image identifying the payment credential for the User. The content of such images are entirely Issuer specific, but images MUST adhere to certain (TDB), dimensions in order to render properly by the wallet.
Through the use of a dedicated credential database, associated FIDO keys can be freely used by the FWP implementation, while remaining invisible and protected from access by all parties but their respective Issuer.
5. Enrollment
The exact enrollment process is yet to be defined; the assumption is that it could be accomplished by extending the existing W3C Web Authenticationlink enrollment system. The extension would enable the Browser to securely distinguish between "ordinary" FIDO keys, and those targeted for payments which is required for maintaining a database in the Browser holding FWP credentials.
It would be great if the enrollment system could handle multiple credentials in a single operation, because an Issuer may want to support international card networks as well as national or regional payment networks 😎
It MAY be technically feasible using a FIDO key associated with an FWP credential for Web Authentication as well, but this would be a deployment decision by the Issuer.
FWP effectively forms a browser "Wallet", holding an arbitrary number of payment credentials, each representing a specific Issuer, User account, and paymentMethod.
6. Detailed Operation
This section describes the different steps needed to authorize a payment operation using FWP. To improve readability, JSON data is "pretty-printed", while CBOR data is provided in "diagnostic notation".
The foundation for the description is the following sequence diagram sample where each step is linked to a clickable number in a box:
FIDO Web Pay - Sample Sequence Diagram User Symbol User Browser Symbol Browser Merchant Symbol Merchant PSP Symbol PSP Issuer Symbol B  A  N  K Issuer PaymentRequest 1 Payment UI 2 Authorization 3 Processing 4 FWP Assertion 5 Processing 6 PSPRequest 7 Processing 8 IssuerRequest 9 Processing 10
Note that the normative part of this specification only covers the steps within the dotted rectangle. That is, how FWP implements the PaymentRequestlink interface.
1
Initiate PaymentRequest
At this point the User is assumed having clicked on an FWP compliant icon like
fwp pay
causing a Merchant Web page to invoke a custom doPaymentRequest() method, like in the following sample:
// FWP sample code

const methodData = [{
  supportedMethods: "fido-web-pay/v1",
  data: {
    payeeName: "Space Shop",  // Shown in the UI
    networks: [{
      name: "https://mastercard.com/fwp"
    },{
      name: "https://visa.com/fwp"
    },{
      name: "https://bankdirect.com",
      networkData: "additional stuff..."
    }]
  }
}];

const request = new PaymentRequest(methodData, {
  id: "7040566321",   // Mandatory for FWP
  total: {label: null, amount: {currency: "EUR", value: "435.00"}}
});

async function doPaymentRequest() {
  const response = await request.show();
  await response.complete("success");
  return response.details;
}
When the PaymentRequest constructor is invoked, the Browser (FWP implementation) MUST perform the following checks:
Any deviations MUST throw an exception.
Note that the name properties in the networks array denote the actual payment methods, corresponding to the paymentMethod attribute in FWP credentials.
Note that the PaymentRequest.canMakePayment() method MUST return true if the User have one or more FWP credentials, regardless if they match the associated PaymentRequest list or not; else it MUST return false.
2
Show Payment Authorization UI
After successful invocation of the PaymentRequest.show() method, the Browser responds with a payment authorization UI like the following:
Payment UI
Non-normative UI in "dark mode".
If the User has no matching payment credentials, the Browser MUST indicate that and give the User an option to return to the Merchant "Checkout" page.
If the User has multiple matching payment credentials, the Browser MUST provide a way to select a specific credential. In the sample UI shown above, the User can swipe credentials to the left and right, while arrow symbols are used to show if there are more credentials available. That is, if there is no left arrow, the credential selector is at the left end point.
If a selected credential is associated with an external token which is currently not available, the User should be asked to insert it.
3
Perform User Authorization
At this point the User authorizes the request with a fingerprint, PIN, or similar. A successful user authorization causes the next step to be performed.
4
Create FWP Assertion
At this point the Browser creates an FWP assertion which requires the following steps to be performed:
4.1 Extract PaymentRequest Core Data (PRCD)
Create a CBOR representation of the core payment request data supplied by the Merchant. For the sample code this should result in the following object:
{
  1: "Space Shop",
  2: "7040566321",
  3: "435.00"
  4: "EUR"
}
Definition:
NameLabelTypeDescription
payeeName 1 text string Merchant common name.
requestId 2 text string Merchant request Id. Copy of details.id.
amount 3 text string Amount of money requested by the Merchant.
currency 4 text string The type of currency requested by the Merchant.
This object is subsequently referred to as PaymentRequest Core Data (PRCD).
Note that throughout this specification, elements are referred to by their symbolic name rather than by their CBOR label.
4.2 Create Authorization Data (AD)
Create a CBOR object representing the data to authorize. For the sample code this should result in the following object:
{
  1: "1.0",
  2: {
    1: "Space Shop",
    2: "7040566321",
    3: "435.00",
    4: "EUR"
  },
  3: "spaceshop.com",
  4: "FR7630002111110020050014382",
  5: "0057162932",
  6: "https://bankdirect.com",
  7: "additional stuff...",
  8: {
    1: {
      3: "Android",
      4: "10.0"
    },
    2: {
      3: "Chrome",
      4: "103"
    }
  },
  9: 0("2021-07-02T12:34:07+02:00"),
  10: {
    1: -7,
    2: {
      1: 2,
      -1: 1,
      -2: h'e812b1a6dcbc708f9ec43cc2921fa0a14e9d5eadcc6dc63471dd4b680c6236b5',
      -3: h'9826dcbd4ce6e388f72edd9be413f2425a10f75b5fd83d95fa0cde53159a51d8'
    }
  }
}
Definition:
NameLabelTypeDescription
version 1 text string FWP assertion data version. This specification covers version "1.0".
paymentRequest 2 map Copy of PaymentRequest Core Data (PRCD).
payeeHost 3 text string Host name as interpreted by the Browser. Included for optional validation by the Issuer, aided by the PSP.
accountId 4 text string User account number associated with the selected FWP credential.
serialNumber 5 text string Unique identifier associated with the selected FWP credential.
paymentMethod 6 text string Payment method associated with the selected FWP credential. Included for "completeness".
networkData 7 Arbitrary Optional. This attribute MUST be included if specified in the PaymentRequest constructor for the particular paymentMethod, otherwise it MUST NOT be defined.
Note that possible networkData data is specified by the calling Merchant as JavaScript, but MUST subsequently be converted to CBOR when included in this object. Due to a mandated restriction on the JavaScript Number type, this conversion is straightforward:
  • Number is converted to integer.
  • String is converted to text string.
  • Object is converted to map.
  • Array is converted to array.
  • null, true, and false are converted to their respective CBOR counterpart.
platformData 8 map Up-to-date information about the core software components. Included for security and logging purposes.
The outer CBOR map contains two entries, 1 for the operating system, and 2 for the "user-agent" (browser), while the sub-maps hold name (3) and version (4) respectively.
Note that hardware (device) data is assumed to be established during credential enrollment.
timeStamp 9 date string ISO (RFC3399link) time stamp generated by the FWP implementation. If the local time zone is known, it SHOULD be included, else the UTC notation ("Z") MUST be used.
authorization 10 map See FIDO Web Pay - Cryptolink for details.
This object is subsequently referred to as Authorization Data (AD).
AD is (after SHA256-digesting), used as the sole FIDO "challenge" source.
4.3 Create Signed Authorization Data (SAD)
Now apply the FIDO signature key (identified by credentialId), associated with the selected FWP credential to sign AD using the scheme described in FIDO Web Pay - Cryptolink. For the sample code this should result in the following object:
{
  1: "1.0",
  2: {
    1: "Space Shop",
    2: "7040566321",
    3: "435.00",
    4: "EUR"
  },
  3: "spaceshop.com",
  4: "FR7630002111110020050014382",
  5: "0057162932",
  6: "https://bankdirect.com",
  7: "additional stuff...",
  8: {
    1: {
      3: "Android",
      4: "10.0"
    },
    2: {
      3: "Chrome",
      4: "103"
    }
  },
  9: 0("2021-07-02T12:34:07+02:00"),
  10: {
    1: -7,
    2: {
      1: 2,
      -1: 1,
      -2: h'e812b1a6dcbc708f9ec43cc2921fa0a14e9d5eadcc6dc63471dd4b680c6236b5',
      -3: h'9826dcbd4ce6e388f72edd9be413f2425a10f75b5fd83d95fa0cde53159a51d8'
    },
    3: h'412e175a0f0bdc06dabf0b1db79b97541c08dbacee7e31c97a553588ee922ea70500000017',
    4: h'7b2274797065223a22776562617574686e2e676574222c226f726967696e223a2268747470733a2f2f6d7962616e6b2e6672222c226368616c6c656e6765223a22437076662d4d4534453064464a706c677a4c4657527667347273776139772d3752304e45333172344f6134227d',
    5: h'30450221008535c37d9f55ed2fed9b5d02c22f2265e0606d6eb59ffd2cd9214a464374f6a8022048c921185c805f209be3a288a158d117c8eff25e27d5d62ff595a7e8d14089f2'
  }
}
This operation updates the authorization (10) element of AD.
The resulting object is subsequently referred to as Signed Authorization Data (SAD).
There is no FIDO authentication server involved in this step since FWP builds on the same "Card Present" authorization concept as EMV.
4.4 Create Encrypted Signed Authorization Data (ESAD)
For privacy and security reasons, Signed Authorization Data (SAD) objects MUST be encrypted by a public key provided by the Issuer through the encryptionKey attribute of the selected FWP credential.
This specification mandates the encryption scheme described in FIDO Web Pay - Cryptolink.
Note that the public key MUST be shared with other clients of the Issuer, otherwise it will work as a static identifier to the specific User!
Encryption sample object:
{
  1: 3,
  2: {
    1: -31,
    3: h'7832353531393a323032313a33',
    5: {
      1: 1,
      -1: 4,
      -2: h'725a88195444c070fdf267ccd0ffcaf4724b677c1677597ae5d464d3d3ac8062'
    },
    9: h'dea3030f3fb794cf580d07c1c05d43ef730b15b900dfd408aa2659b7f0647294bee20f8090aaae90'
  },
  7: h'dbcfcad2e4ee682ec577378473f676fe',
  8: h'dd6000d2f23dc2399098f0a4',
  9: h'85d0c7bccda29e956dc9defe646930a9e603d87312995bcc210d3afd223f715cbbaced9b032297eb1f9014b3051b62c2a402717d89874b150c7465647345e5e8311fb578bd39db3ac018190b6c5c3502fe20b56fea95d23ce8a8458bf6582702405b5371827630fac49fda3440ed29c9398afb7e5f0b72524311936a3f69aeefbd43ec263b3b7424ba540c2e06f521605ba9742fd98cb2a78613df968e8c6a8381ff4018f47e9febb544744aa04cc2d38afb9e498551a9ad586cad0315717f9c3585bdbbdb8b958f79fa774541f2121f6d956aec84ad50cf3f277495f44e8c14b80db75bc5783c15b18864cc433adaf36cb5dd2396ad98cf8da5c42ffb6f8ac790788b501b0b5f664c016a0bfc3da22faef9120dd845729ad9af0a9308cbe6905a6b595c03590a4d247a4c16ee1f6f4c578d58edb898b0308d0e70f5c3eb0e6d34a7d4cb0e48568a234adf3670b5a888ad2b736027ff20745daa061da61820dc22dc1ff5a0ebed155a95fd07aff0d8247c56c32b8fd35a9121067eb3203efa40bf6aff87daf0b7d5921b3aab5d3bdccacf3886ca31d29579bccfb0ef9fb7d162580c112ace41c05835d7759f3c8a019439e553afa2f0a9c06a9c9b7a04299ba7b04dd865038b005aacf154d05b7ab62472b0955015bc52d4fe74fd0563588ae0dbbfe7598ab1003fbd69062034ab46fa72e4021d0768ecf02cdbffef0be8afd0dd5a99d7e4'
}
This object is subsequently referred to as Encrypted Signed Authorization Data (ESAD).
Due to the end-to-end encryption scheme, the domain constraints associated with Web Authentication assertions do not apply.
4.5 Assemble FWP Assertion
Create a JSON-serializable JavaScript object representing an FWP Assertion. For the sample code this should result in the following object:
{
  "paymentMethod": "https://bankdirect.com",
  "issuerId": "https://mybank.fr/payment",
  "encryptedAuthorization": "pQEDAqQBOB4DTXgyNTUxOToyMDIxOjMFowEBIAQhWCByWogZVETAcP3yZ8zQ_8r0cktnfBZ3WXrl1GTT06yAYglYKN6jAw8_t5TPWA0HwcBdQ-9zCxW5AN_UCKomWbfwZHKUvuIPgJCqrpAHUNvPytLk7mguxXc3hHP2dv4ITN1gANLyPcI5kJjwpAlZAgWF0Me8zaKelW3J3v5kaTCp5gPYcxKZW8whDTr9Ij9xXLus7ZsDIpfrH5AUswUbYsKkAnF9iYdLFQx0ZWRzReXoMR-1eL052zrAGBkLbFw1Av4gtW_qldI86KhFi_ZYJwJAW1NxgnYw-sSf2jRA7SnJOYr7fl8LclJDEZNqP2mu771D7CY7O3QkulQMLgb1IWBbqXQv2Yyyp4YT35aOjGqDgf9AGPR-n-u1RHRKoEzC04r7nkmFUamtWGytAxVxf5w1hb2724uVj3n6d0VB8hIfbZVq7IStUM8_J3SV9E6MFLgNt1vFeDwVsYhkzEM62vNstd0jlq2Yz42lxC_7b4rHkHiLUBsLX2ZMAWoL_D2iL675Eg3YRXKa2a8KkwjL5pBaa1lcA1kKTSR6TBbuH29MV41Y7biYsDCNDnD1w-sObTSn1MsOSFaKI0rfNnC1qIitK3NgJ_8gdF2qBh2mGCDcItwf9aDr7RValf0Hr_DYJHxWwyuP01qRIQZ-syA--kC_av-H2vC31ZIbOqtdO9zKzziGyjHSlXm8z7Dvn7fRYlgMESrOQcBYNdd1nzyKAZQ55VOvovCpwGqcm3oEKZunsE3YZQOLAFqs8VTQW3q2JHKwlVAVvFLU_nT9BWNYiuDbv-dZirEAP71pBiA0q0b6cuQCHQdo7PAs2__vC-iv0N1amdfk"
}
Definition:
NameTypeDescription
paymentMethod String Payment method associated with the selected FWP credential.
issuerId String Issuer identifier associated with the selected FWP credential.
encryptedAuthorization String Encrypted Signed Authorization Data (ESAD) supplied in a Base64Url string (in subsequent examples shown as a placeholder only).
The FWP Assertion is made available to the PaymentRequest invocation code via the PaymentResponse.details attribute.
An alternative to using issuerId attributes for service end-points, is populating issuerId attributes with Service Discovery URLs, which in turn provide the actual service end-points (as well as other information that may be required before service invocation).
5
Return FWP Assertion
At this point the checkout Web code would normally return the completed FWP Assertion to the Merchant server through a FORM POST or fetch() operation.
6
Process FWP Assertion and Create PSPRequest Object
After receiving the FWP Assertion, the Merchant would usually call a PSP with a specifically crafted object. The exact definition is likely to be specific for each PSP network and is therefore out of scope for this specification. The following sample outlines such an object:
{
  "paymentRequest": {
    "payeeName": "Space Shop",
    "requestId": "7040566321",
    "amount": "435.00",
    "currency": "EUR"
  },
  "fwpAssertion": {
    "paymentMethod": "https://bankdirect.com",
    "issuerId": "https://mybank.fr/payment",
    "encryptedAuthorization": "pQED•••mdfk"
  },
  "receiveAccount": "DE89370400440532013000",
  "clientIpAddress": "220.13.198.144",
  "timeStamp": "2021-07-02T10:34:22Z"
}
Definition:
NameTypeDescription
paymentRequest Object Copy of PRCD, recreated by the Merchant, but now in JSON notation using the names from the table showing the CBOR version.
fwpAssertion Object Copy of the FWP Assertion.
receiveAccount String Merchant account to be credited.
clientIpAddress String Request IP address (in V4 or V6 format) of the User device. Included for security and logging purposes.
timeStamp String ISO time stamp generated by the Merchant.
7
Send PSPRequest Object
At this point the Merchant sends the completed PSPRequest object to the appropriate PSP.
Note that authentication of the Merchant is out of scope for this specification.
Since FWP supports multiple and independent payment systems, a Merchant may use different PSPs depending on received paymentMethod.
8
Process PSPRequest and Create IssuerRequest Object
After successfully having authenticated the Merchant request, the PSP MUST perform a number of checks on the received object including:
Any deviations MUST cause the request to be rejected. Fault handling is out of scope for this specification.
The next step is creating a suitable IssuerRequest object. The exact definition is likely to be specific for each payment network and is therefore out of scope for this specification. The following sample outlines such an object:
{
  "pspRequest": {
    "paymentRequest": {
      "payeeName": "Space Shop",
      "requestId": "7040566321",
      "amount": "435.00",
      "currency": "EUR"
    },
    "fwpAssertion": {
      "paymentMethod": "https://bankdirect.com",
      "issuerId": "https://mybank.fr/payment",
      "encryptedAuthorization": "pQED•••mdfk"
    },
    "receiveAccount": "DE89370400440532013000",
    "clientIpAddress": "220.13.198.144",
    "timeStamp": "2021-07-02T10:34:23Z"
  },
  "payeeHost": "spaceshop.com",
  "timeStamp": "2021-07-02T10:34:23Z"
}
Definition:
NameTypeDescription
pspRequest Object Copy of the PSPRequest object received from the Merchant.
payeeHost String The Merchant host name registered by the PSP.
timeStamp String ISO time stamp generated by the PSP.
9
Send IssuerRequest Object
At this point the PSP sends the completed IssuerRequest object to the designated Issuer. Note that the method used for locating the proper Issuer depends on the paymentMethod and issuerId attributes. In the sample the IssuerRequest object would presumably be sent to https://mybank.fr/payment.
10
Process IssuerRequest
Before initiating a payment transaction the Issuer MUST decode and perform a number of steps to verify the correctness of the received IssuerRequest object. Any deviation MUST terminate the operation in progress and return an error message to the PSP in a not here specified manner.
Note that pspRequest is a sample. However, regardless of the actual implementation, the data referred to here MUST still be available.
10.1 Core Validation
10.2 Extract Signed Authorization Data (SAD)
10.3 Validate Request Data
10.4 Validate Authorization Signature
10.5 Replay Handling
To cope with possible replays, verify that the received User authorization has not already been used. This can be accomplished by maintaining a lookup cache holding received SAD objects. Due to the unique, account specific data featured in SAD objects, authorizations associated with different accounts may share a common cache. Since authorization signatures encompass variant data like the timeStamp and paymentRequest elements, as well as the signature counter in FIDO authenticatorData objects, false cache collisions on individual SAD objects should be "impossible", also in the cryptographic sense. Cached SAD objects can safely be removed when expired, preferable using a background process.
See Replay Cachelink for a sample in Java.
Note that using this scheme, SAD objects MUST be fully validated before being added to the cache!
Ideally, Issuers SHOULD support idempotent operation to facilitate transaction retries that may happen due to network glitches or similar.
10.6 Other Validation Steps
Obviously there are other things to verify but these are not directly related to FWP, like checking that the User has funds available matching the current request.
8. Delegated Authorization
Using delegated authorization the validation of User authorizations is separated from payment initiations. The purpose with such arrangements include:
Note that FWP makes the use of delegated authorization transparent for both the User and the Merchant.
Delegated authorization differs from 3D Securelink by keeping the authorization process and associated User account information, inside of the core payment network. This enables validation of potentially untrusted Merchant data as well as eliminating dependencies on certified Merchant 3D Secure SDKs.
Delegated authorization builds on the assumption that the PSP is trusted for carrying out payment initiations on behalf of a User (based on a preceding User authorization step), which is an established concept in most payment networks. (In the FWP standard mode the PSP only acts as a proxy for the Merchant).
The delegated authorization mode is illustrated by the following sequence diagram:
FIDO Web Pay - Sample Delegated Sequence Diagram Merchant Symbol Merchant PSP Symbol PSP Authorizer Symbol Authorizer Issuer Symbol B  A  N  K Issuer PSPRequest 7 Processing D1   AuthorizeRequest D2 Processing D3 Authorization D4 Processing D5 "Payment Rails" D6 Processing D7
Note that step 1-7 are identical to the FWP "standard" mode. "Payment Rails" refer to existing payment systems.
In an Open Banking context the PSP would be equivalent to a PISP while the Authorizer would be a specialized AS.
D1
Process PSPRequest and Create AuthorizeRequest Object
This step should involve the same verifications as in step 8 in the standard mode. A suitable AuthorizeRequest object would typically follow the IssuerRequest sample in step 8.
Using delegated authorization may be decided by each Issuer individually. The actual configuration is preferably resolved by making the issuerId attribute play the role of a Service Discovery URL.
D2
Send AuthorizeRequest Object
At this point the PSP sends the completed AuthorizeRequest object to the designated Authorizer. Note that the method used for locating the proper Authorizer depends on the paymentMethod and issuerId attributes.
D3
Process AuthorizeRequest
This step should involve the same verifications as in step 10 in the standard mode.
D4
Return Authorized Data
If the preceding step is successful, AuthorizeRequest would typically return the (now decrypted) User account number.
A more sophisticated approach would be to return signed data for maintaining the end-to-end security model. For card payments this would preferably be in the form of EMV compliant objects that can be passed on to existing payment systems "as is".
 
In an Open Banking implementation based on OAuth2 concepts, the return data would contain access tokens and consent information.
D5
Create Payment Instruction
After receiving the User account number a payment instruction object is created. The format and contents of such objects are payment network specific and are therefore not described here.
D6
Invoke "Payment Rails"
Perform a payment instruction request in a payment network specific way.
D7
Process Payment Instruction
Process the payment instruction request in a payment network specific way.
Security Considerations
Security in FWP depends to a large extent on the W3C PaymentRequestlink API which acts as a "moderator" between the untrusted Web and payment applications. That does though not stop an arbitrary Web site from invoking FWP when the user clicks a link on that site. However, if the site does not represent a genuine merchant even a completed user authorization will not lead to a security breach, because properly designed backend systems will block the rest of the process since the requester would not be recognized. If on the other hand the site is legitimate, the assumption is that in order to become a merchant entitled to request payments, you usually need to follow specific rules regarding how and when payments requests may be performed.
It is technically possible creating Web applications that look like FWP ("spoofing"), but they are not able producing valid assertions since that requires unconstrained access to FIDO keys which is reserved for FWP (which runs with higher privileges than ordinary Web code).
If the internal clock of an FWP client is severely out of sync, associated authorizations will be rejected. This also makes clock manipulations useless as attack vectors.
FWP is of course also dependent on that the underlying software is operating correctly. Bugs or successful attacks on the platform may force the FWP system to perform payments in the background or violate the user's privacy.
Integration
It is pretty clear that the integration of systems like FWP in payment networks is crucial for acceptance by the market.
For card based payments FWP implementations can build on the existing EMV foundation since essentially only the formats differ. Although the lack of a PAN (card number) in FWP may appear as a major obstacle, the issuerId would in this case hold a "neutered" PAN where the BIN (Bank Identification Number) is set, while the rest are set to zeroes + Luhn check digit. E.g. VISA: 4972039000000004. However, using Issuer URLs is also a viable alternative for card payments because payment processors associated with "regular" EMV and FWP payments would probably not share end points.
For account-to-account payments there are currently no generally agreed upon standards for consumer payments, but remapping existing card based systems and infrastructures seems though like a possible path.
Delegated Authorization represents yet another way addressing payment system integration.
Extensions
The FWP client is loosely derived from a proof-of-concept system called Saturnlink. By continuing along this path, features like the following could potentially be added:
Note that some of the features above could impact the PaymentRequest API.
Implementation Options
An alternative to building FWP support into browsers, is moving the FWP implementation (including the credential database), down into the client platform layer. This would open FWP to other scenarios like:
Such an arrangement would also introduce additional features including:
Usage of CBOR
That the internals of FWP assertions are based on CBOR rather than JSON may seem odd since CBOR currently is not particularly common on the Web. However, there is a pretty strong rationale for using CBOR for this application including:
Acknowledgements
The FWP core was heavily influenced by an earlier Microsoft research project called Windows CardSpacelink.
The User icon was derived from https://commons.wikimedia.org/wiki/File:Crystal_Clear_kdm_user_female.svglink
Document History
DateVersionComment
2021-03-120.1Initial publishing.
2021-03-150.11Added external token comment.
2021-03-290.12Improved replay handling + Changed "Acquirer" to "PSP".
2021-04-020.13Added section Delegated Authorization.
2021-04-110.14Added credentialId + more text in Credential Database.
2021-04-140.15Added section Implementation Options.
2021-04-160.16Added sequence diagram "scope" rectangle.
2021-05-090.17Simplification: Removed hashing of PRCD.
2021-05-190.18Aligned wallet database with FIDO names.
2021-06-030.19Added IPR declaration.
2021-06-210.20Converted the FWP core to CBOR (was JSON).
2021-07-020.21Removed redundant FINGERPRINT item.
2021-08-020.22Added document "FIDO Web Pay - Crypto" and ToC.
2021-08-270.23Added section Security Considerations.
2021-09-300.24Added CBOR types in Credential Database.
Authors
The FWP specification is currently authored by Anders Rundgren (anders.rundgren.net@gmail.com) on GitHub (https://github.com/fido-web-pay/specificationlink).
Trademarks
FIDO is a registered trademark of the FIDO alliance.
EMV is a registered trademark of EMVCo.
 
This specification represents an independent effort, not associated with the FIDO alliance or EMVCo.