[DISCUSS] Do any wallets need TLS context from the browser (or app platform)?

[timcappalli]

This isn't really in scope for the web platform API itself, it is more for the OS platform plumbing, but wanted to have the discussion.

Will (some) identity wallets need context from the TLS session in the browser (or even the app platform in the case of a native app verifier), such as certificate attributes or awareness that a verifier (or issuer) presented with a Qualified Website Authentication Certification (QWAC)?

[OR13]

https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/

There is a bunch of other relevant work at IETF, including attested CSRs.

[timcappalli]

https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/

There is a bunch of other relevant work at IETF, including attested CSRs.

Thanks for the link. Whether the information needs to be attested or not is a secondary topic, I think.

[RByers]

Discussion in 11/15 meeting was that we're not aware of any such reason. If wallets want strong RP verification then perhaps they will require a signature of some form in the request protocol. At the moment Chrome/Android intend to pass just the origin since that's what's displayed to the users in the browser, and passing what the user has seen is essential to mitigating MITM attacks.

[Sebastian-Elfors-IDnow]

The final draft eIDAS2 has been published here. Article 6b.1 describes how relying parties shall be registered in order to be trusted by EUDI Wallets. However, there are no explicit requirements that eIDAS2 relying parties must use QWACs for TLS authentication to the EUDI Wallets.

The QWACs are regulated in eIDAS2 article 45, where it is stated: “Qualified certificates for website authentication issued in accordance with paragraph 1 shall be recognised by web-browsers.” So QWACs are addressing TLS server authentication of websites, and web-browsers must validate QWACs.

Technically speaking, however, an EUDI Wallet may rely upon the system browser’s TLS authentication when connecting to a relying party website, so there may be a technical implicit use of QWACs for the EUDI Wallet, although not legally defined in eIDAS2.

It should also be noted that the latest proposal on QWAC is the so called 2-QWAC solution: The TLS certificate should still be issued and trusted according to the existing WebTrust certification scheme, in order for Mozilla Firefox, Google Chrome, Microsoft Edge, et al, to be able to trust the root certificate. The QWAC will then be issued as an attribute X.509 certificate, which the web-browser can download and validate in a second step once the TLS session has completed. The TLS certificate and QWAC must have the same domain name and other attributes that link them together. The details of the 2-QWAC approach are still being hammered out between ETSI ESI and the CA/Browser-Forum.

[timcappalli]

Discussed on 2023-11-15 call. Notes: https://github.com/WICG/identity-credential/wiki/2023-11-15-Meeting-Notes#do-any-wallets-need-tls-context-from-the-browser-or-app-platform

Outcome: not a web platform API issue, but a consideration for the ecosystem. Platforms may find @Sebastian-Elfors-IDnow's comment above useful.