Multiple Relying Party in a single FIDO2 Server

335 views
Skip to first unread message

Job Travaini

unread,
Sep 17, 2024, 8:34:59 PMSep 17
to FIDO Dev (fido-dev)
Hello, folks. I have a question regarding a FIDO2 Server handling registration of credentials for multiple RPs.

The user case is the following:
  • There are four vendors: alpha, beta, delta, gamma;
  • Each vendor will have their own FIDO2 Server;
  • Registration is distributed:
    • Alpha vendor can register credentials for beta, delta, gamma;
    • Beta vendor can register credentials for alpha, delta, gamma;
    • Same pattern for delta and gamma;
  • Registration ceremony:
    • When Alpha is registering a credential in Beta server: Beta server needs to return the Relying Party configuration for Alpha domain (RpID, Origins);
      • To perform this operation, FIDO Server needs to have an capability to select which Relying Party is operating based on Alpha request;
    • The same logic applies for each combination;
  • This is a pattern to integrate these vendors and allow vendor Alpha to execute operations on vendor Beta without redirection;
Is it correct to the FIDO2 proposition to implement such a protocol when a company holds a FIDO2 Server that may represent several other companies (instead of subdomains)?

A company's registered credentials are distributed in several FIDO2 servers which they have no control over, and they are bound to trust the authentication from remote servers to perform their operations. This seems to be against what is proposed by FIDO and WebAuthn.


Confidentiality note: This e-mail may contain confidential information from Nu Holdings Ltd and/or its affiliates. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone; for details about what personal information we collect and why, please refer to our privacy policy.

Shane Weeden

unread,
Sep 17, 2024, 9:25:46 PMSep 17
to Job Travaini, FIDO Dev (fido-dev)
From what you’ve described it certainly seems like an RP cartel / anti-privacy pattern if there is not strong and governed trust amongst the vendors.

