Certains émetteurs (universités, Amiens Métropole…) souhaitent utiliser la méthode de génération des identifiants AMC, pour assurer l’unicité des identifiants entre des supports AMC et d’autres supports non compatibles.

Pour éviter tout risque sécuritaire et toute confusion,il est convenu dans ce cas  d’utiliser pour créer ses identifiants, la seconde clé TDES référencée 0102 h.

Le périmètre de services restera, au moins dans un premier temps celui de l’AMC commune, et les identifiants ainsi générés ne viendront pas prendre la place des identifiants sur support AMC.

La convention d’usage s’appliquera.

Il est suggéré de choisir  la structure  qui a le plus de chances de répondre aux besoins du projet. Quand ces besoins sont  peu définis, le meilleur moyen d'y répondre est de prévoir le maximum, donc la structure la plus riche qui peut tenir dans l’espace disponible de la carte prévue.
Cela donne, par taille décroissante approximative :

• Structure 83h (≈6k octets) : avec les fichiers pour la photographie et pour les données propriétaires.
• Structure 82h (≈5k octets) : avec les fichiers pour la photographie, mais sans les fichiers pour les données propriétaires.
• Structure D1h (≈2k octets) : avec les fichiers pour les données propriétaires, mais sans les fichiers pour la photographie.
• Structure D0h (≈1k octets), en dernier recours : sans les fichiers pour la photographie ni pour les données propriétaires.

Rappels :

• Les données propriétaires sont les identifiants personnalisés, ainsi que des contrats / compteurs / évènements.
• Les fichiers permettant le stockage du nom, du prénom et de la date de naissance sont toujours présents dans ces structures.
• Les tailles effectives dépendent de chaque produit.
• L'utilisation d'une structure de données archaïque (C0h, C1h, 81h ou 82h) est déconseillée.

Pour ceux qui veulent utiliser l'AMC uniquement pour lire les identifiants prédéfinis, les informations utiles  sont les identifiants (octets KIF et KVC) des clés qui sont dans le SAM des encarteurs (configuration "SAM-EPP [XY]") :

Key         KIF    KVC
---         ---    ---
MK_MP1      $41    $F4
MK_MP2      $47    $F4
MK_MP3      $50    $F4
CKD_SIGN    $2A    $F4
CKD_ENC     $EC    $F4

Note: Les clés CKD_SIGN et CKD_ENC ne sont pas utilisées pour les identifiants prédéfinis. CKD_SIGN sert à générer et vérifier les MAC des autres données (photo, nom, identifiants personnalisés, contrats, événements), et la clé CKD_ENC est un intermédiaire de calcul pour le chiffrement de la photo et du nom.

Pour une AMC commune :

