W3C DID 재헌장, 표준 상태 인수서 필요

요약

W3C의 현재 2024년 헌장은 DID Resolution을 Recommendation 트랙 산출물로 지정했으며 2026년 10월 28일까지 연장되었다. 이 작업은 권위의 공백 속에서 운영되고 있지 않다.
DID Resolution은 8월 6일에 Candidate Recommendation Snapshot이 되었다. 이 Patent Review Draft는 10월 5일까지의 제외 기회를 열었고 기능 수준의 구현 기준을 설정했으며, W3C Recommendation이나 승인이 된 것은 아니다.
W3C Team은 8월 10일에 연속성 재헌장의 정제 작업을 시작했다. 그러나 공개 초안 헌장은 8월 27일 리포지터리 헤드를 포함해 여전히 DID Resolution을 Working Draft로 기재하고, 최신 출판물을 7월 10일로 표시하며, 더 오래된 2024년 제외 초안을 가리키고 있다.
그 후 W3C의 공식 이력은 8월 28일자 Candidate Recommendation Draft를 기록한다. 이 최신 초안은 의도된 변경 사항을 통합하지만, 최신 텍스트라는 이유만으로 또 하나의 특허 검토 Snapshot이 되는 것은 아니다.
자문위원회(Advisory Committee) 검토에 앞서, 재헌장에는 현재 헌장 권위, 최신 판독 가능 초안, 지배적인 Snapshot, 제외 기간, 위험 기능 상태, 날짜가 기재된 구현 근거를 결합하는 간결한 표준 상태 인수서가 담겨야 한다. 이 결합은 절차를 설명해야 하며 새로운 게이트를 만들어서는 안 된다.

정확한 네 개의 시계도 하나의 잘못된 해석을 낳을 수 있다

가장 쉬운 실수는 DID Resolution의 상태를 하나의 날짜로 응답되는 질문처럼 묻는 것이다.

출판 시계가 있다. W3C의 이력에는 현재 8월 6일자 Candidate Recommendation Snapshot과 8월 28일자 Candidate Recommendation Draft가 나열된다. 후자가 더 최신의 판독 가능한 보고서다.

특허 시계가 있다. 8월 6일 Snapshot이 Patent Review Draft다. 이는 10월 5일까지 이어지는 제외 대상 공개(Call for Exclusions)를 열었다. 8월 28일 Draft는 출판일이 더 늦다는 이유만으로 그 기준 문서 기능을 대체하지 않는다.

구현 시계가 있다. 공개 테스트 보고서는 3월 27일 실행을 표시하고 있으며, 매트릭스와 여러 구현자를 명시한다. 반면 8월 Snapshot은 기능 수준에서 어떤 근거가 필요한지를 정의한다.

제도 시계가 있다. DID Resolution을 Recommendation 트랙에 올린 현재 헌장은 10월 28일까지 유효하다. 후속 헌장은 정제 중이지만 아직 승인되지 않았고 효력 발생일도 없다.

각 시계는 모두 보인다. 문제는 독자가 이들을 하나의 상태 라벨로 압축할 때 시작된다. “최신”은 최신 통합 텍스트, 최신 특허 기준 문서, 최신 테스트 실행, 현재의 그룹 권위 출처 중 무엇이든 가리킬 수 있다. 이들은 동의어가 아니다.

따라서 거버넌스 과제는 하나의 지배 시계를 고르는 것이 아니라, 이들 사이의 결합을 보존하는 것이다.

현재 헌장은 불만 켜는 역할 이상을 했다

현재 2024년 헌장이 중요한 이유는 8월의 출판물들이 존재하는 이유를 설명해 주기 때문이다. 이 헌장은 DID Resolution을 새로운 Recommendation 트랙 산출물로 채택했다. 초기 종료일은 2026년 4월이었고, W3C는 이를 2026년 10월 28일까지 연장했다.

즉, Candidate Recommendation 작업은 유효한 헌장 아래에서 이루어졌다. 이후의 재헌장이 권위를 소급해서 만들 필요는 없다. 또한 새 초안을 이미 기존 헌장을 대체한 것처럼 서술해서도 안 된다. W3C 프로세스상 헌장 승인은 이후의 제도적 행위이며, 그 뒤에 참여 요청(Call for Participation)과 새로운 참여 약속이 따른다.

제안된 헌장에 대한 Strategy 이슈는 의도된 변경에 관해 이례적으로 솔직하다. 이를 기존 그룹의 재헌장이라고 명시하고, “실질적 변경 사항: 없음”이라고 밝히며, DID Resolution에 대한 합의가 예상보다 오래 걸려 그룹에 더 많은 시간이 필요하다고 설명한다.

