IEC 63563-9:2025

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
...