이 문서는 W3C Decentralized Identifiers (DIDs) v1.0의 한국어 번역본입니다.

이 문서에 오역 및 오타를 포함할 수 있습니다. 영어 원문만이 공식적이고 규범적인 효력을 가지고 있습니다.
문의나 개선사항은 깃헙 링크jshim10@illinois.edu로 연락주시기 바랍니다.

원문작성일: 2019-12-09
최초번역일: 2019-12-29
최종수정일: 2020-01-10

편집자 (가나다순):
심재훈 (Hopae Inc.)

번역자 (가나다순):
안형철
오효근 (SCVSoft Co., Ltd.)
유민호 (IoTrust Co., Ltd.)
유수웅
윤희태 (Hopae Inc.)
임도형 (DSRV Labs)
현수영 (DSRV Labs)

탈중앙 식별자(DIDs)는 검증가능하고 탈중앙화된 디지털 신원을 위한 새로운 형식의 식별자이다. 이러한 새로운 식별자는 DID 컨트롤러가 DID의 제어권을 증명하고, 중앙화된 레지스트리, 신원 제공자, 인증기관 등으로부터 독립적으로 구현할 수 있도록 설계되었다. DIDDID 주체와 관련된 URL로써, DID 문서라는 방식을 통해 해당 주체와 신뢰할 수 있는 상호작용을 가능하게하는 도구이다. DID 문서는 특정 DID를 어떻게 사용하는지에 대해 설명해 놓은 간단한 문서이다. 각 DID 문서는 암호학적 요소, 검증 메소드, 서비스 엔드포인트 등으로 표현될 수 있다. 해당요소들은 DID 컨트롤러가 DID의 통제권에 대한 증명을 가능하게 하는 메커니즘 집합을 제공한다. 서비스 엔드포인트는 DID 주체와의 믿을 수 있는 상호작용을 가능하게 한다.

본 문서는 일반 데이터 모델, URL 형식, DID를 위한 일련의 작동방식, DID 문서 그리고 DID 메소드에 대해 명시하고 있다.

서론

기존의 ID 관리 시스템(identity management)은 기업의 디렉토리 서비스(directory services), 인증 기관(, certificate authorities) 또는 도메인 등록 기관(domain name registries)과 같은 중앙 집중식 기관을 기반으로 한다. 암호학적 신뢰 검증의 관점에서 보면, 이들 중앙집중화 된 각 기관은 각각의 신뢰점(root of trust)이 된다. 이러한 시스템들을 통해 ID 관리를 수행하려면 연합 ID 관리(federated identity management)를 구축해야 한다.

블록체인이라고도 하는 분산원장기술(DLT, Distributed ledger Technology)의 출현은 완전한 탈중앙 ID 관리 기회를 제공한다. 탈중앙 신원 시스템에서 개체(개인, 조직 및 기타 사항과 같은 제한이 없는 개별 식별 가능 단위)는 공유된 신뢰점을 자유롭게 사용할 수 있다. 전세계에 분산된 원장, 탈중앙 p2p 네트워크, 또는 유사한 기능을 가진 다른 시스템은 권한의 집중이나 단일 장애점을 도입하지 않고 신뢰점를 관리할 수 있는 수단을 제공한다. DLTs(분산원장기술들)과 탈중앙 ID 관리를 결합한 시스템에서는 누구나 분산되고, 신뢰점과 독립적인 자신의 식별자들을 생성하고 관리 할 수 있다.

개체들은 탈중앙 식별자(DIDs)에 의해 식별되며, 증명(예: 디지털 서명, 생체인식 등)을 통해 인증할 수 있다. DIDsDID 문서들(DID documents)을 참조한다. DID 문서DID 식별자와 주체가 상호 작용을 하기 위한 서비스 엔드포인트들을 포함한다. 프라이버시 디자인[Privacy by Design] 가이드라인에 따라, 개체들은 신원, 페르소나, 그리고 컨텍스트들에 따라 구분하고 싶은 바람을 따라 자신이 원하는 만큼 많은 DIDs(DID 문서서비스 엔드포인트들이 포함된)를 가질 수 있다.

DID 메소드는 특정 분산 원장 또는 네트워크에서 DID와 관련된 DID 문서들을 생성, 읽기, 갱신, 그리고 비활성화 하는 메커니즘이다. DID 메소드들은 별도의 DID 메소드 규격을 사용하여 정의한다.

이 설계는 중앙 집중식 레지스트리와 공개키 기반구조(PKI, public key infrastructure)의 중앙 집중식 인증 기관에 대한 식별자의 의존성을 제거 한다. DID 레지스트리분산 원장인 경우, 각 개체는 자체 인증 기관의 역할을 할 수 있으며, 이것을 분권화된 PKI- DPKI(decentralized PKI)라고 한다.

참고로 DID 메소드들은 연합, 또는 중앙집중식 ID 관리 시스템에 등록된 식별자로도 사용될 수 있다. 이것을 위해, 모든 유형의 식별자 시스템에 DIDs 지원을 추가할 수 있다. 이로 인해 중앙집중, 연합 및 탈중앙 식별자들 사이의 상호 운용성이 형성 된다.

이 규격의 첫번째 목적은 일반적인 DID 스키마와 일반적인 DID 문서들에서 동작하는 명령어 집합을 모든 DID 레지스트리에 구현될 수 있도록 정의하는 것 이다. 이 규격의 두번째 목적은 DID 메소드를 위한 적합 요구조건(특정 DID 레지스트리를 위한 특정 DID 스키마와 특정 DID 문서에서 동작하는 명령어 세트를 정의하는 별도의 규격)을 정의하기 위함이다.

개념적으로, 이 규격(Decentralized Identifiers)과 DID 메소드 규격의 관계는 IETF 일반 URI 규격([[RFC3986]])과 특정 URI 체계([[IANA-URI-SCHEMES]])([[RFC7230]]에 명시된 http:와 https: 체계)의 관계와 유사하다. IETF 일반 URN 규격([[RFC8141]]) 및 특정 URN 네임스페이스 정의([[RFC4122]]에 정의된 UUID URN 네임스페이스 등과 같은)의 관계와도 역시 유사하다. 차이점은 DID 메소드 규격은 특정 DID 스키마를 정의하는 것 외에도, 적절한 DID 레지스트리에서 DIDs의 구별방법을 제공하거나, 비활성화하거나, DID 문서를 작성하는 방법을 명시한다는 것이다.

특정 DID 메소드 규격을 가진 일반 DID 규격의 계층적 설계는 URI 규격과 동일한 개념의 일부를 도입한다:

DID 메소드 및 규격 목록은 [[DID-METHOD-REGISTRY]]를 참조하십시오.

간단한 예제

DID는 3부분으로 구성된 간단한 문자열이다:

did:example:123456789abcdefghi
    