이 서술은 상태 인수서의 필요성을 강화한다. 제도적 목적이 새 범위가 아니라 연속성이라면, 기록은 연속성을 증명할 수 있어야 한다. 어떤 산출물이 경계를 넘는가? 그 특허 검토 텍스트는 어떤 헌장 아래에서 만들어졌는가? 어떤 미해결 근거 의무가 함께 이동하는가? 어떤 후속 텍스트가 단지 진행 중인 작업인가? 연속성 문서는 연속성 질문에 특히 잘 답해야 한다.

이것은 제안된 헌장이 권한을 만든다는 주장이 아니다. 그렇지 않다. 이는 그 반대의 문제다. 미래의 헌장이 이미 다른 곳에서 승인된 작업을 어떻게 정확히 받아들이는가의 문제다.

Snapshot과 Draft는 서로 다른 종류의 “후보”다

용어가 기만적으로 비슷하다. W3C는 Candidate Recommendation Snapshot과 Candidate Recommendation Draft를 모두 출판한다. 두 형태는 같은 성숙 단계에 있지만 서로 다른 역할을 한다.

8월 6일 Snapshot은 안정된 검토 지점이다. W3C 프로세스는 Candidate Recommendation Snapshot을 Patent Review Draft로 기술한다. 그 출판은 제외 대상 공개를 촉발한다. 따라서 DID 워킹그룹의 공개 IPR 페이지는 8월 6일을 현재 기회의 시작으로, 10월 5일을 종료로 명명한다.

8월 28일 Candidate Recommendation Draft는 다른 기능을 가진다. 그 상태 텍스트는 워킹그룹이 이후 Snapshot에 넣으려는 이전 Candidate Recommendation의 변경 사항을 통합한다고 밝힌다. 이는 명시적으로 진행 중인 작업이며, 그 외의 것으로 인용하는 것은 부적절하다. 프로세스상 CR Draft는 그 자체로 제외 기회를 제공하지 않는다.

이 구분은 구현자와 참여자를 정반대의 두 오류에서 보호한다. 최신 Draft를 특허 기준 문서로 취급하면, 그 기준을 만드는 절차 없이 법적 비교 지점이 이동할 수 있다. 반대로 더 오래된 Snapshot만을 현재 기술 텍스트로 취급하면 구현자에게 검토를 요구 중인 변경 사항이 가려질 수 있다.

두 문서 모두 인수서에 포함되어야 하며, 라벨은 서로 다르다:

최신 통합 기술 텍스트: 8월 28일 CR Draft;
지배적인 특허 검토 기준: 8월 6일 CR Snapshot;
현재 제외 기회: 8월 6일~10월 5일;
다음 특허 검토 지점: W3C가 또 다른 Snapshot을 출판하기 전까지 추론하지 않음.

더 최신 날짜가 구촐 제도적 행위의 모든 기능을 흡수하지는 않는다.

제외 기록은 결여된 것이 아니라 진행 중이다

초안 헌장의 DID Resolution 행은 여전히 2024년 11월 28일자 Working Draft를 제외 초안으로, 2025년 4월 27일 종료 기간을 표시하고 있다. 그 행만 읽으면 현재 프로세스보다 뒤처져 있다.

그러나 W3C의 실시간 IPR 면은 뒤처져 있지 않다. 새로운 DID Resolution 기회, 8월 6일 시작, 10월 5일 마감을 보여 주고, 2024–2025년 기회를 과거 이력으로 보존한다. 공개 제외 대상 공개는 또한 새 기회가 이전 기준 문서에 존재하거나 명백하지 않았던 사안에 관한 것임을 설명한다.

이는 발견이 고발이 아니라 정합화라는 점에서 중요하다. 여기에는 W3C가 제외 기간을 시작하지 못했거나, 적용 기록을 숨겼거나, 특허 정책 이력을 잃었다는 증거가 없다. 증거는 그 반대를 보여 준다. 전문 특허 면이 자기 역할을 하고 있다.

열려 있는 제외 기간이 특허 문제를 의미하지도 않는다. 그룹의 IPR 페이지는 자사 사양에 대해 제기된 특허 공시가 없다고 밝힌다. 기회는 절차적 상태이며, 청구권이 존재하거나 제외될 것이라는 주장이 아니다.

따라서 헌장 인수서는 실시간 기록에 연결해야 하며, 산문으로 특허법을 다시 서술하려고 해서는 안 된다. Snapshot, 개시·종료일, 이전 기준 문서, 공개 IPR URL을 명명해야 한다. 나중에 또 다른 Snapshot이 또 다른 기회를 만들면, 인수서는 기존 상태를 다시 쓰지 않고 새 상태를 덧붙일 수 있다.

