일반 DID 구문

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

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

아래는 ALPHA와 DIGIT을 정의하는 [[!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-name과 method-specific-id 구문을 정의함으로써 일반 DID 구문을 추가로 제한해야 한다. 더 상세한 내용은 섹션 참조.

일반 DID 매개변수 이름

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

일부 일반 DID 매개변수 이름(예를들면, 서비스 선택을 위한)은 어떠한 특정 DID 메소드와 완전히 독립적이어야 하며, 반드시 모든 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 경로는 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 URL이 DID 문서 오브젝트 안의 타겟 컴포넌트를 위해 DID URL 역참조 알고리즘([[DID-RESOLUTION]]을 볼 것)에 입력값으로 무조건 사용되어야한다.

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

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

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

did:example:123456#oidc
      

노말라이제이션

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

• DID 스키마는 무조건 소문자여야 한다
• DID 메소드 이름은 무조건 소문자여야 한다
• 의 method-specific-id 규칙의 값의 대소문자 구분과 정규화는 관리되고 있는 DID 메소드 정의에서 무조건 정의되야한다.

지속성(영속성)

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

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

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

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

예시:

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

위의 예시에서 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, serviceEndpoint 및 id 속성이 포함되어야 하며 추가적인 속성이 포함될 수 있다.

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 컨트롤러 (있는 경우).

이 증명은 DID와 DID 문서간의 연관성(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)

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

• The requirement to model complex multi-entity relationships is provided through the use of a graph-based data model.
• The requirement to enable extending the machine-readable vocabularies used to describe information in the data model — without relying on a centralized system — is accomplished via the use of [[LINKED-DATA]].
• The requirement to support multiple types of cryptographic proof formats is accomplished via the use of Linked Data Proofs [[LD-PROOFS]], Linked Data Signatures [[LD-SIGNATURES]], and a variety of signature suites.
• The requirement to provide all of the extensibility mechanisms outlined above in a data format that is popular among software developers and web page authors is enabled via the use of [[!JSON-LD]].

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, authentication 및 service 속성의 내용이 중요하지 않다. 중요한 것은 위의 개체가 유효한 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.

JSON

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

• IEEE754 표준과 같은 방식으로 기술한 숫자 값은 숫자 타입으로 표현해야 한다.
• 참과 거짓(boolean)으로 기술한 값은 불리언 타입으로 표현해야 한다.
• 열거된 값은 배열 타입으로 표현해야 한다.
• 순서없는 값의 집합은 배열 타입으로 표현해야 한다.
• 속성들의 집합은 객체(Object) 타입으로 표현해야 한다.
• 비어있는 값은 널(null)로 표현해야 한다.
• 이외의 나머지는 무조건 문자열 타입으로 표현해야 한다.

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가 제공하는 주목할만한 기능은 다음과 같다:

• @id와 @type 키워드는 각각 id와 type에 연결되며, 개발자가 이 명세서를 관용적인 JSON으로 처리할 수 있도록 한다.
• 정수형이나 날짜, 측정 단위, URL과 같은 데이터 타입은 자동적으로 타입이 정해진다. 그 이유는 그것을 요구하는 유즈 케이스에서 더 강력한 타입 보장을 지원하기 위함이다.
• JSON-LD 1.1의 @protected 속성은 이 명세서에 정의된 용어가 재정의되지 않도록 하는데 사용된다. 즉, 같은 @context 선언이 DID 문서의 꼭대기에 존재하는 한, JSON-LD 프로세서를 사용하는 프로그램과 사용하지 않는 프로그램간에 상호 운용성이 보장된다.