Government Gateway: Secure Transactions & Single Identity Access

1. Government Gateway Overview E-Government

2. What is the Gateway? • A conduit for secure transactions between customers and government, covering Inputs, Outputs and Payments to Government; • Gateway does not host e-forms or applications that generate or consume transactions; • Gateway must communicate with front office and back office components to deliver an e-service.

3. What does the Gateway do? • Single route into any government system; • Processes and routes XML “e-forms”; • Provides “single identity” access for users; • Highly secure, resilient “always on” environment; • Delivers outbound messages securely; • Capacity to handle high volumes; • Provides payment facilities.

4. Who can use the Gateway? • Customers: • Citizens, businesses, intermediaries • Using ANY application, ANY device, ANY digital ID service that is t-Scheme approved • Government: • Departments • Local Authorities • Agencies • Devolved Administrations • Digital ID services. t-Scheme approved providers, currently are: • British Chambers of Commerce (using Royal Mail’s ViaCode) • Equifax • Software developers: • Software Vendors • Departments

5. Gateway Overview Front Office Applications Government Portals Commercial Portals For Example For Example Accounting packages HMCE For Example Yahoo Home finance packages Inland Revenue MSN ukonline.gov.uk Bank sites Insurance sites Internet Middle Office Gateway Registration Transaction Payments Secure Mail and Enrolment Engine Credit Card Debit Card Direct Debit Data Internet (Via VPN) or GSI Back Office DIS DIS DIS DIS Inland LA HMCE DEFRA Revenue

6. Front Office • Encourage multiple channels for any transaction; • Open standards allow easy integration with applications using UkGovTalk compliant XML; • Support for Government portals with external authentication capability.

7. Middle Office • Gateway provides generic building blocks for creation of end-to-end services: • Registration and Enrolment engine for authentication • Transaction engine for routing • Payment Engine for payment of government related bills by credit, debit card or for setting up direct debits • Secure Mail system for secure communications between user and Government

8. Back Office • Department Interface Service (DIS) boxes provide off the shelf connectivity to Gateway; • DIS box can be used to transform XML messages into other formats when they reach departments.

9. Registration & Enrolment • The R&E system: • enables users to have one account whilst having access to a diverse set of transactions and departments; • authenticates all incoming transactions; • remembers relationships between users and intermediaries (such as accountants).

10. Registration and Enrolment • Registration • this is the process of creating the user account, specifying passwords and providing information such as email address (optional); • the service that is being enrolled for will dictate the level of authentication required (either certificate or userid/password). • Enrolment • this is the process of enrolling for one or more services that the citizen or business wants to use. • Activation • Activation PINs are used to ensure the enroller is who they claim to be. PINS are sent to the name and address held by the back office system.

11. Process Overview Key Facts Government Gateway Internet Letter contents AddressRequest AddressResponse Secure Printers User ID /Activation PIN Gov Dpt

12. What Does The Transaction Engine Do? • Authenticate • authentication of transactions from the Internet; • authentication of department connections over the Government Secure Intranet (GSI)/Virtual Private Network (VPN). • Consumes the transaction • apply a unique identifier and timestamp. • Validate • validate the content of the document header and check the structure. • Route • routing to departmental systems. • Audit • audit and logging; • transaction integrity.

13. Main functions of Transaction Engine • Transaction id routine; • timestamp routine; • call R&E for authentication and service list; • XML Header validation routine; • forward authenticated document to DIS; • “response to customer” routine.

14. Gateway transaction engine Transaction Engine Authenticate Add transaction id and timestamp Parse XML Internet acknowledgement Route Transaction • PC Application/browser • prepare transaction • prepare form • sign and send • display response Transaction response GSI / VPN • DIS • transform data • validate • Department Back • End Server • validation • processing • storage

15. XML • Platform independent; • XML allows the tagging of data; • language used to describe structure and/or content of a document; • makes data more portable and therefore is a keen enabler of BtoB e-commerce; • does not provide presentation information - require XSL for this, which allows you to apply stylesheets to XML to present the information back to the user; • All transactions are submitted using HTTP Post to the Gateway URL using XML.

