1. The eCert Project Project director: Dr David Argles Project manager: Lisha Chen-Wilson Project assistant: Dr Tao Guan Learning Societies Lab, School of Electronic and Computer Science, University of Southampton, UK

2. Agenda Morning Session: eCertificate issues and problems Afternoon session: Towards solving the problems: the eCert plan

3. eCert outline Objective To develop and test a suitable protocol (eCert) for electronic certificates, which can be used either stand alone or within ePortfolios Main requirements from ePortfolio prevent forgery, authenticate the veracity of the data transmitted, allow for verification of the certificates and its related files; protect privacy, owner can control who can see what and for how long; suit users with low IT skills; allow for easy transfer of eCertificates between different systems;

4. Existing systems We have looked at four systems in particular: GDP project system Chinese system Digitary Europass Each has something to offer, but we believe that a full national system should consider: The student's full academic record The status of individual certificates The student's right to tailor the look of what is presented The need to continue to certify an award after the awarding body ceases to exist The need to minimise storage requirements The need for scalability

5. eCert stakeholders An eCertificate issuer is a body that creates and issues the certificate, such as a college or a university. An eCertificate owner is the certificate holder who has successfully passed the qualification certification process and gained the award, such as a student or a graduate. An eCertificate reviewer is an organisation or a person who receive the certificate as a proof document for an application. This can be an academic institution or an employer.

6. eCert scenarios processesScenarios and conditions createAn exam board checks that the students have successfully passed the particular exams, and are who they claim to be, and then creates the eCertificates accordingly. -- This involves identification and verification against the exam board’s database. The creation process needs to have standard control for all level certificates in order to suit educational institutions of a wild range. issueThe exam board issues the eCertificates for students. -- This needs security methods to a) indicate that the eCertificates are issued by the exam board, in order to prove its genuineness; b) prevent unauthorized editing and copying after issue; c) issue the eCertificates; withdrawAn exam board found out that an eCertificate was misissued, and needs to be withdrawn. -- This needs security methods to support the withdrawal mechanism receiving award The students receive their eCertificates, and view the contents. -- This needs security methods to ensure that no one other than the students themselves can view their own eCertificates. manageA student specifies certain eCertificate views to be visible to particular employers. -- The student needs to be able to control who can see what and for how long. The system design needs to be user friendly, suitable for users without IT skills distributeA student sends the selected eCertificates to potential employers -- The student should be able to send the eCertificate(s) alone or within an ePortfolio. reviewAn employer views the received eCertificate(s) -- This needs security methods to a) ensure only the specified employer can view the eCertificate(s), but not anyone else; b) protect from modifying and unauthorized copying. verifyThe employer verifies the received eCertificate(s) -- The system need to be able to verify all level qualifications that are issued using the same standard from any education institutions nationwide.

7. eCert scenarios and use case analysis eCertificate assertion: The system need to be self certificating to prove it’s genuine, and also to allow reviewers to further confirm it. From ePortfolio’s point, this may need to include the evident files that the assessments based on. As well as generating these assertions, it should be possible to withdraw them. Parallels can be drawn with Public Key Infrastructure certificate systems, which provides the required method while also maintaining a revocation list of keys which are invalid as they have been compromised. eCertificate privacy: The ePortfolio privacy issue also applies to eCertificates, as no matter whether it is used standalone or within an ePortfolio, one aim is to give students control over who can see what and for how long. This can provide the owner with flexible control over the content (e.g. hide the marks); and prevent untrustworthy reviewers republishing the e-certificate without the owners’ permission (e.g. to an ePortfolio bank which recruitment agencies might access). This is a similar paradigm to Web 2.0 social networking sites were a user can “categorize their network [of friends] into different access groups with different access privileges”.

8. eCert use case analysis (c0ntinued) Stakeholder Trust: The use cases shows a situation that authentication of data is required when transmitting between two or more, but not always known, parties. A fundamental requirement is the need to establish trust amongst all three stakeholders, such that one stakeholder can place faith that the identity of another is true, and their eCertificates have not been tampered with: o The issuer needs to maintain a reputation o The owner need to know that they can trust the credibility of the award they have obtained; but they also need to trust the reviewer not to misuse the information on the certificate. o The reviewer needs to be able to trust issuer, not only to maintain standards, but also to have protected against fraud; and to trust the owner not to have tampered with the eCertificate. Once more, parallels can be drawn with PKI systems where trust networks have to be engineered in order for any other user to see value in the key certificates generated. This is typically achieved either with a hierarchy of globally “trusted nodes called Certificate Authorities” (CA) or methods such as Pretty Good Privacy (PGP) where chains of trust are formed between users who already know each other.

9. eCert use case analysis (c0ntinued) Distributed Stakeholders: To “stimulate large-scale uptake” of users, eCertificate tools need to define “architecture of participation”. The eCertificate system won’t work unless there is a significant body of universities and employers who will accept them. This concept is defined within the Web 2.0 community as the network effects that are achieved when “Users Add Value” and encourage further users to participate. E-certificate lifetime validation: When consider the three parties authentication problem outlined above, it can be seen that the effective “transaction” period lasts for the entire lifetime of the eCertificate owner. E.g. people who have continued studying well past the age of retirement, may still be presenting awards they acquired as children, decades previously. The important factor in this is the lifetime of the e-certificate owner. During their lifetime, it is almost certain that awarding bodies will have come and gone, so an e- certificate system needs to be able to validate an award long after the issuer has ceased to exist. The implication of this is that an e-certificate system needs to be independent of both issuer and reviewer and to be able to provide a mechanism for the e- certificate owner to continue to provide evidence of their attainment long after the issuer has disappeared

10. Discussion 1.Are there any missing issues? If yes, what they are? 2.Should there be any more required functions? If yes, what they are? 3.Anything that is over and above what is required? 4.Are there any errors and misunderstanding? 2 groups Group A: 1  4 Angela SmallwoodNottingham University Jonathan DempseyDigitary Peter Rees-JonesUniversity of Leeds Simon GrantJISC-CETIS Shane SutherlandPebblePad ePortfolio Clive ChurchNottingham University Tao GuanUniversity of Southampton Group B: 4  1 Kirstie CoolinNottingham University Andy DowlingDigitary George InmanUniversity of Kent John HarrisonEdentity Scott WilsonJISC-CETIS Christopher BrownJISC David ArglesUniversity of Southampton

11. The eCert project Afternoon session: Towards solving the problems: the eCert plan

12. eCert digital signing issues – the (eCertificate) 2 problem

13. The selected approach and its issues

14. Ideas of solving the problems Unique numbering systems Certificate revocation lists Auto request Timestamp Content Extraction Signatures (CES)

15. eCert system design decisions and rules Aim to provide service for eCertificates issued through out the UK The service will have a single reference point nationwide Every student need to register a student account (e.g. When start study at six form or college ) Student : student id  1 : 1; Student id : eCert id  1 : many All institutions and their presenters will need to be certified first eCert central system will maintain a revocation list for all issued eCerts. Institutions will update their eCert revocation list to the central system on a regular base

16. Propose solution – the eCert protocol

17. Create eCert

18. eCert management subsystem

19. eCert verification subsystem

20. Discussion Clarification? Errors and Mistakes? Comments and suggestions?