위의 예제 DIDDID 문서로 해석될 수 있다. DID 문서에는 DID를 제어하여 개체를 암호학적으로 인증하는 방법 및 개체와 상호 작용하는 데 사용할 수있는 서비스와 같이 DID와 관련된 정보가 포함되어 있다.

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    // used to authenticate as did:...fghi
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],
  "service": [{
    // used to retrieve Verifiable Credentials associated with the DID
    "id":"did:example:123456789abcdefghi#vcs",
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}
    

디자인 목표

탈중앙 식별자들은 [[?VC-DATA-MODEL]]과 같은 검증가능한 증명생태계와 같은 더 큰 시스템의 구성요소이며, 이 규격의 설계를 주도 했다. 이 절에는 이 규격의 기본 설계 목표가 요약되어 있다.

Goal Description
Decentralization 글로벌 고유 식별자, 공개 확인 키, 서비스 엔드포인트 및 기타 메타 데이터의 등록을 포함한, 식별자 관리에서 중앙집중식 기관, 또는 단일실패점 요소를 제거해야 한다.
Control 주어진 개체, 인간과 비인간 모두에게 외부 기관에 의존하지 않고 디지털 식별자를 직접 제어 할 수있는 권한을 부여하십시오.
Privacy 개체가 속성 또는 기타 데이터의 최소, 선택적 및 점진적 공개를 포함하여 정보의 프라이버시를 제어 할 수 있도록한다.
Security 필요한 수준의 보증을 위해 DID 문서에 의존할 수 있도록 RP(relying parties)들에게 충분한 보안을 제공한다.
Proof-based 다른 개체와 상호작용할 때 DID 주체가 암호화 증명을 제공 할 수 있어야 한다.
Discoverability 다른 개체가 해당 개체에 대해 더 많이 학습하거나 상호 작용할 수 있도록 DIDs를 검색 할 수 있어야 한다.
Interoperability DID 인프라는 상호운용성을 위해 설계된 기존 툴과 소프트웨어 라이브러리를 이용할 수 있도록 상호운용성 표준을 사용해야 한다.
Portability 시스템과 네트워크에 독립적이어야 하며 기업이 DIDsDID 메소드를 지원하는 모든 시스템과 함께 디지털 식별자를 사용할 수 있도록 해야 한다.
Simplicity 기술을보다 쉽게 이해하고, 구현 및 배포 할 수 있도록 축소 된 간단한 기능을 선호해야 한다.
Extensibility 상호운용성(Interoperability), 이식성(Portability) 또는 단순성(Simplicity)을 크게 방해하지 않는 경우 가능한 확장할 수 있다.

상호운용성

DIDsDID 문서의 구현 상호운용성은 규격에 부합하는 DIDsDID 문서를 작성하고 분석할 수 있는 구현 능력을 평가하여 시험한다. DID 메소드의 상호운용성은 최소한 다음과 같이 최소 규격을 평가함으로써 결정된다.:

DIDsDID 문서의 생산자와 소비자를 위한 상호운용성은 DIDsDID 문서가 일치하는지 확인함으로써 보장된다. DID 메소드 규격에 대한 상호운용성은 각 DID 메소드 규격에 있는 세부사항에 의해 보장된다. 웹 브라우저가 알려진 모든 URIs 스키마를 구현할 필요가 없는 것처럼, DIDs와 함께 작동하는 호환 소프트웨어는 알려진 모든 DID 메소드를 구현할 필요가 없음을 이해해야한다. 그러나 지정된 DID 메소드의 모든 구현은 해당 메소드에 대해 상호운용성이 보장해야한다.

용어

데이터 모델

이 섹션에서는 decentralized identifier 데이터 모델 개념, 특히, 키와 서비스 그리고 DID 주체DID 문서와 어떻게 관련되어 있는지에 대해 개략적으로 설명한다.

데이터 모델을 확장하는 방법에 대한 자세한 내용은 을 참조한다.

식별자

데이터 모델에서 식별자는 일반적으로 사람, 조직, 장치, 키, 서비스 및 사물의 특정 인스턴스를 식별하기 위해 사용된다. 식별자는 대부분 URLs이며, 좀 더 일반적으로는 URIs이다. 비 URI 기반 식별자는 데이터 모델이 이를 지원하기는 하지만, 다른 인터넷 기반 식별자와 함께 사용하기 쉽지 않기 때문에 권장되지 않는다.

DID 문서

DID 문서decentralized identifier(DID)와 관련된 리소스다. DID 문서는 일반적으로 검증 메소드(public key 등) 및 DID 컨트롤러와 상호 작용 하는데 사용할 수 있는 서비스를 포함한다.

DID 문서는 특정 구문에 따라 일련화된다( 참조). DID 자체는 id 속성에 포함되어 있다.

DID 문서에 존재할 수 있는 속성은 에 자세히 설명되어 있다.

DID 문서에 있는 속성은 해당 에 따라 업데이트 할 수 있다.

암호화 키 및 기타 검증 메소드

DID 문서DID 주체 또는 관련된 것들과의 상호작용을 인증 하거나 승인하는 데 사용할 수 있는 암호화 키 및 기타 검증 메소드를 나타낼 수 있다. 표현된 정보에는 디지털 서명을 확인하는 데 전역적으로 사용할 수 있는 명확한 식별자와 공개키 자료가 포함된다. 키의 상태 정보(예: 정지 또는 취소된 경우)나 하드웨어 기반 암호화 키인지 여부를 결정할 수 있는 속성 등 기타 정보를 표시할 수 있다.

암호화 키 자료와 관련하여, 공개키는 사용할 대상에 따라 publicKey 또는 authentication 속성을 사용하는 DID 문서에 포함될 수 있다. 각 공개키는 고유한 식별자(id), type, 그리고 controller 뿐만아니라 키 유형에 따라 다른 속성을 갖는다. 자세한 내용은 를 참조한다.

이 규격은 DID 문서에서 공개키 자료를 표현하기 위한 형식의 수를 가능한 적게 제한하여 상호 운용성을 높이려고 노력한다. 구현자가 구현해야하는 형식이 적을수록 모든 형식을 지원할 가능성이 높다. 이 접근 방식은 구현의 용이성과 역사적으로 광범위하게 배포된 지원 형식간에 미묘한 균형을 유지한다. 이 규격에서 지원되는 특정 유형의 키 형식은 에 나와 있다.

서비스

서비스 엔드포인트DID 주체 또는 관련 개체와 통신할 수 있는 방법을 나타내기 위해 DID 문서에서 사용된다. DID 문서에 나열된 서비스에는 개인 정보 보호 메시징 서비스에 대한 정보 또는 소셜 미디어 계정, 개인 웹사이트, 이메일 주소와 같은 공개 정보가 포함될 수 있다. 서비스와 관련된 메타 데이터는 보통 서비스마다 다르다. 예를 들어, 암호화된 메시징 서비스와 관련된 메타 데이터는 메시지는 보내기 전에 암호화된 링크를 시작하는 방법을 나타낼 수 있다.

서비스에 대한 포인터는 service 속성을 사용하여 표현한다. 각 서비스에는 고유한 idtype 뿐만 아니라, URI 또는 서비스를 설명하는 추가적 특성이 있는 serviceEndpoint 가 있다.

자세한 내용은 를 참조한다.

탈중앙 식별자 (DIDs)

전역에서 유일한 탈중앙 식별자는 새로운 개념은 아니다. 범용고유식별자(UUIDs)는 1980년대에 처음 개발되었고 향후 개방소프트웨어재단의 분산 컴퓨팅 환경에서 표준 기능이 되었다. UUID는 충돌 가능성이 무한히 작을 정도로 충분한 엔트로피를 가진 128bit 값을 생성하는 알고리즘을 통해 중앙화된 등록 서비스 없이도 글로벌 유일성을 가질 수 있다. UUID는 [RFC4122]에서 URN(Unified Resource Name)의 특정 형식으로써 공식 명시되어 있다.

DID는 아래 사항을 제외하고는 UUID와 유사하다:

일반 DID 구문

일반 DID 스키마는 [[!RFC3986]]을 준수하는 URI 체계이다. DID 스키마DID URL 체계 및 권한 구성 요소에만 특화되어 있다. path-abempty, query, 그리고 fragment 구성 요소들은 [[!RFC3986]]에서 정의된 ABNF 규칙과 동일하다.

DID라는 용어는 아래와 같이 ABNF의 did 규칙을 따르는 URI만을 의미한다. DIDDID 주체를 항상 식별한다. DID URL이라는 용어는 did-url 규칙에 따라 정의되는데, DID로 시작하고 그 뒤에 하나 이상의 구성 요소가 추가되는 URL을 나타낸다. DID URL은 찾아야 할 리소스를 항상 식별한다.

아래는 ALPHADIGIT을 정의하는 [[!RFC5234]] 구문을 사용하는 ABNF 정의에 대한 것이다. ABNF에서 정의되지 않은 다른 모든 규칙 이름들은 RFC3986에 정의되어 있다.

did                = "did:" method-name ":" method-specific-id
method-name        = 1*method-char
method-char        = %x61-7A / DIGIT
method-specific-id = *idchar *( ":" *idchar )
idchar             = ALPHA / DIGIT / "." / "-" / "_"
did-url            = did *( ";" param ) path-abempty [ "?" query ]
                     [ "#" fragment ]
param              = param-name [ "=" param-value ]
param-name         = 1*param-char
param-value        = *param-char
param-char         = ALPHA / DIGIT / "." / "-" / "_" / ":" /
                     pct-encoded
      

The grammar currently allows an empty method-specific-id, e.g., did:example: would be a valid DID that could identify the DID method itself.

메소드 특화 구문

DID 메소드 명세는 반드시 method-namemethod-specific-id 구문을 정의함으로써 일반 DID 구문을 추가로 제한해야 한다. 더 상세한 내용은 섹션 참조.

일반 DID 매개변수 이름

DID URL 구문은 matrix parameter 구문([[MATRIX-URIS]])을 기반의 매개변수를 위한 간단하고 일반화 된 포멧을 지원한다. 위의 ABNF는 매개변수 이름에 대해 어떠한 것도 특정하지 않는다 (param-name 규칙)

일부 일반 DID 매개변수 이름(예를들면, 서비스 선택을 위한)은 어떠한 특정 DID 메소드와 완전히 독립적이어야 하며, 반드시 모든 DID와 동일하게 작동해야만 한다. 그 외(예를들면, 버전관리를 위한)는 특정 DID 메소드에 의해 지원될 수 있지만, 반드시 DID 메소드가 그것을 지원하는 방식으로 동일하게 작동해야만 한다.

메소드에 완전히 특화된 매개변수 이름은 에서 설명하고 있다.

아래 표는 일반 DID 매개변수 이름 세트를 정의하고 있다:

일반 DID 매개변수 이름 설명
hl [[HASHLINK]]에 명시된, 무결성 보호를 추가하기 위한 DID 문서의 자원 해시
service 서비스 ID를 통해 DID 문서로 부터 서비스를 식별
version-id 해석할 DID 문서의 특정 버전을 식별 (버전 ID는 순차적이거나 UUID이거나 메소드에 특화될 수 있음. 이 매개변수는 모든 DID 메소드에서 지원하지 않을 수 있음에 주의
version-time 해석할 DID 문서의 특정 버전 타임스탬프를 식별. 즉, 특정 시간의 DID에 대해 DID 문서가 유효하다는 것을 의미. 이 매개변수는 모든 DID 메소드에서 지원하지 않을 수 있음에 주의

위 매개변수들을 위한 정확한 처리 규칙은 [[DID-RESOLUTION]]에 명시되어 있다.

DID URL에 포함되지는 않지만 DID 리졸버대역외(Out-of-band)로 전달하는 추가적인 매개변수나 옵션이 있을 수 있다. 예를들면, Resolution 프로토콜 혹은 다른 어떤 메커니즘을 사용하는 것이다. 이러한 옵션은 캐싱(Caching) 또는 기대하는 Resolution 결과에 대한 형식을 제어할 수도 있다. 이것은 HTTP와 유사하게 캐싱 또는 결과 형식이 HTTP URL의 일부가 아닌 HTTP 헤더에 표현되는 것과 같다. 중요한 구별점은 DID URL의 일부가 아닌 DID 매개변수는 어떠한 자원이 식별되는지를 지정하는 반면, DID URL의 일부가 아닌 DID 리졸버 옵션은 해당 자원이 어떻게 역참조하는지를 제어한다는 점이다.

메소드 특정한 DID 매개변수 이름

DID 메소드 명세는 추가적인 메소드 특정한 매개변수 이름에 대해서 정의를 할 있다. 메소드 특정한 매개변수 이름은 method-name 규칙에 정의된 메소드 이름에 따라 무조건 접두사가 되어야한다.

예를 들어, 만약 did:foo: 메소드가 매개변수 bar를 정의한다면 매개변수 이름은 foo:bar 가 되어야만 한다. 메소드와 메소드 특정한 매개변수를 사용하는 DID URL에 대한 예시는 다음과 같다 :

did:foo:21tDAKCERh95uGgKbJNHYp;foo:bar=high
      

케밥 케이스 스타일 대신에 콜론 분리자를 사용하는 것을 고려한다. 예) foo-bar 대신에 foo:bar를 사용하는 것

DID 메소드에서 정의된 메소드 특정한 파마리터 이름은 다른 DID 메소드에서도 사용되어질 수 있다. 예를 들면,

did:example:21tDAKCERh95uGgKbJNHYp;foo:bar=low
      

메소드 특정한 매개변수 이름은 다른 종류의 포괄적인 매개변수와 순서에 관계 없이 섞일 수 있다.

did:example:21tDAKCERh95uGgKbJNHYp;service=agent;foo:bar=high
      

DID 메소드 네임스페이스와 메소드 특정한 매개변수 네임스페이스 모두 콜론을 포함 할 수 있으며, 이에 따라 DID 메소드 규격에 정의된 처럼 계층적으로 분리 될 수 있다. 여기 이 두 가지를 보이는 DID URL 예시가 있다.

did:foo:baz:21tDAKCERh95uGgKbJNHYp;foo:baz:hex=b612
      

한 메소드에서 정의 되었지만, 다른 메소드를 갖고 있는 DID URL 안에서도 사용되는 메소드 특정한 매개변수에 대해서 리뷰를 한다. 또한, DID 파라메터 이름 속에서 계층화된 메소드 네임스페이스에 대해서 논의한다.

경로

일반적인 DID 경로는 URI 경로와 동일해야하며, [[!RFC3986]]에서 정의된 path-abempty ABNF 규칙을 무조건 따라야만 한다. DID 경로서비스 엔드포인트를 통해 사용 가능한 주소 자원으로써 사용될 수 있어야만한다. 를 확인하십시오

일부 DID 스키마는 이 세션의 일반적인 규칙보다 제한된 DID 경로 규칙을 위한 ABNF 규칙을 정의할 수 있다.

did:example:123456/path
      

질의(쿼리)

일반적인 DID 쿼리는 URI 쿼리와 동일하며, [[!RFC3986]]의 query ABNF 규칙을 무조건적으로 따라야한다. DID 쿼리서비스 엔드포인트를 통해 사용 가능한 주소 자원으로써 사용 될 수 있어야만 한다. 을 확인하십시오.

일부 DID 스키마는 이 세션의 일반적인 규칙보다 제한된 DID 쿼리 규칙을 위한 ABNF 규칙을 정의할 수 있다.

did:example:123456?query=true
      

파편화(프래그먼트)

보편적인 DID 파편화는 URI 파편화와 동일하며, [[RFC3986]]의 fragment ABNF 규칙을 무조건 따라야만 한다. 구현을 하는 사람은 DID 문서의 컴포넌트(e.g. 유일한 공개키 설명, 혹은 서비스 엔드포인트 )를 식별하기 위해 사용하는 DID 문서 안의 메소드 독립적인 레퍼런스 대신에 DID 파편화를 사용하는 것을 강력하게 권장하지 않는다. 이러한 레퍼런스를 가져오기 위해서는, DID 파편화를 포함한 완벽한 DID URLDID 문서 오브젝트 안의 타겟 컴포넌트를 위해 DID URL 역참조 알고리즘([[DID-RESOLUTION]]을 볼 것)에 입력값으로 무조건 사용되어야한다.

특수한 DID 스키마는 이 섹션의 범용적인 규칙 대신에 더 제한적인 DID 파편화 ABNF 규칙을 사용할 수 있다.

구현체는 DIDDID 파편화를 포함하고 있을 때, DID 문서 속에 포함된 메타데이터를 찾아내기 위해 DID 문서에 대해 그래프 기반 처리에 의존하지 않아야한다. 그 대신, 트리 기반 처리사 사용 될 수 있다.

구현은 JSON Pointer([[@RFC6901]])의 사용을 막지 않아야만 한다.

did:example:123456#oidc
      

노말라이제이션

상호 운용성을 높이기 위해, DID 정규화는 가능한 보편적이고 간단해야한다. 그러므로 :

지속성(영속성)

DID는 지속적이고 변화 불가능한 것으로 간주됩니다. 예를 들어 하나의 대상에만 오직 영원하고 배타적으로 종속됩니다. 심지어 DID가 비활성화 된 이후에도, 절대로 다른 목적으로 갖고 새롭게 사용되지 않아야한다.

이상적으로 DIDDID 레지스트리들에 여러 번 등록 될 수 있어서, 어떠한 특정한 시스템에도 독립적으로 존재할 수 있는 (UUID 처럼) 완벽히 추상화된 식별자가 되어야한다. 그러나, 동일한 식별자를 복수의 DID 레지스트리에 등록하는 것은 실재함을 극단적으로 힘들게 만들고, 권한 시작 문제를 발생시킵니다. 또한 개발자들이 이를 적용시키는데 있어서 복잡성을 높인다.

이러한 문제들을 피하기 위해, DID 메소드 정의는 DIDsDID 메소드가 시간이 지나도 지속이 될 수 있도록 최고의 수준의 노력을 할 수 있는 강력하고 안정적인 DID 레지스트리에만 등록되도록 하는 것을 추천한다

이 버전에는 도입되지 않았지만, 이 규격의 미래의 버전에는 다수의 DID 레지스트리에 동일안 추체로써 DIDs가 관계를 갖고 있다는 것을 증명할 수 있도록 DID 문서equivID 프로퍼티를 지원할 수 있다. 이러한 대등 관계는 하나의 지속적인 추상 DID의 실용적인 대등함을 만들어 낼 수 있다. 를 참조.

DID 문서

DIDDID 문서를 가리킨다. DID 문서들은 을 직렬화 한 것이다. 이번 섹션에서는 DID 문서의 속성과 이 속성들이 필수인지 옵션인지를 정의한다.

Contexts

두 개의 소프트웨어 시스템이 데이터를 교환해야 하는 경우 두 시스템이 이해할 수 있는 용어와 프로토콜을 사용해야 한다. @context 속성은 동일한 DID 문서에서 작동하는 두 시스템이 서로 동의하는 용어를 사용하도록 한다.

DID 문서는 반드시 @context 속성을 포함해야 한다.

JSON-LD Context에 대한 자세한 정보는 [[JSON-LD]] 사양에서 확인할 수 있다.

@context
@context 속성의 값은 반드시 하나 이상의 URIs 여야 하며, 여기서 첫 번째 URI의 값은 https://www.w3.org/ns/did/v1 이다. 둘 이상의 URI가 제공될 경우, URIs는 반드시 순서있는 배열로 해석되어야 한다. URIs를 역 참조하여 컨텍스트에 대한 기계 판독 가능한 정보가 포함된 문서를 생성 하는 것이 좋다.

Example:

{
  "@context": "https://www.w3.org/ns/did/v1"
}

DID 문서 규격은 자체 JSON-LD 컨텍스트를 정의 할 수 있다. 하지만 메소드를 올바르게 구현하는 데 필요한 경우가 아니면 새 컨텍스트를 정의하는 것은 권장하지 않는다. 메소드별 컨텍스트는 일반 DID 컨텍스트에 정의된 용어를 재정의하면 안된다.

DID 주체

DID 주체id 속성으로 표시된다. DID 주체는 DID가 식별하고 DID 문서가 설명하고자 하는 항목을 말한다.

DID 문서들은 반드시 id 속성을 포함해야 한다.

id
id의 값은 반드시 하나의 유효한 DID이어야 한다.

예시:

{
  "id": "did:example:21tDAKCERh95uGgKbJNHYp"
}
      

어떤 DID 메소드 규격은 DID 리졸버가 DID 해석을 수행하는 것과 같은 경우에 id라는 키를 가지고 있지 않은 중간 형태의 DID 문서를 생성할 수도 있다. 그러나, (중간 형태가 아닌) 완전하게 해석된 DID 문서는 항상 유효한 id 속성을 가지고 있다. 해석된 DID 문서에 있는 id의 값은 해석한 DID와 같아야 한다.

공개키

공개키는 인증( 참조)이나 서비스 엔드포인트 ( 참조)와의 안전한 통신 채널을 수립하는데 기초가 되는 전자서명, 암호화 그리고 암호 연산에 사용된다. 또한, 공개키는 DID 메소드 규격에 정의되는 DID의 CRUD 작업(참조)에 있어서 권한 부여 메커니즘으로 활용되기도 한다.

DID 문서publicKey 속성을 포함 할 수도 있다. 만약 포함한다면:

publicKey
publicKey 속성의 값은 반드시 공개키 객체들의 배열이어야 한다. 각 공개키 객체는 type, controller 속성 및 각 공개키에 특화된 속성을 반드시 포함하고 있어야 하며, id 속성을 포함해야 한다. 공개키 객체는 추가적인 속성도 포함할 수 있다.

(만약 존재한다면) id 속성의 값은 반드시 URI이어야 한다. 공개키의 배열에는 중복되는 id가 무조건 없어야 한다. 그런 경우, DID 문서 프로세서에서 반드시 에러를 발생시켜야만 한다.

type 속성의 값은 반드시 하나의 공개키 값이어야 한다 (사용 가능한 키 타입은 부록의 참조).

개인키와 관련된 컨트롤러를 식별하는 controller 속성의 값은 반드시 유효한 DID여야 한다.

모든 공개키의 속성들은 반드시 연결 데이터 암호화 수트 레지스트리(Linked Data Cryptographic Suite Registry)에 정의되어 있는 값이어야만 한다. 키 타입과 형식의 등록 정보는 부록 에서 확인할 수 있다.

만약 공개키가 DID 문서에 존재하지 않는다면, 반드시 그 키가 폐기되었거나 유효하지 않다고 간주해야 한다. 그 DID 문서에는 폐기된 키들을 포함하고 있을 수도 있다. 폐기된 키를 포함하고 있는 DID 문서는 반드시 그 키에 대한 폐기 정보들 포함하거나 참조하고 있어야 한다 (예. 폐기된 키 리스트). 각각의 DID 메소드 규격에는 키가 어떻게 폐기되고 그 정보가 어떻게 추적되는지 설명되어야 한다.

모든 공개키의 형식은 반드시 publicKeyJwk 속성을 사용한 JWK (JSON Web Key) 포맷이거나, 아래 표예 설명한 포맷 중에 하나여야 한다. 공개키의 표현형은 어떤 경우에도 다른 키의 포맷을 사용할 수 없다.

The Working Group is still debating whether the base encoding format used will be Base58 (Bitcoin) [[BASE58]], base64url [[RFC7515]] or base16 (hex) [[RFC4648]]. The entries in the table below currently assume PEM and Base58 (Bitcoin), but may change to base64url and/or base16 (hex) once the group achieves consensus on this particular issue.

The Working Group is still debating whether secp256k1 Schnorr public key values will be elaborated upon in this specification and if so, how they will be expressed and encoded.

Key Type Support
RSA RSA 공개키 값은 반드시 JWK로 인코딩하거나 publicKeyPem 속성을 사용하여 PEM(Privacy Enhanced Mail) 포맷으로 인코딩해야 한다.
ed25519 Ed25519 공개키 값은 반드시 JWK로 인코딩하거나 publicKeyBase58 속성을 사용하여 원시형태(raw)의 32 바이트 공개키 값을 Base58 비트코인 포맷으로 인코딩해야 한다.
secp256k1-koblitz Secp256k1 Koblitz 공개키 값은 반드시 JWK로 인코딩하거나 publicKeyBase58 속성을 사용하여 원시형태의 33바이트 공개키 값을 Base58 비트코인 포맷으로 인코딩해야 한다.
secp256r1 Secp256r1 공개키 값은 반드시 JWK로 인코딩하거나 publicKeyBase58 속성을 사용하여 원시형태의 32바이트 공개키 값을 Base58 비트코인 포멧으로 인코딩해야 한다.
Curve25519 (X25519로도 알려진) Curve25519 공개키 값은 반드시 JWK로 인코딩하거나 publicKeyBase58 속성을 사용하여 원시형태의 32바이트 공개키 값을 Base58 비트코인 포맷으로 인코딩해야 한다.

예시:

{
  "@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/security/v1"],
  "id": "did:example:123456789abcdefghi",
  ...
  "publicKey": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }, {
    "id": "did:example:123456789abcdefghi#keys-2",
    "type": "Ed25519VerificationKey2018",
    "controller": "did:example:pqrstuvwxyz0987654321",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }, {
    "id": "did:example:123456789abcdefghi#keys-3",
    "type": "Secp256k1VerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
  }],
  ...
}

