05 role requirements

OFFICIAL

OFFICIAL

05 Role Requirements

Trusted Digital Identity Framework

Release 4 June 2021, version 1.7

PUBLISHED VERSION

Digital Transformation Agency — TDIF: 05 – Role Requirements iii

OFFICIAL

OFFICIAL

Digital Transformation Agency (DTA)

This work is copyright. Apart from any use as permitted under the Copyright Act 1968

and the rights explicitly granted below, all rights are reserved.

Licence

With the exception of the Commonwealth Coat of Arms and where otherwise noted,

this product is provided under a Creative Commons Attribution 4.0 International

Licence. (http://creativecommons.org/licenses/by/4.0/legalcode)

This licence lets you distribute, remix, tweak and build upon this work, even

commercially, as long as they credit the DTA for the original creation. Except where

otherwise noted, any reference to, reuse or distribution of part or all of this work must

include the following attribution:

Trusted Digital Identity Framework (TDIF)™05 – Role Requirements ©

Commonwealth of Australia (Digital Transformation Agency) 2021

Use of the Coat of Arms

The terms under which the Commonwealth Coat of Arms can be used are detailed on the It’s an Honour website (http://www.itsanhonour.gov.au)

Conventions

References to TDIF documents, abbreviations and key terms (including the words

MUST, MUST NOT, and MAY) are denoted in italics are to be interpreted as

described in the current published version of the TDIF: 01 – Glossary of

Abbreviations and Terms.

TDIF requirements and references to Applicants are to be read as also meaning

Accredited Providers, and vice versa. The scope of TDIF requirements are to be read

as applying to the identity system under Accreditation and not to the organisation’s

broader operating environment.

Contact us

The DTA is committed to providing web accessible content wherever possible. This

document has undergone an accessibility check however, if you are having

difficulties with accessing the document, or have questions or comments regarding

the document please email [email protected]

http://creativecommons.org/licenses/by/4.0/legalcode

http://www.itsanhonour.gov.au/

mailto:[email protected]

Digital Transformation Agency — TDIF: 05 – Role Requirements iv

OFFICIAL

OFFICIAL

Document management

The DTA has reviewed and endorsed this document for release.

Change log

Version Date Author Description of the changes

0.1 July 2019 SJP Initial version

0.2 Oct 2019 SJP Updated to incorporate feedback provided by stakeholders during the first round of collaboration on TDIF Release 4

0.3 Dec 2019 SJP Updated to incorporate feedback provided by stakeholders during the second round of collaboration on TDIF Release 4

0.4 Mar 2020 SJP Updated to incorporate feedback provided during the third consultation round on TDIF Release 4

1.0 May 2020 Published version

1.1 Aug 2020 MC Minor updates to Tables 1 and 5

1.2 Sep 2020 MC Minor update to IP3 wording and Table 1 Operation Objective and update to Appendix A UiTC Document Concession Card.

1.3 Jan 2021 JK CRID0005 – Emergency Change to CSP-04-01-05a – referenced requirement that did not exist. Corrected.

1.4 Feb 2021 JK, SJP CRID0008 – Emergency Change to IDP-03-07-03 – referenced incorrect requirement.

1.5 Mar 2021 JK CRID0017 – Emergency Change to IDP-03-08-21 – Temporary error while waiting for legislation to pass to implement

1.6 Mar 2021 AV, JK, SJP

Consultation Version - March 2021 version

1.7 Jun 2021 AV, JK, SJP

Published version CRID0006, CRID0009, CRID0012, CRID0016, CRID0018 - Changes to requirements, new requirements added, archived requirements: see Change Log for full list of requirements changes. Tables 1, 2, 3, 4 rewritten and reformatted.

All changes made to the TDIF are published in the TDIF Change Log which is

available at https://www.digitalidentity.gov.au/privacy-and-security/trusted-digital-

identity-framework.

https://www.digitalidentity.gov.au/privacy-and-security/trusted-digital-identity-framework

https://www.digitalidentity.gov.au/privacy-and-security/trusted-digital-identity-framework

Digital Transformation Agency — TDIF: 05 – Role Requirements v

OFFICIAL

OFFICIAL

Contents

1 Introduction ...................................................................................................................... 1

2 Common Role Requirements .......................................................................................... 2

2.1 User terms...................................................................................................................................... 2

2.1.1 Usage terms ............................................................................................................................ 2

2.1.2 Disclaimer and liability ............................................................................................................. 3

2.1.3 Third party service providers ................................................................................................... 3

2.1.4 Intellectual Property and use of information ............................................................................ 3

2.1.5 Fees and general terms .......................................................................................................... 4

3 Identity Service Provider Requirements ......................................................................... 5

3.1 Identity proofing concepts .............................................................................................................. 5

3.2 Identity Proofing ............................................................................................................................. 5

3.3 Individuals unable to meet Identity Proofing Requirements ........................................................ 15

3.4 Identity proofing lifecycle management ....................................................................................... 17

3.5 Identity proofing Step-Up ............................................................................................................. 18

3.6 Attribute collection, verification and validation ............................................................................. 18

3.7 Attribute disclosure ...................................................................................................................... 20

3.8 Biometric verification requirements .............................................................................................. 20

3.8.1 Requirements for online Biometric Binding ........................................................................... 21

3.8.2 Requirements for Presentation Attack Detection .................................................................. 21

3.8.3 Requirements for Document Biometric Matching ................................................................. 23

3.8.4 Photo ID specific requirements ............................................................................................. 24

3.8.5 Image quality specific requirements ...................................................................................... 25

3.8.6 Requirements for Local Biometric Binding ............................................................................ 25

3.8.7 Requirements for logging and data retention ........................................................................ 26

3.8.8 Manual Face Comparison specific requirements .................................................................. 27

4 Credential Service Provider Requirements ...................................................................28

4.1 Credential Levels ......................................................................................................................... 28

4.2 Credential types and requirements .............................................................................................. 15

4.2.1 Memorised Secrets ............................................................................................................... 15

Digital Transformation Agency — TDIF: 05 – Role Requirements vi

OFFICIAL

OFFICIAL

4.2.2 Look-up Secrets .................................................................................................................... 17

4.2.3 Out-of-band devices .............................................................................................................. 18

4.2.4 Single-factor one-time password (SF OTP) devices ............................................................. 22

4.2.5 Multi-factor one-time password (MF OTP) devices ............................................................... 23

4.2.6 Single-factor Cryptographic (SF Crypto) Software ................................................................ 25

4.2.7 Single-factor cryptographic (SF Crypto) devices .................................................................. 26

4.2.8 Multi-factor cryptographic (MF Crypto) software ................................................................... 27

4.2.9 Multi-factor Cryptographic (MF Crypto) Devices ................................................................... 28

4.3 General Credential requirements ................................................................................................. 29

4.3.1 Physical Credentials .............................................................................................................. 29

4.3.2 Rate limiting (Throttling) ........................................................................................................ 30

4.3.3 Biometrics (for Authentication use) ....................................................................................... 31

4.3.4 Credential Attestation ............................................................................................................ 33

4.3.5 CSP-impersonation Resistance ............................................................................................ 34

4.3.6 IdP-CSP communications ..................................................................................................... 35

4.3.7 CSP-compromise Resistance ............................................................................................... 35

4.3.8 Replay resistance .................................................................................................................. 35

4.3.9 Authentication intent .............................................................................................................. 36

4.3.10 Restricted Credentials ......................................................................................................... 36

4.4 Credential lifecycle management ................................................................................................. 37

4.4.1 Credential binding ................................................................................................................. 37

4.4.2 Binding at enrolment ............................................................................................................. 38

4.4.3 Binding additional Credentials............................................................................................... 39

4.4.4 Binding to a User-provided Credential .................................................................................. 40

4.4.5 Renewal ................................................................................................................................ 40

4.5 Loss, theft, damage and unauthorised duplication ...................................................................... 40

4.6 Credential expiration .................................................................................................................... 41

4.7 Credential revocation and termination ......................................................................................... 41

4.8 Session management .................................................................................................................. 42

4.9 Re-authentication ......................................................................................................................... 42

4.10 Credential Step-Up .................................................................................................................... 43

4.11 Certification Authorities .............................................................................................................. 44

Digital Transformation Agency — TDIF: 05 – Role Requirements vii

OFFICIAL

OFFICIAL

5 Attribute Service Provider Requirements ......................................................................46

5.1 Attribute Classes .......................................................................................................................... 46

5.2 General requirements .................................................................................................................. 47

6 Identity Exchange Requirements ...................................................................................49

6.1 Audit Logging Requirements ....................................................................................................... 49

6.2 Consent Management .................................................................................................................. 49

6.3 Single Sign On/Single Log out ..................................................................................................... 50

6.4 User Dashboard ........................................................................................................................... 50

6.5 IdP Selection ................................................................................................................................ 51

: Evidence types and verification methods ..................................................52

List of tables

Table 1: Identity Proofing Levels ................................................................................ 6

Table 2: Attribute collection, verification and validation ............................................ 19

Table 3: Assumed Self-asserted Attributes .............................................................. 19

Table 4: Credential Levels ....................................................................................... 15

Table 5: Attribute Classes ........................................................................................ 46

Table 6: Evidence types and verification methods ................................................... 52

Digital Transformation Agency–TDIF 05 Role Requirements 1

OFFICIAL

OFFICIAL

1 Introduction

This document sets out the TDIF role requirements to be met by Applicants to

achieve TDIF accreditation.

These TDIF role requirements do not replace, remove or diminish existing obligations

imposed on organisations or government agencies through other policies, legislation

or regulations, or by any other means. These TDIF role requirements supplement

existing obligations and apply specifically to Identity services that undergo the TDIF

Accreditation Process.

The intended audience for this document includes:

• Accredited Providers.

• Applicants.

• Assessors.

• Relying Parties.


OFFICIAL

OFFICIAL

2 Common Role Requirements

2.1 User terms

2.1.1 Usage terms

TDIF Req: ROLE-02-01-01; Updated: Mar-20; Applicability: A, C, I, X

The Applicant MUST have User terms that include:

a) A description of the nature of the Identity System (consistent with the TDIF)

provided to the User by the Applicant.

b) A general acknowledgment by the User that their use of the Identity System

