software developers homepage | - background · web viewthe work conducted by the digital...

DIGITAL IDENTITY PROGRAMDSP ENGAGEMENTS

Prepared by the DCIS team

FOR OFFICIAL USE ONLYEXTERNAL

Version

Version Date Distributed to

v0.1

v0.2

v1.0

07-08-17

12-03-18

14-03-18

DCIS project team (Ben Foster), SIPO, RAM

DCIS project team review and update for release

Document finalised

Authors

Name Position Phone:

Esteban Martinez Designer, Digital Identity Services, EST

(02)

9685-8819

Approval

Ben Foster Digital Business Lead, Digital Identity Services, EST

(03)8632-4406

FOR OFFICIAL USE ONLY EXTERNAL 2

Contents

Background 4Intent 5

Scope 5

Business goals 5

Methodology 6Approach 6

Deliverables 6

Stakeholders 6Project team 6

Digital Service Providers (DSP) 7

Summary findings 8

Detailed findings 121 Business Software Purchase 12

2 New Employees 14

3 Employee Accessing Software 16

4 Machine 2 Machine 18

5 Technical Implementation Considerations 21

Appendix 24


This report outlines feedback collected from developers, over the proposal to realise the integration of a Whole of Government (WofG) identity solution, into their products.

Currently the developer community relies on product controls in their software, which establishes client identities and creates client accounts based upon their own independent security designs. Between software products, the differences that then exist in how these identities and related accounts are managed can vary greatly. The quality and depth of detail within collected identity attributes for software clients, also varies between products.

Without a single source of identity truth or authority point to depend on, software products have maintained functional silos in the area of user identity.

As principle consumers of government services, the irritants and inconsistencies of identity in developer products ultimately find their way into the agency environment. Also in some scenarios the current AUSkey solution doesn’t meet the expectations of end users, which also contributes to the irritants in this environment.

The work conducted by the Digital Communication & Identity Services (DCIS) team, is intent on correcting these shortcomings by developing a WofG identity solution, which can correct the current state and support developer solutions with enhanced identity capabilities.

This first step has involved direct engagement with the developer community, to explore a range of potential scenarios with a closed group.


Background

Intent The intent of this initial developer engagement is to understand:

developer attitudes towards the delivery of a WofG Identity and authentication solution

developer attitudes towards the delivery of a WofG authorisation solution and;

the likelihood of whether developers would be willing to leverage these solutions through the validation of 4 potential scenarios

ScopeThe scope of this activity will be limited to participant’s views about:

the merits or benefits of leveraging from a government identity and authentication solution for developer/vendor product sale processes with their own clients (Scenario 1)

the merits or benefits of leveraging from a government identity and authentication solution for employee record creation in software, for developer clients (Scenario 2)

the merits or benefits of leveraging from a government identity and authentication solution for continued access to software by known users (Scenario 3)

the merits or benefits of leveraging from a government identity and authentication solution for machine to machine B2B and B2G bulk transactions, as an alternative to AUSkey (Scenario 4)

Developer preferences across a range of service build considerations

Business goals The business goals are as follows:

To determine the viability of whether to include or exclude wholesale service designs for developers into the project work for DCIS, by recognising their platforms as participating services.

To extract intelligence from the initial developer engagements that supports a best practice approach to DCIS technical designs.

To establish a foundation that will act as a design principle which will inform future build and delivery work should the findings be considered viable.


ApproachThe DCIS design team took advantage to announce the intent to engage with Digital Service Providers (DSP) at the AUSkey Special Interest Group (SIG) meeting held in May 2017. This meeting focused upon the irritants of AUSkey in industry, which provided a perfect segue way into further discussions surrounding the future of identity, authentication and authorisation. The group showed a keen interest to be engaged which led to the commencement of this approach.

Prior to any form of engagement the DCIS design team considered the future identity environment, and commenced the development of high level Digital Service Provider (DSP) scenarios. These would be coupled together with examples of ATO retail high level scenarios, in a presentation pack that could be consumed by developers, giving them a picture of what the future of identity could mean for their services. The approach would involve direct one on one engagement with developers, which were willing to participate in discussions whilst being walked through the aforementioned pack.

