This section illustrates some of our early ideas relating to the idea of an external private asset.
The interested reader can see how this idea evolved by downloading the final report.
Description
One of the key things we have attempted to capture in our draft asset list is the security model for each asset - i.e. how is it accessed. One outcome from this analysis, albeit an obvious one, is that there may be a myriad of security models which must be handled by the e-portfolio tool. This in turn led us to consider how this might be handled from a usability viewpoint - that is, the system must be as simple as possible to use for the academic and the employer. Security is a requirement, but it must not make the system unusable.
One possible solution is outlined below, where we introduce the concept of an external private asset. In this, the e-portfolio has the functionality to manage authentication / authorisation with external systems, using a variety of methods. Users will set-up the authentication / authorisation for an asset once only, when they create that asset (and we foresee that the e-portfolio system will provide wizards to help in this task). Thereafter the e-portfolio will manage any authentication / authorisation required to access the asset transparently to the user.
The second part of the model is that, when a user wants to give permission to third parties to view external private assets, the e-portfolio system will act as a proxy to control the access.
The idea behind the model is to simplify the process for the user (set-up authentication / authorisation once only, a common model for providing access to external private assets no matter the security model of the asset, etc) and the employer (just click on a URL to access the asset). One of the key issues we still have to address is whether the same security model which is required to access the external private asset by the e-portfolio should be rippled through to the employer (i.e. if the asset requires Shibolleth authentication then the employer must be similarly authenticated) or whether a system of providing secret URLs to all external private assets is appropriate.
The provisional model also appears to meet some of the key user requirements (which will be described in the forthcoming "Scenario Elaboration". There is a fundamental tension between (a) the needs of the employer (the recruiting academic) for use of the standard application form (a corporate requirement) and an incremental presentation of information, with substantial commonality with a non interactive text-only presentation, to allow a quick evaluation of the interactive e-portfolio-backed application (without clicking through to any of the detail evidence) along with (b) the desire of the applicant to leverage all the relevant information already present in their e-portfolio.
The approach presented here minimises the technical burden on the application form (by only requiring it to accept URLs) while allowing the applicant to provide richness of information through these URLs.
Separately, we also recognise that the burden of work for the applicant associated with assembling the e-portfolio in the first place, is significant. In fact, it is often the reason why personal (e-)portfolios (cf Progress Files, Records of Achievement) fall into disuse. The project takes as a given that the applicant already has an e-portfolio and is using it for other aspects of their personal and professional advice (eg providing evidence for appraisal, maintaining a personal datastore/knowledge base). For the e-portfolio employment scenario to be attractive (ie to be worth the bother over and above paper application), the approach must (a) allow and encourage the use of rich evidence and narrative from the e-portfolio, and (b) make it as easy as possible to reuse this evidence and narrative, from whyever it was created, in the e-application. By placing the e-portfolio application at the centre of the model, this approach maximises the potential for reuse.
