SSI와 DID에 대하여

오랭·2022년 8월 9일
1
post-thumbnail

신원 관리 모델의 종류

단계이름설명예시
1세대개별신원모델개별서비스마다 이용자의 ID와 PW를 저장하고 신원확인을 제공하는 시스템Gmarket, interpark, tmon...
2세대연합형신원모델다른 주체를 통해 인증google, kakao, naver...로 login
3세대자기주권신원모델개인의 정보를 자신이 소유, 개인정보 발급내역만 분산원장에 기록SSI,DID

SSI (Self Sovereignty Identity 자기주권 신원)

스스로 독림적인 권한을 가진 신원, 자신이 부여한 신원, 신원의 소유권을 가진 주체가 신원에 대한 권리를 가지고 공개 대상과 범위 선택.

SSI 형성요소

  1. DIDs : ID, PW
  2. DID Auth
  3. DKMS (Decentralized Key Management System 탈중앙화 키 관리 시스템)
  4. VC (Verifiable Credentials 검증가능한 크리덴셜)
    소유자가 어떤 것을 할수 있는 자격을 갖추었음을 검증하는 방법

SSI 구성요소

  1. Issuer 발행자
  2. Holder 소유자
  3. Verifier 검증자

DID (Decentralized Identity 탈중앙 신원 증명)

  • 데이터의 주권이 개인에게 있음.
  • 필요한 때 그 데이터를 중앙화된 시스템을 거치지 않고 증명.
  • 역할의 분리.
    • registry : 중앙화된 저장소
    • provider : 데이터 제공자
    • certificate authorities : 인증기관

중앙화된 방식이 탈 중앙화 될 수 있도록 설계해야 함.

데이터의 소유가 특정한 법인(중앙화된 기관 혹은 플랫폼)에 종속되는 것이 아니라 개인에게 이전 시킴.

DID Document라는 방식을 통해서 주체와 신뢰할 수 있는 상호작용을 하는 도구이며, 분산원장(블록체인)에서 사용하는 인증기술이라고 할 수 있다.
기존의 중앙화된 법인을 신뢰하기 보다는 분산원장을 신뢰하는 것이다.
사용자들은 DIDs(탈중앙 식별자)에 의해 식별이되고 증명을 통해


DIDs (Decentralized Identifiers 탈중앙화 식별자)

  1. Identity : 개인, 법인 구별 할 수 있는 고유 값.

  2. DID Document : DID 사용방법.

  3. DID Method : DID Documentdml 생성, 읽기, 갱신, 비활성화

  4. DID 형식 : did:example:문자열

    • did : 고정 prefix
    • example : did method 이름
    • did method 안에서 사용하는 고유 id
  5. DID Document 내용
    - id : 이 DID Document를 설명하는 ID
    - public key : 이 ID와 관련된 public key list
    - 인증 정보 : 이 ID의 소유권을 증명하기 위한 정보
    - service : 이 ID와 상호작용이 가능한 service들의 list
    ※ 어떠한 개인정보도 포함하지 않음.

  6. DID Registry
    DID Method가 다르고 DID 사용 platform이 모두 다르면 DID Document를 가져올 경우의 해결방법이 담겨 있음.

  7. DIF(Decentralized Identity Foundation) Global Organization
    이용자들이 보다 쉽게 사용하기 위해 만든 조직 (사용자 편의성, DID표준 제작...)

  8. DID Authentication 절차

    1. 법인이 DID 소유권자의 DID 유무 확인 시도
    2. 소유자는 법인에게 응답
    3. 응답받은 DID로 Universal Resolver에서 DID Document를 얻음
    4. 문서의 인증정보로 소유권자에게 받았던 응답 검사.
    5. 확인이 완료되면 인증 끝

VC (Verifiable Credentials 검증가능한 크리덴셜)

구성 요소

  1. Claim (각 단위데이터) : 주체 - 속성 mapping 되어있음.
  2. 객체 단위로 연결정보를 생성한다.

Claim의 기본 구조

단위 Claim은 다른 Claim과 결합하여 연결정보를 생성 가능.

구조

  1. Credential Metadata : Credential을 해석할 수있도록
  2. Claim : 주체에 대한 claim
  3. Proofs : Credential을 검증가능하도록 만드는 암호학적 요소들이 포함된 증명

VC가 적합한 발급자인지를 확인하기위한 4가지 요소

  1. Issuer의 DID인지 진위여부
  2. 사용자 DID인지 진위여부
  3. 블록체인 내에서의 발급내역 유무
  4. Schema 확인을 통해 형식이 맞는지 확인

VP (Verifiable Presentation 검증가능한 프레젠테이션)

증명을 할 때 필요한 정보만 담긴것. (원하는 정보만 선택적 취합 가능)

Verifiable Credential Graph

  • Claim으로 정보 확인 -> Digital Proof를 통해 확인
  • 발급내역이 블록체인에 쓰여졌는지 확인 (취소된 Credential 확인)
  • Issuer와 Holder의 Digital Signature(전자서명) 포함
  • 제대로된 Format인지 Schema 검증

아이콘 제작자: Retinaicons - Flaticon

profile
호기심천국

0개의 댓글