Phần VI — Tài liệu được ký bằng Git: tạo tác chữ ký (GCSIG)

Điểm kích hoạt S6: Một hợp đồng sẽ được ký theo cách Git-native. Nhưng ngay trước khi ký phải có thể truy vết được tài liệu đã được hiển thị cho ai, khi nào được chấp thuận và khi nào được ký. Điều đó được ghi lại ở đâu nếu bản thân Ur-Doc phải giữ nguyên không thể thay đổi?

Vấn đề: sự kiện cần một nơi

Các Phần I–III cho thấy một tài liệu (Ur-Doc), siêu dữ liệu của nó (Sidecar), các Signatur-Doc/Sự kiện của nó và quy trình (GCPN) phối hợp với nhau như thế nào. Tuy nhiên, vẫn còn một điểm nhức nhối chưa được giải quyết: Các sự kiện của một tài liệu riêng lẻ — hiển thị (presented), chấp thuận (accepted), ký (signed) — cần một nơi riêng cho từng tài liệu, và ngay từ bản nháp.

Bản thân Ur-Doc không được mang nơi này. Nó — một khi đã được ký — là bất biến: Mọi thay đổi sau đó (kể cả một cờ trạng thái đơn thuần) đều thay đổi SHA-256 của nó và do đó làm vô hiệu hóa một chữ ký đã thực hiện. Ngay cả bản nháp cũng có thể là phiên bản cuối cùng; vì vậy không trạng thái, không lịch sử, không ghi chú quy trình nào thuộc về Ur-Doc.

Giải pháp: một tạo tác chữ ký cho mỗi tài liệu (*.gcsig.md)

Mỗi Ur-Doc .md được dự định ký đều có ngay từ bản nháp một tạo tác chữ ký {name}.gcsig.md:

Tạo (công cụ gc-docsign):

gc-docsign gcsig --doc "<ur-doc.md>"            # ab Entwurf, Phase draft
gc-docsign gcsig --doc "<ur-doc.md>" --phase presented
gc-docsign gcsig --doc "<ur-doc.md>" --phase accepted
gc-docsign gcsig --doc "<ur-doc.md>" --phase signed --key <fingerprint>

BitVector pha

Pha Bit Giá trị Ý nghĩa
draft 0 1 Bản nháp (điểm xuất phát)
presented 1 2 được trình để ký / được hiển thị
accepted 2 4 được chấp nhận / được phê duyệt
signed 3 8 đã ký
denied 4 16 bị từ chối
withdrawn 5 32 đã rút lại
revoked 6 64 đã thu hồi
expired 7 128 đã hết hạn
superseded 8 256 đã được thay thế
verified 9 512 xác minh thành công (bổ nghĩa trực giao)

Các bit tích lũy bằng OR trong phases.phases_result; current_phase được suy ra theo thứ tự ưu tiên (revoked > superseded > … > draft). verified là một bổ nghĩa trực giao (không phải bước riêng của vòng đời). Ngữ nghĩa cờ này tương ứng với yêu cầu „Sự kiện dưới dạng BitVector“ (không phải kiểu union, vì có tính tích lũy).

Khối chữ ký trong Ur-Doc

Ur-Doc vẫn bất biến, nhưng sau khối chữ ký nhận một phần giải thích ## Signatur (GCSIG), phần này nêu tên tạo tác chữ ký tương ứng:

## Signatur (GCSIG)

Diese Vereinbarung ist für **GC-Signatur** erstellt. …

- **Signatur-Artefakt (GCSIG):** `<uuidV7>`      ← der „Name" (docUid)
- **Titel:** `<basename>.gcsig.md`               ← Dateiname
- **Verfahren:** Textform (§ 126b BGB) mit Facsimile; GC-Signatur (GPG / signierter Git-Commit)
- **Zeichner:** <Name> (Rolle)

uuidV7 (= docUid của GCSIG) được suy ra không tạo vòng lặp từ danh tính chủ thể (tên cơ sở tài liệu/ID hợp đồng) — không từ SHA của tài liệu này —, để nó có thể xuất hiện trong Ur-Doc mà không làm cho neo chữ ký trở nên bất ổn định. Một tham chiếu chỉ bằng tên tệp là có thể; nhưng uuidV7 được trích dẫn làm cho tạo tác có thể nhận diện theo tên và — vì dựa trên danh tính thay vì nội dung — ổn định. Trạng thái, quy trình và sự kiện chỉ nằm duy nhất trong tạo tác chữ ký và/hoặc GCPN.

