Credentials

A credential is a certification of status or accomplishment. A university degree is a credential; so is a driver’s license, and so is a certificate for having completed the Boston marathon.

What characterizes a credential is that although it is held by a given individual (or, in the case of ISO certification, organizations), it is something that is not in the exclusive domain of the individual. You cannot simply award yourself a university degree or first prize in a spelling bee; the credential has to be granted by some external agency.

In the world of pen and paper, credentials are represented in some physical form, such as a certificate or a diploma. These certificates have a unique appearance, and are typically signed by presiding officials and stamped with the granting institution’s seal. This makes them difficult to duplicate, but not impossible. As a result, there are also systems for the verification of credentials. These typically involve the granting institution attesting directly to the questioner.

This tells us what we need to consider when thinking about the presentation of credentials in a personal learning environment. As the creators of e-portfolios have already determined, “Evidence of any Summative Assessment must be linked to a secure repository ie the awarding body or a central MIAP/Minerva archive.”

MIAP, which stands for the “Managing Information Across Partners programme (MIAP)”, “is an IT enabled, data centric set of shared services built on the principle of collect once, use many times and used by all that are entitled to do so.” Students are identified by a unique learner number and credentials are associated with that number. This can support validation of credentials; as Mark Power states, “SOAP based web services can be accommodated by MIAP to support external applications.”

How would this be represented as data in a personal learning environment. Probably the most comprehensive specification with respect to personal qualifications can be found in the HR-XML specification. In this specification, individuals are designated as candidates that may have resumes. A variety of certification types may be found listed in the resume element, including certifications, licenses, military history, qualifications, and more. In addition, HR-XML specifies an additional competency definitions element.

Though there are small variations in each, the certification types follow a common pattern in HR-XML (so much so one wonders why they weren’t just treated as a single type of element). If we look at the licenses element, for example, it begins with a ‘valid from… to’ element and a version identifier. Then there is a definition of a scheme that corresponds with the license, with scheme ID and URI locations, along with a scheme agency ID and URI.

In related work, a course advertising XML format is being undertaken in XCRI’s Course Advertising Protocol (XCRI stands for eXchange of Course-Related Information). The work is part of a wider landscape of related work, which would address such issues as pre-requisites, portfolios and credentials. Various tools are available, including schemas and aggregators. My thanks to KavuBob for Twitter help.

A number of other specifications exist and are summarized on this Eifel page (Eifel stands for European Institute for E-Learning). EasyCV allows you to build a resume online and make it available on the web, in Facebook, and elsewhere. Europass is a qualifications exchange system in Europe; an extensive vocabulary is available on the Europass website. CVUniversal is a system providing CVs to potential employers.

In these instances, which can all be represented as instances of HR-XML, the credential is embedded in a larger document, such as a c.v. Another approach is to view it as a separate element, which can then be embedded in various documents as needed. This is the general approach taken in microformats, and the hresume element is intended to fulfil this function. But hresume is too simple; there is not the suggestion that these are certificates issues by, and verifiable by, external agencies.

When thinking about credential systems for Plearn, it seems to me that the HR-XML system is well entrenched and should not be ignored. That said, the treatment of credentials inside a PLE should be more mobile and lightweight. Rather than being thought of as a part of some other document, each credential should be thought of as a separate document, and the original of the document is held at the certifying agency.

Credential metadata is stored in the PLE, each record corresponding to the HR-XML format specified above. As in the specification, the name and URI of the agency and the schema is specified, and the credential ID points to a specific instance of the credential. The local PLE data should also include, over and above HR-XML metadata, a title identifying the name of the credential, and a description field containing any relevant information about the credential; this information would be derived from the original of the credential. A credential ‘type’ parameter would alleviate the need to have separate definitions and storage for each different type of credential. Finally, a copy of the credential may be stored locally, with a pointer to the copy as well as to the original in the credential metadata.

Thus represented locally, credential information may thus be made individual by a person from his or her PLE. This information may be displayed as a web page, in an XML feed, made available as a service, distributed to a Facebook page, or syndicated in some other manner. The reason for doing it this way is to allow the person control over the distribution of his or her credentials. Information not distributed by an individual should not typically be discoverable without the permission of the individual.

A PLE that manages credentials in this manner is therefore well adapted to the existing credential landscape. It leverages existing specifications, and can interoperate with existing credential registries. It also allows for the possibility of a wider, distributed, credential infrastructure, as any stand-alone third party service could serve as the issuer of a credential. Thus a person with such a PLE could accumulate not only centrally managed credentials, such as university degrees and driver’s licenses, he or she could also report a wide variety of training and testing outcomes.