Qi Specification version 2.0 - Part 9: Authentication Protocol

IEC 63563-9:2025 defines the architecture and application-level messaging for the Authentication of a Power Transmitter Product by a Power Receiver to ensure that the Power Transmitter Product is both Qi certified and the product of a registered manufacturer.

Spécification Qi version 2.0 - Partie 9 : Protocole d'authentification

IEC 63563-9:2025 définit l'architecture et la messagerie au niveau de l'application pour l'authentification d'un produit émetteur de puissance par un récepteur de puissance afin d'assurer que le produit émetteur de puissance est à la fois certifié Qi et le produit d'un fabricant enregistré.

General Information

Status
Published
Publication Date
13-Feb-2025
Drafting Committee
WG 1 - TC 100/TA 15/WG 1
Current Stage
PPUB - Publication issued
Start Date
14-Feb-2025
Completion Date
07-Mar-2025

Overview

IEC 63563-9:2025 - Qi Specification version 2.0: Part 9: Authentication Protocol defines the architecture and application‑level messaging used by a Power Receiver to authenticate a Power Transmitter Product. The goal is to confirm that the transmitter is both Qi certified and produced by a registered manufacturer. Published by IEC and based on the Wireless Power Consortium’s Qi v2.0 Authentication Protocol, this standard specifies certificate handling, message exchanges, timing, and support for revocation and caching.

Key topics and technical requirements

  • Authentication architecture: Defines roles, message flows and state machines for receiver–transmitter authentication.
  • Certificates and private keys: Requirements for X.509-style certificate chains, certificate slots, issuer/manufacturer certificates, and secure handling of private keys.
  • Certificate chain and digest operations: Procedures for requesting and validating certificate digests and full certificate chains.
  • Authentication protocol messages: Application‑level message formats (requests, responses, headers) used to perform digest queries, certificate reads, and cryptographic challenges.
  • Authentication challenge: Mechanisms for proving possession of private keys and binding certificates to devices via challenge/response exchanges.
  • Timing and performance: Specified timing requirements for Power Receiver and Power Transmitter implementations to ensure interoperable authentication flows.
  • Revocation and caching: Support for certificate revocation checks, caching strategies, and associated flows (e.g., caching with revocation).
  • Cryptographic guidance and examples: Informative examples covering certificate basics, dummy CA/product certificates, and example authentication sequences.
  • Compliance language: Mandatory (“shall”) vs. recommended/optional provisions per ISO/IEC directives.

Practical applications and who uses this standard

  • Device and accessory manufacturers (wireless chargers, charging pads) implement the protocol to achieve and demonstrate Qi certification and to prevent counterfeit or non‑certified transmitters.
  • Chipset and firmware developers integrate authentication messaging, certificate validation, and cryptographic challenge/response logic.
  • Security architects and compliance engineers use the standard to design secure key storage and certificate lifecycle processes.
  • Test laboratories and certification bodies use the specification to validate conformance to Qi v2.0 authentication requirements.
  • Ecosystem integrators and platform providers rely on the protocol to maintain a trusted wireless power ecosystem and protect user devices.

Related standards and references

  • Other parts of the Qi Specification (v2.0) series: Communications Protocol, Power Delivery, Foreign Object Detection, NFC Tag Protection, etc.
  • References and implementation details are available from the IEC webstore and the Wireless Power Consortium (WPC).

For implementation or certification work, consult the full IEC 63563-9:2025 text and associated Qi Specification documents for normative details, sample certificates, and cryptographic examples.

Buy Documents

Standard

IEC 63563-9:2025 - Qi Specification version 2.0 - Part 9: Authentication Protocol Released:2/14/2025 Isbn:9782832701928

English language (93 pages)
sale 15% off
Preview
sale 15% off
Preview
Standard

IEC 63563-9:2025 - Spécification Qi version 2.0 - Partie 9 : Protocole d'authentification Released:2/14/2025 Isbn:9782832705452

French language (97 pages)
sale 15% off
Preview
sale 15% off
Preview
Standard

IEC 63563-9:2025 - Qi Specification version 2.0 - Part 9: Authentication Protocol Released:2/14/2025 Isbn:9782832705452

English and French language (190 pages)
sale 15% off
Preview
sale 15% off
Preview

Get Certified

Connect with accredited certification bodies for this standard

BSI Group

BSI (British Standards Institution) is the business standards company that helps organizations make excellence a habit.

UKAS United Kingdom Verified

Intertek Testing Services NA Inc.

Intertek certification services in North America.

ANAB United States Verified

UL Solutions

Global safety science company with testing, inspection and certification.

ANAB United States Verified

Sponsored listings

Frequently Asked Questions

IEC 63563-9:2025 is a standard published by the International Electrotechnical Commission (IEC). Its full title is "Qi Specification version 2.0 - Part 9: Authentication Protocol". This standard covers: IEC 63563-9:2025 defines the architecture and application-level messaging for the Authentication of a Power Transmitter Product by a Power Receiver to ensure that the Power Transmitter Product is both Qi certified and the product of a registered manufacturer.

IEC 63563-9:2025 defines the architecture and application-level messaging for the Authentication of a Power Transmitter Product by a Power Receiver to ensure that the Power Transmitter Product is both Qi certified and the product of a registered manufacturer.

IEC 63563-9:2025 is classified under the following ICS (International Classification for Standards) categories: 29.240.99 - Other equipment related to power transmission and distribution networks; 35.240.99 - IT applications in other fields. The ICS classification helps identify the subject area and facilitates finding related standards.

IEC 63563-9:2025 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.

Standards Content (Sample)


IEC 63563-9 ®
Edition 1.0 2025-02
INTERNATIONAL
STANDARD
Qi Specification version 2.0 –
Part 9: Authentication Protocol

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - webstore.iec.ch/advsearchform IEC Products & Services Portal - products.iec.ch
The advanced search enables to find IEC publications by a Discover our powerful search engine and read freely all the
variety of criteria (reference number, text, technical publications previews, graphical symbols and the glossary.
committee, …). It also gives information on projects, replaced With a subscription you will always have access to up to date
and withdrawn publications. content tailored to your needs.

IEC Just Published - webstore.iec.ch/justpublished
Electropedia - www.electropedia.org
Stay up to date on all new IEC publications. Just Published
The world's leading online dictionary on electrotechnology,
details all new publications released. Available online and once
containing more than 22 500 terminological entries in English
a month by email.
and French, with equivalent terms in 25 additional languages.

Also known as the International Electrotechnical Vocabulary
IEC Customer Service Centre - webstore.iec.ch/csc
(IEV) online.
If you wish to give us your feedback on this publication or need

further assistance, please contact the Customer Service
Centre: sales@iec.ch.
IEC 63563-9 ®
Edition 1.0 2025-02
INTERNATIONAL
STANDARD
Qi Specification version 2.0 –

Part 9: Authentication Protocol

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 29.240.99; 35.240.99 ISBN 978-2-8327-0192-8

- 2 - IEC 63563-9:2025 © IEC 2025
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
QI SPECIFICATION VERSION 2.0 –
Part 9: Authentication Protocol
FOREWORD
 The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprisingall
national electrotechnical committees (IEC National Committees). The object of IEC is to promote internationalco-
operation on all questions concerning standardization in the electrical and electronic fields. To this end andin addition
to other activities, IEC publishes International Standards, Technical Specifications, TechnicalReports, Publicly
Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Theirpreparation is entrusted to
technical committees; any IEC National Committee interested in the subject dealt withmay participate in this
preparatory work. International, governmental and non-governmental organizationsliaising with the IEC also
participate in this preparation. IEC collaborates closely with the InternationalOrganization for Standardization
(ISO) in accordance with conditions determined by agreement between the twoorganizations.
 The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
 IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
 In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence betweenany IEC
Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
 IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
 All users should ensure that they have the latest edition of this publication.
 No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage orother
damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) andexpenses
arising out of the publication, use of, or reliance upon, this IEC Publication or any other IECPublications.
 Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
 IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights inrespect
thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s),which may be
required to implement this document. However, implementers are cautioned that this may notrepresent the latest
information, which may be obtained from the patent database available athttps://patents.iec.ch. IEC shall
not be held responsible for identifying any or all such patent rights.
IEC 635-9 has been prepared by technical area 15: Wireless Power Transfer, of IEC
technical committee 100: Audio, video and multimedia systems and equipment. It is an
International Standard.
It is based on Qi Specification version 2.0, Authentication Protocol and was submitted as a
Fast-Track document.
The text of this International Standard is based on the following documents:
Draft Report on voting
//FDIS //RVD
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this International Standard is English.
The structure and editorial rules used in this publication reflect the practice of the organization
which submitted it.
This document was developed in accordance with ISO/IEC Directives, Part 1 and ISO/IEC
Directives, IEC Supplement available at www.iec.ch/members_experts/refdocs. The main
document types developed by IEC are described in greater detail at www.iec.ch/publications.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
x reconfirmed,
x withdrawn, or
x revised.
- 4 - IEC 63563-9:2025 © IEC 2025
WIRELESS POWER
CONSORTIUM
Qi Specification
Authentication Protocol
Version 2.0
April 2023
DISCLAIMER
Theinformationcontainedhereinisbelievedtobeaccurateasofthedateofpublication,
butisprovided“asis”andmaycontainerrors.TheWirelessPowerConsortiummakesno
warranty,expressorimplied,withrespecttothisdocumentanditscontents,includingany
warrantyoftitle,ownership,merchantability,orfitnessforaparticularuseorpurpose.
NeithertheWirelessPowerConsortium,noranymemberoftheWirelessPower
Consortiumwillbeliableforerrorsinthisdocumentorforanydamages,includingindirect
orconsequential,fromuseoforrelianceontheaccuracyofthisdocument.For any further
explanation of the contents of this document, or in case of any perceived inconsistency or ambiguity
of interpretation, contact: info@wirelesspowerconsortium.com.
RELEASE HISTORY
Specification Version Release Date Description
v2.0 April 2023 Initial release of the v2.0 Qi Specification.