이것은 얇은 조정이다. 안정된 식별자, 정확한 날짜, 명시적 계보, 정정 경로. 모든 가능한 특허 입장의 실질을 하나의 위원회가 결정할 필요는 없다.

구현 근거는 구현자 수가 아니다

8월 Snapshot은 실험적 구현을 요구하고 엄격한 종료 기준을 설정한다. 모든 기능에 대해 그룹은 공개 테스트 스위트를 통해 검증된, 최소 두 개의 독립적이고 상호운용 가능한 구현을 기대한다. 기계 판독 가능한 규범 문장은 기능별로 최소 두 개의 적합 구현이 필요하고, 기계 판독 불가능한 문장은 최소 두 개의 입증이 필요하다. 독립 구현은 또한 하나 이상의 구현에 의해 상호운용적으로 구현된, 최소 두 개의 공개 명시 DID 메서드를 지원해야 한다.

이 조건들은 “표에 네 개의 이름이 나타난다”로 줄일 수 없다. 공개 구현 보고서는 여러 구현자를 명명하고 상세한 매트릭스를 노출한다. 그러나 실행 시각은 2026년 3월 27일로 표시되며, 이는 8월의 두 Candidate Recommendation 출판물보다 수개월 전이다.

이 날짜가 보고서가 모든 면에서 낙후됐다는 증명은 아니다. 3월 실행이 변경되지 않은 기능을 테스트했을 수도 있다. 매트릭스는 표지에서는 보이지 않는 메커니즘으로 갱신될 수 있다. 또한 맥락에서 떼어낸 가시적 실패나 “미구현” 셀이 최종 종료 테스트의 실패를 입증하지도 않는다. 기능 정의, 테스트 버전, 적합성 문장, 독립성 모두 중요하다.

겸손한 결론이 추측적 판정보다 강하다. 이 작업을 받아들이는 재헌장은 날짜가 기재된 기능–테스트–구현 인수 증명을 가리켜야 한다:

테스트된 사양 커밋 또는 출판물;
테스트 스위트 커밋과 실행 시각;
각 기능으로 묶인 규범 문장;
그 기능에 대한 두 개의 적격 구현 또는 입증;
구현을 독립적으로 취급하는 근거;
상호운용성을 위해 사용된 공개 명시 DID 메서드;
미해결, 건너뜀, 위험 항목;
보고서를 갱신할 책임자.

이 기록이 있으면 실행 코드가 제도적 라벨을 규율할 수 있다. 헌장이 구현 현실을 선언으로 존재하게 만들 수는 없다.

“위험(at risk)”은 통제된 상태이지 실패 판정이 아니다

8월 6일 상태 섹션은 DID URL 역참조(dereferencing)를 위험 기능으로 지목하며, 이 기능이 변경되거나 제거될 가능성이 있다고 밝힌다. 워킹그룹은 정의된 대로의 기능이 가치가 있는지 구현자에게 묻고 있다. 이 문서는 또한 열려 있는 클래스 1, 2, 3 이슈가 사양을 변경할 수 있다고 경고한다.

이것은 건강한 정보다. Candidate Recommendation은 부분적으로 구현으로부터 배우기 위해 존재한다. 기능 위험 표시는 프로세스 실패의 고백이 아니라, 일부가 그대로 살아남지 못할 수 있다는 유계 경고다.

위험은 제도적 전환 중 표시가 사라질 때 온다. 새 헌장이 그룹이 DID Resolution을 “유지할 것”이라고만 쓴다면, 이후 독자는 무엇을 물려받았는지 알아야 한다. 최종 기능인지, 열려 있는 이슈인지, 제거 가능한 후보인지, 테스트된 상호운용성 주장인지, 잠정 섹션인지.

인수서는 답을 얼려서는 안 된다. 질문, 책임 결정 표면, 그것을 닫는 데 필요한 근거를 보존해야 한다. “있음” 또는 “없음”만 말할 수 있는 상태 기록은 표준 작업에 비해 너무 거칠다.

초안 헌장은 정정을 위해 설계된 단계에 있다

공개 헌장 페이지는 스스로를 초안이라고 부른다. 시작·종료일은 자리표시자이며, 이는 시작일이 미래의 승인과 참여 요청에 의존하기 때문에 놀랍지 않다. W3C는 정제가 약 9월 15일까지 계속될 것으로 예상된다고 발표했다. 프로세스상 정제 기간은 폭넓은 검토가 이루어지고, 이슈가 공식적으로 다뤄지며, Team이 자문위원회 검토 시작, 정제 연장 또는 제안 중단을 결정하는 기간이다.

