The scope of 18013-5 states:
The following items are out of scope for this document:
— how mDL holder consent to share data is obtained;
In OID4VP, the User Consent is briefly mentioned in section 15.1:
15.1. User Consent
Wallets SHOULD obtain explicit, informed consent from the End-User before releasing any Verifiable Credential
or Presentation to a Verifier, or returning an error.
However, none of these two documents mentions how user consents are transmitted to the verifier.
At the moment, the response to a DCQL query is a data structure that includes one or more digital presentation proofs.
This point of view is narrow as it focuses only on digital presentation proofs.
From a broader perspective, a verifier can request to obtain attributes related to an individual that can be communicated by their mdoc app
using different ways:
(1) self-declared attributes (e.g., manually entered by the individual), and/or
(2) attributes contained in an attachment (e.g. a pdf document or an image), and/or
(3) attributes contained in a Visible Digital Seal (VDS) — which is it is a cryptographically signed data structure encoded
in a two-dimensional barcode, usually a QR code — used by legal entities to certify and authenticate electronic documents, and/or
(4) attributes contained in one or more digital presentation proofs (i.e., the current case).
The fact that an individual has given his consent for the disclosure of a given set of attribute and the means he has used to communicate them
must be returned to the verifier in a separate data structure, so that the verifier can record the fact that the individual has indeed given their consent.
Many jurisdictions require a service provider (i.e. a verifier) to demonstrate that it has indeed obtained the consent of the individual to collect
and process a given set of attribute types for specific purposes.
This data structure can be called a 'consent declaration'. It should contain attribute types but not attribute values.
One goal is to allows auditors to audit these consent declarations once they have been transformed by the verifier into 'consent records'.
Auditors will then be in a position to verify that the requested attribute types are proportionate to the action the individual was willing to perform
and to verify that the third and fourth privacy principles of the ISO/IEC 29100 standard—namely "collection limitation" and "data minimization"—
are effectively addressed by the verifiers.
The implications are as follows:
- the DCQL request should be extended to allow requesting self-declared attributes. (e.g., manually entered by the individual),
and/or attributes present in attachments (e.g. a pdf document or an image) that can contain Visible Digital Seals (VDSs),
- the response to a DCQL query should be extended to allow to carry 'consent declarations', self-declared attributes
and attachments containing attributes or Visible Digital Seals (VDSs).
Additional Endpoints should be defined to return to a verifier:
- 'consent declarations',
- self-declared attributes (e.g., manually entered by the individual), if appropriate,
- attachments containing attributes (e.g. in a pdf document or an image), if appropriate.
By default a 'consent declaration' shall be returned.
The scope of 18013-5 states:
In OID4VP, the User Consent is briefly mentioned in section 15.1:
However, none of these two documents mentions how user consents are transmitted to the verifier.
At the moment, the response to a DCQL query is a data structure that includes one or more digital presentation proofs.
This point of view is narrow as it focuses only on digital presentation proofs.
From a broader perspective, a verifier can request to obtain attributes related to an individual that can be communicated by their mdoc app
using different ways:
(1) self-declared attributes (e.g., manually entered by the individual), and/or
(2) attributes contained in an attachment (e.g. a pdf document or an image), and/or
(3) attributes contained in a Visible Digital Seal (VDS) — which is it is a cryptographically signed data structure encoded
in a two-dimensional barcode, usually a QR code — used by legal entities to certify and authenticate electronic documents, and/or
(4) attributes contained in one or more digital presentation proofs (i.e., the current case).
The fact that an individual has given his consent for the disclosure of a given set of attribute and the means he has used to communicate them
must be returned to the verifier in a separate data structure, so that the verifier can record the fact that the individual has indeed given their consent.
Many jurisdictions require a service provider (i.e. a verifier) to demonstrate that it has indeed obtained the consent of the individual to collect
and process a given set of attribute types for specific purposes.
This data structure can be called a 'consent declaration'. It should contain attribute types but not attribute values.
One goal is to allows auditors to audit these consent declarations once they have been transformed by the verifier into 'consent records'.
Auditors will then be in a position to verify that the requested attribute types are proportionate to the action the individual was willing to perform
and to verify that the third and fourth privacy principles of the ISO/IEC 29100 standard—namely "collection limitation" and "data minimization"—
are effectively addressed by the verifiers.
The implications are as follows:
and/or attributes present in attachments (e.g. a pdf document or an image) that can contain Visible Digital Seals (VDSs),
and attachments containing attributes or Visible Digital Seals (VDSs).
Additional Endpoints should be defined to return to a verifier:
By default a 'consent declaration' shall be returned.