Perhaps a better approach if that trust really exists is “Related Origins” (https://github.com/w3c/webauthn/wiki/Explainer:-Related-origin-requests)


--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/4cad31a9-c747-413a-82df-3154bb767fe9n%40fidoalliance.org.

Arshad Noor

unread,
Sep 17, 2024, 9:40:30 PMSep 17
to Job Travaini, FIDO Dev (fido-dev)

It all depends on the implementation of the FIDO server, and the implementation of the application using the FIDO server.

While I am confident others will elucidate on how their FIDO servers will handle this, here is how StrongKey's FIDO Certified server - StrongKey FIDO Server (SKFS) - handles this:

  1. SKFS is implemented with "cryptographic domains" so that there is a logical separation of each domain and all the FIDO credentials/transactions SKFS handles for that domain. (NOTE: The logical separation is at a Master Key level within FIPS certified cryptographic hardware that protects the integrity of all objects within the domain - this is NOT a FIDO/WebAuthn requirement, but a protection we've implemented to protect legitimate users from being compromised - there is a presentation from the Authenticate 2023 conference I gave last year that describes the attack and the mitigation) ;
  2. SKFS also has a Policy Module that allows the "operator" of SKFS to configure the FIDO policy for each domain; while there are many items that can be specified in the policy (see documentation for details), one of the important ones is the rpid. As a consequence, with a single SKFS cluster (for HA/DR and scale), SKFS can host hundreds of domains and have a distinct rpid in each of them. All registrations/authentications/transaction confirmations that are sent to a specific domain must comply with the FIDO Policy defined within that domain;
  3. Now comes the application implementation part. If you use a standard web-browser - or the Webview  component - on mobile devices, the WebAuthn API is implemented by the manufacturer of that browser/component. This will enforce the FIDO policy configured in the FIDO server, so it will not work in a multi-party transaction as you described - at least not without redirection. (There are some rumblings about WebAuthn Level-3 that hint at new capabilities, but that is not a standard yet to the best of my knowledge - its a work-in-progress);
  4. To support the 'journey without redirection', the RP handling the transaction in the app must use a native library - in StrongKey's case, the StrongKey Android Client Library (SACL) - to call their back-end application indicating the desired rpid in the challenge from SKFS. The back-end application must then authenticate/authorize the caller for that specific rpid with whatever means they choose. If the back-end application determines that the caller is authentic and authorized, it will proxy the request to the right SKFS domain - wherever it may be and whoever may be hosting it - and request the challenge (this assumes the RP handling the transaction has some 'relationship' with the RP operating SKFS, so they know how to find them on the internet). When SKFS is satisfied with the authentication/authorization of the request, it will generate the challenge with the configured FIDO Policy parameters - which includes the appropriate rpid - and returns it to back-end application, which in turn, returns it to the mobile app for processing;
  5. Since the SACL is a native library that does not use the a browser or the Webview component, it handles all cryptographic processing itself and delivers credentials using the TEE or SE with an AndroidKeystore attestation; users of the library will have adapted the resources within their app to configure all the right values for such a multi-party scheme;
  6. The SACL and SKFS can be used collectively to support Transaction Confirmation, and deliver digital signatures around business transactions, displayed within a Secure Display, using the TEE/SE-bound FIDO credential with biometrics/PIN/Pattern to comply with regulations like EU's PSD2. This capability was demonstrated in a Virtual Authenticate presentation ("Towards Frictionless Strong Customer Authentication") some years ago;
  7. SKFS, SACL and sample applications are all available on SourceForge - but without the FIPS-certified cryptographic hardware in StrongKey's appliances - the SourceForge distribution uses a software keystore (BCFKS, protected by a password) for the integrity protection of credentials.

The Authenticate presentations I referenced can all be found here: https://authenticatecon.com/speaker/arshad-noor/

Hope that helps.

Arshad Noor
StrongKey

rjhal...@gmail.com

unread,
Sep 18, 2024, 7:20:53 AMSep 18
to Job Travaini, FIDO Dev (fido-dev)

I may be wrong on this but I believe Open Finance Brazil refers to the exchange of customer data, with customer permission of course, and not inclusive of customer authentication credentials which of course should remain confidential.

 

As for RpID, there’s the requirement that it be associated with service (RP) URL during FIDO2 registration.

 

Regards,

--

Job Travaini

unread,
Sep 18, 2024, 9:31:14 AMSep 18
to FIDO Dev (fido-dev), rjhal...@gmail.com, Job Travaini
Hello, everyone! Thanks for engaging in the discussion.

In terms of implementation, I agree it is something achievable, since software is flexible and it is possible for a WebAuthn RP Server to select between RPs. My main concern is conceptually.

I understand some companies such as Meta may need multiple RPs, for instance one RP for Instagram, another one for WhatsApp and yet another one for Facebook. In the case I am bringing, Open Finance Brazil, multiple RPs for a single Bank may make sense, but not how it is described. Let me delve into it:

Let us assume the following scenario based on OpF Journey Without Redirect: Bank Alpha, Bank Beta and Bank Delta

Here is the ceremony:
  • Bank Alpha wants to perform an operation on Bank Beta resources in name of customer John Doe, therefore it asks Bank Alpha (who is also a Bank Beta) to register a passkey (on Bank Alpha's behalf) on Bank Beta's  FIDO2 Server.
    • This is already something that concerns my understanding, because Bank Alpha is registering a credential on a server they have no governance over, which means they are outsourcing authentication and authorization to a blackbox outside their domain;
  • Bank Alpha now authorizes the operation using Bank Beta's FIDO2 Server
    • This is also a concern to me, because it is trusting a remote origin on their credential;
On another operation, maintaining the above state - i.e. the operations above were sucessful:
  • Now customer John Doe wants to perform an operation in Bank Alpha using the passkey it just generated. It is impossible, because the credential generated is stored in another location - since it does not reside in the "legitimate" RP Server of Bank Alpha.
    • The Bank Alpha credentials are becoming decentralized in several servers, probably creating constraints of governance, deletion, authenticity and others.
Does it make sense of an analysis? Are there flows and diagrams to reduce those risks?

Arshad Noor

unread,
Sep 18, 2024, 10:02:26 AMSep 18
to Job Travaini, FIDO Dev (fido-dev)

The use-case is not uncommon. This is the mandate of Strong Customer Authentication (SCA) in the EU PSD2 regulation.

  1. Consumer interacts with a merchant, and wants to buy something that costs more than 30 Euro, and pay with a credit/debit card;
  2. Consumer's Bank wants to verify that the transaction is authentic - that the Consumer was strongly authenticated, and explicitly agreed to the transaction details in a manner that ensures the Consumer is not compromised;
  3. Merchant must now deliver a unique authentication code to the Bank with the transaction details - in the use-case with FIDO, it would be a FIDO digital signature over the transaction details;
  4. Bank must verify all this before choosing to accept/deny the transaction.

Here is how the FIDO Alliance claimed it meets the Regulatory Technical Standards (RTS) for SCA: https://fidoalliance.org/how_fido_meets_the_rts_requirements. There are pictures and regulatory statements on how the law must be complied with. The JWR journey is no different, IMO.

While the W3C is trying to leverage FIDO/WebAuthn to support SCA using a different API - Secure Payment Confirmation (SPC) - that API is not a standard yet. Last I looked at it 3-4 years ago, it would not meet stipulations in the RTS. Perhaps the SPC Working Group has updated their specification -  I cannot tell since I have not read the spec recently.

In order to meet Brazil's Open Finance regulation and stipulations for JWR, it cannot be done with a browser using the WebAuthn Level-2 API - Level-3 is a different matter, as I've already stated earlier. However, even though some browsers may have implemented some Level-3 features, I'm not sure you can comply with Brazilian law to use a FIDO Certified implementation if the Level-3 API itself is not a standard yet.

This brings you  back to using what is defined in WebAuthn Level-1 and/or Level-2 (for which FIDO Certification existed/exists). The flow I mentioned earlier is the only technical way I can think of, where one can implement JWR using existing standards and its implementations.

Arshad

Is it correct to the FIDO2 proposition to implement such a protocol when a company holds a FIDO2 Server that may represent several other companies (instead of subdomains)?

 

A company's registered credentials are distributed in several FIDO2 servers which they have no control over, and they are bound to trust the authentication from remote servers to perform their operations. This seems to be against what is proposed by FIDO and WebAuthn.

 


Confidentiality note: This e-mail may contain confidential information from Nu Holdings Ltd and/or its affiliates. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone; for details about what personal information we collect and why, please refer to our privacy policy.

--

You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/4cad31a9-c747-413a-82df-3154bb767fe9n%40fidoalliance.org.



Confidentiality note: This e-mail may contain confidential information from Nu Holdings Ltd and/or its affiliates. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone; for details about what personal information we collect and why, please refer to our privacy policy.
--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.

pa...@fidoalliance.org

unread,
Sep 18, 2024, 10:52:57 PMSep 18
to Arshad Noor, Job Travaini, FIDO Dev (fido-dev)

I confirm that a FIDO Certified implementation meets the requirements of Brazil’s Open Finance.

 

More information is coming, and I’ll be sure to share it here when it becomes available.  

 

Thank you,

Paul

 

Paul Heim | Certification Director | FIDO Alliance

T: +1 623-200-3994

pa...@fidoalliance.org | www.fidoalliance.org

 

signature_4152129623

 

Join us Oct. 14-16 in Carlsbad, CA or virtually! Learn more at authenticatecon.com

image001.png

rjhal...@gmail.com

unread,
Sep 19, 2024, 5:27:52 AMSep 19
to Job Travaini, FIDO Dev (fido-dev)

Hello,

 

This seems to be a complex approach to solving what is otherwise a simple problem. Actually two problems that I separate for simplification purposes.

 

The architecture you propose raises security concerns whilst at the same time potentially sacrificing the mutual authentication feature of FIDO2 which to many is one of FIDO2’s strengths.

 

There may be a more straightforward approach to accomplish the same goals as I now understand them.

For the authentication part of the problem:

  1. Employ an Identity Provider Service separate and apart of Alpha, Beta, and Gamma but federated in a way that each can access and use the service.
  2. The IdP provides federated customer authentication services each Bank can use as then need.
  3. For security purposes, the IdP may need access to customer information from each bank such as you have described. This would be a design detail.
  4. Another design detail would be a customer naming convention, I prefer use of customer email address for its singularity and verifiability aspect.
  5. In operation:
    1. Registration and FIDO2 authentication ceremony occurs between John Doe and the IdP retaining all of the WebAuthn security features.
    2. The banks would then hit an IdP API to request authentication of John Doe.

This then leaves the second problem of sharing customer information between Alpha, Beta, and Gamma separate and apart from the complexities of identity verification and authentication.

Arshad Noor

unread,
Sep 20, 2024, 5:32:30 AMSep 20
to rjhal...@gmail.com, FIDO Dev (fido-dev)
Rick,

Theoretically, while it seems centralizing identity management and FIDO
authentication with a 3rd party IdP would be simpler, there are multiple
problems with that architecture:

1) A founding principle of FIDO Alliance was to be a privacy-protecting
protocol, so that only the consumer and their RP would know about the
existence and use of the consumer's FIDO credential. Introducing an IdP
in the middle breaks that privacy promise. I highlighted that in the
2023 Authenticate presentation.

2) In an age of GDPR, LGPD, CCPA and similar data privacy laws all over
the world, who is responsible for a consumer's privacy being breached
when the IdP is compromised? The bank that delegated their
responsibility to the IdP, or the IdP that failed to protect the
consumer? Or, are both absolving themselves and offloading the risk onto
the consumer? Someone has to pay for this liability and it should not
have to be the consumer;

3) This leads to the third problem; here is what I found related to IdP
data breaches on the internet:

- https://duckduckgo.com/?q=okta+breach
- https://duckduckgo.com/?q=duo+breach
- https://duckduckgo.com/?q=onelogin+breach
- https://duckduckgo.com/?q=lastpass+breach
- ....

I could go on, but you get the picture.

FIDO was designed to be a strict 2-party authentication protocol; but
the world has changed with respect to security and privacy: PSD2 and
Open Banking are new business initiatives that are changing our notions
of security & privacy. As a result, implementations have to innovate and
adapt; if that introduces complexity, that is the price we pay for
preserving consumer security and privacy.

Arshad

P.S. Could you clarify how FIDO offers mutual authentication between the
client and the RP? That is a feature of TLS with Client Authentication;
FIDO only offers client authentication, and thus, must trust the RP
using the TLS certificate on their website.


On 9/19/24 2:27 AM, rjhal...@gmail.com wrote:
> Hello,
>
> This seems to be a complex approach to solving what is otherwise a
> simple problem. Actually two problems that I separate for simplification
> purposes.
>
> The architecture you propose raises security concerns whilst at the same
> time potentially sacrificing the mutual authentication feature of FIDO2
> which to many is one of FIDO2’s strengths.
>
> There may be a more straightforward approach to accomplish the same
> goals as I now understand them.
>
> For the authentication part of the problem:
>
> 1. Employ an Identity Provider Service separate and apart of Alpha,
> Beta, and Gamma but federated in a way that each can access and use
> the service.
> 2. The IdP provides federated customer authentication services each
> Bank can use as then need.
> 3. For security purposes, the IdP may need access to customer
> information from each bank such as you have described. This would be
> a design detail.
> 4. Another design detail would be a customer naming convention, I
> prefer use of customer email address for its singularity and
> verifiability aspect.
> 5. In operation:
> 1. Registration and FIDO2 authentication ceremony occurs between
> John Doe and the IdP retaining all of the WebAuthn security
> features.
> 2. The banks would then hit an IdP API to request authentication of
> John Doe.
>
> This then leaves the second problem of sharing customer information
> between Alpha, Beta, and Gamma separate and apart from the complexities
> of identity verification and authentication.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org
> <mailto:fido-dev+u...@fidoalliance.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/017601db0a76%2428c8d270%247a5a7750%24%40gmail.com <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/017601db0a76%2428c8d270%247a5a7750%24%40gmail.com?utm_medium=email&utm_source=footer>.

