Project Summary

The Linkey project will provide JISC and the community with a Case Study and related technical outputs of an implementation of the OAuth 2.0 standard as part of an institution-wide strategy for Access and Identity Management at the University of Lincoln.

Working closely with the university Library, we will examine how the OAuth 2.0 specification can be integrated into a ‘single sign on’ environment alongside Microsoft’s Unified Access Gateway.

One of the lasting outcomes of our JISC-funded Total Recal ‘rapid innovation’ project in 2010, was that we wrote the first (and only) OAuth 2.0 server for the CodeIgniter PHP development framework that we use. Since the Total Recal project, we’ve used OAuth 2.0 for a number of projects: Jerome, data.lincoln.ac.uk, Zendesk, Get Satisfaction, and more recently the cloud-based Orbital project.

Having been researched, developed and implemented under earlier JISC-funded projects, our OAuth 2.0 server has been formally adopted by central ICT Services, and consequently a more user centric approach to AIM is being adopted, where staff and students are gradually being presented with a consistent sign-in process, as well as given control over what services their identity is bound to and what permissions those services have.

Objectives

Our intention is to show how OAuth 2.0 can be used as part of an access and identity environment in higher education that improves the student experience by:

1. Richer sharing of data between applications: A student or lecturer should be able to identify themselves to multiple applications and approve (and revoke) access to the sharing of personal data between those applications.
2. A consistent user experience (UX): We are initially aiming for ‘consistent sign on’ rather than ‘single sign on’, where the user is presented with a consistent UX when signing into disparate applications.
3. Rapid deployment: New applications that we develop or purchase should be easier to implement, plugging into either OAuth or the UAG and immediately benefiting from 1) and 2).

Anticipated Outputs and Outcomes

Output / Outcome Type (e.g. report, publication, software, knowledge built)	Brief Description
Case Study	A case study of our implementation of OAuth 2.0 together with Microsoft’s UAG product. We will provide draft sections of the final case study in 12 monthly blog posts, allowing for early peer-review.
Code	Continued development of our open source OAuth 2.0 server, including an implementation of the ‘SAML 2.0 Bearer Assertion Profiles for OAuth 2.0’ specification and other relevant extensions to the main standard. We aim to produce a ‘drop in’ solution for OAuth 2.0, in a similar way that the SimpleSAMLphp project supports SAML implementations.
Workshop	A public workshop on the use of OAuth 2.0 in Further and Higher Education.
Conference paper	A conference/journal paper, based on our case study.
Expertise	Expertise in the implementation of an institution-wide infrastructure for AIM.

Overall Approach

ICT and the Library have agreed to take the following steps to achieving our above stated objectives:

• To ensure a single, consistent identity for each person, all library (and ICT) applications that we operate internally must have Active Directory sign-in instead of local databases. Almost all of our applications achieve this already. This is the first step towards objective.
• All web-based applications must offer a consistent looking sign-in screen based on the current https://sso.lincoln.ac.uk design (which uses our Common Web Design[1]). This is the second step towards objective.
• All systems must implement web-based single sign on via OAuth, SAML or ADFS, using either the Microsoft Unified Access Gateway (UAG)[2] or the OAuth server, which will include the ‘SAML 2.0 Bearer Assertion Profiles for OAuth 2.0’ specification.[3]

This is a twelve-month project, largely undertaken by Alex Bilbie, a web developer working in the central ICT Online Services Team. The work consists of research, development and a fully documented implementation of OAuth 2.0 as part of an institutional Access and Identity Management solution. This will result in a Case Study and accompanying source code, which are our main deliverable. The Principal User on the project will be Dave Masterson, Head of Electronic Library Services, who has been charged with improving the usability of our Library’s online services. The Principal Investigator/Project Manager for the project will be Joss Winn, Senior Lecturer in CERD and coordinator of the LNCD group.[4] Tim Simmonds, Online Services Team Manager, will assume management and oversight of the technical implementation of both OAuth and UAG.

Dissemination will be both informal and formal. Community engagement will be on-going throughout the project using our project blog, Twitter accounts and Github (where the code is hosted). We have demonstrated in past projects that we maintain active project websites and use social media effectively. More formal dissemination will take place through the use of Press Releases, a public workshop and the case study.

Anticipated Impact

We believe this is a distinctive project that clearly builds on previous JISC-funded projects and further development at the University of Lincoln. It offers a number of benefits to project stakeholders:

Impact Area	Anticipated Impact Description
Students and academic staff	The Linkey project benefits students and staff by providing a consistent, user centric experience when signing in to services across the university. Furthermore, they will be able to clearly identify the applications they have approved, their permissions and the data that those applications have access to, offering greater oversight over personal data.
Technical staff	The Linkey project will consolidate the Access and Identity Management processes at the university into a single directory of users across all applications. It offers the opportunity for technical staff to focus on the research, development and implementation of a robust ‘consistent sign-on’ infrastructure. Research into OAuth, SAML and UAG, for example, will be documented and shared with others, benefitting from peer-review via the project blog, workshops, conferences and responses to the case study. Much will be learned during the course of the project.
The University of Lincoln	Improving Access and Identity Management is a strategic step towards improving the student and staff experience at Lincoln. Once implemented, it will allow the institution to respond more rapidly to changing expectations from our users and deploy a broader range of technologies more swiftly and consistently. By consolidating Access Management into two clearly delineated but joined methods (OAuth & UAG), we expect it to positively impact other processes, including the procurement of new applications, the security of data and remote working.
The University sector	The case study, conference paper and workshop, will benefit colleagues from the sector by providing a number of opportunities to learn about the use of OAuth at Lincoln and consider how it could benefit their own institutions. This body of knowledge will accompany open source server code that works ‘out of the box’ and can be re-used for implementation by other HEIs.
The Public	All project outputs will be publicly available for re-use, and all code from the Linkey project will be open source for use by other developers and organisations. To our knowledge (based on a question sent to the IETF OAuth mailing list), there are no existing open source implementations of the ‘SAML 2.0 Bearer Assertion Profiles for OAuth 2.0’, and our existing OAuth 2.0 server is the most complete open source solution written in PHP.

Stakeholder Analysis

Stakeholder	Interest/Stake	Importance
Staff and students	Improved User Experience; richer sharing of data between applications. Greater oversight of academic identity.	High
Technical staff	Consolidation of services; efficiencies gained through re-use of previous work. Provision of new infrastructure; personal and professional development of staff.	High
University of Lincoln	Consolidation of services; increased agility and more rapid deployment of new and more flexible services.	High
Other HEIs	A case study and workshop on the use of OAuth in a HEI. Opportunities for knowledge transfer. Re-use of open source OAuth server.	Medium
JISC	Value for money, in terms of re-use of previous JISC-funded work. Provision of open source code for re-use by the sector. Distinctive case studies and a well-documented project website. Showcase of innovative use of new technologies.	High
Public	Value for money, in terms of re-use of previous JISC-funded work. Provision of open source OAuth server for re-use.	Medium

Related Projects

This project has several related internal projects that are using OAuth for application authorisation, but there are no dependent projects. External to the University of Lincoln, we are not aware of any projects in the UK HE community that are actively implementing the OAuth 2.0 standard.

Constraints

Unified Access Gateway is a product that we currently have little-to-no experience with as an institution so extensive research and testing will be needed to undertaken to understand it’s potential and how it can be integrated into our environment and work-flows.

As there is no open source implementation (to our knowledge) of the OAuth Assertions extension our work will rely heavily on the OAuth standards community and other contributors to help ensure that our implementation correctly follows the specification.

Assumptions

We assume that the project is 12 months long and will be run as a close collaboration between the Centre for Educational Research and Development (where the Project Manager works), the Library (where the Senior User works) and the Online Services Team (where the Web Developer works). This has worked well for us in the past. We have made certain technical assumptions about the intended use of OAuth 2.0 and Microsoft UAG. We assume that we will receive support from colleagues outside the project team and have secured senior support for the project to help enable this.

Risk Analysis

Risk Description	Probability (P) 1 – 5 (1 = low  5 = high)	Severity (S) 1 – 5 (1 = low  5 = high)	Risk Score (PxS)	Detail of action to be taken (mitigation / reduction / transfer / acceptance)
Losing staff	1	4	4	Mitigation. Assign other staff to the role. Ensure transfer of knowledge to other staff throughout the project.
Intended approach (OAuth/UAG) is not viable.	2	3	6	Reduction. Spend first part of the project designing a solution with users. Speak to vendors and OAuth community.
Doesn’t pass user acceptance tests	3	2	6	Reduction. We take an agile approach and iterate our projects regularly, working closely with users.
Significant changes to the OAuth specification	1	2	2	Acceptance. The standard has been quite stable for some time. Any changes made to the standard should affect our project positively overall, providing any dependent technologies also reflect those changes.
Changes in requirements for overall AIM architecture	2	3	6	Acceptance. The intended approach is to combine Microsoft UAG and OAuth. The Linkey project can meet its objectives regardless of changes to the overall required architecture as this is a business driven project and the outcome will still be of value to the university and sector.