provided by the Applicant is governed by the User terms.

c) The Applicant’s Identity System is provided on an ‘as is’ and ‘as available’

basis.

d) The scope of the User’s right to access and use the Identity System must be

consistent with the TDIF.

e) The User is responsible for their use of the Applicant’s Identity System,

including any Identity Documents it provides to the Applicant, and will use the

service in compliance with all applicable laws.

f) The User is responsible to provide accurate Identity Documents and Attributes

to the Applicant.

g) The Applicant does not share Attributes, Personal Information or sensitive

information, or Credentials with third parties without the Consent of the

Individual.

h) The User reports unauthorised use of their Digital Identity or Credential to the

Applicant as soon as they become aware of it.

i) The Applicant may suspend, cancel or terminate the User’s access to the

Identity System at any time.

j) That the Applicant may make changes to the User terms at any time without

prior notice and if the User terms are changed, the User’s continued use of the

Identity System will be subject to their acceptance of the updated User terms.


OFFICIAL

OFFICIAL

2.1.2 Disclaimer and liability


The Applicant MUST have User terms, including:

a) The Applicant gives no express or implied warranties or makes any

representation (and to the full extent permitted by law excludes all statutory

warranties) in relation to any part of its Identity System, including as to its or

their availability, performance, security or fitness for a particular purpose and in

respect of the availability, accuracy, completeness or correctness of any

information.

b) To the extent permitted by law, the Applicant will not be liable to the User or

any third party for any loss or damage arising from or in connection with the

availability, use or performance of the Identity System or any part of the

Identity System.

2.1.3 Third party service providers



a) The User’s access to the Identity System may be facilitated by third party

services or software and the provider may require, enable or facilitate access

to third party services or software.

b) The User is responsible for complying with any terms of any such third-party

service provider, including any other Accredited Participant.

c) To the extent permitted by law, the Applicant is not liable to the User for any

damage or loss arising in connection with User’s access to the service, either

directly or through a third-party provider.

2.1.4 Intellectual Property and use of information

TDIF Req: ROLE-02-01-04; Updated: Jun-21; Applicability: A, C, I, X


a) All title, rights and interest in and to the intellectual property of the Applicant,

including any modifications, corrections or enhancements thereto, will remain

vested in the Applicant, in accordance with the TDIF.


OFFICIAL

OFFICIAL

b) The User is liable for breaches of intellectual property caused by the User’s

use of the service other than in accordance with the TDIF.

c) The User must not use, reproduce, amend or alter intellectual property rights in

the service.

d) The User must comply with security requirements or instructions provided to it

by the Applicant.

2.1.5 Fees and general terms



a) That the Applicant will not be responsible for any fees charged by any other

Accredited Participant or a third-party provider used by the User to access the

service.

b) The governing law of the User terms.

c) Provisions setting out a process for dispute resolution.

d) A whole of agreement provision (i.e. that the terms represent the entire

agreement between the User and Applicant).

e) A severability provision.


The Applicant MUST NOT have User terms that are inconsistent with the User terms

required under the TDIF.

2.2 Operations Manual

TDIF Req: ROLE-02-02-01; Archived: Jun-21

This requirement has been archived in version 1.7.

TDIF Req: ROLE-02-02-01a; Archived: Jun-21


TDIF Req: ROLE-02-02-01b; Archived: Jun-21



OFFICIAL

OFFICIAL

3 Identity Service Provider Requirements

3.1 Identity proofing concepts

Identity proofing concepts, descriptions and guidance is available in TDIF 05A Role

Guidance.

The list of approved Evidence of Identity (EoI) documents that an Identity Service

Provider’s Identity System may support and the verification methods that must be

used by the IdP for each EoI document within the Identity Proofing process are set

out in Appendix A.

Descriptions of the Identity Proofing Levels are available in TDIF: 05A Role Guidance.

All Identity Proofing lifecycle management operations must be informed by the

Applicant’s Fraud Control Plan (FRAUD-02-02-01), Privacy Policy (PRIV-03-02-03)

and System Security Plan (PROT-04-01-12a). These requirements can be found in

TDIF 04 Functional Requirements.

3.2 Identity Proofing

TDIF Req: IDP-03-02-01; Updated: Jun-21; Applicability: I

At a minimum, the Applicant MUST operate a TDIF accredited Identity System at

Identity Proofing level 1 Plus as described in Table 1 below1

.

TDIF Req: IDP-03-02-02; Updated: Mar-20; Applicability: I

For each supported Identity Proofing Level, the Applicant MUST implement it as

described in Table 1 below.

1 This does not prevent an IdP from supporting IP1. Rather, TDIF accreditation will not be supported for Applicants that can only

meet IP1 requirements.


OFFICIAL

OFFICIAL

Table 1: Identity Proofing Levels

Requirements IP1 IP1 Plus IP2 IP2 Plus IP3 IP4

Intended use:

For very low-risk transactions where no verification of identity is required, but the parties desire a continuing conversation

For low-risk transactions or services where fraud will have minor consequences for the service or User

For moderate-risk transactions or services where fraud will have moderate consequences for the service or User

For moderate to high-risk transactions or services where fraud will have moderate to high consequences for the service or User

For high-risk transactions or services where fraud will have high consequences for the service or User

For very high-risk transactions or services where major consequences arise from fraudulent verifications.

Identity Proofing objectives2

Claimed identity meets: • Uniqueness

Claimed identity meets: • Uniqueness • Legitimacy • Fraud Control

Claimed identity meets: • Uniqueness • Legitimacy • Operation • Fraud Control

Claimed identity meets: • Uniqueness • Legitimacy • Operation • Binding • Fraud Control



Uniqueness Objective

Identifier chosen by the Individual is unique

MUST MUST MUST MUST MUST MUST

A check undertaken by the IdP to establish that the Individual is