Phân biệt với các tạo tác lân cận

Tạo tác Vai trò Tính thay đổi
Ur-Doc ({name}.md) Tài liệu nguồn với văn bản hợp đồng + Facsimile bất biến từ khi ký
Ur-Doc-Sidecar ({name}.md.gc.md) Siêu dữ liệu; SHA-256 = SSoT có thể thay đổi
Tạo tác chữ ký ({name}.gcsig.md) Vòng đời chữ ký cho mỗi tài liệu, từ bản nháp có thể thay đổi (vùng chứa pha)
GCPN ({name}.gcpn.md) Quy trình/hồ sơ; parents[]/children[] có thể thay đổi
GCSIG (Commit) ({abbrev}.gcsig.md) Git-Commit được GPG ký bất biến

GCSIG với vai trò Sidecar — và bước chuyển .gc.md → .gcsig.md

Tạo tác chữ ký không phải là một tài liệu phụ đơn thuần. Cần phân biệt hai trường hợp:

  1. Chức năng Sidecar (Ur-Doc MD gốc). Nếu Ur-Doc đã ký tồn tại nguyên bản dưới dạng Markdown — không phải bản scan, không phải PDF, không phải ảnh — thì *.gcsig.md đồng thời có thể đóng vai trò Sidecar: Khi đó nó mang (như một .gc.md) neo nội dung (SHA-256), docUid và siêu dữ liệu và vòng đời chữ ký trong một tạo tác. Một .gc.md riêng là không bắt buộc cho việc này.

  2. Bước chuyển .gc.md → .gcsig.md (PDF đã ký). Khi một PDF (hoặc tương tự) được ký, .gc.md mang tính lập danh mục có thể chuyển thành một .gcsig.md. Trong quá trình đó không có thông tin nào bị mất — nội dung Sidecar (neo, docUid, lớp, siêu dữ liệu) được chuyển giao vào tạo tác chữ ký. Nhưng trạng thái của Ur-Doc và mục đích sử dụng của nó thay đổi: Từ một chứng từ chỉ được lập danh mục trở thành một Ur-Doc đã ký với vòng đời chữ ký riêng (Phasen-BitVector). Không được có các Sidecar cạnh tranh tồn tại song song — nội dung được chuyển giao, không bị nhân bản.

Tóm lại: GCSIG là một nơi duy nhất nơi chữ ký của tài liệu này tồn tại — dù là tạo tác chữ ký thuần túy, ở vai trò Sidecar hay là kế thừa của một .gc.md.

Tạo tác chữ ký được GCPN tham chiếu thông qua cạnh tree (GCSIG:{docUid}); ngược lại, nó nêu quy trình của mình qua gcpn_ref. Đối với đối tượng Git (commit/tree/tag/PR), ngược lại, GCSIG vẫn là một tạo tác bất biến (gc-docsign gcsig <repo> --commit <sha>).

Quy tắc (quy phạm)

  1. Mỗi Ur-Doc được dự định ký đều được tạo một *.gcsig.md ngay từ bản nháp (lược đồ gcsig-1.4); nếu không có tạo tác này thì không thể ghi nhận các sự kiện.
  2. Ur-Doc vẫn bất biến: không trạng thái, không thông tin quy trình/lịch sử/ hash tự thân; chỉ khối ## Signatur (GCSIG) với tham chiếu tên tệp.
  3. Trạng thái/sự kiện sống trong tạo tác chữ ký và/hoặc GCPN.
  4. Một *.gcsig.md từ một gc-Signatur (chữ ký commit) là một Ur-Doc bất biến; ngược lại, tạo tác theo từng tài liệu (document) là một vùng chứa pha có thể thay đổi.
  5. Với Ur-Doc MD gốc, *.gcsig.md đồng thời có thể là Sidecar (siêu dữ liệu + vòng đời trong một tạo tác). Với PDF đã ký, .gc.md được phép chuyển thành một .gcsig.md — không mất thông tin (chuyển giao nội dung), nhưng trạng thái/mục đích sử dụng của Ur-Doc thay đổi; không có các Sidecar cạnh tranh.

Tham chiếu chéo


Đã tạo: 261008 | Nhà phát hành: ORG-1 (Trình giữ chỗ) | Sê-ri: digital-signage