La validation de l’authentification Qi doit démontrer l’échange d’authentification requis sur la combinaison exacte de matériel, de micrologiciel et de récepteur, puis montrer ce qui se passe si cet échange échoue. La présence d’un composant de sécurité sur une carte ne prouve pas un échange réussi, et un échange réussi n’établit pas de manière indépendante la certification Qi du produit fini.
Pour un projet de développement de chargeur, définissez le profil implémenté et les exigences d’authentification applicables avant de choisir les outils ou les cas d’acceptation. La page d’authentification WPC fournit le contexte principal de l’écosystème. Dans un chargeur-sans fil WECENT programme OEM/ODM, acceptez la responsabilité des enregistrements de mise en œuvre, de l’approvisionnement autorisé et de l’examen de certification externe avant d’approuver la portée de l’authentification. Conservez les preuves fonctionnelles, les contrôles d’attribution des informations d’identification et la demande de certification externe en tant qu’éléments d’examen distincts avec leurs propres parties responsables.
Que doit démontrer un flux d’authentification Qi ?
Montrez l’échange requis et son résultat défini.
Un échange partiel ne peut pas établir le résultat final de l’authentification ; préserver les tentatives et l’état de fonctionnement autorisé afin que le succès fonctionnel puisse être séparé d’une capture incomplète ou non prise en charge.
L’explication d’authentification Microchip Qi 1.3 a est une référence d’implémentation spécifique à la version. Utilisez les exigences du profil réellement implémenté plutôt que d’appliquer sa description universellement. Identifiez les participants et le résultat lié à la confiance que l’outil peut établir. Un état général du contrôleur peut résumer un échange mais peut ne pas exposer suffisamment de détails pour diagnostiquer une panne.
Conservez la séquence complète, y compris les tentatives et les changements d’état pertinents. Si la capture commence après la décision, le résultat nécessite un autre enregistrement source fiable. Distinguer l’absence d’échange, un échange rejeté et un échange dont l’interprétation est limitée par l’outillage. Ces résultats nécessitent différentes actions correctives et ne doivent pas être réduits à un échec d’authentification générique.
Un échange réussi nécessite le résultat souhaité, et pas seulement un trafic visible. Identifiez ce qui établit ce résultat dans le cadre du profil mis en œuvre et de la portée de l’outil. Si l’acquisition ne peut pas évaluer une pièce nécessaire, signalez cette limitation séparément d’un rejet démontré par le produit.
Quels outils doivent être approuvés pour l’évaluation ?
Utilisez des outils prenant en charge la portée de l’authentification.
Confirmez ce que l’outil évalue avant de faire confiance à son étiquette d’état ; Le décodage de contrôle ordinaire peut ne pas couvrir la méthode d’authentification ou les preuves liées à la confiance requises pour le profil de produit mis en œuvre.
L’approbation de l’outil doit provenir du programme ou du processus de laboratoire responsable. Un décodeur qui reconnaît le trafic de contrôle ordinaire peut ne pas évaluer l’échange d’authentification ou la chaîne de confiance requis par le cas. Déterminez ce que l’outil vérifie et ce qui reste en dehors de son champ d’application avant d’interpréter un indicateur d’état vert.
Conservez le logiciel et la configuration de l’outil avec le résultat. Lorsqu’un récepteur ou un émulateur contrôlé est utilisé, documentez son rôle et son comportement pris en charge. Évitez de placer des informations d’identification privées dans des journaux publics ou des exemples d’articles. Les preuves doivent montrer le résultat et la traçabilité requis pour l’examen sans divulguer de secrets. Si des documents sensibles sont nécessaires à un laboratoire agréé, traitez-les via le canal contrôlé convenu plutôt que de traiter la documentation publique comme une archive de diffusion.
Comment sélectionner la matrice réceptrice ?
Couvrez les chemins d’authentification que le produit doit prendre en charge.
Un destinataire qui n’exerce jamais l’échange requis ne peut pas fournir de couverture d’authentification ; sélectionnez les entrées de la matrice en fonction de leur comportement pertinent plutôt que du nombre de marques d’appareils reconnaissables testées.
Choisissez des cas parmi les exigences réelles et les modes de fonctionnement pris en charge. Un destinataire qui n’exerce pas l’échange concerné ne peut pas établir de couverture d’authentification simplement parce que la facturation fonctionne. Enregistrez pourquoi chaque entrée de la matrice est importante et quel résultat est attendu pour cette combinaison.
La documentation du produit ST STSAFE-V100-Qi fournit un exemple de composant de sécurité, et non une réclamation concernant le chargeur testé. Pour chaque récepteur réel, conservez le modèle et l’état du micrologiciel ou du logiciel correspondant. Si le comportement d’un appareil change après une mise à jour, vérifiez si les preuves précédentes le couvrent toujours. Gardez visibles les cas non pris en charge, non exécutés et ayant échoué au lieu de leur attribuer la même étiquette qu’un échange validé.
Sélectionnez les récepteurs qui exercent le chemin d’authentification approprié. Un appareil pris en charge fonctionnant dans un mode différent peut fournir une couverture de charge ordinaire sans tester ce chemin. Gardez les cas attendus valides, non pris en charge et délibérément échoués distincts afin que leurs résultats ne puissent pas gonfler le nombre de couverture d’authentification.
Pourquoi l’identité du micrologiciel est-elle importante pour l’authentification ?
Identifiez le logiciel et la configuration testés.
Un marquage de composant de sécurité n’établit pas un approvisionnement correct ; conserver la configuration contrôlée et l’artefact exact du micrologiciel qui a produit l’échange sans exposer les informations d’identification confidentielles dans les archives publiques.
Le Discussion sur l’authentification par puce électronique et la fourniture de clés illustre pourquoi la mise en œuvre comprend plus qu’un choix de pièces au niveau de la carte. Ne déduisez pas un approvisionnement correct d’un marquage de composant. Le programme réel nécessite des enregistrements contrôlés pour la configuration testée et le processus de fabrication autorisé.
Lorsque le micrologiciel change, évaluez la communication, l’accès aux informations d’identification et les chemins de secours que cela peut affecter. Conservez la ligne de base et le candidat séparément. Un test fonctionnel d’une unité d’ingénierie n’établit pas que la programmation de production crée le même état. Définissez la vérification et la traçabilité de la fabrication appropriées au programme, tout en gardant les détails confidentiels de mise en œuvre hors des réclamations adressées aux clients. Les preuves de publication doivent identifier l’artefact testé sans exposer les clés privées ni inventer de capacités de provisionnement.
L’artefact testé inclut la configuration ainsi que le code. Une étiquette de version inchangée peut masquer différents paramètres d’approvisionnement ou persistants. Utilisez la méthode d’identité contrôlée du programme pour relier le résultat fonctionnel à l’état de fabrication sans divulguer de documents d’identification privés dans des preuves publiques.
Quel comportement de repli faut-il tester ?
Utilisez le résultat requis par le profil implémenté.
Le repli dépend du profil plutôt qu’universel ; définissez l’état attendu avant d’appliquer les cas d’échec, puis observez le transfert et la prochaine connexion prise en charge ainsi que le résultat de l’authentification et la récupération.
Différentes implémentations et profils peuvent nécessiter des résultats différents. Obtenez les règles applicables et les exigences produit avant de définir la réponse attendue. Un chargeur continuant à transférer de l’énergie après un échange infructueux n’est pas automatiquement correct ou incorrect sans ce contexte.
Utilisez des stimuli contrôlés qui démontrent le cas prévu et vérifient leur exécution. Enregistrez le résultat de l’authentification à côté de la réponse électrique ou de l’état du récepteur. Si l’outil ne parvient pas à déterminer la raison de l’échec de l’échange, laissez cette cause non résolue. Suivez la session jusqu’à la prochaine connexion où la récupération est importante. Un refus attendu ponctuel peut coexister avec un état persistant involontaire qui empêche un récepteur pris en charge ultérieur de fonctionner ; les deux observations appartiennent à la décision de mise en liberté.
La gestion des pannes pose deux questions : si l’état de fonctionnement immédiat est autorisé et si la prochaine connexion prise en charge se rétablit comme requis. Un refus attendu peut toujours laisser un état persistant involontaire. Conservez les deux résultats au lieu de fermer le dossier à partir du premier statut visible.
Que doit expliquer un journal d’échec d’authentification ?
Localisez l’étape ayant échoué et préservez son contexte.
Un délai d’attente et un décodeur non pris en charge sont des résultats différents ; localisez la première défaillance prise en charge avant d’attribuer une cause au produit ou de clôturer un problème après un échange ultérieur réussi.
Un code récapitulatif peut guider l’enquête mais peut ne pas identifier la cause première. Alignez-le avec la trace et les participants réellement configurés. Vérifiez l’exhaustivité de l’acquisition et la compatibilité des outils avant de conclure qu’un message manquait. Préservez les tentatives, car un éventuel succès peut masquer un échec initial intermittent.
Conservez les identifiants de production et les enregistrements d’approvisionnement sensibles dans le système interne approuvé. Le rapport destiné au client peut décrire la révision testée, la méthode, le résultat et la référence contrôlée sans révéler de documents confidentiels. Lorsqu’une modification corrective est apportée, conservez le résultat initial et répétez les cas valides et d’échec pertinents. Un nouvel échange réussi prend en charge la correction testée uniquement dans sa configuration et sa couverture démontrées.
| Modèle / révision et récepteur | Flux et outils d’authentification | Résultat mesuré/enregistré | Décision |
|---|---|---|---|
| Identités testées exactes requises | Échange applicable ; outil pris en charge approuvé | Résultat réussi et état de fonctionnement autorisé capturés | Accepter le cas d’authentification testé selon ses exigences |
| Identités testées exactes requises | Stimulant d’échec approuvé | Repli attendu et récupération à la prochaine connexion enregistrée | Évaluer séparément le comportement de défaillance requis |
| Carte avec un composant de sécurité | Pas de dossier d’échange complet | Marquage des pièces ou documentation des composants uniquement | Contribution à la mise en œuvre ; preuve d’authentification non fonctionnelle |
| Modèle fini avec un passe interne | Périmètre interne identifié | Aucun dossier de certification de produit fini applicable fourni | Ne pas déduire la certification du résultat interne |
En quoi l’authentification est-elle différente de la portée de la certification ?
Séparez la portée de l’authentification et de la certification.
Les preuves des composants soutiennent uniquement leur portée définie ; vérifiez séparément l’enregistrement de certification applicable du modèle fini avant d’utiliser un code d’authentification interne pour prendre en charge une réclamation de statut de produit certifié adressée au client.
Les Guide des composants et sous-systèmes WPC expliquent l’importance du produit assemblé et la portée des preuves des composants. Un dispositif de sécurité annoncé pour l’authentification Qi peut prendre en charge une implémentation, mais sa présence ne constitue pas un enregistrement de certification du produit fini.
Faites correspondre toute réclamation externe au modèle exact et à l’enregistrement de l’organisation applicable. Vérifiez si les modifications apportées au matériel, au micrologiciel ou à l’intégration nécessitent des travaux supplémentaires dans le cadre du processus pertinent. Si les preuves se limitent à des tests d’authentification internes, indiquez-le dans le package de version contrôlée et conservez la formulation du client dans cette portée. Cela évite à la fois d’exagérer la conformité et de rejeter des preuves techniques utiles simplement parce qu’elles ne constituent pas en elles-mêmes un artefact de certification.
La certification et un résultat d’authentification fonctionnelle répondent à différentes questions. Faire correspondre un enregistrement externe au modèle fini et à sa portée ; faire correspondre la trace interne à l’implémentation testée. L’application prévue d’un composant de sécurité ne peut pas à elle seule intégrer ces enregistrements dans une approbation de produit plus large.
Qu’est-ce qui devrait autoriser la publication de l’implémentation ?
Approuver l’artefact testé et sa couverture documentée.
Un échantillon d’ingénierie fonctionnel n’établit pas de contrôle de configuration de production ; connectez l’artefact testé au processus de provisionnement autorisé et gardez visibles les cas non résolus du récepteur ou de l’approbation externe.
Le package devrait permettre à l’ingénierie de distinguer un échantillon de travail d’un processus de production contrôlé. Conservez la révision du matériel testé, l’identité du micrologiciel, la configuration de l’outil, les références des résultats et la responsabilité d’approvisionnement autorisée. La capacité générale de sécurité d’un fournisseur ne remplace pas ces dossiers de programme.
L’approbation de la production nécessite la mise en œuvre testée et le processus d’approvisionnement autorisé pour être accepté. Un échantillon d’ingénierie réussi ne peut pas couvrir une configuration de fabrication non spécifiée. Liez l’artefact publié aux enregistrements qualité traçables par lots, puis conservez les décisions distinctes pour les échanges valides, le comportement en cas d’échec et la portée de la certification externe. Une modification du micrologiciel affectant la communication ou l’accès aux informations d’identification nécessite une régression ciblée. Conservez les documents privés dans des dossiers contrôlés pendant que le résumé de la publication expose suffisamment de preuves d’identité et de résultats pour étayer sa revendication publique précise.
Questions fréquentes
Une puce de sécurité d’authentification Qi rend-elle le chargeur certifié ?
Non. Il peut s’agir d’un composant de mise en œuvre, mais le modèle final nécessite toujours le processus et la portée de certification applicables. Confirmez l’enregistrement externe de manière indépendante et conservez la preuve d’échange fonctionnel pour le matériel et le micrologiciel exacts. Le marquage d’une pièce ou la fiche technique d’un composant n’établit pas une intégration, un approvisionnement ou une approbation du produit fini corrects. Gardez chaque affirmation liée à ses propres preuves plutôt que de traiter l’application prévue du composant comme le statut du chargeur assemblé.
Un échec d’authentification peut-il quand même permettre la facturation ?
Le résultat autorisé dépend du profil implémenté et de ses exigences applicables. Ne présumez pas d’une solution de repli universelle. Établissez l’état de fonctionnement attendu avant le test, puis capturez ensemble le résultat de l’authentification et la réponse de transfert réelle. Si une opération réduite ou un refus est requis, vérifier ce comportement et la récupération ultérieure. Une session qui continue à se charger n’est qu’une observation jusqu’à ce qu’elle soit comparée à la règle correcte pour cette configuration.
Les informations d’identification privées doivent-elles apparaître dans un rapport de test client ?
Les rapports publics ou largement diffusés ne doivent pas divulguer de documents d’identification privés. Utilisez des références contrôlées et le canal autorisé approuvé pour les preuves d’approvisionnement sensibles. Le rapport peut toujours identifier l’artefact testé, la méthode, le résultat et l’enregistrement responsable sans publier de secrets. Accepter les exigences d’accès au laboratoire et aux clients dans le cadre du programme. Les preuves doivent étayer la portée de l’authentification indiquée tout en préservant les exigences de confidentialité convenues par le programme et le laboratoire responsable.
Conclusion : garder les trois couches de preuves distinctes
Une évaluation d’authentification contrôlée relie l’échange requis à son résultat d’exploitation, exerce un comportement de défaillance défini et préserve la mise en œuvre exacte derrière la trace. Les contrôles d’approvisionnement et de fabrication établissent que la production peut reproduire l’état testé ; La certification des produits finis suit son propre processus et sa propre portée. Gardez ces couches distinctes dans le package de version et dans les réclamations des clients. Cela permet à un programme d’utiliser des preuves techniques valides sans impliquer de certification ou d’assurances de sécurité que les enregistrements disponibles n’établissent pas.
{« @context »: « https://schema.org », « @type »: « FAQPage », « mainEntity »: [{« @type »: « Question », « name »: « Une puce de sécurité d’authentification Qi rend-elle le chargeur certifié ? », « acceptedAnswer »: {« @type »: « Answer », « text »: « Non. Il peut s’agir d’un composant de mise en œuvre, mais le modèle final nécessite toujours le processus et la portée de certification applicables. Confirmez l’enregistrement externe de manière indépendante et conservez la preuve d’échange fonctionnel pour le matériel et le micrologiciel exacts. Le marquage d’une pièce ou la fiche technique d’un composant n’établit pas une intégration, un approvisionnement ou une approbation du produit fini corrects. Gardez chaque affirmation liée à ses propres preuves plutôt que de traiter l’application prévue du composant comme le statut du chargeur assemblé. »}}, {« @type »: « Question », « name »: « Un échec d’authentification peut-il quand même permettre la facturation ? », « acceptedAnswer »: {« @type »: « Answer », « text »: « Le résultat autorisé dépend du profil implémenté et de ses exigences applicables. Ne présumez pas d’une solution de repli universelle. Établissez l’état de fonctionnement attendu avant le test, puis capturez ensemble le résultat de l’authentification et la réponse de transfert réelle. Si une opération réduite ou un refus est requis, vérifier ce comportement et la récupération ultérieure. Une session qui continue à se charger n’est qu’une observation jusqu’à ce qu’elle soit comparée à la règle correcte pour cette configuration. »}}, {« @type »: « Question », « name »: « Les informations d’identification privées doivent-elles apparaître dans un rapport de test client ? », « acceptedAnswer »: {« @type »: « Answer », « text »: « Les rapports publics ou largement diffusés ne doivent pas divulguer de documents d’identification privés. Utilisez des références contrôlées et le canal autorisé approuvé pour les preuves d’approvisionnement sensibles. Le rapport peut toujours identifier l’artefact testé, la méthode, le résultat et l’enregistrement responsable sans publier de secrets. Accepter les exigences d’accès au laboratoire et aux clients dans le cadre du programme. Les preuves doivent étayer la portée de l’authentification indiquée tout en préservant les exigences de confidentialité convenues par le programme et le laboratoire responsable. »}}]}