the sole claimant of the Identity3

- MUST MUST MUST MUST MUST

Legitimacy Objective

A check undertaken by the IdP that the identity is not that of a deceased person

- MAY MAY MAY MUST MUST

2 See TDIF 05A Role Guidance for full descriptions of each proofing objective.

3 This MAY be done through checking internal organisation records for an Identity with the same Attributes.


OFFICIAL

OFFICIAL


Binding Objective

A check undertaken to confirm the link between the individual

and the claimed identity4

- - - MUST MUST MUST

The original, physical EoI documents to be provided in-person.

- - - - - MUST

In person interview required to satisfy the Binding Objective

- - - - - MUST

Fraud Control Objective

Checks to be undertaken against information or records held

within the IdP5to confirm the

identity is not known to be used fraudulently.

- MUST MUST MUST MUST MUST

Checks to be undertaken against information on known fraudulent identities from other

Authoritative Sources6

- MAY MAY MAY MAY MAY

Other Requirements

Personnel performing Identity Proofing processes required to be provided with tools and training to detect fraudulent Attributes and Identity

Documents7

- - MAY MAY MUST MUST

NAATI accredited translation of identity documents in languages

other than English required?8

- - MAY MAY MUST MUST

4 Verification of the link between the individual and the identity to occur through biometric verification in accordance with the requirements set out in Section 3.8.

5 Such as checks against internal registers of known fraudulent identities or vulnerable identities

6 Such as law enforcement or other government agencies.

7 Such as recognition of document security features, particularly for foreign documents.

8 National Accreditation Authority for Translators and Interpreters. Further information is available at https:///www.naati.com.au/


OFFICIAL

OFFICIAL


Attributes that MUST be verified with an Authoritative Source or

checked against evidence:9

- All names

Date of Birth

All names

Date of Birth

All names

Date of Birth

All names

Date of Birth

All names

Date of Birth

Documents required for Verification

IP1 IP1 Plus IP2 IP2 Plus IP3 IP4

Verification of a CoI document MUST be undertaken?

- - Yes or Photo ID

(see below) Yes or Photo ID

(see below) Yes10

Yes10

Verification of a Photo ID MUST be undertaken?

- Yes or UiTC

(see below)11

Yes or CoI

(see above)

Yes or CoI

(see above) Yes Yes

Verification of a UiTC document MUST be undertaken?

- - Yes x1 Yes x1 Yes x1 Yes x2

Verification of a Linking document MUST be undertaken if Attributes vary across EoI documents?

- - Yes Yes Yes Yes

Verification of a UiTC document MUST be undertaken that can confirm name and date of birth required?

- Yes or Photo ID (see above)11

- - - -

Approved technical Credential bindings

CL1/CL2/CL3 CL1/CL2/CL3 CL2/CL3 CL2/CL3 CL2/CL3 CL3

9 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 identity document to include these attributes.

10 Australian Passports MAY be used for CoI and Photo ID for up to IP3 proofing but MUST NOT be accepted as CoI for IP4 proofing.

11 To satisfy the Operation Objective at Identity Proofing Level 1 Plus, the Individual's name and date of birth MUST be verified.


OFFICIAL

OFFICIAL

3.3 Individuals unable to meet Identity Proofing Requirements

Although most Individuals should be able to meet the requirements set out in Table 1,

in some cases Individuals may face genuine difficulty in providing the necessary EoI

documents themselves to the required Identity Proofing Level. The IdP may develop

alternative Identity Proofing processes for these exception cases.

Exception cases are those where an Individual does not possess, and is unable to

obtain, the necessary information or EoI documents to the required Identity Proofing

Level. This may include:

• Individuals whose birth was not registered.

• Individuals who are homeless or displaced.

• Undocumented arrivals to Australia.

• Individuals living in remote areas.

• Individuals who do not have enough Identity Documents, for example, foreign

nationals living in Australia or Australians living in other countries.

• Individuals who do not have any Identity Documents but need a Digital Identity,

for example, foreign nationals living outside Australia who need to access

government systems or services.

• Individuals who are transgender or intersex.

• Individuals effected by natural disasters.

• Individuals with limited access to Identity Documents, for example, Individuals

who were raised in institutional or foster care.

• Individuals with limited participation in society.

• Young people and those over 18 years who are yet to obtain EoI documents.


The Applicant MAY implement alternative Identity Proofing processes to the

requirements set out in Table 1 to support exceptions cases.


OFFICIAL

OFFICIAL

TDIF Req: IDP-03-03-01a; Updated: Jun-21; Applicability: I

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 and consistent with

requirement IDP-03-03-01b

TDIF Req: IDP-03-03-01b; Updated: Mar-20; Applicability: I

All alternative Identity Proofing processes an Applicant implements to support

exceptions cases MUST be informed by a Risk Assessment. Evidence of these

alternative processes and Risk Assessment will be requested by the DTA as part of

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


OFFICIAL

OFFICIAL

3.4 Identity proofing lifecycle management

This section sets out the requirements for Identity Proofing lifecycle management

activities undertaken by the Applicant. As part of this process the Applicant may

collect Personal information from Identity Documents listed in Table 6 (Appendix A)

with the Individual’s Express Consent.


The Applicant MUST allow Individuals to update their Attributes held by the Applicant.

TDIF Req: IDP-03-04-01a; Updated: Mar-20; Applicability: I

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


Where unusual transactions are detected, the Applicant MUST verify the Digital

Identity is still under the control of its legitimate account holder.


When requested to do so, the Applicant MUST prevent the continued use of a Digital

Identity (e.g. temporary suspension while traveling abroad).


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


OFFICIAL

OFFICIAL

3.5 Identity proofing Step-Up

The requirements in this section only apply to an Applicant if their Identity System

supports Step-Up of Identity Proofing from one Identity Proofing Level to another12

.

Step-Up is supported for all Identity Proofing Levels.


The Applicant MUST achieve all the requirements of the higher Identity Proofing

Level.


The Applicant MUST ensure that an Individual can prove ownership of their existing

Identity by authenticating with their Credential to their account prior to commencing

the Identity Proofing Step-Up process.

3.6 Attribute collection, verification and validation


The Applicant MUST NOT collect, verify or validate Attributes beyond those listed in

Table 2 and Table 31314

.

TDIF Req: IDP-03-06-02; Archived: Jun-21


12

An IdP can offer multiple proofing levels without offering Identity Proofing Step-up

13 An Applicant must demonstrate to the DTA a need for its accredited identity system to collect, verify and validate Attributes

beyond those listed in tables 2 and 3. An Applicant’s accredited identity system must be separate from the Applicant’s other

business operations.

14 Biometric attributes and verification are covered in section 3.8 Biometric Verification Requirements


OFFICIAL

OFFICIAL

Table 2: Attribute collection, verification and validation

Attribute collection, verification and validation

Identity Attributes (verified)

All verified names – family name(s), given name(s), surname(s), full name(s),

previous name(s) as recorded on the EoI document

Verified date of birth as recorded on the EoI document [if collected]

Contact Attributes (validated)

Mobile phone number

Email address

EoI document Attributes (verified restricted Attributes)

EoI document type name

EoI document type code

EoI document issuer

EoI document identifier(s) (e.g. registration, document, licence, or card numbers)

EoI document issuer state

Other EoI document Attributes (i.e. other Attributes on the document verified by an

Authoritative Source)

Verification method used for each EoI document (i.e. S, T, V)

Date and time the EoI document was verified

Identity System metadata

Date and time Attributes last updated (i.e. verified names and date of birth)

Date and time email address was last validated (if collected)

Date and time mobile phone number was last validated (if collected)

Date and time the User authenticated at the Identity Service Provider

Identity Proofing Level achieved

Date and time the Digital Identity was created

Digital Identity (User Identifier)

Table 3: Assumed Self-asserted Attributes

Attributes that may be collected and recorded15

Preferred name(s)

Residential address

Postal address

Other address (e.g. second residential address)

Other phone number (e.g. landline)

Place of Birth

