Divulgation sélective

Vue d'ensemble

Les attestations PublicSchema sont conçues pour être utilisées avec SD-JWT VC, un format d'attestations vérifiables à divulgation sélective, permettant aux détenteurs de ne révéler que les affirmations nécessaires à une interaction spécifique.

Approche de classification des données

PublicSchema n'attribue pas de classification de données fixe aux propriétés individuelles. Le fait qu'une propriété constitue une donnée personnelle dépend du contexte de l'enregistrement dans lequel elle apparaît, pas de la propriété elle-même. Par exemple, date_of_birth dans un enregistrement de Personne est une donnée personnelle ; le même champ dans un tableau statistique agrégé ne l'est pas.

En revanche, le comportement de divulgation est défini au niveau de l'attestation. Chaque type d'attestation ci-dessous spécifie quelles affirmations sont toujours divulguées et lesquelles sont sélectivement divulgables.

Pour les annotations de sensibilité au niveau des propriétés, consultez Conception du schéma : Annotations de sensibilité.

Valeurs de vocabulaire dans les attestations

Les valeurs de vocabulaire n'ont pas toutes leur place dans les attestations.

Des faits stables, pas des états transitoires. Une attestation vérifiable devrait attester des faits qui gardent leur sens dans la durée ("cette personne est éligible"), pas des états de processus qui changent en quelques heures ("cette demande est en cours d'examen").

Pas de valeurs en brouillon dans les attestations de production. La signification d'une valeur provisoire peut évoluer. Les émetteurs ne devraient utiliser que des valeurs ayant atteint la maturité usage expérimental ou normatif.

Le type d'identifiant seul est insuffisant. identifier_type: national_id_number est sans signification sans la juridiction émettrice et le schéma d'identifiant. Les vocabulaires utilisés dans les attestations doivent documenter quel contexte supplémentaire est nécessaire.

Structure des attestations pour SD-JWT VC

IdentityCredential

Toujours divulgué :

• type (Person)

Sélectivement divulgable :

• given_name, family_name, name
• date_of_birth
• gender, sex
• nationality, marital_status, education_level
• phone_number
• identifiers (chaque identifiant peut être divulgué indépendamment)

Cas d'utilisation : Vérification d'âge sans révéler l'identité complète. Un vérificateur doit confirmer que le détenteur a plus de 18 ans. Le détenteur divulgue uniquement date_of_birth, gardant given_name, phone_number et autres informations personnellement identifiables cachées.

EnrollmentCredential

Toujours divulgué :

• type (Person + Enrollment)
• enrollment_status
• is_enrolled
• enrollment_date, start_date

Sélectivement divulgable :

• program_ref
• Affirmations d'identité de la Personne (given_name, family_name, date_of_birth)
• Référence beneficiary

Cas d'utilisation : Preuve d'inscription active pour l'accès aux services. Un vérificateur dans une clinique de santé doit confirmer que le détenteur est inscrit à un programme. Le détenteur divulgue enrollment_status (active) et is_enrolled (true), gardant l'identité du programme et les informations personnelles cachées.

PaymentCredential

Toujours divulgué :

• type (Person + PaymentEvent)
• payment_status
• payment_date

Sélectivement divulgable :

• entitlement_ref
• enrollment_ref
• payment_amount, payment_currency
• delivery_channel
• identifiers (y compris toute entrée transaction_reference)
• failure_reason
• Affirmations d'identité de la Personne

Cas d'utilisation : Preuve de réception de paiement. Un auditeur doit vérifier que les paiements ont été effectués. Le détenteur divulgue payment_amount, payment_date et l'entrée transaction_reference de identifiers, mais pas son identité personnelle. Pour les paiements échoués, failure_reason peut être divulgué pour soutenir la résolution des litiges.

VoucherCredential

Toujours divulgué :

• type (Voucher)
• voucher_status
• serial_number
• expiry_date

Sélectivement divulgable :

• entitlement_ref
• issued_to
• redeemable_by
• amount, currency
• voucher_format
• items (chaque article de livraison peut être divulgué indépendamment)
• issue_date
• redemption_date, redeemed_by, redemption_agent

