A80000OFFICIAL #

CRID Type of Change TDIF Document Document

Version TDIF R4 Version

NA Emergency TDIF 06D Attribute Profile 4.1.5 4.8

# A80000OFFICIAL
 A80000OFFICIAL #

Updated Page A C I X
(YYMMDD) Section/Requirement

Sections: 3.1.4, Section

6.1, Annex A and Annex
2023-02-23 All B. Table 33. No No Yes Yes

# A80000OFFICIAL
 A80000OFFICIAL #

Description

Clarifed the specification of verified documents throughout

06D and provided updated examples in Annex A. Additionally
refined the OIDC data representation for tdif_core claims, and
corrected a data type error in Table 33.

# A80000OFFICIAL
 A80000OFFICIAL #

Reason Implementation Comments

Resolve coflicting definitions and examples for

verified documents. Fix an error in the specification
of the TDIF bespoke _updated_at attributes.

Changes only relevant to AGDIS IdPs, IdX and relying

parties.

# A80000OFFICIAL
 A80000OFFICIAL #

Advised Providers of
Author
Change

AV, MOK

# A80000OFFICIAL
 A80000OFFICIAL #

S
TDIF Requirements (All changes 7 June 21) Applicability O
Requirement A Indicator
C I X R
T
ACCRED 3 1 1 The Applicant MUST formally request TDIF A C I X ACCRED
accreditation with a TDIF Application Letter . ###
ACCRED 3 1 1 a All information provided to the DTA for the purpose A C I X
of TDIF accreditation MUST be in English .
###
ACCRED 3 1 1 b The Applicant MUST have a registered and active A C I X
ABN. ###
ACCRED 3 1 2 b The TDIF Application Letter MUST specify whether the C I ACCRED
identity system supports web responsive design,
mobile apps or a combination of these. This
information will determine the scope of the
Accessibility Assessment.

###
ACCRED 3 1 2 c The TDIF Application Letter MUST specify whether the A C I X
Applicant is seeking to connect to the Australian
Government identity federation .
###
ACCRED 3 1 3 The Application Letter MUST include a Statement of A C I X ACCRED
Applicability which describes the scope of the
Applicant’s identity system.
###
ACCRED 3 1 3 a At a minimum, the Statement of Applicability MUST: A C I X ACCRED
a) Be written for an operational identity system,
regardless of whether the Applicant’s identity system
is operational or not.
b) summarise the fraud control, privacy, protective
security and user experience features of the identity
system.
c) Provide a high-level summary of how the
Applicant will meet the fraud control, privacy,
protective security and user experience requirements
set out in TDIF 04 Functional Requirements.
d) Include the version of the Australian Government
Information Security Manual used as its basis (i.e.
month and year).
The Statement of Applicability forms the basis of the
Applicant’s Functional Assessments.

###
ACCRED 3 1 3 b For multi-entity identity systems, the Statement of A C I X ACCRED
Applicability MUST also include all fraud control,
privacy, protective security, and user experience
controls which directly contribute to meeting TDIF
requirements.
###

# A80000OFFICIAL
 A80000OFFICIAL #

ACCRED 3 1 4 The TDIF Application Letter MUST include an A C I X ACCRED

accreditation schedule which at a minimum includes:
a. Estimated dates when Functional Assessments
will be undertaken
b. Estimated dates when Functional Assessment
Reports will be provided to the DTA
c. Estimated dates when the Applicant’s evidence
addressing TDIF requirements will be provided to the
DTA.

###
ACCRED 3 1 4 a The TDIF Application Letter MUST propose a A C I X ACCRED
commencement date and a date by which TDIF
accreditation is anticipated .
###
ACCRED 3 1 5 The TDIF Application Letter MUST include the names A C I X ACCRED
and contact details of people responsible within the
Applicant’s organisation(s) to manage their TDIF
accreditation .

###
ACCRED 3 1 6 The TDIF Application Letter MAY include any relevant A C I X ACCRED
TDIF Exemption Requests in accordance with the
process set out in Appendix A: TDIF exemption
process.
###
ACCRED 3 1 6 a Each TDIF Exemption Request MUST include all A C I X ACCRED
information as described in Appendix A: TDIF
exemption process.
###
ACCRED 3 1 7 The Applicant MAY include a copy of prior audit work A C I X ACCRED
which it requests the DTA consider as a substitute for
relevant Functional Assessments.
###
ACCRED 3 1 7 a Any request made to the DTA to consider prior audit A C I X
work MUST include:
a. An indication of which Functional Assessment it is
provided as a substitute for.
b. A rationale why it is being provided.
c. A summary of which TDIF requirements the
Applicant believes will be addressed by the prior audit
work.

###
FRAUD 2 2 2 The Fraud Control Plan (and supporting Fraud Control A C I X FRAUD
Plans) MUST be reviewed annually by the Applicant’s
Accountable Authority and when there is a change in
the ownership, structure, functions or activities of the
Applicant which may impact the operation of the
fraud control components of their identity system.

###

# A80000OFFICIAL
 A80000OFFICIAL #

FRAUD 2 5 10 The Applicant MUST develop and use procedures to A C I X FRAUD

report incidents of fraud or suspected fraud to the
DTA.
###
FRAUD 2 5 10 a As soon as they become aware the Applicant MUST A C I X FRAUD
report incidents of fraud or suspected fraud to the
DTA.
###
FRAUD 2 5 10 b The Applicant MUST include the following information A C I X FRAUD
when reporting on incidents of fraud or suspected
fraud:
a) Date and time of the fraud incident
b) Quantity of fraud incidents and their level of
severity
c) Time taken to respond to the fraud incident
d) Measures taken in response to the fraud incident
e) Type(s) of fraud
f) If applicable, the Identity Proofing Level and
Credential Level of the impacted identity record(s)
g) Any other supporting information (e.g. attack
vectors used by the fraudster).
Depending on the nature of the fraud incident and
legal advice obtained, the DTA may advise impacted
stakeholders of the outcome of a fraud investigation.

###
PRIV 3 4 1 An Applicant, covered by the Privacy Act, MUST A C I X PRIV
report eligible data breaches to affected individuals
and the Information Commissioner as required under
the Privacy Act and also report the eligible data
breach to the DTA.
###
PRIV 3 4 1 a An Applicant, not covered by the Privacy Act, MUST A C I X PRIV
report eligible data breaches as defined in the Privacy
Act 1988 to affected individuals and the DTA.

###
PRIV 3 5 2 The Applicant MUST include a statement in their A C I X
privacy notices advising that the Applicant may use
the Individual’s information as required by the TDIF,
including to detect, manage and investigate fraud.

###

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV 3 7 1 The Applicant MUST only collect, use and disclose an A C I X PRIV
Individual’s Behavioural Information to:
a) Verify the Identity of an Individual and assist
them to receive a digital service from a Relying Party.
b) To support identity fraud management functions.
c) To improve the performance or usability of the
Applicant’s identity system.
d) To de-identify the data to create aggregate data.

###
PRIV 3 7 1 a The Applicant MUST NOT sell or disclose an A C I X
Individual’s Behavioural information to a third party.
###
PRIV 3 8 2 Biometric information collected to for the purpose of I PRIV
proofing an Individual’s Identity MUST be destroyed
once the Biometric information has been used to
verify that identity (for example it has been matched
against a source photograph), unless:
• The Individual chooses to retain the Biometric
information stored or controlled by the Individual on
their device, or
• The Biometric information is collected or was
collected to create a government Identity document
(for example where a Road Traffic and Transport
Authority is an Identity document issuer and an
Identity Service Provider), or
The Biometric information is reused for
authentication use (in accordance with CSP-04-03-03).

###
PRIV 3 9 1 The Applicant MUST ensure Express Consent is A C I X PRIV
obtained from an Individual prior to disclosing that
individual’s Attributes to a Relying Party or any third
party.
###
PRIV 3 9 1 a This requirement has been archived in version 1.2. A C I X PRIV

###
PRIV 3 9 2 The Applicant MUST allow an Individual to withdraw A C I X PRIV
their Express Consent. ###
PRIV 3 9 2 a The Applicant MUST demonstrate how this Express A C I X PRIV
Consent withdrawal process is straightforward and
easy to use.
###

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV 3 9 2 b An Individual MUST be made aware of the A C I X PRIV

implications of providing or withdrawing their Express
Consent.
###
PRIV 3 9 3 The Applicant MUST maintain Audit Logs that A C I X PRIV
demonstrate how Express Consent was obtained from
the Individual.
###
PRIV 3 9 3 a The Audit Logs MUST NOT contain Biometric A C I X PRIV
information. ###
PRIV 3 9 4 The Applicant MUST inform Individuals of other A I PRIV
channels available to verify Identity and make clear to
the User what the consequences are of declining to
provide Express Consent or the required information.

###
PRIV 3 9 5 The Applicant MUST obtain Express Consent to A I PRIV
disclose and verify Identity Attributes with an
Authoritative Source. For example, through an
Identity Matching Service.
###
PRIV 3 10 2 a If it discloses Personal information to an overseas A C I X PRIV
recipient that is not the individual, the Applicant
MUST demonstrate to the DTA’s reasonable
satisfaction it has appropriate contractual and
practical measures to ensure the overseas recipient
complies with these TDIF privacy requirements.

###
PROT 4 1 13 The System Security Plan (and supporting System A C I X PROT
Security Plans) MUST be reviewed annually by the
Applicant’s Accountable Authority and when there is a
change in the ownership, structure, functions or
activities of the Applicant which may impact the
operation of the protective security components of
their identity system.

###
PROT 4 1 19 a The Applicant MUST document and present evidence A C I X PROT
of their security maturity to the DTA. ###
PROT 4 2 15 The Applicant MUST develop and use procedures to A C I X PROT
report Cyber security incidents to the DTA.
###
PROT 4 2 15 a As soon as they become aware the Applicant MUST A C I X PROT
report Cyber security incidents to the DTA.
###

# A80000OFFICIAL
 A80000OFFICIAL #

PROT 4 2 15 b The Applicant MUST include the following information A C I X PROT

when reporting Cyber security incidents:
a) Date and time of the Cyber security incident.
b) Quantity of Cyber security incidents and their
level of severity.
c) Time taken to respond to the Cyber security
incident.
d) Measures taken in response to the Cyber security
incident.
e) If applicable, the Identity Proofing Level and
Credential Level of the impacted identity record(s).
f) Any other supporting information (e.g. attack
vectors used).
Depending on the nature of the Cyber security
incident and legal advice sought, the DTA may advise
impacted stakeholders of the outcome of a security
investigation.

###
PROT 4 2 24 The Applicant MUST ensure their ICT systems A C I X PROT
(including software) incorporate processes for
generating Audit Logs.
###
PROT 4 2 24 a At a minimum, Audit Logs MUST include the following A C I X PROT
activities:
• Successful and failed elevation of privileges by
Personnel.
• User and group additions, deletions and
modification to permissions.
• Security related system alerts and failures (e.g.
attempted access that is denied, crashes or error
messages).
• Unauthorised access attempts to critical systems
and files.

###

# A80000OFFICIAL
 A80000OFFICIAL #

PROT 4 2 24 b At a minimum, Audit Logs for an activity MUST include A C I X PROT

:
• The date and time,
• The relevant User, identifier or process. Each
activity must have a unique identifier.
• The description.
• The ICT equipment involved.
• The source IP address of the device that
authenticated to the identity system.
• The source port used to perform the
authentication event.
• The destination IP address used to perform the
authentication event.
• The destination port used to perform the
authentication event.
• The User Agent String which identifies the
browser and operating system of the attempted
authentication.
• The International Mobile Equipment Identity
(IMEI) of a mobile phone (if a mobile phone is used to
authenticate to the identity system).

###
PROT 4 2 24 c Audit logs MUST include: C PROT
• Credential type used.
• Credential Level achieved.
###
PROT 4 2 24 d Audit Logs MUST include: I PROT
• Identity Proofing Level achieved.
• The binding of any Attributes to a Digital Identity.

###
PROT 4 2 24 e Audit Logs MUST include: X
• Interaction type. (E.g. OIDC Authentication
Request and response).
• Unique interaction identifier. (in accordance with
IDX-06-01-01).
• Entity. An Identity Service Provider or a Relying
Party.
• Entity link. Any identity link used in the
interaction, such as the RP Link or IdP Link.
• Names of any Attributes requested and returned.
• Any Identity Proofing Level or Credential Level
requested and returned.

###
PROT 4 2 24 f Audit Logs MUST include the following events: A
• The binding of any Attributes to a Digital Identity.
• The retrieval of any Attributes by a Third Party.

###

# A80000OFFICIAL
 A80000OFFICIAL #

PROT 4 2 25 Audit Logs MUST be: A C I X PROT

• Protected and stored to ensure the accuracy and
integrity of data captured or held.
• Protected from unauthorised access,
modification and deletion.
• Retained for a minimum of 7 years.
• Used to correlate activity across Audit Logs,
prioritise assessments and focus investigations.

###
ASSESS 7 2 1 The Applicant’s identity system MUST undergo a A C I X ASSESS
Security assessment by one or more Assessors (or
IRAP Assessor or other security professional) to
identify security deficiencies as part of initial
accreditation and annually thereafter as part of the
Annual Assessment.

###
ASSESS 7 3 1 The Applicant’s identity system MUST commission an A C I X ASSESS
Assessor to conduct an Accessibility Assessment and,
at a minimum:
• meet WCAG version 2.0 to the AA standard for
web-based identity services
• meet WCAG version 2.1 to the AA standard for
mobile-based identity services
as part of initial accreditation and annually thereafter
as part of the Annual Assessment.

###
ASSESS 7 4 2 The Applicant MUST define the scope , objectives and A C I X ASSESS
criteria for each Functional Assessment.
###

# A80000OFFICIAL
 A80000OFFICIAL #

ROLE 2 1 1 The Applicant MUST have user terms that include: A C I X ROLE
a) A description of the nature of the identity system
(consistent with the TDIF) provided to the User by the
Applicant.
b) A general acknowledgment by the User that their
use of the identity system provided by the Applicant is
governed by the user terms.
c) The Applicant’s identity system is provided on an
‘as is’ and ‘as available’ basis.
d) The scope of the User’s right to access and use
the identity system must be consistent with the TDIF.
e) The User is responsible for their use of the
Applicant’s identity system, including any Identity
Documents it provides to the Applicant, and will use
the service in compliance with all applicable laws.
f) The User is responsible to provide accurate
Identity Documents and Attributes to the Applicant.
g) The Applicant does not share Attributes, Personal
information or Sensitive information, or Credentials
with third parties without the Consent of the
Individual.
h) The User reports unauthorised use of their Digital
Identity or Credential to the Applicant as soon as they
become aware of it.
i) The Applicant may suspend, cancel or terminate
the User’s access to the identity system at any time.
j) That the Applicant may make changes to the user
terms at any time without prior notice and if the user
terms are changed, the User’s continued use of the
identity system will be subject to their acceptance of
the updated user terms.

###
ROLE 2 1 4 The Applicant MUST have user terms, including: A C I X ROLE
a) All title, rights and interest in and to the
intellectual property of the Applicant, including any
modifications, corrections or enhancements thereto,
will remain vested in the Applicant, in accordance
with the TDIF.
b) The User is liable for breaches of intellectual
property caused by the User’s use of the service other
than in accordance with the TDIF.
c) The User must not use, reproduce, amend or
alter intellectual property rights in the service.
d) The User must comply with security requirements
or instructions provided to it by the Applicant.

###
ROLE 2 2 1 This requirement has been archived in version 1.7. A C I X ROLE
###

# A80000OFFICIAL
 A80000OFFICIAL #

ROLE 2 2 1 a This requirement has been archived in version 1.7. A C I X ROLE

###
ROLE 2 2 1 b This requirement has been archived in version 1.7. A C I X ROLE

###
IDP 3 2 1 At a minimum, the Applicant MUST operate a TDIF I IDP
accredited identity system at Identity Proofing level 1
Plus as described in Table 1 below . [Table 1 of TDIF:
05 Role Requirements]
###
IDP 3 3 1 a The alternative Identity Proofing processes MAY I IDP
include:
• Acceptance of alternative types of EoI (for
example, evidence of the operation of an Identity in a
non-Australian community over time.
• Verification of an Individual’s claimed Identity
with a trusted referee whose Identity has been
verified to an equal or greater Identity Proofing Level.
• Verification of an Individual’s claimed Identity
with reputable organisations or bodies known to them
(for example, Aboriginal and Torres Strait Islander
organisations may hold, or be able to verify, the
Identity of Individuals where no prior government
record exists).
• Reliance on the Identity Proofing processes of
other organisations that have verified the Identity of
the Individual (i.e. Known Customer)
• A detailed interview with the Individual about
their life story to assess the consistency and
legitimacy of their claims.
• Alternative methods of providing Attributes or
Identity Documents (such as the provision of certified
copies by trusted third parties instead of attending an
in-person interview where an Individual can
demonstrate they live in a very remote area).
• Providing support for Individuals to obtain
evidence (such as assisting the Individual to register
their birth with a RBDM)
• Any other processes or approaches supported by
the IdP consistent with requirement IDP-03-03-01b

###
IDP 3 6 1 The Applicant MUST NOT collect, verify or validate I IDP
Attributes beyond those listed in Table 2 and Table 3.
[Table 2 and 3 of TDIF: 05 Role Requirements]

###

# A80000OFFICIAL
 A80000OFFICIAL #

IDP 3 6 2 This requirement This requirement has been archived I IDP

in version 1.7. ###
IDP 3 6 3 This requirement This requirement has been archived I IDP
in version 1.7.
###
IDP 3 6 4 This requirement This requirement has been archived I IDP
in version 1.7.
###
IDP 3 7 1 In accordance with PRIV-03-09-05, the Applicant I IDP
MUST limit this disclosure to Attributes listed in Table
2

###
IDP 3 7 1 a This requirement This requirement has been archived I IDP
in version 1.7.
###
IDP 3 7 2 In accordance with PRIV-03-09-01, the Applicant I IDP
MUST limit this disclosure to the following Attributes:
• Identity attributes (verified) listed in Table 2.
• Contact attributes (validated) listed in Table 2.
• Identity system metadata listed in Table 2.
• Assumed self-asserted Attributes listed in Table 3.

###
IDP 3 7 3 The Applicant MUST seek permission from the DTA to I IDP
disclose Attributes beyond those listed in IDP-03-07-
02.
###
IDP 3 7 3 a The Applicant MUST NOT disclose Attributes beyond I IDP
those listed in IDP-03-07-02 unless approved by the
DTA to do so.
###
IDP 3 8 15 b The minimum number of subjects for the testing I IDP
MUST be at least the same as described in current
published version of the FIDO Biometric Requirements
.
###
IDP 3 8 31 If the Applicant utilises manual processes, The I IDP
Applicant MUST include this in their risk assessment
for biometric binding processes.
###
IDP 3 8 34 The Applicant MUST only undertake remote Manual I IDP
Face Comparison utilising Assessing Officers located
within Australia.
###
CSP 4 1 1 The Applicant MUST support at least one of the C CSP
Credential Levels described in Table 4.. [Table 4 of
TDIF: 05 Role Requirements]
###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 1 2 For each supported Credential Level, the Applicant C CSP

MUST implement it to meet all requirements as
described in Table 4. [Table 4 of TDIF: 05 Role
Requirements]
###
CSP 4 2 1 If Memorised Secrets are supported, then the C CSP
Applicant MUST implement the following
requirements for the operation of Memorised Secrets.

###
CSP 4 2 1 a Memorised secrets MUST be at least 8 characters in C
length if chosen by the Individual. ###
CSP 4 2 1 b Memorised secrets chosen randomly by the Applicant C
MUST be at least 6 characters in length and MAY be
entirely numeric.
###
CSP 4 2 1 c If the Applicant disallows a chosen memorised secret C
based on its appearance on a blacklist of
compromised values, the Individual MUST be required
to choose a different memorised secret.

###
CSP 4 2 1 d When processing requests to establish and change C
memorised secrets, the Applicant MUST compare the
prospective secrets against a list that contains values
known to be commonly used, expected, or
compromised. For example, the list may include, but
is not limited to:
• Passwords obtained from previous breach
corpuses.
• Dictionary words.
• Repetitive or sequential characters (e.g. ‘aaaaaa’,
‘1234abcd’).
• Context-specific words, such as the name of the
service, the username, and derivatives thereof.

###
CSP 4 2 1 e If the chosen secret is found in the list, the Applicant C
MUST:
• advise the Individual that they need to select a
different secret,
• provide the reason for rejection, and
• require the Individual to choose a different value.

###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 2 1 f The Applicant MAY offer guidance to the Individual, C

such as a password-strength meter, to assist the
Individual in choosing a strong memorised secret. This
is particularly important following the rejection of a
memorised secret on the above list as it discourages
trivial modification of listed (and likely very weak)
memorised secrets.

###
CSP 4 2 1 g C

The Applicant MAY permit Individuals to use the

“paste” functionality when entering a memorised
secret. This facilitates the use of password managers,
which are widely used and, in many cases, increase
the likelihood that Individuals will choose stronger
memorised secrets. ###
CSP 4 2 1 h C

To assist the Individual in successfully entering a

memorised secret, the Applicant MAY offer an option
to display the secret — rather than a series of dots or
asterisks — until it is entered. This allows the
Individual to verify their entry if they are in a location
where their screen is unlikely to be observed. ###
CSP 4 2 1 i C

The Applicant MAY permit the Individual’s device to

display individual entered characters for a short time
after each character is typed to verify correct entry.
This is particularly applicable on mobile devices. ###
CSP 4 2 1 j C
The Applicant MUST use Australian Signals Approved
Cryptographic Algorithms (AACAs) and an
authenticated protected channel when requesting
memorised secrets to provide resistance to
eavesdropping and Man-in-the-Middle (MitM)
attacks. ###
CSP 4 2 1 k The Applicant MUST store memorised secrets in a C
form that is resistant to offline attacks. ###
CSP 4 2 1 l C
Memorised secrets MUST be salted and hashed using
a suitable one-way key derivation function. ###
CSP 4 2 1 m C
The salt MUST be at least 32 bits in length and be
chosen arbitrarily so as to minimise salt value
collisions among stored hashes. ###
CSP 4 2 1 n C
Both the salt value and the resulting hash MUST be
stored for each Individual who uses memorised
secrets. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 2 2 C CSP

If Look-up Secrets are supported, then the Applicant

MUST implement the following requirements for the
operation of look-up secrets. ###
CSP 4 2 2 a A Applicant creating look-up secrets MUST deliver C
them securely to the subscriber. ###
CSP 4 2 2 b Look-up secrets MUST prompt the Individual for the C
next secret (e.g. the next numbered secret). ###
CSP 4 2 2 c C

A given look-up secret MUST be used successfully only

once. If the look-up secret is derived from a grid card,
each cell of the grid MUST be used only once. ###
CSP 4 2 2 d The Applicant MUST store look-up secrets in a form C
that is resistant to offline attacks. ###
CSP 4 2 2 e Look-up secrets MUST be hashed using an AACA. C ###
CSP 4 2 2 f C
The salt value MUST be at least 32 in bits in length
and arbitrarily chosen so as to minimise salt value
collisions among stored hashes. ###
CSP 4 2 2 g Both the salt value and the resulting hash MUST be C
stored for each look-up secret. ###
CSP 4 2 2 h C

For look-up secrets that have less than 64 bits of

entropy, the Applicant MUST implement a rate-
limiting mechanism that effectively limits the number
of failed authentication attempts that can be made on
the Individual’s digital identity account. ###
CSP 4 2 2 i C
The Applicant MUST use AACAs and an authenticated
protected channel when requesting look-up secrets in
order to provide resistance to eavesdropping and
MitM attacks. ###
CSP 4 2 3 C CSP
If Out-of-band Devices are supported, then the
Applicant MUST implement the following
requirements for the operation of out-of-band
devices. ###
CSP 4 2 3 a C

The out-of-band device MUST establish a separate

channel with the Applicant to retrieve the out-of-
band secret or authentication request. This channel is
out-of-band with respect to the primary
communication channel (even if it terminates on the
same device) provided the device does not leak
information from one channel to the other without
consent of the Individual. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 2 3 b C

The out-of-band device MUST uniquely authenticate

itself in one of the following ways when
communicating with the Applicant:
• Establish an authenticated protected channel to
the Applicant using approved cryptography .
• The key used MUST be stored in suitably secure
storage available to the credential application (e.g.
keychain storage, secure element etc.).
• Authenticate to a public mobile telephone
network using a SIM card or equivalent that uniquely
identifies the device. This method MUST only be used
if a secret is being sent from the Applicant to the out-
of-band device via the Public Switched Telephone
Network (PSTN) (SMS or voice). ###
CSP 4 2 3 c C

If the out-of-band device sends an approval message

over the secondary communication channel — rather
than by the Individual transferring a received secret to
the primary communication channel — it MUST do
one of the following:
• The device MUST accept transfer of the secret
from the primary channel, which it MUST send to the
Applicant over the secondary channel to associate the
approval with the authentication transaction.
• The device MUST present a secret received via
the secondary channel from the Applicant and prompt
the Individual to verify the consistency of that secret
with the primary channel, prior to accepting a yes/no
response from the Individual. It MUST then send that
response to the Applicant.
• The Individual MAY perform the transfer
manually or use a technology such as a barcode or QR
code to effect the transfer. ###
CSP 4 2 3 d C
If out-of-band verification is to be made using a
secure application, such as on a smart phone, the
Applicant MAY send a push notification to that device.
The Applicant will then wait for the establishment of
an authenticated protected channel and verify the
device’s identifying key. ###
CSP 4 2 3 e The Applicant MUST NOT store the identifying key C
itself. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 2 3 f C

The Applicant MUST use a verification method (e.g. an

approved hash function using an AACA) to uniquely
identify the device. Once authenticated, the Applicant
will transmit the authentication secret to the device. ###
CSP 4 2 3 g C

Depending on the type of out-of-band device, one of

the following options (1, 2, OR 3) MUST take place:
1. Transfer of secret to primary channel:
o The Applicant MUST signal the device containing
the Individual’s credential to indicate readiness to
authenticate
o It MUST then transmit a random secret to the
out-of-band device
o The Applicant MUST then wait for the secret to
be returned on the primary communication channel.
2. Transfer of secret to secondary channel:
o The Applicant MUST display a random
authentication secret to the Individual via the primary
channel
o It MUST then wait for the secret to be returned
on the secondary channel from the Individual’s out-
of-band device.
3. Verification of secrets by the Individual:
o The Applicant MUST display a random
authentication secret to the Individual via the primary
channel and MUST send the same secret to the out-
of-band device via the secondary channel for
presentation to the Individual.
o It MUST then wait for an approval (or
disapproval) message via the secondary channel. ###
CSP 4 2 3 h C
In all cases, the authentication MUST be considered
invalid if not completed within 10 minutes. ###
CSP 4 2 3 i C
To provide replay resistance, the Applicant MUST
accept a given authentication secret only once during
the validity period. ###
CSP 4 2 3 j C
The Applicant MUST generate random authentication
secrets with at least 20 bits of entropy. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 2 3 k C

If the authentication secret has less than 64 bits of

entropy, the Applicant MUST implement a rate-
limiting mechanism that effectively limits the number
of failed authentication attempts that can be made on
the Individual’s digital identity account. ###
CSP 4 2 3 l C
If out-of-band verification is to be made using the
PSTN, the Applicant MUST verify that the pre-
registered telephone number being used is associated
with a specific physical device. ###
CSP 4 2 3 m C

The Applicant MUST consider risks associated with

device swap, SIM change, number porting or other
abnormal behaviour before using the PSTN to deliver
an out-of-band authentication secret. ###
CSP 4 2 3 n C
Risks of using the PSTN MUST be recorded in the
Applicant’s System Security Plan and managed
accordingly. ###
CSP 4 2 4 C CSP

If single-factor OTP devices are supported, the

Applicant MUST implement the following
requirements to operate single-factor OTP devices. ###
CSP 4 2 4 a C
The secret key and its algorithm MUST provide at
least the minimum-security strength specified in the
latest edition of the ISM. ###
CSP 4 2 4 b C
The nonce MUST be of sufficient length to ensure that
it is unique for each operation of the device over its
lifetime. ###
CSP 4 2 4 c OTP credentials MUST NOT facilitate the cloning of C
the secret key onto multiple devices. ###
CSP 4 2 4 d C

If the nonce used to generate the authentication

output is based on a real-time clock, the nonce MUST
be changed at least once every 2 minutes. ###
CSP 4 2 4 e The OTP value associated with a given nonce MUST be C
accepted only once. ###
CSP 4 2 4 f C

When a single-factor OTP Credential is being

associated with an Individual’s digital identity
account, the Applicant MUST use AACAs to either
generate and exchange or to obtain the secrets
required to duplicate the authentication output. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 2 4 g C

The Applicant MUST use AACAs and an authenticated

protected channel when collecting the OTP to provide
resistance to eavesdropping and MitM attacks. ###
CSP 4 2 4 h C
To provide replay resistance, the Applicant MUST
accept a given time-based OTP only once during the
validity period. ###
CSP 4 2 4 i C
Time-based OTPs MUST have a defined lifetime that is
determined by the expected clock drift — in either
direction — of the credential over its lifetime, plus
allowance for network delay and user entry of the
OTP. ###
CSP 4 2 4 j C

If the authentication output has less than 64 bits of

entropy, the Applicant MUST implement a rate-
limiting mechanism that effectively limits the number
of failed authentication attempts that can be made on
the Individual’s digital identity account. ###
CSP 4 2 5 C CSP
If multi-factor one-time password (MF OTP) devices
are supported, then the Applicant MUST implement
the following requirements for the operation of MF
OTP devices. ###
CSP 4 2 5 a C
The secret key and its algorithm MUST provide at
least the minimum -security strength specified in the
latest edition of the ISM. ###
CSP 4 2 5 b C
The nonce MUST be of sufficient length to ensure that
it is unique for each operation of the device over its
lifetime. ###
CSP 4 2 5 c OTP authentication MUST NOT facilitate the cloning of C
the secret key onto multiple devices. ###
CSP 4 2 5 d C

If the nonce used to generate the authentication

output is based on a real-time clock, the nonce MUST
be changed at least once every 2 minutes. ###
CSP 4 2 5 e C
Any memorised secret used for activation MUST be a
randomly chosen numeric secret at least 6 decimal
digits in length. ###
CSP 4 2 5 f C

The unencrypted key and activation secret or

biometric sample — and any biometric data derived
from the biometric sample, such as a probe produced
through signal processing — MUST be zeroised
immediately after an OTP has been generated. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 2 5 g C
When a MF OTP Credential is being associated with an
Individual’s digital identity account, the Applicant
MUST use AACAs to either generate and exchange, or
to obtain the secrets required to duplicate the
authentication output. ###
CSP 4 2 5 h C

The Applicant MUST use AACAs and an authenticated

protected channel when collecting the OTP to provide
resistance to eavesdropping and MitM attacks. ###
CSP 4 2 5 i The Applicant MUST also establish that the Credential C
is a MF OTP device. ###
CSP 4 2 5 j C
Time-based OTPs MUST have a defined lifetime that is
determined by the expected clock drift — in either
direction — of the credential over its lifetime, plus
allowance for network delay and user entry of the
OTP. ###
CSP 4 2 5 k C
To provide replay resistance, the Applicant MUST
accept a given time-based OTP only once during the
validity period. ###
CSP 4 2 5 l C

In the event an Individual’s authentication is denied

due to duplicate use of an OTP, the Applicant MAY
warn the Individual in case an attacker has been able
to authenticate in advance. ###
CSP 4 2 5 m C
The Applicant MAY also warn the Individual in an
existing session of the attempted duplicate use of an
OTP. ###
CSP 4 2 5 n C

If the authentication output has less than 64 bits of

entropy, the Applicant MUST implement a rate-
limiting mechanism that effectively limits the number
of failed authentication attempts that can be made on
the Individual’s digital identity account. ###
CSP 4 2 6 C CSP
If single-factor cryptographic software is supported,
then the Applicant MUST implement the following
requirements for the operation of single-factor
cryptographic software. ###
CSP 4 2 6 a C

The key MUST be strongly protected against

unauthorised disclosure using access controls that
limit access to the key to only those software
components on the device requiring access. ###
CSP 4 2 6 b C
Single-factor cryptographic software credentials
MUST NOT facilitate the cloning of the secret key onto
multiple devices. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 2 6 c Keys MUST be protected against modification. C ###

CSP 4 2 6 d Keys MUST be protected against unauthorised C
disclosure. ###
CSP 4 2 6 e The challenge nonce MUST be at least 64 bits in C
length. ###
CSP 4 2 6 f C
The challenge nonce MUST either be unique over the
credential’s lifetime or be statistically unique. ###
CSP 4 2 6 g The authentication event MUST use approved C
cryptography (i.e. AACAs and AACPs). ###
CSP 4 2 7 C CSP
If single-factor cryptographic devices are supported,
then the Applicant MUST implement the following
requirements for the operation of single-factor
cryptographic devices. ###
CSP 4 2 7 a C
Single-factor cryptographic devices MUST encapsulate
one or more secret keys unique to the device that
MUST NOT be exportable (i.e. cannot be removed
from the device). ###
CSP 4 2 7 b C
The secret key and its algorithm MUST provide at
least the minimum-security length specified in the
latest edition of the ISM. ###
CSP 4 2 7 c The challenge nonce MUST be at least 64 bits in C
length. ###
CSP 4 2 7 d C
The challenge nonce MUST either be unique over the
credential’s lifetime, or be statistically unique. ###
CSP 4 2 7 e Approved cryptography (i.e., AACAs and AACPs) MUST C
be used. ###
CSP 4 2 7 f Keys MUST be protected against modification. C ###
CSP 4 2 7 g Keys MUST be protected against unauthorised C
disclosure. ###
CSP 4 2 8 C CSP
If multi-factor cryptographic software is supported,
then the Applicant MUST implement the following
requirements for the operation of multi-factor
cryptographic software. ###
CSP 4 2 8 a C

The key MUST be strongly protected against

unauthorised disclosure by the use of access controls
that limit access to the key to only those software
components on the device requiring access. ###
CSP 4 2 8 b Authentication events MUST require the input of both C
factors. ###
CSP 4 2 8 c C
Any memorised secret used for activation MUST be a
randomly chosen numeric value at least 6 decimal
digits in length. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 2 8 d C

The unencrypted key, and activation secret or

biometric sample — and any biometric data derived
from the biometric sample such as a probe produced
through signal processing — MUST be zeroised
immediately after an authentication has taken place. ###
CSP 4 2 8 e Keys MUST be protected against modification. C ###
CSP 4 2 8 f Keys MUST be protected against unauthorised C
disclosure. ###
CSP 4 2 8 g The challenge nonce MUST be at least 64 bits in C
length. ###
CSP 4 2 8 h C
The challenge nonce MUST either be unique over the
credential’s lifetime or, be statistically unique. ###
CSP 4 2 8 i The authentication event MUST use approved C
cryptography (i.e. AACAs and AACPs). ###
4 2 8 j Truncation MUST NOT be performed on the C
memorised secret used for activation. ###
CSP 4 2 9 C CSP
If multi-factor cryptographic device is supported, the
Applicant MUST implement the following
requirements for the operation of multi-factor
cryptographic devices. ###
CSP 4 2 9 a C
The secret key and its algorithm MUST provide at
least the minimum-security length specified in the
latest edition of the ISM. ###
CSP 4 2 9 b The challenge nonce MUST be at least 64 bits in C
length. ###
CSP 4 2 9 c C
The challenge nonce MUST either be unique over the
Credential’s lifetime or, be statistically unique. ###
CSP 4 2 9 d Approved cryptography (i.e., AACAs and AACPs) MUST C
be used. ###
CSP 4 2 9 e Keys MUST be protected against modification. C ###
CSP 4 2 9 f Keys MUST be protected against unauthorised C
disclosure. ###
CSP 4 3 1 C CSP
If physical Credentials are supported, the Applicant
MUST implement the following requirements to
operate physical Credentials. ###
CSP 4 3 1 a C
The Applicant MUST provide the Individual with
instructions on how to appropriately protect the
credential against theft or loss. ###
CSP 4 3 1 b C
The Applicant MUST provide a mechanism to revoke
or suspend the credential immediately upon
notification from the individual that loss or theft of
the credential is suspected. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 3 2 The Applicant MUST implement rate limiting (or C CSP

throttling) for all credentials. ###
CSP 4 3 2 a The Applicant MUST implement controls to protect C
against online guessing attacks. ###
CSP 4 3 2 b C
The Applicant MUST limit consecutive failed
authentication attempts on a single account to no
more than 100. ###
CSP 4 3 2 c C

Additional techniques MAY be used to reduce the

likelihood that an attacker will lock the Individual out
of their digital identity account out as a result of rate
limiting. Following a failed authentication event, the
Applicant MAY require:
• The individual to complete a Completely
Automated Public Turing test to tell Computers and
Humans Apart (CAPTCHA) before attempting
authentication.
• The Individual to wait for a period of time that
increases as the account approaches its maximum
allowance for consecutive failed attempts (e.g. 30
seconds up to an hour).
• Accepting only authentication requests that come
from a whitelist of IP addresses from which the
Individual has been successfully authenticated before.
• Leveraging other risk-based or adaptive
authentication techniques to identify user behaviour
that falls within or out of typical norms. Examples
include: use of IP address, geolocation, timing of
request patterns, or browser metadata. ###
CSP 4 3 2 d C
When the individual successfully authenticates, the
Applicant MAY disregard any previous failed attempts
for that user from the same IP address. ###
CSP 4 3 3 C CSP
If biometrics for authentication use are supported,
then the Applicant MUST implement the following
biometrics requirements for the operation of
biometrics for authentication use. ###
CSP 4 3 3 a Biometrics MUST be used only as part of multi-factor C
authentication with a physical Credential. ###
CSP 4 3 3 b C

An authenticated protected channel between sensor

and Applicant MUST be authenticated prior to
capturing the biometric sample from the Individual. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 3 3 c The biometric system MUST operate with a False- C

Match-Rate (FMR) of 1 in 1000 or better. ###
CSP 4 3 3 d C
This FMR MUST be achieved under conditions of a
conformant attack (i.e., zero-effort impostor attempt)
as defined in ISO/IEC 30107-1. ###
CSP 4 3 3 e The biometric system MUST implement Presentation C
Attack Detection (PAD). ###
CSP 4 3 3 f C

Testing of the biometric system to be deployed MUST

demonstrate at least 90% resistance to presentation
attacks for each relevant attack type (i.e. species),
where resistance is defined as the number of
thwarted presentation attacks divided by the number
of trial presentation attacks. ###
CSP 4 3 3 g C
Testing of presentation attack resistance MUST be in
accordance with Clause 12 of ISO/IEC 30107-3:2017. ###
CSP 4 3 3 h The PAD decision MAY be made either locally on the C
Individual’s device or by the Applicant. ###
CSP 4 3 3 i C
The biometric system MUST allow no more than 5
consecutive failed authentication attempts or 10
consecutive failed attempts. ###
CSP 4 3 3 j C

Once the limit of consecutive failed attempts has

been reached, the biometric system MUST either:
• Impose a delay of at least 30 seconds before the
next attempt, increasing exponentially with each
successive attempt (e.g. 1 minute before the following
failed attempt, 2 minutes before the second following
attempt), or
• Disable the biometric user authentication and
offer another factor (e.g., a different biometric
modality or a PIN/Passcode if it is not already a
required factor) if such an alternative method is
already available. ###
CSP 4 3 3 k C

The Applicant MUST make a determination of sensor

and endpoint performance, integrity, and
authenticity. Acceptable methods for making this
determination include, but are not limited to:
• Authentication of the sensor or endpoint.
• Certification by an approved accreditation
authority
• Runtime interrogation of signed metadata (e.g.
attestation). ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 3 3 l C

If supported, Biometric comparison that is performed

centrally MUST implement the following:
• Use of the biometric as an authentication factor
MUST be limited to one or more specific devices that
are identified using approved cryptography (i.e,
AACAs and AACPs).
• Since the biometric has not yet unlocked the
main authentication key, a separate key MUST be
used for identifying the device.
• Biometric revocation, referred to as biometric
template protection in ISO/IEC 24745, MUST be
implemented.
• All transmission of biometrics MUST be over the
authenticated protected channel. ###
CSP 4 3 3 m C
Biometric samples collected in the authentication
process MAY be used to train comparison algorithms
or — with user consent — for other research
purposes. ###
CSP 4 3 3 n C
Biometric samples and any biometric data derived
from the biometric sample such as a probe produced
through signal processing MUST be zeroiszed
immediately after any training or research data has
been derived. ###
CSP 4 3 4 C CSP

If credential attestation is supported, the Applicant

MUST implement the following requirements for the
operation of credential attestation. ###
CSP 4 3 4 a C

Information conveyed by credential attestation MAY

include, but is not limited to:
• The provenance (e.g. manufacturer or supplier
certification), health, and integrity of the credential
and endpoint
• Security features of the credential
• Security and performance characteristics of
biometric sensor(s)
• Sensor modality. ###
CSP 4 3 4 b C
If this attestation is signed, it MUST be signed using a
digital signature that provides at least the minimum-
security strength specified in the latest version of the
ISM. ###
CSP 4 3 4 c Attestation information MAY be used as part of a C
CSP’s risk-based authentication decision. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 3 5 C CSP

Where a Applicant supports CL3, it MUST implement

the following Applicant-impersonation resistance
requirements. These requirements do not need to be
implemented for CL1 or CL2. ###
CSP 4 3 5 a C
A CSP-impersonation resistant authentication
protocol MUST establish an authenticated protected
channel with the Applicant. ###
CSP 4 3 5 b C

A CSP-impersonation resistant authentication

protocol MUST strongly and irreversibly bind a
channel identifier that was negotiated in establishing
the authenticated protected channel to the
authentication output (e.g. by signing the two values
together using a private key controlled by the
claimant for which the public key is known to the
Applicant). ###
CSP 4 3 5 c C

The Applicant MUST validate the signature or other

information used to prove CSP-impersonation
resistance. This prevents an impostor CSP attacker,
even one that has obtained a certificate representing
the actual CSP, from replaying that authentication on
a different authenticated protected channel. ###
CSP 4 3 5 d AACAs MUST be used to establish CSP-impersonation C
resistance where it is required. ###
CSP 4 3 5 e C
Keys used for this purpose MUST provide at least the
minimum-security strength specified in the latest
edition of the ISM. ###
CSP 4 3 5 f C
Credentials that involve the manual entry of an
authentication output, such as out-of-band and OTP
Credentials, MUST NOT be considered CSP-
impersonation resistant because the manual entry
does not bind the authentication output to the
specific session being authenticated. ###
CSP 4 3 6 C CSP
In situations where the IdP and CSP are separate
entities, communication MUST occur through a
mutually authenticated secure channel (such as a
client-authenticated TLS connection) using approved
cryptography (i.e, AACAs and AACPs). ###
CSP 4 3 7 C CSP

Where a Applicant supports CL 3 it MUST implement

the following Applicant-compromise resistance
requirements. These requirements do not need to be
implemented for CL1 or CL 2. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 3 7 a C
To be considered CSP-compromise resistant, public
keys stored by the Applicant MUST be associated with
the use of approved cryptographic algorithms (i.e.
AACAs). ###
CSP 4 3 7 b C
Keys MUST provide at least the minimum-security
strength specified in the latest version of the ISM. ###
CSP 4 3 8 C CSP

Where the Applicant supports CL2 or CL3 it MUST

implement at least one of the following credentials:
• OTP devices;
• Out-of-band Devices;
• Cryptographic-based credentials; or
• Look-up secrets. ###
CSP 4 3 9 C CSP
Where the Applicant supports CL 3 it MUST
implement the following authentication intent
requirements. These requirements do not need to be
implemented for CL 1 or CL 2. ###
CSP 4 3 9 a Authentication intent MUST be established by the C
Credential itself. ###
CSP 4 3 9 b C

Authentication intent MAY be established in several

ways, including:
• Authentication processes that require the
Individual’s intervention (e.g., an Individual entering
an authentication output from an OTP device).
• Cryptographic devices that require user action
(e.g., pushing a button or reinsertion) for each
authentication or reauthentication operation. ###
CSP 4 3 10 C CSP
If, at any time, the Applicant determines that a
Credential is resulting in an unacceptable risk to any
party, then they MUST prevent continued use of that
Credential. Such Credentials are referred to as
Restricted Credentials. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 3 11 C

If a Applicant supports the use of a Restricted

Credential, it MUST:
1. Offer Individuals at least one alternate Credential
that is not restricted and can be used to authenticate
at the required CL
2. Provide meaningful notice to Individuals
regarding the security risks of the Restricted
Credential and availability of alternative(s) that are
not restricted
3. Address any additional risk to Individuals in its
security risk assessment
4. Develop a migration plan for the possibility that
the Restricted Credential is no longer acceptable at
some point in the future. ###
CSP 4 4 1 C CSP
A Credential MUST be bound to an Individual’s
account by either:
• Issuance by the Applicant as part of enrolment;
or
• Associating a user-provided Credential that is
acceptable to the Applicant. ###
CSP 4 4 1 a C
Throughout the digital identity lifecycle, the Applicant
MUST maintain a record of all Credentials that are or
have been associated with each digital identity
account. ###
CSP 4 4 1 b C
The Applicant MUST maintain the information
required for throttling authentication attempts when
required. ###
CSP 4 4 1 c C

The Applicant MUST also verify the credential type of

a user-provided Credential (e.g., single-factor
cryptographic device vs. multi-factor cryptographic
device) so the Applicant can determine compliance
with requirements at each CL. ###
CSP 4 4 1 d C
The record created by the Applicant MUST contain
the date and time the Credential was bound to the
account. ###
CSP 4 4 1 e C
The record MUST include information about the
source of the binding (e.g., IP address, device
identifier) of any device associated with the
enrolment. ###
CSP 4 4 1 f C
The record MUST also contain information about the
source of unsuccessful authentications attempted
with the Credential. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 4 1 g C
When any new Credential is bound to an Individual’s
account, the Applicant MUST ensure that the binding
protocol and the protocol for provisioning the
associated key(s) are done at a level of security
commensurate with the CL at which the Credential
will be used. ###
CSP 4 4 2 C CSP

For remote transactions where enrolment and binding

cannot be completed in a single electronic transaction
(i.e. within a single protected session), the following
requirements MUST be met to ensure that the same
party acts as the Individual throughout the process:
• The Individual MUST identify themselves in each
new binding transaction by presenting a temporary
secret which was either established during a prior
transaction or sent to the Individual’s mobile phone
number or email address.
• Long-term authentication secrets MUST only be
issued to the Individual within a protected session. ###
CSP 4 4 2 a C

TDIF Req: Applicant-04-04-02a; Updated: Jun-21;

Applicability: C
For in-person transactions where enrolment and
binding cannot be completed in a single physical
encounter (i.e. within a single protected session), the
following requirements MUST be met to ensure that
the same party acts as the Individual throughout the
process:
• The Individual MUST identify themselves in-
person by either using a secret as described in
Applicant-04-04-02, or through use of a biometric that
was recorded during the identity proofing process.
• Temporary secrets MUST NOT be reused
• If the Applicant issues long-term authentication
secrets during a physical transaction, then they MUST
be loaded locally onto a physical device that is issued
in-person to the individual or delivered in a manner
that confirms the individual’s email address or mobile
phone number ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 4 3 C CSP
If a Applicant supports the binding of additional
Credentials to an Individual’s account, then it MUST
implement the following requirements for the
operation of binding additional credentials to an
individual’s account. ###
CSP 4 4 3 a C

Before binding an additional Credential to an

Individual’s account, the Applicant MUST first require
the Individual to authenticate at the CL (or a higher
CL) at which the new Credential will be used. ###
CSP 4 4 3 b C

When a Credential is added, the Applicant MAY send a

notification to the Individual via a mechanism that is
independent of the transaction binding the new
Credential (e.g. email to an address previously
associated with the Individual). ###
CSP 4 4 3 c The Applicant MAY limit the number of Credentials C
that may be bound in this manner. ###
CSP 4 4 4 C CSP
Before binding a new Credential to an account, the
Applicant MUST require the Individual to authenticate
with a Credential of at least CL1. ###
CSP 4 4 4 a C

When a Credential is added, the Applicant MAY send a

notification to the Individual via a mechanism that is
independent of the transaction binding the new
Credential (e.g. email to an address previously
associated with the Individual). ###
CSP 4 4 5 This requirement has been archived in version 1.7. C CSP

###
CSP 4 4 6 C CSP

The Applicant MAY, where practical, accommodate

the use of a user-provided Credential to relieve the
burden to the Individual of managing a large number
of Credentials. ###
CSP 4 4 7 C CSP
The Applicant MAY bind an updated Credential an
appropriate amount of time before an existing
Credential’s expiration. ###
CSP 4 4 8 C
Following successful use of the new Credential, the
Applicant MAY revoke the Credential that it is
replacing. ###
CSP 4 5 1 C CSP
The suspension, revocation or destruction of a
compromised Credential MUST occur as promptly as
practical following detection of loss, theft, damage or
unauthorised duplication. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 5 2 C

To facilitate secure reporting of the loss, theft or

damage to a Credential, the Applicant MAY provide
the Individual with a method of authenticating to the
Applicant using a backup or alternate Credential. ###
CSP 4 5 3 C
If the Applicant implements CSP-04-05-02, then the
backup Credential MUST be either a Memorised
Secret or a physical Credential. ###
CSP 4 5 4 C
The Applicant MAY choose to validate a User’s
contact details (i.e. email, mobile phone number) and
MUST suspend a Credential reported to have been
compromised. ###
CSP 4 5 5 C

The suspension of a compromised credential MUST be

reversible if the Individual successfully authenticates
to the Applicant using a valid (i.e. not suspended)
Credential and requests reactivation of a Credential
suspended in this manner. ###
CSP 4 5 6 C
The Applicant MAY set a time limit after which a
suspended Credential can no longer be reactivated. ###
CSP 4 6 1 C CSP
The Applicant MAY issue Credentials that expire. ###
CSP 4 6 1 a When a Credential expires, it MUST NOT be usable for C
authentication. ###
CSP 4 6 1 b C
The Applicant MUST require an Individual to
surrender or prove destruction of any physical
Credential containing attribute certificates signed by
the Applicant as soon as practical after expiration or
receipt of a renewed Credential. ###
CSP 4 7 1 C CSP

The Applicant MUST revoke the binding of a

Credential promptly when an account ceases to exist
(e.g. an Individual’s death, discovery of a fraudulent
account), when requested by the Individual, or when
the Applicant determines that the Individual no longer
meets its eligibility requirements. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 7 2 C

The Applicant MUST require an Individual to

surrender or certify destruction of any physical
Credential containing certified attributes signed by
the Applicant as soon as practical after revocation or
termination takes place. This is necessary to block the
use of the Credential’s certified attributes in offline
situations between revocation or termination and
expiration of the certification. ###
CSP 4 8 1 C CSP
A session MAY be started in response to an
authentication event and continue until such time
that it is terminated. ###
CSP 4 8 1 a C

A session MAY be terminated for any number of

reasons, including but not limited to an inactivity
timeout, an explicit logout event or other means. ###
CSP 4 8 1 b C
The session MAY be continued through a
reauthentication event wherein the Individual repeats
some or all of the initial authentication event, thereby
re-establishing the session. ###
CSP 4 8 2 This requirement has been archived in version 1.7. C CSP

###
CSP 4 8 3 This requirement has been archived in version 1.7. C CSP
###
CSP 4 8 4 This requirement has been archived in version 1.7. C CSP
###
CSP 4 8 5 This requirement has been archived in version 1.7. C CSP
###
CSP 4 9 1 C CSP

Continuity of authenticated sessions MUST be based

upon the possession of a session secret issued by the
Applicant at the time of authentication and optionally
refreshed during the session. ###
CSP 4 9 1 a Session secrets MUST be non-persistent. C ###
CSP 4 9 1 b C
Session secrets MUST NOT be retained across a
restart of the associated application or a reboot of the
host device. ###
CSP 4 9 1 c C

Periodic reauthentication of sessions MUST be

performed to confirm the continued presence of the
Individual at an authenticated session (i.e. that the
Individual has not walked away without logging out). ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 9 1 d C

When a session has been terminated, due to a time-

out or other action, the Individual MUST be required
to establish a new session by authenticating again. ###
CSP 4 10 1 C CSP

If the Step-Up of a Credential from one Credential

Level to another is supported by the Applicant, then it
MUST implement the following requirements for the
operation of Step-Up for all Credential Levels. ###
CSP 4 10 1 a The Applicant MUST be accredited to issue a C
Credential at the higher Credential Level. ###
CSP 4 10 1 b The Credential MUST meet all the requirements of the C
higher Credential level. ###
CSP 4 10 2 C

The Applicant MUST ensure that an Individual can

prove ownership of their existing Identity by
authenticating with their Credential to their account
prior to commencing the Credential Step-Up process. ###
CSP 4 11 1 C

If Certification Authorities are supported, then the

Applicant MUST implement all of the following
requirements to operate as a Certification Authority. ###
CSP 4 11 2 C

The Applicant MUST ensure all:

a. Certification Practice Statements (CPS) and
Certificate Policies (CP) conform to Request for
Comment (RFC) 3647.
b. Digital Certificates conform to the (RFC) 5280
format.
c. Certificate Revocation Lists (CRLs) conform to the
X.509 version 2 profile as described in RFC 5280.
d. Online Certificate Status Protocol (OCSP)
responses conform to RFC 6960. ###

# A80000OFFICIAL
 A80000OFFICIAL #

CSP 4 11 3 C

The Applicant MUST ensure the Root Certification

Authority (CA) Private Key is not used to digitally sign
Digital Certificates, except in the following cases:
• Self-signed Digital Certificates to represent the
Root CA itself.
• Digital Certificates for Subordinate CAs and Cross
Certificates.
• Digital Certificates for infrastructure purposes
(for example, administrative role certificates and
OCSP Digital Certificates).
• Digital Certificates issued solely for the purpose
of testing software with Digital Certificates issued by
the Root CA. ###
CSP 4 11 4 C
The Applicant MUST implement a process to allow
Individuals to request revocation of their Digital
Certificate. ###
CSP 4 11 4 a C

The Applicant MUST implement revocation

procedures for the following situations:
• The Individual notifies the Applicant that a Digital
Certificate request was not authorised by them.
• The Applicant obtains evidence that a Digital
Certificate’s Private Key suffered a Key compromise or
no longer complies with the requirements outlined in
the Certificate Policy.
• The Applicant obtains evidence that a Digital
Certificate it has issued has been misused.
• The Applicant is made aware that an Individual
has violated one or more of their usage terms (for
example, those set out in ROLE-02-01-01).
• The Applicant is made aware that the Certificate
was not issued in accordance with its Certification
Practice Statements or Certificate Policy.
• The Applicant determines that any information
set out in the Digital Certificate is inaccurate or
misleading.
• The Applicant obtains evidence of a suspected or
actual compromise of a subordinate CA’s Private Key. ###
IDX 6 1 1 The Applicant MUST generate a unique audit Id for an X
Authentication Request from a Relying Party to be
used as the Unique interaction identifier for the
interaction.
###

# A80000OFFICIAL
 A80000OFFICIAL #

IDX 6 1 2 The Applicant MUST log all related interactions X

between Relying Parties and Identity Service Providers
using this unique audit id (this includes Attribute
Service Providers acting as Relying Parties).

###
IDX 6 2 1 In accordance with PRIV-03-09-03, the Applicant X
MUST maintain the following information as part of
its auditable logs:
• timestamp.
• Duration of Consent. (including any time limit on
the consent).
• Relying Party. (i.e. The RP that requested to
receive the attributes).
• The Identifier that identifies the User at the
Relying Party authorised to receive the attributes.
• IdP/AP from which the attributes were sourced.
• The link to the identity at the source of the
attributes.
• Name of any attribute or attribute set authorised.
• Consent decision. This may be “grant”, “deny”, or
“ongoing”.

###
IDX 6 3 1 If single sign on is supported, then the Applicant X
MUST implement the following requirements to
operate single sign on.
###
IDX 6 3 2 The Applicant MUST support the ability for a Relying X
Party to request that a User authenticates regardless
of whether a pre-existing session exists.

###
IDX 6 3 2 a The Applicant MUST implement a single log out X
mechanism according to the Federation Protocol that
it supports.
###
IDX 6 3 3 The Applicant MAY securely cache Attributes from an X
Identity Service Provider for the duration of an
authenticated session to support single sign on.

###
IDX 6 3 3 a If the Applicant securely caches attributes as per IDX- X
06-03-03, these attributes MUST NOT be accessible to
the Applicant’s Personnel.
###
IDX 6 3 4 The Applicant MAY restrict the expiration period for X
an authentication session to manage security risks.
###

# A80000OFFICIAL
 A80000OFFICIAL #

IDX 6 4 1 If a User Dashboard is supported, then the Applicant X

MUST implement the following requirements for the
operation of a User Dashboard.

###
IDX 6 4 2 The Applicant MUST display to the Individual their X
Consumer History and enable the Individual to view
the Express Consent they have provided to share
attributes with a Relying Party or any third party.

###
IDX 6 4 3 The Applicant MUST NOT store Attributes of the X
Individual beyond the Individual’s presence at the
User Dashboard.
###
IDX 6 5 1 If IdP Selection is supported, the Applicant MUST X
implement the following requirements for the
operation of IdP Selection.
###
IDX 6 5 2 The list of Identity Service Providers presented by the X
Applicant to the User MUST be capable of meeting
the Credential Level and Identity Proofing Level
requested in the Authentication Request.

###
IDX 6 5 3 The Applicant MAY provide a mechanism for an X
Individual’s selection of an Identity Service Provider to
be remembered so the Individual does not have to
select an Identity Service Provider (again) when
accessing a Relying Party.
###
IDX 6 5 3 a Express Consent MUST be obtained from the X
Individual prior to offering the mechanism described
in IDX-06-05-02.
###
IDX 6 5 3 b The Individual MUST have the ability to opt out of X
using the mechanism described in IDX-06-05-02.
###
FED 2 1 7 This requirement has been archived in version 1.1. X FED
The content of this requirement has been moved to
PRIV-03-09-03.
###

# A80000OFFICIAL
 A80000OFFICIAL #

FED 2 1 7 a This requirement has been archived in version 1.1. X FED

The content of this requirement has been moved to
IDX-06-02-01

###
FED 2 1 8 The Applicant’s Audit logs MUST store a record of all X FED
federated identity interactions that relate to an
Individual, including any requests and responses
between a Relying Party and an Identity Exchange, or
an Identity Service Provider and an Identity Exchange.

###
FED 2 1 8 a This requirement has been archived in version 1.1. X FED
The content of this requirement has been moved to
PROT-04-02-24e.

###
FED 2 1 9 The Applicant MUST develop and use procedures to A C I X
report incidents of fraud or suspected fraud to the
Oversight Authority (this replaces FRAUD-02-05-10).

###
FED 2 1 9 a As soon as they become aware the Applicant MUST A C I X
report incidents of fraud or suspected fraud to the
Oversight Authority (this replaces FRAUD-02-05-10a).

###

# A80000OFFICIAL
 A80000OFFICIAL #

FED 2 1 9 b The Applicant MUST include the following information A C I X

when reporting on incidents of fraud or suspected
fraud:
a) Date and time of the fraud incident.
b) Quantity of fraud incidents and their level of
severity.
c) Time taken to respond to the fraud incident.
d) Measures taken in response to the fraud incident.
e) Type(s) of fraud.
f) If applicable, the Identity Proofing Level and
Credential Level of the impacted identity record(s).
g) Any other supporting information (e.g. attack
vectors used by the fraudster).

Depending on the nature of the fraud incident and

legal advice obtained, the Oversight Authority may
advise impacted stakeholders of the outcome of a
fraud investigation (this replaces FRAUD-02-05-10b).

###
FED 2 1 10 An Applicant, covered by the Privacy Act, MUST A C I X
report eligible data breaches to affected individuals
and the Information Commissioner as required under
the Privacy Act[1] and also report the eligible data
breach to the Oversight Authority (this replaces PRIV-
03-04-01).
###
FED 2 1 10 a An Applicant, not covered by the Privacy Act, MUST A C I X
report eligible data breaches as defined in the Privacy
Act 1988 to affected individuals and the Oversight
Authority (this replaces PRIV-03-04-01a).

###
FED 2 1 11 The Applicant MUST include a statement in their A C I X
privacy notices advising that the Applicant may use
the Individual’s information as required by the
Oversight Authority, including to detect, manage and
investigate fraud (this replaces PRIV-03-05-02).

###
FED 2 1 12 The Applicant MAY include a statement in their A C I X
privacy notices advising that the Applicant may
provide the Individual’s system metadata to the
Oversight Authority to enable it to perform the
Oversight Authority’s functions related to fraud
management.
###

# A80000OFFICIAL
 A80000OFFICIAL #

FED 2 1 13 If it discloses Personal information to an overseas A C I X

recipient that is not the individual, the Applicant
MUST demonstrate to the Oversight Authority’s
reasonable satisfaction it has appropriate contractual
and practical measures to ensure the overseas
recipient complies with these TDIF privacy
requirements (this replaces PRIV-03-10-02a).

###
FED 2 1 14 The Applicant MUST develop and use procedures that A C I X
ensure:
a) All elements of the Applicant’s System Security
Plan are achieved.
b) Cyber security incidents are investigated,
responded to and reported to the Oversight
Authority.
c) Relevant security policy or legislative obligations
are met.
(This replaces PROT-04-01-06).

###
FED 2 1 15 The Applicant MUST develop and use procedures to A C I X
report Cyber security incidents to the Oversight
Authority (this replaces PROT-04-02-15).

###
FED 2 1 15 a As soon as they become aware the Applicant MUST A C I X
report Cyber security incidents to the Oversight
Authority (this replaces PROT-04-02-15a).

###

# A80000OFFICIAL
 A80000OFFICIAL #

FED 2 1 15 b The Applicant MUST include the following information A C I X

when reporting Cyber security incidents:
a) Date and time of the Cyber security incident.
b) Quantity of Cyber security incidents and their
level of severity.
c) Time taken to respond to the Cyber security
incident.
d) Measures taken in response to the Cyber security
incident.
e) If applicable, the Identity Proofing Level and
Credential Level of the impacted identity record(s).
f) Any other supporting information (e.g. attack
vectors used).
Depending on the nature of the Cyber security
incident and legal advice sought, the Oversight
Authority may advise impacted stakeholders of the
outcome of a security investigation (this replaces
PROT-04-02-15b).

###
FED 2 3 1 The Applicant MUST generate Pairwise Identifiers in I X FED
accordance with section 8.1 of the OpenID Connect
Core 1.0 specification [OpenIDCore] and use these to
interact with Relying Parties regardless of the
Federation Protocol the Applicant is using to
communicate with other Participants in the
Federation.

###
FED 2 3 9 This requirement has been archived in version 1.1. X FED

###
FED 2 3 10 The Applicant MUST have a process to conduct X FED
Deduplication of Digital identities which pass through
an Identity Exchange to ensure that a User with
multiple digital identities is presented as the same
user to a Relying Party.
###
FED 2 3 11 The Applicant MUST only deduplicate Digital Identities X FED
which have been proved to the same Identity Proofing
Level.
###
FED 2 3 21 If the Applicant supports single sign on, it MUST X FED
support the ability for a Relying Party to request
Authentication for a particular User using the method
specified in the Federation Protocol being used. See
section 4.2 for more detail on how an Identity
Exchange can support this.
###

# A80000OFFICIAL
 A80000OFFICIAL #

FED 2 3 22 This requirement has been archived in version 1.1. X FED

The content of this requirement has been moved to
IDX-06-03-02

###
FED 2 3 23 This requirement has been archived in version 1.1. C I X FED
The content of this requirement has been moved to
IDX-06-03-02a
###
FED 2 3 25 This requirement has been archived in version 1.1. X FED
The content of this requirement has been moved to
IDX-06-03-03a
###
FED 2 3 26 This requirement has been archived in version 1.1. C I X FED
###
FED 2 3 27 This requirement has been archived in version 1.1. X FED
The content of this requirement has been moved to
IDX-06-03-03
###
FED 2 3 28 This requirement has been archived in version 1.1. C I X FED
The content of this requirement has been moved to
IDX-06-03-04
###
FED 2 3 29 This requirement has been archived in version 1.1. X FED

###
FED 2 3 30 This requirement has been archived in version 1.1. I FED

###
FED 3 2 1 The Applicant’s Audit Log MUST include any User A FED
Consent managed by the Applicant that enables the
sharing of attributes with a Relying Party.

###
FED 3 2 2 The Applicant’s Audit Log MUST include the value of A FED
the RP Audit Id Attribute received from an Identity
Exchange for the following events:
• The retrieval of Attributes by an Identity
Exchange.
• The binding of any Attributes to a Digital Identity
brokered by an Identity Exchange.

###
FED 3 2 3 This requirement has been archived in version 1.1. A FED

###
FED 4 1 1 This requirement has been archived in version 1.1. X FED
The content of this requirement has been moved to
IDX-06-01-01.
###

# A80000OFFICIAL
 A80000OFFICIAL #

FED 4 1 1 a In addition to the requirements in section 6.1 of the X

TDIF 05 – Role Requirements, the Applicant MUST
implement the following requirements
###
FED 4 1 2 This requirement has been archived in version 1.1. X FED
The content of this requirement has been moved to
IDX-06-01-02.

###
FED 4 1 3 The Applicant MUST provide the unique audit id X FED
described in IDX-06-01-01 to the Relying Party using
the RP_audit_id Attribute in response to every logical
interaction between a Relying Party (including an
Attribute Service Provider) and an Identity Exchange

###
FED 4 1 4 When the Applicant calls an API provided by an X FED
Attribute Service Provider, they MUST include the
value of the unique audit id that has been generated
by the Identity Exchange for the Relying Party that
requested the Attributes.
###
FED 4 1 5 The Applicant MUST NOT send the unique audit id X FED
that has been generated by the Identity Exchange for
the Relying Party that requested the Attributes to an
Identity Service Provider.
###
FED 4 1 6 The Applicant MUST implement a User Dashboard in X FED
accordance with the requirements in section 6.4 of
the TDIF 05 – Role Requirements.

###
FED 4 1 7 This requirement has been archived in version 1.1. X FED
The content of this requirement has been moved to
IDX-06-04-02.

###
FED 4 1 8 This requirement has been archived in version 1.1. X FED
The content of this requirement has been moved to
IDX-06-04-03.
###
FED 4 1 13 The Applicant MUST implement IdP Selection in X FED
accordance with the requirements in section 6.5 of
the TDIF 05 – Role Requirements.

###
FED 4 1 14 This requirement has been archived in version 1.1. X FED
The content of this requirement has been moved to
IDX-06-05-01b.

###

# A80000OFFICIAL
 A80000OFFICIAL #

FED 4 1 15 This requirement has been archived in version 1.1. X FED

The content of this requirement has been moved to
IDX-06-05-02a

###
FED 4 1 16 This requirement has been archived in version 1.1. X FED
The content of this requirement has been moved to
IDX-06-05-02

###
FED 4 2 1 This requirement has been archived in version 1.1. X FED

###
FED 4 2 1 a This requirement has been archived in version 1.1. X FED

###
FED 4 2 1 b This requirement has been archived in version 1.1. X FED

###
FED 4 2 1 c This requirement has been archived in version 1.1. X FED

###
FED 4 2 1 d This requirement has been archived in version 1.1. X FED

###
FED 4 2 3 c If the sub (subject) claim is specified then it MUST be X FED
processed as per the requirements in section 4.2.2.2
###
FED 4 2 10 The Applicant MUST evaluate the ACR returned from X FED
the Identity Service Provider and if the ACR meets or
exceeds the originally requested value(s), return one
of the originally requested values

###

# A80000OFFICIAL
 A80000OFFICIAL #

FED 4 2 13 This requirement has been archived in version 1.1. X FED

###
FED 4 2 14 This requirement has been archived in version 1.1 X FED

###
FED 4 2 19 The Applicant MUST evaluate the X FED
<saml:AuthnContextClassRef> returned from the
Identity Service Provider and if the
<saml:AuthnContextClassRef> meets or exceeds the
originally requested ACR value(s), return one of the
originally requested values.
###
FED 5 1 1 The Applicant MUST support the disclosure of all X FED
Attributes described in section 3.1 of the TDIF: 06D -
Attribute Profile using one of the federation protocols
specified in section 2.1.1 of the TDIF 06 – Federation
Onboarding Requirements

###
FED 5 1 2 The Applicant MUST support the disclosure of all I FED
Attributes listed as mandatory in section 3.1 of the
TDIF: 06D - Attribute Profile using one of the
federation protocols specified in section 2.1.1 of the
TDIF 06 – Federation Onboarding Requirements

###
FED 5 1 3 The Applicant MAY support the disclosure of an I FED
Attribute listed as optional in section 3.1 of TDIF: 06D
- Attribute Profile using one of the federation
protocols specified in section 2.1.1 of the TDIF 06 –
Federation Onboarding Requirements

###
FED 5 1 4 The Applicant MUST support the disclosure of all I FED
Attributes listed as mandatory in section 3.2 of the
TDIF: 06D - Attribute Profile using one of the
federation protocols specified in section 2.1.1 of the
TDIF 06 – Federation Onboarding Requirements.

###
FED 5 1 6 The Applicant MUST support the disclosure of all X FED
Attributes described in section 3.3 of TDIF: 06D -
Attribute Profile using one of the federation protocols
specified in section 2.1.1 of the TDIF 06 – Federation
Onboarding Requirements
###

# A80000OFFICIAL
 A80000OFFICIAL #

FED 5 1 7 The Applicant MUST support the disclosure of all X FED

Attributes described in section 3.5 of TDIF: 06D -
Attribute Profile using one of the federation protocols
specified in section 2.1.1 of the TDIF 06 – Federation
Onboarding Requirements
###
FED 5 2 2 The Applicant MUST support the disclosure of X FED
additional computed attributes described in section
3.4 of the TDIF: 06D - Attribute Profile using one of
the federation protocols specified in section 2.1.1 of
the TDIF 06 – Federation Onboarding Requirements

###
FED 5 3 1 The Applicant MAY support the disclosure of X FED
Attributes an Attribute Service Provider is accredited
to provide. These Attributes are defined in section 5
of the TDIF: 06D - Attribute Profile.

###
FED 5 3 2 The Applicant MUST ensure that it only disclosure, or A FED
provides to an Identity Exchange to be shared,
Attributes that are relevant to the Relying Party
requesting the Attributes
###
FED 5 4 1 The Applicant MUST only disclose Attributes with X FED
Relying Parties in accordance with the Attribute
Sharing Policy specified for the Attribute Set which an
Attribute is part of as described in section 2.2 of the
TDIF: 06D - Attribute Profile.

###
FED 5 5 1 When disclosing Attributes to other Participants in the A I X FED
Identity Federation, the Applicant MUST use the
attribute data representation for Attributes specified
in section 6 of the TDIF: 06D - Attribute Profile.

###

# A80000OFFICIAL
 A80000OFFICIAL #

TDIF Requirements (Previous Release)

Requirement
Colour Key
3 1 1 The Applicant MUST formally request TDIF accreditation and
complete the TDIF Application Letter at Appendix A.

3 1 2 b The TDIF Application Letter MUST specify whether the identity

system supports web responsive design, mobile apps or a
combination of these. This information will determine the
accessibility assessment to be met.

3 1 3 The Application Letter MUST include a Statement of Applicability

which lists the protective security controls implemented by the
Applicant for their identity system.

3 1 3 a At a minimum, the Statement of Applicability MUST:

a) Specify the Applicant’s risk tolerance for their identity system.

b) Be written for an operational identity system, regardless of

whether the Applicant’s identity system is operational or not.
c) Include all protective security requirements (section 4) set
out in TDIF: 04 - Functional Requirements.
d) Include the version of the Australian Government Information
Security Manual used as its basis (i.e. month and year).
The Statement of Applicability forms the basis of the Applicant’s
security assessment.

3 1 3 b For multi-entity identity systems, the Statement of Applicability

MUST include all protective security controls which directly
contribute to meeting TDIF protective security requirements.

# A80000OFFICIAL
 A80000OFFICIAL #

3 1 4 The TDIF Application Letter MUST include an accreditation

schedule which highlights key dates and accreditation milestones.

3 1 4 a The TDIF Application Letter MUST propose a date by which TDIF

accreditation is anticipated.

3 1 5 The TDIF Application Letter MUST include the names and contact
details of people responsible within the Applicant’s organisation
to manage their TDIF accreditation .

3 1 6 The TDIF Application Letter MAY include any relevant TDIF

Exemption Requests in accordance with the process set out in
‘Appendix B: TDIF exemption process’.

3 1 6 a Each TDIF Exemption Request MUST include all information as

described in ‘Appendix B: TDIF exemption process’.

3 1 7 The Applicant MAY include a copy of prior assessments which it

requests the DTA consider as a substitute for relevant Functional
Assessments.

2 2 2 The Fraud Control Plan (and supporting Fraud Control Plans)

MUST be reviewed annually by the Applicant’s Accountable
Authority and when there is a change in the structure, functions
or activities of the Applicant which impact the operation of the
fraud control components of their identity system.

# A80000OFFICIAL
 A80000OFFICIAL #

2 5 10 The Applicant MUST develop and use procedures to report

incidents of fraud or suspected fraud to the Oversight Authority
and DTA.

2 5 10 a As soon as they become aware the Applicant MUST report

incidents of fraud or suspected fraud to the Oversight Authority
and DTA.

2 5 10 b The Applicant MUST include the following information when

reporting on incidents of fraud or suspected fraud: Date and time
of the fraud incident.
a) Quantity of fraud incidents and their level of severity.
b) Time taken to respond to the fraud incident.
c) Measures taken in response to the fraud incident.
d) Type(s) of fraud.
e) If applicable, the Identity Proofing Level and Credential Level
of the impacted identity record(s).
f) Any other supporting information (e.g. attack vectors used by
the fraudster).
Depending on the nature of the fraud incident and legal advice
obtained, the Oversight Authority or DTA may advise impacted
stakeholders of the outcome of a fraud investigation.

3 4 1 An Applicant, covered by the Privacy Act, MUST report eligible

data breaches to affected individuals and the Information
Commissioner as required under the Privacy Act and also report
the eligible data breach to the Oversight Authority and DTA.

3 4 1 a An Applicant, not covered by the Privacy Act, MUST report eligible

data breaches as defined in the Privacy Act 1988 to affected
individuals and the Oversight Authority and DTA.

# A80000OFFICIAL
 A80000OFFICIAL #

3 7 1 The Applicant MUST only collect, use and disclose information

about an Individual’s behaviour on the Australian Government’s
identity federation to:
a) Verify the Identity of an Individual and assist them to receive
a digital service from a relying party.
b) To support identity fraud management functions.
c) To improve the performance or usability of the Applicant’s
identity system.
d) To de-identify the data to create aggregate data.

3 8 2 Biometric information collected to for the purpose of proofing an

Individual’s Identity MUST be destroyed once the Biometric
information has been used to verify that identity (for example it
has been matched against a source photograph), unless:
• The Individual chooses to retain the Biometric information
stored or controlled by the Individual on their device, or
• The Biometric information is collected or was collected to
create a government Identity document (for example where a
Road Traffic and Transport Authority is a, Identity document issuer
and an Identity Service Provider)

3 9 1 The Applicant MUST obtain Express Consent from an Individual

prior to disclosing the individual’s Attributes to a Relying Party or
any third party.

3 9 1 a The Applicant MUST only disclose the Individual’s Attributes

required for the Relying Party’s transaction with that Individual’s
Consent.

3 9 2 The Applicant MUST allow an Individual to withdraw their

Consent.
3 9 2 a The Applicant MUST demonstrate how this Consent withdrawal
process is straightforward and easy to use.

# A80000OFFICIAL
 A80000OFFICIAL #

3 9 2 b An Individual MUST be made aware of the implications of

providing or withdrawing their Consent.

3 9 3 The Applicant MUST maintain auditable logs that demonstrate

that Consent was obtained and is current.

3 9 3 a The auditable logs MUST NOT contain Biometric information.

3 9 4 The Applicant MUST inform Individuals of other channels available

to verify Identity and make clear to the User what the
consequences are of declining to provide Consent or the required
information.

3 9 5 The Applicant MUST obtain Consent to verify Identity Attributes

against an Authoritative Source. For example, through an Identity
Matching Service.

3 10 2 a If it discloses Personal information to an overseas recipient that is

not the individual, the Applicant MUST demonstrate to the
Oversight’s reasonable satisfaction it has appropriate contractual
and practical measures to ensure the overseas recipient complies
with these TDIF privacy requirements.

4 1 13 The System Security Plan (and supporting System Security Plans)

MUST be reviewed annually by the Applicant’s Accountable
Authority and when there is a substantial change in the structure,
functions or activities of the Applicant which impact the operation
of the protective security components of their identity system.

4 1 19 a The Applicant MUST document and evidence their assessment of

its security maturity.
4 2 15 The Applicant MUST develop and use procedures to report Cyber
security incidents to the Oversight Authority and DTA.

4 2 15 a As soon as they become aware the Applicant MUST report Cyber

security incidents to the Oversight Authority and DTA.

# A80000OFFICIAL
 A80000OFFICIAL #

4 2 15 b The Applicant MUST include the following information when

reporting Cyber security incidents:
a) Date and time of the Cyber security incident.
b) Quantity of Cyber security incidents and their level of
severity.
c) Time taken to respond to the Cyber security incident.
d) Measures taken in response to the Cyber security incident.
e) If applicable, the Identity Proofing Level and Credential Level
of the impacted identity record(s).
f) Any other supporting information (e.g. attack vectors used).

4 2 24 The Applicant MUST ensure their ICT systems (including software)

incorporate processes for audit trails and activity logging in
applications

4 2 24 a At a minimum activity logging MUST occur for the following

events:
• Successful and failed elevation of privileges by Personnel.
• User and group additions, deletions and modification to
permissions.
• Security related system alerts and failures (e.g. attempted
access that is denied, crashes or error messages).
• Unauthorised access attempts to critical systems and files.
• The source IP address of the device that authenticated to the
identity system.
• The source port used to perform the authentication event.
• The destination IP address used to perform the
authentication event.
• The destination port used to perform the authentication
event.
• The User Agent String which identifies the browser and
operating system of the attempted authentication.
• The International Mobile Equipment Identity (IMEI) of a
mobile phone (if a mobile phone is used to authenticate to the
identity system).

# A80000OFFICIAL
 A80000OFFICIAL #

4 2 24 b At a minimum activity logs MUST include:

• The date and time of the event,
• The relevant User, identifier or process. Each event must have
a unique identifier.
• The event description.
• The ICT equipment involved.
Further guidance on events to log is available in the ISM.

4 2 24 c Activity logs MUST include:

• Credential type used.
• Credential Level achieved.

4 2 24 d Activity logs MUST include:

• Identity Proofing Level achieved.

# A80000OFFICIAL
 A80000OFFICIAL #

4 2 25 Activity logs MUST be:

• Protected and stored to ensure the accuracy and integrity of
data captured or held.
• Protected from unauthorised access, modification and
deletion.
• Retained for a minimum of 7 years.
• Used to correlate activity across event logs, prioritise
assessments and focus investigations.

7 2 1 The Applicant’s identity system MUST undergo a Security

assessment by a security Assessor (or IRAP Assessor or other
security professional) to identify security deficiencies as part of
initial accreditation and annually thereafter as part of the Annual
Assessment.
As per the TDIF: 03 - Accreditation Process:
• The Statement of Applicability forms the basis of the
Applicant’s Security assessment.
• For multi-entity systems, the scope of the Security
assessment MUST include all security controls which contribute to
meeting the TDIF protective security requirements.

7 3 1 The Applicant’s identity system MUST at a minimum:

• For web-based identity services meet WCAG version 2.0 to
the AA standard.
• For mobile-based identity services meet WCAG version 2.1 to
the A standard.
As part of initial accreditation and annually thereafter as part of
the Annual Assessment .

7 4 2 The Applicant MUST define the scope , objectives and criteria for
each Functional Assessment and provide this to the DTA as part of
its Accreditation Plan.

# A80000OFFICIAL
 A80000OFFICIAL #

2 1 1 The Applicant MUST have user terms that include:

a) A description of the nature of the identity system (consistent
with the TDIF) provided to the User by the Applicant.
b) A general acknowledgment by the User that their use of the
identity system provided by the Applicant is governed by the user
terms.
c) The Applicant’s identity system is provided on an ‘as is’ and
‘as available’ basis.
d) The scope of the User’s right to access and use the identity
system must be consistent with the TDIF.
e) The User is responsible for its use of the Applicant’s identity
system, including any Identity Documents it provides to the
Applicant, and will use the service in compliance with all
applicable laws.
f) The User is responsible to provide accurate Identity
Documents and Attributes to the Applicant.
g) The User does not share Attributes, Personal information or
Sensitive information, or Credentials with third parties without the
Consent of the Individual.
h) The User reports unauthorised use of their Digital Identity or
Credential to the Applicant as soon as they become aware of it.
i) The Applicant may suspend, cancel or terminate the User’s
access to the identity system at any time.
j) That the Applicant may make changes to the user terms at
any time without prior notice and if the user terms are changed,
the User’s continued use of the identity system will be subject to
their acceptance of the updated user terms.

2 1 4 The Applicant MUST have user terms, including:

a) All title, rights and interest in and to the intellectual property
of the Applicant, including any modifications, corrections or
enhancements thereto, will remain vested in the Applicant, in
accordance with the TDIF.
b) The User is liable for breaches of intellectual property caused
by the User’s use of the service other than in accordance with the
TDIF.
c) The User must not use, reproduce, amend or alter intellectual
property rights in the service.
d) The user consents to the Applicant using their information as
required by the TDIF, including to detect, manage and investigate
fraud.
e) The User must comply with security requirements or
instructions provided to it by the Applicant.

2 2 1 The Applicant MUST establish and maintain an Operations

Manual.

# A80000OFFICIAL
 A80000OFFICIAL #

2 2 1 a The Operations Manual MUST include:

a) The roles and responsibilities of the Applicant’s Personnel.
b) The processes, procedures and workflows used to support the
Applicant’s lifecycle management functions.
c) All interactions with Accredited Participants.

2 2 1 b The Applicant MUST ensure that all information included in the

Operations Manual is consistent with information included in its
Protective security documentation.

3 2 1 At a minimum, the Applicant’s identity system MUST support

Identity Proofing Level 1 Plus as described in Table 1 below. [pg
10-11 of TDIF: 05 Role Requirements]

3 3 1 a The alternative Identity Proofing processes MAY include:

• Acceptance of alternative types of EoI (for example, evidence
of the operation of an Identity in a non-Australian community
over time).
• Verification of an Individual’s claimed Identity with a trusted
referee whose Identity has been verified to an equal or greater
Identity Proofing Level.
• Verification of an Individual’s claimed Identity with reputable
organisations or bodies known to them (for example, Aboriginal
and Torres Strait Islander organisations may hold, or be able to
verify, the Identity of Individuals where no prior government
record exists).
• Reliance on the Identity Proofing processes of other
organisations that have verified the Identity of the Individual (i.e.
Known Customer)
• A detailed interview with the Individual about their life story
to assess the consistency and legitimacy of their claims.
• Alternative methods of providing Attributes or Identity
Documents (such as the provision of certified copies by trusted
third parties instead of attending an in-person interview where an
Individual can demonstrate they live in a very remote area).
• Providing support for Individuals to obtain evidence (such as
assisting the Individual to register their birth with a RBDM)

3 6 1 For each EoI document used, the Applicant MAY collect and verify,
and create and record the Attributes listed in Table 2. [pg 17 of
TDIF: 05 Role Requirements]

# A80000OFFICIAL
 A80000OFFICIAL #

3 6 2 The Applicant MAY collect, validate and record the Individual’s

mobile phone number, email address, or both.
3 6 3 The Applicant MAY collect and record the Attributes listed on EoI
documents as described in Table 3. [pg 17 of TDIF: 05 Role
Requirements]

3 6 4 The Applicant MUST NOT collect, create, verify or record

Attributes beyond that which is listed in Table 2 or Table 3. [pg 17
of TDIF: 05 Role Requirements]

3 7 1 The Applicant MAY disclose the Attributes listed in the “Attributes

to be collected, verified and recorded” column of Table 2 and the
Attributes listed in Table 3 for the purpose of having them verified
(i.e. with the issuer of the associated EoI document). [pg 17 of
TDIF: 05 Role Requirements]

3 7 1 a The Applicant MUST NOT disclose Attributes beyond those listed

in IDP-03-07-01 for the purpose of having them verified.

3 7 2 The Applicant MAY disclose all of the following Attributes:

• Verified name(s).
• Verified date of birth.
• Validated contact details it collects.
• Identity Proofing Level achieved.
• Date and time the Digital Identity was created.
to a Relying Party via an Identity Exchange or Attribute Service
Provider).

3 7 3 The Applicant MAY seek permission from the DTA to request the
sharing of more Attributes than those listed in TDIF req: IDP-03-
07-02.

3 7 3 a The Applicant MUST NOT disclose Attributes beyond those listed

in IDP-03-07-01 for the purpose of service delivery, unless
approved by the DTA to do so.

3 8 15 b The minimum number of subjects for the testing MUST be 245, as

described in FIDO Biometric Requirements.

3 8 31 If the Applicant utilises any manual processes, The Applicant

MUST include this in their risk assessment for biometric binding
processes.

3 8 34 The Applicant MUST only undertake remote Manual Face

Comparison utilizing Assessing Officers located within Australia.

4 1 1 The Applicant MUST support at least one approved Credential at a

Credential Level as described in Table 4. [pg 19 of TDIF: 05 Role
Requirements]

# A80000OFFICIAL
 A80000OFFICIAL #

4 1 2 For each supported Credential, the Applicant MUST implement it

to meet all requirements as described in Table 5. [pg 20 of TDIF:
05 Role Requirements]

4 2 1 If supported, the Applicant MUST implement a “memorised

secret” as set out in Section 5.1.1 of NIST SP 800-63B.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

4 2 2 If supported, the Applicant MUST implement a “look-up secret” as

set out in Section 5.1.2 of NIST SP 800-63B.

4 2 3 If supported, the Applicant MUST implement an “out-of-band

device” as set out in Section 5.1.3 of NIST SP 800-63B.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

4 2 4 If supported, the Applicant MUST implement a “SF OTP device” as

set out in Section 5.1.4 of NIST SP 800-63B.

# A80000OFFICIAL
 A80000OFFICIAL #

4 2 5 If supported, the Applicant MUST implement a “MF OTP device”

as set out in Section 5.1.5 of NIST SP 800-63B.

# A80000OFFICIAL
 A80000OFFICIAL #

4 2 6 If supported, the Applicant MUST implement “SF crypto software”

as set out in Section 5.1.6 of NIST SP 800-63B.

# A80000OFFICIAL
 A80000OFFICIAL #

4 2 7 If supported, the Applicant MUST implement “SF crypto device” as

set out in Section 5.1.7 of NIST SP 800-63B.

4 2 8 If supported, the Applicant MUST implement “MF crypto

software” as set out in Section 5.1.8 of NIST SP 800-63B.

# A80000OFFICIAL
 A80000OFFICIAL #

4 2 9 If supported, the Applicant MUST implement “MF crypto device”

as set out in Section 5.1.9 of NIST SP 800-63B.

4 3 1 The Applicant MUST implement “physical authenticators” as set

out in Section 5.2.1 of NIST SP 800-63B.

# A80000OFFICIAL
 A80000OFFICIAL #

4 3 2 The Applicant MUST implement “rate limiting (throttling)” as set

out in Section 5.2.2 of NIST SP 800-63B.

4 3 3 If biometrics are used for authentication, the Applicant MUST

implement “biometrics (for authentication use)” as set out in
Section 5.2.3 of NIST SP 800-63B.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

4 3 4 The Applicant MUST implement “attestation” as set out in Section

5.2.4 of NIST SP 800-63B.

# A80000OFFICIAL
 A80000OFFICIAL #

4 3 5 The Applicant MUST implement “verifier-impersonation

resistance” as set out in Section 5.2.5 of NIST SP 800-63B.

4 3 6 The Applicant MUST implement “verifier-CSP communications” as

set out in Section 5.2.6 of NIST SP 800-63B.

4 3 7 The Applicant MUST implement “verifier-compromise resistance”

as set out in Section 5.2.7 of NIST SP 800-63B.

# A80000OFFICIAL
 A80000OFFICIAL #

4 3 8 The Applicant MUST implement “replay resistance” as set out in

Section 5.2.8 of NIST SP 800-63B.

4 3 9 The Applicant MUST implement “authentication intent” as set out

in Section 5.2.9 of NIST SP 800-63B.

4 3 10 The Applicant MUST implement “restricted authenticators” as set

out in Section 5.2.10 of NIST SP 800-63B.

# A80000OFFICIAL
 A80000OFFICIAL #

4 4 1 The Applicant MUST implement “authenticator binding” as set out

in Section 6.1 of NIST SP 800-63B.

# A80000OFFICIAL
 A80000OFFICIAL #

4 4 2 The Applicant MUST implement “binding at enrolment” as set out

in Section 6.1.1 of NIST SP 800-63B.

# A80000OFFICIAL
 A80000OFFICIAL #

4 4 3 The Applicant MAY implement “binding of an additional

authenticator at existing AAL” as set out in Section 6.1.2.1 of NIST
SP 800-63B.

4 4 4 The Applicant MAY implement “adding an additional factor to a

single-factor account” as set out in Section 6.1.2.2 of NIST SP 800-
63B.

4 4 5 The Applicant MUST implement “replacement of a lost

authentication factor” as set out in Section 6.1.2.3 of NIST SP 800-
63B.

4 4 6 The Applicant MUST implement “binding to a subscriber-provided

authenticator” as set out in Section 6.1.3 of NIST SP 800-63B.

4 4 7 The Applicant MUST implement “renewal” as set out in Section

6.1.4 of NIST SP 800-63B.

4 5 1 The Applicant MUST implement “loss, theft, damage and

unauthorised duplication” as set out in Section 6.2 of NIST SP 800-
63B.

# A80000OFFICIAL
 A80000OFFICIAL #

4 6 1 The Applicant MUST implement “expiration” as set out in Section

6.3 of NIST SP 800-63B.

4 7 1 The Applicant MUST implement “revocation and termination” as

set out in Section 6.4 of NIST SP 800-63B.

# A80000OFFICIAL
 A80000OFFICIAL #

4 8 1 The Applicant MAY “start a session in response to an

authentication event” as described in Section 7 of NIST SP 800-
63B.

4 8 2 If the Applicant starts a session they MUST implement “session

bindings” as set out in Section 7.1 of NIST SP 800-63B.

4 8 3 The Applicant MAY implement “browser cookies” as set out in

Section 7.1.1 of NIST SP 800-63B.
4 8 4 The Applicant MUST implement “access tokens” as set out in
Section 7.1.2 of NIST SP 800-63B.
4 8 5 The Applicant MUST implement “device identification” as set out
in Section 7.1.3 of NIST SP 800-63B.
4 9 1 The Applicant MUST implement “reauthentication” as set out in
Section 7.2 of NIST SP 800-63B.

# A80000OFFICIAL
 A80000OFFICIAL #

4 10 1 The Applicant MUST achieve all the requirements of the higher

Credential Level.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

2 1 7 The Applicant MUST store any user consent decisions (grant or

deny) that a User makes in relation to sharing attributes from
another Participant with a Relying Party.

# A80000OFFICIAL
 A80000OFFICIAL #

2 1 7 a The Applicant MUST include the following Consent data regarding

a user consent decision:
a) timestamp.
a) Duration of Consent. (including any time limit on the
consent).
b) Relying Party. (i.e. The RP that requested to receive the
attributes).
c) RP Link. (i.e. The link to RP that is authorised to receive the
attributes).
d) IdP/AP from which the attributes were sourced.
e) IdP Link/AP’s RP Link. (i.e. The link to the identity at the
source of the attributes).
f) Name of any attribute or attribute set authorised.
g) Consent decision. This may be “grant”, “deny”, or “ongoing”.

2 1 8 The Applicant MUST store a record of all federated identity

interactions that relate to an individual, including any requests
and responses between a Relying Party and an Identity Exchange,
or an Identity Service Provider and an Identity Exchange.

2 1 8 a The records to be stored in accordance with FED-02-01-08 MUST

include:
a) Timestamp.
a) Interaction type. E.g. OIDC authentication request.
b) Unique interaction identifier. The Identity Exchange will need
to be able to correlate the requests and responses in an
interaction.
c) Entity. An Identity Service Provider or a Relying Party.
d) Entity link. Any identity link used in the interaction, such as
the RP Link or IdP Link.
e) Names of any attributes requested and returned.
f) Any level of assurance requested and returned.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

2 3 1 The Applicant MUST generate Pairwise Identifiers in accordance

section 8.1 of the OpenID Connect Core 1.0 specification
[OpenIDCore] and use these to interact with Relying Parties
regardless of the Federation Protocol the Applicant is using to
communicate with other Participants in the Federation.

2 3 9 The Applicant MAY advertise a maximum length of the Pairwise

Identifiers it generates based on the mechanism it uses.

2 3 10 The Applicant MUST have a process to conduct Deduplication of

identities which pass through an Identity Exchange to ensure that
a User with multiple digital identities is presented as the same
user to a Relying Party.

2 3 11 The Applicant MUST only deduplicate identities which have been

proved to the same Identity Proofing Level.

2 3 21 If the Applicant supports single sign on, it MUST support the

ability for a Relying Party to request Authentication for a particular
User using the method specified in the Federation Protocol being
used. This is termed as known subject authentication.

# A80000OFFICIAL
 A80000OFFICIAL #

2 3 22 If the Applicant supports single sign on, it MUST support the

ability for a Relying Party to request that a user authenticates at
an IdP regardless of whether a session exists. This is known as a
force authentication request.

2 3 23 If the Applicant supports single sign on, it MUST implement a

single log out mechanism according to the Federation Protocol
that it supports.

2 3 25 If the Applicant securely caches attributes as per FED-02-02-22,

these attributes MUST NOT be accessible to the Applicant’s
Personnel.

2 3 26 The Applicant MAY support single sign on.

2 3 27 The Applicant MAY securely cache Attributes from an Identity

Service Provider for the duration of an authenticated session.

2 3 28 The Applicant MAY restrict the expiration period for an

authentication session to manage security risks.

2 3 29 The Applicant MAY implement a single log out mechanism

according to the Federation Protocol that it supports, based on
the needs of the Users and Relying Parties that it will be
supporting.

2 3 30 The Applicant MAY implement a single log out mechanism which

is interoperable with the Federation Protocols used by an Identity
Exchange.

3 2 1 The Applicant MUST maintain a log of any User Consent managed

by the Applicant that enables the sharing of attributes with a
Relying Party.

3 2 2 The Applicant MUST maintain a log of the binding of any

attributes to a Digital Identity brokered by an Identity Exchange.
These logged events must include the value of the RP Audit Id
Attribute received in the response from an Identity Exchange.

3 2 3 The Applicant MUST maintain a log of the retrieval of attributes by

an Identity Exchange or Relying Party, which must include the
value of the RP audit Id Attribute received as part of the request.

4 1 1 The Applicant MUST generate a unique audit Id for an

Authentication Request from a Relying Party.

# A80000OFFICIAL
 A80000OFFICIAL #

4 1 2 The Applicant MUST log all related interactions between Relying

Parties and Identity Service Providers using this unique audit id
(this includes Attribute Service Providers acting as Relying Parties).

4 1 3 The Applicant MUST provide the unique audit id to the Relying

Party using the RP_audit_id Attribute in response to every logical
interaction between a Relying Party (including an Attribute Service
Provider) and an Identity Exchange.

4 1 4 When the Applicant calls an API provided by an Attribute Service

Provider, they MUST include the value of RP Audit ID Attribute
that has been generated by the Identity Exchange for the Relying
Party that requested the Attributes.

4 1 5 The Applicant MUST NOT send the RP Audit Id to an Identity

Service Provider.

4 1 6 The Applicant MUST provide a method for a User to view their

Consumer History and manage their Consent.

4 1 7 The Applicant MUST include in the user’s Consumer History the

history of all the interactions the user has performed via the
Identity Exchange using the Identity Service Provider and enable
the user to view the consent they have provided to share
attributes provided by either an Attribute Service Provider or an
Identity Service Provider with a Relying Party.

4 1 8 The Applicant MUST ensure that the User Dashboard feature does
not store personal Attributes of the User beyond the User’s
presence at the User Dashboard.

4 1 13 The Applicant MUST allow a User to select an Identity Service

Provider when accessing a Relying Party from a list of Identity
Service Providers that are integrated with the Identity Exchange.

4 1 14 The list of Identity Service Providers presented by the Applicant to

the User MUST be capable of meeting the Credential Level and
Identity Proofing Level requested by the Relying Party which
initiated the Authentication Request.

# A80000OFFICIAL
 A80000OFFICIAL #

4 1 15 If the Applicant provides the mechanism specified in FED-04-01-16

then they MUST get Consent for the Applicant to remember an
Identity Service Provider selection, and there must be a
mechanism available for the User to remove the remembered
Identity Service Provider selection.

4 1 16 The Applicant MAY provide a mechanism for a User’s selection of

Identity Service Provider to be remembered so that the User does
not have to select an Identity Service Provider when accessing a
Relying Party.

4 2 1 The Applicant MUST broker Authentication Requests from a

Relying Party to an Identity Service Provider using the following
rules for mapping between Federation Protocols:

4 2 1 a Where the Authentication Request from the Relying Party is made

using OIDC and is brokered to an Identity Service Provider which
uses OIDC to communicate to an Identity Exchange, then the
processing rules specified in section 4.2.2 MUST be applied.

4 2 1 b Where the Authentication Request from the Relying Party is made

using OIDC and is brokered to an Identity Service Provider which
uses SAML to communicate to an Identity Exchange, then the
processing rules specified in section 4.2.3 MUST be applied.

4 2 1 c Where the Authentication Request from the Relying Party is made

using SAML and is brokered to an Identity Service Provider which
uses SAML to communicate to an Identity Exchange, then the
processing rules specified in section 4.2.4 MUST be applied.

4 2 1 d Where the Authentication Request from the Relying Party is made

using SAML and is brokered to an Identity Service Provider which
uses SAML to communicate to an Identity Exchange, then the
processing rules specified in section 4.2.5 MUST be applied.

4 2 3 c If the sub (subject) claim is specified then it MUST be processed as

per 4.2.2.2.

4 2 10 The Applicant MUST evaluate the ACR returned from the Identity
Service Provider and if the ACR meets or exceeds the originally
requested value, return the originally requested value.

# A80000OFFICIAL
 A80000OFFICIAL #

4 2 13 The Applicant MAY include an ID Token previously issued by the

Identity Exchange in the Authentication Request to identify a
specific User that requires Authentication.

4 2 14 The Applicant MAY include the resolved subject identifier

previously received from the Identity Service Provider in the
Authentication Request to the Identity Service Provider using the
sub (subject) claim.

4 2 19 The Applicant MUST evaluate the <saml:AuthnContextClassRef>

returned from the Identity Service Provider and if the
<saml:AuthnContextClassRef> meets or exceeds the originally
requested ACR value, return the originally requested value.

5 1 1 The Applicant MUST support the sharing of all Attributes

described in section 3.1 of [TDIF.Attr].

5 1 2 The Applicant MUST provide any Attributes requested by an

Identity Exchange if those Attributes are listed as mandatory in
section 3.1 of the TDIF: 06D - Attribute Profile.

5 1 3 The Applicant MAY provide an Attribute listed as optional in

section 3.1 of TDIF: 06D - Attribute Profile if requested to do so by
an Identity Exchange.

5 1 4 The Applicant MUST be able to share all Attributes listed as

mandatory in section 3.2 of the TDIF: 06D - Attribute Profile if the
Attributes are requested by an Identity Exchange.

5 1 6 The Applicant MUST support the sharing of all Attributes

described in section 3.3 of TDIF: 06D - Attribute Profile.

# A80000OFFICIAL
 A80000OFFICIAL #

5 1 7 The Applicant MUST support the sharing of all Attributes

described in section 3.5 of TDIF: 06D - Attribute Profile.

5 2 2 The Applicant MUST support additional computed attributes

described in section 3.4 of the TDIF: 06D - Attribute Profile.

5 3 1 The Applicant MAY support the sharing of Attributes an Attribute

Service Provider is accredited to provide. These Attributes are
defined in section 5 of the TDIF: 06D - Attribute Profile.

5 3 2 The Applicant MUST ensure that it only shares, or provides to an

Identity Exchange to be shared, Attributes that are relevant to the
Relying Party requesting the Attributes.

5 4 1 The Applicant MUST only share Attributes with Relying Parties in

accordance with the Attribute Sharing Policy specified for the
Attribute Set which an Attribute is part of as described in section
2.2 of the TDIF: 06D - Attribute Profile.

5 5 1 When passing Attributes to other Participants in the Identity

Federation, the Applicant MUST use the attribute data
representation for Attributes specified in section 6 of the TDIF:
06D - Attribute Profile.

# A80000OFFICIAL
 A80000OFFICIAL #

Colour Key

Changed

New

Archived

# A80000OFFICIAL
 A80000OFFICIAL #

TDIF Requirement Subsectio Requirement Text

Require n
ments
Section Requirement Subsection TDIF: 03 - Accreditation Process
ACCRED ACCRED-03-01-01 3.3.1 The Applicant MUST formally request TDIF
accreditation by submitting to the DTA a
completed TDIF Application Letter and response to
the TDIF Statement of Claims

ACCRED ACCRED-03-01-01a 4.3.1 All information provided to the DTA for the
purpose of TDIF accreditation MUST be in English .

ACCRED ACCRED-03-01-01b 4.3.1 The Applicant MUST have a registered and active
ABN.

ACCRED ACCRED-03-01-02 4.3.1 The TDIF Application Letter MUST specify

Accredited Roles being sought, or a combination of
these.

ACCRED ACCRED-03-01-02a 4.3.1 The TDIF Application Letter MUST specify the
assurance levels supported by their identity
service. For Identity Service Providers this means
Identity Proofing Levels. For Credential Service
Providers this means Credential Levels .

# A80000OFFICIAL
 A80000OFFICIAL #

ACCRED ACCRED-03-01-02b 4.3.1 The TDIF Application Letter MUST specify whether
the identity system supports web responsive
design, mobile apps or a combination of these.
This information will determine the scope of the
Accessibility Assessment.

ACCRED ACCRED-03-01-02c 4.3.1 The TDIF Application Letter MUST specify whether
the Applicant is seeking to connect to the
Australian Government’s identity federation

ACCRED ACCRED-03-01-03 4.3.1 The Application Letter MUST include a Statement

of Applicability which describes the scope of the
Applicant’s identity system.

ACCRED ACCRED-03-01-03a 4.3.1 At a minimum, the Statement of Applicability

MUST:

The Statement of Applicability forms the basis of

the Applicant’s Functional Assessments.

ACCRED ACCRED-03-01-03a 4.3.1

# A80000OFFICIAL
 A80000OFFICIAL #

ACCRED ACCRED-03-01-03a 4.3.1

ACCRED ACCRED-03-01-03a 4.3.1

ACCRED ACCRED-03-01-03b 4.3.1 For multi-entity identity systems, the Statement of

Applicability MUST also include all fraud control,
privacy, protective security, and user experience
controls which directly contribute to meeting TDIF
requirements.

ACCRED ACCRED-03-01-04 4.3.1 The TDIF Application Letter MUST include an

accreditation schedule which at a minimum
includes:

ACCRED ACCRED-03-01-04 4.3.1

ACCRED ACCRED-03-01-04 4.3.1

ACCRED ACCRED-03-01-04a 4.3.1 The TDIF Application Letter MUST propose a

commencement date and a date by which TDIF
accreditation is anticipated .

ACCRED ACCRED-03-01-05 4.3.1 The TDIF Application Letter MUST include the
names and contact details of people responsible
within the Applicant’s organisation(s) to manage
their TDIF accreditation .

# A80000OFFICIAL
 A80000OFFICIAL #

ACCRED ACCRED-03-01-06 4.3.1 The TDIF Application Letter MAY include any
relevant TDIF Exemption Requests in accordance
with the process set out in Appendix A: TDIF
exemption process.

ACCRED ACCRED-03-01-06a 4.3.1 Each TDIF Exemption Request MUST include all
information as described in Appendix A: TDIF
exemption process.

ACCRED ACCRED-03-01-07 4.3.1 The Applicant MAY include a copy of prior audit
work which it requests the DTA consider as a
substitute for relevant Functional Assessments.

ACCRED ACCRED-03-01-07a 4.3.1 Any request made to the DTA to consider prior
audit work MUST include:

ACCRED ACCRED-03-01-07a 4.3.1

# A80000OFFICIAL
 A80000OFFICIAL #

ACCRED ACCRED-03-01-07a 4.3.1

# A80000OFFICIAL
 A80000OFFICIAL #

0 TDIF: 04 - Functional Requirements

Chapter 1 Fraud Requirements
4.2.1 2.1 Accountable Authority
FRAUD FRAUD-02-01-01 4.2.1 The Applicant MUST appoint a senior executive as
the designated Accountable Authority for
managing fraud risks within its organisation.

# A80000OFFICIAL
 A80000OFFICIAL #

FRAUD FRAUD-02-01-02 4.2.1 The Accountable Authority MUST:

FRAUD FRAUD-02-01-02 4.2.1

FRAUD FRAUD-02-01-02 4.2.1

FRAUD FRAUD-02-01-02 4.2.1

FRAUD FRAUD-02-01-02 4.2.1

FRAUD FRAUD-02-01-03 4.2.1 Where exceptional circumstances prevent or affect

the Applicant’s capability to implement a TDIF
requirement, the Accountable Authority:

FRAUD FRAUD-02-01-03 4.2.1

4.2.2 2.2 Fraud control plan

FRAUD FRAUD-02-02-01 4.2.2 The Applicant MUST have in place a Fraud Control
Plan approved by the Accountable Authority to
manage the Applicant’s fraud risks.

# A80000OFFICIAL
 A80000OFFICIAL #

FRAUD FRAUD-02-02-01a 4.2.2 The Fraud Control Plan MUST detail the:

Where a single fraud control plan is not practicable

due to the Applicant’s side or complexity of
business, the Accountable Authority may approve
a strategic-level overarching fraud control plan
that addresses the requirements listed above.

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

# A80000OFFICIAL
 A80000OFFICIAL #

FRAUD FRAUD-02-02-02 4.2.2 The Fraud Control Plan (and supporting Fraud
Control Plans) MUST be reviewed annually by the
Applicant’s Accountable Authority and when there
is a change in the ownership, structure, functions
or activities of the Applicant which may impact the
operation of the fraud control components of their
identity system.

FRAUD FRAUD-02-02-02a 4.2.2 This review MUST:

FRAUD FRAUD-02-02-02a 4.2.2

# A80000OFFICIAL
 A80000OFFICIAL #

4.2.3 2.3 Fraud prevention, awareness and training

FRAUD FRAUD-02-03-01 4.2.3 The Applicant MUST provide all Personnel with
fraud awareness training at engagement and
annually thereafter. A copy of these training
materials will be requested by the DTA as part of
initial accreditation and annually thereafter as part
of the Annual Assessment.

FRAUD FRAUD-02-03-02 4.2.3 The Applicant MUST demonstrate to the DTA how
it considers the risk of fraud when planning and
conducting activities associated with the operation
of its identity system.

FRAUD FRAUD-02-03-03 4.2.3 The Applicant MUST maintain appropriately

documented instructions and procedures to assist
personnel prevent, detect, report and deal with
fraud.

FRAUD FRAUD-02-03-04 4.2.3 The Applicant MUST ensure Personnel primarily

engaged in fraud control activities possess or attain
relevant qualifications or training.

FRAUD FRAUD-02-03-05 4.2.3 The Applicant MUST conduct background checks

on individuals prior to their commencement of
employment with the Applicant and on Personnel
with access to Personal information.

FRAUD FRAUD-02-03-06 4.2.3 The Applicant MUST provide fraud-control advice

to Users on how to safeguard their Digital Identity
and Attributes.

FRAUD FRAUD-02-03-07 4.2.3 Where identity-related scams are detected, the

Applicant MUST provide advice to Individuals on
how to avoid being scammed.

# A80000OFFICIAL
 A80000OFFICIAL #

4.2.4 2.4 Fraud monitoring and detection

FRAUD FRAUD-02-04-01 4.2.4 The Applicant MUST implement a mechanism for
detecting incidents of fraud or suspected fraud,
including a process for Personnel and users to
report suspected fraud confidentially.

FRAUD FRAUD-02-04-02 4.2.4 The Applicant MUST implement a fraud control

mechanism to flag incidents of fraud or suspected
fraud.

FRAUD FRAUD-02-04-02a 4.2.4 The Applicant MUST compare all new registrations
and updates to existing records against the fraud
control mechanism used to flag incidents of fraud
or suspected fraud.

FRAUD FRAUD-02-04-02b 4.2.4 The Applicant MUST NOT allow a new registration
or update to be completed if the fraud control
mechanism indicates the registration or update is
fraudulent or suspected fraud.

4.2.5 2.5 Incident management, investigations and

reporting

# A80000OFFICIAL
 A80000OFFICIAL #

FRAUD FRAUD-02-05-01 4.2.5 The Applicant MUST implement a mechanism for

investigating or otherwise dealing with incidents of
fraud or suspected fraud.

FRAUD FRAUD-02-05-02 4.2.5 The Applicant MUST maintain documented

procedures setting out criteria for making
decisions at critical stages in managing a suspected
fraud incident.

FRAUD FRAUD-02-05-03 4.2.5 The Applicant MUST have in place investigation

and referral processes and procedures that are
consistent with the AGIS.

FRAUD FRAUD-02-05-04 4.2.5 The Applicant MUST document decisions to use

civil, administrative or disciplinary procedures, or
to take no further action in response to a
suspected fraud incident.

FRAUD FRAUD-02-05-05 4.2.5 The Applicant MUST take responsibility for

investigating instances of fraud or suspected fraud
against it, including investigating disciplinary
matters, unless the matter is referred to and
accepted by the Australian Federal Police (AFP) or
another law enforcement agency.

FRAUD FRAUD-02-05-06 4.2.5 Where a law enforcement agency declines a

referral, the Applicant MUST resolve the matter in
accordance with relevant internal and external
requirements.

# A80000OFFICIAL
 A80000OFFICIAL #

FRAUD FRAUD-02-05-07 4.2.5 The Applicant MUST refer all instances of potential
or serious or complex fraud offences to the AFP in
accordance with the AGIS and AFP referral process,
except in the following circumstances:
a) Where legislation sets out specific alternative
arrangements.
b) Where the Applicant:
i. Has the capacity and the appropriate skills and
resources needed to investigate potential criminal
matters.
ii. Meets the requirements of the AGIS for
gathering evidence and the Commonwealth
Director of Public Prosecutions (CDPP) in preparing
briefs of evidence.

FRAUD FRAUD-02-05-07 4.2.5

FRAUD FRAUD-02-05-07 4.2.5

FRAUD FRAUD-02-05-08 4.2.5 Fraud investigations MUST be carried out by

appropriately qualified Personnel as set out in the
AGIS. If external investigators are engaged, they
must as a minimum meet the investigations
competency requirements set out in the AGIS.

FRAUD FRAUD-02-05-09 4.2.5 The Applicant MUST take all reasonable measures
to recover financial losses caused by illegal activity
through proceeds of crime and civil recovery
processes or administrative remedies.

FRAUD FRAUD-02-05-10 4.2.5 The Applicant MUST develop and use procedures
to report incidents of fraud or suspected fraud to
the DTA.

FRAUD FRAUD-02-05-10a 4.2.5 As soon as they become aware the Applicant

MUST report incidents of fraud or suspected fraud
to the DTA.

# A80000OFFICIAL
 A80000OFFICIAL #

FRAUD FRAUD-02-05-10b 4.2.5 The Applicant MUST include the following

information when reporting on incidents of fraud
or suspected fraud:

Depending on the nature of the fraud incident and

legal advice obtained, the DTA may advise
impacted stakeholders of the outcome of a fraud
investigation.

FRAUD FRAUD-02-05-10b 4.2.5

FRAUD FRAUD-02-05-10b 4.2.5

FRAUD FRAUD-02-05-10b 4.2.5

FRAUD FRAUD-02-05-10b 4.2.5

FRAUD FRAUD-02-05-10b 4.2.5

FRAUD FRAUD-02-05-10b 4.2.5

4.2.6 2.6 Support for victims of identity fraud

FRAUD FRAUD-02-06-01 4.2.6 The Applicant MUST implement a process which

allows Users to notify it when they suspect or
become aware of fraudulent use of their
Attributes, Digital Identity or Credentials.

# A80000OFFICIAL
 A80000OFFICIAL #

FRAUD FRAUD-02-06-02 4.2.6 The Applicant MUST provide (either directly or

through a third party) support services to Users
whose Attributes, Digital Identity or Credential
have been compromised.

FRAUD FRAUD-02-06-03 4.2.6 The Applicant MUST have in place processes such
as appropriate identification of an Individual
whose Attributes, Digital Identity or Credential has
been compromised and appropriate technologies
to enable the applicant to flag the Attributes,
Digital Identity or Credential as compromised.

FRAUD FRAUD-02-06-04 4.2.6 The Applicant MUST prevent the fraudulent use of
a User’s Attributes, Digital Identity or Credentials
(including continued fraudulent activity) once the
Applicant suspects or it becomes aware of the
fraudulent use.

FRAUD FRAUD-02-06-05 4.2.6 When an Individual is identified by the Applicant as

a victim of fraud, or the Individual self-identifies,
their existing record MUST be reproofed to the
highest Identity Proofing Level which they have
previously met.

Chapter 2 Privacy Requirements

4.3.1 3.1 General privacy requirements
PRIV PRIV-03-01-01 4.3.1 The Applicant MUST comply with its obligations
under the Privacy Act, including the Australian
Privacy Principles (APPs), and Australian
Government Agencies Privacy Code or, where
relevant, state or territory privacy legislation.

PRIV PRIV-03-01-02 4.3.1 If the Applicant is a small business operator as

defined by the Privacy Act, and therefore exempt
from the Privacy Act, it MUST opt-in to coverage of
the APPs as an organisation.

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-01-03 4.3.1 Any state or territory government Applicant not

covered by state privacy laws or not prescribed
under s6F of the Privacy Act 1988 MUST comply
with APPs for the purpose of achieving and
maintaining TDIF accreditation.

PRIV PRIV-03-02-01 4.3.2 The Applicant MUST have at least one designated
Privacy Officer who is the primary point of contact
for advice on privacy matters.

PRIV PRIV-03-02-01a 4.3.2 The Applicant MUST demonstrate how the

following Privacy Officer functions are carried out:

PRIV PRIV-03-02-01a 4.3.2

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-02-01a 4.3.2

PRIV PRIV-03-02-01a 4.3.2

PRIV PRIV-03-02-01a 4.3.2

PRIV PRIV-03-02-01a 4.3.2

4.3.2 3.2 Privacy governance

PRIV PRIV-03-02-02 4.3.2 The Applicant MUST have at least one designated
Privacy Champion.

PRIV PRIV-03-02-02a 4.3.2 The Applicant MUST demonstrate how its Privacy
Champion promotes a culture of privacy that
values and protects Personal information.

PRIV PRIV-03-02-02b 4.3.2 The Applicant MUST demonstrate how its Privacy
Champion approves its Privacy Management Plan,
and reviews of the Applicant’s progress against the
Privacy Management Plan.

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-02-03 4.3.2 The Applicant MUST publish a clearly expressed

and up to date Privacy Policy about the
management of Personal information by the
entity.

PRIV PRIV-03-02-03a 4.3.2 The Applicant MUST have a separate Privacy Policy
in relation to its identity system to that of its other
business, organisation functions or Accredited
Roles.

PRIV PRIV-03-02-03b 4.3.2 The Applicant MUST maintain separate Privacy

Policies for their Identity Service Provider and
Identity Exchange if they are accredited in both
roles (i.e. a Privacy Policy for their Identity Service
Provider and a separate Privacy Policy for their
Identity Exchange).

PRIV PRIV-03-02-04 4.3.2 The Applicant’s Privacy Policy MUST include

information on:

PRIV PRIV-03-02-04 4.3.2

PRIV PRIV-03-02-04 4.3.2

PRIV PRIV-03-02-04 4.3.2

PRIV PRIV-03-02-04 4.3.2

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-02-04 4.3.2

PRIV PRIV-03-02-05 4.3.2 The Applicant’s Accountable Authority MUST

review the Privacy Policy which covers its identity
system at least annually.

PRIV PRIV-03-02-06 4.3.2 The Applicant’s Accountable Authority MUST

develop and maintain a Privacy Management Plan
that identifies measurable privacy goals and
targets for its identity system and the practices,
procedures and systems that will be implemented
to achieve these targets and goals.

PRIV PRIV-03-02-07 4.3.2 The Applicant’s Accountable Authority MUST

measure and document its performance against
the Privacy Management Plan relevant to TDIF at
least annually.

PRIV PRIV-03-02-08 4.3.2 The Applicant MUST on an annual basis, provide

privacy awareness training which incorporates
these TDIF privacy requirements, to all Personnel
that access the Applicant’s identity system. A copy
of these training materials will be requested by the
DTA as part of initial accreditation and annually
thereafter as part of the Annual Assessment.

PRIV PRIV-03-02-09 4.3.2 The privacy awareness training provided by the

Applicant, MUST cover the Applicant’s Privacy
Policy and include the TDIF privacy requirements.

4.3.3 3.3 Privacy Impact Assessment

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-03-01 4.3.3 The Applicant MUST maintain a register of the PIAs
it conducts.

PRIV PRIV-03-03-01a 4.3.3 The Applicant MUST publish the register, or a

version of the register, on its website.
4.3.4 3.4 Data Breach Response Management
PRIV PRIV-03-04-01 4.3.4 An Applicant, covered by the Privacy Act, MUST
report eligible data breaches to affected
individuals and the Information Commissioner as
required under the Privacy Act and also report the
eligible data breach to the DTA.

PRIV PRIV-03-04-01a 4.3.4 An Applicant, not covered by the Privacy Act,

MUST report eligible data breaches as defined in
the Privacy Act 1988 to affected individuals and
the DTA.

PRIV PRIV-03-04-02 4.3.4 The Applicant MUST develop and maintain a Data
Breach Response Plan that includes a description
of the actions to be taken if a breach is suspected,
discovered, or reported by Personnel or external
party, including a clear communication plan and
information about when it is to be escalated to the
data breach response team or third party.

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-04-03 4.3.4 The Data Breach Response Plan MUST:

PRIV PRIV-03-04-03 4.3.4

PRIV PRIV-03-04-03 4.3.4

4.3.5 3.5 Notification of Collection

PRIV PRIV-03-05-01 4.3.5 The Applicant MUST notify or make people aware
as required by APP 5.
PRIV PRIV-03-05-02 4.3.5 The Applicant MUST include a statement in their
privacy notices advising that the Applicant may use
the Individual’s information as required by the
TDIF, including to detect, manage and investigate
fraud.

4.3.6 3.6 Collection and use limitation

PRIV PRIV-03-06-01 4.3.6 The Applicant MUST only collect Personal
information that it is permitted to collect under
law and that is reasonably necessary for one or
more of its functions or activities directly relating
to identity verification.

PRIV PRIV-03-06-02 4.3.6 The Applicant MUST only collect Personal

information by lawful and fair means.
PRIV PRIV-03-06-03 4.3.6 The Applicant MUST only collect Personal
information from the Individual or their
representative, unless it is unreasonable or
impractical to do so.

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-06-04 4.3.6 The Applicant MUST NOT use Personal information
for direct marketing purposes as defined in APP 7.

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-06-05 4.3.6 The Applicant MUST publish in an open and

accessible manner an Annual Transparency Report
that discloses the scale, scope and reasons for
access to Personal information (including
metadata) by an enforcement body, as defined in
the Privacy Act.

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-06-06 4.3.6 The Applicant MUST NOT retain Users’ Attributes
once they are passed from an Identity Service
Provider to a Relying Party with the exception of
securely storing the attributes for the duration of
an authenticated session.

4.3.7 3.7 Limitation on use of behavioural information

PRIV PRIV-03-07-01 4.3.7 The Applicant MUST only collect, use and disclose
an Individual’s Behavioural Information to:

PRIV PRIV-03-07-01 4.3.7

PRIV PRIV-03-07-01 4.3.7

PRIV PRIV-03-07-01 4.3.7

PRIV PRIV-03-07-01a 4.3.7 The Applicant MUST NOT sell an Individual’s

Behavioural information to a third party.

4.3.8 3.8 Collection and disclosure of biometrics

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-08-01 4.3.8 The Applicant MUST only collect Sensitive

information (including Biometric information) as
outlined in APP 3.3 and 3.4.

PRIV PRIV-03-08-02 4.3.8 Biometric information collected to for the purpose

of proofing an Individual’s Identity MUST be
destroyed once the Biometric information has
been used to verify that identity (for example it
has been matched against a source photograph),
unless:

PRIV PRIV-03-08-02 4.3.8

PRIV PRIV-03-08-02 4.3.8

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-08-03 4.3.8 Biometric information collected to prove an

Individual’s Identity MUST NOT be used and
disclosed for purposes other than those listed in
TDIF Req: PRIV-03-08-02.

4.3.9 3.9 Express Consent

PRIV PRIV-03-09-01 4.3.9 The Applicant MUST ensure Express Consent is
obtained from an Individual prior to disclosing that
individual’s Attributes to a Relying Party or any
third party.

PRIV PRIV-03-09-01 4.3.9 The Applicant MUST ensure Express Consent is

obtained from an Individual prior to disclosing that
individual’s Attributes to a Relying Party or any
third party.

PRIV PRIV-03-09-01 4.3.9 The Applicant MUST ensure Express Consent is

obtained from an Individual prior to disclosing that
individual’s Attributes to a Relying Party or any
third party.

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-09-01 4.3.9 The Applicant MUST ensure Express Consent is

obtained from an Individual prior to disclosing that
individual’s Attributes to a Relying Party or any
third party.

PRIV-03-09-01a 4.3.9 This requirement has been archived in version 1.2.

PRIV PRIV-03-09-02 4.3.9 The Applicant MUST allow an Individual to

withdraw their Express Consent.
PRIV PRIV-03-09-02a 4.3.9 The Applicant MUST demonstrate how this Express
Consent withdrawal process is straightforward and
easy to use.

PRIV PRIV-03-09-02b 4.3.9 An Individual MUST be made aware of the

implications of providing or withdrawing their
Express Consent.

PRIV PRIV-03-09-03 4.3.9 The Applicant MUST maintain Audit Logs that
demonstrate how Express Consent was obtained
from the Individual.

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-09-03a 4.3.9 The Audit Logs MUST NOT contain Biometric
information.
PRIV PRIV-03-09-04 4.3.9 The Applicant MUST inform Individuals of other
channels available to verify Identity and make clear
to the User what the consequences are of
declining to provide Express Consent or the
required information.

PRIV PRIV-03-09-05 4.3.9 The Applicant MUST obtain Express Consent to

disclose and verify Identity Attributes with an
Authoritative Source. For example, through an
Identity Matching Service.

4.3.10 3.10 Cross border and contractor disclosure of

Personal information
PRIV PRIV-03-10-01 4.3.10 The Applicant MUST demonstrate how it complies
with APP 8 - cross border disclosure of Personal
information.

PRIV PRIV-03-10-02 4.3.10 The Applicant MUST take reasonable steps to

ensure an overseas recipient of Personal
information used by the Applicant to provide its
identity system only uses the Personal information
disclosed to it for purposes directly related to
identity verification.

PRIV PRIV-03-10-02a 4.3.10 If it discloses Personal information to an overseas

recipient that is not the individual, the Applicant
MUST demonstrate to the DTA’s reasonable
satisfaction it has appropriate contractual and
practical measures to ensure the overseas
recipient complies with these TDIF privacy
requirements.

4.3.11 3.11 Government Identifiers

PRIV PRIV-03-11-01 4.3.11 The Applicant MUST NOT create a new
government identifier for use across the identity
federation (i.e. an identifier that is sent to more
than one Relying Party or Identity Service
Provider).

4.3.12 3.12 Access, correction and individual history log

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-12-01 4.3.12 The Applicant MUST on request by an Individual,

give that Individual access to the Personal
information it holds about the Individual, unless an
exception is available under APP 12 (APP 12.2 for
Commonwealth agencies and APP 12.3 for other
Applicants).

PRIV PRIV-03-12-02 4.3.12 The Applicant MUST respond to a request for

access to Personal information that it holds from
an individual within 30 days after the request is
received.

PRIV PRIV-03-12-03 4.3.12 The Applicant MUST give the Individual access to
their Personal information in the manner
requested by the Individual, if it is reasonable,
secure and practicable to do so.

PRIV PRIV-03-12-04 4.3.12 The Applicant MUST provide access at no cost to

the Individual.
PRIV PRIV-03-12-05 4.3.12 The Applicant MUST, where access is refused, take
steps to meet the needs of the Individual and
provide a written notice as set out in APP 12.

PRIV PRIV-03-12-06 4.3.12 The Applicant MUST allow Individuals to correct

their Personal information it holds as set out in
APP 13.

PRIV PRIV-03-12-07 4.3.12 The Applicant MUST provide Individuals with a

simple and accessible means to access and review
their Personal information.

PRIV PRIV-03-12-07a 4.3.12 The Applicant MUST provide Individuals with a

channel to update their Personal information in
near to real time.

PRIV PRIV-03-12-08 4.3.12 The Applicant MUST provide Individuals with a

centralised view of the metadata of services the
Individual accessed, the time of access and the
Attributes passed to the Relying Party unless such
information has already been destroyed by the
Applicant in accordance with the TDIF.

4.3.13 3.13 Quality of personal information

PRIV PRIV-03-13-01 4.3.13 An Applicant MUST take reasonable steps to
ensure quality of Personal information as outlined
in APP 10.

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-13-02 4.3.13 The Applicant MUST implement internal practices,

procedures and systems (including training
Personnel in these practices, procedures and
systems) to audit, monitor, identify and correct
poor-quality Personal information.

PRIV PRIV-03-13-03 4.3.13 The Applicant MUST ensure updated or new

Personal information is promptly added to relevant
existing records.

4.3.14 3.14 Handling Privacy Complaints

PRIV PRIV-03-14-01 4.3.14 The Applicant MUST provide a complaints service
for handling privacy complaints which:

PRIV PRIV-03-14-01 4.3.14

PRIV PRIV-03-14-01 4.3.14

PRIV PRIV-03-14-01 4.3.14

PRIV PRIV-03-14-01 4.3.14

4.3.15 3.15 Destruction and de-identification

PRIV PRIV-03-15-01 4.3.15 The Applicant MUST demonstrate it takes
reasonable steps to destroy or de-identify Personal
information in line with APP 11.2.

Chapter 4 Protective Security Requirements

4.4.1 4.1 Security governance
PROT PROT-04-01-01 4.4.1 The Applicant MUST appoint a senior executive as
the designated Accountable Authority for
managing security risks within their organisation.

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-01-02 4.4.1 The Accountable Authority MUST:

PROT PROT-04-01-02 4.4.1

PROT PROT-04-01-02 4.4.1

PROT PROT-04-01-02 4.4.1

PROT PROT-04-01-03 4.4.1 Where exceptional circumstances prevent or affect

the Applicant’s capability to implement a TDIF
requirement, the Accountable Authority:

PROT PROT-04-01-03 4.4.1

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-01-04 4.4.1 The Accountable Authority MUST appoint a Chief

Security Officer (CSO) at a management level to be
responsible for security in the Applicant’s
organisation.

PROT PROT-04-01-04a 4.4.1 The Accountable Authority MUST empower the

CSO or equivalent role to make decisions about:

PROT PROT-04-01-04a 4.4.1

PROT PROT-04-01-04a 4.4.1

PROT PROT-04-01-04a 4.4.1

PROT PROT-04-01-05 4.4.1 The Accountable Authority MUST ensure

Personnel are aware of their collective
responsibility to foster a positive security culture
and are provided sufficient information and
training to support this.

PROT PROT-04-01-05a 4.4.1 The CSO or equivalent role MUST be responsible

for directing all areas of security to protect the
Applicant’s Personnel, Information, ICT and assets.
This includes appointing security advisors to
support them in the day-to-day deliver of
protective security and to perform specialist
services as required.

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-01-06 4.4.1 The Applicant MUST develop and use procedures
that ensure:

PROT PROT-04-01-07 4.4.2

PROT PROT-04-01-08 4.4.3

PROT PROT-04-01-07 4.4.1 The Applicant MUST provide all Personnel with
security awareness training at engagement and
annually thereafter. A copy of these training
materials will be requested by the DTA as part of
initial accreditation and annually thereafter as part
of the Annual Assessment.

PROT PROT-04-01-08 4.4.1 The Applicant MUST maintain appropriately

documented instructions and procedures to assist
Personnel prevent, detect, report and deal with
security risks.

PROT PROT-04-01-09 4.4.1 The Applicant MUST provide Personnel in specialist

and high-risk positions (including contractors and
security incident investigators) with specific
security awareness training targeted to the scope
and nature of the position.

PROT PROT-04-01-010 4.4.1 The Applicant MUST maintain a monitored email

address as a central conduit for all security-related
matters across governance, Personnel,
information, ICT and physical security.

PROT PROT-04-01-011 4.4.1 The Applicant MUST provide security advice to

users on how to safeguard their Digital Identity,
Credentials, Personal information and Attributes.

PROT PROT-04-01-12 4.4.1 The Applicant MUST have in place a System

Security Plan approved by the Accountable
Authority to manage the Applicant’s security risks.

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-01-12a 4.4.1 The System Security Plan MUST include:

Where a Single Security Plan is not practicable due

to the Applicant’s side or complexity of business,
the Accountable Authority may approve a
strategic-level overarching System Security Plan
that addresses the requirements listed above.

PROT PROT-04-01-12a 4.4.1

PROT PROT-04-01-12a 4.4.1

PROT PROT-04-01-12a 4.4.1

PROT PROT-04-01-12a 4.4.1

PROT PROT-04-01-12a 4.4.1

PROT PROT-04-01-12a 4.4.1

PROT PROT-04-01-12a 4.4.1

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-01-12a 4.4.1

PROT PROT-04-01-13 4.4.1 The System Security Plan (and supporting System
Security Plans) MUST be reviewed annually by the
Applicant’s Accountable Authority and when there
is a change in the ownership, structure, functions
or activities of the Applicant which may impact the
operation of the protective security components of
their identity system.

PROT PROT-04-01-13a 4.4.1 This review MUST:

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-01-13a 4.4.1

PROT PROT-04-01-14 4.4.1 The Applicant MUST identify Personnel,

information, ICT and assets that are critical to the
ongoing operation of the Applicant’s identity
system and apply appropriate protections to these
resources to support their operation.

PROT PROT-04-01-15 4.4.1 The Applicant MUST identify a risk steward (or
manager) who is responsible for each security risk
or category of security risk, including for shared
risks.

PROT PROT-04-01-16 4.4.1 When conducting a Security assessment, the

Applicant MUST communicate to the affected
organisation any identified risks that could
potentially impact on their business operations.

PROT PROT-04-01-17 4.4.1 The System Security Plan (and supporting System
Security Plans) MUST include scalable measures to
meet variations in threat levels and accommodate
changes in the National Terrorism Threat Level.

PROT PROT-04-01-18 4.4.1 Where the CSO (or security advisor on behalf of
the CSO) implements an alternative mitigation
measure or control to a TDIF requirement, they
MUST document the decision and adjust the
maturity level for the related TDIF requirement.
These decisions will be requested by the DTA
during Annual Assessments.

PROT PROT-04-01-19 4.4.1 The Applicant MUST assess the maturity of its
security capability and risk culture by considering
its progress against goals and strategic objectives
identified in its System Security Plan.

PROT PROT-04-01-19a 4.4.1 The Applicant MUST document and present

evidence of their security maturity to the DTA.

4.4.2 4.2 Information security

PROT PROT-04-02-01 4.4.2 The Applicant MUST:

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-02-01 4.4.2

PROT PROT-04-02-01 4.4.2

PROT PROT-04-02-02 4.4.2 The Applicant MUST ensure information it holds is

stored, transferred, transmitted and disposed of
securely in a manner that meet the minimum
protection requirements set out in the PSPF . This
includes ensuring Sensitive information is
appropriately destroyed or archived when it has
passed minimum retention requirements or
reaches authorised destruction dates.

PROT PROT-04-02-03 4.4.2 The Applicant MUST enable appropriate access to

information. This includes:

PROT PROT-04-02-03 4.4.2

PROT PROT-04-02-03 4.4.2

PROT PROT-04-02-04 4.4.2 To manage access to information systems holding

Sensitive information, the Applicant MUST
implement unique User identification,
authentication and authorisation practices on each
occasion where system access is granted.

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-02-05 4.4.2 The Applicant MUST mitigate common and

emerging cyber threats by implementing the ASD
Strategies to Mitigate Cyber Security Incidents.

PROT PROT-04-02-05a 4.4.2 The Applicant MAY consider implementing

additional ASD Strategies to Mitigate Cyber
Security Incidents.

PROT PROT-04-02-06 4.4.2 The Applicant MUST NOT expose the public to
unnecessary security risks when transacting online.

PROT PROT-04-02-07 4.4.2 The Applicant MUST implement a mechanism for

detecting Cyber security incidents, including a
process for Personnel and Users to report
suspected Cyber security incidents confidentially.

PROT PROT-04-02-08 4.4.2 The Applicant MUST implement a control

mechanism to flag Cyber security incidents.

PROT PROT-04-02-08a 4.4.2 The Applicant MUST compare all new registrations
and updates to existing records against the control
mechanism used to flag Cyber security incidents.

PROT PROT-04-02-08b 4.4.2 The Applicant MUST NOT allow a new registration
or update to be completed if the control
mechanism indicates the registration or update
will create a Cyber security incident.

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-02-09 4.4.2 The Applicant MUST maintain documented

procedures setting out criteria for making
decisions at critical stages in managing Cyber
security incidents.

PROT PROT-04-02-10 4.4.2 The Applicant MUST take responsibility for

investigating Cyber security incidents, including
investigating disciplinary matters, unless the
matter is referred to and accepted by the AFP or
another law enforcement agency.

PROT PROT-04-02-11 4.4.2 Where a law enforcement agency declines a

referral, the Applicant MUST resolve the matter in
accordance with relevant internal and external
requirements.

PROT PROT-04-02-12 4.4.2 The Applicant MUST refer all instances of potential
or serious or complex security offences to the AFP
in accordance with the AGIS and AFP referral
process, except in the following circumstances:

PROT PROT-04-02-12 4.4.2

PROT PROT-04-02-12 4.4.2

PROT PROT-04-02-13 4.4.2 Security investigations MUST be carried out by

appropriately qualified personnel as set out in the
AGIS. If external investigators are engaged, they
must as a minimum meet the investigations
competency requirements set out in the AGIS.

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-02-14 4.4.2 The Applicant MUST take all reasonable measures
to recover financial losses caused by illegal activity
through proceeds of crime and civil recovery
processes or administrative remedies.

PROT PROT-04-02-15 4.4.2 The Applicant MUST develop and use procedures
to report Cyber security incidents to the DTA.

PROT PROT-04-02-15a 4.4.2 As soon as they become aware the Applicant

MUST report Cyber security incidents to the DTA.

PROT PROT-04-02-15b 4.4.2 The Applicant MUST include the following

information when reporting Cyber security
incidents:

Depending on the nature of the Cyber security

incident and legal advice sought, the DTA may
advise impacted stakeholders of the outcome of a
security investigation.

PROT PROT-04-02-15b 4.4.2

PROT PROT-04-02-15b 4.4.2

PROT PROT-04-02-15b 4.4.2

PROT PROT-04-02-15b 4.4.2

PROT PROT-04-02-15b 4.4.2

PROT PROT-04-02-16 4.4.2 The Applicant MUST develop and use procedures
to report significant Cyber security incidents to the
relevant authority or affected entity as described
in the PSPF.

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-02-17 4.4.2 The Applicant MUST implement a process which

allows users to notify them when they suspect or
become aware of a Cyber Security Incident.

PROT PROT-04-02-18 4.4.2 The Applicant MUST provide (either directly or

through a third party) support services to Users
who are impacted by Cyber security incidents.

PROT PROT-04-02-19 4.4.2 The Applicant MUST have in place processes such
as appropriate identification of an Individual
whose Attributes, Digital Identity or Credential has
been subject to a Cyber Security Incident and
appropriate technologies to enable the Applicant
to flag the Attributes, Digital Identity or Credential
as compromised.

PROT PROT-04-02-20 4.4.2 The Applicant MUST prevent the continued use of
a User’s Attributes, Digital Identity or Credentials
once the Applicant suspects or it becomes aware it
has been subject to a Cyber Security Incident.

PROT PROT-04-02-20a 4.4.2 When an Individual is identified by the Applicant as

a victim of a Cyber Security Incident, or the
Individual self-identifies, their existing EoI
documents MUST be reproofed to the highest
Identity Proofing Level which they have previously
met.

PROT PROT-04-02-20b 4.4.2 When an Individual is identified by the Applicant as

a victim of a Cyber Security Incident, or the
Individual self-identifies, their Credential MUST be
reverified to the highest Credential Level which
they have previously met.

PROT PROT-04-02-20c 4.4.2 When an Individual is identified by the Applicant as

a victim of a Cyber Security Incident, or the
Individual self-identifies, their Attributes MUST be
reverified.

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-02-21 4.4.2 The Applicant MUST have in place secure

measures during all stages of ICT systems
development. This includes certifying and
accrediting ICT systems in accordance with the ISM
(or a similar process for non-government
Applicants) when implemented into the
operational environment.

PROT PROT-04-02-22 4.4.2 When establishing new ICT systems or

implementing improvements to current ICT
systems (including software development), the
Applicant MUST address security in the early
phases of the system’s development life cycle. This
includes during the system concept development
and planning phases, and then in the requirements
analysis and design phases.

PROT PROT-04-02-23 4.4.2 The Applicant MUST NOT process, store or

communicate Sensitive information on an ICT
system, unless the residual security risks to the
system and information have been recognised and
accepted by the Accountable Authority, CSO or a
security advisor on behalf of the CSO.

PROT PROT-04-02-24 4.4.2 The Applicant MUST ensure their ICT systems
(including software) incorporate processes for
generating Audit Logs.

PROT PROT-04-02-24a 4.4.2 At a minimum, Audit Logs MUST include the

following activities:

PROT PROT-04-02-24a 4.4.2

PROT PROT-04-02-24a 4.4.2

PROT PROT-04-02-24a 4.4.2

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-02-24b 4.4.2 At a minimum, Audit Logs for an activity MUST

include :

Further guidance on events to log is available in

the ISM.

PROT PROT-04-02-24b 4.4.2

PROT PROT-04-02-24b 4.4.2

PROT PROT-04-02-24b 4.4.2

PROT PROT-04-02-24b 4.4.2

PROT PROT-04-02-24b 4.4.2

PROT PROT-04-02-24b 4.4.2

PROT PROT-04-02-24b 4.4.2

PROT PROT-04-02-24b 4.4.2

PROT PROT-04-02-24b 4.4.2

PROT PROT-04-02-24c 4.4.2 Audit logs MUST include:

PROT PROT-04-02-24c 4.4.2

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-02-24d 4.4.2 Audit Logs MUST include:

PROT PROT-04-02-24d 4.4.2

PROT PROT-04-02-24e 4.4.2 Audit Logs MUST include:

PROT PROT-04-02-24e 4.4.2

PROT PROT-04-02-24e 4.4.2

PROT PROT-04-02-24e 4.4.2

PROT PROT-04-02-24e 4.4.2

PROT PROT-04-02-24e 4.4.2

PROT PROT-04-02-24f 4.4.2 Audit Logs MUST include the following events:

PROT PROT-04-02-24f 4.4.2

PROT PROT-04-02-25 4.4.2 Audit Logs MUST be:

PROT PROT-04-02-25 4.4.2

PROT PROT-04-02-25 4.4.2

PROT PROT-04-02-25 4.4.2

PROT PROT-04-02-26 4.4.2 The Applicant MUST maintain a Disaster Recovery

and Business Continuity Plan for its identity system
that covers:

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-02-26 4.4.2

PROT PROT-04-02-26 4.4.2

PROT PROT-04-02-26 4.4.2

PROT PROT-04-02-26 4.4.2

PROT PROT-04-02-27 4.4.2 The Applicant MUST test their Disaster Recovery
and Business Continuity Plan annually. The DTA
will request evidence of as part of accreditation
and during Annual Assessments.

PROT PROT-04-02-28 4.4.2 The Applicant MUST use:

• Australian Signals Directorate Approved
Cryptographic Algorithms (AACAs).
• Australian Signals Directorate Approved
Cryptographic Protocols (AACPs).
To protect information while in transit and at rest.

PROT PROT-04-02-29 4.4.2 The Applicant MUST maintain a Cryptographic Key

Management Plan for their identity system which
covers:

PROT PROT-04-02-29 4.4.2

PROT PROT-04-02-29 4.4.2

PROT PROT-04-02-29 4.4.2

PROT PROT-04-02-29 4.4.2

4.4.3 4.3 Personnel security

PROT PROT-04-03-01 4.4.3 The Applicant MUST ensure the eligibility and
suitability of its Personnel who have access to
information, ICT and assets which support the
operation of their identity service.

PROT PROT-04-03-02 4.4.3 The Applicant MUST undertake pre-employment

screening on people, including:
a) Verifying Identity using the Document
Verification Service.

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-03-02 4.4.3

PROT PROT-04-03-03 4.4.3 The Applicant MUST assess and manage the
ongoing suitability of its Personnel.
PROT PROT-04-03-04 4.4.3 The Applicant MUST ensure that separating
Personnel have their access to the Applicant’s
resources withdrawn, including:

PROT PROT-04-03-04 4.4.3

PROT PROT-04-03-05 4.4.3 Prior to Personnel separation or transfer, the
Applicant MUST ensure the CSO, or relevant
security advisor is advised of any proposed
cessation of employment resulting from
misconduct or other adverse reasons.

PROT PROT-04-03-05a 4.4.3 Where it is not possible to undertake required

separation procedures, the Applicant MUST
undertake a risk assessment to identify any
security implications.

4.4.4 4.4 Physical security

PROT PROT-04-04-01 4.4.4 The Applicant MUST implement physical security
measures that minimise or remove the risk of:

PROT PROT-04-04-01 4.4.4

PROT PROT-04-04-02 4.4.4 The Applicant MUST protect its resources

commensurate with the assessed business impact
level of their compromise, loss or damage.

PROT PROT-04-04-03 4.4.4 The Applicant MUST assess security risks and
select appropriate containers, cabinets, secure
rooms and strong rooms to protect information
and assets.

PROT PROT-04-04-04 4.4.4 The Applicant MUST dispose of physical assets

securely.
Chapter 5 Usability Requirements
4.5.1 5.1 Usability requirements

# A80000OFFICIAL
 A80000OFFICIAL #

UX UX-05-01-01 4.5.1 The Applicant MUST demonstrate how Users can

also use other available channels if needed,
without repetition or confusion.

UX UX-05-01-02 4.5.1 The Applicant MUST demonstrate how Users with

low digital skills can have readily available access
to Assisted Digital support.

UX UX-05-01-03 4.5.1 The Applicant MUST demonstrate how its identity

system is built with responsive design methods to
support common devices, browsers and assistive
technologies, including desktop and mobile
devices.

UX UX-05-01-04 4.5.1 The Applicant MUST allow Users to provide

feedback, seek assistance or otherwise resolve
disputes or complaints in relation to the
Applicant’s identity system.

UX UX-05-01-05 4.5.1 The Applicant MUST create and maintain an

individual end-to-end journey map for its identity
system.

UX UX-05-01-05a 4.5.1 Where the Applicant cannot support a User’s

technology preference, the individual journey map
MUST indicate how an Individual can use an
alternative channel to complete a specific activity.

UX UX-05-01-06 4.5.1 The Applicant MUST ensure information it provides

to Users is available in multiple accessible formats,
including accessible online formats (such as HTML),
large print format, Easy English, and braille (on
request).

UX UX-05-01-07 4.5.1 The Applicant MUST provide Users with

uncomplicated ways to learn about its identity
system on digital channels.

4.5.2 5.2 Requirements for the identity verification

journey
UX UX-05-02-01 4.5.2 The Applicant MUST provide Users with
information about the entire identity management
process, including what to expect in each step of
the individual journey and what they will need to
do in order to complete each step.

# A80000OFFICIAL
 A80000OFFICIAL #

UX UX-05-02-02 4.5.2 The Applicant MUST provide Users with

information on technical requirements for using
the Applicant’s identity system (for example,
requirements for internet access, or access to a
mobile phone or webcam).

UX UX-05-02-03 4.5.2 The Applicant MUST provide Users with

information on the required Identity documents,
whether each piece is mandatory, and the
consequences for not providing the complete set
of required documents. Individuals need to know
the specific combinations of identity documents.

UX UX-05-02-04 4.5.2 If a code or number is issued by the Applicant to a

User as part of the identity verification process, the
Applicant MUST notify the User in advance that
they will receive a digital code or number and what
to do with it.

UX UX-05-02-05 4.5.2 The Applicant MUST advise the User whether the
identity verification process has been successfully
completed.

UX UX-05-02-05a 4.5.2 If verification is successful, the Applicant MUST

send the User confirmation regarding the
successful verification and information on next
steps.

UX UX-05-02-05b 4.5.2 If verification is partially complete, the Applicant

MUST communicate to the User what information
will be discarded.

# A80000OFFICIAL
 A80000OFFICIAL #

UX UX-05-02-05c 4.5.2 If verification is unsuccessful, the Applicant MUST

provide the User with information for alternative
options, for example, offering an over-the-counter
identity verification process if they were unable to
complete the digital identity verification process.

UX UX-05-02-06 4.5.2 The Applicant MUST provide support to Users who

need assistance during the identity verification
process.

UX UX-05-02-07 4.5.2 The Applicant MUST provide support to Users who

do not have the technology or capacity to create a
Digital Identity. For example, by providing support
via a shopfront, a call centre that is contactable via
the National Relay Service, or through a text-based
support such as an online chat window.

UX UX-05-02-08 4.5.2 The Applicant MUST provide clear instructions to a

User on how they can update their Personal
information collected as part of the identity
verification process.

4.5.3 5.3 Requirements for the authentication journey

UX UX-05-03-01 4.5.3 The Applicant MUST provide Users with relevant

information for the use and maintenance of their
Credential. For example, this may include
instructions for use, information on Credential
expiry, and what to do if the Credential is
forgotten, lost or stolen.

UX UX-05-03-02 4.5.3 The Applicant MUST enable Users to recover a

Credential if it has been lost or forgotten.
Additionally, the recovery mechanism must be as
strong as the initial Credential provisioning
process.

4.5.4 5.4 Usability test plans

# A80000OFFICIAL
 A80000OFFICIAL #

UX UX-05-04-01 4.5.4 The Applicant MUST document, by way of a

Usability Test Plan, how it will conduct usability
testing.

UX UX-05-04-01a 4.5.4 The Applicant’s Usability Test Plan MUST:

UX UX-05-04-01a 4.5.4

UX UX-05-04-01a 4.5.4

UX UX-05-04-01a 4.5.4

# A80000OFFICIAL
 A80000OFFICIAL #

UX UX-05-04-01a 4.5.4

UX UX-05-04-01a 4.5.4

UX UX-05-04-01b 4.5.4 The range of representative Individuals MUST

include:
UX UX-05-04-01b 4.5.4
UX UX-05-04-01b 4.5.4

UX UX-05-04-01b 4.5.4

UX UX-05-04-01b 4.5.4

UX UX-05-04-01b 4.5.4

UX UX-05-04-01b 4.5.4

UX UX-05-04-01b 4.5.4

UX UX-05-04-01c 4.5.4 The range of representative Individuals MUST be

gender neutral.

4.5.5 5.5 Conduct usability testing

UX UX-05-05-01 4.5.5 The Applicant MUST use experienced User
Researchers to conduct usability testing of its
identity service. For the purpose of this
requirement, an experienced User Researcher is
highly skilled in identifying individual needs,
conducting usability tests, and feeding insights
back to the product team.

UX UX-05-05-02 4.5.5 The Applicant MUST conduct usability testing on

its identity system as part of initial accreditation
and annually thereafter as part of the Annual
Assessment.

# A80000OFFICIAL
 A80000OFFICIAL #

UX UX-05-05-03 4.5.5 The Applicant MUST conduct usability testing of its

identity system from end to end, in an
environment that replicates its live environment
with a range of representative Individuals.

UX UX-05-05-04 4.5.5 The Applicant MUST document the outcomes of its

usability testing, including test methodology(s),
test results, findings and recommendations.

UX UX-05-05-04a 4.5.5 The Applicant MUST provide the outcomes of its

usability testing to the DTA as part of initial
accreditation and annually thereafter as part of the
Annual Assessment.

4.5.6 5.6 Accessibility requirements

UX UX-05-06-01 4.5.6 The Applicant’s identity system MUST be
presented in a clear and concise manner, using
plain language that is easy to understand and
accessible across all devices.

Chapter 6 Technical Testing Requirements

4.6.1 6.1 Technical test planning

# A80000OFFICIAL
 A80000OFFICIAL #

TEST TEST-06-01-01 4.6.1 The Applicant MUST develop at least one Technical
Test Plan which covers the testing of all applicable
TDIF requirements (i.e. at a minimum the TDIF
requirements set out at TEST-06-01-04).

TEST TEST-06-01-02 4.6.1 The Applicant MUST include the content described
in Table 1 in Technical Test Plan and provide a copy
of the Technical Test Plan to the DTA as part of
initial accreditation.

TEST TEST-06-01-03 4.6.1 The Applicant MUST agree on test completion

criteria with the DTA prior to commencing
technical testing.

TEST TEST-06-01-04 4.6.1 The Applicant MUST demonstrate through testing

how its identity system meets the following TDIF
requirements:

TEST TEST-06-01-04 4.6.1

TEST TEST-06-01-04 4.6.1

TEST TEST-06-01-04 4.6.1

TEST TEST-06-01-04 4.6.1

# A80000OFFICIAL
 A80000OFFICIAL #

TEST TEST-06-01-04 4.6.1

TEST TEST-06-01-04 4.6.1

TEST TEST-06-01-05 4.6.1 The Applicant MUST demonstrate through testing

how its identity system meets the following TDIF
requirements:

TEST TEST-06-01-05 4.6.1

TEST TEST-06-01-06 4.6.1 The Applicant MUST demonstrate through testing

of all verification methods and Identity Proofing
Levels its identity system supports as well as its
Step-Up process if this is also supported.

TEST TEST-06-01-07 4.6.1 The Applicant MUST demonstrate through testing

all Credential Levels and Credentials its identity
system supports as well as its Step-Up process if
this is also supported.

TEST TEST-06-01-08 4.6.1 The Applicant MUST develop a Requirements

Traceability Matrix (RTM) which maps test cases to
requirements, which MUST include all
requirements the Applicant is required to do
technical testing for.

# A80000OFFICIAL
 A80000OFFICIAL #

4.6.2 6.2 Technical testing

TEST TEST-06-02-01 4.6.2 The Applicant MUST be satisfied of the following
prior to commencement of test execution:

TEST TEST-06-02-01 4.6.2

TEST TEST-06-02-01 4.6.2

TEST TEST-06-02-01 4.6.2

TEST TEST-06-02-01 4.6.2

TEST TEST-06-02-02 4.6.2 The Applicant MUST assess and report execution
coverage for each test case during the testing
process.

TEST TEST-06-03-01 4.6.3 For test completion the Applicant MUST complete
a Technical Test Report and provide this to the
DTA as part of initial accreditation.

4.6.3 6.3 Technical test completion

TEST TEST-06-03-02 4.6.3 The Applicant’s Technical Test Report MUST
include:

TEST TEST-06-03-02 4.6.3

TEST TEST-06-03-02 4.6.3

Chapter 7 Functional Assessments

4.7.1 7.1 PIA and Privacy Assessment

# A80000OFFICIAL
 A80000OFFICIAL #

ASSESS ASSESS-07-01-01 4.7.1 The Applicant MUST commission an Assessor to

conduct a Privacy Impact Assessment on their
identity system as part of accreditation.

ASSESS ASSESS-07-01-02 4.7.1 Once accredited, the Applicant MUST conduct a

Privacy Impact Assessment on all high-risk projects
related to their identity system.

ASSESS ASSESS-07-01-03 4.7.1 The Privacy Impact Assessment conducted MUST:

ASSESS ASSESS-07-01-03 4.7.1

ASSESS ASSESS-07-01-03 4.7.1

ASSESS ASSESS-07-01-03 4.7.1

ASSESS ASSESS-07-01-03 4.7.1

ASSESS ASSESS-07-01-03 4.7.1

ASSESS ASSESS-07-01-03 4.7.1

ASSESS ASSESS-07-01-03 4.7.1

# A80000OFFICIAL
 A80000OFFICIAL #

ASSESS ASSESS-07-01-03 4.7.1

ASSESS ASSESS-07-01-04 4.7.1 The Applicant’s identity system MUST undergo a
Privacy Assessment (which is separate to and
follows on from the PIA) as part of initial
accreditation and annually thereafter as part of the
Annual Assessment.

4.7.2 7.2 Security assessment and penetration test

ASSESS ASSESS-07-02-01 4.7.2 The Applicant’s identity system MUST undergo a

Security assessment by one or more Assessors (or
IRAP Assessor or other security professional) to
identify security deficiencies as part of initial
accreditation and annually thereafter as part of the
Annual Assessment.

ASSESS ASSESS-07-02-02 4.7.2 The Applicant’s identity system MUST undergo a

Penetration test as part of each major production
release during initial accreditation and annually
thereafter as part of the Annual Assessment.

ASSESS ASSESS-07-02-02a 4.7.2 For multi-entity systems the scope of the

Penetration test MUST include all security controls
which contribute to meeting the TDIF protective
security requirements.

4.7.3 7.3 Accessibility assessment

# A80000OFFICIAL
 A80000OFFICIAL #

ASSESS ASSESS-07-03-01 4.7.3 The Applicant’s identity system MUST commission

an Assessor to conduct an Accessibility Assessment
and, at a minimum:
• meet WCAG version 2.0 to the AA standard for
web-based identity services
• meet WCAG version 2.1 to the AA standard for
mobile-based identity services
as part of initial accreditation and annually
thereafter as part of the Annual Assessment.

4.7.4 7.4 Applicant obligations

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

ASSESS ASSESS-07-04-01 4.7.4 The Applicant MUST undergo each Functional

Assessment.

# A80000OFFICIAL
 A80000OFFICIAL #

ASSESS ASSESS-07-04-02 4.7.4 The Applicant MUST define the scope , objectives
and criteria for each Functional Assessment.

4.7.5 7.5 Assessor skills, experience, and independence

# A80000OFFICIAL
 A80000OFFICIAL #

ASSESS ASSESS-07-05-01 4.7.5 The Applicant MUST demonstrate to the DTA how
the Assessors have relevant, reasonable and
adequate experience, training and qualifications to
conduct the Functional Assessment.

ASSESS ASSESS-07-05-02 4.7.5 The Applicant MUST demonstrate to the DTA how
the Assessors:
• Are independent from the development and
operational teams of the Applicant’s identity
system.
• Do not possess a conflict of interest in
performing the Functional Assessment on the
Applicant’s identity system.

4.7.6 7.6 Assessment process

ASSESS ASSESS-07-06-01 4.7.6 The Applicant MUST ensure Assessors have access
to and consider all relevant evidence provided by
the Applicant to the DTA. This includes any
responses by the DTA to questions which may have
been asked.

ASSESS ASSESS-07-06-02 4.7.6 The Applicant MUST ensure Assessors conduct the
Functional Assessments.
ASSESS ASSESS-07-06-03 4.7.6 The Applicant MUST use the compliance ratings
listed in ‘Appendix A: Compliance ratings’ when
determining areas of compliance and non-
compliance with the requirements of the TDIF.

ASSESS ASSESS-07-06-04 4.7.6 The Functional Assessments MUST include:

# A80000OFFICIAL
 A80000OFFICIAL #

ASSESS ASSESS-07-06-04 4.7.6

ASSESS ASSESS-07-06-04 4.7.6

ASSESS ASSESS-07-06-05 4.7.6 The Functional Assessment MAY include a site visit
to the Applicant’s premises or other location
where it provides services in connection with its
identity system.

4.7.7 7.7 Functional Assessment Report

ASSESS ASSESS-07-07-01 4.7.7 The Applicant MUST ensure the Assessors

document the outcomes of the assessment in a
Functional Assessment Report.

ASSESS ASSESS-07-07-01a 4.7.7 The Applicant’s Accountable Authority MUST

respond in writing, to the recommendations
outlined in the Functional Assessment Report
including whether the recommendations are
accepted, the reasons for any non-acceptance and
the timeframe for implementation of the
recommendations.

ASSESS ASSESS-07-07-02 4.7.7 The Applicant’s Functional Assessment Report

MUST include:

ASSESS ASSESS-07-07-02 4.7.7

ASSESS ASSESS-07-07-02 4.7.7

# A80000OFFICIAL
 A80000OFFICIAL #

ASSESS ASSESS-07-07-02 4.7.7

ASSESS ASSESS-07-07-02 4.7.7

ASSESS ASSESS-07-07-02 4.7.7

ASSESS ASSESS-07-07-02 4.7.7

ASSESS ASSESS-07-07-02 4.7.7
ASSESS ASSESS-07-07-02 4.7.7
ASSESS ASSESS-07-07-02 4.7.7

ASSESS ASSESS-07-07-02 4.7.7

ASSESS ASSESS-07-07-02 4.7.7

# A80000OFFICIAL
 A80000OFFICIAL #

ASSESS ASSESS-07-07-03 4.7.7 The Applicant MUST:

• Provide a copy of the full findings and report
to the DTA, or
• Enable the DTA access to a copy of the
findings and report.
An executive summary or redacted version of the
findings or Functional Assessment Report is
insufficient to meet this requirement.

0 TDIF: 05 - Role Requirements

Chapter 2 Common Role Requirements
ROLE ROLE-02-01-01 5.2.1 The Applicant MUST have user terms that include:

ROLE ROLE-02-01-01 5.2.1

ROLE ROLE-02-01-01 5.2.1

ROLE ROLE-02-01-01 5.2.1

ROLE ROLE-02-01-01 5.2.1

ROLE ROLE-02-01-01 5.2.1

# A80000OFFICIAL
 A80000OFFICIAL #

ROLE ROLE-02-01-01 5.2.1

ROLE ROLE-02-01-01 5.2.1

ROLE ROLE-02-01-01 5.2.1

ROLE ROLE-02-01-01 5.2.1

ROLE ROLE-02-01-02 5.2.1 The Applicant MUST have user terms, including:

# A80000OFFICIAL
 A80000OFFICIAL #

ROLE ROLE-02-01-02 5.2.1

ROLE ROLE-02-01-03 5.2.1 The Applicant MUST have user terms, including:

ROLE ROLE-02-01-03 5.2.1

ROLE ROLE-02-01-03 5.2.1

ROLE ROLE-02-01-04 5.2.1 The Applicant MUST have user terms, including:

ROLE ROLE-02-01-04 5.2.1

# A80000OFFICIAL
 A80000OFFICIAL #

ROLE ROLE-02-01-04 5.2.1

ROLE ROLE-02-01-04 5.2.1

ROLE ROLE-02-01-05 5.2.1 The Applicant MUST have user terms, including:

ROLE ROLE-02-01-05 5.2.1

ROLE ROLE-02-01-05 5.2.1

ROLE ROLE-02-01-05 5.2.1

ROLE ROLE-02-01-05 5.2.1

ROLE ROLE-02-01-06 5.2.1 The Applicant MUST NOT have user terms that are
inconsistent with the user terms required under
the TDIF.

ROLE-02-02-01 5.2.2 This requirement has been archived in version 1.7.

ROLE-02-02-01a 5.2.2 This requirement has been archived in version 1.7.

ROLE-02-02-01a 5.2.2 This requirement has been archived in version 1.7.

Chapter 2 Identity Service Provider Requirements

5.3.2 Section 3.2 Identity Proofing

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-02-01 5.3.2 At a minimum, the Applicant MUST operate a TDIF

accredited identity system at Identity Proofing
level 1 Plus as described in Table 1 below . [Table
1 of TDIF: 05 Role Requirements]

IDP IDP-03-02-02 5.3.2 For each supported Identity Proofing Level, the
Applicant MUST implement it as described in Table
1 below. [Table 1 of TDIF: 05 Role Requirements]

5.3.3 3.3 Individuals unable to meet Identity Proofing

Requirements
IDP IDP-03-03-01 5.3.3 The Applicant MAY implement alternative Identity
Proofing processes to the requirements set out in
Table 1 to support exceptions cases. [Table 1 of
TDIF: 05 Role Requirements]

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-03-01a 5.3.3 The alternative Identity Proofing processes MAY

include:
• Acceptance of alternative types of EoI (for
example, evidence of the operation of an Identity
in a non-Australian community over time.
• Verification of an Individual’s claimed Identity
with a trusted referee whose Identity has been
verified to an equal or greater Identity Proofing
Level.
• Verification of an Individual’s claimed Identity
with reputable organisations or bodies known to
them (for example, Aboriginal and Torres Strait
Islander organisations may hold, or be able to
verify, the Identity of Individuals where no prior
government record exists).
• Reliance on the Identity Proofing processes of
other organisations that have verified the Identity
of the Individual (i.e. Known Customer)
• A detailed interview with the Individual about
their life story to assess the consistency and
legitimacy of their claims.
• Alternative methods of providing Attributes or
Identity Documents (such as the provision of
certified copies by trusted third parties instead of
attending an in-person interview where an
Individual can demonstrate they live in a very
remote area).
• Providing support for Individuals to obtain
evidence (such as assisting the Individual to
register their birth with a RBDM)
• Any other processes or approaches supported
by the IdP consistent with requirement IDP-03-03-
01b

IDP IDP-03-03-01b 5.3.3 All alternative Identity Proofing processes an

Applicant implements to support exceptions cases
MUST be informed by a risk assessment. Evidence
of these alternative processes and risk assessment
will be requested by the DTA as part of initial
accreditation and annually thereafter as part of the
Annual Assessment.

5.3.4 3.4 Identity proofing lifecycle management

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-04-01 5.3.4 The Applicant MUST allow Individuals to update

their Attributes held by the Applicant.

IDP IDP-03-04-01a 5.3.4 The Applicant MUST verify updates to the

Individual’s Identity prior to making changes to the
Individual’s Digital Identity. This includes any
status changes made to the Individual’s Digital
Identity (e.g. temporary suspension or
reactivation).

IDP IDP-03-04-01b 5.3.4 Where unusual transactions are detected the

Applicant MUST verify the Digital Identity is still
under the control of its legitimate account holder.

IDP IDP-03-04-02 5.3.4 When requested to do so, the Applicant MUST

prevent the continued use of a Digital Identity (e.g.
temporary suspension while traveling abroad).

IDP IDP-03-04-02a 5.3.4 The Applicant MUST confirm the legitimacy of any
request by a User to prevent the continued use of
their Digital Identity in accordance with IDP-03-04-
02, prior to preventing the continued use of that
Digital Identity.

IDP IDP-03-04-02b 5.3.4 The Applicant MUST notify the User that a Digital
Identity can no longer be used in accordance with
IDP-03-04-02 and the reason why it can no longer
be used (e.g. deactivated, suspended, etc).

# A80000OFFICIAL
 A80000OFFICIAL #

5.3.5 3.5 Identity proofing Step-Up

IDP IDP-03-05-01 5.3.5 The Applicant MUST achieve all the requirements
of the higher Identity Proofing Level.

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-05-02 5.3.5 The Applicant MUST ensure that an Individual can
prove ownership of their existing Identity by
authenticating with their Credential to their
account prior to commencing the Identity Proofing
Step-Up process.

5.3.6 3.6 Attribute collection, verification and validation

IDP IDP-03-06-01 5.3.6 The Applicant MUST NOT collect, verify or validate
Attributes beyond those listed in Table 2 and Table
3. [Table 2 and 3 of TDIF: 05 Role Requirements]

IDP-03-06-02 5.3.6 This requirement This requirement has been

archived in version 1.7.

IDP-03-06-03 5.3.6 This requirement This requirement has been

archived in version 1.7.

IDP-03-06-04 5.3.6 This requirement This requirement has been

archived in version 1.7.

5.3.7 3.7 Attribute disclosure

IDP IDP-03-07-01 5.3.7 In accordance with PRIV-03-09-05, the Applicant
MUST limit this disclosure to Attributes listed in
Table 2

IDP-03-07-01a 5.3.7 This requirement This requirement has been

archived in version 1.7.

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-07-02 5.3.7 In accordance with PRIV-03-09-01, the Applicant

MUST limit this disclosure to the following
Attributes:
• Identity attributes (verified) listed in Table 2.
• Contact attributes (validated) listed in Table 2.
• Identity system metadata listed in Table 2.
• Assumed self-asserted Attributes listed in
Table 3.

IDP IDP-03-07-03 5.3.7 The Applicant MUST seek permission from the DTA
to disclose Attributes beyond those listed in IDP-
03-07-02.

IDP IDP-03-07-03a 5.3.7 The Applicant MUST NOT disclose Attributes

beyond those listed in IDP-03-07-02 unless
approved by the DTA to do so.

5.3.8 3.8 Biometric verification requirements

5.3.8.1
3.8.1 Requirements for online Biometric Binding
5.3.8.1

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-08-01 5.3.8.1 The Applicant MUST restrict access to the control
of any aspects of the Biometric Capability
exclusively to Assessing Officers that have
completed the appropriate training pertaining to
the exercise of such control.

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-08-02 5.3.8.1 To complete Online Biometric binding the

Applicant MUST either:

IDP IDP-03-08-02 5.3.8.1

IDP IDP-03-08-03 5.3.8.1 The Applicant MUST incorporate presentation

attack detection when performing Online
Biometric binding.

IDP IDP-03-08-04 5.3.8.1 The Applicant MUST complete the image capture
and presentation attack detection processes as
part of the same process before submission to
Online Biometric binding. This is to prevent attacks
that would exploit the separation of the
presentation attack detection and the image
acquisition.

5.3.8.2 3.8.2 Requirements for Presentation Attack

Detection

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-08-05 5.3.8.2 The Applicant MUST employ presentation attack

detection technology to determine if the Acquired
image is of a living human subject present at the
point of capture.

IDP IDP-03-08-06 5.3.8.2 The Applicant MUST include liveness detection

processes as part of presentation attack detection.

IDP IDP-03-08-07 5.3.8.2 The Applicant MUST employ presentation attack

detection technology that includes data capture
and system level monitoring as described by ISO
30107-1.

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-08-08 5.3.8.2 The Applicant MUST ensure that the presentation
attack detection technology meets the
requirements of at least Evaluation Assurance
Level 1 as described by ISO 30107-3.

IDP IDP-03-08-08a 5.3.8.2 If the comprehensive risk assessment undertaken

by the Applicant indicates that the presentation
attack detection technology used in the capability
must exceed these standards, the Applicant MUST
meet the requirements described in the risk
assessment.

IDP IDP-03-08-09 5.3.8.2 The Applicant capability MUST have been tested
by a qualified third-party testing entity with
experience in biometric testing and ISO 30107 to
determine that the presentation attack detection
technology meets the requirements for at least
Evaluation Assurance Level 1 of ISO 30107-3.

IDP IDP-03-08-09a 5.3.8.2 The Applicant MUST have determined

presentation attack detection outcomes in a
trusted computing environment.

IDP IDP-03-08-09b 5.3.8.2 All testing performed MUST have been performed
on a solution that incorporates all hardware and
software involved in the biometric binding process
including the presentation attack detection
technology and biometric matching.

IDP IDP-03-08-09c 5.3.8.2 Any determinations made by manual processes

MUST be recorded separately to the biometric
matching or presentation attack detection
systems.

IDP IDP-03-08-10 5.3.8.2 The Applicant MUST provide a report to the DTA as
part of initial accreditation from the qualified third-
party testing entity outlining that the Applicant’s
presentation attack detection technology has been
suitably tested to the specifications of at least
Evaluation Assurance Level 1 of ISO 30107-3.

IDP IDP-03-08-10a 5.3.8.2 The report MUST describe the completed

presentation attack detection evaluation and
corresponding results for each presentation attack
type with the closest possible adherence to
reporting specifications as described in ISO 30107-
3.

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-08-10b 5.3.8.2 The report MUST be completed annually

thereafter and provided to the DTA as part of the
Annual Assessment.

5.3.8.3 3.8.3 Requirements for Document Biometric

Matching

IDP IDP-03-08-11 5.3.8.3 The Applicant MUST verify the authenticity of the
image read from the Photo ID RFID chip according
to the Photo ID Issuing Authority instructions.

IDP IDP-03-08-12 5.3.8.3 The Applicant MUST only process Claimed Photo ID
through document biometric matching that
contain a government issued and cryptographically
signed image, such as an ePassport.

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-08-13 5.3.8.3 The Applicant MUST use a biometric matching

algorithm to perform one-to-one verification
matching between the Acquired image and the
Photo ID image.

IDP IDP-03-08-14 5.3.8.3 The Applicant MUST NOT use a biometric matching
algorithm to perform one-to-many matching
against a database of reference images as part of
the biometric binding process.

IDP IDP-03-08-15 5.3.8.3 The Applicant MUST ensure their biometric

matching algorithm is tested by a qualified third-
party testing entity to determine the failure to
enroll rate (if applicable), failure to acquire rate,
false match rate and false non-match rate of the
capability as per the reporting specification
described in ISO 19795.

IDP IDP-03-08-15a 5.3.8.3 This MUST be tested under production-like

conditions.
IDP IDP-03-08-15b 5.3.8.3 The minimum number of subjects for the testing
MUST be at least the same as described in current
published version of the FIDO Biometric
Requirements .

IDP IDP-03-08-15c 5.3.8.3 The testing MUST be performed in a verification

scenario with comparable image types to
production expectations.

IDP IDP-03-08-16 5.3.8.3 The Applicant MUST achieve a false match rate
equivalent to or lower than FIDO Biometric
Requirements. This requires a false match rate of
not more than 0.01% and a false non-match rate of
not more than 3%.

IDP IDP-03-08-16a 5.3.8.3 The Applicant MUST record biometric matching

outcomes in a trusted computing environment.

5.3.8.4 3.8.4 Photo ID specific requirements

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-08-17 5.3.8.4 Where the Photo ID used has an RFID chip that is
available and functional, the Applicant MUST
perform a biometric match of the Acquired image
only against the image read directly from the
Photo ID RFID chip.

IDP IDP-03-08-17a 5.3.8.4 Where an RFID chip is not available, the Photo ID
image used for biometric matching MUST NOT be
from a scan of a physical document.

IDP IDP-03-08-18 5.3.8.4 Where the Photo ID used is an Australian

ePassport, the Applicant MUST check the Country
Signing Certification Authority (CSCA) Certificate as
per the International Civil Aviation Organization
(ICAO) document validation guidelines OR perform
a DVS check. Where the Australian ePassport
security certificate is checked, the Australian
Certificate Revocation List must also be checked.

IDP IDP-03-08-18a 5.3.8.4 Where an RFID chip is not available, non-functional

or the document security is lower than that of the
Australian ePassport, a DVS check MUST be
performed by the Applicant.

IDP IDP-03-08-18b 5.3.8.4 A DVS check MUST be performed by the Applicant

where the Photo ID used is a foreign ePassport to
ensure that the foreign ePassport is linked to a
current visa.

IDP IDP-03-08-18c 5.3.8.4 Where the Photo ID used is a foreign ePassport

and an RFID chip is not available or non-functional
the Applicant MUST attempt to perform a
biometric match against the corresponding image
recorded against that identity from the Photo ID
Authoritative Source.

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-08-18d 5.3.8.4 Where the Photo ID used is a foreign ePassport

and an RFID chip is not available or non-functional
and the corresponding image recorded against
that identity from the Photo ID Authoritative
Source is unavailable, the Applicant MUST perform
Local Biometric binding.

5.3.8.5 3.8.5 Image quality specific requirements

IDP IDP-03-08-19 5.3.8.5 The Applicant MUST produce an Acquired image

quality profile informed by the properties and
characteristics described by ISO 29794-5 which
details a set of minimum standards that the
Acquired image must meet before biometric
matching.

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-08-20 5.3.8.5 The Applicant MUST include automated quality

controls and appropriate user-interface
instructions that directs Users to provide an image
that meets the Acquired image quality profile.

5.3.8.6
3.8.6 Requirements for Local Biometric Binding

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-08-21 5.3.8.6 The Applicant MAY perform source biometric

matching to supplement Manual Face Comparison
by performing a biometric match against the
corresponding image recorded against that
identity from the Photo ID Authoritative Source.

IDP IDP-03-08-22 5.3.8.6 The Applicant MUST perform a DVS check as part
of the Local Biometric binding process to confirm
the authenticity of a Photo ID.

IDP IDP-03-08-23 5.3.8.6 The Applicant MUST train relevant Assessing

Officer’s on Manual Face Comparison techniques
including, but not limited to:
• Techniques for Individual feature comparison
• Awareness of racial and cognitive biases
• Presentation attack indicators
• Guided matching examples
The training material MUST be provided by the
Applicant to the DTA as part of initial accreditation
and annually thereafter as part of the Annual
Assessment.

5.3.8.7
3.8.7 Requirements for logging and data retention

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-08-24 5.3.8.7 The Applicant MUST maintain the information

associated with each Individual transaction,
including a log of activities that details which
Assessing Officer collected data, what data was
collected, when and where the data was collected.

IDP IDP-03-08-24a 5.3.8.7 This log MUST NOT include Biometric Samples.

IDP IDP-03-08-25 5.3.8.7 The Applicant MUST have in place audit or random
checking procedures to help detect fraud or
inadequate Manual Face Comparison and
verification by Assessing Officers.

IDP IDP-03-08-26 5.3.8.7 The Applicant MUST NOT retain any Personally
Identifiable Information captured in biometric
binding processes.

IDP IDP-03-08-27 5.3.8.7 The Applicant MUST ensure that it is responsible

for the destruction of all Biometric Samples,
including all copies, caches, and intermediary
databases, including any subcontractors or third-
party components.

IDP IDP-03-08-27a 5.3.8.7 This destruction process MUST be documented by

a specific audit log.
IDP IDP-03-08-27b 5.3.8.7 The Acquired image MUST, unless required by law,
then be destroyed consistent with TDIF Req: PRIV-
03-08-02.

5.3.8.8 3.8.8 Manual Face Comparison specific

requirements
IDP IDP-03-08-28 5.3.8.8 The Applicant MAY utilise manual processors
performed by Assessing Officers to complete Local
Biometric binding or Online Biometric binding
processes.

IDP IDP-03-08-29 5.3.8.8 The Applicant MAY utilize manual processors to

review and/or adjust decisions made by the
Applicant Capability, including biometric match
results and presentation attack detection.

IDP IDP-03-08-30 5.3.8.8 The Acquired image MUST NOT be retained after
completion of the Local Biometric Binding or
Online Biometric binding processes by the
Assessing Officer.

IDP IDP-03-08-31 5.3.8.8 If the Applicant utilises manual processes, The

Applicant MUST include this in their risk
assessment for biometric binding processes.

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-08-32 5.3.8.8 The Applicant MUST maintain an audit log of

manual processes that meets the requirements of
the TDIF. This includes records of transactions in
production and the training activities of Assessing
Officers. The audit log MUST be auditable by the
DTA.

IDP IDP-03-08-33 5.3.8.8 The Applicant MUST only perform remote Manual
Face Comparison for Online Biometric binding
after attempting a Biometric Match.

IDP IDP-03-08-34 5.3.8.8 The Applicant MUST only undertake remote

Manual Face Comparison utilising Assessing
Officers located within Australia.

0 Chapter 4 Credential Service Provider

Requirements
5.4.1 4.1 Credential Levels
CSP CSP-04-01-01 5.4.1 The Applicant MUST support at least one of the
Credential Levels described in Table 4.. [Table 4 of
TDIF: 05 Role Requirements]

CSP CSP-04-01-02 5.4.1 For each supported Credential Level, the Applicant
MUST implement it to meet all requirements as
described in Table 4. [Table 4 of TDIF: 05 Role
Requirements]

CSP CSP-04-01-03 5.4.1 The Applicant MUST ensure that Credentials

presented are valid or active and that they are not
expired or revoked prior to authenticating the
Individual.

CSP CSP-04-01-04 5.4.1 Where unusual transactions are detected the

Applicant MUST verify the Credential is still under
the control of its legitimate owner.

CSP CSP-04-01-05 5.4.1 When requested by the Individual the Applicant

MUST prevent the continued use of a Credential
(e.g. temporary suspension while traveling
abroad).

CSP CSP-04-01-05a 5.4.1 The Applicant MUST confirm the legitimacy of the
request in accordance with CSP-04-01-05, prior to
preventing the continued use of a Credential.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-01-05b 5.4.1 The Applicant MUST notify the Individual that a
Credential can no longer be used in accordance
with CSP-04-01-05 and the reason why it can no
longer be used (e.g. deactivated, expired, revoked,
etc).

0 5.4.2.1 4.2.1 Memorised Secrets

CSP CSP-04-02-01 5.4.2.1 If Memorised Secrets are supported, then the
Applicant MUST implement the following
requirements for the operation of Memorised
Secrets.

CSP CSP-04-02-01a 5.4.2.1 Memorised secrets MUST be at least 8 characters

in length if chosen by the Individual.

CSP CSP-04-02-01b 5.4.2.1 Memorised secrets chosen randomly by the

Applicant MUST be at least 6 characters in length
and MAY be entirely numeric.

CSP CSP-04-02-01c 5.4.2.1 If the Applicant disallows a chosen memorised

secret based on its appearance on a blacklist of
compromised values, the Individual MUST be
required to choose a different memorised secret.

CSP CSP-04-02-01d 5.4.2.1 When processing requests to establish and change

memorised secrets, the Applicant MUST compare
the prospective secrets against a list that contains
values known to be commonly used, expected, or
compromised. For example, the list may include,
but is not limited to:
• Passwords obtained from previous breach
corpuses.
• Dictionary words.
• Repetitive or sequential characters (e.g.
‘aaaaaa’, ‘1234abcd’).
• Context-specific words, such as the name of
the service, the username, and derivatives thereof.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-02-01e 5.4.2.1 If the chosen secret is found in the list, the
Applicant MUST:
• advise the Individual that they need to select a
different secret,
• provide the reason for rejection, and
• require the Individual to choose a different
value.

CSP CSP-04-02-01f 5.4.2.1 The Applicant MAY offer guidance to the

Individual, such as a password-strength meter, to
assist the Individual in choosing a strong
memorised secret. This is particularly important
following the rejection of a memorised secret on
the above list as it discourages trivial modification
of listed (and likely very weak) memorised secrets.

CSP CSP-04-02-01g 5.4.2.1

The Applicant MAY permit Individuals to use the

“paste” functionality when entering a memorised
secret. This facilitates the use of password
managers, which are widely used and, in many
cases, increase the likelihood that Individuals will
choose stronger memorised secrets.
CSP CSP-04-02-01h 5.4.2.1

To assist the Individual in successfully entering a

memorised secret, the Applicant MAY offer an
option to display the secret — rather than a series
of dots or asterisks — until it is entered. This
allows the Individual to verify their entry if they
are in a location where their screen is unlikely to
be observed.
CSP CSP-04-02-01i 5.4.2.1

The Applicant MAY permit the Individual’s device

to display individual entered characters for a short
time after each character is typed to verify correct
entry. This is particularly applicable on mobile
devices.
CSP CSP-04-02-01j 5.4.2.1

The Applicant MUST use Australian Signals

Approved Cryptographic Algorithms (AACAs) and
an authenticated protected channel when
requesting memorised secrets to provide
resistance to eavesdropping and Man-in-the-
Middle (MitM) attacks.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-02-01k 5.4.2.1

The Applicant MUST store memorised secrets in a
form that is resistant to offline attacks.
CSP CSP-04-02-01l 5.4.2.1
Memorised secrets MUST be salted and hashed
using a suitable one-way key derivation function.
CSP CSP-04-02-01m 5.4.2.1
The salt MUST be at least 32 bits in length and be
chosen arbitrarily so as to minimise salt value
collisions among stored hashes.
CSP CSP-04-02-01n 5.4.2.1
Both the salt value and the resulting hash MUST be
stored for each Individual who uses memorised
secrets.
0 5.4.2.2 4.2.2 Look-up secrets
CSP CSP-04-02-02 5.4.2.2

If Look-up Secrets are supported, then the

Applicant MUST implement the following
requirements for the operation of look-up secrets.
CSP CSP-04-02-02a 5.4.2.2 A Applicant creating look-up secrets MUST deliver
them securely to the subscriber.
CSP CSP-04-02-02b 5.4.2.2

Look-up secrets MUST prompt the Individual for

the next secret (e.g. the next numbered secret).
CSP CSP-04-02-02c 5.4.2.2
A given look-up secret MUST be used successfully
only once. If the look-up secret is derived from a
grid card, each cell of the grid MUST be used only
once.
CSP CSP-04-02-02d 5.4.2.2

The Applicant MUST store look-up secrets in a

form that is resistant to offline attacks.

CSP CSP-04-02-02e 5.4.2.2

Look-up secrets MUST be hashed using an AACA.
CSP CSP-04-02-02f 5.4.2.2

The salt value MUST be at least 32 in bits in length

and arbitrarily chosen so as to minimise salt value
collisions among stored hashes.
CSP CSP-04-02-02g 5.4.2.2
Both the salt value and the resulting hash MUST be
stored for each look-up secret.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-02-02h 5.4.2.2

For look-up secrets that have less than 64 bits of
entropy, the Applicant MUST implement a rate-
limiting mechanism that effectively limits the
number of failed authentication attempts that can
be made on the Individual’s digital identity
account.
CSP CSP-04-02-02i 5.4.2.2

The Applicant MUST use AACAs and an

authenticated protected channel when requesting
look-up secrets in order to provide resistance to
eavesdropping and MitM attacks.
5.4.2.3 4.2.3 Out-of-band devices
CSP CSP-04-02-03 5.4.2.3
If Out-of-band Devices are supported, then the
Applicant MUST implement the following
requirements for the operation of out-of-band
devices.
CSP CSP-04-02-03a 5.4.2.3

The out-of-band device MUST establish a separate

channel with the Applicant to retrieve the out-of-
band secret or authentication request. This
channel is out-of-band with respect to the primary
communication channel (even if it terminates on
the same device) provided the device does not
leak information from one channel to the other
without consent of the Individual.
CSP CSP-04-02-03b 5.4.2.3

The out-of-band device MUST uniquely

authenticate itself in one of the following ways
when communicating with the Applicant:
• Establish an authenticated protected channel
to the Applicant using approved cryptography .
• The key used MUST be stored in suitably
secure storage available to the credential
application (e.g. keychain storage, secure element
etc.).
• Authenticate to a public mobile telephone
network using a SIM card or equivalent that
uniquely identifies the device. This method MUST
only be used if a secret is being sent from the
Applicant to the out-of-band device via the Public
Switched Telephone Network (PSTN) (SMS or
voice).

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-02-03c 5.4.2.3

If the out-of-band device sends an approval

message over the secondary communication
channel — rather than by the Individual
transferring a received secret to the primary
communication channel — it MUST do one of the
following:
CSP CSP-04-02-03c 5.4.2.3

CSP CSP-04-02-03c 5.4.2.3

CSP CSP-04-02-03d 5.4.2.3

If out-of-band verification is to be made using a

secure application, such as on a smart phone, the
Applicant MAY send a push notification to that
device. The Applicant will then wait for the
establishment of an authenticated protected
channel and verify the device’s identifying key.
CSP CSP-04-02-03e 5.4.2.3 The Applicant MUST NOT store the identifying key
itself.
CSP CSP-04-02-03f 5.4.2.3

The Applicant MUST use a verification method

(e.g. an approved hash function using an AACA) to
uniquely identify the device. Once authenticated,
the Applicant will transmit the authentication
secret to the device.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-02-03g 5.4.2.3

Depending on the type of out-of-band device, one

of the following options (1, 2, OR 3) MUST take
place:
CSP CSP-04-02-03g 5.4.2.3

CSP CSP-04-02-03g 5.4.2.3

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-02-03h 5.4.2.3

In all cases, the authentication MUST be
considered invalid if not completed within 10
minutes.
CSP CSP-04-02-03i 5.4.2.3
To provide replay resistance, the Applicant MUST
accept a given authentication secret only once
during the validity period.
CSP CSP-04-02-03j 5.4.2.3
The Applicant MUST generate random
authentication secrets with at least 20 bits of
entropy.
CSP CSP-04-02-03k 5.4.2.3
If the authentication secret has less than 64 bits of
entropy, the Applicant MUST implement a rate-
limiting mechanism that effectively limits the
number of failed authentication attempts that can
be made on the Individual’s digital identity
account.
CSP CSP-04-02-03l 5.4.2.3

If out-of-band verification is to be made using the

PSTN, the Applicant MUST verify that the pre-
registered telephone number being used is
associated with a specific physical device.
CSP CSP-04-02-03m 5.4.2.3

The Applicant MUST consider risks associated with

device swap, SIM change, number porting or other
abnormal behaviour before using the PSTN to
deliver an out-of-band authentication secret.
CSP CSP-04-02-03n 5.4.2.3
Risks of using the PSTN MUST be recorded in the
Applicant’s System Security Plan and managed
accordingly.
0 5.4.2.4 4.2.4 Single-factor one-time password (OTP)
devices
CSP CSP-04-02-04 5.4.2.4

If single-factor OTP devices are supported, the

Applicant MUST implement the following
requirements to operate single-factor OTP devices.
CSP CSP-04-02-04a 5.4.2.4

The secret key and its algorithm MUST provide at

least the minimum-security strength specified in
the latest edition of the ISM.
CSP CSP-04-02-04b 5.4.2.4
The nonce MUST be of sufficient length to ensure
that it is unique for each operation of the device
over its lifetime.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-02-04c 5.4.2.4

OTP credentials MUST NOT facilitate the cloning of
the secret key onto multiple devices.
CSP CSP-04-02-04d 5.4.2.4

If the nonce used to generate the authentication

output is based on a real-time clock, the nonce
MUST be changed at least once every 2 minutes.
CSP CSP-04-02-04e 5.4.2.4 The OTP value associated with a given nonce
MUST be accepted only once.
CSP CSP-04-02-04f 5.4.2.4

When a single-factor OTP Credential is being

associated with an Individual’s digital identity
account, the Applicant MUST use AACAs to either
generate and exchange or to obtain the secrets
required to duplicate the authentication output.
CSP CSP-04-02-04g 5.4.2.4
The Applicant MUST use AACAs and an
authenticated protected channel when collecting
the OTP to provide resistance to eavesdropping
and MitM attacks.
CSP CSP-04-02-04h 5.4.2.4
To provide replay resistance, the Applicant MUST
accept a given time-based OTP only once during
the validity period.
CSP CSP-04-02-04i 5.4.2.4
Time-based OTPs MUST have a defined lifetime
that is determined by the expected clock drift — in
either direction — of the credential over its
lifetime, plus allowance for network delay and user
entry of the OTP.
CSP CSP-04-02-04j 5.4.2.4
If the authentication output has less than 64 bits of
entropy, the Applicant MUST implement a rate-
limiting mechanism that effectively limits the
number of failed authentication attempts that can
be made on the Individual’s digital identity
account.
0 5.4.2.5 4.2.5 Multi-factor one-time password devices
CSP CSP-04-02-05 5.4.2.5

If multi-factor one-time password (MF OTP)

devices are supported, then the Applicant MUST
implement the following requirements for the
operation of MF OTP devices.
CSP CSP-04-02-05a 5.4.2.5

The secret key and its algorithm MUST provide at

least the minimum -security strength specified in
the latest edition of the ISM.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-02-05b 5.4.2.5

The nonce MUST be of sufficient length to ensure
that it is unique for each operation of the device
over its lifetime.
CSP CSP-04-02-05c 5.4.2.5
OTP authentication MUST NOT facilitate the
cloning of the secret key onto multiple devices.
CSP CSP-04-02-05d 5.4.2.5

If the nonce used to generate the authentication

output is based on a real-time clock, the nonce
MUST be changed at least once every 2 minutes.
CSP CSP-04-02-05e 5.4.2.5
Any memorised secret used for activation MUST be
a randomly chosen numeric secret at least 6
decimal digits in length.
CSP CSP-04-02-05f 5.4.2.5
The unencrypted key and activation secret or
biometric sample — and any biometric data
derived from the biometric sample, such as a
probe produced through signal processing —
MUST be zeroised immediately after an OTP has
been generated.
CSP CSP-04-02-05g 5.4.2.5

When a MF OTP Credential is being associated

with an Individual’s digital identity account, the
Applicant MUST use AACAs to either generate and
exchange, or to obtain the secrets required to
duplicate the authentication output.
CSP CSP-04-02-05h 5.4.2.5
The Applicant MUST use AACAs and an
authenticated protected channel when collecting
the OTP to provide resistance to eavesdropping
and MitM attacks.
CSP CSP-04-02-05i 5.4.2.5 The Applicant MUST also establish that the
Credential is a MF OTP device.
CSP CSP-04-02-05j 5.4.2.5
Time-based OTPs MUST have a defined lifetime
that is determined by the expected clock drift — in
either direction — of the credential over its
lifetime, plus allowance for network delay and user
entry of the OTP.
CSP CSP-04-02-05k 5.4.2.5
To provide replay resistance, the Applicant MUST
accept a given time-based OTP only once during
the validity period.
CSP CSP-04-02-05l 5.4.2.5

In the event an Individual’s authentication is

denied due to duplicate use of an OTP, the
Applicant MAY warn the Individual in case an
attacker has been able to authenticate in advance.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-02-05m 5.4.2.5

The Applicant MAY also warn the Individual in an
existing session of the attempted duplicate use of
an OTP.
CSP CSP-04-02-05n 5.4.2.5
If the authentication output has less than 64 bits of
entropy, the Applicant MUST implement a rate-
limiting mechanism that effectively limits the
number of failed authentication attempts that can
be made on the Individual’s digital identity
account.
0 5.4.2.6 4.2.6 Single-factor cryptographic software
CSP CSP-04-02-06 5.4.2.6

If single-factor cryptographic software is

supported, then the Applicant MUST implement
the following requirements for the operation of
single-factor cryptographic software.
CSP CSP-04-02-06a 5.4.2.6

The key MUST be strongly protected against

unauthorised disclosure using access controls that
limit access to the key to only those software
components on the device requiring access.
CSP CSP-04-02-06b 5.4.2.6
Single-factor cryptographic software credentials
MUST NOT facilitate the cloning of the secret key
onto multiple devices.
CSP CSP-04-02-06c 5.4.2.6
Keys MUST be protected against modification.
CSP CSP-04-02-06d 5.4.2.6 Keys MUST be protected against unauthorised
disclosure.
CSP CSP-04-02-06e 5.4.2.6 The challenge nonce MUST be at least 64 bits in
length.
CSP CSP-04-02-06f 5.4.2.6
The challenge nonce MUST either be unique over
the credential’s lifetime or be statistically unique.
CSP CSP-04-02-06g 5.4.2.6
The authentication event MUST use approved
cryptography (i.e. AACAs and AACPs).
0 5.4.2.7 4.2.7 Single-factor cryptographic devices
CSP CSP-04-02-07 5.4.2.7

If single-factor cryptographic devices are

supported, then the Applicant MUST implement
the following requirements for the operation of
single-factor cryptographic devices.
CSP CSP-04-02-07a 5.4.2.7
Single-factor cryptographic devices MUST
encapsulate one or more secret keys unique to the
device that MUST NOT be exportable (i.e. cannot
be removed from the device).

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-02-07b 5.4.2.7

The secret key and its algorithm MUST provide at
least the minimum-security length specified in the
latest edition of the ISM.
CSP CSP-04-02-07c 5.4.2.7 The challenge nonce MUST be at least 64 bits in
length.
CSP CSP-04-02-07d 5.4.2.7
The challenge nonce MUST either be unique over
the credential’s lifetime, or be statistically unique.
CSP CSP-04-02-07e 5.4.2.7 Approved cryptography (i.e., AACAs and AACPs)
MUST be used.
CSP CSP-04-02-07f 5.4.2.7
Keys MUST be protected against modification.
CSP CSP-04-02-07g 5.4.2.7 Keys MUST be protected against unauthorised
disclosure.
0 5.4.2.8 4.2.8 Multi-factor cryptographic software
CSP CSP-04-02-08 5.4.2.8

If multi-factor cryptographic software is supported,

then the Applicant MUST implement the following
requirements for the operation of multi-factor
cryptographic software.
CSP CSP-04-02-08a 5.4.2.8
The key MUST be strongly protected against
unauthorised disclosure by the use of access
controls that limit access to the key to only those
software components on the device requiring
access.
CSP CSP-04-02-08b 5.4.2.8 Authentication events MUST require the input of
both factors.
CSP CSP-04-02-08c 5.4.2.8
Any memorised secret used for activation MUST be
a randomly chosen numeric value at least 6
decimal digits in length.
CSP CSP-04-02-08d 5.4.2.8
The unencrypted key, and activation secret or
biometric sample — and any biometric data
derived from the biometric sample such as a probe
produced through signal processing — MUST be
zeroised immediately after an authentication has
taken place.
CSP CSP-04-02-08e 5.4.2.8
Keys MUST be protected against modification.
CSP CSP-04-02-08f 5.4.2.8 Keys MUST be protected against unauthorised
disclosure.
CSP CSP-04-02-08g 5.4.2.8 The challenge nonce MUST be at least 64 bits in
length.
CSP CSP-04-02-08h 5.4.2.8
The challenge nonce MUST either be unique over
the credential’s lifetime or, be statistically unique.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-02-08i 5.4.2.8

The authentication event MUST use approved
cryptography (i.e. AACAs and AACPs).
CSP CSP-04-02-08j 5.4.2.8 Truncation MUST NOT be performed on the
memorised secret used for activation.
0 5.4.2.9 4.2.9 Multi-factor cryptographic devices
CSP CSP-04-02-09 5.4.2.9
If multi-factor cryptographic device is supported,
the Applicant MUST implement the following
requirements for the operation of multi-factor
cryptographic devices.
CSP CSP-04-02-09a 5.4.2.9
The secret key and its algorithm MUST provide at
least the minimum-security length specified in the
latest edition of the ISM.
CSP CSP-04-02-09b 5.4.2.9 The challenge nonce MUST be at least 64 bits in
length.
CSP CSP-04-02-09c 5.4.2.9
The challenge nonce MUST either be unique over
the Credential’s lifetime or, be statistically unique.
CSP CSP-04-02-09d 5.4.2.9 Approved cryptography (i.e., AACAs and AACPs)
MUST be used.
CSP CSP-04-02-09e 5.4.2.9
Keys MUST be protected against modification.
CSP CSP-04-02-09f 5.4.2.9 Keys MUST be protected against unauthorised
disclosure.
0 5.4.3 4.3 General credential requirements
0 5.4.3.1 4.3.1 Physical credentials
CSP CSP-04-03-01 5.4.3.1

If physical Credentials are supported, the Applicant

MUST implement the following requirements to
operate physical Credentials.
CSP CSP-04-03-01a 5.4.3.1
The Applicant MUST provide the Individual with
instructions on how to appropriately protect the
credential against theft or loss.
CSP CSP-04-03-01b 5.4.3.1

The Applicant MUST provide a mechanism to

revoke or suspend the credential immediately
upon notification from the individual that loss or
theft of the credential is suspected.
0 5.4.3.2 4.3.2 Rate limiting (throttling)
CSP CSP-04-03-02 5.4.3.2 The Applicant MUST implement rate limiting (or
throttling) for all credentials.
CSP CSP-04-03-02a 5.4.3.2 The Applicant MUST implement controls to protect
against online guessing attacks.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-03-02b 5.4.3.2

The Applicant MUST limit consecutive failed
authentication attempts on a single account to no
more than 100.
CSP CSP-04-03-02c 5.4.3.2

Additional techniques MAY be used to reduce the

likelihood that an attacker will lock the Individual
out of their digital identity account out as a result
of rate limiting. Following a failed authentication
event, the Applicant MAY require:
• The individual to complete a Completely
Automated Public Turing test to tell Computers
and Humans Apart (CAPTCHA) before attempting
authentication.
• The Individual to wait for a period of time that
increases as the account approaches its maximum
allowance for consecutive failed attempts (e.g. 30
seconds up to an hour).
• Accepting only authentication requests that
come from a whitelist of IP addresses from which
the Individual has been successfully authenticated
before.
• Leveraging other risk-based or adaptive
authentication techniques to identify user
behaviour that falls within or out of typical norms.
Examples include: use of IP address, geolocation,
timing of request patterns, or browser metadata.
CSP CSP-04-03-02d 5.4.3.2

When the individual successfully authenticates,

the Applicant MAY disregard any previous failed
attempts for that user from the same IP address.
0 5.4.3.3 4.3.3 biometrics (for authentication use)
CSP CSP-04-03-03 5.4.3.3

If biometrics for authentication use are supported,

then the Applicant MUST implement the following
biometrics requirements for the operation of
biometrics for authentication use.
CSP CSP-04-03-03a 5.4.3.3
Biometrics MUST be used only as part of multi-
factor authentication with a physical Credential.
CSP CSP-04-03-03b 5.4.3.3
An authenticated protected channel between
sensor and Applicant MUST be authenticated prior
to capturing the biometric sample from the
Individual.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-03-03c 5.4.3.3

The biometric system MUST operate with a False-
Match-Rate (FMR) of 1 in 1000 or better.
CSP CSP-04-03-03d 5.4.3.3

This FMR MUST be achieved under conditions of a

conformant attack (i.e., zero-effort impostor
attempt) as defined in ISO/IEC 30107-1.
CSP CSP-04-03-03e 5.4.3.3 The biometric system MUST implement
Presentation Attack Detection (PAD).
CSP CSP-04-03-03f 5.4.3.3

Testing of the biometric system to be deployed

MUST demonstrate at least 90% resistance to
presentation attacks for each relevant attack type
(i.e. species), where resistance is defined as the
number of thwarted presentation attacks divided
by the number of trial presentation attacks.
CSP CSP-04-03-03g 5.4.3.3
Testing of presentation attack resistance MUST be
in accordance with Clause 12 of ISO/IEC 30107-
3:2017.
CSP CSP-04-03-03h 5.4.3.3
The PAD decision MAY be made either locally on
the Individual’s device or by the Applicant.
CSP CSP-04-03-03i 5.4.3.3
The biometric system MUST allow no more than 5
consecutive failed authentication attempts or 10
consecutive failed attempts.
CSP CSP-04-03-03j 5.4.3.3

Once the limit of consecutive failed attempts has

been reached, the biometric system MUST either:
CSP CSP-04-03-03j 5.4.3.3

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-03-03k 5.4.3.3

The Applicant MUST make a determination of

sensor and endpoint performance, integrity, and
authenticity. Acceptable methods for making this
determination include, but are not limited to:
• Authentication of the sensor or endpoint.
• Certification by an approved accreditation
authority
• Runtime interrogation of signed metadata
(e.g. attestation).
CSP CSP-04-03-03l 5.4.3.3

If supported, Biometric comparison that is

performed centrally MUST implement the
following:
CSP CSP-04-03-03l 5.4.3.3

CSP CSP-04-03-03l 5.4.3.3

CSP CSP-04-03-03l 5.4.3.3

CSP CSP-04-03-03m 5.4.3.3

Biometric samples collected in the authentication
process MAY be used to train comparison
algorithms or — with user consent — for other
research purposes.
CSP CSP-04-03-03n 5.4.3.3
Biometric samples and any biometric data derived
from the biometric sample such as a probe
produced through signal processing MUST be
zeroiszed immediately after any training or
research data has been derived.
0 5.4.3.4 4.3.4 Credential Attestation
CSP CSP-04-03-04 5.4.3.4

If credential attestation is supported, the Applicant

MUST implement the following requirements for
the operation of credential attestation.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-03-04a 5.4.3.4

Information conveyed by credential attestation

MAY include, but is not limited to:
• The provenance (e.g. manufacturer or supplier
certification), health, and integrity of the credential
and endpoint
• Security features of the credential
• Security and performance characteristics of
biometric sensor(s)
• Sensor modality.
CSP CSP-04-03-04b 5.4.3.4
If this attestation is signed, it MUST be signed using
a digital signature that provides at least the
minimum-security strength specified in the latest
version of the ISM.
CSP CSP-04-03-04c 5.4.3.4 Attestation information MAY be used as part of a
CSP’s risk-based authentication decision.
0 5.4.3.5 4.3.5 CSP-impersonation resistance
CSP CSP-04-03-05 5.4.3.5

Where a Applicant supports CL3, it MUST

implement the following Applicant-impersonation
resistance requirements. These requirements do
not need to be implemented for CL1 or CL2.
CSP CSP-04-03-05a 5.4.3.5

A CSP-impersonation resistant authentication

protocol MUST establish an authenticated
protected channel with the Applicant.
CSP CSP-04-03-05b 5.4.3.5

A CSP-impersonation resistant authentication

protocol MUST strongly and irreversibly bind a
channel identifier that was negotiated in
establishing the authenticated protected channel
to the authentication output (e.g. by signing the
two values together using a private key controlled
by the claimant for which the public key is known
to the Applicant).
CSP CSP-04-03-05c 5.4.3.5

The Applicant MUST validate the signature or

other information used to prove CSP-
impersonation resistance. This prevents an
impostor CSP attacker, even one that has obtained
a certificate representing the actual CSP, from
replaying that authentication on a different
authenticated protected channel.
CSP CSP-04-03-05d 5.4.3.5
AACAs MUST be used to establish CSP-
impersonation resistance where it is required.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-03-05e 5.4.3.5

Keys used for this purpose MUST provide at least
the minimum-security strength specified in the
latest edition of the ISM.
CSP CSP-04-03-05f 5.4.3.5

Credentials that involve the manual entry of an

authentication output, such as out-of-band and
OTP Credentials, MUST NOT be considered CSP-
impersonation resistant because the manual entry
does not bind the authentication output to the
specific session being authenticated.
0 5.4.3.6 4.3.6 IdP-CSP communications
CSP CSP-04-03-06 5.4.3.6

In situations where the IdP and CSP are separate

entities, communication MUST occur through a
mutually authenticated secure channel (such as a
client-authenticated TLS connection) using
approved cryptography (i.e, AACAs and AACPs).
0 5.4.3.7 4.3.7 CSP-compromise resistance
CSP CSP-04-03-07 5.4.3.7

Where a Applicant supports CL 3 it MUST

implement the following Applicant-compromise
resistance requirements. These requirements do
not need to be implemented for CL1 or CL 2.
CSP CSP-04-03-07a 5.4.3.7
To be considered CSP-compromise resistant, public
keys stored by the Applicant MUST be associated
with the use of approved cryptographic algorithms
(i.e. AACAs).
CSP CSP-04-03-07b 5.4.3.7
Keys MUST provide at least the minimum-security
strength specified in the latest version of the ISM.
0 5.4.3.8 4.3.8 Replay resistance
CSP CSP-04-03-08 5.4.3.8

Where the Applicant supports CL2 or CL3 it MUST

implement at least one of the following
credentials:
• OTP devices;
• Out-of-band Devices;
• Cryptographic-based credentials; or
• Look-up secrets.
0 5.4.3.9 4.3.9 Authentication intent
CSP CSP-04-03-09 5.4.3.9
Where the Applicant supports CL 3 it MUST
implement the following authentication intent
requirements. These requirements do not need to
be implemented for CL 1 or CL 2.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-03-09a 5.4.3.9 Authentication intent MUST be established by the

Credential itself.
CSP CSP-04-03-09b 5.4.3.9

Authentication intent MAY be established in

several ways, including:
• Authentication processes that require the
Individual’s intervention (e.g., an Individual
entering an authentication output from an OTP
device).
• Cryptographic devices that require user action
(e.g., pushing a button or reinsertion) for each
authentication or reauthentication operation.
0 5.4.3.10
4.3.10 Restricted Credentials
CSP CSP-04-03-10 5.4.3.10

If, at any time, the Applicant determines that a

Credential is resulting in an unacceptable risk to
any party, then they MUST prevent continued use
of that Credential. Such Credentials are referred to
as Restricted Credentials.
CSP CSP-04-03-11 5.4.3.10

If a Applicant supports the use of a Restricted

Credential, it MUST:
CSP CSP-04-03-11 5.4.3.10

CSP CSP-04-03-11 5.4.3.10

CSP CSP-04-03-11 5.4.3.10

0 5.4.4 4.4 Credential lifecycle management

0 5.4.4.1 4.4.1 Credential binding

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-04-01 5.4.4.1

A Credential MUST be bound to an Individual’s
account by either:
• Issuance by the Applicant as part of
enrolment; or
• Associating a user-provided Credential that is
acceptable to the Applicant.
CSP CSP-04-04-01a 5.4.4.1
Throughout the digital identity lifecycle, the
Applicant MUST maintain a record of all
Credentials that are or have been associated with
each digital identity account.
CSP CSP-04-04-01b 5.4.4.1
The Applicant MUST maintain the information
required for throttling authentication attempts
when required.
CSP CSP-04-04-01c 5.4.4.1

The Applicant MUST also verify the credential type

of a user-provided Credential (e.g., single-factor
cryptographic device vs. multi-factor cryptographic
device) so the Applicant can determine compliance
with requirements at each CL.
CSP CSP-04-04-01d 5.4.4.1
The record created by the Applicant MUST contain
the date and time the Credential was bound to the
account.
CSP CSP-04-04-01e 5.4.4.1
The record MUST include information about the
source of the binding (e.g., IP address, device
identifier) of any device associated with the
enrolment.
CSP CSP-04-04-01f 5.4.4.1

The record MUST also contain information about

the source of unsuccessful authentications
attempted with the Credential.
CSP CSP-04-04-01g 5.4.4.1

When any new Credential is bound to an

Individual’s account, the Applicant MUST ensure
that the binding protocol and the protocol for
provisioning the associated key(s) are done at a
level of security commensurate with the CL at
which the Credential will be used.
0 5.4.4.2 4.4.2 Binding at enrolment

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-04-02 5.4.4.2

For remote transactions where enrolment and

binding cannot be completed in a single electronic
transaction (i.e. within a single protected session),
the following requirements MUST be met to
ensure that the same party acts as the Individual
throughout the process:

CSP CSP-04-04-02 5.4.4.2

CSP CSP-04-04-02a 5.4.4.2

For in-person transactions where enrolment and

binding cannot be completed in a single physical
encounter (i.e. within a single protected session),
the following requirements MUST be met to
ensure that the same party acts as the Individual
throughout the process:
CSP CSP-04-04-02a 5.4.4.2

CSP CSP-04-04-02a 5.4.4.2

0 5.4.4.3 4.4.3 Binding additional Credentials

CSP CSP-04-04-03 5.4.4.3

If a Applicant supports the binding of additional

Credentials to an Individual’s account, then it
MUST implement the following requirements for
the operation of binding additional credentials to
an individual’s account.
CSP CSP-04-04-03a 5.4.4.3
Before binding an additional Credential to an
Individual’s account, the Applicant MUST first
require the Individual to authenticate at the CL (or
a higher CL) at which the new Credential will be
used.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-04-03b 5.4.4.3

When a Credential is added, the Applicant MAY

send a notification to the Individual via a
mechanism that is independent of the transaction
binding the new Credential (e.g. email to an
address previously associated with the Individual).
CSP CSP-04-04-03c 5.4.4.3
The Applicant MAY limit the number of Credentials
that may be bound in this manner.
CSP CSP-04-04-04 5.4.4.3

Before binding a new Credential to an account, the

Applicant MUST require the Individual to
authenticate with a Credential of at least CL1.
CSP CSP-04-04-04a 5.4.4.3

When a Credential is added, the Applicant MAY

send a notification to the Individual via a
mechanism that is independent of the transaction
binding the new Credential (e.g. email to an
address previously associated with the Individual).
CSP-04-04-05 5.4.4.3 This requirement has been archived in version 1.7.

0 5.4.4.4 4.4.4 Binding to a User-provided credential

CSP CSP-04-04-06 5.4.4.4

The Applicant MAY, where practical, accommodate

the use of a user-provided Credential to relieve the
burden to the Individual of managing a large
number of Credentials.

0 5.4.4.5 4.4.5 Renewal

CSP CSP-04-04-07 5.4.4.5

The Applicant MAY bind an updated Credential a

reasonable amount of time before an existing
Credential’s expiration.
CSP CSP-04-04-08 5.4.4.5
Following successful use of the new Credential, the
Applicant MAY revoke the Credential that it is
replacing.

# A80000OFFICIAL
 A80000OFFICIAL #

0 5.4.5 4.5 Loss, theft, damage and unauthorised

duplication
CSP CSP-04-05-01 5.4.5

The suspension, revocation or destruction of a

compromised Credential MUST occur as promptly
as practical following detection of loss, theft,
damage or unauthorised duplication.
CSP CSP-04-05-02 5.4.5
To facilitate secure reporting of the loss, theft or
damage to a Credential, the Applicant MAY
provide the Individual with a method of
authenticating to the Applicant using a backup or
alternate Credential.
CSP CSP-04-05-03 5.4.5
If the Applicant implements CSP-04-05-02, then
the backup Credential MUST be either a
Memorised Secret or a physical Credential.
CSP CSP-04-05-04 5.4.5

The Applicant MAY choose to validate a User’s

contact details (i.e. email, mobile phone number)
and MUST suspend a Credential reported to have
been compromised.
CSP CSP-04-05-05 5.4.5
The suspension of a compromised credential MUST
be reversible if the Individual successfully
authenticates to the Applicant using a valid (i.e.
not suspended) Credential and requests
reactivation of a Credential suspended in this
manner.
CSP CSP-04-05-06 5.4.5
The Applicant MAY set a time limit after which a
suspended Credential can no longer be
reactivated.
0 5.4.6 4.6 Credential expiration
CSP CSP-04-06-01 5.4.6
The Applicant MAY issue Credentials that expire.
CSP CSP-04-06-01a 5.4.6 When a Credential expires, it MUST NOT be usable
for authentication.
CSP CSP-04-06-01b 5.4.6

The Applicant MUST require an Individual to

surrender or prove destruction of any physical
Credential containing attribute certificates signed
by the Applicant as soon as practical after
expiration or receipt of a renewed Credential.
0 5.4.7 4.7 Credential revocation and termination

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-07-01 5.4.7

The Applicant MUST revoke the binding of a

Credential promptly when an account ceases to
exist (e.g. an Individual’s death, discovery of a
fraudulent account), when requested by the
Individual, or when the Applicant determines that
the Individual no longer meets its eligibility
requirements.
CSP CSP-04-07-02 5.4.7

The Applicant MUST require an Individual to

surrender or certify destruction of any physical
Credential containing certified attributes signed by
the Applicant as soon as practical after revocation
or termination takes place. This is necessary to
block the use of the Credential’s certified
attributes in offline situations between revocation
or termination and expiration of the certification.
0 5.4.8 4.8 Session management
CSP CSP-04-08-01 5.4.8
A session MAY be started in response to an
authentication event and continue until such time
that it is terminated.
CSP CSP-04-08-01a 5.4.8

A session MAY be terminated for any number of

reasons, including but not limited to an inactivity
timeout, an explicit logout event or other means.
CSP CSP-04-08-01b 5.4.8

The session MAY be continued through a

reauthentication event wherein the Individual
repeats some or all of the initial authentication
event, thereby re-establishing the session.
CSP-04-08-02 5.4.8 This requirement has been archived in version 1.7.

CSP-04-08-03 5.4.8 This requirement has been archived in version 1.7.

CSP-04-08-04 5.4.8 This requirement has been archived in version 1.7.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP-04-08-05 5.4.8 This requirement has been archived in version 1.7.

0 5.4.9 4.9 Reauthentication

CSP CSP-04-09-01 5.4.9
Continuity of authenticated sessions MUST be
based upon the possession of a session secret
issued by the Applicant at the time of
authentication and optionally refreshed during the
session.
CSP CSP-04-09-01a 5.4.9 Session secrets MUST be non-persistent.
CSP CSP-04-09-01b 5.4.9
Session secrets MUST NOT be retained across a
restart of the associated application or a reboot of
the host device.
CSP CSP-04-09-01c 5.4.9

Periodic reauthentication of sessions MUST be

performed to confirm the continued presence of
the Individual at an authenticated session (i.e. that
the Individual has not walked away without
logging out).
CSP CSP-04-09-01d 5.4.9
When a session has been terminated, due to a
time-out or other action, the Individual MUST be
required to establish a new session by
authenticating again.
0 5.4.10 4.10 Credential Step-Up
CSP CSP-04-10-01 5.4.10

If the Step-Up of a Credential from one Credential

Level to another is supported by the Applicant,
then it MUST implement the following
requirements for the operation of Step-Up for all
Credential Levels.
CSP CSP-04-10-01a 5.4.10 The Applicant MUST be accredited to issue a
Credential at the higher Credential Level.
CSP CSP-04-10-01b 5.4.10

The Credential MUST meet all the requirements of

the higher Credential level.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-10-02 5.4.10

The Applicant MUST ensure that an Individual can

prove ownership of their existing Identity by
authenticating with their Credential to their
account prior to commencing the Credential Step-
Up process.
0 5.4.11 4.11 Certificate Authorities
CSP CSP-04-11-01 5.4.11
If Certification Authorities are supported, then the
Applicant MUST implement all of the following
requirements to operate as a Certification
Authority.
CSP CSP-04-11-02 5.4.11

The Applicant MUST ensure all:

CSP CSP-04-11-02 5.4.11

CSP CSP-04-11-02 5.4.11

CSP CSP-04-11-02 5.4.11

CSP CSP-04-11-03 5.4.11

The Applicant MUST ensure the Root Certification

Authority (CA) Private Key is not used to digitally
sign Digital Certificates, except in the following
cases:
• Self-signed Digital Certificates to represent the
Root CA itself.
• Digital Certificates for Subordinate CAs and
Cross Certificates.
• Digital Certificates for infrastructure purposes
(for example, administrative role certificates and
OCSP Digital Certificates).
• Digital Certificates issued solely for the
purpose of testing software with Digital
Certificates issued by the Root CA.
CSP CSP-04-11-04 5.4.11
The Applicant MUST implement a process to allow
Individuals to request revocation of their Digital
Certificate.

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-11-04a 5.4.11

The Applicant MUST implement revocation

procedures for the following situations:

CSP CSP-04-11-04a 5.4.11

CSP CSP-04-11-04a 5.4.11

CSP CSP-04-11-04a 5.4.11

CSP CSP-04-11-04a 5.4.11

CSP CSP-04-11-04a 5.4.11

CSP CSP-04-11-04a 5.4.11

0 5.5.1 Chapter 5 Attribute Service Providers

ASP ASP-05-01-01 5.5.1 The Applicant MUST support at least one Attribute
Class as described in Table 6. [pg 25 of TDIF: 05
Role Requirements]

ASP ASP-05-01-02 5.5.1 The Applicant MAY directly connect to an Identity

Service Provider.

# A80000OFFICIAL
 A80000OFFICIAL #

ASP ASP-05-01-03 5.5.1 Beyond the minimum dataset required to

associate Identity Attributes with Attributes
related to Attribute Classes, the Applicant MUST
NOT store Attributes held by an Identity Service
Provider and Attribute Service Provider together in
the one repository.

ASP ASP-05-02-01 5.5.2 The Applicant MUST either be an Authoritative

Source for Attributes it issues or have approval
from the Authoritative Source to manage
Attributes on their behalf.

ASP ASP-05-02-01a 5.5.2 Where the Applicant manages Attributes on behalf

of an Authoritative Source, it MUST provide
evidence of this arrangement to the DTA. Evidence
of this arrangement will be requested by the DTA
as part of initial accreditation and annually
thereafter as part of the Annual Assessment.

ASP ASP-05-02-02 5.5.2 The Applicant MUST ensure every Attribute it

issues or manages is uniquely identifiable.
ASP ASP-05-02-03 5.5.2 The Applicant MUST manage and provide up-to-
date, relevant and accurate Attributes.
ASP ASP-05-02-04 5.5.2 If the Applicant is an Authoritative Source for an
Attribute, the Applicant MUST verify all requests to
update relevant Attributes prior to making
changes.

ASP ASP-05-02-05 5.5.2 The Applicant MUST take reasonable measures to

prevent the continued use of an Attribute (e.g.
suspension, deactivation) when requested to do so
by an authorised Individual or Authoritative
Source.

ASP ASP-05-02-05a 5.5.2 The Applicant MUST confirm the legitimacy of the
request from an authorised Individual or
Authoritative Source in accordance with ASP-05-
02-05, prior to actioning the request.

ASP ASP-05-02-06 5.5.2 The Applicant MAY support issuing or linking

multiple Attributes and Attribute Classes to a
Person.

ASP ASP-05-02-06a 5.5.2 The Applicant MAY support issuing or linking

multiple Attributes relating to the same entity to a
Person.

# A80000OFFICIAL
 A80000OFFICIAL #

ASP ASP-05-02-06b 5.5.2 The Applicant MAY support issuing or linking

multiple People to the same Attribute.

0 5.6 Chapter 6 Identity Exchange Requirements

0 5.6.1 6.1 Audit Logging Requirements
IDX IDX-06-01-01 5.6.1 The Applicant MUST generate a unique audit Id for
an Authentication Request from a Relying Party to
be used as the Unique interaction identifier for the
interaction.

IDX IDX-06-01-02 5.6.1 The Applicant MUST log all related interactions
between Relying Parties and Identity Service
Providers using this unique audit id (this includes
Attribute Service Providers acting as Relying
Parties).

0 5.6.2 6.2 Consent Management

IDX IDX-06-02-01 5.6.2 In accordance with PRIV-03-09-03, the Applicant
MUST maintain the following information as part
of its auditable logs:

IDX IDX-06-02-01 5.6.2

IDX IDX-06-02-01 5.6.2

IDX IDX-06-02-01 5.6.2

IDX IDX-06-02-01 5.6.2

IDX IDX-06-02-01 5.6.2

IDX IDX-06-02-01 5.6.2

IDX IDX-06-02-01 5.6.2

0 5.6.3 6.3 Single Sign On/Single Log out

IDX IDX-06-03-01 5.6.3 If single sign on is supported, then the Applicant
MUST implement the following requirements to
operate single sign on.

# A80000OFFICIAL
 A80000OFFICIAL #

IDX IDX-06-03-02 5.6.3 The Applicant MUST support the ability for a
Relying Party to request that a User authenticates
regardless of whether a pre-existing session exists.

IDX IDX-06-03-02a 5.6.3 The Applicant MUST implement a single log out
mechanism according to the Federation Protocol
that it supports.

IDX IDX-06-03-03 5.6.3 The Applicant MAY securely cache Attributes from
an Identity Service Provider for the duration of an
authenticated session to support single sign on.

IDX IDX-06-03-03a 5.6.3 If the Applicant securely caches attributes as per

IDX-06-03-03, these attributes MUST NOT be
accessible to the Applicant’s Personnel.

IDX IDX-06-03-04 5.6.3 The Applicant MAY restrict the expiration period
for an authentication session to manage security
risks.

0 5.6.4 6.4 User Dashboard

IDX IDX-06-04-01 5.6.4 If a User Dashboard is supported, then the
Applicant MUST implement the following
requirements for the operation of a User
Dashboard.

IDX IDX-06-04-02 5.6.4 The Applicant MUST display to the Individual their
Consumer History and enable the Individual to
view the Express Consent they have provided to
share attributes with a Relying Party or any third
party.

IDX IDX-06-04-03 5.6.4 The Applicant MUST NOT store Attributes of the
Individual beyond the Individual’s presence at the
User Dashboard.

0 5.6.5 6.5 IdP Selection

IDX IDX-06-05-01 5.6.5 If IdP Selection is supported, the Applicant MUST
implement the following requirements for the
operation of IdP Selection.

IDX IDX-06-05-02 5.6.5 The list of Identity Service Providers presented by

the Applicant to the User MUST be capable of
meeting the Credential Level and Identity Proofing
Level requested in the Authentication Request.

# A80000OFFICIAL
 A80000OFFICIAL #

IDX IDX-06-05-03 5.6.5 The Applicant MAY provide a mechanism for an

Individual’s selection of an Identity Service
Provider to be remembered so the Individual does
not have to select an Identity Service Provider
(again) when accessing a Relying Party.

IDX IDX-06-05-03a 5.6.5 Express Consent MUST be obtained from the

Individual prior to offering the mechanism
described in IDX-06-05-02.

IDX IDX-06-05-03b 5.6.5 The Individual MUST have the ability to opt out of
using the mechanism described in IDX-06-05-02.

0 TDIF: 06 - Federation Onboarding Requirements

FED FED-02-01-01 6.2.1 The Applicant MUST implement the following

profiles as specified in the TDIF: 06B - OpenID
Connect 1.0 Profile:
a) Relying Party to Identity Exchange Profile.
b) Identity Exchange to Identity Service Provider
Profile.

FED FED-02-01-02 6.2.1 The Applicant MAY implement the following

profiles as specified in the TDIF: 06C - SAML 2.0
Profile:
a) Relying Party to Identity Exchange Profile.
b) Identity Exchange to Identity Service Provider
Profile.

FED FED-02-01-03 6.2.1 The Applicant MUST implement the Relying Party
to Identity Exchange profile specified in either the:
a) TDIF: 06B - OpenID Connect 1.0 Profile; or
b) The TDIF: 06C - SAML 2.0 Profile.

FED FED-02-01-04 6.2.1 The Applicant MUST implement the Identity

Exchange to Identity Service Provider profile
specified in either the:
a) TDIF: 06B - OpenID Connect 1.0 Profile; or
b) The TDIF: 06C - SAML 2.0 Profile.

FED FED-02-01-05 6.2.1 The Applicant MUST test their implementation of a

Federation Protocol in accordance with the
“technical testing requirements” set out in section
6 of the TDIF: 04 – Functional Requirements.

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-02-01-06 6.2.1 The Applicant MUST conform to the applicable

recommendations in the security considerations
section set out in [RFC 6749] and those set out in
the ‘OAuth 2.0 threat model and security
considerations’ document [RFC 6819].

FED FED-02-01-06a 6.2.1 The Applicant’s conformance with the security

considerations MUST be considered as part of its
System Security Plan as per PROT-04-01-12.

FED-02-01-07 6.2.1 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to PRIV-03-09-03.

FED-02-01-07a 6.2.1 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to IDX-06-02-01

FED FED-02-01-08 6.2.1 The Applicant’s Audit logs MUST store a record of
all federated identity interactions that relate to an
Individual, including any requests and responses
between a Relying Party and an Identity Exchange,
or an Identity Service Provider and an Identity
Exchange.

FED-02-01-08a 6.2.1 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to PROT-04-02-24e.

FED FED-02-01-09 6.2.1 The Applicant MUST develop and use procedures
to report incidents of fraud or suspected fraud to
the Oversight Authority (this replaces FRAUD-02-
05-10).

FED FED-02-01-09a 6.2.1 As soon as they become aware the Applicant

MUST report incidents of fraud or suspected fraud
to the Oversight Authority (this replaces FRAUD-
02-05-10a).

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-02-01-09b 6.2.1 The Applicant MUST include the following

information when reporting on incidents of fraud
or suspected fraud:
a) Date and time of the fraud incident.
b) Quantity of fraud incidents and their level of
severity.
c) Time taken to respond to the fraud incident.
d) Measures taken in response to the fraud
incident.
e) Type(s) of fraud.
f) If applicable, the Identity Proofing Level and
Credential Level of the impacted identity record(s).
g) Any other supporting information (e.g. attack
vectors used by the fraudster).

Depending on the nature of the fraud incident and

legal advice obtained, the Oversight Authority may
advise impacted stakeholders of the outcome of a
fraud investigation (this replaces FRAUD-02-05-
10b).

FED FED-02-01-10 6.2.1 An Applicant, covered by the Privacy Act, MUST

report eligible data breaches to affected
individuals and the Information Commissioner as
required under the Privacy Act[1] and also report
the eligible data breach to the Oversight Authority
(this replaces PRIV-03-04-01).

FED FED-02-01-10a 6.2.1 An Applicant, not covered by the Privacy Act,

MUST report eligible data breaches as defined in
the Privacy Act 1988 to affected individuals and
the Oversight Authority (this replaces PRIV-03-04-
01a).

FED FED-02-01-11 6.2.1 The Applicant MUST include a statement in their

privacy notices advising that the Applicant may use
the Individual’s information as required by the
Oversight Authority, including to detect, manage
and investigate fraud (this replaces PRIV-03-05-
02).

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-02-01-12 6.2.1 The Applicant MAY include a statement in their

privacy notices advising that the Applicant may
provide the Individual’s system metadata to the
Oversight Authority to enable it to perform the
Oversight Authority’s functions related to fraud
management.

FED FED-02-01-13 6.2.1 If it discloses Personal information to an overseas

recipient that is not the individual, the Applicant
MUST demonstrate to the Oversight Authority’s
reasonable satisfaction it has appropriate
contractual and practical measures to ensure the
overseas recipient complies with these TDIF
privacy requirements (this replaces PRIV-03-10-
02a).

FED FED-02-01-14 6.2.1 The Applicant MUST develop and use procedures
that ensure:
a) All elements of the Applicant’s System
Security Plan are achieved.
b) Cyber security incidents are investigated,
responded to and reported to the Oversight
Authority.
c) Relevant security policy or legislative
obligations are met.
(This replaces PROT-04-01-06).

FED FED-02-01-15 6.2.1 The Applicant MUST develop and use procedures
to report Cyber security incidents to the Oversight
Authority (this replaces PROT-04-02-15).

FED FED-02-01-15a 6.2.1 As soon as they become aware the Applicant

MUST report Cyber security incidents to the
Oversight Authority (this replaces PROT-04-02-
15a).

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-02-01-15b 6.2.1 The Applicant MUST include the following

information when reporting Cyber security
incidents:
a) Date and time of the Cyber security incident.
b) Quantity of Cyber security incidents and their
level of severity.
c) Time taken to respond to the Cyber security
incident.
d) Measures taken in response to the Cyber
security incident.
e) If applicable, the Identity Proofing Level and
Credential Level of the impacted identity record(s).
f) Any other supporting information (e.g. attack
vectors used).
Depending on the nature of the Cyber security
incident and legal advice sought, the Oversight
Authority may advise impacted stakeholders of the
outcome of a security investigation (this replaces
PROT-04-02-15b).

FED FED-02-02-01 6.2.2 [1] See Part IIIC of

https://www.legislation.gov.au/Details/C2019C000
25 for the definition of an eligible data breach
including exceptions to reporting.

FED FED-02-03-01 6.2.3 The Applicant MUST generate Pairwise Identifiers

in accordance with section 8.1 of the OpenID
Connect Core 1.0 specification [OpenIDCore] and
use these to interact with Relying Parties
regardless of the Federation Protocol the Applicant
is using to communicate with other Participants in
the Federation.

FED FED-02-03-02 6.2.3 The Applicant MUST send through a Pairwise

Identifier in response to a successful
Authentication Request.

FED FED-02-03-03 6.2.3 The Applicant MUST use a different Pairwise

Identifier to an Identity Service Provider to identify
the subject of an Authentication to the Relying
Party.

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-02-03-04 6.2.3 An Identity Exchange MUST implement an identity

mapping process that maps the Pairwise Identifier
presented by an IdP in response to an
authentication request to the Pairwise Identifier
for the user at the Relying Party that initiated the
Authentication interaction.

FED FED-02-03-05 6.2.3 The Applicant MUST be able to receive Pairwise

Identifiers of up to 255 ASCII characters.

FED FED-02-03-06 6.2.3 The Applicant MUST support the configuration of a

sector identifier for a Relying Party in accordance
with Section 8.1 of the [OpenIDCore].

FED FED-02-03-07 6.2.3 The process for the registration of OIDC clients by
the Applicant MUST ensure that only valid and
authorised clients for the Relying Party can use the
same configured sector_identifier_uri.

FED FED-02-03-08 6.2.3 The Applicant MUST NOT generate Pairwise

Identifiers greater than 255 ASCII characters.
FED-02-03-09 6.2.3 This requirement has been archived in version 1.1.

FED FED-02-03-10 6.2.3 The Applicant MUST have a process to conduct

Deduplication of Digital identities which pass
through an Identity Exchange to ensure that a User
with multiple digital identities is presented as the
same user to a Relying Party.

FED FED-02-03-11 6.2.3 The Applicant MUST only deduplicate Digital

Identities which have been proved to the same
Identity Proofing Level.

FED FED-02-03-12 6.2.3 If the TDIF EDI attribute is requested by an Identity

Exchange, the Applicant MUST return an EDI
constructed using the document specified in Table
1 (as updated by DTA from time to time) according
to the Identity Proofing Level used in the
authentication context.

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-02-03-13 6.2.3 The Applicant MUST return an EDI constructed

using only such documents specified in Table 1 (as
updated by DTA from time to time) as are bound
to the current authentication context.

FED FED-02-03-14 6.2.3 The Applicant MUST ensure that the documents
and attributes used to construct an EDI reflect the
most up to date documents and attributes bound
to the current authentication context.

FED FED-02-03-15 6.2.3 When constructing an EDI using a document the

Applicant MUST concatenate the document type
code URN from section 6.1 of the TDIF: 06D -
Attribute Profile and the attributes specified in
Table 2 in the order specified in Table 2, for that
document, using the attribute formats specified in
Table 3.

FED FED-02-03-15a 6.2.3 If the User has not verified any of the documents
in Table 1 (as updated by DTA from time to time),
the Applicant MUST construct an EDI by
concatenating the IP Link for the User and a
suitable globally-unique identifier for the Applicant
(e.g. OIDC Issuer URI).

FED FED-02-03-15b 6.2.3 The string resulting from either TDIF Req FED-02-
03-15 or TDIF Req FED-02-03-15a MUST then be
encoded using UTF-8, before being hashed using
the SHA-256 algorithm.

FED FED-02-03-16 6.2.3 The Applicant MUST NOT provide access to an EDI
to any party other than an Identity Exchange.

FED FED-02-03-17 6.2.3 The Applicant MUST NOT store an EDI received
from an Identity Service Provider or use it as their
Pairwise Identifier for the User being
authenticated.

FED FED-02-03-18 6.2.3 The Applicant MUST NOT provide access to an EDI
to any other party in the Identity Federation.

FED FED-02-03-19 6.2.3 If the Applicant uses the EDI to conduct

Deduplication, it MUST NOT do so across the
Identity Federation, but instead only conduct
deduplication at a sector identifier level.

FED FED-02-03-20 6.2.3 The Applicant MAY request an EDI to conduct

Deduplication as part of an authentication request
made to an Identity Service Provider.

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-02-03-21 6.2.3 If the Applicant supports single sign on, it MUST
support the ability for a Relying Party to request
Authentication for a particular User using the
method specified in the Federation Protocol being
used. See section 4.2 for more detail on how an
Identity Exchange can support this.

FED-02-03-22 6.2.3 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to IDX-06-03-02

FED-02-03-23 6.2.3 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to IDX-06-03-02a

FED FED-02-03-24 6.2.3 If the Applicant is using securely cached attributes

for single sign on, and the Applicant receives an
Authentication Request which cannot be fulfilled
using the cached information and can’t retrieve
additional Attributes without further requiring user
interaction, it MUST send an Authentication
Request to an Identity Service Provider.

FED-02-03-25 6.2.3 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to IDX-06-03-03a

FED-02-03-26 6.2.3 This requirement has been archived in version 1.1.

FED-02-03-27 6.2.3 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to IDX-06-03-03

FED-02-03-28 6.2.3 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to IDX-06-03-04

FED-02-03-29 6.2.3 This requirement has been archived in version 1.1.

# A80000OFFICIAL
 A80000OFFICIAL #

FED-02-03-30 6.2.3 This requirement has been archived in version 1.1.

FED FED-03-01-01 6.3.1 The Applicant MUST publish a schema for any
Attributes it provides. This schema must
enumerate the valid values for any Attributes that
have a defined set of values, and be done in a
format which complies with the platform through
which it provides access to an Identity Exchange,
and the Federation Protocols which a Relying Party
may use to request the Attributes from an Identity
Exchange.

FED FED-03-01-02 6.3.1 The Applicant MUST use the Pairwise Identifiers
generated by an Identity Exchange for it as a
Relying Party to associate the attributes that it
provides with the Digital Identity brokered by an
Identity Exchange.

FED FED-03-01-03 6.3.1 The Applicant MUST provide an API that enables
the attributes it provides to be shared with Relying
Parties.

FED FED-03-01-04 6.3.1 The Applicant MUST authorise an accredited

Identity Exchange to securely access the API it
provides.

FED FED-03-01-05 6.3.1 The Applicant MAY implement the API as a REST
API.
FED FED-03-01-06 6.3.1 Where the Applicant provides a REST API, the
Applicant MAY authorise access in accordance with
the JSON Web Token Profile for OAuth 2.0 Client
Authentication and Authorization Grants [RFC
7523].

FED FED-03-01-07 6.3.1 The Applicant MAY allow Attributes to be directly

requested from it by a Relying Party using a
security token returned by an Identity Exchange to
the Relying Party.

FED FED-03-02-01 6.3.2 The Applicant’s Audit Log MUST include any User
Consent managed by the Applicant that enables
the sharing of attributes with a Relying Party.

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-03-02-02 6.3.2 The Applicant’s Audit Log MUST include the value
of the RP Audit Id Attribute received from an
Identity Exchange for the following events:
• The retrieval of Attributes by an Identity
Exchange.
• The binding of any Attributes to a Digital
Identity brokered by an Identity Exchange.

FED-03-02-03 6.3.2 This requirement has been archived in version 1.1.

FED-04-01-01 6.4.1 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to IDX-06-01-01.

FED FED-04-01-01a 6.4.1 In addition to the requirements in section 6.1 of

the TDIF 05 – Role Requirements, the Applicant
MUST implement the following requirements

FED-04-01-02 6.4.1 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to IDX-06-01-02.

FED FED-04-01-03 6.4.1 The Applicant MUST provide the unique audit id
described in IDX-06-01-01 to the Relying Party
using the RP_audit_id Attribute in response to
every logical interaction between a Relying Party
(including an Attribute Service Provider) and an
Identity Exchange

FED FED-04-01-04 6.4.1 When the Applicant calls an API provided by an

Attribute Service Provider, they MUST include the
value of the unique audit id that has been
generated by the Identity Exchange for the Relying
Party that requested the Attributes.

FED FED-04-01-05 6.4.1 The Applicant MUST NOT send the unique audit id
that has been generated by the Identity Exchange
for the Relying Party that requested the Attributes
to an Identity Service Provider.

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-04-01-06 6.4.1 The Applicant MUST implement a User Dashboard

in accordance with the requirements in section 6.4
of the TDIF 05 – Role Requirements.

FED-04-01-07 6.4.1 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to IDX-06-04-02.

FED-04-01-08 6.4.1 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to IDX-06-04-03.

FED FED-04-01-09 6.4.1 When the Applicant receives an Authentication

Request from a Relying Party that includes
Attributes supplied by an Attribute Service
Provider then it MUST call the API provided by the
Attribute Service Provider to make these Attributes
available to the Relying Party in the Authentication
response.

FED FED-04-01-10 6.4.1 The Applicant MAY make Attributes requested by a

Relying Party available by authorising the Relying
Party to directly retrieve the attributes from the
Attribute Service Provider using a security token, if
a Relying Party has requested to do so.

FED FED-04-01-11 6.4.1 Security tokens issued by the Applicant to a

Relying Party MUST NOT reveal the Pairwise
Identifier of the User at the Attribute Service
Provider.

FED FED-04-01-12 6.4.1 The Applicant MUST call an Attribute Service

Provider’s API using the Pairwise Identifier it has
issued to assist in identifying the required
Attributes.

FED FED-04-01-13 6.4.1 The Applicant MUST implement IdP Selection in

accordance with the requirements in section 6.5 of
the TDIF 05 – Role Requirements.

FED-04-01-14 6.4.1 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to IDX-06-05-01b.

# A80000OFFICIAL
 A80000OFFICIAL #

FED-04-01-15 6.4.1 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to IDX-06-05-02a

FED-04-01-16 6.4.1 This requirement has been archived in version 1.1.

The content of this requirement has been moved
to IDX-06-05-02

FED-04-02-01 6.4.2 This requirement has been archived in version 1.1.

FED-04-02-01a 6.4.2 This requirement has been archived in version 1.1.

FED-04-02-01b 6.4.2 This requirement has been archived in version 1.1.

FED-04-02-01c 6.4.2 This requirement has been archived in version 1.1.

FED-04-02-01d 6.4.2 This requirement has been archived in version 1.1.

FED FED-04-02-02 6.4.2 When the Applicant is accepting Authentication

Requests from a Relying Party using OIDC and
translating those requests to an Identity Service
Provider using OIDC, the Applicant MUST interact
with the Identity Service Provider as per the TDIF:
06B - OpenID Connect 1.0 Profile [TDIF.OIDC], and
the requirements set out below.

FED FED-04-02-03 6.4.2 Scopes and claims that are received from the
Relying Party MUST be included by the Applicant in
the Authentication Request to the Identity Service
Provider in accordance with the following
processing rules:

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-04-02-03a 6.4.2 All Attributes included in the Relying Party’s

Authentication Request which are found in section
3 of the TDIF: 06D – Attribute Profile MUST be
included in the Authentication Request sent to the
Identity Service Provider in either scopes or claims.

FED FED-04-02-03b 6.4.2 Scopes that are defined in the Authentication

Request MAY be expanded into the underlying
claims described in section 4.1 of the TDIF: 06D –
Attribute Profile.

FED FED-04-02-03c 6.4.2 If the sub (subject) claim is specified then it MUST
be processed as per the requirements in section
4.2.2.2

FED FED-04-02-04 6.4.2 Scopes and claims not in the TDIF: 06D – Attribute
Profile MUST be ignored by the Applicant.

FED FED-04-02-04a 6.4.2 Where scopes or claims are ignored, the Applicant
MUST NOT raise an error.
FED FED-04-02-05 6.4.2 The Applicant MUST resolve a Pairwise Identifier
included in the sub (subject) claim in the
Authentication Request from a Relying Party to an
existing Pairwise Identifier for the User at the
required Identity Service Provider.

FED FED-04-02-06 6.4.2 If no Pairwise Identifier for the User at the Identity
Service Provider can be resolved then the
Applicant MAY return an error.

FED FED-04-02-07 6.4.2 The Applicant MAY support the sub (subject) claim.

FED FED-04-02-08 6.4.2 Where the acr_values or acr claim received from
the Relying Party is a single value the Applicant
MUST pass the set of ACR values that meet or
exceed the value of the requested ACR value to
the Identity Service Provider in the generated
Authentication Request according to the ranking in
Table 4.

FED FED-04-02-09 6.4.2 Where the acr claim is marked as essential within
the Authentication Request from the Relying Party
it MUST be marked as essential when the
Applicant sends the request to an Identity Service
Provider.

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-04-02-10 6.4.2 The Applicant MUST evaluate the ACR returned
from the Identity Service Provider and if the ACR
meets or exceeds the originally requested value(s),
return one of the originally requested values

FED FED-04-02-11 6.4.2 The Applicant MUST implement the processing

rules for OIDC prompt parameters described in
Table 5.

FED FED-04-02-12 6.4.2 If the id_token_hint mechanism defined in

[TDIF.OIDC] is supported the following processing
rules MUST apply:
a. Where the Identity Exchange receives an
id_token_hint within an Authentication Request
from a Relying Party the Identity Exchange is
required to validate the Identity Token and extract
the subject. The Identity Exchange must resolve
this to a subject identifier at the Identity Service
Provider as per section 4.2.2.2.
b. The Identity Exchange must include the
resolved subject identifier in the Authentication
Request to the Identity Service Provider using the
sub (subject) Claim as per section 5.5 of the
[OpenID.Core] with essential=true.

FED-04-02-13 6.4.2 This requirement has been archived in version 1.1.

FED-04-02-14 6.4.2 This requirement has been archived in version 1.1

FED FED-04-02-15 6.4.2 When the Applicant is accepting Authentication

Requests from a Relying Party using OIDC and
translating those Authentication Requests to an
Identity Service Provider using SAML, the Identity
Exchange MUST interact with the Identity Service
Provider as per the TDIF: 06C – SAML 2.0 Profile
[TDIF.SAML] with the following processing rules.

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-04-02-16 6.4.2 Scopes and claims that are received from the
Relying Party MUST be included by the Applicant in
the Authentication Request to the Identity Service
Provider in accordance with the following
processing rules:

FED FED-04-02-16a 6.4.2 All Attributes included in the Relying Party’s

Authentication Request which are found in section
3 of the TDIF: 06D – Attribute Profile MUST be
included in the Authentication Request sent to the
Identity Service Provider in either scopes or claims.

FED FED-04-02-16b 6.4.2 Scopes that are defined in the Authentication

Request MAY be expanded into the underlying
claims described in section 4.1 of the TDIF: 06D –
Attribute Profile and then mapped according to
section 4.3.1 of the TDIF: 06D – Attribute Profile.

FED FED-04-02-16c 6.4.2 If the sub (subject) claim is specified then it MUST
be processed as per section 4.2.2.2. Once it is
resolved to a sub claim, then it should include the
resolved subject identifier in the Authentication
Request to the Identity Service Provider by
including it in a <saml:Subject> element in the
SAML <AuthnRequest> message.

FED FED-04-02-16d 6.4.2 Scopes and claims not in the TDIF: 06D – Attribute
Profile MUST be ignored. Where scopes or claims
are ignored, the Identity Exchange MUST NOT raise
an error.

FED FED-04-02-17 6.4.2 Where the acr_values or acr claim received from
the Relying Party is a single value the Applicant
MUST pass the set of
<saml:AuthnContextClassRef> values that meet or
exceed the value of the requested ACR to the
Identity Service Provider in the generated
Authentication Request according to the ranking
described in Table 4.

FED FED-04-02-18 6.4.2 Where the acr claim is marked as essential within
the request from the Relying Party the
<samlp:RequestedAuthnContext> comparison
Attribute MUST be set to minimum when sent to
the Identity Service Provider.

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-04-02-19 6.4.2 The Applicant MUST evaluate the

<saml:AuthnContextClassRef> returned from the
Identity Service Provider and if the
<saml:AuthnContextClassRef> meets or exceeds
the originally requested ACR value(s), return one of
the originally requested values.

FED FED-04-02-20 6.4.2 The Applicant MUST implement the processing

rules for OIDC prompt parameters as specified in
Table 6.

FED FED-04-02-21 6.4.2 A Relying Party MAY include an ID Token

previously issued by an Identity Exchange in the
Authentication Request to identify a specific User
that requires Authentication.

FED FED-04-02-22 6.4.2 This specification does not require support for this
mechanism by an Identity Exchange, but where it
is supported the following processing rules MUST
apply:
a. Where the Identity Exchange receives an
id_token_hint within an Authentication Request
from a Relying Party the Identity Exchange is
required to validate the token and extract the
subject. The Identity Exchange must resolve this to
an IP Link at the Identity Service Provider as per
4.2.2.2.
b. The Identity Exchange should include the
resolved subject identifier in the authentication
request to the Identity Service Provider by
including it in a <saml:Subject> element in the
SAML 2.0 <AuthnRequest> message.

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-04-02-23 6.4.2 In order to support this functionality the Identity

Exchange MUST implement the following
processing:
a. On receiving the authentication response, an
Identity Exchange must calculate the elapsed time
since the User was Authenticated using the value
of the AuthInstant attribute in the SAML response
from the Identity Service Provider.
b. If the elapsed time is greater than the
max_age value requested by the Relying Party
then the Identity Exchange must generate a fresh
Authentication Request with the ForceAuthn
Attribute is set to true on the <AuthnRequest>
message.

FED FED-04-02-24 6.4.2 The Applicant MUST implement the processing

rules for OIDC parameters as specified in Table 7.

FED FED-04-02-25 6.4.2 When an Identity Exchange is accepting

Authentication Requests from a Relying Party using
SAML and translating those requests to an Identity
Service Provider using SAML, the Identity Exchange
MUST interact with the Identity Service Provider as
per the TDIF: 06C – SAML 2.0 Profile.

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-04-02-26 6.4.2 Where the Attributes required are predefined

within the Relying Parties metadata, the set of
required Attributes MUST be included in the
Authentication Request to the Identity Service
Provider with the following processing rules:
a. Where the requested Attributes contained
within the Relying Party’s metadata are the same
as the Identity Exchanges requested Attributes in
its metadata exchanged with the Identity Service
Provider; the Identity Exchange creates a standard
Authentication Request.
b. Where the requested attributes are not
available in the requested Attributes as part of the
metadata shared with the Identity Service Provider
by the Identity Exchange; the Identity Exchange is
required to create an Authentication Request to
the Identity Exchange using extensions to request
the Attributes required by the Relying Party.

FED FED-04-02-27 6.4.2 Where the Attributes requested by a Relying Party

are requested via extensions the Identity Exchange
MUST copy those Attributes into the
Authentication Request to the Identity Service
Provider as extensions.

FED FED-04-02-28 6.4.2 The Relying Party MAY include a SAML Subject in
the Authentication Request.
FED FED-04-02-28a 6.4.2 As the subject identifier is the Pairwise Identifier
for the User at the Relying Party, the Identity
Exchange MUST resolve this Pairwise Identifier in
any Authentication Request to an existing Pairwise
Identifier for the User at the required Identity
Service Provider. If no Pairwise Identifier for the
User at the Identity Service Provider can be
resolved then the Identity Exchange should return
an error.

FED FED-04-02-28b 6.4.2 The Applicant MAY include the resolved Pairwise
Identifier in the Authentication Request to the
Identity Service Provider.

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-04-02-29 6.4.2 Where the Relying Party includes a

<RequestedAuthnContext> in the Authentication
Request, the Applicant MUST send the set of
<AuthnContextClassRef> to the Identity Service
Provider that meet or exceed the originally
requested <RequestedAuthnContext> according to
the rankings described in Table 4.

FED FED-04-02-30 6.4.2 The Comparison attribute for the

<RequestedAuthnContext> MUST be set to exact
or minimum.

FED FED-04-02-31 6.4.2 When the ForceAuthn Attribute is set to true

within the Authentication Request from the
Relying Party the Applicant MUST pass this
Attribute through in the Authentication Request
sent by the Applicant to the Identity Service
Provider.

FED FED-04-02-32 6.4.2 When the isPassive Attribute is set to true within
the Authentication Request from the Relying Party
the Applicant MUST pass this Attribute through in
the Authentication Request sent by the Applicant
to the Identity Service Provider.

FED FED-04-02-33 6.4.2 When the Identity Exchange is accepting

Authentication Requests from a Relying Party using
the SAML Federation Protocol and translating
those requests to an Identity Service Provider
using the OIDC Federation Protocol, the Applicant
MUST interact with the Identity Service Provider as
per the [TDIF.OIDC].

FED FED-04-02-34 6.4.2 The Attributes requested within the Authentication

Request either through extensions or via the
Relying Party’s metadata MUST be processed by
the Applicant in accordance with the following
rules:

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-04-02-34a 6.4.2 All Attributes included in the Relying Party’s

Authentication Request which are found in section
3 of the TDIF: 06D – Attribute Profile must be
included in the Authentication Request sent to the
Identity Service Provider in either scopes or claims.
The Applicant MUST use the mappings between
SAML and OIDC described in section 4.3.1 of the
TDIF: 06D – Attribute Profile.

FED FED-04-02-34b 6.4.2 Where the Attributes can be mapped fully into an
available scope an Identity Exchange MAY request
those scopes from an Identity Service Provider.

FED FED-04-02-34c 6.4.2 Where the Attributes do not map fully into a scope
the Identity Exchange MUST request those
Attributes as claims from the Identity Service
Provider.

FED FED-04-02-35 6.4.2 Where the Relying Party includes a

<RequestedAuthnContext> in the Authentication
Request, the Applicant MUST send the set of acr
values to the Identity Service Provider that meet or
exceed the originally requested
<RequestedAuthnContext> according to the
rankings described in Table 4.

FED FED-04-02-36 6.4.2 The Applicant MAY use the acr claim or the
acr_values parameter.
FED FED-04-02-37 6.4.2 The Comparison attribute for the
<RequestedAuthnContext> MUST be set to exact
or minimum.

FED FED-04-02-38 6.4.2 Where the ForceAuthn attribute is included in the

Authentication Request from the Relying Party, the
Applicant MUST set the prompt parameter to login
in the OIDC Authentication Request to the Identity
Service Provider.

FED FED-04-02-39 6.4.2 Where the isPassive Attribute is included in the

Authentication Request from the Relying Party, the
Identity Exchange MUST set the prompt parameter
to none in the OIDC Authentication Request to the
Identity Service Provider.

FED FED-04-02-40 6.4.2 The Applicant MUST resolve the value of the
subject to a subject identifier at the Identity
Service Provider as per 4.2.2.2.

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-04-02-40a 6.4.2 The Applicant MAY include the resolved subject
identifier in the Authentication Request to the
Identity Service Provider using the sub (subject)
claim.

FED FED-05-01-01 6.5.1 The Applicant MUST support the disclosure of all
Attributes described in section 3.1 of the TDIF: 06D
- Attribute Profile using one of the federation
protocols specified in section 2.1.1 of the TDIF 06 –
Federation Onboarding Requirements

FED FED-05-01-02 6.5.1 The Applicant MUST support the disclosure of all
Attributes listed as mandatory in section 3.1 of the
TDIF: 06D - Attribute Profile using one of the
federation protocols specified in section 2.1.1 of
the TDIF 06 – Federation Onboarding
Requirements

FED FED-05-01-03 6.5.1 The Applicant MAY support the disclosure of an

Attribute listed as optional in section 3.1 of TDIF:
06D - Attribute Profile using one of the federation
protocols specified in section 2.1.1 of the TDIF 06 –
Federation Onboarding Requirements

FED FED-05-01-04 6.5.1 The Applicant MUST support the disclosure of all
Attributes listed as mandatory in section 3.2 of the
TDIF: 06D - Attribute Profile using one of the
federation protocols specified in section 2.1.1 of
the TDIF 06 – Federation Onboarding
Requirements.

FED FED-05-01-05 6.5.1 The Applicant MUST be able to include any of the
Attributes described in section 3.2 of TDIF: 06D -
Attribute Profile in an Authentication Request to
an Identity Service Provider.

FED FED-05-01-06 6.5.1 The Applicant MUST support the disclosure of all
Attributes described in section 3.3 of TDIF: 06D -
Attribute Profile using one of the federation
protocols specified in section 2.1.1 of the TDIF 06 –
Federation Onboarding Requirements

FED FED-05-01-07 6.5.1 The Applicant MUST support the disclosure of all
Attributes described in section 3.5 of TDIF: 06D -
Attribute Profile using one of the federation
protocols specified in section 2.1.1 of the TDIF 06 –
Federation Onboarding Requirements

# A80000OFFICIAL
 A80000OFFICIAL #

FED FED-05-02-01 6.5.2 The Applicant MAY define support for additional
computed Attributes derived from the Attributes in
an Attribute Set. The DTA will add any computed
attributes to the TDIF: 06D - Attribute Profile.

FED FED-05-02-02 6.5.2 The Applicant MUST support the disclosure of

additional computed attributes described in
section 3.4 of the TDIF: 06D - Attribute Profile
using one of the federation protocols specified in
section 2.1.1 of the TDIF 06 – Federation
Onboarding Requirements

FED FED-05-02-03 6.5.2 The Applicant MAY source a computed attribute

from an Attribute Service Provider or Identity
Service Provider.

FED FED-05-03-01 6.5.3 The Applicant MAY support the disclosure of

Attributes an Attribute Service Provider is
accredited to provide. These Attributes are defined
in section 5 of the TDIF: 06D - Attribute Profile.

FED FED-05-03-02 6.5.3 The Applicant MUST ensure that it only disclosure,
or provides to an Identity Exchange to be shared,
Attributes that are relevant to the Relying Party
requesting the Attributes

FED FED-05-04-01 6.5.4 The Applicant MUST only disclose Attributes with
Relying Parties in accordance with the Attribute
Sharing Policy specified for the Attribute Set which
an Attribute is part of as described in section 2.2 of
the TDIF: 06D - Attribute Profile.

FED FED-05-05-01 6.5.5 When disclosing Attributes to other Participants in

the Identity Federation, the Applicant MUST use
the attribute data representation for Attributes
specified in section 6 of the TDIF: 06D - Attribute
Profile.

0 TDIF: 06B - OpenID Connect 1.0 Profile

OIDC OIDC-02-01-01 6B.2.1 The resource owner password credentials grant
type defined in [RFC 6749] is intentionally omitted
and the Applicant MUST NOT use this grant type
under these profiles.

OIDC OIDC-02-01-02 6B.2.1 These clients MUST use the authorisation code
flow of OAuth 2.0 by sending the resource owner
to the authorisation endpoint to obtain
authorisation.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-02-01-03 6B.2.1 The Applicant MUST ensure that the user
authenticates to the authorisation endpoint.
The user’s web browser is then redirected back to
a URI hosted by the client service, from which the
client can obtain an authorisation code passed as a
query parameter. The client then presents that
authorisation code along with its own credentials
(private_key_jwt) to the authorisation server’s
token endpoint to obtain an access token.

OIDC OIDC-02-01-04 6B.2.1 The Applicant MUST associate these clients with a
unique public key as described in section 2.4 of this
document.

OIDC OIDC-02-01-05 6B.2.1 The Applicant MAY issue a refresh token to this
type of client if they are satisfied that there are no
security issues precluding them from doing so.

OIDC OIDC-02-01-06 6B.2.1 These clients MUST use the authorization code
flow of OAuth 2.0 by sending the resource owner
to the authorisation endpoint to obtain
authorisation.

OIDC OIDC-02-01-07 6B.2.1 The user MUST authenticate to the authorisation

endpoint. The user’s web browser is then
redirected back to a URI hosted by the client, from
which the client can obtain an authorisation code
passed as a query parameter. The client then
presents that authorisation code along to the
authorisation servers token endpoint to obtain an
access token.

OIDC OIDC-02-01-08 6B.2.1 Native clients MUST either:

• Use dynamic client registration to obtain a
separate client id for each instance.
• Use a common client id and use PKCE to
protect calls to the token endpoint.

OIDC OIDC-02-01-09 6B.2.1 Native applications using dynamic registration

MAY generate a unique public and private key pair
on the device and register that public key value
with the authorisation server. Alternatively, an
authorisation server MAY issue a public and
private key pair to the client as part of the
registration process.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-02-01-10 6B.2.1 If the authorisation server issues a public and

private key pair to the client as part of the
registration process, the authorisation server
MUST discard its copy of the private key.

OIDC OIDC-02-01-11 6B.2.1 Client credentials MUST NOT be shared among

instances of client software.
OIDC OIDC-02-01-12 6B.2.1 Native Applications not registering a separate
public key for each instance MUST use PKCE with
the S256 code challenge mechanism.

OIDC OIDC-02-01-13 6B.2.1 Dynamically registered native applications MAY

use PKCE.
OIDC OIDC-02-01-14 6B.2.1 Native applications not registering a separate
public key for each instance are considered Public
Clients and MUST use PKCE with the S256 code
challenge mechanism. Public Clients do not
authenticate with the Token Endpoint in any other
way.

OIDC OIDC-02-01-15 6B.2.1 The Applicant MAY issue a refresh token to this
type of client if they are satisfied that there are no
security issues precluding them from doing so.

OIDC OIDC-02-02-01 6B.2.2 All clients MUST register with the authorisation
server. For client software that may be installed on
multiple client instances, each client instance
MUST receive a unique client identifier from the
authorisation server.

OIDC OIDC-02-02-02 6B.2.2 Client registration MAY be performed by either

static configuration or dynamically.
OIDC OIDC-02-02-03 6B.2.2 The Applicant MUST require that a client seeking
to register dynamically provides an initial access
token.

OIDC OIDC-02-02-04 6B.2.2 If the Applicant supports dynamic registration of

clients, the Applicant MUST be able to accept the
access okens described in OIDC-02-02-04 in the
manner described in the Oauth 2.0 Bearer Token
Usage [RFC6750] specification.

OIDC OIDC-02-03-01 6B.2.3 Clients using the authorisation code grant type
MUST register their full redirect URIs.
OIDC OIDC-02-03-02 6B.2.3 The authorisation server MUST validate the
redirect URI given by the client at the authorisation
endpoint using strict string comparison.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-02-03-03 6B.2.3 The Applicant MUST ensure that the redirect URI
used by a client is one of the following:
• Hosted on a website with TLS protection
(HTTPS).
• Hosted on a local domain of the client (e.g.
http://localhost/).
• Hosted on a client specific non-remote
protocol URI scheme (e.g. myapp:// or
au.gov.app://).

OIDC OIDC-02-03-04 6B.2.3 If a client‘s redirect URI is either hosted on the

local domain of the client or hosted on a client
specific non-remote protocol URI scheme as per
OIDC-02-03-03, then the Applicant MAY require
that the client uses the Proof Key for Code
Exchange (PKCE) extension to the authorization
code flow.

OIDC OIDC-02-03-05 6B.2.3 Clients MUST NOT have URIs in more than one
category and should not have multiple redirect
URIs on different domains.

OIDC OIDC-02-03-06 6B.2.3 Clients MUST NOT forward values passed back to
their redirect URIs to other arbitrary or user-
provided URIs (i.e. no open redirects).

OIDC OIDC-02-03-07 6B.2.3 The Applicant MAY allow these schemes to

continue to be used for existing applications.
OIDC OIDC-02-03-08 6B.2.3 Where the native platform supports the newer
App-Claimed HTTPS URL redirection capability
(Android, and iOS 9 or greater) this method MAY
be used. This method allows the registration of a
HTTPS URL e.g. https://app.gov.au/auth. When
that URL is accessed the platform will open the
application (if not already open) and the required
actions can be performed.

OIDC OIDC-02-04-01 6B.2.4 Clients using the authorisation code grant type
MUST have a public and private key pair type for
use in authentication to the token endpoint.

OIDC OIDC-02-04-02 6B.2.4 The client MUST register their public keys in their
client registration metadata by either sending the
public key directly in the jwks field or by registering
a jwks_uri that MUST be reachable by the
authorisation server. It is recommended that
clients use a jwks_uri as it allows for easier key
rotation.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-02-04-03 6B.2.4 The jwks field or the content available from the
jwks_uri of a client MUST contain a public key in
JSON Web Key Set (JWK Set) format.

OIDC OIDC-02-04-04 6B.2.4 The authorisation server MUST validate the

content of the clients registered jwks_uri
document and verify that it contains a JWK Set.

OIDC OIDC-02-04-05 6B.2.4 Native Client applications MAY omit their key
during registration if they are a public client using
PKCE.

OIDC OIDC-02-05-01 6B.2.5 The grant type of authorization_code MUST be

supported. Authentication using the Authorisation
Code flow is described in section 3.1 of
[OpenIDCore].

OIDC OIDC-02-06-01 6B.2.6 Clients making a request to the authorisation

endpoint MAY use an unpredictable value for the
state parameter with at least 128 bits of entropy.
This is recommended, but it is up to the Relying
Party to decide what level of entropy is required in
the state parameter.

OIDC OIDC-02-06-02 6B.2.6 Clients MUST validate the value of the state
parameter upon return to the redirect URI and
MUST ensure that the state value is securely tied
to the user’s current session e.g. by relating the
state value to a session identifier issued by the
client software to the browser.

OIDC OIDC-02-06-03 6B.2.6 Clients MUST include their full redirect URIs in the
authorisation request.
OIDC OIDC-02-06-04 6B.2.6 To prevent open redirection and other injection
attacks, the Applicant MUST match the entire
redirect URI using a direct string comparison
against registered values and MUST reject requests
with invalid or missing redirect URIs.

OIDC OIDC-02-06-05 6B.2.6 The Authentication Request MUST contain the

following REQUIRED parameters and MAY contain
the following OPTIONAL parameter values: [Refer
to list of parameters]

OIDC OIDC-02-06-06 6B.2.6 The JWT assertion used in client authentication

MUST be signed by the client using the client’s
private key. See section 2.4 for the mechanisms a
client can use to make its public key known to the
authorization server.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-02-06-07 6B.2.6 For clients that are required to use PKCE as
described in section 2.1.2 and section 2.3, the
following claims MUST be included in the request
to the token endpoint.
• code_verifier.
o Code verifier generated by client to use PKCE
with the S256 code challenge mechanism.

OIDC OIDC-02-06-08 6B.2.6 The Applicant MUST include the following claims in
the request to the token endpoint: [Refer to list of
parameters]

OIDC OIDC-02-06-09 6B.2.6 ID Tokens MAY be encrypted using the appropriate

key of the requesting client. Note that the issuing
server is the OP (Identity Exchange)

OIDC OIDC-02-06-10 6B.2.6 Clients MUST verify the following in received ID

tokens:
• Iss.
o The Issuer field is the URL of the expected
issuer.
• Aud.
o The audience field contains the client ID of the
client.
• exp, iat, nbf.
o The expiration, issued at and not before
tokens are dates (integer number of seconds since
00:00:00Z 1st January 1970, i.e. Unix epoch) are
within acceptable ranges.

OIDC OIDC-02-06-11 6B.2.6 The client MAY send a UserInfo Request using
either a HTTP GET or HTTP POST.
OIDC OIDC-02-06-12 6B.2.6 The Applicant MUST send the access token
obtained from an OpenID Connect Authentication
Request as a bearer token as per section 2 of
OAuth Bearer Token Usage [RFC 6750].

OIDC OIDC-02-06-13 6B.2.6 Clients MAY send requests to the Authorization

Endpoint using the request parameter as defined
in [OpenIDCore].

OIDC OIDC-02-06-14 6B.2.6 Request objects MUST be signed by the clients

registered key.
OIDC OIDC-02-06-15 6B.2.6 Request objects MAY be encrypted to the
Authorisation Server’s public key.
OIDC OIDC-02-06-16 6B.2.6 Clients and protected resources MAY cache
OpenID Provider (OP) metadata once an OP has
been discovered and used by the Client.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-02-07-01 6B.2.7 The authorisation server MUST validate all redirect
URIs for the authorization_code grant type.

OIDC OIDC-02-07-02 6B.2.7 The authorisation server MUST enforce client

authentication to the authorization servers token
endpoint using a JWT assertion as defined by using
only the private_key_jwt method as described in
[OpenIDCore]. Clients that have registered a public
key sign a JWT using the associated private key.
The Client authenticates in accordance with JSON
Web Token (JWT) Profile for OAuth 2.0 Client
Authentication and Authorization Grants and
Assertion Framework for OAuth 2.0 Client
Authentication and Authorization Grants.

OIDC OIDC-02-07-03 6B.2.7 The JWT must expire and MAY have a lifetime no
longer than five minutes. Short expiration times
are recommended wherever practicable. The
following guidance is provided in [RFC 7523]
regarding expiration times: the JWT MUST contain
an "exp" (expiration time) claim that limits the
time window during which the JWT can be used.

OIDC OIDC-02-07-04 6B.2.7 The authorization server MUST reject any JWT with
an expiration time that has passed, subject to
allowable clock skew between systems. Note that
the authorization server may reject JWTs with an
"exp" claim value that is unreasonably far in the
future.

OIDC OIDC-02-07-05 6B.2.7 The JWT MUST contain the following REQUIRED
claims and MAY contain the following OPTIONAL
Claim values: [Refer to list of parameters]

OIDC OIDC-02-07-06 6B.2.7 Dynamic registration of Clients MAY be supported

by an Identity Exchange.
OIDC OIDC-02-07-07 6B.2.7 Access to the Discovery document MAY be
protected with existing web authentication
methods if required by the Identity Exchange.
Credentials for the Discovery document are then
managed by the Identity Exchange and support for
these authentication methods is outside the scope
of this specification.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-02-07-08 6B.2.7 Endpoints described in the Discovery document

MUST be secured in accordance with this
specification and MAY have additional controls the
Identity Exchange wishes to support.

OIDC OIDC-02-07-09 6B.2.7 The discovery document MUST as a minimum

contain the following fields: [Refer to list of
parameters]

OIDC OIDC-02-07-10 6B.2.7 An Authorisation Server MUST support the Proof

Key for Code Exchange (PKCE) extension to the
authorization code flow, including support for the
S256 code exchange method.

OIDC OIDC-02-07-11 6B.2.7 The Authorisation Server MUST NOT allow a client
to use the plain code challenge method.

OIDC OIDC-02-07-12 6B.2.7 The Authorization Response to the Authorization

Code flow MUST return the following fields in the
response: [Refer to list of parameters]

OIDC OIDC-02-07-13 6B.2.7 If the Applicant receives a request for a scope or

claim for which it can not return a value, it MUST
ignore the scopes or claims for which a value can
not be returned, subject to TDIF Req: OIDC-02-07-
15. See s5.5 of the [OpenID.Core] for further
detail.

OIDC OIDC-02-07-14 6B.2.7 The Applicant MUST deny an authentication

request as per section 4.1.2.1 of [RFC 6749] from a
Relying Party using the error code access_denied if
the Relying Party requests a claim or scope it is not
authorised to request, as defined in section 2.3 of
the [TDIF.Attr].

OIDC OIDC-02-07-15 6B.2.7 All tokens MUST be signed by the issuer

Exchange’s private key.
OIDC OIDC-02-07-16 6B.2.7 For clients using the Authorization Code grant
type, access tokens MAY have a valid lifetime no
greater than one hour.

OIDC OIDC-02-07-17 6B.2.7 Refresh tokens, if issued, MAY have a lifetime no

longer than 24 hours.
OIDC OIDC-02-07-18 6B.2.7 These token lifetime values are recommended
values and MAY be varied in accordance with a
security risk assessment and the agreement of the
Relying Parties that an Identity Exchange supports.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-02-07-19 6B.2.7 ID Tokens MAY be encrypted using the appropriate

key of the requesting client.
OIDC OIDC-02-07-20 6B.2.7 The ID Token must expire and MAY have a lifetime
no longer than five minutes. Short expiration times
are recommended as the ID token is consumed by
the client and not presented to remote systems

OIDC OIDC-02-07-21 6B.2.7 When an ID Token is returned, ID Token values

which are defined as REQUIRED MUST be included
in the ID Token.

OIDC OIDC-02-07-22 6B.2.7 When an ID Token is returned, ID Token values

which are defined as OPTIONAL MAY be included
in the ID Token, unless otherwise specified in
another requirement in this document.

OIDC OIDC-02-07-23 6B.2.7 Identity Exchanges MUST support the use of the
UserInfo endpoint for claims and scopes which are
stated as described in the TDIF: 06 - Federation
Onboarding Requirements.

OIDC OIDC-02-07-24 6B.2.7 The UserInfo endpoint MUST only return claims
that are authorised within the authentication
request that issued the access token that is being
used to access the endpoint.

OIDC OIDC-02-07-25 6B.2.7 For privacy reasons, the Exchange MAY elect to not
return values for some of the requested claims; it
shouldn’t present with a null or empty string value.

OIDC OIDC-02-07-26 6B.2.7 The sub claim MUST always be returned in the
UserInfo Response.
OIDC OIDC-02-07-27 6B.2.7 The Identity Exchange operating as an OP MUST
accept requests containing a request object signed
by the client’s private key.

OIDC OIDC-02-07-28 6B.2.7 The Identity Exchange MUST validate the signature
on such requests against the Clients public key.

OIDC OIDC-02-07-29 6B.2.7 The Identity Exchange MUST accept request

objects encrypted with the Identity Exchanges
Public key.

OIDC OIDC-02-07-30 6B.2.7 The Identity Exchange MUST provide an

Authentication Context Class Reference (ACR), See
section 2.8.3 below on valid ACR Claims.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-02-07-31 6B.2.7 The Identity Exchange MUST return the ACR value
used for the authentication even if the acr claim
was not marked essential or the acr_values
parameter was used.

OIDC OIDC-02-08-01 6B.2.8 Discovery mandates the inclusion of the

claims_supported field that defines the claims a
client MAY expect to receive for the supported
scopes.

OIDC OIDC-02-08-02 6B.2.8 Authorisation Servers MUST return claims on a

best effort basis. An Identity Exchange asserting
that it can provide a user claim however, does not
imply that the data is available for all its users.

OIDC OIDC-02-08-03 6B.2.8 Identity Exchanges MUST only return claims as

described in the TDIF: 06D - Attribute Profile.

OIDC OIDC-02-08-04 6B.2.8 A Relying Party MAY use either acr_values or the
acr claim to request an ACR.
OIDC OIDC-02-08-05 6B.2.8 The Identity Exchange MUST reject any requests
that include both the acr_values parameter and
the acr claim to request an ACR.

OIDC OIDC-02-08-06 6B.2.8 Where the ACR is requested using the acr claim,
this acr claim MAY be marked as essential claim
[see example for further details]

OIDC OIDC-02-08-07 6B.2.8 When the acr values are marked as an essential
claim, the Identity Provider MUST return a value
that matches the requested values.

OIDC OIDC-02-08-08 6B.2.8 If the End-User is unable to achieve a level of

assurance that matches the request then an
authentication error response MUST be returned.

OIDC OIDC-02-08-09 6B.2.8 When the acr claim is not marked as essential, i.e.
they are a voluntary claim, the Applicant MAY
return the level of assurance that the End-User
was able to achieve.

OIDC OIDC-02-08-10 6B.2.8 The Relying Party MUST determine if the returned
ACR meets the minimum requirement for the
authentication context that was requested.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-02-10-01 6B.2.10 All transactions MUST be protected by TLS. The

specific requirements for the version of TLS to be
used by an Applicant can be found in section 4.2.8
of the TDIF: 04 – Functional Requirements.

OIDC OIDC-02-10-02 6B.2.10 All clients MUST conform to the applicable

recommendations in the Security considerations
section of [RFC 6749] and those found in the
OAuth 2.0 Threat Model and Security
Considerations document.

OIDC OIDC-03-01-01 6B.3.1 The resource owner password credentials grant

type as defined in [RFC 6749] is intentionally
omitted and MUST NOT be used under these
profiles.

OIDC OIDC-03-01-02 6B.3.1 These clients MUST use the authorisation code
flow of OAuth 2.0 by sending the resource owner
to the authorisation endpoint to obtain
authorisation.

OIDC OIDC-03-01-03 6B.3.1 The user MUST authenticate to the authorisation

endpoint. The user’s web browser is then
redirected back to a URI hosted by the client
service, from which the client can obtain an
authorisation code passed as a query parameter.
The client then presents that authorisation code
along with its own credentials (private_key_jwt) to
the authorisation server’s token endpoint to obtain
an access token.

OIDC OIDC-03-01-04 6B.3.1 These clients MUST be associated with a unique

public key as described in 3.4 below.
OIDC OIDC-03-01-05 6B.3.1 This client type MAY request and be issued a
refresh token if the security parameters of the
request allow for it.

OIDC OIDC-03-02-01 6B.3.2 The Applicant MUST register with the

authorisation server, and each client instance must
receive a unique client identifier from the
authorisation server.

OIDC OIDC-03-02-02 6B.3.2 Client registration MUST use a static configuration.

There is no support for the dynamic registration of
Identity Exchange clients by Identity Providers.

OIDC OIDC-03-03-01 6B.3.3 As Clients, Identity Exchanges must use the

authorization_code grant type so MUST register
their full redirect URIs.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-03-03-02 6B.3.3 The authorisation server MUST validate the

redirect URI given by the client at the authorisation
endpoint using strict string comparison.

OIDC OIDC-03-03-03 6B.3.3 The Applicant MUST NOT have multiple redirect
URIs on different domains.
OIDC OIDC-03-03-04 6B.3.3 The Applicant MUST NOT forward values passed
back to their redirect URIs to other arbitrary or
user-provided URIs (i.e. no open redirectors).

OIDC OIDC-03-04-01 6B.3.4 As Clients using the authorisation code grant type,
Identity Exchanges MUST have a public and private
key pair type for use in authentication to the token
endpoint.

OIDC OIDC-03-04-02 6B.3.4 As a client, the Applicant MUST register their

public keys in their client registration metadata by
either sending the public key directly in the jwks
field or by registering a jwks_uri that MUST be
reachable by the authorisation server. It is
recommended that clients use a jwks_uri as it
allows for easier key rotation.

OIDC OIDC-03-04-03 6B.3.4 The jwks field or the content available from the
jwks_uri of a client MUST contain a public key in
JSON Web Key Set (JWK Set) format.

OIDC OIDC-03-04-04 6B.3.4 The authorisation server MUST validate the

content of the clients registered jwks_uri
document and verify that it contains a JWK Set.

OIDC OIDC-03-06-01 6B.3.6 The Exchange MUST log all the related interactions
with Identity Providers using the unique audit id it
has generated for an authentication request from
a Relying Party as per the TDIF: 06 - Federation
Onboarding Requirements.

OIDC OIDC-03-06-02 6B.3.6 To enable a traceable audit trail for requests sent
to an Identity Provider, an Exchange MUST
implement a scheme to ensure that each request
be uniquely identifiable at the Identity Provider.

OIDC OIDC-03-06-03 6B.3.6 Clients making a request to the authorisation

endpoint MUST use an unpredictable value for the
state parameter with at least 128 bits of entropy.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-03-06-04 6B.3.6 Clients MUST validate the value of the state
parameter upon return to the redirect URI and
MUST ensure that the state value is securely tied
to the user’s current session e.g. by relating the
state value to a session identifier issued by the
client software to the browser.

OIDC OIDC-03-06-05 6B.3.6 Clients MUST include their full redirect URIs in the
authorisation request. To prevent open redirection
and other injection attacks, the authorisation
server MUST match the entire redirect URI using a
direct string comparison against registered values
and MUST reject requests with invalid or missing
redirect URIs.

OIDC OIDC-03-06-06 6B.3.6 The Authentication Request MUST contain the

following REQUIRED parameters and MAY contain
the following OPTIONAL parameter values: [Refer
to list of parameters]

OIDC OIDC-03-06-07 6B.3.6 Additional claims MAY be included in this set.

OIDC OIDC-03-06-08 6B.3.6 The JWT assertion MUST be signed by the client
using the client’s private key. See section 3.4 for
the mechanisms by the client can make its public
key known to the authorization server.

OIDC OIDC-03-06-09 6B.3.6 The following claims MUST be included in a

request to a Token Endpoint: [Refer to list of
parameters]

OIDC OIDC-03-06-10 6B.3.6 The Access Token obtained from an OpenID

Connect Authentication Request MUST be sent as
a Bearer Token as per section 2 of OAuth Bearer
Token Usage [RFC 6750].

OIDC OIDC-03-06-11 6B.3.6 ID Tokens MAY be encrypted using the appropriate

key of the requesting client.
OIDC OIDC-03-06-12 6B.3.6 Clients MUST verify the following in received ID
tokens: [Refer to list of parameters]
OIDC OIDC-03-06-13 6B.3.6 Clients MAY optionally send requests to the
Authorization Endpoint using the request
parameter as defined in [OpenIDCore].

OIDC OIDC-03-06-14 6B.3.6 Request objects MUST be signed by the clients

registered key. Request objects MAY be encrypted
to the Authorisation Server’s public key.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-03-06-15 6B.3.6 The Identity Exchange MAY cache OpenID Provider
(OP) metadata once an OP has been discovered
and used by the Identity Exchange.

OIDC OIDC-03-07-01 6B.3.7 The Identity Provider MUST always log all
authentication requests and responses, including
the values of client_id and the state parameters
associated with the request.

OIDC OIDC-03-07-02 6B.3.7 The authorisation server MUST validate all redirect
URIs for the authorization_code grant type.

OIDC OIDC-03-07-03 6B.3.7 The authorisation server MUST enforce client

authentication to the authorization servers token
endpoint using a JWT assertion as defined by using
only the private_key_jwt method as described in
[OpenIDCore]. Clients that have registered a public
key sign a JWT using the associated private key.
The Client authenticates in accordance with JSON
Web Token (JWT) Profile for OAuth 2.0 Client
Authentication and Authorization Grants and
Assertion Framework for OAuth 2.0 Client
Authentication and Authorization Grants.

OIDC OIDC-03-07-04 6B.3.7 The JWT must expire and MAY have a lifetime no
longer than five minutes. Short expiration times
are recommended wherever practicable. The
following guidance is provided in [RFC 7523]
regarding expiration times: the JWT MUST contain
an "exp" (expiration time) claim that limits the
time window during which the JWT can be used.
The authorization server MUST reject any JWT with
an expiration time that has passed, subject to
allowable clock skew between systems. Note that
the authorization server may reject JWTs with an
"exp" claim value that is unreasonably far in the
future.

OIDC OIDC-03-07-05 6B.3.7 The JWT MUST contain the following REQUIRED
claims and MAY contain the following OPTIONAL
Claim values: [Refer to list of parameters]

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-03-07-06 6B.3.7 Endpoints and parameters specified in the

Discovery document MAY be considered public
information regardless of the existence of the
discovery document.

OIDC OIDC-03-07-07 6B.3.7 Access to the Discovery document MAY be

protected with existing web authentication
methods if required by the Identity Exchange.
Credentials for the Discovery document are then
managed by the Identity Exchange and support for
these authentication methods is outside the scope
of this specification.

OIDC OIDC-03-07-08 6B.3.7 Endpoints described in the Discovery document

MUST be secured in accordance with this
specification and MAY have additional controls the
Identity Exchange wishes to support.

OIDC OIDC-03-07-09 6B.3.7 The discovery document MUST as a minimum

contain the following fields: [Refer to list of
parameters]

OIDC OIDC-03-07-10 6B.3.7 The IdP MUST support ALL of the mechanisms for
requesting a Level of assurance as described in
section 3.8.3 of this document.

OIDC OIDC-03-07-11 6B.3.7 The Authorization Response to the Authorization

Code flow MUST return the following fields in the
response: [Refer to list of parameters]

OIDC OIDC-03-07-12 6B.3.7 All tokens MUST be signed by the issuer IdP’s
private key.
OIDC OIDC-03-07-13 6B.3.7 ID Tokens MAY be encrypted using the appropriate
key of the requesting client.
OIDC OIDC-03-07-14 6B.3.7 The ID Token MUST expire and MAY have a
lifetime no longer than five minutes. Short
expiration times are recommended as the ID token
is consumed by the client and not presented to
remote systems.

OIDC OIDC-03-07-15 6B.3.7 When an ID Token is returned, ID Token values

which are defined as REQUIRED MUST be included
in the ID Token.

OIDC OIDC-03-07-16 6B.3.7 When an ID Token is returned, ID Token values

which are defined as OPTIONAL MAY be included
in the ID Token, unless otherwise specified in
another requirement in this document.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-03-07-17 6B.3.7 Identity Providers MUST support the UserInfo

endpoint for claims as described in the TDIF:
Attribute Profile.

OIDC OIDC-03-07-18 6B.3.7 The UserInfo endpoint MUST only return claims
that are authorised within the authentication
request that issued the access token that is being
used to access the endpoint.

OIDC OIDC-03-07-19 6B.3.7 For privacy reasons, the Identity Provider MAY
elect to not return values for some of the
requested claims; it should not present with a null
or empty string value.

OIDC OIDC-03-07-20 6B.3.7 The sub claim MUST always be returned in the
UserInfo Response.
OIDC OIDC-03-07-21 6B.3.7 The Identity Provider MUST accept requests
containing a request object signed by the Identity
Exchange’s private key.

OIDC OIDC-03-07-22 6B.3.7 The Identity Provider MUST validate the signature
on such requests against the Identity Exchange’s
public key

OIDC OIDC-03-07-23 6B.3.7 The Identity Provider MUST accept request objects
encrypted with the Identity Providers Public key.

OIDC OIDC-03-07-24 6B.3.7 The Identity Provider MUST return the ACR value
used for the authentication even if the acr claim
was not marked as essential or the acr_values
parameter was used.

OIDC OIDC-03-08-01 6B.3.8 Servers MUST return claims on a best effort basis.

OIDC OIDC-03-08-02 6B.3.8 An Identity Exchange asserting that it can provide a

user claim however, does not imply that the data is
available for all its users. Clients MUST be prepared
to receive partial data.

OIDC OIDC-03-08-03 6B.3.8 Identity Exchanges MAY return claims outside of

the claims_supported list but MUST ensure that
they do not violate the privacy policies set out by
the federation.

OIDC OIDC-03-08-04 6B.3.8 The Identity Exchange MAY use either acr_values
or the acr claim to request an ACR.
OIDC OIDC-03-08-05 6B.3.8 The Identity Exchange MUST NOT specify both the
acr claim and acr_values.

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-03-08-06 6B.3.8 The Identity Exchange (acting as the Relying Party
in this profile) MUST request the full set of ACR
values that will meet the original Relying Party’s
minimum assurance requirements.

OIDC OIDC-03-08-07 6B.3.8 When the ACR values are marked as an essential
claim, the Identity Provider MUST return a value
that matches the requested values.

OIDC OIDC-03-08-08 6B.3.8 If the End-User is unable to achieve a level of

assurance that matches at least one of the ACR
values requested by an Exchange then an
authentication error response MUST be returned.

OIDC OIDC-03-08-09 6B.3.8 When the acr claim is not marked as essential, i.e.
they are a voluntary claim, the Identity Provider
MAY return the level of assurance that the End-
User was able to achieve.

OIDC OIDC-03-08-10 6B.3.8 The Identity Exchange MUST determine if the

returned ACR meets the minimum requirement for
the authentication context that was requested.

OIDC OIDC-03-10-01 6B.3.10 All transactions MUST be protected by TLS. The

specific requirements for the version of TLS to be
used by an Applicant can be found in section 4.2.8
of the TDIF: 04 – Functional Requirements.

OIDC OIDC-03-10-02 6B.3.10 All clients MUST conform to the applicable

recommendations in the Security considerations
section of [RFC 6749] and those found in the
OAuth 2.0 Threat Model and Security
Considerations document [RFC 6819].

OIDC OIDC-04-01-01 6B.4.1 When making or responding to a request using the

OIDC 1.0 federation protocol the Applicant MUST
use the mapping of the attributes to the scopes
and claims specified in section 4.1 of the
[TDIF.Attr].

OIDC OIDC-04-01-02 6B.4.1 The Applicant MUST support all the scopes and
claims defined in section 4.1.2 of the [TDIF.Attr].

OIDC OIDC-04-01-03 6B.4.1 The Applicant MUST support all the scopes and
claims defined in section 4.1.3 of the [TDIF.Attr].

# A80000OFFICIAL
 A80000OFFICIAL #

OIDC OIDC-04-01-04 6B.4.1 The Applicant MUST support individual claim

requests for tdif_doc and individual claim requests
for a specific document type using the standard
OIDC members in the JSON object that requests
the claim as specified in Table 1.

0 TDIF: 06C - SAML 2.0 Profile

SAML SAML-02-02-01 6C.2.2 Implementations MUST allow for reasonable clock
skew between systems when interpreting
xsd:dateTime values and enforcing security policies
based thereupon.

SAML SAML-02-02-02 6C.2.2 Where specific constraints are absent in the SAML
standards or profile documents, Applicant’s
implementations MUST be able to accept without
error or truncation, element and attribute values
of type xs:string that are comprised of any
combination of valid XML characters and
containing up to 256 characters. This requirement
applies to both user defined types and the types
defined within the SAML standards such as
transient and persistent NameIDs.

SAML SAML-02-02-03 6C.2.2 Implementations MUST NOT send and MUST have
the ability to reject SAML protocol messages
containing a Document Type Definition (DTD).

SAML SAML-02-03-01 6C.2.3 The Applicant’s implementations MUST support

the routine consumption of SAML metadata from a
remote location via HTTP/1.1 [RFC 2616] on a
scheduled or recurring basis with the contents
applied automatically upon successful validation.

SAML SAML-02-03-02 6C.2.3 HTTP/1.1 redirects (status codes 301, 302, and
307) MUST be honoured by the Applicant.
SAML SAML-02-03-03 6C.2.3 The Applicants implementation MUST support the
consumption of SAML metadata rooted in both
<md:EntityDescriptor> and
<md:EntitiesDescriptor> elements by this
mechanism. Any number of child elements must
be allowed for <md:EntitiesDescriptor>.

# A80000OFFICIAL
 A80000OFFICIAL #

SAML SAML-02-03-04 6C.2.3 The Applicant MAY support the acquisition of

SAML metadata rooted in <md:EntityDescriptor>
elements via the Metadata Query Protocol,
defined in [SAML-MDQ] and [MDQ].

SAML SAML-02-03-05 6C.2.3 Applicant’s Implementations that claim support for

this protocol MUST be able to request and utilise
metadata from one or more MDQ responders for
any entity from which a SAML protocol message is
received.

SAML SAML-02-03-06 6C.2.3 The Applicant MUST validate the authenticity and
integrity of SAML metadata by verifying an
enveloped XML signature attached to the root
element of the metadata.

SAML SAML-02-03-07 6C.2.3 Public keys used for signature verification of the
metadata MUST be configured out of band by the
Applicant.

SAML SAML-02-03-08 6C.2.3 These keys MAY be contained by the Applicant

within X.509 certificates but it MUST be possible to
ignore the other content in the certificate and
validate the XML Signature based on the public
key.

SAML SAML-02-03-09 6C.2.3 It MUST be possible for the Applicant to limit the
use of a trusted key to a single metadata source.

SAML SAML-02-03-10 6C.2.3 Applicant’s Implementations MUST reject

metadata if any one of the following conditions is
true:
• The validUntil XML attribute on the root
element is missing.
• The value of the validUntil XML attribute on
the root element is a xsd:dateTime in the past.
• The value of the validUntil XML attribute on
the root element is a xsd:dateTime too far into the
future, where too far into the future is a
configurable option.

# A80000OFFICIAL
 A80000OFFICIAL #

SAML SAML-02-03-11 6C.2.3 Applicant’s Implementations MUST support SAML

metadata as defined in the following OASIS
specifications:
• SAML V2.0 Metadata [SAML2Meta] as
updated by Errata [MetaAttr].
• SAML V2.0 Metadata Schema [SAML2MD-
xsd].
• SAML V2.0 Metadata Interoperability Profile
[SAML2MDIOP].
• SAML V2.0 Metadata Extension for Algorithm
Support [SAML2MetaAlgSup].

SAML SAML-02-03-12 6C.2.3 Applicant’s Implementations MAY support SAML

V2.0 Metadata Extension for Entity Attributes
[MetaAttr].

SAML SAML-02-03-13 6C.2.3 Service Providers MAY support: SAML V2.0

Metadata Extensions for Login and Discovery User
Interface [MetaUI].

SAML SAML-02-03-14 6C.2.3 In accordance with the Extensibility section 2.5

below, other metadata may be present and MUST
NOT prevent the consumption and use of the
metadata.

SAML SAML-02-03-15 6C.2.3 Applicant’s Implementations MUST support the

interpretation and application of metadata as
defined by [SAML2MDIOP].

SAML SAML-02-03-16 6C.2.3 Applicant’s Implementations MUST be able to

interoperate with any number of SAML peers for
which metadata is available without additional
inputs or separate configuration.

SAML SAML-02-03-17 6C.2.3 Applicant’s Implementations MUST have the ability

to consume and make use of any number of
signing keys bound to a single role descriptor in
metadata.

SAML SAML-02-03-18 6C.2.3 When verifying digital signatures, Applicant’s

implementations MUST attempt to use each
signing key until the signature is verified or there
are no remaining keys and the signature
verification is then deemed to have failed.

# A80000OFFICIAL
 A80000OFFICIAL #

SAML SAML-02-03-19 6C.2.3 If an Applicant’s implementation supports out

bound encryption it MUST be able to consume any
number of encryption keys bound to a single role
descriptor in the metadata. If multiple encryption
keys are specified any one of them may be used to
encrypt outbound messages.

SAML SAML-02-03-20 6C.2.3 Applicant’s implementations MUST be capable of

publishing the cryptographic capabilities of their
runtime configurations regarding XML Signature
and Encryption. It is recommended that they
support dynamic generation and export of this
information and provide it in a machine readable
format that can be included in metadata according
to [SAML2MetaAlgSup].

SAML SAML-02-03-21 6C.2.3 If a SAML peer has declared algorithm support

according to [SAML2MetaAlgSup] in its metadata,
SAML Identity Providers MUST and SAML Service
Providers MAY limit the use of algorithms for XML
Signature and Encryption to those declared in the
messages they produce for that peer.

SAML SAML-02-03-22 6C.2.3 Applicant’s implementations MAY be able to

support the use of good and bad algorithms for
some time to relax the schedule of updates.
Implementations should select the most secure
algorithm from those that are available.

SAML SAML-02-03-23 6C.2.3 A <md:KeyDescriptor> element in metadata that

contains no use XML Attribute MUST be valid as
both a signing and encryption key. This is clarified
in E62 of the SAML 2.0 Errata.

SAML SAML-02-04-01 6C.2.4 Applicant’s implementations MUST support the

SAML 2.0 Web Browser SSO profile as defined in
and as updated by [SAML2Errata].

SAML SAML-02-04-02 6C.2.4 SAML Identity Providers MUST support both the
HTTP-Redirect and HTTP-POST bindings for
authentication requests.

SAML SAML-02-04-03 6C.2.4 SAML Service Providers MUST support either the
HTTP-Redirect and HTTP-POST bindings for
authentication requests.

SAML SAML-02-04-04 6C.2.4 Applicant’s implementations MUST support the

signing of assertions and responses, both together
and independently.

# A80000OFFICIAL
 A80000OFFICIAL #

SAML SAML-02-04-05 6C.2.4 Applicant’s implementations MUST support the

following SAML 2.0 name identifier formats, in
accordance with the normative obligations
associated with them by [SAML2Core] section 8.3:
• urn:oasis:names:tc:SAML:2.0:nameid-
format:persistent

SAML SAML-02-04-06 6C.2.4 Applicant’s implementations MUST support the

consumption of peer configuration values from
SAML metadata, without additional inputs or
separate configuration, for any metadata element
that:
• Is identified as MUST or MAY in the “Use of
Metadata” section for the Web Browser SSO
Profile in [SAML2Prof] section 4.1.6; and
corresponds to settings supported by the
implementation.
• Unless specifically noted by subsequent
requirements in this profile it is OPTIONAL for
implementations to support the inclusion of
optional elements and attributes in the protocol
messages and assertions issued. It is REQUIRED
that implementations successfully process
messages and assertions containing any optional
content they do not support i.e. this content must
not result in errors or may be ignored, as directed
by the processing rules for the element or attribute
in [SAML2Core].

SAML SAML-02-05-01 6C.2.5 Applicant’s implementations MUST successfully

consume any well-formed extension. Unless
otherwise noted in these profiles the content of
<samlp:Extension>, <md:Extensions> and
<saml:Advice> elements MAY be ignored but
MUST NOT result in software failures.

SAML SAML-02-05-02 6C.2.5 Any element established in [SAML2MD-xsd] with a

type definition containing an xsd:anyAttribute sub-
element may include undefined attribute content.
The Applicant MAY ignore this content but doing
so MUST NOT result in software failures.

# A80000OFFICIAL
 A80000OFFICIAL #

SAML SAML-02-06-01 6C.2.6 The Service Provider MAY request a single

<saml:AuthnContextClassRef> that will meet the
SPs minimum Identity and Credential
requirements.

SAML SAML-02-06-02 6C.2.6 The IdP MUST return the

<saml:AuthnContextClassRef> that is the
representation of the assurance levels that are
defined in TDIF: 06 – Federation Onboarding
Requirements.

SAML SAML-03-01-01 6C.3.1 Service Providers MUST support the consumption

of <saml:Attribute> elements containing any
arbitrary xs:string value in the Name attribute and
any arbitrary xs:anyURI value in the NameFormat
attribute.

SAML SAML-03-01-02 6C.3.1 Service Providers MUST support the consumption

of <saml:AttributeValue> elements containing any
“simple” element content; that is, element content
consisting only of text nodes, not mixed/complex
content that may contain nested XML elements. It
is OPTIONAL to support complex content.

SAML SAML-03-01-03 6C.3.1 Service providers MUST generate

<saml:AuthnRequest> messages with a
<samlp:NameIDPolicy> element with a
<samlp:NameIDPolicy> Format of
urn:oasis:names:tc:SAML:2.0:nameid-
format:persistent and AllowCreate set to true.

SAML SAML-03-01-04 6C.3.1 Service Providers MUST support IdP discovery in

accordance with [IdPDisco].
SAML SAML-03-01-05 6C.3.1 Service Providers MUST be capable of generating
<samlp:AuthnRequest> messages with a
<samlp:RequestedAuthnContext> element
containing the exact comparison method and any
number of <samlp:AuthnContextClassRef>
elements as described in section 2.6
Authentication Context Class Reference.

SAML SAML-03-01-06 6C.3.1 When decrypting assertions, an attempt to use

each decryption key MUST be made until the
assertion is successfully decrypted or there are no
more keys whereupon the decryption fails.

# A80000OFFICIAL
 A80000OFFICIAL #

SAML SAML-03-01-07 6C.3.1 Service providers MUST support deep linking and
maintain the direct accessibility of protected
resources in the presence of Web Browser SSO.

SAML SAML-03-01-07a 6C.3.1 It MUST be possible to request an arbitrary

protected resource and where the authorization
permits, have it supplied as the result of a
successful SAML SSO profile exchange.

SAML SAML-03-01-08 6C.3.1 Service Providers MUST NOT require the presence
of the xsi:type XML attribute.
SAML SAML-03-01-09 6C.3.1 Service Providers MAY support the acceptance or
rejection of assertion based on the content of the
<saml:AuthnContext> element.

SAML SAML-03-01-10 6C.3.1 Service Providers MAY support decryption of

<saml:EncryptedAssertion> elements. To fully
support key rollover, Service Providers MUST be
configurable with at least two decryption keys.

SAML SAML-03-01-11 6C.3.1 Service Providers MAY support the preservation of

POST bodies across a successful SSO profile
exchange, subject to size limitations dictated by
policy or implementation constraints.

SAML SAML-03-01-12 6C.3.1 Service Providers MUST NOT fail or reject

responses due to the presence of unrecognised
<saml:Attribute> elements.

SAML SAML-03-01-13 6C.3.1 Service Providers MUST NOT treat the

FriendlyName attribute normatively or make
comparisons based on its value.

SAML SAML-03-01-14 6C.3.1 Service Providers MUST NOT require that the
name identifiers with a format of
urn:oasis:names:tc:SAML:2.0:nameid-
format:persistent to be overloaded with semantics
or content beyond what is outlined in
[SAML2Core] section 8.3.7.

SAML SAML-03-01-15 6C.3.1 Service Providers MUST support the ability to

reject unsigned <samlp:Response> elements and
should do so by default.

SAML SAML-03-02-01 6C.3.2 Identity Providers MUST support the generation of

<saml:Attribute> elements containing any arbitrary
xs:string value in the Name attribute and any
arbitrary xs:anyURI value in the NameFormat
attribute.

# A80000OFFICIAL
 A80000OFFICIAL #

SAML SAML-03-02-02 6C.3.2 Identity Providers MUST be capable of determining

whether or not to include specific SAML attributes
or specific values in a response based on the
entityID of the Relying Party.

SAML SAML-03-02-03 6C.3.2 Identity Providers MUST be capable of determining

whether or not to include specific SAML attributes
or specific values in a response based on the
presence of <mdattr:EntityAttributes> extension
elements [MetaAttr].

SAML SAML-03-02-04 6C.3.2 Identity Providers MUST be capable of determining

whether or not to include specific SAML attributes
or values in a response based on the presence of
<md:AttributeConsumingService> elements
(containing <md:RequestedAttribute> elements)
found in metadata for a Relying Party, including
the value of the enclosed isRequired XML
attribute.

SAML SAML-03-02-05 6C.3.2 The Identity Provider MUST support the

AttributeConsumingServiceIndex attribute in
<samlp:AuthnRequest> messages as a means of
determining the appropriate
<md:AttributeConsumingService> element to
process.

SAML SAML-03-02-05a 6C.3.2 Attributes released this way MUST only be

released in accordance with the Attribute Sharing
Policies set out in TDIF: 06 – Federation
Onboarding Requirements.

SAML SAML-03-02-06 6C.3.2 Identity Providers MUST support the issuance of

<samlp:Response> messages with the appropriate
status code in the event of an error condition,
provided the user agent remains available and an
acceptable location to which to deliver the
response is known. The criteria for “acceptability”
of a response location are not formally specified
but are subject to Identity Provider policy and
reflect its responsibility to protect users from being
sent to untrusted or possible malicious parties.

# A80000OFFICIAL
 A80000OFFICIAL #

SAML SAML-03-02-07 6C.3.2 Identity Providers MUST support the ForceAuthn

attribute in the <samlp:AuthnRequest> messages
as defined in [SAML2Core].

SAML SAML-03-02-07a 6C.3.2 The authentication mechanism within an

implementation MUST have access to the
ForceAuthn indicator so that their behaviour may
be influenced by its value.

SAML SAML-03-02-08 6C.3.2 Identity Providers MUST support the isPassive

attribute in <samlp:AuthnRequest> messages as
defined in [SAML2Core].

SAML SAML-03-02-09 6C.3.2 Identity Providers MUST support the

<saml:RequestAuthnContext> exact and minimum
comparison method in <samlp:AuthnRequest>
messages as defined in [SAML2Core].

SAML SAML-03-02-10 6C.3.2 Identity providers MAY support encryption of

assertions. Support for encryption of identifiers
and attributes is OPTIONAL.

SAML SAML-03-02-11 6C.3.2 Identity Providers MUST support the

<samlp:NameIDPolicy> element in
<samlp:AuthnRequest> messages as defined in
[SAML2Core].

SAML SAML-03-02-12 6C.3.2 Identity Providers MUST support the

AssertionConsumerServiceURL, ProtocolBinding,
and AssertionConsumerServiceIndex attributes in
<samlp:AuthnRequest> messages for the
identification of the response endpoint and
binding as defined in [SAML2Core].

SAML SAML-04-01-01 6C.4.1 Service Providers MUST support the consumption

of <saml:Attribute> elements containing any
arbitrary xs:string value in the Name attribute and
any arbitrary xs:anyURI value in the NameFormat
attribute.

SAML SAML-04-01-02 6C.4.1 Service Providers MUST support the consumption

of <saml:AttributeValue> elements containing any
“simple” element content; that is, element content
consisting only of text nodes, not mixed/complex
content that may contain nested XML elements. It
is OPTIONAL to support complex content. Service
Providers MUST NOT require the presence of the
xsi:type XML attribute.

# A80000OFFICIAL
 A80000OFFICIAL #

SAML SAML-04-01-03 6C.4.1 Service providers MUST be capable of generating,

<saml:AuthnRequest> messages without a
<samlp:NameIDPolicy> element and with a
<samlp:NameIDPolicy> element but no Format
attribute.

SAML SAML-04-01-04 6C.4.1 Service Providers MUST support IdP discovery in

accordance with [IdPDisco].
SAML SAML-04-01-05 6C.4.1 Service providers MUST support the processing of
responses from any number of issuing IdPs for any
given resource URL. It MUST NOT be a restriction
of an implementation that multiple IdPs can only
be supported by requiring distinct resource URLs
for each IdP. The ability to satisfy this requirement
should come naturally from the ability to support
[IdPDisco].

SAML SAML-04-01-06 6C.4.1 Service Providers MUST be capable of generating

<samlp:AuthnRequest> messages with a
<samlp:RequestedAuthnContext> element
containing the exact comparison method and any
number of <samlp:AuthnContextClassRef>
elements.

SAML SAML-04-01-07 6C.4.1 Service Providers MUST support the acceptance or

rejection of assertion based on the content of the
<saml:AuthnContext> element.

SAML SAML-04-01-08 6C.4.1 Service Providers MUST support decryption of

<saml:EncryptedAssertion> elements.
SAML SAML-04-01-09 6C.4.1 To fully support key rollover, Service Providers
MUST be configurable with at least two decryption
keys.

SAML SAML-04-01-09a 6C.4.1 When decrypting assertions, an attempt to use

each decryption key MUST be made until the
assertion is successfully decrypted or there are no
more keys whereupon the decryption fails.
Support for unsolicited responses (IdP initiated
SSO) is not a substitute for this requirement.

SAML SAML-04-01-10 6C.4.1 Service Providers MUST support the ability to

reject unsigned <samlp:Response> elements and
should do so by default.

SAML SAML-04-01-11 6C.4.1 Service Providers MUST NOT fail or reject

responses due to the presence of unrecognised
<saml:Attribute> elements.

# A80000OFFICIAL
 A80000OFFICIAL #

SAML SAML-04-01-12 6C.4.1 Service Providers MUST NOT treat the

FriendlyName attribute normatively or made
comparisons based on its value.

SAML SAML-04-01-13 6C.4.1 Service Providers MUST NOT require that the
name identifiers with a format of
urn:oasis:names:tc:SAML:2.0:nameid-
format:persistent be overloaded with semantics or
content beyond what is outlined in [SAML2Core]
section 8.3.7.

SAML SAML-04-02-01 6C.4.2 Identity Providers MUST support the generation of

<saml:Attribute> elements containing any arbitrary
xs:string value in the Name attribute and any
arbitrary xs:anyURI value in the NameFormat
attribute.

SAML SAML-04-02-02 6C.4.2 Identity Providers MUST be capable of determining

whether or not to include specific SAML attributes
or specific values in a response based on the
entityID of the Relying Party.

SAML SAML-04-02-03 6C.4.2 Identity Providers MUST be capable of determining

whether or not to include specific SAML attributes
or specific values in a response based on the
presence of <mdattr:EntityAttributes> extension
elements [MetaAttr].

SAML SAML-04-02-04 6C.4.2 Identity Providers MUST be capable of determining

whether or not to include specific SAML attributes
or values in a response based on the presence of
<md:AttributeConsumingService> elements
(containing <md:RequestedAttribute> elements)
found in metadata for a Relying Party, including
the value of the enclosed isRequired XML
attribute.

SAML SAML-04-02-05 6C.4.2 The Identity Provider MUST support the

AttributeConsumingServiceIndex attribute in
<samlp:AuthnRequest> messages as a means of
determining the appropriate
<md:AttributeConsumingService> element to
process.

# A80000OFFICIAL
 A80000OFFICIAL #

SAML SAML-04-02-06 6C.4.2 Identity Providers MUST support the issuance of

<samlp:Response> messages with the appropriate
status code in the event of an error condition,
provided the user agent remains available and an
acceptable location to which to deliver the
response is known. The criteria for “acceptability”
of a response location are not formally specified
but are subject to Identity Provider policy and
reflect its responsibility to protect users form being
sent to untrusted or possible malicious parties.

SAML SAML-04-02-07 6C.4.2 Identity Providers MUST support the ForceAuthn

attribute in the <samlp:AuthnRequest> messages
as defined in [SAML2Core].

SAML SAML-04-02-08 6C.4.2 The authentication mechanism within an

implementation MUST have access to the
ForceAuthn indicator so that their behaviour may
be influenced by its value.

SAML SAML-04-02-09 6C.4.2 Identity Providers MUST support the isPassive

attribute in <samlp:AuthnRequest> messages as
defined in [SAML2Core].

SAML SAML-04-02-10 6C.4.2 Identity Providers MUST support the

<saml:RequestAuthnContext> exact comparison
method in <samlp:AuthnRequest> messages as
defined in [SAML2Core].

SAML SAML-04-02-11 6C.4.2 Identity providers MUST support encryption of

assertions. Support for encryption of identifiers
and attributes is OPTIONAL.

SAML SAML-04-02-12 6C.4.2 Identity Providers MUST support the

<samlp:NameIDPolicy> element in
<samlp:AuthnRequest> messages as defined in
[SAML2Core].

SAML SAML-04-02-13 6C.4.2 Identity Providers MUST be capable of generating

<saml:Assertion> elements without a
<saml:NameID> element in the <saml:Subject>
element.

# A80000OFFICIAL
 A80000OFFICIAL #

SAML SAML-04-02-14 6C.4.2 Identity Providers MUST support the

AssertionConsumerServiceURL, ProtocolBinding,
and AssertionConsumerServiceIndex attributes in
<samlp:AuthnRequest> messages for the
identification of the response endpoint and
binding as defined in [SAML2Core].

SAML SAML-05-01-01 6C.5.1 Attributes MAY be requested as part of the SAML

Authentication Request. These attributes are
requested through the Extension element.

SAML SAML-05-01-02 6C.5.1 The Sender and the Recipient of the request MAY
agree to the semantics of data sent this way.

SAML SAML-05-01-03 6C.5.1 When making or responding to a request using the

SAML 2.0 Federation Protocol the Applicant MUST
use the mapping of the attributes to the protocols
specified in section 4.2.2 of the TDIF: 06D –
Attribute Profile.

SAML SAML-05-01-04 6C.5.1 The following approach MUST be used for complex
objects that have nested elements:
• Where there is at most one instance of the
complex object, then the contents of the complex
object may be flattened into separate SAML
attributes where the name of the attribute is
qualified with xml namespace that is the extension
namespace for TDIF attributes. See an example of
this approach at
http://www.simplecloud.info/specs/draft-scim-
saml2-binding-02.html#anchor5
• Where there is one or more instances of the
complex object then the JSON representation of
the component object as defined by this
specification may be included as the
<AttributeValue> element as a XML string.

Section Requirement Subsection TDIF 07 - Annual Assessment

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL 2.2 2.2 Accredited Provider Obligations

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-02-01 2.2 The Accredited Provider MUST ensure that all
Annual Assessment requirements are completed
by the anniversary of its initial accreditation date.
Failure by an Accredited Provider to complete the
Annual Assessment in accordance with the TDIF is
a breach of the Accredited Provider’s obligations
under the TDIF and may result in the termination
of accreditation.

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL 2.3 1.1 Assessor skills, experience and independence

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-03-01 2.3 The Accredited Provider MUST demonstrate to the

DTA how the Assessors have relevant, reasonable
and adequate experience, training and
qualifications to conduct the Annual Assessment.

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-03-01a 2.3 The Accredited Provider MUST demonstrate to the

DTA how the Assessors:
• Are independent from the development and
operational teams of the Accredited Provider’s
Identity System.
• Do not possess a conflict of interest in
performing the Annual Assessment on the
Accredited Provider’s Identity System.

ANNUAL 2.4 2.4 Annual Assessment schedule

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-04-01 2.4 Annual Assessments that occur during:

• Even calendar years (i.e. 2020, 2022, 2024, etc)
MUST be undertaken by Assessors who are
external to the Accredited Provider’s organisation.
• Odd calendar years (i.e. 2021, 2023, 2025, etc)
MAY be undertaken by Assessors who are external
to the development and operational teams of the
Accredited Provider’s Identity System.

ANNUAL 2.4.1 2.4.1 Annual Assessment process

ANNUAL ANNUAL-02-04-02 2.4.1 The Accredited Provider MUST ensure Assessors

have access to and consider all relevant evidence
provided by the Accredited Provider to the DTA.
This includes any responses by the DTA to
questions which may have been asked.

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-04-03 2.4.1 The Accredited Provider MUST ensure Assessors

conduct the Annual Assessments and prepares the
Annual Assessment Report in accordance with the
requirements of the TDIF.

ANNUAL ANNUAL-02-04-04 2.4.1 The Accredited Provider MUST use the compliance
ratings listed in ‘Appendix A: Compliance ratings’
when determining areas of compliance and non-
compliance with the requirements of the TDIF.

ANNUAL ANNUAL-02-04-05 2.4.1 As part of the Annual Assessment, the Assessors

MUST undertake the following activities:

ANNUAL ANNUAL-02-04-05 2.4.1

ANNUAL ANNUAL-02-04-05 2.4.1

ANNUAL ANNUAL-02-04-05a 2.4.1 As part of the Annual Assessment, the Assessors

MAY undertake a site visit to the Accredited
Provider’s premises or other location where it
provides services in connection with its Identity
System.

ANNUAL ANNUAL-02-04-06 2.4.1 As part of the Annual Assessment the Accredited

Provider MUST provide the DTA with:

ANNUAL ANNUAL-02-04-06 2.4.1

ANNUAL ANNUAL-02-04-06 2.4.1

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-04-06 2.4.1

ANNUAL 2.5 2.5 Annual Assessment reporting

ANNUAL ANNUAL-02-05-01 2.5 The Accredited Provider MUST ensure that the
Assessor prepares Annual Assessment Reports
which cover:

ANNUAL ANNUAL-02-05-01 2.5

ANNUAL ANNUAL-02-05-01 2.5

ANNUAL ANNUAL-02-05-01 2.5

ANNUAL ANNUAL-02-05-01 2.5

ANNUAL ANNUAL-02-05-01 2.5

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-05-02 2.5 As part of the Annual Assessment the Accredited

Provider MUST provide the DTA with:

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-02 2.5

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-02 2.5

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-02 2.5

ANNUAL ANNUAL-02-05-03 2.5 The Accredited Provider’s Accountable Authority

MUST respond in writing to any adverse findings
identified by the Assessors in the Annual
Assessment Reports including whether the
recommendations are accepted, the reasons for
any nonacceptance and the timeframe for
implementation of the recommendations.

ANNUAL ANNUAL-02-05-04 2.5 The Annual Assessment Reports MUST include the fo

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-05-04 2.5

ANNUAL ANNUAL-02-05-04 2.5

ANNUAL ANNUAL-02-05-04 2.5

ANNUAL ANNUAL-02-05-04 2.5

ANNUAL ANNUAL-02-05-04 2.5

ANNUAL ANNUAL-02-05-04 2.5

ANNUAL ANNUAL-02-05-04 2.5

ANNUAL ANNUAL-02-05-04 2.5

ANNUAL ANNUAL-02-05-04 2.5

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-05-04 2.5

ANNUAL ANNUAL-02-05-04 2.5

ANNUAL 2.6 2.6 Qualifying Attestation Letter

ANNUAL ANNUAL-02-06-01 2.6 The Qualifying Attestation Letter MUST, at a

minimum, contain information that supports the
Accredited Provider’s claim that its operations
remain in accordance with TDIF requirements.

ANNUAL ANNUAL-02-06-02 2.6 In addition, the Qualifying Attestation Letter MUST

be signed by the Accredited Provider’s relevant
Accountable Authority and include the name,
role/position and contact details of the
Accountable Authority that is asserting that the
Accredited Provider’s Identity System complies
with TDIF requirements.

ANNUAL ANNUAL-02-06-03 2.6 The Accredited Provider MAY publish the

Qualifying Attestation Letter onto its public
dashboard or website

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Sub-Requirement A C I X Category

A C I X Unchanged

A C I X Unchanged

A C I X Restructured/Changed

New

A C I X Restructured/Changed

C I Unchanged

# A80000OFFICIAL
 A80000OFFICIAL #

C I Restructured/Changed

A C I X Restructured/Changed

New

A C I X Unchanged

a) Be written for an operational A C I X Unchanged

Identity System, regardless of
whether the
Applicant’s Identity System is
operational or not.

b) summarise the fraud control, A C I X Unchanged

privacy, protective security and
user experience features of the
identity system.

# A80000OFFICIAL
 A80000OFFICIAL #

c) Provide a high-level summary A C I X Unchanged

of how the Applicant will meet
the fraud control, privacy,
protective security and user
experience requirements set out
in TDIF 04 Functional
Requirements.

d) Include the version of the A C I X Unchanged

Australian Government
Information Security Manual
used as its basis (i.e. month and
year).

A C I X Archived

a. Estimated dates when A C I X Restructured/Changed

Functional Assessments will be
undertaken

b. Estimated dates when A C I X Restructured/Changed

Functional Assessment Reports
will be provided to the DTA

c. Estimated dates when the A C I X Restructured/Changed

Applicant’s evidence addressing
TDIF requirements will be
provided to the DTA.

A C I X Restructured/Changed

A C I X Unchanged

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

A C I X Restructured/Changed

Restructured/Changed

Restructured/Changed

A C I X Restructured/Changed

a. An indication of which A C I X Restructured/Changed

Functional Assessment it is
provided as a substitute for.

b. A rationale why it is being A C I X Restructured/Changed

provided.

# A80000OFFICIAL
 A80000OFFICIAL #

c. A summary of which TDIF A C I X Restructured/Changed

requirements the Applicant
believes will be addressed by the
prior audit work.

New

New

New

New

New

# A80000OFFICIAL
 A80000OFFICIAL #

New

New

New

New

New

New

Restructured/Changed
A C I X Restructured/Changed

New

New

# A80000OFFICIAL
 A80000OFFICIAL #

a) Determine the Applicant’s A C I X Restructured/Changed

tolerance for fraud risks.

b) Manage the Applicant’s fraud A C I X Restructured/Changed

risks.

c) Demonstrate how its fraud A C I X Restructured/Changed

controls are applied to its
identity system.

d) Take all reasonable measures A C I X Restructured/Changed

to prevent, detect and deal with
fraud relating to its identity
system.

e) Consider the implications their A C I X Restructured/Changed

risk management decisions have
for other organisations and share
information on risks where
appropriate.

a) MUST record the decision to A C I X Restructured/Changed

vary its fraud control
arrangements and advise the
DTA of remedial action taken to
reduce the risk to their business
operations. These decisions will
be requested by the DTA during
Annual Assessments.

New

b) MAY vary application, for a A C I X Restructured/Changed

limited period, consistent with
the Applicant’s risk tolerance

A C I X Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

a) Fraud control goals and A C I X Restructured/Changed

strategic objectives of the
Applicant, including how the
management of fraud risks
intersects with and supports
broader business objectives and
priorities.

b) Applicant’s strategies to A C I X Unchanged

implement fraud risk
management and maintain a
positive risk culture.

c) Applicant’s tolerance to fraud A C I X Unchanged

risks.
d) Fraud threats, risks and A C I X Unchanged
vulnerabilities that impact the
protection of the Applicant’s
people, information (including
ICT) and assets

e) Maturity of the Applicant’s A C I X Unchanged

capability to manage fraud risks.

f) Treatment strategies and A C I X Unchanged

controls put in place to manage
fraud threats, risks and
vulnerabilities.

g) Strategies to ensure the A C I X Unchanged

Applicant meets its training and
awareness needs

h) Procedures and mechanisms A C I X Unchanged

for fraud incident management,
fraud investigations and
reporting fraud incidents.

i) An outline of key roles and A C I X Unchanged

responsibilities for fraud control
within the Applicant’s
organisation.

New

# A80000OFFICIAL
 A80000OFFICIAL #

New

New

New

A C I X Restructured/Changed

New

a) Determine the adequacy of A C I X Unchanged

existing fraud control measures
and mitigation controls

b) Respond to and manage shifts A C I X Unchanged

in the Applicant’s risk, threat and
operating environment

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

A C I X Archived

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Archived

A C I Restructured/Changed

A C I Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

Restructured/Changed

Restructured/Changed

New

A C I X Restructured/Changed

New

A C I X Restructured/Changed

A C I Restructured/Changed

A C I Restructured/Changed

New

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

New

New

New

A C I X Restructured/Changed

A C I X Archived

A C I X Restructured/Changed

New

A C I X Restructured/Changed

A C I X Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

a) Where legislation sets out A C I X Archived

specific alternative
arrangements.

b) Where the Applicant: A C I X Archived

i. Has the capacity and the
appropriate skills and resources
needed to investigate potential
criminal matters.

ii. Meets the requirements of the A C I X Archived

AGIS for gathering evidence and
the Commonwealth Director of
Public Prosecutions (CDPP) in
preparing briefs of evidence.

A C I X Restructured/Changed

A C I X Archived

A C I X Archived

A C I X Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

a) Date and time of the fraud A C I X Restructured/Changed

incident

New

New

b) Quantity of fraud incidents A C I X Restructured/Changed

and their level of severity
c) Time taken to respond to the A C I X Archived
fraud incident
d) Measures taken in response to A C I X Restructured/Changed
the fraud incident

e) Type(s) of fraud A C I X Restructured/Changed

f) If applicable, the Identity A C I X Archived
Proofing Level and Credential
Level of the impacted identity
record(s)

g) Any other supporting A C I X Archived

information (e.g. attack vectors
used by the fraudster).

A C I Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

A C I Restructured/Changed

A C I Archived

A C I Restructured/Changed

A C I Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

New

New

A C I X Archived

A C I X Restructured/Changed

a) Handling of internal and A C I X Restructured/Changed

external privacy enquiries and
complaints.

b) Handles requests for access to A C I X Unchanged

and correction of Personal
information.

# A80000OFFICIAL
 A80000OFFICIAL #

c) Maintaining a record of A C I X Restructured/Changed

Personal information holdings.

d) Assisting with the preparation A C I X Unchanged

of Privacy Impact Assessments
(PIAs).

e) Maintaining a register of PIAs. A C I X Unchanged

f) Measuring and documenting A C I X Restructured/Changed

performance against the Privacy
Management Plan and reviewing
and, where relevant updating,
the Privacy Policy at least
annually relevant to the TDIF.

A C I X Restructured/Changed

A C I X Unchanged

A C I X Restructured/Changed

New

New

New

# A80000OFFICIAL
 A80000OFFICIAL #

I X Restructured/Changed

I X Restructured/Changed

I X Restructured/Changed

a) The kinds of Personal A C I X Restructured/Changed

information that the entity
collects and holds

b) How the entity collects and A C I X Restructured/Changed

holds Personal information.

c) The purposes for which the A C I X Unchanged

Applicant collects, holds, uses
and discloses Personal
information.

d) How an Individual can access A C I X Unchanged

Personal information about
themselves that is held by the
Applicant and how to seek the
correction of such information.

e) How an Individual can A C I X Unchanged

complain about a breach of the
APPs(or a particular jurisdiction
privacy principle) and how the
Applicant will deal with such a
complaint.

# A80000OFFICIAL
 A80000OFFICIAL #

f) Whether the Applicant is likely A C I X Unchanged

to disclose Personal information
to overseas recipients and if so
the countries in which such
recipients are likely to be located
(if it is practicable to do so).

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

New
A C I X Restructured/Changed

New

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

New

A C I X Restructured/Changed

New

A C I X Restructured/Changed

New

# A80000OFFICIAL
 A80000OFFICIAL #

New

a) List the roles or members of A C I X Restructured/Changed

the response team.
b) List the actions the response A C I X Restructured/Changed
team is expected to take

c) Describe how the actions and A C I X Restructured/Changed

roles in the plan align to the
Applicant’s Incident Response
Plan .

New

A C I X Unchanged

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Unchanged

A C I X Unchanged

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

# A80000OFFICIAL
A80000OFFICIAL #

New

X Restructured/Changed

New

New

New

New

# A80000OFFICIAL
 A80000OFFICIAL #

X Restructured/Changed

a) Verify the Identity of an A C I X Restructured/Changed

Individual and assist them to
receive a digital service from a
Relying Party.

b) To support identity fraud A C I X Restructured/Changed

management functions

c) To improve the performance A C I X Restructured/Changed

or usability of the Applicant’s
identity system.

d) To de-identify the data to A C I X Restructured/Changed

create aggregate data.

A C I X Unchanged

New

New

Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

I Archived

• The Individual chooses to I Restructured/Changed

retain the Biometric information
stored or controlled by the
Individual on their device, or

• The Biometric information is I Restructured/Changed

collected or was collected to
create a government Identity
document (for example where a
Road Traffic and Transport
Authority is an Identity
document issuer and an Identity
Service Provider), or

• The Biometric information is C I Restructured/Changed

reused for authentication use (in
accordance with CSP-04-03-03).

New

New

New

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV-03-08-02: See Requirement I Archived

Above

New

Restructured/Changed

A C I X Restructured/Changed

5 If the Attribute Service A Unchanged

Provider connects directly with a
Relying Party, it is required to
obtain Express Consent prior to
the disclosure. If the connection
to the Relying Party is brokered
by an Identity Exchange, Express
Consent may be obtained by the
Identity Exchange on behalf of
the Attribute Service Provider.

6 If the Identity Service Provider I Unchanged

connects directly with a Relying
Party, it is required to obtain
Express Consent prior to the
disclosure. If the connection to
the Relying Party is brokered by
an Identity Exchange, Express
Consent may be obtained by the
Identity Exchange on behalf of
the Identity Service Provider.

# A80000OFFICIAL
 A80000OFFICIAL #

7 If the connection to the Relying X Unchanged

Party is brokered by an Identity
Exchange, the Identity Exchange
may delegate the collection of
Express Consent to the Identity
Service Provider or Attribute
Service Provider.

A C I X

New

A C I X Restructured/Changed

A C I X Restructured/Changed

New

A C I X Restructured/Changed

A C I X Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

A I Restructured/Changed

A I Archived

A C I X Unchanged

A C I X Unchanged

A C I X Unchanged

X Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Unchanged

A C I X Unchanged

A C I X Unchanged

A C I X Unchanged

A C I X Unchanged

A C I X Unchanged

A C I Unchanged

A C I Restructured/Changed

X Archived

A C I X Unchanged

# A80000OFFICIAL
 A80000OFFICIAL #

A C I Unchanged

A C I Unchanged

a) is readily accessible, including A C I X Unchanged

prominent contact information
about the service.

b) is fair, including a process that A C I X Unchanged

is impartial, confidential and
transparent.

c) has a process that is timely, A C I X Unchanged

clear and can provide a remedy
where applicable.

d) has skilled and professional A C I X Unchanged

people who have knowledge of
privacy laws and these TDIF
privacy requirements and the
complaint service process.

e) is integrated with other A C I X Unchanged

complaint handling bodies, (e.g.
other Participants of an identity
federation) as required, so it can
assist the individual and refer
complaints.

A C I X Unchanged

A C I X Archived

# A80000OFFICIAL
 A80000OFFICIAL #

New

a) Determine the Applicant’s A C I X Restructured/Changed

tolerance for security risks.

b) Manage the Applicant’s A C I X Restructured/Changed

security risks.

c) Demonstrate how its A C I X Restructured/Changed

protective security controls are
applied to its identity system.

d) Consider the implications their A C I X Restructured/Changed

risk management decisions have
for other agencies and
organisations and share
information on risks where
appropriate.

New

a) MUST record the decision to A C I X Restructured/Changed

vary its security arrangements
and advise the DTA of remedial
action taken to reduce the risk to
their business operations. These
decisions will be requested by
the DTA during Annual
Assessments.

b) MAY vary application, for a A C I X Restructured/Changed

limited period of time, consistent
with the Applicant’s risk
tolerance.

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

New

a) Appointing security advisors A C I X Restructured/Changed

with the Applicant’s
organisation.

b) The Applicant’s protective A C I X Unchanged

security planning.
c) The Applicant’s protective A C I X Unchanged
security practices and
procedures.

d) Investigating, responding to A C I X Restructured/Changed

and reporting on security
incidents.

A C I X Restructured/Changed

Restructured/Changed

Restructured/Changed
A C I X Archived

# A80000OFFICIAL
 A80000OFFICIAL #

a) All elements of the Applicant’s A C I X Unchanged

System Security Plan are
achieved.

b) Cyber security incidents are A C I X Unchanged

investigated, responded to and
reported to the DTA.

c) Relevant security policy or A C I X Unchanged

legislative obligations are met.

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

New

A C I Restructured/Changed

A C I X Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

a) Security goals and strategic A C I X Restructured/Changed

objectives of the Applicant,
including how security risk
management intersects with and
supports broader business
objectives and priorities.

b) Applicant’s strategies to A C I X Restructured/Changed

implement security risk
management and maintain a
positive risk culture.

c) Applicant’s tolerance to A C I X Restructured/Changed

security risks.
New

d) Maturity of the Applicant’s A C I X Restructured/Changed

capability to manage security
risks.

e) A summary of the threats, A C I X Restructured/Changed

risks and vulnerabilities that
impact the confidentiality,
integrity and availability of the
Applicant’s identity service.

New

f) Treatment strategies and A C I X Restructured/Changed

controls put in place to manage
security risks and vulnerabilities.

g) Strategies to ensure the A C I X Restructured/Changed

Applicant meets its training and
awareness needs.

New

h) Procedures and mechanisms A C I X Restructured/Changed

for security incident
management, security
investigations and reporting
security incidents.

# A80000OFFICIAL
 A80000OFFICIAL #

i) An outline of key roles and A C I X Restructured/Changed

responsibilities for protective
security control within the
Applicant’s organisation.

New

New

New

A C I X Restructured/Changed

Restructured/Changed

a) Determine the adequacy of A C I X Restructured/Changed

existing protective security
control measures and mitigation
controls.

# A80000OFFICIAL
 A80000OFFICIAL #

b) Respond to and manage A C I X Restructured/Changed

significant shifts in the
Applicant’s risk, threat and
operating environment.

A C I X Unchanged

A C I X Archived

A C I X Archived

A C I X Archived

A C I X Archived

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed
a) Identify information holdings.

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed
b) Assess the sensitivity of
information holdings.
A C I X Restructured/Changed
c) Implement operational
controls for these information
holdings proportional to their
value, importance and
sensitivity.
A C I X Restructured/Changed

A C I X Restructured/Changed

a) Sharing information within the

Applicant’s organisation as well
as with other relevant
stakeholders as required.
A C I X Restructured/Changed
b) Ensuring that access to
Sensitive information or
resources is only provided to
people with a Need to know that
information
A C I X
c) Controlling access (including
remove access) to supporting ICT
systems, networks,
infrastructure, devices and
applications.
A C I X Unchanged

New

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

New
New
New
A C I X Restructured/Changed

A C I X Archived

A C I X Restructured/Changed

New

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Unchanged

A C I X Archived

a) Where legislation sets out

specific alternative
arrangements.
A C I X Archived

b) Where the Applicant: i. Has

the capacity and the appropriate
skills and resources needed to
investigate potential criminal
matters.
A C I X Archived
ii. Meets the requirements of the
AGIS for gathering evidence and
the CDPP in preparing briefs of
evidence.
A C I X Restructured/Changed

New

# A80000OFFICIAL
 A80000OFFICIAL #

New

A C I X Archived

A C I X Restructured/Changed

A C I X Archived

A C I X Restructured/Changed

a) Date and time of the Cyber

security incident.
A C I X Restructured/Changed
b) Quantity of Cyber security
incidents and their level of
severity
A C I X Archived
c) Time taken to respond to the
Cyber security incident.
A C I X Restructured/Changed
d) Measures taken in response to
the Cyber security incident.
A C I X Archived
e) If applicable, the Identity
Proofing Level and Credential
Level of the impacted identity
record(s).
A C I X Archived
f) Any other supporting
information (e.g. attack vectors
used).
A C I X Archived

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Archived

I Restructured/Changed

C Archived

A Archived

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed
• Successful and failed elevation
of privileges by Personnel.
A C I X Unchanged
• User and group additions,
deletions and modification to
permissions.
A C I X Unchanged

• Security related system alerts

and failures (e.g. attempted
access that is denied, crashes or
error messages).
A C I X Unchanged
• Unauthorised access attempts
to critical systems and files.

# A80000OFFICIAL
 A80000OFFICIAL #

New

New

A C I X Restructured/Changed

• The date and time

A C I X Unchanged

• The relevant User, identifier or

process. Each activity must have
a unique identifier.
• The description. A C I X Unchanged
A C I X Unchanged
• The ICT equipment involved.
A C I X Unchanged
• The source IP address of the
device that authenticated to the
identity system.
A C I X Unchanged
• The source port used to
perform the authentication
event.
A C I X Unchanged
• The destination IP address
used to perform the
authentication event.
A C I X Unchanged
• The destination port used to
perform the authentication
event.
A C I X Unchanged
• The User Agent String which
identifies the browser and
operating system of the
attempted authentication.
A C I X Restructured/Changed

• The International Mobile

Equipment Identity (IMEI) of a
mobile phone (if a mobile phone
is used to authenticate to the
identity system).
• Credential type used. C Restructured/Changed
• Credential Level achieved. C Unchanged

# A80000OFFICIAL
 A80000OFFICIAL #

I Restructured/Changed
• Identity Proofing Level
achieved.
I Archived
• The binding of any Attributes
to a Digital Identity.
X Restructured/Changed
• Interaction type. (e.g. OIDC
Authentication Request and
response)
X Restructured/Changed
• Unique interaction identifier.
(in accordance with IDX-06-01-
01).
• Entity. An Identity Service X Restructured/Changed
Provider or a Relying Party.
X Restructured/Changed
• Entity link. Any identity link
used in the interaction, such as
the RP Link or IdP Link.
• Names of any Attributes X Restructured/Changed
requested and returned.
X Restructured/Changed
• Any Identity Proofing Level or
Credential Level requested and
returned.
A Archived
• The binding of any Attributes
to a Digital Identity.
• The retrieval of any Attributes A Archived
by a Third Party.
A C I X Restructured/Changed

• Protected and stored to ensure

the accuracy and integrity of
data captured or held.
A C I X Unchanged
• Protected from unauthorised
access, modification and
deletion.
• Retained for a minimum of 7 A C I X Restructured/Changed
years
A C I X Archived
• Used to correlate activity
across Audit Logs, prioritise
assessments and focus
investigations.
New

A C I X Restructured/Changed
a) Business continuity
governance.

# A80000OFFICIAL
 A80000OFFICIAL #

b) Training requirements for A C I X Unchanged

recovery team members.
c) Recovery objectives and A C I X Unchanged
priorities.
d) Continuity strategies. A C I X Unchanged
e) Testing requirements and A C I X Unchanged
restoration procedures.
A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

a) Cryptographic key lifecycle

management over the lifecycle
of the key (generation, delivery,
renewal, revocation, etc).
A C I X

b) How records will be

maintained and audited.
A C I X
c) The conditions under which
compromised keys will be
declared.
d) Maintenance of cryptographic A C I X
components.
e) Evidence of cryptographic A C I X
evaluations undertaken.

A C I X Unchanged

A C I X Restructured/Changed

a) Verifying Identity using the

Document Verification Service.

# A80000OFFICIAL
 A80000OFFICIAL #

b) Confirming eligibility to work A C I X Restructured/Changed

in Australia.
A C I X Unchanged

A C I X Unchanged

a) Physical facilities.
b) ICT systems. A C I X Unchanged
A C I X Unchanged

A C I X Restructured/Changed

A C I X Unchanged

a) Harm to Individuals
A C I X Unchanged

b) Information and physical

assets and resources being made
inoperable or inaccessible, or
being accessed, used or removed
without appropriate
authorisation.
A C I X Unchanged

A C I X Unchanged

A C I X Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

A C I Unchanged

A C I Unchanged

A C I X Unchanged

A C I X Unchanged

A C I X Unchanged

I Restructured/Changed

A C I X Unchanged

A C I X Unchanged

I Unchanged

# A80000OFFICIAL
 A80000OFFICIAL #

I Unchanged

I Restructured/Changed

Restructured/Changed
Restructured/Changed

I Restructured/Changed

I Restructured/Changed

I Restructured/Changed

I Restructured/Changed

New

New

# A80000OFFICIAL
 A80000OFFICIAL #

I Restructured/Changed

New

I Unchanged

I Unchanged

I Unchanged

C Unchanged

C Archived

# A80000OFFICIAL
 A80000OFFICIAL #

New

New

A C I X Restructured/Changed

A C I X Unchanged

a) Describe the test objectives,

usability goals, and usability
metrics that will be captured.
A C I X Unchanged
b) Describe the number of test
participants, how they will be
recruited and the cohort to
which they belong
A C I X Unchanged
c) Document the approach and
the methodology used to
conduct the tests to indicate
what is working, pain points and
where improvements are
needed.
A C I X Unchanged
d) Document representative
scenarios for testing, on both
desktop and mobile devices.

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Unchanged
e) Describe how findings from
usability testing will be
implemented.
A C I X Unchanged
f) Identify a range of
representative Individuals of the
identity system.
A C I X Restructured/Changed
a) Individuals with disability.
b) Older Individuals A C I X Restructured/Changed
c) Individuals who use assistive A C I X
technologies.
A C I X
d) Individuals with low literacy.
A C I X
e) Individuals from culturally and
linguistically diverse backgrounds
A C I X
f) Individuals who are Aboriginal
or Torres Strait Islander.
g) Individuals from regional and A C I X
remote areas.
A C I X
h) Individuals with older
technology and low bandwidth
connections.
A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

A C I X Restructured/Changed

New

New

A C I X Restructured/Changed

A C I X Restructured/Changed

New

New

New

# A80000OFFICIAL
 A80000OFFICIAL #

Restructured/Changed

New

New

New

See requirement below A C I X Archived

Template Avaialable on the TDIF A C I X Archived

website

A C I X Archived

A C I X Restructured/Changed
• Its fraud control mechanism for
detecting incidents of fraud or
suspected fraud (as per FRAUD-
02-04-01).
A C I X Restructured/Changed
• Its fraud control mechanism to
flag incidents of fraud or
suspected fraud (as per FRAUD-
02-04-02).
A C I X Restructured/Changed

• Its security mechanism for

detecting Cyber security
incidents (as per PROT04-02-07).
A C I X Restructured/Changed
• Its security mechanism to flag
Cyber security incidents (as per
PROT-04-02- 08).
A C I X Restructured/Changed
• Its processes for audit trails
and activity logging in
applications (as per PROT04-02-
24)

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed
• The activities and events
logged (as per PROT-04-02-24a)
A C I X Restructured/Changed
• The content included in activity
logs (as per PROT-04-02-24b)
A C I Restructured/Changed

• Its fraud control mechanism

which prevents new registrations
or updates to existing records
from occurring if the fraud
control mechanism indicates the
registration or update is
fraudulent or suspected of being
fraudulent (as per FRAUD-02-04-
02b).
A C I Restructured/Changed

• Its security mechanism which

prevents new registrations or
updates to existing records from
occurring if the security
mechanism indicates the
registration or update will create
a Cyber security incident (as per
PROT-04-02-08b).
I Restructured/Changed

C Restructured/Changed

A C I X Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Archived
a) The test plan is approved and
released.
b) All requirements are included A C I X Archived
in the RTM.
A C I X Archived
c) All requirements are covered
by one or more test cases.
d) All test cases are appropriately A C I X Archived
documented.
e) All test resources are A C I X Archived
identified and available.
A C I X Archived

A C I X Archived

A C I X Archived
a) Demonstration testing has
been executed in accordance
with the approved Technical Test
Plan.
A C I X Archived
b) Status of all test cases,
including the execution coverage
and defects.
A C I X Archived
c) Test completion criteria has
been met, where the criteria
have not been met a risk-
assessment must be included for
approval to deviate and exit
testing.

New

New

New

New

# A80000OFFICIAL
 A80000OFFICIAL #

New

New

New

New

New

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

a) Be undertaken early enough

to influence the design of the
identity system.
b) Reflect consultation with A C I X Restructured/Changed
relevant stakeholders
c) Include a description of the A C I X Restructured/Changed
proposed identity system.
d) Map the identity system’s A C I X Restructured/Changed
personal information flows.
A C I X Restructured/Changed
e) Include an analysis of risks of
non-compliance with relevant
privacy laws and TDIF privacy
requirements.
A C I X Restructured/Changed
f) Include an analysis of the
impact of the project on the
privacy of Individuals.
A C I X Restructured/Changed
g) Include an analysis of whether
privacy impacts are necessary or
avoidable.
A C I X Restructured/Changed
h) Include an analysis of possible
mitigations to privacy risks.

# A80000OFFICIAL
 A80000OFFICIAL #

i) Include recommendations A C I X Restructured/Changed

A C I X Restructured/Changed

Restructured/Changed
Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Archived

Restructured/Changed
New
Restructured/Changed

Restructured/Changed
Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

Restructured/Changed
Restructured/Changed

New

New

New
New

A C I X Restructured/Changed

Archived
Restructured/Changed
Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

# A80000OFFICIAL
A80000OFFICIAL #

Restructured/Changed

Restructured/Changed
Restructured/Changed
Restructured/Changed

Restructured/Changed

Restructured/Changed

New

New

New

New

# A80000OFFICIAL
 A80000OFFICIAL #

New

New

New

New

New

New

A C I X Archived

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Archived

Restructured/Changed

Restructured/Changed
Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed
Restructured/Changed

Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

A C I X Restructured/Changed

Restructured/Changed
Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Archived

a) Documentation reviews. A C I X Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed
b) Interviews with key personnel.
c) A run through of the A C I X Restructured/Changed
Applicant’s identity system.
A C I X Restructured/Changed

Restructured/Changed

Restructured/Changed

A C I X Restructured/Changed

A C I X Archived

A C I X Restructured/Changed
a) A summary of the activities
performed during the Functional
Assessment.
A C I X Restructured/Changed
b) The date of and period
covered by the Functional
Assessment Report.
A C I X Restructured/Changed

c) Name, role (or position) and

contact details of the relevant
Accountable Authority and point
of contact within the Applicant’s
government agency or
organisation.

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed
d) Qualifications and basis of
independence for all Assessors
used.
A C I X Restructured/Changed
e) Names and versions of all
documents used by the
Applicant.
A C I X Restructured/Changed

f) City, state (and if applicable,

country) of all physical locations
used in the Applicant’s
operations. This includes data
centre locations (primary and
alternative sites) and all other
locations where general ICT and
business process controls that
are relevant to the Applicant’s
operations are performed.
g) The test or evaluation methodo A C I X Restructured/Changed
h) The test or evaluation results A C I X Restructured/Changed
i) Findings. A C I X Restructured/Changed
A C I X Restructured/Changed
j) Remediation actions or
recommendations to address any
areas of noncompliance.
A C I X Restructured/Changed

k) Express an opinion and

provide recommendations to the
DTA of the Applicant’s identity
system against the TDIF
requirements, including any
requirements that could not be
adequately assessed due to
access or timing issues.
A C I X Restructured/Changed

l) Include a list of compliant and

non-compliant controls. Where a
noncompliance has been
identified, the remedial actions
and timeframes within which the
actions will be completed to
address the non-compliance.

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Archived

A C I X

A C I X Archived

a) A description of the nature of

the Identity System (consistent
with the TDIF) provided to the
User by the Applicant
A C I X Restructured/Changed

b) A general acknowledgment by
the User that their use of the
Identity System provided by the
Applicant is governed by the
User terms.
A C I X Archived
c) The Applicant’s Identity
System is provided on an ‘as is’
and ‘as available’ basis.
A C I X Restructured/Changed
d) The scope of the User’s right
to access and use the Identity
System must be consistent with
the TDIF.
A C I X Restructured/Changed

e) The User is responsible for

their use of the Applicant’s
Identity System, including any
Identity Documents it provides
to the Applicant, and will use the
service in compliance with all
applicable laws.
A C I X Archived

f) The User is responsible to

provide accurate Identity
Documents and Attributes to the
Applicant.

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Archived
g) The Applicant does not share
Attributes, Personal Information
or sensitive information, or
Credentials with third parties
without the Consent of the
Individual.
A C I X Restructured/Changed

h) The User reports unauthorised

use of their Digital Identity or
Credential to the Applicant as
soon as they become aware of it.
A C I X Restructured/Changed
i) The Applicant may suspend,
cancel or terminate the User’s
access to the Identity System at
any time.
A C I X Restructured/Changed

j) That the Applicant may make

changes to the User terms at any
time without prior notice and if
the User terms are changed, the
User’s continued use of the
Identity System will be subject to
their acceptance of the updated
User terms.
A C I X Archived

a) The Applicant gives no express

or implied warranties or makes
any representation (and to the
full extent permitted by law
excludes all statutory warranties)
in relation to any part of its
Identity System, including as to
its or their availability,
performance, security or fitness
for a particular purpose and in
respect of the availability,
accuracy, completeness or
correctness of any information.

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Archived

b) To the extent permitted by

law, the Applicant will not be
liable to the User or any third
party for any loss or damage
arising from or in connection
with the availability, use or
performance of the Identity
System or any part of the
Identity System.
A C I X Restructured/Changed

a) The User’s access to the

Identity System may be
facilitated by third party services
or software and the provider
may require, enable or facilitate
access to third party services or
software.
A C I X Archived
b) The User is responsible for
complying with any terms of any
such third-party service provider,
including any other Accredited
Participant.
A C I X Archived

c) To the extent permitted by

law, the Applicant is not liable to
the User for any damage or loss
arising in connection with User’s
access to the service, either
directly or through a third-party
provider.
A C I X Archived

a) All title, rights and interest in

and to the intellectual property
of the Applicant, including any
modifications, corrections or
enhancements thereto, will
remain vested in the Applicant,
in accordance with the TDIF.
A C I X Archived
b) The User is liable for breaches
of intellectual property caused
by the User’s use of the service
other than in accordance with
the TDIF.

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Archived
c) The User must not use,
reproduce, amend or alter
intellectual property rights in the
service.
A C I X Restructured/Changed
d) The User must comply with
security requirements or
instructions provided to it by the
Applicant.
A C I X Archived

a) That the Applicant will not be

responsible for any fees charged
by any other Accredited
Participant or a third-party
provider used by the User to
access the service.
b) The governing law of the User A C I X Restructured/Changed
terms.
A C I X Restructured/Changed
c) Provisions setting out a
process for dispute resolution.
A C I X Archived
d) A whole of agreement
provision (i.e. that the terms
represent the entire agreement
between the User and
Applicant).
e) A severability provision. A C I X Archived
A C I X Unchanged

A C I X

A C I X

A C I X

# A80000OFFICIAL
 A80000OFFICIAL #

See TDIF 05 Table 1 & 4 Sheet I Restructured/Changed

below

See TDIF 05 Table 1 & 4 Sheet I Restructured/Changed

below

Restructured/Changed

Restructured/Changed
New

I Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

I Unchanged

I Restructured/Changed

New

Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

New

I Restructured/Changed

I Restructured/Changed

I Restructured/Changed

I Restructured/Changed

I Restructured/Changed

I Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

I New

New

New

New

New

New

New

I Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

New

I Restructured/Changed

New

I Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

I Restructured/Changed

I Unchanged

I Archived

Restructured/Changed

Restructured/Changed

New
New

New

New

# A80000OFFICIAL
A80000OFFICIAL #

New

New

New

New

New

New

New

New

New

# A80000OFFICIAL
 A80000OFFICIAL #

New

New

New

New

New

New

I Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

I Restructured/Changed
• capture and send the Acquired
image to the Photo ID
Authoritative Source (or proxy)
in the case of Source Biometric
Matching; or,
I Restructured/Changed

• capture and perform

Document Biometric Matching of
the Acquired Image against the
image read directly from the
Photo ID RFID chip.
I Restructured/Changed

I Restructured/Changed

Archived

New
New

New

New
New

Restructured/Changed

New

# A80000OFFICIAL
A80000OFFICIAL #

New

Restructured/Changed

Restructured/Changed

New

Restructured/Changed

New

New

New

# A80000OFFICIAL
 A80000OFFICIAL #

Restructured/Changed

New

New

New

New

New

New

I Restructured/Changed

I Restructured/Changed

I Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

I Archived

I Restructured/Changed

I Archived

I Archived

I Restructured/Changed

I Archived

I Archived

I Archived

# A80000OFFICIAL
 A80000OFFICIAL #

I Archived

Restructured/Changed

New
New

New

New
Restructured/Changed

New

New

I Archived

I Archived

# A80000OFFICIAL
 A80000OFFICIAL #

I Restructured/Changed

I Restructured/Changed

I Restructured/Changed

I Restructured/Changed

I Archived

I Archived

I Archived

I Archived

Archived
New

New

# A80000OFFICIAL
A80000OFFICIAL #

New

New

Restructured/Changed

New

Restructured/Changed

New

New

# A80000OFFICIAL
 A80000OFFICIAL #

New

I Archived

I Archived

I Archived

I Archived

I Restructured/Changed

I Archived

# A80000OFFICIAL
 A80000OFFICIAL #

I Archived

Archived
New

New

New

New

I Archived

# A80000OFFICIAL
 A80000OFFICIAL #

I Restructured/Changed

Restructured/Changed

Restructured/Changed
New

New

New

New

New

# A80000OFFICIAL
 A80000OFFICIAL #

Restructured/Changed

New

New

I Archived

I Restructured/Changed

I Archived

Archived

# A80000OFFICIAL
 A80000OFFICIAL #

I Restructured/Changed

I Archived

I Restructured/Changed

I Archived

I Restructured/Changed

I Archived

I Restructured/Changed

Restructured/Changed

I Archived

I Archived

I Archived

I Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

I Archived

I Archived

I Archived

C Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

C
C

C Restructured/Changed

C Restructured/Changed

Restructured/Changed

Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

C Archived

C Restructured/Changed

C Restructured/Changed

C Restructured/Changed

C Restructured/Changed

C Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

C Restructured/Changed

C Restructured/Changed

C Restructured/Changed

C Restructured/Changed

C
C

C Restructured/Changed

C Restructured/Changed

Restructured/Changed

C Archived

C Archived

C Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

C
C

C Restructured/Changed

C Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

C Restructured/Changed

• The device MUST accept

transfer of the secret from the
primary channel, which it MUST
send to the Applicant over the
secondary channel to associate
the approval with the
Authentication transaction.
C Restructured/Changed

• The device MUST present a

secret received via the secondary
channel from the Applicant and
prompt the Individual to verify
the consistency of that secret
with the primary channel, prior
to accepting a yes/no response
from the Individual. It MUST
then send that response to the
Applicant.
C Archived

The Individual MAY perform the

transfer manually or use a
technology such as a barcode or
QR code to effect the transfer.
C

# A80000OFFICIAL
 A80000OFFICIAL #

1.
Transfer of secret to primary
channel: o The Applicant MUST
signal the device containing the
Individual’s Credential to
indicate readiness to
authenticate
o It MUST then transmit a
random secret to the out-of-
band device
o The Applicant MUST then wait
for the secret to be returned on
the primary communication
channel.
C

2.
Transfer of secret to secondary
channel:
o The Applicant MUST display a
random Authentication secret to
the Individual via the primary
channel
o It MUST then wait for the
secret to be returned on the
secondary channel from the
Individual’s out-of-band device.
C

3.
Verification of secrets by the
Individual:
o The Applicant MUST display a
random Authentication secret to
the Individual via the primary
channel and MUST send the
same secret to the out-of-band
device via the secondary channel
for presentation to the
Individual.
o It MUST then wait for an
approval (or disapproval)
message via the secondary
channel.

# A80000OFFICIAL
 A80000OFFICIAL #

C Restructured/Changed

C Archived

# A80000OFFICIAL
 A80000OFFICIAL #

C
C

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

C
C

C
C

# A80000OFFICIAL
 A80000OFFICIAL #

C
C

# A80000OFFICIAL
 A80000OFFICIAL #

C
C

C
C
C

C
C

# A80000OFFICIAL
 A80000OFFICIAL #

C
C

# A80000OFFICIAL
 A80000OFFICIAL #

• Impose a delay of at least 30

seconds before the next attempt,
increasing exponentially with
each successive attempt (e.g. 1
minute before the following
failed attempt, 2 minutes before
the second following attempt),
or
C

• Disable the biometric User

Authentication and offer another
factor (e.g. a different biometric
modality or a PIN/Passcode if it is
not already a required factor) if
such an alternative method is
already available.

# A80000OFFICIAL
 A80000OFFICIAL #

• Use of the biometric as an

Authentication factor MUST be
limited to one or more specific
devices that are identified using
approved cryptography (i.e.
AACAs and AACPs)
C Restructured/Changed
• Since the biometric has not yet
unlocked the main
Authentication Key, a separate
Key MUST be used for identifying
the device
C

• Biometric revocation, referred

to as ‘biometric template
protection’ in ISO/IEC 24745,
MUST be implemented
C

• All transmission of biometrics

MUST be over the Authenticated
Protected Channel.
C Archived

C Archived

C
C

# A80000OFFICIAL
 A80000OFFICIAL #

C Archived

C
C

C Restructured/Changed

C Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

C
C

C
C

C Archived
C Archived

C Restructured/Changed
C Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

C Restructured/Changed

C Restructured/Changed

C Restructured/Changed

C Restructured/Changed

1. Offer Individuals at least one

alternate Credential that is not
restricted and can be used to
authenticate at the required CL
C Restructured/Changed

2. Provide meaningful notice to

Individuals regarding the security
risks of the Restricted Credential
and availability of alternative(s)
that are not restricted
C Restructured/Changed
3. Address any additional risk to
Individuals in its security Risk
Assessment
C Restructured/Changed
4. Develop a migration plan for
the possibility that the Restricted
Credential is no longer
acceptable at some point in the
future.
C
C

# A80000OFFICIAL
 A80000OFFICIAL #

C Archived

C Restructured/Changed

C Restructured/Changed

C Restructured/Changed

C Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

• The Individual MUST identify

themselves in each new binding
transaction by presenting a
temporary secret which was
either established during a prior
transaction or sent to the
Individual’s mobile phone
number or email address
C
• Long-term Authentication
secrets MUST only be issued to
the Individual within a protected
Session.
C

• The Individual MUST identify

themselves in-person by either
using a secret as described in
CSP-04-04-02, or through use of
a biometric that was recorded
during the identity proofing
process
• Temporary secrets MUST NOT C
be reused
C

• If the Applicant issues long-

term Authentication secrets
during a physical transaction,
then they MUST be loaded
locally onto a physical device
that is issued in-person to the
individual or delivered in a
manner that confirms the
individual’s email address or
mobile phone number.
C
C

# A80000OFFICIAL
 A80000OFFICIAL #

C Archived

C Archived

C Archived

C
C Restructured/Changed

New

C
C Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

C Archived

C Restructured/Changed

C
C

# A80000OFFICIAL
 A80000OFFICIAL #

C
C

C Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

C
C

C
C

C
C Restructured/Changed

C Restructured/Changed

C Restructured/Changed

Restructured/Changed

Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

C Restructured/Changed

C
C

a. Certification Practice
Statements (CPS) and Certificate
Policies (CP) conform to Request
for Comment (RFC) 3647
C
b. Digital Certificates conform to
the (RFC) 5280 format
C
c. Certificate Revocation Lists
(CRLs) conform to the X.509
version 2 profile as described in
RFC 5280
C
d. Online Certificate Status
Protocol (OCSP) responses
conform to RFC 6960.
C

# A80000OFFICIAL
 A80000OFFICIAL #

C
• The Individual notifies the
Applicant that a Digital
Certificate request was not
authorised by them.
C

• The Applicant obtains evidence

that a Digital Certificate’s Private
Key suffered a Key compromise
or no longer complies with the
requirements outlined in the
Certificate Policy
C

• The Applicant obtains evidence

that a Digital Certificate it has
issued has been misused.
C

• The Applicant is made aware

that an Individual has violated
one or more of their usage terms
(for example, those set out in
ROLE-02-01-01)
C

• The Applicant is made aware

that the Certificate was not
issued in accordance with its
Certification Practice Statements
or Certificate Policy.
C
• The Applicant determines that
any information set out in the
Digital Certificate is inaccurate or
misleading.
C
• The Applicant obtains evidence
of a suspected or actual
compromise of a subordinate
CA’s Private Key.

A Archived

# A80000OFFICIAL
 A80000OFFICIAL #

A Restructured/Changed

A Restructured/Changed

A Restructured/Changed

A Restructured/Changed

A Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

A Restructured/Changed

X
X
X

X
X Restructured/Changed

• Timestamp
X Restructured/Changed
• Duration of Consent. (including
any time limit on the consent)
X Restructured/Changed
• Relying Party. (i.e. The Relying
Party that requested to receive
the Attributes)
X Restructured/Changed
• The Identifier that identifies
the User at the Relying Party
authorised to receive the
Attributes
X Restructured/Changed
• Identity Service
Provider/Attribute Service
Provider from which the
Attributes were sourced
• The link to the Identity at the X Restructured/Changed
source of the Attributes
• Name of any Attribute or X Restructured/Changed
Attribute set authorised
X Restructured/Changed
• Consent decision. This may be
“grant”, “deny”, or “ongoing”
X
X

# A80000OFFICIAL
A80000OFFICIAL #

X
X

X Restructured/Changed

X
X

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X

A I X

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X

A C I X

A C I X

A C I X

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X

A C I X

A C I X

A C I X

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

A C I X

A C I X

A C I X

A C I X

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X

A C I X

I X

I X

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

I X

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

A I X

A I X

A C I X
X

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

A X

I X

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

I X

A I X

I X

# A80000OFFICIAL
 A80000OFFICIAL #

I X

A C I X
A I X

A I X

A I X

A I X

A I X

A I X

# A80000OFFICIAL
 A80000OFFICIAL #

A I X

A I X

A I X

A I X

A I X

A I X

A I X

# A80000OFFICIAL
 A80000OFFICIAL #

A I X

A I X

A I X

A I X

A I X

A I X

# A80000OFFICIAL
 A80000OFFICIAL #

A I X

A I X

A I X

A I X

A I X

A I X

I X

A X

A I X

# A80000OFFICIAL
 A80000OFFICIAL #

A I X

A I X

A I X

A I X

# A80000OFFICIAL
 A80000OFFICIAL #

I X

A X

A X

A X

A X

A X

A X

# A80000OFFICIAL
 A80000OFFICIAL #

A X

A X

A X

A X

A X

A X

A X

A X

A X

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

A X

# A80000OFFICIAL
 A80000OFFICIAL #

I X

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

A I X

A I X

I X

A I X

Restructured/Changed

Restructured/Changed

# A80000OFFICIAL
A80000OFFICIAL #

New

New

New

New

New

# A80000OFFICIAL
A80000OFFICIAL #

New

New

New

New

New

# A80000OFFICIAL
A80000OFFICIAL #

New

New
New

New

New

New

Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

New

A C I X Restructured/Changed

New

New

New

# A80000OFFICIAL
A80000OFFICIAL #

New

New

New

New
New

New

New

New

New

New

New
Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

New

New

New

New

New

A C I X Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

Restructured/Changed

New

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

New

New

# A80000OFFICIAL
 A80000OFFICIAL #

New

New

New

A C I X Restructured/Changed

Restructured/Changed

A C I X Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

A C I X Restructured/Changed

A C I X Archived

a) Documentation reviews. A C I X Restructured/Changed

b) Interviews with key personnel. A C I X Restructured/Changed

c) A run through of the A C I X Restructured/Changed

Accredited Provider’s Identity
System.

A C I X Restructured/Changed

a) A copy of all Annual A C I X Restructured/Changed

Assessment Reports (as per
ANNUAL-02-05-01) which
include all required information
(as per ANNUAL-02-05-04).

b) A response from the A C I X Restructured/Changed

Accredited Provider’s
Accountable Authority to all
adverse findings identified by the
Assessors in the Annual
Assessment Reports (as per
ANNUAL-02-05-03).

c) A copy of all decisions and A C I X Restructured/Changed

supporting documentation (as
per ANNUAL-02-05- 02).

# A80000OFFICIAL
 A80000OFFICIAL #

d) An annual Qualifying A C I X Restructured/Changed

Attestation Letter in accordance
with the requirements set out in
ANNUAL-02-06-01 and ANNUAL-
02-06-02.

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

A C I X Restructured/Changed

a) The Privacy Assessment (as A C I X Restructured/Changed

per ASSESS-07-01-04).

b) The security assessment (as A C I X Restructured/Changed

per ASSESS-07-02-01)

c) The penetration test (as per A C I X Restructured/Changed

ASSESS-07-02-02).

d) An annual usability test (as per A C I X Archived

UX-05-05-02)
e) An Accessibility Assessment A C I X Restructured/Changed
against the Web Content
Accessibility Guidelines (as per
ASSESS-07-03-01).

# A80000OFFICIAL
 A80000OFFICIAL #

a) Any decisions and supporting A C I X Restructured/Changed

documentation made by the
Accredited Provider’s
Accountable Authority to vary its
fraud control arrangements
during the year (as per FRAUD-
02-01-03).

b) Evidence the Accredited A C I X Restructured/Changed

Provider has reviewed its Fraud
Control Plan (and supporting
Fraud Control Plans) during the
year (as per FRAUD-02-02-02).

c) A copy of fraud awareness A C I X Restructured/Changed

training materials provided by
the Accredited Provider to
Personnel during the year (as per
FRAUD-02-03-01).

d) Evidence of the Accredited A C I X Restructured/Changed

Provider has reviewed its Privacy
Policy and where relevant
updated during the year (as per
PRIV-03-02-05).

e) Evidence of the Accredited A C I X Restructured/Changed

Provider has reviewed its Privacy
Management Plan and where
relevant updated during the year
(as per PRIV-03-02-07)

f) A copy of privacy awareness A C I X Restructured/Changed

training materials provided by
the Accredited Provider to
Personnel during the year (as per
PRIV-03-02-08)

g) For Identity Exchanges, a copy X Restructured/Changed

of their Annual Transparency
Report (as per PRIV-03-06-05).

# A80000OFFICIAL
 A80000OFFICIAL #

h) Any decisions and supporting A C I X Restructured/Changed

documentation made by the
Accredited Provider’s
Accountable Authority to vary its
protective security control
arrangements during the year (as
per PROT-04-01-03).

i) A copy of protective security A C I X Restructured/Changed

training materials provided by
the Accredited Provider to
Personnel during the year (as per
PROT-04-01-07)

j) Evidence of the Accredited A C I X Restructured/Changed

Provider has reviewed its System
Security Plan (and supporting
System Security Plans) and
where relevant updated during
the year (as per PROT-04-01-13).

k) Any decisions and supporting A C I X Restructured/Changed

documentation made during the
year by the Accredited Provider’s
Chief Security Officer (or their
delegate) to implement
alternative mitigation measures
or controls to those listed in the
TDIF protective security
requirements (as per PROT-04-
01-18).

l) Evidence the Accredited A C I X Restructured/Changed

Provider has tested its Disaster
Recovery and Business
Continuity Plan during the year
(as per PROT-04-02-27).

m) Outcomes of its annual A C I X Restructured/Changed

usability test conducted on its
Identity System (as per UX-05-
05-04a)

# A80000OFFICIAL
 A80000OFFICIAL #

n) For Identity Service Providers, I Restructured/Changed

processes and risk assessments
to support exception cases (as
per IDP-03-03-01b)

o) For Identity Service Providers, I Archived

the evaluation, results and
report for the presentation
attack detection technology used
(as per IDP-03-08-10b as set out
in Appendix B of the TDIF: 05 –
Role Requirements).

p) For Identity Service Providers, I Archived

a copy of Manual Face
Comparison training materials
provided to Personnel during the
year (as per IDP-03-08-23 as set
out in Appendix B of the TDIF: 05
– Role Requirements).

q) For Attribute Service A Restructured/Changed

Providers, evidence of its
arrangements with an
Authoritative Source (as per ASP-
05-02-01a)

r) Where an Accredited Provider A C I X Archived

has been granted an exemption
against a TDIF requirement,
justification the exemption is still
required. (The TDIF exemption
process is set out in B.2 of the
TDIF: 03 Accreditation Process).

Restructured/Changed

a) The date of and period A C I X Restructured/Changed

covered by the report.

# A80000OFFICIAL
 A80000OFFICIAL #

b) Name, role (or position) and A C I X Restructured/Changed

contact details of the relevant
Accountable Authority and point
of contact within the Accredited
Provider’s organisation.

c) Qualifications and basis of A C I X Restructured/Changed

independence for all Assessors
used.

d) Names and version numbers A C I X Restructured/Changed

of all documents used by the
Accredited Provider

e) City, state and (if applicable) A C I X Restructured/Changed

country of all physical locations
used in the Accredited Provider’s
operations. This includes data
centre locations (primary and
alternative sites) and all other
locations where general ICT and
business process controls that
are relevant to the Accredited
Provider’s operations are
performed.

f) The test or evaluation A C I X Restructured/Changed

methodology(s) used.

g) The test or evaluation results. A C I X Restructured/Changed

h) Findings. A C I X Restructured/Changed

i) Remediation actions or A C I X Restructured/Changed

recommendations to address any
areas of noncompliance.

j) Express an opinion and provide A C I X Restructured/Changed

recommendations to the DTA of
the Accredited Provider’s
Identity System against the TDIF
requirements, including any
requirements that could not be
adequately assessed due to
access or timing issues

# A80000OFFICIAL
 A80000OFFICIAL #

k) Include a list of compliant and A C I X Restructured/Changed

non-compliant controls.

l) Where a non-compliance has A C I X Restructured/Changed

been identified, the remedial
actions and timeframes within
which actions will be completed
to address the noncompliance.

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

A C I X Restructured/Changed

A C I X Restructured/Changed

A C I X Archived

Restructured/Changed

# A80000OFFICIAL
A80000OFFICIAL #

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

New

New

New

New

Restructured/Changed

# A80000OFFICIAL
A80000OFFICIAL #

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

New

New

# A80000OFFICIAL
A80000OFFICIAL #

New

New

New

New

New

New

# A80000OFFICIAL
A80000OFFICIAL #

New

New

New

New

New

New

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

# A80000OFFICIAL
A80000OFFICIAL #

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

# A80000OFFICIAL
A80000OFFICIAL #

Restructured/Changed

New

New

New

New

New

New

# A80000OFFICIAL
A80000OFFICIAL #

New

New

New

New

New

New

New

New

# A80000OFFICIAL
A80000OFFICIAL #

Restructured/Changed

New

New

New

New

New

# A80000OFFICIAL
A80000OFFICIAL #

New

New

New

New

New

New

New

# A80000OFFICIAL
A80000OFFICIAL #

New

New

New
New

New
Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

Restructured/Changed

# A80000OFFICIAL
 A80000OFFICIAL #

Notes TDIF Requirement Subsecti

Requirem on
ents

ACCRED ACCRED-03-01-01c 4.3.1

# A80000OFFICIAL
 A80000OFFICIAL #

Note applicability indicators adjusted to

account for rewording of req.

ACCRED ACCRED-03-01-02d 4.3.1

# A80000OFFICIAL
 A80000OFFICIAL #

Removed as intent of req is already

covered by wording in requirements
above.

New Section - 3.2.2 Exemption Requests

Assists structure of document

# A80000OFFICIAL
 A80000OFFICIAL #

New sub requirement

New sub requirement

New Section - 3.2.2 Alternative

assessment reports

Assists structure of document

# A80000OFFICIAL
 A80000OFFICIAL #

New supporting requirement for ACCRED ACCRED-03-01-07a 3.3.2

Alternative Assessment Report submission
and acceptance

New Section - 3.3.3.7 Varying 3.3.3

Accreditation during Initial Accreditation

New supporting requirement for current ACCRED ACCRED-03-03-01 3.3.3

accreditation processes

New supporting requirement for current ACCRED ACCRED-03-03-01a 3.3.3

accreditation processes

New supporting requirement for current ACCRED ACCRED-03-03-01b 3.3.3

accreditation processes

New Section - 3.4.1 Finalisation of 3.4.1

Accreditation Requirements
New supporting requirement for current ACCRED ACCRED-03-04-01 3.4.1
accreditation processes

# A80000OFFICIAL
 A80000OFFICIAL #

New supporting requirement for current

accreditation processes

New supporting requirement for current

accreditation processes

New supporting requirement for current

accreditation processes

New supporting requirement for current

accreditation processes

New supporting requirement for current

accreditation processes

New supporting requirement for current ACCRED ACCRED-03-04-02 3.4.1

accreditation processes

Terminology has changed and FRAUD FRAUD-02-01-01 4.2.1

requirement has been expanded upon.

FRAUD FRAUD-02-01-01 4.2.1

FRAUD FRAUD-02-01-02 4.2.1

# A80000OFFICIAL
 A80000OFFICIAL #

Changed to being applicable to Applicant, FRAUD FRAUD-02-01-03 4.2.1

not Accountable Authority and moved to
FRAUD 02-01-03

FRAUD FRAUD-02-01-03 4.2.1

FRAUD FRAUD-02-01-03 4.2.1

FRAUD FRAUD-02-01-03 4.2.1

FRAUD FRAUD-02-01-03 4.2.1

Moved to FRAUD-02-01-04 FRAUD FRAUD-02-01-04 4.2.1

FRAUD FRAUD-02-01-04 4.2.1

moved to FRAUD-02-01-04 © FRAUD FRAUD-02-01-04 4.2.1

4.2.2
Changed to align with changes to FRAUD FRAUD-02-02-01 4.2.2
Accountable Authority responsibilities and
terminology.

# A80000OFFICIAL
 A80000OFFICIAL #

Added extra sub-requirements, and FRAUD FRAUD-02-02-01a 4.2.2

updated terminology to align with new
terms.

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

# A80000OFFICIAL
 A80000OFFICIAL #

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

FRAUD FRAUD-02-02-01a 4.2.2

Restructured and changed with new FRAUD FRAUD-02-02-02 4.2.2

requirements for review.

FRAUD FRAUD-02-02-02 4.2.2

FRAUD FRAUD-02-02-02a 4.2.2

FRAUD FRAUD-02-02-02a 4.2.2

# A80000OFFICIAL
 A80000OFFICIAL #

4.2.3

Policy Moved to FRAUD-02-03-02

Moved to guidance

Wording and terminology changed, but

core policy is unchanged.

Combined with FRAUD-02-03-01 into

FRAUD-02-03-02

Moved to FRAUD-02-03-03

Moved to FRAUD-02-03-04

FRAUD FRAUD-02-03-01 4.2.3

FRAUD FRAUD-02-03-02 4.2.3

FRAUD FRAUD-02-03-02 4.2.3

# A80000OFFICIAL
 A80000OFFICIAL #

FRAUD FRAUD-02-03-03 4.2.3

FRAUD FRAUD-02-03-04 4.2.3

FRAUD FRAUD-02-03-04 4.2.3

4.2.4
language changed for clarity. ` FRAUD-02-04-01 4.2.4

FRAUD FRAUD-02-04-01a 4.2.4

language changed for clarity. FRAUD FRAUD-02-04-02 4.2.4

language changed for clarity. FRAUD FRAUD-02-04-02a 4.2.4

FRAUD FRAUD-02-04-02b 4.2.4

FRAUD FRAUD-02-04-02b 4.2.4

4.2.5

# A80000OFFICIAL
 A80000OFFICIAL #

Updated to allow for applicability scoping. FRAUD FRAUD-02-05-01 4.2.5

FRAUD FRAUD-02-05-01 4.2.5

FRAUD FRAUD-02-05-01a 4.2.5

FRAUD FRAUD-02-05-01a 4.2.5

FRAUD FRAUD-02-05-02 4.2.5

Moved to FRAUD-02-05-03 FRAUD FRAUD-02-05-03 4.2.5

FRAUD FRAUD-02-05-03 4.2.5

Moved to FRAUD-02-05-01

Moved to FRAUD-02-05-04 FRAUD FRAUD-02-05-04 4.2.5

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to FRAUD-02-05-05 and references FRAUD FRAUD-02-05-05 4.2.5

to AGIS removed.

Changed to be less onerous for accredited FRAUD FRAUD-02-05-06 4.2.5

applicants and moved to FRAUD-02-05-06

# A80000OFFICIAL
 A80000OFFICIAL #

FRAUD FRAUD-02-05-06 4.2.5

Changed to be less onerous and moved to FRAUD FRAUD-02-05-06a 4.2.5

FRAUD-02-05-06a

FRAUD FRAUD-02-05-06a 4.2.5

FRAUD FRAUD-02-05-06a 4.2.5

Moved to FRAUD-02-05-06a (a)

Moved to FRAUD-02-05-06a (c)

Moved to FRAUD-02-05-06a (b)

4.2.6

Changed to be about supporting FRAUD FRAUD-02-06-01 4.2.6

individuals, rather than solely users.

# A80000OFFICIAL
 A80000OFFICIAL #

language changed for clarity. FRAUD FRAUD-02-06-02 4.2.6

Moved to FRAUD-02-04-02b

language changed for clarity. FRAUD FRAUD-02-06-03 4.2.6

4.3.1
language updated for clarity PRIV PRIV-03-01-01 4.3.1

Restructured in line with the TDI Bill. PRIV PRIV-03-01-02 4.3.1

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-01-02 4.3.1

PRIV PRIV-03-01-02 4.3.1

Moved into PRIV-03-01-02

language updated for clarity and PRIV PRIV-03-02-01 4.3.2

introduced requirement for qualification
and experience

sub-requirements have been updated PRIV PRIV-03-02-01a 4.3.2

slightly

PRIV PRIV-03-02-01a 4.3.2

# A80000OFFICIAL
 A80000OFFICIAL #

added extra detail to provide clarity. PRIV PRIV-03-02-01a 4.3.2

PRIV PRIV-03-02-01a 4.3.2

PRIV PRIV-03-02-01a 4.3.2

PRIV PRIV-03-02-01a 4.3.2

Added requirements for privacy champion PRIV PRIV-03-02-02 4.3.2

to have relevant qualifications and
experience

PRIV PRIV-03-02-02a 4.3.2

Expanded remit of Privacy Champion PRIV PRIV-03-02-02b 4.3.2

PRIV PRIV-03-02-02b 4.3.2

PRIV PRIV-03-02-02b 4.3.2

PRIV PRIV-03-02-02b 4.3.2

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-02-03 4.3.2.2

language changed for clarity PRIV PRIV-03-02-03a 4.3.2.2

updated structure of requirment for PRIV PRIV-03-02-03b 4.3.2.2

clarity, expanded applicability.

language changed for clarity PRIV PRIV-03-02-04 4.3.2.2

PRIV PRIV-03-02-04 4.3.2.2

PRIV PRIV-03-02-04 4.3.2.2

PRIV PRIV-03-02-04 4.3.2.2

PRIV PRIV-03-02-04 4.3.2.2

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-02-04 4.3.2.2

PRIV PRIV-03-02-05 4.3.2.2

Responsibility assigned to privacy officer, PRIV PRIV-03-02-06 4.3.2.3

not accountable authority.

Rsponsibility assigned to Privacy PRIV PRIV-03-02-07 4.3.2.3

Champion

PRIV PRIV-03-02-08 4.3.2.3

PRIV PRIV-03-02-08 4.3.2.3

Expanded obligations to be about relevant PRIV PRIV-03-02-09 4.3.2.3
privacy laws

4.3.3
PRIV PRIV-03-03-01 4.3.3

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to PRIV-03-03-01a and expanded PRIV PRIV-03-03-01a 4.3.3

for clarity.

Moved to PRIV-03-03-01B and expanded PRIV PRIV-03-03-01b 4.3.3

for clarity.

PRIV PRIV-03-04-01 4.3.4

PRIV PRIV-03-04-01 4.3.4

Modified to better support non APP PRIV PRIV-03-04-01a 4.3.4

entities.

PRIV PRIV-03-04-01a 4.3.4

PRIV PRIV-03-04-02 4.3.4

PRIV PRIV-03-04-02 4.3.4

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-04-02 4.3.4

Moved to PRIV-03-04-02

Moved to PRIV-03-04-02

Moved to PRIV-03-04-02 and updated.

PRIV PRIV-03-04-03 4.3.4

PRIV PRIV-03-05-01 4.3.5

Reduced scope of required notice PRIV PRIV-03-05-02 4.3.5

language changed for clarity PRIV PRIV-03-06-01 4.3.6

PRIV PRIV-03-06-02 4.3.6

PRIV PRIV-03-06-03 4.3.6

# A80000OFFICIAL
 A80000OFFICIAL #

language changed for clarity, and PRIV PRIV-03-06-04 4.3.6

exemption added.

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-06-04a 4.3.6

language changed for clarity PRIV PRIV-03-06-05 4.3.6

Inserted for clarity PRIV PRIV-03-06-05a 4.3.6

PRIV PRIV-03-06-05a 4.3.6

PRIV PRIV-03-06-05a 4.3.6

PRIV PRIV-03-06-05a 4.3.6

# A80000OFFICIAL
 A80000OFFICIAL #

updated to ensure Exchange can retain PRIV PRIV-03-06-06 4.3.6

info essential for its function.

these have been changed and shuffled PRIV PRIV-03-07-01 4.3.7

around, and brought in line with the
legislation.

these have been changed and shuffled PRIV PRIV-03-07-01 4.3.7

around, and brought in line with the
legislation.

these have been changed and shuffled PRIV PRIV-03-07-01 4.3.7

around, and brought in line with the
legislation.

these have been changed and shuffled PRIV PRIV-03-07-01 4.3.7

around, and brought in line with the
legislation.

PRIV PRIV-03-07-01a 4.3.7

4.3.8

PRIV PRIV-03-08-01 4.3.8

PRIV PRIV-03-08-01a 4.3.8

Intended to be equivalent to exemption in PRIV PRIV-03-08-01a 4.3.8

old PRIV-03-08-02

# A80000OFFICIAL
 A80000OFFICIAL #

sub requirement has been moved to PRIV- PRIV PRIV-03-08-02 4.3.8

03-08-04

Moved to PRIV-03-08-02a PRIV PRIV-03-08-02 4.3.8

Moved to PRIV-03-08-02 (b)

PRIV PRIV-03-08-02a 4.3.8

PRIV PRIV-03-08-02b 4.3.8

PRIV PRIV-03-08-02c 4.3.8

# A80000OFFICIAL
 A80000OFFICIAL #

Requirements referenced have changed

now part of PRIV-03-08-01a

PRIV PRIV-03-08-03 4.3.8

PRIV PRIV-03-08-04 4.3.8

4.3.9
language updated for clarity PRIV PRIV-03-09-01 4.3.9

PRIV PRIV-03-09-01 4.3.9

PRIV PRIV-03-09-01 4.3.9

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-09-01 4.3.9

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

PRIV PRIV-03-09-02 4.3.9

Moved to PRIV-03-09-02a, expanded to PRIV PRIV-03-09-02a 4.3.9

allow variation
Moved to PRIV-03-09-02b, expanded to PRIV PRIV-03-09-02b 4.3.9
allow variation

PRIV PRIV-03-09-02c 4.3.9

PRIV PRIV-03-09-02d 4.3.9

PRIV PRIV-03-09-02d 4.3.9

PRIV PRIV-03-09-02d 4.3.9

Moved to PRIV-03-09-02d

PRIV PRIV-03-09-03 4.3.9

PRIV PRIV-03-09-03 4.3.9

PRIV PRIV-03-09-03 4.3.9

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-09-03 4.3.9

Moved to PROT-04-02-23a

language updated for clarity PRIV PRIV-03-09-04 4.3.9

Covered by PRIV-03-09-01

4.3.10

PRIV PRIV-03-10-01 4.3.10

PRIV PRIV-03-10-02 4.3.10

PRIV PRIV-03-10-02a 4.3.10

4.3.10
Expanded applicability to other roles and PRIV PRIV-03-11-01 4.3.11
non-government systems.

4.3.12

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-12-01 4.3.12

PRIV PRIV-03-12-02 4.3.12

PRIV PRIV-03-12-03 4.3.12

PRIV PRIV-03-12-04 4.3.12

PRIV PRIV-03-12-05 4.3.12

PRIV PRIV-03-12-06 4.3.12

PRIV PRIV-03-12-07 4.3.12

language updated for clarity PRIV PRIV-03-12-07a 4.3.12

Addressed by IDX consumer dashboard

requirements.

PRIV PRIV-03-13-01 4.3.13

# A80000OFFICIAL
 A80000OFFICIAL #

PRIV PRIV-03-13-02 4.3.13

PRIV PRIV-03-13-03 4.3.13

PRIV PRIV-03-14-01 4.3.14

PRIV PRIV-03-14-01 4.3.14

PRIV PRIV-03-14-01 4.3.14

PRIV PRIV-03-14-01 4.3.14

PRIV PRIV-03-14-01 4.3.14

PRIV PRIV-03-15-01 4.3.15

4.4.1
Archived to enable support for non-
Commonwealth entities.

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-01-01 4.4.1

Obligation placed on applicant now, not PROT PROT-04-01-02 4.4.1

the Accountable authority to better
support non-commonwealth entities.

language changed for clarity PROT PROT-04-01-02 4.4.1

language changed for clarity PROT PROT-04-01-02 4.4.1

language changed for clarity PROT PROT-04-01-02 4.4.1

PROT PROT-04-01-03 4.4.1

language changed for clarity PROT PROT-04-01-03 4.4.1

language changed for clarity PROT PROT-04-01-03 4.4.1

# A80000OFFICIAL
 A80000OFFICIAL #

language changed for clarity, expanded PROT PROT-04-01-04 4.4.1

assessable responsibilities.

language changed for clarity, expanded PROT PROT-04-01-04 4.4.1

assessable responsibilities.

Emphasis changed to being on an PROT PROT-04-01-04a 4.4.1

obligation on the Applicant

PROT PROT-04-01-04a 4.4.1

PROT PROT-04-01-04a 4.4.1

language changed for clarity. PROT PROT-04-01-04a 4.4.1

simplied requirement and placed PROT PROT-04-01-05 4.4.1

obligation on applicant

PROT PROT-04-01-05a 4.4.1

PROT PROT-04-01-05a 4.4.1

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-01-06 4.4.1

PROT PROT-04-01-06 4.4.1

PROT PROT-04-01-06 4.4.1

Moved to new PROT-04-01-05a.

Moved to PROT-04-01-07 PROT PROT-04-01-07 4.4.1

Moved to PROT-04-01-08 PROT PROT-04-01-08 4.4.1

Moved to PROT-04-01-09, split and PROT PROT-04-01-09 4.4.1

changed from email address.

PROT PROT-04-01-09 4.4.1

moved to PROT-04-01-10 PROT PROT-04-01-10 4.4.1

lanugage updated in line with release, PROT PROT-04-01-11 4.4.1

moved to PROT-04-01-11

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to PROT-04-01-11a PROT PROT-04-01-11a 4.4.1

Moved to PROT-04-01-11a PROT PROT-04-01-11a 4.4.1

Moved to PROT-04-01-11a PROT PROT-04-01-11a 4.4.1

PROT PROT-04-01-11a 4.4.1

Moved to PROT-04-01-11a PROT PROT-04-01-11a 4.4.1

Moved to PROT-04-01-11a PROT PROT-04-01-11a 4.4.1

PROT PROT-04-01-11a 4.4.1

Moved to PROT-04-01-11a PROT PROT-04-01-11a 4.4.1

Moved to PROT-04-01-11a PROT PROT-04-01-11a 4.4.1

PROT PROT-04-01-11a 4.4.1

Moved to PROT-04-01-11a PROT PROT-04-01-11a 4.4.1

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to PROT-04-01-11a PROT PROT-04-01-11a 4.4.1

PROT PROT-04-01-11a 4.4.1

PROT PROT-04-01-11a 4.4.1

PROT PROT-04-01-11a 4.4.1

Moved to PROT-04-01-12, and additional PROT PROT-04-01-12 4.4.1

requirements added around when a
review is necessary.

PROT PROT-04-01-12 4.4.1

Now PROT-04-01-13 PROT PROT-04-01-13 4.4.1

# A80000OFFICIAL
 A80000OFFICIAL #

Now PROT-04-01-13 PROT PROT-04-01-13 4.4.1

PROT PROT-04-01-14 4.4.1

Already dealt with as part of System

Security Plan

Covered by PROT-04-01-03

language modified and moved to PROT- PROT PROT-04-01-15 4.4.1

04-01-15

language modified and moved to PROT- PROT PROT-04-01-15a 4.4.1

04-01-15a

language changed for clarity PROT PROT-04-02-01 4.4.2

# A80000OFFICIAL
 A80000OFFICIAL #

language changed for clarity PROT PROT-04-02-01 4.4.2

language changed for clarity PROT PROT-04-02-01 4.4.2

removed reference to PSPF to support PROT PROT-04-02-02 4.4.2

commercial entities

language changed for clarity (a) removed. PROT PROT-04-02-03 4.4.2

language changed for clarity PROT PROT-04-02-03 4.4.2

PROT PROT-04-02-04 4.4.2

PROT PROT-04-02-04a 4.4.2

# A80000OFFICIAL
 A80000OFFICIAL #

Called out four in particular, and have split PROT PROT-04-02-05 4.4.2
into sub requirements

PROT PROT-04-02-05 4.4.2

PROT PROT-04-02-05 4.4.2
PROT PROT-04-02-05 4.4.2
moved to PROT-04-02-06 PROT PROT-04-02-06 4.4.2

Removed due to difficulty of assessing.

Split into two requirements PROT PROT-04-02-07 4.4.2

Broader requirement for notification of PROT PROT-04-02-07a 4.4.2

cyber security incidents

language update for clarity PROT PROT-04-02-08 4.4.2

language update for clarity PROT PROT-04-02-08a 4.4.2

language update for clarity, added sub PROT PROT-04-02-08b 4.4.2

requirements to ensure appropriate
behaviour is followed

language update for clarity, added sub

requirements to ensure appropriate
behaviour is followed

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-02-09 4.4.2

Changed to refer to enforcement bodies PROT PROT-04-02-10 4.4.2

PROT PROT-04-02-11 4.4.2

Archived in line with bill.

Archived in line with bill.

Archived in line with bill.

Moved to PROT-04-02-12 PROT PROT-04-02-12 4.4.2

PROT PROT-04-02-13 4.4.2

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-02-13 4.4.2

Archived in line with bill.

Reduced onerousness of requirement to PROT PROT-04-02-14 4.4.2

quarterly reports for applicants, moved to
PROT-04-02-14

PROT PROT-04-02-14a 4.4.2

PROT PROT-04-02-14a 4.4.2

PROT PROT-04-02-14a 4.4.2

# A80000OFFICIAL
 A80000OFFICIAL #

Changed to individuals and req number PROT PROT-04-02-15 4.4.2

Changed to individuals and req number PROT PROT-04-02-16 4.4.2

req number changed PROT PROT-04-02-17 4.4.2

Covered by an existing requirement

Applicability extended, requirements PROT PROT-04-02-18 4.4.2

modified, req no. changed

Combined with previous requirement,

Combined with previous requirement.

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to PROT-04-02-19 PROT PROT-04-02-19 4.4.2.6

Moved to PROT-04-02-20 PROT PROT-04-02-20 4.4.2.6

Moved to PROT-04-02-21, changed PROT PROT-04-02-21 4.4.2.6

language for clarity and consistency with
rest of TDIF.

Moved to PROT-04-02-22 PROT PROT-04-02-22 4.4.2.6

Moved to PROT-04-02-22a, added extra PROT PROT-04-02-22a 4.4.2.6

events.

PROT PROT-04-02-22a 4.4.2.6

PROT PROT-04-02-22a 4.4.2.6

PROT PROT-04-02-22a 4.4.2.6

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-02-22a 4.4.2.6

PROT PROT-04-02-22a 4.4.2.6

moved to PROT-04-02-22b, and language PROT PROT-04-02-22b 4.4.2.6

updated.

PROT PROT-04-02-22b 4.4.2.6

PROT PROT-04-02-22b 4.4.2.6

PROT PROT-04-02-22b 4.4.2.6

PROT PROT-04-02-22b 4.4.2.6

PROT PROT-04-02-22b 4.4.2.6

PROT PROT-04-02-22b 4.4.2.6

PROT PROT-04-02-22b 4.4.2.6

PROT PROT-04-02-22b 4.4.2.6

Modified to be a general requirement to PROT PROT-04-02-22b 4.4.2.6

identify the device being used, rather than
specifically the IMEI. The IMEI will not
always be available,but a requirement for
a uniquely addressable device is
nonetheless important.

Moved to PROT-04-02-22c PROT PROT-04-02-22c 4.4.2.6

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to PROT-04-02-22d PROT PROT-04-02-22d 4.4.2.6

Moved to PROT-04-02-22e PROT PROT-04-02-22e 4.4.2.6

PROT PROT-04-02-22e 4.4.2.6

PROT PROT-04-02-22e 4.4.2.6

PROT PROT-04-02-22e 4.4.2.6

PROT PROT-04-02-22e 4.4.2.6

PROT PROT-04-02-22e 4.4.2.6

Moved to PROT-04-02-22a

Moved to PROT-04-02-23, length of time PROT PROT-04-02-23 4.4.2.6

audit logs are required to be retained for
reduced to 3 years.

PROT PROT-04-02-23 4.4.2.6

PROT PROT-04-02-23 4.4.2.6

Moved from Privacy requirements. PROT PROT-04-02-23a 4.4.2.6

Moved to PROT-04-02-24 PROT PROT-04-02-24 4.4.2.6

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-02-24 4.4.2.6

PROT PROT-04-02-24 4.4.2.6

PROT PROT-04-02-24 4.4.2.6

PROT PROT-04-02-24 4.4.2.7

PROT PROT-04-02-25 4.4.2.7

Moved to PROT-04-02-26 and language PROT PROT-04-02-26 4.4.2.8

modified

Moved to PROT-04-02-27 and language PROT PROT-04-02-27 4.4.2.8

modified.

PROT PROT-04-02-27 4.4.2.8

PROT PROT-04-02-27 4.4.2.8

PROT PROT-04-02-27 4.4.2.8

PROT PROT-04-02-27 4.4.2.8

4.4.3
PROT PROT-04-03-01 4.4.3.1

Language updated in line with Feb PROT PROT-04-03-02 4.4.3.1

release, removed reference to DVS.

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-03-02 4.4.3.1

PROT PROT-04-03-03 4.4.3.2

PROT PROT-04-03-04 4.4.3.3

PROT PROT-04-03-04 4.4.3.3

PROT PROT-04-03-05 4.4.3.3

Addition of requirement to mitigate PROT PROT-04-03-05a 4.4.3.3

identified risks with separation
procedures.

PROT PROT-04-04-01 4.4.4

PROT PROT-04-04-01 4.4.4

PROT PROT-04-04-02 4.4.4

PROT PROT-04-04-03 4.4.4

Added new details for clarity PROT PROT-04-04-04 4.4.4

4.5.1

# A80000OFFICIAL
 A80000OFFICIAL #

UX UX-05-01-01 4.5.1

UX UX-05-01-02 4.5.1

UX UX-05-01-03 4.5.1

UX UX-05-01-04 4.5.1

UX UX-05-01-05 4.5.1

Language updated for clarity. UX UX-05-01-05a 4.5.1

UX UX-05-01-06 4.5.1

UX UX-05-01-07 4.5.1

4.5.2

UX UX-05-02-01 4.5.2

# A80000OFFICIAL
 A80000OFFICIAL #

UX UX-05-02-02 4.5.2

Some of the language has been moved to UX UX-05-02-03 4.5.2

a footnote and modified to avoid
confusion.

UX UX-05-02-03 4.5.2
UX UX-05-02-03 4.5.2

Language updated for clarity. UX UX-05-02-04 4.5.2

Language updated for clarity. UX UX-05-02-05 4.5.2

Language updated for clarity. UX UX-05-02-05a 4.5.2

Language updated for clarity, and further UX UX-05-02-05b 4.5.2

detail added.

UX UX-05-02-05b 4.5.2

UX UX-05-02-05b 4.5.2

# A80000OFFICIAL
 A80000OFFICIAL #

UX UX-05-02-05c 4.5.2

UX UX-05-02-05c 4.5.2

UX UX-05-02-06 4.5.2

UX UX-05-02-07 4.5.2

UX UX-05-02-08 4.5.2

UX UX-05-03-01 4.5.3

Already dealt with as part of the lifecycle

piece.

4.5.4

# A80000OFFICIAL
 A80000OFFICIAL #

Inserted limited exemption for usability UX UX-05-04-01 4.5.4.1

testing.

UX UX-05-04-01 4.5.4.1

Moved to UX-05-04-02 UX UX-05-04-02 4.5.4.2

UX UX-05-04-02a 4.5.4.2

UX UX-05-04-02a 4.5.4.2

UX UX-05-04-02a 4.5.4.2

UX UX-05-04-02a 4.5.4.2

# A80000OFFICIAL
 A80000OFFICIAL #

UX UX-05-04-02a 4.5.4.2

UX UX-05-04-02a 4.5.4.2

Moved to UX-05-04-02b UX UX-05-04-02b 4.5.4.2

UX UX-05-04-02b 4.5.4.2
UX UX-05-04-02b 4.5.4.2

UX UX-05-04-02b 4.5.4.2

UX UX-05-04-02b 4.5.4.2

UX UX-05-04-02b 4.5.4.2

UX UX-05-04-02b 4.5.4.2

UX UX-05-04-02b 4.5.4.2

Updated language to better represent UX UX-05-04-02c 4.5.4.2

policy objective.

4.5.4.3
Moved to UX-05-04-03 UX UX-05-04-03 4.5.4.3

Moved to UX-05-04-04 and language UX UX-05-04-04 4.5.4.3

updated for clarity.

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to UX-05-04-05 and language UX UX-05-04-05 4.5.4.3

updated

Moved to UX-05-04-06 and updated UX UX-05-04-06 4.5.4.3

obligation to be on applicant to make UX
researcher prepare report.

UX UX-05-04-06a 4.5.4.3

UX UX-05-04-06a 4.5.4.3

Moved to UX-05-04-06b UX UX-05-04-06b 4.5.4.3

4.5.5
Moved to UX-05-05-01 UX UX-05-05-01 4.5.5

TEST TEST-06-01-01 4.6.1

TEST TEST-06-01-01 4.6.1

TEST TEST-06-01-01 4.6.1

# A80000OFFICIAL
 A80000OFFICIAL #

TEST -06-01-06 TEST TEST-06-01-02 4.6.1

TEST TEST-06-01-03 4.6.1

TEST TEST-06-01-03 4.6.1

TEST TEST-06-01-03 4.6.1

Test plan no longer required - alignment

to industry best practice

Test plan no longer required - alignment

to industry best practice

Test plan no longer required - alignment

to industry best practice

TEST-06-01-04 4.6.1

TEST-06-01-04 4.6.1

TEST-06-01-04 4.6.1

TEST-06-01-04 4.6.1

TEST-06-01-04 4.6.1

# A80000OFFICIAL
 A80000OFFICIAL #

TEST-06-01-04 4.6.1

TEST-06-01-04 4.6.1

TEST-06-01-05 4.6.1

TEST-06-01-05 4.6.1

TEST-06-01-06 4.6.1

TEST-06-01-07 4.6.1

Moved to TEST-06-01-02

# A80000OFFICIAL
 A80000OFFICIAL #

Test plan no longer required - alignment

to industry best practice

Test plan no longer required - alignment

to industry best practice
Test plan no longer required - alignment
to industry best practice

Test plan no longer required - alignment

to industry best practice
Test plan no longer required - alignment
to industry best practice
Test plan no longer required - alignment
to industry best practice

Related to New requirements - TEST-06-

01-01 and 02

Related to New requirements - TEST-06-

01-01 and 02

Related to New requirements - TEST-06-

01-01 and 02

Related to New requirements - TEST-06-

01-01 and 02

4.7.1
Restructure of section and requirements ASSESS ASSESS-07-01-01 4.7.1

Restructure of section and requirements ASSESS ASSESS-07-01-01 4.7.1

Restructure of section and requirements ASSESS ASSESS-07-01-01 4.7.1

Restructure of section and requirements ASSESS ASSESS-07-01-01 4.7.1

# A80000OFFICIAL
 A80000OFFICIAL #

Restructure of section and requirements ASSESS ASSESS-07-01-01 4.7.1

Restructure of section and requirements ASSESS ASSESS-07-01-02 4.7.1

Restructure of section and requirements ASSESS ASSESS-07-01-02 4.7.1

Restructure of section and requirements ASSESS ASSESS-07-01-02 4.7.1

Restructure of section and requirements ASSESS ASSESS-07-01-02 4.7.1

Moved to ASSESS-07-05-01

Moved to PRIV-03-03-01

Moved to ASSESS-07-05-02

Moved to ASSESS-07-05-02

Moved to ASSESS-07-05-02

Moved to ASSESS-07-05-02

Moved to ASSESS-07-05-02

Moved to ASSESS-07-05-02

Moved to ASSESS-07-05-02

Moved to ASSESS-07-05-02

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to ASSESS-07-05-02
Incorporated into ASSESS-07-05-03

4.7.2

Moved from ASSESS-07-02-02 and 03 ASSESS ASSESS-07-02-01 4.7.2

Moved from ASSESS-07-02-02 and 03 ASSESS ASSESS-07-02-02 4.7.2

Moved from ASSESS-07-02-02 and 03 ASSESS ASSESS-07-02-03 4.7.2

Moved to ASSESS-07-06-01

Moved to ASSESS-07-06-02

Covered by wording of security and pen

test reqs

4.7.3
Moved from ASSESS-07-06-01 ASSESS-07-03-01

Moved from ASSESS-07-06-04 ASSESS-07-03-02

Moved from ASSESS-07-06-04 ASSESS-07-03-02

# A80000OFFICIAL
 A80000OFFICIAL #

Moved from ASSESS-07-06-04 ASSESS-07-03-02

Moved from ASSESS-07-06-05 ASSESS-07-03-03

incorporated ASSESS-07-07-01 ASSESS-07-03-04

incorporated ASSESS-07-07-01

incorporated ASSESS-07-07-01
incorporated ASSESS-07-07-01

Moved to ASSESS-07-07-01

4.7.4
Moved from ASSESS-07-07-02 ASSESS ASSESS-07-04-01 4.7.4

Moved from ASSESS-07-07-02 ASSESS ASSESS-07-04-01 4.7.4

Moved from ASSESS-07-07-02 ASSESS ASSESS-07-04-01 4.7.4

Moved from ASSESS-07-07-02 ASSESS ASSESS-07-04-01 4.7.4

Moved from ASSESS-07-07-02 ASSESS ASSESS-07-04-01 4.7.4

# A80000OFFICIAL
 A80000OFFICIAL #

Moved from ASSESS-07-07-02 ASSESS ASSESS-07-04-01 4.7.4

Moved from ASSESS-07-07-02 ASSESS ASSESS-07-04-01 4.7.4

Moved from ASSESS-07-07-02 ASSESS ASSESS-07-04-01 4.7.4
Moved from ASSESS-07-07-02 ASSESS ASSESS-07-04-01 4.7.4

Moved from ASSESS-07-07-02 ASSESS ASSESS-07-04-01 4.7.4

Moved from ASSESS-07-07-02 ASSESS ASSESS-07-04-01 4.7.4

ASSESS ASSESS-07-04-02 4.7.4

ASSESS ASSESS-07-04-02 4.7.4

ASSESS ASSESS-07-04-02 4.7.4

ASSESS ASSESS-07-04-02 4.7.4

# A80000OFFICIAL
 A80000OFFICIAL #

ASSESS ASSESS-07-04-03 4.7.4

ASSESS ASSESS-07-04-03 4.7.4

ASSESS ASSESS-07-04-03a 4.7.4

ASSESS ASSESS-07-04-03b 4.7.4

ASSESS ASSESS-07-04-03b 4.7.4

ASSESS ASSESS-07-04-03b 4.7.4

incorporated into ASSESS-07-01-01 and 02

# A80000OFFICIAL
 A80000OFFICIAL #

incorporated into ASSESS-07-01-01 and 02

4.7.5
Moved from ASSESS-07-01-01 ASSESS ASSESS-07-05-01 4.7.5

Moved from ASSESS-07-01-03 ASSESS ASSESS-07-05-02 4.7.5

Moved from ASSESS-07-01-03 ASSESS ASSESS-07-05-02 4.7.5

Moved from ASSESS-07-01-03 ASSESS ASSESS-07-05-02 4.7.5

Moved from ASSESS-07-01-03 ASSESS ASSESS-07-05-02 4.7.5

Moved from ASSESS-07-01-03 ASSESS ASSESS-07-05-02 4.7.5

Moved from ASSESS-07-01-03 ASSESS ASSESS-07-05-02 4.7.5

Moved from ASSESS-07-01-03 ASSESS ASSESS-07-05-02 4.7.5

Moved from ASSESS-07-01-03 ASSESS ASSESS-07-05-02 4.7.5

Moved from ASSESS-07-01-03 ASSESS ASSESS-07-05-02 4.7.5

incorporates ASSESS-07-01-04 ASSESS ASSESS-07-05-03 4.7.5

incorporates ASSESS-07-01-05 ASSESS ASSESS-07-05-03 4.7.5

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to ASSESS-07-02-01 and 02

Moved to ASSESS-07-02-01 and 02

4.7.6

incorporates ASSESS-07-02-01 and 02 ASSESS ASSESS-07-06-01 4.7.6

incorporates ASSESS-07-02-01 and 02 ASSESS ASSESS-07-06-01 4.7.6

incorporates ASSESS-07-02-01 and 02 ASSESS ASSESS-07-06-02 4.7.6

incorporates ASSESS-07-02-01 and 02 ASSESS ASSESS-07-06-02 4.7.6

Moved to ASSESS-07-03-01

Moved to ASSESS-07-01-01 and 02

Incorporated into ASSESS-07-04-02

Moved to ASSESS-07-03-02

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to ASSESS-07-03-02

Moved to ASSESS-07-03-02

Moved to ASSESS-07-03-03

4.7.4
Moved from ASSESS-07-03-01 ASSESS ASSESS-07-07-01 4.7.7

Moved from ASSESS-07-03-01 ASSESS ASSESS-07-07-01 4.7.7

incorporated into ASSESS-07-03-04

Requirement incorporated into ASSESS-

07-04-02 and 03

Moved to ASSESS-07-04-01

Moved to ASSESS-07-04-01

Moved to ASSESS-07-04-01

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to ASSESS-07-04-01

Moved to ASSESS-07-04-01

Moved to ASSESS-07-04-01

Moved to ASSESS-07-04-01
Moved to ASSESS-07-04-01
Moved to ASSESS-07-04-01
Moved to ASSESS-07-04-01

Moved to ASSESS-07-04-01

Moved to ASSESS-07-04-01

# A80000OFFICIAL
 A80000OFFICIAL #

NA - incorporated intent into other reqs.

ROLE ROLE-02-01-01 5.2.1

ROLE ROLE-02-01-01 5.2.1

Moved to ROLE-02-01-01
ROLE ROLE-02-01-01 5.2.1

ROLE ROLE-02-01-01 5.2.1

Moved to ROLE-02-01-01
ROLE ROLE-02-01-01 5.2.1

Moved to ROLE-02-01-01
ROLE ROLE-02-01-01 5.2.1

# A80000OFFICIAL
 A80000OFFICIAL #

ROLE ROLE-02-01-01 5.2.1

ROLE ROLE-02-01-01 5.2.1

Moved to ROLE-02-01-01
ROLE ROLE-02-01-01 5.2.1

Moved to ROLE-02-01-01
ROLE ROLE-02-01-01 5.2.1

Moved to ROLE-02-01-01

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to ROLE-02-01-01

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to ROLE-02-01-01

Moved to ROLE-02-01-01

Moved to ROLE-02-01-01

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

# A80000OFFICIAL
 A80000OFFICIAL #

PROT PROT-04-04-04 4.4.4

PROT PROT-04-04-04 4.4.4

IDP IDP-03-02-02a 5.3.2

# A80000OFFICIAL
 A80000OFFICIAL #

new sub point

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-04-01 5.3.4

Requirement Numbers Adjusted to IDP IDP-03-04-01a 5.3.4

account for new scoping req at IDP-03-04-
01

Requirement Numbers Adjusted to IDP IDP-03-04-01b 5.3.4

account for new scoping req at IDP-03-04-
02

Requirement Numbers Adjusted to IDP IDP-03-04-01c 5.3.4

account for new scoping req at IDP-03-04-
03

Requirement Numbers Adjusted to IDP IDP-03-04-02 5.3.4

account for new scoping req at IDP-03-04-
04

Requirement Numbers Adjusted to IDP IDP-03-04-02a 5.3.4

account for new scoping req at IDP-03-04-
05

Requirement Numbers Adjusted to IDP IDP-03-04-02b 5.3.4

account for new scoping req at IDP-03-04-
06

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-04-02c 5.3.4

5.3.4.1
IDP IDP-03-04-03 5.3.4.1

IDP IDP-03-04-03 5.3.4.1

IDP IDP-03-04-03a 5.3.4.1

IDP IDP-03-04-03a 5.3.4.1

IDP IDP-03-04-03b 5.3.4.1

New Scoping Requirement IDP IDP-03-05-01 5.3.5

Requirement numbers adjusted to IDP IDP-03-05-01a 5.3.5

account for new scoping req at IDP-03-05-
01

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-05-01b 5.3.5

Requirement numbers adjusted to IDP IDP-03-05-02 5.3.5

account for new scoping req at IDP-03-05-
01

IDP IDP-03-05-02a 5.3.5

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

# A80000OFFICIAL
 A80000OFFICIAL #

Clarified wording

Removed as a duplicate of requirement

intentions above

NOTE - This whole section has been 5.3.8

restructured and rewritten. The DTA ran
consultation for the TDIF biometric
requirements in September - November
2021 and consultation feedback has been
incorporated into the new requirements.
Where possible, we have tracked any
remaining old requirements to the new
ones in this Notes column

Moved to section 3.8.2

5.3.8.1
IDP-03-08-01 5.3.8.1

IDP
IDP-03-08-02 5.3.8.1
IDP
IDP IDP-03-08-02 5.3.8.1

# A80000OFFICIAL
 A80000OFFICIAL #

IDP-03-08-03 5.3.8.1

IDP
IDP-03-08-03 5.3.8.1
IDP
IDP-03-08-03 5.3.8.1
IDP
Adapted from IDP-03-08-31 IDP-03-08-03 5.3.8.1

IDP
IDP-03-08-03 5.3.8.1
IDP
IDP-03-08-03a 5.3.8.1

IDP
IDP-03-08-04 5.3.8.1

IDP
IDP-03-08-05 5.3.8.1

IDP
IDP-03-08-06 5.3.8.1

IDP

# A80000OFFICIAL
 A80000OFFICIAL #

IDP-03-08-07 5.3.8.1

IDP
IDP-03-08-07 5.3.8.1

IDP
IDP-03-08-07 5.3.8.1
IDP
IDP-03-08-07 5.3.8.1

IDP
IDP-03-08-07 5.3.8.1

IDP
IDP-03-08-07 5.3.8.1

IDP
Moved to IDP-03-08-14a

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to IDP-03-08-09

Moved to IDP-03-08-09

Moved to IDP-03-08-11

Moved to IDP-03-08-11a

Incorporated into Section 3.8.2 Online

Biometric Binding
5.3.8.2
IDP IDP-03-08-08 5.3.8.2

IDP IDP-03-08-09 5.3.8.2

IDP IDP-03-08-09 5.3.8.2

IDP IDP-03-08-10 5.3.8.2

IDP IDP-03-08-10a 5.3.8.2

IDP IDP-03-08-10b 5.3.8.2

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-08-10c 5.3.8.2

Adapted from IDP-03-08-05 IDP IDP-03-08-11 5.3.8.2

Adapted from IDP-03-08-07 IDP IDP-03-08-11a 5.3.8.2

IDP IDP-03-08-11b 5.3.8.2

Adapted from IDP-03-08-06 IDP IDP-03-08-11c 5.3.8.2

IDP IDP-03-08-12 5.3.8.2

IDP IDP-03-08-12a 5.3.8.2

IDP IDP-03-08-12b 5.3.8.3

# A80000OFFICIAL
 A80000OFFICIAL #

Adapted from IDP-03-08-09b IDP IDP-03-08-12c 5.3.8.4

IDP IDP-03-08-12d 5.3.8.5

IDP IDP-03-08-12e 5.3.8.6

IDP IDP-03-08-12f 5.3.8.7

IDP IDP-03-08-12g 5.3.8.8

IDP IDP-03-08-12h 5.3.8.9

IDP IDP-03-08-12i 5.3.8.10

Moved to IDP-03-08-11

Moved to IDP-03-08-11c

Moved to IDP-03-08-11a

# A80000OFFICIAL
 A80000OFFICIAL #

Now covered by Requirements IDP-03-08-

12 to IDP-03-08-12i

Moved to IDP-03-08-12b

Now covered by Requirements IDP-03-08-

12 to IDP-03-08-12i

NA - Archived as covered by PROT

requirements around system security

Moved to IDP-03-08-12c

NA - Archived as covered by logging

requirements and policy changes to
Assessing Officer requirements

Now covered by Requirements IDP-03-08-

12 to IDP-03-08-12i

Now covered by Requirements IDP-03-08-

12 to IDP-03-08-12i

# A80000OFFICIAL
 A80000OFFICIAL #

Annual testing is no longer a requirement.

However, ANNUAL-02-10-11b and
ANNUAL-02-10-11c indicate when testing
must be undertaken.

Moved to Section 3.8.4 Technical

Biometric Matching
5.3.8.3
IDP IDP-03-08-13 5.3.8.3

IDP IDP-03-08-14 5.3.8.3

IDP IDP-03-08-14 5.3.8.3

Adapted from IDP-03-08-01 IDP IDP-03-08-14a 5.3.8.3

IDP IDP-03-08-14b 5.3.8.3

IDP IDP-03-08-14c 5.3.8.3

Moved and adjusted to IDP-03-08-16

Moved and adjusted to IDP-03-08-16a

# A80000OFFICIAL
 A80000OFFICIAL #

Requirement is the same. Now IDP-03-08-

17

Requirement moved to IDP-03-08-18a

Moved to IDP-03-08-18

Covered by requirements IDP-03-08-18a -

IDP-03-08-18c
Covered by requirements IDP-03-08-18a -
IDP-03-08-18c

Covered by requirements IDP-03-08-18a -

IDP-03-08-18c

Covered by requirements IDP-03-08-18a -

IDP-03-08-18c

NA - Archived as covered by PROT

requirements around system security

Previously: Requirements for Document 5.3.8.4

Biometric Matching
IDP IDP-03-08-15 5.3.8.4

# A80000OFFICIAL
 A80000OFFICIAL #

Adapted from reqs IDP-03-08-17 to 18a IDP IDP-03-08-16 5.3.8.4

Adapted from reqs IDP-03-08-17 to 18a IDP IDP-03-08-16a 5.3.8.4

Moved from IDP-03-08-13 IDP IDP-03-08-17 5.3.8.4

IDP IDP-03-08-18 5.3.8.4

Moved from IDP-03-08-14 IDP IDP-03-08-18a 5.3.8.4

IDP IDP-03-08-18b 5.3.8.4

IDP IDP-03-08-18c 5.3.8.4

# A80000OFFICIAL
 A80000OFFICIAL #

IDP IDP-03-08-18d 5.3.8.4

Covered by reqs IDP-03-08-16 and IDP-03-

08-16a

Covered by reqs IDP-03-08-16 and IDP-03-

08-16a

Policy covered by Section 3.8.2 and 3.8.4

requirements

See IDP-03-08-04 and 04a

See IDP-03-08-04 and 04a

No longer applicable with the way the

TDIF Biometric Binding reqs work

# A80000OFFICIAL
 A80000OFFICIAL #

No longer applicable with the way the

TDIF Biometric Binding reqs work

Previously: Requirements for Document 5.3.8.5

Biometric Matching
IDP IDP-03-08-19 5.3.8.5

IDP IDP-03-08-20 5.3.8.5

IDP IDP-03-08-21 5.3.8.5

Covered by reqs IDP-03-08-10 and IDP-03-

08-10c

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to IDP-03-08-10c

Moved to Section 3.8.3

5.3.8.6
IDP IDP-03-08-22 5.3.8.6

IDP IDP-03-08-23 5.3.8.6

IDP IDP-03-08-24 5.3.8.6

IDP IDP-03-08-24a 5.3.8.6

IDP IDP-03-08-24b 5.3.8.6

# A80000OFFICIAL
 A80000OFFICIAL #

changed from IDP-03-08-25 IDP IDP-03-08-25 5.3.8.6

IDP IDP-03-08-26 5.3.8.6

IDP IDP-03-08-27 5.3.8.6

Covered by IDP-03-08-04

New requirements for Manual Face

Comparison training in Section 3.8.6

Section archived and incorporated into

restructure above

# A80000OFFICIAL
 A80000OFFICIAL #

Incorporated into PROT requirements for

logging

This requirement is a duplicate of PRIV

requirement
Moved and incorporated into IDP-03-08-
25

Incorporated into PRIV requirements for

Biometric Retention

Incorporated into PRIV requirements for

Biometric Retention

Incorporated into PRIV requirements for

Biometric Retention
Incorporated into PRIV requirements for
Biometric Retention

Section archived and incorporated into

restructure above
Covered by scoping requirement for
Manual Face Comparison reqs

No longer allowable under TDIF. This is to

strengthen the risk profile of Manual Face
Comparison

Covered by PRIV requirements for

Biometric Retention

Incorporated into IDP-03-08-03

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to PROT logging requirements

No longer allowable under TDIF. This is to

strengthen the risk profile of Manual Face
Comparison

NA by restrictions now imposed on how

Manual Face Comparison must take place
(i.e. Local Biometric Binding)

# A80000OFFICIAL
 A80000OFFICIAL #

Wording swapped with d CSP CSP-04-02-01c 5.4.2.1

Wording swapped with c CSP CSP-04-02-01d 5.4.2.1

CSP CSP-04-02-01d 5.4.2.1

CSP CSP-04-02-01d 5.4.2.1

# A80000OFFICIAL
 A80000OFFICIAL #

Requirement combined into d

Requirement Numbers adjusted for above CSP CSP-04-02-01e 5.4.2.1

restructure

Requirement Numbers adjusted for above CSP CSP-04-02-01f 5.4.2.1

restructure

Requirement Numbers adjusted for above CSP CSP-04-02-01g 5.4.2.1

restructure

Requirement Numbers adjusted for above CSP CSP-04-02-01h 5.4.2.1

restructure

Requirement Numbers adjusted for above CSP CSP-04-02-01i 5.4.2.1

restructure

# A80000OFFICIAL
 A80000OFFICIAL #

Requirement Numbers adjusted for above CSP CSP-04-02-01j 5.4.2.1

restructure

Requirement Numbers adjusted for above CSP CSP-04-02-01k 5.4.2.1

restructure

Requirement Numbers adjusted for above CSP CSP-04-02-01l 5.4.2.1

restructure

Requirement Numbers adjusted for above CSP CSP-04-02-01m 5.4.2.1

restructure

Requirement rewritten to combine 02e

and 02f

Requirement rewritten to combine 02e

and 02f

Combined into 02d

Combined into 02d

CSP CSP-04-02-02e 5.4.2.2

# A80000OFFICIAL
 A80000OFFICIAL #

CSP CSP-04-02-02f 5.4.2.2

CSP CSP-04-02-02g 5.4.2.2

# A80000OFFICIAL
 A80000OFFICIAL #

Removed subpoint from requirement

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Combined into above requirement

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Minor wording change

Archived due to conflict with PRIV

requirements

Archived due to conflict with PRIV

requirements

# A80000OFFICIAL
 A80000OFFICIAL #

Duplication of reqs above

Wording adjusted

Wording adjusted

# A80000OFFICIAL
 A80000OFFICIAL #

Requirement duplicates what is already in

Table 4

5.4.3.8
Restructured req numbers due to deleted CSP CSP-04-03-08 5.4.3.8
section above

# A80000OFFICIAL
 A80000OFFICIAL #

Restructured req numbers due to deleted CSP CSP-04-03-08a 5.4.3.8

section above
Restructured req numbers due to deleted CSP CSP-04-03-08b 5.4.3.8
section above

Restructured req numbers due to deleted 5.4.3.9

section above
Restructured req numbers due to deleted CSP CSP-04-03-09 5.4.3.9
section above

Restructured req numbers due to deleted CSP CSP-04-03-10 5.4.3.9

section above

Restructured req numbers due to deleted CSP CSP-04-03-10 5.4.3.9

section above

Restructured req numbers due to deleted CSP CSP-04-03-10 5.4.3.9

section above

Restructured req numbers due to deleted CSP CSP-04-03-10 5.4.3.9

section above

# A80000OFFICIAL
 A80000OFFICIAL #

Req numbers changed due to above req CSP CSP-04-04-01c 5.4.4.1

being archived

Req numbers changed due to above req CSP CSP-04-04-01d 5.4.4.1

being archived

Req numbers changed due to above req CSP CSP-04-04-01e 5.4.4.1

being archived

Req numbers changed due to above req CSP CSP-04-04-01f 5.4.4.1

being archived

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Duplicate requirement

Duplicate requirement

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

CSP CSP-04-04-06a 5.4.4.4

# A80000OFFICIAL
 A80000OFFICIAL #

Removed in line with industry best

practice

Changed req number due to above req CSP CSP-04-05-05 5.4.5

archived.

# A80000OFFICIAL
 A80000OFFICIAL #

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

# A80000OFFICIAL
 A80000OFFICIAL #

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

New wording CSP CSP-04-10-01b 5.4.10

CSP CSP-04-10-01b 5.4.10

CSP CSP-04-10-01b 5.4.10

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Changed numbering due to above ASP ASP-05-01-02 5.5.1

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Changed from MAY to MUST

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

# A80000OFFICIAL
 A80000OFFICIAL #

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

# A80000OFFICIAL
 A80000OFFICIAL #

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

# A80000OFFICIAL
 A80000OFFICIAL #

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

# A80000OFFICIAL
 A80000OFFICIAL #

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

Removing Archived Requirements from

this release - See June 2021 Release
Change Log for tracking of previously
archived requirements

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Section Requirement Subsection

ANNUAL 7.2.1

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-01-01 7.2.1

ANNUAL ANNUAL-02-01-01a 7.2.1

ANNUAL ANNUAL-02-01-02 7.2.1

ANNUAL ANNUAL-02-01-02 7.2.1

ANNUAL ANNUAL-02-01-02a 7.2.1

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-01-02b 7.2.1

ANNUAL 7.2.1

ANNUAL 7.2.1

7.2.1.1

ANNUAL ANNUAL-02-01-03 7.2.1.1

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-01-03 7.2.1.1

7.2.1.2
ANNUAL ANNUAL-02-01-04 7.2.1.2

ANNUAL ANNUAL-02-01-05 7.2.1.2

ANNUAL ANNUAL-02-01-06 7.2.1.2

ANNUAL ANNUAL-02-01-07 7.2.1.2

ANNUAL ANNUAL-02-01-07a 7.2.1.3

7.2.2

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-02-01 7.2.2

Moved to Annual-02-02-02 ANNUAL ANNUAL-02-02-02 7.2.2

ANNUAL ANNUAL-02-02-03 7.2.2

ANNUAL ANNUAL-02-02-03 7.2.2

ANNUAL ANNUAL-02-02-03 7.2.2

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-02-03 7.2.2

ANNUAL ANNUAL-02-02-03 7.2.2

ANNUAL ANNUAL-02-02-03 7.2.2

7.2.2.1
ANNUAL ANNUAL-02-02-04 7.2.2.1

ANNUAL ANNUAL-02-02-04 7.2.2.1

ANNUAL ANNUAL-02-02-04 7.2.2.1

ANNUAL ANNUAL-02-02-04 7.2.2.1

ANNUAL ANNUAL-02-02-04 7.2.2.1

ANNUAL ANNUAL-02-02-04 7.2.2.1

7.2.3

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-03-01 7.2.3

ANNUAL ANNUAL-02-03-01a 7.2.3

ANNUAL ANNUAL-02-03-01 7.2.3

ANNUAL ANNUAL-02-03-01 7.2.3

ANNUAL ANNUAL-02-03-01b 7.2.3

Moved to ANNUAL-02-05-01

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to ANNUAL-02-05-01a

Moved to Section 2.6

7.2.4

Moved Section from ANNUAL-02-05-01 ANNUAL ANNUAL-02-04-01 7.2.4

Moved Section from ANNUAL-02-05-01 ANNUAL ANNUAL-02-04-01 7.2.4

Moved Section from ANNUAL-02-05-01 ANNUAL ANNUAL-02-04-01 7.2.4

Moved Section from ANNUAL-02-05-01 ANNUAL ANNUAL-02-04-01 7.2.4

ANNUAL ANNUAL-02-04-02 7.2.4

ANNUAL ANNUAL-02-04-02a 7.2.4

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-04-02b 7.2.4

ANNUAL ANNUAL-02-04-02b 7.2.4

ANNUAL ANNUAL-02-04-02b 7.2.4

Moved to ANNUAL-02-06-01

Now under Section 2.5 - 2.7

Now under Section 2.5 - 2.7

# A80000OFFICIAL
 A80000OFFICIAL #

Now under Section 2.5 - 2.8

See Section 2.8 requirements.

Now under Sections 2.5 - 2.8

Now under Sections 2.5 - 2.8

Now under Sections 2.5 - 2.8

Now under Sections 2.5 - 2.8

Moved and incorporated into ANNUAL-

02-02-03

Moved and incorporated into ANNUAL-

02-02-03

Moved and incorporated into ANNUAL-

02-02-03

# A80000OFFICIAL
 A80000OFFICIAL #

Moved and incorporated into ANNUAL-

02-02-03

This Section is now covered under Section

2.8 requirements

7.2.5

Moved from ANNUAL-02-03-01 ANNUAL ANNUAL-02-05-01 7.2.5

Moved from ANNUAL-02-03-01a ANNUAL ANNUAL-02-05-01a 7.2.5

Moved from ANNUAL-02-03-01a ANNUAL ANNUAL-02-05-01a 7.2.5

Moved to ANNUAL-02-04-01

Moved to ANNUAL-02-04-01

Moved to ANNUAL-02-04-01

Moved to ANNUAL-02-04-01

Moved to ANNUAL-02-04-02 and 02a

Moved to ANNUAL-02-04-01

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to Section 2.9 TDIF 04 Functional

Requirements Review

Moved to Section 2.9 TDIF 04 Functional

Requirements Review

Moved to Section 2.9 TDIF 04 Functional

Requirements Review

Moved to Section 2.9 TDIF 04 Functional

Requirements Review

Moved to Section 2.9 TDIF 04 Functional

Requirements Review

Moved to Section 2.9 TDIF 04 Functional

Requirements Review

Moved to Section 2.9 TDIF 04 Functional

Requirements Review

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to Section 2.9 TDIF 04 Functional

Requirements Review

Moved to Section 2.9 TDIF 04 Functional

Requirements Review

Moved to Section 2.9 TDIF 04 Functional

Requirements Review

Moved to Section 2.9 TDIF 04 Functional

Requirements Review

Moved to Section 2.9 TDIF 04 Functional

Requirements Review

Moved to Section 2.9 TDIF 04 Functional

Requirements Review

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to ANNUAL-02-10-02 and now

scoped

See section 2.10.1 requirements

See section 2.10.1 requirements

Moved to ANNUAL-02-10-06

See Section 2.11

Incorporated into ANNUAL-02-08-02 and

ANNUAL-02-08-02a

Moved to ANNUAL-02-08-01

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to ANNUAL-02-08-01

Moved to ANNUAL-02-08-01

Moved to ANNUAL-02-08-01

Moved to ANNUAL-02-08-01

Moved to ANNUAL-02-08-01

Moved to ANNUAL-02-08-01

Moved to ANNUAL-02-08-01

Moved to ANNUAL-02-08-01

Moved to ANNUAL-02-08-01

# A80000OFFICIAL
 A80000OFFICIAL #

Moved to ANNUAL-02-08-01

Moved to ANNUAL-02-08-01

Moved to Section 2.2.1

7.2.6

ANNUAL ANNUAL-02-06-01 7.2.6

ANNUAL ANNUAL-02-06-01 7.2.6

Incorporated into ANNUAL-02-02-04

Incorporated into ANNUAL-02-02-04

MAY requirement, not necessary

7.2.7

# A80000OFFICIAL
 A80000OFFICIAL #

Moved from ANNUAL-02-04-02 ANNUAL ANNUAL-02-07-01 7.2.7

Moved from ANNUAL-02-04-05 ANNUAL ANNUAL-02-07-02 7.2.7

Moved from ANNUAL-02-04-05 ANNUAL ANNUAL-02-07-02 7.2.7

Moved from ANNUAL-02-04-05 ANNUAL ANNUAL-02-07-02 7.2.7

Moved from ANNUAL-02-04-05a ANNUAL ANNUAL-02-07-03 7.2.7

Pulled out of old Annual Assessment ANNUAL ANNUAL-02-07-04 7.2.7

report requirement (because assessors
are not meant to prepare that)

Pulled out of old Annual Assessment ANNUAL ANNUAL-02-07-04 7.2.7

report requirement (because assessors
are not meant to prepare that)

Pulled out of old Annual Assessment ANNUAL ANNUAL-02-07-04 7.2.7

report requirement (because assessors
are not meant to prepare that)

Pulled out of old Annual Assessment ANNUAL ANNUAL-02-07-04 7.2.7

report requirement (because assessors
are not meant to prepare that)

7.2.8
Adapted from ANNUAL-02-05-04 ANNUAL ANNUAL-02-08-01 7.2.8

# A80000OFFICIAL
 A80000OFFICIAL #

Adapted from ANNUAL-02-05-04 ANNUAL ANNUAL-02-08-01 7.2.8

Adapted from ANNUAL-02-05-04 ANNUAL ANNUAL-02-08-01 7.2.8

Adapted from ANNUAL-02-05-04 ANNUAL ANNUAL-02-08-01 7.2.8

Adapted from ANNUAL-02-05-04 ANNUAL ANNUAL-02-08-01 7.2.8

Adapted from ANNUAL-02-05-04 ANNUAL ANNUAL-02-08-01 7.2.8

Adapted from ANNUAL-02-05-04 ANNUAL ANNUAL-02-08-01 7.2.8

Adapted from ANNUAL-02-05-04 ANNUAL ANNUAL-02-08-01 7.2.8

Adapted from ANNUAL-02-05-04 ANNUAL ANNUAL-02-08-01 7.2.8

Adapted from ANNUAL-02-05-04 ANNUAL ANNUAL-02-08-01 7.2.8

Adapted from ANNUAL-02-05-04 ANNUAL ANNUAL-02-08-01 7.2.8

7.2.8
ANNUAL ANNUAL-02-08-02 7.2.8

ANNUAL ANNUAL-02-08-02 7.2.8

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-08-02 7.2.8

ANNUAL ANNUAL-02-08-02 7.2.8

ANNUAL ANNUAL-02-08-02a 7.2.8

ANNUAL ANNUAL-02-08-02a 7.2.8

ANNUAL ANNUAL-02-08-03 7.2.8

ANNUAL ANNUAL-02-08-03 7.2.8

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-08-03 7.2.8

ANNUAL ANNUAL-02-08-03 7.2.8

ANNUAL ANNUAL-02-08-04 7.2.8

ANNUAL ANNUAL-02-08-04a 7.2.8

ANNUAL ANNUAL-02-08-04a 7.2.8

ANNUAL ANNUAL-02-08-04a 7.2.8

7.2.9

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-01 7.2.9

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-01 7.2.9

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-01 7.2.9

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-01 7.2.9

# A80000OFFICIAL
 A80000OFFICIAL #

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-01 7.2.9

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-02 7.2.9

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-02 7.2.9

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-02 7.2.9

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-02 7.2.9

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-03 7.2.9

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-04 7.2.9

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-04 7.2.9

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-04 7.2.9

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-04 7.2.9

# A80000OFFICIAL
 A80000OFFICIAL #

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-09-04 7.2.9

ANNUAL ANNUAL-02-09-04 7.2.9

7.2.9.1
ANNUAL ANNUAL-02-09-05 7.2.9.1

ANNUAL ANNUAL-02-09-05 7.2.9.1

ANNUAL ANNUAL-02-09-05 7.2.9.1

ANNUAL ANNUAL-02-09-05 7.2.9.1

ANNUAL ANNUAL-02-09-06 7.2.9.2

ANNUAL ANNUAL-02-09-06 7.2.9.2

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-09-06 7.2.9.2

ANNUAL ANNUAL-02-09-06 7.2.9.2

ANNUAL ANNUAL-02-09-06 7.2.9.2

ANNUAL ANNUAL-02-09-06 7.2.9.2

ANNUAL ANNUAL-02-09-07 7.2.9.3

ANNUAL ANNUAL-02-09-08 7.2.9.4

ANNUAL ANNUAL-02-09-09 7.2.9.4

ANNUAL ANNUAL-02-09-10 7.2.9.5

7.2.10

# A80000OFFICIAL
 A80000OFFICIAL #

Previously in ANNUAL-02-05-02 ANNUAL ANNUAL-02-10-01 7.2.10

7.2.10.1
ANNUAL ANNUAL-02-10-02 7.2.10.1

ANNUAL ANNUAL-02-10-03 7.2.10.1

ANNUAL ANNUAL-02-10-03 7.2.10.1

ANNUAL ANNUAL-02-10-03 7.2.10.1

ANNUAL ANNUAL-02-10-03 7.2.10.1

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-10-03a 7.2.10.1

ANNUAL ANNUAL-02-10-03b 7.2.10.1

ANNUAL ANNUAL-02-10-03c 7.2.10.1

ANNUAL ANNUAL-02-10-04 7.2.10.1

ANNUAL ANNUAL-02-10-05 7.2.10.1

ANNUAL ANNUAL-02-10-05 7.2.10.1

ANNUAL ANNUAL-02-10-05 7.2.10.1

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL ANNUAL-02-10-05 7.2.10.1

ANNUAL ANNUAL-02-10-05 7.2.10.1

7.2.10.2
ANNUAL ANNUAL-02-10-06 7.2.10.2

7.2.11
Adapted from ANNUAL-02-05-02 ANNUAL ANNUAL-02-11-01 7.2.10.2

Adapted from ANNUAL-02-05-02 ANNUAL ANNUAL-02-11-01 7.2.10.2

Adapted from ANNUAL-02-05-02 ANNUAL ANNUAL-02-11-01 7.2.10.2

Adapted from ANNUAL-02-05-02 ANNUAL ANNUAL-02-11-01 7.2.10.2

Adapted from ANNUAL-02-05-02 ANNUAL ANNUAL-02-11-01 7.2.10.2

# A80000OFFICIAL
 A80000OFFICIAL #

Requirement Text Sub-Requirement A

The Applicant MUST have a registered and

active ABN or ABRN.
The Applicant MUST demonstrate that it is one
of the following:
• a body corporate incorporated by or under
a law of the Commonwealth or a State or
Territory
• a registered foreign company (within the
meaning of the Corporations Act 2001)
• a Commonwealth entity, or a
Commonwealth company, within the meaning
of the Public Governance, Performance and
Accountability Act 2013
• a person or body that is an agency within
the meaning of the Freedom of Information Act
1982
• a body specified, or the person holding an
office specified, in Part I of Schedule 2 to the
Freedom of Information Act 1982
• a department or authority of a State
a department or authority of a Territory.

The TDIF Application Letter MUST specify all

Accredited Roles being sought

# A80000OFFICIAL
 A80000OFFICIAL #

The TDIF Application Letter MUST specify • web responsive design (e.g. can be accessed A
whether the Identity Facility supports: through an internet browser)
• a mobile application (e.g. the Identity Facility is a
[A white-label product is a product or service mobile application)
produced by one organisation that other • a component of either of the above (e.g. a white
organisations can rebrand to make it appear as label service
if they had made it.]

The TDIF Application Letter MUST specify

whether the Applicant wants to connect to the
Australian Government’s Digital Identity System

The Application Letter MUST include evidence

which describes the architecture of the
Applicant’s Identity System and how it operates.

[This is intended to support the DTA in its

accreditation activities and assist it in
determining the scope of Functional
Assessments. The evidence should explain how
the Applicant’s Identity Facility operates, and
provide the DTA with a sufficient understanding
to enable it to work with the Applicant to
determine whether a requirement has been
met.]

# A80000OFFICIAL
 A80000OFFICIAL #

The TDIF Application Letter MUST include an a. Estimated dates when Functional Assessments and
accreditation schedule which includes: any other required testing will be undertaken

b. Estimated dates when Functional Assessment

Reports will be provided to the DTA

c. Estimated dates when the Applicant’s other

required evidence addressing TDIF requirements will be
provided to the DTA

The TDIF Application Letter MUST propose a

commencement date and a date by which TDIF
accreditation is expected to be completed

# A80000OFFICIAL
 A80000OFFICIAL #

If an Applicant seeks a TDIF Exemption Request

against an applicable TDIF Requirement, then it
MUST submit a TDIF Exemption Request in
accordance with ACCRED-03-01-06a and the
process set out in Appendix A: TDIF exemption
process.

Each TDIF Exemption Request MUST include all • A filled out TDIF Exemption Request Form signed by
information as described in Appendix A: TDIF the Applicant’s Accountable Executive
exemption process and, at a minimum:

• A date of expiry or review of the Exemption Request

that is not more than 12 months from the date of the
request; and

• Any supporting information or statements for the

risk assessment and mitigation measures.

The Applicant MAY submit an Alternative

Assessment Report, which it requests the DTA
consider as a substitute for a relevant Functional
Assessment or as evidence to meet other TDIF
requirements. If the Applicant submits an
Alternative Assessment Report, it MUST do so in
accordance with the following requirements.

Any request made to the DTA to consider a) Which Functional Assessment or TDIF requirements
Alternative Assessment Reports MUST include: it is provided as evidence for

b) A rationale for why the Alternative Assessment

Report should be considered as equivalent to a
Functional Assessment or as appropriate evidence to
meet the TDIF Requirements, and

# A80000OFFICIAL
 A80000OFFICIAL #

c) A Requirements Traceability Matrix, which sets out

i. each TDIF requirement the Alternative Assessment
Report addresses,
ii. a reference to where the Alternative Assessment
Report addresses that TDIF requirement (e.g. page
number or section), and
iii. any supporting statements for why that section of
the Alternative Assessment Report addresses the TDIF
requirements (if needed).

The Alternative Assessment Report MUST have

been produced no more than 12 months prior
to the date it is assessed by the DTA and MUST
cover the latest Major Production Release of the
Applicant’s Identity System (if any)

If a Provider seeks to vary its accreditation, then

it MUST apply for a Variation to Accreditation
and submit an updated TDIF Application Letter,
and other required evidence, as per
requirements ACCRED-03-01-01 to ACCRED-03-
01-05 and the following requirements.

The Applicant MUST submit a Requirements

Traceability Matrix and identify all applicable
TDIF requirements that may be impacted by the
variation of accreditation.

The Applicant MUST include and submit to the

DTA a review of the applicable evidence
required for variation of accreditation, as
outlined in Appendix C.

Once the applicant has achieved all applicable • The name, role/position and contact details of the
requirements, the Applicant MUST submit a Accountable Executive
Qualifying Attestation Letter signed by the
Applicant’s Accountable Executive that contains
the following information to support its claim
that its operations are in accordance with TDIF
requirements:

# A80000OFFICIAL
 A80000OFFICIAL #

• A statement that the Accredited Provider’s Identity

System complies with the assessed TDIF requirements

• The version of the TDIF the Accredited Provider is

assessed and accredited under for the Initial Assessment
.

• a statement confirming it has provided the DTA with

all relevant documents, materials and evidence to the
accreditation as part of its review

• A statement confirming that the evidence provided

is a fair and accurate representation of its Identity
System

• If the Applicant has risks, recommendations or non-

compliances identified in its Forward Work Plan, then
the Qualifying Attestation Letter MUST contain a
summary of these risks, implementation dates and any
further information as per ASSESS-07-04-02 and ASSESS-
07-04-03.

Once the Applicant has achieved all applicable

requirements, it MUST sign a TDIF Agreement
(MOU) with the DTA, which sets out the rights,
roles and obligations of both parties in relation
to the Accredited Provider’s TDIF accreditation.

2.1 Digital Identity Fraud Controller

a) managing Digital Identity Fraud Risks within its A
organisation; and
The Applicant MUST have an officer or
senior employee of the Applicant as the
designated Digital Identity Fraud
Controller who is responsible for
b) ensuring the Applicant complies with the fraud A
control requirements in this section
The Applicant MUST conduct an assessment of A
the Digital Identity Fraud Risk associated with
the services for which the Applicant is
accredited and the Applicant’s Identity System
prior to accreditation and at least once every 12
months beginning on the date the Applicant was
accredited

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST a) Determine the Applicant’s tolerance for Digital A

Identity Fraud Risks.

b) Manage the Applicant’s Digital Identity Fraud Risks, A

including by complying with the requirements of this
section.

c) Demonstrate how its Digital Identity fraud controls A

are applied to its Identity Facility.

d) Take all reasonable measures to prevent, detect and A

deal with Digital Identity fraud relating to its Identity
System.

e)Consider the implications their risk management A

decisions have for Accredited Providers, Relying Parties ,
Users and other organisations and share information on
risks with them where appropriate

a) MUST, as soon as practicable notify the DTA of the A

circumstances and the non-compliance, including details
of the remedial action (if any) taken or to be taken to
reduce the risk to the Applicant’s Identity System

Where exceptional circumstances

prevent or affect the Applicant’s
capability to implement a TDIF
requirement, the Applicant:
b) MUST keep a record of decisions taken by the A
Applicant in relation to such non compliance and
remedial action (if any). These decisions will be
requested by the DTA during Annual Assessments

c) MAY vary the Applicant’s Digital Identity fraud A

control arrangements (including, if relevant, the Digital
Identity Fraud Control Plan) for a limited period, but not
so as to increase the level of Digital Identity Fraud Risk
above the Applicant’s risk tolerance.

2.2 Digital Identity Fraud Control Plan

The Applicant MUST have in place a Digital A
Identity Fraud Control Plan approved by the
Digital Identity Fraud Controller to manage the
Applicant’s Digital Identity Fraud Risks

# A80000OFFICIAL
 A80000OFFICIAL #

The Digital Identity Fraud Control Plan MUST a) Fraud control goals and strategic objectives of the A
detail the Applicant, including how the management of Digital
Identity Fraud Risks intersects with and supports broader
business objectives and priorities

b) Applicant’s strategies to implement Digital Identity A

Fraud Risk management and maintain a positive risk
culture

c) Applicant’s tolerance of Digital Identity Fraud Risks. A

d) Digital Identity Fraud threats, risks and A

vulnerabilities that impact the protection of the
Applicant’s Personnel, information (including ICT) and
assets used in connection with the services for which the
Applicant is accredited.

e) Maturity of the Applicant’s capability to manage A

Digital Identity Fraud Risks.

f) Treatment strategies and controls put in place to

manage Digital Identity fraud threats, risks and
vulnerabilities.
A
g) Strategies and controls to ensure the Applicant and
its Personnel successfully complete appropriate training
and raise awareness in relation to Digital Identity Fraud
Risks.
A

h) Procedures and mechanisms for Digital Identity

Fraud Incident management, fraud investigations and
reporting Digital Identity Fraud Incidents.
A

i) An outline of key roles and responsibilities for Digital

Identity Fraud Control within the Applicant’s
organisation
A
j) The risk ratings and scale to be used by the Applicant
when assessing the severity of a Digital Identity Fraud
Incident.

# A80000OFFICIAL
 A80000OFFICIAL #

k) Where applicable, details of the procedures to

detect fraudulent activities by the Assessing Officer
when performing Manual Face Comparison.
l) Where applicable, details of the Applicant’s approach A
to the use of Biometric Information.
A
m) Where applicable, a description of the location(s)
from which Local Biometric Binding will be undertaken
by the Applicant
The Applicant MUST review and update its a) at least annually; and A
Digital Identity Fraud Control Plan:

b) as soon as practicable after:

(i) the Applicant becomes aware of a Digital

Identity Fraud Incident which is of a type not
covered in the Applicant’s Digital Identity Fraud
Control Plan or which exceeds the Applicant’s
tolerance of Digital Identity Fraud Risks as set
out in their Digital Identity Fraud Control Plan;
(ii) the Applicant becomes aware of a breach of
the requirements of their Digital Identity Fraud
Control Plan;
(iii) a change in the structure, functions or
activities of the Applicant which may impact the
operation of the fraud control components of
their Identity System.
(iv) a change to the Applicant’s Identity System
where such change may increase the level of
Digital Identity Fraud Risk
This review MUST: a) Determine the adequacy of existing fraud control A
measures and mitigation controls

b) Respond to and manage shifts in the Applicant’s risk, A

threat and operating environment

# A80000OFFICIAL
 A80000OFFICIAL #

2.3 Digital Identity Fraud prevention, awareness

and training

The Applicant MUST maintain records of A

instructions it gives its Personnel and
contractors and procedures to assist Personnel
to prevent, detect, report and deal with Digital
Identity Fraud Incidents.

The Applicant MUST provide appropriate Digital a) before such Personnel start work on those duties A
Identity Fraud Risk information and training to
Personnel whose duties relate to the services
for which the Applicant is accredited:

b) and at least once every 12 months thereafter A

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST provide fraud- A

control advice to Users on how to
safeguard their Digital Identity and
Attributes
If the Applicant is aware of a Digital Identity a) provide advice to Users on how to avoid such A
Fraud Incident or Digital Identity Fraud Risk incidents or risks; or
which may affect Users, the Applicant MUST:

b) if Users do not interact directly with the Applicant or A

the Applicant’s Identity System, take reasonable steps
to support the provision of such advice by another
Accredited Provider or Relying Party

2.4 Fraud monitoring and detection

The Applicant MUST implement and maintain a A
Digital Identity Fraud control mechanism to
detect actual or suspected Digital Identity Fraud
Incidents.

The Applicant MUST implement and maintain a A

process for Personnel, Individuals, Enforcement
Bodies and other entities to report suspected
Digital Identity Fraud confidentially

The Applicant MUST implement and maintain a A

Digital Identity Fraud control mechanism to flag
actual or suspected Digital Identity Fraud
Incidents

The Applicant MUST compare all new A

registrations and updates to existing records
against the fraud control mechanism used to
flag actual or suspected Digital Identity Fraud
Incidents

If the Applicant reasonably suspects that a MUST NOT allow a new registration or update of that A
Digital Identity is fraudulent or its use may result Digital Identity to be completed
in a Digital Identity Fraud Incident, the
Applicant:

MUST block the use of the Digital Identity on its Identity A

System
2.5 Incident management, investigations and
reporting

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST either: a) investigate actual and suspected Digital Identity A
Fraud Incidents, unless the incident or suspected
incident has been referred to, and been accepted by, an
Enforcement Body; o

b) if the Digital Identity Information held by the A

Applicant in connection with the services for which it is
accredited does not include Personal Information, take
reasonable steps to support an investigation being
conducted by another Entity

In the event of a Digital Identity Fraud Incident, a) mitigate the adverse effects of the incident; and A
the Applicant MUST take reasonable steps to

b) eliminate or, if it cannot be eliminated, minimise, the A

risk of recurrence of similar incidents

The Applicant MUST maintain documented A

procedures setting out criteria for Digital
Identity Fraud Incident investigation processes
and procedures including appropriate criteria
for making timely decisions at critical stages in
managing a Digital Identity Fraud Incident

The Applicant MUST keep records of: a) decisions to use civil, administrative or disciplinary A
procedures, or to take no further action in response to a
suspected Digital Identity Ffraud Iincident; and

b) the Applicant’s investigation of and responses to A

actual and suspected Digital Identity Fraud Incidents

Where an Enforcement Body declines a A

referral, the Applicant MUST resolve the matter
in accordance with relevant internal and
external requirements

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST demonstrate that the A

Personnel, or any external investigators,
engaged to conduct Fraud investigations are
appropriately qualified Personnel with relevant
qualifications or training to effectively carry out
their duties

The Applicant MUST: a) provide the DTA with a report on Digital Identity Fraud A
Incidents at least once every quarter; or

# A80000OFFICIAL
 A80000OFFICIAL #

b) if the Digital Identity Information held by the A

Applicant in connection with the services for which it is
accredited does not include Personal Information, take
reasonable steps to support the reporting of Digital
Identity Fraud Incidents by another Accredited Provider
or Relying Party.

The Applicant MUST include, at a minimum, the a) the number of Digital Identity Fraud Incidents related A
following information when reporting on Digital to the Applicant in the period since the last report. The
Identity Fraud Incidents: number of such incidents may be zero

b) a description of the type or types of Digital Identity A

Fraud Incidents and their severity; and
c) a description of the measures taken by the Applicant A
in response to the incidents covered by the report

2.6 Support for victims of Digital identity fraud

The Applicant MUST implement a process which A

allows any Individual to notify the Applicant
when they suspect or become aware that they
have been affected by a Digital Identity Fraud
Incident

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST provide (either directly or A

through a third party) support services to any
Individuals who are impacted by a Digital
Identity Fraud Incident.

If the use of a Digital Identity has been blocked A

by the Applicant in accordance with FRAUD-02-
04-02b, the Applicant MUST ensure that the
Digital Identity is not used on the Applicant’s
Identity System unless the Digital Identity has
been reproofed to the highest Identity Proofing
Level as applied to the Digital Identity before
the incident

3.1 General privacy requirements

The Applicant MUST comply with applicable A
laws in relation to the protection and privacy of
Personal Information including, where relevant,
applicable obligations under the Privacy Act,
including the Australian Privacy Principles
(APPs), Australian Government Agencies Privacy
Code and relevant, state or territory privacy
legislation

If the Applicant is not an APP Entity, the a) the Privacy Act applies to that action or practice as if A
Applicant MUST NOT take any action or engage the Applicant were an organisation within the meaning
in a practice with respect to Personal of that Act; or
Information when providing services using its
Identity System unless:

# A80000OFFICIAL
 A80000OFFICIAL #

b) a law of a State or Territory that provides for all of A

the following applies to the Applicant in relation to the
action or practice:
(i) protection of Personal Information (including
requirements relating to the notification of data
breaches) comparable to that provided by the Privacy
Act and the APPs; and
(ii) monitoring of compliance with the law; andor
(iii) a means for an Individual to seek recourse if
the Individual’s Personal Information is dealt with in a
way contrary to the law.; or

neither (a) nor (b) apply and the Applicant has entered A
an agreement with the DTA, and the agreement requires
the Applicant to comply with the Privacy Act and the
APPs in relation to that action or practice as if the
Applicant were an APP Entity.

The Applicant MUST have at least one

designated Privacy Officer who is the primary
point of contact for advice on privacy matters
and ensure that position is held by a person
with relevant qualifications and experience to
effectively carry out the functions specified for
the Privacy Officer in PRIV-03-02-01a

The Applicant MUST demonstrate how the a) Handling of internal and external privacy enquiries A
following Privacy Officer functions are carried and complaints.
out:

b) Handling requests for access to and correction of A

Personal information

# A80000OFFICIAL
 A80000OFFICIAL #

c) Maintaining a record of Personal information A

holdings including:
(i) the types of Personal Information collected, held or
disclosed;
(ii) the manner in which such information is
received by the Applicant; and
(iii) where such information is held

d) Assisting with the preparation of Privacy Impact A

Assessments (PIAs)

e) Maintaining a register of PIAs. A

f) Reviewing and, where relevant, updating the Privacy A

Policy at least annually in accordance with PRIV-03-02-
05

The Applicant MUST have at least one A

designated Privacy Champion and ensure that
position is held by a person with relevant
qualifications and experience to effectively carry
out the functions specified for the Privacy
Champion in PRIV-03-02-02a and PRIV-03-02-
02b

The Applicant MUST demonstrate how its A

Privacy Champion promotes a culture of privacy
that values and protects Personal information.

The Applicant MUST demonstrate how its a) approves its Privacy Management Plan; A
Privacy Champion:

b) reviews the Applicant’s progress against the Privacy A

Management Plan as described in PRIV-03-02-07

c) provides regular reports to the Applicant’s executive A

on privacy issues; and
d) provides leadership within the Applicant on broader A
strategic privacy issues

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST publish a clearly expressed A

and up to date Privacy Policy about the
management of Personal Information by the
Applicant.

The Applicant MUST have a separate Privacy A

Policy in relation to its Identity System to that of
its other business, organisation functions or
Accredited Roles.

Where an Applicant is applying to, or has been, A

accredited in two or more of the following
Accredited Roles:
a) an Identity Service Provider;
b) an Attribute Service Provider;
c) an Identity Exchange;
the Applicant MUST clearly distinguish between
the privacy policy or privacy policies for each
Accredited Role

The Applicant’s Privacy Policy MUST include a) The kinds of Personal information that the Applicant
information on: collects and holds

b) How the Applicant collects and holds Personal

information

c) The purposes for which the Applicant collects, holds, A

uses and discloses Personal information.

d) How an Individual can access Personal information A

about themselves that is held by the Applicant and how
to seek the correction of such information.

e) How an Individual can complain about a breach of the A

APPs(or a particular jurisdiction privacy principle) and
how the Applicant will deal with such a complaint.

# A80000OFFICIAL
 A80000OFFICIAL #

f) Whether the Applicant is likely to disclose Personal A

information to overseas recipients and if so the
countries in which such recipients are likely to be located
(if it is practicable to do so).

The Applicant’s Privacy Officer MUST review the Privacy A

Policy which covers the Applicant’s Identity System at
least annually and ensure that the Privacy Policy is
updated where required promptly following such review.

The Applicant's Privacy Officer MUST develop A

and maintain a Privacy Management Plan that
identifies measurable privacy goals and targets
for its Identity System and the practices,
procedures and systems that will be
implemented to achieve these targets and goals

The Applicant’s Privacy Champion MUST A

measure and document its performance against
the Privacy Management Plan relevant to TDIF
at least annually

The Applicant MUST provide appropriate a) before such Personnel start work on those duties; and A
privacy awareness training to Personnel whose
duties relate to the services for which the
Applicant is accredited:

(A copy of the training materials will be

requested by the DTA as part of initial
accreditation and annually thereafter as part of
the Annual Assessment under TDIF: 07-Annual
Assessment)

b) at least once every 12 months thereafter A

The privacy awareness training provided by the A
Applicant MUST cover the Applicant’s Privacy
Policy, TDIF privacy requirements, and any
relevant privacy laws

3.3 Privacy Impact Assessment

The Applicant MUST conduct a Privacy Impact A
Assessment on all High Risk Projects related to
its Identity System

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST maintain a register of the A

PIAs it conducts in respect of its Identity
System, including PIAs referred to in PRIV-03-
03-01 and PIAs conducted as part of Functional
Assessments

The Applicant MUST publish the register, or a A

version of the register, on its website.

If the Applicant is an APP Entity, the Applicant a) report eligible data breaches to affected Individuals A
MUST: and the Information Commissioner as required under
the Privacy Act ; and

b) if required to notify the Information Commissioner— A

provide the DTA with a copy of the report at the same
time it is provided to the Information Commissioner

If the Applicant is not an APP Entity, the a) if the Applicant is a department or authority of a A
Applicant MUST: State or Territory and the Applicant is covered by a law
of State or Territory that provides a scheme for
notification of data breaches that is comparable to the
scheme provided for in Part IIIC of the Privacy Act, the
Applicant MUST:
(i) comply with its notification obligations under the
relevant State or Territory Scheme; and
(ii) if required to notify another entity—provide the
DTA with a copy of any statement provided to the
notified entity under such scheme at the same time as it
is provided to the notified entity; or

b) if paragraph (a) does not apply to the Applicant, the A

Applicant MUST comply with PRIV-03-04-01 as if the
Applicant were an APP Entity.

The Applicant MUST develop and maintain a a) includes a description of the actions to be taken if a A
Data Breach Response Plan that: data breach is suspected, discovered, or reported by
Personnel or external party

b) lists the roles and responsibilities of Personnel A

involved in managing a data breach; and

# A80000OFFICIAL
 A80000OFFICIAL #

c) includes a clear communication plan and A

information about when a data breach is to be:
(i) escalated to the data breach response team;
(ii) notified to Individuals affected by the data breach;
and
(iii) notified to a third party, including notifications
required by law and notifications under PRIV-03-04-01a

The Data Breach Response Plan MUST NOT be A

inconsistent with the Applicant’s Digital Identity
Fraud Control Plan or System Security Plan

The Applicant MUST notify or make people A

aware as required by APP 5.
The Applicant MUST notify Individuals that the A
Applicant may use the Individual’s information
to detect, manage and investigate Digital
Identity Fraud Incidents.

The Applicant MUST only collect Personal A

information that it is permitted to collect under
law and that is reasonably necessary for the
Applicant to provide the services for which it is
seeking accreditation

The Applicant MUST only collect Personal A

information by lawful and fair means.
The Applicant MUST only collect Personal A
information from the Individual or their
representative, unless it is unreasonable or
impractical to do so.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST NOT use or disclose A

Personal information for direct marketing
purposes, including:
a) offering to supply goods or services;
b) advertising or promoting goods or services;
c) enabling another entity to offer to supply
goods or services;
d) enabling another entity to advertise or
promote goods or services; or
e) market research.
This requirement does not apply to the
disclosure of Personal Information if:
f) the information is disclosed for the
purposes of offering to supply services or
advertising or promoting services that the
Applicant is seeking accreditation to provide to
an Individual; and
g) the individual about whom the information
is disclosed has expressly consented to the
disclosure and receiving communications for
purposes permitted by paragraph (f)

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST NOT use or disclose A

Personal information for enforcement related
activities conducted by, or on behalf of, an
Enforcement Body unless:
a) the Applicant is satisfied that the
enforcement body reasonably suspects that a
person has committed an offence against a law
of the Commonwealth or of a State or Territory
that is punishable on conviction by
imprisonment for at least 3 years or started
proceedings against a person for such an
offence; or
b) the Applicant is satisfied that the
enforcement body reasonably suspects that a
person has breached a law imposing a penalty
of 180 penalty units or more (for an individual)
or 900 penalty units or more (for a body
corporate), or has started proceedings against a
person in relation to the breach; or
c) the information is used or disclosed under a
warrant issued by a magistrate, judge or
member of a tribunal; or
d) the use or disclosure is otherwise required
by a law or TDIF Requirement that applies to
and is binding on the Applicant.

The Applicant MUST publish in an open and

accessible manner an Annual Transparency
Report.

Unless prohibited by law, the Annual a) the name of each Enforcement Body that has
Transparency Report MUST disclose: requested Digital Identity Information from the
Applicant since the previous report;

b) the total number of such requests received by the

Applicant;
c) details of the type or kind of Digital Identity
Information requested by each Enforcement Body (but
not so as to include the Personal Information of an
Individual); and

d) the total number of requests that resulted in the

Applicant providing Digital Identity Information in
response to the request.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST NOT retain Users’

Attributes or Restricted Attributes once they are
passed from an Identity Service Provider to a
Relying Party with the exception of:
a) securely storing the Attributes for the
duration of an authenticated session.
b) Identity System Metadata listed in table 2
of the TDIF 05 Role Requirements.

The Applicant MUST only collect, use and a) provide the services for which the Applicant is A
disclose an Individual’s Behavioural Information seeking accreditation
to:

b) comply with a requirement or authorisation under a A

law of the Commonwealth, a state or territory

c) support Digital Identity fraud management functions; A

or

d) improve the performance or usability of the A

Applicant’s Identity System

The Applicant MUST NOT sell an Individual’s A

Behavioural information to a third party.

3.8 Collection, Use and Disclosure of biometrics

The Applicant MUST ensure Express Consent is

obtained from an Individual prior to collecting,
using, or disclosing that Individual’s Biometric
Information.

a) The Applicant is seeking accreditation, or is

accredited, as an Identity Service Provider or Credential
Service Provider and the Biometric Information is being
collected, used or disclosed for the purposes of
The Applicant MUST NOT collect, use, or conducting Biometric Binding as part of an Identity
disclose an Individual’s Biometric Information Proofing Process or authenticating the Individual to their
unless: Digital Identity; or
A
b) The Biometric Information is being collected, used
or disclosed for the purposes of creating a government
issued Identity document.

# A80000OFFICIAL
 A80000OFFICIAL #

Subject to PRIV-03-08-02a, Biometric a) if collected by an Identity Service Provider for the

information MUST be destroyed purpose of conducting Biometric Binding as part of an
Identity Proofing Process, immediately after the
Biometric Binding process is complete; or

b) if collected by a Credential Service Provider with the

Express Consent of an Individual for the purpose of
authenticating that Individual to their Digital Identity,
immediately after the consent is withdrawn

In accordance with PRIV-03-08-02, the Applicant

MUST destroy Biometric information unless the
Biometric information is collected or was
collected to create a government issued Identity
document and the Applicant is an Identity
Document Issuer for that Identity Document

For example where a Road Traffic and Transport

Authority is an Identity document issuer and an Identity
Service Provider.
When destroying or retaining Biometric
Information in accordance with PRIV-03-08-02,
the Applicant MUST ensure that it is responsible
for the destruction or retention of all collected
Biometric Information, including all copies,
caches, and intermediary databases, including
any subcontracted or third-party components.
The Applicant MUST provide evidence of this to
the DTA.

When destroying Biometric Information, the A

Applicant MUST create and maintain a record
that the destruction of Biometric Information
has occurred.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST NOT use a Biometric A

Matching algorithm to perform one-to-many
matching.

If the Applicant can collect, use or disclose

Biometric Information under PRIV-03-08-01a,
the Applicant MAY disclose that biometric
information to the Individual to whom the
information relates.

3.9 Express Consent

The Applicant MUST ensure Express Consent is A
obtained from an Individual prior to disclosing
that individual’s Attributes to a Relying Party or
any third party (including an Authoritative
Source).

The Applicant MUST ensure Express Consent is 5 If the Attribute Service Provider connects directly with A
obtained from an Individual prior to disclosing a Relying Party, it is required to obtain Express Consent
that individual’s Attributes to a Relying Party or prior to the disclosure. If the connection to the Relying
any third party. Party is brokered by an Identity Exchange, Express
Consent may be obtained by the Identity Exchange on
behalf of the Attribute Service Provider.

The Applicant MUST ensure Express Consent is 6 If the Identity Service Provider connects directly with a
obtained from an Individual prior to disclosing Relying Party, it is required to obtain Express Consent
that individual’s Attributes to a Relying Party or prior to the disclosure. If the connection to the Relying
any third party. Party is brokered by an Identity Exchange, Express
Consent may be obtained by the Identity Exchange on
behalf of the Identity Service Provider.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST ensure Express Consent is 7 If the connection to the Relying Party is brokered by an
obtained from an Individual prior to disclosing Identity Exchange, the Identity Exchange may delegate
that individual’s Attributes to a Relying Party or the collection of Express Consent to the Identity Service
any third party. Provider or Attribute Service Provider.

If the Applicant is obtaining enduring Express A

Consent from a User, they MUST implement the
following requirements: (PRIV-03-09-02a, PRIV-
03-09-02b, PRIV-03-09-02c 02a, and PRIV-03-09-
02d) for the operation of withdrawal of
enduring Express Consent

The Applicant MUST allow an Individual to A

withdraw or vary their Express Consent
The Applicant MUST demonstrate how this A
Express Consent withdrawal or variation process
is straightforward and easy to use

The Applicant MUST include a clear description A

of the process to withdraw or vary the Express
Consent in the Applicant’s Privacy Policy

The Applicant MUST, at the time of obtaining a) that providing enduring Express Consent is optional A
enduring consent, notify Individuals

b) of the implications of providing or not providing their A

enduring Express Consent; and
c) of the process for withdrawing or varying their A
enduring Express Consent.

The Applicant MUST maintain Audit Logs that a) the date and method by which Express Consent was A
demonstrate how Express Consent was obtained from the Individual;
obtained from the Individual, including:

b)the duration of the Express Consent; A

c)the terms of the Express Consent; and A

# A80000OFFICIAL
 A80000OFFICIAL #

d) whether the Express Consent has been withdrawn A

or has expired.

The Applicant MUST inform Individuals of other A

channels available to verify their Identity and
make clear to the Individual what the
consequences are of declining to provide
Express Consent or the required information

3.10 Cross border and contractor disclosure of

Personal information
The Applicant MUST demonstrate how it A
complies with APP 8 - cross border disclosure of
Personal information.

The Applicant MUST take reasonable steps to A

ensure an overseas recipient of Personal
information used by the Applicant to provide its
identity system only uses the Personal
information disclosed to it for purposes directly
related to identity verification.

If it discloses Personal information to an A

overseas recipient that is not the individual, the
Applicant MUST demonstrate to the DTA’s
reasonable satisfaction it has appropriate
contractual and practical measures to ensure
the overseas recipient complies with these TDIF
privacy requirements.

3.11 Single Identifiers

The Applicant MUST NOT create and assign a A
unique identifier to a User for use across an
Identity federation

3.12 Access, correction and individual history

log

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST on request by an A

Individual, give that Individual access to the
Personal information it holds about the
Individual, unless an exception is available
under APP 12 (APP 12.2 for Commonwealth
agencies and APP 12.3 for other Applicants).

The Applicant MUST respond to a request for A

access to Personal information that it holds
from an individual within 30 days after the
request is received.

The Applicant MUST give the Individual access A

to their Personal information in the manner
requested by the Individual, if it is reasonable,
secure and practicable to do so.

The Applicant MUST provide access at no cost to A

the Individual.
The Applicant MUST, where access is refused, A
take steps to meet the needs of the Individual
and provide a written notice as set out in APP
12.

The Applicant MUST allow Individuals to correct A

their Personal information it holds as set out in
APP 13.

The Applicant MUST provide Individuals with a A

simple and accessible means to access and
review their Personal information.

The Applicant MUST provide Individuals with A

clear instructions on how to update their
Personal information

An Applicant MUST take reasonable steps to A

ensure quality of Personal information as
outlined in APP 10.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST implement internal A

practices, procedures and systems (including
training Personnel in these practices,
procedures and systems) to audit, monitor,
identify and correct poor-quality Personal
information.

The Applicant MUST ensure updated or new A

Personal information is promptly added to
relevant existing records.

The Applicant MUST provide a complaints a) is readily accessible, including prominent contact A
service for handling privacy complaints which: information about the service.

b) is fair, including a process that is impartial, A

confidential and transparent.

c) has a process that is timely, clear and can provide a A

remedy where applicable.

d) has skilled and professional people who have A

knowledge of privacy laws and these TDIF privacy
requirements and the complaint service process.

e) is integrated with other complaint handling bodies, A

(e.g. other Participants of an identity federation) as
required, so it can assist the individual and refer
complaints.

The Applicant MUST demonstrate it takes A

reasonable steps to destroy or de-identify
Personal information in line with APP 11.2.

4.1 Security governance

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST conduct an assessment of A

the Cyber Security Risks in relation to the
Applicant prior to accreditation and at least
once every 12 months beginning on the date
the Applicant is accredited

The Applicant MUST a) Determine and record the Applicant’s tolerance for A
Cyber Security Risks

b) Manage the Applicant’s Cyber Security Risks, including A

by complying with the requirements of this section

c) Demonstrate how its protective security controls A

(including controls for Cyber Security Risks) are applied
to its Identity System

d) Consider the implications their risk management A

decisions have for Accredited Providers, Relying Parties
and Users and share information on risks with them
where appropriate

Where exceptional circumstances prevent or a) MUST, as soon as practicable notify the DTA of the A
affect the Applicant’s capability to implement a circumstances and the non-compliance, including details
TDIF requirement, the Applicant of the remedial action (if any) taken or to be taken to
reduce the risk to the Applicant’s Identity System

b)MUST keep a record of decisions taken by the A

Applicant in relation to such non-compliance and
remedial action (if any). These decisions will be
requested by the DTA during Annual Assessments

a) MAY vary the Applicant’s protective security A

arrangements (including, if relevant, the System Security
Plan), for a limited period of time, but not so as to
increase the level of Cyber Security Risk above the
Applicant’s risk tolerance.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST have an officer or senior a) managing Cyber Security Risks within their A
employee of the Applicant as the designated organisation; and
Chief Security Officer (CSO) or equivalent role
who is responsible for:

b) ensuring the Applicant complies with the protective A

security requirements in this section.

The Applicant MUST empower the CSO or a) Appointing security advisors within the Applicant’s A
equivalent role to make and implement organisation to support the CSO in the day-to-day
decisions about delivery of protective security services

b) The Applicant’s protective security planning. A

c) The Applicant’s protective security practices and A

procedures.

d) Investigating, responding to and reporting on Cyber A

Security Incidents

The Applicant MUST ensure Personnel are A

aware of their collective responsibility to foster
a positive security culture.

The Applicant MUST provide appropriate a) before such Personnel start work on those duties ; and A
information and training in relation to the
prevention and management of Cyber Security
Risks to Personnel whose duties relate to the
services for which the Applicant is accredited:

A copy of the training materials will be

requested by the DTA as part of initial
accreditation and annually thereafter as part of
the Annual Assessment under TDIF: 07-Annual
Assessment.

b)at least once in every 12 months thereafter. A

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST develop and use a) All elements of the Applicant’s System Security Plan A
procedures that ensure: are achieved.

b) Cyber security incidents are investigated, responded A

to and reported to the DTA.

c) Relevant security policy or legislative obligations are A

met.

The Applicant MUST maintain records of A

instructions it gives its Personnel and
contractors and its procedures to assist
Personnel and contractors to prevent, detect,
report and deal with Cyber Security Risks

The Applicant MUST provide Personnel in A

specialist and high-risk positions (including
contractors and security incident investigators)
with specific security awareness training
targeted to the scope and nature of the
position.

The Applicant MUST: a) maintain a monitored central communications A

channel (such as an email address ) for all security-
related matters across governance, Personnel,
information, ICT and physical security, including in
relation to Cyber Security Risks related to the Applicant;
and

b) ensure Personnel are aware of the communications A

channel and the purposes for which it is to be used

The Applicant MUST provide security advice to A

users on how to safeguard their Digital Identity,
Credentials, Personal information and
Attributes.

The Applicant MUST have in place a System A

Security Plan approved by the CSO to manage
the Applicant’s Cyber Security Risks

# A80000OFFICIAL
 A80000OFFICIAL #

The System Security Plan MUST include a) The Cyber security goals and strategic objectives of A
the Applicant, including how Cyber Security Risk
management intersects with and supports broader
business objectives and priorities.

b)The Applicant’s strategies to implement Cyber Security A

Risk management and maintain a positive Cyber Security
Risk culture

c) The Applicant’s tolerance of Cyber Security Risks A

d) The Personnel, information, ICT and assets that are A

critical to the ongoing operation of the Applicant’s
Identity System

e) The maturity of the Applicant’s capability to manage A

Cyber Security Risks and the proposed steps to enhance
that capability or meet new or emerging risks, threats or
vulnerabilities.

f) A summary of the threats, risks and vulnerabilities that A

impact the confidentiality, integrity and availability of
the Applicant’s Identity System

g) An assessment of the significance of the threats, risks, A

and vulnerabilities in paragraph (f).
h) The treatment strategies and controls put in place to A
manage Cyber Security Risks and vulnerabilities

i) The strategies to ensure the Applicant meets its A

training and awareness needs in relation to the
prevention and management of Cyber Security Risks

j)Details of the training that will be provided under A

paragraph (i);
k) The procedures and mechanisms for Cyber Security A
Incident management, cyber security investigations and
reporting Cyber Security Incidents.

# A80000OFFICIAL
 A80000OFFICIAL #

l) An outline of key roles and responsibilities for A

protective security control within the Applicant’s
organisation including one or more risk steward/s (or
manager/s) who are responsible for each Cyber security
risk or category of Cyber security risk, including for
shared risks

m) Flexible measures that can be implemented where A

necessary to meet variations in threat levels, including
changes in the national terrorism threat level.

n) The risk ratings and scale to be used by the A

Applicant when assessing the severity of a Cyber Security
Incident.

o) Where applicable, a description of the location(s) A

from which Local Biometric Binding will be undertaken
by the Applicant.

The Applicant MUST review and update its a)at least annually; and A
System Security Plan

b) as soon as practicable after: A

(i) the Applicant becomes aware of a Cyber Security
Incident in connection with its Identity System which is
of a type not covered in the System Security Plan or
which exceeds the Applicant’s recorded tolerance for
Cyber Security Risks;
(ii) the Applicant becomes aware of a breach of the
requirements of its System Security Plan; or
(iii) a change in the structure, functions or activities of
the Applicant (including a change to the Applicant’s
Identity FacilityIdentity System) where such change may
increase their level of Cyber Security Risk

This review MUST: a) Determine the adequacy of existing protective A

security control measures and mitigation controls.

# A80000OFFICIAL
 A80000OFFICIAL #

b) Respond to and manage significant shifts in the A

Applicant’s risk, threat and operating environment.

The Applicant MUST identify Personnel, A

information, ICT and assets that are critical to
the ongoing operation of the Applicant’s
Identity System and apply appropriate
protections to these resources to support their
operation.

The Applicant MUST assess the maturity of its A

security capability to manage Cyber Security
Risks and risk culture by considering its progress
against goals and strategic objectives identified
in its System Security Plan.

The Applicant MUST document and present A

evidence to the DTA of the maturity of the
Applicant’s capability to manage Cyber Security
Risks.

The Applicant MUST: a) Identify Digital Identity Information in the possession A

or control of the Applicant

# A80000OFFICIAL
 A80000OFFICIAL #

b) Assess the sensitivity of such information and the A

importance of the information to the Applicant’s Identity
System

c) Implement appropriate controls to secure such A

information against loss, interference, misuse,
unauthorised access, unauthorised modification or
unauthorised disclosure

The Applicant MUST ensure information it holds A

is stored, transferred, transmitted and disposed
of securely. This includes ensuring Sensitive
information (within the meaning of that term in
PSPF 08) is appropriately destroyed or archived
when it has passed minimum retention
requirements or reaches authorised destruction
dates

The Applicant MUST enable appropriate access a) Ensuring that access to Sensitive information, Digital A
to Digital Identity Information. This includes Identity Information or components of the Identity
System on which such information is stored is only
provided to people with a Need to know that
information

b) Controlling access (including remove access) to A

supporting ICT systems, networks, infrastructure,
devices and applications used by the Applicant in
connection with its Identity System.

To manage access to information systems A

holding Sensitive information, the Applicant
MUST implement unique User identification,
authentication and authorisation practices on
each occasion where system access is granted.

The Applicant MUST record each occasion A

where access is authorised, denied, limited or
removed in accordance with PROT-04-02-04,
and the identity of the individual on each such
occasion

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST mitigate common and a) application control A

emerging cyber threats, including, at a
minimum, by implementing and maintaining
controls for:

b) patching applications A
c) restricting administrative privileges; and A
d)patching operating systems; A
The Applicant MAY consider implementing A
additional ASD Strategies to Mitigate Cyber
Security Incidents

The Applicant MUST implement and maintain a A

mechanism for detecting Cyber Security
Incidents and suspected Cyber Security
Incidents which occur in connection with its
Identity System

The Applicant MUST implement and maintain a A

process for Personnel, Individuals, Enforcement
Bodies and other entities to report suspected
Cyber Security Incidents confidentially

A
The Applicant MUST implement and maintain a
control mechanism to flag Cyber Security
Incidents or suspected Cyber Security Incidents
which occur in connection with its Identity
System.
The Applicant MUST compare all new A
registrations and updates to existing records
against the control mechanism used to flag
actual or suspected Cyber Security Incidents

If the Applicant reasonably suspects that the a) MUST NOT allow a new registration or update of A
registration or update of a Digital Identity is that Digital Identity to be completed;
likely to create a Cyber Security Incident, the
Applicant:

b) MUST block the use of the Digital Identity on its A

Identity System.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST maintain documented A

procedures setting out criteria for Cyber
Security Incident investigation processes and
procedures including appropriate criteria for
making timely decisions at critical stages in
managing a Cyber Security Incident

The Applicant MUST take responsibility for A

investigating actual or suspected Cyber Security
Incidents which occur in connection with its
Identity System, including investigating
disciplinary matters, unless the matter is
referred to and accepted by the Australian
Cyber Security Centre or an Enforcement Body

Where an Enforcement Body declines a referral,

the Applicant MUST resolve the matter in
accordance with relevant internal and external
requirements.

The Applicant MUST demonstrate that the A

Personnel, or any external investigators,
engaged to conduct security investigations are
appropriately qualified Personnel with relevant
qualifications or training to effectively carry out
their duties

In the event of a Cyber Security Incident which a) mitigate the adverse effects of the incident; and A
impacts the Applicants Identity System, the
Applicant MUST take reasonable steps to:

# A80000OFFICIAL
 A80000OFFICIAL #

b) eliminate or, if it cannot be eliminated, minimise, A

the risk of recurrence of similar incidents.

The Applicant MUST report Cyber Security A

Incidents which occur in connection with their
Identity System to the DTA at least once every
quarter.

The Applicant MUST include the following a) the number of Cyber Security Incidents which A
information when reporting Cyber Security occurred in connection with the Applicant’s Identity
Incidents System in the period since the last report. The number
of such incidents may be zero;

b) a description of the type or types of Cyber Security A

Incidents and their severity; and

c) a description of the measures taken by the A

Applicant in response to the incidents covered by the
report.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST implement a process which A

allows Individuals to notify them when they
suspect or become aware of a Cyber Security
Incident.

The Applicant MUST provide (either directly or A

through a third party) support services to
Individuals who are impacted by Cyber security
incidents which occur in connection with the
Applicant’s Identity System.

The Applicant MUST have in place processes A

such as appropriate identification of an
Individual whose Attributes, Digital Identity or
Credential has been subject to a Cyber Security
Incident and appropriate technologies to enable
the Applicant to flag the Attributes, Digital
Identity or Credential as compromised.

If the use of a Digital Identity has been blocked A

by the Applicant in accordance with PROT-04-
02-08b as a result of a Cyber Security Incident,
the Applicant MUST ensure that the Digital
Identity is not used on the Applicant’s Identity
System unless the Digital Identity has been
reproofed to at least the same Identity Proofing
Level that applied to the Digital Identity before
the incident

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST have in place secure A

measures during all stages of ICT systems
development. This includes certifying and
accrediting ICT systems in accordance with the
ISM (or a similar process for non-government
Applicants) when implemented into the
operational environment.

When establishing new ICT systems or A

implementing improvements to current ICT
systems (including software development), the
Applicant MUST address security in the early
phases of the system’s development life cycle.
This includes during the system concept
development and planning phases, and then in
the requirements analysis and design phases.

The Applicant MUST NOT process, store or A

communicate Sensitive information (within the
meaning of that term in PSPF 08) on its Identity
System, unless the residual Cyber Security Risks
to the Identity System and Digital Identity
Information have been recognised and accepted
by the CSO or a security advisor on behalf of the
CSO

The Applicant MUST ensure their ICT systems A

(including software) incorporate processes for
generating Audit Logs.

At a minimum, Audit Logs MUST record the A

following events:
• Successful and failed elevation of privileges by
Personnel.
A
• User and group additions, deletions and modification
to permissions.
A

• Security related system alerts and failures (e.g.

attempted access that is denied, crashes or error
messages).
A
• Unauthorised access attempts to critical systems and
files.

# A80000OFFICIAL
 A80000OFFICIAL #

for an Identity Service Provider, the binding of Attributes

to a Digital Identity; and
A

• for an Attribute Service Provider:

o the binding of Attributes to a Digital Identity; and
o the retrieval of Attributes by a third party.
At a minimum, Audit Logs MUST include[1] the A
following details for each event:

• The date and time

A

• The relevant User, identifier or process. Each activity

must have a unique identifier.
• The description. A
A
• The ICT equipment involved.
A
• The source IP address of the device that authenticated
to the identity system.
A
• The source port used to perform the authentication
event.
A
• The destination IP address used to perform the
authentication event.
A
• The destination port used to perform the
authentication event.
A

• The User Agent String which identifies the browser and

operating system of the attempted authentication.
A unique identifier for the device being used in the event A
(such as an International Mobile Equipment Identity
(IMEI) of a mobile phone if a mobile phone is used to
authenticate to the Identity System).

Audit logs MUST include for each event: • Credential type used.
• Credential Level achieved.

# A80000OFFICIAL
 A80000OFFICIAL #

Audit Logs MUST include for each event the

Identity Proofing Level of the Digital Identity
used, if any

Audit Logs MUST include for each event:

a) Interaction type. (e.g. OIDC Authentication Request
and response)
Unique interaction identifier

(b) The name of the Identity Service Provider or a

Relying Party.
(c) Any unique identifier used in the activity

(d) Names of any Attributes requested and returned.

(e) Any Identity Proofing Level or Credential Level

requested and returned.

Each Audit Log MUST be A

a) Protected and stored to ensure the accuracy and

integrity of data captured or held.
b) Protected from unauthorised access, modification A
and deletion.

c) Retained for a minimum of 3 years from the date it A

was generated.

The Audit Logs MUST NOT contain Biometric A

information.
The Applicant MUST maintain a Disaster A
Recovery and Business Continuity Plan for its
identity system that covers:
a) Business continuity governance.

# A80000OFFICIAL
 A80000OFFICIAL #

A
b) Training requirements for recovery team members.
A
c) Recovery objectives and priorities.
d) Continuity strategies. A
A
e) Testing requirements and restoration procedures.
The Applicant MUST test their Disaster Recovery A
and Business Continuity Plan as part of initial
accreditation and at least once every 12 months
thereafter

The Applicant MUST use: A

• Australian Signals Directorate Approved
Cryptographic Algorithms (AACAs); and .).
• Australian Signals Directorate Approved
Cryptographic Protocols (AACPs),.).
tTo protect all Digital Identity Iinformation while
in transit and at rest

The Applicant MUST maintain a Cryptographic a) Cryptographic key lifecycle management over the A
Key Management Plan for their identity system lifecycle of the key (generation, delivery, renewal,
which covers: revocation, etc).

b) Details of the records that will be generated by the A

Applicant in relation to its use of keys and HhowHow
records will be maintained and audited.

c) The conditions under which compromised keys will A

be declared.

d) Maintenance of cryptographic components. A

e) Evidence of cryptographic evaluations undertaken. A

4.3 Personnel security

The Applicant MUST ensure the eligibility and A
suitability of its Personnel who have access to
information, ICT and assets which support the
operation of their Identity System

The Applicant MUST undertake pre- a) Verifying the identity of Personnel. A

employment screening on such Personnel,
including

# A80000OFFICIAL
 A80000OFFICIAL #

b) Confirming eligibility of such Personnel to work in A

Australia.
The Applicant MUST assess and manage the A
ongoing suitability of its Personnel.
The Applicant MUST ensure that separating A
Personnel have their access to the Applicant’s
resources withdrawn, including:

a) Physical facilities.
b) ICT systems. A
Prior to Personnel separation or transfer, the A
Applicant MUST ensure the CSO, or relevant
security advisor is advised of any proposed
cessation of employment resulting from
misconduct or other adverse reasons.

Where it is not possible to undertake required A

separation procedures, the Applicant MUST
undertake a risk assessment to identify any
security implications and take reasonable steps
to mitigate any identified risks.

The Applicant MUST implement physical A

security measures that minimise or remove the
risk of:
a) Harm to Individuals
A

b) Information and physical assets and resources being

made inoperable or inaccessible, or being accessed, used
or removed without appropriate authorisation.
The Applicant MUST protect its resources A
commensurate with the assessed business
impact level of their compromise, loss or
damage.

The Applicant MUST assess security risks and A

select appropriate containers, cabinets, secure
rooms and strong rooms to protect information
and assets.

The Applicant MUST dispose of physical assets a) resetting combination locks to factory settings; A
securely, including by;
Chapter 5 Usability Requirements
5.1 Usability requirements

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST demonstrate how Users A

can also use other available channels if needed,
without repetition or confusion.

The Applicant MUST demonstrate how Users A

with low digital skills can have readily available
access to Assisted Digital support.

The Applicant MUST demonstrate how its A

identity system is built with responsive design
methods to support common devices, browsers
and assistive technologies, including desktop
and mobile devices.

The Applicant MUST allow Users to provide A

feedback, seek assistance or otherwise resolve
disputes or complaints in relation to the
Applicant’s identity system.

The Applicant MUST create and maintain an A

individual end-to-end journey map for its
identity system.

The individual journey map MUST address each

alternative channel made available to a User to
complete a specific activity.

The Applicant MUST ensure information it A

provides to Users is available in multiple
accessible formats, including accessible online
formats (such as HTML), large print format, Easy
English, and braille (on request).

The Applicant MUST provide Users with A

uncomplicated ways to learn about its identity
system on digital channels.

5.2 Requirements for the identity proofing

journey
The Applicant MUST provide Users with
information about the entire identity
management process, including what to expect
in each step of the individual journey and what
they will need to do in order to complete each
step.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST provide Users with

information on technical requirements for using
the Applicant’s identity system (for example,
requirements for internet access, or access to a
mobile phone or webcam).

The Applicant MUST provide Users with a) the required Identity documents;
information on

b) whether each piece is mandatory; and

c) the consequences for not providing the complete set
of required documents.[1]
If a code or number is issued by the Applicant to
a User as part of the identity proofing process,
the Applicant MUST notify the User in advance
that they will receive a digital code or number,
how it will be issued and what to do with it.

The Applicant MUST advise the User on the

outcome of the Identity Proofing process.

If proofing is successful, the Applicant MUST

send the User confirmation regarding the
successful completion of Identity Proofing and
information on next steps.

If proofing is partially complete[1], the Applicant a) information and documents that will be deleted by
MUST inform the User of: the Applicant;

b) information and documents that will be retained by

the Applicant and the period for which such information
and documents will be retained; and

c) further information and documents to be provided

by the User in order to successfully complete the
relevant identity proofing process.

# A80000OFFICIAL
 A80000OFFICIAL #

If proofing is unsuccessful, the Applicant MUST a) an option to either:

provide the User with: i. continue with the proofing process using one or
more alternative channels; or
ii. not continue with the proofing process; and

b) details of the alternative channels under paragraph (a)

above and clear instructions on how to use such
alternative channels.

The Applicant MUST provide support to Users

who need assistance during the identity
proofing process.

The Applicant MUST provide support to Users

who do not have the technology or capacity to
create a Digital Identity. For example, by
providing support via a shopfront, a call centre
that is contactable via the National Relay
Service, or through a text-based support such as
an online chat window.

The Applicant MUST provide clear instructions

to a User on how they can update their Personal
information collected as part of the identity
proofing process

The Applicant MUST provide Users with relevant

information for the use and maintenance of
their Credential. For example, this may include
instructions for use, information on Credential
expiry, and what to do if the Credential is
forgotten, lost or stolen.

5.4 Usability testing

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST meet the requirements in 1) no interaction with a user when providing the services A
Section 5.4.2 (Usability Test Plans) and Section for which the Applicant is seeking accreditation; or
5.4.35 (Conduct Usability Testing) unless it can
demonstrate to the DTA that the Applicant has

2) limited interaction with a User when providing the A

services for which the Applicant is seeking accreditation,
including where the User is interacting with the
Applicant’s Identity System and has:

a. determined, through a risk assessment, that there is

a low risk that the failure to conduct the usability testing
will adversely impact the usability of the Applicant’s
Identity System; and
b. taken reasonable steps, including processes and
procedures, to:

i. obtain and record feedback from users about the

usability of the Applicant’s Identity System; and
ii. incorporate such feedback into the design of its
Identity System.

The Applicant MUST document, by way of a A

Usability Test Plan, how it will conduct usability
testing.

The Applicant’s Usability Test Plan MUST: a) Describe the test objectives, usability goals, and A
usability metrics that will be captured.

b) Describe the number of test participants, how they A

will be recruited and the cohort to which they belong.

c) Document the approach and the methodology used A

to conduct the tests to indicate what is working, pain
points and where improvements are needed.

d) Document representative scenarios for testing, on A

both desktop and mobile devices.

# A80000OFFICIAL
 A80000OFFICIAL #

e) Describe how findings from usability testing will be A

implemented.

f) Identify a range of representative Individuals to A

participate in the usability testing.

A
a) Individuals with disability.
b) Individuals over the age of 65. A
A
c) Individuals who use assistive technologies.
A
d) Individuals with low literacy.
A
e) Individuals from culturally and linguistically diverse
backgrounds
A

f) Individuals who are Aboriginal or Torres Strait Islander.

A
g) Individuals from regional and remote areas.
A
h) Individuals with older technology and low bandwidth
connections.
The range of representative Individuals MUST A
be from a diverse range of gender classifications

5.4.3 Conduct usability testing

The Applicant MUST use experienced User A
Researchers to conduct usability testing of its
Identity System in accordance with its usability
test plan. For the purpose of this requirement,
an experienced User Researcher is one who is
highly skilled in identifying individual needs,
conducting usability tests, and feeding insights
back to the product team

The Applicant MUST conduct usability testing on A

its Identity System as part of initial accreditation
and at least once every 12 months thereafter

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST conduct usability testing of A

its Identity System across all relevant
components of the Applicant’s Identity System,
in a production-like environment.

The Applicant MUST ensure that the User A

Researcher prepares a usability testing report
that documents the outcomes of its usability
testing, including test methodology(s), test
results, findings and recommendations

The Applicant’s Accountable Executive must a) for each recommendation in the report that is A
respond in writing to any recommendation accepted by the Applicant, the timeframe for
identified in the usability testing report implementation of the recommendation; and
including

b) for each recommendation in the report that is not A

accepted by the Applicant, the reasons for non-
acceptance and details of alternative actions (if any) to
be taken by the Applicant.

The Applicant MUST provide the outcomes of its A

usability testing to the DTA as part of initial
accreditation and annually thereafter as part of
the Annual Assessment.

5.5 Accessibility requirements

The Applicant’s Identity System MUST be A
presented in a clear and concise manner, using
plain language that is easy to understand and
accessible across all devices supported by the
Applicant’s Identity System.

For the Technical Testing that the Applicant is a)The exit criteria used when testing; A
required to complete under this section, it
MUST provide the DTA with the following:

b) The assumptions, limitations and dependencies A

relevant to the testing; and
c) The methodology used to conduct testing, including A
a description of the data used, and the environment
used to conduct testing

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST develop a Requirements A

Traceability Matrix (RTM) which maps the tests
completed to the TDIF requirements they are
being used to demonstrate compliance with.

The Applicant MUST provide the DTA with a a) Confirmation that the testing has been undertaken A
technical test report detailing the outcomes of and completed
the Technical Testing done under this section,
including:

b) The results of the testing, including any defects A

detected in testing, and whether these have been
addressed; and

c) Evidence that the exit criteria specified for testing A

has been met.

The Applicant MUST demonstrate through • Its fraud control mechanism for detecting Digital A
Technical Testing how its Identity System meets Identity Fraud Incidents (as per FRAUD-02-04-01).
the following TDIF requirements:

• Its fraud control mechanism to flag incidents of A

Digital Identity Fraud Incidents (as per FRAUD-02-04-02).

• Its security mechanism for detecting Cyber Security A

Incidents (as per PROT-04-02-07).

• Its security mechanism to flag Cyber Security A

Incidents (as per PROT-04-02-08).

• Its processes for audit trails and activity logging in A

applications (as per PROT-04-02-24).)

# A80000OFFICIAL
 A80000OFFICIAL #

• The activities and events logged (as per PROT-04-02- A

24a).

• The content included in activity logs (as per PROT- A

04-02-24b, PROT-04-02-24c, and PROT-04-02-24d and
PROT-04-02-24e).

The Applicant MUST demonstrate through • Its fraud control mechanism, which prevents new A
testing how its Identity System meets the registrations or updates to existing records from
following TDIF requirements: occurring if the fraud control mechanism indicates the
registration or update is fraudulent or suspected of
being fraudulent (as per FRAUD-02-04-02b).

• Its security mechanism, which prevents new A

registrations or updates to existing records from
occurring if the security mechanism indicates the
registration or update will create a Cyber Security
Incident (as per PROT-04-02-08b).

The Applicant MUST demonstrate

through Technical Testing the
functionality of all verification methods,
Identity Proofing Levels, identity lifecycle
management processes and any Step-
up processes supported by the
Applicant’s Identity System.

The Applicant MUST demonstrate

through Technical Testing the
functionality of all Credential Levels,
Credentials, Credential lifecycle
management processes and any Step-
Up processes supported by the
Applicant’s Identity System.

# A80000OFFICIAL
 A80000OFFICIAL #

7.1 Functional Assessment Requirements

The Applicant MUST ensure an Assessor a) a privacy impact assessment in accordance with A
conducts: ASSESS-07-05-01
b) a Privacy Assessment in accordance with ASSESS-07- A
05-03
c)a penetration test in accordance with ASSESS-07-06-02 A

d) a security assessment in accordance with ASSESS- A

07-06-01; and

# A80000OFFICIAL
 A80000OFFICIAL #

e) an accessibility assessment in accordance with A

ASSESS-07-07-01.
The Applicant MUST: a) define and prepare written instructions on the A
scope , objectives and criteria for each Functional
Assessment

[ In the context of the Security assessment this refers to

the Statement of Applicability.]

b) ensure such written instructions are consistent with A

the TDIF requirements
c) provide a copy of such instructions to the relevant A
Assessor prior to commencement of the Functional
Assessment; and

d) ensure that each Functional Assessment is A

conducted in accordance with such written instructions.

# A80000OFFICIAL
 A80000OFFICIAL #

7.2 Assessor Skills, experience and

independence
The Applicant MUST demonstrate to the DTA A
how the Assessors have relevant, reasonable,
and adequate experience, training and
qualifications to conduct the relevant Functional
Assessment.

The Applicant MUST demonstrate to the DTA • Are independent from the development and A
how the Assessors: operational teams of the Applicant’s Identity System

• Do not possess a conflict of interest in performing A

the Functional Assessment.

7.3 Functional Assessment Process

The Applicant MUST ensure Assessors have A
access to and consider all relevant evidence
provided by the Applicant to the DTA. This
includes any responses by the DTA to questions
which may have been asked.

The Functional Assessments MUST include: a)Documentation reviews. A

b)Interviews with key personnel. A

# A80000OFFICIAL
 A80000OFFICIAL #

c)A run through of the Applicant’s Identity System. A

If required by an Assessor or the DTA, the A
Applicant MUST take reasonable steps to permit
the Assessor to undertake a site visit to the
Applicant’s premises or other location where it
provides services in connection with its Identity
System.

The Applicant MUST ensure that each Assessor a)test results where applicable; A
prepares a report on the outcomes of the
relevant Functional Assessment that includes:

b) an assessment of whether the Applicant’s Identity A

System meets the applicable requirements of the TDIF

c)recommendations by the Assessor; and A

d) such other information required by the Applicant to A
enable it to comply with the TDIF and prepare the
Functional Assessment Report.

7.4 Functional Assessment Report

The Applicant MUST document the outcomes of a) A summary of the activities performed by the A
each Functional Assessment in a Functional Assessor during the Functional Assessment.
Assessment Report. The Applicant’s Functional
Assessment Report MUST include, for each
Functional Assessment:

b) The dates on which the Functional Assessment was A

commenced and completed.
c) Name, role (or position) and contact details of the A
relevant Accountable Executive and point of contact.

d) Qualifications and basis of independence for all A

Assessors used.
e) Names and versions of all documents used by the A
Applicant.

# A80000OFFICIAL
 A80000OFFICIAL #

f) City, state (and if applicable, country) of all physical A

locations used in the Applicant’s operations. This
includes data centre locations (primary and alternative
sites) and all other locations where general ICT and
business process controls that are relevant to the
Applicant’s operations are performed.

g)The test or evaluation methodology(s) used. A

h)The test or evaluation results. A
i) The Assessor’s opinion on whether the Applicant’s A
Identity System meets the applicable TDIF requirements,
including any requirements that could not be adequately
assessed due to access or timing issues.

j) Details of any identified instance of non-compliance A

with the TDIF requirements or any other risk identified
by the Assessor.

k) Any recommendation from the Assessor to address A

such non-compliance or risk.
The Applicant MUST: a) Assess each identified instance of non-compliance A
with the TDIF requirements covered by the Functional
Assessment report as per ASSESS-07-04-01

b)Assess any other risks identified by the Assessor A

c) Assign each instance of non-compliance and risk A

with a risk rating as set out in Appendix A: Risk Ratings;
and

d) Include in the Functional Assessment Report: A

i. Details of each such risk assessment

ii. A copy of the Applicant’s risk matrix; and
iii. Descriptions of the likelihood and risk categories
associated with the risk ratings assigned above.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant’s Accountable Executive MUST a) for each recommendation, risk and non-compliance A
respond in writing to each recommendation, that is accepted by the Applicant, the timeframe and
risk and non-compliance outlined in the details of the actions that the Applicant will take for
Functional Assessment Report including: implementation ; and

[Applicants must be aware of their ongoing obligations

regarding items on their Forward Work Plan. Detailed
information, including requirements and guidance can
be found in Section 2.8.1 Forward Work Plan of TDIF 07
Maintain Accreditation]

b) for each recommendation, risk and non-compliance A

that is not accepted by the Applicant, the reasons for
non-acceptance and details of alternative actions (if any)
to be taken by the Applicant.

Any recommendation, risk or non-compliance A

identified in ASSESS-07-04-03 MUST NOT meet
or exceed a Moderate, High or Extreme risk
rating for the Applicant’s Initial Assessment.

[NOTE : Applicants MUST be aware that a

Moderate, High or Extreme risk rating is grounds
for a failed Initial Assessment and that the DTA
will not grant TDIF accreditation until the items
required in ASSESS-07-04-03b are complete and
the DTA is satisfied that the risk is sufficiently
mitigated. Appendix A: Risk Ratings in this
document contains further details outlining the
conditions of each risk rating.]

If the risk rating meets or exceeds that outlined • it has implemented mitigations to address the A
above in ASSESS-07-04-03a, the Accredited recommendation, risk or non-compliance; and
Provider MUST confirm:

• The recommendation, risk or non-compliance has A

been reassessed and the residual risk rating is at Low or
Compliant; and

• The Accountable Executive has signed off and A

confirmed the implemented mitigation of the
recommendation, risk or non-compliance and the new
residual risk rating.

# A80000OFFICIAL
 A80000OFFICIAL #

7.5 Privacy Assessment

The Applicant MUST commission an Assessor to A
conduct a Privacy Impact Assessment on their
Identity System as part of Initial Accreditation.

[Applicants must be aware that a Privacy Impact

Assessment is required to be conducted on any
high-risk projects after Initial Accreditation as
per PRIV-03-03-01]

The Privacy Impact Assessment conducted a) Be undertaken early enough to influence the design A
under ASSESS-07-05-01 MUST: of the Identity System.
b)Reflect consultation with relevant stakeholders. A

c)Include a description of the proposed Identity System. A

d)Map the Identity System’s personal information flows. A

e) Include an analysis of risks of non-compliance with A

relevant privacy laws and TDIF privacy requirements.

f) Include an analysis of the impact of the project on A

the privacy of Individuals.
g) Include an analysis of whether privacy impacts are A
necessary or avoidable.
h) Include an analysis of possible mitigations to privacy A
risks.
i)Include recommendations A
The Applicant MUST commission an Assessor to a) address the recommendations (if any) included in A
conduct a Privacy Assessment (which is separate the Privacy Impact Assessment under ASSESS-07-05-01;
to and follows on from the PIA under ASSESS- and
07-05-01) as part of initial accreditation and
annually thereafter as part of the Annual
Assessment. The Privacy Assessment MUST:

b) includes a review and assessment of the Applicant’s A

compliance with the privacy requirements of the TDIF.

# A80000OFFICIAL
 A80000OFFICIAL #

7.6 Security Assessment and penetration test

The Applicant MUST commission an Assessor to a) include a review and assessment of the Applicant’s A
conduct a Security Assessment of its Identity compliance with the applicable Protective Security
System to identify security deficiencies as part Requirements; and
of initial accreditation and annually thereafter
as part of the Annual Assessment. The Security
Assessment must, at a minimum:

b) address the findings and recommendations (if any) A

from the Penetration testing under ASSESS-07-06-02.

The Applicant MUST commission an Assessor to a)its Identity System; and A

conduct a Penetration test of:
b) each major production release of software forming A
part of its Identity System following accreditation.

# A80000OFFICIAL
 A80000OFFICIAL #

7.7 Accessibility Assessment

The Applicant MUST commission an Assessor to • meets WCAG version 2.0 to the AA standard for A
conduct an Accessibility Assessment as part of web-based identity services
initial accreditation and annually thereafter as
part of the Annual Assessment, which MUST, at
a minimum, assess whether the Applicant’s
Identity System:

• meets WCAG version 2.1 to the AA standard for A

mobile-based identity services.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST have user terms in place a) A general acknowledgment by the User that their A
between the Applicant and each user that use of the Identity System provided by the Applicant is
include: governed by the User terms.

b) The scope of the User’s right to access and use the

Identity System must be consistent with the TDIF.
c) That the User is responsible for providing accurate A
Identity Documents and Attributes to the Applicant.

d) That the User is responsible for reporting A

unauthorised use of their Digital Identity or Credential to
the Applicant as soon as they become aware of it.

e) That the Applicant may suspend, cancel or A

terminate the User’s access to the Identity System at any
time.

f) That the Applicant may make changes to the User A

terms at any time without prior notice and if the User
terms are changed, the User’s continued use of the
Identity System will be subject to their acceptance of the
updated User terms.

# A80000OFFICIAL
A80000OFFICIAL #

g) If applicable, that the User’s access to the Identity A

System may be facilitated by third party services or
software and the provider may require, enable or
facilitate access to third party services or software.

h) That the User must comply with security A

requirements or instructions provided to them by the
Applicant.

i)The governing law of the User terms A

j)Provisions setting out a process for dispute resolution A

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST support identity proofing at

the level of Identity Proofing level 1 Plus or
above as described in Table 1 Identity Proofing
Levels

For each supported Identity Proofing Level, the

Applicant MUST implement it in accordance
with the requirements for that Identity Proofing
Level set out in Table 1 Identity Proofing Levels

b) removing all contents from physical assets and A

performing a visual inspection to confirm such removal;
and

c) sanitising or destroying ICT. A

The Applicant MUST NOT make a
representation, digitally or otherwise, that a
Digital Identity has achieved a particular Identity
Proofing Level unless the Applicant is accredited
to support that Identity Proofing Level, and the
User has achieved the requirements for that
Identity Proofing Level as set out in Table 1
below.

The Applicant MAY implement alternative

Identity Proofing processes to the requirements
set out in Table 1 to support Exceptional Use
Cases

# A80000OFFICIAL
 A80000OFFICIAL #

Before implementing an alternative identity a) perform an assessment of the risk associated with
proofing process under IDP-03-03-01, the implementing the alternative process and provide the
Applicant MUST: risk assessment to the DTA

b) Have in place mitigation methods and a plan to

manage the risks of an alternative identity proofing
process and provide the plan to the DTA; and

c) Receive permission from the DTA to perform an

alternative Identity Proofing process and assert that it is
equivalent to a particular Identity Proofing Level.

# A80000OFFICIAL
 A80000OFFICIAL #

If the Applicant supports Identity Proofing

Lifecycle Management , then the Applicant
MUST implement the following requirements
for the operation of Identity Proofing Lifecycle
Management.

If the Applicant supports Identity Proofing

Lifecycle Management , then the Applicant
MUST implement the following requirements
for the operation of Identity Proofing Lifecycle
Management.

The Applicant MUST allow Individuals to update

their Attributes held by the Applicant.

The Applicant MUST verify updates to the

Individual’s Identity prior to making changes to
the Individual’s Digital Identity. This includes any
status changes made to the Individual’s Digital
Identity (e.g. temporary suspension or
reactivation).

When requested to do so by an Authorised

Representative or a User, the Applicant MUST
either:
a) suspend the use of a Digital Identity for the
period requested; or
b) deactivate the digital identity.

The Applicant MUST confirm the legitimacy of

any request by a User to prevent the continued
use of their Digital Identity in accordance with
IDP-03-04-02, prior to preventing the continued
use of that Digital Identity.

The Applicant MUST notify the User that a

Digital Identity can no longer be used in
accordance with IDP-03-04-02 and the reason
why it can no longer be used (e.g. deactivated,
suspended, etc).

# A80000OFFICIAL
 A80000OFFICIAL #

If a Digital Identity is suspended in accordance

with IDP-03-04-02, the Applicant MUST provide
a process for a User to recover that Digital
Identity which MUST include a requirement for
the user to be reproofed to the highest Identity
Proofing Level as applied to the Digital Identity
before the suspension.

3.4.1 Expiry of a Digital Identity

If the Applicant has implemented Identity • require that the maximum time elapsed between
Proofing Lifecycle Management and subject to verifications of the link between the User and their
TDIF Req: IDP-03-04-03a, the Applicant MUST: Digital Identity is 5 years; and

• suspend a digital identity where the period between

verifications of the link between the user and the user’s
digital identity is longer than 5 years

To verify the link between the User and their • Require the User to complete the Identity Proofing
Digital Identity, the Applicant MUST either: process for the Identity Proofing level of the Digital
Identity and ensure that the Attributes presented can be
linked to the Attributes which comprise the Digital
Identity.

• Require the User to complete Biometric Verification

in accordance with the requirements in section 3.8 of
the TDIF 05 Role Requirements using a document whose
Attributes can be linked to the Attributes which
comprise the Digital Identity.

If a Digital Identity is suspended in accordance

with IDP-03-04-03, the Applicant MUST provide
a process for a User to recover that Digital
Identity by completing one of the two processes
outlined in IDP-03-04-03a for an appropriate
period of time after the Digital Identity has been
suspended.

If the Applicant supports Identity Proofing Step-

up for a User then the Applicant MUST
implement the following requirements for the
operation of Identity Proofing Step-up.

The Applicant MUST ensure that the User

achieves all the requirements of the higher
Identity Proofing Level.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST be accredited to conduct

an Identity Proofing Process at the higher
Identity Proofing Level.

The Applicant MUST ensure that the User can

prove ownership of their existing Digital Identity
by authenticating with their Credential prior to
commencing the Identity Proofing Step-Up
process.

When a User completes the Identity Proofing

Step-up process, the Applicant MAY send a
notification to the User.

The Applicant MUST limit disclosure of

Attributes to an Authoritative Source to
Attributes listed in Table 2 .

# A80000OFFICIAL
 A80000OFFICIAL #

Unless permission has been obtained under IDP-

03-07-03, or Attributes are being disclosed to an
Authoritative Source in accordance with IDP-03-
07-01, the Applicant MUST limit disclosure of
Attributes to the following Attributes:
• Identity Attributes (verified) listed in Table
2.
• Contact Attributes (validated) listed in Table
2.
• Identity System metadata listed in Table 2.
• Assumed Self-asserted Attributes listed in
Table 3.

3.8 Biometric Binding requirements

General Biometric Binding Requirements

If Biometric Binding is supported, then the
Applicant MUST implement the following
requirements for the operation of Biometric
Binding.

The Applicant MUST complete Biometric Binding •Online Biometric Binding as per Section 3.9.2, or
by performing either:
•Local Biometric Binding as per Section 3.9.3

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST consider fraud and security • Risks related to using Biometric Matching
risks, and the associated mitigation strategies algorithms and Presentation Attack Detection (PAD)
and treatments, related to performing Biometric systems to complete Biometric Verification and PAD
Binding when developing their Fraud Control
Plan and System Security Plan, including the
following risks (where applicable):

• Risks related to using Assessing Officers to complete

Local Biometric Binding.
• Risks related to the capture, temporary storage, and
deletion of Biometric Samples.
• Risks related to the Biometric Matching process the
Applicant implements (i.e. Source, Technical, or Manual
Face Comparison).

• Risks related to potential and known threats and

attacks to the Biometric Capability.
Evidence of the Applicant’s consideration of
applicable risks outlined in IDP-03-08-03,
associated mitigation strategies and treatments,
the Applicant’s risk framework, and any
supporting evidence MUST be provided to the
DTA.

The Photo ID used in the Biometric Matching

Process MUST undergo Source Verification.

Where the Photo ID is a foreign passport, the

Applicant MUST perform a DVS check to ensure
that the document and identity attributes of the
foreign passport correspond to the document
and identity attributes of a current Australian
visa.

The Applicant MUST log information associated

with each Biometric Binding transaction, as per
PROT-04-02-22a, including the specific
Biometric Matching method utilised

# A80000OFFICIAL
 A80000OFFICIAL #

If the Applicant is required to have a Biometric a) it has engaged a Biometric Testing Entity to conduct
Testing Entity test their Biometric Capability by the biometric testing
either IDP-03-08-12 or IDP-03-08-18, then the
Applicant MUST provide evidence that:

NOTE: an entity accredited to perform PAD

testing according to ISO/IEC 30107-3 and/or
biometric performance testing according to
ISO/IEC 19795-2 under the National Voluntary
Laboratory Accreditation Program (NVLAP)
coordinated by National Institute of Standards
and Technology (NIST) would meet the above
requirements for each kind of testing
respectively. Further information about
Biometric Testing Entities is also available in
TDIF 05A Role Guidance.

b) the Biometric Testing Entity has employed

appropriately experienced personnel with a background
in biometric testing to conduct the biometric testing

c) the Biometric Testing Entity is a certified ISO 17025

laboratory
d) the Biometric Testing Entity has a policy for working
with human test subjects approved by a relevant
national body

e) The Biometric Testing Entity has established test

methods for:

i. PAD testing informed by ISO/IEC 30107-3, if

performing testing relating to IDP-03-08-12 and all its
parts, and
ii. (if applicable) Biometric matching algorithm
accuracy testing informed by ISO/IEC 19795-2, if
performing testing relating to IDP-03-08-18 and all its
parts.

f) The Biometric Testing Entity is an independent

entity with no conflict of interest, perceived or
otherwise.

# A80000OFFICIAL
 A80000OFFICIAL #

3.8.2 Online Biometric Binding

If Online Biometric Binding is supported, then
the Applicant MUST implement the following
requirements for the operation of Online
Biometric Binding.

To complete Online Biometric Binding the •Technical Biometric Matching as per Section 3.9.4
Applicant MUST capture an Acquired Image and
perform at least one of the following:

•Source Biometric Matching as per Section 3.9.5

The Applicant MUST create an Image Quality
Profile of the Acquired Image and apply a
quality threshold that this image MUST pass
prior to being used for Biometric Matching.

The method for generating the Acquired

Image’s Image Quality Profile MUST be
informed by characteristics of biometric image
quality described by ISO 29794-5.

The Applicant MUST provide to the DTA the

characteristics used in generating the Image
Quality Profile as a part of the initial
Accreditation.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST include automated quality

controls and appropriate user-interface
instructions that direct a User to provide an
image that meets the Acquired Image’s Image
Quality Profile.

When performing Online Biometric Binding, the

Applicant MUST incorporate PAD technology at
the point of capture of the Acquired Image.

The Applicant MUST complete the capture of

the Acquired Image and PAD processes as part
of the same process before submission of the
Acquired Image to Biometric Matching.

The Applicant MUST employ PAD technology

based on data captured by both the data
capture subsystem and through system level
monitoring, as described by ISO 30107-1

The Applicant MUST include Liveness Detection

as part of PAD.
The Applicant MUST ensure their PAD
technology is tested according to ISO 30107-3
by a Biometric Testing Entity .

[NOTE: Applicants who must meet this

requirement should be familiar with obligations
for retesting PAD technology as described in
TDIF 07 Maintain Accreditation.]

The Applicant MUST provide the Biometric

Testing Entity’s report with the results of the
testing conducted under IDP-03-08-12 to the
DTA .

The PAD testing carried out by the Biometrics

Testing Entity MUST include Presentation Attack
Instrument Species to address potential
Presentation Attack threats as informed by the
risk assessment completed as part of IDP-03-08-
03 and, if applicable, ANNUAL-03-08-03a.

# A80000OFFICIAL
 A80000OFFICIAL #

The PAD testing MUST be performed on a

system that incorporates all hardware and
software involved in the Biometric Binding
process, including the PAD technology and
Biometric Matching (where applicable).

The PAD technology MUST be tested by a

Biometric Testing Entity with configurations and
settings that align to the Applicant’s operational
environment.

The PAD testing MUST calculate and record the

completed PAD evaluation and corresponding
results for each Presentation Attack Species as
described in ISO 30107-3.

The PAD testing MUST include at least 6 Level A

Presentation Attack Instrument Species and at
least 6 Level B Presentation Attack Instrument
Species.

The PAD testing MUST include a minimum of 10

individuals.

For each Presentation Attack Instrument

Species, at least one Presentation Attack
Instrument MUST be created for a minimum of
3 individuals.

All utilised Attack Instrument Species (PAI

Species) MUST have an attack presentation
classification error rate (APCER) of 0%.
If the Applicant’s reported APCER for any PAI
Species does not meet these requirements, then
a risk-based justification for failures MUST be
provided to the DTA, who will make a
qualitative assessment of whether the PAD
technology is fit for purpose.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Local Biometric Binding

If Local Biometric Binding is supported, then the
Applicant MUST implement the following
requirements for the operation of Local
Biometric Binding

Local Biometric Binding is performed when an • Capturing an Acquired Image and performing
Individual is in the physical presence of an either:
Assessing Officer, and MUST be achieved by the o Technical Biometric Matching as per Section 3.9.4
Assessing Officer performing one or more of the o Source Biometric Matching as per section 3.9.5
following biometric matching processes:

•A Manual Face Comparison as per section 3.9.7

While performing Local Biometric Binding, the
Applicant MUST restrict access to Biometric
Information and any aspects of the Biometric
Capability to Assessing Officers.

If an Acquired Image is being captured as part of

Local Biometric Binding, then the Applicant
MUST develop and apply an Image Quality
Profile in accordance with IDP-03-08-10 to IDP-
03-08-10c.

The Applicant MUST only undertake Local

Biometric Binding at a suitable locationas
identified in the Applicant’s Fraud Control Plan
and System Security Plan.

# A80000OFFICIAL
 A80000OFFICIAL #

3.8.4 Technical Biometric Matching

If Technical Biometric Matching is supported,

then the Applicant MUST implement the
following requirements for the operation of
Technical Biometric Matching.

# A80000OFFICIAL
 A80000OFFICIAL #

When performing Technical Biometric Matching,

the Applicant MUST verify the authenticity of
the image read from the Photo ID using
Technical Verification.

The Applicant MUST only process Photo IDs

through Technical Biometric Matching that are
government issued, and only if the digital
signature for the image read from the Photo ID
can be validated by Technical Verification.

The Applicant MUST use a Biometric Matching

algorithm to perform one-to-one verification
matching between the Acquired Image and the
image read from the Photo ID.

The Applicant MUST ensure their Biometric

Matching algorithm is tested by a Biometric
Testing Entity to determine the Failure to Enrol
rate (if applicable), Failure to Acquire Rate, False
Match Rate and False Non-match Rate of the
Biometric Capability as per the testing and
reporting specifications described in ISO/IEC
19795-2.

The Biometric Matching algorithm MUST be

tested by a Biometric Testing Entity with
operational configurations and settings that
align to the Applicant’s operating environment.

The Biometric Matching algorithm MUST be

tested by a Biometric Testing Entity using
representation from a diverse age, gender, and
ethnicity demographics that considers possible
Users of the Applicant’s system.

The Biometric Matching algorithm testing MUST

establish, with a minimum 90% confidence
interval, that the Biometric Matching algorithm
achieves a false match rate (FMR) of not more
than 0.01% and a false non-match rate (FNMR)
of not more than 3%, as described in ISO/IEC
19795-9.

# A80000OFFICIAL
 A80000OFFICIAL #

As a part of the initial TDIF Accreditation Process

the Applicant MUST provide the report to the
DTA from the Biometric Testing Entity outlining
that the Applicant’s Biometric Matching
algorithm has been suitably tested as per the
testing and reporting specifications described in
ISO/IEC 19795-2.

# A80000OFFICIAL
 A80000OFFICIAL #

3.8.5 Source Biometric Matching

If Online Biometric Binding with Source

Biometric Matching is supported, then the
Applicant MUST implement the following
requirements for the operation of Source
Biometric Matching.

To perform Source Biometric Matching, the

Applicant MUST provide the Acquired Image
and other information about the Photo ID in
accordance with the instructions specific to the
Photo ID Authoritative Source capable of
performing Biometric Matching to verify the
User’s Acquired Image biometrically matches
the corresponding image stored in the Photo ID
Authoritative Source .

[A list of PhotoID Authoritative Sources capable

of performing Source Biometric Matching is
available in TDIF 05A Role Guidance.]

The Applicant MUST provide evidence that end-

to-end testing has taken place with the Photo ID
Authoritative Source and that their Biometric
Capability can meet any operating standards set
by the Photo ID Authoritative Source.

# A80000OFFICIAL
 A80000OFFICIAL #

3.8.6 Manual Face Comparison

If Manual Face Comparison is used for any
Biometric Binding processes, then the Applicant
MUST implement the following requirements
for the operation of Manual Face Comparison.

If Manual Face Comparison is attempted using a

Photo ID that can undergo Technical Verification
for authenticity, then Technical Verification
MUST be attempted.

The Applicant MUST ensure that Assessing

Officers performing Manual Face Comparison
receive awareness training, as part of Initial
Accreditation and annually thereafter, in
accordance with the guidance provided by the
latest version of the Facial Identification
Scientific Working Group (FISWG), Guide for
Facial Comparison Awareness Training of
Assessors.

The Applicant MUST provide Assessing Officers

with an up-to-date reference card outlining
practical steps and guidance when performing
Manual Face Comparison.

The Applicant MUST provide evidence of the

Manual Face Comparison training materia ls and
reference cards received by each Assessing
Officer.

[A copy of the training materials will be

requested by the DTA as part of initial
accreditation and annually thereafter as part of
the Annual Assessment under TDIF: 07-Annual
Assessment.]

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST design and implement

procedures to detect fraudulent activities by
Assessing Officers performing Manual Face
Comparison. These procedures MUST be
included in the Fraud Control Plan.

The Applicant MUST design and implement

quality control and quality assurance
procedures for Manual Face Comparison
decisions made by Assessing Officers as part of
initial accreditation and annually thereafter. The
Applicant MUST include these procedures in
their risk assessment for Biometric Binding
processes.

The Assessing Officer MUST only perform

Manual Face Comparison using an original,
physical Photo ID presented in-person by the
Individual.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

For each supported Credential Level, the

Applicant MUST ensure that when a credential
level is asserted as a result of an authentication
event, that the authentication event met all the
requirements of that credential level as
described in Table 4.

# A80000OFFICIAL
 A80000OFFICIAL #

When processing requests from an Individual to

establish or change a Memorised Secret, the
Applicant MUST compare the prospective secret
against a list that contains secrets known to be
commonly used, expected or compromised.

If the Applicant disallows a chosen Memorised a) advise the Individual that they need to select a
Secret based on its appearance on the list different secret
described in CSP-04-02-01d , the Applicant
MUST:

b) Provide the reason for rejection; and

c) Require the Individual choose a different

Memorised Secret.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MAY offer guidance to the

Individual, such as a password-strength meter,
to assist the Individual in choosing a strong
memorised secret. This is particularly important
following the rejection of a memorised secret
on the above list as it discourages trivial
modification of listed (and likely very weak)
memorised secrets.

The Applicant MAY permit Individuals to use the

“paste” functionality when entering a
memorised secret. This facilitates the use of
password managers, which are widely used and,
in many cases, increase the likelihood that
Individuals will choose stronger memorised
secrets.

To assist the Individual in successfully entering a

memorised secret, the Applicant MAY offer an
option to display the secret — rather than a
series of dots or asterisks — until it is entered.
This allows the Individual to verify their entry if
they are in a location where their screen is
unlikely to be observed.

The Applicant MAY permit the Individual’s

device to display individual entered characters
for a short time after each character is typed to
verify correct entry. This is particularly
applicable on mobile devices.

The Applicant MUST use Australian Signals

Approved Cryptographic Algorithms (AACAs)
and an authenticated protected channel when
requesting memorised secrets to provide
resistance to eavesdropping and Man-in-the-
Middle (MitM) attacks.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST store memorised secrets in

a form that is resistant to offline attacks.

Memorised secrets MUST be salted and hashed

using a suitable one-way key derivation
function.

The salt MUST be at least 32 bits in length and

be chosen arbitrarily so as to minimise salt value
collisions among stored hashes.

Both the salt value and the resulting hash MUST

be stored for each Individual who uses
memorised secrets.

W hen an Individual is authenticating, the

Applicant MUST prompt the Individual for the
next secret from their Credential (e.g. the next
numbered secret) or a specific secret.

The Applicant MUST store Look-up Secrets in a a)Look-Up Secrets are hashed using an AACA; and
form that is resistant to offline attacks by
ensuring that:

b) Look-Up Secrets that have less than 112 bits of

entropy are salted and hashed using an AACA with a salt
value of at least 32 bits in length which is arbitrarily
chosen.

The Applicant MUST store both the salt value

and the resulting hash for each look-up secret.

# A80000OFFICIAL
 A80000OFFICIAL #

For Look-up Secrets that have less than 64 bits

of entropy, the Applicant MUST implement a
Rate-limiting mechanism that effectively limits
the number of failed Authentication attempts
that can be made on the Individual’s Digital
Identity account.

The Applicant MUST use AACAs and an

Authenticated Protected Channel when
requesting Look-up Secrets in order to provide
resistance to eavesdropping and MitM attacks.

The out-of-band device MUST establish a

separate channel with the Applicant to retrieve
the out-of-band secret or Authentication
Request.

The out-of-band device MUST uniquely

authenticate itself in one of the following ways
when communicating with the Applicant:
• Establish an Authenticated Protected
Channel to the Applicant that:
a) Uses an AACA;
b) stores the cryptographic key in suitably
secure storage available to the Credential
application (e.g. Keychain storage, secure
element etc.).
• Only where a secret is being sent from the
Applicant to the out-of-band device via the
public switched telephone network,
authenticate to a public mobile telephone
network using a SIM card or equivalent that
uniquely identifies the device.

# A80000OFFICIAL
 A80000OFFICIAL #

If the out-of-band device sends an approval • The device MUST accept transfer of the secret from
message over the secondary communication the primary channel, which it MUST send to the
channel — rather than by the Individual Applicant over the secondary channel to associate the
transferring a received secret to the primary approval with the Authentication transaction. The
communication channel — it MUST do one of Individual MAY perform the transfer manually or use a
the following: technology such as a barcode or QR code to effect the
transfer .

• The device MUST present a secret received via the

secondary channel from the Applicant and prompt the
Individual to verify the consistency of that secret with
the primary channel, prior to accepting a yes/no
response from the Individual. It MUST then send that
response to the Applicant.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST consider risks when

developing their Fraud Control Plan and System
Security Plan, associated with device swap, SIM
change, number porting or other abnormal
behaviour before using the PSTN to deliver an
out-of-band Authentication secret.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

•a separate Key MUST be used for identifying the device

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST validate the signature or

other information used to prove CSP-
impersonation Resistance.

AACAs MUST be used to establish CSP-

impersonation Resistance.

# A80000OFFICIAL
 A80000OFFICIAL #

4.3.8 Authentication intent

# A80000OFFICIAL
 A80000OFFICIAL #

4.3.9 Restricted Credentials

If, at any time, the Applicant determines that a

Credential is resulting in an unacceptable risk to
any party, then they MUST, as soon as practical
after the determination has been made, prevent
continued use of that Credential. Such
Credentials are referred to as Restricted
Credentials.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Subject to the requirements in section 4.4.1, the

Applicant MAY, where practical, accommodate
the use of a User-provided Credential to relieve
the burden to the User of managing a large
number of Credentials.

The Applicant MUST verify the Credential type

of a User-provided Credential (e.g. Single-factor
Cryptographic Device vs. Multi-factor
Cryptographic Device) so the Applicant can
determine compliance with requirements at
each CL.

If the Applicant issues Credentials which expire,

the Applicant MUST bind an updated Credential
a reasonable amount of time before an existing
Credential’s expiration.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

The Session MAY be continued through a re-

authentication in accordance with the
requirements in section 4.9.

# A80000OFFICIAL
 A80000OFFICIAL #

If the Applicant supports a User to Step-Up the

Credential Level that can be asserted as a result
of an authentication event to a higher
Credential Level supported by the Applicant,
then it MUST implement the following
requirements for the operation of Step-Up for
all Credential Levels.

The Applicant MUST be accredited to assert the

higher Credential Level.
If a credential is added to the user’s digital a) is capable of meeting all the applicable
identity account as a result of Step-up, the requirements of the higher credential level
Applicant MUST ensure that the new Credential:

b) is a type of Credential supported by the Applicant’s

Identity System; and
c)meets all the requirements for that credential type

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST ensure that an Individual

can prove ownership of their existing Digital
Identity by authenticating with their Credential
to their account prior to commencing the
Credential Step-Up process.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Where the Applicant manages Attributes on

behalf of an Authoritative Source, it MUST
provide evidence of this arrangement to the
DTA.

[Evidence of this arrangement will be requested

by the DTA as part of initial accreditation and
annually thereafter as part of the Annual
Assessment.]

The Applicant MUST take reasonable measures

to prevent the continued use of an Attribute
(e.g. suspension, deactivation) when requested
to do so by a User, Authorised Representative or
Authoritative Source.

The Applicant MAY support issuing or linking

multiple Attributes and Attribute Classes to an
Individual.

The Applicant MAY support issuing or linking

multiple Attributes relating to the same entity to
an Individual.

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MAY support issuing or linking

multiple Individuals to the same Attribute.

In accordance with PRIV-03-09-03, the Applicant •Timestamp

MUST maintain the following information as
part of its Audit Logs:
• Where an entity records consent on behalf of an IdP
or ASP, the duration of Consent. (including any time limit
on the consent)

• The name of the Relying Party that requested the

relevant attributes.

• The Identifier that identifies the User at the Relying

Party authorised to receive the Attributes

• Identity Service Provider/Attribute Service Provider

from which the Attributes were sourced

• The Identifier that identifies the Identity at the

source of the Attributes
•Name of any Attribute or Attribute set authorised

• Consent decision. This may be “grant”, “deny”, or

“ongoing”

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST NOT store Attributes of the

Individual after the Individual’s session at the
User Dashboard has been terminated.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

The Applicant MUST include a statement in their

privacy notices advising that the Applicant may
provide the Individual’s system metadata to the
Oversight Authority to enable it to perform the
Oversight Authority’s functions related to fraud
management.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

TDIF 07 - Maintain Accreditation

2.1 Accredited Provider Ongoing Obligations

# A80000OFFICIAL
 A80000OFFICIAL #

If the DTA requests evidence that an Accredited

Provider continues to meet a TDIF requirement,
the Accredited Provider MUST provide this
evidence as part of its Annual Assessment.

Accredited Providers MUST meet any new or NOTE: If an Accredited Provider does not provide the
amended requirements in the newest version of information required by ANNUAL-02-01-01 or ANNUAL-
the TDIF, published on the TDIF website, within 02-01-01a by their Annual Assessment date, the DTA will
12 months of that version being published. then assess whether the Accredited Provider has failed
These requirements will be assessed as part of to meet one or more of their ongoing obligations. If the
the Accredited Provider’s Annual Assessment DTA finds that the Accredited Provider has failed to
meet their obligations, this will result in a finding of non-
compliance with the TDIF. A finding of non-compliance
may result in a failed Annual Assessment. A failed
Annual Assessment may result in suspension or
termination of accreditation.

If the DTA makes a finding that the Accredited a) a risk rating assigned to each instance of non-
Provider has failed to comply with ANNUAL-02- compliance as set out in Appendix A; and
01-01 and ANNUAL-02-01-01a, the DTA will
advise the Accredited Provider of the non-
compliance in writing and direct it to submit
evidence to meet the relevant requirements.
The Accredited Provider MUST provide to the
DTA in writing:

b) Include details of:

i. each such risk assessment;

ii. A copy of the Accredited Provider’s risk matrix
iii. and description of the likelihood and risk categories
associated with the risk ratings assigned above.

Any risks or recommendations identified in

ANNUAL-02-01-02 MUST NOT:
• meet or exceed a High or Extreme risk
rating for the Accredited Provider’s Annual
Assessment.

# A80000OFFICIAL
 A80000OFFICIAL #

If the risk rating meets or exceeds that outlined a) it has implemented mitigations to address the
above in ANNUAL-02-01-02a, the Accredited recommendation, risk or non-compliance
Provider MUST confirm:

[NOTE: If the Accredited Provider cannot meet

ANNUAL-02-01-02a, then this will result in a
failed Annual Assessment. Where the DTA
makes a finding that an Accredited Provider has
failed an Annual Assessment, the DTA will make
a decision whether the Accredited Provider’s
accreditation will be suspended or terminated.]

b) The risk, recommendation or non-compliance has

been reassessed and the residual risk rating is at
Moderate or below; and

c) The Accountable Executive has signed off and

confirmed the implemented mitigation of the risk and
the new residual risk rating.

7.2.1.1 Changes to an Accredited Provider's

Identity System
If an Accredited Provider’s Identity System • Significant impacts to the Accredited Provider’s
releases a Major Production Release, or is protective security arrangements
changed or impacted in such a manner, that • Serious or repeated privacy breaches (including of
results in: TDIF requirements or the Australian Privacy Principles)
• Material changes to the Accredited Provider’s risk
exposure where such exposure results in the Applicant
identifying High or Extreme risks (as per Appendix A –
Risk Ratings or the Accredited Provider’s own equivalent
risk framework)
• A significant change to the Accredited Provider’s
Identity System that significantly impacts on the agreed
and implemented system architecture and System
Security Plan
• significant changes to the threats or risk faced by
the Accredited Provider’s Identity System, or
• TDIF requirements that were not previously
applicable to an Accredited Provider’s Identity System
becoming applicable

# A80000OFFICIAL
 A80000OFFICIAL #

then the Applicant MUST inform the DTA of changes to

their Identity System as part of its Annual Assessment
and any provisions as stipulated by the TDIF Agreement
(MOU).

[The DTA will decide, and provide in writing, whether the

Applicant will need to formally apply for a Variation in
Accreditation or, depending on the severity of risks or
impacts to the Accredited Provider’s Identity System,
whether the accreditation should be suspended or
terminated]

7.2.1.2 Variations in Accreditation

If an Accredited Provider seeks to vary its
accreditation, it MUST complete a TDIF
Application Letter as per requirements ACCRED-
03-01-01 to ACCRED-03-01-05 and the
requirements below.

The Accredited Provider MUST submit a

Requirements Traceability Matrix and identify
all applicable TDIF requirements that may be
impacted by the variation of accreditation.

NOTE: the DTA will assess the Requirements

Traceability Matrix and may identify additional
applicable requirements that an Accredited
Provider must submit evidence for.

The Accredited Provider MUST include and

submit to the DTA a review of the applicable
evidence required for variation of accreditation,
as outlined in Appendix C.

An Accredited Provider MAY use Alternative

Assessment Reports as per requirements
ANNUAL-02-03-01 to ANNUAL-02-03-01b to
meet the TDIF requirements.

If an Accredited Provider submits an Alternative

Assessment Report as per ANNUAL-02-01-07,
then it MUST cover the changes to the
Accredited Provider’s Identity System.

2.2 Annual Assessment Requirements

# A80000OFFICIAL
 A80000OFFICIAL #

The Accredited Provider MUST meet all-

obligations set out in the TDIF Agreement
(MOU) and provide evidence of such to the DTA.

The Accredited Provider MUST ensure that all In order for the DTA to review an Accredited Provider’s
Annual Assessment requirements are Annual Assessment materials, the Accredited Provider
completed by the anniversary of its initial should submit its Annual Assessment evidence at least
accreditation date. two months prior to the anniversary of its initial
accreditation date
[NOTE: If the Accredited Provider cannot meet
ANNUAL-02-02-01 and ANNUAL-02-02-02, then
this will result in a failed Annual Assessment.
Where the DTA makes a finding that an
Accredited Provider has failed an Annual
Assessment, the DTA will make a decision
whether the Accredited Provider’s accreditation
will be suspended or terminated]

Before the anniversary of the Accredited a) each Functional Assessment report prepared under
Provider’s initial accreditation date, the ANNUAL-02-07-04.
Accredited Provider MUST provide the DTA with
a full and unredacted copy of:

[An executive summary or redacted version of

this information is insufficient to meet this
requirement.

The DTA will acknowledge receipt of the Annual

Assessment Reports, supporting documentation
and evidence and conduct a review of the
documents. Once this review is completed, the
DTA will advise the Accredited Provider of its
acceptance of the reports and evidence and
whether it meets the applicable TDIF
requirements. This includes whether the
proposed remediation actions and timings, are
acceptable. ]

b) Where applicable, the Accredited Provider’s Annual

Usability Test Report conducted in accordance with
ANNUAL-02-04-02

c) the Accredited Provider’s Annual Assessment

Reports prepared in accordance with ANNUAL-02-08-01

# A80000OFFICIAL
 A80000OFFICIAL #

d) each response from the Accredited Provider’s

Accountable Executive under ANNUAL-02-08-02a.
e) All applicable evidence required as part of the
review under Section 2.9 Evidence Review Requirements
and listed in Appendix B.

f) An annual Qualifying Attestation Letter in

accordance with the requirements set out in ANNUAL-
02-02-04.

7.2.2.1 Qualifying Attestation Letter

Once the Accredited Provider has achieved all • The name, role/position and contact details of the
applicable TDIF Annual Assessment Accountable Executive
requirements, it MUST submit a Qualifying
Attestation Letter signed by the Accredited
Provider’s Accountable Executive that contains
the following information to support the
Accredited Provider’s claim that its operations
remain in accordance with TDIF requirements:

• A statement that the Accredited Provider’s Identity

System complies with the TDIF requirements and the
TDIF Agreement (MOU)

• The version of the TDIF the Accredited Provider is

assessed and accredited under for the relevant Annual
Assessment

• a statement confirming it has provided the DTA with

all relevant documents, materials and evidence to the
accreditation as part of its review

• A statement confirming that the evidence provided

is a fair and accurate representation of its Identity
System

• If the Accredited Provider has risks or non-

compliances identified in its Annual Assessment reports,
then the Qualifying Attestation Letter MUST contain a
summary of these risks, implementation dates and any
further information as per ANNUAL-02-08-02 to
ANNUAL-02-08-04a

Alternative Assessment Reports

# A80000OFFICIAL
 A80000OFFICIAL #

If an Accredited Provider requests that an

Alternative Assessment should be considered by
the DTA as a substitute for a relevant Functional
Assessment or as evidence to meet other TDIF
requirements, then it MUST submit the
Alternative Assessment Report as per the
following requirements.

Any request made to the DTA to consider a) Which Functional Assessment or TDIF requirements
Alternative Assessment Reports MUST include: it is provided as evidence for

b) A rationale for why the Alternative Assessment

Report should be considered as equivalent to a
Functional Assessment or as appropriate evidence to
meet the TDIF Requirements, and

c) A Requirements Traceability Matrix, which sets out:

i. each TDIF requirement the Alternative Assessment

Report addresses,
ii. a reference to where the Alternative Assessment
Report addresses that TDIF requirement (e.g. page
number or section), and
iii. any supporting statements for why that section of
the Alternative Assessment Report addresses the TDIF
requirements (if needed).

The Alternative Assessment Report MUST have

been produced no more than 12 months prior
to the date it is provided to the DTA and MUST
cover the latest Major Production Release of the
Applicant’s Identity System (if any) at the time
of the Accredited Provider’s Annual Assessment.

# A80000OFFICIAL
 A80000OFFICIAL #

2.4 Annual Functional Assessment and Usability Testing

The Accredited Provider must ensure an a) a Privacy Assessment in accordance with ANNUAL-
Assessor conducts the following Functional 02-09-05;
Assessments by the anniversary of the
Accredited Provider’s accreditation date each
year:

b) a Security Assessment in accordance with ANNUAL-

02-09-06

c) a Penetration Test in accordance with ANNUAL-02-

09-07; and

d) an Accessibility Assessment in accordance with

ANNUAL-02-09-08.

Subject to ANNUAL-02-04-02a or ANNUAL-02-04-02b,

the Accredited Provider MUST ensure a user researcher
conducts a Usability Test in accordance with ANNUAL-
02-09-09 by the anniversary of the Accredited Provider’s
accreditation date each year.

ANNUAL-02-04-02 does not apply if the

Accredited Provider has demonstrated to the
DTA that the Accredited Provider has no
interaction with a user when providing the
services for which the Accredited Provider is
accredited for.

# A80000OFFICIAL
 A80000OFFICIAL #

ANNUAL-02-04-02 does not apply if the 1. either:

Accredited Provider has demonstrated to the
DTA that the Accredited Provider: a) has limited interaction with a User when providing
the services for which the Applicant is accredited,
including where the User is interacting with the
Accredited Provider’s Identity System; or
b) has assessed and can demonstrate that there have
been no relevant changes to the Accredited Provider’s
Identity System in the 12 months prior to the date of the
annual assessment; and

2. has determined, through a risk assessment, that

there is a low risk that the failure to conduct the
usability testing will adversely impact the usability of the
Accredited Provider’s Identity System; and

3. the Accredited Provider has taken reasonable steps,

including processes and procedures, to:

a) obtain and record feedback from Users about the

usability of the Accredited Provider’s Identity System;
and
b) incorporate such feedback into the design of its
Identity System.

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

7.2.5 Skills, experience and independence of

Assessors and User Researcher
The Accredited Provider MUST demonstrate to
the DTA how each Assessor and User
Researcher has relevant, reasonable and
adequate experience, training and qualifications
to conduct the relevant Functional Assessment.

The Accredited Provider MUST demonstrate to a) Are independent from the development and
the DTA how the Assessors : operational teams of the Accredited Provider’s Identity
System.

b) Do not possess a conflict of interest in performing

the Functional Assessment on the Accredited Provider’s
Identity System

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

7.2.6 Annual Assessment schedule

Annual Assessments that occur during: a) Even calendar years (i.e. 2022, 2024, 2026 etc)
require that Functional Assessments MUST be
undertaken by Assessors who are external to the
Accredited Provider’s organisation.

b) Odd calendar years (i.e. 2023, 2025, etc) MAY be

undertaken by Assessors who are external to the
development and operational teams of the Accredited
Provider’s Identity System.

7.2.6 Annual Assessment schedule

# A80000OFFICIAL
 A80000OFFICIAL #

The Accredited Provider MUST ensure Assessors

and the User Researcher(s) have access to and
consider all relevant evidence provided by the
Accredited Provider to the DTA. This includes
any responses by the DTA to questions which
may have been asked.

As part of the Functional Assessments, the a)Documentation reviews.

Assessors MUST undertake the following
activities

b)Interviews with key Personnel.

c) A run through of the Accredited Provider’s Identity

System.

If required by an Assessor or the DTA, the

Accredited Provider MUST take reasonable
steps to permit the Assessor to undertake a site
visit to the Accredited Provider’s premises or
other location where it provides services in
connection with its Identity System.

The Accredited Provider MUST ensure that each a)test results where applicable;
Assessor prepares a report on the outcomes of
the relevant Functional Assessment that
includes:

b) an assessment of whether the Accredited Provider’s

Identity System meets the applicable requirements of
the TDIF;

c)recommendations by the Assessor; and

d) such other information required by the Accredited

Provider to enable the Accredited Provider to comply
with the TDIF and prepare the Annual Assessment
Report.

2.8 Annual Assessment Report

The Accredited Provider MUST document the a) A summary of the activities performed by the
outcomes of each Functional Assessment in an Assessor during the Functional Assessment.
Annual Assessment Report, which MUST include
the following:

# A80000OFFICIAL
 A80000OFFICIAL #

b) The dates on which the Functional Assessments

were commenced and completed

c) Name, role (or position) and contact details of the

relevant Accountable Executive and point of contact.

d) Qualifications and basis of independence for all

Assessors used.

e) Names and version numbers of all documents used

by the Accredited Provider.

f) City, state and (if applicable) country of all physical

locations used in the Accredited Provider’s operations.
This includes data centre locations (primary and
alternative sites) and all other locations where general
ICT and business process controls that are relevant to
the Accredited Provider’s operations are performed.

g)The test or evaluation methodology(s) used.

h)The test or evaluation results and findings.

i) The opinion of the Assessor or user researcher (as

applicable) on whether the Accredited Provider’s
Identity Facility meets the applicable TDIF requirements,
including any requirements that could not be adequately
assessed due to access or timing issues.

j) Details of any identified instance of non-compliance

with the TDIF requirements or any other risk identified
by the Assessor or user researcher; and

k) Any recommendation from the Assessor or user

researcher to address such non-compliance or risk.

2.8 Annual Assessment Report

The Accredited Provider MUST: a) assess each identified instance of non-compliance
with the TDIF requirements covered by the Annual
Assessment reports submitted as per ANNUAL-02-08-01

b)Assess any other risks identified by the Assessor

# A80000OFFICIAL
 A80000OFFICIAL #

c) Assign each instance of non-compliance and risk

with a risk rating as set out in Appendix A: Risk Ratings;
and

d) Include in the Annual Assessment Report:

i. Details of each such risk assessment

ii. A copy of the Accredited Provider’s risk matrix; and
iii. Descriptions of the likelihood and risk categories
associated with the risk ratings assigned above.

The Accredited Provider’s Accountable a) for each recommendation, risk and non-compliance
Executive MUST respond in writing to each that is accepted by the Accredited Provider, the
recommendation, risk and non-compliance timeframe and details of the actions that the Accredited
outlined in the Annual Assessment Reports Provider will take for implementation ; and
including:

b) for each recommendation, risk and non-compliance

that is not accepted by the Accredited Provider, the
reasons for non-acceptance and details of alternative
actions (if any) to be taken by the Accredited Provider.

If the Accredited Provider does not implement a a)A revaluation of the risk
mitigation or recommendation by the
timeframe set out in ANNUAL-02-08-02a, then
its Accountable Executive MUST provide to the
DTA in writing:

NOTE: if the Accredited Provider has failed to

implement a mitigation or recommendation
following its written commitment as per
ANNUAL-02-08-03, the DTA will then assess
whether the Accredited Provider has failed to
meet one or more of their ongoing obligations.
If the DTA finds that the Accredited Provider has
failed to meet their obligations, this will result in
a finding of non-compliance with the TDIF, the
DTA will make a decision whether the
Accredited Provider’s accreditation will be
suspended or terminated.

b) Any agreed upon mitigation strategies

implemented, or being implemented, to manage the risk

# A80000OFFICIAL
 A80000OFFICIAL #

c) Confirmation of the Applicant’s tolerance to

continue to carry the risk until the fix is implemented;
and

d) The proposed new date for implementation that will

be agreed upon by the DTA
Any risks or recommendations identified in • meet or exceed a High or Extreme risk rating for the
ANNUAL-02-08-02 or ANNUAL-02-08-03 MUST Accredited Provider’s Annual Assessment .
NOT:
[According to Appendix A: Risk Ratings in TDIF 07
Maintain Accreditation, or the Applicant’s equivalent risk
framework.]

If the risk rating meets or exceeds that outlined a) it has implemented mitigations to address the
above in ANNUAL-02-08-04, the Accredited recommendation, risk or non-compliance
Provider MUST confirm:

b) The risk, recommendation or non-compliance has

been reassessed and the residual risk rating is at
Moderate or below ; and

[According to Appendix A: Risk Ratings in TDIF 07

Maintain Accreditation, or the Applicant’s equivalent risk
framework.]

c) The Accountable Executive has signed off and

confirmed the implemented mitigation of the risk and
the new residual risk rating.

7.2.9 TDIF 04 Functional Requirements Review

As part of the Annual Assessment the a) The annual assessment of the Digital Identity Fraud
Accredited Provider MUST review following Risk associated with the services for which the
FRAUD requirements in TDIF 04 Functional Accredited Provider is accredited and the Accredited
Requirements and provide the DTA with: Provider’s Identity System as per FRAUD-02-01-02

b) Where exceptional circumstances prevented or

affected the Applicant’s capability to implement a TDIF
requirement, the record of decisions taken by the
Applicant in relation to such non compliance and
remedial action as per FRAUD-02-01-04

c) Any decisions and supporting documentation made

by the Accredited Provider to vary its fraud control
arrangements during the year (as per FRAUD-02-01-04).

d) Evidence the Accredited Provider has reviewed its

Fraud Control Plan (and supporting Fraud Control Plans)
during the year (as per FRAUD-02-02-02 and FRAUD-02-
02-02a).

# A80000OFFICIAL
 A80000OFFICIAL #

e) A copy of fraud awareness training materials

provided by the Accredited Provider to Personnel during
the year (as per FRAUD-02-03-01 and FRAUD-02-03-02).

As part of the Annual Assessment the a) Evidence the Accredited Provider has reviewed its
Accredited Provider MUST review the following Privacy Policy and where relevant updated during the
PRIV requirements in TDIF 04 Functional year (as per PRIV-03-02-05).
Requirements and provide the DTA with:

b) Evidence the Accredited Provider has reviewed its

Privacy Management Plan and where relevant updated
during the year (as per PRIV-03-02-07).

c) A copy of privacy awareness training materials

provided by the Accredited Provider to Personnel during
the year (as per PRIV-03-02-08).

d) A copy of any Privacy Impact Assessments

conducted on all High Risk Projects related to its Identity
System (as per PRIV-03-03-01)

As part of the Annual Assessment the

Accredited Provider MUST provide the DTA with
a copy of their Annual Transparency Report (as
per PRIV-03-06-05 and PRIV-03-06-05a).

As part of the Annual Assessment the a) The annual assessment of the Cyber Security Risk
Accredited Provider MUST review the following associated with the services for which the Accredited
PROT requirements in TDIF 04 Functional Provider is accredited and the Accredited Provider’s
Requirements and provide the DTA with: Identity System as per PROT-04-01-01

b) Where exceptional circumstances prevented or

affected the Applicant’s capability to implement a TDIF
requirement, the record of decisions taken by the
Applicant in relation to such non compliance and
remedial action as per PROT-04-01-03

c) Any decisions and supporting documentation made

by the Accredited Provider to vary its protective security
arrangements during the year as per PROT-04-01-03.

a) A copy of protective security training materials and

evidence that training was provided by the Accredited
Provider to Personnel during the year as per PROT-04-
01-05a.

# A80000OFFICIAL
 A80000OFFICIAL #

e) Evidence the Accredited Provider has reviewed its

System Security Plan (and supporting System Security
Plans) and where relevant updated them during the year
as per PROT-04-01-12 and PROT-04-01-13

f) Evidence the Accredited Provider has tested its

Disaster Recovery and Business Continuity Plan during
the year as per PROT-04-02-25.

2.9.1 Annual Privacy Assessment

The Accredited Provider MUST commission an a) include an assessment of whether the Accredited
Assessor to conduct a privacy assessment which Provider has addressed all recommendations included in
MUST, at a minimum: the privacy impact assessment prepared under ASSESS-
07-05-01 ; and

b) address the recommendations (if any) included in a

privacy impact assessment conducted by the Accredited
Provider under PRIV-03-03-01 after the date of
accreditation or the date of the last Annual Assessment

c) address the recommendations (if any) made by the

Information Commissioner or a State or Territory privacy
authority (as applicable), in respect of any complaints
against the Accredited Provider or in respect of any
privacy incidents involving the Accredited Provider; and

d) includes a review and assessment of the Applicant’s

compliance with the privacy requirements of the TDIF

The Accredited Provider MUST commission an a) address the findings and recommendations (if any)
Assessor to conduct a security assessment from the penetration testing of the Accredited Provider’s
which MUST, at a minimum: Identity System conducted under ANNUAL-02-09-07

b) if the Accredited Provider has conducted

penetration testing of a major production release of
software forming part of its Identity System after the
date of accreditation or the date of the last Annual
Assessment—address the findings and
recommendations (if any) from such testing

# A80000OFFICIAL
 A80000OFFICIAL #

c) include an evaluation of the impact of the following

events against the Accredited Provider’s protective
security controls:

i. changes to the Accredited Provider’s tolerance of

Cyber Security Risks
ii. Cyber Security Incidents reported to the DTA, and
the Accredited Provider’s response to such incidents;
and
iii. changes to the design of the Accredited Provider’s
Identity System

d) include an evaluation of the sufficiency of the

Accredited Provider’s protective security controls
e) include a review and assessment of any decisions,
together with supporting information, taken by the
Accredited Provider’s CSO under PROT-04-01-03 to vary
the Accredited Provider’s protective security
arrangements; and

f) include a review and assessment of the entity’s

compliance with the applicable requirements section 4
(Protective Security Requirements) of TDIF: 04
Functional Requirements.

The Accredited Provider MUST commission an

Assessor to conduct penetration testing of its
Identity System which must, at a minimum,
meet the requirements of ASSESS-07-06-02.

The Accredited Provider MUST commission an a) WCAG version 2.0 to the AA standard for web-based
Assessor to conduct an accessibility assessment Identity Systems; and
which must, at a minimum, assess whether the
Accredited Provider’s Identity System meets:

b) WCAG version 2.1 to the AA standard for mobile-

based Identity Systems.
The Accredited Provider MUST commission a
user researcher to conduct a usability test which
must, at a minimum, meet the requirements of
UX-05-04-02 to UX-05-04-06b.

2.10 TDIF 05 Role Requirements Review

# A80000OFFICIAL
 A80000OFFICIAL #

If an Identity Service Provider supports

Exceptional Use Cases as per IDP-03-03-01, it
MUST review its processes and risk assessments
as per IDP-03-03-01b and provide evidence of
this review and any updated documentation to
the DTA.

2.10.1 IDP Biometric Requirements

If an Accredited Provider operates biometrics in
accordance with Section 3.8 of TDIF 05 Role
Requirements, then it MUST implement the
following requirements as part of its Annual
Assessment and submit evidence of this review
to the DTA.

The Applicant MUST consider the following risks a)Applicable risks in IDP-03-08-03
related to performing Biometric Binding when
reviewing their Fraud Control Plan and System
Security Plan as part of its Annual Assessment
requirements:

b) Any Major Production Releases that impact the

operation, or result in a substantive change to the
performance, of the Applicant’s Biometric Capability

o The Applicant MUST provide a copy of their product

release version documentation, including release notes,
to the DTA

c) Changes in the biometric vulnerability landscape

that impact the Applicant’s operation of their Biometric
Capability.

[NOTE: biometric vulnerability landscape refers to

accessible and widespread emerging technology that
may overcome a previously difficult way of fooling a PAD
system or matching algorithm. For example, convincing
silicon masks become much cheaper to acquire in a short
period of time. Or in the case of 3d printers, widespread,
cheaper access to the technology means there are more
ways for more people to create attack artefacts.]

d) Risks related to identified attacks on the Biometric

Capability that have occurred since the last assessment

# A80000OFFICIAL
 A80000OFFICIAL #

Evidence of the review and risks outlined in

ANNUAL-02-10-03, associated mitigation
strategies and treatments, the Applicant’s risk
framework and any supporting evidence MUST
be provided to the DTA as part of the Annual
Assessment.

If the risk assessment undertaken by the

Applicant in ANNUAL-02-10-03 indicates that
substantial changes have occurred to the PAD
technology of the Accredited Provider’s
Biometric Capability , the PAD technology
MUST be re-tested as per IDP-03-08-12 to IDP-
03-08-12i and the report and any additional
required evidence submitted to the DTA for
review as part of the Annual Assessment.

If the risk assessment undertaken by the

Applicant in ANNUAL-02-10-03 indicates that
substantial changes have occurred to the
matching algorithm of the Accredited Provider’s
Biometric Capability, the Matching Algorithm
MUST be re-tested as per IDP-03-08-18 to IDP-
03-08-18d and the report and any additional
evidence submitted to the DTA for review as
part of the Annual Assessment.

If the Accredited Provider supports Local

Biometric Binding, then it MUST review and
record any variations to the locations used for
Local Biometric Binding during the last 12
months as per IDP-03-08-14c and FRAUD-02-01-
04.

If the Accredited Provider supports Manual Face a) The tools and annual training for Personnel
Comparison, it MUST review and submit to the performing identity proofing processes to detect
DTA evidence of: fraudulent attributes and Evidence of Identity
Documents

[ As per the requirements in Table 1: Identity Proofing

Levels of TDIF 05 Role Requirements.]

b) Assessing Officer annual training and training

material as per IDP-03-08-24
c) The Assessing Officer reference card as per IDP-03-
08-24a

# A80000OFFICIAL
 A80000OFFICIAL #

d) Its Fraud Control Plan and procedures to detect

fraudulent activities by Assessing Officers performing
Manual Face Comparison as per IDP-03-08-25 and
FRAUD-02-02-01a

e) The quality control and quality assurance

procedures for Manual Face Comparison decisions made
by Assessing Officers and the Accredited Provider’s
response to any risks that have arisen during operations
as per IDP-03-08-26

2.10.2 ASP Annual Requirements

As part of the Annual Assessment the
Accredited Provider MUST provide the DTA with
evidence of its arrangements with an
Authoritative Source (as per ASP-05-02-01a )

Exemption Request Review

If an Accredited Provider has been granted an a)Confirm that the Exemption Request is still required
exemption request as per ACCRED-03-01-06 and
ACCRED-03-01-06a, then it MUST review the
exemption request and:

b) Reassess the risk and mitigation measures in place,

including any new risks arising throughout the year in
response to the Accredited Provider’s operations

c) Include a new date of expiry or review of the

Exemption Request that is not more than 12 months
from the date of the review

d) Have the Accredited Provider’s Accountable

Executive confirm and sign off on the items above; and

e)Submit evidence of the above to the DTA.

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I

C I

C I

C I X

C I X

C I X

C I

C I

C I

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I

# A80000OFFICIAL
 A80000OFFICIAL #

C I

C I

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X
C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I

C I

C I

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X
C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I

C I

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I

C I

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X
C I X
C I X
C I X

C I X

C I X

C I X

C I X

C I

C I

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X
C I X

C I X

C I X

C I X

C I X

C I X

C I X

C
C

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X
C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X
C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I

C I

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

I
I

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X
C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I

C I

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X
C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X
C I X

C I X

C I X

C I X
C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X
C I X
C I X

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X

C I X
C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

C I X

C I X

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

C I X

C I X

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

C I X

C I X

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
A80000OFFICIAL #

# A80000OFFICIAL
 A80000OFFICIAL #

Change log
The next scheduled review of TDIF will occur by July 2022. Any changes made to the policy framework pri
changes will be considered as part of the next scheduled review of TDIF.

Digital Transformation Agency

This work is copyright. Apart from any use as permitted under the Copyright Act 1968 and the rights explic
Licence

With the exception of the Commonwealth Coat of Arms and where otherwise noted, this product is provided under a Creative

This licence lets you distribute, remix, tweak and build upon this work, even commercially, as long as they
reuse or distribution of part or all of this work must include the following attribution:
Trusted Digital Identity Framework (TDIF ™) Change log © Commonwealth of Australia (Digital Transform
Use of the Coat of Arms
The terms under which the Commonwealth Coat of Arms can be used are detailed on the It’s an Honour website (http://www
Contact us

The DTA is committed to providing accessible web content wherever possible. This document has undergone an accessibility c

# A80000OFFICIAL
 A80000OFFICIAL #

Emergency
Routine
Material

TDIF 01 Glossary
TDIF 02 Overview
TDIF 03 Accreditation Process
TDIF 04 Functional Requirements
TDIF 04A Functional Guidance
TDIF 05 Role Requirements
TDIF 05A Role Guidance
TDIF 06 Federation Onboarding Requirements
TDIF 06A Federation Onboarding Guidance
TDIF 06B OpenID Connect 1.0 Profile
TDIF 06C SAML 2.0 Profile
TDIF 06D Attribute Profile
TDIF 07 Annual Assessment
TDIF Variation SOP

# A80000OFFICIAL