Titles (e.g. Dr. Mr, Ms)

15

Assumed Self-asserted attributes in this table are limited and are considered separate from Assumed Self-asserted attributes

that an Attribute Service Provider (ASP) may offer. See Section 5 of this document for a list of ASP requirements.


OFFICIAL

OFFICIAL





3.7 Attribute disclosure


In accordance with PRIV-03-09-05, the Applicant MUST limit this disclosure to

Attributes listed in Table 2.

TDIF Req: IDP-03-07-01a; Archived: Jun-21



In accordance with PRIV-03-09-01, the Applicant MUST limit this disclosure to the

following Attributes:

• Identity Attributes (verified) listed in Table 2.

• Contact Attributes (validated) listed in Table 2.

• Identity System metadata listed in Table 2.

• Assumed Self-asserted Attributes listed in Table 3.


The Applicant MUST seek permission from the DTA to disclose Attributes beyond

those listed in IDP-03-07-02.

TDIF Req: IDP-03-07-03a; Updated: Jun-21; Applicability: I

The Applicant MUST NOT disclose Attributes beyond those listed in IDP-03-07-02

unless approved by the DTA to do so.

3.8 Biometric verification requirements

This section sets out requirements to confirm the link between the Individual and the

Identity being claimed using Biometric verification.


OFFICIAL

OFFICIAL

3.8.1 Requirements for online Biometric Binding


The Applicant MUST restrict access to the control of any aspects of the biometric

capability exclusively to Assessing Officers that have completed the appropriate

training pertaining to the exercise of such control.


To complete Online Biometric Binding the Applicant MUST either:

• capture and send the Acquired image to the Photo ID Authoritative Source (or

proxy) in the case of Source Biometric Matching; or,

• capture and perform Document Biometric Matching of the Acquired Image

against the image read directly from the Photo ID RFID chip.


The Applicant MUST incorporate Presentation Attack Detection when performing

Online Biometric Binding.


The Applicant MUST complete the image capture and Presentation Attack Detection

processes as part of the same process before submission to Online Biometric

Binding. This is to prevent attacks that would exploit the separation of the

Presentation Attack Detection and the image acquisition.

3.8.2 Requirements for Presentation Attack Detection


The Applicant MUST employ Presentation Attack Detection technology to determine if

the Acquired image is of a living human subject present at the point of capture.


The Applicant MUST include liveness detection processes as part of Presentation

Attack Detection.


The Applicant MUST employ Presentation Attack Detection technology that includes

data capture and system level monitoring as described by ISO 30107-1.


OFFICIAL

OFFICIAL


The Applicant MUST ensure that the Presentation Attack Detection technology meets

the requirements of at least Evaluation Assurance Level 1 as described by ISO

30107-3.


If the comprehensive Risk Assessment undertaken by the Applicant indicates that the

Presentation Attack Detection technology used in the capability must exceed these

standards, the Applicant MUST meet the requirements described in the Risk

Assessment.


The Applicant capability MUST have been tested by a qualified third-party testing

entity with experience in biometric testing and ISO 30107 to determine that the

Presentation Attack Detection technology meets the requirements for at least

Evaluation Assurance Level 1 of ISO 30107-3.


The Applicant MUST have determined Presentation Attack Detection outcomes in a

Trusted Computing Environment.


All testing performed MUST have been performed on a solution that incorporates all

hardware and software involved in the Biometric Binding process including the

Presentation Attack Detection technology and Biometric Matching.

TDIF Req: IDP-03-08-09c; Updated: Mar-2020; Applicability: I

Any determinations made by manual processes MUST be recorded separately to the

Biometric Matching or Presentation Attack Detection systems.


The Applicant MUST provide a report to the DTA as part of initial accreditation from

the qualified third-party testing entity outlining that the Applicant’s Presentation Attack

Detection technology has been suitably tested to the specifications of at least

Evaluation Assurance Level 1 of ISO 30107-3.


The report MUST describe the completed Presentation Attack Detection evaluation

and corresponding results for each presentation attack type with the closest possible

adherence to reporting specifications as described in ISO 30107-3.


OFFICIAL

OFFICIAL


The report MUST be completed annually thereafter and provided to the DTA as part

of the Annual Assessment.

3.8.3 Requirements for Document Biometric Matching


The Applicant MUST verify the authenticity of the image read from the Photo ID RFID

chip according to the Photo ID Issuing Authority instructions.


The Applicant MUST only process Claimed Photo ID through Document Biometric

Matching that contain a government issued and cryptographically signed image, such

as an ePassport.


The Applicant MUST use a Biometric Matching algorithm to perform one-to-one

verification matching between the Acquired image and the Photo ID image.


The Applicant MUST NOT use a Biometric Matching algorithm to perform one-to-

many matching against a database of reference images as part of the Biometric

Binding process.


The Applicant MUST ensure their Biometric Matching algorithm is tested by a

qualified third-party testing entity to determine the failure to enroll rate (if applicable),

failure to acquire rate, false match rate and false non-match rate of the capability as

per the reporting specification described in ISO 19795.


This MUST be tested under production-like conditions.

TDIF Req: IDP-03-08-15b; Updated: Jun-21; Applicability: I

The minimum number of subjects for the testing MUST be at least the same as

described in current published version of the FIDO Biometric Requirements16

.

16

This number is 245 as of the publication date of the TDIF 05 Role Requirements Release 4 V1.7.


OFFICIAL

OFFICIAL


The testing MUST be performed in a verification scenario with comparable image

types to production expectations.


The Applicant MUST achieve a false match rate equivalent to or lower than FIDO

Biometric Requirements. This requires a false match rate of not more than 0.01% and

a false non-match rate of not more than 3%.


The Applicant MUST record Biometric Matching outcomes in a Trusted Computing

Environment.

3.8.4 Photo ID specific requirements


Where the Photo ID used has an RFID chip that is available and functional, the

Applicant MUST perform a biometric match of the Acquired image only against the

image read directly from the Photo ID RFID chip.

TDIF Req: ID-03-08-17a; Updated: Jun-21; Applicability: I

Where an RFID chip is not available, the Photo ID image used for Biometric Matching

MUST NOT be from a scan of a physical document.


Where the Photo ID used is an Australian ePassport, the Applicant MUST check the

Country Signing Certification Authority (CSCA) Certificate as per the International

Civil Aviation Organization (ICAO) document validation guidelines OR perform a DVS

check. Where the Australian ePassport security certificate is checked, the Australian

Certificate Revocation List must also be checked.


Where an RFID chip is not available, non-functional or the document security is lower

than that of the Australian ePassport, a DVS check MUST be performed by the

Applicant.


A DVS check MUST be performed by the Applicant where the Photo ID used is a

foreign ePassport to ensure that the foreign ePassport is linked to a current visa.


OFFICIAL

OFFICIAL


Where the Photo ID used is a foreign ePassport and an RFID chip is not available or

non-functional the Applicant MUST attempt to perform a biometric match against the

corresponding image recorded against that identity from the Photo ID Authoritative

Source.

TDIF Req: IDP-03-08-18d; Updated: Mar-2020; Applicability: I

Where the Photo ID used is a foreign ePassport and an RFID chip is not available or

non-functional and the corresponding image recorded against that identity from the

Photo ID Authoritative Source is unavailable, the Applicant MUST perform Local

Biometric Binding.

3.8.5 Image quality specific requirements


The Applicant MUST produce an Acquired image quality profile informed by the

properties and characteristics described by ISO 29794-5 which details a set of

minimum standards that the Acquired image must meet before Biometric Matching.


The Applicant MUST include automated quality controls and appropriate User-

interface instructions that directs Users to provide an image that meets the Acquired

image quality profile.

3.8.6 Requirements for Local Biometric Binding


The Applicant MAY perform Source Biometric Matching to supplement Manual Face

Comparison by performing a biometric match against the corresponding image

recorded against that identity from the Photo ID Authoritative Source.


The Applicant MUST perform a DVS check as part of the Local Biometric Binding

process to confirm the authenticity of a Photo ID.


