Comments (5)
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.
from digital-credentials.
https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/
There is a bunch of other relevant work at IETF, including attested CSRs.
from digital-credentials.
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.
from digital-credentials.
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.
from digital-credentials.
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.
from digital-credentials.
Related Issues (20)
- What should be the data type for the response? HOT 3
- Are iframes supported by the Digital Credential API? HOT 2
- Should requests be assumed to be linkable by the browser? HOT 7
- Access to an Open Global Web Reduced HOT 1
- [spec] add statement about responses with PII MUST be encrypted HOT 2
- [spec] Add JSON (de)serialization methods
- Digital credential API should support requests for directed identifiers HOT 8
- Digital credential API should support identity verification HOT 4
- Define error handling HOT 2
- Define WebDriver integration HOT 2
- Consider requiring mitigation of script injection attacks. HOT 3
- Consider requiring a strong signal of user intent. HOT 5
- Explainer: Expand alternatives considered section
- define a well-known way for a verifier to indicate registration, validation, trustmark assurances or other necessary info HOT 3
- Add placeholder security and privacy considerations section
- Issuer identity in selective disclosure cases HOT 8
- Disallow multiple types via navigator.credentials's methods HOT 9
- Credential request options mediation requirement HOT 3
- Presentation request format validation
- Rename "providers" to "presentationRequests" or just "requests"? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from digital-credentials.