A trial run of the contents of the pack would be tested with ABSIA, prior to official engagement with their community. This was completed with ABSIA on 25th May 2017. The success of the trial would give the DCIS project team the green light to commence the DSP engagements. ABSIA would canvass the community of developers and put forward nominations of those willing to partake in discussions.

DeliverablesThe DCIS design team will provide the final report detailing all of the findings including any recommendations based on the insights gained from these engagements back to the developer community.

Project teamProduct Manager: Ben Foster, Digital Business Lead, Digital Identity Services, EST

Product Manager: Claire Miller, Digital Business Lead, Digital Identity Services, EST

Enterprise Architect: Peter Karouzos, Enterprise Architecture, Digital Delivery, EST

Technical Solution Manager: Hoshedar Elavia, Digital Identity Services, EST

Assistant Director: George Afarian, Digital Identity Services, EST


Methodology

Stakeholders

Assistant Director: Nicole Shepperd, Digital Identity Services, EST

Designer: Esteban Martinez, Digital Identity Services, EST

DCM: Terry Seiver, Software Experience, DPO

Digital Service Providers (DSP)ABSIA: engaged 25th May 2017

Oban Solutions: engaged 16th Jun 2017

MYOB: engaged 20th Jun 2017

XERO: engaged 20th Jun 2017

Layer Security: engaged 21st Jun 2017

Pronto: engaged 23rd Jun 2017

Software Objectives: engaged 26th Jun 2017

ADP: engaged 4th Jul 2017


Overall reaction

If we take the position to consider the DSP response from a statistical point of view, for everything between scenario validation and their respective component questions – we find that the solutions received:

a 63% positive response to all facets of the proposed scenarios an 8% negative response and; a remaining 29% that could not be qualified either through the fact that it did not apply

to the developers product(s) or a response was simply not captured

If we factor out that final grey area, the true meaningful result that we are left with is an 88% positive response to these high level designs. If on the other hand we take a face value approach to what we heard, the following statements provide an indication of just how necessary the solutions are for developers:


"The WofG thing is pretty important" - "I don't think you'll find too many software providers that didn't want to do this" -

"You can't not provide this service"

"Get on with it"

"Consider me bought into all 4 scenarios … love it" "Seriously guys we could easily adapt what we've got to

make use of the capability that your describing" - "We would jump at the opportunity to integrate any of these services

and if we didn’t I would find another employer"

"I want it yesterday"

Summary findings

From this initial experience with the 8 developers, it would be an understatement to simply imply that we are on the “right track” in terms of understanding the industry need for an identity solution. All four scenarios presented hit the mark with the DSPs, where it appropriately applied to the developer’s product environment.

Even whilst under the high level format in which the scenarios are placed, it was more than enough to appease a range of concerns that each developer had surrounding the pitfalls of identity, authentication and authorisation. It prompted a degree of industry recommendation for development, which we can benefit from come detail design.

Next Steps

This was a great first start during the discovery period, which should prompt the project to harness the next phase of design in order to secure a non-government service participant into the identity network. This will include continued engagement with the DSP’s as we roll out detailed level designs and flows aimed at expanding what they have now validated. The team will facilitate further discussions to work through the next level of detail of how identity, authentication and authorisation should work when accessing services through Digital Service Providers.

Recommendations

During discussions, DSP’s had the opportunity to go beyond the high level concept and really get into the technical content that would potentially make these solutions stand up. With the support of project solution architects, we were able to dig deeper into how the services could be delivered, secured and consumed by industry. The following feedback points are standout statements that were raised for the record:

A WofG identity solution First and foremost, the mere mention of rolling out a government controlled identity platform for industry services to consume is not a concept that inherits great opposition. On the contrary, most DSP’s demand certainty and security around the subject of identity in order to rid the burdens of risk from their own environments. However, the network will need to be flexible enough to support all individual user circumstances.


ConnectivityIn terms of what would be expected by DSP’s when looking to connect their products to an identity, authentication and authorisation exchange, concerns around complexity, branding and connection methods were a focus. As there is no mandate driving adoption, access to the identity exchange will need to remain keenly flexible and provide agnostic options to sustain a mixed government with industry network.

B2B and B2G This area of discussion proved highly critical and it is clear to see why. In the space of current day AUSkey, 7 out of 8 developers had serious investments into this space and


"The ABN is issued by the government and the electronic form of identity should also be handled and managed by the

government so that we can all trust it"

