Tdif Accreditation Requirements - Release 4.8 Feb 2023 - Finance

OFFICIAL #
>PROVIDER NAME< >TYPE OF ACCREDITATION<

Application
ABN Date
Accreditation Role being sought

Identity Service Provider
Credential Service Provider
Attribute Service Provider
Identity Exchange
For Identity Service Providers

IP Levels supported Verification methods supported
IP 1 Source
IP 1 Plus Technical
IP 2 Visual
IP 2 Plus
IP 3
IP 4
TDIF Application Letter checklist:

Accreditation particulars provided
Accreditation schedule provided
List of key personnel provided
Statement of Applicability provided
Prior audit work justification provided
Name Role Email

Trentino Bino Accreditation Officer digitalid@finance.gov.au
>Applicant< Assessment Status (this section is filled out during accreditation by the De
Application Date 30-Dec-99 Anticipated accreditation date:
Status
# OFFICIAL
OFFICIAL #
Latest accreditation status
Functional Assessments completed: Expected Date
Privacy Impact Assessment

Privacy Audit
Security Assessment
Penetration Test
Accessibility Assessment
TDIF Initial Accreditation - Requirements Assessment

0 Total Requirements considered
0 #DIV/0! Agreed Not Applicable
0 #DIV/0! Outstanding
0 #DIV/0! Agreed Exemptions
0 #DIV/0! Accepted
0 #DIV/0! Completed
Outstanding Data Entry

0 #DIV/0! Evidence Statement by applicant outstanding
0 #DIV/0! Reference (or NA) by applicant (or Finance) outstanding
0 #DIV/0! Assessment Comment by Finance outstanding
For Data Provided - Action Set to
0 Applicant to action
0 Finance to action
TDIF Maintain Accreditation - Requirements Assessment

0 #DIV/0! Accepted
0 #DIV/0! Completed
TDIF 06 Federation Onboarding - Requirements Assessment

# OFFICIAL
OFFICIAL #
0 #DIV/0! Accepted
0 #DIV/0! Completed
Schedule & Progress

Date Description
Decisions & Issues

Date Description
# OFFICIAL
OFFICIAL #
Date Accreditation
Expected
Technical capability of service

Web-responsive design
Mobile app
Both
For Credential Service Providers For Attribute Service Providers

CL Levels supported Attribute classes supported
CL1 Authorisation
CL2 Qualification
CL3 Entitlement
Self-Asserted
Platform
Australian Government Digital Identity System

Onboarding to DI system
Out of federation accreditation
Total Requirements in TDIF

1460 Total
Email Phone
alid@finance.gov.au 000 000 0000
t during accreditation by the Department o

30-Dec-99
# OFFICIAL
OFFICIAL #
Who
anding
ance) outstanding
tanding
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
Finance Link
Finance Link
# OFFICIAL
OFFICIAL #
TDIF Requirement Subsection

Requirements
INSTRUCT
ACCRED ACCRED-03-01-01 3.2.3.2
ACCRED ACCRED-03-01-01a 3.2.3.2
ACCRED ACCRED-03-01-01b 3.2.3.2

ACCRED ACCRED-03-01-01c 3.2.3.2

ACCRED ACCRED-03-01-02b 3.2.3.2
ACCRED ACCRED-03-01-02c 3.2.3.2
# OFFICIAL
OFFICIAL #
ACCRED ACCRED-03-01-02d 4.3.1
3.3.2
ACCRED ACCRED-03-01-06 3.3.2
ACCRED ACCRED-03-01-06a 3.3.2
3.3.2.3
# OFFICIAL
OFFICIAL #
ACCRED ACCRED-03-01-07b 3.3.2
3.3.3
ACCRED ACCRED-03-03-01b 3.3.3
3.3.4
# OFFICIAL
OFFICIAL #
4.2.1
FRAUD FRAUD-02-01-01 4.2.1
FRAUD FRAUD-02-01-01 4.2.1
FRAUD FRAUD-02-01-02 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
FRAUD FRAUD-02-01-03 4.2.1
# OFFICIAL
OFFICIAL #
FRAUD FRAUD-02-01-03 4.2.1
FRAUD FRAUD-02-01-04 4.2.1
FRAUD FRAUD-02-01-04 4.2.1
FRAUD FRAUD-02-01-04 4.2.1
4.2.2
FRAUD FRAUD-02-02-01 4.2.2
FRAUD FRAUD-02-02-01a 4.2.2

# OFFICIAL
OFFICIAL #
FRAUD FRAUD-02-02-02 4.2.2

FRAUD FRAUD-02-02-02 4.2.2
4.2.3
# OFFICIAL
OFFICIAL #
FRAUD FRAUD-02-03-01 4.2.3
FRAUD FRAUD-02-03-02 4.2.3
FRAUD FRAUD-02-03-02 4.2.3

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
FRAUD FRAUD-02-04-01 4.2.4
FRAUD FRAUD-02-04-02 4.2.4
FRAUD FRAUD-02-04-02b 4.2.4
FRAUD FRAUD-02-04-02b 4.2.4

4.2.5
FRAUD FRAUD-02-05-01 4.2.5
FRAUD FRAUD-02-05-01 4.2.5
# OFFICIAL
OFFICIAL #
FRAUD FRAUD-02-05-02 4.2.5
FRAUD FRAUD-02-05-03 4.2.5
FRAUD FRAUD-02-05-03 4.2.5
FRAUD FRAUD-02-05-04 4.2.5
FRAUD FRAUD-02-05-05 4.2.5
FRAUD FRAUD-02-05-06 4.2.5
FRAUD FRAUD-02-05-06 4.2.5
4.2.6
FRAUD FRAUD-02-06-01 4.2.6
FRAUD FRAUD-02-06-02 4.2.6
FRAUD FRAUD-02-06-03 4.2.6
4.3.1
PRIV PRIV-03-01-01 4.3.1
# OFFICIAL
OFFICIAL #
PRIV PRIV-03-01-02 4.3.1
PRIV PRIV-03-01-02 4.3.1
PRIV PRIV-03-01-02 4.3.1
PRIV PRIV-03-02-01 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
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
PRIV PRIV-03-02-02 4.3.2
PRIV PRIV-03-02-02a 4.3.2
PRIV PRIV-03-02-02b 4.3.2
# OFFICIAL
OFFICIAL #
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-03 4.3.2.2
PRIV PRIV-03-02-03a 4.3.2.2
PRIV PRIV-03-02-03b 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
PRIV PRIV-03-02-04 4.3.2.2
PRIV PRIV-03-02-04 4.3.2.2
PRIV PRIV-03-02-05 4.3.2.2
PRIV PRIV-03-02-06 4.3.2.3
PRIV PRIV-03-02-07 4.3.2.3
# OFFICIAL
OFFICIAL #
PRIV PRIV-03-02-08 4.3.2.3
PRIV PRIV-03-02-08 4.3.2.3

PRIV PRIV-03-02-09 4.3.2.3
4.3.3
PRIV PRIV-03-03-01 4.3.3
PRIV PRIV-03-03-01a 4.3.3
PRIV PRIV-03-03-01b 4.3.3

4.3.4
PRIV PRIV-03-04-01 4.3.4
PRIV PRIV-03-04-01 4.3.4
PRIV PRIV-03-04-01a 4.3.4
PRIV PRIV-03-04-01a 4.3.4
PRIV PRIV-03-04-02 4.3.4
PRIV PRIV-03-04-02 4.3.4
# OFFICIAL
OFFICIAL #
PRIV PRIV-03-04-02 4.3.4
PRIV PRIV-03-04-03 4.3.4
4.3.5
PRIV PRIV-03-05-01 4.3.5
PRIV PRIV-03-05-02 4.3.5
4.3.6
PRIV PRIV-03-06-01 4.3.6
PRIV PRIV-03-06-02 4.3.6

PRIV PRIV-03-06-03 4.3.6
PRIV PRIV-03-06-04 4.3.6
# OFFICIAL
OFFICIAL #
PRIV PRIV-03-06-04a 4.3.6
PRIV PRIV-03-06-05 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
PRIV PRIV-03-06-05a 4.3.6
PRIV PRIV-03-06-06 4.3.6
4.3.7
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-01 4.3.7
PRIV PRIV-03-07-01a 4.3.7

4.3.8
PRIV PRIV-03-08-01 4.3.8
# OFFICIAL
OFFICIAL #
PRIV PRIV-03-08-01a 4.3.8
PRIV PRIV-03-08-01a 4.3.8
PRIV PRIV-03-08-02 4.3.8
PRIV PRIV-03-08-02 4.3.8
PRIV PRIV-03-08-02a 4.3.8
PRIV PRIV-03-08-02b 4.3.8
PRIV PRIV-03-08-02c 4.3.8
PRIV PRIV-03-08-03 4.3.8
PRIV PRIV-03-08-04 4.3.8
4.3.9
PRIV PRIV-03-09-01 4.3.9
PRIV PRIV-03-09-01 4.3.9
PRIV PRIV-03-09-01 4.3.9
# OFFICIAL
OFFICIAL #
PRIV PRIV-03-09-01 4.3.9
PRIV PRIV-03-09-02 4.3.9
PRIV PRIV-03-09-02a 4.3.9

PRIV PRIV-03-09-02b 4.3.9
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
PRIV PRIV-03-09-04 4.3.9
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.11
PRIV PRIV-03-11-01 4.3.11
4.3.12
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
# OFFICIAL
OFFICIAL #
PRIV PRIV-03-12-07 4.3.12
PRIV PRIV-03-12-07a 4.3.12
4.3.13
PRIV PRIV-03-13-01 4.3.13
PRIV PRIV-03-13-02 4.3.13
PRIV PRIV-03-13-03 4.3.13
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-14-01 4.3.14
4.3.15
PRIV PRIV-03-15-01 4.3.15
4.4.1
4.4.1.1
PROT PROT-04-01-01 4.4.1.1
PROT PROT-04-01-02 4.4.1.1
PROT PROT-04-01-02 4.4.1.1
PROT PROT-04-01-02 4.4.1.1
PROT PROT-04-01-02 4.4.1.1
# OFFICIAL
OFFICIAL #
PROT PROT-04-01-03 4.4.1.1
PROT PROT-04-01-03 4.4.1.1
PROT PROT-04-01-03 4.4.1.1
4.4.1.2
PROT PROT-04-01-04 4.4.1.2
PROT PROT-04-01-04 4.4.1.2
PROT PROT-04-01-04a 4.4.1.2
PROT PROT-04-01-04a 4.4.1.2

PROT PROT-04-01-04a 4.4.1.2
PROT PROT-04-01-04a 4.4.1.2
PROT PROT-04-01-05 4.4.1.2
PROT PROT-04-01-05a 4.4.1.2
PROT PROT-04-01-05a 4.4.1.2

PROT PROT-04-01-06 4.4.1.2
PROT PROT-04-01-06 4.4.1.2
PROT PROT-04-01-06 4.4.1.2

PROT PROT-04-01-07 4.4.1.2
PROT PROT-04-01-08 4.4.1.2
# OFFICIAL
OFFICIAL #
PROT PROT-04-01-09 4.4.1.2
PROT PROT-04-01-09 4.4.1.2
PROT PROT-04-01-10 4.4.1.2
4.4.1.3
PROT PROT-04-01-11 4.4.1.3
PROT PROT-04-01-11a 4.4.1.3
PROT PROT-04-01-11a 4.4.1.3
PROT PROT-04-01-11a 4.4.1.3

PROT PROT-04-01-11a 4.4.1.3
PROT PROT-04-01-11a 4.4.1.3
PROT PROT-04-01-11a 4.4.1.3
PROT PROT-04-01-11a 4.4.1.3
PROT PROT-04-01-11a 4.4.1.3
PROT PROT-04-01-11a 4.4.1.3
PROT PROT-04-01-11a 4.4.1.3

PROT PROT-04-01-11a 4.4.1.3
PROT PROT-04-01-11a 4.4.1.3
PROT PROT-04-01-11a 4.4.1.3
# OFFICIAL
OFFICIAL #
PROT PROT-04-01-11a 4.4.1.3
PROT PROT-04-01-11a 4.4.1.3
PROT PROT-04-01-12 4.4.1.3

PROT PROT-04-01-12 4.4.1.3
PROT PROT-04-01-13 4.4.1.3
PROT PROT-04-01-13 4.4.1.3
PROT PROT-04-01-14 4.4.1.3
4.4.1.4
PROT PROT-04-01-15 4.4.1
PROT PROT-04-01-15a 4.4.1
4.4.2
4.4.2.1
PROT PROT-04-02-01 4.4.2.1
PROT PROT-04-02-01 4.4.2.1
PROT PROT-04-02-01 4.4.2.1
PROT PROT-04-02-02 4.4.2.1
4.4.2.2
PROT PROT-04-02-03 4.4.2.2
# OFFICIAL
OFFICIAL #
PROT PROT-04-02-03 4.4.2.2
PROT PROT-04-02-04 4.4.2.2
PROT PROT-04-02-04a 4.4.2.2
4.4.2.3
PROT PROT-04-02-05 4.4.2.3
PROT PROT-04-02-05 4.4.2.3

PROT PROT-04-02-05 4.4.2.3
PROT PROT-04-02-05 4.4.2.3
PROT PROT-04-02-06 4.4.2.3
4.4.2.4
PROT PROT-04-02-07 4.4.2.4
PROT PROT-04-02-07a 4.4.2.4
PROT PROT-04-02-08 4.4.2.4
PROT PROT-04-02-08a 4.4.2.4
PROT PROT-04-02-08b 4.4.2.4
PROT PROT-04-02-08b 4.4.2.4
PROT PROT-04-02-09 4.4.2.4
PROT PROT-04-02-10 4.4.2.4
PROT PROT-04-02-11 4.4.2.4
PROT PROT-04-02-12 4.4.2.4
PROT PROT-04-02-13 4.4.2.4
# OFFICIAL
OFFICIAL #
PROT PROT-04-02-13 4.4.2.4
PROT PROT-04-02-14 4.4.2.4
PROT PROT-04-02-14a 4.4.2.4
PROT PROT-04-02-14a 4.4.2.4
PROT PROT-04-02-14a 4.4.2.4
4.4.2.5
PROT PROT-04-02-15 4.4.2.5
PROT PROT-04-02-16 4.4.2.5
PROT PROT-04-02-17 4.4.2.5
PROT PROT-04-02-18 4.4.2.5
4.4.2.6
PROT PROT-04-02-19 4.4.2.6
PROT PROT-04-02-20 4.4.2.6
PROT PROT-04-02-21 4.4.2.6
PROT PROT-04-02-22 4.4.2.6
PROT PROT-04-02-22a 4.4.2.6

PROT PROT-04-02-22a 4.4.2.6
# OFFICIAL
OFFICIAL #
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
PROT PROT-04-02-22a 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
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-22c 4.4.2.6

PROT PROT-04-02-22d 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
PROT PROT-04-02-22e 4.4.2.6
PROT PROT-04-02-23 4.4.2.6
PROT PROT-04-02-23 4.4.2.6
PROT PROT-04-02-23 4.4.2.6
PROT PROT-04-02-23a 4.4.2.6

4.4.2.7
PROT PROT-04-02-24 4.4.2.7
PROT PROT-04-02-24 4.4.2.7
# OFFICIAL
OFFICIAL #
PROT PROT-04-02-24 4.4.2.7

PROT PROT-04-02-24 4.4.2.7
PROT PROT-04-02-24 4.4.2.7
PROT PROT-04-02-25 4.4.2.7
4.4.2.8
PROT PROT-04-02-26 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
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
PROT PROT-04-03-02 4.4.3.1

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
PROT PROT-04-03-05a 4.4.3.3
4.4.4
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
PROT PROT-04-04-04 4.4.4

PROT PROT-04-04-04 4.4.4
# OFFICIAL
OFFICIAL #
PROT PROT-04-04-04 4.4.4
4.5.1
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
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
UX UX-05-02-02 4.5.2
UX UX-05-02-03 4.5.2
UX UX-05-02-03 4.5.2
UX UX-05-02-03 4.5.2
UX UX-05-02-04 4.5.2
UX UX-05-02-05 4.5.2
UX UX-05-02-05a 4.5.2
UX UX-05-02-05b 4.5.2
UX UX-05-02-05b 4.5.2
UX UX-05-02-05b 4.5.2
# OFFICIAL
OFFICIAL #
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
4.5.3
UX UX-05-03-01 4.5.3
4.5.4
UX UX-05-04-01 4.5.4.1
UX UX-05-04-01 4.5.4.1
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
# OFFICIAL
OFFICIAL #
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-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
UX UX-05-04-02c 4.5.4.2
4.5.5
UX UX-05-04-03 4.5.4.3
UX UX-05-04-04 4.5.4.3
UX UX-05-04-05 4.5.4.3
UX UX-05-04-06 4.5.4.3
UX UX-05-04-06a 4.5.4.3
UX UX-05-04-06a 4.5.4.3
UX UX-05-04-06b 4.5.4.3
4.5.6
UX UX-05-05-01 4.5.5
4.6.1
# OFFICIAL
OFFICIAL #
TEST TEST-06-01-01 4.6.1
TEST TEST-06-01-01 4.6.1
TEST TEST-06-01-01 4.6.1
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 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
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-05 4.6.1
TEST TEST-06-01-05 4.6.1
TEST TEST-06-01-06 4.6.1
TEST TEST-06-01-07 4.6.1
4.7.1
# OFFICIAL
OFFICIAL #
ASSESS ASSESS-07-01-01 4.7.1

4.7.2
4.7.3


4.7.4
# OFFICIAL
OFFICIAL #



# OFFICIAL
OFFICIAL #
ASSESS ASSESS-07-04-03a 4.7.4
ASSESS ASSESS-07-04-03b 4.7.4
4.7.5


4.7.6
# OFFICIAL
OFFICIAL #

4.7.7
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
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
ROLE ROLE-02-01-02 5.2.1
5.3.2
# OFFICIAL
OFFICIAL #
IDP IDP-03-02-01 5.3.2
IDP IDP-03-02-02 5.3.2
IDP IDP-03-02-02a 5.3.2
5.3.3
IDP IDP-03-03-01 5.3.3
IDP IDP-03-03-01a 5.3.3
IDP IDP-03-03-01b 5.3.3
IDP IDP-03-03-01b 5.3.3
IDP IDP-03-03-01b 5.3.3
5.3.4
IDP IDP-03-04-01 5.3.4
IDP IDP-03-04-01 5.3.4
# OFFICIAL
OFFICIAL #
IDP IDP-03-04-01a 5.3.4