- 6 - IEC 63563-9:2025 © IEC 2025
Table of Contents
1  General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Structure of the Qi Specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Power Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Cryptographic methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Security overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Impact to existing ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Support for revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3  Certificates and private keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Certificate Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Certificate Chain slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Power Transmitter private keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Other private keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4  Authentication protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1 Digest query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Certificate Chain read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Authentication challenge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Errors and alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5  Authentication messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1 Authentication message header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2 Authentication requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3 Authentication responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6  Timing requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1 Power Receiver timing requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Power Transmitter timing requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7  Protocol flow examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1 Simple flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.2 Flow with caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.3 Flow with caching and revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.4 Challenge first flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8  Cryptographic examples (informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.1 X.509 Certificate basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.2 Dummy Root CA Certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.3 Manufacturer CA Certificate Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.4 Example Product Unit Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.5 Certificate Chain and digest of certificates example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.6 Authentication examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Annex A: Sample data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.1 Dummy Root CA Certificate in PEM format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.2 Dummy Root CA Certificate in ASN.1 parser output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.3 Manufacturer CA Certificate in PEM Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.4 Manufacturer CA Certificate in ASN.1 parser output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.5 Product Unit Certificate, example 1 in PEM format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.6 Product Unit Certificate, example 1 in ASN.1 parser output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.7 Product Unit Certificate, example 2 in PEM format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.8 Product Unit Certificate, example 2 in ASN.1 parser output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

- 8 - IEC 63563-9:2025 © IEC 2025
1 General
The Wireless Power Consortium (WPC) is a worldwide organization that aims to develop and
promote global standards for wireless power transfer in various application areas. A first
application area comprises flat-surface devices such as mobile phones and chargers in the
Baseline Power Profile (up to 5 W) and Extended Power Profile (above 5 W).
1.1 Structure of the Qi Specification
General documents
ƒ Introduction
ƒ Glossary, Acronyms, and Symbols
System description documents
ƒ Mechanical, Thermal, and User Interface
ƒ Power Delivery
ƒ Communications Physical Layer
ƒ Communications Protocol
ƒ Foreign Object Detection
ƒ NFC Tag Protection
ƒ Authentication Protocol
1.2 Scope
The QiSpecification,AuthenticationProtocol (this document) defines the architecture and
application-level messaging for the Authentication of a Power Transmitter Product by a Power
Receiver to ensure that the Power Transmitter Product is both Qi certified and the product of a
registered manufacturer.
1.3 Compliance
All provisions in the QiSpecification are mandatory, unless specifically indicated as recommended,
optional, note, example, or informative. Verbal expression of provisions in this Specification follow
the rules provided in ISO/IEC Directives, Part 2.
Table 1: Verbal forms for expressions of provisions
Provision Verbal form
requirement “shall” or “shall not”
recommendation “should” or “should not”
permission “may” or “may not”
capability “can” or “cannot”
1.4 References
For undated references, the most recently published document applies. The most recent WPC
publications can be downloaded from http://www.wirelesspowerconsortium.com.

- 10 - IEC 63563-9:2025 © IEC 2025
1.5 Conventions
1.5.1 Notation of numbers
ƒ Real numbers use the digits 0 to 9, a decimal point, and optionally an exponential part.
ƒ Integer numbers in decimal notation use the digits 0 to 9.
ƒ Integer numbers in hexadecimal notation use the hexadecimal digits 0 to 9 and A to F, and are
prefixed by "0x" unless explicitly indicated otherwise.
ƒ Single bit values use the words ZERO and ONE.
1.5.2 Tolerances
Unless indicated otherwise, all numeric values in the QiSpecification are exactly as specified and do
not have any implied tolerance.
1.5.3 Fields in a data packet
A numeric value stored in a field of a data packet uses a big-endian format. Bits that are more
significant are stored at a lower byte offset than bits that are less significant. Table 2 and Figure 1
provide examples of the interpretation of such fields.
Table 2: Example of fields in a data packet
b b b b b b b b
7 6 5 4 3 2 1 0
(msb)
B
16-bit Numeric Data Field
B
(lsb)
B Other Field (msb)
B 10-bit Numeric Data Field (lsb) Field
Figure 1. Examples of fields in a data packet
16-bit Numeric Data Field
b b b b b b b b b b b b b b b b
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
B B
0 1
10-bit Numeric Data Field
b b b b b b b b b b
9 8 7 6 5 4 3 2 1 0
B B
2 3
1.5.4 Notation of text strings
Text strings consist of a sequence of printable ASCII characters (i.e. in the range of 0x20 to 0x7E)
enclosed in double quotes ("). Text strings are stored in fields of data structures with the first
character of the string at the lowest byte offset, and are padded with ASCII NUL (0x00) characters
to the end of the field where necessary.
EXAMPLE: The text string “WPC” is stored in a six-byte fields as the sequence of characters 'W', 'P', 'C', NUL,
NUL, and NUL. The text string “M:4D3A” is stored in a six-byte field as the sequence 'M', ':', '4', 'D',
'3', and 'A'.
1.5.5 Short-hand notation for data packets
In many instances, the QiSpecification refers to a data packet using the following shorthand
notation:
/
In this notation, refers to the data packet's mnemonic defined in the QiSpecification,
CommunicationsProtocol, and refers to a particular value in a field of the data packet.
The definitions of the data packets in the QiSpecification,CommunicationsProtocol, list the
meanings of the modifiers.
For example, EPT/cc refers to an End Power Transfer data packet having its End Power Transfer
code field set to 0x01.
- 12 - IEC 63563-9:2025 © IEC 2025
1.6 Power Profiles
A Power Profile determines the level of compatibility between a Power Transmitter and a Power
Receiver. Table 3 defines the available Power Profiles.
ƒ BPPPTx: A Baseline Power Profile Power Transmitter.
ƒ EPP5PTx: An Extended Power Profile Power Transmitter having a restricted power transfer
()pot
capability, i.e. P = 5 W.
L
ƒ EPPPTx: An Extended Power Profile Power Transmitter.
ƒ BPPPRx: A Baseline Power Profile Power Receiver.
ƒ EPPPRx: An Extended Power Profile Power Receiver.
Table 3: Capabilities included in a Power Profile
Feature BPP PTx EPP5 PTx EPP PTx BPP PRx EPP PRx
Ax or Bx design Yes Yes No N/A N/A
MP-Ax or MP-Bx design No No Yes N/A N/A
Baseline Protocol Yes Yes Yes Yes Yes
Extended Protocol No Yes Yes No Yes
Authentication N/A Optional Yes N/A Optional

2 Overview
The QiSpecification,AuthenticationProtocol (this document) defines a protocol for a Power
Receiver to authenticate a Power Transmitter. In this context, Authentication is a tamper-resistant
method to establish and verify the identity of the Power Transmitter, enabling the Power Receiver
to trust the Power Transmitter to operate within the bounds of the QiSpecification. This
Authentication protocol version 1.0 makes use of Data Transport Streams between the Power
Receiver and Power Transmitter as defined in the QiSpecification,CommunicationsProtocol.
Authentication allows an organization to set and enforce a policy with regard to acceptable
products. This will permit useful security assurances in real world situations. For example, a mobile
phone manufacturer concerned about product damage or safety hazards resulting from
substandard wireless charging devices can set a policy limiting the power drawn from an untrusted
wireless charger.
This document aims to be closely aligned with the USB Authentication specification, particularly as
it is likely that products will exist in the market that support both.
In addition to this document, the WPCManufacturerAgreement covers legal and implementation
requirements, including secure storage and handling of secrets (Annex A) and revocation rules and
procedure (Annex B). For further information or to obtain a copy of this agreement, contact:
info@wirelesspowerconsortium.com.

- 14 - IEC 63563-9:2025 © IEC 2025
2.1 References
Unless specified otherwise, all standards specified, including those from ISO, ITU, and NIST refer to
the version or edition which is more recent, as of 1 January 2018.
ECDSA
ƒ ANSI X9.62-2005; Public Key Cryptography for the Financial Services Industry, The Elliptic
Curve Digital Signature Algorithm (ECDSA) (available at www.global.ihs.com or https://
www.techstreet.com)
ƒ NIST-FIPS-186-4, Digital Signature Standard (DSS), Section 6, Federal Information Processing
Standards Publication, July 2013 (available at: http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf)
ƒ ISO/IEC 14888-3 Digital signatures with appendix—Part 3: Discrete logarithm based
mechanisms (Clause 6.6)
NIST P-256, secp-256r1
ƒ NIST-FIPS-186-4, Digital Signature Standard (DSS), Appendix D: Recommended Elliptic Curves
for Federal Government Use, Federal Information Processing Standards Publication, July 2013
(available at: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
ƒ ISO/IEC 15946 Cryptographic techniques based on elliptic curves (NIST P-256 is included as
example)
NOTE: The ISO/IEC 15946 series treats elliptic curves differently from FIPS 186- 4. ISO/IEC 15946-5 is
about elliptic curve generation. That is, based on the method in part 5, each application and
implementation can generate its own curves to use. In other words, there are no ISO/IEC
recommended curves. P-256 is considered an example in ISO/IEC 15946. In addition, Elliptic
Curve signatures and key establishment schemes have been moved to ISO/IEC 14888 and ISO/
IEC 11770 respectively, together with other discrete-log based mechanisms. Test vectors
(examples) using P-256 are included for each of those mechanisms.
SEC 1
ƒ Certicom Corp., Standards for Efficient Cryptography Group (SECG), SEC 1: “Elliptic Curve
Cryptography,” Version 1.0, September 2000 (available at: https://www.secg.org/SEC1-Ver-
1.0.pdf)
SEC 2
ƒ Certicom Corp., Standards for Efficient Cryptography Group (SECG), SEC 2: “Recommended
Elliptic Curve Domain Parameters,” Version 2.0, January 2010 (available at: http://
www.secg.org/sec2-v2.pdf)
SHA-256
ƒ NIST-FIPS-180-4 (available at: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf)
ƒ ISO/IEC 10118-3 Hash-functions—Part 3: Dedicated hash-functions (Clause 10)
SP800-90A
ƒ NIST-SP-800-90A Revision 1 (available at: http://nvlpubs.nist.gov/nistpubs/
SpecialPublications/NIST.SP.800-90Ar1.pdf.)
SP800-90B
ƒ NIST-SP-800-90B (available at: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-90B.pdf)
USB Authentication
ƒ Universal Serial Bus Type-C™ Authentication Specification (available at http://www.usb.org/
developers/docs/ as part of the USB 3.2 Specification download package)
X.509
ƒ ITU-T-X.509, Information technology - Open Systems Interconnection - The Directory: Public-
key and attribute Certificate frameworks (available at: https://www.itu.int/rec/T-REC-X.509/
en)
ƒ ISO/IEC 9594-8, Information technology—Open Systems Interconnection—The
Directory—Part 8: The Directory: Public-key and attribute Certificate frameworks (available
at: https://www.iso.org/standard/80325.html)
ƒ IETF-RFC-5280: Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile
- 16 - IEC 63563-9:2025 © IEC 2025
2.2 Cryptographic methods
This specification targets a 128-bit security level for all cryptographic primitives. The
cryptographic methods used by this specification are shown in Table 5 (in Section 3.1).
2.2.1 Random number generators
The generation of cryptographic keys and the cryptographic protocol exchanges rely on
cryptographic quality random numbers. Random numbers are defined as numbers that are
distinguishable from random by no algorithm with an algorithmic complexity of less than O(2 ).
The output of a NIST SP800-90A-compliant PRNG seeded with a 256-bit full SP800-90B entropy
value is sufficient to meet this standard.
2.3 Security overview
Security of the Authentication protocol depends on the protection of private keys, and that
protection is supported by security evaluation.
2.3.1 Methodology
This specification defines a Certificate-based method for Authentication that allows a Power
Receiver to authenticate a Power Transmitter and, by policy, choose how to interact with that
Power Transmitter. For example, a Power Receiver may choose not to use the full advertised
capabilities of an unauthenticated Power Transmitter.
2.3.2 Periodic re-Authentication
The Power Receiver can optionally perform periodic re-Authentications to verify that an
authenticated Power Transmitter has not been replaced by a different one.
2.4 Impact to existing ecosystem
The impact to existing Power Transmitter Products depends largely on individual Policy decisions
regarding legacy Power Transmitters (i.e. Power Transmitters that predate this specification). For
example, a Power Receiver with a Policy that allows full functioning of legacy Power Transmitters
will have a minimal impact on the current ecosystem, while a Power Receiver with a Policy that
limits or refuses to use functionalities exposed by a legacy Power Transmitter will have a more
significant impact.
2.5 Support for revocation
If the Power Receiver supports Authentication functionality, then the Power Receiver should
support Revocation.
Revocation Lists are normally updated off line, e.g. as part of a software or firmware update or
during Product manufacturing. Manufacturers are not required to provide on-line maintenance of
Revocation Lists or to make Revocation Lists field-updatable in their Products, however, the Power
Receiver should frequently update its revocation list and not only during firmware updates. For
some Power Receiver Products with Internet connectivity (e.g. smartphones), frequent Revocation
List updates should be relatively easy. Other Power Receiver Products without direct Internet
connectivity, such as fitness trackers, may not be able to update their Revocation List as frequently,
but manufacturers should consider ways to keep the Revocation List current in their product
designs.
NOTE: Support for updatable Revocation Lists implies field-updatable non-volatile memory.
NOTE: The WPC Authentication License Administrator (WPC-ALA) will issue Revocation Lists from time to
time. The format of Revocation Lists and how they are communicated is outside the scope of this
specification.
- 18 - IEC 63563-9:2025 © IEC 2025
3 Certificates and private keys
3.1 Certificate Chains
The requirements in this section apply to Certificate Chains that are populated in slots 0 and 1. The
Power Transmitter Product manufacturer determines the requirements for Certificates that are
populated in slots 2 and 3. For further information about slots, see Section 3.3, CertificateChain
slots.
A Certificate Chain consists of three Certificates; see Table 4. The first Certificate in the chain is the
Root Certificate identifying the WPC Root Certificate Authority. It is a self-signed Certificate (i.e.
signed by the WPC Root Certificate Authority). As an optimization, the Certificate Chain contains a
hash of the Root Certificate rather than the Root Certificate itself. The second Certificate is a
Manufacturer CA Certificate identifying the product's manufacturer. It is signed by the WPC Root
Certificate Authority. The last Certificate in the chain is a Product Unit Certificate identifying the
individual Power Transmitter product. It is signed by the Manufacturer Certificate Authority.
In addition to identification data, the Manufacturer CA Certificate contains a public key for verifying
the authenticity of the Product Unit Certificate. The Product Unit Certificate contains a public key
for verifying the authenticity of the Power Transmitter Product Unit. See Section 4, Authentication
protocol, for details.
The following requirements apply to the Certificates in a Certificate Chain.
ƒ Each Product Unit Certificate shall identify a unique Power Transmitter Product Unit by using,
for example, the product unit's RSID number (wpc-qi-rsid).
ƒ Each Power Transmitter Product Unit shall have a unique public key.
ƒ Product Unit Certificates contained in different slots of the same Power Transmitter Product
Unit may contain the same identity and public key, provided that this does not introduce a
security vulnerability.
ƒ A manufacturer may have multiple Manufacturer CA Certificates to identify, for example,
different production facilities or product families. Each of these Manufacturer CA Certificates
shall contain a unique public key relating to a unique private key.
NOTE: Using multiple Manufacturer CA Certificates is encouraged to partition volumes of product units
to limit the collateral impact caused in the event that a Manufacturer CA Certificate is revoked
(collateral impact of revoking all product units signed by that Manufacturer CA Certificate).
ƒ A manufacturer shall use the private key associated with a Manufacturer CA Certificate to sign
Product Unit Certificates.
ƒ The WPC Root Certificate Authority shall ensure that all Manufacturer CA Certificates contain
unique public keys.
The Certificate Chains populated in slots 0 and 1 shall use X.509 Certificates. See Section 3.3,
CertificateChainslots, for further information about slots 0 and 1.
Table 4: Certificate Chain (X.509 Certificates)
b b b b b b b b
7 6 5 4 3 2 1 0
B .B msb
0 1
Length
lsb
B .B Root Certificate Hash (length N_RH)
2 (1+N_RH)
B .B
Manufacturer CA Certificate (length N_MC)
(2+N_RH) (1+N_RH+N_MC)
B .
(2+N_RH+N_MC)
Product Unit Certificate (length N_PUC)
B
(1+N_RH+N_MC+N_PUC)
Note: The Root Certificate is not included in the chain, only its hash is included in the chain.
Length The length is the total number of bytes in the Certificate Chain including the Length field.
RootCertificateHash A SHA-256 hash of the Root Certificate. The length of N_RH is 32 bytes.
See Section 2, Overview.
Manufacturer CA Certificate This Certificate identifies the manufacturer.
ProductUnitCertificate This Certificate identifies the individual product unit.

- 20 - IEC 63563-9:2025 © IEC 2025
3.2 Certificates
3.2.1 Format of Certificates
All Certificates shall use:
ƒ the X.509 v3 ASN.1 structure,
ƒ binary DER encoding for ASN.1, and
ƒ the cryptographic methods listed in Table 5.
Table 5: Summary of cryptographic methods
Method Use
X.509 v3, DER encoding Certificate format
ECDSA using the NIST P256, secp256r1 curve,
uncompressed point OR compressed point for- Digital signing of Certificates and Authentication
mat as specified by SEC1 (see Section 2, Over- Messages
view)
Hash algorithm, used in the ECDSA calculation
SHA-256 and in creating digests of Certificates and
Certificate Chains.
The further description of the Certificate format assumes that the reader is familiar with X.509 v3
Certificate terminology.
NOTE: Certificates and the fields, attributes, and extensions defined therein are Big Endian.
Product unit Certificates shall not exceed MaxProdCertSize in length. A Manufacturer CA Certificate
shall not exceed MaxManufacturerCertSize in length.
3.2.1.1 Textual format
All textual ASN.1 objects contained within X.509 Certificates, including DirectoryString,
GeneralName, and DisplayText, shall be specified as a UTF8String. The length of any textual object
shall not exceed 64 bytes excluding the DER type and DER length encoding.
3.2.1.2 Attributes and Extensions
Where applicable, the Object Identifier (OID) is provided.
Basic Constraints (OID 2.5.29.19)
Manufacturer CA Certificates contain this extension. (The extension is marked as critical, its cA
component is set to true, and its pathLenConstraint component set to zero). Product Unit
Certificates do not contain this extension.

Validity
The notBefore and notAfter fields indicate the time interval during which information regarding a
Certificate's validity is maintained. For Product Units, the validity times should be ignored.
Certificate notBefore and notAfter validity times shall be specified using ASN.1 GeneralizedTime
for any year, or ASN.1 UTCTime for years prior to 2050.
For a Manufacturer CA Certificate it is recommended that the notBefore field be
"19700101000000Z" (for 00:00 on 01-Jan-1970 UTC, which is POSIX epoch time). It is
recommended that the notAfter field be "99991231235959Z" (for 23:59:59 on 31-Dec-9999 UTC,
which is used for an unknown expiration time as defined in IETF-RFC-5280, Section 4.1.2.5). Use of
the recommended notBefore and notAfter values will maximize compatibility with Certificate
processing stacks.
Qi policy extension (wpc-qi-policy)
The WPC Qi policy extension is a custom Manufacturer CA Certificate extension for use with
products compliant to this specification. The value is a binary object and is reserved in this version
of the specification. The value of wpc-qi-policy is listed on The Qi Specifications page of the WPC
members’ website.
The binary object is encoded as an ASN.1 DER OCTET STRING with a fixed size of QiPolicySize
bytes.
Manufacturer CA Certificates shall contain this extension. Product Unit Certificates shall not
contain this extension.
Qi RSID extension (wpc-qi-rsid)
The WPC Qi revocation sequential identifier (RSID) extension is a custom Product Unit Certificate
extension for use with products compliant to this specification. The value is a binary object and is
provided to store a sequential identifier unique to each product unit that enables range-based
revocation of batches. The value of wpc-qi-rsid is listed on The Qi Specifications page of the WPC
members’ website.
The binary object is DER encoded as an ASN.1 OCTET STRING with a maximum size of
MaxQiRSIDSize bytes. The RSID value is unique to each product unit, from a minimum of 1 up to
MaxQiRSIDSize bytes.
Product Unit Certificates shall contain this extension. Manufacturer CA Certificates shall not
contain this extension.
- 22 - IEC 63563-9:2025 © IEC 2025
ASN.1 schema for WPC Object identifiers
The ASN.1 module below defines the WPC administered object identifiers and the schema for the
certificate extensions used for WPC Qi authentication.
-- WPC OID allocation
wpc INTEGER ::= 148
id-wpc OBJECT IDENTIFIER
::= {joint-iso-ccitt(2) international-organizations(23) wpc}
-- Qi Authentication certificate extensions
qiAuth INTEGER ::= 1
id-wpc-qiAuth OBJECT IDENTIFIER ::= {id-wpc qiAuth}
policy INTEGER ::= 1
id-wpc-qiAuth-policy OBJECT IDENTIFIER ::= {id-wpc-qiAuth policy}
rsid INTEGER ::= 2
id-wpc-qiAuth-rsid OBJECT IDENTIFIER ::= {id-wpc-qiAuth rsid}
-- WPC Qi Authentication size constants
wpcQiAuthPolicySize INTEGER ::= 4
wpcQiAuthRsidMaxSize INTEGER ::= 9
-- WPC Qi Authentication certificate extension schema
policy ::= OCTET STRING (SIZE (wpcQiAuthPolicySize))
rsid ::= OCTET STRING (SIZE (1…wpcQiAuthRsidMaxSize))
3.2.1.3 Manufacturer CA Certificate
A Manufacturer CA Certificate uses the ASN.1 structure defined in Rec. ITU-T X.509 (10/2016),
Section 7.2 Public-Key Certificate.
The TBSCertificate component of a Manufacturer CA Certificate only implements the ASN.1 fields
shown in Table 6.
Table 6: Certificate profile for a Manufacturer CA Certificate
Field OID Data type Value Example
Version INTEGER 0x02 {=X.509v3} 0x02
SerialNumber INTEGER A unique 1- to 72-bit 0x01 10 20 30 40 50
positive integer value 60 70
Note: The maximum length of 9 bytes refers to the “baseband” original value, before
DER encoding. The encoded value can have an additional zero byte if the top bit of the
original value is set. Be aware that this can be 10 bytes after encoding.
signature 1.2.840.10045.4.3.2 N/A
{ecdsa-with-SHA256}
issuer 2.5.4.3 UTF8String “WPCCA“+ one "WPCCA1"
{Common Name} character suffix
denoting different
root CA instances
validity.notBefor Either Any value 2000-01-01
e Generalized (not used by PRx) 00:00:00
Time for any
year, or
UTCTime for
years prior
to 2050
validity.notAfter Either Any value 9999-12-31
Generalized (not used by PRx) 23:59:59
Time for any
year, or
UTCTime for
years prior
to 2050
subject 2.5.4.3 UTF8String 7 byte string “CACA-1A”
{Common Name} consisting of:
ƒ four upper-case
characters
containing a PTMC
hex value
ƒ one character
containing a dash
ƒ two arbitrary
alpha-numeric
characters
TBSCertificate
- 24 - IEC 63563-9:2025 © IEC 2025
Table 6: Certificate profile for a Manufacturer CA Certificate (Continued)
Field OID Data type Value Example
subjectPublicKey 1.2.840.10045.2.1 N/A
Info.algorithm {ecPublicKey}
*
N/A
1.2.840.10045.3.1.7
{secp256r1}
subjectPublicKey BIT STRING (Public Key value; 0x04:64:68:34:24:4e
Info.subjectPubli optionally may use :1a:37:b2:f8:3a:d5:3
cKey compressed point 0:68:73:8a:65:9b:e2:

a6:d2:c6:f3:c9:3f:90:
representation)
5e:8c:7d:a3:59:79:2
7:6b:a7:fb:d4:30:83:
42:a9:90:a7:c1:92:90
:98:20:7d:90:77:f2:9
7:f3:f5:3a:77:25:01:3
c:55:44:19:e8:4a
Extensions.1 2.5.29.19 N/A
{basicConstraints}
Extensions.1. BOOLEAN TRUE TRUE
critical
Extensions.1. BOOLEAN TRUE TRUE
extnValue.cA
Extensions.1. INTEGER 0 0x00
extnValue.pathL
enConstraint
Extensions.2 2.23.148.1.1 N/A
{wpc-qiAuth-policy}
Extensions.2. BOOLEAN TRUE TRUE
critical
Extensions.2. OCTET 4 octets (bytes) re- 0x00 00 00 01
extnValue STRING served for future use
*
1.2.840.10045 refers to the named curve defined equivalently by three organizations as:
NIST (FIPS186-4): "P-256", SECG (SEC 2): "secp256r1", and IETF (RFC 3279): "prime256v1"

A Certificate verifier can unambiguously distinguish compressed from uncompressed point representations by
evaluating the value of the first byte (0x02 and 0x03 for compressed points and 0x04 for an uncompressed
point).
TBSCertificate
3.2.1.4 Product Unit Certificate
A Product Unit Certificate uses the ASN.1 structure defined in Rec. ITU-T X.509 (10/2016),
Section 7.2 Public-Key Certificate.
The TBSCertificate component of a Product Unit Certificate only implements the ASN.1 fields shown
in Table 7.
Table 7: Certificate profile for a Product Unit Certificate
Field OID Data Type Value Example
Version INTEGER 0x02 0x02
{=X.509v3}
serialNumber INTEGER 0x01 10 20 30 40 50 60
A unique 1- to 72-bit
positive integer value
Note: The maximum length of 9 bytes refers to the “baseband” original value,
before DER encoding. The encoded value can have an additional zero byte if the top
bit of the original value is set. Be aware that this can be 10 bytes after encoding.
signature 1.2.840.10045. N/A
4.3.2
{ecdsa-with-
SHA256}
issuer 2.5.4.3 UTF8String 7 bytes string "CACA-1A"
consisting of:
{Common
Name} ƒ Four upper-case
characters
containing a PTMC
hex value
ƒ one character
containing a dash
ƒ two arbitrary
alpha-numeric
characters
ƒ this matches
exactly byte-for-
byte the value from
the Manufacturer
CA Certificate
Subject common
name
validity.notBefo Either Should use the 2020-10-01 00:00:00
re Generalized current time when
Time for any issuing the Certificate
year, or (not used by PRx)
UTCTime for
years prior
to 2050
TBSCertificate
- 26 - IEC 63563-9:2025 © IEC 2025
Table 7: Certificate profile for a
...


IEC 63563-9 ®
Edition 1.0 2025-02
NORME
INTERNATIONALE
Spécification Qi version 2.0 -
Partie 9: Protocole d'authentification
ICS 29.240.99; 35.240.99 ISBN 978-2-8327-0545-2
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et
les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.
IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.
A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.
Recherche de publications IEC -  IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Découvrez notre puissant moteur de recherche et consultez
La recherche avancée permet de trouver des publications gratuitement tous les aperçus des publications, symboles
IEC en utilisant différents critères (numéro de référence, graphiques et le glossaire. Avec un abonnement, vous aurez
texte, comité d’études, …). Elle donne aussi des toujours accès à un contenu à jour adapté à vos besoins.
informations sur les projets et les publications remplacées
ou retirées. Electropedia - www.electropedia.org
Le premier dictionnaire d'électrotechnologie en ligne au
IEC Just Published - webstore.iec.ch/justpublished monde, avec plus de 22 500 articles terminologiques en
Restez informé sur les nouvelles publications IEC. Just anglais et en français, ainsi que les termes équivalents
Published détaille les nouvelles publications parues. dans 25 langues additionnelles. Egalement appelé
Disponible en ligne et une fois par mois par email. Vocabulaire Electrotechnique International (IEV) en ligne.
Service Clients - webstore.iec.ch/csc
Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-
nous: sales@iec.ch.
- 2 - IEC 63563-9:2025 © IEC 2025
COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE
____________
SPÉCIFICATION QI VERSION 2.0 –

Partie 9: Protocole d'authentification

AVANT-PROPOS
1) La Commission Electrotechnique Internationale (IEC) est une organisation mondiale de normalisation composée
de l'ensemble des comités électrotechniques nationaux (Comités nationaux de l'IEC). L'IEC a pour objet de
favoriser la coopération internationale pour toutes les questions de normalisation dans les domaines de
l'électricité et de l'électronique. À cet effet, l'IEC – entre autres activités – publie des Normes internationales, des
Spécifications techniques, des Rapports techniques, des Spécifications accessibles au public (PAS) et des Guides
(ci-après dénommés "Publication(s) de l'IEC"). Leur élaboration est confiée à des comités d'études, aux travaux
desquels tout Comité national intéressé par le sujet traité peut participer. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l'IEC, participent également aux travaux. L'IEC
collabore étroitement avec l'Organisation Internationale de Normalisation (ISO), selon des conditions fixées par
accord entre les deux organisations.
2) Les décisions ou accords officiels de l'IEC concernant les questions techniques représentent, dans la mesure du
possible, un accord international sur les sujets étudiés, étant donné que les Comités nationaux de l'IEC intéressés
sont représentés dans chaque comité d'études.
3) Les Publications de l'IEC se présentent sous la forme de recommandations internationales et sont agréées comme
telles par les Comités nationaux de l'IEC. Tous les efforts raisonnables sont entrepris afin que l'IEC s'assure de
l'exactitude du contenu technique de ses publications; l'IEC ne peut pas être tenue responsable de l'éventuelle
mauvaise utilisation ou interprétation qui en est faite par un quelconque utilisateur final.
4) Dans le but d'encourager l'uniformité internationale, les Comités nationaux de l'IEC s'engagent, dans toute la
mesure possible, à appliquer de façon transparente les Publications de l'IEC dans leurs publications nationales et
régionales. Toutes divergences entre toutes Publications de l'IEC et toutes publications nationales ou régionales
correspondantes doivent être indiquées en termes clairs dans ces dernières.
5) L'IEC elle-même ne fournit aucune attestation de conformité. Des organismes de certification indépendants
fournissent des services d'évaluation de conformité et, dans certains secteurs, accèdent aux marques de
conformité de l'IEC. L'IEC n'est responsable d'aucun des services effectués par les organismes de certification
indépendants.
6) Tous les utilisateurs doivent s'assurer qu'ils sont en possession de la dernière édition de cette publication.
7) Aucune responsabilité ne doit être imputée à l'IEC, à ses administrateurs, employés, auxiliaires ou mandataires, y
compris ses experts particuliers et les membres de ses comités d'études et des Comités nationaux de l'IEC, pour
tout préjudice causé en cas de dommages corporels et matériels, ou de tout autre dommage de quelque nature
que ce soit, directe ou indirecte, ou pour supporter les coûts (y compris les frais de justice) et les dépenses
découlant de la publication ou de l'utilisation de cette Publication de l'IEC ou de toute autre Publication de l'IEC,
ou au crédit qui lui est accordé.
8) L'attention est attirée sur les références normatives citées dans cette publication. L'utilisation de publications
référencées est obligatoire pour une application correcte de la présente publication.
9) L'IEC attire l'attention sur le fait que la mise en application du présent document peut entraîner l'utilisation d'un ou
de plusieurs brevets. L'IEC ne prend pas position quant à la preuve, à la validité et à l'applicabilité de tout droit de
brevet revendiqué à cet égard. À la date de publication du présent document, l'IEC n'a pas reçu notification qu'un
ou plusieurs brevets pouvaient être nécessaires à sa mise en application. Toutefois, il y a lieu d'avertir les
responsables de la mise en application du présent document que des informations plus récentes sont susceptibles
de figurer dans la base de données de brevets, disponible à l'adresse https://patents.iec.ch. L'IEC ne saurait être
tenue pour responsable de ne pas avoir identifié tout ou partie de tels droits de propriété.
L'IEC 63563-9 a été établie par le Domaine Technique 15: Wireless Power Transfer, du comité
d'études de l’IEC 100: Systèmes et équipements audio, vidéo et multimédia. Il s'agit d'une
Norme internationale.
Il est basé sur la Spécification Qi version 2.0, Protocole d'authentification et a été soumis en
tant que document Fast-Track.
La présente version bilingue (2025-07) correspond à la version anglaise monolingue publiée en
2025-02.
La version française de cette norme n'a pas été soumise au vote.

La langue employée pour l'élaboration de cette Norme internationale est l'anglais.
La structure et les règles éditoriales utilisées dans cette publication reflètent la pratique de
l'organisation qui l'a soumise.
Ce document a été rédigé selon les Directives ISO/IEC, Partie 2, il a été développé selon les
Directives ISO/IEC, Partie 1 et les Directives ISO/IEC, Supplément IEC, disponibles sous
www.iec.ch/members_experts/refdocs. Les principaux types de documents développés par l'IEC
sont décrits plus en détail sous www.iec.ch/publications/.
Le comité a décidé que le contenu de ce document ne sera pas modifié avant la date de
stabilité indiquée sur le site web de l'IEC sous webstore.iec.ch dans les données relatives au
document recherché. À cette date, le document sera
x reconduit,
x supprimé, ou
x révisé.
- 4 - IEC 63563-9:2025 © IEC 2025
WIRELESS POWER
CONSORTIUM
Spécification Qi
Protocole d'authentification
Version 2.0
avril 2023
CLAUSE DE NON-RESPONSABILITÉ
Les informations contenues dans le présent document sont considérées comme exactes à
la date de publication, mais elles sont fournies "en l'état" et peuvent contenir des erreurs.
Le Wireless Power Consortium ne donne aucune garantie, expresse ou implicite,
concernant le présent document et son contenu, y compris toute garantie de titre, de
propriété, de qualité marchande ou d'adéquation à une utilisation ou un objectif
particulier. Ni le Wireless Power Consortium, ni aucun membre du Wireless Power
Consortium ne pourra être tenu responsable des erreurs contenues dans le présent
document ou des dommages, y compris indirects ou consécutifs, résultant de l'utilisation
ou de la confiance accordée à la justesse du présent document. Pour toute explication
complémentaire sur le contenu du présent document, ou en cas d'incohérence ou d'ambiguïté
d'interprétation perçue, contactez : info@wirelesspowerconsortium.com.

