B6 Access management (SL)

The term “access” has a number of different senses, including access by users to the repository system—for example, physical security and user authentication), and the different stages of accessing records (making a request, verifing the rights of the requester, and preparing and sending a Dissemination Information Package (DIP). This section is concerned with all of these. It is divided into two main requirements: one concerned with the existence and implementation of access policies, and one with the capacity of the repository to provide demonstrably authentic objects as DIPs. Thus the first requirement relates to requests initiated by a user and how the repository handles them to ensure that rights and agreements are respected, that security is monitored, that requests are fulfilled, etc. The second requirement relates to what is delivered to the accessor of the repository and the trust that can be placed in it.

It must be understood that the capabilities and sophistication of the access system will vary depending on the repository’s designated community(ies) and the access mandates of the repository. Because of the variety of repositories, archives, and access mandates, these criteria may be subject to questions about applicability and interpretation at a local level. For in-depth discussion of access management issues, see Appendix 6: Understanding Digital Repositories & Access Functionality.

Repositories with a mandate to provide current access must be able to produce Dissemination Information Packages that meet the needs of their users or are appropriate to the levels of access they offer. “Dark” archives or national archives that may have mandates restricting access for a certain number of years will produce most DIPs for internal requirements, such as performing migrations, rather than for access. In any case, any repository must be able to produce a DIP, however primitive and whatever its purpose.

B6.1 Repository can demonstrate compliance with Access Policies.

Supporting Text

The repository must demonstrate that a complete access management system, with all access policies, is implemented. This is necessary in order to ensure the repository has fully addressed all aspects of usage which might effect the trustworthiness of the repository, particularly with reference to support of the user community.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Statements of policies that are available to the user communities; information about user capabilities (authentication matrices); logs and audit trails of access requests;explicit tests of some types of access.

Discussion

Depending on the nature of the repository, the Access Policies may cover:

  • Statements of what is accessible to which community, and on what conditions
  • Requirements for authentication and authorisation of accessors
  • Enforcement of agreements applivable to access conditions
  • Recording access actions

Access may be managed partly by computers and partly by humans—checking passports, for instance, before issuing a user ID and password may be an appropriate part of access management for some institutions.

B6.1.1 Repository logs all access management failures, and staff review inappropriate incidents.

Supporting Text

The repository must demonstrate that there is regular review of anomalous or unusual usage and access management failures. This is necessary in order to identify security threats and access management system failures.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Access logs, capability of the system to use automated analysis/monitoring tools and generate problem/error messages; notes of reviews undertaken or action taken as a result of reviews.

Discussion

A repository should have some automated mechanism to note anomalous or unusual denials and use them to identify either security threats or failures in the access management system, such as valid users being denied access. This does not mean looking at every denied access.

This requirement does not apply to repositories with unrestricted access.

B6.2 Repository follows policies that enable the dissemination of copies of that are traceable to the originals, with evidence supporting their authenticity.

The repository must demonstrate that it can trace in some auditable way the DIP it disseminates back to the original object(s). The trace must provide evidence of the authenticity of the DIP. This is necessary to ensure the DIP that is disseminated can be regarded as an authentic copy of the original object(s) (AIPs).

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; production of a sample copy with evidence of authenticity; documentation of community requirements for evidence of authenticity.

Discussion

Authenticity is not an “all or nothing” concept, but is a matter of degree, judged on the basis of evidence. Thus the adequacy of the evidence is of key importance in assessing this requirement.

It must also be remembered that objects are not always disseminated in the same way, or in the same groupings, as they are deposited. For example, a database, which originally had subsets of its rows, columns, and tables, may be disseminated without the original formatting, so that the phrase “authentic copy” has little meaning. Ingest and preservation actions may change the formats of files, or may group and split the original objects deposited. The degree of authenticity might also arise when transformation processes are applied. For instance, a repository that stores digital audio from radio broadcasts may disseminate derived text that is constructed by automated voice recognition from the digital audio stream. Derived text may be imperfect but useful to many users, but clearly has a lesser degree of authenticity than either delivering the original audio stream or getting a human to verify and correct the transcript against the stored audio.

This requirement ensures that ingest, preservation, and transformation actions do not lose information that would support an auditable trail of authenticity between the original deposited object and the eventual disseminated object.

For compliance, the chain of authenticity need only reach as far back as ingest, though some communities, such as those dealing with legal records, may require chains of authenticity that reach back further.

A repository should be able to demonstrate the processes to construct the DIP from the relevant AIP(s). This is a key part of establishing that DIPs reflect the content of AIPs, and hence of original material, in a trustworthy and consistent fashion. DIPs may simply be a copy of AIPs, or may result from a simple format transformation of an AIP. But in other cases, they may be derived in complex ways from a large set of AIPs. A user may request a DIP consisting of the title pages from all e-books published in a given period, for instance, which will require these to be extracted from many different AIPs. A repository that allows requests for such complex DIPs will need to put more effort into demonstrating how it meets this requirement than a repository that only allows requests for DIPs that correspond to an entire AIP.

A repository is not required to show that every DIP it provides can be verified as authentic at a later date; it must show that it can do this when it is required at the time of production of the DIP. The level of authenticity required is to be determined by the designated community(ies). This requirement is meant to enable demosntration of high levels of authenticity, not to impose it on all copies, since it may be an expensive process.

B6.2.1 Repository can demonstrate that any problem reports about errors in data or responses from users are recorded and acted on.

Supporting Text

The objective of access management is to ensure that user receives a usable and correct version of the digital object(s) (i.e., DIP) that they requested. A repository must show that any problems that do occur and are brought to its attention are investigated and acted on. This is necessary in order for the repository to be considered trustworthy.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; logs of orders and DIP production; documentation of error reports and the actions taken.

Discussion

This requirement is intended to cover the correctness of any transformations that may be applied to generate the DIP. A simple example is that if the repository stores TIFF images but delivers JPEGS, the users should receive that format, be able to read it and have it correspond to what they expect. In general it is difficult, if not impossible to prove that this is the case, so the ability to respond to error reports is essential.

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2009-03-30 - SimonLambert
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback