DID(Decentralized Identifier) 1.0 제안된 권장 사항에 대한 W3C 회원 검토는 3개의 조직(Google, Apple 및 Mozila)의 공식적인 반대 의견으로 마무리되었습니다.
반대 의견에 대해서 자세한 내용은 아래의 링크를 참고바랍니다.
Google:
DID-core는 고유한 사양이 필요한 “DID Method”를 사용할 때만 유용합니다. … DID core spec이 웹에 미치는 영향을 함께 검토해야 합니다. RFC 1738은 일반적으로 URL을 표준화함과 동시에 10가지 방식을 표준화한 URL의 발전에 따른 선례를 따라야 합니다. 권장 사항 트랙을 통해 몇 가지 최상의 방법을 발전시키는 과정은 검토에 초점을 맞추는 데 도움이 되며, 개선 방법에 맞게 did-core spec을 변경해야 하는 지점을 밝힐 수 있습니다. 적어도 3개 이상의 Method가 REC로 진행할 준비가 될 때까지 did-core를 REC 상태로 진행하는 것을 보류하는 것이 좋습니다.
W3C Members:
core spec에는 기본적으로 작동하는 상호 운용 가능한 Method가 하나 이상 있어야 합니다. core spec은 이러한 Method가 마련될 때까지 REC로 변경해서는 안 됩니다.
Mozila:
DID core spec은 실질적인 상호 운용성을 입증하지 못했으며 대신 50개 이상의 Method 레지스트리에 위임했습니다. DID 아키텍처 접근 방식은 수렴 및 상호 운용성보다는 발산을 장려하는 것으로 보입니다. 실제 상호 운용성 없이 레지스트리에 50개 이상의 항목이 있다는 것은 여러 기존 방법 중 하나와 상호 운용을 시도하는 것보다 새로운 방법을 도입하는 데 더 큰 인센티브가 있음을 의미하는 것 같습니다. 레지스트리에 대한 제한이 없기 때문에 그룹 및 사양의 원칙에 완전히 반대되는 Method과 지속 가능성에 전 세계적으로 적극적으로 유해한 Method가 허용됩니다. 우리는 DID core spec을 수정할 수 없다고 생각합니다(권장사항이 되어서는 안됩니다.)
이러한 반대는 제안된 식별자 구문, 데이터 모델, 속성, 표현, 작업 및 확인 기능의 기존 구현이 DID 코어가 다음과 같은 식별자 클래스를 갖기 위한 요구 사항을 얼마나 잘 달성했는지에 대한 우려에 중점을 둡니다.;
중앙 발행 기관이 없어야 합니다.
식별자는 본질적으로 영구적이어야 하며 기본 조직의 지속적인 운영이 필요하지 않습니다.
식별자를 암호로 제어할 수 있어야 합니다.
식별자에 대한 메타데이터를 검색할 수 있어야 합니다.
– Use Cases and Requirements for Decentralized Identifiers
단일 DID Method가 이러한 속성 중 하나 이상을 달성하지 못할 수 있다는 점은 의심의 여지가 없습니다. 여기서 고려해야 할 사항은 제안된 DID 식별자 구문 및 관련 메커니즘이 이러한 속성을 가진 확장 가능한 식별자 클래스를 정의하기에 충분히 표시되었는지 여부입니다.
반대론자들은 초기 URL 사양 및 사양에 포함된 URL 체계와 유사합니다. 아키텍처 관점에서 URL/URI 체계와 DID Method간의 유추는 합리적입니다. 반대론자들은 DID URI 권장 사항이 URL 사양으로 확립된 선례를 따를 것을 촉구합니다. 여기서 그 사양에는 일부 당시 일반적인 프로토콜에 매핑된 몇 가지 특정 체계가 포함되었습니다.
이것은 아키텍처 수준에서는 적합할지 모르지만 시간적 맥락에서는 부적절합니다. DID 권장 트랙 작업이 전개될 당시의 논의는 표준 DID Method가 바람직하다는 합의를 보여주었습니다. 토론에서 특정 표준 Method에 대한 합의에 도달하는 것이 이러한 식별자 클래스에 대한 공통 기반에 대한 합의에 도달하는 것보다 훨씬 더 어려울 것이라는 점을 인정했습니다. 이러한 관점에서 다양한 DID Method를 준수하는 등록은 core spec이 이 분야에서 개발 중인 구현의 합의 요구 사항을 충족한다는 데모로 볼 수 있습니다.
이러한 의미에서 — core spec을 사용하고 준수하는 다양한 Method 구현이 존재한다는 점에서 — core spec은 상호 운용성을 보여줍니다. 일부 Method도 W3C 권장 사항으로 진행하는 것이 바람직합니다.
여기서 결정된 문제는 DID core를 권장 상태로 발전시키거나 표준 Method에 대한 추가 작업을 기다리도록 유지하는 경로가 분산 식별자를 필요로 하는 커뮤니티와 보다 일반적으로 웹 커뮤니티에 잠재적인 피해를 최소화하는 것입니다.
반대론자들은 URL core자체가 표준화되었을 때 일부 표준 URL 체계가 있었던 선례가 지금 적용되어야 한다고 주장합니다.
현재의 DID core spec은 구현 가능성에 대한 증거가 부족하지 않습니다. 많은 인터넷 표준의 역사는 미래의 작업이 초기 표준에 대한 개선으로 이어질 수 있고 종종 그렇게 함을 보여줍니다. 이것은 결함이 아니라 기능입니다. 커뮤니티가 표준으로 업데이트하기 전에 기술을 배포해야 하는 기간에 대한 궁극적인 판단을 하는 것은 커뮤니티입니다.
DID core가 권장 사항 상태로 진행되면 작업 그룹과 DID Method 설계자 및 구현자 커뮤니티가 이 표준화된 아키텍처 계층으로 요구 사항의 일부를 충족했으며 권장하는 Method의 sepc에 다음으로 집중할 수 있다는 데 동의합니다. 이미 배포된 것 또는 여러 설계의 기능을 하나 이상의 “동급 최고”로 결합하는 것입니다.
“분산화”라는 용어의 의미에 대한 논의, 특정 DID Method가 이를 사용하는 응용 프로그램의 각 클래스의 요구 사항을 얼마나 잘 충족하는지, 등록된Method가 허용되는 항목을 제한해야 하는지 여부 및 어떤 기준에 따라야 하는지에 대하여 논의되어야 하며, 각 Method가 사용하는 리소스의 허용 가능한 비용과 해당 Method가 의도한 응용 프로그램 클래스의 예상 이익의 균형은 확실히 계속될 것입니다. DID core spec이 옵션이 없거나 이러한 논의를 복잡하게 만든다는 증거는 제시되지 않았습니다.
DID core가 권장 사항으로 진행되는 것이 보류되면 분산 식별자 시스템의 다른 설계자가 이 공간에서 결과물을 생성하도록 승인된 커뮤니티의 합의를 따를 동기가 줄어들 것입니다. 커뮤니티가 해결하기 위해 노력해 온 상호 운용성 문제를 복잡하게 만드는 다른 URI 체계의 불필요한 배포를 쉽게 예측할 수 있습니다.
이사회는 DID 개발자 커뮤니티가 작업을 계속하고 표준 DID Method에 대한 합의를 찾도록 권장하면서 균형이 DID 개발자 커뮤니티에 유리하다고 결론지었습니다. 그러므로 반대 의견은 기각됩니다.
DID core spec은 W3C 권장 사항으로 진행하도록 승인되었습니다.
이후 승인 기간에 워킹 그룹은 제안된 표준 DID Method를 처리 및 제공하고 상호 운용 가능한 구현을 보여야 합니다. 제안된 Method에 대한 커뮤니티 및 회원 검토는 탈중앙화, 목적 적합성 및 지속 가능한 자원 활용과 관련하여 반대자 및 기타 회원 검토자가 제기한 질문을 평가하기 위한 장소가 됩니다.