Technical Development

In the Total Recal project, we released version 1 of the OAuth 2.0 server code[5] but have learned a lot since that project through integrating OAuth with other services and through our API-driven approach to development.[6] Version 2 of our OAuth server[7] is more representative of our current implementation and fully implements the latest draft (28) of the specification. Our single sign-on (SSO) service at https://sso.lincoln.ac.uk[8] is the gateway to our current OAuth 2.0 implementation.

Most recently, the Orbital project has extended our OAuth 2.0 server to include some of the optional parts of the specification which had not been in use at Lincoln, such as refresh tokens[9] and using HTTP Authentication[10] with the client credentials flow.[11] This means that the server is now able to drop straight into a wider range of projects and services. However, many of our larger applications, such as WordPress, Exchange, Blackboard, HIP, EPrints and Sharepoint, remain disparate from one another, with no sharing of application data, except for that provided by the Active Directory.[12]

At the time of writing, the current institution-wide use of OAuth extends to Zendesk,[13] the Gateway,[14] the Staff Directory,[15] the Student Union website[16] and Posters@Lincoln.[17] Projects such as Jerome, and Orbital, as well as three 3rd year Computer Science student dissertation projects are using it, too. As stated above, our intention is to use OAuth alongside Microsoft’s Unified Access Gateway (UAG) using SAML as a bridge to OAuth via the ‘SAML 2.0 Bearer Assertion Profiles for OAuth 2.0’ specification. As such, we anticipate our implementation to look something like this:

 

For Lincoln, a combination of OAuth and UAG is the preferred route to achieving a user-centric and consistent sign in process across all applications, bridging both the internally facing business applications managed by ICT (e.g. Sharepoint, Exchange, Blackboard) and the more outward facing academic and social applications such as those developed and run by the Library and the Centre for Educational Research and Development (e.g. WordPress, EPrints).

Standards

Name of standard or specification	Version	Notes
OAuth	2.0
SAML	2.0
LDAP	3
PHP	5.3+
Micorsoft Forefront UAG	2010 (SP1)

Intellectual Property Rights

All project documentation, including the Case Study and blog, will be licensed under a CC-BY license. Code will continue to be licensed under an open source MIT license.

Project Resources

Project Management

This project is a mixture of research and development, largely undertaken by one person. At least half of Alex’s time will be spent undertaking research around the implementation, engaging with users and designing a solution to SSO. We hold weekly project meeting and require regularly blog posts to keep updated on this aspect of the work. Each of the team members works closely together and communication among us is easy and straightforward.

Development for the project will be run using the ‘Crystal Clear’ agile methodology, which we use on other development projects.[18] Crystal Clear is characterised by the following:

1. Seat people close together, communicating frequently and with goodwill.
2. Get most of the bureaucracy out of their way and let them design.
3. Get a real user directly involved.
4. Have a good automated regression test suite available.
5. Produce shippable functionality early and often.

Within this environment, we practice open development,[19] using Github as a source code repository[20] and Pivotal Tracker to iteratively manage project tasks.[21] We have recently implemented an automated regression test suite and employ ‘Continuous Integration’ using the Jenkins software.[22] Such an environment will support Alex on this project by ensuring that his code is available for peer-review by colleagues and publicly available for scrutiny. Code will be constantly tested by Jenkins for quality assurance and thereby provide working code for regular user testing. Alex will work closely with users in the Library and ICT to guide the development and implementation of the SSO service.

Project Roles

Team Member Name	Role	Contact Details	Days per week to be spent on the project
Joss Winn	Project Manager	jwinn@lincoln.ac.uk	0.25
Alex Bilbie	Web Developer	abilbie@lincoln.ac.uk	5.0
Tim Simmonds	Technical Manger	tsimmonds@lincoln.ac.uk	0.125
Dave Masterson	Senior User	dmasterson@lincoln.ac.uk	0.125