Cas d'utilisation : Remboursement de coupon chez un vendeur. Le détenteur présente l'attestation de coupon. Le vendeur doit confirmer que le coupon est valide (statut), l'identifier (numéro de série) et vérifier qu'il n'a pas expiré (date d'expiration). Le détenteur peut divulguer sélectivement la valeur nominale ou le panier de produits (items) tout en gardant son identité cachée. Les champs post-remboursement (redemption_date, redeemed_by) permettent l'audit sans nouvelle présentation des affirmations d'identité.

EntitlementCredential

Toujours divulgué :

• type (Entitlement)
• entitlement_status
• coverage_period_start, coverage_period_end

Sélectivement divulgable :

• enrollment_ref
• schedule_ref
• benefit_modality
• benefit_description
• amount, currency
• document_expiry_date
• Affirmations d'identité de la Personne (via la chaîne d'inscription)

Cas d'utilisation : Preuve du droit à une prestation. Un bénéficiaire doit démontrer qu'il a droit à une prestation pour une période spécifique (par exemple, pour accéder à un service complémentaire). Le détenteur divulgue entitlement_status (approved) et la période de couverture, gardant les détails du programme et l'identité cachés. Note : les droits émis à chaque cycle de paiement ont une durée de vie limitée, ce qui implique un renouvellement fréquent des attestations ; document_expiry_date contrôle la validité de la VC indépendamment de la période de couverture.

Structure de la charge utile SD-JWT VC

Une SD-JWT VC sépare les affirmations toujours divulguées des affirmations sélectivement divulgables en utilisant le mécanisme _sd. Voici comment un EnrollmentCredential est structuré :

{
  "iss": "did:web:registry.example.gov.sn",
  "sub": "did:web:registry.example.gov.sn:persons:4421",
  "iat": 1706745600,
  "nbf": 1706745600,
  "exp": 1738435200,
  "vct": "https://publicschema.org/schemas/credentials/EnrollmentCredential",
  "_sd_alg": "sha-256",
  "cnf": {
    "jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." }
  },

  "credentialSubject": {
    "type": "Person",
    "_sd": [
      "...hash(given_name)...",
      "...hash(family_name)...",
      "...hash(date_of_birth)...",
      "...hash(gender)..."
    ],
    "enrollment": {
      "type": "Enrollment",
      "enrollment_status": "active",
      "is_enrolled": true,
      "enrollment_date": "2025-01-15",
      "start_date": "2025-02-01",
      "_sd": [
        "...hash(program_ref)...",
        "...hash(beneficiary)..."
      ]
    }
  }
}

Note : les schémas d'attestation PublicSchema utilisent exclusivement le format SD-JWT VC. Les charges utiles SD-JWT VC utilisent vct (type d'attestation) au lieu du @context et des tableaux type du W3C VCDM. L'affirmation cnf lie l'attestation à la clé du détenteur pour la preuve de liaison de clé. Les schémas JSON générés dans dist/schemas/credentials/ valident les charges utiles SD-JWT VC, pas les enveloppes W3C VCDM.

Le tableau _sd contient des hachages des affirmations divulgables. Les valeurs réelles sont fournies séparément sous forme de divulgations que le détenteur peut choisir d'inclure ou d'omettre lors de la présentation de l'attestation.

Guide de traitement traditionnel des données

Les exigences de traitement des données dépendent du contexte de l'attestation ou du jeu de données, pas des définitions individuelles de propriétés. Les équipes de mise en oeuvre doivent évaluer chaque déploiement et appliquer des protections selon que les données, dans ce contexte, identifient ou concernent une personne physique.

Guide général :