• L'AID est celui de l'AMC commune.
• Le périmètre de service (Scope ID) est l'AMC commune.
• Toutes les clés (celles chargées dans les cartes, et celles gérant les identifiants prédéfinis) sont celles de l'AMG commune, gérées par l'ADCET. En particulier, c'est l'ADCET qui assigne les gammes de numéros qui permettent le génération des identifiants prédéfinis (avec la clé TDES commune, fournie par l'ADCET). L'ADCET choisit elle-même à qui elle accepte d'allouer des gammes : encarteur, territoire, etc.
• Les secteurs d'activité ayant un identifiant prédéfini sont les 35 de l'AMC commune.

Pour une AMC spécifique :

• L'AID n'est pas celui de l'AMC commune, il est choisit par l'émetteur de l'application.
• Le périmètre de service est l'émetteur de l'AMC spécifique, avec un Scope ID référencé par l'ADCET, qui choisit elle-même à qui elle accepte d'allouer un Scope ID : encarteur, territoire, etc.
• Toutes les clés sont choisies par l'émetteur de l'application. Si ce sont celles de l'AMC commune, voir ci-dessus. Sinon c'est la même chose en remplaçant "ADCET" par "émetteur de l'AMC spécifique".
• Les secteurs d'activité ayant un identifiant prédéfini sont choisis par l'émetteur de l'AMC spécifique (au plus 35 au total), les numéros 1 à 10 étant réservés aux secteurs CNIL.

Dans les deux cas :

• L'émetteur des données (Issuer ID) est référencé par l'ADCET, qui choisit elle-même à qui elle accepte d'allouer un Issuer ID : encarteur, territoire, etc.

Pour créer les identifiants d'une AMC commune, l'émetteur doit obtenir les clés suivantes:

• La clé publique ECDSA, non chiffrée : ClefAMC-PUB1-1A01.txt
• La  clé privée ECDSA, chiffrée : ClefAMC-PRIV1-1A01.txt.asc
• La  clé TDES de 16 octets, chiffrée : ClefAMC-TDES1-0101-B0F0B6.txt.asc ou la  clé TDES de 16 octets, chiffrée : ClefAMC-TDES1-0102-9E7219.txt.asc pour les identifiants virtuels.

Pour la clés TDES, les 6 derniers caractères du nom du fichier sont la "KCV" (Key Check Value) de la clé, qui sont les 3 premiers octets du résultat du chiffrement de 0000000000000000h avec la clé.

Pour obtenir les clés l'émetteur de l'AMC doit  détenir un jeu de clés GnuPG et adresser une demande à l'ADCET à l'adresse  amc-register@adcet.org. Les clés lui seront adressées sous forme de fichiers chiffrés. 
Le déchiffrement des fichiers nécessite  un mot de passe qui lui sera envoyé dans un autre email dès qu'il aura fait parvenir à l'ADCET  sa clé publique et  pris l’engagement de conserver toutes ces informations confidentielles.
C'est ce mot de passe qui sera déchiffré avec sa clé GnuPG privée, et qu'il faut saisir à la main (pas de copier-coller) pour déchiffrer les fichiers de clés.

1/ Nombre de clés: 9  clés de gestion des identifiants prédéfinis de l'AMC commune ont été générées et conservées par l'ADCET:

• trois clés TDES, pour le calcul des valeurs des identifiants. 
• trois clés ECDSA privées, pour la génération des signatures dont une clé de réserve.
• trois clés  ECDSA publiques (correspondant aux clés privées ), pour la  vérification des signatures dont une clé de réserve.

Les clés ECDSA publiques en cours  d'utilisation sont : 

• EBDD126C12AA5A8357F4EC4B5A3CA87D44C42D6EB97DD430144079EB00E2290F5B43E45E6C94ED56EF827B9EAE0A387EEA193873352816C836B88D5BB199D280 pour les supports Calypso. Référence : 1A01h.
• 4D0217092598E73D4A1F9E2AB6E75691AAB5FE66EBBF623E5E7A60BBB4D380804642CC15CD7157227DD6C46B223D628740226DA222CC734C8B225C133956015B pour les AMC virtuelles. Référence : 1A02h.

La clé publique de réserve est :

• DDC006F0C521BBD4CDE468297EF85AE65B24A2FCE8788098F78974BEAD92DED8AF19AC7577ABB18F86550AD3165AC030FF769EB265D1DA45EDE551345C936A47. Référence : 1A03h.

3/ Références des clés de calcul TDES (valeur de PIDXKeyRef): 

• 0101h pour les identifiants sur support AMC, 
• 0102h pour les identifiants virtuels
• 0103h pour la clé de réserve

A000000291 D250 0800 9301h

Pour une AMC spécifique :

• L'AID n'est pas celui de l'AMC commune, il est choisit par l'émetteur de l'application.
• Le périmètre de service est choisi par l'émetteur de l'AMC spécifique, avec un Scope ID référencé par l'ADCET, qui choisit elle-même à qui elle accepte d'allouer un Scope ID : encarteur, territoire, etc.
• Toutes les clés sont choisies par l'émetteur de l'application. Si ce sont celles de l'AMC commune, voir ci-dessus. Sinon c'est la même chose en remplaçant "ADCET" par "émetteur de l'AMC spécifique".
• Les secteurs d'activité ayant un identifiant prédéfini sont choisis par l'émetteur de l'AMC spécifique (au plus 35 au total), les numéros 1 à 10 étant réservés aux secteurs CNIL.

• L'émetteur des données (Issuer ID) est référencé par l'ADCET, qui choisit elle-même à qui elle accepte d'allouer un Issuer ID : encarteur, territoire, etc.

Le concept de l'AMC virtuelle répond au besoin de certaines collectivités d'utiliser des identifiants de services de même format que ceux de la norme AMC et sans risque de recoupement  avec des identifiants existants, dans des supports non compatibles avec la norme (par exemple non Calypso Revision 3).

Une AMC virtuelle fait référence à une structure de données compatible avec celle de la norme AMC au minimum pour la zone des identifiants prédéfinis ; les données correspondantes peuvent être enregistrées dans un support non compatible avec la norme AMC ou dans un serveur.

AMC commune virtuelle

Une AMC commune virtuelle est une AMC virtuelle dont les identifiants prédéfinis sont géré avec des clés de l'AMC commune, administrées par l'ADCET.
Dans la structure de données Predefined IDs d'une AMC commune virtuelle le périmètre de service indiqué est l'AMC commune (PIDScopeID = '250E00').

Rappel : clés communes

Lors de la cérémonie des clés de l'AMC commune  trois clés TDES ont été créées  pour la génération des identifiants prédéfinis de l'AMC commune, dont les références PIDXKeyRef sont respectivement '0101', '0102' et '0103'.

Celle utilisée pour une AMC commune sur support standard est PIDXKeyRef  = '0101'. Pour la génération des identifiants prédéfinis, la table des gammes de valeurs correspondante est actuellement publiée sur le site de l'ADCET (https://www.adcet.org/fr/amc/les-registres/plage-de-valeurs-amc-commune). Elle est spécifique à cette clé.

Deux paires de clés ECC ont également été créées pour la signature des identifiants, dont les références PIDSignKeyReference sont respectivement '1A01' et '1A02'.
Celle utilisée pour une AMC commune sur support standard est PIDSignKeyReference = '1A01'.

Génération des identifiants prédéfinis

Les identifiants prédéfinis d'une AMC commune virtuelle sont générés suivant l'algorithme décrit dans la norme, en utilisant la clé TDES commune de PIDXKeyRef = '0102' afin qu'il n'y ait pas de collision avec les identifiants prédéfinis des AMC communes sur support standard.

La gamme de valeurs à utiliser est spécifique à cette clé, donc aux AMC communes virtuelles. Elle est disponible sur https://www.adcet.org/fr/amc/les-registres/plage-de-valeurs-amc-commune-2.

Signature des identifiants prédéfinis

Pour éviter de diffuser aux émetteurs d'AMC communes virtuelles la clé secrète des AMC communes sur support standard, la clé ECC commune utilisée pour la signature des identifiants prédéfinis d'une AMC commune virtuelle est celle de PIDSignKeyReference = '1A02'.

Fournitures des clés communes

La procédure pour fournir les clés ADCET au prestataire technique qui produit les structures de données Predefined IDs des AMC communes virtuelles est la même que dans le cas de l'AMC commune sur support standard, avec les spécificités suivantes:

Fournir la clé TDES '0102' et non la '0101', avec les mécanismes de confidentialités habituels.
Fournir une gamme de valeurs issue de la table spécifique à cette clé.
Fournir la paire ECC  '1A02', avec les mécanismes de confidentialités habituels.

Lorsqu'on utilise l'AMC sur mobile sous forme de Code2D il peut être nécessaire de se protéger contre la copie frauduleuse. A cette fin le GT AMC a prévu une méthode pour générer des AMC mobile dynamique. Cette méthode est décrite dan le document https://www.adcet.org/fr/documents-gt-amc?download=151:amc-sur-support-non-calypso-v1-1 et un extrait spécifique à la signature dynamique a été publié https://www.adcet.org/fr/documents-gt-amc?download=190:amc-mobile-avec-signature-dynamique-sur-supports-non-calypso.

Dans notre expérience, pour les échanges entre machines il est toujours préférable de s'affranchir des fuseaux horaires et de l'heure d'été/hiver, qui ne sont utiles que dans les interfaces avec les utilisateurs. Cela évite par exemple des problèmes avec un touriste ayant conservé son téléphone à l'heure de son pays d'origine.

Tous les OS peuvent fournir des horodates UTC, par exemple en Java :

• Horodate UTC courante : Instant.now().getEpochSecond()
• Horodate UTC du CB2D : LocalDateTime.of(year, month, day, 0, 0, 0).toEpochSecond(ZoneOffset.UTC) + DynamicDateTime

Pour avoir l’ancienneté du CB2D en secondes, il suffit de comparer ces deux horodates.

La durée de validité d'un CB2D dynamique devrait être égale à sa période de régénération, plus une marge de sécurité pour gérer le décalage d'heure entre les téléphones qui génèrent le CB2D et les lecteurs qui le vérifient.
Par exemple, pour une période de régénération de 20 secondes, une durée de validité de 50 secondes me semble envisageable.
Ces temps devraient être testés sur le terrain, afin de les adapter aux conditions réelles d'exactitude de l'heure des lecteurs et des téléphones.

Il existe dans un projet mettant en oeuvre une AMC  quatre rôles indépendants, une entité donnée pouvant assumer un seul ou plusieurs de ces rôles.

• Émetteur d'AMC/périmêtre de services
  C'est le responsable des paramètres structurels d'une AMC (AID, structure de fichiers, clés, etc.), et en particulier des gammes de valeurs pour le calculateur des identifiants prédéfinis (voir ci-dessous).
  Il est identifié par son ServiceScopeID.
  Par exemple, pour une carte sans contact (par opposition à une SIM...) l'émetteur de la carte pourrait la collectivité en charge des transports alors que l'émetteur de l'AMC de cette carte serait la collectivité en charge des services aux citoyens (cette collectivité pouvant de son côté émettre des cartes ne portant que l'AMC, pour les citoyen qui n'ont pas de carte de transport).
• Émetteur de données d'AMC
  Il est responsable de l'écriture de données dans n'importe quelle AMC.
  Il est identifié par son IssuerReference.
  L'une des fonctions potentielles de IssuerReference est de filtrer/tracer qui écrit quoi dans les AMC, en utilisant le mécanisme de "CAAD" des SAM.
  Ce rôle peut être assumé un territoire (par ex. pour les données "universelles" d'une AMC : photo, ID prédéfinis, etc.), par un opérateur de services (par ex. pour des ID personnalisés ou des contrats), etc.
• Initialisateur d'AMC
  Il configure les supports pour y créer une application Calypso Rev.3. avec l'AID, la structure de fichiers et les clés d'une AMC (la commune ou une spécifique).
  L'émetteur de cette AMC lui confie un SAM que nous appelons "SAM-CPP", qui contient les clés à charger dans l'application.
  Pour une carte sans contact c'est toujours l'encarteur qui assume ce rôle. Pour une SIM c'est le "TSM SP".
• émetteur des identifiants prédéfinis
  C'est un tiers fiable à qui l'émetteur d'une AMC confie ses clés secrètes TDES et ECDSA et assigne une gamme de valeurs.
  Sa seule tâche est de faire les calculs appropriés afin de générer la structure PredefinedIDs pour le compte d'un émetteur de données, à partir de la gamme de valeur, de la clé TDES (pour générer les ID) et de la clé ECDSA privée (pour signer ces ID).
  Il n'a besoin d'aucune référence AMC. L'émetteur des identifiants prédéfinis ainsi calculés (qui est donc un émetteur de données) peut enjoindre au calculateur de ne faire ses calculs que pour lui. C'est souvent le fabriquant de  cartes qui assure cette fonction.

IMPORTANT — Si l'émetteur de l'application souhaite contrôler les gammes de valeur utilisées par ses fournisseurs de carte, le champ PIDIssuerReference est l’identifiant de cet émetteur d'application(valeur de GDIssuerReference). Si l'émetteur de l'application souhaite déléguer totalement la gestiondes gammes de valeur à ses fournisseurs de carte, le champ PIDIssuerReference est l'identifiant du fournisseur du support .

Sécurité: L'AMC spécifique permet un risque circonscrit au périmètre concerné, mais nécessite le tirage de clés AMC propres à ce périmètre. La collectivité en charge des services devra être en mesure d'assurer la sécurité des secrets. Si c'est généralement le cas pour le transport, ceci peut être une contrainte pour les services n'ayant jamais eu à s'organiser de la sorte. Dans le cas de l'AMC commune, l'ADCET est garante des secrets.

Le gestionnaire des secrets doit également gérer des gammes de valeurs sans recouvrement, pour le calcul des identifiants prédéfinis.

Structure: L'AMC commune offre une structure modulaire prédéfinie qu'il est possible d'adapter en fonction du besoin. Dans le cas d'une AMC spécifique le territoire spécifie la structure de l'application librement. La définition nécessitera potentiellement un accompagnement plus fort.

Données: une AMC spécifique a plus de liberté sur les données obligatoirement/potentiellement présentes, par exemple pour le choix les secteurs d’activités pour les identifiants prédéfinis, mais cela réduit l’universalité des équipements des opérateurs de services (par exemple, difficulté à traiter ≠ AMC spécifiques sur un horodateur).

Interopérabilité : l'AMC commune permet une interopérabilité des services à l'échelle nationale.

Oui, car  comme toute application Calypso Rev.3 conforme à l’ISO7816‑5 chaque AMC (commune et spécifiques) a son propre nom d’application (AID), donc peut cohabiter dans un même support avec une ou plusieurs autres AMC.

Les clés de test recommandées sont :

• Pour les clés chargées dans l'application : clés de test interopérables France de KIF/KVC=414Fh, 474Fh et 504Fh.
• Pour la gestion des MAC de données (comme les Custom IDs) : clé de test interopérable France de KIF/KVC=2B8Bh.
• Pour le (dé)chiffrement des données personnelles (photo, nom/prénom) : clé de test interopérable France de KIF/KVC=EC4Dh.
• Pour la gestion des identifiants prédéfinis ce sont les clés des exemples de la norme (NF P99-508) :
  • Clé TDES de calcul des identifiants prédéfinis : PIDXKeyRef = 0753h (Annexe A.1 de la norme).
  • Clés ECDSA d'authentification des identifiants prédéfinis : PIDSignKeyReference = CB32h (Annexe A.4).

• Pour les clés de test : c'est le responsable du projet qui décide, soit il prend une gamme quelconque (qui peut être en conflit avec une autre gamme de test, mais comme c'est du test c'est acceptable), soit il en demande une à l'ADCET que sera ajoutée sur le site (Plages de valeurs AMC commune) pour l'identifiant d'émetteur correspondant et avec "oui" dans la colonne "Pour test".
• Pour les clés opérationnelles de l'AMC commune : les gammes sont allouées par l'ADCET.
• Pour des clés opérationnelles d'une AMC spécifiques : les gammes sont allouées par l'autorité d'enregistrement du périmètre d'acceptation de l'AMC spécifique en question.

Des clés T-DES seront utilisées pour la gestion des accès aux fichiers AMG ainsi que pour calculer les valeurs des identifiants prédéfinis. Une clé ECDSA sera utilisée pour calculer la signature des identifiants prédéfinis.

Réponse fournie par Stéphane Didier de Spirtech

Les niveaux de sécurité possibles sont les suivants :

1. Aucune authentification : pas de vérification de la signature publique, ni d'authentification du support.
2. Authentification statique seulement : vérification de la signature publique (PIDSignature), mais pas d'authentification du support.
3. Authentification complète: vérification de la signature publique (PIDSignature), et authentification dynamique du support par session sécurisée Calypso.

C'est à chaque opérateur/fournisseur de service de choisir le niveau qui lui convient, en fonction des coûts et des risques.

• Pour le niveau 1, il suffit de savoir lire une carte ISO 7816-4 (commandes Select Application et Read Record), en sans contact ou au contact.
  L'opérateur/fournisseur de service est exposé à tous les risques de falsification : création de faux identifiants, duplication d'identifiants authentiques, création de faux supports, duplication de supports authentiques.
• Pour le niveau 2, il faut en plus implémenter l'algorithme de vérification ECDSA et utiliser la clé publique AMG (aucune utilisation de donnée secrète).
  L'opérateur/fournisseur de service est protégé contre la création de faux identifiants, mais reste exposé aux risques de duplication d'identifiants authentiques, de création de faux supports et de duplication de supports authentiques.
• Pour le niveau 3, il faut en plus implémenter le mécanisme de session sécurisée Calypso, qui nécessite l'accès à un SAM (qui peut se trouver dans le terminal ou dans un serveur) car il met en œuvre des clés secrètes.
  L'opérateur/fournisseur de service est alors protégé contre tous les risques de falsification des identifiants ou des supports (l'authenticité des identifiants et des supports est garantie).

Un fournisseur de terminaux ou un intégrateur pourrait donc se contenter de tester le niveau le plus faible exigé par l'opérateur/fournisseur de service.

Sur une suggestion de Claude Camilli du STIF et avec le concours de SPIRTECH

Il est possible de décorréler, par un système de tokenisation/détokenisation indépendant de la carte :

A) ce qui est dans la carte et destiné en principe à un partenaire, mais physiquement accessible à tous,

