Yes, where practical. Though recognize that by their very nature web apps aren't part of the trust network. The browser and security stack can make a key for them to use, but it's not possible to be sure that the user of that key is not subject to attack at the backend (or even front end, really the best you can do there is XSS protection, which is hardly at the standard of "crytographically secure").
And likewise you as the app vendor can know the key was generated, and that it works, but you can't[1] know that it's actually locked to a device or that it's non-exportable. You could be running in a virtualized environment that logged everything.
Basically it's not really that useful. Which is sort of true for security hardware in general. It's great for the stuff the device vendors have wired up (which amounts to "secured boot", "identifying specific known devices" and "validating human user biometrics on a secured device"), but not really extensible in the way you'd want it to be.
[1] Within the bounds of this particular API, anyway. There may be some form of vendor signing you can use to e.g. verify that it was done on iOS or ChromeOS or some other fully-secured platform. I honestly don't know.
Apple is already shipping remote attestation in Safari in the form of Private Access Tokens (https://developer.apple.com/news/?id=huqjyh7k), though Cloudflare's trial for that has ended. Safari authenticates and attests itself against Apple, who hands out tokens to your browser, which in turn get used to bypass CAPTCHAs and other anti spam filters.
There's no direct remote attestation implementation for passkeys yet, but remote attestation for web browsers has been around for a few years now.
Ask anyone who has tried to run banking apps on GrapheneOS how that works out in practice.
GrapheneOS supports attestation. GrapheneOS even provides the sort of security guarantees that would make risk management types at banks happy, but it isn't popular enough for them to be motivated to support it as an attestation target.
Now imagine it was practical for websites to require attestation from browsers. How likely do you think it that all the major services would accept anything other than Chrome, Safari, and Edge?
And likewise you as the app vendor can know the key was generated, and that it works, but you can't[1] know that it's actually locked to a device or that it's non-exportable. You could be running in a virtualized environment that logged everything.
Basically it's not really that useful. Which is sort of true for security hardware in general. It's great for the stuff the device vendors have wired up (which amounts to "secured boot", "identifying specific known devices" and "validating human user biometrics on a secured device"), but not really extensible in the way you'd want it to be.
[1] Within the bounds of this particular API, anyway. There may be some form of vendor signing you can use to e.g. verify that it was done on iOS or ChromeOS or some other fully-secured platform. I honestly don't know.