logo IPR declaration
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.
Through an extension to EMV, FWP can be used with virtually to any account-based payment system, including the eurozone's SEPA Instantlink.
Apart from obvious data format differences (CBOR/JSON/JavaScript versus ISO7816), the primary technical enhancement to EMV, is that the FWP client encrypts user-authorizations, enabling the following subgoals:
Scope
Note that FWP is not a payment system, it is a payment authorization scheme, 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 the 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.
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".
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 attributes:
NameDescription
credentialId FIDO key identifier for creating FWP signatures.
publicKey FIDO public key matching the private key associated with credentialId.
rpId FIDO relying party identifier for creating FWP signatures.
signatureAlgorithm FIDO signature algorithm for FWP signatures.
encryptionKey Issuer specific (shared) public encryption key. Unless an encryptionKeyId has been specified, the encryptionKey MUST be inserted in FWP encryption objects.
encryptionKeyId Optional. If specified, FWP encryption objects MUST contain this identifier.
contentEncryptionAlgorithm COSE compliant content encryption algorithm for FWP encryption.
keyEncryptionAlgorithm COSE compliant key encryption algorithm for FWP encryption.
accountId Account identifier associated with the credential.
serialNumber Text string that (with respect to the Issuer), uniquely identifies the payment credential.
paymentMethod URL holding the FWP method for a particular payment network.
issuerId Bank Identification Number (BIN) or URL associated with the Issuer. The exact definition is specific for each paymentMethod. See also Service Discovery.
cardImage 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.
Note: how attributes are represented in the credential database is implementation specific, whereas FWP assertions are normative.
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.
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.
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 to have clicked on a "Buy" button (after first having selected an FWP compliant payment method), 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://emvco.com/fwp/mastercard"
    },{
      name: "https://emvco.com/fwp/visa"
    },{
      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.show() method 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 unsigned or negative integer depending on the value.
  • 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 Since the authorization signature is intended to also cover the the FIDO publicKey and signatureAlgorithm associated with the selected FWP credential, these elements MUST also be included in the data to be signed.
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'412e175a0f0bdc06dabf0b1db79b97541c08dbacee7e31c97a553588ee922ea70500000000',
    4: h'7b2274797065223a22776562617574686e2e676574222c226f726967696e223a2268747470733a2f2f6d7962616e6b2e6672222c226368616c6c656e6765223a22437076662d4d4534453064464a706c677a4c4657527667347273776139772d3752304e45333172344f6134227d',
    5: h'3046022100f62898a14cfb61bcebd98e137313adb914bc942b6f9d37daf0933312ced74f68022100d4ed89843b0975628a4e649cb26214ac64a3080773ee67f0b817eb2e349e013b'
  }
}
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.
The actual CEF algorithms to use are defined by the contentEncryptionAlgorithm and keyEncryptionAlgorithm attributes.
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: "x25519:2021:3",
    5: {
      1: 1,
      -1: 4,
      -2: h'2d8105d3ba99b805dca0a15600e47aaa86661a9d0d943e4a6055be391086f841'
    },
    9: h'51f8475cd3ea7f3462b1ae64e69b22c159720bd9170aedb5793100dc07218e14b2f96587af11feb9'
  },
  7: h'978ae0a75c394daab7da559aed28f6cb',
  8: h'db9a70778883212674cab800',
  9: h'9c9763597a3f9f79ab78e5502f07863bc77ef8dccae3e4e53cbf918fad3ed4a87507c02f51154d7be9edb95331ede2473e64eb2d838e1ee82efc924b1b83406a6ea29fc398597887f72601db354b8325372784b4d7c2841a63635050c2261726eec6877ce1dcb214bcec8e8ee25cf50431fa27179062618c666d9a4f327fd0d497e0afc862b0da02bcb75cbe64e16e416cc7a96d1ff73a78f45f84fa7ba43fa8059c15dd1272e9ecc2469d3ecf24248947d5f43578b1895e5a6fd304d06a5e05269f1673129e50da62f96488cb4460ab2704cc415054147a190014962db8cbbcad8c012c7dbe8b70442139b6abfef76ce3b66602e6e53109dddad20f2e87b4d4cf846920a30ab889f2a640ab8824e6b178f733b69da6e0071ba19a61502bcd19f3e439f9a5857aaf57a92264e6c3988229e2c83661b61a8cea9b357ca7d983ba330e00e8d94b736fe2e98d5cfb531c38bc8737ffeee0885ce4943d2fe1516a9f77a32df5807f6772b18f936837d6f6859a90bca617ab4e22548acf423573a82a0f0fdcb7936b04630090ef65d1842c7dccf15de102091f612eec9e731e2bf21a24eb5848313cba03ae669fcd2d59798edf72ad1f365612008b5f0852d63485589536346b41e4103ffde18593e5026d1019765170b889c53ef6a2252eaef43a059fa527aaeb39f1513b7eb826adfaac318fd925cdc188e695fc8249322ccbc6fdb3a373ac60df'
}
This object is subsequently referred to as Encrypted Signed Authorization Data (ESAD). Note that the sample uses an encryptionKeyId.
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": "pQEDAqQBOB4DbXgyNTUxOToyMDIxOjMFowEBIAQhWCAtgQXTupm4BdygoVYA5HqqhmYanQ2UPkpgVb45EIb4QQlYKFH4R1zT6n80YrGuZOabIsFZcgvZFwrttXkxANwHIY4Usvllh68R_rkHUJeK4KdcOU2qt9pVmu0o9ssITNuacHeIgyEmdMq4AAlZAgacl2NZej-feat45VAvB4Y7x3743Mrj5OU8v5GPrT7UqHUHwC9RFU176e25UzHt4kc-ZOstg44e6C78kksbg0BqbqKfw5hZeIf3JgHbNUuDJTcnhLTXwoQaY2NQUMImFybuxod84dyyFLzsjo7iXPUEMfonF5BiYYxmbZpPMn_Q1Jfgr8hisNoCvLdcvmThbkFsx6ltH_c6ePRfhPp7pD-oBZwV3RJy6ezCRp0-zyQkiUfV9DV4sYleWm_TBNBqXgUmnxZzEp5Q2mL5ZIjLRGCrJwTMQVBUFHoZABSWLbjLvK2MASx9votwRCE5tqv-92zjtmYC5uUxCd3a0g8uh7TUz4RpIKMKuInypkCriCTmsXj3M7adpuAHG6GaYVArzRnz5Dn5pYV6r1epImTmw5iCKeLINmG2GozqmzV8p9mDujMOAOjZS3Nv4umNXPtTHDi8hzf_7uCIXOSUPS_hUWqfd6Mt9YB_Z3Kxj5NoN9b2hZqQvKYXq04iVIrPQjVzqCoPD9y3k2sEYwCQ72XRhCx9zPFd4QIJH2Eu7J5zHivyGiTrWEgxPLoDrmafzS1ZeY7fcq0fNlYSAItfCFLWNIVYlTY0a0HkED_94YWT5QJtEBl2UXC4icU-9qIlLq70OgWfpSeq6znxUTt-uCat-qwxj9klzcGI5pX8gkkyLMvG_bOjc6xg3w"
}
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•••xg3w"
  },
  "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•••xg3w"
    },
    "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.
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 SHA256 hashes of ESAD objects associated with successfully processed requests. Cached items would be removed based on their SAD.timeStamp value.
Ideally, Issuers SHOULD support idempotent operation to facilitate transaction retries that may happen due to network glitches or similar.
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.
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.
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.
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 on the 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-07-260.22Added document "FIDO Web Pay - Crypto".
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.