...
- On ingest, or on-demand via REST request. Can store fixity events in repository.
- How does it extend to other checksum algorithms?
- SHA-1 supported because we get it "for free"
- How do we specify how to specify a checksum?
- Ingest- a header. On-demand, in POST
- For huge files (video files) there is no spec for finer-grained checksums
- In the EU, checksums and signatures are indicated in an XML format, checked by external tools. Not sure if it's XML signature spec per se, but it's expressed in XML.
- External tool can schedule re-checking of resourcces
- When changed, a new signature file needs to be generated.
- Will/should fixity generate events picked up by audit?
- Use case: Fixity against entire collections (trees of resources)
- Is there a method of fixity checking for external sources. Is there a standard, e.g. like s3 buckets, swift?
- Not aware of a standard, but maybe s3, swift indicate a defacto standard?
- Can we say in the spec that we expect an external application to include a certain header?
- Are external resources in the spec at all?
- There is a note, this will make it into the spec at some point
- Storing fixity of such resources seems to be reasonable for Fedora to do
- Some desire just to defer to external system
- .. but repository can't/shouldn't necessarily trust these external sources.
- Maybe it's possible to have user specify checksum when creating external resource, or have repository pull in the external source's notion of fixity.