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.

When ROR is enabled (through properties shown below), a configuration file named “webauthn” is generated by SKFS and stored in the SKFS configuration directory (/usr/local/strongauth/skfs/etc) for StrongKey Tellaro appliances and (/usr/local/strongkey/skfs/etc/) for software installations). Note that the properties MUST be enabled on ALL nodes of an SKFS cluster for ROR to work on the cluster.

This webauthn file contains necessary information to allow web applications hosted on named web origins, to use FIDO credentials registered with the RP, on all the named web origins.

The SKFS administrator must take a copy of the "webauthn" file (from any of the configured SKFS instances’ configuration directories) and store it in the location specified in the ROR specification. This 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.

To enable ROR, follow the steps here (Note: Once WebAuthn Level-3 is a formal standard, and if ROR remains a part of the Level-3 standard, SKFS will incorporate ROR configuration properties into its FIDO Policy module in a future release. Since it is NOT a current WebAuthn standard, it is implemented as an SKFS configuration property in this release).

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