IDP IDP-03-04-01b 5.3.4
IDP IDP-03-04-02 5.3.4
IDP IDP-03-04-02a 5.3.4
IDP IDP-03-04-02b 5.3.4
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
5.3.5
IDP IDP-03-05-01 5.3.5
IDP IDP-03-05-01a 5.3.5
IDP IDP-03-05-01b 5.3.5
# OFFICIAL
OFFICIAL #
IDP IDP-03-05-02 5.3.5
IDP IDP-03-05-02a 5.3.5
5.3.6
IDP IDP-03-06-01 5.3.6
5.3.7
IDP IDP-03-07-01 5.3.7
IDP IDP-03-07-02 5.3.7
IDP IDP-03-07-03 5.3.7
5.3.8
5.3.8.1
IDP-03-08-01 5.3.8.1
IDP
IDP IDP-03-08-02 5.3.8.1
IDP IDP-03-08-02 5.3.8.1
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
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
# OFFICIAL
OFFICIAL #
IDP IDP-03-08-04 5.3.8.1

IDP-03-08-05 5.3.8.1
IDP
IDP-03-08-06 5.3.8.1
IDP
IDP-03-08-07 5.3.8.1
IDP
IDP-03-08-07 5.3.8.1
IDP
IDP IDP-03-08-07 5.3.8.1
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
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
IDP IDP-03-08-10c 5.3.8.2
IDP IDP-03-08-11 5.3.8.2
# OFFICIAL
OFFICIAL #
IDP IDP-03-08-11a 5.3.8.2
IDP IDP-03-08-11b 5.3.8.2
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
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
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

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
# OFFICIAL
OFFICIAL #
5.3.8.4
IDP IDP-03-08-15 5.3.8.4
IDP IDP-03-08-16 5.3.8.4
IDP IDP-03-08-16a 5.3.8.4
IDP IDP-03-08-17 5.3.8.4
IDP IDP-03-08-18 5.3.8.4
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
IDP IDP-03-08-18d 5.3.8.4
5.3.8.5
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
5.3.8.6
IDP IDP-03-08-22 5.3.8.6
# OFFICIAL
OFFICIAL #
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
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
5.4.1
CSP CSP-04-01-01 5.4.1
CSP CSP-04-01-02 5.4.1
CSP CSP-04-01-03 5.4.1
CSP CSP-04-01-04 5.4.1
CSP CSP-04-01-05 5.4.1
CSP CSP-04-01-05a 5.4.1
CSP CSP-04-01-05b 5.4.1
5.4.2.1
CSP CSP-04-02-01 5.4.2.1
CSP CSP-04-02-01a 5.4.2.1
# OFFICIAL
OFFICIAL #
CSP CSP-04-02-01b 5.4.2.1
CSP CSP-04-02-01c 5.4.2.1
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

CSP CSP-04-02-01e 5.4.2.1
CSP CSP-04-02-01f 5.4.2.1
CSP CSP-04-02-01g 5.4.2.1
CSP CSP-04-02-01h 5.4.2.1
CSP CSP-04-02-01i 5.4.2.1
CSP CSP-04-02-01j 5.4.2.1

CSP CSP-04-02-01k 5.4.2.1
CSP CSP-04-02-01l 5.4.2.1
CSP CSP-04-02-01m 5.4.2.1
5.4.2.2
CSP CSP-04-02-02 5.4.2.2
CSP CSP-04-02-02a 5.4.2.2

CSP CSP-04-02-02b 5.4.2.2
CSP CSP-04-02-02c 5.4.2.2
CSP CSP-04-02-02d 5.4.2.2
# OFFICIAL
OFFICIAL #
CSP CSP-04-02-02d 5.4.2.2
CSP CSP-04-02-02e 5.4.2.2
CSP CSP-04-02-02f 5.4.2.2
CSP CSP-04-02-02g 5.4.2.2
5.4.2.3
CSP CSP-04-02-03 5.4.2.3
CSP CSP-04-02-03a 5.4.2.3
CSP CSP-04-02-03b 5.4.2.3
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
CSP CSP-04-02-03e 5.4.2.3

CSP CSP-04-02-03f 5.4.2.3
# OFFICIAL
OFFICIAL #
CSP CSP-04-02-03g 5.4.2.3
CSP CSP-04-02-03g 5.4.2.3
CSP CSP-04-02-03g 5.4.2.3
CSP CSP-04-02-03h 5.4.2.3
CSP CSP-04-02-03i 5.4.2.3
CSP CSP-04-02-03j 5.4.2.3
CSP CSP-04-02-03k 5.4.2.3
CSP CSP-04-02-03l 5.4.2.3
CSP CSP-04-02-03m 5.4.2.3
5.4.2.4
CSP CSP-04-02-04 5.4.2.4
CSP CSP-04-02-04a 5.4.2.4
CSP CSP-04-02-04b 5.4.2.4
CSP CSP-04-02-04c 5.4.2.4

CSP CSP-04-02-04d 5.4.2.4
CSP CSP-04-02-04e 5.4.2.4
# OFFICIAL
OFFICIAL #
CSP CSP-04-02-04f 5.4.2.4
CSP CSP-04-02-04g 5.4.2.4
CSP CSP-04-02-04h 5.4.2.4
CSP CSP-04-02-04i 5.4.2.4
CSP CSP-04-02-04j 5.4.2.4
5.4.2.5
CSP CSP-04-02-05 5.4.2.5
CSP CSP-04-02-05a 5.4.2.5
CSP CSP-04-02-05b 5.4.2.5
CSP CSP-04-02-05c 5.4.2.5

CSP CSP-04-02-05d 5.4.2.5
CSP CSP-04-02-05e 5.4.2.5
CSP CSP-04-02-05f 5.4.2.5
CSP CSP-04-02-05g 5.4.2.5
CSP CSP-04-02-05h 5.4.2.5
CSP CSP-04-02-05i 5.4.2.5

CSP CSP-04-02-05j 5.4.2.5
CSP CSP-04-02-05k 5.4.2.5
CSP CSP-04-02-05l 5.4.2.5
CSP CSP-04-02-05m 5.4.2.5
CSP CSP-04-02-05n 5.4.2.5
# OFFICIAL
OFFICIAL #
5.4.2.6
CSP CSP-04-02-06 5.4.2.6
CSP CSP-04-02-06a 5.4.2.6
CSP CSP-04-02-06b 5.4.2.6
CSP CSP-04-02-06c 5.4.2.6

CSP CSP-04-02-06d 5.4.2.6
CSP CSP-04-02-06e 5.4.2.6
CSP CSP-04-02-06f 5.4.2.6
CSP CSP-04-02-06g 5.4.2.6

5.4.2.7
CSP CSP-04-02-07 5.4.2.7
CSP CSP-04-02-07a 5.4.2.7
CSP CSP-04-02-07b 5.4.2.7
CSP CSP-04-02-07c 5.4.2.7

CSP CSP-04-02-07d 5.4.2.7
CSP CSP-04-02-07e 5.4.2.7

CSP CSP-04-02-07f 5.4.2.7
CSP CSP-04-02-07g 5.4.2.7
5.4.2.8
CSP CSP-04-02-08 5.4.2.8
CSP CSP-04-02-08a 5.4.2.8
CSP CSP-04-02-08b 5.4.2.8

CSP CSP-04-02-08c 5.4.2.8
CSP CSP-04-02-08d 5.4.2.8
CSP CSP-04-02-08e 5.4.2.8

CSP CSP-04-02-08f 5.4.2.8
CSP CSP-04-02-08g 5.4.2.8
CSP CSP-04-02-08h 5.4.2.8
CSP CSP-04-02-08i 5.4.2.8

CSP CSP-04-02-08j 5.4.2.8
5.4.2.9
# OFFICIAL
OFFICIAL #
CSP CSP-04-02-09 5.4.2.9
CSP CSP-04-02-09a 5.4.2.9
CSP CSP-04-02-09b 5.4.2.9

CSP CSP-04-02-09c 5.4.2.9
CSP CSP-04-02-09d 5.4.2.9

CSP CSP-04-02-09e 5.4.2.9
CSP CSP-04-02-09f 5.4.2.9
5.4.3
5.4.3.1
CSP CSP-04-03-01 5.4.3.1
CSP CSP-04-03-01a 5.4.3.1
CSP CSP-04-03-01b 5.4.3.1
5.4.3.2
CSP CSP-04-03-02 5.4.3.2
CSP CSP-04-03-02a 5.4.3.2
CSP CSP-04-03-02b 5.4.3.2
CSP CSP-04-03-02c 5.4.3.2
CSP CSP-04-03-02d 5.4.3.2
5.4.3.3
CSP CSP-04-03-03 5.4.3.3
CSP CSP-04-03-03a 5.4.3.3
CSP CSP-04-03-03b 5.4.3.3
CSP CSP-04-03-03c 5.4.3.3
# OFFICIAL
OFFICIAL #
CSP CSP-04-03-03d 5.4.3.3
CSP CSP-04-03-03e 5.4.3.3

CSP CSP-04-03-03f 5.4.3.3
CSP CSP-04-03-03g 5.4.3.3
CSP CSP-04-03-03h 5.4.3.3

CSP CSP-04-03-03i 5.4.3.3
CSP CSP-04-03-03j 5.4.3.3
CSP CSP-04-03-03j 5.4.3.3
CSP CSP-04-03-03k 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-03l 5.4.3.3
CSP CSP-04-03-03l 5.4.3.3
5.4.3.4
CSP CSP-04-03-04 5.4.3.4
CSP CSP-04-03-04a 5.4.3.4
CSP CSP-04-03-04b 5.4.3.4
5.4.3.5
# OFFICIAL
OFFICIAL #
CSP CSP-04-03-05 5.4.3.5
CSP CSP-04-03-05a 5.4.3.5
CSP CSP-04-03-05b 5.4.3.5
CSP CSP-04-03-05c 5.4.3.5
CSP CSP-04-03-05d 5.4.3.5

CSP CSP-04-03-05e 5.4.3.5
CSP CSP-04-03-05f 5.4.3.5
5.4.3.6
CSP CSP-04-03-06 5.4.3.6
5.4.3.7
CSP CSP-04-03-07 5.4.3.7
CSP CSP-04-03-07a 5.4.3.7
CSP CSP-04-03-07b 5.4.3.7
5.4.3.8
CSP CSP-04-03-08 5.4.3.8
CSP CSP-04-03-08a 5.4.3.8

CSP CSP-04-03-08b 5.4.3.8
5.4.3.10
CSP CSP-04-03-09 5.4.3.9
CSP CSP-04-03-10 5.4.3.9
# OFFICIAL
OFFICIAL #
CSP CSP-04-03-10 5.4.3.9
CSP CSP-04-03-10 5.4.3.9
CSP CSP-04-03-10 5.4.3.9
5.4.4
5.4.4.1
CSP CSP-04-04-01 5.4.4.1
CSP CSP-04-04-01a 5.4.4.1
CSP CSP-04-04-01b 5.4.4.1
CSP CSP-04-04-01c 5.4.4.1
CSP CSP-04-04-01d 5.4.4.1
CSP CSP-04-04-01e 5.4.4.1
CSP CSP-04-04-01f 5.4.4.1
5.4.4.2
CSP CSP-04-04-02 5.4.4.2
CSP CSP-04-04-02 5.4.4.2
CSP CSP-04-04-02a 5.4.4.2
CSP CSP-04-04-02a 5.4.4.2
# OFFICIAL
OFFICIAL #
CSP CSP-04-04-02a 5.4.4.2
5.4.4.3
CSP CSP-04-04-03 5.4.4.3
CSP CSP-04-04-03a 5.4.4.3
CSP CSP-04-04-03b 5.4.4.3
CSP CSP-04-04-03c 5.4.4.3

5.4.4.4
CSP CSP-04-04-06 5.4.4.4
5.4.4.5
CSP CSP-04-04-07 5.4.4.5
CSP CSP-04-04-08 5.4.4.5
5.4.5
CSP CSP-04-05-01 5.4.5
CSP CSP-04-05-02 5.4.5
CSP CSP-04-05-03 5.4.5
CSP CSP-04-05-04 5.4.5
CSP CSP-04-05-05 5.4.5
5.4.6
CSP CSP-04-06-01 5.4.6
CSP CSP-04-06-01a 5.4.6
CSP CSP-04-06-01b 5.4.6
5.4.7
# OFFICIAL
OFFICIAL #
CSP CSP-04-07-01 5.4.7
CSP CSP-04-07-02 5.4.7
5.4.8
CSP CSP-04-08-01 5.4.8
CSP CSP-04-08-01a 5.4.8
CSP CSP-04-08-01b 5.4.8
5.4.9
CSP CSP-04-09-01 5.4.9
CSP CSP-04-09-01a 5.4.9

CSP CSP-04-09-01b 5.4.9
CSP CSP-04-09-01c 5.4.9
CSP CSP-04-09-01d 5.4.9
5.4.10
CSP CSP-04-10-01 5.4.10
CSP CSP-04-10-01a 5.4.10

CSP CSP-04-10-01b 5.4.10
CSP CSP-04-10-01b 5.4.10
CSP CSP-04-10-01b 5.4.10

CSP CSP-04-10-02 5.4.10
5.4.11
CSP CSP-04-11-01 5.4.11
# OFFICIAL
OFFICIAL #
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-02 5.4.11
CSP CSP-04-11-03 5.4.11
CSP CSP-04-11-04 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
CSP CSP-04-11-04a 5.4.11
CSP CSP-04-11-04a 5.4.11
5.5.1
ASP ASP-05-01-01 5.5.1
ASP ASP-05-01-02 5.5.1
ASP ASP-05-02-01 5.5.2
ASP ASP-05-02-01a 5.5.2
# OFFICIAL
OFFICIAL #
ASP ASP-05-02-02 5.5.2

ASP ASP-05-02-03 5.5.2
ASP ASP-05-02-04 5.5.2
ASP ASP-05-02-05 5.5.2
ASP ASP-05-02-05a 5.5.2
ASP ASP-05-02-06 5.5.2
ASP ASP-05-02-06a 5.5.2
ASP ASP-05-02-06b 5.5.2

5.6
5.6.1
IDX IDX-06-01-01 5.6.1
IDX IDX-06-01-02 5.6.1
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
IDX IDX-06-02-01 5.6.2

IDX IDX-06-02-01 5.6.2
5.6.3
IDX IDX-06-03-01 5.6.3
IDX IDX-06-03-02 5.6.3
IDX IDX-06-03-02a 5.6.3
IDX IDX-06-03-03 5.6.3
# OFFICIAL
OFFICIAL #
IDX IDX-06-03-03a 5.6.3
IDX IDX-06-03-04 5.6.3
5.6.4
IDX IDX-06-04-01 5.6.4
IDX IDX-06-04-02 5.6.4
IDX IDX-06-04-03 5.6.4
5.6.5
IDX IDX-06-05-01 5.6.5
IDX IDX-06-05-02 5.6.5
IDX IDX-06-05-03 5.6.5
IDX IDX-06-05-03a 5.6.5
IDX IDX-06-05-03b 5.6.5
# OFFICIAL
OFFICIAL #
Requirement Text
TDIF: 03 - Accreditation Process

The Applicant MUST formally request TDIF accreditation by submitting to Finance a completed
TDIF Application Letter and response to the TDIF Statement of Claims
All information provided to Finance for the purpose of TDIF accreditation MUST be in English .
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
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 .
The TDIF Application Letter MUST specify whether the Identity Facility supports:
[A white-label product is a product or service produced by one organisation that other

organisations can rebrand to make it appear as 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
# OFFICIAL
OFFICIAL #
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 Finance 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 Finance with a sufficient understanding to enable it to work with
the Applicant to determine whether a requirement has been met.]
The Application Letter MUST include a Statement of Applicability which describes the scope of
the Applicant’s identity system.
At a minimum, the Statement of Applicability MUST:
The Statement of Applicability forms the basis of the Applicant’s Functional Assessments.
The TDIF Application Letter MUST include an accreditation schedule which includes:
The TDIF Application Letter MUST propose a commencement date and a date by which TDIF
accreditation is expected to be completed
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 .
3.2.2.2 Exemption Requests
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 information as described in

Appendix A: TDIF exemption process and, at a minimum:
3.2.2.3 Alternative assessment reports
# OFFICIAL
OFFICIAL #
The Applicant MAY submit an Alternative Assessment Report, which it requests Finance
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 Finance to consider Alternative Assessment Reports MUST

include:
The Alternative Assessment Report MUST have been produced no more than 12 months prior
to the date it is assessed by Finance and MUST cover the latest Major Production Release of the
Applicant’s Identity System (if any)
3.3.3.7 Varying Accreditation during Initial Accreditation
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 Finance a review of the applicable evidence
required for variation of accreditation, as outlined in Appendix C.
3.3.4.1 Finalisation of Accreditation Requirements
Once the applicant has achieved all applicable requirements, the Applicant MUST
submit a 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:
# OFFICIAL
OFFICIAL #
Once the Applicant has achieved all applicable requirements, it MUST sign a TDIF Agreement
(MOU) with Finance, which sets out the rights, roles and obligations of both parties in relation
to the Accredited Provider’s TDIF accreditation.
TDIF: 04 - Functional Requirements
Chapter 1 Fraud Requirements

2.1 Digital Identity Fraud Controller
The Applicant MUST have an officer or senior employee of the Applicant as the designated
Digital Identity Fraud Controller who is responsible for
The Applicant MUST conduct an assessment of the Digital Identity Fraud Risk associated with
the Applicant’s Identity System prior to accreditation and at least once every 12 months
beginning on the date the Applicant was accredited.
The Applicant MUST
# OFFICIAL
OFFICIAL #
Where exceptional circumstances prevent or affect the Applicant’s capability to implement a

TDIF requirement, the Applicant:
2.2 Digital Identity Fraud Control Plan

