DCQL queries w.r.t. user consent

Aperta
  • Qualcosa non va?
#39 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Ambito
api, security

Direzione di ricerca

Inizia esaminando l’ambito citato di ISO/IEC 18013-5 e la sezione 15.1 di OID4VP, quindi ripercorri l’attuale modello di richiesta e risposta DCQL. Definisci la dichiarazione di consenso, la sua relazione con i tipi di attributi richiesti e i metodi di comunicazione, nonché gli endpoint aggiuntivi proposti. Il lavoro è completato quando la specifica include un design concordato e verificabile che copra le dichiarazioni di consenso, gli attributi autodichiarati e gli allegati.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
18
Fork
3
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openid/dchp

Tutte le issue di openid/dchp

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.