Alex Bilbie is a developer for the Online Services Team within ICT Services and a part-time undergraduate Computer Science student, finishing his final year. He has worked on the JISC-funded JISCPress, Total Recal, Jerome and Linking You projects. He developed the university’s Common Web Design and the university’s OAuth 2.0 server. He is a contributor to the CodeIgniter PHP framework and has also contributed to the HTML5 Boilerplate framework, WordPress and the OAuth 2.0 specification. Alex was invited to talk about OAuth at the Eduserv Federated Access Management conference, November 2011.

Dave Masterson: Head of Electronic Library Services. Dave has responsibility over all technical, electronic, systems, acquisitions and cataloguing services in the Library. Dave was recently charged with improving the user experience of library applications and will act as the Principal User on the Linkey project, co-ordinating other user engagement.

Tim Simmonds: Online Services Team Manager. Tim has worked for the university for over 20 years and is in charge of all online services managed by the ICT department. He will bring this experience to the project and represent ICT Services as a Stakeholder, overseeing the implementation of the UAG and OAuth implementations.

Joss Winn: Project Manager. Joss is a Senior Lecturer in the Centre for Educational Research and Development and has been Project Manager on a number of JISC-funded projects. He will manage the Project and report to JISC and other Stakeholders. Joss joined the University in 2007 to work on the implementation of the Institutional Repository and is Co-ordinator of the LNCD group, an institution-wide group focusing on technology for education.

Programme Support

Advice and guidance on running the workshop deliverable and other effective methods of dissemination.

Detailed Project Planning

3.1    Evaluation Plan

Timing	Factor to Evaluate	Questions to Address	Method(s)	Measure of Success
On-going	Production of case study	Is the document being drafted iteratively? Is it available for comment? Does it include a number of use cases? Does it cover the full scope of the project? Are efforts being made to engage users/the community in the drafting of the document?	Regularly drafts on blog. Announce drafts on mailing lists/social media. Review drafts at project meetings.	The case study is published with input from the JISC AIM community. A briefing paper can be produced from the executive summary.
On-going	Development of OAuth server	Is the server following changes to the OAuth spec? Is the server being developed openly? Are contributions from vendors and the AIM community being solicited? Is the server being designed so that it can be used by other institutions and companines? Does the sever pass QA checks? The work is appropriately documented for implementation by other developers.	Develop on Github public repository. Engage CodeIgniter and other PHP-based communities. Solicit collaboration on OAuth mailing list. Develop QA tests for Jenkins.	An up-to-date, generic, open source OAuth server for PHP is available from Github. It has been openly developed and received contributions from other interested developers and organisations. It is well documented.
May 2013	Workshop	Has the workshop been designed so that it is of greatest benefit to the community? Does the workshop involve both HEIs, developers and vendors? Are the outcomes of the workshop captured and, where appropriate, sustainable?	Develop workshop in consultation with JISC and the AIM community. Ensure that both academic and commercial networks are informed of the event. Have case study ready to hand out at workshop.	The workshop was well attended by people from both within and outside the HEI community. The case study was ready to provide to attendees. The workshop was well integrated with other JISC AIM events. The workshop led to further interest and possible collaboration between attendees.
Early 2013	Conference paper	Does the paper address the interests of its intended audience? Does the paper attempt to combine the interests of HEIs, vendors and developers? Is the conference selected so as to achieve maximum impact for the project? Can the paper be developed into a refereed journal paper? Does the paper reflect the work of the project well?	Identify suitable conferences within the first four months of the project. Consult JISC AIM community for related events. Solicit initial ‘peer review’ from JISC AIM community and Lincoln colleagues.	The paper was accepted and presented at a high profile conference and is suited to submission to a journal.
On-going	Development of expertise	Is the expertise gained being appropriately embedded and disseminated to other Lincoln colleagues? Is expertise being drawn from outside Lincoln and the JISC community e.g. private sector? Is the expertise being transferred/disseminated via the project blog and other events?	Ensure that other ICT staff are well informed of the project’s progress. Hold internal workshops for ICT staff to ensure they understand the findings of the project. Ensure that the project blog is regularly updated and appropriate mailing lists are kept informed of project progress.	Staff at Lincoln develop expertise in Access and Identity Management issues and the implementation of OAuth and UAG-based solutions. There are regular opportunities for knowledge transfer within ICT. The project blog is regularly updated. The case study and other documentation are both informative and useful.

3.2    Quality Assurance