rjhal...@gmail.com

unread,
Sep 23, 2024, 7:23:46 PMSep 23
to Arshad Noor, FIDO Dev (fido-dev)
Arshad,

FIDO2 requires both the user's device and the service to verify each other's identity before completing the authentication ceremony. That process begins with FIDO2 verifying the service’s RpID (authenticator verifies service) and concludes with the service provider using their public key to verify the challenge signature (service verifies authenticator) signed by the authenticator using the corresponding private key. This is the very definition of mutual authentication. It also explains the advice we provide to our tenants to keep your RpID a secret. If in the wrong hands the only thing separating your FIDO2 protected accounts from a breach is a phishing attack.

The statistics cited can be seen as a basis to abandon the IdP or, an opportunity to learn from the experience of others and do better. You know my choice.

Indeed, cybersecurity is more costly, challenging and complex as well and getting more so every day. To wit, the addition of Zero Trust Architecture et.al. to the service providers TODO list substantially impacts all.

As for PII, we are strong advocates of protecting privacy information and do so on par with protecting remote access accounts and FIDO certificates.

We have a FIDO2 app and IdP that shows a commitment to protecting privacy rights (GDPR, CCPR, HIPAA, et.al.) whilst achieving trustworthy authentication with ZTA compliance (NIST 800-207, 800-63 4.2, et.al.). Doing that while using FIDO2 is certainly challenging and complex. Indeed, we found it necessary to tightly couple the FIDO2 authenticator app with the IdP over secure point-to-point encrypted out-of-band channels, breaking with the norm, yes, but seeing no other way to achieve ZTA compliance. And to clarify that point, consider how you might otherwise go about implementing authenticator based continuous identity monitoring using siloed authenticators. This monitoring is based on device location, proximity, and behaviors on a continuous and reporting service information to the service provider of event management.