B) l'identifiant des informations personnelles du titulaire de la carte dans le système d'Information de ce partenaire.

De la sorte, même si un indélicat lit et conserve A, il ne peut remonter à B ni donc aux informations personnelles du titulaire de la carte par le biais du SI de ce partenaire, sans aussi accéder au système de détokenisation.

Sa mise en œuvre avec l'AMG actuelle ne nécessite aucune modification de la spécification, et dépend de la durée de vie du token.

Pour un token inscrit une fois pour toute :

• changement sémantique : l'identifiant dans la carte réservé au secteur d'activité du partenaire devient le token ;
• la tokénisation est l'association par le système de (dé)tokénisation de ce token à l'identifiant qui permet d'accéder aux informations personnelles du titulaire de la carte dans le SI ;
• le mécanisme de (dé)tokénisation peut être réalisé de diverses façons : calcul cryptographique avec une clé sécrète, table de correspondance, etc.

Le risque de vol de données personnelles reposant sur la robustesse du processus de tokenisation et de detokenisation ce dernier devra faire l'objet de mesures de protections renforcées. Si ces mesures ne sont pas suffisantes il sera possible de modifier régulièrement ou en réaction à la détection d'un vol du processus de tokenisation/dékonisation.Pour un token régulièrement modifié, il faudrait prévoir un système de mise à jour, stocker ce token en tant qu'identifiant personnalisé (ou éventuellement en tant que contrat, mais il n'y en a que 4 dans les structures de fichiers de l'AMG commune), et il faudra éventuellement prévoir un système de CAAD.