The Applicant MUST train relevant Assessing Officer’s on Manual Face Comparison

techniques including, but not limited to:


OFFICIAL

OFFICIAL

• Techniques for Individual feature comparison

• Awareness of racial and cognitive biases

• Presentation attack indicators

• Guided matching examples

The training material MUST be provided by the Applicant to the DTA as part of initial

accreditation and annually thereafter as part of the Annual Assessment.

3.8.7 Requirements for logging and data retention


The Applicant MUST maintain the information associated with each Individual

transaction, including a log of activities that details which Assessing Officer collected

data, what data was collected, when and where the data was collected.


This log MUST NOT include Biometric Samples.


The Applicant MUST have in place audit or random checking procedures to help

detect fraud or inadequate Manual Face Comparison and verification by Assessing

Officers.


The Applicant MUST NOT retain any personally identifiable information captured in

Biometric Binding processes.


The Applicant MUST ensure that it is responsible for the destruction of all Biometric

Samples, including all copies, caches, and intermediary databases, including any

subcontractors or third-party components.


This destruction process MUST be documented by a specific Audit Log.


The Acquired image MUST, unless required by law, then be destroyed consistent with

PRIV-03-08-02.


OFFICIAL

OFFICIAL

3.8.8 Manual Face Comparison specific requirements


The Applicant MAY utilise manual processors performed by Assessing Officers to

complete Local Biometric Binding or Online Biometric Binding processes.


The Applicant MAY utilise manual processors to review and/or adjust decisions made

by the Applicant capability, including biometric match results and Presentation Attack

Detection.


The Acquired image MUST NOT be retained after completion of the Local Biometric

Binding or Online Biometric Binding processes by the Assessing Officer.


If the Applicant utilises manual processes, The Applicant MUST include this in their

Risk Assessment for Biometric Binding processes.


The Applicant MUST maintain an Audit Log of manual processes that meets the

requirements of the TDIF. This includes records of transactions in production and the

training activities of Assessing Officers. The Audit Log MUST be auditable by the

DTA.


The Applicant MUST only perform remote Manual Face Comparison for Online

Biometric Binding after attempting a Biometric Match.


The Applicant MUST only undertake remote Manual Face Comparison utilising

Assessing Officers located within Australia.


OFFICIAL

OFFICIAL

4 Credential Service Provider Requirements

These Credential Service Provider requirements:

• have been developed from the National Institute of Standards and Technology

(NIST), Special Publication (SP) 800-63B, Digital Identity Guidelines –

Authentication and Lifecycle Management (NIST SP 800-63B).

See: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-

63b.pdf

• refer to controls in the latest edition of the Information Security Manual (ISM).

See: https://www.cyber.gov.au/acsc/view-all-content/ism

• assume a high-level of technical knowledge. Italicised words are defined in

TDIF 01 Glossary.

All Credential lifecycle management operations must be informed by the Applicant’s

Fraud Control Plan (FRAUD-02-02-01), Privacy Policy (PRIV-03-02-03) and System

Security Plan (PROT-04-01-12a). These requirements can be found in TDIF 04

Functional Requirements.

4.1 Credential Levels

TDIF Req: CSP-04-01-01; Updated: Jun-21; Applicability: C

The Applicant MUST support at least one of the Credential Levels described in Table

4.


For each supported Credential Level, the Applicant MUST implement it to meet all

requirements as described in Table 4.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf

https://www.cyber.gov.au/acsc/view-all-content/ism


OFFICIAL

OFFICIAL

Table 4: Credential Levels

Requirement CL1 CL2 CL3

Permitted Credential types17

ONE OF:

• Memorised Secrets

• Look-up Secrets

• Out-of-Band Devices

• SF OTP Device

• SF Crypto Software

• SF Crypto Devices

• MF OTP Devices

• MF Crypto Software

• MF Crypto Devices

ONE OF:

• Memorised Secrets

• MF OTP Devices

• MF Crypto Software


AND ONE OF:

• Look-up Secrets

• Out-of-Band Devices

• SF OTP Devices

• SF Crypto Software

• SF Crypto Devices


OR

• SF Crypto Devices AND

Memorised Secrets

OR

• SF OTP Devices AND MF

Crypto Software

OR

• SF OTP Devices AND MF

Crypto Devices

OR

• SF OTP Devices AND SF

Crypto Software AND

Memorised Secrets

Re-authentication requirements 30 days 12 hours or 30 minutes of inactivity.

MAY use one Authentication factor

12 hours or 15 minutes of inactivity.

MUST use both Authentication factors

Security requirements

Man-in-the-Middle resistance MUST MUST MUST

CSP-impersonation Resistance - - MUST

CSP-compromise Resistance - - MUST

Replay Resistance - MUST MUST

Authentication Intent - MAY MUST

Approved Identity Proofing

combinations

IP1 and IP1 PLUS IP1 through IP3 (inclusive) All Identity Proofing Levels

17

Expanded terms include: Single-Factor One Time Password (SF OTP), Single-Factor Cryptographic (SF Crypto), Multi-Factor One Time Password (MF OTP), Multi-Factor Cryptographic (MF Crypto)


OFFICIAL

OFFICIAL

TDIF Req: CSP-04-01-03; Updated: Mar-20; Applicability: C

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

TDIF Req: CSP-04-01-05a; Updated: Mar-20; Applicability: C

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.

TDIF Req: CSP-04-01-05b; Updated: Mar-20; Applicability: C

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 Credential types and requirements

4.2.1 Memorised Secrets


If Memorised Secrets are supported, then the Applicant MUST implement the

following requirements for the operation of Memorised Secrets.

TDIF Req: CSP-04-02-01a; Updated: Jun-21; Applicability: C

Memorised Secrets MUST be at least 8 characters in length if chosen by the

Individual.

TDIF Req: CSP-04-02-01b; Updated: Jun-21; Applicability: C

Memorised Secrets chosen randomly by the Applicant MUST be at least 6

characters in length and MAY be entirely numeric.


OFFICIAL

OFFICIAL

TDIF Req: CSP-04-02-01c; Updated: Jun-21; Applicability: C

If the Applicant disallows a chosen Memorised Secret based on its appearance on a

blacklist of compromised values, the Individual MUST be required to choose a

different Memorised Secret.

TDIF Req: CSP-04-02-01d; Updated: Jun-21; Applicability: C

When processing requests to establish and change Memorised Secrets, the

Applicant MUST compare the prospective secrets against a list that contains values

known to be commonly used, expected, or compromised. For example, the list may

include, but is not limited to:

• Passwords obtained from previous breach corpuses.

• Dictionary words.

• Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).

• Context-specific words, such as the name of the service, the username, and

derivatives thereof.

TDIF Req: CSP-04-02-01e; Updated: Jun-21; Applicability: C

If the chosen secret is found in the list, the Applicant MUST:

• advise the Individual that they need to select a different secret,

• provide the reason for rejection, and

• require the Individual to choose a different value.

TDIF Req: CSP-04-02-01f; Updated: Jun-21; Applicability: C

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.

TDIF Req: CSP-04-02-01g; Updated: Jun-21; Applicability: C

The Applicant MAY permit Individuals to use the “paste” functionality when entering

a Memorised Secret. This facilitates the use of password managers, which are

widely used and, in many cases, increase the likelihood that Individuals will choose

stronger Memorised Secrets.


OFFICIAL

OFFICIAL

TDIF Req: CSP-04-02-01h; Updated: Jun-21; Applicability: C

To assist the Individual in successfully entering a Memorised Secret, the Applicant

MAY offer an option to display the secret—rather than a series of dots or asterisks—

until it is entered. This allows the Individual to verify their entry if they are in a

location where their screen is unlikely to be observed.

TDIF Req: CSP-04-02-01i; Updated: Jun-21; Applicability: C

The Applicant MAY permit the Individual’s device to display individual entered

characters for a short time after each character is typed to verify correct entry. This is

particularly applicable on mobile devices.

TDIF Req: CSP-04-02-01j; Updated: Jun-21; Applicability: C

