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.


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.