diff options
Diffstat (limited to 'doc/rfc/rfc7832.txt')
| -rw-r--r-- | doc/rfc/rfc7832.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc7832.txt b/doc/rfc/rfc7832.txt new file mode 100644 index 0000000..490697a --- /dev/null +++ b/doc/rfc/rfc7832.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Smith, Ed. +Request for Comments: 7832 Jisc +Category: Informational May 2016 +ISSN: 2070-1721 + + + Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases + +Abstract + + Federated identity is typically associated with web-based services at + present, but there is growing interest in its application in non-web- + based contexts. The goal of this memo is to document a selection of + the wide variety of these contexts whose user experience could be + improved through the use of technologies based on the Application + Bridging for Federated Access Beyond web (ABFAB) architecture and + specifications. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7832. + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Smith Informational [Page 1] + +RFC 7832 ABFAB Use Cases May 2016 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Context of Use Cases ............................................3 + 3. Use Cases .......................................................3 + 3.1. Cloud Services .............................................3 + 3.1.1. Cloud-Based Application Services ....................4 + 3.1.2. Cloud-Based Infrastructure Services .................5 + 3.2. High-Performance Computing .................................6 + 3.3. Grid Infrastructure ........................................6 + 3.4. Databases and Directories ..................................7 + 3.5. Media Streaming ............................................8 + 3.6. Printing ...................................................9 + 3.7. Accessing Applications from Devices on a Telecoms + Infrastructure .............................................9 + 3.8. Enhanced Security Services for S/MIME .....................10 + 3.9. Smart Objects .............................................11 + 4. Security Considerations ........................................11 + 5. References .....................................................12 + 5.1. Normative References ......................................12 + 5.2. Informative References ....................................12 + Acknowledgments ...................................................13 + Contributors ......................................................13 + Author's Address ..................................................13 + +1. Introduction + + Federated identity facilitates the controlled sharing of information + about people (a.k.a. "principals"), commonly across organizational + boundaries. This avoids redundant registration of principals who + operate in and across multiple domains, both reducing the + administrative overhead for the organizations involved and improving + the usability of systems for the principal. Simultaneously, it can + also help address privacy-related concerns, along with the regulatory + and statutory requirements of some jurisdictions. + + The information that is passed between organizations may include + authentication state and identity information that can be used for + many purposes, including making access management decisions. A + number of mechanisms support the transmission of this information for + web-based scenarios in particular (e.g., the Security Assertion + Markup Language (SAML) [OASIS.saml-profiles-2.0-os]), but there is + significant interest in the more general application of federated + identity to include non-web use cases. This document enumerates some + of these use cases, describing how technologies based on the ABFAB + architecture [RFC7831] and specifications could be used. + + + + + +Smith Informational [Page 2] + +RFC 7832 ABFAB Use Cases May 2016 + + +2. Context of Use Cases + + The use cases described in this document are a result of work led by + Jisc, the operator of the United Kingdom's education and research + network, responding to requirements from its community. These use + cases have also been augmented by various inputs from the IETF + community. + + The ABFAB architecture and specifications enables authentication and + authorization to occur across organizational boundaries. For many + applications, principals need not have pre-instantiated accounts that + their federated identity maps to before their first visit to that + application; the application can perform this process on the fly. In + cases where such accounts are required for particular applications, + the pre-provisioning process is out of scope; the ABFAB technology + assumes that any such requirements have already been fulfilled. + Standards-based work of note that would assist with this + pre-provisioning of accounts includes the standards and + specifications produced by the IETF SCIM working group. + +3. Use Cases + + This section describes some of the various potential use cases where + technologies based on the ABFAB architecture and specifications could + help improve the user experience; each includes a brief description + of how current technologies attempt to solve the use cases and how + this could be improved upon by ABFAB implementations. + +3.1. Cloud Services + + Cloud computing is emerging as a common way of provisioning + infrastructure services in an on-demand manner. These services are + typically offered as one of three models: + + o General infrastructure services such as computing power, networks, + storage, and utilities ("Infrastructure as a Service", or IaaS); + + o Software stacks or platforms such as database servers, web + servers, and application runtime environments ("Platform as a + Service", or PaaS); + + o Common application software such as email, shared storage, + business applications such as Customer Relationship Management + (CRM), or scientific applications ("Software as a Service", + or SaaS). + + + + + + +Smith Informational [Page 3] + +RFC 7832 ABFAB Use Cases May 2016 + + + In many cases, the provisioned cloud infrastructures and applications + need to be integrated with existing infrastructure of the + organization, and it is of course desirable if this could be achieved + in a way that allows business or scientific workflows to act across + infrastructure -- both across the cloud and in the local + infrastructure -- in as seamless a manner as possible. + + There are two main areas where federated access fits in cloud + computing: + + o Using federation to help mediate access to cloud-based application + services (e.g., cloud-provided email or CRM systems); + + o Using federation to help mediate access to the management of + cloud-based infrastructure services. + +3.1.1. Cloud-Based Application Services + + Many organizations are seeking to deliver services to their users + through the use of providers based in the "cloud". This is typically + motivated by a desire to avoid management and operation of commodity + services that, through economies of scale and so forth, can often be + delivered more efficiently by such providers. + + Many providers already provide web-based access using conventional + federated authentication mechanisms -- for example, outsourced email + provision where federated access is enabled using "webmail" + applications where access is mediated through the use of SAML + [OASIS.saml-profiles-2.0-os]. This use of federated authentication + enables organizations that consume cloud services to more efficiently + orchestrate the delivery of these services to their users and also + enables single sign-on to the services for these users. + + Frequently, however, users will prefer to use desktop applications + that do not use web (i.e., based on HTTP) protocols. For example, a + desktop email client may use a variety of non-web protocols, + including SMTP [RFC5321], IMAP [RFC3501], and the Post Office + Protocol (POP) [RFC1939]. Some cloud providers support access to + their services using non-web protocols; however, the authentication + mechanisms used by these protocols will typically require that the + provider has access to the user's credentials -- i.e., non-federated. + Consequently, the provider will require that users' credentials are + regularly synchronized from the user organization to the provider, + with the obvious overhead this imparts on the organization along with + the obvious implications for security and privacy, or else be + provisioned directly by the provider to the user. + + + + + +Smith Informational [Page 4] + +RFC 7832 ABFAB Use Cases May 2016 + + + The latter approach of directly provisioning accounts may be + acceptable in the case where an organization has relationships with + only a small number of providers, but this approach may become + untenable if an organization obtains services from many providers. + Consequently, any organization with a requirement to use non-web + protocols would prefer to make use of the credentials that they have + already provisioned their users with, and to utilize federated + authentication with non-web protocols to obtain access to cloud-based + providers. + + ABFAB could help in this context, as its specifications would enable + federated authentication for a variety of non-web protocols, thus + gaining the benefits of federated authentication without any of the + drawbacks that are currently experienced. + +3.1.2. Cloud-Based Infrastructure Services + + Typical IaaS or PaaS cloud use cases deal with provisioning on-demand + cloud-based infrastructure services that may include infrastructure + components such as computing and storage resources, network + infrastructure, and other utilities. Cloud-based virtualized + applications should ideally operate in the same way as regular + non-virtualized applications whilst allowing management of the + virtual computing resources (scaling, migration, reconfiguration) + without changing the management applications. + + In many cases, moving applications or platforms to the cloud may + require their redesigning/refactoring to support dynamic deployment + and configuration, including their security services, and + authentication and authorization services. These will typically + today be extensively based on manual setup and configuration of such + components and features as trusted certificates and trust anchors, + authorities and trusted services (both their location and + certificates), attribute namespaces, and policies. + + ABFAB could help in this context as a way of moving from the model of + manually configured authentication and authorization towards a more + easily managed system involving federated trust and identity, and + ABFAB will be applicable for a wide range of existing features (e.g., + connecting to a newly provisioned Virtual Machine through + ABFAB-enabled Secure Shell (SSH) [RFC4251] instead of having to + manually manage an administrative login to that machine). + + + + + + + + + +Smith Informational [Page 5] + +RFC 7832 ABFAB Use Cases May 2016 + + +3.2. High-Performance Computing + + High-Performance Computing (HPC) is a discipline that uses + supercomputers and computer clusters to solve complex computation + problems; it is most commonly associated with scientific research or + computational science. + + Access to HPC resources, often mediated through technologies such as + SSH, is typically managed through the use of user digital + certificates [RFC5280] or through manually provisioned credentials + and accounts. This requires HPC operators to issue certificates or + accounts to users using a registration process that often duplicates + identity management processes that already exist within most user + organizations. The HPC community would like to utilize federated + identity to perform both the user registration and authentication + functions required to use HPC resources, and so reduce costs by + avoiding this duplication of effort. + + The HPC community also have the following additional requirements: + + o Improve business continuity: In the event of operational issues at + an HPC system at one organization (for example, a power failure), + users and jobs could be transparently moved to other HPC systems + without the overhead of having to manage user credentials for + multiple organizations; + + o Establish "HPC as a service": Many organizations who have invested + in HPC systems want to make their systems easily available to + external customers. Federated authentication facilitates this by + enabling these customers to use their existing identity + management, user credentialing, and support processes; + + o Improve the user experience: Authentication to HPC systems is + normally performed using user digital certificates, which some + users find difficult to use. Federated authentication can provide + a better user experience by allowing the use of other types of + credentials, without requiring technical modifications to the HPC + system to support these. + + ABFAB could help in this context, as it could enable federated + authentication for many of the protocols and technologies currently + in use by HPC providers, such as SSH. + +3.3. Grid Infrastructure + + Grids are large-scale distributed infrastructures, consisting of many + loosely coupled, independently managed, and geographically + distributed resources managed by organizationally independent + + + +Smith Informational [Page 6] + +RFC 7832 ABFAB Use Cases May 2016 + + + providers. Users of grids utilize these resources using grid + middleware that allows them to submit and control computing jobs, + manipulate datasets, communicate with other users, etc. These users + are organized into Virtual Organizations (VOs); each VO represents a + group of people working collaboratively on a common project. VOs + facilitate both the management of their users and the meditation of + agreements between their users and resource providers. + + Authentication and authorization within most grids are performed + using a Public Key Infrastructure, requiring each user to have an + X.509 public-key certificate [RFC5280]. Authentication is performed + through ownership of a particular certificate, while authorization + decisions are made based on the user's identity (derived from their + X.509 certificate), membership of a particular VO, or additional + information assigned to a user by a VO. While efficient and + scalable, this approach has been found wanting in terms of usability + -- many users find certificates difficult to manage, for various + reasons. + + One approach to ameliorating this issue, adopted to some extent by + some grid communities already, is to abstract away direct access to + certificates from users, instead using alternative authentication + mechanisms and then converting the credential provided by these into + standard grid certificates. Some implementations of this idea use + existing federated authentication techniques. However, current + implementations of this approach suffer from a number of problems, + not the least of which is the inability to use the federated + credentials used to authenticate to a credential-conversion portal to + also directly authenticate to non-web resources such as SSH daemons. + + The ability to use federated authentication directly through ABFAB, + without the use of a credential-conversion service, would allow users + to authenticate to a grid and its associated services, allowing them + to directly launch and control computing jobs, all without having to + manage, or even see, an X.509 public-key certificate at any point in + the process. Authorization within the grid would still be performed + using VO membership as asserted by the user's Identity Provider (IdP) + through the federated transport. + +3.4. Databases and Directories + + Databases (e.g., MySQL, PostgreSQL, Oracle) and directory + technologies (e.g., OpenLDAP (http://www.openldap.org/), Microsoft + Active Directory, Novell eDirectory) are very commonly used within + many organizations for a variety of purposes. Such purposes can + include core administrative functions, such as hosting identity + information for its users, as well as business functions (e.g., + student records systems at educational organizations). + + + +Smith Informational [Page 7] + +RFC 7832 ABFAB Use Cases May 2016 + + + Access to such database and directory systems is usually provided for + internal users only; however, users external to the organizations + sometimes require access to these systems directly -- for example, + external examiners in educational organizations requiring access to + student records systems, members of cross-organizational project + teams who store information in a particular organization's systems, + and external auditors. + + Credentials for users either internal or external to the organization + that allow access to these databases and directories are usually + provisioned manually within an organization, either using identity + management technologies or through more manual processes. For the + internal users, this situation is fine -- this is one of the + mainstays of identity management. However, for external users who + require access, this represents more of a problem for organizational + processes. The organization has to either (1) add these external + users to its internal identity management systems or (2) provision + these credentials directly within the database/directory systems and + continue to manage them, including appropriate access controls + associated with each credential, for the lifetime of that credential. + + Federated authentication to databases or directories, via ABFAB + technologies, would improve upon this situation, as it would remove + the need to provision and de-provision credentials to access these + systems. Organizations may still wish to manually manage access + control of federated identities; however, even this could be provided + through federated means, if the trust relationship between + organizations was strong enough for the organization providing the + service to rely upon it for this purpose. + +3.5. Media Streaming + + Media streaming services (audio or audio/video) are often provided + publicly to anonymous users, but authentication is important for a + protected subset of streams where rights management and access + control must be applied. + + Streams can be delivered via protocols that already include + authentication, such as the Real Time Streaming Protocol (RTSP) + [RFC2326] or RTP [RFC3550], or can be published in an encrypted form + with keys only being distributed to trusted users. Federated + authentication is applicable to both of these cases. + + Alternative mechanisms to managing access exist -- for example, an + approach where a unique stream URI is minted for each user. However, + this relies on preserving the secrecy of the stream URI and also + requires a communication channel between the web page used for + authentication and the streaming service itself. Federated + + + +Smith Informational [Page 8] + +RFC 7832 ABFAB Use Cases May 2016 + + + authentication would be a better fit for this kind of access control. + Thus, ABFAB technologies that allow federated authentication directly + within (inherently non-web) media streaming protocols would represent + an enhancement to this area. + +3.6. Printing + + A visitor from one organization to the premises of another often + requires the use of print services. Their home organization may of + course offer printing, but the output could be a long way away, so + the home service is not useful. The user will typically want to + print from within a desktop or mobile application. + + Where this service is currently offered, it would usually be achieved + through the use of "open" printers (i.e., printers that allow + anonymous print requests), where printer availability is advertised + through the use of Bonjour or other similar protocols. If the + organization requires authenticated print requests (usually for + accounting purposes), the visitor would usually have to be given + credentials that allow this, often supplemented with pay-as-you-go + style payment systems. + + Adding federated authentication to the Internet Printing Protocol + (IPP) [RFC2911] (and other relevant protocols) would enable this kind + of remote printing service without the administrative overhead of + credentialing these visitors (who, of course, may well be one-time + visitors to the organization). This would be immediately applicable + to higher education, where this use case is increasingly important + thanks to the success of federated network authentication systems + such as eduroam (https://www.eduroam.org), but could also be used in + other contexts such as commercial print kiosks, or in large + heterogeneous organizations. + +3.7. Accessing Applications from Devices on a Telecoms Infrastructure + + Telecom operators typically have the following properties: + + o A large collection of registered users, many of whom may have + identities registered to a fairly high level of assurance (often + for payment purposes). However, not all users will have this + property -- for example, non-contract customers on mobile telecoms + infrastructures in countries with low levels of identity + registration requirements. + + o An existing network infrastructure capable of authenticating a + device (e.g., a cellphone or an Asymmetric Digital Subscriber Line + (ADSL) router) and, by inference, its owner. + + + + +Smith Informational [Page 9] + +RFC 7832 ABFAB Use Cases May 2016 + + + o A large collection of applications (both web-based and + non-web-based) that its users wish to access using their devices. + These applications could be hosted by the telecom operator + directly, or they could be any application or system on the + internet -- for example, network messaging services, VoIP, + or email. + + At present, authentication to these applications will be typically + configured manually by the user on the device (or on a different + device connected to that device) by inputting their (usually + pre-provisioned out of band) credentials for that application -- one + per application. + + The use of ABFAB technologies in this case, via a mechanism dubbed + "federated cross-layer access" (see [FCLA]) would greatly enhance the + user experience of using these applications through devices. + Federated cross-layer access would make use of the initial mutual + authentication between device and network, to allow subsequent + authentication and authorization to happen in a seamless manner for + the user of that device authenticating to applications. + +3.8. Enhanced Security Services for S/MIME + + There are many situations where organizations want to protect + information with robust access control, either for implementation of + intellectual property right protections, for enforcement of + contractual confidentiality agreements, or because of legal + regulations. The Enhanced Security Services (ESS) for S/MIME defines + an access control mechanism that is enforced by the recipient's + client after decryption of the message (see [MSG-AC-REQ]). The data + model used makes use of Policy Decision Points (PDPs), which make the + policy decisions; Policy Enforcement Points (PEPs), which make + decision requests to the PDP; and Policy Information Points (PIPs), + which issue attributes about subjects. The decisions themselves are + based on the policies and on the subject attributes. + + The use of ABFAB technologies in this case would enable both the + front-end and back-end attribute exchange required to provide subject + attributes. When the PEP contacts the PDP, it would initiate an + ABFAB authentication in order to authenticate to the PDP and allow it + to obtain these required subject attributes. Once authenticated, the + PDP would return a token to the subject PEP that could then be used + for subsequent authentications to the PDP. + + + + + + + + +Smith Informational [Page 10] + +RFC 7832 ABFAB Use Cases May 2016 + + +3.9. Smart Objects + + Many smart device deployments involve multiple organizations that do + not directly share security infrastructure. For example, in smart + power deployments, devices (e.g., appliances) and infrastructure + (e.g., electric car chargers) will wish to connect to an energy + management system. The energy management system is provided by a + utility company in some deployments. The utility company may wish to + grant access only to authorized devices; for example, a consortium of + utility companies and device manufacturers may certify devices to + connect to power networks. + + In another example, consumer devices may be used to access cloud + services. For example, a camera could be bound to a photo processing + site. Authentication and authorization for uploading pictures or + ordering prints are required. Sensors could be used to provide data + to services run by organizations other than the sensor manufacturer. + Authorization and authentication can become very tricky when sensors + have no user interface. Cellular devices may want to access services + provided by a third party, regardless of whether the cellular network + or Wi-Fi is used. This becomes difficult when authorization and + billing are coordinated by the cellular provider. + + The use of ABFAB technologies in this case would provide + authentication between one entity, such as a smart device, and its + IdP. Only two parties are involved in this exchange; this means that + the smart device need not participate in any complicated public-key + infrastructure even if it is authenticating against many cloud + services. Instead, the device can delegate the process of + authenticating the service, and even deciding whether the device + should be permitted to access the service, to the IdP. This has + several advantages. A wide variety of revenue-sharing models are + enabled. Because device authentication is only with a single IdP, + phishing of device credentials can be avoided. Authorization and + decisions about what personal information to release are made by the + IdP. The device owner can use a rich interface such as a website to + configure authorization and privacy policy even if the device has no + user interface. This model works well with pre-provisioning of + device credentials. + +4. Security Considerations + + This document contains only use cases and defines no protocol + operations for ABFAB. Security considerations for the ABFAB + architecture are documented in [RFC7831], and security considerations + for ABFAB technologies and protocols that are discussed in these use + cases are documented in the corresponding protocol specifications. + + + + +Smith Informational [Page 11] + +RFC 7832 ABFAB Use Cases May 2016 + + +5. References + +5.1. Normative References + + [RFC7831] Howlett, J., Hartman, S., Tschofenig, H., and J. Schaad, + "Application Bridging for Federated Access Beyond Web + (ABFAB) Architecture", RFC 7831, DOI 10.17487/RFC7831, + May 2016, <http://www.rfc-editor.org/info/rfc7831>. + +5.2. Informative References + + [FCLA] Wei, Y., Ed., "Federated Cross-Layer Access", Work in + Progress, draft-wei-abfab-fcla-02, March 2012. + + [MSG-AC-REQ] + Freeman, T., Schaad, J., and P. Patterson, "Requirements + for Message Access Control", Work in Progress, + draft-freeman-plasma-requirements-11, March 2015. + + [OASIS.saml-profiles-2.0-os] + Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, + P., Philpott, R., and E. Maler, "Profiles for the OASIS + Security Assertion Markup Language (SAML) V2.0", OASIS + Standard OASIS.saml-profiles-2.0-os, March 2005, + <http://docs.oasis-open.org/security/saml/v2.0/ + saml-profiles-2.0-os.pdf>. + + [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", + STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, + <http://www.rfc-editor.org/info/rfc1939>. + + [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time + Streaming Protocol (RTSP)", RFC 2326, + DOI 10.17487/RFC2326, April 1998, + <http://www.rfc-editor.org/info/rfc2326>. + + [RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., + and P. Powell, "Internet Printing Protocol/1.1: Model and + Semantics", RFC 2911, DOI 10.17487/RFC2911, + September 2000, <http://www.rfc-editor.org/info/rfc2911>. + + [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - + VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, + March 2003, <http://www.rfc-editor.org/info/rfc3501>. + + + + + + + +Smith Informational [Page 12] + +RFC 7832 ABFAB Use Cases May 2016 + + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, <http://www.rfc-editor.org/info/rfc3550>. + + [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) + Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, + January 2006, <http://www.rfc-editor.org/info/rfc4251>. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + <http://www.rfc-editor.org/info/rfc5280>. + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + DOI 10.17487/RFC5321, October 2008, + <http://www.rfc-editor.org/info/rfc5321>. + +Acknowledgments + + These use cases have been developed and documented using significant + input from Jens Jensen (STFC Rutherford Appleton Laboratory), Daniel + Kouril (CESNET), Michal Prochazka (CESNET), Ian Stewart (University + of Edinburgh), Stephen Booth (Edinburgh Parallel Computing Centre), + Eefje van der Harst (SURFnet), Joost van Dijk (SURFnet), Robin + Breathe (Oxford Brookes University), Yinxing Wei (ZTE Corporation), + Trevor Freeman (Microsoft Corporation), Sam Hartman (Painless + Security, LLC), and Yuri Demchenko (University of Amsterdam). + +Contributors + + The following individuals made important contributions to the text of + this document: Tim Bannister (Manchester University), Simon Cooper + (Jisc), Josh Howlett (Jisc), and Mark Tysom (Jisc). + +Author's Address + + Dr. Rhys Smith (editor) + Jisc + Lumen House, Library Avenue, Harwell + Oxford OX11 0SG + United Kingdom + + Phone: +44 1235 822145 + Email: rhys.smith@jisc.ac.uk + + + + + +Smith Informational [Page 13] + |