[DID] DID개발을 위한 DID, DID Document 개념정리

신규 프로젝트인
DID관련 업무를 위한 사전지식을 습득하고자
여러 가지 자료를 통해 학습한 결과를 정리해보려 한다.

DID구조

w3c 참조

• Scheme: did scheme을 따르겠다는 의미로 did scheme에서 정의한 접근 방식을 준수해 리소스를 찾아오겠다는 것을 명시
• DID Method:  DID Document가 저장된 위치(블록체인 네트워크명), 각 method는 사용할 블록체인을 정의하고 DID document를 찾는(resolve) 방법을 정의
• Method-specific identifier: 저장소 내 DID document의 정확한 위치를 검색하기 위한 고윳값으로, EOA(개인지갑주소) 또는 CA(컨트랙트주소)등이 올 수 있다.
• 예시
  • did:example:123456/path
    • path는 서비스 엔드포인트를 통해 사용가능한 리소스로 사용되어야 함
  • did:example:123456?query=true
    • 쿼리문 또한 서비스 엔드포인트를 통해 사용가능한 리소스로 사용되어야 함
  • did:example:123456#oidc
    • did document를 빠르게 찾아내기 위한 플래그

 

DID로 DID Document를 찾아오려면?

DID로 어떻게 문서를 찾아온다는 걸까?
DID는 URL 구문을 준수해야 하며 이는 RFC3968을 준수하는 URI체계이다.

이 DID는
곧 블록체인 원장 내의 문서의 위치를 위한 쿼리문역할로
데이터가 저장된 주소에 가서 값을 가져오는 원리다.

dereference(역참조)

데이터가 저장된 주소에 가서 값에 접근 →
DID Document가 저장된 장소에 접근해서 값을 가져와 다시 참조된 값을 가져옴
https://www.w3.org/TR/did-core/#did-url-dereferencing

 

Client-Side Dereferencing 

DID에 의해 URL이 역참조 되면
Resolver에 의해 수행되고
나머지 쿼리등의 리소스는 클라이언트에 의해 수행된다. 참고>>>>>>

1. did를 참고해 원장이 기록된 장소를 확인한다.
2. Resolver를 통해 did문서를 가져온다.
3. 가져온 문서에서 service키의 엔드포인트 참조가 있다면 가져온 did document 보조리소스 부분을 쿼리스트링으로 사용해 URL로 반환한다.

 

DID는 결국
Document를 가져오기 위한 URL역할을 하며
누구든 값을 잘 참조할 수 있도록 modeling 하는 것이 중요하다

---

DID Document 분석

DID Auth Architecture List >>>>>
 

DID & DID Document Convention

• did 문서는 반드시 JSON-LD 객체여야 함
• 숫자는 숫자타입
• 순서 없는 값의 집합은 배열
• 속성의 집합은 객체타입
• 비어있는 값은 null로 표현
• 이외에는 문자열

• did 스키마는 무조건 소문자
• did 메서드 이름은 무조건 소문자
• 비활성화되더라도 영속해야 함 재사용불가
• "id" 속성이 없는 형태로 생성될 수 있지만, 최종적으로 해석된 문서는 반드시 유효한 "id" 속성을 가져야 하며, 그 값은 해당 DID 주체를 나타내는 데 사용됩니다. 이렇게 하여 DID의 일관성과 신뢰성을 유지할 수 있음

DID Document 예시 (링크)

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [
    "did:example:123456789abcdefghi#keys-1",
		"did:example:123456789abcdefghi#keys-2"
 	],
  "verificationMethod": [
       {
        "id": "did:example:123456789abcdefghi#keys-1",
        "type": "Ed25519VerificationKey2018",
        "controller": "did:example:123456789abcdefghi",
        "publicKeyBase58": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
       }, 
       {
        "id": "did:example:123456789abcdefghi#keys-2",
        "type": "Ed25519VerificationKey2018",
        "controller": "did:example:123456789abcdefghi",
        "publicKeyBase58": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
       }
 	],	
  "service": [
       {
        "id":"did:example:123456789abcdefghi#vcs",
        "type": "VerifiableCredentialService",
        "serviceEndpoint": "https://example.com/vc/"
       }
    ]
}

@context 

• 데이터 주체들 간의 속성이 무엇을 의미하고 어떤 타입인지 정의하기 위해 사용하는데 인터페이스로 사용된다.
• JSON-LD 문법에 따라 정의(JS object notation for linked data)
• 하나하나를 정의해 줄 수도 있지만 이 양이 너무 많을 경우 (속성값이 너무 많을 경우) @context 이미 정의된 URI를 사용할 수 있음
• 일종의 타입선언임으로 가장 처음에 위치되어야 한다

verificationMethod

authentication 또는 service endpoint를 참조하는데 기초가 되는 서명, 암호화, 암호연산에 사용되는 항목이다.

컨트롤러와 홀더가 다른경우

- 홀더가 어떤 소속을 증명하고자 할경우 다른 3자가 인증을 해야할경우 컨트롤러에 제3자의 아이디가 들어가있음
- 검증자는 제3자에게 인증요청
- 제3자는 홀더에게 did발급기록 있는지 확인
- 기록이 있을경우 did를 생성할떄 만든 비대칭키로 did auth 진행

  {
      "id": "did:example:123456789abcdefghi#keys-1",    //인증 방식의 ID로 내가 사용하고자 하는 인증방식이 위의 키라면 해당 ID를 검증자에게 보낸다.
      "type": "Ed25519VerificationKey2018",             //암호화 방식
      "controller": "did:example:123456789abcdefghi",   //인증권한을 가진 사람(홀더 또는 제 3자)
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" //소유권 인증에 사용될 공개키값
  }

authentication

DID주체는 본인의 DID를 다른 객체에게 알려주면
다른 객체는 이 DID의 진위여부를 확인하는 DID Auth과정을 거친다.
이 과정에서 필요한 값을 기록한 곳

{
...
  "authentication": [
    "did:example:123456789abcdefghi#keys-1", //인증시
    "did:example:123456789abcdefghi#biometric-1", //인증시
    {
      "id": "did:example:123456789abcdefghi#keys-2",     //다른 증명 목적으로 사용될수 없는 전용 권한
      "type": "Ed25519VerificationKey2018",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],
 ...
}

위의 예시를 통해 각 키들을 정리해 보자면 아래와 같이 유추해 볼 수 있다.

DID 참조 (DID Reference)	DID 컨트롤러가 did:example:123456789abcdefghi#keys-1를 사용하여 인증한 경우	클라이언트 애플리케이션 또는 다른 DID 컨트롤러
생체 인식 (Biometric)	DID 컨트롤러가 did:example:123456789abcdefghi#biometric-1를 사용하여 인증한 경우	생체 인식 장치 또는 클라이언트 애플리케이션
디지털 서명 (Digital Signature)	DID 컨트롤러가 디지털 서명 방식 (type: "Ed25519VerificationKey2018")을 사용하여 인증한 경우	클라이언트 애플리케이션 또는 다른 DID 컨트롤러, 공개키로 사용하고싶지 않을경우 포함한다.

service

• 나에게 정보를 요구하거나 나의 신원을 확인하고자 할 때 다른 이용자가 확인할 수 있도록 해주는 안내가이드나 이정표
• did를 활용한 서비스들을 의미(공개키를 바꾸는 기능 등)
• 홀더와 컨트롤러가 다를 경우 컨트롤러에게 인증요청을 보내는 요청명세등이 서비스항목에 포함됨

예시) 서비스 예시

{
  "id": "did:example:123456789abcdefghi",
  "service": [
    {
      "type": "EmailService",
      "serviceEndpoint": "mailto:info@example.com"
    },
    {
      "type": "VerifiableCredentialService",
      "serviceEndpoint": "https://example.com/vc/"
    }
  ]
}

 
EmailService

