Multiple Relying Party in a single FIDO2 Server
Job Travaini
- 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;
- When Alpha is registering a credential in Beta server: Beta server needs to return the Relying Party configuration for Alpha domain (RpID, Origins);
- This is a pattern to integrate these vendors and allow vendor Alpha to execute operations on vendor Beta without redirection;
- If you are familiar with portuguese, this specification is based on Open Finance Brasil
Shane Weeden
--
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
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:
- 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) ;
- 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;
- 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);
- 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;
- 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;
- 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;
- 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
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
- 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;
- 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.
Arshad Noor
The use-case is not uncommon. This is the mandate of Strong Customer Authentication (SCA) in the EU PSD2 regulation.
- Consumer interacts with a merchant, and wants to buy something that costs more than 30 Euro, and pay with a credit/debit card;
- 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;
- 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;
- 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
- -- with portuguese, this specification is based on Open Finance Brasil
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.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/698abbe6-d12d-4bfc-bd3b-74f0227d5030n%40fidoalliance.org.
pa...@fidoalliance.org
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
pa...@fidoalliance.org | www.fidoalliance.org
Join us Oct. 14-16 in Carlsbad, CA or virtually! Learn more at authenticatecon.com
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d9ca3004-2b33-4bbd-b9cf-1527c25fdf8e%40strongkey.com.
rjhal...@gmail.com
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:
- 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.
- The IdP provides federated customer authentication services each Bank can use as then need.
- 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.
- Another design detail would be a customer naming convention, I prefer use of customer email address for its singularity and verifiability aspect.
- In operation:
- Registration and FIDO2 authentication ceremony occurs between John Doe and the IdP retaining all of the WebAuthn security features.
- 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
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:
>
> the service.
> a design detail.
> verifiability aspect.
> 1. Registration and FIDO2 authentication ceremony occurs between
> features.
>
> 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
rjhal...@gmail.com
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
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
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
Paul Heim
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
pa...@fidoalliance.org |www.fidoalliance.org
>> send an email to fido-dev+unsubscribe@fidoalliance.org
>> <mailto:fido-dev+unsubscribe@fidoalliance.org>.