Output / Outcome Name	Production of case study
When will QA be carried out?	Who will carry out the QA work?	What QA methods / measures will be used?
On-going	Project Manager/Web Developer	Draft Case Study on project blog over the course of the project. Make available for peer-review. Include as agenda point at weekly team meetings. Ensure that is uses jargon free language, is available in accessible formats. Final version has approval from project director.
Output / Outcome Name	Development of OAuth server
When will QA be carried out?	Who will carry out the QA work?	What QA methods / measures will be used?
On-going	Project Manager/Web Developer	The code meets recognised QA standards and passes build tests. The code is openly available for peer-review. The code is functional and in production use at Lincoln. The code is correctly licensed for re-use.

3.3    Communication and Dissemination Plan

Timing	Dissemination Activity	Audience	Purpose	Key Message
On-going	Blogging	Public/External and Internal Stakeholders/Project Team/Users	Provide regular updates and reflections on the Orbital project.	To offer general information about the progress of the project.
On-going	Public Project Management	Public/External and Internal Stakeholders/Project Team/Users	Offer a transparent view of the running of the project and its outputs at all stages of production. (i.e. source code via Github, task management via Pivotal Tracker).	We welcome peer-review and engagement at any time and recognise that we have much to learn from others.
On-going	User engagement	The Library and other university staff and students.	To ensure that our users remain at the core of the project and committed stakeholders. So as to receive useful and representative requirements for the project.	Users are at the heart of the project.
11/2012	Articles in Staff Magazine	University of Lincoln staff	To inform all staff at the university of Lincoln about the project and seek their feedback.	We are committed to improve access and identity management at the university.
On-going	Digital Infrastructure Programme networking	DI and AIM communities	To seek reciprocal peer-review and collaboration. The proposed use of OAuth is quite new to the HE sector and should provide a valuable case study for other institutions.	We are doing innovative work that could be of value to you.
12/2012 & 06/2013	Project reports	DI and AIM communities	To inform the community about the work we are doing and seek peer-review and opportunities for collaboration.	A summary of the project to-date.
04/2013	Conference/journal paper(s)	DI and AIM communities	To seek reciprocal peer-review and collaboration.	Our Research and Development is of scholarly interest and undertaken with rigour.
05/2013	Reflective video	DI and AIM communities, public	As a way to reflect informally on lessons learned.	“What we learned in a nutshell”
05/2013	Workshop	DI and AIM communities	To provide space and time for knowledge transfer inside and outside the sector.	We value your interest in the project and would like to help you.

3.4    Exit and Embedding Plans

Project Outputs/Outcomes	Action for Take-up & Embedding	Action for Exit
Production of case study	Draft case study on blog throughout project. Deliver final case study and briefing paper to JISC for community.	CC-BY licensed review, available from our Institutional Repository, linked to via our project website.
Development of OAuth server	On-going engagement with users and developers, both inside and outside the education sector, including vendors. Creation of Github project site to encourage re-use/forking and social engagement among developers.	Publish on Github, engage other open source projects that show an interest in it. Seek advice from Software Sustainability Institute. Provide consultancy to sector and business on AIM.
Workshop	Invitation to JISC community, vendors and key private companies to facilitate knowledge transfer and product awareness.	Publish outcomes of workshop.
Development of expertise	In-house knowledge transfer among key IT staff, good documentation, sharing of responsibilities around AIM among staff.	Ensure that the local developer skills to maintain and develop the AIM infrastructure are retained. Ensure that the benefits of AIM are clear to Snr. Management. Measure the impact of Linkey wherever possible.

3.5    Sustainability Plans

Project Outputs	Why Sustainable	Scenarios for Taking Forward	Issues to Address
Development of OAuth server	This will provide ‘drop in’ code for use by other institutions. Much has been learned in the process of developing the software that will be of relevance and use going forward.	Publish on Github, engage other open source projects that show an interest in it. Seek advice from Software Sustainability Institute. Provide consultancy to sector and business on AIM.	Ensure that the local developer skills to maintain and develop the AIM infrastructure are retained. Ensure that the benefits of AIM are clear to Snr. Management. Measure the impact of Linkey wherever possible.

Workpackages

JISC WORK PACKAGE

Month

1

2

3

4

5

6

7

8

9

10

11

12

Initiate project

X

Community Engagement

X

X

X

X

X

X

X

X

X

X

X

X

Gather user requirements

X

X

X

X

X

X

X

X

X

X

Evaluate available technologies and options

