DocScan Upload from Archive with QR Code

[kahlep]

How can the original archive for an uploaded document coming from DocScan be verified?

1. Plain archive identifier: embedded in QR Code and known to Transkribus. Used to duplicate document to archive's collection.
   • Pros: easy to implement
   • Cons: easy to copy and reuse maliciously
2. One-time token: archive's Transkribus user account fetches one-time token on each QR code generation from Transkribus API. Embedded in QR code which then qualifies for a single upload and disables the token. Token may be set to exceed after a certain time when not used.
   • Pros: reliable assignment of uploads to an archive
   • Cons: QR codes are not reusable (i.e. printing and attaching it to an archival unit will not work)
3. One-time hash: generated from a secret password which is known to the archive and Transkribus. The hash is embedded in the QR code and Transkribus can check its authenticity against the password. Hash must be stored with document to mark it as already used.
   • Pros: reliable assignment of uploads to an archive, no API communication needed upon QR code generation
   • Cons: QR codes are not reusable (i.e. printing and attaching it to an archival unit will not work), cryptographic salt is appended to hash which allows a malicious user to retrieve the secret with some (serious?) effort and to generate new tokens.
4. Upload ID as one-time token: The archive system creates an upload process via Transkribus' API upon QR code generation and receives the upload ID which is used as one-time token. The upload functionality has to be extended to allow uploads without given doc. structure. Upload has to work in that case also for a user that has not created the upload process (as the archive's user did that)
   • Pros: Based on existing functionality and reliable assignment of uploads to an archive
   • Cons: codes are not reusable (i.e. printing and attaching it to an archival unit will not work)

[hackmanschorsch]

zu 4) ist es möglich, wenn wir das token abholen, daß damit auch gleich eine Adresse ausgeliefert wird, wo das image oder die images stehen? Wir wollen ja später auf die Bilder zeigen können. Wenn die Adresse gleich mit dem Token ausgeliefert würde, könnte Ariadne das fix übernehmen und wir sparen umständliche Nacharbeiten:

Das ließe sich mit ein paar Anpassungen über den Upload realisieren. Das Archiv würde einen upload über die REST API starten - d.h. die Metadaten könnten dann auch schon direkt an Transkribus geschickt werden - und bekommt die DocID zurück. Der QR Code müsste dann nur noch diese DocID beinhalten. Beim Upload aus der App wird das Dokument mit dieser DocID in der Greifswald - Collection gespeichert und kann somit leicht verlinkt werden. Auch ein link in das Web Interface ist mit der Collection ID/Doc ID leicht herzustellen.
Wir könnten diese Variante auch als Standardlösung machen. Die DocID wäre also der unique 'token' und die Metadaten würden dann direkt über die Rest API an Transkribus geschickt werden.
Dann wird es allerdings auch einige uploads geben, die zwar gestartet wurden, aber nie abgeschlossen. Das müssten wir dann bereinigen. Also z.B. nach 2 Wochen wird der gestartete upload gelöscht bzw. im Archiv wird es auch links zu Dokumenten geben, die nie fertig hochgeladen wurden. Das müsste dann wahrscheinlich über einen weiteren API call bereinigt werden?

[hackmanschorsch]

Kommentar Greifswald:
Wenn zu einer Akte mehrere Uploads stattfinden, würde es aus Ariadne-Sicht mehrere Links auf Transkribus geben, das wäre für uns gut umsetzbar.

An Metadaten wird aktuell folgendes mitgeschickt (im QR-Code) <title>Entwurf neuer Universitätsstatuten </title>Universitätsarchiv GreifswaldUniversitätsarchiv Greifswald/Altes Rektorat/01. Rechtliche Stellung der Universität - 01.01. Statuten/R 1199R 1199

Wäre es sinnvoll, hier auch den Rück-Link auf Ariadne einzufügen - https://ariadne-portal.uni-greifswald.de/?arc=1&type=obj&id=5162222 ?