HISTORIQUE DE LA PUBLICATION
Version de la spécification Date de sortie Description
v2.0 avril 2023 Publication initiale de la spécification Qi v2.0.

- 6 - IEC 63563-9:2025 © IEC 2025
Table des matières
1 Général . 8
1.1 Structure du Qi Spécification . 8
1.2 Domaine d'application. 9
1.3 Conformité . 9
1.4 Références . 9
1.5 Conventions . 10
1.6 Power Profiles . 12
2 Vue d'ensemble . 13
2.1 Références . 14
2.2 Cryptographique méthodes. . 16
2.3 Aperçu de la sécurité . 16
2.4 Impact sur l'écosystème existant . . 16
2.5 Soutien à la révocation . 17
3 Certificats et clés privées . 18
3.1 Chaînes de certificats . 18
3.2 Certificats . 20
3.3 Créneaux de la chaîne de certificats . 30
3.4 Emetteur de puissance privé touches . 31
3.5 Autres clés privées. 31
4 Protocole d'authentification . 32
4.1 Requête digest . 32
4.2 Lecture de la chaîne de certificats . 32
4.3 Défi d'authentification . 33
4.4 Erreurs et alertes . 33
5 Messages d’authentification . 34
5.1 En-tête du message d'authentification . 35
5.2 Demandes d'authentification . 36
5.3 Réponses d'authentification . 39
6 Temporisation exigences. . 44
6.1 Calage du récepteur d'alimentation exigences. . 44
6.2 Calage du transmetteur de puissance exigences. . 45
7 Exemples de flux de protocoles . 46
7.1 Flux simple. 46

7.2 Flux avec cache . 48
7.3 Flux avec cache et révocation . 50
7.4 Défi premier flux . 52
8 Exemples cryptographiques (informatif) . 55
8.1 X.509 Certificate basics . 55
8.2 A CA racine fictive Certificat . 56
8.3 Exemple de certificat de l'autorité de certification du fabricant . 59
8.4 Exemple d'unité de produit Certificats . 62
8.5 Chaîne de certificats et condensé de certificats exemple. . 68
8.6 Exemples d'authentification . 71
Annexe A : Échantillon données. . 86
A.1 Certificat Root CA factice en PEM format . 86
A.2 Certificat d'AC racine factice dans l'analyseur ASN.1 sortie . 87
A.3 Certificat de l'autorité de certification du fabricant en PEM Format . 89
A.4 Certificat de l'autorité de certification du fabricant dans l'analyseur ASN.1 output . 90
A.5 Certificat d'unité de produit, exemple 1 en PEM format . 92
A.6 Certificat d'unité de produit, exemple 1 dans l'analyseur ASN.1 sortie . 93
A.7 Certificat d'unité de produit, exemple 2 en PEM format . 95
A.8 Certificat d'unité de produit, exemple 2 dans l'analyseur ASN.1 output . 96

