Meetings Log

Here are the working notes from each meeting in a rough summarised form – to provide a record of the development of the project. Much of these discussions and findings and conclusions have found their way into the My Skills white paper document.

1-10-18 My Skills Project Kick off meeting

A long and very productive meeting – the agenda gives an idea of what we covered. Here is the scratch agenda:

  • ‘Walk through’ the project plan (PID) and discuss – be good opportunity to review and harvest ideas and insights on the fly before we dive into the nuts and bolts
  • Discuss a draft consortium agreement – I will send this out before hand
  • Review the risk register
  • Stakeholder mapping exercise – contacts etc that would be very useful as this is important to the Ufi
  • The practical, policy and technical aspects to linking APPII to a source of SQA test data for the white paper – data model, API, GDPR etc
    • The APPII business model – we will need to be able to describe this in the project
  • How APPII works – be good to go over that at the start – so that we can later create an infographic(s) of the data flow and relationships between the users of the envisaged system
  • GDPR compliance
  • Sustainability – where do want at the end of the project.
    • Long term scenarios as well for data preservation and access – cf to current paper-based systems

15-11-18 My Skills Project meeting & Workshop discussion session

At this meeting we had a regular project meeting for the first hour and then devoted the rest of the meeting to a workshop style discussion about how APPII works and how it might be integrated with the SQA systems. Gary from APPII did a great job of creating the technical diagrams and talked us through things as he went see the images and captions. This discussion has fed through into the white paper document. Some general points from the meeting.

Use Fake student accounts – GDPR concerns. Consider using the ‘My SQA’ service (an existing user facing info service) database as the basis of data source feed into APPII

System needs to be learner / user centred

Control of access to data over time – the user needs to be in control (GDPR). The user can remove their digital key and so disable all pubic access they can (in a future APPII development) put a time limit on how long someone can access their data.

The APPII value proposition (for a user) is a central place that users can manage access to the proof and verification of their qualification and easily manage and share this. Other useful services includes a CV builder to easily assemble custom CV from the user profile and the ability to share a link to the CV or download and print the CV as a PDF

Needs to be as easy as possible for users  to use (e.g. predictive text)  to make an enquiry, with pre-loaded institution names (aka centres) because users relate to the provider not the awarding organisation – this means the system has to be able to link the centres to the awarding body over a long period i.e. the SQA has to be able to provide a historical list of the providers and centres to search through to enable the users to locate their qualification for verification with the SQA  awarding body

The Learner Record and the SCN (Scottish Candidate Number): It looks like the SCN is central to the SQA end of the system as each individual has only one of these (should do!) and this will be linked to the learner record for the user – the learner record contains all the data about providers / centres and qualifications connected to the user – i.e. the main data source for this project in the SQA.

We need a narrative of the steps to access the learner record data – Use a google doc to capture and share the data model / system structure, user journey etc.

Need to explain Micro credentials are possible and perhaps give some examples in the white paper

28-11-18 Meeting with APPII via skype

  • APPII and its bizz model and background processes need to be clear to users for cred and trust (John)
  • APPII perspective is the user needs to be authenticated – that is the key to everything else (confirmed by SQA at the 20/12/18 meeting who said that took care of things potentially for them to open up their data to APPII)
  • Agreed
  • APPII checks against a 3rd party service for the result so scanning an official ID card and bio face scan – need to unpack that process for users more than it is in the current APPII support notes. Need more info about what can be checked
  • We need to answer user questions – why the face scan and ID card scan (see above)
  • The APPII bizz model needs to be explained to users
  • How do businesses and employers currently know the certificates are legit? (paper and digital) – trust is a cultural thing…
  • APPII can support micro accreditation and internal training cpd etc – useful for organisational buy in
  • Location of training can be specified via GPS. Date of training captured – this could all go in HR admin systems as well as user APPII accounts.

20-12-18 Workshop at SQA

This is where we really started to get into the detail.

We started with an off-script topic – after a conversation with a rep from a commercial blockchain company selling ‘high speed blockchain for general data management, which I was highly sceptical about. TPS (for blockchain) are Transaction Per Second. Typically for blockchain systems these are slow compared to banking database processes. This question was raised in connection with a discussion about claims being made for ‘high speed blockchain’ applications in the health service. Shows how wide-ranging the hype is about blockchain at the moment. We then got into the nitty gritty of the meeting.

What we are discussing in the project is pretty simple and basic – a secure place to store data between 2 organisations (SQA / APPII) and allow users to access their own data.

Key system components

SQA <-> APPII <-> User (Learner)

Key elements of the system assessment certification and authentication

