C2PA Active Manifest: 내장·원격 자격 증명을 찾는 방법
자산과 가져온 경로를 함께 보존합니다
검토 전에 실제 자산 사본을 편집하지 않고 저장합니다. 파일명, 출처 URL 또는 로컬 경로, 가져온 시각, 미디어 유형, validator 이름과 버전을 기록합니다. HTTP로 받은 자산이라면 다운로드한 바이트와 응답 헤더를 함께 보존합니다. 나중에 받은 사본은 헤더, 메타데이터, 내장 데이터가 달라질 수 있으므로 첫 사본의 결과를 대신하지 못합니다. 이 기록 방식은 본문이 제안하는 실무 절차이며 C2PA가 요구하는 절차는 아닙니다.
질문은 이 자산과 연결된 C2PA Manifest Store를 validator가 찾고 일치 여부를 확인할 수 있는지로 제한합니다. Store를 찾았다는 결과는 중간 기술 결과입니다. 화면 속 사건의 생성자, 발생 시각, caption의 정확성을 증명하지 않습니다.
표준 내장 위치부터 확인합니다
C2PA 2.2는 C2PA Manifest Store 안의 마지막 C2PA Manifest superbox를 active manifest로 봅니다. Validator는 먼저 자산 형식의 표준 위치에 내장된 Manifest Store를 찾습니다. Store 발견 여부와 개수를 기록합니다.
대부분의 자산에서 여러 Manifest Store가 내장되어 있으면 모두 무효이며, validator는 manifest를 찾지 못한 것처럼 처리합니다. PDF incremental update는 별도 조건이 있습니다. 서로 다른 update section에는 각각 store가 있을 수 있지만, 같은 section 안의 여러 store는 여전히 무효입니다. 단순한 “자격 증명 발견” 표시 대신 validator가 보고한 section과 개수를 보존합니다.
자산을 HTTP로 받았다면 validator는 전체 파일을 내려받기 전에 응답의 Link header를 확인할 수 있습니다. 명세는 큰 파일이나 streaming 자산에서 이 방법이 유용하다고 설명합니다. 원격 참조는 파일 바이트뿐 아니라 가져온 상황에도 연결되므로 원래 header를 남깁니다.
원격 참조를 정해진 순서로 추적합니다
내장 store가 없으면 HTTP 응답에서 relation이 c2pa-manifest인 Link header를 확인합니다. 대상은 일반 HTTP 또는 HTTPS URI일 수 있습니다. JUMBF URI fragment로 자산 안의 Manifest Store를 가리킬 수도 있지만, 특정 child manifest 참조는 허용되지 않으며 validator는 child label 부분을 무시합니다.
그다음 C2PA Manifest 밖의 표준 위치에 있는 XMP에서 dcterms:provenance key를 확인합니다. 폰트의 C2PA table에서 activeManifestUriLength가 0이 아니면 해당 URI를 사용합니다. 그래도 찾지 못하면 같은 경로나 URI에 .c2pa 확장자를 붙인 파일을 확인하고, validator는 적합하다고 판단한 다른 위치도 검색할 수 있습니다.
각 시도마다 위치 유형, 정확한 참조, 가져오기 결과, 적용 가능한 HTTP status, validator 메시지를 기록합니다. 원격 manifest가 있다고 문서화됐지만 그 위치에 없거나 offline 상태처럼 접근할 수 없다면 C2PA는 manifest.inaccessible을 사용합니다. 이를 “자격 증명이 존재한 적이 없다”로 바꾸지 않습니다. 현재 검토 환경에서 문서화된 store를 가져오지 못했다는 결과입니다.
찾은 store가 자산과 일치하는지 확인합니다
Manifest Store를 찾은 뒤 active manifest의 hard-binding assertion으로 이 store가 자산과 맞는지 확인합니다. 위치 발견만 성공으로 표시하지 말고 전체 hard-binding 결과를 보존합니다.
Hard binding이 일치하지 않으면 자산이 수정된 것인지, 잘못된 Store를 찾은 것인지 그 결과만으로 알 수 없습니다. 명세는 이를 non-matching hard binding으로 처리해 manifest를 거부합니다. Binding 유형에 따라 assertion.dataHash.mismatch, assertion.boxesHash.mismatch, assertion.collectionHash.mismatch, assertion.bmffHash.mismatch가 사용됩니다. 실제 반환된 code를 기록하고 원인을 추정하지 않습니다.
위치 증거, active manifest 식별자, hard-binding 유형, validator 전체 출력, 파일 식별자를 함께 둡니다. 다음 검토자는 remote store가 없었던 경우와 store는 찾았지만 일치하지 않은 경우를 구분할 수 있습니다.
Provenance, 탐지, 사건 확인을 분리합니다
위치와 hard binding이 통과했다면 이 사본에 대해 validator가 Store를 찾고 기록된 일치 결과를 얻었다고 말할 수 있습니다. Caption, 화자, 촬영 시각, 장소, 화면 속 사건은 원 게시물과 독립 자료로 따로 확인합니다.
보존한 파일을 DeepFakeCheck로 분석한다면 확률적 risk signal을 별도 항목에 둡니다. 자동 탐지에는 진짜 미디어를 의심하는 오탐과 합성 또는 조작 미디어를 놓치는 미탐이 있습니다. 높은 risk는 추가 검토의 이유입니다. 이 확률적 신호와 C2PA provenance credential은 서로 다른 증거 메커니즘이며, 어느 쪽도 화면 속 사건을 증명하지 않습니다.
마지막에는 자산 식별자, 가져온 경로, 시도한 위치, 사용한 참조, 접근 결과, active manifest 식별자, hard-binding 상태, 미해결 질문과 조치를 남깁니다. 다음 담당자가 어떤 사본과 원격 응답을 검사했는지 추측하지 않고 같은 검색을 반복할 수 있어야 합니다.
출처
- C2PA, “C2PA Technical Specification, Locating the Active Manifest”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_locating_the_active_manifest