X

X

X

Design solution

X

X

Technical development and implementation

X

X

X

X

X

X

X

Documentation and Use Cases

X

X

X

X

X

X

X

X

X

X

Write Case Study

X

X

X

X

X

X

X

X

X

X

X

Write/submit conference paper

X

X

X

X

X

X

OAuth workshop

X

Close project

X

Project start date: 05/06/12

Project completion date: 04/6/13

Duration: 12 months

YEAR 1
WORKPACKAGE 1: Initiate project   Objective: Set up project, recruit staff
Complete project documentation		04/07/12	Project Plan, Workpackages, Budget, Web template		Joss
Set up project website		04/07/12	https://linkey.dev.lincoln.ac.uk		Joss/Alex
Recruit Web Developer		04/07/12	Full-time staff for project		Joss
WORKPACKAGE 2: Community Engagement   Objective: A mixture of dissemination, user-feedback and peer-review. This is on-going and multi-various
Set up meetings with users		04/07/12	Regular meetings with users with meeting notes posted on the blog		Alex
Start blogging		04/07/12	Regular blog posts on https://linkey.dev.lincoln.ac.uk		Alex
On-going face-to-face conversations with users		On-going	Regular meetings with users with meeting notes posted on the blog		Alex
Identify conference/journals to submit paper to		01/13			Joss/Alex
Run workshop at Lincoln		05/13			Joss/Alex/Tim
Measure impact of engagement		On-going	Blog posts, analytics, speaking invites, project enquiries, etc.		Alex
Announce project to OAuth community		04/07/12	Message on IETF mailing list, blog posts		Alex
Contact vendors		On-going	Establish relationships with key vendors and users of key technologies.		Alex/Tim
Engagement with open source community (codeigniter, PHP, OAuth)		On-going	Source code available on Github, blog posts and tutorials on blogs		Alex
WORKPACKAGE 3: Gather user requirements   Objective: To understand our users’ requirements and, with them, design an appropriate solution for AIM.
Gather user stories		On-going	Meetings with users		Alex
Assess current state of AIM		On-going	Review of current systems, video/document examples of what needs improving.		Alex
On-going face-to-face communication with users		On-going	Meetings with users		Alex
WORKPACKAGE 4: Evaluate available technologies and options.  Objective: To provide context to our project and ensure that the design of our solution meets best practice.
Research UAG		09/12	Blog posts documenting research		Alex/Tim
Research SAML		09/12	Blog posts documenting research		Alex/Tim
Research OAuth 2		09/12	Blog posts documenting research		Alex/Tim
WORKPACKAGE 5: Design solution   Objective:
Design OAuth 2 server library and framework integrations		10/12	A blog post and accompanying drawings and documentation.		Alex/Tim
Design improved authentication interfaces		10/12	A blog post and accompanying drawings and documentation.		Alex/Tim
WORKPACKAGE 6: Technical development and implementation   Objective:
Re-architect existing OAuth 2 server code		03/13	Open source code with documentation.		Alex/Tim
Implement bearer spec in OAuth 2 server code		03/13	Open source code with documentation.		Alex/Tim
Implement improved authentication interfaces		03/13	Open source code with documentation.		Alex/Tim
WORKPACKAGE 7: Documentation and user cases   Objective:
Document code		On-going	Inline code comments, developer documentation.		Alex
Document user case studies		On-going	Documented in blog posts and with code.		Alex
WORKPACKAGE 8: Write case study   Objective:
Draft blog posts		On-going	Blog posts		Alex
Draft case study		04/13	A draft document		Alex/Joss
Final case study		05/13	A final document.		Alex/Joss
WORKPACKAGE 9: Write/submit conference paper   Objective:
Identify paper topic		12/13			Alex/Joss
Identify conference		01/13			Alex/Joss
Complete/submit paper		05/13			Alex/Joss
WORKPACKAGE 10: OAuth workshop   Objective:
Plan workshop		01/13			Alex/Joss
Deliver workshop		05/13			Alex/Joss
WORKPACKAGE 11: Close project   Objective:
Submit final report and budget report		06/13	A final report and budget.		Joss
Publish Case Study		06/13	A case study		Joss
Ensure sustainability plans are in place		06/13			Joss

Members of Project Team:

Name	Role
Joss Winn	Project Manager
Alex Bilbie	Web Developer
Tim Simmonds	Technical Manager
Dave Masterson	Senior User