1

Whole of Government (WofG)

Cloud Software

Authentication & Authorisation (CAA)

Software developer information kit

2

Version Revision date Author Distributed to Key changes

0.01 1 November 2015 Scott

Gruber

Internal ATO

stakeholders

and Education

and Industry

Initial draft version

0.02 3 March 2016 Scott

Gruber

Internal ATO

stakeholders

and Education

and Industry

Internal feedback

0.03 29 March 2016 CAA project

team

USI SWD For external distribution

0.04 27 April 2016 Shae

Graham

Converted to user friendly update format.

Updated Executive Summary

For internal Feedback and review.

0.05 2 May 2016 Scott

Gruber

Updates to exec summary and structure

0.06 3 May 2016 Ben Avery Internal review and feedback

1.0 20 June 2016 Shae

Graham

USI SWD Incorporated testing and SBR registration

process into info kit.

1.1 12 September

2016

Colin Welch USI SWD Internal feedback - removed ‘draft’

Version Control

3

Contents

1. Executive Summary ................................................................................................................................................... 4

2. Context ...................................................................................................................................................................... 5

3. Policy Advice .............................................................................................................................................................. 6

4. CAA high level solution .............................................................................................................................................. 8

5. Set up and notification process ............................................................................................................................... 10

Appendix A................................................................................................................................................................... 12

Appendix B ................................................................................................................................................................... 14

Appendix C ................................................................................................................................................................... 15

Appendix D .................................................................................................................................................................. 16

Appendix E ................................................................................................................................................................... 17

4

1. Executive Summary

There is an increased demand for the use of software in the cloud (online) as business adapt to the current digital

environment. To provide contemporary services for their clients, software providers had to develop their cloud

software in a way that required their clients to share their AUSkey (this is a breach of AUSkey terms and

conditions).

To resolve issues with the use of AUSkeys when interacting with Government through cloud enabled software, a

Cloud Software Authentication and Authorisation (CAA) solution was delivered. This solution allows a business

entity to notify Government of their software providers services, and the software provider’s dedicated device

AUSkey is able to then be used to secure transmissions.

The CAA solution currently supports ATO transmissions (via SBR). From 2016, a whole of government CAA solution,

integrated with the Department of Industry’s VANguard program, will be available. This will allow businesses

interacting with partner agencies (eg Department of Education and the Unique Student Identifier program) to

transition to the streamlined CAA solution.

This document aims to provide you with high level and detailed information about the CAA solution to assist with

your transition. If you would like to provide feedback or arrange a meeting to discuss your individual

circumstances/scenarios, please directly contact the agency you are transacting with.

Clients do not need to register for an AUSkey to transmit via online (cloud-based) software Clients have a better user experience with a simplified process to notify government of

software provider services to confidently and securely transact with Government

Software developers are able to provide (cloud-based) software solutions to clients for any device – e.g. smart phone or tablet

Software developers will no longer be required to store and maintain clients AUSkeys

The AUSkey compliance problem with 3rd

Party control of credentials is addressed Will leverage and support other WofG credential initiatives from DTO (myGov, ABR) for both

individuals and businesses.

5

2. Context

Registering for and maintaining credentials across government

As digital service offerings increase and businesses rely more on mobile technology, credentials used to access

government services also need to evolve to meet business needs. It is recognised that registering for and

maintaining credentials across government to interact digitally can be difficult for businesses. Recent consultation

activities with small business highlighted the frustration faced with applying for and using an AUSkey. This is

impacting the take-up rate of digital services offered by government.

With the increased demand for the use of software in the cloud (online) and as businesses update their processes

and technology to adapt to the evolving digital environment, there has been a need for business to adapt and

provide contemporary services for their clients.

Software providers had to develop their cloud software in a way that required their clients to share their AUSkey.

This has resulted in:

A poor and over complicated user experience for clients, when registering and maintaining

AUSkeys to transact with government

Administrative burden in the storage and maintenance of client AUSkeys by software

developers

3rd

Party (software developers) control of AUSkey credentials, a breach of AUSkey terms and

conditions

The future of digital identity across Government

With the establishment of the Digital Transformation Office (DTO), government is committed to streamlining

access to government services, making it simpler, clearer and faster for individuals and businesses. The DTO will be

responsible for improving digital identity across government, leveraging myGov and the Australian Business

Register to transform the way services are delivered to both individuals and businesses. This will mean myGov and

the use of other credentials (eg voice biometrics) will become the future of credentials for individuals and

businesses, with reliance on cloud based solutions to enable digital interaction.