Tasks roughly for today – Identify process to make the vision work and begin to create the basis for white paper, Model, Scenarios, Use cases, Personas and User Journeys / Stories etc. View the task as developing an overall generic mode for adoption of digital certificate.

My SQA as the basis of the data. The SCN as the unique identifier in the system  – but the APPII system has to somehow resolve to that….? This would be the same for different awarding bodies.

My SQA provides access to the ‘Learner Record’ this contains the results and qualifications, also the qualifications they have entered including the results of individual units. The digital data goes back to the 1990’s And new users of the system are about 50-60k per annum.

From the APPII perspective the SCN is core. Users become aware of their SCN at different time in their lifecycle and when they register for a qualification. But in general, a user will not know their SCN – they will however relate their qualification to their learning provider

Right hand flipchart 1-5 are consumers, 6 the user is not a consumer of the data but is the data subject (GDPR)

Digital certs – need a digital look up table?

Which parts of their system do the SQA monetise?

  • Replacement certificates– will be regarded by some as income – but this is not replacing existing paper certs? Instead enhancing them (see white paper V1 notes and MOOC examples for more)
  • Each course is provided by a centre – admin and QA

Replacement certs are a point of friction in implementing digital certs for some organisations (especially HEIs) with a misconception that this revenue is ‘profit’ when it is a cost. Also, the replacement cert ‘business’ done not mean that is a reason not to have digital certification. We envisage a system that includes paper and digital.

Scottish culture, media and tradition concentrates on getting paper certs and results via the post whereas students in England go to see their results on a board. Importance of local cultural traditions and attitudes.

Apprentice Certificates are provided by a Centre (SVQ)

The SQA and the SCN are rather invisible to the user. Instead the user relates to the centre that provides them with their education. APPII assumes they will search via their provider. For this the APPII system will need to have a historical list of centres / providers – yes the SQA does have such a list – it would need to be put into such a form that it would be query able by APPII. Probably needs more work to create synonyms etc. On cert replacement task this is currently done by human judgement.

Use the existing paper cert replacement query process questions to test / verify the APPII systems calls to the SQA.

The benefits of the Digital certs are to the users, employers, economy and learning providers. Benefits to Awarding bodies??

APPII business model – employers and employment agencies are their market for revenue – free to use for learners, learning providers and awarding bodies. They are already active in regulated work environments (Health, Care, Offshore Engineering) and as part of their service charge for background checks. This makes the hiring process smoother, more efficient and cheaper to admin and enables employers to concentrate on the suitability of applicants.

Another AB holds record going back to 19962 and digital record going back to 1974

APPII uses a 3rd party supplier for biometric data to support their platform.

The QR code on the CV builder provides an additional layer of reassurance for the employer.

The APPII system can also be used to verify work experience (like Abs) for this employers have to register first – usually nominated people in HR will verify. They also provide other onboarding services (like background checks). Gary simulates a verification request to the SQA on the test system. Verification is done with a  mix of public and privates digital keys between the user and the AB (4 keys in all)

For the users or ABs to withdraw verification they withdraw the private key – effectively destroying access to the data.

To enable updates to user quals from the AB a system upgrade (APPII) would be needed – doable.

In the envisaged integration with the SQA system the user gets to see their learner record and chooses what qualifications they want to verify and have in the APPII system to use. This is transferable to other Abs

When a qual cert is verified it can be placed in a the APPII CV builder. For privacy only those with a link to the CV builder will be able to see the CV. Time limited access is not possible at the moment. Might be a future feature.

Q. What about just having a link to a list of quals that are verified that the user can use with different systems – follow up…

Digital evidence can be placed in the blockchain and linked to the verified qual. Quite doable (!). This prompted a lot of discussion and would be attractive for policy makers and others to develop consistency and quality and could be integrated into the verification and QA processes of Abs. This is potentially a really big deal!! c.f. the work of JC and CEAG and SQA enhanced guidance on digital evidence..

GDPR  – can the learner destroy their record? No But they can destroy access by withdrawing their key – the same thing?

9-1-19 Meeting at West College

A wide ranging meeting that covered the uses of digital badges and possible applications of blockchain – this helped clarify my thinking as I had just done the first draft of the white paper and was able to use parts of that in our discussion. The meeting was arranged by Hannah Wilson who is the organiser of another Ufi project involved in developing training resources for care workers called Carevolution. Through this meeting we got a really useful contact with the Scottish Social Services Council (SSSC) who have been doing a  lot of work with digital badges and they are going to give feeback on our white paper. And through the SSSC we got a really useful contact with the English equivalent.

21-1-19 SQA design meeting process

(AB = Awarding Body)

