...
- Review proposed requirements
- "Audit service MUST store logs separately or protected separately from the repository resources themselves": is this a valid requirement, or an implementation concern?
- Is it possible to fulfill these requirements via integration patterns and practices (without new code)?
- Review proposed queries
- Discuss implementation options
- Outstanding questions?
Minutes
Review proposed requirements
- Write/Import
- Audit service MUST automatically record who updated which resource when and with which action
- How do we determine the “who” in this scenario?
- e.g. Hydra/Islandora use a Fedora admin account rather than a particular user account
- Fedora has a mechanism for passing additional user principals into a request, so these could be used in “on behalf of” entries
- Audit service MUST be able to include/import events that were performed external to the repository.
- e.g. Fedora 3 audit logs, external services, past events, etc.
- Import format would be RDF
- Outputs of events (e.g. FITS XML) would be stored separately and referenced via URI.
- Need a minimum set of elements that need to be present on imported events
- Audit service MUST be able to purge events.
- If the use case is to limit the results of a query, this could be accomplished with a filter
- Audit service should keep a log of deleted resources, which is a separate issue
- For the purpose of a trustworthy repository, users should not be able to alter or delete audit history
- Audit service MUST store logs separately or protected separately from the repository resources themselves
- This is an issue for TRAC compliance
- Could be configurable - needs to allow administrators to store audit history in a separate location
- Audit service MUST import events with RDF triples drawn from the specified ontologies
- Audit service MUST ensure that all events minimally include the following information
- Event Agent
- Event Date/Time
- Event Activity
- Event Entity
- Read/Export
- Audit service MUST be RDF-based, and use PATCH semantics for updates
- We should not use PATCH to modify events - we should use POST to add new events
- This requirement will be removed
- Audit service MUST provide evidence of fixity checking on a "routine basis"
- Audit service should support fixity checking events, but not everyone will use fixity checks.
- Audit service MUST support dissemination of event/audit information
- Need to be able to query the service
- Audit service MUST be able to export full logs in RDF format
- Audit service MUST service queries that vary by:
- Single or all resources
- Date range
- Event type
- Agent
- Audit service MUST provide a single search endpoint for all repository resource-related events
- Audit service MUST provide a SPARQL-Query search endpoint
- This could be accomplished with an external triplestore
- Requirements define what the audit service should do
- Implementation is separate - the service may not be a core function of Fedora but a sidecar service that meets the requirements
- Need to move Fedora toward standards, limit custom code
Actions
- Everyone should review the current set of requirements
- If you have a requirement that is not listed, you should not expect it to be supported in the implementation