6

3. Policy Advice

The current AUSkey https://abr.gov.au/AUSkey/Help-and-support/AUSkey-Terms-and-Conditions/Conditions-of-use---

AUSkey/ outline the responsibilities placed upon AUSkey holders. Failure to uphold these responsibilities will result in the

cancellation of the AUSkey.

Policy advice received from the Department of Finance on the use of AUSkeys in the cloud indicates that software

developers remotely storing their client’s AUSKeys and in some instances their associated passwords, in cloud based

solutions are in breach of the AUSKey terms and conditions of use.

The Department of Finance (as the Gatekeeper Competent Authority) have assessed the proposed CAA solution and

determined it to be compliant with terms and conditions stated in the AUSkey Certification Practices Statement (CPS) and

Certificate Policies (CP).

To support the use of cloud solutions the Department of Finance have released the Australian Government Cloud

Computing Policy. The policy demonstrates the commitment by government to develop cloud based services.

Responsibilities in relation to the AUSkey Standard Certificate

4.1 The Certificate Holder and the Business must not:

disclose the password for the AUSkey Standard Certificate to

any other person

store the AUSkey Standard Certificate in a keystore to which

any other person has access

otherwise allow, grant, permit or enable any person other than

the Certificate Holder to use the AUSkey Standard Certificate.

There is no definition of ‘person’ in the

policy.

We have received legal advice stating

that ‘person’ extends to and includes

computers, systems and software.

4.2

The Certificate Holder and the Business must promptly advise

the ABR CA if:

the Certificate Holder is no longer authorised to use the

AUSkey Standard Certificate on the Business' behalf

it becomes aware of any unauthorised use of the AUSkey

Standard Certificate

the security of the AUSkey Standard Certificate or its password

has been compromised.

There is no definition of ‘compromised’ in the policy.

We have received policy advice from

AGIMO (who accredit the AUSkey

system) that any transfer of an AUSkey

off the computer that it was generated

on, onto another computer via the

internet (ie uploading to any form of

cloud storage), constitutes a breach of

the terms and conditions.

7

Responsibilities in relation to the AUSkey Device Certificate

4.1.1 Who can submit an application for a Device Certificate?

An application for an AUSkey Device Certificate (to be held for a

Business Entity):

can only be made by an Administrator for that same Business

Entity, and

can only be made online through the AUSkey Manager, and

must nominate an individual who holds a valid AUSkey Standard

Certificate (for that same Business Entity) as the Device

Custodian to be associated with that Device Certificate.

4.4.1 Device Custodian responsibilities

The Device Custodian for an AUSkey Device Certificate is responsible

for:

downloading the Device Certificate when it is issued, following

registration

creating the password that protects the Device Certificate and its

associated Keys, and changing that password at recommended

intervals

ensuring the Device Certificate is attached to the correct Device,

for example by ensuring a match between the IP address of the

Device and the subject of the Certificate

safely transferring the Device Certificate from the download

location to the server location, if required for example because:

email access is not available on that server, so that the

download link that is used to install the Device Certificate

cannot be accessed from that location, or

the Business Entity has an IT Outsourcing, SaaS or similar

arrangement with another entity, and needs to transfer its

Device Certificate to that other entity’s hosting location.

Device custodians must hold

pre-existing Standard AUSkeys for the

business, thus typically aren’t the Cloud

provider.

The Device Custodian creates the

password, which cannot be disclosed to

any other ‘person’ (as per previous

slide), and ensures the Device AUSkey is

only used on the intended device,

presumably requiring physical access to

installed sites, or some other form of

assurance.

The Device AUSkey conditions-of-use do

not expressly forbid Cloud use, however

given the definition of ‘compromised’

(as per previous slide) Device Custodians

cannot send the Device AUSkey across

the internet, or by any other

comprisable means. Cloud providers

aren’t allowed to have the password

‘disclosed’ to them, their systems or

software.

8

4. CAA high level solution

The CAA solution allows a business entity to notify Government of their software providers services, and the

software provider’s dedicated device AUSkey is able to then be used to secure transmissions.

Benefits

The business subscribes to an online (cloud-based)

software product that has on boarded the CAA solution.

Business is prompted to notify a government agency of their software provider services.

Once the business initiates a transmission (eg lodges), the data

(including the Software ID) is sent to the agency and secured using the SWD’s dedicated Device AUSkey.

Clients do not need to register for an AUSkey to transmit via online (cloud-based) software Clients have a better user experience with a simplified process to notify government of