CAAD: "Card Access Authorization Decriptor", le mécanisme du SAM qui permet d'imposer l'utilisation d'un identifiant dans les données inscrites dans les cartes, afin de contrôler avec le SAM qui écrit quoi, et éventuellement de limiter la modification d'une donnée à l'opérateur qui l'a inscrite.

À ce jour seul Spirtech le fait, néanmoins Spirtech fournit tous les éléments, et potentiellement d'autres sociétés comme ASK pourraient le faire.

Le HSM doit répondre au standard Calypso. Aujourd'hui il n'existe qu'une seule offre (les HSM Calypso de Spirtech), donc il n'y a pas de contrainte technique. Le SAM n'est nécessaire que pour la mise en œuvre du niveau de sécurité #2 (session sécurisé). En fonction du nombre de transactions simultanées envisagées, il n'est pas forcément nécessaire de s'équiper d'un HSM PCIs (actuellement utilisé uniquement pour des applications billettiques), un HSM SAM‑S20 peut être suffisant (jusqu'à 20 sessions sécurisées simultanées)

 Les clés privées AMC ne sont généralement transmises qu'aux encarteurs. La procédure est a décider au cas par cas (par ex. via mécanisme sécurisé OpenPGP). Dans le cas de l'AMC commune, l'ADCET se charge de transmettre les clés à l'encarteur sur demande de la collectivité en charge des services. Dans le cas d'une AMC spécifique, la collectivité transmets ses clés à l'encarteur. 

En termes techniques il existe 2 groupes de clés:

Groupe1 (dans un SAM) :

- Les 3 clés à charger dans de l’application Calypso

- La clé de signature MAC

- La clé de chiffrement 3DES

Groupe 2 (hors SAM, transmises de manière sécurisée) :

- La paire de clés secrète/privée, pour signature des identifiants prédéfinis

- La clé 3DES de calcul des identifiants prédéfinis

Il est suggéré de choisir  la structure  qui a le plus de chances de répondre aux besoins du projet. Quand ces besoins sont  peu définis, le meilleur moyen d'y répondre est de prévoir le maximum, donc la structure la plus riche qui peut tenir dans l’espace disponible de la carte prévue.
Cela donne, par taille décroissante approximative :

• Structure 83h (≈6k octets) : avec les fichiers pour la photographie et pour les données propriétaires.
• Structure 82h (≈5k octets) : avec les fichiers pour la photographie, mais sans les fichiers pour les données propriétaires.
• Structure D1h (≈2k octets) : avec les fichiers pour les données propriétaires, mais sans les fichiers pour la photographie.
• Structure D0h (≈1k octets), en dernier recours : sans les fichiers pour la photographie ni pour les données propriétaires.

Rappels :

• Les données propriétaires sont les identifiants personnalisés, ainsi que des contrats / compteurs / évènements.
• Les fichiers permettant le stockage du nom, du prénom et de la date de naissance sont toujours présents dans ces structures.
• Les tailles effectives dépendent de chaque produit.
• L'utilisation d'une structure de données archaïque (C0h, C1h, 81h ou 82h) est déconseillée.

Global Data et Predefined IDs. C’est le minimum nécessaire pour que la norme soit utilisable. Ensuite, si on a une structure 81h ou C1h intégrant les données personnelles, il peut être intéressant de tout de suite inscrire ces données personnelles  si on les connaît (mais cela peut aussi relever d’une personnalisation ultérieure).

L'ADCET suggère une règle simple: (LID d’un fichier) = (LID du DF AMC) + (SFI)

Par exemple, si le DF de l'application  a un LID = 3100h :
- Global Data, qui a un SFI = 17h, aura le LID 3117h
- Predefined Identifier, qui a un SFI=03h, aura le LID 3103h
- etc.

Les terminaux devraient utiliser les SFI (qui sont indiqués dans la norme) et pas les LID (qui ne sont pas indiqués dans norme, justement car les terminaux ne devraient pas en avoir besoin).

L'utilisation de LID n'est pas nécessaire pour l'AMC mais il est préférable de les mettre tout en indiquant que les terminaux ne doivent pas les interpréter. L'ADCET fournira les LID génériques pour l'AMC commune.

Afin d’être conforme aux recommandations de la CNIL, la carte porte plusieurs identifiants (de 1 à 10 : ces identifiants sont réservés pour les services publics correspondant à un secteur d’activité défini par la CNIL) :

1     Fiscalité                Taxe ou redevance d'enlèvement des ordures ménagères. Taxe de séjour.

2     Travail et social Bourse de l'emploi. Apprentissage. Formation professionnelle. Demande de stage, d'emploi. Gestion des aides sociales (demande, attribution et suivi) dans les domaines suivants :

demande de logement et/ou d'aides ;

bourse ;

allocation personnalisée d'autonomie ;

aides en faveur des personnes handicapées ;

revenu de solidarité active.

3     Santé    Protection maternelle et infantile. Plan de vaccination. Plan canicule. Plan d'alerte et sauvegarde de la population.Demandes d'agrément d'assistante maternelle.

4     Transports : Inscription, suivi et paiement en ligne des prestations, scolaires ou municipales, de transports individuels ou en commun (vélo, voiture, autobus, etc.).Informations sur les conditions de circulation.

5     État civil et citoyenneté Demande d'extraits ou de copies d'actes de l'état civil, de livret de famille. Inscription à la journée défense et citoyenneté/recensement citoyen obligatoire. Inscription sur les listes électorales. Signalement de changement d'adresse. Attestation d'accueil. Autorisation de sortie du territoire. Demande de titres d'identité, de voyage ou de séjour.

6     Relations avec les élus   Communication municipale. Relations des usagers avec les élus (demande de rendez-vous, etc.).

7     Prestations scolaires et périscolaires, activités sportives et socioculturelles         Gestion des dossiers (inscription, suivi et paiement en ligne) dans les domaines suivants :

centre de loisirs sans hébergement ;

prestations touristiques ;

centre de vacances ;

école ;

crèche-garderie ;

Restauration scolaire ;

activités sportives (piscine municipale, salle de sports, etc.) ;

activités socioculturelles (bibliothèque, médiathèque, musée, réservation de salle municipale) ;

formations pour adultes ;

location de salle ou matériel municipal ;

repas à domicile.

8     Économie et urbanisme Inscription de l'activité dans l'annuaire socio-économique. Aides aux entreprises. Demande de locaux professionnels.

Gestion des dossiers (demande, attribution, suivi et paiement en ligne) dans les domaines suivants :Eau-assainissement ;permis de construire ; permis d'aménager ; permis de démolir ; certificat d'urbanisme ; arrêté individuel d'alignement.

Déclaration : d'achèvement de travaux ; d'ouverture d'un chantier ; d'intention d'aliéner.

9         Polices spéciales et voirie ; Autorisation temporaire de débit de boissons. Déclaration de chien de première ou deuxième catégorie. Attestation de changement de domicile. Paiement, abonnement ou autorisation de stationnement. Emplacement de marché/foire. Accès aux voies piétonnes. Objets perdus. Signalement de nuisance sonore, olfactive ou visuelle. Demande d'intervention sur le domaine public (entretien d'espace vert, éclairage public, graffiti, container, etc.). Cimetière (attribution de concession funéraire). Tournage de films.

