Comments on "Overview of solution options" and "Preliminary Assessment"
The overview presents 4 options and claims that three of them support the credential formats (mDoc and sd-jwt vc) requested by the ARF. I believe that's wrong. Only option C is able to support the mentioned credential formats.
Explanation:
The vc data model in chapter 3.2 defines a verifiable credentials:
A verifiable credential is a set of tamper-evident claims and metadata that cryptographically prove who issued it.
sd-jwt vc
andmDoc
fulfill this definition. The data models of both formats mandate the signing of the claims by the issuer:
draft-ietf-oauth-sd-jwt-vc-01 defines sd-jwt vc
as verifiable credential:
Verifiable Credential (VC): An Issuer-signed assertion with claims about a Subject. SD-JWT-based Verifiable Credential (SD-JWT VC): A Verifiable Credential ...
ISO_IEC18013_5 chapter 9.1.2 defines mdoc
as verifiable credential with issuer signed claims:
The purpose of issuer data authentication is to confirm that the mdoc data is issued by the issuing authority and that it has not changed since issuance.
Thus, the vc data model and in particular the data formats of mdoc
and sd-jwt vc
contradict the requirement of option B and D not to sign the claims of the credential (see explanation of secure channel options):
Since the data is not signed, its authenticity can be disputed (e.g., in case of a leak later on), which is an advantage for user privacy. This approach is used by the German eID system.
Summary: Figure 3 should be corrected to show clearly that option B and D uses proprietary credentials formats which don't match the credential formats mDoc
and sd-jwt vc
requested by the ARF. Further, the ARF is following the ecosystem and core data model described in the vc data model:
issuer
|
| Exchange of Verifiable Credentials (claims signed by issuer - assertion proof)
|
holder
|
| Exchange of Verifiable Presentations (credentials signed by holder - authentication proof)
|
verifier
Only option C is following this core model. Option B and D which are based on Presentation through Secure Channel similiar to the German eID system will lead to an proprietary eID system which is not aligned with the European eID system. This issue cannot be fixed by just introducing additional algorithms for key agreeement as suggest in "Preliminary Assessment and Comparison of PID Design Options".