software provider services to confidently and securely transact with Government

Software developers are able to provide (cloud-based) software solutions to clients for any device – e.g. smart phone or tablet

Software developers will no longer be required to store and maintain clients AUSkeys

The AUSkey compliance problem with 3rd

Party control of credentials is addressed Will leverage and support other WofG credential initiatives from DTO (myGov, ABR) for both

individuals and businesses.

9

Integration with VANGuard

The CAA solution integrates with the Department of Industry’s VANguard program. VANguard will broker the

notification check, as well as the current AUSkey authentication check, on behalf of the partner agency.

VANguard will use the information supplied by the software provider to verify the cloud notification and

‘Software ID’ recorded in Relationship Authorisation Manager for each transmission. The high level process is

described below.

1. Business uses software and is prompted to notify their agency of their Software provider and provide the

‘Software ID’. Either via Relationship Authorisation Manager (using current Admin AUSkey) or over the

phone (verified as a business associate to use the phone channel)

2. Software provider uses their Device AUSKey to secure the transmission, the ‘Software ID’ is also provided

3. VANguard calls the CAA web service and verifies the cloud notification and the ‘Software ID’ included in the

transmission

4. CAA web service provides verification result which is returned to VANguard. The service verifies that a link

between the SWD and the business exists and the ‘Software ID’ matches the one provided.

5. VANguard provides a request for security token response to the Software provider

6. The Software provider sends the transmission to the agency

‘Software ID’ is a unique ID that is used to identify each unique subscription or instance of software and is

automatically generated by the software. See Appendix A. CAA - Detailed Design

10

Lodgement by “business” using cloud software

The end to end process from setting up the initial notification to lodging using the CAA solution via VANguard is

provided below.

11

5. Set up and notification process

To transition to the CAA solution, software developers will be required to follow the processes outlined below. If

you would like to on-board the WofG CAA solution please directly contact the AUSkey participating agency in

which your software will transact with.

Software Developer on-boarding process

Client on-boarding process

Business prompted to notify the

agency of the software

provider’s services and provide

a Software ID

Business notifies the agency of

the software providers services

and provides a Software ID via

Phone

Online (Relationship

Authorisation Manager)

Online software product is

purchased / subscribed.

Design, build and test your

system and messages to

incorporate additional CAA

requirements

Step 1

Register to become a SBR

licenced Software developer

For information select the link

below.

http://www.sbr.gov.au/softwar

e-developers/what-can-i-

expect#register-intent-license

Step 1

Register to become a SBR

licenced Software developer

For information select the link

below.

http://www.sbr.gov.au/softwa

re-developers/what-can-i-

expect#register-intent-license

Step 2

Register to become a SBR

licenced Software developer

For information select the link

below.

http://www.sbr.gov.au/softwa

re-developers/what-can-i-

expect#register-intent-license

Step 3

Refer to this document for:

Generation of the software ID

How to implement and test with the new AUSKey Developer KitK

Contact your external government

agency to receive information about

their specific requirements and testing

guidance

To gain access as an online

software provider in

Relationship Authorisation

Manager, declare that your

software meets agency CAA

requirements

Step 2

Register to become a SBR

licenced Software developer

For information select the link

below.

http://www.sbr.gov.au/softwar

e-developers/what-can-i-

expect#register-intent-license

Once your access has been

granted, set up your Device

AUSkey

Step 3

Register to become a SBR

licenced Software developer

For information select the link

below.

http://www.sbr.gov.au/softwar

e-developers/what-can-i-

expect#register-intent-license

Contact your external government

agency to receive information about

their specific declaration process

This process step may not be required. If

required, it will be enabled from within

the appropriate RAM UI’s.

12

Appendix A

CAA - Detailed design

Software ID requirements

The following outlines the requirements around the automatic generation of a Software ID for cloud software

products transacting with Government Agencies.

The Software ID must:

be generated using the algorithm provided below and contain 10 digits (leading zeroes are required)

be unique for each subscription or instance of software

be passed to the user via a secured electronic communication or over the phone

be given to the user for the purposes of notifying a government agency of a software providers services in Relationship Authorisation Manager

The Software ID must not:

be keyed in by the user for each transmission

be used as a credential to authenticate the client within online software for lodgement

Software ID generation algorithm

1. Generate the first 9 digits of the Software ID (can be a randomly generated string) 2. Pad the generated number with leading zeroes on the left to make a 9 digit string 3. Calculate the sum of all digits in the string and apply the Modulo 10 division to calculate the remainder 4. Use the remainder as the 10th control digit 5. Concatenate the generated 9 digits (from step 2) with the control digit (from step 4) to form the 10

