0017 장부 칸 보충: 봉인 지문 항목별, 공개 줄, 저장고로 옮김, 사전 교정, 보낸 기록 묶기

hgp 이슈 둘에 답한다. A는 provenance가 결정 0016 뒤에 보낸 것(이슈 #3), B는 secretary가 장부를 03-manifest에 맞추다가 보낸 것(이슈 #2)이다. 0016의 parent 칸과 소금 문장을 대신한다.

무엇을

A. 제품 이력 (이슈 #3)

1. 봉인 지문을 항목별로

• 비공개 항목(근거 원본 파일 하나, 값 하나)마다 소금(무작위 32바이트)을 따로 둔다.
• 항목 지문 = SHA-256(소금 ‖ RFC 8785로 적은 항목). 항목 모양은 둘이다: 파일 {"type":"file","sha256":"…"}, 값 {"type":"value","name":"…","value":…,"unit":"…"}.
• 항목 지문들을 02-지문 5절(RFC 6962) 그대로 묶은 뿌리가 사건 기록의 sealed다. 항목 지문이 원본 지문 자리에 들어간다 (잎 = SHA-256(0x00 ‖ 항목 지문)). 차례는 비공개 기록에 적은 항목 차례다. 항목 수는 sealed_count.
• 이렇게 하면 항목 하나만 열 수 있다. 그 항목과 소금과 포함 증명만 내면 되고, 나머지는 계속 닫혀 있다.
• 항목 수는 드러난다. 제품 이력에서는 괜찮다고 본다.

2. 공개 줄

• 봉인한 항목 하나를 여는 것은 범위를 넓히는 일이다. 장부에는 event: "scope_changed" 줄로 적는다. 화면 말과 provenance 안의 이름은 「공개 줄」(disclosure)로 써도 된다.
• 담는 칸: of(그 사건 기록의 id), item(항목), salt(소금), leaf(잎 자리 번호, 0부터), proof(포함 증명), sealed(뿌리), decided_by(누가, 어느 자격으로, 언제).
• decided_by는 confirmed_by와 같은 모양이다: {"who","as","at"}. as는 depositor만 된다. 무리면 대표 자리다 (07-기탁 2·6절). 기탁자 자리 대신은 열지 못한다 (결정 0011).
• 공개 줄도 등록부 줄로 올린다. refUID는 그 사건의 등록부 줄이다.

3. 칸 이름

• parent → parents (목록, 0번이 주 부모). 담금 둘을 섞는 일(blend) 때문이다. refUID는 prev, 없으면 parents[0]. 공개가 아닌 사건은 체인에 없으므로, refUID는 거슬러 올라가 가장 가까운 공개 기록을 가리킨다.
• event_kind: blend(섞음)를 더하고, transfer는 custody_transfer(맡은 곳이 바뀜)로 바꾼다.
• tokenized는 넣지 않는다. 뜻과 쓰임이 정해지지 않은 이름을 미리 잡아 두지 않는다. 토큰은 파일럿 밖의 일이다 (provenance 설계 10절).
• 등록부 줄의 철회 표시를 정정에도 쓴다. 옛 기록은 06-관계망의 「물림」과 같다. 화면은 새 기록이 replaces로 가리키면 「정정됨」, 아니면 「거둠」.

4. 업종 설정

• hgp는 칸 이름과 모양만 정한다. 대상 종류와 event_kind 값, 근거 원본의 기본 범위는 업종 설정이 정한다. 0016 2번 표와 06-관계망 5절의 제품 이력 값은 「전통주 설정」의 예다.
• 업종 설정 파일도 공개 주소에 판 번호를 달아 낸다. 한 번 낸 판은 고치지 않는다 (08-이름표 1절과 같은 규칙). 기록에는 어느 설정을 따랐는지 profile(설정 파일 주소)로 적는다. 그래야 다른 사람이 값의 뜻을 읽는다.

5. 텔레그램 예외 (결정 0010) · 노드원 대표 승인

provenance 요청: 양조장 대표, 대학, 노드원이 한 텔레그램 방에 사진을 「파일」로 올리는 길. 원본이 바깥 회사 서버를 잠그지 않은 채 지난다. 0010(「바깥 회사에는 잠근 채로」)의 예외다.

• 공개할 제품 이력 사진에 한해서만. 비공개로 둘 사진은 Syncthing(기기끼리 직접 주고받는 프로그램)으로.
• 「파일」로 보낸다. 사진으로 보내면 텔레그램이 다시 압축해 원본이 아니다.
• 사람을 알아볼 수 있는 사진은 그 사람의 동의를 받은 뒤에만 이 길로 보낸다 (0016 3번). 동의 전에는 Syncthing으로.
• 원본 지문은 받은 파일에서 뜬다. 보낸 기기에서 지문을 뜨지 못했으므로 sha256_device는 null이다. 기록에 via(거쳐 온 곳)를 적는다: ["telegram"].
• 공개를 그만두면 텔레그램에 올린 사본을 지운다. 지워도 회사 서버에 남았을 수 있다는 것을 거둔 줄에 적는다.
• 확인 단추를 확인 도장으로 칠 수 있다 (결정 0006). 조건: 누른 사람이 그 기록에 권한을 받은 사람이고(양조장 대표 자리, 대표가 정한 수정자), 텔레그램 계정과 사람 번호를 미리 이어 두었고, 봇이 대신 누르지 않는다. 도장에 via: "telegram"을 적는다. 누가 눌렀는지를 텔레그램 계정에 기대므로, 약속으로 막는 것임을 적는다 (01-권한 1절 4번).

6. 공개 메모와 기록 공백

• 공개 메모는 기록 안의 note다 (06-관계망 4.1절의 메모). 기록이 공개면 메모도 공개다.
• 기록 공백(「이 사이에는 기록이 없다」)은 사건이 아니다. provenance Phase 3 전에 정한다. 지금 생각은 대상에 대한 주장(prop: "no_record", when에 빈 구간)이고, 근거는 공백을 선언한 사람의 메모 기록이다 (06-관계망 1절 3번).

7. 0016 바로잡기

• 「머클은 RFC 6962 (정렬, 마지막 복사 빼기)」는 「정렬과 마지막 복사를 뺀다」는 뜻이다. 0016에 바로잡음을 단다.
• 0016 3번의 rights.basis: "agreement"는 03-manifest의 값 이름표대로 "contract"다.

B. secretary (이슈 #2)

1. 원본을 저장고로 옮긴 줄은 received를 한 번 더 쓴다

새 사건 이름을 만들지 않는다. arkive가 받아 지문을 맞췄으면 그것이 「저장소가 받았고 지문이 맞았다」(received, PREMIS ingestion)다. 그 줄의 store가 "arkive"이고, 잠갔으면 sha256_stored가 있다. 임시 저장고 때의 received 줄과 이 줄이 차례로 남아 옮긴 내력이 된다. status는 쓰지 않는다.

2. 사전 교정은 trainedAlgorithmicMedia 그대로

사전으로 확실한 것만 바꾼 교정본도 바탕 글은 기계 전사다. IPTC algorithmicMedia는 「학습 없이 알고리즘만으로 처음부터 만든 것」이라 맞지 않는다. 대신 무엇이 고쳤는지를 다른 칸에 적는다: level: "draft", action: "c2pa.edited", made_by: {"type":"machine","name":"dictionary"}, edits.machine에 고친 수. 03-manifest 6절 표에 한 줄 더한다.

3. confirmed_by.at과 줄의 at은 따로다

confirmed_by.at은 도장을 찍은 때, 줄의 at은 장부에 적은 때다. 대개 같고, 같은 값을 써도 된다. 오프라인에서 찍고 나중에 올리면 다르다. 06-관계망의 「사실의 때와 기록한 때」와 같은 결이다.

4. 보낸 기록은 짝마다 하나로 묶는다

• sent_to에는 (provider, purpose, what) 짝마다 한 칸만 둔다. at은 처음 보낸 때, last_at은 마지막, count는 보낸 횟수.
• event: "sent" 줄은 그 짝으로 그날 처음 보낼 때 하나 쓴다. 보내기 전에 먼저 적는다는 규칙(8절)은 그대로다.
• 학습(train)은 묶지 않는다. 보낼 때마다 따로 적는다.

왜

• A1, A2: 비공개 사진 한 장만 나중에 열 수 있어야 한다. 소금 하나로 전부를 묶으면 하나를 대조하려고 전부를 내놓아야 한다. 묶는 법은 이미 있는 02-지문 5절을 그대로 쓴다.
• A2: 여는 것은 범위를 넓히는 일이고, 범위를 넓히는 것은 기탁자만 한다 (01-권한, 0011). 이미 있는 scope_changed와 confirmed_by 모양에 맞췄다.
• A4: 업종마다 사건이 다르다. 규격이 업종의 값을 다 알 수는 없다. 대신 값이 어디서 왔는지는 늘 읽을 수 있어야 한다.
• A5: 공개할 사진은 어차피 밖에 나간다. 하지만 위치 정보와 아직 동의하지 않은 사람의 얼굴은 공개 전에 나가면 안 된다. 그래서 조건을 붙였다.
• B: 새 이름을 지어내지 않고 있는 칸과 표준 값으로 풀었다.

다른 선택지

선택지	안 고른 이유
A1: 소금 하나로 전부 (0016 그대로)	항목 하나를 열려면 전부를 내놓아야 한다
A2: 새 사건 이름 disclosed	범위를 넓히는 일이라 scope_changed로 충분하다
A5: 텔레그램 예외 없이 모두 Syncthing	양조장 대표와 대학에 프로그램 설치를 요구하게 된다. provenance 설계는 「생산자 부담 0」을 원칙으로 둔다
B1: 새 사건 이름 stored 또는 replicated	하는 일이 received와 같다. PREMIS replication은 같은 보관 안에서 사본을 늘리는 일에 더 가깝다
B2: algorithmicMedia	바탕 글이 학습한 기계의 전사다
B4: 보낼 때마다 한 칸 (지금 8절)	비서가 하루 녹음을 읽을 때마다 쌓여 장부가 커지기만 한다

어디에 영향이 가나

• provenance: sealed 항목별, sealed_count, 공개 줄은 scope_changed + decided_by, parents, blend, custody_transfer, tokenized 빼기, profile, via. 텔레그램 길은 위 조건으로.
• secretary: 옮긴 줄 received, 사전 교정 trainedAlgorithmicMedia + made_by 사전, sent_to 묶기.
• hgp: 03-manifest 3·5·6·8절 (v0.7), 05-용어, 06-관계망 5절 (v0.5), 0016 바로잡음.
• arkive: 원본을 받을 때 received 줄을 쓴다 (결정 0004의 입구와 같은 일).

비용

없다.