The Applicant MUST have in place a Digital Identity Fraud Control Plan approved by the Digital
Identity Fraud Controller to manage the Applicant’s Digital Identity Fraud Risks
The Digital Identity Fraud Control Plan MUST detail the
# OFFICIAL
OFFICIAL #
The Applicant MUST review and update its Digital Identity Fraud Control Plan:
This review MUST:
2.3 Digital Identity Fraud prevention, awareness and training
# OFFICIAL
OFFICIAL #
The Applicant MUST maintain records of 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 Identity Fraud Risk information and training to
Personnel whose duties relate to the services for which the Applicant is accredited:
The Applicant MUST provide fraud-control advice to Users on how to safeguard their Digital
Identity and Attributes
If the Applicant is aware of a Digital Identity Fraud Incident or Digital Identity Fraud Risk which
may affect Users, the Applicant MUST:
2.4 Fraud monitoring and detection

The Applicant MUST implement and maintain a Digital Identity Fraud control mechanism to
detect actual or suspected Digital Identity Fraud Incidents.
The Applicant MUST implement and maintain a process for Personnel, Individuals, Enforcement
Bodies and other entities to report suspected Digital Identity Fraud confidentially
The Applicant MUST implement and maintain a Digital Identity Fraud control mechanism to flag
actual or suspected Digital Identity Fraud Incidents
The Applicant MUST compare all new 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 Digital Identity is fraudulent or its use may result in a
Digital Identity Fraud Incident, the Applicant:
2.5 Incident management, investigations and reporting

The Applicant MUST either:
In the event of a Digital Identity Fraud Incident, the Applicant MUST take reasonable steps to
# OFFICIAL
OFFICIAL #
The Applicant MUST maintain documented 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:
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 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:
The Applicant MUST include, at a minimum, the following information when reporting on
Digital Identity Fraud Incidents:
2.6 Support for victims of Digital identity fraud

The Applicant MUST implement a process which allows any Individual to notify the Applicant
when they suspect or become aware that they have been affected by a Digital Identity Fraud
Incident
The Applicant MUST provide (either directly or 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 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
Chapter 2 Privacy Requirements

3.1 General privacy requirements
The Applicant MUST comply with applicable 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
# OFFICIAL
OFFICIAL #
If the Applicant is not an APP Entity, the Applicant MUST NOT take any action or engage in a
practice with respect to Personal Information when providing services using its Identity System
unless:
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 following Privacy Officer functions are carried out:
3.2 Privacy governance

The Applicant MUST have at least one 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 Privacy Champion promotes a culture of privacy that
values and protects Personal information.
The Applicant MUST demonstrate how its Privacy Champion:
# OFFICIAL
OFFICIAL #
The Applicant MUST publish a clearly expressed and up to date Privacy Policy about the
management of Personal Information by the Applicant.
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.
Where an Applicant is applying to, or has been, 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 information on:
The Applicant's Privacy Officer 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
The Applicant’s Privacy Champion MUST measure and document its performance against the
Privacy Management Plan relevant to TDIF at least annually
# OFFICIAL
OFFICIAL #
The Applicant MUST provide appropriate 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 Finance as part of initial accreditation and
annually thereafter as part of the Annual Assessment under TDIF: 07-Annual Assessment)
The privacy awareness training provided by the 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 Assessment on all High Risk Projects related to its
Identity System
The Applicant MUST maintain a register of the 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 version of the register, on its website.
3.4 Data Breach Response Management
If the Applicant is an APP Entity, the Applicant MUST:
If the Applicant is not an APP Entity, the Applicant MUST:
The Applicant MUST develop and maintain a Data Breach Response Plan that:
# OFFICIAL
OFFICIAL #
The Data Breach Response Plan MUST NOT be inconsistent with the Applicant’s Digital Identity
Fraud Control Plan or System Security Plan
3.5 Notification of Collection
The Applicant MUST notify or make people aware as required by APP 5.
The Applicant MUST notify Individuals that the Applicant may use the Individual’s information
to detect, manage and investigate Digital Identity Fraud Incidents.
3.6 Collection and use limitation
The Applicant MUST only collect Personal 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 information by lawful and fair means.
The Applicant MUST only collect Personal information from the Individual or their
representative, unless it is unreasonable or impractical to do so.
The Applicant MUST NOT use or disclose 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)
# OFFICIAL
OFFICIAL #
The Applicant MUST NOT use or disclose 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 Transparency Report MUST disclose:
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.
3.7 Limitation on use of behavioural information

The Applicant MUST only collect, use and disclose an Individual’s Behavioural Information to:
The Applicant MUST NOT sell an Individual’s Behavioural information to a third party.
3.8 Collection 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.
# OFFICIAL
OFFICIAL #
The Applicant MUST NOT collect, use, or disclose an Individual’s Biometric Information unless:
Subject to PRIV-03-08-02a, Biometric information MUST be destroyed
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
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
Finance.
When destroying Biometric Information, the Applicant MUST create and maintain a record that
the destruction of Biometric Information has occurred.
The Applicant MUST NOT use a Biometric 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 obtained from an Individual prior to disclosing
that individual’s Attributes to a Relying Party or any third party (including an Authoritative
Source).
that individual’s Attributes to a Relying Party or any third party.
# OFFICIAL
OFFICIAL #
If the Applicant is obtaining enduring Express 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 withdraw or vary their Express Consent
The Applicant MUST demonstrate how this Express Consent withdrawal or variation process is
straightforward and easy to use
The Applicant MUST include a clear description of the process to withdraw or vary the Express
Consent in the Applicant’s Privacy Policy
The Applicant MUST, at the time of obtaining enduring consent, notify Individuals
The Applicant MUST inform Individuals of other 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 complies with APP 8 - cross border disclosure of
Personal information.
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.
If it discloses Personal information to an overseas recipient that is not the individual, the
Applicant MUST demonstrate to Finance’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 unique identifier to a User for use across an
Identity federation
3.12 Access, correction and individual history log
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).
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.
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.
The Applicant MUST provide access at no cost to the Individual.
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.
The Applicant MUST allow Individuals to correct their Personal information it holds as set out in
APP 13.
# OFFICIAL
OFFICIAL #
The Applicant MUST provide Individuals with a simple and accessible means to access and
review their Personal information.
The Applicant MUST provide Individuals with clear instructions on how to update their Personal
information
3.13 Quality of personal information
An Applicant MUST take reasonable steps to ensure quality of Personal information as outlined
in APP 10.
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.
The Applicant MUST ensure updated or new Personal information is promptly added to
relevant existing records.
3.14 Handling Privacy Complaints
The Applicant MUST provide a complaints service for handling privacy complaints which:
3.15 Destruction and de-identification

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.1 Security governance
4.1.1 General
The Applicant MUST conduct an assessment of 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
# OFFICIAL
OFFICIAL #
Where exceptional circumstances prevent or affect the Applicant’s capability to implement a

TDIF requirement, the Applicant
4.1.2 Management Structures and Responsibilities

The Applicant MUST have an officer or senior employee of the Applicant as the designated
Chief Security Officer (CSO) or equivalent role who is responsible for:
The Applicant MUST empower the CSO or equivalent role to make and implement decisions
about
The Applicant MUST ensure Personnel are aware of their collective responsibility to foster a
positive security culture.
The Applicant MUST provide appropriate 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 Finance as part of initial accreditation and
annually thereafter as part of the Annual Assessment under TDIF: 07-Annual Assessment.
The Applicant MUST develop and use procedures that ensure:
The Applicant MUST maintain records of 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 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.
# OFFICIAL
OFFICIAL #
The Applicant MUST:
The Applicant MUST provide security advice to users on how to safeguard their Digital Identity,
Credentials, Personal information and Attributes.
4.1.3 System Security Plan
The Applicant MUST have in place a System Security Plan approved by the CSO to manage the
Applicant’s Cyber Security Risks
The System Security Plan MUST include
# OFFICIAL
OFFICIAL #
The Applicant MUST review and update its System Security Plan
This review MUST:
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.
4.1.4 Security Maturity Monitoring
The Applicant MUST assess the maturity of its 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 evidence to Finance of the maturity of the
Applicant’s capability to manage Cyber Security Risks.
4.2 Information security
4.2.1 Sensitive and Classified Information
The Applicant MUST:
The Applicant MUST ensure information it holds 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
4.2.2 Access to Information

The Applicant MUST enable appropriate access to Digital Identity Information. This includes
# OFFICIAL
OFFICIAL #
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.
The Applicant MUST record each occasion 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
4.2.3 Safeguarding information from Cyber Threats
The Applicant MUST mitigate common and emerging cyber threats, including, at a minimum, by
implementing and maintaining controls for:
The Applicant MAY consider implementing additional ASD Strategies to Mitigate Cyber Security
Incidents
4.2.4 Incident Management, investigations and reporting
The Applicant MUST implement and maintain 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 process for Personnel, Individuals, Enforcement
Bodies and other entities to report suspected Cyber Security Incidents confidentially
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 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 registration or update of a Digital Identity is likely
to create a Cyber Security Incident, the Applicant:
The Applicant MUST maintain documented 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 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 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 impacts the Applicants Identity System, the
Applicant MUST take reasonable steps to:
# OFFICIAL
OFFICIAL #
The Applicant MUST report Cyber Security Incidents which occur in connection with their
Identity System to Finance at least once every quarter.
The Applicant MUST include the following information when reporting Cyber Security Incidents
4.2.5 Support for victims of security incidents

The Applicant MUST implement a process which allows Individuals to notify them when they
suspect or become aware of a Cyber Security Incident.
The Applicant MUST provide (either directly or 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 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 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
4.2.6 Robust ICT Systems

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.
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.
The Applicant MUST NOT process, store or 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 (including software) incorporate processes for
generating Audit Logs.
At a minimum, Audit Logs MUST record the following events:
# OFFICIAL
OFFICIAL #
At a minimum, Audit Logs MUST include[1] the following details for each event:
Audit logs MUST include for each event:

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:
Each Audit Log MUST be
The Audit Logs MUST NOT contain Biometric information.

4.2.7 Disaster recovery and business continuity management
The Applicant MUST maintain a Disaster Recovery and Business Continuity Plan for its identity
system that covers:
# OFFICIAL
OFFICIAL #
The Applicant MUST test their Disaster Recovery and Business Continuity Plan as part of initial
accreditation and at least once every 12 months thereafter
4.2.8 Cryptography
The Applicant MUST use:
• Australian Signals Directorate Approved Cryptographic Algorithms (AACAs); and
• Australian Signals Directorate Approved Cryptographic Protocols (AACPs),
to protect all Digital Identity Information while in transit and at rest.
The Applicant MUST maintain a Cryptographic Key Management Plan for their identity system
which covers:
4.3 Personnel security

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 System
The Applicant MUST undertake pre-employment screening on such Personnel, including
The Applicant MUST assess and manage the ongoing suitability of its Personnel.
The Applicant MUST ensure that separating Personnel have their access to the Applicant’s
resources withdrawn, including:
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.
Where it is not possible to undertake required separation procedures, the Applicant MUST
undertake a risk assessment to identify any security implications and take reasonable steps to
mitigate any identified risks.
4.4 Physical security
The Applicant MUST implement physical security measures that minimise or remove the risk of:
The Applicant MUST protect its resources commensurate with the assessed business impact
level of their compromise, loss or damage.
The Applicant MUST assess security risks and select appropriate containers, cabinets, secure
rooms and strong rooms to protect information and assets.
The Applicant MUST dispose of physical assets securely, including by;
# OFFICIAL
OFFICIAL #
Chapter 5 Usability Requirements

5.1 Usability requirements
The Applicant MUST demonstrate how Users can also use other available channels if needed,
without repetition or confusion.
The Applicant MUST demonstrate how Users with low digital skills can have readily available
access to Assisted Digital support.
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.
The Applicant MUST allow Users to provide feedback, seek assistance or otherwise resolve
disputes or complaints in relation to the Applicant’s identity system.
The Applicant MUST create and maintain an 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 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 uncomplicated ways to learn about its identity system
on digital channels.
5.2 Requirements for the identity verification 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.
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 information on
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 MUST inform the User of:
# OFFICIAL
OFFICIAL #
If proofing is unsuccessful, the Applicant MUST provide the User with:
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
5.3 Requirements for the authentication journey
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
The Applicant MUST meet the requirements in Section 5.4.2 (Usability Test Plans) and Section
5.4.35 (Conduct Usability Testing) unless it can demonstrate to Finance that the Applicant has
The Applicant MUST document, by way of a Usability Test Plan, how it will conduct usability
testing.
The Applicant’s Usability Test Plan MUST:
# OFFICIAL
OFFICIAL #
The range of representative Individuals MUST be from a diverse range of gender classifications
5.5 Conduct usability testing

The Applicant MUST use experienced User 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 its Identity System as part of initial
accreditation and at least once every 12 months thereafter
The Applicant MUST conduct usability testing of 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 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 respond in writing to any recommendation
identified in the usability testing report including
The Applicant MUST provide the outcomes of its usability testing to Finance as part of initial
accreditation and annually thereafter as part of the Annual Assessment.
5.6 Accessibility requirements
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 supported by the
Applicant’s Identity System.
Chapter 6 Technical Testing Requirements
6.1 Technical test planning
# OFFICIAL
OFFICIAL #
For the Technical Testing that the Applicant is required to complete under this section, it MUST
provide Finance with the following:
The Applicant MUST develop a Requirements Traceability Matrix (RTM) which maps the tests
completed to the TDIF requirements they are being used to demonstrate compliance with.
The Applicant MUST provide Finance with a technical test report detailing the outcomes of the
Technical Testing done under this section, including:
The Applicant MUST demonstrate through Technical Testing how its Identity System meets the
following TDIF requirements:
The Applicant MUST demonstrate through testing how its Identity System meets the following
TDIF requirements:
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.
Chapter 7 Functional Assessments
7.1 Functional Assessment Requirements
# OFFICIAL
OFFICIAL #
The Applicant MUST ensure an Assessor conducts:
The Applicant MUST:
7.2 Assessor Skills, experience and independence

The Applicant MUST demonstrate to Finance how the Assessors have relevant, reasonable, and
adequate experience, training and qualifications to conduct the relevant Functional
Assessment.
The Applicant MUST demonstrate to Finance how the Assessors:
The Applicant MUST ensure Assessors have access to and consider all relevant evidence
provided by the Applicant to Finance. This includes any responses by Finance to questions
which may have been asked.
The Functional Assessments MUST include:
If required by an Assessor or Finance, the 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 prepares a report on the outcomes of the
relevant Functional Assessment that includes:
7.4 Functional Assessment Report
# OFFICIAL
OFFICIAL #
The Applicant MUST document the outcomes of each Functional Assessment in a Functional
Assessment Report. The Applicant’s Functional Assessment Report MUST include, for each
Functional Assessment:
The Applicant MUST:
The Applicant’s Accountable Executive MUST respond in writing to each recommendation, risk
and non-compliance outlined in the Functional Assessment Report including:
# OFFICIAL
OFFICIAL #
Any recommendation, risk or non-compliance 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 Finance will not grant TDIF accreditation until the items
required in ASSESS-07-04-03b are complete and Finance 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 above in ASSESS-07-04-03a, the Accredited
Provider MUST confirm:
7.5 Privacy Assessment

The Applicant MUST commission an Assessor to 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 under ASSESS-07-05-01 MUST:
The Applicant MUST commission an Assessor to conduct a Privacy Assessment (which is

separate to and follows on from the PIA under ASSESS-07-05-01) as part of initial accreditation
and annually thereafter as part of the Annual Assessment. The Privacy Assessment MUST:
7.6 Security Assessment and penetration test
# OFFICIAL
OFFICIAL #
The Applicant MUST commission an Assessor to conduct a Security Assessment of its Identity
System to identify security deficiencies as part of initial accreditation and annually thereafter as
part of the Annual Assessment. The Security Assessment must, at a minimum:
The Applicant MUST commission an Assessor to conduct a Penetration test of:
7.7 Accessibility Assessment

The Applicant MUST commission an Assessor to conduct an Accessibility Assessment as part of
initial accreditation and annually thereafter as part of the Annual Assessment, which MUST, at a
minimum, assess whether the Applicant’s Identity System:
TDIF: 05 - Role Requirements
Chapter 2 Common Role Requirements

The Applicant MUST have user terms in place between the Applicant and each user that
include:
The Applicant MUST NOT have user terms that are inconsistent with the user terms required
under the TDIF.
Chapter 2 Identity Service Provider Requirements
Section 3.2 Identity Proofing
# OFFICIAL
OFFICIAL #
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
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.
3.3 Individuals unable to meet Identity Proofing Requirements

The Applicant MAY implement alternative Identity Proofing processes to the requirements set
out in Table 1 to support Exceptional Use Cases
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
Before implementing an alternative identity proofing process under IDP-03-03-01, the Applicant
MUST:
3.4 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.
If the Applicant supports Identity Proofing Lifecycle Management , then the Applicant MUST
implement the following requirements for the operation of Identity Proofing Lifecycle
Management.
# OFFICIAL
OFFICIAL #
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).
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 Proofing Lifecycle Management and subject to TDIF
Req: IDP-03-04-03a, the Applicant MUST:
To verify the link between the User and their Digital Identity, the Applicant MUST either:
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.
3.5 Identity proofing Step-Up

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.
The Applicant MUST be accredited to conduct an Identity Proofing Process at the higher
Identity Proofing Level.
# OFFICIAL
OFFICIAL #
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.
3.6 Attribute collection, verification and validation
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]
3.7 Attribute disclosure
The Applicant MUST limit disclosure of Attributes to an Authoritative Source to Attributes listed
in Table 2 .
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.
The Applicant MUST seek permission from Finance to disclose Attributes beyond those listed in
IDP-03-07-02.
3.8 Biometric verification 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 by performing either:
The Applicant MUST consider fraud and security risks, and the associated mitigation strategies
and treatments, related to performing Biometric Binding when developing their Fraud Control
Plan and System Security Plan, including the following risks (where applicable):
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 Finance.
# OFFICIAL
OFFICIAL #
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
If the Applicant is required to have a Biometric Testing Entity test their Biometric Capability by
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.
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 Applicant MUST capture an Acquired Image and
perform at least one of the following:
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 Finance the characteristics used in generating the Image Quality
Profile as a part of the initial Accreditation.
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.
# OFFICIAL
OFFICIAL #
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 Finance .
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.
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 Finance, who will make a qualitative
assessment of whether the PAD technology is fit for purpose.
3.8.3 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 Individual is in the physical presence of an
Assessing Officer, and MUST be achieved by the Assessing Officer performing one or more of
the following biometric matching processes:
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.
# OFFICIAL
OFFICIAL #
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.
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.
As a part of the initial TDIF Accreditation Process the Applicant MUST provide the report to
Finance 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.
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.
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.
# OFFICIAL
OFFICIAL #
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 Finance as part of initial accreditation and
annually thereafter as part of the Annual Assessment under TDIF: 07-Annual Assessment.]
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.
Chapter 4 Credential Service Provider Requirements
4.1 Credential Levels
The Applicant MUST support at least one of the Credential Levels described in Table 4.. [Table 4
of TDIF: 05 Role Requirements]
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.
The Applicant MUST ensure that Credentials presented are valid or active and that they are not
expired or revoked prior to authenticating the Individual.
Where unusual transactions are detected the Applicant MUST verify the Credential is still under
the control of its legitimate owner.
When requested by the Individual the Applicant MUST prevent the continued use of a
Credential (e.g. temporary suspension while traveling abroad).
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.
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).
4.2.1 Memorised Secrets
If Memorised Secrets are supported, then the Applicant MUST implement the following
requirements for the operation of Memorised Secrets.
Memorised secrets MUST be at least 8 characters in length if chosen by the Individual.
# OFFICIAL
OFFICIAL #
Memorised secrets chosen randomly by the Applicant MUST be at least 6 characters in length
and MAY be entirely numeric.
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 Secret based on its appearance on the list
described in CSP-04-02-01d , the Applicant MUST:
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.
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.
4.2.2 Look-up secrets
If Look-up Secrets are supported, then the Applicant MUST implement the following
requirements for the operation of look-up secrets.
A Applicant creating look-up secrets MUST deliver them securely to the subscriber.
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.
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.
The Applicant MUST store Look-up Secrets in a form that is resistant to offline attacks by
ensuring that:
# OFFICIAL
OFFICIAL #
The Applicant MUST store both the salt value and the resulting hash for each look-up secret.
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.
4.2.3 Out-of-band devices
If Out-of-band Devices are supported, then the Applicant MUST implement the following
requirements for the operation of out-of-band devices.
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 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).
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:
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.
The Applicant MUST NOT store the identifying key itself.
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.
# OFFICIAL
OFFICIAL #
Depending on the type of out-of-band device, one of the following options (1, 2, OR 3) MUST
take place:
In all cases, the authentication MUST be considered invalid if not completed within 10 minutes.
To provide replay resistance, the Applicant MUST accept a given authentication secret only
once during the validity period.
The Applicant MUST generate random authentication secrets with at least 20 bits of entropy.
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.
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.
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.
4.2.4 Single-factor one-time password (OTP) devices

