Scenario 3: Updates to repository

Some repository access will involve changes to the content of the repository, for example:


 deposit of an object;

 editorial activities such as modification of an object’s metadata

 annotation of an object;

 administrative and maintenance activities.


The question arises: in such a case, is it important for repository managers to be able to determine who carried out the action at a later date? This would place requirements on the persistence of user identifiers, and on traceability of users. Typically, IdPs in the Federation are not required to keep records beyond six months, and eduPersonTargetedID may in any case be recycled. However, the need for detailed user-related provenance data may be an unusual case, the exception rather than the norm.


The following distinct cases were identified:


(a) In some situations there is a legal/regulatory requirement for tracking user-related provenance at the level of the individual over the long term, for example, when dealing with medical data. The question arises as to whether the federation level is the best approach to dealing with such cases. The medical case is probably beyond the current federation model because of the need to identify individuals; if the institution were liable for legal infringements, then it might be expected to keep records of who made changes to such data. On the other hand, in other cases it may be better to avoid “non-standard” mechanisms that circumvent the federation.


(b) In many cases in which the repository managers will not care exactly who took a particular action. It will be enough to know that the action taken was, when it took place, under the control of a trusted institution, and managed in a reliable way (for example, it is unlikely that anyone would want to track minor changes to metadata at this level). In addition, many of these changes will take place within an institution, and can be tracked by other mechanisms, outside FAM.


(c) However, there are cases in which a repository would want to track exactly who made changes to an object. One example is changes to a document that is being edited by several people – look at what Google Docs does, for example . Another is where objects are annotated during the research process; for various reasons it would be desirable to know who made particular annotations. For example, an annotation would be viewed differently if made by a professor than if made by a PhD student (although this particular example could be handled by using sufficiently fine-grained eduPersonScopedAffiliation).


Note: This Scenario is closely associated with issues of personal identity management – see Scenario 5 below.


Proposed actions:


It was agreed that JISC should concentrate on investigating cases (b) and (c), to determine real scenarios and their implications. Case (a) should be considered out of scope for the moment..


i) The scenario has two general implications for the federation: user anonymity and the (lack of) persistence for user IDs. The federation is amenable to accommodating persistent user IDs, and this scenario provides concrete use cases to support the inclusion of ID persistence in the federation rules (further such use cases arise in grid environments). However, there is a problem within the institutions, which say that they are unable to guarantee that IDs won’t be recycled. JISC needs to determine whether (and how) HE IdPs can be helped to address this issue.


ii) Carry out a detailed and systematic analysis of use cases, to identify those in which these issues (anonymity and persistence) are important, and to determine what IDs would need to be kept, how long they would need to be kept for, whether this is a necessity or a ‘nice to have’, whether users would be willing to reveal their identity, what the DPA implications are, and so forth. This is important as most repositories will have to address this eventually. At a later date, JISC will need to work with institutions on implementing these use cases.


iii) Develop a general vocabulary for expressing “active” access to repositories, that is doing things in repositories other than just search/browse/read access, with the aim of achieving consistency in expressing these actions as entitlements. There is a definite need for such a vocabulary.



3 votes
Idea No. 13