Clarification: Browsers or other user-agents are not required to trust QWACs for use in TLS. We fought very hard for this.

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).

▲

roddylindsay 3 hours ago | parent [-]

2-QWACs are awesome! Thank you for your contributions!

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.

▲

galadran 2 hours ago | parent [-]

Ah, the sins are more to do with the design of 2-QWACs.

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!

▲

roddylindsay 2 hours ago | parent [-]

Very interesting history, thank you for sharing. I had wondered about the design choices there.

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.

▲

ameliaquining 2 hours ago | parent [-]

Why do agents need any of this cryptographic infrastructure? Can't they just check on the certifying authority's website whether an entity is legitimate?

▲

roddylindsay 2 hours ago | parent [-]

It's not so simple:

- 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)

▲

ameliaquining 2 hours ago | parent [-]

Can you give a concrete example of the kind of claim you think QWACs would be useful for verifying, that can't be addressed just as well with existing protocols?

	▲	roddylindsay an hour ago \| parent \| next [-]
		Sure: - 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
	▲	xorcist 36 minutes ago \| parent \| prev [-]
		Easier than ever. Should I really log in with my Microsoft credentials to auth.gfx.ms?