If single-factor OTP devices are supported, the Applicant MUST implement the following
requirements to operate single-factor OTP devices.
The secret key and its algorithm MUST provide at least the minimum-security strength specified
in the latest edition of the ISM.
The nonce MUST be of sufficient length to ensure that it is unique for each operation of the
device over its lifetime.
OTP credentials MUST NOT facilitate the cloning of the secret key onto multiple devices.
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.
The OTP value associated with a given nonce MUST be accepted only once.
# OFFICIAL
OFFICIAL #
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.
The Applicant MUST use AACAs and an authenticated protected channel when collecting the
OTP to provide resistance to eavesdropping and MitM attacks.
To provide replay resistance, the Applicant MUST accept a given time-based OTP only once
during the validity period.
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.
If the authentication output has less than 64 bits of entropy, the Applicant MUST implement a
4.2.5 Multi-factor one-time password devices
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.
The secret key and its algorithm MUST provide at least the minimum -security strength
specified in the latest edition of the ISM.
The nonce MUST be of sufficient length to ensure that it is unique for each operation of the
device over its lifetime.
OTP authentication MUST NOT facilitate the cloning of the secret key onto multiple devices.
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.
Any memorised secret used for activation MUST be a randomly chosen numeric secret at least
6 decimal digits in length.
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.
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.
The Applicant MUST use AACAs and an authenticated protected channel when collecting the
OTP to provide resistance to eavesdropping and MitM attacks.
The Applicant MUST also establish that the Credential is a MF OTP device.
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.
To provide replay resistance, the Applicant MUST accept a given time-based OTP only once
during the validity period.
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.
The Applicant MAY also warn the Individual in an existing session of the attempted duplicate
use of an OTP.
If the authentication output has less than 64 bits of entropy, the Applicant MUST implement a
# OFFICIAL
OFFICIAL #
4.2.6 Single-factor cryptographic software

If single-factor cryptographic software is supported, then the Applicant MUST implement the
following requirements for the operation of single-factor cryptographic software.
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.
Single-factor cryptographic software credentials MUST NOT facilitate the cloning of the secret
key onto multiple devices.
Keys MUST be protected against modification.
Keys MUST be protected against unauthorised disclosure.
The challenge nonce MUST be at least 64 bits in length.
The challenge nonce MUST either be unique over the credential’s lifetime or be statistically
unique.
The authentication event MUST use approved cryptography (i.e. AACAs and AACPs).
4.2.7 Single-factor cryptographic devices
If single-factor cryptographic devices are supported, then the Applicant MUST implement the
following requirements for the operation of single-factor cryptographic devices.
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).
The secret key and its algorithm MUST provide at least the minimum-security length specified
The challenge nonce MUST either be unique over the credential’s lifetime, or be statistically
unique.
Approved cryptography (i.e., AACAs and AACPs) MUST be used.
4.2.8 Multi-factor cryptographic software
If multi-factor cryptographic software is supported, then the Applicant MUST implement the
following requirements for the operation of multi-factor cryptographic software.
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.
Authentication events MUST require the input of both factors.
Any memorised secret used for activation MUST be a randomly chosen numeric value at least 6
decimal digits in length.
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.
The challenge nonce MUST either be unique over the credential’s lifetime or, be statistically
unique.
The authentication event MUST use approved cryptography (i.e. AACAs and AACPs).
Truncation MUST NOT be performed on the memorised secret used for activation.
4.2.9 Multi-factor cryptographic devices
# OFFICIAL
OFFICIAL #
If multi-factor cryptographic device is supported, the Applicant MUST implement the following
requirements for the operation of multi-factor cryptographic devices.
The secret key and its algorithm MUST provide at least the minimum-security length specified
The challenge nonce MUST either be unique over the Credential’s lifetime or, be statistically
unique.
Approved cryptography (i.e., AACAs and AACPs) MUST be used.
4.3 General credential requirements
4.3.1 Physical credentials
If physical Credentials are supported, the Applicant MUST implement the following
requirements to operate physical Credentials.
The Applicant MUST provide the Individual with instructions on how to appropriately protect
the credential against theft or loss.
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.
4.3.2 Rate limiting (throttling)
The Applicant MUST implement rate limiting (or throttling) for all credentials.
The Applicant MUST implement controls to protect against online guessing attacks.
The Applicant MUST limit consecutive failed authentication attempts on a single account to no
more than 100.
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.
When the individual successfully authenticates, the Applicant MAY disregard any previous
failed attempts for that user from the same IP address.
4.3.3 biometrics (for authentication use)
If biometrics for authentication use are supported, then the Applicant MUST implement the
following biometrics requirements for the operation of biometrics for authentication use.
Biometrics MUST be used only as part of multi-factor authentication with a physical Credential.
An authenticated protected channel between sensor and Applicant MUST be authenticated
prior to capturing the biometric sample from the Individual.
The biometric system MUST operate with a False-Match-Rate (FMR) of 1 in 1000 or better.
# OFFICIAL
OFFICIAL #
This FMR MUST be achieved under conditions of a conformant attack (i.e., zero-effort impostor
attempt) as defined in ISO/IEC 30107-1.
The biometric system MUST implement Presentation Attack Detection (PAD).
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.
Testing of presentation attack resistance MUST be in accordance with Clause 12 of ISO/IEC
30107-3:2017.
The PAD decision MAY be made either locally on the Individual’s device or by the Applicant.
The biometric system MUST allow no more than 5 consecutive failed authentication attempts
or 10 consecutive failed attempts.
Once the limit of consecutive failed attempts has been reached, the biometric system MUST
either:
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).
If supported, Biometric comparison that is performed centrally MUST implement the following:
4.3.4 Credential Attestation

If credential attestation is supported, the Applicant MUST implement the following
requirements for the operation of credential attestation.
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.
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.
4.3.5 CSP-impersonation resistance
# OFFICIAL
OFFICIAL #
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.
A CSP-impersonation resistant authentication protocol MUST establish an authenticated
protected channel with the Applicant.
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).
The Applicant MUST validate the signature or other information used to prove CSP-
impersonation Resistance.
AACAs MUST be used to establish CSP-impersonation Resistance.
Keys used for this purpose MUST provide at least the minimum-security strength specified in
the latest edition of the ISM.
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.
4.3.6 IdP-CSP communications
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).
4.3.7 CSP-compromise resistance
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.
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).
Keys MUST provide at least the minimum-security strength specified in the latest version of the
ISM.
4.3.8 Authentication intent
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.
Authentication intent MUST be established by the Credential itself.
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.
4.3.10 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.
If a Applicant supports the use of a Restricted Credential, it MUST:
# OFFICIAL
OFFICIAL #
4.4 Credential lifecycle management

4.4.1 Credential binding
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.
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.
The Applicant MUST maintain the information required for throttling authentication attempts
when required.
The record created by the Applicant MUST contain the date and time the Credential was bound
to the account.
The record MUST include information about the source of the binding (e.g., IP address, device
identifier) of any device associated with the enrolment.
The record MUST also contain information about the source of unsuccessful authentications
attempted with the Credential.
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.
4.4.2 Binding at enrolment
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:
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:
# OFFICIAL
OFFICIAL #
4.4.3 Binding additional Credentials

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.
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.
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).
The Applicant MAY limit the number of Credentials that may be bound in this manner.
4.4.4 Binding to a User-provided credential
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.
4.4.5 Renewal
The Applicant MAY bind an updated Credential a reasonable amount of time before an existing
Credential’s expiration.
Following successful use of the new Credential, the Applicant MAY revoke the Credential that it
is replacing.
4.5 Loss, theft, damage and unauthorised duplication
The suspension, revocation or destruction of a compromised Credential MUST occur as

promptly as practical following detection of loss, theft, damage or unauthorised duplication.
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.
If the Applicant implements CSP-04-05-02, then the backup Credential MUST be either a
Memorised Secret or a physical Credential.
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.
The Applicant MAY set a time limit after which a suspended Credential can no longer be
reactivated.
4.6 Credential expiration
The Applicant MAY issue Credentials that expire.
When a Credential expires, it MUST NOT be usable for authentication.
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.
4.7 Credential revocation and termination
# OFFICIAL
OFFICIAL #
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.
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.
4.8 Session management
A session MAY be started in response to an authentication event and continue until such time
that it is terminated.
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.
The Session MAY be continued through a re-authentication in accordance with the
requirements in section 4.9.
4.9 Reauthentication
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.
Session secrets MUST be non-persistent.
Session secrets MUST NOT be retained across a restart of the associated application or a reboot
of the host device.
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).
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.
4.10 Credential Step-Up
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 identity account as a result of Step-up, the Applicant
MUST ensure that the new Credential:
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.
4.11 Certificate Authorities

If Certification Authorities are supported, then the Applicant MUST implement all of the
following requirements to operate as a Certification Authority.
# OFFICIAL
OFFICIAL #
The Applicant MUST ensure all:
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.
The Applicant MUST implement a process to allow Individuals to request revocation of their
Digital Certificate.
The Applicant MUST implement revocation procedures for the following situations:
Chapter 5 Attribute Service Providers

The Applicant MUST support at least one Attribute Class as described in Table 6. [pg 25 of TDIF:
05 Role Requirements]
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.
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.
Where the Applicant manages Attributes on behalf of an Authoritative Source, it MUST provide
evidence of this arrangement to Finance.
[Evidence of this arrangement will be requested by Finance as part of initial accreditation and
annually thereafter as part of the Annual Assessment.]
# OFFICIAL
OFFICIAL #
The Applicant MUST ensure every Attribute it issues or manages is uniquely identifiable.
The Applicant MUST manage and provide up-to-date, relevant and accurate Attributes.
If the Applicant is an Authoritative Source for an Attribute, the Applicant MUST verify all
requests to update relevant Attributes prior to making changes.
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 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.
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.
The Applicant MAY support issuing or linking multiple Individuals to the same Attribute.
Chapter 6 Identity Exchange Requirements
6.1 Audit Logging Requirements
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.
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).
6.2 Consent Management
In accordance with PRIV-03-09-03, the Applicant MUST maintain the following information as
part of its Audit Logs:
6.3 Single Sign On/Single Log out

If single sign on is supported, then the Applicant MUST implement the following requirements
to operate single sign on.
The Applicant MUST support the ability for a Relying Party to request that a User authenticates
regardless of whether a pre-existing session exists.
The Applicant MUST implement a single log out mechanism according to the Federation
Protocol that it supports.
The Applicant MAY securely cache Attributes from an Identity Service Provider for the duration
of an authenticated session to support single sign on.
# OFFICIAL
OFFICIAL #
If the Applicant securely caches attributes as per IDX-06-03-03, these attributes MUST NOT be
accessible to the Applicant’s Personnel.
The Applicant MAY restrict the expiration period for an authentication session to manage
security risks.
6.4 User Dashboard
If a User Dashboard is supported, then the Applicant MUST implement the following
requirements for the operation of a User Dashboard.
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.
The Applicant MUST NOT store Attributes of the Individual after the Individual’s session at the
User Dashboard has been terminated.
6.5 IdP Selection
If IdP Selection is supported, the Applicant MUST implement the following requirements for the
operation of IdP Selection.
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.
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.
Express Consent MUST be obtained from the Individual prior to offering the mechanism
described in IDX-06-05-02.
The Individual MUST have the ability to opt out of using the mechanism described in IDX-06-05-
02.
# OFFICIAL
OFFICIAL #
Sub-Requirement A C I X
A C I X
A C I X
A C I X
A C I X
A C I X
C I
• web responsive design (e.g. can be accessed through an A C I X

internet browser)
• a mobile application (e.g. the Identity Facility is a mobile
application)
• a component of either of the above (e.g. a white label service
A C I X
# OFFICIAL
OFFICIAL #
A C I X
A C I X
a) Be written for an operational Identity System, regardless of A C I X

whether the Applicant’s Identity System is operational or not.
b) summarise the fraud control, privacy, protective security and A C I X

user experience features of the identity system.
c) Provide a high-level summary of how the Applicant will meet the A C I X
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 A C I X

Security Manual used as its basis (i.e. month and year).
a. Estimated dates when Functional Assessments and any other A C I X
required testing will be undertaken
b. Estimated dates when Functional Assessment Reports will be A C I X
provided to Finance
c. Estimated dates when the Applicant’s other required evidence A C I X
addressing TDIF requirements will be provided to Finance
A C I X
A C I X
A C I X
• A filled out TDIF Exemption Request Form signed by the A C I X

Applicant’s Accountable Executive
• A date of expiry or review of the Exemption Request that is not A C I X
more than 12 months from the date of the request; and
• Any supporting information or statements for the risk A C I X
assessment and mitigation measures.
# OFFICIAL
OFFICIAL #
A C I X
a) Which Functional Assessment or TDIF requirements it is provided A C I X

as evidence for
b) A rationale for why the Alternative Assessment Report should be A C I X
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: A C I X
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).
A C I X
A C I X
A C I X
A C I X
• The name, role/position and contact details of the Accountable A C I X

Executive
• A statement that the Accredited Provider’s Identity System A C I X

complies with the assessed TDIF requirements
• The version of the TDIF the Accredited Provider is assessed and A C I X
accredited under for the Initial Assessment18 .
A C I X
• a statement confirming it has provided Finance 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 A C I X
accurate representation of its Identity System
# OFFICIAL
OFFICIAL #
A C I X
• 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.
A C I X
a) managing Digital Identity Fraud Risks within its organisation; A C I X

and
b) ensuring the Applicant complies with the fraud control A C I X
requirements in this section
A C I X
a) Determine the Applicant’s tolerance for Digital Identity Fraud A C I X

Risks.
b) Manage the Applicant’s Digital Identity Fraud Risks, including by A C I X
complying with the requirements of this section.
c) Demonstrate how its Digital Identity fraud controls are applied A C I X
to its Identity Facility.
d) Take all reasonable measures to prevent, detect and deal with A C I X
Digital Identity fraud relating to its Identity System.
# OFFICIAL
OFFICIAL #
e)Consider the implications their risk management decisions have A C I X

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 Finance of the circumstances A C I X

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
b) MUST keep a record of decisions taken by the Applicant in A C I X

relation to such non compliance and remedial action (if any). These
decisions will be requested by Finance during Annual Assessments
c) MAY vary the Applicant’s Digital Identity fraud control A C I X

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.
A C I X
a) Fraud control goals and strategic objectives of the Applicant, A C I X

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 Fraud Risk A C I X

management and maintain a positive risk culture
c) Applicant’s tolerance of Digital Identity Fraud Risks. A C I X
d) Digital Identity Fraud threats, risks and vulnerabilities that A C I X
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 Digital Identity A C I X

Fraud Risks.
f) Treatment strategies and controls put in place to manage Digital A C I X
Identity fraud threats, risks and vulnerabilities.
A C I X
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.
# OFFICIAL
OFFICIAL #
A C I X
h) Procedures and mechanisms for Digital Identity Fraud Incident
management, fraud investigations and reporting Digital Identity
Fraud Incidents.
i) An outline of key roles and responsibilities for Digital Identity A C I X
Fraud Control within the Applicant’s organisation
A C I X
j) The risk ratings and scale to be used by the Applicant when

assessing the severity of a Digital Identity Fraud Incident.
A C I X
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 to the use A C I X
of Biometric Information.
m) Where applicable, a description of the location(s) from which A C I X
Local Biometric Binding will be undertaken by the Applicant
a) at least annually; and A C I X
A C I X
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
a) Determine the adequacy of existing fraud control measures and A C I X
mitigation controls
b) Respond to and manage shifts in the Applicant’s risk, threat and A C I X
operating environment
# OFFICIAL
OFFICIAL #
A C I X
a) before such Personnel start work on those duties A C I X
b) and at least once every 12 months thereafter A C I X

A C I
a) provide advice to Users on how to avoid such incidents or risks; A C I

or
b) if Users do not interact directly with the Applicant or the A C I
Applicant’s Identity System, take reasonable steps to support the
provision of such advice by another Accredited Provider or Relying
Party
A C I X
A C I X
A C I X
A C I
MUST NOT allow a new registration or update of that Digital A C I