키는 DID 문서포함되어 있거나 참조되어 있을 수 있다. 예를 들어, 아래의 authentication 속성은 두 가지 방식으로 키를 참조한다:

{
...

  "authentication": [
    // 이 키는 하나 이상의 목적으로 사용될 수 있도록 참조 방식을 사용한다
    "did:example:123456789abcdefghi#keys-1",
    // 이 키는 문서에 포함되어 있으며, *오직* 인증 목적으로만 사용할 수 있다
    {
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],

...
}

DID 문서에서 publicKey 속성을 처리할 때 사용하는 알고리즘은 다음과 같다:

  1. valuepublicKey 속성과 관련된 데이터로 세팅되고, resultnull로 초기화된다.
  2. 만약 value가 객체이면, 키 재료는 문서에 포함되어 있는 것이다. resultvalue로 세팅한다.
  3. 만약 value가 문자열이라면, 키는 참조 형식을 사용하는 것이다. value는 URL이라고 가정한다.
    1. URL이 참조하고 있는 곳을 찾아서, 그 URL과 연관된 publicKey 속성을 가져온다 (예를 들어 참조되고 있는 문서의 최상위부터 publicKey 속성을 처리한다).
    2. 각 공개키 객체에 대해 다음을 반복한다.
      1. 만약 객체의 id 속성이 value와 같다면, result를 그 객체로 세팅한다.
  4. 만약 resultid, type, controller와 같은 속성을 포함하고 있지 않거나 resulttype 속성에 따른 필수 공개 암호 재료를 포함하고 있지 않다면 에러를 발생시킨다.

위의 예시에서 controller 항목이 불필요해 보이지만, 키가 정의되는 DID 문서와 컨트롤러가 설명된 DID 문서가 다를 수 있기 때문에 필요하다. 연결 데이터 증명(Linked Data Proof) 라이브러리는 보통 controller 항목이 항상 존재한다고 가정하고 있으며, 만약 controller 필드가 없다면 예외를 발생시킬 수 있다. 게다가 DID 문서는 그래프나 트리 형태로 해석될 수 있다는 요구사항과 관련하여, 트리에서 키의 위치(position)를 이용해서 기본 controller 항목을 추론할 수 없다.

DID 문서에 설명된 키를 캐싱하고 만료시키는 것은 전적으로 DID 리졸버와 다른 클라이언트 프로그램의 책임이다. 참조.

인증

인증은 DID 컨트롤러가 해당 DID와 연결되어 있다는 것을 암호화 방식으로 증명할 수 있는 메커니즘이다. 을 참조. DID 컨트롤러는 다른 사람이 자신의 DID 문서에 대한 제어 권한을 증명하지 않고도 DID 문서를 업데이트하도록 (예. 에서 설명하고 있는 키 복구 지원 참조) 인증과 권한 부여가 분리되어 있다 (그러므로 DID 컨트롤러에 대한 위장이 가능함).

DID 문서는 무조건 authentication 속성을 포함해야한다. 그렇다면:

authentication
authentication 속성 값은 검증 메소드의 배열이어야 한다. 각각의 검증 방법은 포함되거나 참조될 수 있다. 검증 방법의 예로는 공개키 방식이 있다 (참조).

예제:

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  ...
  "authentication": [
    // 이 메소드는 DID(…fghi)로 인증시 사용할 수 있다
    "did:example:123456789abcdefghi#keys-1",
    // 이 메소드는 DID(…fghi)로 인증시 사용할 수 있다
    "did:example:123456789abcdefghi#biometric-1",
    // 이 방법은 인증을 위해 *전용*으로 권한을 부여받았으며,
    // 다른 증명 목적으로 사용될 수 없다.
    // 전체 설명은 참조를 사용하지 않고 포함된다.
    {
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],
  ...
}

인가 및 위임

인가는 DID 주체를 대신하여 작업이 어떻게 수행되는지에 대해서 설명하는데 쓰이는 메커니즘이다. 위임은 다른 사람이 DID 주체를 대신할 수 있도록 권한을 부여하는데 사용하는 메커니즘이다. 에서 설명한 바와 같이 인증과 인가는 분리되어 있다. 이는 키의 분실로 더 이상 키에 액세스 할 수 없거나 키가 유출되어 DID 컨트롤러의 제3신뢰기관들(trusted third parties)이 공격자의 악의적인 활동의 무효화(override)가 필요한 경우 키를 복구하기 위해 중요하다. 참고.

DID 메소드는 필수적인 암호화 연산을 포함하여 인가 및 위임이 구현되는 방법을 정의해야 한다.

인가 및 위임의 구현 방법에 대하여 최소한 2가지 방법이 제안되어 있으며 이는 서로 겹쳐 사용할 수 있다:

  1. DID 레지스트리DID 문서가 제어하는 다른 DID 컨트롤러DID를 표현하거나 추가하여 간략한 controller 패턴을 구현할 수 있다.
  2. DID 레지스트리는 인가 및 위임을 정교하게 제어 할 수 있는 기능 기반 접근 방식으로 구현할 수 있다.

예제:

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "controller": "did:example:bcehfew7h32f32h7af3",
  "service": [{
    // DID와 관련된 검증 가능 자격 증명의 검색 시 사용
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}
        

서비스 엔드포인트

DID 문서의 주요 목적은 서비스 엔드포인트를 검색할 수 있게 하는 것이다. 서비스 엔드포인트는 추가 탐색, 인증, 인가 또는 상호작용을 위한 탈중앙 ID 관리서비스를 포함하여 DID 주체가 공시하는 모든 유형의 서비스를 나타낼 수 있다.

DID 문서service 속성을 포함 할 수도 있다. 그렇다면:

service
service 속성의 값은 반드시 서비스 엔드포인트의 배열이어야 한다. 각 서비스 엔드포인트에는 무조건 type, serviceEndpointid 속성이 포함되어야 하며 추가적인 속성이 포함될 수 있다.

The value of the id property (if present) MUST be a URI. The array of service endpoints MUST NOT contain multiple entries with the same id. A DID document processor MUST produce an error in that case.

serviceEndpoint 속성의 값은 JSON-LD 객체이거나 [[RFC3986]]을 따르는 유효한 URI이어야하고, [[RFC3986]]의 6장 규칙 및 그 밖의 적용 가능한 URI 스킴 명세서의 규칙에 따라 정규화되어야 한다.

서비스 엔드포인트 프로토콜은 표준 명세서로 공개되어야 한다.

예제:

{
  "service": [{
    "id": "did:example:123456789abcdefghi#openid",
    "type": "OpenIdConnectVersion1.0Service",
    "serviceEndpoint": "https://openid.example.com/"
  }, {
    "id": "did:example:123456789abcdefghi#vcr",
    "type": "CredentialRepositoryService",
    "serviceEndpoint": "https://repository.example.com/service/8377464"
  }, {
    "id": "did:example:123456789abcdefghi#xdi",
    "type": "XdiService",
    "serviceEndpoint": "https://xdi.example.com/8377464"
  }, {
    "id": "did:example:123456789abcdefghi#agent",
    "type": "AgentService",
    "serviceEndpoint": "https://agent.example.com/8377464"
  }, {
    "id": "did:example:123456789abcdefghi#hub",
    "type": "IdentityHub",
    "publicKey": "did:example:123456789abcdefghi#key-1",
    "serviceEndpoint": {
      "@context": "https://schema.identity.foundation/hub",
      "type": "UserHubEndpoint",
      "instances": ["did:example:456", "did:example:789"]
    }
  }, {
    "id": "did:example:123456789abcdefghi#messages",
    "type": "MessagingService",
    "serviceEndpoint": "https://example.com/messages/8377464"
  }, {
    "id": "did:example:123456789abcdefghi#inbox",
    "type": "SocialWebInboxService",
    "serviceEndpoint": "https://social.example.com/83hfh37dj",
    "description": "My public social inbox",
    "spamCost": {
      "amount": "0.50",
      "currency": "USD"
    }
  }, {
    "id": "did:example:123456789abcdefghi#authpush",
    "type": "DidAuthPushModeVersion1",
    "serviceEndpoint": "http://auth.example.com/did:example:123456789abcdefg"
  }]
}

서비스 엔드포인트에 대한 추가 보안 고려 사항은 을 참조

생성

DID 문서에는 created 속성이 포함되어야 한다. 그렇다면:

created
created 속성 값은 W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes [[!XMLSCHEMA11-2]] 3.3.7장에 정의된 유효한 XML 날짜 및 시간이다. 날짜 및 시간 값은 "Z" 끝나게 표시되는 UTC 00:00으로 정규화되어야 한다.

예제:

{
  "created": "2002-10-10T17:00:00Z"
}

갱신

식별자 레코드의 표준 메타 데이터에는 가장 최근의 갱신에 대한 타임스탬프가 포함된다.

DID 문서에는 updated 속성이 포함되어야 한다. 그렇다면:

updated
updated 속성 값은 무조건 created 속성과 동일한 규칙을 따른다 ( 참조).

예제:

{
  "updated": "2016-10-17T02:41:00Z"
}

증명 (Proof)

DID 문서proof은 다음 중 하나에 따라 DID 문서의 무결성을 증명하는 암호화 증명이다:

  1. 섹션 5.2 에 정의 된 DID 주체 또는:
  2. 에 정의 된 DID 컨트롤러 (있는 경우).

이 증명은 DIDDID 문서간의 연관성(binding) 대한 증명이 아니다 (섹션 참조).

DID 문서proof 속성을 포함 할 수 있다. 그렇다면:

proof
proof 값은 무조건 링크 된 데이터 증명(Linked Data Proofs)에서 정의한 유효한 JSON-LD 증명이어야한다.

Example:

{
  "proof": {
    "type": "LinkedDataSignature2015",
    "created": "2016-02-08T16:02:20Z",
    "creator": "did:example:8uQhQMGzWxR8vw5P3UWH1ja#keys-1",
    "signatureValue": "QNB13Y7Q9...1tzjn4w=="
  }
}

확장성 (Extensibility)

탈중앙화 식별자 데이터 모델의 목표 중 하나는 비허가형 혁신을 가능하게하는 것이다. 이를 위해서는 데이터 모델을 다양한 방법으로 확장 할 수 있어야 한다:

This approach to data modeling is often called an "open world assumption", meaning that anyone can say anything about any other thing. This approach often feels in conflict with building simple and predictable software systems. Balancing extensibility with program correctness is always more challenging with an open world assumption than it is with closed software systems.

The rest of this section describes how both extensibility and program correctness are achieved through a series of examples.

다음과 같은 DID 문서로 시작한다고 가정 해 본다:

{
  "@context": "https://example.org/example-method/v1",
  "id": "did:example:123456789abcdefghi",
  "publicKey": [{ ... }],
  "authentication": [{ ... }],
  "service": [{ ... }]
}
      

이 섹션에서는 publicKey, authenticationservice 속성의 내용이 중요하지 않다. 중요한 것은 위의 개체가 유효한 DID 문서라는 것이다. 개발자가 추가 정보를 표현하기 위해 DID 문서를 확장하고 싶다고 가정 하자. 추가정보는 피사체의 공개 사진 스트림이다.

The first thing that a developer would do is create a JSON-LD Context containing the new term:

{
  "@context": {
    "PhotoStreamService": "https://example.com/vocab#PhotoStreamService"
  }
}
      

JSON-LD 컨텍스트가 생성되었으므로 개발자는 DID 문서 프로세서에 액세스 할 수있는 어떤 위치에 이를 무조건 게시해야한다. 예를 들어, 우리가 JSON-LD 컨텍스트 위의 다음 URL에 게시되어 있다고 가정하자 : did:example:contexts:987654321. 이 시점에서이 섹션의 첫 번째 예제를 확장하는 것은 위의 컨텍스트를 포함하고 DID 문서에 새 속성을 추가하는 간단한 문제이다.

{
  "@context": "https://example.org/example-method/v1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [ ... ],
  "service": [{
    "@context": "did:example:contexts:987654321",
    "id": "did:example:123456789abcdefghi#photos",
    "type": "PhotoStreamService",
    "serviceEndpoint": "https://example.org/photos/379283"
  }]
}
      

지금까지의 예시에서는 탈중앙화 식별자 데이터 모델을 탈중앙화 방식으로 쉽게 확장 할 수 있음을 보여주었다. 또한 이 방식으로 생성 된 탈중앙화 식별자가 네임 스페이스 충돌 및 의미상 모호성을 방지한다.

동적 확장성 모델은 구현 부담을 증가시킨다. 이러한 시스템 용으로 작성된 소프트웨어는 응용 프로그램의 위험 프로파일에 따라 확장명이 포함 된 DID 문서를 수락 할 수 있는지 여부를 결정해야한다. 일부 응용 프로그램은 확장을 허용하지만 무시하도록 선택하고 다른 응용 프로그램은 특정 확장만 허용하도록 선택할 수 있지만 보안 수준이 높은 환경에서는 확장이 허용되지 않을 수 있다. 이러한 결정은 응용 프로그램 개발자에게 달려 있으며 특히 이 사양의 영역이 아니다.

Implementations MUST produce an error when an extension JSON-LD Context overrides the expanded URL for a term specified in this specification. To avoid the possibility of accidentally overriding terms, developers SHOULD scope their extensions. For example, the following extension scopes the new PhotoStreamService term so that it may only be used within the service property:

{
  "@context": {
    "service": {
      "@id": "https://w3id.org/did#service",
      "@context": {
        "PhotoStreamService": "https://example.com/vocab#PhotoStreamService"
      }
    }
  }
}
      

Developers are urged to ensure that extension JSON-LD Contexts are highly available. Implementations that cannot fetch a context will produce an error. Strategies for ensuring that extension JSON-LD Contexts are always available include using content-addressed URLs for contexts, bundling context documents with implementations, or enabling aggressive caching of contexts.

DID 문서의 문법

DID 문서는 반드시 [[!RFC8259]] 규격을 따르는 하나의 JSON 객체여야만 한다. 이 문서에서 설명하고 있는 많은 개념들은 JSON-LD 문법을 사용하는 예제를 활용하여 소개하고 있다. JSON-LD는 JSON 데이터를 RDF 의미 모형과 매핑하는 형식이며, [[!JSON-LD]] 규격에 정의되어 있다. 이번 장에서는 데이터 모델( 참조)이 어떻게 JSON-LD로 나타나는지에 대해 명세한다.

비록 문법상의 매핑(syntactic mapping)이 JSON과 JSON-LD로만 제시된다 하더라도, 응용프로그램과 서비스는 이와 다른 데이터 모델 표현 도구인 JXD (JSON XDI Data, XDI 그래프 모델을 위한 직렬화 형식)나 XML, YAML, CBOR과 같이 다양한 종류의 데이터 표현 문법을 사용할 수 있다.

JSON

데이터 모델( 참조)은 JSON(Javascript Object Notation, [[RFC8259]])으로 인코딩될 수 있으며, 다음과 같이 속성값을 JSON 타입에 매핑한다:

JSON-LD

[[!JSON-LD]]는 JSON 기반의 형식이며, 연결 데이터(Linked Data)를 직렬화하는데 사용한다. JSON-LD의 문법은 이미 JSON을 사용하고 있는 시스템에 쉽게 통합할 수 있도록 설계되었고, JSON에서 JSON-LD로의 업그레이드를 매끄럽게 할 수 있는 방법을 제공한다. 웹 기반 프로그래밍 환경에서 연결 데이터를 사용할 수 있도록 하고, 상호 운용 가능한 웹서비스를 만들 수 있도록 하며, 연결 데이터를 JSON 기반 저장소 엔진에 저장하는데 주안점을 두고 있다.

JSON-LD는 이 명세서에서 설명하고 있는 데이터 모델을 확장할 때 유용하다. 데이터 모델의 인스턴스는 JSON ( 참조) 형식으로 인코딩되는 것과 같은 방식으로 JSON-LD로 인코딩되며 @context 속성만 추가하면 된다. JSON-LD 컨텍스트에 대한 상세한 내용은 [[!JSON-LD]] 명세서에서 설명하고 있고, 그 사용법은 섹션에서 자세히 다루고 있다.

일반적으로, 이 문서에서 설명하는 데이터 모델과 문법은 개발자가 예제를 복사하여 자신들의 시스템에 붙여넣어 사용할 수 있도록 설계되었다. 이러한 접근법을 선택하게 된 설계 목표는 서로 다른 소프트웨어 간에 글로벌한 상호 운용성을 보장하기 위한 진입 장벽을 낮추는 것이다. 이번 장에서는 이런 접근법 중 일부에 대해 설명할 것이다. 이러한 접근법은 대부분의 개발자의 눈에는 잘 띄지 않지만 구현자들은 관심을 가질 수 있는 상세한 내용이다. JSON-LD가 제공하는 주목할만한 기능은 다음과 같다:

DID 메소드

DID 메소드 체계

DID 메소드 규격은 정확하게 메소드별 DID 체계마다 식별이 가능한 정확한 하나의 메소드 이름이 반드시 정의해야 한다. (method-name 규칙은 에 따른다)

메소드 이름은 DID의 일부이므로, 짧은 메소드 이름이 선호된다. 메소드 이름은 5자 이하여야 한다. 메소드 이름은 DID 메소드 규격이 적용되는 DID 레지스트리의 이름을 반영할 수 있다. (.)

메소드별 DID 체계를 위한 DID 메소드 규격에는 DID의 구성요소인 method-specific-id를 어떻게 생성하는지 반드시 명시가 되어있어야 한다. method-specific-id는 반드시 중앙화 된 레지스트리 서비스를 이용하지 않고 생성할 수 있어야 한다. method-specific-id는 범용(범세계)적으로 고유해야 한다. did 규칙은 에 정의되어 있으며, 반드시 전세계적으로 고유해야 한다.

필요하다면, 메소드별 DID 체계는 다수의 method-specific-id 형식을 정의할 수 있다. (하지만) 가능한 소수의 method-specific-id 형식을 정의하는 것을 권장한다.

DID 기능

특정 DID 레지스트리에서 DIDsDID 문서의 전체 기능을 사용하려면 클라이언트에 의해 수행되는 다음 CRUD 작업이 DID 메소드 규격에 반드시 지정되어 있어야 한다. 각 조작은 DID 레지스트리와 상호운용 가능한 클라이언트 구현을 빌드하고 시험할 수준의 세부사항을 지정해야 할 필요가 있다. 이러한 조작은 CKMS(cryptographic key management system)에 필요한 모든 조작을 효과적으로 수행할 수 있다. 예를 들면 키 등록, 키 교체, 키 회전(key rotation), 키 복구, 키 만료 들이다.

업데이트 또는 비활성화와 같은 특정 작업을 지원하지 않는 DID 메소드 규격은 이러한 제한을 반드시 명확하게 명시해야 한다.

생성 (Create)

DID 메소드 규격은 클라이언트가 DID 및 관련 DID 문서DID 레지스트리에 어떻게 생성할지 명시해야 하며, 여기에는 제어증명 입증을 위한 모든 암호화 작업이 포함된다.

읽기/검증 (Read/Verify)

DID 메소드 규격은 클라이언트가 DID를 사용하여 DID 레지스트리DID 문서를 요청하는 방법, 클라이언트가 응답의 진위를 확인할 수 있는 방법을 반드시 명시해야 한다.

갱신 (Update)

DID 메소드 규격은 클라이언트가 DID 레지스트리DID 문서를 갱신 할 수 있는 방법을 반드시 명시해야 한다. 여기에는 제어증명 입증을 위한 모든 암호화 작업, 또는 업데이트가 불가능하다는 상태가 포함된다.

비활성화 (Deactivate)

DID 메소드 규격은 클라이언트가 DID 레지스트리DID를 비활성화 할 수 있는 방법을 반드시 명시해야 한다. 여기에는 제어증명 입증을 위한 모든 암호화 작업, 또는 비활성화가 불가능하다는 상태가 포함된다.

고유한 DID 메소드 이름 (Unique DID Method Names)

새로운 DID 메소드 규격의 저자는 발표 당시 알려진 모든 DID 메소드 이름들과 중복되지 않는 고유한 메소드 이름을 사용해야만 한다.

DID 메소드 이름을 할당하거나 승인 할 수 있는 권한을 가진 중앙기관이 없기 때문에 특정 DID 메소드 이름이 고유한 지 확인할 방법이 없다. 이 문제를 해결하기 위해 W3C Credentials Community Group은 알려진 DID 메소드 이름과 관련 규격의 비권한 목록을 유지한다(Appendix 참조)

[[DID-METHOD-REGISTRY]]는 새로운 메소드 명칭을 합의할 때 구현자가 참조 할 수 있는 도구이며, 또한 다른 DID 메소드DID 리졸버를 구현하는 소프트웨어 개발자가 참조 할 수 있는 정보가 된다. 좀 더 많은 DID 리졸버에 대한 정보는 을 참고 할 것. [[DID-METHOD-REGISTRY]]는 DID 메소드의 확정적 또는 공식적인 목록이 아니다. 그럼에도 불구하고, [[DID-METHOD-REGISTRY]]에 DID 메소드 이름을 추가하여 다른 구현자와 커뮤니티 구성원이 기존 DID 메소드의 개요를 한곳에서 볼 수 있도록 하는 것을 장려한다. DID 메소드 이름을 추가하기 위한 간략한 기준은 [[DID-METHOD-REGISTRY]]에 문서화되어 있다.

DID 리졸버

DID 리졸버DID를 해석하는데 필요한 API를 제공하는 소프트웨어 또는 하드웨어를 말하며, DID 해석을 위해 DID는 하나 이상의 DID 메소드를 가져야한다. DID 리졸버는 믿을 만한(authoritative) DID 문서를 조회하기 위하여, 해석하려는 DID와 연관된 DID 메소드의 읽기 명령을 수행한다. 더 자세한 내용은 참조.

DID를 해석하고 DID URL을 역참조하기 위한 인터페이스와 알고리즘은 [[DID-RESOLUTION]]에 명시되어 있다.

보안 고려사항 (Security Considerations)

개발자의 초안 단계에서 이 장은 초기 구현에 중요한 보안 주제에 중점을 둔다. 또한, 편집자들은 본 장 또는 사양의 다른 부분에 반영되어야만 하는 위협 및 위협 완화에 대한 피드백을 탐색한다. 탈중앙 식별자(DIDs) 및 DID 문서에 대한 루트 식별자 레코드는 탈중앙 ID 관리의 필수 구성 요소이다. 또한 기존 X.509 인증서를 보완하는 탈중앙 공개키 인프라 (DPKI)의 기본 구성 요소이다. 따라서 DID는 많은 IETF 표준에서 사용하는 일반적인 인터넷 위협 모델에서 작동하도록 설계되었다. 우리는 침해되지 않는 엔드포인트를 가정하지만 네트워크상에서 메시지가 읽혀지거나, 손상될 수 있음을 고려해야 한다. 시스템이 손상되었을 때 공격으로부터 보호하려면 외부 키 서명 하드웨어가 필요하다. 키 폐기 및 복구에 관한 참조. DIDDID 문서를 호스팅하는 DLT에는 능동적인 공격을 방지하기 위한 특별한 보안속성이 있다. 이 설계는 공개키 암호화를 사용하여 개인키가 손상 될 위험없이 수동적으로 모니터링되는 네트워크에서 작동할 수 있다. 이로 인하여 DID 아키텍처와 분산 ID를 가능하게 한다.

DID 메소드 사양의 요구 사항

DID 메소드의 요구사항 명세는 다음과 같다:

DID 리졸버 선택

[[DID-METHOD-REGISTRY]]는 DID 메소드 이름 및 해당 DID 메소드 사양에 대한 정보를 제공하는 목록이다. 개발자는 특정 DID 메소드 이름과 함께 사용해야하는 DID 메소드 사양을 위임 할 CA가 없다는 것을 알아두어야 하지만, DID 메소드 사양은 특정 DID 메소드 이름과 함께 사용해야 하고 [[DID-METHOD-REGISTRY]]를 사용하여 사용할 DID 리졸버 구현을 선택할 때 결정을 내릴 수 있다.

신원의 결합

다음 섹션은 DIDDID 문서에 신원을 결합하는 것에 대해 설명하고 있다.

DID와 DID 문서에 대한 컨트롤 증명하기

서명은 DID 문서가 암호학적으로 검증 가능하도록 하는 하나의 수단이다.

DID 문서에 대한 검증된 서명 자체는 DID에 대한 컨트롤을 증명하지 못한다. 그것은 단지 아래 내용만을 증명한다:

  • DID 문서는 그것이 등록된 이후 변조되지 않았다.
  • DID 컨트롤러는 서명이 생성된 시점의 서명을 위해 개인키를 컨트롤 했다.

DID의 컨트롤을 증명하는 것 즉, DID와 그것을 설명하는 DID 문서 사이를 결합하는 것은 다음 두 가지 과정을 필요로한다:

  1. DIDDID 메소드 명세에 따라 주소분해 한다.
  2. DID 문서id 프로퍼티가 주소분해된 DID와 일치하는지 검증한다.

주목해야 할 점은 이 과정이 DID 문서가 서명되었는지의 여부와 상관없이 DIDDID 문서의 컨트롤을 증명한다는 점이다.

DID 문서에 대한 서명은 선택사항이다. 만약 가능하다면, DID 메소드 명세는 그것의 구현에 대해 반드시 설명해 주어야 한다.

타임스탬프와 서명을 결합하는 것은 좋은 사례이다.

공개키에 대한 컨트롤 증명하기

DID 문서의 공개키에 대응하는 개인키의 증명에는 두가지 방법이 있다: 정적 그리고 동적.

정적 방법은 DID 문서를 개인키로 서명하는 것이다. 이것은 DID 문서가 등록된 시점 까지의 개인키에 대한 컨트롤을 증명한다. 만약 DID 문서가 서명되지 않았다면, DID 문서 상의 공개키는 다음과 같은 동적 방법으로 증명할 수 있다:

  1. DID 문서공개키 설명(Description)을 포함한 신청 메세지를 보낸다. 그리고 DID 문서에 설명된 적절한 서비스 엔드포인트에 논스를 전달한다.
  2. 공개키 설명에 대한 반응 메세지의 서명을 검증한다.

인증과 Verifiable Claim

DIDDID 문서개인식별정보(PII)를 포함하여 전달하지 않는다. DID와 사람 혹은 회사 같은 실 세계의 무언가와 결합하는 과정(예를들면, DID의 동일 주체에 대한 Credential)은 본 규격에서 다루지 않는다. 더 상세한 내용은 [[VC-DATA-MODEL]]을 참고.

인증 서비스 엔드포인트

만약 DID 문서DID 주체에 대한 인증 혹은 승인을 위한 서비스 엔드포인트를 발행했을 경우(섹션 참조), 해당 서비스 엔드포인트에서 지원하는 인증 프로토콜의 요구사항을 만족시키는 것은 서비스 엔드포인트, 주체, 그리고 연계된 조직의 책임이다.

부인방지

DIDDID 문서의 업데이트에 대한 부인 방지는 다음과 같은 가정 아래 지원된다:

DID 문서 변화 알림

DID 문서의 승인되지 않은 변화에 대한 하나의 완화방안은 DID 주체를 모니터링하고 적극적으로 알리는 것이다. 이것은 전통적인 유저명/패스워드 계정의 계정 탈취를 막기 위해 패스워드 재설정에 대한 알림을 이메일 주소로 전달하는 것과 유사하다. 알림을 생성해 줄 중개 등록자 혹은 계정 공급자가 없는 DID의 경우, 다음과 같은 방법이 제안된다:

키 또는 서명 만료

탈중앙 식별자 아키텍처에는 키 또는 서명 만료 정책을 시행할 중앙 권한이 없다. 따라서 DID 리졸버 및 기타 클라이언트 프로그램은 키를 사용할 때 만료되지 않았는지 확인해야한다. 일부 사용 사례에는 이미 만료 된 키를 확장해야하는 합당한 이유가 있을 수 있으므로 만료가 되어도 키의 추가사용을 막지 않아야하며 리졸버를 구현할 때 이런 확장 기능을 호환가능하게 만들어야 한다.

키 해지 및 복구

섹션 은 업데이트 된 DID 문서로 교체하여 DID 문서를 비활성화 하는방법을 포함한 DID 메소드 사양에서 지원해야하는 DID 작업을 설명한다. 일반적으로 DLT 기반에서 키 해지여부 확인은 분산 원장에서 암호 화폐 게정의 잔액을 확인하는 것과 유사한 방식으로 처리 된다: 잔액이 비어있으면 DID 전체가 비활성화 된것이다. DID 메소드 사양은 신뢰하는 집단의 합의를 통해 키 복원을 지원해야한다. 그렇게 할 수 있는 방법들은 섹션 에 나와있다. 참고해야 할 것은 모든 DID 메소드 사양이 다른 DID 메소드를 사용하여 등록 된 DID의 제어를 인식하는 것은 아니며 타사 제어를 동일한 방법을 사용하는 DID로 제한 할 수 있다는 점이다. DID 메소드 사양의 접근 제어 및 키 복구에는 복구를 위한 두번째 제어 권한을 유지하는 방식으로 키 손상을 일으키는 방식을 방지하는 시간 잠금 기능도 포함 될 수 있다. 이러한 유형의 제어에 대한 추가 사양은 향후 작업의 문제이다. (섹션 참조)

인간 친화적 식별자의 역할

DID들은 중앙 등록 기관이 없어도 글로벌 독창성을 달성한다. 그러나 이것은 인간의 기억력을 희생시키면서 발생한다. 전역적으로 고유한 식별자를 생성 할 수 있는 알고리즘은 의미가없는 임의의 문자열을 자동으로 생성한다. 이것은 Zooko의 Triangle(Zooko's Triangle)으로 알려진 식별자에 대한 공리를 보여준다 : "의미, 탈중앙화, 안전. 셋 중 아무거나 둘을 선택하십시오".

물론 인간 친화적인 식별자 (이메일 주소, Twitter 핸들 또는 블로그 URL등과 같은 DID 컨트롤러의 주소, 자연어 이름, 도메인 이름 또는 휴대 전화 번호)에서 시작할 때 DID를 발견하는 것이 바람직한 많은 경우가 있다. 그러나 사람에게 친숙한 식별자를 DID들에 매핑 (및 확인 및 신뢰할 수있는 방식으로)하는 문제는 다른 이야기 이다.

이 문제에 대한 해결책들은 여러가지 사양들 별로 별도의 정의가 필요하다. 정의시 다음과 같은 사양들을 신중하게 고려하는 것 이 좋다:

불변성

많은 사이버 보안 침해는 현실과 합리적이고 선의의 이용자들의 이상 사이의 격차를 이용하는 데 달려 있다. 다른 생태계와 마찬가지로, DID 생태계는 이것이 일어날 가능성이 있다. 이 사양은 프로토콜이 아닌 데이터 모델에 중점을 두기 때문에 해당 모델의 사용 방식에 대한 여러 측면에 대한 의견을 제시하지 않았다. 그러나 개별 DID 메소드들은 필요하지 않은 동작이나 의미를 제거하는 제약 조건을 고려할 수 있다. DID 메소드잠금(locked down)상태 일수록 동일한 기능 세트를 제공하는 반면 악의적인 행위자가 조작 할 수있는 수준은 줄어 든다.

예를 들어, 데이터 모델이 업데이트와 관련하여 제공하는 유연성을 고려해보자. DID 문서를 한 번만 편집하면 문서의 루트 ID 속성을 제외한 모든 항목을 변경할 수 있으며 데이터 모델의 개별 JSON 객체는 root id를 제외한 모든 속성을 변경할 수 있다. 그러나 서비스 엔드포인트가 일단 정의되면 type을 변경하는 것이 실제로 바람직한가? 아니면 가치를 바꾸는 열쇠가 필요한가? 아니면 객체의 특정 기본 속성이 변경 될 때 새로운 id를 요구하는 것이 더 좋은가? 웹 사이트의 악의적인 인수는 종종 사이트가 자신의 식별자 (호스트 이름)를 유지하지만 그 아래에 미묘하고 위험한 변화를 가져 오는 결과를 목표로 한다. 사양에 따라 사이트의 특정 속성을 변경할 수없는 경우 (예 : IP 주소와 관련된 ASN) 이러한 공격을 수행하는 데 훨씬 더 어렵고 비용이 많이 들며 이상 탐지가 더 쉬울 수 있다.

불변성이 일부 사이버 보안 이점을 제공 할 수 있다는 개념은 캐싱 때문에 특히 관련이 있다. 전 세계 진실 소스에 연결된 DID 메소드들의 경우 최신 버전의 DID 문서를 적시에 직접 조회 할 수 있다. 그러나 캐시 레이어는 결국 클라이언트와 해당 소스 사이에 있을 수 있다. 만약 그렇다면, 실제로 미묘하게 다른 DID 문서에있는 객체(object)의 속성이 주어진 상태를 가지고 있다고 믿으면 활용을 증대 할 수 있습니다. 일부 조회가 전체 DID 문서이고 다른 조회가 부분적인 데이터 인 경우 더 큰 맥락이 가정되는 경우에 특히 그렇습니다.

프라이버시 고려사항

DIDs 및 DID 문서는 설계 상 DID 컨트롤러에 의해 직접 관리되므로, 프라이버시 디자인 (Privacy by Design) 원칙을 분산 식별자 아키텍처의 모든 측면에 적용하는 것이 매우 중요하다. 추가적으로 프라이버시 보호를 권장하거나 적용할 등록 기관, 호스팅 회사 또는 기타 중간 서비스 제공 업체는 없다. 이 규격의 저자는 개발 전반에 걸쳐 7가지 프라이버시 디자인(Privacy by Design) 원칙을 모두 적용했다. 예를 들어, 이 규격에서 프라이버시는 예방적이지 교정적이지 않다. 프라이버시는 기본 설정이다. 또한 decentralized identifier 아키텍처 자체는 원칙 # 7, "Respect for user privacy — keep it user-centric."를 구현한다. 이 섹션에는 구현자(implementers), 대리인(delegates) 및 DID 주체가 염두에 두어야 할 추가 프라이버시 고려 사항이 나열되어 있다.

DID 메소드 규격의 요구사항

  1. 이 섹션의 일반적인 프라이버시 고려사항만 가리키는 경우, DID 메소드 규격에는 반드시 자체 프라이버시 고려사항 섹션이 포함되어야한다.
  2. DID 메소드 규격의 프라이버시 고려사항 섹션은 메소드에 따라 적용 할 수있는 [RFC6973]의 5 항의 하위 섹션을 반드시 논의해야한다. 고려해야 할 하위 섹션은 ‘감시, 저장된 데이터 손상, 원치 않는 트래픽, 잘못된 속성, 상관 관계, 식별, 2차 사용, 공개, 예외’가 있다.

개인 식별 정보 비공개 유지

DID 메소드 규격이 모든 DIDsDID 문서를 공개적으로 사용할 수 있는 공개DID 레지스트리에 대해 작성된 경우, DID 문서에 PII가 포함되지 않도록 하는 것은 매우 중요하다. 모든 PII는 DID 주체의 통제 하에 서비스 엔드포인트 뒤에서 유지되어야 한다. With this privacy architecture, PII may be exchanged on a private, peer-to-peer basis using communications channels identified and secured by public key descriptions in DID documents. 이 프라이버시 설계를 통해, PII는 DID 문서공개키 설명으로 식별되고 보안되는 통신 채널을 사용하여, 피어 투 피어 기반으로 교환 될 수 있다. 또한 이것은 불변의 분산 장부에 PII가 기록되지 않기 때문에, DID 주체와 신뢰 당사자가 GDPR right to be forgotten를 구현할 수 있다.

DID 상관 관계 위험과 유사 DIDs

모든 유형의 전역적 고유 식별자와 마찬가지로, DIDs 상관 관계에 사용할 수 있다. DID 컨트롤러는 쌍으로 된 고유한 DIDs 사용하거나, 모든 관계에 대해 다른 개인용 DID를 공유함으로써 프라이버시 위험을 완화할 수 있다. 실제로 각 DID는 익명으로 사용된다. 익명 DIDDID 주체가 당사자 간의 상관 관계를 명시적으로 승인한 경우 둘 이상의 당사자끼리만 공유하면 된다. 익명 DIDs가 기본 값일 때, 공개 DIDs (공개적으로 발행되었거나 다수의 당사자와 공유된 DIDs)가 필요한 경우는 DID 주체가 명시적으로 공개 식별을 원할 때 뿐이다.

DID 문서 상관 관계 위험

해당 DID 문서의 데이터를 연관시킬 수 있으면 익명 DIDs의 안티-상관관계 보호는 쉽게 무너진다. 예를 들어, 여러 DID 문서에서 동일한 공개키 설명 또는 맞춤형 서비스 엔드포인트를 사용하면 동일한 DID를 사용하는 것과 같은 수준의 상관 정보를 제공 할 수 있다. 따라서 익명 DID에 대한 DID 문서도 쌍별로 고유한 공개 키를 사용해야 한다. 익명 DID에 대해 DID 문서에서 쌍별로 고유한 서비스 엔드포인트를 사용하는 것도 자연스러운 것처럼 보일 수 있다. 그러나 고유한 엔드 포인트를 통해 DIDs 간 모든 트래픽을 타이밍 상관 관계와 유사한 분석이 용이한 고유한 버킷으로 완벽하게 분리할 수 있다. 따라서 엔드 포인트 프라이버시를 위한 더 나은 전략은 많은 다른 주체에 의해 제어되는 수천 또는 수백만 개의 DIDs 간에 엔드 포인트를 공유하는 것이다.

군중 프라이버시

DID 주체가 군중의 다른 사람들과 구별되지 않는 경우, 프라이버시 보호가 가능하다. 다른 당사자와 개인적으로 참여하는 행위가 그 자체로 인식 가능한 플래그(flag)인 경우, 프라이버시가 크게 훼손된다. DIDsDID 메소드는 군중 프라이버시의 보호, 특히 합법적으로 가장 필요한 사람들의 프라이버시를 개선하기 위해 작동해야한다. 익명성과 가명성을 유지하는 데 도움이 되는 기술과 휴먼 인터페이스를 선택해야 한다. 디지털 지문을 줄이려면, 클라이언트 구현에서 공통 설정을 공유하고, 협의된 옵션을 유선 프로토콜에서 최소로 유지하고, 암호화 된 전송 계층을 사용하고, 메시지를 표준 길이로 채워야 한다.

Future Work

DID 문자열 길이의 상한

현 규격에서는 DID의 최대 길이에 대한 부분이 없다. 상호 운용가능한 URL의 최대의 길이는 약 2천자 정도이다. QR 코드는 약 4천자를 다룰 수 있다. DIDs를 사용하는 클라이언트는 최대한 많이 DIDs를 저장해야하고, 일부 메소드들은 DIDs가 임시적으로 사용된다는 상태를 추가하거나 좀 더 복잡한 시그니처 스키마에 의존함으로써 비용의 일부를 외부화 할 수 있을 것이다. 이 규격의 미래 버전에서는 합리적인 수준의 DID 문자열 길이 제한을 통해 외부성을 최소화할 것입니다.

동치관계

equivID와 같은 동치관계 속성을 도입하여, DIDs의 배열을 값으로 갖는 DID 문서 안에서의 주체들이 두개 혹은 더 많은 DIDs이 동일한 주체를 가리킨다는 것을 주장할 수 있다. 이 능력은 DID 레지스트리 간 이전을 지원하거나, 미래의 DID 레지스트리에 기존의 DIDs를 전달하는 등의 다양한 용도를 갖고 있다. 이론적으로 동등한 DIDs는 동등한 DIDs에게 적용할 수 있는 한 DID에서 만들어진 증명 가능한 주장을 가능케 하는 같은 식별자 권한을 가져야한다. 동치관계는 다른 DLTs 사이와 다른 DID 메소드, 그리고 동일한 DID 문서의 종합적인 특징들 사이에서 동등함을 증명하는 것의 복잡함 떄문에 현 규격에서는 포함되지 않는다. 그러나 동치관계는 이 규격의 미래 버전에서 지원되어야한만다.

타임스탬프

증명가능한 타임스탬프는 식별자 레코드에서 명백한 용도를 갖고 있다. DLTs에게 잘 어울리는데, DLTs는 일종의 타임스탬프 메커니즘을 제공하기 때문이다. 트랜젝션 비용에 비해, DLTs는 이 세상에서 가장 검열 저항적인 트랜젝션 정렬 시스템이기에 DID 문서의 타임스탬프 저장에 거의 이상적이다. 일부 상황에서 DLT은 근사적인 시간 관념을 쓰지만, "평균 시간 지연" (비트코인 BIP 113을 보라)으로 명료하게 정의될 수 있다. 범용적인 DID 문서의 타임스탬프 매터니즘은 모든 DLTs에 적용될 수 있고, 트랜젠션들이나 트랜젝션의 배치들을 통한 매커니즘을 통해 작동될 수 있다. 범용적인 매커니즘은 이 버전의 목적에 벗어나지만, 이 규격의 미래 버전에서는 포함될 것이다.

타임 락과 DID 문서 복구

세션에서 키의 훼손 이후 DID의 제어 복구에 대한 타임 락에 대한 영리한 실제 사용 가능한 방법을 이야기했다. 이 기법은 공격자를 무력화하기 위해 이전 버전의 DID 문서에 적용된 인가로 제일 최신의 DID 문서 업데이트를 덮어 씌우는 것에 의존한다. 이러한 방어 기법은 트랜젝션 체인을 보호하기 위해 타임 락 (비트코인 BIP 65 보라)을 추가하여, 제어 복구를 위한 인가 블록을 활성화 할 수 있다. 우리는 이 규격의 미래 버전에서 타임 락의 지원을 포함 시킬 것이다.

스마트 서명

모든 DLTs 세션의 인가 로직을 지원하는 건 아니다. 그러무로, 현 규격의 현재 버전에서는 모든 인가 로직은 DID 메소드에 위임한다. 잠재적인 대안은 서명 제어 로직으로 DLT가 적용할 수 있는 스마트 서명 규격이다.

증명가능한 주장

DIDsDID 문서가 탈중앙화된 신원을 위한 기반을 제공해도, 그들의 주체를 설명하는 첫 단계에 불과하다. 나머지의 설명가능한 능력은 증명가능한 주장을 모으고 선택적으로 사용함으로써 나온다. 미래의 버전의 규격에서는 DIDsDID 문서가 증명가능한 주장 생태계와 통합될 수 있는지 (그리고 작동되게 도움이 되는지)에 대해서 설명할 것이다.

그래프 모델과 시리얼라이제이션의 대안

현재 규격의 버전에서는 DID 문서의 표현을 위해 JSON-LD와 RDF 그래프 모델을 사용한다. 미래의 버전에서는 DID 문서을 위한 다른 의미 그래프 포맷을 명시할 수 있다.

현재 이슈

현재 활발하게 논의되고 있고 이 규격에 변화를 줄 수 있는 이슈사항들의 목록이다.

Syntactially differentiate data about the DID versus application data
Add `initial-values` matrix parameter to Generic DID Parameters
Define conformance classes such as "DID document processor"
Bikeshed the DID specification short name
tracking revocation of public keys
Privacy Considerations - Specifically call out GDPR
Enable instant DID use/resolution for DID Methods that include a propagation delay
How to integrate certificates with DIDs?
When do we publish a FPWD?
Supported public key formats?
Does DID Document metadata belong in the Document?
Encrypted serviceEndpoint values?
Add publicKeyHex as a valid publicKey format
Add "service-type" DID URL matrix parameter.
Add "content-type" and "content-id" DID URL matrix parameters.
Add "key-type" DID URL matrix parameter.
Add "key" DID URL matrix parameter.
Registry handling
Clarification of other verification methods in authentication section missing
Added support for ethereumAddress in context - fixed #55
Add support for ethereumAddress public key type in @context
Normative vs. non-normative references
(Minor note) update the IANA file
[Convention] Method `0` (zero) become a well-known method for retrieving properties/metadata from/about a particular DID Server
If an existing DID Document has a Service Endpoint fragment, what are the primary keys to be used if that Service Endpoint needs to be replaced, updated, or deleted?
Some comments by Steven Rowat
It would be useful to have `services` as a mapping instead of an `array`
Is method-specific-id supposed to be equivalent to param-char?

레지스트리

이 규격을 바탕으로 DID 메소드를 정의하는 다수의 레지스트리들이 있다. 그 목록은 다음과 같다:

레지스트리 목적
DID 메소드 레지스트리 모든 DID 메소드들과 그들의 상세 규격에 대한 목록
Linked Data Cryptography Suite Registry 알려진 모든 Linked Data Cryptography Suites와 Key Format을 정의

실사용 예제

미래지향적 실사용 예제는 다음과 같다:

{
  "@context": "https://w3id.org/future-method/v1",
  "id": "did:example:123456789abcdefghi",

  "publicKey": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }, {
    "id": "did:example:123456789abcdefghi#keys-3",
    "type": "Ieee2410VerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],

  "authentication": [
    // this mechanism can be used to authenticate as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
    // this mechanism can be used to biometrically authenticate as did:...fghi
    "did:example:123456789abcdefghi#keys-3",
    // this mechanism is *only* authorized for authentication, it may not
    // be used for any other proof purpose, so its full description is
    // embedded here rather than using only a reference
    {
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],

  "service": [{
    "id": "did:example:123456789abcdefghi#oidc",
    "type": "OpenIdConnectVersion1.0Service",
    "serviceEndpoint": "https://openid.example.com/"
  }, {
    "id": "did:example:123456789abcdefghi#vcStore",
    "type": "CredentialRepositoryService",
    "serviceEndpoint": "https://repository.example.com/service/8377464"
  }, {
    "id": "did:example:123456789abcdefghi#xdi",
    "type": "XdiService",
    "serviceEndpoint": "https://xdi.example.com/8377464"
  }, {
    "id": "did:example:123456789abcdefghi#hub",
    "type": "HubService",
    "serviceEndpoint": "https://hub.example.com/.identity/did:example:0123456789abcdef/"
  }, {
    "id": "did:example:123456789abcdefghi#messaging",
    "type": "MessagingService",
    "serviceEndpoint": "https://example.com/messages/8377464"
  }, {
    "type": "SocialWebInboxService",
    "id": "did:example:123456789abcdefghi#inbox",
    "serviceEndpoint": "https://social.example.com/83hfh37dj",
    "description": "My public social inbox",
    "spamCost": {
      "amount": "0.50",
      "currency": "USD"
    }
  }, {
    "type": "DidAuthPushModeVersion1",
    "id": "did:example:123456789abcdefghi#push",
    "serviceEndpoint": "http://auth.example.com/did:example:123456789abcdefghi"
  }, {
    "id": "did:example:123456789abcdefghi#bops",
    "type": "BopsService",
    "serviceEndpoint": "https://bops.example.com/enterprise/"
  }]
}