10   Relations avec les usagers           Relation des usagers avec les services (demande de rendez-vous, etc.).

Inscription à la cérémonie des nouveaux habitants.

Exercice des droits informatique et libertés (demande d'information, de rectification, suppression, etc.).

11   Services aux agents (carte agent)

12   Services de la vie étudiante (Restauration étudiante, accès aux locaux et services réservés aux étudiants : bibliothèques, résidences étudiantes, salles informatiques, etc.)

13   Fidélité et commerce

14         Mobilité (Maas) actions de mobilité regroupant autour d'un même compte soit des transports publics soit des transports privés

15– 19 Réservés pour une définition future SERVICES PUBLICS

20          Services à la personne

21          Transports privés

22          Paiements

23          Réseaux sociaux

24          Activités sportives et culturelles et loisirs

25          Programme de fidélité (hors contexte « cœur de villes »)

26 à 35 : RFU

Si l’on considère la totalité des AMC émises dans un périmètre de services donné , l’unicité d’un identifiant prédéfini est garantie par l’ensemble des champs suivants :

• PIDXSector (2 octets) qui définit le périmètre de services ;
• PIDXKeyRef (2 octets) qui définit la clé TDES utilisée pour le calcul des identifiants à partir d'une valeur racine;
• PIDXValue (4 octets) qui définit la valeur calculée à partir le la clé ci-dessus et d'une valeur racine..

Cette unicité est assurée par le respect des règles définies pour le choix des valeurs de PIDXSector,PIDXKeyRef, et PIDXValue.
Au sein d’un système d’information donné, PIDXKeyRef ou PIDXSector peuvent être omis s’ils sont identiques pour toutes les AMC gérées par ce système.

Donc, dans le cas de l'AMC commune, pour utiliser une des plages définies sur le site de l'ADCET (Plages de valeurs AMC commune), il faut et il suffit que dans la structure de données des identifiant prédéfinis il y ait :

• PIDScopeID = 250E00h (AMC commune).
• PIDXKeyRef = 0101h (clé TDES référencée sur le site de l'ADCET, Clés pour les identifiants prédéfinis de l'AMC commune) 

Bien sûr, il faut aussi que celui qui produit les identifiant prédéfinis ne prenne des valeurs que dans les gammes qui lui ont été allouées par l'ADCET.

IMPORTANT — Règle d’unicité et de non corrélation : l’émetteur des identifiants prédéfinis (indiqué par PIDIssuerReference) est garant que chaque valeur qu’il génère n’est utilisée qu’une seule fois pour un secteur d’activité donné, et que l’identifiant ne doit pas pouvoir être déduit de la seule connaissance d’un ou plusieurs autres identifiants AMC.
Les principes de génération des valeurs utilisée pour l’AMC commune, et recommandés pour les AMC spécifiques sont les suivants :

• l’émetteur d’identifiants prédéfinis dispose de la totalité d’une gamme de valeurs de 4 octets (soit plus de 4 milliards de valeurs possibles) qu’il peut subdiviser comme il le souhaite. Il est par exemple possible de la scinder en gammes plus petites assignable à différents sous-traitants ou à différents projets, à condition que ces gammes ne se recouvrent pas ;
• une clé triple-DES (« TDES ») gérée par  la gouvernance du périmètre de services (l'ADCET pour l'AMC commue)  est utilisée. Cette clé doit rester confidentielle car elle peut permettre de prédire les numéros des applications AMC : seules les entités qui génèrent les identifiants ont besoin de la connaître.