Identity to be completed
MUST block the use of the Digital Identity on its Identity System A C I
a) investigate actual and suspected Digital Identity Fraud Incidents, A C I X

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 Applicant in A C I X
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
a) mitigate the adverse effects of the incident; and A C I X
# OFFICIAL
OFFICIAL #
b) eliminate or, if it cannot be eliminated, minimise, the risk of A C I X

recurrence of similar incidents
A C I X
a) decisions to use civil, administrative or disciplinary procedures, or A C I X

to take no further action in response to a suspected Digital Identity
Ffraud Iincident; and
b) the Applicant’s investigation of and responses to actual and A C I X
suspected Digital Identity Fraud Incidents
A C I X
A C I X
a) provide Finance with a report on Digital Identity Fraud Incidents A C I X

at least once every quarter; or
b) if the Digital Identity Information held by the Applicant in A C I X
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.
a) the number of Digital Identity Fraud Incidents related to the A C I X

Applicant in the period since the last report. The number of such
incidents may be zero
b) a description of the type or types of Digital Identity Fraud A C I X
Incidents and their severity; and
c) a description of the measures taken by the Applicant in response A C I X
to the incidents covered by the report
A C I
A C I
A C I
A C I X
# OFFICIAL
OFFICIAL #
a) the Privacy Act applies to that action or practice as if the A C I X

Applicant were an organisation within the meaning of that Act; or
b) a law of a State or Territory that provides for all of the A C I X

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 an A C I X
agreement with Finance, 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.
A C I X
a) Handling of internal and external privacy enquiries and A C I X

complaints.
b) Handling requests for access to and correction of Personal A C I X

information
c) Maintaining a record of Personal information holdings A C I X
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 Assessments A C I X

(PIAs)
e) Maintaining a register of PIAs. A C I X
f) Reviewing and, where relevant, updating the Privacy Policy at A C I X
least annually in accordance with PRIV-03-02-05
A C I X
A C I X
a) approves its Privacy Management Plan; A C I X
# OFFICIAL
OFFICIAL #
b) reviews the Applicant’s progress against the Privacy Management A C I X

Plan as described in PRIV-03-02-07
c) provides regular reports to the Applicant’s executive on privacy A C I X
issues; and
d) provides leadership within the Applicant on broader strategic A C I X
privacy issues
A C I X
A C I X
A C I X
a) The kinds of Personal information that the Applicant collects and A C I X

holds
b) How the Applicant collects and holds Personal information A C I X
c) The purposes for which the Applicant collects, holds, uses and A C I X
discloses Personal information.
d) How an Individual can access Personal information about A C I X
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 APPs(or a A C I X
particular jurisdiction privacy principle) and how the Applicant will
deal with such a complaint.
f) Whether the Applicant is likely to disclose Personal information to A C I X
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 Policy A C I X

which covers the Applicant’s Identity System at least annually and
ensure that the Privacy Policy is updated where required promptly
following such review.
A C I X
A C I X
# OFFICIAL
OFFICIAL #
a) before such Personnel start work on those duties; and A C I X
b) at least once every 12 months thereafter A C I X

A C I X
A C I X
A C I X
A C I X
a) report eligible data breaches to affected Individuals and the A C I X

Information Commissioner as required under the Privacy Act ; and
b) if required to notify the Information Commissioner—provide A C I X

Finance with a copy of the report at the same time it is provided to
the Information Commissioner
a) if the Applicant is a department or authority of a State or A C I X
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 Finance 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 Applicant A C I X

MUST comply with PRIV-03-04-01 as if the Applicant were an APP
Entity.
a) includes a description of the actions to be taken if a data breach A C I X
is suspected, discovered, or reported by Personnel or external party
b) lists the roles and responsibilities of Personnel involved in A C I X

managing a data breach; and
# OFFICIAL
OFFICIAL #
c) includes a clear communication plan and information about A C I X

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
A C I X
A C I X
A C I X
A C I X
A C I X
A C I X
A C I X
# OFFICIAL
OFFICIAL #
A C I X
a) the name of each Enforcement Body that has requested Digital X

Identity Information from the Applicant since the previous report;
b) the total number of such requests received by the Applicant; X

c) details of the type or kind of Digital Identity Information X
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 X
providing Digital Identity Information in response to the request.
X
a) provide the services for which the Applicant is seeking A C I X

accreditation
b) comply with a requirement or authorisation under a law of the A C I X
Commonwealth, a state or territory
c) support Digital Identity fraud management functions; or A C I X
d) improve the performance or usability of the Applicant’s Identity A C I X
System
A C I X
C I
# OFFICIAL
OFFICIAL #
A C I X
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 conducting Biometric Binding as part of an Identity
Proofing Process or authenticating the Individual to their Digital
Identity; or
A C I X
b) The Biometric Information is being collected, used or disclosed
for the purposes of creating a government issued Identity
document.
a) if collected by an Identity Service Provider for the purpose of C I
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 C I

Consent of an Individual for the purpose of authenticating that
Individual to their Digital Identity, immediately after the consent is
withdrawn
For example where a Road Traffic and Transport Authority is an

Identity document issuer and an Identity Service Provider.
C I
C I
A C I X
C I
A C I X
5 If the Attribute Service Provider connects directly with a Relying A

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 connects directly with a Relying I

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.
# OFFICIAL
OFFICIAL #
7 If the connection to the Relying Party is brokered by an Identity X

Exchange, the Identity Exchange may delegate the collection of
Express Consent to the Identity Service Provider or Attribute Service
Provider.
A C I X
A C I X
A C I X
A C I X
a) that providing enduring Express Consent is optional A C I X

b) of the implications of providing or not providing their enduring A C I X
Express Consent; and
c) of the process for withdrawing or varying their enduring A C I X
Express Consent.
A C I X
A C I X
A C I X
A C I X
A C I X
A C I X
A C I X
A C I X
A C I X
A C I X
A C I X
# OFFICIAL
OFFICIAL #
A C I
A C I
A C I X
A C I
A C I
a) is readily accessible, including prominent contact information A C I X

about the service.
b) is fair, including a process that is impartial, confidential and A C I X
transparent.
c) has a process that is timely, clear and can provide a remedy A C I X
where applicable.
d) has skilled and professional people who have knowledge of A C I X
privacy laws and these TDIF privacy requirements and the complaint
service process.
e) is integrated with other complaint handling bodies, (e.g. other A C I X
Participants of an identity federation) as required, so it can assist
the individual and refer complaints.
A C I X
A C I X
a) Determine and record the Applicant’s tolerance for Cyber A C I X

Security Risks
b) Manage the Applicant’s Cyber Security Risks, including by A C I X
complying with the requirements of this section
c) Demonstrate how its protective security controls (including A C I X
controls for Cyber Security Risks) are applied to its Identity System
d) Consider the implications their risk management decisions have A C I X

for Accredited Providers, Relying Parties and Users and share
information on risks with them where appropriate
# OFFICIAL
OFFICIAL #
a) MUST, as soon as practicable notify Finance of the circumstances A C I X

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
b)MUST keep a record of decisions taken by the Applicant in A C I X

relation to such non-compliance and remedial action (if any). These
decisions will be requested by Finance during Annual Assessments
a) MAY vary the Applicant’s protective security arrangements A C I X

(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.
a) managing Cyber Security Risks within their organisation; and A C I X
b) ensuring the Applicant complies with the protective security A C I X

requirements in this section.
a) Appointing security advisors within the Applicant’s organisation A C I X
to support the CSO in the day-to-day delivery of protective security
services
b) The Applicant’s protective security planning. A C I X
c) The Applicant’s protective security practices and procedures. A C I X
d) Investigating, responding to and reporting on Cyber Security A C I X
Incidents
A C I X
a) before such Personnel start work on those duties ; and A C I X
b)at least once in every 12 months thereafter. A C I X

a) All elements of the Applicant’s System Security Plan are achieved. A C I X
b) Cyber security incidents are investigated, responded to and A C I X

reported to Finance.
c) Relevant security policy or legislative obligations are met. A C I X
A C I X
A C I X
# OFFICIAL
OFFICIAL #
a) maintain a monitored central communications channel (such as A C I X

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 channel and A C I X

the purposes for which it is to be used
A C I
A C I X
a) The Cyber security goals and strategic objectives of the A C I X

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 Risk A C I X

management and maintain a positive Cyber Security Risk culture
c) The Applicant’s tolerance of Cyber Security Risks A C I X
d) The Personnel, information, ICT and assets that are critical to the A C I X
ongoing operation of the Applicant’s Identity System
e) The maturity of the Applicant’s capability to manage Cyber A C I X
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 impact the A C I X
confidentiality, integrity and availability of the Applicant’s Identity
System
g) An assessment of the significance of the threats, risks, and A C I X
vulnerabilities in paragraph (f).
h) The treatment strategies and controls put in place to manage A C I X
Cyber Security Risks and vulnerabilities
i) The strategies to ensure the Applicant meets its training and A C I X
awareness needs in relation to the prevention and management of
Cyber Security Risks
j)Details of the training that will be provided under paragraph (i); A C I X
k) The procedures and mechanisms for Cyber Security Incident A C I X
management, cyber security investigations and reporting Cyber
Security Incidents.
l) An outline of key roles and responsibilities for protective security A C I X
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 necessary A C I X

to meet variations in threat levels, including changes in the national
terrorism threat level.
# OFFICIAL
OFFICIAL #
n) The risk ratings and scale to be used by the Applicant when A C I X

assessing the severity of a Cyber Security Incident.
o) Where applicable, a description of the location(s) from which A C I X
Local Biometric Binding will be undertaken by the Applicant.
a)at least annually; and A C I X
b) as soon as practicable after: A C I X
(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
a) Determine the adequacy of existing protective security control A C I X

measures and mitigation controls.
b) Respond to and manage significant shifts in the Applicant’s risk, A C I X
threat and operating environment.
A C I X
A C I X
A C I X
a) Identify Digital Identity Information in the possession or control A C I X

of the Applicant
b) Assess the sensitivity of such information and the importance of A C I X
the information to the Applicant’s Identity System
c) Implement appropriate controls to secure such information A C I X
against loss, interference, misuse, unauthorised access,
unauthorised modification or unauthorised disclosure
A C I X
a) Ensuring that access to Sensitive information, Digital Identity A C I X

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
# OFFICIAL
OFFICIAL #
b) Controlling access (including remove access) to supporting ICT A C I X

systems, networks, infrastructure, devices and applications used by
the Applicant in connection with its Identity System.
A C I X
A C I X
a) application control A C I X
b) patching applications A C I X
c) restricting administrative privileges; and A C I X
d)patching operating systems; A C I X
A C I X
A C I X
A C I X
A C I X
A C I X
a) MUST NOT allow a new registration or update of that Digital A C I

Identity to be completed;
b) MUST block the use of the Digital Identity on its Identity A C I
System.
A C I X
A C I X
A C I X
A C I X
a) mitigate the adverse effects of the incident; and A C I X
# OFFICIAL
OFFICIAL #
b) eliminate or, if it cannot be eliminated, minimise, the risk of A C I X

recurrence of similar incidents.
A C I X
a) the number of Cyber Security Incidents which occurred in A C I X

connection with the Applicant’s Identity 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 Incidents A C I X
and their severity; and
c) a description of the measures taken by the Applicant in A C I X

response to the incidents covered by the report.
A C I X
A C I X
A C I X
A C I
A C I X
A C I X
A C I X
A C I X
• Successful and failed elevation of privileges by Personnel. A C I X

• User and group additions, deletions and modification to A C I X
permissions.
# OFFICIAL
OFFICIAL #
• Security related system alerts and failures (e.g. attempted access A C I X

that is denied, crashes or error messages).
• Unauthorised access attempts to critical systems and files. A C I X
for an Identity Service Provider, the binding of Attributes to a Digital I
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.
• The date and time A C I X
• The relevant User, identifier or process. Each activity must have a A C I X
unique identifier.
• The description. A C I X
• The ICT equipment involved. A C I X
• The source IP address of the device that authenticated to the A C I X
identity system.
• The source port used to perform the authentication event. A C I X
• The destination IP address used to perform the authentication A C I X
event.
• The destination port used to perform the authentication event. A C I X
• The User Agent String which identifies the browser and operating A C I X
system of the attempted authentication.
A unique identifier for the device being used in the event (such as A C I X
an 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

I
a) Interaction type. (e.g. OIDC Authentication Request and X

response)
Unique interaction identifier X
(b) The name of the Identity Service Provider or a Relying Party. X
(c) Any unique identifier used in the activity X
(d) Names of any Attributes requested and returned. X
(e) Any Identity Proofing Level or Credential Level requested and X
returned.
a) Protected and stored to ensure the accuracy and integrity of data A C I X
captured or held.
b) Protected from unauthorised access, modification and A C I X
deletion.
c) Retained for a minimum of 3 years from the date it was A C I X
generated.
A C I X
A C I X
a) Business continuity governance.
b) Training requirements for recovery team members. A C I X
# OFFICIAL
OFFICIAL #
c) Recovery objectives and priorities. A C I X

d) Continuity strategies. A C I X
e) Testing requirements and restoration procedures. A C I X
A C I X
A C I X
a) Cryptographic key lifecycle management over the lifecycle of the A C I X

key (generation, delivery, renewal, revocation, etc).
b) Details of the records that will be generated by the Applicant in A C I X
relation to its use of keys and how records will be maintained and
audited.
c) The conditions under which compromised keys will be declared. A C I X
d) Maintenance of cryptographic components. A C I X

e) Evidence of cryptographic evaluations undertaken. A C I X
A C I X
a) Verifying the identity of Personnel. A C I X

b) Confirming eligibility of such Personnel to work in Australia. A C I X
A C I X
A C I X
a) Physical facilities.
b) ICT systems. A C I X
A C I X
A C I X
A C I X
a) Harm to Individuals
A C I X
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
A C I X
a) resetting combination locks to factory settings; A C I X

b) removing all contents from physical assets and performing a A C I X
visual inspection to confirm such removal; and
# OFFICIAL
OFFICIAL #
c) sanitising or destroying ICT. A C I X
A C I
A C I
A C I X
A C I X
A C I X
A C I X
A C I X
a) the required Identity documents; I

b) whether each piece is mandatory; and I
c) the consequences for not providing the complete set of I
required documents.[1]
I
I
I
a) information and documents that will be deleted by the I

Applicant;
b) information and documents that will be retained by the I
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 I
in order to successfully complete the relevant identity proofing
process.
# OFFICIAL
OFFICIAL #
a) an option to either: I
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 I

clear instructions on how to use such alternative channels.
I
1) no interaction with a user when providing the services for which A C I X

the Applicant is seeking accreditation; or
2) limited interaction with a User when providing the services for A C I X

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.
A C I X
a) Describe the test objectives, usability goals, and usability A C I X

metrics that will be captured.
b) Describe the number of test participants, how they will be A C I X
recruited and the cohort to which they belong.
c) Document the approach and the methodology used to conduct A C I X
the tests to indicate what is working, pain points and where
improvements are needed.
# OFFICIAL
OFFICIAL #
d) Document representative scenarios for testing, on both desktop A C I X

and mobile devices.
e) Describe how findings from usability testing will be A C I X
implemented.
f) Identify a range of representative Individuals to participate in A C I X
the usability testing.
a) Individuals with disability. A C I X
b) Individuals over the age of 65. A C I X
c) Individuals who use assistive technologies. A C I X
d) Individuals with low literacy. A C I X
A C I X
e) Individuals from culturally and linguistically diverse backgrounds
f) Individuals who are Aboriginal or Torres Strait Islander. A C I X
g) Individuals from regional and remote areas. A C I X
h) Individuals with older technology and low bandwidth A C I X
connections.
A C I X
A C I X
A C I X
A C I X
A C I X
a) for each recommendation in the report that is accepted by the A C I X

Applicant, the timeframe for implementation of the
recommendation; and
b) for each recommendation in the report that is not accepted by A C I X
the Applicant, the reasons for non-acceptance and details of
alternative actions (if any) to be taken by the Applicant.
A C I X
A C I X
# OFFICIAL
OFFICIAL #
a)The exit criteria used when testing; A C I X
b) The assumptions, limitations and dependencies relevant to the A C I X

testing; and
c) The methodology used to conduct testing, including a A C I X
description of the data used, and the environment used to conduct
testing
A C I X
a) Confirmation that the testing has been undertaken and A C I X

completed
b) The results of the testing, including any defects detected in A C I X
testing, and whether these have been addressed; and
c)Evidence that the exit criteria specified for testing has been met. A C I X
• Its fraud control mechanism for detecting Digital Identity Fraud A C I X

Incidents (as per FRAUD-02-04-01).
• Its fraud control mechanism to flag incidents of Digital Identity A C I X
Fraud Incidents (as per FRAUD-02-04-02).
• Its security mechanism for detecting Cyber Security Incidents A C I X
(as per PROT-04-02-07).
• Its security mechanism to flag Cyber Security Incidents (as per A C I X
PROT-04-02-08).
• Its processes for audit trails and activity logging in applications A C I X
(as per PROT-04-02-24).)
•The activities and events logged (as per PROT-04-02-24a). A C I X
• The content included in activity logs (as per PROT-04-02-24b, A C I X
PROT-04-02-24c, and PROT-04-02-24d and PROT-04-02-24e).
• Its fraud control mechanism, which prevents new registrations A C I
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).
• Its security mechanism, which prevents new registrations or A C I

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).
# OFFICIAL
OFFICIAL #
a)a privacy impact assessment in accordance with ASSESS-07-05-01 A C I X
b)a Privacy Assessment in accordance with ASSESS-07-05-03 A C I X

c)a penetration test in accordance with ASSESS-07-06-02 A C I X
d)a security assessment in accordance with ASSESS-07-06-01; and A C I X
e)an accessibility assessment in accordance with ASSESS-07-07-01. A C I X
a) define and prepare written instructions on the scope , A C I X

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 the TDIF A C I X

requirements
c) provide a copy of such instructions to the relevant Assessor A C I X
prior to commencement of the Functional Assessment; and
d) ensure that each Functional Assessment is conducted in A C I X
accordance with such written instructions.
A C I X
• Are independent from the development and operational teams A C I X

