The FIDO protocol was originally designed for 2-party communication: a human user authenticating to a web application operated by a company – the Relying Party (RP) – with whom users register FIDO credentials for strong authentication.

However, there are business situations where a human user must authenticate to the RP (where the FIDO credential is registered) through an intermediary, using a web application created by the intermediary. This is a 3-party communication which the current FIDO protocol did not handle.

Some example business situations where such 3-party communications are prevalent, are:

• In an e-Commerce environment, a Consumer buying a product at a Merchant’s web site, and the Bank with the Consumer credit card account needs to authenticate the Consumer before authorizing the payment;

• In an Open Finance environment, a Consumer transferring money to someone – for example, to pay a plumber for installing a new faucet - with a mobile app created by a third-party Payment Service Initiator (PSI), and the Bank with the Consumer account needs to authenticate the Consumer before authorizing/executing the transfer.

In these situations, the user is interacting with the intermediary’s – Merchant or Payment Service Initiator - application, but the FIDO credential is registered with the RP – in these examples, the Bank – that must authenticate the Consumer. The current FIDO protocol doesnot not support this feature. Note: An older FIDO protocol - Universal 2nd Factor aka U2F – did (AppID and TrustedFacets); but when U2F was merged into the current FIDO protocol – FIDO2/WebAuthn - the feature was removed!

Recognizing the need tor such a capability, the feature has been reintroduced in WebAuthn Level-3 as the Related Origin Requests (ROR). While the specification is not yet final, multiple browsers have implemented the feature, and as such web applications can leverage it if a FIDO server and its RP support it.

With version 4.14.0, SKFS introduces support for ROR, enabling an RP to authenticate their users either directly or through an intermediary’s application at defined web origin(s). Read more about ROR here.

Follow the steps here to enable ROR on SKFS. Once you have added allowed related web Origins to the database and enabled ROR, SKFS administrator must make a  "webauthn" file and store it in the location specified in the ROR specification (Please follow this link to retrieve the list of all active related web origins)

The location is a directory named “.well-known/” on a publicly accessible website on the internet with a web origin matching the RPID configured in SKFS for that FIDO Domain. Thus, if the RPID for an SKFS FIDO Domain is “myshoppe.com”, the ROR configuration file must be accessible at https://myshoppe.com/.well-known/webauthn. If the RPID of another FIDO Domain on the same SKFS instance is “mypaymentapp.net”, the ROR configuration file must be accessible at https://mypaymentapp.net/.well-known/webauthn.

Since this configuration file is generated by the RP (on their SKFS machine) and stored on a site controlled by the RP (since it corresponds to their RPID), it ensures only web applications running on known, predefined web origins are permitted to authenticate users using FIDO credentials generated for the RP’s use.

The server hosting the "webauthn" document must ensure it is served with a content type of application/json.

NOTE: Ensure all web origins listed are valid in accordance with RFC standards.