EMV® 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 FIDO2
with the W3C
PaymentRequest 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:
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 Instant.
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 network,
making FWP intrinsically compliant with
PCI
requirements as well as with GDPR.
Since changes in payment systems 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 level.
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.
See also Integration.
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.
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".
In this document CBOR primitives are expressed in
CDDL [RFC8610]
notation.
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:
Name
Label
Type
Description
version
1
tstr
Since credential data may evolve over time, versioning is necessary.
This specification covers version
"https://fido-web-pay.github.io/ns/w1"
which is compatible with FWP assertions of the type described here
("https://fido-web-pay.github.io/ns/p1").
COSE compliant content encryption algorithm. See FWP encryption.
keyEncryptionAlgorithm
9
int
COSE compliant key encryption algorithm. See FWP encryption.
accountId
10
tstr
Account identifier associated with the credential.
paymentNetworkId
11
tstr
URL or predefined short string identifying the associated payment network.
issuerId
12
tstr
Bank Identification Number (BIN) or URL associated with
the Issuer.
The exact definition is specific for each paymentNetworkId.
See also Service Discovery.
serialNumber
13
tstr
Text string that (with respect to the Issuer),
uniquely identifies the payment credential.
cardImage
14
bstr
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 Authentication 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 paymentNetworkId.
For details on a preliminary enrollment system you may take a peek at
this document.
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:
Note that the normative part of this specification only covers the
steps within the dotted rectangle. That is, how FWP implements
the PaymentRequest
interface.
For brevity return (status) messages are not shown in the diagram.
1
Initiate PaymentRequest
At this point the User is assumed having clicked on
an FWP compliant icon like
causing a Merchant Web page to invoke
a custom doPaymentRequest() method, like in the following sample:
When the PaymentRequest constructor is invoked, the Browser
(FWP implementation) MUST perform the following checks:
There is an accompanying data attribute holding a
JSON-serializable JavaScript Object.
The data object contains a payeeName
attribute holding a non-empty JavaScript String argument.
The data object contains a networks
attribute holding a JavaScript Array argument.
The networks array holds a non-empty list of
JavaScript Objects.
That each object in the networks array contains a id
attribute holding a non-empty JavaScript String argument.
That none of the objects in the networks array contain other
attributes, with the exception of an optionalnetworkOptions
attribute holding an arbitrary JavaScript/JSON-compatible argument, where the
Number type
is limited to integers in the range of -2^53 to +2^53.
There is only onePaymentItem and it has a
label attribute with the argument null.
There is a non-emptyid argument included in the
details parameter to the PaymentRequest constructor.
Any deviations MUST throw an exception.
Note that the id properties in the networks
array denote the actual payment networks, corresponding to the paymentNetworkId
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:
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 Userauthorizes 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 substeps 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:
Host name as interpreted by the Browser.
Included for optional validation by the Issuer,
aided by the PSP.
accountId
3
tstr
User account number associated
with the selected FWP credential.
paymentNetworkId
4
tstr
Payment network associated with the selected FWP credential.
Included for "completeness".
serialNumber
5
tstr
Unique identifier associated with the selected FWP credential.
networkOptions
6
"Any"
Optional. This attribute MUST be included if
specified in the PaymentRequest constructor
for the particular paymentNetworkId, otherwise it MUST NOT be defined.
Note that possible networkOptions 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 int.
String is converted to tstr.
Object is converted to map.
Array is converted to array.
null, true, and false
are converted to their respective CBOR counterpart.
platformData
7
map
Up-to-date information about the core software components.
Included for security and logging purposes.
The outer CBOR map holds two sub maps with
int label 1 for the operating system,
and int label 2 for the "user-agent" (browser).
Each sub map holds two tstr arguments,
name with int label 3
and version with int label 4
respectively.
Note that hardware (device) data is assumed to be established during credential
enrollment.
location
8
array
Optional. If the platform supports GPS and the user has granted
access to location data, this attribute MUST contain a CBOR array
holding two CBOR IEEE-754
(2, 4, or 8 byte) floating point data items representing
latitude (index 0) and longitude (index 1) respectively.
timeStamp
9
tstr
ISO (RFC3399)
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.
This object is subsequently referred to as Authorization Data (AD).
4.3 Create Signed Authorization Data (SAD)
Now apply the FIDO signature key (identified by credentialId
and rpId),
associated with the selected FWP credential to sign AD using the
scheme described in
FIDO Web Pay - Crypto.
For the sample code this should result in the following object:
This operation updates the signature (-1) attribute 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 - Crypto.
Note the
COTX tag which is used to identify the FWP assertion object in its entirety.
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!
Payment network associated with the selected FWP credential.
issuerId
String
Issuer identifier associated with the selected FWP credential.
userAuthorization
String
Encrypted Signed Authorization Data (ESAD) supplied in a Base64Url string
(in subsequent examples shown as a placeholder only).
Note that whatever changes FWP may undergo, the userAuthorization field
MUST remain since the actual FWP version is only available through the COTX tag.
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:
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 paymentNetworkId.
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:
That paymentRequest is properly formatted and that
the payeeName attribute
matches the Merchant common name registered with the PSP.
That the fwpAssertion.paymentNetworkId is supported.
That the format of the fwpAssertion.issuerId matches
fwpAssertion.paymentNetworkId.
That the receiveAccount matches a Merchant account
registered with the PSP.
That the timeStamp is within "reasonable limits".
That the rest of the expected parameters are available as well that there are no unknown attributes.
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:
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 paymentNetworkId 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
Verify that IssuerRequest schema-wise is properly formatted.
Verify that the timeStamp is within "reasonable limits".
Verify that the pspRequest.fwpAssertion.paymentNetworkId is supported.
Verify that the pspRequest.receiveAccount
is compatible with the pspRequest.fwpAssertion.paymentNetworkId.
Verify that the pspRequest.fwpAssertion.issuerId
is compatible with the pspRequest.fwpAssertion.paymentNetworkId
as well as matching the Issuer.
Verify that pspRequest.paymentRequest
represents a valid PRCD object.
10.2 Extract Signed Authorization Data (SAD)
Decode the Base64Url string supplied in pspRequest.fwpAssertion.userAuthorization.
Parse the result of the previous operation as CBOR and set result as ESAD.
Verify that the COTX object Id is supported.
Verify that the resulting object is compatible with the encryption profile specified by FWP.
Verify that the public key or key Id declared in the encrypted object matches an
existing decryption (private) key of the Issuer.
Decrypt the ESAD object using the private key retrieved in the previous operation.
Parse the result of the previous operation as CBOR and set result as SAD.
Verify that the SAD object schema-wise has the proper format.
10.3 Validate Request Data
Verify that pspRequest.paymentRequest is equivalent to SAD.paymentRequest.
That is, verifying that the Merchant payment claim corresponds to what the
User have actually seen and authorized.
Verify that pspRequest.payeeHost is equivalent to SAD.payeeHost.
That is, verifying that the User was not subject to phishing.
Note that phishing attacks against FWP are not useful for stealing money,
but for redirecting purchased goods to another address.
Verify that the SAD.timeStamp is within "reasonable limits".
Tentative: CurrentTime - 600s < SAD.timeStamp < CurrentTime + 60s.
Verify that the optionalSAD.networkOptions attribute complies
with the specific requirements of the Issuer.
10.4 Validate Authorization Signature
Verify the signature of the recovered SAD object.
Since the public key is included in the signature container, signature validation
does not require database lookups.
Verify that the aforementioned public key is linked to a User
account matching the SAD.accountId and SAD.serialNumber attributes
(where the latter would typically serve as the primary key in a credential database table).
Note that this check requires that the public key is in a canonical form.
Fortunately, this is a "built-in" feature if public keys are stored in the COSE format.
Using SHA256 hashes of public keys is a common method for limiting the
the need storing and comparing large keys (like required by the RSA algorithm).
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 attributes,
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.
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:
Ease the integration of FWP in existing payment systems.
Open the possibility outsourcing the authorization process to TPPs.
Note that FWP makes the use of delegated authorization transparent
for both the User and the Merchant.
Delegated authorization differs from
3D Secure
by keeping the authorization process and associated User
account information, inside of the core payment network.
This enables validation of potentially untrustedMerchant
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:
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 Issuerindividually. 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 paymentNetworkId 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 and Privacy Considerations
Security in FWP depends to a large extent on the W3C
PaymentRequest API
which acts as a "mediator" between the untrusted Web and payment applications.
That does though not stop arbitrary Web sites from invoking FWP when the user clicks a
link on the 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 should
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.
Due to the end-to-end security model, card numbers and similar personally identifiable information
(PII) are protected from illicit access, as long as payment providers manage FWP
decryption keys in a secure manner.
It is technically possible creating Web applications that look like FWP ("spoofing"),
but such applications 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 should be rejected.
This makes clock manipulations useless as attack vectors.
FWP depends 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.
Although FWP was designed with privacy in mind, it does add some
data which (to a rather limited extent),
can be used by merchants for "binning" users:
Each authorization returns a non-personal payment network identfier.
Each authorization returns a non-personal bank identifier. This information
provides a crude estimate of where the user may live.
The availability of FWP itself represents user related data.
Integration
It goes without saying 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 an 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.
The FWP client is loosely derived from a proof-of-concept system called
Saturn.
By continuing along this path, features like the following could potentially be added:
Support for non-direct payments,
including secure (tokenized) versions of Card-on-File.
Support for real-time account balances.
Support for Userrefunding.
Support for universal digital receipts.
Support for private messaging and additional authentication information between the
Issuer and User.
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:
Point-of-sale (PoS) payments.
This would (at least initially) depend on QR-code for invocation.
Person-to-person (P2P) payments.
Such an arrangement would also introduce additional features including:
Making it easier for alternative browser vendors adopting the FWP system
since they would not have to build a copy of FWP themselves;
a thin wrapper should suffice.
Relieving users from having to enroll payment credentials
for each browser they want to use.
Limiting the number of systems to certify in the case certification
becomes a requirement.
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:
Simplified cryptographic operations, not needing specific canonicalization support or
awkward Base64Url encoding of data to be signed.
Elements always appear at the same position, making documentation
matching actual data.
Denser code.
FWP assertions are (due to the end-to-and security model), only processable by
the Issuer and possible delegated parties.
FIDO attestations require CBOR support.
To maintain simple and deterministic representation of data, this specification
only uses a subset of CBOR. Extensions to this specification SHOULD NOT
introduce additional CBOR primitives beyond floating point and big number.
Acknowledgements
The FWP core was heavily influenced by an earlier Microsoft research project
called Windows CardSpace.
represents
the current "Gold Standard" for secure and convenient payments
in the physical world.