of the Applicant’s Identity System
• Do not possess a conflict of interest in performing the A C I X
Functional Assessment.
A C I X
a)Documentation reviews. A C I X
b)Interviews with key personnel. A C I X
c)A run through of the Applicant’s Identity System. A C I X
A C I X
a)test results where applicable; A C I X
b) an assessment of whether the Applicant’s Identity System A C I X

meets the applicable requirements of the TDIF
c)recommendations by the Assessor; and A C I X
d) such other information required by the Applicant to enable it to A C I X
comply with the TDIF and prepare the Functional Assessment
Report.
# OFFICIAL
OFFICIAL #
a) A summary of the activities performed by the Assessor during A C I X

the Functional Assessment.
b) The dates on which the Functional Assessment was A C I X

commenced and completed.
c) Name, role (or position) and contact details of the relevant A C I X
Accountable Executive and point of contact.
d)Qualifications and basis of independence for all Assessors used. A C I X
e)Names and versions of all documents used by the Applicant. A C I X

f) City, state (and if applicable, country) of all physical locations A C I X
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 C I X

h)The test or evaluation results. A C I X
i) The Assessor’s opinion on whether the Applicant’s Identity A C I X
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 with the A C I X

TDIF requirements or any other risk identified by the Assessor.
k) Any recommendation from the Assessor to address such non- A C I X
compliance or risk.
a) Assess each identified instance of non-compliance with the A C I X
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 I X
c) Assign each instance of non-compliance and risk with a risk A C I X
rating as set out in Appendix A: Risk Ratings; and
d) Include in the Functional Assessment Report: A C I X
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.
a) for each recommendation, risk and non-compliance that is A C I X

accepted by the Applicant, the timeframe and details of the actions
that the Applicant will take for 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]
# OFFICIAL
OFFICIAL #
b) for each recommendation, risk and non-compliance that is not A C I X

accepted by the Applicant, the reasons for non-acceptance and
details of alternative actions (if any) to be taken by the Applicant.
A C I X
• it has implemented mitigations to address the A C I X

recommendation, risk or non-compliance; and
• The recommendation, risk or non-compliance has been A C I X
reassessed and the residual risk rating is at Low or Compliant; and
• The Accountable Executive has signed off and confirmed the A C I X

implemented mitigation of the recommendation, risk or non-
compliance and the new residual risk rating.
A C I X
a) Be undertaken early enough to influence the design of the A C I X

Identity System.
b)Reflect consultation with relevant stakeholders. A C I X
c)Include a description of the proposed Identity System. A C I X
d)Map the Identity System’s personal information flows. A C I X
e) Include an analysis of risks of non-compliance with relevant A C I X
privacy laws and TDIF privacy requirements.
f) Include an analysis of the impact of the project on the privacy A C I X
of Individuals.
g) Include an analysis of whether privacy impacts are necessary or A C I X
avoidable.
h)Include an analysis of possible mitigations to privacy risks. A C I X
i)Include recommendations A C I X
a) address the recommendations (if any) included in the Privacy A C I X
Impact Assessment under ASSESS-07-05-01; and
b) includes a review and assessment of the Applicant’s A C I X

compliance with the privacy requirements of the TDIF.
# OFFICIAL
OFFICIAL #
a) include a review and assessment of the Applicant’s compliance A C I X

with the applicable Protective Security Requirements; and
b) address the findings and recommendations (if any) from the A C I X

Penetration testing under ASSESS-07-06-02.
a)its Identity System; and A C I X
b) each major production release of software forming part of its A C I X
Identity System following accreditation.
• meets WCAG version 2.0 to the AA standard for web-based A C I X

identity services
• meets WCAG version 2.1 to the AA standard for mobile-based A C I X

identity services.
A C I X
a) A general acknowledgment by the User that their use of the A C I X

Identity System provided by the Applicant is governed by the User
terms.
b) The scope of the User’s right to access and use the Identity A C I X
System must be consistent with the TDIF.
c) That the User is responsible for providing accurate Identity A C I X
Documents and Attributes to the Applicant.
d) That the User is responsible for reporting unauthorised use of A C I X
their Digital Identity or Credential to the Applicant as soon as they
become aware of it.
e) That the Applicant may suspend, cancel or terminate the User’s A C I X
access to the Identity System at any time.
f) That the Applicant may make changes to the User terms at any A C I X
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.
g) If applicable, that the User’s access to the Identity System may A C I X

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 requirements or A C I X

instructions provided to them by the Applicant.
i)The governing law of the User terms A C I X
j)Provisions setting out a process for dispute resolution A C I X
A C I X
# OFFICIAL
OFFICIAL #
See TDIF 05 Table 1 & 4 Sheet below I
See TDIF 05 Table 1 & 4 Sheet below I
a) perform an assessment of the risk associated with I

implementing the alternative process and provide the risk
assessment to Finance
b) Have in place mitigation methods and a plan to manage the I
risks of an alternative identity proofing process and provide the plan
to Finance; and
c) Receive permission from Finance to perform an alternative I
Identity Proofing process and assert that it is equivalent to a
particular Identity Proofing Level.
# OFFICIAL
OFFICIAL #
I
I
• require that the maximum time elapsed between verifications I

of the link between the User and their Digital Identity is 5 years; and
• suspend a digital identity where the period between I

verifications of the link between the user and the user’s digital
identity is longer than 5 years
• Require the User to complete the Identity Proofing process for I
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 I

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.
# OFFICIAL
OFFICIAL #
•Online Biometric Binding as per Section 3.9.2, or I

•Local Biometric Binding as per Section 3.9.3 I
• Risks related to using Biometric Matching algorithms and I
Presentation Attack Detection (PAD) systems to complete Biometric
Verification and PAD
• Risks related to using Assessing Officers to complete Local I

Biometric Binding.
• Risks related to the capture, temporary storage, and deletion of I
Biometric Samples.
• Risks related to the Biometric Matching process the Applicant I
implements (i.e. Source, Technical, or Manual Face Comparison).
• Risks related to potential and known threats and attacks to the I

Biometric Capability.
I
# OFFICIAL
OFFICIAL #
I
I
a) it has engaged a Biometric Testing Entity to conduct the I

biometric testing
b) the Biometric Testing Entity has employed appropriately I

experienced personnel with a background in biometric testing to
conduct the biometric testing
c)the Biometric Testing Entity is a certified ISO 17025 laboratory I
d) the Biometric Testing Entity has a policy for working with I
human test subjects approved by a relevant national body
I
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 I
conflict of interest, perceived or otherwise.
•Technical Biometric Matching as per Section 3.9.4 I
•Source Biometric Matching as per Section 3.9.5 I

I
# OFFICIAL
OFFICIAL #
I
I
I
I
• Capturing an Acquired Image and performing either: I

o Technical Biometric Matching as per Section 3.9.4
o Source Biometric Matching as per section 3.9.5
•A Manual Face Comparison as per section 3.9.7 I
I
# OFFICIAL
OFFICIAL #
I
I
# OFFICIAL
OFFICIAL #
C
C
# OFFICIAL
OFFICIAL #
a)advise the Individual that they need to select a different secret C
b) Provide the reason for rejection; and C
c)Require the Individual choose a different Memorised Secret. C

C
C
C
C
C
C
C
a)Look-Up Secrets are hashed using an AACA; and C
# OFFICIAL
OFFICIAL #
b) Look-Up Secrets that have less than 112 bits of entropy are C
salted and hashed using an AACA with a salt value of at least 32 bits
in length which is arbitrarily chosen.
C
C
C
• The device MUST accept transfer of the secret from the C

primary channel, which it MUST send to the Applicant over the
secondary channel to associate the approval with the
Authentication transaction. The Individual MAY perform the
transfer manually or use a technology such as a barcode or QR code
to effect the transfer .
• The device MUST present a secret received via the secondary C

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
C
# OFFICIAL
OFFICIAL #
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.
C
C
C
C
C
# OFFICIAL
OFFICIAL #
C
C
C
C
C
C
# OFFICIAL
OFFICIAL #
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
# OFFICIAL
OFFICIAL #
C
C
C
C
C
C
C
C
C
C
C
C
C
C
# OFFICIAL
OFFICIAL #
C
C
C
C
C
• 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.
C
C
• 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)
•a separate Key MUST be used for identifying the device C
• Biometric revocation, referred to as ‘biometric template C
protection’ in ISO/IEC 24745, MUST be implemented
• All transmission of biometrics MUST be over the Authenticated C
Protected Channel.
C
C
# OFFICIAL
OFFICIAL #
C
C
C
C
C
C
C
C
C
C
C
C
1. Offer Individuals at least one alternate Credential that is not C

restricted and can be used to authenticate at the required CL
# OFFICIAL
OFFICIAL #
C
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 C
Assessment
4. Develop a migration plan for the possibility that the Restricted C
Credential is no longer acceptable at some point in the future.
C
C
C
C
C
• 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 C
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 be reused C
# OFFICIAL
OFFICIAL #
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
C
C
C
C
C
C
C
C
C
C
C
# OFFICIAL
OFFICIAL #
C
C
C
C
C
C
C
C
C
a) is capable of meeting all the applicable requirements of the C
higher credential level
b) is a type of Credential supported by the Applicant’s Identity C

System; and
c)meets all the requirements for that credential type C
C
C
C
# OFFICIAL
OFFICIAL #
a. Certification Practice Statements (CPS) and Certificate Policies C

(CP) conform to Request for Comment (RFC) 3647
b. Digital Certificates conform to the (RFC) 5280 format C
c. Certificate Revocation Lists (CRLs) conform to the X.509 version 2 C
profile as described in RFC 5280
d. Online Certificate Status Protocol (OCSP) responses conform to C
RFC 6960.
C
• The Individual notifies the Applicant that a Digital Certificate C

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
• The Applicant obtains evidence that a Digital Certificate it has C
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.
• The Applicant determines that any information set out in the C
Digital Certificate is inaccurate or misleading.
• The Applicant obtains evidence of a suspected or actual C
compromise of a subordinate CA’s Private Key.
# OFFICIAL
OFFICIAL #
A
A
A
A
X
X
X
X
•Timestamp X
• Where an entity records consent on behalf of an IdP or ASP, X

the duration of Consent. (including any time limit on the consent)
• The name of the Relying Party that requested the relevant X
attributes.
• The Identifier that identifies the User at the Relying Party X
authorised to receive the Attributes
• Identity Service Provider/Attribute Service Provider from which X
the Attributes were sourced
• The Identifier that identifies the Identity at the source of the X
Attributes
•Name of any Attribute or Attribute set authorised X
•Consent decision. This may be “grant”, “deny”, or “ongoing” X
X
X
# OFFICIAL
OFFICIAL #
X
X
X
X
# OFFICIAL
OFFICIAL #
Evidence that meets the TDIF Document ID Internal Doc Assessme

requirement on GovTEAMS Reference nt Status
[Applicant to fill in] OR document (Page no., Requires
To fill in this column, include a name paragraph/s DTA = DTA
statement of fact and a direct link to to action
the evidence location, document name, APP =
page, website, application, code etc.: Applicant to
We are able to meet this requirement action
by: NFA = No
- Statement of evidence, evidence Further
located in [SHARED FILE LOCATION] Action
DOCUMENT UNIQUE IDENTIFIER, page
3.
Assertions by an Applicant in lieu of

evidence is not supported.
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
DTA comments Accepted Applicabl

[Y, N, e to Role
N/A]
Finance Accreditation Lead will assess the evidence
provided and supply feedback if it cannot be accepted
at the time.
This spreadsheet is a shared working document and will
be regularly updated by both parties
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
Applicability Statement Applicant can add

columns here and
beyond (if required)
Statement of Applicability for
agreed non-applicable
requirements
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
TDIF Requirement Subsecti Requirement Text

Require on
ments
Section Requirement Subsectio
n
ANNUAL 7.2.1 2.1 Accredited Provider Ongoing Obligations
ANNUAL ANNUAL-02-01-01 7.2.1 If the Department of Finance (Finance) 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.
ANNUAL ANNUAL-02-01-01a 7.2.1 Accredited Providers MUST meet any new or amended
requirements in the newest version of the TDIF, published on the
TDIF website, within 12 months of that version being published.
These requirements will be assessed as part of the Accredited
Provider’s Annual Assessment
ANNUAL ANNUAL-02-01-02 7.2.1 If Finance makes a finding that the Accredited Provider has failed
to comply with ANNUAL-02-01-01 and ANNUAL-02-01-01a, Finance
will advise the Accredited Provider in writing of the non-
compliance and direct it to submit evidence to meet the following
requirements. The accredited provider MUST provide to Finance in
writing:
ANNUAL ANNUAL-02-01-02 7.2.1
ANNUAL ANNUAL-02-01-02a 7.2.1 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.
ANNUAL ANNUAL-02-01-02b 7.2.1 If the risk rating meets or exceeds that outlined above in ANNUAL-
02-01-02a, the Accredited Provider MUST confirm:
[NOTE: If the Accredited Provider cannot meet ANNUAL-02-01-02a,

then this will result in a failed Annual Assessment. Where Finance
makes a finding that an Accredited Provider has failed an Annual
Assessment, Finance will make a decision whether the Accredited
Provider’s accreditation will be suspended or terminated.]
# OFFICIAL
OFFICIAL #
ANNUAL 7.2.1
ANNUAL 7.2.1
7.2.1.1 7.2.1.1 Changes to an Accredited Provider's Identity System

ANNUAL ANNUAL-02-01-03 7.2.1.1 If an Accredited Provider’s Identity System releases a Major
Production Release, or is changed or impacted in such a manner,
that results in:
ANNUAL ANNUAL-02-01-03 7.2.1.1
7.2.1.2 7.2.1.2 Variations in Accreditation

ANNUAL ANNUAL-02-01-04 7.2.1.2 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.
ANNUAL ANNUAL-02-01-05 7.2.1.2 The Applicant MUST submit a Requirements Traceability Matrix
and identify all applicable TDIF requirements that the variation of
accreditation will impact.
NOTE: Finance will assess the Requirements Traceability Matrix

and may identify additional applicable requirements that an
Accredited Provider must submit evidence for.
ANNUAL ANNUAL-02-01-06 7.2.1.2 The Accredited Provider MUST include and submit to Finance a
review of the evidence required for a change of scope of
accreditation, as outlined in Appendix C .
ANNUAL ANNUAL-02-01-07 7.2.1.2 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.
# OFFICIAL
OFFICIAL #
ANNUAL ANNUAL-02-01-07a 7.2.1.3 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.
7.2.2 2.2 Annual Assessment Requirements
ANNUAL ANNUAL-02-02-01 7.2.2 The Accredited Provider MUST meet all- obligations set out in the
TDIF Agreement (MOU) and provide evidence of such to Finance.
ANNUAL ANNUAL-02-02-02 7.2.2 The Accredited Provider MUST ensure that all Annual Assessment
requirements are completed by 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 Finance makes a finding that an Accredited
Provider has failed an Annual Assessment, Finance will make a
decision whether the Accredited Provider’s accreditation will be
suspended or terminated]
ANNUAL ANNUAL-02-02-03 7.2.2 Before the anniversary of the Accredited Provider’s initial
accreditation date, the Accredited Provider MUST provide Finance
with a full and unredacted copy of:
[An executive summary or redacted version of this information is

insufficient to meet this requirement.
Finance will acknowledge receipt of the Annual Assessment

Reports, supporting documentation and evidence and conduct a
review of the documents. Once this review is completed, Finance
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. ]
7.2.2.1 7.2.2.1 Qualifying Attestation Letter
# OFFICIAL
OFFICIAL #
ANNUAL ANNUAL-02-02-04 7.2.2.1 Once the Accredited Provider has achieved all applicable TDIF
Annual Assessment 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:
7.2.3 Alternative Assessment Reports

ANNUAL ANNUAL-02-03-01 7.2.3 If an Accredited Provider requests that an Alternative Assessment
should be considered by Finance 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.
ANNUAL ANNUAL-02-03-01a 7.2.3 Any request made to Finance to consider Alternative Assessment
Reports MUST include:
ANNUAL ANNUAL-02-03-01b 7.2.3 The Alternative Assessment Report MUST have been produced no
more than 12 months prior to the date it is provided to Finance
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.
# OFFICIAL
OFFICIAL #
7.2.4 2.4 Annual Functional Assessment and Usability Testing

ANNUAL ANNUAL-02-04-01 7.2.4 The Accredited Provider must ensure an Assessor conducts the
following Functional Assessments by the anniversary of the
Accredited Provider’s accreditation date each year:
ANNUAL ANNUAL-02-04-02a 7.2.4 ANNUAL-02-04-02 does not apply if the Accredited Provider has
demonstrated to Finance that the Accredited Provider has no
interaction with a user when providing the services for which the
Accredited Provider is accredited for.
ANNUAL ANNUAL-02-04-02b 7.2.4 ANNUAL-02-04-02 does not apply if the Accredited Provider has
demonstrated to Finance that the Accredited Provider:
ANNUAL ANNUAL-02-04-02b 7.2.4
ANNUAL ANNUAL-02-04-02b 7.2.4
7.2.5 7.2.5 Skills, experience and independence of Assessors and User

Researcher
ANNUAL ANNUAL-02-05-01 7.2.5 The Accredited Provider MUST demonstrate to Finance how each
Assessor and User Researcher has relevant, reasonable and
adequate experience, training and qualifications to conduct the
relevant Functional Assessment.
ANNUAL ANNUAL-02-05-01a 7.2.5 The Accredited Provider MUST demonstrate to Finance how the
Assessors :
ANNUAL ANNUAL-02-05-01a 7.2.5
7.2.6 7.2.6 Annual Assessment schedule
# OFFICIAL
OFFICIAL #
ANNUAL ANNUAL-02-06-01 7.2.6 Annual Assessments that occur during:
7.2.7 7.2.7 Functional Assessment Process

ANNUAL ANNUAL-02-07-01 7.2.7 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 Finance. This includes any
responses by Finance to questions which may have been asked.
ANNUAL ANNUAL-02-07-02 7.2.7 As part of the Functional Assessments, the Assessors MUST
undertake the following activities
ANNUAL ANNUAL-02-07-03 7.2.7 If required by an Assessor or Finance, 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.
ANNUAL ANNUAL-02-07-04 7.2.7 The Accredited Provider MUST ensure that each Assessor prepares
a report on the outcomes of the relevant Functional Assessment
that includes:

7.2.8 2.8 Annual Assessment Reports

ANNUAL ANNUAL-02-08-01 7.2.8 The Accredited Provider MUST document the outcomes of each
Functional Assessment in an Annual Assessment Report, which
MUST include the following:

# OFFICIAL
OFFICIAL #

7.2.8.1 2.8.1 Forward Work Plan

ANNUAL ANNUAL-02-08-02 7.2.8.1 The Accredited Provider MUST:

ANNUAL ANNUAL-02-08-02a 7.2.8.1 The Accredited Provider’s Accountable Executive MUST respond in
writing to each recommendation, risk and non-compliance outlined
in the Annual Assessment Reports including:
ANNUAL ANNUAL-02-08-02a 7.2.8.1
ANNUAL ANNUAL-02-08-03 7.2.8.1 If the Accredited Provider does not implement a mitigation or
recommendation by the timeframe set out in ANNUAL-02-08-02a,
then its Accountable Executive MUST provide to Finance 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, Finance will then assess whether the
Accredited Provider has failed to meet one or more of their
ongoing obligations. If Finance finds that the Accredited Provider
has failed to meet their obligations, this will result in a finding of
non-compliance with the TDIF, Finance will make a decision
whether the Accredited Provider’s accreditation will be suspended
or terminated.
# OFFICIAL
OFFICIAL #
ANNUAL ANNUAL-02-08-04 7.2.8.1 Any risks or recommendations identified in ANNUAL-02-08-02 or

ANNUAL-02-08-03 MUST NOT:
ANNUAL ANNUAL-02-08-04a 7.2.8.1 If the risk rating meets or exceeds that outlined above in ANNUAL-
02-08-04, the Accredited Provider MUST confirm:
7.2.9 7.2.9 TDIF 04 Functional Requirements Review

ANNUAL ANNUAL-02-09-01 7.2.9 As part of the Annual Assessment the Accredited Provider MUST
review following FRAUD requirements in TDIF 04 Functional
Requirements and provide Finance with:
review the following PRIV requirements in TDIF 04 Functional
# OFFICIAL
OFFICIAL #
provide Finance with a copy of their Annual Transparency Report
(as per PRIV-03-06-05 and PRIV-03-06-05a).
review the following PROT requirements in TDIF 04 Functional
7.2.9.1 2.9.1 Annual Privacy Assessment

ANNUAL ANNUAL-02-09-05 7.2.9.1 The Accredited Provider MUST commission an Assessor to conduct
a privacy assessment which MUST, at a minimum:
7.2.9.2 2.9.2 Annual Security Assessment

a security assessment which MUST, at a minimum:
# OFFICIAL
OFFICIAL #
7.2.9.3 2.9.3 Annual Penetration Test

penetration testing of its Identity System which must, at a
minimum, meet the requirements of ASSESS-07-06-02.
7.2.9.4 2.9.4 Annual Accessibility Assessment
an accessibility assessment which must, at a minimum, assess
whether the Accredited Provider’s Identity System meets:
7.2.9.5 Annual Usability Test

ANNUAL ANNUAL-02-09-10 7.2.9.5 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.
7.2.10 2.10 TDIF 05 Role Requirements Review
ANNUAL ANNUAL-02-10-01 7.2.10 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 Finance.
7.2.10.1 2.10.1 IDP Biometric Requirements
# OFFICIAL
OFFICIAL #
ANNUAL ANNUAL-02-10-02 7.2.10.1 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 Finance.
ANNUAL ANNUAL-02-10-03 7.2.10.1 The Applicant MUST consider the following risks related to
performing Biometric Binding when reviewing their Fraud Control
Plan and System Security Plan as part of its Annual Assessment
requirements:
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-03a 7.2.10.1 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
Finance as part of the Annual Assessment.
ANNUAL ANNUAL-02-10-03b 7.2.10.1 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 Finance for review as part of the Annual Assessment.
ANNUAL ANNUAL-02-10-03c 7.2.10.1 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 Finance for review as part of the Annual
Assessment.
# OFFICIAL
OFFICIAL #
ANNUAL ANNUAL-02-10-04 7.2.10.1 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.
ANNUAL ANNUAL-02-10-05 7.2.10.1 If the Accredited Provider supports Manual Face Comparison, it
MUST review and submit to Finance evidence of:
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
ANNUAL ANNUAL-02-10-05 7.2.10.1
7.2.10.2 2.10.2 ASP Annual Requirements

ANNUAL ANNUAL-02-10-06 7.2.10.2 As part of the Annual Assessment the Accredited Provider MUST
provide Finance with evidence of its arrangements with an
Authoritative Source (as per ASP-05-02-01a )
7.2.11 Exemption Request Review
ANNUAL ANNUAL-02-11-01 7.2.10.2 If an Accredited Provider has been granted an exemption request
as per ACCRED-03-01-06 and ACCRED-03-01-06a, then it MUST
review the exemption request and:
ANNUAL ANNUAL-02-11-01 7.2.10.2
ANNUAL ANNUAL-02-11-01 7.2.10.2
ANNUAL ANNUAL-02-11-01 7.2.10.2
ANNUAL ANNUAL-02-11-01 7.2.10.2
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
Sub-Requirement A C I X Y/
N
TDIF 07 - Maintain Accreditation
A C I X
NOTE: If an Accredited Provider does not provide the information
required by ANNUAL-02-01-01 or ANNUAL-02-01-01a by their Annual
Assessment date, Finance will then assess whether the Accredited
Provider has failed to meet one or more of their ongoing obligations. If
Finance 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.
A C I X
a) a risk rating assigned to each instance of non-compliance as set
out in Appendix A; and
A C I X
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.
A C I X
A C I X
a) it has implemented mitigations to address the recommendation,
risk or non-compliance
A C I X
# OFFICIAL
OFFICIAL #
b) The risk, recommendation or non-compliance has been reassessed

and the residual risk rating is at Moderate or below; and
A C I X
c) The Accountable Executive has signed off and confirmed the
implemented mitigation of the risk and the new residual risk rating. A C I X
• Significant impacts to the Accredited Provider’s protective security

arrangements
• Serious or repeated privacy breaches (including of 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
A C I X
then the Applicant MUST inform Finance of changes to their Identity
System as part of its Annual Assessment and any provisions as
stipulated by the TDIF Agreement (MOU).
[Finance 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]
A C I X
A C I X
A C I X
A C I X
A C I X
# OFFICIAL
OFFICIAL #
A C I X
A C I X
In order for Finance to review an Accredited Provider’s Annual
Assessment materials, the Accredited Provider should submit its
Annual Assessment evidence at least two months prior to the
anniversary of its initial accreditation date
A C I X
a) each Functional Assessment report prepared under ANNUAL-02-
07-04.
A C I X
b) Where applicable, the Accredited Provider’s Annual Usability Test
Report conducted in accordance with ANNUAL-02-04-02 A C I X
c) the Accredited Provider’s Annual Assessment Reports prepared in
accordance with ANNUAL-02-08-01 A C I X
d) each response from the Accredited Provider’s Accountable
Executive under ANNUAL-02-08-02a. A C I X
e) All applicable evidence required as part of the review under
Section 2.9 Evidence Review Requirements and listed in Appendix B.
A C I X
f) An annual Qualifying Attestation Letter in accordance with the
requirements set out in ANNUAL-02-02-04. A C I X
# OFFICIAL
OFFICIAL #
• The name, role/position and contact details of the Accountable

Executive
A C I X
• A statement that the Accredited Provider’s Identity System
complies with the TDIF requirements and the TDIF Agreement (MOU)
A C I X
• The version of the TDIF the Accredited Provider is assessed and
accredited under for the relevant Annual Assessment A C I X
• a statement confirming it has provided Finance with all relevant
documents, materials and evidence to the accreditation as part of its
review
A C I X
• A statement confirming that the evidence provided is a fair and
accurate representation of its Identity System A C I X
• 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
A C I X
A C I X
a) Which Functional Assessment or TDIF requirements it is provided
as evidence for A C I X
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
A C I X
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).
A C I X
A C I X
# OFFICIAL
OFFICIAL #
a)a Privacy Assessment in accordance with ANNUAL-02-09-05;
A C I X
b)a Security Assessment in accordance with ANNUAL-02-09-06 A C I X
c)a Penetration Test in accordance with ANNUAL-02-09-07; and A C I X
d)an Accessibility Assessment in accordance with ANNUAL-02-09-08.
A C I X
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.
A C I X
A C I X
1. either:
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
A C I X
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
A C I X
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.
A C I X
A C I X
a) Are independent from the development and operational teams of
the Accredited Provider’s Identity Facility. A C I X
b) Do not possess a conflict of interest in performing the Annual
Functional Assessment on the Accredited Provider’s Identity System A C I X
# OFFICIAL
OFFICIAL #
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.
A C I X
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.
A C I X
A C I X
a)Documentation reviews.
A C I X
b)Interviews with key Personnel. A C I X
c)A run through of the Accredited Provider’s Identity Facility. A C I X
A C I X
a)test results where applicable;
A C I X
b) an assessment of whether the Accredited Provider’s Identity
System meets the applicable requirements of the TDIF; A C I X
c)recommendations by the Assessor; and A C I X
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.
A C I X
a) A summary of the activities performed by the Assessor during the

Functional Assessment.
A C I X
b) The dates on which the Functional Assessments were commenced
and completed A C I X
c) Name, role (or position) and contact details of the relevant
Accountable Executive and point of contact. A C I X
d)Qualifications and basis of independence for all Assessors used. A C I X
e) Names and version numbers of all documents used by the
Accredited Provider. A C I X
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.
A C I X
g)The test or evaluation methodology(s) used. A C I X
# OFFICIAL
OFFICIAL #
h)The test or evaluation results and findings. A C I X

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.
A C I X
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
A C I X
k) Any recommendation from the Assessor or user researcher to
address such non-compliance or risk. A C I X
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
A C I X
b)Assess any other risks identified by the Assessor A C I X
c) Assign each instance of non-compliance and risk with a risk rating
as set out in Appendix A: Risk Ratings; and A C I X
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.
A C I X
a) for each recommendation, risk and non-compliance that is
accepted by the Accredited Provider, the timeframe and details of the
actions that the Accredited Provider will take for implementation ; and
A C I X
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.
A C I X
a)A revaluation of the risk
A C I X
b) Any agreed upon mitigation strategies implemented, or being
implemented, to manage the risk A C I X
# OFFICIAL
OFFICIAL #
c) Confirmation of the Applicant’s tolerance to continue to carry the

risk until the fix is implemented; and A C I X
d) The proposed new date for implementation that will be agreed
upon by Finance A C I X
• meet or exceed a High or Extreme risk rating for the Accredited
Provider’s Annual Assessment .
[According to Appendix A: Risk Ratings in TDIF 07 Maintain

Accreditation, or the Applicant’s equivalent risk framework.]
A C I X
a) it has implemented mitigations to address the recommendation,
risk or non-compliance A C I X
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.]
A C I X
c) The Accountable Executive has signed off and confirmed the
implemented mitigation of the risk and the new residual risk rating. A C I X
a) The annual assessment of the Digital Identity Fraud Risk

associated with the services for which the Accredited Provider is
accredited and the Accredited Provider’s Identity System as per
FRAUD-02-01-02
A C I X
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
A C I X
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).
A C I X
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).
A C I X
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).
A C I X
a) Evidence the Accredited Provider has reviewed its Privacy Policy
and where relevant updated during the year (as per PRIV-03-02-05).
A C I X
b) Evidence the Accredited Provider has reviewed its Privacy
Management Plan and where relevant updated during the year (as per
PRIV-03-02-07).
A C I X
c) A copy of privacy awareness training materials provided by the
Accredited Provider to Personnel during the year (as per PRIV-03-02-
08).
A C I X
# OFFICIAL
OFFICIAL #
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) A C I X
X
a) The annual assessment of the Cyber Security Risk associated with
the services for which the Accredited Provider is accredited and the
Accredited Provider’s Identity System as per PROT-04-01-01
A C I X
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
A C I X
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 C I X
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.
A C I X
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
A C I X
f) Evidence the Accredited Provider has tested its Disaster Recovery
and Business Continuity Plan during the year as per PROT-04-02-25.
A C I X
a) include an assessment of whether the Accredited Provider has

addressed all recommendations included in the privacy impact
assessment prepared under ASSESS-07-05-01 ; and
A C I X
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
A C I X
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
A C I X
d) include a review and assessment of the Accredited Provider’s
compliance with privacy requirements under applicable law and the
TDIF.
A C I X
a) address the findings and recommendations (if any) from the

penetration testing of the Accredited Provider’s Identity System
conducted under ANNUAL-02-09-07
A C I X
# OFFICIAL
OFFICIAL #
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
A C I X
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 Finance, and the Accredited
Provider’s response to such incidents; and
iii. changes to the design of the Accredited Provider’s Identity System
A C I X
d) include an evaluation of the sufficiency of the Accredited
Provider’s protective security controls A C I X
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
A C I X
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.
A C I X
A C I X
a) WCAG version 2.0 to the AA standard for web-based Identity

Systems; and
A C I X
b) WCAG version 2.1 to the AA standard for mobile-based Identity
Systems. A C I X
A C I X
# OFFICIAL
OFFICIAL #
I
a)Applicable risks in IDP-03-08-03
I
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 Finance
I
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.]
I
d) Risks related to identified attacks on the Biometric Capability that
have occurred since the last assessment I
# OFFICIAL
OFFICIAL #
I
a) The tools and annual training for Personnel performing identity
proofing processes to detect fraudulent attributes and Evidence of
Identity Documents
[ As per the requirements in Table 1: Identity Proofing Levels of TDIF

05 Role Requirements.]
I
b) Assessing Officer annual training and training material as per IDP-
03-08-24 I
c)The Assessing Officer reference card as per IDP-03-08-24a I
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
I
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
I
a)Confirm that the Exemption Request is still required
A C I X
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
A C I X
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
A C I X
d) Have the Accredited Provider’s Accountable Executive confirm
and sign off on the items above; and A C I X
e)Submit evidence of the above to Finance. A C I X
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
Evidence that meets Document ID on Internal Doc Assessmen

the TDIF GovTEAMS OR Reference t Status
requirement document name (Page no., Requires
paragraph/s
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
DTA comments Accepted Applica Applica Applica

[Y, N, ble to bility nt can
N/A] Role Stateme add
nt columns
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
TDIF Requirement Subse Requirement Text

Requir ction
ement
sINSTRUC
T
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.
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].
# OFFICIAL
OFFICIAL #
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-11a.
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
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.

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-06).
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--06a).
# OFFICIAL
OFFICIAL #
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 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).
FED FED-02-01-12 6.2.1 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.
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).

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

procedures to report Cyber security incidents to
the Oversight Authority (this replaces PROT-04-
02-14).
# OFFICIAL
OFFICIAL #
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-
14a).
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
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.
# OFFICIAL
OFFICIAL #
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.
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.
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.
# OFFICIAL
OFFICIAL #
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.
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.

moved to IDX-06-03-02a
# OFFICIAL
OFFICIAL #
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.

1.1.
1.1.
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.
# OFFICIAL
OFFICIAL #
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.
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.

1.1.
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 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.
# OFFICIAL
OFFICIAL #
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 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.

moved to IDX-06-05-01b.
1.1.
1.1.
FED-04-02-01b 6.4.2 This requirement has been archived in version
1.1.
# OFFICIAL
OFFICIAL #
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:
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.
# OFFICIAL
OFFICIAL #
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.
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.

1.1.
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.
# OFFICIAL
OFFICIAL #
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:

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

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

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.
# OFFICIAL
OFFICIAL #
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
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
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.
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.
# OFFICIAL
OFFICIAL #
FED FED-04-02-31 6.4.2 When the ForceAuthn Attribute is set to true

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

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:

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

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
Requirements

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

all Attributes described in section 3.3 of TDIF:
06D - Attribute Profile using one of the
Requirements

all Attributes described in section 3.5 of TDIF:
06D - Attribute Profile using one of the
Requirements
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. Finance will add
any computed attributes to the TDIF: 06D -
Attribute Profile.

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
FED FED-05-04-01 6.5.4 to
ThebeApplicant
shared, Attributes
MUST onlythat are relevant
disclose to the
Attributes
Relying Party requesting the 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
# OFFICIAL
OFFICIAL #
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.
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
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.
# OFFICIAL
OFFICIAL #
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.
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.
# OFFICIAL
OFFICIAL #
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.
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.
# OFFICIAL
OFFICIAL #

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.
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.
# OFFICIAL
OFFICIAL #
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.
OIDC OIDC-02-07-01 6B.2.7 The authorisation server MUST validate all
redirect URIs for the authorization_code grant
type.
# OFFICIAL
OFFICIAL #
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
OIDC OIDC-02-07-05 6B.2.7 with an expiration
The JWT time the
MUST contain thatfollowing
has passed, subject
REQUIRED
to allowable clock skew between systems.
claims and MAY contain the following Note
that the authorization server may reject
OPTIONAL Claim values: [Refer to list of JWTs
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.
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.
# OFFICIAL
OFFICIAL #
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.

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.
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.
# OFFICIAL
OFFICIAL #
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.
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]
# OFFICIAL
OFFICIAL #
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.
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
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.
# OFFICIAL
OFFICIAL #
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.
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.
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.
# OFFICIAL
OFFICIAL #
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.
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-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].
# OFFICIAL
OFFICIAL #
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.
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]
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.
# OFFICIAL
OFFICIAL #
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-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.

which are defined as REQUIRED MUST be
included in the ID Token.
which are defined as OPTIONAL MAY be
included in the ID Token, unless otherwise
specified in another requirement in this
document.
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.
# OFFICIAL
OFFICIAL #
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.
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.
# OFFICIAL
OFFICIAL #
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].
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.
# OFFICIAL
OFFICIAL #
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>.
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.
# OFFICIAL
OFFICIAL #
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.
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.
# OFFICIAL
OFFICIAL #
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.
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.
# OFFICIAL
OFFICIAL #
SAML SAML-02-04-03 6C.2.4 SAML Service Providers MUST support either

the HTTP-Redirect and HTTP-POST bindings for
authentication requests.
signing of assertions and responses, both
together and independently.
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

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

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

based on the presence of
<mdattr:EntityAttributes> extension elements
[MetaAttr].

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.
SAML SAML-03-02-07 6C.3.2 Identity Providers MUST support the

ForceAuthn attribute in the
<samlp:AuthnRequest> messages as defined in
SAML SAML-03-02-07a 6C.3.2 The authentication mechanism within an
[SAML2Core].
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].
# OFFICIAL
OFFICIAL #

