However, there are obligations to display 2-QWACs if sites choose to use them. Their keys are not used to authenticate web domains or encrypt web traffic.
Disclosure: I was Mozilla's lead for this effort and also helped design 2-QWACs (for my sins).
Though I don't understand why they would atone for any sins. IMHO, you created the website identity infrastructure for the agentic web...
And yes, I hope I didn't imply that QWACs are trusted by default for TLS. 1-QWACs would have to come from an existing trusted CA to be recognized by the browser.
All the design needed was for the browser to check the TLS cert and the QWAC cert covered the same domain name. Instead, folks at ETSI insisted very stubbornly on the signature from the QWAC over the cert used in TLS - which is an annoying complication for site operators - and provides little additional benefit.
I'd also like to see the EU encode more information in these certs. Knowing a company's address is not very useful (IMO), but a machine readable label that the site is regulated by $COUNTRY_NAME financial or medical regulator would be a much more useful signal.
Good luck in your endeavours!
Agree that the next step for 2-QWACs is additional corporate data (professional licensure like you mentioned, incorporation date) and eventually arbitrary claims vetted by a QTSP.
For an average human user, these additional claims are nearly useless since they're so buried in the browser UI...and even if they were more prominent, they wouldn't be of much benefit, as the EV history has shown.
But for an agent that knows to look out for these signals, extensible 2-QWACs will be extremely valuable.
- If by certifying authority you mean a CA/Trust Service Provider, they don't generally publish client information in a central location.
- If you mean the actual jurisdictional authority, there are thousands and public records are all over the place.
- Websites aren't generally part of corporate filing records. So the agent would still need a way to connect the website to the corporation even after checking the legitimacy of the corporation.
- Serving the structured info in an HTTP header that is cryptographically verifiable by the browser itself (via its trusted roots) essentially serves as a distributed database for website identity, which eliminates the need for each agent to come up with its own ad-hoc verification system on the fly (and all the additional fetches that come along with it)
- which business is behind the website?
- when was said business incorporated?
- how many employees does this business have?
- what is the jurisdiction and canonical registration identifier of this business?
All useful info for an agent determining how much to trust the content on a website and whether to transact with it