• Les métadonnées structurelles (paramètres de programme, statuts, dates) ne nécessitent généralement aucun traitement spécial au-delà de la protection normale des données.
• Les données liées à une personne (affirmations d'identité, enregistrements spécifiques à une personne) nécessitent des protections standard : contrôle d'accès, chiffrement au repos, périodes de rétention définies.
• Les données sensibles (propriétés qui révèlent des circonstances comme l'état de santé, la pauvreté ou le statut de victime dans la plupart des contextes) nécessitent une justification pour être collectées ou divulguées. Consultez l'annotation sensitivity dans Conception du schéma.
• Les données restreintes (scores d'évaluation, indices de vulnérabilité) nécessitent des protections renforcées : journalisation des accès, limitation des finalités, analyse d'impact sur la protection des données.

Attestation de reçu de consentement (Consent Receipt VC)

Un ConsentRecord avec consent_record_type = receipt est un candidat naturel pour une attestation vérifiable (Verifiable Credential), en particulier pour les programmes qui s'orientent vers une gouvernance des données basée sur les portefeuilles numériques. Ce modèle est aligné sur la décision 24 de l'ADR-009 et est conçu pour de futurs déploiements avec portefeuilles numériques ; il ne constitue pas une attente immédiate.

L'attestation de reçu de consentement (Consent Receipt VC) permet à un concerné de porter la preuve de ce qui a été convenu, de l'avis qui a été présenté et de l'identité des responsables du traitement, sans dépendre de la disponibilité en ligne du registre du programme. Ce modèle est cohérent avec l'intention de la spécification Kantara Consent Receipt v1.1 et la sémantique de reçu de la norme ISO/IEC TS 27560:2023. Il utilise le format SD-JWT VC défini ailleurs dans ce document.

Affirmations à divulgation obligatoire (ne peuvent pas être masquées par le détenteur) :

• data_subject (l'identité du concerné, sous forme d'identifiant ; les affirmations d'identité complètes figurent dans l'IdentityCredential)
• controllers (les organisations responsables du traitement)
• purposes (les URI de finalités DPV qui ont fait l'objet de l'accord)
• legal_basis (le code de base légale, par ex. consent, public_interest)
• signed_date (la date à laquelle le concerné a indiqué son accord)
• status (l'état actuel du consentement, par ex. given, withdrawn)

Affirmations sélectivement divulgables :

• evidence_ref (le détenteur peut ne pas vouloir exposer l'emplacement des pièces justificatives)
• witnessed_by (les identités des témoins ; le détenteur peut choisir de ne pas les divulguer)
• Les valeurs individuelles de personal_data_categories (chaque URI DPV peut être divulgué indépendamment ; le détenteur peut divulguer les catégories de données de santé à un prestataire de santé sans exposer les catégories de données financières)
• recipients (les identités des organisations destinataires spécifiques ; une divulgation par destinataire est possible)
• expiry_date et effective_date (les dates de validité peuvent être divulguées indépendamment)
• notice_ref et notice_version (référence à l'avis ; un détenteur peut divulguer ces informations à un vérificateur qui doit consulter l'avis complet)
• special_category_basis (uniquement pertinent lorsque des données de catégorie spéciale sont impliquées)
• jurisdiction

Note d'implémentation. Dans la version 1, la plupart des programmes émettront des attestations de reçu de consentement sous forme de dossiers dans leur registre, pas comme des attestations détenues dans un portefeuille. La structure des affirmations ci-dessus est conçue de sorte que, lorsque l'infrastructure de portefeuille sera disponible, la même sérialisation de ConsentRecord s'applique directement à la charge utile de l'attestation sans restructuration. La valeur vct pour un ConsentReceiptCredential sera https://publicschema.org/schemas/credentials/ConsentReceiptCredential une fois ce type d'attestation formellement publié.

Guide d'implémentation

1. Les émetteurs doivent consulter les définitions de types d'attestation ci-dessus au moment de produire des SD-JWT VC. Les affirmations listées comme "toujours divulguées" figurent en clair dans la charge utile ; les affirmations "sélectivement divulgables" vont dans _sd. Pour les propriétés non couvertes par un type d'attestation défini, l'émetteur détermine le comportement de divulgation en fonction du contexte de l'attestation.

2. Les détenteurs (applications de portefeuille) doivent proposer une interface permettant à l'utilisateur de choisir quelles affirmations divulguer, en distinguant les affirmations toujours visibles des affirmations optionnelles. Les affirmations intrinsèquement sensibles (scores d'évaluation, indices de vulnérabilité) doivent nécessiter une confirmation explicite. En cas de doute, privilégiez la divulgation sélective par précaution, conformément au principe de minimisation des données.

3. Les vérificateurs ne doivent demander que les affirmations dont ils ont besoin. Une demande d'affirmations intrinsèquement sensibles doit inclure une justification (par exemple, une référence à l'autorité d'audit).

4. Le pipeline de construction produit les métadonnées de propriétés dans vocabulary.json. Les implémentations de portefeuille et de vérificateur doivent utiliser les définitions de types d'attestation dans ce document pour configurer les politiques de divulgation.