요약

  • W3C의 10월 1일 DID Resolution 초안에는 HTTP(S)를 통한 DID URL 역참조 예시와 네트워크 역참조기 적합성 범주가 있었다. 24일과 26일 초안에서는 그 범주와 HTTP 역참조 규정이 빠졌다.
  • DID 자체를 HTTPS로 해석하는 통로는 남았다. 전체 URL이 가리키는 조각이나 자원을 처리하는 과정은 클라이언트의 선택과 실행에 달렸다.

택배 기사가 상자를 문 앞에 두고 떠났다. 주문한 열쇠를 찾으려면 상자를 열어야 한다. did:example:123#key-1을 쓰는 앱에서도 DID 문서가 도착한 뒤 #key-1을 찾아 적용하는 단계가 남는다.

10월 1일 W3C 초안은 DID 해석과 DID URL 역참조를 함께 HTTP(S) 연결 규정에 담았다. 네트워크 DID URL 역참조기의 적합성 범주와 HTTP 요청 예시도 있었다. 24일 판은 이 범주와 예시를 삭제했고, 26일 판의 개정 기록은 OpenAPI 정의에서도 역참조가 빠졌다고 적는다.

해석기가 맡는 일은 그대로 명확하다. 현행 초안은 DID 문서와 해석 메타데이터를 HTTPS로 받는 방식을 규정한다. 적합한 해석기는 GET을 지원해야 하고 POST는 선택할 수 있다. 여러 DID 방식을 다루는 서비스에도 공통의 접수 창구가 생기는 셈이다.

창구 뒤의 일은 URL의 내용에 따라 달라진다. 초안의 역참조 알고리즘은 클라이언트가 사용자에게 DID 방식별 해석기를 고르게 하고, 결과에 맞는 처리 방식을 정해 핸들러를 실행하도록 한다. W3C 예시는 # 뒤의 조각을 클라이언트에서 다룬다. 서비스 매개변수가 붙은 주소라면 서비스 선택과 자원 접근이 뒤따른다. 앱이 사용 목적을 알고 마지막 결정을 내린다.

이 논점은 W3C 이슈 306에서 3월부터 제기됐다. 원격 서비스가 클라이언트 쪽의 조각 처리를 끝까지 대신할 수 있느냐는 질문이다. 10월 15일 회의록에서는 추상 알고리즘과 구체적인 시험 인터페이스를 연결하는 방식을 논의했다. 구매자와 운영자는 이제 HTTP 응답만 확인할 수 없다. 해석기가 준 문서와 앱이 전체 URL에서 얻은 결과를 각각 시험해야 한다.

역참조 기능은 후보 권고안 단계에서 여전히 변경 가능성이 있는 항목으로 표시돼 있다. 그래서 현재의 운영 기록에는 두 이름이 필요하다. 문서를 준 해석기, 그리고 그 문서에서 실제 열쇠나 자원을 찾아낸 클라이언트 코드다. 앞사람의 영수증으로 뒷사람의 배송까지 증명할 수는 없다.