DID Resolution 행은 의도된 의미에 관해서도 솔직하다. “Draft 상태”는 헌장 승인 시점의 산출물 상태를 의미하며, 최신 정보는 출판 상태 페이지에 연결한다고 밝힌다.

그 문장이 올바른 기준을 제시한다. 이 행은 정제의 모든 시간에 실시간 티커처럼 작동할 필요는 없다. 헌장이 승인에 도달할 때 정확하면 된다. 그러나 증거 기준 시점에 실시간 페이지와 8월 27일 리포지터리 헤드는 여전히 Working Draft, 최신 출판물 7월 10일, 구식 제외 초안을 말하고 있다. 8월 6일 Snapshot이 이미 그 헤드가 병합될 당시 3주 늙은 상태였음에도 말이다. 이어서 8월 28일 CR Draft가 그 격차를 더 벌렸다.

이것은 정정 가능한 초안 상태 불일치이지, 무효성의 증명이 아니다. 무효라고 부르면 정제의 존재 이유가 지워지고, 무시하면 정제의 존재 이유가 낭비된다.

표준 상태 인수서에 담겨야 할 것

해답은 헌장을 두 번째 출판 데이터베이스로 만드는 것이 아니다. W3C에는 이미 전용 출판, IPR, 그룹, 테스트 면이 있다. 공통 계층은 얇게 유지되어야 한다.

하나의 간결한 기록이 안정된 식별자로 이들을 결합할 수 있다:

권위

현재 헌장, 그 효력 기간, 후속 헌장 커밋, 정제 상태, 최종 승인 결정을 명명한다. 승인까지는 후속 헌장을 제안(proposed)으로 표기한다.

텍스트

최신 판독 가능 기술 보고서와 그 상태를 명명한다. 지배적인 Candidate Recommendation Snapshot은 별도로 명명한다. 둘을 위해 하나의 “최신” 필드를 사용하지 않는다.

특허 상태

Patent Review Draft, 제외 개시·종료일, 이전 기준 문서, 공개 IPR 페이지를 명명한다. 이후의 제외 기회는 추가 전용(append-only)으로 기록한다.

구현 상태

구현 보고서 버전, 실행 시각, 테스트된 사양, 기능 커버리지, 독립성 근거, 미해결 셀을 명명한다. 원시 테스트 근거를 연결해 둔다.

검토 상태

기능 위험 표시, 열린 이슈, 수평 검토, 폭넓은 검토 기간, 의견 처분에 연결한다. 닫힌 날짜가 그것을 만든 경로를 지워서는 안 된다.

보관

각 프로젝션의 소유자, 정정 경로, 필드를 대체하는 이벤트를 식별한다. 이후 출판은 전환을 덧붙여야 하며, 제도적 기억을 조용히 덮어써서는 안 된다.

이 기록은 표로 렌더링되고 구조화 데이터로 저장될 수 있다. 공개적 가치는 경계를 보존하는 데서 나오며, 또 하나의 승인 계층을 추가하는 데서 나오지 않는다.

하나의 넓은 신원 연결이 W3C의 권한을 확대하지 않는다

DID Resolution은 탈중앙화 식별자와 이를 DID 문서 및 자원으로 해석하는 절차에 관한 것이다. 따라서 신원 및 접근 관리(identity and access management)는 관련된 주변 분야다. 그렇다고 W3C가 IAM 제품을 승인하거나, DID 메서드를 인증하거나, 모든 신원 제공자를 통제하거나, 법적 신원 제도를 만드는 것은 아니다.

사양 자체가 워킹그룹 범위에서 인증·권한 부여 프로토콜, 브라우저 API, 웹에서 “신원 문제를 해결하려는” 야망을 제외한다. 이 절제는 요약과 디렉터리 연결에서도 살아남아야 한다. 표준 기사는 독자를 더 넓은 신원 주제로 안내하면서도, 주제 관련성을 제도적 관할로 바꿔서는 안 된다.

참여에도 같은 경계가 있다. 구현자, 회원, 초빙 전문가, 공개 검토자는 근거, 코드, 반대 의견, 판단을 공급한다. 그들의 참여가 부재하는 제품 운영자나 정부에 대한 권위가 되지는 않는다. 헌장은 워킹그룹의 정의된 작업을 승인하고, Recommendation 프로세스는 W3C 출판을 통제하며, 외부 채택은 다른 주체에게서 나온다.

인수서는 이 계층들을 더 쉽게 보이게 해야 하며, 보편적 권한으로 혼합해서는 안 된다.

W3C의 DID 재헌장은 계승하는 표준의 상태 인수서가 필요하다

왜 중요한가