"There are too many independent solutions right now which is what is causing the big fight in the Super industry"

"We still have to support people using our software without a government identity"

"I would prefer to be able to make a call to a web service using stock standard (JAVA or .NET) class libraries rather than take a piece of software written by you guys to plug

into my software"

"We would like to end up with a token we can trust and an identity we can trust, you'll be publishing keys so we can

verify those tokens"

"If someone says here is an authentication provider here is an encryption provider and here's the protocol like ebMS, I

really think they're nuts if they want to build their own"

concern for what may

come next. From the key points recorded, it is imperative that if the design is to consider an AUSkey alternative we should be placing value in:

o Adopting the SBR2 channel and AS4 framework to support both B2B and B2Go End to end encryption and encapsulationo The establishment of a government controlled PK registero No SAML tokenso The development of one PKI solution for both B2B and B2Go Associating a business identity whilst still being able to trace the human element

Authorisation


"Reticent to send customers away from my site there's branding issues and API options - I can make an API call to

the exchange to validate and get a token back"

"A public register (for public certificates) would be great" - "We'll be all over this like a bad rash in fact we would be

fighting each other to be first"

"The whole of the digital economy is going to require a trusted source of authentication for B2B and for B2G" -

"SSL Transport security doesn’t cut it. What we need here is message layer security end to end and the best way to do this is using AS4 (SBR2)" - "A token service is not required if you have this AS4 asynchronous message standard as

mentioned"

The area of how RAM might play a role in this connected environment will need a thorough review especially in the space of determining relationship types as they relate to a wholesale product. What was important for clarity sake in these discussions, was calling out the foundation of what a WofG recognised relationship is and is not. (i.e. internal client environment permissions vs client to government permissions). Whilst these could not be defined in this instance, there is genuine interest in the industry to consume a service like this:

Delivery

The final emphasis made is upon how we go about releasing the network services and how easy or hard we make it to consume them. Of key note is the consideration of providing government developed API’s. Whilst not favoured amongst the group for taking away market opportunities to build and sell their own API’s, the ATO should still promote baseline services that can be easily consumed by all DSP’s. A call is made to not over complicate the design and to very carefully consider what we package up in a release and how we time those releases. If we can get a preferred balance, there is a potential to realise greater adoption.


"I see value in both sides of the fence for both general employees and agents with specific permission

requirements" - "My attitude is if the government provides a relationship service I should use it - I can blame the

government if it's wrong"

"Yes take my money"

"It's interesting we should explore that"

"Consider putting in a lot of effort into packaging it up so that its services that we could consume really easily and then we

would be more likely to move to integrate" - "You’re final properly validated scope and the date of implementation,

there needs to be enough breathing room there"

"I shouldn't have to rely on plugins (API) to get going it slows down uptake and our ability to upgrade other parts of our

software"

"To be able to see that this employee in myGov has been set up with the business with these functions then we would play those functions into the software to recognise the same

permissions"

1 Business Software PurchaseThe concept behind the business software purchase scenario (as presented to the group) is one where wholesale products might consider integrating into a WofG identity exchange, for the purpose of completing the commercial sale of vendor licensing or standalone products with their clients. The benefit proposed in this instance, is where the leveraged identity of clientele could facilitate automated accurate client account creation and preliminary software set-up.

All 8 DSP were canvassed to consider this scenario to determine whether the proposed solution is one that would be deemed viable to enhance their product(s). (See figure 1.1)

Figure 1.1 Scenario 1 Validation Result

VALID = 5

*Doesn’t apply to DSP product(s)

The process of reaching an overall validation point with this scenario included highlighting certain components in the solution during discussion. The following aspects of the solution were questioned:

1. Does the industry see value in integrating an identity exchange solution into their product license sales processes?

2. Would vendor solutions find value in the provision of verified, pre-filled identity attributes for the creation of client sales accounts?

3. Would white listed CAA products find value in automating client to vendor relationships for service authorisations?


Detailed findings

Collective responses to each question were tabled from an audio extract, where a response was in fact captured. N/A signifies the solution does not apply to the DSP. (See figure 1.2)

Figure 1.2 Scenario 1 Component Questions

Question 1 Question 2 Question 3

5 5

4

1 1 1

2 2 2

1

YES NO N/A Not Captured

Indicative of these results the following DSP statements provide some context towards their thinking on the various questions presented:

Q1 - "If this process is bundled into the software purchased it makes a better user experience for everybody"

"I do see good rationale to use that process where an agent is coming to set up a business for a client”

Q2 - "Huge value - we can get their business details ideally including industry, whether they employ people, GST and PAYGW registrations"

Q3 - "If we can find a way to make the (CAA) process seamless and smooth everybody including users and the ATO will benefit”

"That makes sense to me and all my users would love to throw away their AUSkeys”


2 New EmployeesThe common denominator between each scenario presented, is the integration point of the WofG identity exchange. In this scenario we demonstrated to DSP’s how the same integration of the exchange could now enhance the user experience for their clients, when they themselves are recruiting new staff. The design principle here, is that DSP wholesale products that do connect to the exchange, open up the possibility to enhance the way that their client’s software identifies new staff, creates new employee records and establishes B2I relationships. Note: This solution is decoupled from the STP Wholesale on-boarding service.



VALID = 5



1. Does the industry see value in integrating an identity exchange solution into their product to enhance client employee on-boarding processes (wholesale)?

2. Would vendor solutions find value in the provision of verified, pre-filled identity attributes for the creation of new client employee records – and if so what are the minimum attribute sets?

3. Is there a benefit in establishing software features that enable either automated or manual B2I relationship authorisations?




Question 1 Question 2 Question 3

5

4

3

2 2 2

1

2 2

1



Q1 - "So long as your network allows me to pass you some custom data when I direct the employee to your exchange, and you then pass that back when

redirecting the employee - I'm fine, I can read that custom data and it's relevant to me"

Q2 - "Name DOB and email address are the bare minimum we need but the answer is we will take as much as we can get”

Q3 - "I see value in both sides of the fence for both general employees and agents with specific permission requirements"

"No I think the process will still require manual approval at some point for the relationship to be created"

3 Employee Accessing Software Of the four scenarios this one is generally considered the “day to day” solution, when looking at the software environment of a client that employs staff. Whilst in scenario 2 we considered the induction of a new employee and their associated WofG identity, here we expect to see


continual access and use of the same software by existing employees. Largely the consideration needed by DSP’s here, is whether or not they would be willing to swap out their own access security features (e.g. FAS), for the integration of authenticating via the WofG identity exchange. The design principle is for the authentication to be used continuously via the identity exchange, at each access attempt.


Figure 3.1 Scenario 3 Validation Results

VALID = 5



1. Does the industry see value in leveraging a government identity exchange solution into their product, where client access, authentication and authorisation are concerned?

2. Would vendor solutions be able to implement greater access controls surrounding the use of their software (logging) if access sessions are tied to verified identities?




Question 1 Question 2

5

2

1 1

2 2

3



Q1 - "The more that we can interact with anything that the government has on file; that gives us certainty around making sure the data is up to date and matched with

what we have on file"

"I think it should be done every time - if we are going to go this far with authentication and don't do it each time - my preference would be to keep it

consistent - yes"

"Conceptually the right thing to do although from a SWD perspective we are reticent to send customers away from my site for branding reasons"

Q2 - "This feels less useful"

"Yes particularly because software allows such important things such as lodging BAS's and tax returns"


4 Machine 2 MachineThe final DSP scenario in the pack is an attempt to realise an alternative solution to the current state use of AUSkey, in the machine to machine (M2M) world. Noting that AUSkey today does not facilitate M2M transactions on the business to business (B2B) channel, the supply of a government controlled installable PKI that can is the design principle. The concept proposes the benefit of having one solution, to carry out both B2B and B2G transactions, whether they are pull or push actions. This flexibility in design will not only continue to support the B2G environment in which AUSkey operates, but also look to support the e-Invoicing initiative.



VALID = 7



1. Will an exportable PKI tied to a government identity exchange, benefit M2M B2G/B2B transactions?

2. What type of identity is expected to support automated M2M transactions – Human (TFN) or Business (ABN) type identities?

3. Would a Token service be considered best practice for the verification of transmitted credential authentications?

4. Will transactions need crypto encryption/decryption between machines?




Question 1 Question 2 Question 3 Question 4

7 7

1 1 1 1

5

2

5

2

YES NO N/A Not CapturedBusiness Individual Both