The Applicant MUST use Australian Signals Approved Cryptographic Algorithms

(AACAs) and an Authenticated Protected Channel when requesting Memorised

Secrets to provide resistance to eavesdropping and Man-in-the-Middle (MitM)

attacks.

TDIF Req: CSP-04-02-01k; Updated: Jun-21; Applicability: C

The Applicant MUST store Memorised Secrets in a form that is resistant to offline

attacks.

TDIF Req: CSP-04-02-01l; Updated: Jun-21; Applicability: C

Memorised Secrets MUST be salted and hashed using a suitable one-way Key

derivation function.

TDIF Req: CSP-04-02-01m; Updated: Jun-21; Applicability: C

The salt MUST be at least 32 bits in length and be chosen arbitrarily so as to

minimise salt value collisions among stored hashes.

TDIF Req: CSP-04-02-01n; Updated: Jun-21; Applicability: C

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.



OFFICIAL

OFFICIAL

An Applicant creating Look-up Secrets MUST deliver them securely to the Individual.


Look-up Secrets MUST prompt the Individual for the next secret (e.g. the next

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


Look-up Secrets MUST be hashed using an AACA.


The salt value MUST be at least 32 bits in length and arbitrarily chosen so as to

minimise salt value collisions among stored hashes.


Both the salt value and the resulting hash MUST be stored 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



OFFICIAL

OFFICIAL

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. This channel is out-of-

band with respect to the primary communication channel (even if it terminates on the

same device) provided the device does not leak information from one channel to the

other without consent of the Individual.


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 cryptography18

.

• 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:

• The device MUST accept transfer of the secret from the primary channel,

which it MUST send to the Applicant over the secondary channel to associate

the approval with the Authentication transaction.

• The device MUST present a secret received via the secondary channel from

the Applicant and prompt the Individual to verify the consistency of that secret

18

This includes using AACAs and Australian Signals Directorate Approved Cryptographic Protocols (AACPs).


OFFICIAL

OFFICIAL

with the primary channel, prior to accepting a yes/no response from the

Individual. It MUST then send that response to the Applicant.

The Individual MAY perform the transfer manually or use a technology such as a

barcode or QR code to effect the transfer.


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.


Depending on the type of out-of-band device, one of the following options (1, 2, OR

3) MUST take place:

1. Transfer of secret to primary channel:

o The Applicant MUST signal the device containing the Individual’s

Credential to indicate readiness to authenticate

o It MUST then transmit a random secret to the out-of-band device

o The Applicant MUST then wait for the secret to be returned on the

primary communication channel.

2. Transfer of secret to secondary channel:

o The Applicant MUST display a random Authentication secret to the

Individual via the primary channel

o It MUST then wait for the secret to be returned on the secondary

channel from the Individual’s out-of-band device.

3. Verification of secrets by the Individual:


OFFICIAL

OFFICIAL

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.


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




If out-of-band verification is to be made using the PSTN, the Applicant MUST

validate that the pre-registered telephone number being used is associated with a

specific physical device.



OFFICIAL

OFFICIAL

The Applicant MUST consider risks associated with device swap, SIM change,

number porting or other abnormal behaviour before using the PSTN to deliver an

out-of-band Authentication secret.


Risks of using the PSTN MUST be recorded in the Applicant’s System Security Plan

and managed accordingly.

4.2.4 Single-factor one-time password (SF 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.



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



4.2.5 Multi-factor one-time password (MF OTP) 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.



OFFICIAL

OFFICIAL

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.



collecting the OTP to provide resistance to eavesdropping and MitM attacks.


The Applicant MUST also establish that the Credential is a MF OTP device.



OFFICIAL

OFFICIAL

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



4.2.6 Single-factor Cryptographic (SF Crypto) 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 by using

access controls that limit access to the Key to only those software components on

the device requiring access.


OFFICIAL

OFFICIAL


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 (SF Crypto) 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).


OFFICIAL

OFFICIAL


The secret Key and its algorithm MUST provide at least the minimum-security length

specified in the latest edition of the ISM.




The challenge nonce MUST either be unique over the Credential’s lifetime or be



Approved cryptography (i.e. AACAs and AACPs) MUST be used.





4.2.8 Multi-factor cryptographic (MF Crypto) 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.


OFFICIAL

OFFICIAL


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



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 (MF Crypto) Devices


If Multi-factor Cryptographic Devices are supported, the Applicant MUST implement

the following requirements for the operation of Multi-factor Cryptographic Devices.


OFFICIAL

OFFICIAL


The secret Key and its algorithm MUST provide at least the minimum-security length





The challenge nonce MUST either be unique over the Credential’s lifetime or, be



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


OFFICIAL

OFFICIAL


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


OFFICIAL

OFFICIAL

4.3.3 Biometrics (for Authentication use)


If the use of biometrics for Authentication is supported, then the Applicant MUST

implement the following requirements for the operation of biometrics for

Authentication.


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.


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.


OFFICIAL

OFFICIAL


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:

• Impose a delay of at least 30 seconds before the next attempt, increasing

exponentially with each successive attempt (e.g. 1 minute before the following

failed attempt, 2 minutes before the second following attempt), or

• Disable the biometric User Authentication and offer another factor (e.g. a

different biometric modality or a PIN/Passcode if it is not already a required

factor) if such an alternative method is already available.


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 requirements:

• Use of the biometric as an Authentication factor MUST be limited to one or

more specific devices that are identified using approved cryptography (i.e.

AACAs and AACPs)

• Since the biometric has not yet unlocked the main Authentication Key, a

separate Key MUST be used for identifying the device

• Biometric revocation, referred to as ‘biometric template protection’ in ISO/IEC

24745, MUST be implemented


OFFICIAL

OFFICIAL

• All transmission of biometrics MUST be over the Authenticated Protected

Channel.


Biometric Samples collected in the Authentication process MAY be used to train

comparison algorithms or — with User Express Consent — for other research

purposes.


Biometric Samples and any biometric data derived from the Biometric Sample such

as a probe produced through signal processing MUST be zeroised immediately after

any training or research data has been derived.

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.


Attestation information MAY be used as part of an Applicant’s risk-based

Authentication decision.


OFFICIAL

OFFICIAL

4.3.5 CSP-impersonation Resistance

As per Table 4, CSP-impersonation Resistance is required at CL3.


Where the Applicant supports CL3, it MUST implement the following CSP-

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. This prevents an impostor CSP Attacker, even one that

has obtained a certificate representing the actual CSP, from replaying that

Authentication on a different Authenticated Protected Channel.


AACAs MUST be used to establish CSP-impersonation Resistance where it is

required.


Keys used for this purpose MUST provide at least the minimum-security strength



OFFICIAL

OFFICIAL


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

TDIF Req: CSP-04-03-06; Updated: Jun-21; Applicability: C, I

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

As per Table 4, CSP-compromise Resistance is required at CL3.


Where the Applicant supports CL3, it MUST implement the following CSP-

compromise Resistance requirements. These requirements do not need to be

implemented for CL1 or CL2.


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 Replay resistance

As per Table 4, replay resistance is required at CL2 and CL3.


OFFICIAL

OFFICIAL


Where the Applicant supports CL2 or CL3, it MUST implement at least one of the

following Credentials:

• OTP Devices

• Out-of-band Devices

• Cryptographic-based Credentials

• Look-up Secrets.

4.3.9 Authentication intent

As per Table 4, Authentication intent is required at CL 3.


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 re-authentication 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 prevent continued use of that

Credential. Such Credentials are referred to as Restricted Credentials.


If the Applicant supports the use of a Restricted Credential, it MUST:


OFFICIAL

OFFICIAL

1. Offer Individuals at least one alternate Credential that is not restricted and can

be used to authenticate at the required CL

2. Provide meaningful notice to Individuals regarding the security risks of the

Restricted Credential and availability of alternative(s) that are not restricted

3. Address any additional risk to Individuals in its security Risk Assessment

4. Develop a migration plan for the possibility that the Restricted Credential is no

longer acceptable at some point in the future.

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 Applicant MUST also verify the Credential type of a User-provided Credential

(e.g. Single-factor Cryptographic Device vs. Multi-factor Cryptographic Device) so

the Applicant can determine compliance with requirements at each CL.


The record created by the Applicant MUST contain the date and time the Credential

was bound to the account.


OFFICIAL

OFFICIAL


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:

• The Individual MUST identify themselves in each new binding transaction by

presenting a temporary secret which was either established during a prior

transaction or sent to the Individual’s mobile phone number or email address.

• Long-term Authentication secrets MUST only be issued to the Individual within

a protected Session.


For in-person transactions where enrolment and binding cannot be completed in a

single physical encounter (i.e. within a single protected Session), the following

requirements MUST be met to ensure that the same party acts as the Individual

throughout the process:

• The Individual MUST identify themselves in-person by either using a secret as

described in CSP-04-04-02, or through use of a biometric that was recorded

during the identity proofing process.

• Temporary secrets MUST NOT be reused


OFFICIAL

OFFICIAL

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

4.4.3 Binding additional Credentials


If the Applicant supports the Binding of additional Credentials to an Individual’s

account, then it MUST implement the following requirements when 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.


Before Binding a new Credential to an account, the Applicant MUST require the

Individual to authenticate with a Credential of at least CL1.


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

TDIF Req: CSP-04-04-05; Archived: Jun-21



OFFICIAL

OFFICIAL

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 User 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 the detection or report of loss, theft, damage or

unauthorised duplication of a Credential.


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.


OFFICIAL

OFFICIAL


The suspension of a compromised Credential MUST be reversible if the Individual

successfully authenticates to the Applicant using a valid (i.e. not suspended)

Credential and requests reactivation of a Credential suspended in this manner.


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


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


OFFICIAL

OFFICIAL

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 event wherein the

Individual repeats some or all of the initial Authentication event, thereby re-

establishing the Session.









4.9 Re-authentication


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.


OFFICIAL

OFFICIAL


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 re-authentication 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 Step-Up of a Credential from one Credential Level to another is supported by

the Applicant, then it MUST implement the following requirements for the operation

of Step-Up for all Credential Levels.


The Applicant MUST be accredited to issue a Credential at the higher Credential

Level.


The Credential MUST meet all the requirements of the higher Credential level.


The Applicant MUST ensure that an Individual can prove ownership of their existing

Identity by authenticating with their Credential to their account prior to commencing

the Credential Step-Up process.


OFFICIAL

OFFICIAL

4.11 Certification Authorities


If Certification Authorities are supported, then the Applicant MUST implement all of

the following requirements to operate as a Certification Authority.


The Applicant MUST ensure all:

a. Certification Practice Statements (CPS) and Certificate Policies (CP) conform

to Request for Comment (RFC) 3647

b. Digital Certificates conform to the (RFC) 5280 format

c. Certificate Revocation Lists (CRLs) conform to the X.509 version 2 profile as

described in RFC 5280

d. Online Certificate Status Protocol (OCSP) responses conform to RFC 6960.


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:

• The Individual notifies the Applicant that a Digital Certificate request was not

authorised by them.

• The Applicant obtains evidence that a Digital Certificate’s Private Key suffered

a Key compromise or no longer complies with the requirements outlined in the

Certificate Policy.


OFFICIAL

OFFICIAL

• The Applicant obtains evidence that a Digital Certificate it has issued has

been misused.

• The Applicant is made aware that an Individual has violated one or more of

their usage terms (for example, those set out in ROLE-02-01-01).

• The Applicant is made aware that the Certificate was not issued in

accordance with its Certification Practice Statements or Certificate Policy.

• The Applicant determines that any information set out in the Digital Certificate

is inaccurate or misleading.

• The Applicant obtains evidence of a suspected or actual compromise of a

subordinate CA’s Private Key.


OFFICIAL

OFFICIAL

5 Attribute Service Provider Requirements

All Attribute lifecycle management operations must be informed by the Applicant’s

Fraud Control Plan (FRAUD-02-02-01), Privacy Policy (PRIV-03-02-03) and System

Security Plan (PROT-04-01-12a). These requirements can be found in TDIF 04

Functional Requirements.

5.1 Attribute Classes

TDIF Req: ASP-05-01-01; Updated: Mar-20; Applicability: A

The Applicant MUST support at least one Attribute Class as described in Table 6.

Table 5: Attribute Classes

Attribute Class Description

Authorisation An Individual gives a permission, delegation or privilege for

someone to act on their behalf. (e.g. an Individual authorised to

act on behalf of their children when applying for a government

service).

Qualification A statement of attainment by an education or training

organization consistent with the AQF19

(e.g. a bachelor’s degree

from an Australian university).

Entitlement Meeting a set of conditions which enables a Individual to have a

right to something (e.g. an Individual is a resident of an

Australian state or territory aged over 60 years and not working

more than a set number of hours per week is entitled to a

Seniors Card).

Assumed Self-

asserted

Unverified Attributes provided by an Individual that can assist

with service delivery, such as prefilling online forms. This

Attribute Class can be used for ‘Tell Us Once’ services.

Platform Attributes which uniquely identify platforms and ICT systems that

connect into the Australian Government’s identity federation. For

example, MyGov.


The Applicant MAY directly connect to an Identity Service Provider.

TDIF Req: ASP-05-01-03; Updated: Mar-20; Applicability: A, I

19

Australian Qualifications Framework. Further information is available at https://www.aqf.edu.au/


OFFICIAL

OFFICIAL

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.

5.2 General requirements


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.

TDIF Req: ASP-05-02-01a; Updated: Mar-20; Applicability: A

Where the Applicant manages Attributes on behalf of an Authoritative Source, it

MUST provide evidence of this arrangement to the DTA. Evidence of this

arrangement will be requested by the DTA as part of initial accreditation and

annually thereafter as part of the Annual Assessment.


The Applicant MUST 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 an authorised

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


OFFICIAL

OFFICIAL


The Applicant MAY support issuing or linking multiple Attributes and Attribute

Classes to a Person.


The Applicant MAY support issuing or linking multiple Attributes relating to the same

entity to a Person.

TDIF Req: ASP-05-02-06b; Updated: Mar-20; Applicability: A

The Applicant MAY support issuing or linking multiple People to the same Attribute.


OFFICIAL

OFFICIAL

6 Identity Exchange Requirements

All Identity Exchange operations must be informed by the Applicant’s Fraud Control

Plan (FRAUD-02-02-01), Privacy Policy (PRIV-03-02-03) and System Security Plan

(PROT-04-01-12a). These requirements can be found in TDIF 04 Functional

Requirements.

6.1 Audit Logging Requirements

TDIF Req: IDX-06-01-01; Updated: Jun-21; Applicability: X

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:

• Timestamp

• Duration of Consent. (including any time limit on the consent)

• Relying Party. (i.e. The Relying Party that requested to receive the

Attributes)

• The Identifier that identifies the User at the Relying Party authorised to

receive the Attributes

• Identity Service Provider/Attribute Service Provider from which the Attributes

were sourced

• The link to the Identity at the source of the Attributes

• Name of any Attribute or Attribute set authorised

• Consent decision. This may be “grant”, “deny”, or “ongoing”


OFFICIAL

OFFICIAL

6.3 Single Sign On/Single Logout

Single Sign On is an optional feature that an Applicant may implement in their

system.


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.

TDIF Req: IDX-06-03-02a; Updated: Jun-21; Applicability: X

The Applicant MUST implement a single Logout 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.


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

A User Dashboard is a way for an Individual to view their Consumer History and

manage their Express Consent. A User Dashboard is an optional feature that an

Applicant may implement in their system.


If a User Dashboard is supported, then the Applicant MUST implement the following

requirements for the operation of a User Dashboard.


OFFICIAL

OFFICIAL


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 beyond the Individual’s

presence at the User Dashboard.

6.5 IdP Selection

The Applicant may provide a method for an Individual to select an Identity Service

Provider from a list of Identity Service Providers that are integrated with the Identity

Exchange when accessing a Relying Party. This is known as IdP Selection.


If IdP Selection is supported, then 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-03.

TDIF Req: IDX-06-05-03b; Updated: Jun-21; Applicability: X

The Individual MUST have the ability to opt out of using the mechanism described in

IDX-06-05-03.


OFFICIAL

OFFICIAL

: Evidence types and verification methods This Appendix sets out the EoI document types and the verification methods that an

Applicant may support to confirm a claimed Identity is legitimate (Legitimacy

Objective), confirm the operation of the Identity in the Australian community over

time (Operation Objective), and confirm the link between the Individual and the

Identity being claimed (Binding Objective).

Table 6 lists the EoI document types and the verification methods that an Applicant

may support. A description of the verification methods is available in TDIF 05A Role

Guidance. EoI document types and verification methods may need to change in the

future as Applicants update Identity Proofing processes, security practices and the

methods of provision.

Table 6: Evidence types and verification methods

Type of Evidence Notes Verification

method

Legitimacy Objective - confirm the claimed Identity is legitimate

Commencement of Identity documents

Australian birth

certificate

Issued by an Australian State or Territory

Government Register of Births, Deaths and

Marriages.

Source

Visual

Australian Passport20 Issued in the individual’s name or former

name, within 3 years of the expiry date.

Source

Technical

Visual

Australian citizenship

certificate

Issued in the individual’s name or former

name. If their name appears on their parents’

certificate, they can use that.

Source

Visual

Foreign Passport A current passport issued by another

country, with a valid entry stamp or visa.

Source

Technical

Visual

20

Although an Australia Passport in not evidence of Commencement of Identity in Australia, it can be used as proxy at IP 2, IP

2 Plus and IP 3, but not for IP 4. Use of the Australian Passport to provide evidence of Commencement of Identity should be

considered on a risk management basis. Australian Passports are generally valid for 10 years and so will not always reflect

changes of name. By contrast, many RBDMs are now updating birth records where a change of name has occurred and

issuing a new certificate. This would mean that old birth records in the previous name could not be electronically verified.


OFFICIAL

OFFICIAL


method

DFAT issued

Certificate of Identity


name by the Department of Foreign Affairs

and Trade.

Source

Visual

DFAT issued

Document of Identity



and Trade.

Source

Visual

Immicard A card issued in the individual’s name or

former name by the Department of Home

Affairs.

Source

Visual

Aboriginal and/or

Torres Strait Islander

descent records

This includes proof of Aboriginal and/or

Torres Strait Islander heritage

Visual

Linking documents

Australian marriage

certificate

Issued by an Australian State or Territory

Government

Source

Visual

Change of Name

Certificate

Legal change of name or deed poll

certificate.

Source

Visual

Australian divorce

papers

In your name or former name. For example,

a Decree Nisi or Decree Absolute.

Visual

Commonwealth

victims certificate

Issued by a magistrate in Issued by an

Australian State or Territory Government.

Visual

Australian birth

certificate

Issued by a State or Territory Government

Register of Births, Deaths and Marriages.

Source

Visual

Operation Objective – confirm the operation of the Identity in the Australian

community over time

Use in the Community documents

Concession and

Health Care Cards

Issued by Services Australia. Source

Visual

Medicare Card Issued by Services Australia. Source

Visual

Student ID card A current student ID card issued by an

Australian secondary school, TAFE,

university or Registered Training

Organisation which includes the Individual’s

name and may also include their photo.

Visual

Bank or financial

institution card,

passbook, statement

Issued by a bank, credit union or building

society. Card statements or passbooks must

cover at least 6 months of financial

transactions and be in the Individual’s name.

Source

Visual


OFFICIAL

OFFICIAL


method

The Individual’s signature must be on the

card and their current address on the

statement or passbook. Documents from

foreign banks or institutions are not

accepted.

Education certificate

or certified academic

transcript.

Issued by an Australian secondary school,

TAFE, university or Registered Training

Organisation which includes the Individual’s

name or former name.

Source

Visual

Mortgage papers For an Australian property in the name of the

Individual or their former name. These need

to be legally drawn.

Visual

Veterans Affairs card A current card issued in the Individual’s

name.

Visual

Tenancy agreement

or lease

A current formal agreement or lease in the

Individual’s name showing their address.

Visual

Motor vehicle

registration

Current registration papers with the

Individual’s name, address and proof of

payment.

Source

Visual

Rates notice A paid rates notice issued in the Individual’s

name with their address that is less than 12

months old.

Visual

Electoral enrolment Proof of electoral enrolment in the

Individual’s name and showing their current

address.

Source

Visual

Postal Records A history of at least 6 months of postal

deliveries.

Source

Visual

Telephone Records Records showing 6 months of phone usage. Source

Visual

Any document listed

in the Photo ID

category

If not used elsewhere. Source

Technical

Visual

Utility account Issued in the Individual’s name, with their

address, that is less than 6 months old.

Visual

Superannuation

statement

Issued in the Individual’s name, with their

address, that is less than 6 months old.

Visual

Seniors card Issued in the Individual’s name. Visual

Land titles office

records

Issued in the Individual’s name. Visual

Insurance renewal Current insurance renewal for house and

contents, vehicle, boat, or similar insurance

Source

Visual


OFFICIAL

OFFICIAL


method

in the Individual’s name held for over 12

months.

Binding Objective – confirm the link between the Identity and the Individual

claiming the Identity

Photo ID documents

Australian Passport Issued in the Individual’s name or former

name, within 3 years of the expiry date.

Source

Technical

Visual

Australian State or

Territory issued

Drivers licence

includes a digital

Drivers licence)

