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:
- Lớp V7GUID
GCSIG, lược đồgcsig-1.4. Từ 1.4, GCSIG có thể nhúng nội dung Ur-Doc (content, ví dụbusiness-meal-receipt-1.0cho một hóa đơn tiếp khách), nguồn gốc OCR (ocr, TrustVector-BitVector), khối chữ ký (signature, có Facsimile) và một khối Sidecar tích hợp (source) — nhờ đó, đối với chứng từ đã ký, nó thay thế.gc.mdriêng (xem bên dưới). 1.3/1.2/1.1/1.0 vẫn là các lược đồ legacy hợp lệ. - Vùng chứa pha có thể thay đổi (như GCPN): Vòng đời chữ ký được quản lý dưới dạng 32-bit-Phasen-BitVector; các thay đổi trạng thái là các thao tác bit đơn giản.
- Neo nội dung:
subject.sha= SHA-256 của Ur-Doc. Do đó, tạo tác được gắn với phiên bản cụ thể và bền vững trước việc viết lại lịch sử. - Có thể tồn tại ngay trong bản nháp (pha
draft);signer/gpgchỉ được đặt khi ký.
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:
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),docUidvà siêu dữ liệu và vòng đời chữ ký trong một tạo tác. Một.gc.mdriêng là không bắt buộc cho việc này.Bước chuyển
.gc.md→.gcsig.md(PDF đã ký). Khi một PDF (hoặc tương tự) được ký,.gc.mdmang 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)
- Mỗi Ur-Doc được dự định ký đều được tạo một
*.gcsig.mdngay 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. - 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. - Trạng thái/sự kiện sống trong tạo tác chữ ký và/hoặc GCPN.
- Một
*.gcsig.mdtừ 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. - 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
- Phần I — Textform — Ur-Doc, Sidecar, Signatur-Doc, GCPN.
- Phần II — FES & Facsimile — Ghép nối FES, lớp Facsimile.
- Phần IV — PII, GPG & Governikus — Cấp khóa.
- Công cụ và lược đồ:
work/OSS/gc-docsign(docs/gcsig.md), lược đồgcsig-1.4(OSS-Normative-Root.gitcover/schemas/).
Đã tạo: 261008 | Nhà phát hành: ORG-1 (Trình giữ chỗ) | Sê-ri: digital-signage