Q1 - "Ultimately what we have to do here is mutual certificate pinging, it doesn't necessarily matter who produces that credential so long as the credential is

registered so government doesn't necessarily need to provide a PKI it could be a third party – a trusted root CA or a CA that the ATO trusts"

"Yes provided you do your PKI properly, you'll need a certification authority that can support a proper root certificate and not a fly by nighter. The CA has really got to protect their root private keys and issue intermediate certificates and end entity certificates. Then on top of that you need revocation to supply an OCSP service ...

really important ok!"

"I've been a long advocate of this, I wanted one process one system and I wanted to use the government's one. It makes sense to me, why have a second layer

(approach) for B2B traffic"

Q2 - "It’s got to be the ABN; the business has the responsibility for the lodgement not the individual. I don't think any of our clients would want a human TFN being

associated to a M2M transaction"


"It's the ABN and you have to represent legally that the organisation is the owner of the ABN and the certificate is then bound to the ABN"

Q3 - "If you have got the payload encrypted and effectively tamper proof, to be only decrypted at the end point, a lot of what happens along the way becomes irrelevant

and AS4 already supports this"

"You don't need a SAML token and PKI it's ludicrous. In a M2M world to have any token exposed to the end user is totally unjustifiable"

"SSL Transport security doesn’t cut it. What we need here is message layer security end to end and the best way to do this is using AS4 (SBR2)"

Q4 - "Digital signing is the key to it. If the message is encrypted by our client and handed over to us, then we're just the messenger like AusPost is"

"Only the person that has got the two matching keys (Public Private) can decrypt the message that I send and sign anything that they receive. Also if the government are the controlling body that issues the keys, should they need to check the contents of a business transaction, it should be said that it must happen number 1 and 2 that

the government has the tools to do it"

"You need the communication level encrypted but the payload needs to be encrypted as it is vital”

"They should be - it should be E2E encryption and the tools used to manage encryption should be universal”


5 Technical Implementation ConsiderationsWith a broader focus past the initial DSP scenarios, a subsequent set of standalone questions were worked through with developers to better understand their product environment and build preferences. Should the ATO consider moving forward on supporting wholesale in the identity world, the responses collected here have potential to inform a delivery approach for build solutions.

Whilst not all 8 developers were canvassed across this set of questioning, the recorded feedback here will prove valuable. The following implementation considerations were questioned:

1. Would DSPs expect to leverage and integrate identity, authentication and authorisation solutions offered by government into their software?

"We would leverage that by having in our code the ability to lookup the relevant public key of any business that is maintained as current by government, instead of us needing to maintain a PK library. We would also trust the provision of that PK

knowing the only parties that can access the payloads are the holders of the private keys or government"

”We probably wouldn't see our software authenticating through myGov but certainly at the time of submitting financials we would make authentication happen

at that point"

"So long as your network allows me to pass you some custom data when I direct the employee to your exchange, and you then pass that back when redirecting the

employee - I'm fine, I can read that custom data and it's relevant to me”

"Yep quite possibly - it stretches across portfolios too, business, practice tools and payroll"


1a. Do DSPs see value in leveraging solutions offered by government or is there a preference for these to be developed and managed separately by DSPs?

GOVT = 3

DSP = 1

Not Captured = 4

1b. Would developers expect to receive accreditation; where software meets build standards?

YES = 4NO = 1

Not Captured = 3

1c. Would developers prefer to leverage a business client’s government identity and authentication or launch their own native security credentials into the network (e.g. Federated Authentication Service) for use within an identity exchange environment?

GOVT = 2

OWN = 3

Not Captured = 3


2. Would developers find value in the management of identity authorisations – being established within their natural systems?

YES = 3

NO = 0

Not Captured = 5

3. What protocols are preferred by developers (OAUTH / WS-Trust)?

OAUTH = 4

OIDC = 2

WS TRUST = 1

4. What implementation lead times could be expected in the industry?

6 MONTHS = 24-6 WEEKS = 1UNSURE = 1Not Captured = 4

5. What developer tools (SDK / MIG / BIG) would be required/preferred, to make build work viable towards these scenarios?

MIG = 3BIG = 2SDK (Commercial) = 2TEST ENV = 2SAMPLE CODE = 2


Presentation pack for DSP’s including scenario experience flows:


Appendix

software developers homepage | - background · web viewthe work conducted by the digital...

Documents