Rick,

P.S. To clarify, several methods used in our approach are covered by US patents dating to 2015 on a project that began the prior year.

-----Original Message-----
From: Arshad Noor <arsha...@strongkey.com>
Sent: Friday, September 20, 2024 5:32 AM
To: rjhal...@gmail.com; 'FIDO Dev (fido-dev)' <fido...@fidoalliance.org>
Subject: Re: [FIDO-DEV] Multiple Relying Party in a single FIDO2 Server

Arshad Noor

unread,
Sep 23, 2024, 8:15:54 PMSep 23
to rjhal...@gmail.com, FIDO Dev (fido-dev)
I cannot speak for any of the proprietary things you've done with your
app and back-end solution, Rick.

Since your solution neither uses the browser (which normally handles
passing the ClientDataJSON object with what it "knows" about the origin
where it got the FIDO challenge from, to pass onto the Authenticator for
verification), nor is it open-source (to see what your app-code does),
it is hard for a third-party to verify that this is FIDO.

So I will drop this discussion. Thanks.

Arshad

rjhal...@gmail.com

unread,
Sep 26, 2024, 8:14:30 PMSep 26
to Arshad Noor, FIDO Dev (fido-dev)
Understood

But you raise a couple of additional questions I'll address for the benefit of others who may be following

As for the app, its been available from Apple and Google since 2019'ish with FIDO2 over BLE. We pulled it recently in preparation for replacement, a complete refactor using Maui and .Net8.

The iteration includes along with the out-of-band FIDO2 channel the original FIDO2 over BLE. A second salient feature of FIDO2 in addition to mutual authentication is verification of proximity to the device running the FIDO client. In some service provider circles this is a very critical need.

As for open-source, we are considering doing so with that portion of the app of our creation. Business and legal considerations.

As for the FIDO2 implementation, we scraped our efforts when we came across Solo-Key SDK. It’s a very good solution and as I understand it is also Level 1 certified.

The RpID that got this thread started plus URL are included in the Json payload.

Rick
Message has been deleted

Paul Heim

unread,
Sep 27, 2024, 3:35:07 PMSep 27
to FIDO Dev (fido-dev), rjhal...@gmail.com, Arshad Noor

All,

I would like to provide additional context for my initial September 26, 2024, post.  Please see the additional context and the original post as follows:

Re: Clarification to “Multiple Relying Party in a single FIDO2 Server”

I would like to clarify that anyone choosing to use a FIDO Certified/FOSS product from its original manufacturer uses a certified solution for their deployment.  This is outlined in certification policies and TMLA documentation at https://fidoalliance.org/.  StrongKey FIDO Server (SKFS) is an example of this scenario, receiving FIDO Certification in 2019. 

Refer to the FIDO Certified Database for such details: https://fidoalliance.org/certification/fido-certified-products/

FIDO Certification Policies and TMLA should be reviewed completely to understand the nuances of the ongoing maintenance of certifications, delta/derivative/recertification, and other requirements for all FIDO Certified Products. FIDO Certification can be contacted at certif...@fidoalliance.org for more information.

>> Original Post to “Multiple Relying Party in a single FIDO2 Server”

On 9/26/24 6:16 PM, pa...@fidoalliance.org wrote:

FIDO Certified does not apply to open-source solutions.

Please feel free to directly contact me if you have any questions or would like to discuss this in detail.

Thank you,

Paul

 

Paul Heim | Certification Director | FIDO Alliance

T: +1 623-200-3994

pa...@fidoalliance.org  |www.fidoalliance.org


Reply all
Reply to author
Forward
0 new messages