16. Scenarios • The following scenarios show the different modes of operation you can take advantage of when designing services

17. Authenticated User Form X Please Form X Please Form x please User Prepopulated Form Prepopulated Form Prepopulated Form server e-Forms User Completes form Gateway Dpt System User Form Validated Authenticated User Signs and sends completed form completed form X E-Forms example

18. Standards • XML using XSD schemas and GovTalk header • 128 bit SSL encryption • HTTP • tScheme digital ID (optional) • Any application: Dept/Portal/3rd party • Any host • Any device Customer Applications Application • SSL • HTTP Internet • Authentication • Store & forward • Transformation • Routing • tScheme digital certificates • HTTP and SSL server certificates • XML and GovTalk • SMTP for email acknowledgements • Reliable messaging using SOAP and Biztalk Gateway Gateway GSI ( & Variants) • HTTP • SSL for authentication Backend Systems System • XML and GovTalk • HTTP • Reliable messaging

19. InputsScenario 1 – Pre-populate form with data • Log on and pre-populate form • Complete form • Sign and send • DA web form • 3rd party application Customer Applications Application 1 2 • Input Transaction • Auth request • & response Internet • Authentication & routing • Optionally query backend system for data to pre-populate form. Gateway Gateway 1 2 • Authorised Input • Authorised Data request GSI ( & Variants) • Provide data • Consume transaction • Optionally, validate and respond Backend Systems System

20. InputsScenario 2 – Fill form and send • DA web form • 3rd party application 1. Complete form 2. Sign and send Customer Applications Application • Response • Input Transaction Internet Gateway 1. Authentication 2. Routing to URL for recipient LA Gateway • Authorised Input form • Response GSI (& Variants) Backend Systems 1. Consume transaction 2. Optionally, validate and respond LA LA

21. Outputs Scenario 1 – Customer request for self service output • Web form • 3rd party application 1. Raise request 2. Sign and send Customer Applications Application • Output Payload • Output request Internet Gateway 1. Authentication of request 2. Route to URL for target dept Gateway • Authorised Output request • Output Payload GSI (& Variants) DIS Backend Systems • Self-service data source 1. Access data source 2. Return output

22. OutputsScenario 2 – Department triggered output • Receive email ’you have mail’ • Click link to Gateway • View output or download Customer Applications Browser/ Application 1 2 3 1. ‘You have mail’ email • Request for output • Output payload Internet • Hold output awaiting collection • Send email ‘You have mail’ • Authenticate requests for output • Display or download output Gateway Gateway GSI ( & Variants) DIS Backend Systems • Prepare output • Transfer to Gateway Output to go

23. OutputsScenario 3 – User sends mail to department • Click link to Gateway • Access secure mailbox • Compose mail to department Customer Applications Browser/ Application Internet • Show recipient list based on enrolled services. • Route composed mail to department Gateway Gateway GSI ( & Variants) • Receive message in DIS • Transfer to internal mail or similar systems. • Department can then respond to user (see scenario 2) DIS Backend Systems

24. Secure Mail • Provides a web based mail system for all users; • Allows Government to deliver correspondence into the users’ secure mailbox; • Users can send mail direct to Government departments whose services they have enrolled for.

25. Payments Engine • Will allow bill payment with credit, debit card or direct debit (dept can specify which is acceptable for each service); • Payments can be taken as part of a transaction (Self Assessment transaction could contain a payment section) or via the payment web site; • User can receive bills via the secure mailbox and pay in the same session on the payment engine.

26. Summary • Gateway provides a conduit for secure transactions between customers and government, covering Inputs, Outputs and Payments to Government; • Need to register with the Gateway and then enrol for specific services; • Transaction engine always ensures that there is a response to each request and assurance that government has received the transaction; • DIS boxes are housed at departments.