Back to Course

Scottish Digital Government

0% Complete
0/0 Steps
  1. Digital Government Transformation
    4 Topics
  2. Service Design
    4 Topics
  3. Agile Development
    2 Topics
  4. Digital Identity
    6 Topics
  5. Connecting Scotland
    2 Topics
  6. Government Cloud and Applications
    6 Topics
  7. Local Government
    3 Topics
  8. Digital Health and Social Care
    3 Topics
  9. Digital Democracy
    1 Topic
Lesson 4, Topic 3
In Progress

Digital Identity Scotland – Scottish Attribute Provider Service

digitalscotland July 13, 2021
Lesson Progress
0% Complete

The feature video introduces the Scottish Government’s plan to build and implement SAPS – The Scottish Attribute Provider Service, which:

“Will improve citizen’s access to public services, by providing them safe and easy ways to prove their identity, or attributes thereof, which are relevant to eligibility for the service.”

Key design principles include user-centric principles of only allowing the sharing of data between services with the active consent of the citizen, no data will be shared for commercial purposes nor will data be stored in a centralized database, ensuring that a citizen’s data remains under their own control, so they can store and consent to share their data with public sector organizations where needed.

Verified Attributes is data about a citizen that has been proven by a trusted public sector organization, that can be reused to save the user time and effort, and reduce bureaucracy costs for the government.

SAPS 1.0 – 4.0

An implementation roadmap is planned across four main phases:

  • 1.0 – Q4 2020: User will be provided a digital sign on for services, so that the user can save and resume online workflow processes.
  • 2.0 –  Q2 2021: User can save Verified Attributes for future use.
  • 3.0 – Q1 2022: Identities can be verified by trusted parties.
  • 4.0 – Q3 2023: An easier user journey, reducing data input requirements and removing dependence on third party identity providers.

User-Centred Design

From 11:20 they describe the methodology they’ve applied to ensure user needs are at the centre of the service design. They’ve set out to create an adaptable design that can cater for the full spectrum of different user scenarios, such as an Older Adult, a Parent and a Young Scot Card Holder.

These have been organized these into five main themes:

  1. Multiple user groups – Services that support the individual and the organization.
  2. Clearly add value – Communicate the benefits of the program.
  3. Ease of integration – Utilize current solutions and tie in with the existing user journeys.
  4. Accessibility – The solution needs to work well for every one.
  5. Future proof – The solution needs to be forward looking and enable public sector innovation.

High Level Solution

From 14:30 they share their high level design for the SAPS system, emphasizing the point it is an evolving design and they welcome feedback.

This will function as a closed ecosystem for public service providers, where they can make use of shared verified attributes to reduce friction when accessing digital services. The user will own and control their attributes, and be provided a single sign-on, giving access to a secure place for storing their attributes, an encrypted store where they can authorize their consents.

The three core building blocks of SAPS are The Credential Provider, the Attribute Store and Broker. The user will have a strong authentication credential from the outset without providing their identity, a credential that complies with GPG-44.

SAPS Relying Parties will offer users the ability to store and control their credentials in the Attribute Store, provided free of charge, and is controlled by the user – Only the owner will be able to view and decrypt the content. Attribute Store capability will include the ability to create and sign derived attributes.

The Broker will enable a low cost approach to integration, and will manage protocol flows and session state, supporting SSO across credential providers, as well as orchestrating calls to the Attribute Store.

Other functions will include consent management, derived attributes, standard metadata, delegation and attestation.


At 29:50 they outline the procurement process for building SAPS. Their expectation is they will contract a capable development partner who can to plan, select and integrate the different functional components.