A licence issued by an Australian State or

Territory Government in the Individual’s

name with their photo. For digital Drivers

licence the security features must be tested

to ensure authenticity.

Source

Technical

Visual

Foreign passport A passport issued by another country, with a

valid entry stamp or visa.

Source

Technical

Visual

Foreign military ID

card

An identification card issued in the name of

an Individual’s by a foreign government

showing a picture of the Individual and

identifying the Individual as a current

member of the defence forces of that

government

Visual

Titre de Voyage/

DFAT issued UN

Travel documents

Issued in the Individual’s name or former


and Trade.

Source

Visual

Australian citizenship

certificate

Issued in the Individual’s name or former

name by the Department of Home Affairs.21

Source

Indigenous

Community Card22

EoI used to provide confirmation of identity

for Aboriginal or Torres Strait Islanders who

have not provided other Identity Documents.

Visual

Shooter or firearm

licence

A current card issued in the Individual’s

name and includes their photo.

Visual

Aviation Security

Identity Card



Visual

Maritime Security

Identity Card



Visual

21

NB. Citizenship certificate may not have an actual photo embedded, but an associated photo is stored in the source

environment.

22 The IDP must satisfy itself that the quality of the card and card issuance process is sufficient to support its use as a Photo ID

document.


OFFICIAL

OFFICIAL


method

Australian

Government issued

Photo ID card

(employee ID)

A Photo ID card issued by the

Commonwealth, or an Australian State or

Territory Government issued in the

Individual’s name and includes their photo.

The card may include a validity period.

Visual

Australian

Department of

Defence Highly

Trusted Token



Technical

Visual

Defence Force

identity card

Issued by the Australian Defence Force and

shows the Individual’s name and photo.

Visual

Police identity card A current card issued in the Individual’s


Visual

Australian State or

Territory issued trade

(work or business)

licence


name and includes their photo (e.g. trade

licences, real estate agents, security agents

etc.)

Visual

Tangentyere

Community ID card



Visual

Proof-of-Age card23 Issued by an Australian State or Territory

Government in the Individual’s name and

includes their photo.

Visual

Australia Post

Keypass



Source

Visual

Working with

children/Vulnerable

card



Source

Visual

23

NB. State names vary but they have the same fundamental intent e.g. NSW/WA Photo Card, ACT Proof of Identity, Qld Adult

Proof of Age, TAS Personal Information, NT Evidence of Age, VIC/SA Proof of Age.