- 8 - IEC 63563-9:2025 © IEC 2025
1 Général
Le Wireless Power Consortium (WPC) est une organisation mondiale qui vise à développer et
à promouvoir des normes mondiales pour le transfert d'énergie sans fil dans divers domaines
d'application. Un premier domaine d'application comprend les appareils à surface plane tels
que les téléphones mobiles et les chargeurs dans le profil de puissance de base (jusqu'à 5 W)
et le profil de puissance étendu (plus de 5 W).

1.1 Structure du Qi Spécification
Documents généraux
Ŷ Introduction
Ŷ Glossaire, acronymes et symboles

Documents de description du système
Ŷ Mécanique, thermique et interface usager [domaine des transports].
Ŷ Fourniture d'énergie
Ŷ Couche physique des communications
Ŷ Protocole de communication
Ŷ Détection des objets étrangers
Ŷ Protection des étiquettes NFC
Ŷ Protocole d'authentification

1.2 Domaine d'application
La Spécification Qi, Protocole d'authentification (le présent document) définit l'architecture et
la messagerie au niveau de l'application pour l'authentification d'un produit émetteur de
puissance par un récepteur de puissance afin d'assurer que le produit émetteur de puissance
est à la fois certifié Qi et le produit d'un fabricant enregistré.

1.3 Conformité
Toutes les dispositions de la Spécification Qi sont obligatoires, à moins qu'il ne soit
spécifiquement indiqué qu'elles sont recommandées, facultatives, qu'il s'agit d'une note, d'un
exemple ou d'une information. L'expression verbale des dispositions de la présente Disposition
suit les règles prévues dans les Directives ISO/CEI, Partie 2.
Tableau 1 : Formes verbales pour l'expression des dispositions

Disposition Forme verbale
Exigence "doit" ou "ne doit pas"
Recommandation "doit" ou "ne doit pas".
autorisation "peut" ou "ne peut pas".
capacité "peut" ou "ne peut pas".

1.4 Références
Pour les références non datées, le document publié le plus récent s'applique. Les publications les
plus récentes du CMP peuvent être téléchargées à partir de
http://www.wirelesspowerconsortium.com.

- 10 - IEC 63563-9:2025 © IEC 2025
1.5 Conventions
1.5.1 Notation des nombres
Ŷ Les nombres réels utilisent les chiffres de 0 à 9, une virgule et éventuellement une partie
exponentielle.
Ŷ Les nombres entiers en notation décimale utilisent les chiffres de 0 à 9.
Ŷ Les nombres entiers en notation hexadécimale utilisent les chiffres hexadécimaux de 0 à 9 et
de A à F, et sont précédés de "0x", sauf indication contraire explicite.
Ŷ Les valeurs à un seul bit utilisent les mots ZERO et ONE.

1.5.2 Tolérances
Sauf indication contraire, toutes les valeurs numériques dans la Spécification Qi sont exactement
telles que spécifiées et ne comportent aucune tolérance implicite.

1.5.3 Champs d'un paquet de données
Une valeur numérique stockée dans un champ d'un paquet de données utilise un format big-
endian. Les bits les plus significatifs sont stockés à un décalage d'octet inférieur à celui des bits les
moins significatifs. Tableau 2 et Figure 1 fournissent des exemples d'interprétation de tels champs.
Tableau 2 : Exemple de champs dans un paquet de données

b b b b b b b b
7 6 5 4 3 2 1 0
(msb)
B
Champ de données
B
numériques de 16 bits
(lsb)
B Autre domaine (msb)
B Champ de données numériques de 10 bits (lsb) Champ
d'application
Figure 1. Exemples de champs dans un paquet de données

Anglais Français
16-bit Numeric Data field Champ de données numériques de 16 bits
10-bit Numeric Data field Champ de données numériques de 10 bits

1.5.4 Notation des chaînes de texte
Les chaînes de texte consistent en une séquence de caractères ASCII imprimables (c'est-à-dire
compris entre 0x20 et 0x7E) entre guillemets ("). Les chaînes de texte sont stockées dans les
champs des structures de données, le premier caractère de la chaîne se trouvant à l'octet de
décalage le plus bas, et sont complétées par des caractères ASCII NUL (0x00) jusqu'à la fin du
champ, si nécessaire.
EXEMPLE : La chaîne de texte "WPC" est stockée dans une zone de six octets sous la forme d'une séquence
de caractères "W", "P", "C", NUL, NUL et NUL. La chaîne de texte "M:4D3A" est enregistrée dans
un champ de six octets sous la forme de la séquence "M", " :", "4", "D", "3" et "A".

1.5.5 Notation abrégée pour les paquets de données
Dans de nombreux cas, la Spécification Qi fait référence à un paquet de données en utilisant la
notation abrégée suivante :
/
Dans cette notation,fait référence au mnémonique du paquet de données défini
dans la Spécification Qi, Protocole de communication, etfait référence à une valeur
particulière dans un champ du paquet de données. Les définitions des paquets de données dans
la Spécification Qi, Protocole de communication, énumèrent les significations des modificateurs.
Par exemple, EPT/cc désigne un paquet de données de fin de transfert de puissance dont le champ
de code de fin de transfert de puissance est réglé sur 0x01.

- 12 - IEC 63563-9:2025 © IEC 2025
1.6 Power Profiles
Un profil de puissance détermine le niveau de compatibilité entre un émetteur de puissance et
un récepteur de puissance. Tableau 3 définit les profils de puissance disponibles.
Ŷ BPP PTx: Un émetteur de puissance à profil de puissance de base.
Ŷ EPP5 PTx: Un émetteur de puissance à profil de puissance étendu ayant une capacité de
pot
transfert de puissance restreinte, c'est-à-dire P = 5 W.
L
Ŷ EPP PTx: Un émetteur de puissance à profil de puissance étendu.
Ŷ BPP PRx: Un profil de puissance de base Récepteur de puissance.
Ŷ EPP PRx: Un récepteur de puissance à profil de puissance étendu.
Tableau 3 : Capacités incluses dans un profil de puissance
Le phénomène BPP PTx EPP5 PTx EPP PTx BPP PRx EPP PRx
Ax ou Bx design Oui Oui Non N/A N/A
MP-Ax ou MP-Bx design Non Non Oui N/A N/A
Protocole de base Oui Oui Oui Oui Oui
Protocole étendu Non Oui Oui Non Oui
Authentification N/A En option Oui N/A En option

2 Vue d'ensemble
La Spécification Qi, Protocole d'authentification (le présent document) définit un protocole
permettant à un récepteur de puissance d'authentifier un émetteur de puissance. Dans ce
contexte, l'authentification est une méthode inviolable pour établir et vérifier l'identité de
l'émetteur de puissance, permettant au récepteur de puissance de faire confiance à l'émetteur de
puissance pour fonctionner dans les limites de la spécification Qi. Ce protocole d'authentification
version 1.0 utilise les flux de transport de données entre le récepteur de puissance et l'émetteur
de puissance tels que définis dans la Spécification Qi, Protocole de communication.
L'authentification permet à une organisation de définir et d'appliquer une politique concernant les
produits acceptables. Cela permettra d'obtenir des garanties de sécurité utiles dans des situations
réelles. Par exemple, un fabricant de téléphones mobiles préoccupé par les dommages au produit
ou les limites de sécurité résultant de dispositifs de chargement sans fil non conformes aux normes
peut établir une politique limitant la puissance tirée d'un chargeur sans fil non fiable.
Le présent document vise à s'aligner étroitement sur la spécification relative à l'authentification
USB, d'autant plus qu'il est probable qu'il existe sur le marché des produits prenant en charge les
deux types de spécification.
Outre ce document, le WPC Manufacturer Agreement couvre les exigences juridiques et de mise en
œuvre, notamment le stockage et le traitement sécurisés des secrets (Annexe A) ainsi que les
règles et la procédure de révocation (Annexe B). Pour de plus amples informations ou pour obtenir
une copie de cet accord, veuillez contacter : info@wirelesspowerconsortium.com.

- 14 - IEC 63563-9:2025 © IEC 2025
2.1 Références
Sauf indication contraire, toutes les normes spécifiées, y compris celles de l'ISO, de l'UIT et du
NIST, font référence à la version ou à l'édition la plus récente, au 1er janvier 2018.

ECDSA
Ŷ ANSI X9.62-2005 ; Public Key Cryptography for the Financial Services Industry, The
Elliptic Curve Digital Signature Algorithm (ECDSA) (disponible sur www.global.ihs.com or
https:// www.techstreet.com)
Ŷ NIST-FIPS-186-4, Norme de signature numérique (DSS), Section 6, Publication des normes
fédérales de traitement de l'information, juillet 2013 (disponible à l'adresse suivante :
http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf)
Ŷ ISO/IEC 14888-3 Signatures numériques avec annexe - Partie 3 : Mécanismes basés
sur le logarithme discret (Article 6.6)

NIST P-256, secp-256r1
Ŷ NIST-FIPS-186-4, Norme de signature numérique (DSS), Annexe D : Courbes elliptiques
recommandées pour l'utilisation par le gouvernement fédéral, Publication des normes
fédérales de traitement de l'information, juillet 2013 (disponible à l'adresse suivante :
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf).
Ŷ ISO/IEC 15946 Techniques cryptographiques basées sur les courbes elliptiques (NIST P-
256 est inclus comme exemple)
NOTE : La série ISO/IEC 15946 traite les courbes elliptiques différemment de la norme FIPS 186-4.
L'IEC 15946-5 porte sur la génération de courbes elliptiques. En d'autres termes, sur la base de
la méthode décrite dans la Partie 5, chaque application et mise en œuvre peut générer ses
propres courbes à utiliser. En d'autres termes, il n'existe pas de courbes recommandées par
l'ISO/CEI. P-256 est pris en considération dans la norme ISO/IEC 15946. En outre, les
signatures par courbes elliptiques et les systèmes d'établissement de clés ont été transférés
respectivement dans les normes ISO/IEC 14888 et ISO/IEC 11770, ainsi que d'autres
mécanismes basés sur le logarithme discret. Des vecteurs de test (exemples) utilisant le P-256
sont inclus pour chacun de ces mécanismes.
SEC 1
Ŷ Certicom Corp, Groupe des normes de cryptographie efficace (SECG), SEC 1 : "Elliptic Curve
Cryptography," Version 1.0, Septembre 2000 (disponible à l'adresse :
https://www.secg.org/SEC1-Ver- 1.0.pdf)

SEC 2
Ŷ Certicom Corp, Groupe des normes de cryptographie efficace (SECG), SEC 2 : "Paramètres
recommandés pour le domaine des courbes elliptiques", version 2.0, janvier 2010
(disponible à l'adresse suivante : http:// www.secg.org/sec2-v2.pdf)

SHA-256
Ŷ NIST-FIPS-180-4 (disponible à l'adresse suivante :
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf)
Ŷ ISO/IEC 10118-3 Fonctions de hachage-Partie 3 : Fonctions de hachage dédiées (Article 10)

SP800-90A
Ŷ NIST-SP-800-90A Revision 1 (disponible à :
http://nvlpubs.nist.gov/nistpubs/ SpecialPublications/NIST.SP.800-
90Ar1.pdf.).
SP800-90B
Ŷ NIST-SP-800-90B (disponible à l'adresse suivante :
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-90B.pdf)

Authentification USB
Ŷ Universal Serial Bus Type-C™ Authentication Specification (disponible sur
http://www.usb.org/ developers/docs/ en tant que partie du paquet de téléchargement de
la spécification USB 3.2).
X.509
Ŷ ITU-T-X.509, Technologies de l'information - Interconnexion des systèmes ouverts - Le
répertoire : Cadres de certificats de clés publiques et d'attributs (disponibles à l'adresse
suivante : https://www.itu.int/rec/T-REC-X.509/ en)
Ŷ ISO/IEC 9594-8, Technologies de l'information-Interconnexion des systèmes ouverts-
Répertoire-Partie 8 : L'annuaire : Cadres de certificats de clés publiques et d'attributs
(disponibles à l'adresse : https://www.iso.org/standard/80325.html).
Ŷ IETF-RFC-5280 : Profil du certificat d'infrastructure à clé publique X.509 et de la
liste de révocation de certificats (CRL) de l'internet

- 16 - IEC 63563-9:2025 © IEC 2025
2.2 Cryptographique méthodes.
Cette spécification vise un niveau de sécurité de 128 bits pour toutes les primitives
cryptographiques. Les méthodes cryptographiques utilisées par cette spécification sont
présentées dans Tableau 5 (dans la section 3.1).

2.2.1 Générateurs de nombres aléatoires
La génération de clés cryptographiques et les échanges de protocoles cryptographiques reposent
sur des nombres aléatoires de qualité cryptographique. Les nombres aléatoires sont définis comme
des nombres qui ne peuvent être distingués du hasard par aucun algorithme dont la complexité
algorithmique est inférieure à O(2 ).
La sortie d'un PRNG conforme à la norme NIST SP800-90A et ensemencé avec une valeur
d'entropie SP800-90B complète de 256 bits est suffisante pour satisfaire à cette Norme.

2.3 Aperçu de la sécurité
La sécurité du protocole d'authentification dépend de la protection des clés privées, et cette
protection est assurée par l'évaluation de la sécurité.

2.3.1 Méthodologie
Cette spécification définit une méthode d'authentification basée sur un certificat qui permet à
un récepteur de puissance d'authentifier un émetteur de puissance et, par politique, de choisir
comment interagir avec cet émetteur de puissance. Par exemple, un récepteur de puissance
peut choisir de ne pas utiliser toutes les capacités annoncées d'un émetteur de puissance non
authentifié.
2.3.2 Réauthentification périodique
Le récepteur de puissance peut éventuellement effectuer des réauthentifications périodiques pour
vérifier qu'un émetteur de puissance authentifié n'a pas été remplacé par un autre.

2.4 Impact sur l'écosystème existant .
L'impact sur les transmetteurs de puissance existants dépend largement des décisions politiques
individuelles concernant les anciens transmetteurs de puissance (c'est-à-dire les transmetteurs de
puissance antérieurs à cette spécification). Par exemple, un récepteur de puissance dont la
politique autorise le fonctionnement complet des émetteurs de puissance existants aura un impact
minimum sur l'écosystème actuel, tandis qu'un récepteur de puissance dont la politique limite ou
refuse l'utilisation des fonctionnalités exposées par un émetteur de puissance existant aura un
impact plus important.
2.5 Soutien à la révocation
Si le récepteur de puissance prend en charge la fonctionnalité d'authentification, il doit
prendre en charge la révocation.
Les listes de révocation sont normalement mises à jour hors ligne, par exemple dans le cadre d'une
mise à jour du logiciel ou du micrologiciel ou pendant la fabrication du produit. Les fabricants ne
sont pas tenus d'assurer la maintenance en ligne des listes de révocation ou de rendre les listes de
révocation modifiables sur le terrain dans leurs produits. Toutefois, le récepteur de puissance doit
fréquemment mettre à jour sa liste de révocation, et pas seulement lors des mises à jour du
micrologiciel. Pour certains récepteurs de puissance dotés d'une connexion Internet (par exemple,
les smartphones), les mises à jour fréquentes de la liste de révocation devraient être relativement
aisées. D'autres produits récepteurs d'énergie sans connexion directe à Internet, tels que les
trackers de fitness, peuvent ne pas être en mesure de mettre à jour leur liste de révocation aussi
fréquemment, mais les fabricants doivent prendre en considération les moyens de maintenir la
liste de révocation à jour dans la conception de leurs produits.
NOTE : La prise en charge des listes de révocation actualisables implique une mémoire non volatile
actualisable sur le terrain.
NOTE : L'administrateur de la licence d'authentification de la WPC (WPC-ALA) publiera de temps à autre des
listes de révocation. Le format des listes de révocation et la manière dont elles sont communiquées
n'entrent pas dans le champ d'application de la présente spécification.

- 18 - IEC 63563-9:2025 © IEC 2025
3 Certificats et clés privées
3.1 Chaînes de certificats
Les exigences de cette section s'appliquent aux chaînes de certificats qui sont insérées dans les
emplacements 0 et 1. Le fabricant du produit transmetteur de puissance détermine les exigences
relatives aux certificats qui sont installés dans les emplacements 2 et 3. Pour plus d'informations
sur les slots, voir Section 3.3, Lots de la chaîne de certificats.
Une chaîne de certificats est constituée de trois certificats ; voir Tableau 4. Le premier certificat de
la chaîne est le certificat racine qui identifie l'autorité de certification racine du WPC. Il s'agit d'un
certificat auto-signé (c'est-à-dire signé par l'autorité de certification racine de la WPC). Pour
optimiser les choses, la chaîne de certificats contient un hachage du certificat racine plutôt que le
certificat racine lui-même. Le deuxième certificat est un certificat de l'autorité de certification du
fabricant qui identifie le fabricant du produit. Il est signé par l'autorité de certification racine du
WPC. Le dernier certificat de la chaîne est un certificat d'unité de produit qui identifie le
transmetteur de puissance individuel. Il est signé par l'autorité de certification du fabricant.
Outre les données d'identification, le certificat de l'AC du fabricant contient une clé publique
permettant de vérifier l'authenticité du certificat de l'unité de produit. Le certificat d'unité de
produit contient une clé publique permettant de vérifier l'authenticité de l'unité de produit du
transmetteur de puissance. Voir Section 4, Protocole d'authentification, pour plus de détails.
Les exigences suivantes s'appliquent aux certificats d'une chaîne de certification.
Ŷ Chaque certificat d'unité de produit doit identifier une unité de produit de transmetteur de
puissance unique en utilisant, par exemple, le numéro RSID de l'unité de produit (wpc-qi-
rsid).
Ŷ Chaque unité de produit du transmetteur de puissance doit avoir une clé publique unique.
Ŷ Les certificats d'unité de produit contenus dans différents emplacements de la même unité
de produit du transmetteur de puissance peuvent contenir la même identité et la même clé
publique, à condition que cela n'introduise pas de faille de sécurité.
Ŷ Un fabricant peut avoir plusieurs certificats d'AC de fabricant pour identifier, par exemple,
différentes installations de production ou familles de produits. Chacun de ces certificats de
l'AC du fabricant doit contenir une clé publique unique liée à une clé privée unique.
NOTE : L'utilisation de plusieurs certificats d'AC de fabricant est encouragée pour partitionner les
volumes d'unités de produit afin de limiter l'impact collatéral causé en cas de révocation d'un
certificat d'AC de fabricant (impact collatéral de la révocation de toutes les unités de produit
signées par ce certificat d'AC de fabricant).
Ŷ Un fabricant doit utiliser la clé privée associée à un certificat d'AC de fabricant pour signer
les certificats d'unité de produit.
Ŷ L'autorité de certification racine du CMP doit s'assurer que tous les certificats de l'AC du
fabricant contiennent des clés publiques uniques.

Les chaînes de certificats figurant dans les emplacements 0 et 1 doivent utiliser des certificats
X.509. Voir Section 3.3,
Les emplacements de la chaîne de certificats, pour plus d'informations sur les emplacements 0 et 1.
Tableau 4 : Chaîne de certificats (certificats X.509)

b b b b b b b b
7 6 5 4 3 2 1 0
B .B msb
0 1
Longueur
lsb
B .B Hachage du certificat racine (longueur N_RH)
2 (1+N_RH)
B .B
Certificat de l'autorité de certification du fabricant
(2+N_RH) (1+N_RH+N_MC)
(longueur N_MC)
B .
(2+N_RH+N_MC)
Certificat d'unité de produit (longueur N_PUC)
B
(1+N_RH+N_MC+N_PUC)
Note : Le certificat racine n'est pas inclus dans la chaîne, seul son hachage est inclus dans la chaîne.
Longueur La longueur est le nombre total d'octets dans la chaîne de certificats, y compris le
champ Longueur. Root Certificate Hash A SHA-256 hash of the Root Certificate. La longueur de
N_RH est de 32 octets. See Section 2, Overview.
Certificat de l'autorité de certification du fabricant Ce certificat identifie le fabricant.
Certificat d'unité de produit Ce certificat identifie l'unité de produit individuelle.

- 20 - IEC 63563-9:2025 © IEC 2025
3.2 Certificats
3.2.1 Format des certificats
Tous les certificats doivent être utilisés :
Ŷ la structure ASN.1 de la norme X.509 v3,
Ŷ le codage binaire DER pour l'ASN.1, et
Ŷ les méthodes cryptographiques énumérées dans le tableau 5.
Tableau 5 : Résumé des méthodes cryptographiques

Méthode
Utilisation
X.509 v3, encodage DER Format du certificat
ECDSA utilisant la courbe NIST P256, secp256r1,
point non compressé OU point compressé for- Signature numérique des certificats et des
mat comme spécifié par SEC1 (voir Section 2, messages d'authentification
Vue d'ensemble).
Algorithme de hachage, utilisé dans le calcul
SHA-256 ECDSA et dans la création de condensés de
certificats et de chaînes de certificats.

La description du format des certificats suppose que le lecteur est familiarisé avec la terminologie
des certificats X.509 v3.
NOTE : Les certificats et les champs, attributs et extensions qui y sont définis sont des Big Endian.
La longueur des certificats d'unité de produit ne doit pas dépasser MaxProdCertSize. La longueur
d'un certificat d'AC de fabricant ne doit pas dépasser MaxManufacturerCertSize.

3.2.1.1 Format textuel
Tous les objets ASN.1 textuels contenus dans les certificats X.509, y compris DirectoryString,
GeneralName et DisplayText, doivent être spécifiés sous la forme d'une chaîne UTF8String. La
longueur de tout objet textuel ne doit pas dépasser 64 octets, à l'exclusion du type DER et du
codage de la longueur DER.
3.2.1.2 Attributs et extensions
Le cas échéant, l'identifiant de l'objet (OID) est fourni.

Contraintes de base (OID 2.5.29.19)
Les certificats de l'autorité de certification du fabricant contiennent cette extension. (L'extension
est marquée comme critique, sa composante cA est fixée à true et sa composante
pathLenConstraint est fixée à zero). Les certificats d'unité de produit ne contiennent pas cette
extension.
Validité
Les champs notBefore et notAfter indiquent l'intervalle de temps pendant lequel les informations
relatives à la validité d'un certificat sont conservées. Pour les unités de produit, les durées de
validité doivent être ignorées.
Les heures de validité des certificats notBefore et notAfter doivent être spécifiées en utilisant
ASN.1 GeneralizedTime pour n'importe quelle année, ou ASN.1 UTCTime pour les années
antérieures à 2050.
Pour un certificat d'AC de fabricant, il est recommandé que le champ notBefore soit
"19700101000000Z" (pour 00:00 le 01-Jan-1970 UTC, qui est l'heure d'origine POSIX). Il est
recommandé que le champ notAfter soit "99991231235959Z" (pour 23:59:59 on 31-Dec-9999
UTC, qui est utilisé pour un délai d'expiration inconnu tel que défini dans IETF-RFC-5280,
Section 4.1.2.5). L'utilisation des valeurs notBefore et notAfter recommandées maximisera la
compatibilité avec les piles de traitement des certificats.

Extension de la politique Qi (wpc-qi-policy)
L'extension de la politique WPC Qi est une extension de certificat d'AC de fabricant
personnalisée à utiliser avec les produits conformes à cette spécification. La valeur est un objet
binaire et est réservée dans cette version de la spécification. La valeur de wpc-qi-policy est listée
sur Les spécifications Qi page du site web des membres du WPC.
L'objet binaire est codé sous la forme d'une chaîne ASN.1 DER OCTET STRING d'une taille fixe
de QiPolicySize octets.
Les certificats de l'AC du fabricant doivent contenir cette extension. Les certificats d'unité de
produit ne doivent pas contenir cette extension.

Extension Qi RSID (wpc-qi-rsid)
L'extension WPC Qi revocation sequential identifier (RSID) est une extension de certificat d'unité
de produit personnalisée à utiliser avec les produits conformes à cette spécification. La valeur est
un objet binaire et est fournie pour stocker un identifiant séquentiel unique pour chaque unité de
produit qui permet la révocation des lots en fonction de la gamme. La valeur de wpc-qi-rsid est
indiquée sur Les spécifications Qi page du site web des membres du WPC.
L'objet binaire est codé en DER sous la forme d'une chaîne ASN.1 OCTET STRING d'une taille
maximale de MaxQiRSIDSize octets. La valeur RSID est unique pour chaque unité de produit,
d'un minimum de 1 jusqu'à MaxQiRSIDSize octets.
Les certificats d'unité de produit doivent contenir cette extension. Les certificats de l'AC du
fabricant ne doivent pas contenir cette extension.

- 22 - IEC 63563-9:2025 © IEC 2025
Schéma ASN.1 pour les identificateurs d'objets WPC
Le module ASN.1 ci-dessous définit les identificateurs d'objets administrés WPC et le schéma des
extensions de certificat utilisées pour l'authentification WPC Qi.

-- WPC OID allocation
wpc INTEGER ::= 148
id-wpc OBJECT IDENTIFIER
::= {joint-iso-ccitt(2) international-organizations(23) wpc}

-- Qi Authentication certificat extensions
qiAuth INTEGER ::= 1
id-wpc-qiAuth OBJECT IDENTIFIER ::= {id-wpc qiAuth}
politique INTEGER ::= 1
id-wpc-qiAuth-policy OBJECT IDENTIFIER ::= {id-wpc-qiAuth policy}
rsid INTEGER ::= 2
id-wpc-qiAuth-rsid OBJECT IDENTIFIER ::= {id-wpc-qiAuth rsid}

-- WPC Qi Authentication size constants
wpcQiAuthPolicySize INTEGER ::= 4
wpcQiAuthRsidMaxSize INTEGER ::= 9
-- WPC Qi Authentication certificate extension schema
policy ::= OCTET STRING (SIZE (wpcQiAuthPolicySize))
rsid ::= OCTET STRING (SIZE (1…wpcQiAuthRsidMaxSize))

3.2.1.3 Certificat de l'autorité de certification du fabricant
Un certificat d'AC de fabricant utilise la structure ASN.1 définie dans la Rec. ITU-T X.509
(10/2016), Section 7.2 Certificat de clé publique.
Le composant TBSCertificate d'un certificat d'AC de fabricant ne met en œuvre que les champs
ASN.1 indiqués dans Tableau 6.

Tableau 6 : Profil de certificat pour un certificat de l'autorité de certification d'un fabricant

Champ OID Type de données Valeur Exemple
d'application
Version INTEGER 0x02 {=X.509v3} 0x02

Numéro de série INTEGER Une valeur entière positive
0x01 10 20 30
unique de 1 à 72 bits 40 50
60 70
Note : La longueur maximale de 9 octets correspond à la valeur originale "en
bande de base", avant l'encodage DER. La valeur codée peut comporter un octet
supplémentaire de zéro si le bit de tête de la valeur originale est défini. Sachez
que cela peut représenter 10 octets après l'encodage.

signature N/A
1.2.840.1004
5.4.3.2
{ecdsa-with-
SHA256}
émetteur 2.5.4.3 UTF8String "WPCCA "+ un "WPCCA1
{nom suffixe de caractères
commun} désignant différentes
instances de l'autorité
de certification racine
validité.notBefore Soit le temps Toute valeur (non
2000-01-01
généralisé pour utilisée par PRx)
00:00:00
n'importe quelle
année, soit le
temps UTCT pour
les années
antérieures à
validité.notAfter Soit le temps Toute valeur (non 9999-12-31
généralisé pour utilisée par PRx) 23:59:59
n'importe quelle
année, soit le
temps UTCT pour
les années
antérieures à
sujet UTF8String "CACA-1A
2.5.4.3 Chaîne de 7 octets
{nom composée de :
commun}
Ŷ quatre caractères
majuscules contenant
une valeur hexagonale
PTMC
Ŷ un caractère contenant
un tiret
Ŷ deux caractères
alphanumériques
arbitraires
Certificat TBSC
- 24 - IEC 63563-9:2025 © IEC 2025
Tableau 6 : Profil de certificat pour un certificat d'autorité de certification de fabricant (suite)

Champ OID Type de Valeur Exemple
d'application données
subjectPublicKey 1.2.840.10045.2.1 N/A
Info.algorithm
{ecPublicKey}
*
N/A
1.2.840.10045.3.1.7
{secp256r1}
clé publique du CHAÎNE DE (Valeur de la clé 0x04:64:68:34:24:4e
sujet Clé BITS publique ; peut :1a:37:b2:f8:3a:d5:3
publique du 0:68:
...


IEC 63563-9 ®
Edition 1.0 2025-02
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
Qi Specification version 2.0 –
Part 9: Authentication Protocol

Spécification Qi version 2.0 –
Partie 9: Protocole d'authentification
ICS 29.240.99, 35.240.99  ISBN 978-2-8327-0545-2

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either
IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC copyright
or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local
IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et
les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
The advanced search enables to find IEC publications by a publications previews, graphical symbols and the glossary.
variety of criteria (reference number, text, technical With a subscription you will always have access to up to date
committee, …). It also gives information on projects, content tailored to your needs.

replaced and withdrawn publications.
Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
Also known as the International Electrotechnical Vocabulary
once a month by email.
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer
Service Centre: sales@iec.ch.
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.

Recherche de publications IEC -  IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Découvrez notre puissant moteur de recherche et consultez
La recherche avancée permet de trouver des publications gratuitement tous les aperçus des publications, symboles
IEC en utilisant différents critères (numéro de référence, graphiques et le glossaire. Avec un abonnement, vous aurez
texte, comité d’études, …). Elle donne aussi des toujours accès à un contenu à jour adapté à vos besoins.
informations sur les projets et les publications remplacées
ou retirées. Electropedia - www.electropedia.org
Le premier dictionnaire d'électrotechnologie en ligne au
IEC Just Published - webstore.iec.ch/justpublished monde, avec plus de 22 500 articles terminologiques en
Restez informé sur les nouvelles publications IEC. Just anglais et en français, ainsi que les termes équivalents
Published détaille les nouvelles publications parues. dans 25 langues additionnelles. Egalement appelé
Disponible en ligne et une fois par mois par email. Vocabulaire Electrotechnique International (IEV) en ligne.

Service Clients - webstore.iec.ch/csc
Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-
nous: sales@iec.ch.
IEC 63563-9 ®
Edition 1.0 2025-02
INTERNATIONAL
STANDARD
Qi Specification version 2.0 –

Part 9: Authentication Protocol

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 29.240.99; 35.240.99 ISBN 978-2-8327-0192-8

- 2 - IEC 63563-9:2025 © IEC 2025
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
QI SPECIFICATION VERSION 2.0 –
Part 9: Authentication Protocol
FOREWORD
 The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprisingall
national electrotechnical committees (IEC National Committees). The object of IEC is to promote internationalco-
operation on all questions concerning standardization in the electrical and electronic fields. To this end andin addition
to other activities, IEC publishes International Standards, Technical Specifications, TechnicalReports, Publicly
Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Theirpreparation is entrusted to
technical committees; any IEC National Committee interested in the subject dealt withmay participate in this
preparatory work. International, governmental and non-governmental organizationsliaising with the IEC also
participate in this preparation. IEC collaborates closely with the InternationalOrganization for Standardization
(ISO) in accordance with conditions determined by agreement between the twoorganizations.
 The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
 IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
 In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence betweenany IEC
Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
 IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
 All users should ensure that they have the latest edition of this publication.
 No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage orother
damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) andexpenses
arising out of the publication, use of, or reliance upon, this IEC Publication or any other IECPublications.
 Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
 IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights inrespect
thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s),which may be
required to implement this document. However, implementers are cautioned that this may notrepresent the latest
information, which may be obtained from the patent database available athttps://patents.iec.ch. IEC shall
not be held responsible for identifying any or all such patent rights.
IEC 635-9 has been prepared by technical area 15: Wireless Power Transfer, of IEC
technical committee 100: Audio, video and multimedia systems and equipment. It is an
International Standard.
It is based on Qi Specification version 2.0, Authentication Protocol and was submitted as a
Fast-Track document.
The text of this International Standard is based on the following documents:
Draft Report on voting
//FDIS //RVD
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this International Standard is English.
The structure and editorial rules used in this publication reflect the practice of the organization
which submitted it.
This document was developed in accordance with ISO/IEC Directives, Part 1 and ISO/IEC
Directives, IEC Supplement available at www.iec.ch/members_experts/refdocs. The main
document types developed by IEC are described in greater detail at www.iec.ch/publications.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
x reconfirmed,
x withdrawn, or
x revised.
 ,(&‹,(&
WIRELESS POWER
CONSORTIUM
Qi Specification
Authentication Protocol
Version 2.0
April 2023
,(&‹,(& 
DISCLAIMER
Theinformationcontainedhereinisbelievedtobeaccurateasofthedateofpublication,
butisprovided“asis”andmaycontainerrors.TheWirelessPowerConsortiummakesno
warranty,expressorimplied,withrespecttothisdocumentanditscontents,includingany
warrantyoftitle,ownership,merchantability,orfitnessforaparticularuseorpurpose.
NeithertheWirelessPowerConsortium,noranymemberoftheWirelessPower
Consortiumwillbeliableforerrorsinthisdocumentorforanydamages,includingindirect
orconsequential,fromuseoforrelianceontheaccuracyofthisdocument.For any further
explanation of the contents of this document, or in case of any perceived inconsistency or ambiguity
of interpretation, contact: info@wirelesspowerconsortium.com.
RELEASE HISTORY
Specification Version Release Date Description
v2.0 April 2023 Initial release of the v2.0 Qi Specification.

 ,(&‹,(&
Table of Contents
1  General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Structure of the Qi Specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Power Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Cryptographic methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Security overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Impact to existing ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Support for revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3  Certificates and private keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Certificate Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Certificate Chain slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Power Transmitter private keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Other private keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4  Authentication protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1 Digest query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Certificate Chain read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Authentication challenge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Errors and alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5  Authentication messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1 Authentication message header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2 Authentication requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3 Authentication responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6  Timing requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1 Power Receiver timing requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Power Transmitter timing requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7  Protocol flow examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1 Simple flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

,(&‹,(& 
7.2 Flow with caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.3 Flow with caching and revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.4 Challenge first flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8  Cryptographic examples (informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.1 X.509 Certificate basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.2 Dummy Root CA Certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.3 Manufacturer CA Certificate Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.4 Example Product Unit Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.5 Certificate Chain and digest of certificates example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.6 Authentication examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Annex A: Sample data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.1 Dummy Root CA Certificate in PEM format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.2 Dummy Root CA Certificate in ASN.1 parser output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.3 Manufacturer CA Certificate in PEM Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.4 Manufacturer CA Certificate in ASN.1 parser output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.5 Product Unit Certificate, example 1 in PEM format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.6 Product Unit Certificate, example 1 in ASN.1 parser output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.7 Product Unit Certificate, example 2 in PEM format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.8 Product Unit Certificate, example 2 in ASN.1 parser output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

 ,(&‹,(&
1 General
The Wireless Power Consortium (WPC) is a worldwide organization that aims to develop and
promote global standards for wireless power transfer in various application areas. A first
application area comprises flat-surface devices such as mobile phones and chargers in the
Baseline Power Profile (up to 5 W) and Extended Power Profile (above 5 W).
1.1 Structure of the Qi Specification
General documents
ƒ Introduction
ƒ Glossary, Acronyms, and Symbols
System description documents
ƒ Mechanical, Thermal, and User Interface
ƒ Power Delivery
ƒ Communications Physical Layer
ƒ Communications Protocol
ƒ Foreign Object Detection
ƒ NFC Tag Protection
ƒ Authentication Protocol
,(&‹,(& 
1.2 Scope
The QiSpecification,AuthenticationProtocol (this document) defines the architecture and
application-level messaging for the Authentication of a Power Transmitter Product by a Power
Receiver to ensure that the Power Transmitter Product is both Qi certified and the product of a
registered manufacturer.
1.3 Compliance
All provisions in the QiSpecification are mandatory, unless specifically indicated as recommended,
optional, note, example, or informative. Verbal expression of provisions in this Specification follow
the rules provided in ISO/IEC Directives, Part 2.
Table 1: Verbal forms for expressions of provisions
Provision Verbal form
requirement “shall” or “shall not”
recommendation “should” or “should not”
permission “may” or “may not”
capability “can” or “cannot”
1.4 References
For undated references, the most recently published document applies. The most recent WPC
publications can be downloaded from http://www.wirelesspowerconsortium.com.

 ,(&‹,(&
1.5 Conventions
1.5.1 Notation of numbers
ƒ Real numbers use the digits 0 to 9, a decimal point, and optionally an exponential part.
ƒ Integer numbers in decimal notation use the digits 0 to 9.
ƒ Integer numbers in hexadecimal notation use the hexadecimal digits 0 to 9 and A to F, and are
prefixed by "0x" unless explicitly indicated otherwise.
ƒ Single bit values use the words ZERO and ONE.
1.5.2 Tolerances
Unless indicated otherwise, all numeric values in the QiSpecification are exactly as specified and do
not have any implied tolerance.
1.5.3 Fields in a data packet
A numeric value stored in a field of a data packet uses a big-endian format. Bits that are more
significant are stored at a lower byte offset than bits that are less significant. Table 2 and Figure 1
provide examples of the interpretation of such fields.
Table 2: Example of fields in a data packet
b b b b b b b b
7 6 5 4 3 2 1 0
(msb)
B
16-bit Numeric Data Field
B
(lsb)
B Other Field (msb)
B 10-bit Numeric Data Field (lsb) Field
Figure 1. Examples of fields in a data packet
16-bit Numeric Data Field
b b b b b b b b b b b b b b b b
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
B B
0 1
10-bit Numeric Data Field
b b b b b b b b b b
9 8 7 6 5 4 3 2 1 0
B B
2 3
,(&‹,(& 
1.5.4 Notation of text strings
Text strings consist of a sequence of printable ASCII characters (i.e. in the range of 0x20 to 0x7E)
enclosed in double quotes ("). Text strings are stored in fields of data structures with the first
character of the string at the lowest byte offset, and are padded with ASCII NUL (0x00) characters
to the end of the field where necessary.
EXAMPLE: The text string “WPC” is stored in a six-byte fields as the sequence of characters 'W', 'P', 'C', NUL,
NUL, and NUL. The text string “M:4D3A” is stored in a six-byte field as the sequence 'M', ':', '4', 'D',
'3', and 'A'.
1.5.5 Short-hand notation for data packets
In many instances, the QiSpecification refers to a data packet using the following shorthand
notation:
/
In this notation, refers to the data packet's mnemonic defined in the QiSpecification,
CommunicationsProtocol, and refers to a particular value in a field of the data packet.
The definitions of the data packets in the QiSpecification,CommunicationsProtocol, list the
meanings of the modifiers.
For example, EPT/cc refers to an End Power Transfer data packet having its End Power Transfer
code field set to 0x01.
 ,(&‹,(&
1.6 Power Profiles
A Power Profile determines the level of compatibility between a Power Transmitter and a Power
Receiver. Table 3 defines the available Power Profiles.
ƒ BPPPTx: A Baseline Power Profile Power Transmitter.
ƒ EPP5PTx: An Extended Power Profile Power Transmitter having a restricted power transfer
()pot
capability, i.e. P = 5 W.
L
ƒ EPPPTx: An Extended Power Profile Power Transmitter.
ƒ BPPPRx: A Baseline Power Profile Power Receiver.
ƒ EPPPRx: An Extended Power Profile Power Receiver.
Table 3: Capabilities included in a Power Profile
Feature BPP PTx EPP5 PTx EPP PTx BPP PRx EPP PRx
Ax or Bx design Yes Yes No N/A N/A
MP-Ax or MP-Bx design No No Yes N/A N/A
Baseline Protocol Yes Yes Yes Yes Yes
Extended Protocol No Yes Yes No Yes
Authentication N/A Optional Yes N/A Optional

,(&‹,(& 
2 Overview
The QiSpecification,AuthenticationProtocol (this document) defines a protocol for a Power
Receiver to authenticate a Power Transmitter. In this context, Authentication is a tamper-resistant
method to establish and verify the identity of the Power Transmitter, enabling the Power Receiver
to trust the Power Transmitter to operate within the bounds of the QiSpecification. This
Authentication protocol version 1.0 makes use of Data Transport Streams between the Power
Receiver and Power Transmitter as defined in the QiSpecification,CommunicationsProtocol.
Authentication allows an organization to set and enforce a policy with regard to acceptable
products. This will permit useful security assurances in real world situations. For example, a mobile
phone manufacturer concerned about product damage or safety hazards resulting from
substandard wireless charging devices can set a policy limiting the power drawn from an untrusted
wireless charger.
This document aims to be closely aligned with the USB Authentication specification, particularly as
it is likely that products will exist in the market that support both.
In addition to this document, the WPCManufacturerAgreement covers legal and implementation
requirements, including secure storage and handling of secrets (Annex A) and revocation rules and
procedure (Annex B). For further information or to obtain a copy of this agreement, contact:
info@wirelesspowerconsortium.com.

 ,(&‹,(&
2.1 References
Unless specified otherwise, all standards specified, including those from ISO, ITU, and NIST refer to
the version or edition which is more recent, as of 1 January 2018.
ECDSA
ƒ ANSI X9.62-2005; Public Key Cryptography for the Financial Services Industry, The Elliptic
Curve Digital Signature Algorithm (ECDSA) (available at www.global.ihs.com or https://
www.techstreet.com)
ƒ NIST-FIPS-186-4, Digital Signature Standard (DSS), Section 6, Federal Information Processing
Standards Publication, July 2013 (available at: http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf)
ƒ ISO/IEC 14888-3 Digital signatures with appendix—Part 3: Discrete logarithm based
mechanisms (Clause 6.6)
NIST P-256, secp-256r1
ƒ NIST-FIPS-186-4, Digital Signature Standard (DSS), Appendix D: Recommended Elliptic Curves
for Federal Government Use, Federal Information Processing Standards Publication, July 2013
(available at: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
ƒ ISO/IEC 15946 Cryptographic techniques based on elliptic curves (NIST P-256 is included as
example)
NOTE: The ISO/IEC 15946 series treats elliptic curves differently from FIPS 186- 4. ISO/IEC 15946-5 is
about elliptic curve generation. That is, based on the method in part 5, each application and
implementation can generate its own curves to use. In other words, there are no ISO/IEC
recommended curves. P-256 is considered an example in ISO/IEC 15946. In addition, Elliptic
Curve signatures and key establishment schemes have been moved to ISO/IEC 14888 and ISO/
IEC 11770 respectively, together with other discrete-log based mechanisms. Test vectors
(examples) using P-256 are included for each of those mechanisms.
SEC 1
ƒ Certicom Corp., Standards for Efficient Cryptography Group (SECG), SEC 1: “Elliptic Curve
Cryptography,” Version 1.0, September 2000 (available at: https://www.secg.org/SEC1-Ver-
1.0.pdf)
SEC 2
ƒ Certicom Corp., Standards for Efficient Cryptography Group (SECG), SEC 2: “Recommended
Elliptic Curve Domain Parameters,” Version 2.0, January 2010 (available at: http://
www.secg.org/sec2-v2.pdf)
,(&‹,(& 
SHA-256
ƒ NIST-FIPS-180-4 (available at: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf)
ƒ ISO/IEC 10118-3 Hash-functions—Part 3: Dedicated hash-functions (Clause 10)
SP800-90A
ƒ NIST-SP-800-90A Revision 1 (available at: http://nvlpubs.nist.gov/nistpubs/
SpecialPublications/NIST.SP.800-90Ar1.pdf.)
SP800-90B
ƒ NIST-SP-800-90B (available at: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-90B.pdf)
USB Authentication
ƒ Universal Serial Bus Type-C™ Authentication Specification (available at http://www.usb.org/
developers/docs/ as part of the USB 3.2 Specification download package)
X.509
ƒ ITU-T-X.509, Information technology - Open Systems Interconnection - The Directory: Public-
key and attribute Certificate frameworks (available at: https://www.itu.int/rec/T-REC-X.509/
en)
ƒ ISO/IEC 9594-8, Information technology—Open Systems Interconnection—The
Directory—Part 8: The Directory: Public-key and attribute Certificate frameworks (available
at: https://www.iso.org/standard/80325.html)
ƒ IETF-RFC-5280: Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile
 ,(&‹,(&
2.2 Cryptographic methods
This specification targets a 128-bit security level for all cryptographic primitives. The
cryptographic methods used by this specification are shown in Table 5 (in Section 3.1).
2.2.1 Random number generators
The generation of cryptographic keys and the cryptographic protocol exchanges rely on
cryptographic quality random numbers. Random numbers are defined as numbers that are
distinguishable from random by no algorithm with an algorithmic complexity of less than O(2 ).
The output of a NIST SP800-90A-compliant PRNG seeded with a 256-bit full SP800-90B entropy
value is sufficient to meet this standard.
2.3 Security overview
Security of the Authentication protocol depends on the protection of private keys, and that
protection is supported by security evaluation.
2.3.1 Methodology
This specification defines a Certificate-based method for Authentication that allows a Power
Receiver to authenticate a Power Transmitter and, by policy, choose how to interact with that
Power Transmitter. For example, a Power Receiver may choose not to use the full advertised
capabilities of an unauthenticated Power Transmitter.
2.3.2 Periodic re-Authentication
The Power Receiver can optionally perform periodic re-Authentications to verify that an
authenticated Power Transmitter has not been replaced by a different one.
2.4 Impact to existing ecosystem
The impact to existing Power Transmitter Products depends largely on individual Policy decisions
regarding legacy Power Transmitters (i.e. Power Transmitters that predate this specification). For
example, a Power Receiver with a Policy that allows full functioning of legacy Power Transmitters
will have a minimal impact on the current ecosystem, while a Power Receiver with a Policy that
limits or refuses to use functionalities exposed by a legacy Power Transmitter will have a more
significant impact.
,(&‹,(& 
2.5 Support for revocation
If the Power Receiver supports Authentication functionality, then the Power Receiver should
support Revocation.
Revocation Lists are normally updated off line, e.g. as part of a software or firmware update or
during Product manufacturing. Manufacturers are not required to provide on-line maintenance of
Revocation Lists or to make Revocation Lists field-updatable in their Products, however, the Power
Receiver should frequently update its revocation list and not only during firmware updates. For
some Power Receiver Products with Internet connectivity (e.g. smartphones), frequent Revocation
List updates should be relatively easy. Other Power Receiver Products without direct Internet
connectivity, such as fitness trackers, may not be able to update their Revocation List as frequently,
but manufacturers should consider ways to keep the Revocation List current in their product
designs.
NOTE: Support for updatable Revocation Lists implies field-updatable non-volatile memory.
NOTE: The WPC Authentication License Administrator (WPC-ALA) will issue Revocation Lists from time to
time. The format of Revocation Lists and how they are communicated is outside the scope of this
specification.
 ,(&‹,(&
3 Certificates and private keys
3.1 Certificate Chains
The requirements in this section apply to Certificate Chains that are populated in slots 0 and 1. The
Power Transmitter Product manufacturer determines the requirements for Certificates that are
populated in slots 2 and 3. For further information about slots, see Section 3.3, CertificateChain
slots.
A Certificate Chain consists of three Certificates; see Table 4. The first Certificate in the chain is the
Root Certificate identifying the WPC Root Certificate Authority. It is a self-signed Certificate (i.e.
signed by the WPC Root Certificate Authority). As an optimization, the Certificate Chain contains a
hash of the Root Certificate rather than the Root Certificate itself. The second Certificate is a
Manufacturer CA Certificate identifying the product's manufacturer. It is signed by the WPC Root
Certificate Authority. The last Certificate in the chain is a Product Unit Certificate identifying the
individual Power Transmitter product. It is signed by the Manufacturer Certificate Authority.
In addition to identification data, the Manufacturer CA Certificate contains a public key for verifying
the authenticity of the Product Unit Certificate. The Product Unit Certificate contains a public key
for verifying the authenticity of the Power Transmitter Product Unit. See Section 4, Authentication
protocol, for details.
The following requirements apply to the Certificates in a Certificate Chain.
ƒ Each Product Unit Certificate shall identify a unique Power Transmitter Product Unit by using,
for example, the product unit's RSID number (wpc-qi-rsid).
ƒ Each Power Transmitter Product Unit shall have a unique public key.
ƒ Product Unit Certificates contained in different slots of the same Power Transmitter Product
Unit may contain the same identity and public key, provided that this does not introduce a
security vulnerability.
ƒ A manufacturer may have multiple Manufacturer CA Certificates to identify, for example,
different production facilities or product families. Each of these Manufacturer CA Certificates
shall contain a unique public key relating to a unique private key.
NOTE: Using multiple Manufacturer CA Certificates is encouraged to partition volumes of product units
to limit the collateral impact caused in the event that a Manufacturer CA Certificate is revoked
(collateral impact of revoking all product units signed by that Manufacturer CA Certificate).
ƒ A manufacturer shall use the private key associated with a Manufacturer CA Certificate to sign
Product Unit Certificates.
ƒ The WPC Root Certificate Authority shall ensure that all Manufacturer CA Certificates contain
unique public keys.
,(&‹,(& 
The Certificate Chains populated in slots 0 and 1 shall use X.509 Certificates. See Section 3.3,
CertificateChainslots, for further information about slots 0 and 1.
Table 4: Certificate Chain (X.509 Certificates)
b b b b b b b b
7 6 5 4 3 2 1 0
B .B msb
0 1
Length
lsb
B .B Root Certificate Hash (length N_RH)
2 (1+N_RH)
B .B
Manufacturer CA Certificate (length N_MC)
(2+N_RH) (1+N_RH+N_MC)
B .
(2+N_RH+N_MC)
Product Unit Certificate (length N_PUC)
B
(1+N_RH+N_MC+N_PUC)
Note: The Root Certificate is not included in the chain, only its hash is included in the chain.
Length The length is the total number of bytes in the Certificate Chain including the Length field.
RootCertificateHash A SHA-256 hash of the Root Certificate. The length of N_RH is 32 bytes.
See Section 2, Overview.
Manufacturer CA Certificate This Certificate identifies the manufacturer.
ProductUnitCertificate This Certificate identifies the individual product unit.

 ,(&‹,(&
3.2 Certificates
3.2.1 Format of Certificates
All Certificates shall use:
ƒ the X.509 v3 ASN.1 structure,
ƒ binary DER encoding for ASN.1, and
ƒ the cryptographic methods listed in Table 5.
Table 5: Summary of cryptographic methods
Method Use
X.509 v3, DER encoding Certificate format
ECDSA using the NIST P256, secp256r1 curve,
uncompressed point OR compressed point for- Digital signing of Certificates and Authentication
mat as specified by SEC1 (see Section 2, Over- Messages
view)
Hash algorithm, used in the ECDSA calculation
SHA-256 and in creating digests of Certificates and
Certificate Chains.
The further description of the Certificate format assumes that the reader is familiar with X.509 v3
Certificate terminology.
NOTE: Certificates and the fields, attributes, and extensions defined therein are Big Endian.
Product unit Certificates shall not exceed MaxProdCertSize in length. A Manufacturer CA Certificate
shall not exceed MaxManufacturerCertSize in length.
3.2.1.1 Textual format
All textual ASN.1 objects contained within X.509 Certificates, including DirectoryString,
GeneralName, and DisplayText, shall be specified as a UTF8String. The length of any textual object
shall not exceed 64 bytes excluding the DER type and DER length encoding.
3.2.1.2 Attributes and Extensions
Where applicable, the Object Identifier (OID) is provided.
Basic Constraints (OID 2.5.29.19)
Manufacturer CA Certificates contain this extension. (The extension is marked as critical, its cA
component is set to true, and its pathLenConstraint component set to zero). Product Unit
Certificates do not contain this extension.

,(&‹,(& 
Validity
The notBefore and notAfter fields indicate the time interval during which information regarding a
Certificate's validity is maintained. For Product Units, the validity times should be ignored.
Certificate notBefore and notAfter validity times shall be specified using ASN.1 GeneralizedTime
for any year, or ASN.1 UTCTime for years prior to 2050.
For a Manufacturer CA Certificate it is recommended that the notBefore field be
"19700101000000Z" (for 00:00 on 01-Jan-1970 UTC, which is POSIX epoch time). It is
recommended that the notAfter field be "99991231235959Z" (for 23:59:59 on 31-Dec-9999 UTC,
which is used for an unknown expiration time as defined in IETF-RFC-5280, Section 4.1.2.5). Use of
the recommended notBefore and notAfter values will maximize compatibility with Certificate
processing stacks.
Qi policy extension (wpc-qi-policy)
The WPC Qi policy extension is a custom Manufacturer CA Certificate extension for use with
products compliant to this specification. The value is a binary object and is reserved in this version
of the specification. The value of wpc-qi-policy is listed on The Qi Specifications page of the WPC
members’ website.
The binary object is encoded as an ASN.1 DER OCTET STRING with a fixed size of QiPolicySize
bytes.
Manufacturer CA Certificates shall contain this extension. Product Unit Certificates shall not
contain this extension.
Qi RSID extension (wpc-qi-rsid)
The WPC Qi revocation sequential identifier (RSID) extension is a custom Product Unit Certificate
extension for use with products compliant to this specification. The value is a binary object and is
provided to store a sequential identifier unique to each product unit that enables range-based
revocation of batches. The value of wpc-qi-rsid is listed on The Qi Specifications page of the WPC
members’ website.
The binary object is DER encoded as an ASN.1 OCTET STRING with a maximum size of
MaxQiRSIDSize bytes. The RSID value is unique to each product unit, from a minimum of 1 up to
MaxQiRSIDSize bytes.
Product Unit Certificates shall contain this extension. Manufacturer CA Certificates shall not
contain this extension.
 ,(&‹,(&
ASN.1 schema for WPC Object identifiers
The ASN.1 module below defines the WPC administered object identifiers and the schema for the
certificate extensions used for WPC Qi authentication.
-- WPC OID allocation
wpc INTEGER ::= 148
id-wpc OBJECT IDENTIFIER
::= {joint-iso-ccitt(2) international-organizations(23) wpc}
-- Qi Authentication certificate extensions
qiAuth INTEGER ::= 1
id-wpc-qiAuth OBJECT IDENTIFIER ::= {id-wpc qiAuth}
policy INTEGER ::= 1
id-wpc-qiAuth-policy OBJECT IDENTIFIER ::= {id-wpc-qiAuth policy}
rsid INTEGER ::= 2
id-wpc-qiAuth-rsid OBJECT IDENTIFIER ::= {id-wpc-qiAuth rsid}
-- WPC Qi Authentication size constants
wpcQiAuthPolicySize INTEGER ::= 4
wpcQiAuthRsidMaxSize INTEGER ::= 9
-- WPC Qi Authentication certificate extension schema
policy ::= OCTET STRING (SIZE (wpcQiAuthPolicySize))
rsid ::= OCTET STRING (SIZE (1…wpcQiAuthRsidMaxSize))
3.2.1.3 Manufacturer CA Certificate
A Manufacturer CA Certificate uses the ASN.1 structure defined in Rec. ITU-T X.509 (10/2016),
Section 7.2 Public-Key Certificate.
The TBSCertificate component of a Manufacturer CA Certificate only implements the ASN.1 fields
shown in Table 6.
,(&‹,(& 
Table 6: Certificate profile for a Manufacturer CA Certificate
Field OID Data type Value Example
Version INTEGER 0x02 {=X.509v3} 0x02
SerialNumber INTEGER A unique 1- to 72-bit 0x01 10 20 30 40 50
positive integer value 60 70
Note: The maximum length of 9 bytes refers to the “baseband” original value, before
DER encoding. The encoded value can have an additional zero byte if the top bit of the
original value is set. Be aware that this can be 10 bytes after encoding.
signature 1.2.840.10045.4.3.2 N/A
{ecdsa-with-SHA256}
issuer 2.5.4.3 UTF8String “WPCCA“+ one "WPCCA1"
{Common Name} character suffix
denoting different
root CA instances
validity.notBefor Either Any value 2000-01-01
e Generalized (not used by PRx) 00:00:00
Time for any
year, or
UTCTime for
years prior
to 2050
validity.notAfter Either Any value 9999-12-31
Generalized (not used by PRx) 23:59:59
Time for any
year, or
UTCTime for
years prior
to 2050
subject 2.5.4.3 UTF8String 7 byte string “CACA-1A”
{Common Name} consisting of:
ƒ four upper-case
characters
containing a PTMC
hex value
ƒ one character
containing a dash
ƒ two arbitrary
alpha-numeric
characters
TBSCertificate
 ,(&‹,(&
Table 6: Certificate profile for a Manufacturer CA Certificate (Continued)
Field OID Data type Value Example
subjectPublicKey 1.2.840.10045.2.1 N/A
Info.algorithm {ecPublicKey}
*
N/A
1.2.840.10045.3.1.7
{sec
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...