• type은 "EmailService"
• serviceEndpoint는 "mailto:info@example.com"으로 이메일 서비스를 나타낸다.
• DID 주체가 이 이메일 주소를 공개함으로써 다른 사용자가 DID 주체에게 이메일로 연락할 수 있다.
• DID 주체의 이메일 주소를 확인하고, "mailto" 프로토콜을 통해 이메일을 보낼 수 있다:

VerifiableCredentialService

• type은 "VerifiableCredentialService"
• serviceEndpoint는 "https://example.com/vc/"로 신원 확인 자격증을 관리하는 서비스를 나타냄.
• DID 주체는 이 서비스를 통해 신원 확인 자격증을 발급하고 관리할 수 있음.
• 다른 주체는 DID 주체의 신원 확인 자격증 서비스에 접근하여 자격증을 요청하거나 확인. (신원 확인 및 권한 부여가 가능)

 

authentication vs assertionMethod vs verificationMethod 비교이해

비슷한 키가 중복으로 들어가는 경우가 많고, 같은 공개키주소가 여러 key에 쓰여있어  한번에 이해되진 않는다.
각각의 키가 쓰임새가 다르므로 확인하고 모델링해야 한다.
 
개념설명주요 사용 시기

개념	설명	주요사용시기
authentication	DID 주체가 자신의 신원을 확인하기 위해 사용하는 키 또는 메서드	로그인, 트랜잭션 서명 등 신원 확인 시 사용 (자신임을 입증할때)
assertionMethod	DID 주체가 다른 엔터티에게 주장을 할 때 사용하는 키 또는 메서드	주장을 생성하고 검증할 때 사용(주장을 만들어 내거나 검증할떄 사용하는 키)
verificationMethod	주장을 받은 엔터티가 주장의 진위를 검증하기 위해 사용하는 키 또는 메서드	주장을 검증할 때 사용, 주장을 받은 쪽에서 활용 (주로 상대방이 DID주체에게 주장을 받았을때 주장의 서명을 확인할때 이 메서드의 키 사용)

 

DID resolver

DID를 해석하는데 필요하며 하나이상의 DID 메서드를 가져야 한다.
 

DID Auth Flow (소유권 인증 과정)

1. DID주체는 본인의 DID를 다른 객체에게 알려주면 다른 객체는 이 DID를 통해 universal resolver등과 같은 해석기 이용해 DID document를 가져온다.
2. 객체는 가져온 문서중 이 DID가 정말 본인의 것인지 문서의 적혀있는 공개키를 이용해 암호화한 메시지를 전송해 인증을 요구한다(Challenge)
3. DID주체는 객체의 메시지를 받고 개인키로 해독한 뒤 이 메시지의 해답을 response로 전송한다.
4. 객체는 본인이 맞는지 확인한다.

Challenge-Response 인증방식(비대칭방식)

• 한쪽은 암호화, 다른 한쪽은 복호화 진행
• 양쪽이 같은 값인지 확인, 공격자가 재사용할 수 없도록 사용할 때마다 의미 없는 난수(nonce) 값

DID Auth Interaction 구성 시 주요 참고 사항

• Relying Party의 주소 확인:  사용자가 DID 문서를 잘 찾을 수 있도록 정확한 주소를 안내해주고 있는가?
• DID Auth Challenge의 Transport Mechanism: 사용자는 암호화된 데이터를 보내고, RP는 해당 데이터를 해독하여 사용자를 인증할 수 있는가
• Authentication Material의 저장 위치: 키가 안전하게 보관되어 있고, 필요할 때 사용할 수 있는 곳에 있는가?
• DID Auth Response의 Transport Mechanism: 사용자의 응답 데이터는 안전한 방식으로 RP에게 전달되어 검증과 인증에 사용할 수 있는가?

 

참고

---

https://en.wikipedia.org/wiki/Challenge–response_authentication
https://benny-jung.medium.com/did-기술-분석-did-auth-2-dced244c4dec
탈중앙 식별자 Decentralized Identifiers (DIDs) v1.0
검증가능한 크리덴셜 데이터 모델 (Verifiable Credentials Data Model) 1.0
SSI Introduction