digit Software ID

The below table provides some examples of Software ID generation.

Generated

number

Zero padded

string

(9 characters)

Sum of all digits

Remainder from

division by 10

(control digit)

Software ID

1 000000001 0+0+0+0+0+0+0+0+1 = 1 1 0000000011

2 000000002 0+0+0+0+0+0+0+0+2 = 2 2 0000000022

… … … … …

478593 000478593 0+0+0+4+7+8+5+9+3=36 6 0004785936

13

How to implement and test with the new AUSkey Developer Kit and transmit using CAA

The existing AUSkey Developer Kit (ADK) and guidance will be updated to include:

new endpoints to connect to VANguard services in 3rd party test environments as well as production,

how to submit the Software ID and ABN attributes to VANguard and,

how to receive and use the CAA SAML to transmit to participating CAA agencies.

For further information about how to receive the ADK, register as a SWD through the SBR Service Desk or contact

the external government agency with which you will be transacting.

Once successfully registered to receive the latest ADK updates, through the SBR Sharefile website for which you

will be granted access and provided relevant instructions to install.

For technical queries and support associated with implementing the latest ADK version, please contact

government agency you are developing for to assist with determining the appropriate support area.

14

Appendix B

Software provider user interface screens

This section will be finalised when the user interface detailed design is complete.

15

Appendix C

How your client will notify a government agency of your software provider services

New and existing subscribers to online software products will be required to notify a government agency of the software provider’s services to be able to transact automatically with them.

To successfully undertake their software nomination, a customer will need to have the following information ready:

Their ABN

The ABN or name of the Software provider (supplied by the software provider)

Unique software ID (supplied by the software provider)

Clients are able to notify a government agency of their chosen software provider by either one of the following 2 methods:

Over the phone (1300 85 22 32): AUSkey not required. Normal proof of record ownership (PORO) will apply to the caller.

Online via Relationship Authorisation Manager (RAM): an existing administrator AUSkey or myGov login is required

More detailed Instructions on how to notify will be made available online.

To further assist software providers in supporting their clients through this process, screenshots of the

Relationship Authorisation Manager User Interface will be provided once finalised.

16

Appendix D

How cloud transmissions are verified

For a cloud transmission to pass verification through CAA, the following steps are performed:

Agency specific

authorisation checks

Any additional agency specific authorisation checks

Passes additional checks Step 6

Determine if client

making transmission

has correctly notified

the agency of the

software provider’s

services

Does the SWD have online software provider access in Relationship

Authorisation Manager?

SWD has been granted online software provider access in Relationship

Authorisation Manager.

Step 1

Is the Device AUSkey set up?

The SWD Device AUSkey has been enabled to secure online (cloud)

transmissions in Relationship Authorisation Manager.

Step 2

Does the notification exist?

The software client has notified the agency of the online software

providers services in Relationship Authorisation Manager

The client’s ABN sent in the transmission and SWD ABN (AUSkey) must

relate to the notification.

Step 3

Step 4 Does the Software ID match the notification?

The client has entered a valid software ID against their chosen software

provider notification in Relationship Authorisation Manager.

The Software ID sent in the transmission matches against the notification

in Relationship Authorisation Manager.

Step 5

Determine if the SWD

is setup to secure

transmissions with

cloud

Step 7 - Lodgement Accepted

Has the notification been disabled?

The notification has not been disabled by the SWD in Relationship

Authorisation Manager.

17

Appendix E

Online Software Provider Appointment Web Service

. This service can be used to verify if a software developer’s client has notified the agency of their services and has

correctly registered their Software ID. It will be made available for SWD with online software provider access in

Relationship Authorisation Manager

To call this service the software provider must authenticate using their AUSkey credential and provide their ABN,

client’s ABN and the Software ID.

Detailed instructions to call this service have been made available.

Required attributes

SWD ABN

Clients ABN

Software ID

Calls ‘Online Software Provider

Appointment Web Service’

Online Software Provider

Appointment Web Service

Web service checks

the AUSkey being used is a device

AUSkey

the SWD has online software provider

access in Relationship Authorisation

Manager

The AUSkey is enabled to secure online

transmissions in Relationship

Authorisation Manager

a notification exists

the notification is enabled (notifications

can be disabled by the SWD)

the Software ID matches the notification

IsValid = True IsValid = False

Authenticates using

SWD Device AUSkey

IsValid = True

IsValid = False

with reason code