Purpose – scope / outline what kind of data the SQA would need to supply into the block chain to make it work for users in the APPII system.

Quick review of previous meetings (15/11/18 & 20/12/18) and the draft white paper notes doc. (early version)

Agreed the relevant design decisions from the white paper notes doc:

  • System is designed around needs of users
  • Use blockchain for storing data
  • Use external blockchain service provider
  • Use existing paper-based replacement certificate process as model for digital system

SQA and other ABs will be using a number of data services to supply them with data they need in their processes. So changing formats can be a challenge (e.g. schools sector). Something to think about going forwards

For the purposes of this project it easiest and relevant to concentrate on the FE sector because the SQA is in control of all the data for this ‘data pipeline’.

It was agreed that there should be the options for a human intervention if an APPII user could not find their qualification in the system. This could consist of a form or a link to the existing SQA enquiry service. So APPII is also a way of reducing the demand or streamlining the process for replacement paper certificates

If APPII handles the individual identity verification process the user can query the data base and be able to supply the following information to make the query:

  • Name (auto from APPII)
    • There is a need for married women to be able to enter previous surnames
  • DOB (auto from APPII)
  • Centre Name)s) (manual) – with options for antecedent names
  • Qualification Name / Subject
  • SCN / AB system unique identifier with a link to obtain it separately is needed (not mandatory)
  • If there is an apparent data conflict the user could be directed to contact the SQA for clarification

This would be enough to let the SQA AB system, present everything the system holds for that user from that provider. In addition, this would tell the user what their SCN is even if they do not know it. Quick verbal rough run throughs by SQA people in the meeting suggested this would work. But needs to be tested

Data Reality Check: What information does an existing certificate provide?

  • Name
  • Qualification
  • Scottish Candidate Number (AB system unique identifier)

So in terms of data it is pretty minimal – the existing paper system greatly relies on trust – that the holder of the paper certificate is entitled to it.

Next Steps / Actions

  • Paul and SQA Colleagues to agree an initial data schema for what the SQA would put into the blockchain
  • John to Use City of Glasgow College and it’s antecedents to create users for us to use  in a ‘paper prototype exercise’ to search for a certificate from:
    • Glasgow Nautical College
    • Glasgow College of Food Technology
    • Glasgow College of Building and Printing
  • John to create a Google folder / doc for us to share
  • Meet up again
  • Start work on the user journeys

5-2-19 My Skills SQA workshop Notes

Discussed previous meetings work. Then started to discuss the idea of a draft data schema, raised at the last meeting. John brought along a set of test accounts based on previous colleges that were merged into the COGC and SQA qualifications.

Meet again in the first half of march

Wednesdays not

After Next week can start on user journeys


Married names not really an issue for most while at college but would be after. The model revolved around the user providing information to APPII to verify their identity so that that the SQA would be satisfied that part has been done.

The user creates an APPII account – enters data – verified identity

User contacts SQA via APPII to request a digital certificate verification (see below)

The SQA will require the following information; to be supplied by a mixture of the APPII profile and any associated data that APPII pulls from identity verification services:

  • DOB
  • First name
  • Surname
    • Names at time of certification
  • SCN (if they have it)
  • Name of Learning Provider used while they studied there (mapped against ‘centre coded’)
  • Qualification(s) names requested
  • Address at time of qualification

Note: there will always need to be a human communication channel option for users who cannot match their ID to a qualification or who have any other queries about their SQA qualification.

NB – makes sense that all the qualifications on record are returned for that user – not just the ones requested, need to see how that is presented in the system and user options for selection and presentation to 3rd parties.

Creating a data schema for this (has sent a draft copy to John). John will share the draft schema with APPII and another awarding body – the NCFE – to see if that would be the basis for a similar schema for them. John is meeting with the NCFE in the last week of February to do a workshop session similar to what we have done with the SQA. NCFE is arranging this. 

Small Technical Tests / Trials

  • John will use the schema to input test data to the APPII blockchain for the test accounts he has created to see how that works from the APPII user side.
  • SQA will set up a small test server with a database with test users and see if this can be linked to the APPII system and interrogated by a test user to pull back data into the APPII blockchain to be used as the basis of digital certificates in the APPII system

NB The SQA will try to make a best match to this information from its records to issue a digital cert. If a match is found the SQA will write the information to the APPII blockchain for that user.

If a match cannot be made the user will be asked to get in touch with the SQA directly to provide more information – via a human channel

NBS QA will not write bulk data to the APPII blockchain, it will write in response to requests from users via APPII – that way the most up to date data at the time is used.

See diagram below:

How the data is written to the APPII Blockchain
Blockchain Write Process