Project notes about '''Security Research Challenges for e-Science''' Document ''published'' by the UK e-Science Security Task Force (2005)
  * The Security Research Challenges for e-Science document (2005) has lots of implied requirements (general expectations). (This document has [End July 05] been published on the NeSC web site).
  '''''General Note''''': Doc. talks about AAA= Authentication, Authorisation and Accounting, but when it gets down to detail, the final A becomes “Auditing”.  This is probably deliberate, but could do with highlighting and explaining.

  '''''General Note''''': Doc. is about priority needs for further work, but this implies requirements.

  '''''General Note'''''/Requirement: [p3] “Authentication is the establishment ''and propagation'' of a user's identity in the system”.  This is presented as a definition!

  '''''Implied Requirement''''': Need to support different levels of “trust and responsibility” (and assurance levels).

  '''''Implied Requirement''''': Easy credential management by users (i.e./e.g. transporting their authentication credentials between applications and end-systems).

  '''''Implied Requirement''''': Support for Secure Roaming [overlaps with the above, really].

  '''''Implied Requirement''''': Management of authorisation policies and their distribution

  '''''Implied Requirement''''': Authorisation policies must allow for dynamic or short-term groups of users.

  '''''Implied Requirement''''': Need flexible dynamic delegation policies.

  '''''General Note'''''/Requirement: [p4] “Many e-Science and e-Health applications require fine grained access controls, perhaps administered through a number of different policy authorities and distributed decision points.

  '''''Implied Requirement''''': Privacy requirement for some applications during the authorisation process.

  '''''Implied Requirement''''': Auditing: need to be able to generate complete diagnostic trails.

  '''''Implied Requirement''''': Re. above – need to “allow some types of record (e.g. user accountability information) to be obtained securely from other parts of the system and interpreted in a common framework.

  '''''Implied Requirement''''': (Some applications) – Privacy of the data subject.

  '''''Implied Requirement''''': (Some applications) Confidentiality of data (i.e. who can access data at all).

  '''''Implied Requirement''''': Signalling of need for (a) privacy and (b) confidentiality when data are passed between systems.

  '''''Implied Requirement''''': Provenance of data (“maintaining the integrity of chains or groups of related data”) whilst in transit and in storage.

  '''''General Note''''': Trust relationships between organisations are needed for: standards for identifying and managing users, agreements about payments or other boundary settlements, limitations of use etc.

  '''''Implied Requirement''''': Policies and parameters that control security (both inside and outside the system) must be able to be changed flexibly and easily.

  '''''Implied Requirement''''': Mechanisms are required for the agreement and setting of assurance levels for a particular security policy or function.  These are needed in both directions (i.e. user to SP and SP to user).