webauthn
webauthn copied to clipboard
w3c
Cross-origin credential creation in iframes
In level two we supported cross-origin assertions (when allowed by the top-level) but omitted cross-origin creation because there wasn't anyone with a use-case.
We would like to revisit that and allow cross-origin creation along the same lines as assertion. We believe this will be useful in a payments context.
When making a payment there are three (or four) parties involved. The customer seeks to authorise the payment. They are on the merchant's site. A bank needs to approve the payment, and there might be a payment processor between the merchant and the bank. If the bank can make a cross-origin assertion on the merchant page then that can greatly improve their confidence that the transaction is genuine. However, that assumes that the bank has a credential for the user, and that would be aided by being able to enroll users inline. Thus the desire for cross-origin creation.
Hi Adam (@agl ),
I concur with the use-case: that it is essential for Banks to receive digital signatures from Consumers directly when they're confirming a payment transaction at a Merchant site. But I humbly disagree with the premise that the optimal way to register Consumers is with cross-origin credential creation. I think Banks and browser companies are making a mistake and forcing the FIDO protocol/implementations to become a lot more complex than it need become - at least for this use-case.
Every Bank, IMO, is going to have to contend with FIDO sooner or later whether they like it or not. Windows 11 and Apple Passkey will ensure that. If they have to implement FIDO for their own users to interact with them directly, why would they not simply require that the Consumer register with them first and associate all their registered Public Keys for whatever payment instruments they have acquired from the Bank?
By doing so, here are all the benefits that accrue to the ecosystem:
-
Consumers only have to register with the Bank once (for each unique Authenticator they choose to register);
-
Consumers do not have to be distracted with additional friction during the Checkout process (to register an Authenticator);
-
Consumers do not have to be worried that they are being attacked by someone while shopping at a site ("What are these additional things the Merchant wants me to do?", "How do I know I can trust what I'm seeing here?", "Perhaps the Merchant has been compromised?");
-
Merchants do NOT have to create complex Checkout workflows for registration of Authenticators. When the Consumer chooses a specific payment instrument during Checkout, and the Merchant sends that information to the Bank, the Bank recognizes the instrument, finds the associated Public Key(s) and a unique challenge comes back as a response for the Consumer to sign;
-
Banks do not have to worry about whether the Consumer may register their new payment instrument with them - they can mandate it as a prerequisite to using the instrument (they already require all kinds of user actions to enable the use of a payment card before first use currently);
-
Banks can transition to digital payment instruments - instead of sending out cards - and register those instruments faster and more securely with FIDO, rather than:
- Wait for the Consumer to receive the card;
- Choose to go shopping on the internet;
- Choose to use a Merchant that might have implemented FIDO; and finally
- Choose to register at the Bank during Checkout.
-
There are too many conditional probabilities that are likely to result in very low registrations with the Bank. When registered directly with the Bank, they will have 100% compliance and the potential to offer Merchants faster Checkouts (and more conversions) because of FIDO enabled payment instruments;
-
Banks will reduce risk and costs while providing Consumers a better experience in interacting with the Bank when they use FIDO for all interactions with the Bank - not just for Merchant transactions (at sites that might have FIDO enabled).
By not thinking of the bigger picture, Banks and browser manufacturers might unnecessarily complicate the protocol and the process. IMO, it will be more productive for Banks to register Consumers directly - and more securely - while eliminating the need for one more change to the protocol to carry new baggage.
I agreed with @arshadnoor here. There is a great risk that over-complication and feature extension to this standard will open us to security issues and undermine the trust that exists in webauthn. Webauthn is intended to be a simple 1:1 authentication mechanism. However it appears banks want to use this as a multi-party distributed trust and cryptographic standard.
As a result, I think it would be better if a parallel standard for banks with multi-party processing and proper documentation of intended workflows is created which can then call into fido tokens instead. This keeps both webauthn and bank operations seperate, and reduces risk of security issues and complexity from becoming part of webauthn.
@arshadnoor Your proposed workflow doesn't work (in a meaningful way...) because the creation of a credential at the bank presumes (if we stick to payments) that you get something back comparable to a virtual payment card. This is not what Google & Co plan to ship later this year: consumers still have to manually type in card data and hand it over to merchants which in turn through certified and pretty complex software and services can deduct the origin of (in order to carry out an authentication through the actual issuer).
Fortunately Chrome and other browsers support "deep-links", permitting banks to deploy native applications that make on-line payments comparable to current PoS payments. These solutions also work (using the same virtual payment cards) for PoS payments making this one-time registration + download of app much more acceptable. In fact, the very same app is typically also used for login as well. But it doesn't stop there. In some more developed parts of the world, banks want to use their already existing account-to-account payment networks such as SEPA. This is incompatible with Google's take on the matter since there are no physical cards to read account data from. The mentioned native apps therefore build on a "wallet" concept, like Apple: https://vipps.io/about-us/news/mobilepay-pivo-and-vipps-join-forces-to-create-one-strong-mobile-wallet/
@agl
Can an RP say that it does not want any other website to be able to invoke create command for them? Or only a allowlist of RPID that it control? And by default there should be no-one else who should be able to create a credential for another RP.
Also this enforcement must be at the creation level before invoking the create() API. Potentially in addition, server must also be able to verify at it's level while evaluating credential creation response.
This has security implications, and then the question becomes is why user cannot go to the bank and create the credential there. Is the issue is that merchant does not know what kind of bank credentials user has?
This has security implications, and then the question becomes is why user cannot go to the bank and create the credential there.
@akshayku The assumption is that requiring users to go to the bank to get their payment credentials would hamper adoption.
If they have to implement FIDO for their own users to interact with them directly, why would they not simply require that the Consumer register with them first
We are thinking in terms of the world outlined in #1637: consider a person who has their banking app on their phone and thus has a WebAuthn credential on their phone. When performing a transaction on their desktop the bank can request an assertion and, with the existing support for cross-origin assertions and phone support coming to browsers soon, will be able to confirm on their phone. But the bank can't offer to register the local computer for future transactions because there's no cross-origin registration. Using the platform authenticator on the desktop is preferable to having to pull out a phone each time, but the guideance would have to be something like "Go to bank.com and figure out how to add an authenticator in settings".
Can an RP say that it does not want any other website to be able to invoke create command for them?
It's not another website invoking it for them, it's the site itself invoking it in an iframe. If the site has lost origin integrity (e.g. due to an XSS) then, ignoring the probably worse things that result, the create() call could be made, but the clientDataJSON would indicate that it was done in a cross-origin context. The backend could then reject it.
(But note that, if the site can be XSSed then an attacker can trigger a top-level navigation and likely to the same thing today, and in a same-origin context.)
Going back to @agl's issue.
Is this: a) proposing that a site can create an iframe with the feature-policy publickey-credentials-create to allow the origin of the iframe to make a credential? If so I support that. There are situations like 3dSecure where the ACS is not the bank itself and needs to register a separate credential. There are lots of other places where a SAAS IDP embeds an iframe on a enterprise login page to do authentication. The problem as I think Duo pointed out is that offering to register a platform authenticator for next time won't currently work without doing a full page redirect that may take the user out of the flow they are expecting.
b) per Dirk's proposal on payments. Allow a site in a full page redirect to create a non-discoverable credential for a third site. I see a lot of uses for that and would like to explore if there are any security/privacy issues with doing that.
Is this proposing that a site can create an iframe with the feature-policy publickey-credentials-create to allow the origin of the iframe to make a credential?
Yes, this one.
@agl The de-facto standard for mobile to desktop interaction is QR code. Using the aforementioned (in Europe and China already deployed) native mobile apps, you open the application, point to the QR, receive the request on the mobile, and then authorize. You never have to type in card numbers etc. This system typically also works without modifications at the PoS terminal.
Regarding 3DS, due to the PSD2 regulation EU banks have been forced implementing support for SCA (Strong Customer Authentication). That is, you are already enrolled when you get your mobile application. There is no PSD2 in the US but given the fact that it took the US 10 extra years to get chip-card support compared to the EU, we are on very slow train. @wseltzer
QR is primitive? Sure, but NFC which once was a part of the PC specification (and sometimes even shipping) was effectively "ostracized" due to a lack of foresight by the W3C: https://github.com/w3c/web-nfc/issues/140
We are thinking in terms of the world outlined in #1637: consider a person who has their banking app on their phone and thus has a WebAuthn credential on their phone. When performing a transaction on their desktop the bank can request an assertion and, with the existing support for cross-origin assertions and phone support coming to browsers soon, will be able to confirm on their phone. But the bank can't offer to register the local computer for future transactions because there's no cross-origin registration. Using the platform authenticator on the desktop is preferable to having to pull out a phone each time, but the guideance would have to be something like "Go to bank.com and figure out how to add an authenticator in settings".
There are 3 problems with this use-case that do not make it compelling enough to complicate FIDO, Adam:
- If someone already has a FIDO credential on their phone registered to their bank, 99.99% of people will initiate and complete whatever transaction they want to do, on their phone;
- Given Microsofts and Apple's direction wrt FIDO, and given Google's support for FIDO since Android 8, in less than 2 years, I anticipate the vast majority - if not all - of consumer devices will be FIDO ready/enabled;
- The last bridge that makes FIDO universal is the problem this cross-credential creation issue is trying to solve: enabling someone who has FIDO on one device to register another platform device with the same RP. IMHO, based on what I've seen in SE Asia, I agree with @cyberphone, QR codes are the simplest, easiest way to solve this problem:
- Consumer registers "genesis" FIDO credential on phone with Bank;
- Consumer requests Bank app for a QR code to register another platform - say a desktop PC;
- Bank app generates and displays encrypted, digitally signed QR code on phone, with whatever the Bank needs to assure itself of the authenticity, confidentiality and integrity of information in QR code;
- Consumer uses desktop browser to go to Bank website;
- Consumer clicks on a button on the Bank's home-page that says "Register your device with QR code";
- Camera on desktop is activated by browser and prompts for QR code;
- Consumer displays QR code on phone to desktop;
- Desktop reads, decrypts and verifies QR code;
- Browser prompts Consumer for "gesture" to register desktop with Consumer's account.
To unnecessarily complicate the FIDO ecosystem for something as simple as this with iframes, caBLE, syncing, etc. seems like taking a sledge-hammer to swat a fly. If the QR code scheme I've outlined is too complicated for banks to handle, perhaps they can start giving out FIDO Security Keys to customers (reprising the "toasters" of a bygone era) to those who are QR code-challenged.
@agl @arshadnoor Widely deployed mobile payment systems pretty much all use the phone as a virtual payment terminal (regardless of scenario), rather than as an authenticator. AFAICT, caBLE doesn't address the virtual payment terminal concept.
A further complication with respect to FIDO/WebAuthn is that current "mobile first" consumer banking solutions predominantly use OOB methods like QR code or push notifications for dealing with desktop Web authentication.
QR codes are the simplest, easiest way to solve this problem
From the perspective of the Web Authentication group, a solution that assumes that RPs have to have a native app shouldn't be satisfying. And, if we're building an authentication scheme, having a big chunk where RPs are expected to build their own solution feels like a gap.
Consumer displays QR code on phone to desktop
Desktops with cameras are far from ubiquitous. Rather I expect the QR would be shown on the desktop and scanned with a phone. But WebAuthn can do better than QR scanning with a native app. WebAuthn to a phone requires proximity (usually via BLE) and so sites that try proxying a QR image won't work.
To unnecessarily complicate the FIDO ecosystem
Above, John asked whether this issue was just about allowing create() in iframes. It is, but the question suggests that it wasn't sufficiently clear. While the implications of enabling creation in iframes should be considered, the actual change is tiny. WebAuthn already supports assertions from iframes so this is just changing the ancestor requirement on create().
From the perspective of the Web Authentication group, a solution that assumes that RPs have to have a native app shouldn't be satisfying. And, if we're building an authentication scheme, having a big chunk where RPs are expected to build their own solution feels like a gap.
Seems to me that that boat has sailed - Google Play shows 250 mobile banking apps for the US, 100 for India, 50 for Singapore alone, 100 for South Africa, ... Apple claims a total of 2M apps in their app store with Statista claiming nearly 3M for Google Play. I cannot even count 20 passwordless FIDO sites all over the world.
Desktops with cameras are far from ubiquitous. Rather I expect the QR would be shown on the desktop and scanned with a phone. But WebAuthn can do better than QR scanning with a native app. WebAuthn to a phone requires proximity (usually via BLE) and so sites that try proxying a QR image won't work.
The post-pandemic world has changed that, IMO. The scheme I've outlined works between any 2 devices - not just mobile to desktop. I've made the assumption that RPs will build in additional security controls rather than accept just any QR code shown to them (even if encrypted and signed).
the actual change is tiny. WebAuthn already supports assertions from iframes so this is just changing the ancestor requirement on create()
I agree the change is tiny for the browser manufacturer - but I fear the Consumer will end up bearing the consequences of a third-party creating a credential using a protocol that was only intended for a two-party interaction. I would not be surprised if new forms of tracking individual users surfaced, with iframes requesting assertions from such credentials all over the internet - with facial recognition UVMs, the Consumer doesn't even have to do anything to accept the challenge - they're already looking at the device!
Once you open that doorway, it doesn't imply that only legitimate sites and ethical people end up using it.
@agl I don't have a strong opinion about the technical part of this issue, I rather looked on the motives. This observation by @arshadnoor
Seems to me that that boat has sailed - Google Play shows 250 mobile banking apps for the US, 100 for India, 50 for Singapore alone, 100 for South Africa, ... Apple claims a total of 2M apps in their app store with Statista claiming nearly 3M for Google Play. I cannot even count 20 passwordless FIDO sites all over the world.
indicates that getting under the skin of consumer (aka retail) banking will be anything but simple and fast. Personally I think it could be worthwhile to do something which this lot CANNOT DO as a complement to waiting for the deprecation of already sunken (and ongoing) investments supporting pretty well functioning software and services.
Leaving the discussion here. GitHub have an option called discussions that would be more appropriate.
Just to reiterate on the initial ask, Stripe is a PSP that participates in Web Payment WG and we found that enrolling credentials from a cross origin iframe is useful for payments use case.
There are different situations where a payment is performed in a cross domain iframe most commonly while requiring 3DS authentication. The 3DS authentication is traditionally performed using SMS OTP, previous transactions recognition or a password. From an issuer perspective, the card is initially enrolled to be authenticated no matter the user device. Allowing WebAuthn credential enrollment in a cross domain iframe allows issuers to enroll cardholder credentials right after a successful traditional 3DS authentication without relying in popups or redirecting the user to the bank website.
b) per Dirk's proposal on payments. Allow a site in a full page redirect to create a non-discoverable credential for a third site. I see a lot of uses for that and would like to explore if there are any security/privacy issues with doing that.
@ve7jtb Hi John, has there been any update on Dirk's proposal lately? May be an issue here that I missed so far? Thank you.
Allow a site in a full page redirect to create a non-discoverable credential for a third site.
That's not what is being proposed here, is it? Only RP should be able to create a credential for itself. The proposal is for the RP to be in an iframe instead of top-level context. Sorry if I'm not understanding the "third site" comment.
While I do not deny that everybody benefits from Transaction Confirmation, there are many non-technical issues that need to be considered (some of which I highlighted earlier in this thread). But, here is another one.
Have Banks, PSPs and browser manufacturers given any consideration to how they will comply with GDPR and CCPA regulations wrt providing notice of consent to collecting personally identifiable information (PII) when registering FIDO credentials? While I am not a lawyer, I would consider a credentialId PII since it does uniquely identify a specific individual to an RP. Among other information, CCPA considers a Consumer's "..unique personal identifier, online identifier, internet protocol address, email address, account name, .." PII.
GDPR's Article 7 and CCPA's Section 999.305 have explicit statements on how a Consumer must be notified of the collection of PII and how consent must be received by the party collecting that data. In a cross-origin iframe (as shown in sample screenshots for SPC), the prompts would definitely not comply with the law in my non-legal opinion - the Consumer doesn't even know they're dealing with a third-party RP in the iframe! While the card may be initially enrolled to be authenticated, generating new credentials with a credentialId that uniquely identifies the Consumer is a different transaction/matter.
A second consideration: in the event the Consumer's privacy is breached - not the Private Key, of course, but just the uniquely identifying credentialId - who is responsible for this breach?
- The Bank that registered the Consumer's credential in the iframe?
- The Merchant/PSP that enabled the iframe to collect the PII? or
- The browser manufacturer that facilitated the Merchant/PSP and the Bank to collect the PII?
@arshadnoor From the current spec: The credential ID could be used as a tracking vector, but to obtain it from the Relying Party the merchant already needs an as-strong identifier to give to the Relying Party (e.g., the credit card number).
That is, 3DS-inspired systems like SPC depend on the user handing over a GUID linked to the user to every third-party (e.g. merchant), he/she interacts with.
Absent from the spec: To secure this process, associated third-party software must be certified and third-parties must be fitted with TLS client certificates in order to access the complex and sensitive support systems required by card not present (CNP) schemes. This obviously doesn't scale well so SPC-based payment processes would in most cases likely be outsourced to payment providers like Stripe or to e-commerce hosts like Shopify.
I am familiar with that statement in the spec, Anders (@cyberphone); but, in that transaction the Merchant is attempting to get an assertion from the Consumer. What we're discussing here is the creation of a credential. Without GDPR/CCPA like notices and consents at the time PII is created/collected, the transaction could be deemed in violation of the laws.
Additionally, the following sub-article of GDPR Article 7 indicates Merchants/PSPs cannot coerce Consumers into registering FIDO credentials - but Banks could if they changed their terms and required FIDO registration before the payment instrument was used.
4. When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract.
Copied over from #1336. Thanks to @emlun for the link to this issue.
I'm a bit saddened by this decision to not allow credential enrolment from the context of an iframe. I'm the CTO of a new payments company (https://stitch.money), which is aiming to improve the payments experience of account to account transfers in our markets.
As @btidor-stripe and @jcemer-stripe mentioned, 3d Secure is a good example of where allowing iframe credential enrolment would be hugely advantageous for the security of the payments ecosystem, but it goes beyond just 3d Secure.
For many of our clients, Stitch offering a more integrated experience, rather than forcing users to do a redirect is an important product feature. Our clients are generally already trusted e-commerce brands/fintech services, and they wish to leverage their brand equity as much as possible in the payment process.
In order to prevent our customers from having to shoulder a large part of the PCI, compliance, and general infosec burden, we deliver the embedded version of our interface via an iframe so that our customers do not have the ability to handle the credentials themselves. I'd venture to say that this is quite a common approach in the industry at large.
For our product, we perform tokenisation of user credentials to streamline subsequent checkouts, and currently have to store this single use token in localStorage. This isn't the best as this value could conceivably be exfiltrated from local storage and used on another device. It'd be greatly preferable if we could use Web Authn as an alternative to these tokens.
I'm a little unclear as to why the enrolment is considered a significant privacy threat in the model (privacy seemed like the original motivation for restricting this functionality), does both retrieval and enrolment not require user interaction? If that is indeed the case, surely this would not be a particularly attractive fingerprinting method? Or is it because some of the associated parts of the API increase the available entropy that could be used in general fingerprinting methods?
With regards to GDRP, the approach I described above actually is to my understanding friendlier to GDPR and GDPR equivalent data protection regimes, as it means our clients don't need to store a token/identifier on their side to allow repeated payments.
We of course design our flow and mandate that our customers do the same to make sure that the appropriate disclosures and consents are made.
Out of necessity, we need to store certain pieces of PII as is to provide our services, and this would not change regardless of whether we enrolled credentials or not.
The issue to the best of my knowledge, Natalie (@ncthbrt), is that the schemes devised in the past to authenticate Consumers to Issuers, excluded the use of public-key cryptography (PKC) as an authentication mechanism. While PKC schemes can be designed to be used in embedded mode (as S/MIME does), the FIDO/WebAuthn protocol was not designed with this requirement.
FIDO was designed to be a 2-party protocol - like TLS ClientAuth - but with additional features and constraints. Trying to shoehorn that protocol into a multi-party transaction with a third-party controlling the flow was not a design-requirement. When you add in the fact that the world has changed wrt privacy (with GDPR/CCPA simply representing the vanguard of privacy regulations), you have additional non-technical constraints placed on the protocol.
IMO, these constraints can be addressed by simply having Consumers register their payment instrument directly with the Issuer before they use it anywhere. Not only does it eliminate the multi-party FIDO registration conundrum, but the registration flow can be designed to comply with privacy regulations adequately (once the Issuer's lawyers are involved in the process).
Once registered, as long as the Issuer has received consent from the Consumer for that credential to be used (for generating digital signatures) through the Issuers' affiliates, getting an assertion through an iframe is not as problematic - as long as we have ethical Issuers and Merchants/PSPs.
getting an assertion through an iframe is not as problematic - as long as we have ethical Issuers and Merchants/PSPs.
@arshadnoor - Out of curiosity, what kind of attacks on FIDO/WebAuth become available with unethical issuers, merchants, and PSPs or in 3rd party contexts?
I don't think any multi-party transaction has been proposed here. The proposal is not to allow site A (merchant) to register credentials on behalf of site B (payment provider), rather that site A may embed site B in an iframe, in which site B may register credentials for site B. Communication between the user and site B will be direct and not pass through site A on the way (i.e., public keys and identifiers will not be exposed to site A), and site B is in full control of the registration ceremony just like it would be with a full page redirect.
(I don't have a strong opinion either in favor or against, just trying to clear up what looks to me like a misconception.)
I suppose the way I see it is we do consider our use case one which would fit a two party protocol. End users essentially have the option to register with us (acting as a payment processor) the first time they make a payment on a given device. That this just happens to be in the context of an iframe seems pretty tangential. To make this more concrete, we'd like to be able to offer the following:
-
Allow the user to sign in to one or more institutions from their device. This typically entails entering credentials and completing some sort of out of band MFA. Note: Storing these credentials is NOT what we we want to use the WebAuthn API for.
-
Give the user the option to enroll their device with Stitch (or Stripe, Braintree, Fast etc), as part of the embedded payment flow. Note: This is the part that we'd like to use it Web Authn for, and in this case the two parties are the user, and Stitch.
-
Subsequent payments could then follow a more streamlined flow with lower risk if enrolled as we have already verified the device with that set of credentials once. This streamlining is discretionary, based on risk models on the PSP's side.
The actual underlying payment mechanisms are IMO a separate concern to authenticating the device.
The "issuers" that you mentioned are ones that would unlikely see widespread adoption of Web Authn, or even protocols like FAPI/OpenID Connect/OAuth 2.0 in the markets we operate in (Africa) in the next decade. It is simply not a priority for the banks, while it is the payment processors who really have the incentives to drive innovation and security/privacy practises in the market.
In essence we want to improve the security and experience of the real world ecosystem we operate in by adding extra controls, above and beyond what the banks already provide.
.. what kind of attacks on FIDO/WebAuth become available with unethical issuers, merchants, and PSPs or in 3rd party contexts?
Given that passwordless authentication using FIDO is not widely implemented yet (if at all), its a little too soon to know what's possible, Rouslan (@rsolomakhin). For now, I envision mostly privacy related attacks on Consumers, where an unethical Issuer allows their RPID to be used (through a DNS sub-domain) by trackers, to violate Consumer privacy at sites that may have nothing to do with payments. We really need passwordless FIDO to be deployed at scale before we can learn where gaps exist; with the exception of https://digitalbank-test.com and https://demo.strongkey.com, I haven't seen much of passwordless FIDO anywhere.
.. and site B is in full control of the registration ceremony just like it would be with a full page redirect.
Unfortunately, its not a full page redirect, Emil (@emlun) - its an iframe that doesn't provide very much information to Consumers on which RP they're dealing with and what happens with whatever data Consumers provide in that iframe. We accepted this over the years for card payments, but with we're in a post-GDPR/CCPA era now where legal mandates have to be addressed by technical implementations.
(Thank you for trying to clear it up - I wasn't under a misconception; perhaps I used the term "multi-party" a little loosely where I was implying that the Consumer thinks they're dealing with site A, but in reality, they are dealing two sites, A and B, with site B operating in the iframe - for the vast majority of the internet - in the guise of site A).
Please forgive my lack of intimate knowledge about the payments ecosystem, Natalie (@ncthbrt). There are many terms in your use-case that are not clear to me.
Allow the user to sign in to one or more institutions
Are you referring to the Merchant, PSP or the Issuer, here?
from their device.
Are you referring to their mobile device, desktop/laptop or Security Key (aka FIDO Authenticator) here?
This typically entails entering credentials
Which credentials are you referring to here? For passwordless FIDO/WebAuthn authentication, there is nothing for the Consumer to type in.
Note: Storing these credentials is NOT what we we want to use the WebAuthn API for.
The RP that registers a FIDO/WebAuthn credential is required to store some credential-related information - these are not secrets, but some information has to be stored to verify assertions - otherwise, there is no point in using FIDO.
The remaining statements in your flow will become clearer once the meaning of the terms above are clarified.
@arshadnoor
Which credentials are you referring to here? For passwordless FIDO/WebAuthn authentication, there is nothing for the Consumer to type in.
For 3DS you type in the card number since this is how you find out the issuer URL. AFAICT, the card number is the only information shared between the merchant and bank during credential creation using this proposal. In reality, due to the cumbersome backend support required, the entire payment operation must in most cases be outsourced.