Issuance of QEAA

  • Technical

Summary

Adjust acc. ETSI TS 119 471 and 472-1

QEAA issuance

The current QEAA Issuance contains in the described flow (Step 27) a seemingly mandatory device binding. A QEAA can be issued in any system. eIDAS Section 9 does not limit it to EUDIW. Also the device binding is not mandatory (see ETSI TS 119 471 and 472-1). as QEAA can be issued by any QTSP also in German EUDIW the requirement in German Architecture shall follow the ETSI standards:

Also Step 14 of pre-authorization flow seems not correct "The Wallet sends a Token Request to the PID Provider; containing..." - acc. to Art. 24 eiDAS the PID is not mandatory for identification for QEAA. Please adjust the issuance of QEAA to the regulation as well as ETSI TS 119 461 (identification) ETSI TS 119 471 and 472 (issuance, authentication etc.)

The flows only contain SD-JWT and mDoc, acc. to Implementing Act on Art. 5a the formats to be accepted by Relying party are: W3CVCDM and mDoc. As the ETSI TS 119 472-1 defines the formats to be recognized by QTSP on issuance of QEAA also this standard shall be recognized and contains: mDoc, SD-JWT VC, W3CVCDM & x509.

Please adjust the QEAA issuance accordingly and include also W3CVCDM and x509.

please make clear:

  • Flow is only example
  • Device binding not mandatory
  • EUDIW only example

Please add:

  • identification for QEAA acc. Art. 24 eIDAS and ETSI TS 119 461
  • authentication acc. ETSI TS 119 471 and 472-1
  • QES/Qseal on QEAA acc. Annex V incl. the used format for each QEAA format
  • formats acc. Implementing Act and ETSI standards
  • clarify which kind of signature from QTSP you expect for which format or reference ETSI only

Alternatively: Define that QEAA issuance follow the ETSI standards mentioned above

Edited by Steffen Schwalm
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information