<saml:RequestAuthnContext> exact and
minimum comparison method 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.
<samlp:NameIDPolicy> element in
[SAML2Core].

AssertionConsumerServiceURL, ProtocolBinding,
and AssertionConsumerServiceIndex attributes
in <samlp:AuthnRequest> messages for the
identification of the response endpoint and
binding as defined in [SAML2Core].

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.

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.
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].
# OFFICIAL
OFFICIAL #
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.
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
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.

based on the entityID of the Relying Party.
# OFFICIAL
OFFICIAL #

based on the presence of
<mdattr:EntityAttributes> extension elements
[MetaAttr].

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

ForceAuthn attribute in the
[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
<saml:RequestAuthnContext> exact comparison
method in <samlp:AuthnRequest> messages as
# OFFICIAL
OFFICIAL #
SAML SAML-04-02-11 6C.4.2 Identity providers MUST support encryption of

assertions. Support for encryption of identifiers
and attributes is OPTIONAL.
<samlp:NameIDPolicy> element in
[SAML2Core].

generating <saml:Assertion> elements without a
<saml:NameID> element in the <saml:Subject>
element.

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.
# OFFICIAL
OFFICIAL #
Sub-Requirement A C I X Y/N Evidence that meets the

TDIF requirement
[Applicant to fill in]
To fill in this column, include a
statement of fact and a direct link
to the evidence location, document
name, page, website, application,
code etc.:
We are able to meet this
requirement by:
- Statement of evidence, evidence
located in [SHARED FILE LOCATION]
DOCUMENT UNIQUE IDENTIFIER,
page 3.
A C I X
A I X
A C I X
# OFFICIAL
OFFICIAL #
A C I X
A C I X
A C I X
A C I X
# OFFICIAL
OFFICIAL #
A C I X
A C I X
A C I X
A C I X
A C I X
A C I X
A C I X
# OFFICIAL
OFFICIAL #
A C I X
A C I X
[1] See Part IIIC of A C I X

https://www.legislation.gov.au/Details/C2019
C00025 for the definition of an eligible data
breach including exceptions to reporting.
I X
I X
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
C I X
# OFFICIAL
OFFICIAL #
C I X
C I X
C I X
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
I X
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
A I X
A I X
A C I X
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
X
X
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
A X
I X
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
X
X
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
I X
A I X
I X
I X
A C I X
A I X
# OFFICIAL
OFFICIAL #
A I X
A I X
A I X
A I X
A I X
A I X
A I X
A I X
A I X
# OFFICIAL
OFFICIAL #
A I X
A I X
A I X
A I X
A I X
A I X
A I X
# OFFICIAL
OFFICIAL #
A I X
A I X
A I X
A I X
A I X
A I X
A I X
A I X
I X
# OFFICIAL
OFFICIAL #
A X
A I X
A I X
A I X
A I X
A I X
# OFFICIAL
OFFICIAL #
I X
A X
A X
A X
A X
A X
A X
# OFFICIAL
OFFICIAL #
A X
A X
A X
A X
A X
A X
A X
A X
A X
# OFFICIAL
OFFICIAL #
A X
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
I X
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
A I X
A I X
I X
A I X
# OFFICIAL
OFFICIAL #
Document ID Internal Doc Assessm DTA comments

on GovTEAMS Reference (Page no., ent
OR document paragraph/sections) Status
name Require
DTA = DTA Finance Accreditation Lead will
to action assess the evidence provided and
APP = supply feedback if it cannot be
Applicant accepted at the time.
to action This spreadsheet is a shared working
NFA = No document and will be regularly
Further updated by both parties
Action
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
Accept Applica Applica Applica

ed [Y, ble to bility nt can
N, N/A] Role Statem add
ent column
Statemen
t of
Applicabil
ity for
agreed
non-
applicabl
e
requirem
ents
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
Archived
Archived
No
Archived
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
Archived
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
Archived
Archived
# OFFICIAL
OFFICIAL #
No
Archived
Archived
Archived
Archived
Archived
Archived
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
Archived
Archived
No
Archived
No
No
No
# OFFICIAL
OFFICIAL #
No
Archived
Archived
No
No
No
No
No
Archived
Archived
Archived
Archived
Archived
Archived
# OFFICIAL
OFFICIAL #
Archived
Archived
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
Archived
Archived
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
TDIF 05 - Role Requirements - Chapter 3, Table 1: Identity Proofing Levels - Chapter 4

Proofing Requirement Requirement Text
Level
IP1
IP 1 TABLE-01-01 Identifier chosen by the Individual MUST be unique
IP 1 TABLE-01-02 Approved technical Credential bindings: CL1/CL2/CL3
IP1 Plus
IP1 Plus TABLE-01-03 Identifier chosen by the Individual MUST be unique
A check MUST undertaken by the IdP to establish that the Individual is the
IP1 Plus TABLE-01-04 sole claimant of the Identity
A check MAY undertaken by the IdP that the identity is not that of a
IP1 Plus TABLE-01-05 deceased person
Checks MUST be undertaken against information or records held within

the IdP to confirm the identity is not known to be used fraudulently.
[Footnote: Such as checks against internal registers of known fraudulent

IP1 Plus TABLE-01-06 identities or vulnerable identities]
Checks MAY be undertaken against information on known fraudulent

identities from other Authoritative Sources
IP1 Plus TABLE-01-07 [Footnote: Such as law enforcement or other government agencies]
All Names and Date of Birth Attributes MUST be verified with Source
Verification or Technical Verification
[This requires all names and the date of birth of the Individual to be
verified as part of the Identity Proofing process. It does not require every
IP1 Plus TABLE-01-08 identity document to include these attributes. ]
Verification of a Photo ID MUST be undertaken?
IP1 Plus TABLE-01-09 Yes or UiTC as per TABLE-01-10
Verification of a UiTC document MUST be undertaken that can confirm
name and date of birth required?
IP1 Plus TABLE-01-10 Yes or Photo ID as per TABLE-01-09
IP1 Plus TABLE-01-11 Approved technical Credential bindings: CL1/CL2/CL3
IP2
IP2 TABLE-01-12 Identifier chosen by the Individual MUST be unique
IP2 TABLE-01-13 sole claimant of the Identity
IP2 TABLE-01-14 deceased person


IP2 TABLE-01-15 identities or vulnerable identities]
# OFFICIAL
OFFICIAL #

IP2 TABLE-01-16 [Footnote: Such as law enforcement or other government agencies]
Personnel performing Identity Proofing processes MAY be required to be

provided with tools and training to detect fraudulent Attributes and
Identity Documents before such personnel start work on those duties and
annually thereafter
[This may include training on recognition of document security features,

particularly for foreign documents. Evidence of the training provided
IP2 TABLE-01-17 MUST be submitted to Finance.]
NAATI accredited translation of identity documents in languages other
IP2 TABLE-01-18 than English MAY be required?
IP2 TABLE-01-19 identity document to include these attributes. ]
Verification of a CoI document MUST be undertaken?

Yes or Photo ID as per TABLE-01-21
[Footnote: Australian Passports MAY be used for CoI and Photo ID for up
IP2 TABLE-01-20 to IP3 proofing but MUST NOT be accepted as CoI for IP4 proofing]
IP2 TABLE-01-21 Yes or CoI as per TABLE-01-20
IP2 TABLE-01-22 Verification of ONE UiTC document MUST be undertaken

Verification of a Linking document MUST be undertaken if Attributes vary
IP2 TABLE-01-23 across EoI documents
IP2 TABLE-01-24 Approved technical Credential bindings: CL1/CL2/CL3
IP2 Plus
IP2 Plus TABLE-01-25 Identifier chosen by the Individual MUST be unique
IP2 Plus TABLE-01-26 sole claimant of the Identity
IP2 Plus TABLE-01-27 deceased person
Confirmation of the link between the individual and the claimed identity
by completing Biometric Binding in accordance with Section 3.8
IP2 Plus TABLE-01-28 Requirements for Biometric Binding
If completing Manual Face Comparison (as per section 3.8.6), then the
IP2 Plus TABLE-01-28a original, physical PhotoID is to be provided in-person
# OFFICIAL
OFFICIAL #


IP2 Plus TABLE-01-29 identities or vulnerable identities]

IP2 Plus TABLE-01-30 [Footnote: Such as law enforcement or other government agencies]
Personnel performing Identity Proofing processes MUST be required to be

annually thereafter

IP2 Plus TABLE-01-31 MUST be submitted to Finance.]

than English MAY be required
[Footnote: National Accreditation Authority for Translators and

Interpreters. Further information is available at
IP2 Plus TABLE-01-32 https:///www.naati.com.au/]
IP2 Plus TABLE-01-33 identity document to include these attributes. ]
Verification of a CoI document MUST be undertaken?

Yes or Photo ID as per TABLE-01-35
IP2 Plus TABLE-01-34 to IP3 proofing but MUST NOT be accepted as CoI for IP4 proofing]
IP2 Plus TABLE-01-35 Yes or CoI as per TABLE-01-34
IP2 Plus TABLE-01-36 Verification of ONE UiTC document MUST be undertaken

IP2 Plus TABLE-01-37 across EoI documents
IP2 Plus TABLE-01-38 Approved technical Credential bindings: CL2/CL3
IP3
# OFFICIAL
OFFICIAL #
A check MUST undertaken by the IdP that the identity is not that of a
IP3 TABLE-01-42 Requirements for Biometric Binding
IP4 TABLE-01-42a original, physical PhotoID is to be provided in-person




annually thereafter


than English MUST be required

IP3 TABLE-01-46 https:///www.naati.com.au/]
Verification of a CoI document MUST be undertaken
IP3 TABLE-01-48 to IP3 proofing but MUST NOT be accepted as CoI for IP4 proofing]
Verification of a Photo ID MUST be undertaken
IP3 TABLE-01-49
IP3 TABLE-01-50 Verification of ONE UiTC document MUST be undertaken

# OFFICIAL
OFFICIAL #
IP3 TABLE-01-52 Approved technical Credential bindings: CL2/CL3

IP4
A check MUST undertaken by the IdP that the identity is not that of a
IP4 TABLE-01-56 Requirements for Biometric Binding
IP4 TABLE-01-57 original, physical PhotoID is to be provided in-person
ALL original, physical EoI documents to be provided and the individual
IP4 TABLE-01-58 witnessed in-person at IP4




annually thereafter


than English MUST be required

IP4 TABLE-01-62 https:///www.naati.com.au/]
Verification of a CoI document MUST be undertaken
IP4 TABLE-01-64 Australian Passports MUST NOT be accepted as CoI for IP4 proofing
# OFFICIAL
OFFICIAL #
IP4 TABLE-01-65 Verification of a Photo ID MUST be undertaken
IP4 TABLE-01-66 Verification of TWO UiTC document MUST be undertaken

IP4 TABLE-01-68 Approved technical Credential bindings: CL3
Chapter 4, Table 4: Credential Levels
CL1
The Applicant MUST have one of the following permitted Credential Type
Combinations to satisfy the credential level:
ONE OF:
• Memorised Secret
• Look-up Secret
• Out-of-Band Device
• SF OTP Device
• SF Crypto Software
• SF Crypto Device
• MF OTP Device
• MF Crypto Software
• MF Crypto Device
[NOTE: If an Applicant is implementing more than one credential type,

CL1 TABLE-04-01 each credential type must be assessed seperately]
CL1 TABLE-04-02 Re-authentication MUST occur after 30 days
CL1 TABLE-04-03 Man-in-the-Middle resistance MUST be implemented
CL1 TABLE-04-04 CL1 MUST only be used for Identity Proofing Levels IP1 and IP1 PLUS
CL2
ONE OF:
• MF OTP Device
• MF Crypto Software
• MF Crypto Device;
OR
Memorised Secret AND ONE OF:
• Look-up Secret
• Out-of-Band Device
• SF OTP Device
• SF Crypto Software
• SF Crypto Device

CL2 TABLE-04-06 Re-authentication MUST occur after 12 hours, or 30 minutes of inactivity.

CL2 TABLE-04-07 Re-authentication MAY use one Authentication factor.
# OFFICIAL
OFFICIAL #

Replay Resistance MUST be implemented according to Section 4.3.8
CL2 TABLE-04-09 Replay Resistance
CL2 TABLE-04-10 Authentication Intent MAY be implemented
CL2 MUST only be used for Identity Proofing Levels IP1, IP1 PLUS, IP2, and
CL2 TABLE-04-11 IP3
CL3
• MF Crypto Device
OR
• SF Crypto Devices AND Memorised Secret
OR
• SF OTP Device AND MF Crypto Software
OR
• SF OTP Device AND MF Crypto Device
OR
• SF OTP Device AND SF Crypto Software AND Memorised Secret

CL3 TABLE-04-13 Re-authentication MUST occur after 12 hours, or 15 minutes of inactivity.

CL3 TABLE-04-14 Re-authentication MUST use both Authentication factors.
CSP-impersonation Resistance MUST be implemented according to
CL3 TABLE-04-16 Section 4.3.5 CSP-impersonation Resistance
CSP-compromise Resistance MUST be implemented according to Section
CL3 TABLE-04-17 4.3.7 CSP-compromise Resistance
Replay Resistance MUST be implemented according to Section 4.3.8
CL3 TABLE-04-18 Replay Resistance
CL3 TABLE-04-19 Authentication Intent MUST be implemented
CL3 TABLE-04-20 CL3 MAY be used for all Identity Proofing Levels
# OFFICIAL
OFFICIAL #
ofing Levels - Chapter 4, Table 4: Credential Levels

Objective Section I C Y/N Evidence that meets the TDIF requirement
[Applicant to fill in]
Uniqueness Objective I
CSP Bindings I
Legitimacy Objective I
Fraud Control Objective I
Other Requirements I
Documents required for
Verification I

Verification I
CSP Bindings I
# OFFICIAL
OFFICIAL #

Verification I
Verification I
Verification I
Verification I
CSP Bindings I
Binding Objective
Binding Objective I
# OFFICIAL
OFFICIAL #

Verification I
Verification I
Verification I
Verification I
CSP Bindings I
# OFFICIAL
OFFICIAL #
Binding Objective I
Binding Objective I

Verification I
Verification I
Verification I
Verification I
# OFFICIAL
OFFICIAL #
CSP Bindings I
Binding Objective I
Binding Objective I
Binding Objective I

Verification I
# OFFICIAL
OFFICIAL #

Verification I
Verification I
Verification I
CSP Bindings I
Credential Type
Combinations C
Re-authentication C
Security Requirements C
Credential Type
Combinations C
Re-authentication C
Re-authentication C
# OFFICIAL
OFFICIAL #
Credential Type
Combinations C
Re-authentication C
Re-authentication C
# OFFICIAL
OFFICIAL #
Document ID on Internal Doc Reference Assessment DTA comments

GovTEAMS OR (Page no., Status Requires
document name paragraph/sections)
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
# OFFICIAL
OFFICIAL #
Accepted Applicable to Role Applicability

[Y, N, N/A] Statement
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL
OFFICIAL #
No
No
No
No
No
No
No
No
No
No
No
No
No
# OFFICIAL

Tdif Accreditation Requirements - Release 4.8 Feb 2023 - Finance

Uploaded by

Copyright:

Available Formats

You might also like

Tdif Accreditation Requirements - Release 4.8 Feb 2023 - Finance

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tdif Accreditation Requirements - Release 4.8 Feb 2023 - Finance

Uploaded by

Copyright:

Available Formats

OFFICIAL #

>PROVIDER NAME< >TYPE OF ACCREDITATION<

Accreditation Role being sought

For Identity Service Providers

TDIF Application Letter checklist:

Name Role Email

Latest accreditation status

Functional Assessments completed: Expected Date

Privacy Impact Assessment

TDIF Initial Accreditation - Requirements Assessment

Outstanding Data Entry

TDIF Maintain Accreditation - Requirements Assessment

TDIF 06 Federation Onboarding - Requirements Assessment

Schedule & Progress

Decisions & Issues

Technical capability of service

For Credential Service Providers For Attribute Service Providers

Australian Government Digital Identity System

Total Requirements in TDIF

t during accreditation by the Department o

TDIF Requirement Subsection

ACCRED ACCRED-03-01-01 3.2.3.2

ACCRED ACCRED-03-01-01a 3.2.3.2

ACCRED ACCRED-03-01-01b 3.2.3.2

ACCRED ACCRED-03-01-02 3.2.3.2

ACCRED ACCRED-03-01-02b 3.2.3.2

ACCRED ACCRED-03-01-02c 3.2.3.2

ACCRED ACCRED-03-01-02d 4.3.1

ACCRED ACCRED-03-01-03 3.2.3.2

ACCRED ACCRED-03-01-03a 3.2.3.2

ACCRED ACCRED-03-01-03a 3.2.3.2

ACCRED ACCRED-03-01-03a 3.2.3.2

ACCRED ACCRED-03-01-03a 3.2.3.2

ACCRED ACCRED-03-01-04 3.2.3.2

ACCRED ACCRED-03-01-04 3.2.3.2

ACCRED ACCRED-03-01-04 3.2.3.2

ACCRED ACCRED-03-01-04a 3.2.3.2

ACCRED ACCRED-03-01-05 3.2.3.2

ACCRED ACCRED-03-01-06a 3.3.2

ACCRED ACCRED-03-01-06a 3.3.2

ACCRED ACCRED-03-01-06a 3.3.2

ACCRED ACCRED-03-01-07 3.3.2.3

ACCRED ACCRED-03-01-07a 3.3.2

ACCRED ACCRED-03-01-07a 3.3.2

ACCRED ACCRED-03-01-07a 3.3.2

ACCRED ACCRED-03-01-07b 3.3.2

ACCRED ACCRED-03-03-01a 3.3.3

ACCRED ACCRED-03-03-01b 3.3.3

ACCRED ACCRED-03-04-01 3.3.4

ACCRED ACCRED-03-04-01 3.3.4

ACCRED ACCRED-03-04-01 3.3.4

ACCRED ACCRED-03-04-01 3.3.4

ACCRED ACCRED-03-04-01 3.3.4

ACCRED ACCRED-03-04-02 3.3.4

FRAUD FRAUD-02-01-01 4.2.1

FRAUD FRAUD-02-01-02 4.2.1

FRAUD FRAUD-02-01-03 4.2.1

FRAUD FRAUD-02-01-03 4.2.1