Over the past decade or more, we’ve developed federated access management as a technical, policy and legal framework to exchange up-to-date information to help current staff and students access the resources they need. Authentication, status and membership information all need to be fresh to be useful and frequent use makes it worth organisations entering into formal federation agreements to ensure that.
But there’s another kind of educational information that’s far longer-lived. Degree certificates are still relevant forty years on; transcripts of course content at least a year or two. These are used much less often, but with a much wider range of organisations. Various technologies have been proposed to store and process these in digital form. So what might their legal and organisational framework look like? Existing processes around paper degree certificates provide an interesting angle.
Issue:
- Institution creates certificate and provides it to graduate. Certificate has various mechanisms to enable validation (often a university crest) and to help detect forgeries.
- Graduate stores certificate in a safe place.
Presentation (perhaps many years later):
- Graduate presents certificate to potential employer as proof of qualification; employer’s grounds for requesting that personal data will usually be that it is “necessary to take steps prior to entering into a contract” (GDPR Art 6(1)(b)).
Assessment. Employer does one or more of the following, to obtain the verified information they need:
- Checks that certificate is not an obvious forgery. This uses characteristics of the certificate plus generic information (for example whether the institution used that title at that date). There is no processing or transfer of personal data.
- Checks that the qualification is relevant to the job applied for. Again, this uses only information on the certificate, any processing personal data should be limited to matching the qualification details against the requirements of the specific job.
- (optional) Verifies with the issuing institution that the information in the certificate is still valid. This does involve a new processing of personal data, by both the employer and the institution: typically the graduate is asked to consent (GDPR Art.6(1)(a)) to this one-off transfer in their application (“you agree that we may check your qualifications with your university”).
- (optional) Requests additional information – topics covered in the course, relevant skills demonstrated, etc. – from the issuing institution. Again, this is a new processing activity based on a one-off consent.
All these steps, except one, either do not involve processing of personal data or have an obvious GDPR provision. So what part of GDPR best fits the first step – the creation and issuing of the certificate?
Consent seems to work at a high level, but thinking of it as “data subject requests copy of own personal data” makes either the Article 15 Subject Access Request (SAR) or the Article 20 Right to Portability (RtP) a much more precise fit. The right to portability would be best of all – the intention here is, precisely, that the data subject will subsequently “port” the information on their certificate to another data controller – however this formally only covers information the student has provided to the institution. We therefore need to fall back on the more general Article 15 right of any data subject to “obtain … access to data” that is being processed by the controller. In practice, many regulators seem to have treated the Article 20 right as a formatted SAR anyway, and Article 15(3) already requires “provided in a commonly used electronic form”.
So a possible framework for long-lived digital credentials might look like:
- Process 1 (“Issue” above): user requests a digital copy of their qualification: institution provides the data in standard electronic form (e.g. a W3C verifiable credential) as an Article 15(3) Subject Access Request.
- Process 2 (“Presentation” above): applicant presents qualification data as part of an application, most likely requested as Article 6(1)(b) necessary for contract.
- Process 3a (“Forgery” and “Relevance” above): recipient checks that the offered data is not obviously forged (e.g. that its digital signature is valid), and is relevant to the role applied for. This may, particularly with a formatted credential whose validity can be checked separately to its content, involve no processing of personal data; or the processing may be necessary for contract or consented.
- Process 3b (“Verification” and “Request” above): recipient may ask the issuing institution to either confirm or supplement the information contained within the certificate. To authorise this one-off transaction the recipient should obtain a recent, specific, consent from the applicant. The institution has a free choice how to respond: for paper certificates, consent is routinely received as a photocopy of a tick on a form, but the digital world may offer more robust processes to check and confirm (for example verified credentials can include expiry dates, when either the holder or issuer must refresh the information and its signature).
This framework, which treats Issue, Presentation and Assessment as individual, free-standing, transactions, is very different to the federated access management model’s ongoing exchange of data backed by a long-term contractual relationship (the “Federation Agreement”, for example for the UK Access Management Federation). That provides safeguards such that we can take the individual’s requests to access content and services as implicitly directing the necessary release and processing of real-time information, it being in the legitimate interests of institution and service provider to facilitate access to services desired by their members. Requiring explicit consent for each transmission of information would be impossibly onerous for all parties.
However in the qualification context, information flows are much rarer and sparser, occurring between a much wider range of parties. Requiring a pre-existing contract is therefore too heavyweight, and a framework where the individual explicitly requests each transaction is both more appropriate and a much more natural fit for the actual data flows. In both frameworks, the responsibilities of each party (and their limits) are clear and appropriate to the context.
Finally, there is a natural transition between the two models. Where an institution and an employer have a particularly close relationship (for example through student placements) they may well want to enter into a contract to cover that relationship. Such a contract could naturally include moving to the “federated” model with its stronger guarantees of fresh data and safeguards agreed once, by contract, rather than on every individual transaction, by consent.
